CN114004319A - 轨道交通乘车验证方法、系统和装置 - Google Patents

Abstract

本申请涉及一种轨道交通乘车验证方法、系统、装置、计算机设备和存储介质。通过在检测到二维码展示指令时，基于待验证用户的用户标识查询健康码大数据中心，获取用户标识对应的健康数据。并根据用户标识获取对应的支付账户信息，基于支付账户信息生成支付二维码结构数据，再根据支付二维码结构数据和健康数据，生成对应的目标二维码并展示，以供轨道交通验证设备根据目标二维码验证用户的健康信息和行程信息。相较于传统的将健康码和乘车码分开检测的方式，本方案通过将健康码和乘车码的信息结合到同一个二维码中，可以提升乘车时的验证效率。

Description

轨道交通乘车验证方法、系统和装置

技术领域

本申请涉及互联网技术领域，特别是涉及一种轨道交通乘车验证方法、系 统、装置、计算机设备和存储介质。

背景技术

随机计算机技术发展，目前乘坐轨道交通工具时，通过扫描二维码过闸机 已成为乘客的选择之一，然而在目前的环境下，乘坐轨道交通工具前需要对乘 客的健康状况进行确认，例如通过检查健康码的方式确认等，乘客需要在入闸 前先出示健康码，然后再切换到乘车码进行坐车，导致来回切换不方便。

因此，目前乘坐交通工具的验证方式存在验证效率低的缺陷。

发明内容

基于此，有必要针对上述技术问题，提供一种能够提升效率的轨道交通乘 车验证方法、系统、装置、计算机设备和存储介质。

一种轨道交通乘车验证方法，应用于移动终端，所述方法包括：

响应于二维码展示指令，获取待验证用户对应的用户标识，并根据所述用 户标识查询健康码大数据中心，获取所述用户标识对应的健康数据；

根据所述用户标识获取对应的支付账户信息，并根据所述支付账户信息生 成支付二维码结构数据；

根据所述支付二维码结构数据以及所述健康数据，生成对应的目标二维码 并展示，以供轨道交通验证设备根据所述目标二维码对所述待验证用户的健康 信息和行程信息进行验证。

在其中一个实施例中，所述根据所述用户标识获取对应的支付账户信息， 包括：

根据所述用户标识查询轨道交通乘客数据库，确定所述待验证用户是否存 在未支付订单和/或所述待验证用户是否为黑名单用户；

若所述待验证用户不存在未支付订单并且所述待验证用户不为黑名单用 户，获取所述用户标识对应的支付机构信息，并根据所述支付机构信息获取对 应的支付账户信息。

在其中一个实施例中，所述根据所述支付机构信息获取对应的支付账户信 息，包括：

根据所述支付机构信息查询所述移动终端的缓存，确定所述缓存中存在所 述支付机构信息对应的支付账户信息；

若是，从所述缓存中获取所述支付账户信息；

若否，根据所述支付机构信息查询所述轨道交通乘客数据库，以获取所述 支付账户信息并基于所述支付账户信息更新所述缓存。

在其中一个实施例中，所述获取所述用户标识对应的健康数据之后，还包 括：

根据所述健康数据查询所述健康码大数据中心；

若确定所述健康数据为异常健康码对应的数据，获取所述异常健康码对应 的健康告警信息以通知所述待验证用户。

一种轨道交通乘车验证方法，应用于轨道交通验证设备，所述方法包括：

获取移动终端展示的目标二维码，提取所述目标二维码中的健康数据以及 支付二维码结构数据；

根据所述健康数据验证待验证用户的健康信息并验证所述支付二维码结构 数据中的数据是否正确；

若检测到所述待验证用户的健康信息为正常健康码对应的健康信息以及所 述支付二维码结构数据正确，生成所述待验证用户对应的行程信息并基于轨道 交通乘客数据库验证所述待验证用户的行程信息；

若确定所述行程信息正确，向轨道交通验证设备对应的检票设备发送放行 指令，以使所述检票设备打开闸门允许所述待验证用户通过。

在其中一个实施例中，所述验证所述支付二维码结构数据中的数据是否正 确，包括：

获取所述支付二维码机构数据中的生成时间、密钥、签名数据以及支付机 构信息；

若检测到所述生成时间未过期、所述密钥正确、所述签名数据有效以及所 述支付机构信息正确，确定所述支付二维码结构数据中的数据正确；

和/或，

所述基于轨道交通乘客数据库验证所述待验证用户的行程信息，包括：

向轨道交通乘客数据库发送指令信息包含所述行程信息的查询指令，以使 所述轨道交通数据库在检测到所述行程信息为所述待验证用户的唯一行程、所 述行程信息对应的进出站逻辑顺序正确、所述行程信息的授权有效以及所述行 程时间在预设时间范围内时，向所述轨道交通验证设备返回行程信息验证通过 信息；

若接收到所述轨道交通乘客数据库发送的行程信息验证通过信息，确定所 述行程信息通过验证。

在其中一个实施例中，所述方法还包括：

若检测到所述待验证用户通过闸门以及所述行程信息为所述待验证用户的 出站行程信息，获取所述出站行程信息对应的入站行程信息；

根据所述出站行程信息以及所述入站行程信息，获取所述待验证用户对应 的计费信息；

向所述支付二维码结构数据对应的支付机构发送请求信息包含所述计费信 息以及所述待验证用户对应的支付账户信息的请款请求，以使所述支付机构根 据所述计费信息扣除所述支付账户信息中对应的费用。

一种轨道交通乘车验证系统，包括：移动终端和轨道交通验证设备；其中，

所述移动终端，用于响应于二维码展示指令，获取待验证用户对应的用户 标识，并根据所述用户标识查询健康码大数据中心，获取所述用户标识对应的 健康数据；根据所述用户标识获取对应的支付账户信息，并根据所述支付账户 信息生成支付二维码结构数据；根据所述支付二维码结构数据以及所述健康数 据，生成对应的目标二维码并展示；

所述轨道交通验证设备，用于获取移动终端展示的目标二维码，提取所述 目标二维码中的健康数据以及支付二维码结构数据；根据所述健康数据验证所 述待验证用户的健康信息、验证所述支付二维码结构数据中的数据是否正确； 若检测到所述待验证用户的健康信息为正常健康码对应的健康信息以及所述支 付二维码结构数据正确，生成所述待验证用户对应的行程信息并基于轨道交通 乘客数据库验证所述待验证用户的行程信息；若确定所述行程信息正确，向轨 道交通验证设备对应的检票设备发送放行指令，以使所述检票设备打开闸门允 许所述待验证用户通过。

