一种单次交换即可完成的虚拟公共交通一卡通充值方法

本发明涉及的是交通技术领域,特别涉及一种单次交换即可完成的虚拟公共交通一卡通充值方法。

虚拟交通一卡通，是指主要在交通运输领域用于支付或清算的虚拟介质。虚拟交通一卡通一般存储在移动通信设备、可穿戴设备等的安全芯片内，应用于城市公共汽电车、城市轨道交通、出租汽车、市域(郊)铁路旅客运输、道路旅客运输、水路旅客运输等交通运输服务领域。

虚拟交通一卡通具有存储文件、交易数据和密钥数据的能力，可以进行计算和加解密，具备在线充值、在线圈提、离线普通消费、离线分段消费、离线分时消费、交易查询、应用维护等业务功能。

对于现有的以实体卡片为载体传统交通一卡通卡片，在线充值的流程至少需要进行三次后台交换，包括交易申请、业务处理和结果提交，增加了业务处理的时间，降低了系统效率，尤其在地铁站、郊区车站等信号较弱的地区，充值业务的失败几率会大大增加，影响用户的体验也因此产生了较多客户投诉，失败的交易往往需要几天过后才能进行退款，同时也增加了公共交通服务的压力。明显，传统的充值方法已经不适用于现有的互联网时代，更加体现不出加载于移动设备的虚拟卡能够实时通信的优势。

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的一种单次交换即可完成的虚拟公共交通一卡通充值方法。

一种单次交换即可完成的虚拟公共交通一卡通充值方法，包括：

S100.厂商钱包向厂商服务器发送支付请求，厂商服务器向厂商钱包回复支付成功结果；

S200.厂商钱包向厂商服务器请求获取支付成功数据脚本，厂商服务器生成获取支付成功数据脚本，并向厂商钱包返回支付成功数据脚本；

S300.厂商钱包接收到支付成功数据脚本后，对支付成功数据脚本进行编译，生成支付成功数据，并将支付成功数据发送给MOT小程序；

S400.厂商钱包还将支付成功数据发送给厂商服务器，厂商服务器通过支付成功数据得到申请卡数据，并将申请卡数据发送给MOT服务器；

S500.MOT服务器接收申请卡数据，验证订单状态，验证申请卡数据中的支付安全数据并生成充值数据；

S600.MOT服务器对生成的充值数据进行加密，并向厂商服务器返回加密充值数据；

S700.厂商服务器根据加密充值数据生成充值脚本，并向厂商钱包返回充值脚本；

S800.厂商钱包将充值脚本发送给MOT程序，MOT小程序运行充值脚本，完成充值。

进一步地，S100中，厂商服务器向厂商钱包回复支付成功结果后，还用于向MOT服务器返回支付凭证。

进一步地，S200中，当厂商侨胞请求获取安全数据脚本准备充值时，应先通过订单状态查询的接口查询订单支付结果，如已支付，才返回相关指令，当接口返回超时，应重试查询，当处于未支付或者有明确的错误码返回时，应拒绝返回相关指令。

进一步地，S400中，当申请卡数据出现异常时，允许使用原订单重试或者退款。

进一步地，S400中，当厂商服务器没有收到安全数据脚本的执行结果时，厂商钱包应在网络正常的情况下主动重试将执行结果和安全数据上送给厂商服务器，MOT服务在预设时间后会主动获取安全数据，MOT服务器判断安全数据是成功的，会主动将订单置为成功，如果是失败的，将自动退款给用户。

进一步地，当厂商服务器收到执行失败的结果时，厂商服务必须将安全数据以调整失败的事件类型通知给MOT服务器，MOT服务器验证安全数据确实失败后允许使用原订单重试或者退款。

进一步地，MOT小程序包括远程充值计数器和远程消费计数器，远程充值计数器用于REMOTE LOAD命令，通过REMOTE LOAD命令完成的充值交易，远程充值计数器与原联机交易序号都同时加1，并记录交易日志；通过原CREDIT FOR LOAD指令完成的充值交易，远程充值计数器不变，原联机交易序号加1，并记录交易日志。

进一步地，远程消费计数器用于REMOTE PURCHASE命令，当通过REMOTE PURCHASE命令完成的消费交易，远程消费计数器与原脱机交易序号都同时加1，并记录交易日志；通过原DEBIT FOR PURCHASE指令完成的消费交易，远程消费计数器不变，原脱机交易序号加1，并记录交易日志。

进一步地，MOT小程序还包括远程TAC/MAC存储区，远程TAC/MAC存储区用于保存REMOTE PURCHASE命令(远程消费)或REMOTE LOAD命令产生的最后一条交易结果的TAC和MAC2，当通过远程命令完成的交易，远程TAC/MAC2存储区与MOT原TAC/MAC2存储区同时被更新，并记录交易日志；通过原交易指令完成的交易，不更新远程存储区。

