一种电子票处理方法、 系统及装置 【技术领域】
本发明涉及数据业务技术领域， 尤其涉及一种电子票处理方法、 系统及装置。背景技术 电子票指将电子化的实体票券信息存入电子票载体， 用户持电子票载体在检票设 备通过 RFID(Radio Frequency Identification， 射频识别 ) 或二维码等技术进行检票， 方 便用户订票、 取票、 检票。其中， RFID 是一种非接触式的自动识别技术， 通过射频信号自动 识别电子票并获取相关数据 ； 二维码是用某种特定的几何图形按一定规律在平面 ( 二维方 向上 ) 分布的黑白相间的图形记录电子票信息， 通过图象输入设备或光电扫描设备自动识 读以实现电子票信息自动处理。
现有技术中一种电子票务实现方案为 ： 首先由使用者传送订票信息及取票者移动 电话号码至票务平台 ； 再由票务平台依据订票信息产生电子票， 并根据取票者移动电话号 码传送出电子票， 电子票中具有取票者移动电话号码 ； 接着电子票载体接收电子票， 并由其 安全认证机制核对电子票的取票者移动电话号码与其移动电话号码以确认使用者的合法 性。随后， 再由检票设备验核电子票载体的电子票。
现有技术中另一种电子票务实现方案为 ： 由电子票载体向票务平台进行电子票申 购， 接受该中购的票务平台发行票券信息并写入所述电子票载体 ； 持有所述票券信息的电 子票载体通过所述检票设备时， 检票设备对电子票载体中写入的票券信息进行认证， 从而 决定入场与否。
上述两种方案虽然提出电子票的基本实现方法， 可以为某个电子票提供商的电子 化票券服务产品设计提供依据。 但是， 现有技术方案却没有实现票代理商在同一系统、 同一 载体同时为多家票券提供商提供电子化票券的解决办法。这主要是由于 ：
a. 不同行业、 不同机构的电子票差异性太大， 例如票券分类、 包含的信息， 检票规 则等方面 ；
b. 存放电子票信息的载体， 需要能知晓不同行业、 不同机构门票的不同检票规则。
因此， 如何实现在同一系统， 同一载体中同时为多家票券提供商提供方便、 简洁和 通用的电子化票券服务， 为本发明要解决的问题。
发明内容
本发明实施例提供了一种电子票处理方法、 系统及装置， 实现票代理商在同一系 统、 同一载体同时为多家电子票提供商提供电子化票券。
本发明实施例提供了一种电子票处理方法， 应用于包括票务平台和电子票载体的 系统中， 其特征在于， 所述方法包括以下步骤 ：
所述票务平台设置电子票解析全表， 所述电子票解析全表记录不同电子票提供商 的不同电子票类型的属性信息与属性标识信息的对应关系 ；
所述票务平台接收所述电子票载体发送的购票请求， 所述购票请求中携带电子票类型和电子票提供商 ；
所述票务平台根据所述电子票类型和电子票提供商， 从所述电子票解析全表中选 择对应的电子票属性信息， 并以所述电子票属性信息对应的属性标识信息为索引生成电子 票下发给所述电子票载体。
其中， 所述将电子票下发给所述电子票载体， 之后还包括 ：
所述电子票载体将所述电子票属性信息记录到本地电子票解析表中， 并生成对应 的电子票状态信息， 其中， 每项电子票属性信息中携带待检标记， 用于确定所述电子票属性 信息是否在检票时需要提供给检票设备。
其中， 还包括 ：
所述票务平台和所述电子票载体分别对电子票解析全表和本地电子票解析表配 置相同的版本号， 电子票内容每更新一次， 表的版本号递增 ；
所述票务平台在预设周期或检测到满足触发条件后， 向所述电子票载体发送新版 本电子票解析全表变动的内容 ；
所述电子票载体判断新版本号高于本地电子票解析表的版本号， 则将所述变动的 内容更新到所述本地电子票解析表中。 其中， 还包括 ：
所述票务平台和所述电子票载体分别对电子票解析全表和本地电子票解析表配 置相同的版本号， 电子票内容每更新一次， 表版本号递增 ；
所述电子票载体向所述票务平台发送更新请求或购票请求， 其中携带本地电子票 解析表的版本号 ；
所述票务平台将所述本地电子票解析表的版本号与电子票解析全表的版本号比 较， 如果， 电子票解析全表版本号高， 则向电子票载体下发新版本电子票解析全表变动的内 容， 使所述电子票载体将所述变动的内容更新到所述本地电子票解析表。
本发明实施例提供了一种电子票检验方法， 应用于包括电子票载体、 检票设备和 票务平台的系统中， 所述方法包括以下步骤 ：
所述电子票载体根据所述检票设备提供的检票条件找到匹配的电子票属性信 息；
所述电子票载体根据待检标记确定需要发送给检票设备的电子票属性信息中的 待检测信息， 并将所述待检测信息发送给所述检票设备， 使所述检测设备根据从所述票务 平台获取的检票规则信息对所述票据属性信息中的待检测信息进行检验， 若检票通过， 则 修改票状态信息为已检。
其中， 所述电子票载体根据待检标记确定需要发送给检票设备的电子属性信息中 的待检测信息， 之前还包括 ：
所述电子票载体向所述票务平台发送购票请求 ；
所述电子票载体接收所述票务平台返回的购票响应， 所述响应中携带电子票属性 信息， 每项电子票属性信息中携带待检标记 ；
所述电子票载体根据所述待检标记确定所述电子票属性信息是否在检票时需要 提供给检票设备。
其中， 所述待检测标记通过 Tag 编码规则中增加 1bit 实现， 或通过在电子票属性
信息中增加一个字段实现。
其中， 所述检测设备根据检票规则信息对所述电子票属性信息中的待检测信息进 行检验， 之前还包括 ：
所述检票设备向票务平台发送获取检票规则信息的请求， 所述请求中携带可检的 票提供商和票类型信息 ；
所述票务平台接收该请求后， 根据该请求中的票提供商和票类型信息， 从电子票 解析全表中获取对应的待检信息的 Tag， 以及预先设定的对应的票提供商和票类型的待检 信息的属性参数要求的取值或范围， 并发送给所述检票设备 ； 或
所述票务平台从电子票解析全表中获取待检信息的 Tag， 以及预先设定的某个检 票设备对应的电子票提供商和电子票类型的待检信息的属性参数要求的取值或范围， 并发 送给对应的检票设备。
其中， 所述检测设备根据检票规则对所述票据属性信息中的待检测信息进行检 验， 具体包括 ：
检票规则中包括需要检验信息的 Tag 和其属性参数要求取值或范围， 若电子票载 体送出的待检信息中的属性标识信息、 属性参数符合检票规则， 则检票通过， 所述规则与检 票规则要求的 Tag 相同， 并且属性参数值与要求的属性参数值相同或者出于要求的取值范 围之内 ； 否则， 检票不通过。 本发明实施例提供了一种电子票载体， 包括 ：
购票模块， 用于向所述票务平台发送购票请求， 接收所述票务平台返回的购票响 应， 所述响应中携带电子票属性信息， 所述电子票属性信息中携带待检标记， 用于确定所述 电子票属性信息是否在检票时需要提供给检票设备 ；
检票模块， 与所述购票模块连接， 用于根据所述检票设备提供的检票条件找到匹 配的电子票属性信息， 并根据所述待检标记确定所述电子票属性信息是否在检票时需要提 供给检票设备 ；
本地电子票解析表维护模块， 用于将所述电子票属性信息记录到本地电子票解析 表中， 并生成对应的电子票状态信息。
其中， 所述本地电子票解析表维护模块， 还用于接收所述票务平台发送的新版本 电子票解析全表变动的内容， 判断新版本号高于本地电子票解析表的版本号， 则更新所述 电子票解析表 ； 或向所述票务平台发送更新请求， 其中携带本地电子票解析表的版本号， 所 述票务平台将该版本号与电子票解析全表的版本号比较， 如果电子票解析全表版本号高， 则向电子票载体下发新版本电子票解析全表变动的内容。
其中， 所述待检测标记通过 Tag 编码规则中增加 1bit 实现， 或通过在电子票属性 信息中增加一个字段实现。
本发明实施例提供了一种票务平台， 包括 ：
通信模块， 用于与电子票载体和检票设备通信 ；
发行模块， 与所述通信模块连接， 用于根据所述电子票类型和电子票提供商， 从所 述电子票解析全表中选择对应的电子票属性信息， 并以所述电子票属性信息对应的属性标 识信息为索引生成电子票 ；
下发模块， 分别与所述发行模块和所述通信模块连接， 用于收到电子票载体通过
所述通信模块发送的电子票下发请求时， 通知所述发行模块将电子票通过所述通信模块发 送给所述电子票载体 ；
票信息属性表维护模块， 与所述发行模块连接， 用于设置电子票解析全表， 所述电 子票解析全表记录有不同电子票提供商的不同电子票类型的属性信息与属性标识信息的 对应关系 ；
更新模块， 分别与所述通信模块和票信息属性表维护模块连接， 用于对票务平台 的电子票解析全表的内容进行管理， 包括增加、 删除或修改电子票解析全表中的电子票属 性信息。
本发明实施例提供了一种检票设备， 包括 ：
检票规则获取模块， 用于向票务平台发送获取检票规则信息的请求， 所述请求中 携带可检的票提供商和票类型信息 ； 接收所述票务平台返回的响应， 从所述响应中获取对 应的检票规则信息 ；
待检测信息获取模块， 用于从所述电子票载体获取需要发送给检票设备的电子票 属性信息中的待检测信息 ；
检测模块， 分别与所述检票规则获取模块和待检测信息获取模块连接， 用于根据 从所述票务平台获取的检票规则信息对所述票据属性信息中的待检测信息进行检验， 若检 票通过， 则修改票状态信息为已检。 本发明实施例提供了一种电子票处理系统， 包括 ：
电子票载体， 用于向所述票务平台发送购票请求， 并接收票务平台返回的电子票， 将所述电子票信息记录到本地电子票解析表中， 并生成对应的电子票状态信息 ；
票务平台， 用于设置电子票解析全表， 所述电子票解析全表记录有不同电子票提 供商的不同电子票类型的属性信息与属性标识信息的对应关系 ； 接收所述电子票载体发送 的购票请求， 所述购票请求中携带电子票类型和电子票提供商 ； 根据所述电子票类型和电 子票提供商， 从所述电子票解析全表中选择对应的电子票属性信息， 并以所述电子票属性 信息对应的属性标识信息为索引生成电子票下发给所述电子票载体 ；
检票设备， 用于根据从所述票务平台获取的检票规则信息对所述票据属性信息中 的待检测信息进行检验， 若检票通过， 则修改票状态信息为已检。
与现有技术相比， 本发明实施例具有以下优点 ：
本发明实施例中， 实现了电子票代理商在同一系统、 同一载体同时为多家电子票 提供商提供电子化票券服务。 解决了已往电子票代理商需要为各家电子票提供商分别提供 系统和载体的问题， 有效的实现了资源与服务的整合 ； 同时用户感受也得到大幅提升， 无需 为不同电子票提供商准备不同电子票载体。
附图说明 为了更清楚地说明本发明实施例或现有技术中的技术方案， 下面将对实施例或现 有技术描述中所需要使用的附图作简单地介绍， 显而易见地， 下面描述中的附图仅仅是本 发明的一些实施例， 对于本领域普通技术人员来讲， 在不付出创造性劳动性的前提下， 还可 以根据这些附图获得其他的附图。
图 1 是本发明实施例中电子票系统结构图 ；
图 2 是本发明实施例中票务平台结构图 ； 图 3 是本发明实施例中 TV 格式的示意图 ； 图 4 是本发明实施例中 TLV 格式示意图 ； 图 5 是本发明实施例中 TV 和 TLV 格式组合示意图 ； 图 6 是本发明实施例中故宫博物院参观票示意图 ； 图 7 是本发明实施例中公园年票示意图 ； 图 8 是本发明实施例中一种电子票载体结构图 ； 图 9 是本发明实施例中一种是更新模块主动发起更新流程图 ； 图 10 是本发明实施例中一种电子票载体主动向票务平台发起更新流程图 ； 图 11 是本发明实施例中一种电子票载体购票流程流程图 ； 图 12 是本发明实施例中一种检票设备结构图 ； 图 13 是本发明实施例中区分不同票据需要提供的待检属性信息流程图 ； 图 14 是本发明实施例中检票规则信息是由检票设备主动从票务平台获得流程图；
图 15 是本发明实施例中检票规则信息是由票务平台在到达触发条件时向检测设 备发送流程图。具体实施方式
下面将结合本发明实施例中的附图， 对本发明实施例中的技术方案进行清楚、 完 整地描述， 显然， 所描述的实施例仅是本发明的一部分实施例， 而不是全部的实施例。基于 本发明中的实施例， 本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他 实施例， 都属于本发明实施例保护的范围。
本发明实施例为通过在票务平台设置电子票解析全表， 所述电子票解析全表记录 不同电子票提供商的不同电子票类型的属性信息与属性标识信息的对应关系 ； 票务平台接 收所述电子票载体发送的购票请求， 所述购票请求中携带电子票类型和电子票提供商 ； 所 述票务平台根据所述电子票类型和电子票提供商， 从所述电子票解析全表中选择对应的电 子票属性信息， 并以所述电子票属性信息对应的属性标识信息为索引生成电子票下发给所 述电子票载体。
所述电子票载体将所述电子票属性信息记录到本地电子票解析表中， 并生成对应 的电子票状态信息， 其中， 每项电子票属性信息中携带待检标记， 用于确定所述电子票属性 信息是否在检票时需要提供给检票设备。本发明可实现在同一系统、 同一载体的同一应用 中， 同时为不同行业的不同电子票提供商提供电子票服务。
如图 1 所示， 本发明实施例提供了一种电子票系统， 包括 ： 票务平台 110、 电子票载 体 120、 检票设备 130。
票务平台 110， 用于电子票属性信息管理、 销售， 对不同电子票提供商统一编号， 对 不同电子票类型统一编码。具体用于设置电子票解析全表， 其中包含所有电子票的属性信 息， 并能通过标记区分哪些信息需参与检票， 哪些信息不需参与检票 ( 一般不需参与检票 的信息供用户浏览， 例如节目简介、 价格等 ) ； 所述电子票解析全表记录有不同电子票提供 商的不同电子票类型的属性信息， 并设置属性信息与属性标识信息之间的对应关系 ； 票务平台 110 接收所述电子票载体发送的购票请求， 所述购票请求中携带电子票类型和电子票 提供商， 根据所述电子票类型和电子票提供商， 从所述电子票解析全表中选择对应的电子 票属性信息， 并以所述电子票属性信息对应的属性标识信息为索引生成电子票下发给电子 票载体 120。
电子票载体 120， 是供用户使用的承载电子票的介质， 介质本身可以具备对所存电 子票信息的查看能力， 具体形态可以是手机、 卡片等 ； 电子票载体向所述票务平台发送购票 请求， 并接收票务平台返回的电子票， 电子票的属性信息中携带待检标记， 用于确定所述电 子票属性信息是否在检票时需要提供给检票设备。
电子票载体 120 也保留有本地电子票解析表， 目的是让电子票载体能够将电子票 信息准确展示给用户， 该电子票解析表可为票务平台的电子票解析全表的子表， 并能对表 内容增加或删除。票务平台 110 按统一的格式将单张或多张电子票信息 ( 信息需同时携带 标记 ) 通过无线或有线网络配送至电子票载体 120。电子票载体 120 记录下这些电子票信 息， 并额外生成一些电子票属性信息， 如电子票状态， 在刚写入时， 自动增加电子票状态信 息， 后续发生电子票状态更改时， 电子票载体能自动修改电子票状态值。 该电子票状态信息 例如电子票的使用情况， 对于一次性使用的电子票， 在没有使用前为有效， 当通过检票设备 检票使用后， 为无效 ； 对于多次使用的电子票， 在没使用前使用次数为满值， 每使用一次， 使 用次数减一， 直到使用完毕。 本地电子票解析表可以在申请电子票业务时从票务平台下载， 也可以当用户购买电子票时进行更新。 检票设备 130， 用于根据从票务平台 110 获取的检票规则信息对所述票据属性信 息中的待检测信息进行检验， 若检票通过， 则修改所述票状态信息为已检。检票设备检票 时， 电子票载体 120 能依据检票设备 130 指定检票条件 ( 电子票提供商、 电子票日期等 )， 找 到匹配的电子票， 然后将该电子票的待检信息送给检票设备检查， 电子票载体 120 可依据 标记找到所有待检信息。
在票务平台 110 中， 对电子票提供商编号方式为 ：
电子票提供商编号的长度为 4 字节， 采用二进制编码， 由 8 位数字组成以下 3 部 分：
地区代码 (2 位 )+ 电子票提供商类型 (2 位 )+ 电子票提供商顺序号 (4 位 ) ；
其中 ：
地区代码可以为省代码 (2 位数字 )， 从 01 开始依次为 31 个省编号， 如表 1 所示 ：
表1：
数字值 01 02 03省编号 北京市 上海市 ......10CN 101989341 A说04 05明书...... ...... ...... 海南岛7/17 页...... 31
电子票提供商类型 (2 位数字 )， 如表 2 所示， 电子票提供商类型包括场馆类、 电影 类、 演出类、 体育类、 交通类及旅游类等 ：
表2：
值 10 20 30 40 50 60 ......
类型解释 场馆类 电影类 演出类 体育类 交通类 旅游类 ......说明 世博会、 科技馆、 博物馆等 电影票等 音乐、 话剧、 演唱会等 体育比赛等 飞机票、 火车票等 景点门票 ( 可扩充 )提供商顺序号 (4 位数字 )， 按照提供商电子票类型的顺序增加， 不足 4 位时左方补 “0” 。如表 3 所示 ：
表3：
数字值 0001 0002 0003 0004提供商顺序号 某类电子票中的第一子类 某类电子票中的第二子类 某类电子票中的第三子类 ......11CN 101989341 A说......明书8/17 页......
例如， 01， 10， 0001 代表北京市场馆类中的第一子类电子票， 例如某个博物馆的电子票。 另外， 票务平台 110 中， 对电子票类型编码方式采用 2 字节长的 CN 编码， 共 4 位数 字： 其中，
第一位数字， 标识使用者类型 ： “1” 指个人非实名， “2” 指个人实名， “3” 指团体， 其 它保留 ；
第二位数字， 标识电子票使用次数类型 ： “1” 指单次票， “2” 指三次票， “3” 指七次 票， “9” 指不限次票， 其它保留 ；
第三位数字， 标识电子票的使用日期时间受限类型 ： “1” 指指定日非指定时间使 用； “2” 指非指定日非指定时间使用 ； “3” 指指定日指定时间使用 ； “4” 指非指定日指定时 间使用 ； 其它保留 ；
第四位数字， 标识电子票所属的优惠类型 ： “1” 指普通未优惠 ； “2” 指优惠 ； “3” 指 赠送 ； 其它保留 ；
以上数字表示含义只是举例说明， 实际可以采用其他数字进行标识， 也可以增加 新的内容。
票务平台结构如图 2 所示 ：
通信模块 210， 用于与电子票载体和检票设备通信， 提供与外界的通信能力 ；
发行模块 220， 与通信模块 210 连接， 用于根据电子票类型和电子票提供商， 从电 子票解析全表中选择对应的电子票属性信息， 并以所述电子票属性信息对应的属性标识信 息为索引生成电子票 ；
其中， 电子票解析全表结构可采用 TV 或 TLV 方式， 数据编码格式如表 4 所示 ：
表4：
票务平台可以将不同行业涉及的电子票可能包含的信息， 添加至该电子票解析全 表中。为每项属性信息分配唯一的标记值 (Tag)， 设定该属性信息的数据编码格式， 设定数 据信息长度类型 ( 定长或变长 )， 定长时需设定实际长度值。
当票务平台进行某类电子票销售前， 由发行模块 220 执行该类电子票发行操作。
即： 依据该类电子票特征， 从电子票解析全表中选择该类电子票关联的属性信息项， 将该类 票关联的属性信息索引或 Tag 组成该类电子票发行表保存在发行模块。
如发行故宫博物院参观票，
经发行后， 保存在发行模块中的故宫博物院参观票发行表如表 5 所示，
表5：
属性项 1 2 3 4 5
0x81 0x82 0x83 0x87 0x01另外， 电子票发行表也可以根所需要被发行模块更新， 如增加或删除某个属性项。
下发模块 230， 分别与发行模块 220 和通信模块 210 连接， 用于收到电子票载体通 过通信模块 210 发送的电子票下发请求时， 按照请求携带的电子票类型和电子票提供商， 通知发行模块 220 组成电子票属性信息， 使发行模块 220 依据该种电子票发行表， 按照票信 息属性表规定的格式和长度要求， 组装数据。
对于一个需要生成的电子票， 确定该电子票所具备的各个属性， 进而根据该电子 票发行表确定电子票的各属性信息。例如， 对于一个故宫博物院参观票， 其具备的属性包 括： 电子票提供商、 电子票类型、 电子票序列号、 指定日期、 最大使用次数。对于公园年票， 其具备的属性包括 ： 电子票提供商、 电子票类型、 电子票序列号、 生效起始日期、 生效截止日 期。
其中， 生成电子票属性记录的方法有 ： TV、 TLV、 或者混合模式等。具体地 ：
TV 方式 ： V( 数值 ) 长度固定， 票务平台和电子票载体程序均默认知道长度 ；
在电子票中依次记录每个属性的属性标识信息 Tag 和属性参数 Value， 而每个属 性标识信息所占存储空间为设定值 A， 属性参数所占存储空间为设定值 B。即先记录第一个 属性的属性标识信息， 该属性标识信息所占存储空间大小等于设定值 A， 然后记录第一个属 性的属性参数， 该属性参数所占存储空间大小等于设定值 B ； 之后记录第二个属性的属性 标识信息 ...... 依次类推。如图 3 所示。
TLV 方式 ： TLV 是对 TV 的拓展， 不限定 V 值的长度， 增加一个 V 值长度 Length， 来 表示实际长度值， 如图 4 所示。
TV 和 TLV 格式组合混合， 对于固定长度的 V 值采用 TV 方式， 对变长度的 V 值采用 TLV 方式。如图 5 所示。
为减少数据量， 可以将所有票种都需要的票属性信息， 直接记录 V 值， 差异化信息 采用 TV 或 TLV 方式， 例如故宫博物院参观票和公园年票。共同的属性信息有 ： 电子票提供商、 电子票类型、 电子票序列号 ； 故宫博物院参观票如图 6 所示， 公园年票如图 7 所示。
票信息属性表维护模块 240， 与发行模块 220 连接， 用于设置电子票解析全表， 所 述电子票解析全表记录有不同电子票提供商的不同电子票类型的属性信息与属性标识信 息的对应关系。
更新模块 250， 分别与通信模块 210 和票信息属性表维护模块 240 连接， 用于对票 务平台的电子票解析全表的内容进行管理， 包括增加、 删除或修改电子票解析全表中的电 子票属性信息。如增加火车票属性信息 ： 车次、 车厢、 座位类型。另外， 更新模块 250 可以发 起对电子票载体的本地电子票解析表进行更新。
电子票载体结构， 如图 8 所示， 包括 ：
购票模块 810， 用于向所述票务平台发送购票请求， 接收所述票务平台返回的购票 响应， 所述响应中携带电子票属性信息， 所述电子票属性信息中携带待检标记， 所述待检测 标记通过 Tag 编码规则中增加 1bit 实现， 或通过在电子票属性信息中增加一个字段实现， 用于确定所述电子票属性信息是否在检票时需要提供给检票设备 ；
检票模块 820， 与购票模块 810 连接， 用于根据所述检票设备提供的检票条件找到 匹配的电子票属性信息， 并根据所述待检标记确定所述电子票属性信息是否在检票时需要 提供给检票设备。 本地电子票解析表维护模块 830， 分别与购票模块 810 和检票模块 820 连接， 用于 将所述电子票属性信息记录到本地电子票解析表中， 并生成对应的电子票状态信息 ； 另外， 所述本地电子票解析表维护模块， 还用于接收所述票务平台发送的电子票解析全表变动的 内容， 更新本地电子票解析表 ； 或向所述票务平台发送更新请求， 获取电子票解析全表变动 的内容。
具体地， 在本发明实施例中， 对电子票载体中的电子票属性信息进行更新， 有如下 方法，
a. 通过票务平台的更新模块主动发起更新， 如图 9 所示， 包括以下步骤 ：
步骤 901， 所述票务平台和所述电子票载体分别对电子票解析全表和本地电子票 解析表配置版本号 ( 如 version1.0)， 初始时， 电子票载体和票务平台的电子票解析全表内 容是一致的， 版本号相同 ； 票务平台电子票解析全表每次变动时， 该表的版本号递增 1， 更 新为更高级别的电子票解析全表， 例如 version2.0。由于票务平台初始时的电子票解析全 表与电子票载体的本地电子票解析表的版本相同， 因此， 票务平台的电子票解析全表更新 后， 版本一定会比电子票载体的本地电子票解析表高， 因此， 为了使电子票载体的本地电子 票解析表同步， 更新模块向低版本的电子票载体下发新版本电子票解析全表变动的内容。
步骤 902， 所述票务平台在预设周期或检测到满足触发条件后， 向所述电子票载体 发送新版本电子票解析全表变动的内容。
步骤 903， 电子票载体提取更新请求中的内容， 根据该内容中的票属性信息更新 本地电子票解析表， 并将本地电子票解析表的版本修改为与票务平台的电子票解析全表的 版本号一致 ； 当票务平台下发的更新请求中携带本地电子票解析表的全部参数时， 电子票 载体可以将整表进行更新， 也可以比较该表中的信息与本地存储的本地电子票解析表的差 异， 将不同的内容更新到本地电子票解析表中 ； 如果更新请求中仅包括票务平台更新的内 容， 则电子票载体只更新这些内容， 可以节省传输带宽， 也可以减少电子票载体侧的比较运
算。 b. 电子票载体主动向票务平台发起更新， 如图 10 所示， 包括以下步骤 ；
步骤 1001， 在票务平台和电子票载体上分别对电子票解析全表和本地电子票解析 表配置一个版本号， 初始时， 电子票载体和票务平台的表内容是一致的， 版本号相同。票务 平台每更新一次电子票解析全表， 电子票解析全表版本依次加 1 ； 电子票解析全表的版本 更新都是由票务平台一侧完成的， 根据电子票提供的需求变化不断改变电子票解析全表中 的相关内容。
步骤 1002， 电子票载体在触发条件满足时， 向票务平台发起本地电子票解析表更 新请求， 该更新请求中携带电子票载体中的本地电子票解析表的版本号 ； 该触发条件例如， 当电子票载体与票务平台的表不同后， 启动定时器， 当该定时器超时时， 满足触发条件 ； 或 接收到了用户的某些触发指令。
步骤 1003， 票务平台更新模块判断电子票载体当前的本地电子票解析表版本与本 地存储的电子票解析全表版本是否不一致， 如果一致， 则说明电子票载体与票务平台中的 票属性信息同步， 不需要更新， 通知票务平台 ； 如果不一致， 转步骤 1004 ；
步骤 1004， 票务平台将两版本间的差异内容下发至电子票载体。
步骤 1005， 电子票载体收到下发内容后， 更新本地电子票解析表， 并将版本修改为 与票务平台版本号一致。
c. 电子票载体购票时发起更新， 如图 11 所示， 包括以下步骤 ：
步骤 1101， 初始时， 电子票载体只预装票务平台的电子票解析全表中所有票共有 的属性。
步骤 1102， 电子票载体向票务平台发送购票请求， 该购票请求中携带本次待购电 子票类型 ；
步骤 1103， 票务平台接收到购票请求后， 从票务平台的电子票解析全表中依据本 次待购的电子票类型， 获取本类型对应的电子票属性信息内容， 并将该内容下发至电子票 载体 ；
步骤 1104， 电子票载体收到下发内容后， 在本地电子票解析表中增加接收内容， 并 通知票务平台更新完毕 ；
步骤 1105， 票务平台下发模块将购买的电子票据下发至电子票载体 ；
本方式可以节省存储电子票载体的本地电子票解析表的空间大小， 实现按需更 新。例如， 初始时， 假定电子票载体只需支持对电影票的购票， 此时电子票载体仅需要预装 支持电影票的信息解析表， 此时电子票载体子表可以为以下内容， 如表 6 所示。
表6：
当该电子票载体需要支持公园年票时， 可以通过无线或者有线连接， 对电子票载 体的子表内容进行在线扩充。增加以下信息， 如表 7 所示 ：
表7：
Name Cert-Class ID-Num Start-Date End-Date
0x84 0x85 0x86 0x8B 0x8CB AN CN CN CN姓名 证件类型 证件号码 生效开始日期 失效日期Y Y Y Y Y最大 20 定长 1 最大 32 定长 4 定长 4当该电子票载体还需要其它类型票券服务时， 可以再次扩充其它票券所需的属性信息。 当该电子票载体不需要公园年票服务时， 也可以在线删除子表内的公园年票所需 的属性信息。
检票设备结构， 如图 12 所示， 包括 ：
检票规则获取模块 1210， 用于向票务平台发送获取检票规则信息的请求， 所述请 求中携带可检的电子票提供商和电子票类型信息 ； 接收所述票务平台返回的响应， 从所述 响应中获取对应的检票规则信息 ；
待检测信息获取模块 1220， 用于从所述电子票载体获取需要发送给检票设备的电 子票属性信息中的待检测信息 ；
检测模块 1230， 分别与检票规则获取模块 1210 和待检测信息获取模块 1220 连接， 用于根据从所述票务平台获取的检票规则信息对所述票据属性信息中的待检测信息进行 检验， 若检票通过， 则修改票状态信息为已检。
不同的票据， 需要检查的属性信息不尽相同。对电子票载体可以通过如下方法来 区分不同票据需要提供的待检属性信息， 如图 13 所示， 包括以下步骤 ：
步骤 1301， 票务平台根据电子票载体的购票请求， 向电子票载体发送票据属性信 息， 对每项票据属性信息中增加待检标记， 该待检标记用于向电子票载体指明该票据属性 信息是否在检票时需要提供， 即当票据属性信息携带的待检测标记有效时， 则说明该票据 属性信息需要在检票时提供给电子票检测设备， 当票据属性信息携带的待检测标记无效 时， 则说明该票据属性信息不需要在检票时提供给电子票检测设备。一般不需参与检票的 票据属性信息供用户浏览， 例如节目简介、 价格等。
其中， 待检标记可以通过在 Tag 编码规则中增加 1bit 实现， 如 Tag， 定长 1 个字节。 首比特为待检标识， 0 为不检， 1 为待检 (0x00 ～ 0x7F 表示不参与检票规则信息， 0x80 ～ 0xFF 表示参与检票规则信息 )。使用该方法， 不增加额外传输字段。
另外， 待检标记可以在票据属性信息中单独增加一个字段 C 实现， 该字段携带待 检标记， 此时的 TLV 或 TV 结构， 变成 TCLV 或 TCV。电子票载体收到票据属性信息时， 存储票 据属性信息。
步骤 1302， 电子票载体接收来自票务平台发送的票据属性信息， 将该票据属性信 息进行存储。
步骤 1303， 在检票设备对电子票载体检票时， 电子票载体从存储的票据属性信息 中， 依据属性 Tag 标签中的待检标记 ( 或字段 C)， 决定是否送给检票设备进行核检。电 子票载体能依据检票设备指定检票条件 ( 电子票提供商、 电子票日期等 )， 找到匹配的电 子票， 然后将该电子票的待检信息送给检票设备检查， 电子票载体可依据标记找到所有待 检信息。对于具有待检标记的票属性信息发送给检票设备进行检测。检票设备可以通过 NFC(Near FieldCommunication， 近距离无线通信 ) 接口与电子票载体交互， 获得待检电子 票属性信息。
步骤 1304， 检测设备根据检票规则信息对电子票载体中对应记录的票据属性信息 进行检验。若检票通过， 则修改电子票中的相关属性的属性参数作为已验标记。在检票通 过后， 检票设备对电子票中相关属性的属性参数作修改， 比如将 “是否有效” 属性的属性参 数修改为 “无效” ， 则表明该电子票， 或者该电子票中的部分项目已经检票通过了， 后续不得 再使用。
步骤 1305， 票务平台将修改后的电子票返回给电子票载体。
上述检票规则信息是由检票设备主动从票务平台获得， 具体过程如图 14 所示， 包 括以下步骤 ：步骤 1401， 检票设备向票务平台发送获取检票规则信息的请求， 所述请求中携带 要获取的检票规则信息的相关属性、 类型等参数 ；
步骤 1402， 票务平台接收该请求后， 根据该请求中的检票规则信息的相关属性， 从 全表中获取对应的检票规则信息 ； 检票规则信息中包括需要检验的属性 ( 待检验属性 ) 的 相关参数， 例如待检验属性的属性标识信息以及期待的该属性的属性参数。若检票规则信 息中需要检验的该属性的属性标识信息和期待的属性参数与电子票中相应属性的属性标 识信息、 属性参数相同， 则检票通过 ； 否则， 检票不通过。
步骤 1403， 票务平台将检票规则信息通过响应消息发送给检票设备。
上述检票规则信息也可以是由票务平台在到达触发条件时向检测设备发送， 具体 过程如图 15 所示， 包括以下步骤 ：
步骤 1501， 票务平台检测发生需要向检测设备发送检票规则信息， 例如， 预先设置 了在固定时间需要更新某些检测设备的检票规则信息 ( 可以在票务平台设置一个列表， 存 储所有注册的检测设备信息， 并根据类型、 时间等进行分类， 在某些场景下需要对某类检测 设备进行更新 )。
步骤 1502， 票务平台从全表中获取需要更新的检测设备的检票规则信息 ；
步骤 1503， 票务平台将这些检票规则信息发送给对应的检测设备。由于票务平台 可以更新检票设备的检票规则信息， 因此， 检票设备可以灵活的实现各种电子票的检验。
通过以上的实施方式的描述， 本领域的技术人员可以清楚地了解到本发明可以通 过硬件实现， 也可以借助软件加必要的通用硬件平台的方式来实现。 基于这样的理解， 本发 明的技术方案可以以软件产品的形式体现出来， 该软件产品可以存储在一个非易失性存储 介质 ( 可以是 CD-ROM， U 盘， 移动硬盘等 ) 中， 包括若干指令用以使得一台计算机设备 ( 可 以是个人计算机， 服务器， 或者网络设备等 ) 执行本发明各个实施例所述的方法。
本领域技术人员可以理解附图只是一个优选实施例的示意图， 附图中的模块或流 程并不一定是实施本发明所必须的。
本领域技术人员可以理解实施例中的装置中的模块可以按照实施例描述进行分 布于实施例的装置中， 也可以进行相应变化位于不同于本实施例的一个或多个装置中。上 述实施例的模块可以合并为一个模块， 也可以进一步拆分成多个子模块。
上述本发明序号仅仅为了描述， 不代表实施例的优劣。
以上公开的仅为本发明的几个具体实施例， 但是， 本发明并非局限于此， 任何本领 域的技术人员能思之的变化都应落入本发明的保护范围。