一种轨道交通乘车验证装置，应用于移动终端，所述装置包括：

获取模块，用于响应于二维码展示指令，获取待验证用户对应的用户标识， 并根据所述用户标识查询健康码大数据中心，获取所述用户标识对应的健康数 据；

生成模块，用于根据所述用户标识获取对应的支付账户信息，并根据所述 支付账户信息生成支付二维码结构数据；

展示模块，用于根据所述支付二维码结构数据以及所述健康数据，生成对 应的目标二维码并展示，以供轨道交通验证设备根据所述目标二维码对所述待 验证用户的健康信息和行程信息进行验证。

一种轨道交通乘车验证装置，应用于轨道交通验证设备所述装置包括：

二维码获取模块，用于获取移动终端展示的目标二维码，提取所述目标二 维码中的健康数据以及支付二维码结构数据；

验证模块，用于根据所述健康数据验证待验证用户的健康信息并验证所述 支付二维码结构数据中的数据是否正确；

生成模块，用于若检测到所述待验证用户的健康信息为正常健康码对应的 健康信息以及所述支付二维码结构数据正确，生成所述待验证用户对应的行程 信息并基于轨道交通乘客数据库验证所述待验证用户的行程信息；

发送模块，用于若确定所述行程信息正确，向轨道交通验证设备对应的检 票设备发送放行指令，以使所述检票设备打开闸门允许所述待验证用户通过。

上述轨道交通乘车验证方法、系统、装置、计算机设备和存储介质，通过 在检测到二维码展示指令时，基于待验证用户的用户标识查询健康码大数据中 心，获取用户标识对应的健康数据。并根据用户标识获取对应的支付账户信息， 基于支付账户信息生成支付二维码结构数据，再根据支付二维码结构数据和健 康数据，生成对应的目标二维码并展示，以供轨道交通验证设备根据目标二维 码验证用户的健康信息和行程信息。相较于传统的将健康码和乘车码分开检测 的方式，本方案通过将健康码和乘车码的信息结合到同一个二维码中，可以提 升乘车时的验证效率。

附图说明

图1为一个实施例中轨道交通乘车验证方法的应用环境图；

图2为一个实施例中轨道交通乘车验证方法的流程示意图；

图3为一个实施例中二维码生成步骤的流程示意图；

图4为一个实施例中加密步骤的流程示意图；

图5为一个实施例中获取用户健康数据步骤的流程示意图；

图6为另一个实施例中轨道交通乘车验证方法的流程示意图；

图7为一个实施例中通知步骤的流程示意图；

图8为一个实施例中流量控制步骤的流程示意图；

图9为一个实施例中日志存储步骤的流程示意图；

图10为一个实施例中监控步骤的流程示意图；

图11为一个实施例中轨道交通乘车验证装置的结构框图；

图12为另一个实施例中轨道交通乘车验证装置的结构框图；

图13为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实 施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅 用以解释本申请，并不用于限定本申请。

本申请提供的轨道交通乘车验证方法，可以应用于如图1所示的应用环境 中。其中，移动终端102与轨道交通验证设备104进行通信，并且移动终端102 和轨道交通验证设备104均可以通过网络和轨道交通票务系统106进行通信。 移动终端102中设置有应用程序以及应用程序后台，应用程序和应用程序后台 通过无线网络进行通信。轨道交通票务系统106设置有多种功能类型的模块， 轨道交通票务系统106可以设置在轨道交通验证设备104中，也可以是与轨道 交通验证设备通过物理相连接的服务器中。移动终端102可以在检测到二维码 展示指令时，从应用程序后台获取用户标识，并查询健康码大数据中心，获取 用户标识对应的健康数据，并根据用户标识，从轨道交通票务系统106中获取 对应的支付账户信息，基于支付账户信息生成支付二维码结构数据，还可以基 于支付二维码结构数据和健康数据，生成对应的目标二维码并展示，轨道交通 验证设备104可以对目标二维码进行扫描，从而轨道交通验证设备104可以对 用户的健康信息和行程信息进行验证。其中，移动终端102与轨道交通票务系 统106，以及轨道交通验证设备104与轨道交通票务系统106之间的通信可以通 过网关模块进行，网关模块可以用于轨道交通验证设备104与轨道交通票务系 统106的通信工作，作为所有API接口服务的接入点和聚合点，实现安全、路 由、过滤等策略。移动终端102可以但不限于是各种个人计算机、笔记本电脑、 智能手机、平板电脑和便携式可穿戴设备，轨道交通票务系统106可以用独立 的服务器或者是多个服务器组成的服务器集群来实现。

在一个实施例中，如图2所示，提供了一种轨道交通乘车验证方法，以该 方法应用于图1中的终端为例进行说明，包括以下步骤：

步骤S202，响应于二维码展示指令，获取待验证用户对应的用户标识，并 根据用户标识查询健康码大数据中心，获取用户标识对应的健康数据。

其中，二维码展示指令可以是用户触发的指令，当用户需要使用轨道交通 工具时，用户可以通过移动终端102触发二维码展示指令。例如通过移动终端 102中的相应APP进行触发。移动终端102检测到用户触发了二维码展示指令 后，可以通过APP后台获取待验证用户对应的用户标识。该用户标识可以是可 以代表该用户唯一特征的信息。移动终端102可以根据该用户标识查询健康码 大数据中心，并获取用户标识对应的健康数据，从而移动终端102可以基于该 健康数据和支付信息结合生成相应的二维码。