进一步地，GET INFORMATION命令用于获取applet实例的生命周期状态、当前状态和基本信息；REMOTE LOAD命令用于执行远程充值操作。执行此命令之前，应成功执行GETINFORMATION命令。

本发明实施例提供的上述技术方案的有益效果至少包括：

本发明将MOT小程序、厂商钱包、厂商服务器和MOT服务器进行结合，通过厂商服务器生成安全数据脚本，厂商钱包对安全数据脚本进行编译，生成支付成功数据，厂商钱包还将支付成功数据发送给厂商服务器，厂商服务器通过支付成功数据得到申请卡数据，并将申请卡数据发送给MOT服务器；MOT服务器接收申请卡数据，验证订单状态，验证申请卡数据中的支付安全数据并生成充值数据；MOT服务器对生成的充值数据进行加密，并向厂商服务器返回加密充值数据；本发明解决了现有技术充值流程过多，处理时间长，效率过低的问题，增加了用户的使用体验。

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：

图1为本发明实施例1中，一种单次交换即可完成的虚拟公共交通一卡通充值方法的第一流程图；

图2为本发明实施例1中，一种单次交换即可完成的虚拟公共交通一卡通充值方法的第二流程图。

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

为了解决现有技术中存在的语音合成需要声码器解码和对数据库数据量需求大的问题，本发明实施例提供一种基于神经网络的语音合成方法和系统。

实施例1

本实施例公开了一种单次交换即可完成的虚拟公共交通一卡通充值方法，包括：

S100.厂商钱包向厂商服务器发送支付请求，厂商服务器向厂商钱包回复支付成功结果。

在本实施例中，S100中，厂商服务器向厂商钱包回复支付成功结果后，还用于向MOT服务器返回支付凭证。

S200.厂商钱包向厂商服务器请求获取支付成功数据脚本，厂商服务器生成获取支付成功数据脚本，并向厂商钱包返回支付成功数据脚本。

在本实施例中，S200中，当厂商侨胞请求获取安全数据脚本准备充值时，应先通过订单状态查询的接口查询订单支付结果，如已支付，才返回相关指令，当接口返回超时，应重试查询，当处于未支付或者有明确的错误码返回时，应拒绝返回相关指令。

S300.厂商钱包接收到支付成功数据脚本后，对支付成功数据脚本进行编译，生成支付成功数据，并将支付成功数据发送给MOT小程序。

具体的，MOT小程序新增两个独立的远程充值计数器与独立的远程消费计数器，保留MOT规范原有的联机交易序号与脱机交易序号；新增一个独立的远程TAC&MAC2存储区，用于保存远程充值或远程消费所产生的最后一笔交易的TAC与MAC2，保留MOT规范原有的TAC&MAC2存储区。

远程充值计数器用于REMOTE LOAD命令(远程充值)，通过REMOTE LOAD命令完成的充值交易，远程充值计数器与原联机交易序号都同时加1，并记录交易日志。通过原CREDITFOR LOAD指令完成的充值交易，远程充值计数器不变，原联机交易序号加1，并记录交易日志。

远程消费计数器用于REMOTE PURCHASE命令(远程消费)，当通过REMOTE PURCHASE命令完成的消费交易，远程消费计数器与原脱机交易序号都同时加1，并记录交易日志。通过原DEBIT FOR PURCHASE指令完成的消费交易，远程消费计数器不变，原脱机交易序号加1，并记录交易日志。

远程TAC/MAC存储区用于保存REMOTE PURCHASE命令(远程消费)或REMOTE LOAD命令(远程充值)产生的最后一条交易结果的TAC和MAC2，当通过远程命令完成的交易，远程TAC/MAC2存储区与MOT原TAC/MAC2存储区同时被更新，并记录交易日志。通过原交易指令完成的交易，不更新远程存储区。

在本实施例中，远程管理命令包括GET INFORMATION命令和REMOTE LOAD命令；其中，GET INFORMATION命令用于获取applet实例的生命周期状态、当前状态和基本信息。该专有命令为发卡机构提供了获取卡上信息的方法。

GET INFORMATION返回的数据元素因卡的生命周期状态而不同。

如果MOT小城市实例处于PRE-PERSONALIZED(个性化)状态，使用OTPK生成MAC(线路保护)。一旦转换为PERSONALIZED状态，则使用远程管理密钥(DRMK)的会话密钥生成MAC。

REMOTE LOAD命令用于执行远程充值操作。执行此命令之前，应成功执行GETINFORMATION命令。成功执行GET INFORMATION命令后，只要不是执行REMOTE LOAD/REMOTEPURCHASE/CONTACTLESS CONTROL或者原交通部的充值、消费指令，可以继续执行本指令，否则执行失败。此命令必须使用远程管理密钥(DRMK)的会话密钥进行保护。