其中，健康码大数据中心可以是存储有多个用户的健康信息的设备，该健 康码大数据中心也可以设置在轨道交通票务系统106中，例如轨道交通票务系 统106中的健康码模块，健康码模块可以用来获取个人最新的健康信息数据， 健康码数据分为红码数据、黄码数据、绿码数据。红码数据代表提示持码人属 于高风险人员；黄码数据代表提示持码人属于居家健康管理、待核酸检测风险 人员；绿码数据代表提示持码人健康风险状态正常。二维码乘车码生成过程中 需调用健康码模块获取个人最新的健康信息数据并与乘车码数据结合在一起生 成二维码乘车码和健康码相结合的码。例如，移动终端102生成乘车码和健康 码结合的二维码的流程可以如图3所示，图3为一个实施例中二维码生成步骤 的流程示意图。移动终端102中可以设置有相应的APP，例如乘车APP，移动 终端102通过APP后台与网关模块通信，并通过网关模块与乘客事务模块通信， 通过乘客事务模块获取乘客相关信息，例如乘客的支付相关信息，以及移动终 端102调用健康码模块获取用户对应的最新的健康数据。另外，移动终端102 还可以对数据进行加密传输。例如，如图4所示，图4为一个实施例中加密步 骤的流程示意图。在一些实施例中，移动终端102在调用乘客事务模块时，可以对数据进行数据加密。其中，轨道交通票务系统106和移动终端102所采用 的加密算法有3DES算法和SM2算法，这两种算法都具有加密速度快、加密强 度高的技术特点。3DES加密算法不是一种全新的算法，只是DES加密算法的 一种模式，比DES安全性更高，它使用3条64位的密钥对数据进行三次加密， 这样就将密钥的强度提高到112位。SM2算法是选用国密标准256位长的密钥 用于证书签名和验签。SM2算法全称为椭圆曲线算法，SM2对比RSA在安全和性能上具有优势，256位的密钥强度和2048位RSA密钥强度相当，采用SM2 的签名数据为64字节，比2048位的RSA签名数据要短很多。具体地，上述乘 客事务模块可以将待加密的二维码结构数据发送给加密模块，加密模块接收后 对二维码结构数据进行加密后返回给乘客事务模块。二维码结构数据包括但不 限于行业数据、行业数据长度、证书版本、证书数据签名算法标识、动态数据 签名算法标识、密钥版本、用户账号编号、账户发行方、证书签发时间、证书 失效时间、二维码有效时间、用户信用等级、证书签名数据等。通过对数据进 行加密，可以实现提高数据安全性的效果。

另外，在一个实施例中，获取用户标识对应的健康数据之后，还包括：根 据健康数据查询健康码大数据中心；若确定健康数据为异常健康码对应的数据， 获取异常健康码对应的健康告警信息以通知待验证用户。本实施例中，移动终 端102在获取用户的最新健康数据时还可以对获取的数据进行检查，确定用户 的健康数据是否正常。例如，移动终端102可以根据用户的健康数据查询健康 码大数据中心，若确定健康数据为异常健康码对应的数据，如黄码或红码，则 移动终端102可以获取该异常健康数据对应的告警信息通知待验证用户。具体 地，上述获取健康数据的流程可以如图5所示。图5为一个实施例中获取用户健康数据步骤的流程示意图。移动终端102可以调用健康码模块，从健康码大 数据中心中获取用户的健康数据，并检测乘客的健康数据是否正常。例如，在 二维码乘车码和健康码相结合的码生成过程中，移动终端102可以调用健康码 模块获取乘客个人的健康码数据，而健康码模块是从健康码大数据中心提供的 API查询乘客的健康码数据。若乘客的健康码数据为黄码或者红码则发送告警信 息给告警模块存储，同时调用通知模块提供的短信方法发送短信给乘客手机上 提示当前健康码数据为黄码或者红码。若乘客的健康码数据为绿码则不发送告 警信息给告警模块。其中，通知模块是将告警信息通过发送短信或者邮件方式 通知系统的运维人员。告警模块是接收各个应用服务和所有的自动检票机设备 的告警信息后并及时通过短信或邮件通知到系统运维人员，从而进一步可以帮 助系统运维人员第一时间收到相应的告警信息并及时做好应对的措施。告警规 则规定告警发生条件，当符合产生条件的事件发生时，监控模块会监测到该事 件并产生一条告警信息。告警规则按照类型为设备告警规则、应用告警规则和 服务网络告警规则，告警规则设置包括规则名称、规则类型、触发条件、监测 时间、告警频率、告警级别、消息通知方式、描述等内容。除了上述对异常健 康数据的告警外，告警规则还包括但不限于过去1分钟内服务的CPU使用率超 过90％、过去1分钟内服务的内存使用率超过90％、过去3分钟内服务平均响 应时间超过1秒、服务成功率在过去2分钟内低于80％、服务90％响应时间在 过去3分钟内低于1000毫秒、服务实例在过去2分钟内的平均响应时间超过1 秒、端点平均响应时间过去2分钟超过1秒。

步骤S204，根据用户标识获取对应的支付账户信息，并根据支付账户信息 生成支付二维码结构数据。

其中，支付账户信息可以是需要进行验证的用户的支付账户信息。移动终 端102可以利用上述用户标识，获取需要进行验证的用户对应的支付账户信息， 该支付账户信息可以用于生成乘车码，用户使用乘车码通过轨道交通验证设备 104时，轨道交通验证设备104可以从对应的支付账户上扣除相应的金额，实现 乘车扣费。而本实施例中，该支付账户信息可以用于生成和健康数据结合的二 维码，例如，移动终端102可以根据上述支付账户信息生成相应的用于支付的 支付二维码结构数据。

步骤S206，根据支付二维码结构数据以及健康数据，生成对应的目标二维 码并展示，以供轨道交通验证设备104根据目标二维码对待验证用户的健康信 息和行程信息进行验证。

其中，支付二维码结构数据可以是移动终端102根据用户的支付账户信息 生成的数据，健康数据可以是移动终端102基于用户标识查找到的用户的健康 信息对应的数据。移动终端102可以基于支付二维码结构数据和健康数据生成 目标二维码，例如，移动终端102将支付二维码结构数据和健康数据结合并组 装成包含两者信息的新的数据，形成相应的结合二维码，从而移动终端102可 以将二维码进行展示。轨道交通验证设备104可以检测到上述结合的目标二维 码，并基于目标二维码验证用户的健康信息和行程信息。例如结合轨道交通票 务系统106进行验证。

上述轨道交通乘车验证方法中，通过在检测到二维码展示指令时，基于待 验证用户的用户标识查询健康码大数据中心，获取用户标识对应的健康数据。 并根据用户标识获取对应的支付账户信息，基于支付账户信息生成支付二维码 结构数据，再根据支付二维码结构数据和健康数据，生成对应的目标二维码并 展示，以供轨道交通验证设备根据目标二维码验证用户的健康信息和行程信息。 相较于传统的将健康码和乘车码分开检测的方式，本方案通过将健康码和乘车 码的信息结合到同一个二维码中，可以提升乘车时的验证效率。

在一个实施例中，根据用户标识获取对应的支付账户信息，包括：根据用 户标识查询轨道交通乘客数据库，确定待验证用户是否存在未支付订单和/或待 验证用户是否为黑名单用户；若待验证用户不存在未支付订单并且待验证用户 不为黑名单用户，获取用户标识对应的支付机构信息，并根据支付机构信息获 取对应的支付账户信息。

本实施例中，移动终端102可以基于用户标识获取用户对应的支付账户信 息。移动终端102可以根据用户标识查询轨道交通乘客数据库，该数据库可以 设置在轨道交通票务系统106中，移动终端102可以查询该需要验证的用户首 付存在未支付订单、是否为黑名单用户中的一项或多项；若移动终端102检测 到上述需要验证的用户不存在未支付订单，并且该用户不为黑名单用户，则移 动终端102可以获取用户标识对应的支付机构信息，该支付机构信息可以是第 三方的支付机构，并且该支付机构可以是与用户进行绑定的支付机构，移动终 端102可以从支付机构中获取用户对应的支付账户信息，从而移动终端102可以基于支付账户信息生成对应的支付二维码结构数据。例如，在乘客需要乘坐 交通工具时，用户在移动终端102中打开APP，若乘客未登录APP则提示乘客 需登录APP，若乘客未进行用户实名认证则需要认证后才允许生成二维码乘车 码和健康码结合的码，因为未实名认证是无法获取健康码相关数据及乘车码的 行业数据的，同时为了确保数据安全，在亮码扫码使用时，均需本人授权。若 已登录且经过本人授权后则允许点击乘车码后访问APP后台，APP后台通过网 关模块访问乘客事务模块，并基于乘客事务模块首先检测用户是否存在待支付 的乘车订单，若存在则返回提示让乘客进行支付。若不存在则检验当前乘客账号是否为黑名单，若是则返回提示给乘客禁止通行，若不是黑名单后检验乘客 是否未绑定第三方支付，若未绑定则返回给乘客提示需绑定第三方支付，即上 述的支付机构信息。若已绑定第三方支付则向查询是否存在行业数据，若存在 行业数据则读取行业数据组装二维码结构数据。其中，行业数据可以包含上述 的支付账户信息。

通过本实施例，移动终端102可以利用轨道交通乘客数据库确定用户没有 待支付订单以及不是黑名单用户时才获取用户的支付账户信息，实现提高对二 维码验证的安全性的效果。

在一个实施例中，根据支付机构信息获取对应的支付账户信息，包括：根 据支付机构信息查询移动终端的缓存，确定缓存中存在支付机构信息对应的支 付账户信息；若是，从缓存中获取支付账户信息；若否，根据支付机构信息查 询轨道交通乘客数据库，以获取支付账户信息并基于支付账户信息更新缓存。

本实施例中，移动终端102可以从缓存中获取上述用户对应的支付账户信 息。移动终端102可以根据上述获取的支付机构信息查询移动终端102的缓存， 查询缓存中是否存在支付账户信息，若是，则移动终端102从缓存中获取支付 账户信息；否则，移动终端102利用支付机构信息查询轨道交通乘客数据库， 从而获取支付账户信息并基于该支付账户信息更新缓存，从而移动终端102可 以基于该支付账户信息结合用户的健康数据生成对应的二维码。例如，移动终 端102可以在确定乘客已绑定第三方支付时，向缓存查询是否存在行业数据， 若存在行业数据则读取缓存中的行业数据组装二维码结构数据后，获取健康码模块的乘客个人最新的健康信息数据，将二维码结构数据与乘客个人最新的健 康信息数据结合生成新的数据后并通过加密模块加密后利用移动终端102中的 APP生成二维码。若缓存不存在行业数据则查询乘客事务模块的数据库并更新 缓存，例如查询上述轨道交通乘客数据库，得到行业数据后组装二维码结构数 据，获取健康码模块的乘客个人最新的健康信息数据，将二维码结构数据与乘 客个人最新的健康信息数据结合生成新的数据后并通过加密模块加密后返回给 乘客APP生成二维码。其中，上述行业数据包括上述支付账户信息。

通过本实施例，移动终端102可以从缓存中获取用户对应的支付账户信息 等数据，提高了二维码生成的效率，进而提高了二维码验证的效率。

在一个实施例中，如图6所示，提供了一种轨道交通乘车验证方法，以该 方法应用于图1中的轨道交通验证设备为例进行说明，包括以下步骤：

步骤S302，获取移动终端展示的目标二维码，提取目标二维码中的健康数 据以及支付二维码结构数据。

其中，轨道交通验证设备104可以是设置在轨道交通工具站场中的设备， 可以用于进行乘车验证。本实施例中，轨道交通验证设备104可以用于验证用 户的行程信息和健康信息。移动终端102可以生成包含乘客的健康数据和支付 二维码结构数据的目标二维码并展示给轨道交通验证设备104，轨道交通验证设 备104可以获取移动终端102展示的目标二维码，例如通过设置在轨道交通验 证设备104中的扫描设备捕获到目标二维码的信息，从而轨道交通验证设备104 可以提取目标二维码中的健康数据和支付二维码结构数据。

例如，上述轨道交通验证设备104可以是自动检票机，自动检票机上装有 识别二维码的装置，负责对用户APP生成的二维码乘车码和健康码结合的码进 行扫描采集。

步骤S304，根据健康数据验证待验证用户的健康信息并验证支付二维码结 构数据中的数据是否正确。

其中，轨道交通验证设备104可以利用上述获取的健康数据，验证需要验 证的用户的健康信息；例如验证用户的健康信息是否处于健康状态；轨道交通 验证设备104还可以验证上述目标二维码中的支付二维码结构数据中的数据是 否正确；例如验证支付二维码结构数据是否有效等信息。

步骤S306，若检测到待验证用户的健康信息为正常健康码对应的健康信息 以及支付二维码结构数据正确，生成待验证用户对应的行程信息并基于轨道交 通乘客数据库验证待验证用户的行程信息。

其中，轨道交通验证设备104可以对需要验证的用户的健康信息和支付二 维码结构数据进行验证。当轨道交通验证设备104检测到上述用户的健康信息 为正常健康码对应的信息以及支付二维码结构数据正确时，可以生成上述用户 对应的行程信息，并且可以调用轨道交通票务系统106，利用轨道交通乘客数据 库验证上述待验证用户的行程信息。例如，自动检票机可以将采集到二维码乘 车信息打上进站或者出站的标识，生成用户的进站或者出站行程，通过物理传 输网络上送到轨道交通票务系统106的网关模块，网关模块将用户行程信息透 传给交易匹配模块，从而进行交易信息等校验。

步骤S308，若确定行程信息正确，向轨道交通验证设备104对应的检票设 备发送放行指令，以使检票设备打开闸门允许待验证用户通过。