S400.厂商钱包还将支付成功数据发送给厂商服务器，厂商服务器通过支付成功数据得到申请卡数据，并将申请卡数据发送给MOT服务器。

在本实施例中，S400中，当申请卡数据出现异常时，允许使用原订单重试或者退款。

在本实施例中，S400中，当厂商服务器没有收到安全数据脚本的执行结果时，厂商钱包应在网络正常的情况下主动重试将执行结果和安全数据上送给厂商服务器，MOT服务在预设时间后会主动获取安全数据，MOT服务器判断安全数据是成功的，会主动将订单置为成功，如果是失败的，将自动退款给用户。

在本实施例中，当厂商服务器收到执行失败的结果时，厂商服务必须将安全数据以调整失败的事件类型通知给MOT服务器，MOT服务器验证安全数据确实失败后允许使用原订单重试或者退款。

S500.MOT服务器接收申请卡数据，验证订单状态，验证申请卡数据中的支付安全数据并生成充值数据；

S600.MOT服务器对生成的充值数据进行加密，并向厂商服务器返回加密充值数据；

S700.厂商服务器根据加密充值数据生成充值脚本，并向厂商钱包返回充值脚本；

S800.厂商钱包将充值脚本发送给MOT程序，MOT小程序运行充值脚本，完成充值。

本发明公开的种单次交换即可完成的虚拟公共交通一卡通充值方法，将MOT小程序、厂商钱包、厂商服务器和MOT服务器进行结合，通过厂商服务器生成安全数据脚本，厂商钱包对安全数据脚本进行编译，生成支付成功数据，厂商钱包还将支付成功数据发送给厂商服务器，厂商服务器通过支付成功数据得到申请卡数据，并将申请卡数据发送给MOT服务器；MOT服务器接收申请卡数据，验证订单状态，验证申请卡数据中的支付安全数据并生成充值数据；MOT服务器对生成的充值数据进行加密，并向厂商服务器返回加密充值数据；本发明解决了现有技术充值流程过多，处理时间长，效率过低的问题，增加了用户的使用体验。

应该明白，公开的过程中的步骤的特定顺序或层次是示例性方法的实例。基于设计偏好，应该理解，过程中的步骤的特定顺序或层次可以在不脱离本公开的保护范围的情况下得到重新安排。所附的方法权利要求以示例性的顺序给出了各种步骤的要素，并且不是要限于所述的特定顺序或层次。

在上述的详细描述中，各种特征一起组合在单个的实施方案中，以简化本公开。不应该将这种公开方法解释为反映了这样的意图，即，所要求保护的主题的实施方案需要清楚地在每个权利要求中所陈述的特征更多的特征。相反，如所附的权利要求书所反映的那样，本发明处于比所公开的单个实施方案的全部特征少的状态。因此，所附的权利要求书特此清楚地被并入详细描述中，其中每项权利要求独自作为本发明单独的优选实施方案。

本领域技术人员还应当理解，结合本文的实施例描述的各种说明性的逻辑框、模块、电路和算法步骤均可以实现成电子硬件、计算机软件或其组合。为了清楚地说明硬件和软件之间的可交换性，上面对各种说明性的部件、框、模块、电路和步骤均围绕其功能进行了一般地描述。至于这种功能是实现成硬件还是实现成软件，取决于特定的应用和对整个系统所施加的设计约束条件。熟练的技术人员可以针对每个特定应用，以变通的方式实现所描述的功能，但是，这种实现决策不应解释为背离本公开的保护范围。

结合本文的实施例所描述的方法或者算法的步骤可直接体现为硬件、由处理器执行的软件模块或其组合。软件模块可以位于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、移动磁盘、CD-ROM或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质连接至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。该ASIC可以位于用户终端中。当然，处理器和存储介质也可以作为分立组件存在于用户终端中。

对于软件实现，本申请中描述的技术可用执行本申请所述功能的模块(例如，过程、函数等)来实现。这些软件代码可以存储在存储器单元并由处理器执行。存储器单元可以实现在处理器内，也可以实现在处理器外，在后一种情况下，它经由各种手段以通信方式耦合到处理器，这些都是本领域中所公知的。

上文的描述包括一个或多个实施例的举例。当然，为了描述上述实施例而描述部件或方法的所有可能的结合是不可能的，但是本领域普通技术人员应该认识到，各个实施例可以做进一步的组合和排列。因此，本文中描述的实施例旨在涵盖落入所附权利要求书的保护范围内的所有这样的改变、修改和变型。此外，就说明书或权利要求书中使用的术语“包含”，该词的涵盖方式类似于术语“包括”，就如同“包括，”在权利要求中用作衔接词所解释的那样。此外，使用在权利要求书的说明书中的任何一个术语“或者”是要表示“非排它性的或者”。