其中，轨道交通验证设备104可以对上述用户的行程信息进行检测，若检 测到行程信息正确，则轨道交通验证设备104可以向其对应的检票设备发送放 行指令，从而检票设备接收到该指令后，可以打开闸门允许上述用户通过。例 如，行程信息可以包括出站行程和入站行程，轨道交通验证设备104针对不同 类型的行程信息采用不同的检测方式，从而确定是否允许出站或进站。

上述轨道交通乘车验证方法中，通过在检测到二维码展示指令时，基于待 验证用户的用户标识查询健康码大数据中心，获取用户标识对应的健康数据。 并根据用户标识获取对应的支付账户信息，基于支付账户信息生成支付二维码 结构数据，再根据支付二维码结构数据和健康数据，生成对应的目标二维码并 展示，以供轨道交通验证设备根据目标二维码验证用户的健康信息和行程信息。 相较于传统的将健康码和乘车码分开检测的方式，本方案通过将健康码和乘车 码的信息结合到同一个二维码中，可以提升乘车时的验证效率。

在一个实施例中，验证支付二维码结构数据中的数据是否正确，包括：获 取支付二维码机构数据中的生成时间、密钥、签名数据以及支付机构信息；若 检测到生成时间未过期、密钥正确、签名数据有效以及支付机构信息正确，确 定支付二维码结构数据中的数据正确。

本实施例中，轨道交通验证设备104可以从移动终端102展示的目标二维 码中提取支付二维码结构数据，并验证该支付二维码结构数据中的数据是否正 确。轨道交通验证设备104验证的信息包括生成时间、密钥、签名数据以及支 付机构信息等。其中，支付机构信息可以是用户的支付账户的账户发行方。轨 道交通验证设备104可以在检测到上述生成时间未过期、密钥正确、签名数据 有效以及支付机构信息正确时，确定该支付二维码结构数据中的数据正确；反 之，若其中一项信息不正确，则确定该支付二维码结构数据不正确。例如，上 述轨道交通验证设备104可以是自动检票机；自动检票机对乘客所展示的二维 码乘车码和健康码结合的码进行扫描采集，自动检票机采集二维码结构数据后 并对数据解密分析处理，首先检验健康码数据是否为黄码或者红码，若是则禁 止乘客过闸并给出相应的提示，同时若是绿码则对二维码结构数据进行检验。 检验的内容包括二维码生成时间是否过期、密钥比较是否正确、签名数据是否 正确、账户发行方是否正确等，若二维码无效则返回给乘客提示该二维码乘车 码无效，若二维码有效，自动检票机设备生成用户行程信息通过网关模块传输 给乘客事务模块，从而利用乘客事务模块对行程信息进行校验。

通过本实施例，轨道交通验证设备104可以对目标二维码中的健康数据和 支付二维码结构数据的正确性进行检测，从而可以提高二维码验证的安全性。

在一个实施例中，基于轨道交通乘客数据库验证待验证用户的行程信息， 包括：向轨道交通乘客数据库发送指令信息包含行程信息的查询指令，以使轨 道交通数据库在检测到行程信息为待验证用户的唯一行程、行程信息对应的进 出站逻辑顺序正确、行程信息的授权有效以及行程时间在预设时间范围内时， 向轨道交通验证设备返回行程信息验证通过信息；若接收到轨道交通乘客数据 库发送的行程信息验证通过信息，确定行程信息通过验证。

本实施例中，轨道交通票务系统106可以设置在轨道交通验证设备104中， 也可以设置在服务器中，并通过物理网线与轨道交通验证设备104相连接。轨 道交通验证设备104可以对用户的行程信息进行验证。例如通过调用轨道交通 票务系统106实现行程信息的验证。轨道交通验证设备104可以向轨道交通乘 客数据库发送查询指令，该查询指令包含上述得到的行程信息，并通过轨道交 通数据库检测行程信息是否为待验证用户的唯一行程、行程信息对应的进出站 逻辑顺序是否正确、行程信息的授权是否有效以及行程时间是否在预设时间范 围内，若检测到行程信息为待验证用户的唯一行程、行程信息对应的进出站逻 辑顺序正确、行程信息的授权有效以及行程时间在预设时间范围内时，可以向 轨道交通验证设备104返回行程信息验证通过信息，当上述条件存在一项未满 足时，可以向轨道交通验证设备104发送验证失败信息。而轨道交通验证设备 104在接收到该验证通过信息时，可以确定行程信息验证通过；接收到验证失败 信息时，可以确定行程信息验证不通过。例如，轨道交通验证设备104可以调 用轨道交通票务系统106中乘客事务模块接收用户行程信息，并对其进行鉴别， 并将鉴别结果通过网关模块利用物理传输网络反馈给自动检票机。鉴别内容包 括：行程唯一性判断、行程进出站逻辑顺序判断、授权有效性判断、行程时间 判断、防重判断、防抖判断。自动检票机接收到行程鉴别结果，根据鉴别结果 给予乘客放行确认，放行确认包括打开闸门并提示乘客请通行、拒绝放行并提 示拒绝原因。并且，轨道交通票务系统106中乘客事务模块完成用户行程鉴别 后，还可以利用网关模块通过互联网或物理专线完成与用户APP后台的数据通 信，实现对用户乘车记录实时推送。APP后台利用无线网络与用户APP完成通 信，实现用户乘车记录在手机APP上及时展现。

通过本实施例，轨道交通验证设备106可以利用轨道交通票务系统106对 用户的行程信息进行检测，从而在确定行程信息正确时为用户放行，提高了乘 车时二维码验证的效率。

在一个实施例中，还包括：若检测到待验证用户通过闸门以及行程信息为 待验证用户的出站行程信息，获取出站行程信息对应的入站行程信息；根据出 站行程信息以及入站行程信息，获取待验证用户对应的计费信息；向支付二维 码结构数据对应的支付机构发送请求信息包含计费信息以及待验证用户对应的 支付账户信息的请款请求，以使支付机构根据计费信息扣除支付账户信息中对 应的费用。

本实施例中，轨道交通验证设备104还可以在用户通过闸门后进行费用计 算。当轨道交通验证设备104检测到上述用户通过闸门时，检测行程信息是出 站还是进站。若为用户的出站行程信息，则轨道交通验证设备104可以获取该 出站信息对应的入站行程信息，并根据出站行程信息和入站行程信息，获取待 验证用户对应的计费信息。从而轨道交通验证设备105可以向上述用户对应的 支付二维码结构数据对应的支付机构发送请款请求，其中请款请求中包含计费 信息以及上述用户对应的支付账户信息，支付机构可以在接收到请款请求后， 基于计费信息扣除上述支付账户信息中对应的费用，实现用户乘车费用的缴纳。 例如，轨道交通验证设备104可以调用轨道交通票务系统106中乘客事务模块， 在接收到用户出站行程记录时，与其进站行程进行匹配，并将用户出站行程发 送至交易匹配模块，交易匹配模块接收后并找到符合条件进站行程匹配，匹配 后计算行程费用并发起请款，请款成功后将结果通过网关模块推送给APP后台， APP后台利用无线网络将用户行程计费信息推送至用户APP，由用户APP负责 展现此行程计费信息。

通过本实施例，轨道交通验证设备104可以利用轨道交通票务系统106实 现对用户行程的计费和推送，提高了用户乘车验证的效率。

在一个实施例中，上述移动终端102、轨道交通验证设备104和轨道交通票 务系统106还可以进行消息通知，如图7所示，图7为一个实施例中通知步骤 的流程示意图。上述各设备和系统可以通过通知模块进行通知，通知模块分成 邮件通知方式和短信通知方式，当请求过来时首先检测参数是否合法，若不合 法则返回请求参数有问题。若请求参数合法，则将参数转化为通知信息对象并 调用通知信息API发送，若发送成功则返回发送成功结果，若发送不成功则返 回发送超时。

通过本实施例，移动终端102、轨道交通验证设备104和轨道交通票务系统 106可以通过通知模块进行消息通知，从而提高了消息获取的及时性。

在一个实施例中，轨道交通验证设备104还可以对流量进行控制，如图8 所示，图8为一个实施例中流量控制步骤的流程示意图。轨道交通验证设备104 可以调用流量控制模块进行流量控制。其中，轨道交通验证设备104可以是自 动米检票机，流量控制模块是用于对乘客过闸请求流量的管控，可以起到很好 地保护轨道交通票务系统的效果。任意时间的请求往往是随机不可控的，而系 统的处理能力是有限的。流量控制模块可以有效的防止由于网络中瞬间的大量 乘客过闸请求数据对网络带来的冲击，可以很好地保证轨道交通票务系统高效 稳定的运行。

具体地，流量控制模块有流控规则的管理，先在流控控制模块设定流控规 则，设定规则内容包括但不限于被保护的资源名、阈值类型、单机阈值、是否 集群、流控模式、流控效果、超时时间等。流控模式有QPS和线程数两种模式， 流控效果有冷启动和排队等待两种方式。所有的自动检票机的乘客过闸请求流 量都会达到流量控制模块，流量控制模块首先检测是否符合流控规则，若不符 合则跳过流量控制模块，若符合则判断是否超过设定的阈值，若不超过则跳过 流量控制模块，若已超过则按照流控规则预先设定的效果启动流控效果，流控 效果有冷启动和排队等待两种方式。若预先设定的流控效果是冷启动方式，冷启动方式主要用于系统长期处于低水位的情况下，当流量突然增加时，直接把 系统拉升到高水位可能瞬间把系统压垮。通过"冷启动"，让通过的流量缓慢增加， 在一定时间内逐渐增加到阈值上限，给轨道交通票务系统一个预热的时间，避 免轨道交通票务系统被压垮的情况。若预先设定的流控效果是排队等待的方式， 若每秒超过预先设好的请求数，超过的话就排队等待，等待的超时间为预先设 定的时间，目的是为了轨道交通票务系统匀速处理请求，保证服务的均匀性， 而不是一会处理大量的请求，一会没有请求可处理。

通过本实施例，轨道交通验证设备104可以调用轨道交通票务系统106中 的流量控制模块实现对过闸人员的控制和预警，提高了轨道交通流量控制的效 率。

在一个实施例中，轨道交通验证设备104中还可以对日志进行存储和分析。 如图9所示，图9为一个实施例中日志存储步骤的流程示意图。本实施例中， 轨道交通验证设备104可以是自动检票机，所有自动检票机和应用服务都装有 filebeat工具，filebeat工具可以定时读取服务器硬盘上的文件日志并发送到缓存 器Redis(缓冲高峰期的流量)中，日志接收器Logstash定时从Redis获取日志， 过滤出需要的字段并存储ElasticSearch中。轨道交通验证设备104中还可以设 置有在ElasticSearch Java API基础上再开发的日志分析处理模块，用于对日志 进行分析处理，日志分析器可以通过定时器定时分析收集来的原始日志。把分 析的结果存储到elastic search中。对外提供查询日志的方法，从而可以在界面中 查询自动检票机或应用服务的日志。

通过本实施例，轨道交通验证设备104可以对日志进行存储和分析，从而 提高了用户乘车相关数据的可溯性。

在一个实施例中，如图10所示，图10为一个实施例中监控步骤的流程示 意图。轨道交通验证设备104可以调用轨道交通票务系统106的监控模块加农 自身心跳是否正常。其中，轨道交通验证设备104可以是自动检票机。监控模 块使用心跳技术，除了用来监控集群的各个应用服务节点信息、状态,还监控各 个自动检票机设备版本信息、状态。若触发告警模块的告警规则的告警生成条 件，会生成一条告警信息传输给告警模块。通过获取集群的各个应用范围和自 动检票机的各种指标数据可以帮助用户全面掌握应用、终端设备的运行情况， 同时也能够让用户快速定位线上故障的根源。

具体地，自动检票机通过监控模块采用心跳技术检测自动检票机心跳是否 不正常，若心跳不正常发送告警信息给告警模块后并判断次数是否已连续达到3 次，若已达到则更新自动检票机的状态到数据库中并发送告警信息给告警模块， 若心跳正常则更新自动检票机版本相关信息到数据库。自动检票机通过监控模 块定时获取应用服务相关信息，这个服务相关信息包括但不限于CPU、内存、 线程数，首先判断服务心跳是否正常，若不正常则发送告警信息给告警模块， 若服务心跳正常判断是否符合告警规则，若不符合告警规则就结束，若符合告 警规则后发送告警信息给告警模块，告警模块接收到后调用通知模块的通知方 法发送短信通知或者邮件通知给系统运维人员。告警规则包括是否超过内存、CPU设定的值等。应用服务信息管理界面可实时查看集群的各个应用服务的内 存、CPU、线程数等；自动检票机版本管理界面可实时查看集群的各个自动检 票机的版本信息、状态等。

通过本实施例，轨道交通验证设备104可以对其自身的运行情况进行监控， 从而提高了轨道交通验证设备104的运行安全。

在一个实施例中，提供一种轨道交通乘车验证系统，包括：移动终端和轨 道交通验证设备；其中，

移动终端，用于响应于二维码展示指令，获取待验证用户对应的用户标识， 并根据用户标识查询健康码大数据中心，获取用户标识对应的健康数据；根据 用户标识获取对应的支付账户信息，并根据支付账户信息生成支付二维码结构 数据；根据支付二维码结构数据以及健康数据，生成对应的目标二维码并展示；

轨道交通验证设备，用于获取移动终端展示的目标二维码，提取目标二维 码中的健康数据以及支付二维码结构数据；根据健康数据验证待验证用户的健 康信息、验证支付二维码结构数据中的数据是否正确；若检测到待验证用户的 健康信息为正常健康码对应的健康信息以及支付二维码结构数据正确，生成待 验证用户对应的行程信息并基于轨道交通乘客数据库验证待验证用户的行程信 息；若确定行程信息正确，向轨道交通验证设备对应的检票设备发送放行指令， 以使检票设备打开闸门允许待验证用户通过。

关于轨道交通乘车验证系统的具体限定可以参见上文中对于轨道交通乘车 验证方法的限定，在此不再赘述。上述轨道交通乘车验证系统中的各个模块可 全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于 或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的 存储器中，以便于处理器调用执行以上各个模块对应的操作。

应该理解的是，虽然图2-图10的流程图中的各个步骤按照箭头的指示依次 显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有 明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的 顺序执行。而且，图2-图10中的至少一部分步骤可以包括多个步骤或者多个阶 段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时 刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它 步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图11所示，提供了一种轨道交通乘车验证装置，包括： 获取模块500、生成模块502和展示模块504，其中：

获取模块500，用于响应于二维码展示指令，获取待验证用户对应的用户标 识，并根据用户标识查询健康码大数据中心，获取用户标识对应的健康数据。

生成模块502，用于根据用户标识获取对应的支付账户信息，并根据支付账 户信息生成支付二维码结构数据。

展示模块504，用于根据支付二维码结构数据以及健康数据，生成对应的目 标二维码并展示，以供轨道交通验证设备根据目标二维码对待验证用户的健康 信息和行程信息进行验证。

在一个实施例中，上述生成模块502，具体用于根据用户标识查询轨道交通 乘客数据库，确定待验证用户是否存在未支付订单和/或待验证用户是否为黑名 单用户；若待验证用户不存在未支付订单并且待验证用户不为黑名单用户，获 取用户标识对应的支付机构信息，并根据支付机构信息获取对应的支付账户信 息。

在一个实施例中，上述生成模块502，具体用于根据支付机构信息查询移动 终端的缓存，确定缓存中存在支付机构信息对应的支付账户信息；若是，从缓 存中获取支付账户信息；若否，根据支付机构信息查询轨道交通乘客数据库， 以获取支付账户信息并基于支付账户信息更新缓存。

在一个实施例中，上述装置还包括：异常通知模块，用于根据健康数据查 询健康码大数据中心；若确定健康数据为异常健康码对应的数据，获取异常健 康码对应的健康告警信息以通知待验证用户。

在一个实施例中，如图12所示，提供了一种轨道交通乘车验证装置，包括： 二维码获取模块600、验证模块602、生成模块604和发送模块606，其中：

二维码获取模块600，用于获取移动终端展示的目标二维码，提取目标二维 码中的健康数据以及支付二维码结构数据。

验证模块602，用于根据健康数据验证待验证用户的健康信息并验证支付二 维码结构数据中的数据是否正确。

生成模块604，用于若检测到待验证用户的健康信息为正常健康码对应的健 康信息以及支付二维码结构数据正确，生成待验证用户对应的行程信息并基于 轨道交通乘客数据库验证待验证用户的行程信息。

发送模块606，用于若确定行程信息正确，向轨道交通验证设备对应的检票 设备发送放行指令，以使检票设备打开闸门允许待验证用户通过。

在一个实施例中，上述验证模块602，具体用于获取支付二维码机构数据中 的生成时间、密钥、签名数据以及支付机构信息；若检测到生成时间未过期、 密钥正确、签名数据有效以及支付机构信息正确，确定支付二维码结构数据中 的数据正确。

在一个实施例中，上述生成模块604，具体用于向轨道交通乘客数据库发送 指令信息包含行程信息的查询指令，以使轨道交通数据库在检测到行程信息为 待验证用户的唯一行程、行程信息对应的进出站逻辑顺序正确、行程信息的授 权有效以及行程时间在预设时间范围内时，向轨道交通验证设备返回行程信息 验证通过信息；若接收到轨道交通乘客数据库发送的行程信息验证通过信息， 确定行程信息通过验证。

在一个实施例中，上述装置还包括：计费模块，用于若检测到待验证用户 通过闸门以及行程信息为待验证用户的出站行程信息，获取出站行程信息对应 的入站行程信息；根据出站行程信息以及入站行程信息，获取待验证用户对应 的计费信息；向支付二维码结构数据对应的支付机构发送请求信息包含计费信 息以及待验证用户对应的支付账户信息的请款请求，以使支付机构根据计费信 息扣除支付账户信息中对应的费用。

关于轨道交通乘车验证装置的具体限定可以参见上文中对于轨道交通乘车 验证方法的限定，在此不再赘述。上述轨道交通乘车验证装置中的各个模块可 全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于 或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的 存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是终端，其 内部结构图可以如图13所示。该计算机设备包括通过系统总线连接的处理器、 存储器、通信接口、显示屏和输入装置。其中，该计算机设备的处理器用于提 供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。 该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存 储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的通信接口 用于与外部的终端进行有线或无线方式的通信，无线方式可通过WIFI、运营商 网络、NFC(近场通信)或其他技术实现。该计算机程序被处理器执行时以实现一种轨道交通乘车验证方法。该计算机设备的显示屏可以是液晶显示屏或者 电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也 可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、 触控板或鼠标等。

本领域技术人员可以理解，图13中示出的结构，仅仅是与本申请方案相关 的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定， 具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件， 或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器 中存储有计算机程序，该处理器执行计算机程序时实现上述的轨道交通乘车验 证方法。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程 序，计算机程序被处理器执行时实现上述的轨道交通乘车验证方法。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程， 是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于 一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述 各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、 存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的 至少一种。非易失性存储器可包括只读存储器(Read-Only Memory，ROM)、磁 带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory， SRAM)或动态随机存取存储器(Dynamic Random Access Memory，DRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述 实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特 征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细， 但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的 普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改 进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权 利要求为准。

Claims (10)

1.一种轨道交通乘车验证方法，其特征在于，应用于移动终端，所述方法包括：

响应于二维码展示指令，获取待验证用户对应的用户标识，并根据所述用户标识查询健康码大数据中心，获取所述用户标识对应的健康数据；

根据所述用户标识获取对应的支付账户信息，并根据所述支付账户信息生成支付二维码结构数据；

根据所述支付二维码结构数据以及所述健康数据，生成对应的目标二维码并展示，以供轨道交通验证设备根据所述目标二维码对所述待验证用户的健康信息和行程信息进行验证。

2.根据权利要求1所述的方法，其特征在于，所述根据所述用户标识获取对应的支付账户信息，包括：

根据所述用户标识查询轨道交通乘客数据库，确定所述待验证用户是否存在未支付订单和/或所述待验证用户是否为黑名单用户；

若所述待验证用户不存在未支付订单并且所述待验证用户不为黑名单用户，获取所述用户标识对应的支付机构信息，并根据所述支付机构信息获取对应的支付账户信息。

3.根据权利要求2所述的方法，其特征在于，所述根据所述支付机构信息获取对应的支付账户信息，包括：

根据所述支付机构信息查询所述移动终端的缓存，确定所述缓存中存在所述支付机构信息对应的支付账户信息；

若是，从所述缓存中获取所述支付账户信息；

若否，根据所述支付机构信息查询所述轨道交通乘客数据库，以获取所述支付账户信息并基于所述支付账户信息更新所述缓存。

4.根据权利要求1所述的方法，其特征在于，所述获取所述用户标识对应的健康数据之后，还包括：

根据所述健康数据查询所述健康码大数据中心；

若确定所述健康数据为异常健康码对应的数据，获取所述异常健康码对应的健康告警信息以通知所述待验证用户。

5.一种轨道交通乘车验证方法，其特征在于，应用于轨道交通验证设备，所述方法包括：

获取移动终端展示的目标二维码，提取所述目标二维码中的健康数据以及支付二维码结构数据；

根据所述健康数据验证待验证用户的健康信息并验证所述支付二维码结构数据中的数据是否正确；

若检测到所述待验证用户的健康信息为正常健康码对应的健康信息以及所述支付二维码结构数据正确，生成所述待验证用户对应的行程信息并基于轨道交通乘客数据库验证所述待验证用户的行程信息；

若确定所述行程信息正确，向轨道交通验证设备对应的检票设备发送放行指令，以使所述检票设备打开闸门允许所述待验证用户通过。

6.根据权利要求5所述的方法，其特征在于，所述验证所述支付二维码结构数据中的数据是否正确，包括：

获取所述支付二维码机构数据中的生成时间、密钥、签名数据以及支付机构信息；

若检测到所述生成时间未过期、所述密钥正确、所述签名数据有效以及所述支付机构信息正确，确定所述支付二维码结构数据中的数据正确；

和/或，

所述基于轨道交通乘客数据库验证所述待验证用户的行程信息，包括：

向轨道交通乘客数据库发送指令信息包含所述行程信息的查询指令，以使所述轨道交通数据库在检测到所述行程信息为所述待验证用户的唯一行程、所述行程信息对应的进出站逻辑顺序正确、所述行程信息的授权有效以及所述行程时间在预设时间范围内时，向所述轨道交通验证设备返回行程信息验证通过信息；

若接收到所述轨道交通乘客数据库发送的行程信息验证通过信息，确定所述行程信息通过验证。

7.根据权利要求5所述的方法，其特征在于，所述方法还包括：

若检测到所述待验证用户通过闸门以及所述行程信息为所述待验证用户的出站行程信息，获取所述出站行程信息对应的入站行程信息；

根据所述出站行程信息以及所述入站行程信息，获取所述待验证用户对应的计费信息；

向所述支付二维码结构数据对应的支付机构发送请求信息包含所述计费信息以及所述待验证用户对应的支付账户信息的请款请求，以使所述支付机构根据所述计费信息扣除所述支付账户信息中对应的费用。

8.一种轨道交通乘车验证系统，其特征在于，包括：移动终端和轨道交通验证设备；其中，

所述移动终端，用于响应于二维码展示指令，获取待验证用户对应的用户标识，并根据所述用户标识查询健康码大数据中心，获取所述用户标识对应的健康数据；根据所述用户标识获取对应的支付账户信息，并根据所述支付账户信息生成支付二维码结构数据；根据所述支付二维码结构数据以及所述健康数据，生成对应的目标二维码并展示；

所述轨道交通验证设备，用于获取移动终端展示的目标二维码，提取所述目标二维码中的健康数据以及支付二维码结构数据；根据所述健康数据验证所述待验证用户的健康信息、验证所述支付二维码结构数据中的数据是否正确；若检测到所述待验证用户的健康信息为正常健康码对应的健康信息以及所述支付二维码结构数据正确，生成所述待验证用户对应的行程信息并基于轨道交通乘客数据库验证所述待验证用户的行程信息；若确定所述行程信息正确，向轨道交通验证设备对应的检票设备发送放行指令，以使所述检票设备打开闸门允许所述待验证用户通过。

9.一种轨道交通乘车验证装置，其特征在于，应用于移动终端，所述装置包括：

获取模块，用于响应于二维码展示指令，获取待验证用户对应的用户标识，并根据所述用户标识查询健康码大数据中心，获取所述用户标识对应的健康数据；

生成模块，用于根据所述用户标识获取对应的支付账户信息，并根据所述支付账户信息生成支付二维码结构数据；

展示模块，用于根据所述支付二维码结构数据以及所述健康数据，生成对应的目标二维码并展示，以供轨道交通验证设备根据所述目标二维码对所述待验证用户的健康信息和行程信息进行验证。

10.一种轨道交通乘车验证装置，其特征在于，应用于轨道交通验证设备所述装置包括：

二维码获取模块，用于获取移动终端展示的目标二维码，提取所述目标二维码中的健康数据以及支付二维码结构数据；

验证模块，用于根据所述健康数据验证待验证用户的健康信息并验证所述支付二维码结构数据中的数据是否正确；

生成模块，用于若检测到所述待验证用户的健康信息为正常健康码对应的健康信息以及所述支付二维码结构数据正确，生成所述待验证用户对应的行程信息并基于轨道交通乘客数据库验证所述待验证用户的行程信息；

发送模块，用于若确定所述行程信息正确，向轨道交通验证设备对应的检票设备发送放行指令，以使所述检票设备打开闸门允许所述待验证用户通过。

Images