CN102521933A

CN102521933A - 跨平台的智能卡在线月票充值方法

Info

Publication number: CN102521933A
Application number: CN2011103968082A
Authority: CN
Inventors: 吴昊; 周亮; 李响; 修伟; 宋昆; 靳展; 高山华; 张彬
Original assignee: Tianjin Ic Card Public Network System Co Ltd
Current assignee: Tianjin Ic Card Public Network System Co Ltd
Priority date: 2011-12-05
Filing date: 2011-12-05
Publication date: 2012-06-27

Abstract

本发明涉及一种专门适用于行政、商业、金融、管理、监督或预测目的的数据处理系统或方法，进一步涉及一种跨平台的智能卡在线月票充值方法。在上述系统上实现的跨平台的智能卡在线操作方法，过程如下：首先，将智能卡放在读卡器上，步骤一：预读卡；步骤二：读卡器读卡；步骤三：输入充值起始月份和充值月数信息；步骤四：记录卡片当前信息；步骤五：读卡器改写卡内标志；步骤六：在第三方客户端程序上显示充值结果；本发明真正地实现了跨平台操作，后台集中管理。

Description

跨平台的智能卡在线月票充值方法

技术领域：

本发明涉及一种专门适用于行政、商业、金融、管理、监督或预测目的的数据处理系统或方法，进一步涉及一种跨平台的智能卡在线月票充值方法。

背景技术：

当前，很多城市已经开通了公交智能卡收费系统和城市一卡通收费系统，以下统称为智能卡系统。这些城市运行的系统中，对智能卡进行发行和卡内电子钱包充值的模块往往是由一个公司来进行开发和维护。当用户希望与其他的商家进行业务合作时，必须让原有智能卡系统开发商进行软件的修改或者提供相应的技术资料，才能实现所需的业务开发。

举个例子：如果智能卡系统运营商希望与银行进行合作，利用银行的网点优势和资金优势，完成智能卡的发行和电子钱包的充值工作。银行拥有独立的金融管理系统和网络，银行往往出于安全性方面的考虑，不允许智能卡系统开发商在银行金融系统和网络中进行程序应用。因此，智能卡系统开发商必须提供一套完整的技术解决方案给银行，通过银行的通讯系统与智能卡系统进行通讯，从而完成智能卡的发行与充值业务。另外不同的银行系统，使用不同的操作系统，因此智能卡系统开发商提供的技术解决方案必须是跨平台的，具有二次开发功能的，这样才可以让智能卡系统在银行的操作系统下运行起来。

由于以上的种种原因，造成智能卡系统业务的拓展非常困难。

如何开发一款跨平台的、可以进行二次开发的、安全的智能卡在线充值系统，是摆在我们面前的一个急需解决的问题。

发明内容：

本系统开发的目的在于，克服原有系统技术上的不足，利用串口操作和Socket通讯机制，提供跨平台的、二次开发的功能。同时系统提供数据的安全性和交易的完整性保障。

本系统通过以下技术方案实现：

跨平台的智能卡在线操作系统，包括：读卡器，与读卡器一一对应串接的第三方客户端，分别与一个以上第三方客户端串接的第三方通讯程序端，与一个以上第三方通讯程序分别串接的智能卡清算中心交易中间件程序端，与智能卡清算中心交易中间件程序端依次串接的清算中心，清算中心具有加密和解密功能。

所述读卡器内置嵌入式软件，用于对智能卡进行读写操作；读卡器内安装SAM卡，用于传输过程中对数据的加密和解密，SAM卡中设置多组密钥，由嵌入式软件随机选取；读卡器提供专用的智能卡读写指令，用于对智能卡进行操作。

读卡器可以为外置式读卡器，与第三方客户端所在的计算机主机连接；也可以为内置式读卡器，与ATM机、银行查询机、POS机设备中的任何一种通过串口连接。

本系统所对应的智能卡具有黑名单标志，表识卡片的当前状态。

在上述系统上实现的跨平台的智能卡在线操作方法，过程如下：

首先，将智能卡放在读卡器上，

步骤一：第三方客户端程序向读卡器发送充值预读卡指令，读卡器以密文的形式将智能卡的基本信息依次通过第三方客户端、第三方通讯程序、交易中间件程序，最后到达智能卡清算中心数据库；加密机经过解密后查询卡类型参数、计算充值密钥；卡类型参数以明文的形式依次通过交易中间件程序、第三方通讯程序，到达第三方客户端；包括充值密钥在内的智能卡操作信息经过加密机加密，以密文的形式依次通过交易中间件程序、第三方通讯程序、第三方客户端，到达读卡器；

步骤二：读卡器读卡，判断卡状态和交易进程标志，如果黑名单和进程标志正常，进入充值界面，转步骤三，如果黑名单和进程标志正常任何一个标志不正常，转步骤七；

步骤三：操作人员通过第三方客户端程序输入充值起始月份和充值月数信息，并向读卡器发送预月票充值指令；读卡器首先将黑名单标志由0改写为4，进程标志由0改写为21；然后将智能卡的信息形成月票充值密文，依次通过第三方客户端、第三方通讯程序、交易中间件程序，最后到达智能卡清算中心数据库；

步骤四：智能卡清算中心数据库进行电子月票充值操作合法性检验，如果合法，记录卡片当前信息，进行月票充值纪录，并形成充值确认报文，以密文的形式经交易中间件程序、交易中间件程序、第三方客户端程序，到达读卡器；

步骤五：读卡器改写卡内标志，进程标志由21改写为22，然后按照密文信息对智能卡进行充值，充值完成后，将黑名单标志由4改写为0，进程标志由12改写为0；

步骤六：在第三方客户端程序上显示充值结果；

步骤七：读卡器将包含卡号、黑名单标志、交易进程标志信息在内的月票恢复报文以密文的形式依次经过第三方客户端、第三方通讯程序、交易中间件程序，最后到达智能卡清算中心数据库；

步骤八：本步骤共有二种恢复方案，第一方案；生成月票恢复密文，其操作要领是更改黑名单标志为0，更改进程标志为0，卡内其它内容不变；第二方案：在清算中心数据库中补齐起始月份月票充值记录，生成月票恢复密文，其操作要领是更改黑名单标志为0，更改进程标志为0，卡内其它内容不变；当满足如下条件：步骤七中的黑名单标志为4，进程标志为21，该卡号在月票充值未结算表中有多条记录，且多条记录与卡的记录一致，实施第一方案；当满足如下条件：步骤七中的黑名单标志为4，进程标志为21，该卡号在月票充值未结算表中有多条记录，且多条记录与卡的记录不一致，实施第二方案；当满足如下条件：步骤七中的黑名单标志为4，进程标志为21，该卡号在月票充值未结算表中无记录，但在已结算表中有记录，且多条记录与卡的记录一致，实施第一方案；当满足如下条件：步骤七中的黑名单标志为4，进程标志为21，该卡号在月票充值未结算表中无记录，但在已结算表中有记录，且多条记录与卡的记录不一致，实施第二方案；当满足如下条件：步骤七中的黑名单标志为4，进程标志为21，该卡号在月票充值未结算表中无记录，且在已结算表中也无记录，实施第二方案；当满足如下条件：步骤七中的黑名单标志为4，进程标志为22，该卡号在月票充值未结算表或已结算表中有记录，且多条记录与卡的记录一致，实施第一方案；当满足如下条件：步骤七中的黑名单标志为4，进程标志为22，该卡号在月票充值未结算表或已结算表中有记录，且多条记录与卡的记录不一致，实施第二方案；当满足如下条件：步骤七中的黑名单标志为4，进程标志为22，该卡号在月票充值未结算表和已结算表中均无记录，实施第二方案；

步骤九：将恢复密文并以明文的形式附带将恢复数据经交易中间件程序、第三方通讯程序、第三方客户端，到达读卡器，读卡器执行完恢复操作后将数据以明文的形式发送给第三方客户端；

然后重新执行步骤二。

所述步骤一中读卡器形成密文数据包括：随机数、卡芯片号、卡号、卡类型号、卡认证码、有效日期、启用日期、密钥卡号；所述步骤一中卡类型参数数据包括：服务器时间、卡类型名称、月票金额、月票基次。

所述步骤一中智能卡操作信息除充值密钥外，还包括：随机数、服务器时间。

所述步骤二中充值界面可现实信息包括：卡芯片号、卡号、卡类型号、押金、有效日期、启用日期、年检日期、月票基本次数、月票累计充值次数、月票总余次、月票起始月份、月票截至月份、黑名单标志、密钥卡号。

所述步骤三中的充值密文信息包括：随机数、卡芯片号、卡号、卡类型、月票充值计数器、卡内起始年月日、卡内终止年月日、卡内月票余额、充值起始月份、充值月数、月票基本金额、密钥卡号。

所述步骤四中的合法性检查包括以下检查的一种或多种：根据卡类型及操作员号查询是否有售卡权限、查询是否是黑名单卡、判断充值月份是否合法、判断月票金额是否合法。

所述步骤四中记录卡片当前信息的内容至少包括下述内容中的一种：月票月份、月票余额。

所述步骤四中的充值确认报文内容至少包括下述内容中的一种：随机数、充值时间、卡号、累计充值次数、月票起始月份、月票截止月份、月票总次数、月票基本次数、密钥卡号。

所述步骤六中的现示信息包括：月票起始月份、月票截止月份和月票总余次。

所述步骤九中以明文的形式发送给第三方客户端的信息内容包括：卡号、月票起始月份、月票截止月份、月票总余次。

本发明相对于现有技术具有如下优点：

(一)可以与任何具有独立运行网络的第三方，譬如银行、邮局等单位进行合作，既实现了利用第三方网店实现卡的发行与充值，又满足了这些第三方对数据安全性的苛刻要求。

(二)真正地实现了跨平台操作，后台集中管理。

附图说明

图1是本发明系统结构示意图。

图2是实施例中的SAM密钥卡结构示意图。

图3是实施例中的读卡器RC500与天线原理示意图。

图4是实施例中的读卡器RC500总体结构示意图。

图5是实施例中的交易中间件程序端主要部件与内存结构。

图6是实施例系统结构示意图。

图7是实施例中建立数据库连接步骤一计算机实际显示截图。

图8是实施例中建立数据库连接步骤二计算机实际显示截图。

图9是实施例中建立数据库连接步骤三计算机实际显示截图。

图10是实施例中建立数据库连接步骤五计算机实际显示截图。

图11是实施例中修改ConnectParam.xml配置文件中的内容实际显示截图。

图12是实施例中系统启动实际显示截图。

具体实施方式：

实施例：

XX城市一卡通系统采用本方案设计实现。实现建设银行圈存机和柜面系统的IC卡售卡、充值业务。借助银行网点的数量与网络优势，实现城市一卡通业务的拓展。

功能描述

实现城市一卡通系统中IC卡的售卡、电子钱包充值、月票充值功能。

目前建设银行在20多台圈存机以及柜面储蓄系统中加入了IC卡的在线充值功能。从而有效地拓展了IC卡业务的覆盖范围。

跨平台的智能卡在线操作系统，包括：读卡器，与读卡器一一对应串接的第三方客户端，分别与一个以上第三方客户端串接的第三方通讯程序，与一个以上第三方通讯程序分别串接的智能卡清算中心交易中间件程序，与智能卡清算中心交易中间件程序依次串接的清算中心，清算中心具有加密和解密功能。

一、内/外置读卡器

如图3、4所示。具体参数如下：

CPU：采用美国SST公司生产的SST89E52RD2；

工作电压：由USB接口供电，无需外加电源；

工作电流：300mA；

最大功耗：≤2.25W；

工作温度：20℃～+50℃；

读写距离：≤4.0CM；

通讯速率：57.6Kbps。

读卡器分别设计具有接触式IC卡和非接触式IC卡的读写功能；

采用低工作电压、低功耗技术，硬件性能安全可靠；

采用SAM卡安全管理模块和CPU管理卡密钥方式，发卡及充值工作安全可靠；

支持符合mifare国际标准的系列非接触IC卡；支持符合T＝0/T＝1协议的CPU卡；

支持符合ISO7816-3系列接触式IC存储卡，逻辑加密卡；

支持符合ISO14443国际标准的非接触式逻辑加密卡，非接触CPU卡；

采用RS232接口(USB供电)，传输速率为57600bps；

支持串口通讯，发送指令，接收数据；

嵌入式程序，实现对IC卡的安全操作和数据加解密。

读卡器通讯接口：RS232；

读卡器通讯接口波特率：19200；

读卡器通讯数据格式：0xAA+LEN+COMMAND+DATA+VERIFY+0xCC

读卡器通讯LEN：COMMAND+DATA+VERIFY(一个字节)

读卡器通讯VERIFY：LEN XOR COMMAND XOR DATA(一个字节)

读卡器通讯回应格式：0xBB+VALUE+0xCC

读卡器通讯VALUE：

读卡器通讯逆序字节排列：高位字节-＞低位字节；

如100逆序四字节顺序为64H 00H 00H 00H。

二、SAM密钥卡结构

如图2所示。

三、交易中间件程序

交易中间件，同步接收用户的连接，校验用户身份，实时分析用户的交易请求，并反馈处理结果，本系统需要配合使用RF内/外置读卡器。该系统可以有效的防止非法程序的运行和使用，并且在数据传输过程中进行自动加解密，防止信息被窃取后造成对系统的危害；防止非法节点的运行和使用；数据全程密文传输。动态通讯身份认证密钥体系，可以实现每次用户身份认证均赋予一个唯一的通讯密钥，并且在通讯全过程进行动态验证，保证用户身份的正确性。

1、工作原理：

主要部件与内存结构如图5所示。启动中间件程序，相当于启动一个服务进程，服务进程将启动多个线程来管理系统，并为多个连接的用户提供相应的服务。

服务进程主要提供以下功能：

(1)分配内存空间，启动多个线程进行系统管理；

(2)启动Server线程。a、接受用户的连接请求、关闭连接请求，并为用户分配处理线程；b、对数据库连接池进行有效的控制和管理。

(3)启动处理线程。a、处理用户的签到、签退报文；b、处理用户的交易报文；c、分别将显示数据、统计数据、日志数据分别放入显示队列、统计队列、日志队列中。

(4)启动显示线程。a、维护界面的显示；b、实现提示信息、统计数据信息、日志信息的界面显示；c、实现将系统通讯信息记录到系统日志文件中。

交易中间件软件的特点：大量在线用户；频繁信息访问；小事务处理；TCP/IP网络；管理C/S数据流；支持3层结构；支持二次开发；基于实时交易处理；核心参数配置文件；负载平衡；安全数据传输。

2、交易中间件程序通讯报文设计

采用交易终端+读卡器、交易中间件程序、数据库三层结构，交易终端与中间件之间使用本协议制定的报文格式进行通讯，通讯报文依据ISO8583报文规范制定。

(1)数据类型

交易终端与中间件之间的交换消息报文中，各数据元类型及格式如下所列：

A 字母，左靠，右部多余部分补空格。

N 数字，右靠，首位有效数字前补零。若表示金额，则最右二位为角分。

S 特殊符号。

AN 字母和/或数字，左靠，右部多余部分补空格。

AS 字母和/或特殊符号，左靠，右部多余部分补空格。

ANS 字母、数字和/或特殊符号，左靠，右部多余部分补空格。

B 二进制位。

DD 日。

MM 月。

YY 年。

hh 时。

mm 分。

ss 秒。

LL 可变长域的长度值(二位数)，允许的最大长度为99。

LLL 可变长域的长度值(三位数)，允许的最大长度为999。

VAR可变长域。

X 借贷符号，在数值之前，D表示借，C表示贷。

M：强制域(Mandatory)，表示此域必须出现在消息报文中，否则报文接收方认为该消息报文格式出错。

C：条件域(Conditional)，表示此域在一定条件下出现在消息报文中。

对可变长数据元，以下例说明：

变量XYZ的数据类型为ANS...999(LLLVAR)，则表示：该变量中可包含字母、数字和特殊符号，最长不超过999个字符，具体长度由三位数字确定。

(2)报文格式：交易终端上送中间件的消息报文结构包括TPDU、报文头和应用数据三部分，如下表1所示

表1

TPDU说明：长度为5个字节。

报文头说明：总长度为12字节，压缩时用BCD码表示为6个字节长度的数值。

在交易终端上送的请求/通知报文中，该数值由交易终端应用程序在打包上送时根据交易终端参数和当前状态填入应用类别、软件版本号和终端状态，用于中间件根据数值进行相应的处理。

在中间件返回的响应报文中，由中间件填入处理要求，其他域保持原值返回，交易终端将根据收到报文头中的处理要求进行相应处理。

报文头取值如下：

应用类别定义：70

软件版本号：05

终端状态：0代表正常交易状态，1代表测试交易状态。

处理要求：0代表用户签到，1代表交易处理。

保留使用：暂时不用，填全“0”。

应用数据说明：应用数据是符合ISO8583报文协议格式的交易数据，本文档定义的各种交易报文使用的消息域包括：域1、域11、域12、域13、域32、域37、域39、域41、域42、域55、域56和域59。

(3)应用数据消息域说明

消息类型。变量属性：N4，4个字节的定长数字字符域，

消息类型定义如下：

0600IC卡业务类请求消息：查询请求、IC卡业务请求、IC卡业务撤消请求。

0610IC卡业务类应答消息：查询应答、IC卡业务应答、IC卡业务撤消应答。

0800网络业务管理类消息：终端签到请求、终端参数传递请求。

0810网络业务管理类应答消息：终端签到应答、终端参数传递应答。

0820网络业务管理类消息：终端签退请求。

0830网络业务管理类应答消息：终端签退应答。

下面说明中忽略未使用的域。

域1位图域。属性：B8，8个字节的定长域。

描述：如将位图的第一位设为’1’，表示使用扩展位图，否则表示只使用基本位图。如使用某数据域，则在位图中将相应的位设为’1’，如使用41域，则需将位图的41位设为’1’。如使用65到128域，需设位图域的第一位设为’1’。因本系统仅使用1至64域，故本域为8字节定长域。

域11受卡方系统跟踪号。变量属性：N6，6个字节的定长数字字符域。

描述：交易受卡方(IC卡业务的交易终端、POS交易的POS终端)赋予交易的在某段时间内唯一确定该笔交易的流水号。对受卡方来说，该跟踪号与41域(受卡方终端标识码)、42域(受卡方标识码)和55.2域(批次号)的组合唯一标识该笔交易。

用法：终端对发起的每一笔正常交易赋予一个跟踪号。对于恢复交易，该域与原始交易保持一致；IC卡中心在收到消息后保存该值，并在应答消息中原样返回给终端。终端应用该值和41域(受卡方终端标识码)、42域(受卡方标识码)、55.2域(批次号)一起匹配原始请求消息。

规定：000001-999999。

域12受卡方所在地时间。变量属性：N6，6个字节的定长数字字符域。

域描述：交易发生时，受卡方所在地时间(服务器时间)。格式为hhmmss，其中hh为小时，mm为分，ss为秒。

用法：IC卡中心收到终端的请求消息时，将12域和13域一起返回给终端。

受卡方所在地时间的取值范围：hh：00-23；mm：00-59；ss：00-59。

规定：123021。

域13受卡方所在地日期。变量属性：N4，4个字节的定长数字字符域

域描述：交易发生时，受卡方所在地日期(服务器时间)。格式为MMDD，其中MM为月份，DD为日。

用法：IC卡中心收到终端的请求消息时，将12域和13域一起返回给终端。受卡方所在地日期的取值范围：MM：01-12；DD：01-31。

规定：0926。

域32受理方标识码。变量属性：N..11(LLVAR)，2个字节的长度值+最大11个字节的受理方标识码。

域描述：受理方标识码。本系统中指“IC卡运营中心”。

用法：目前用八位数字来标识一个机构，若此域的长度值不等于8，则认为消息格式出错。

规定：0800000001。

域37检索参考号。变量属性：AN12，12个字节的定长字符域。

域描述：IC卡中心赋予在每个清算日内每笔从终端收到的唯一的系统流水号。IC卡中心用该流水号与消息类型、12域(受卡方所在地时间)和13域(受卡方所在地日期)的组合唯一地标识该笔交易(重复发送的交易将被认为是一笔交易)。

用法1：终端在收到交易应答消息时可获取IC卡中心的系统流水号，本域的值可作为日后交易查询的依据。

用法2：IC卡中心赋予终端发出的非在线交易类消息的流水号。

规定：范围：X00000000001-X99999999999。

域39应答码。变量属性：AN2，2个字节的定长字符域。

域描述：IC卡中心响应终端的应答码。

用法：交易应答码中仅″00″为交易成功，其它为交易不成功。交易返回终端时都有39域，终端和终端操作员根据应答码要采取相应的操作，可以把操作分为以下几类：

A：交易成功

B：交易失败，可重试

C：交易失败，不需要重试

D：交易失败，终端操作员处理

E：交易失败，系统故障，不需要重试

注1：如果39域的内容不能在下表中找到，就显示“交易失败”

注2：如果交易的批次号和网络中心批次号不一致时应答码会填“77”，此时终端应当提示操作员重新签到，再作交易。

详细内容见表2

表2

终端引发的恢复消息中，存放恢复原因码，详见表3。

表3

代码	说明
		98	终端在时限内未能收到IC卡中心的应答
96	终端收到IC卡中心的批准应答消息，但由于终端故障无法完成交易
		99	终端对收到IC卡中心的批准应答消息，验证MAC出错
06	其他情况引发的恢复

域41受卡方终端标识码。变量属性：AN8，8个字节的定长域。

域描述：受卡方终端的标识码。该标识码在IC卡中心的网络中唯一标识一个终端，不能重复。

用法：IC卡中心在收到消息后保存受卡方终端标识码，在应答消息中原样返回给终端。终端用该值和11域(受卡方系统跟踪号)、42域(受卡方标识码)、55.2域(批次号)一起匹配原始请求消息。

规定范围：00000001-99999999。

域42受卡方标识码。变量属性：AN15，15个字节的定长域。

域描述：受卡方的标识码，即商户代码。

用法：该标识码在IC卡中心的网络中唯一标识一个代理商户代码，不能重复。目前根据中国银联规定的“银行卡特约商户统一编码及使用规则”执行。

规定范围：000000000000001-000000099999999。

域55交易数据。变量属性：ANS...995(LLLVAR)，3个字节的长度值+最大995个字节的数据域。

域描述：本域为交易数据域。

用法：所有的终端向IC卡中心发送的交易消息中，均包含55.1域和55.2域，用于指明本交易的交易类型。

终端的网络管理类报文中，网络管理信息码与消息类型码的组合标识不同的网络管理类消息。

55.A交易类型码如表4所示。

表4

消息类型	交易类型码	网络管理信息码	交易类型
				0600/0610	80	000	售卡预读卡
0600/0610	81	000	售卡
				0600/0610	84	000	充值预读卡
0600/0610	85	000	钱包充值
				0600/0610	86	000	钱包恢复
0600/0610	87	000	月票充值
				0600/0610	88	000	月票恢复
0600/0610	90	000	钱包冲红
				0600/0610	91	000	月票冲红

55.B网络管理信息码如表5所示。

表5

55.1充值预读卡

消息类型统一为：0600

返回信息统一为：0610

网络管理信息码：000

交易类型码：84

交易(密文)数据格式：

表6

编码	含义	格式	取值
				1	密文内容	AN64	数据元长度：32字节

55.2月票充值

消息类型统一为：0600

返回信息统一为：0610

网络管理信息码：000

交易类型码：87

交易(密文)数据格式：

表7

编码	含义	格式	取值
				1	密文内容	AN80	数据元长度：40字节

55.3月票恢复

消息类型统一为：0600

返回信息统一为：0610

网络管理信息码：000

交易类型码：88

交易(密文)数据格式：

表8

编码	含义	格式	取值
				1	密文内容	AN128	数据元长度：64字节

域56返回数据

变量属性：

ANS...990(LLLVAR)，3个字节的长度值+最大990个字节的数据域。

域描述：

本域为自定义域。

数据元长度 N3

56.X 返回数据 ANS...990(LLLVAR)

56.1充值预读卡

返回(明文)数据格式：

表9

编码	含义	格式	取值
				1	卡类型名称	AN20	10字节HEX码，(ASCII码)
2	月票是否有效	AN2	1字节HEX码，0x00：无效；0x01：有效
				3	月票每月次数	N4	2字节HEX码
4	月票每月金额	AN8	4字节HEX码，以分为单位
				5	客票是否有效	N2	1字节HEX码，0x00：无效；0x01：有效

6	客票充值上限	N8	4字节HEX码，以分为单位
				7	客票充值下限	N8	4字节HEX码，以分为单位

数据元长度：26字节

返回(密文)数据格式：

表10

编码	含义	格式	取值
				8	密文内容	AN64	数据元长度：32字节

56.2月票充值

返回(密文)数据格式：

表11

编码	含义	格式	取值
				1	密文内容	AN96	数据元长度：48字节

56.3月票恢复

返回数据格式：

表12

编码	含义	格式	取值
				1	密文内容	AN96	数据元长度：48字节

域59操作员代码

自定义域(Reserved Private)

变量属性：

ANS..63(LLVAR)，2个字节的长度值+最大63个字节的数据。

域描述：

本域为自定义域。

数据元长度 N2

59.1 操作员代码 AN16

在终端交易中，终端将操作员代码上送到IC卡中心，应答时原样返回。

(3)交易报文

充值预读卡

表14

月票充值

表15

月票恢复

3、交易中间件系统安装与配置

程序安装

(1)选择一台应用服务器，基本配置(CPU：Intel酷睿双核1.8G以上，内存：2G DDR2800以上，硬盘：160GB SATA，网卡：10/100M网卡)

(2)在D盘根目录下建立CAgent目录，并将以下文件拷贝到目录中。

CAgent.exe

CTongBASIC.dll

CTongFile.dll

CTongSE.dll

ProcCommand.xml

ConnectParam.xml

(3)建立D:\CAgent\DB，D:\CAgent\FTP，D:\CAgent\LOG子目录。

(4)安装.net 2005运行环境。

建立数据库连接

(1)控制面板→管理工具→数据源(ODBC)，如图7所示。

(2)选择用户DSN，并按按“添加”按钮，如图8所示。

(3)选择“microsoft ODBC for Oracle”，并按完成按钮，如图9所示。

(4)在弹出窗口中输入信息，并按确定按钮。

数据源名称：用于定义的ODBC连接名称；

描述：用户关于连接的描述；

用户名称：连接数据库的用户名；

服务器：为建立oracle连接所配置的服务名；

(5)按确定按钮完成配置，如图10所示。

修改ConnectParam.xml配置文件中的内容，如图11所示

系统启动，运行D:\CAgent\CAgent.exe；如图12所示。

在上述系统上实现的跨平台的智能卡在线操作方法，包括：

首先，将智能卡放在读卡器上，

步骤六：在第三方客户端程序上显示充值结果；

然后重新执行步骤二。

Claims

1.跨平台的智能卡在线月票充值方法，其特征在于，包括如下步骤：

首先，将智能卡放在读卡器上，

步骤六：在第三方客户端程序上显示充值结果；

然后重新执行步骤二。

2.根据权利要求1所述的跨平台的智能卡在线月票充值方法，其特征在于，所述步骤一中读卡器形成密文数据包括：随机数、卡芯片号、卡号、卡类型号、卡认证码、有效日期、启用日期、密钥卡号；所述步骤一中卡类型参数数据包括：服务器时间、卡类型名称、月票金额、月票基次。

3.根据权利要求1所述的跨平台的智能卡在线月票充值方法，其特征在于，所述步骤一中智能卡操作信息除充值密钥外，还包括：随机数、服务器时间。

4.根据权利要求1所述的跨平台的智能卡在线月票充值方法，其特征在于，所述步骤二中充值界面可现实信息包括：卡芯片号、卡号、卡类型号、押金、有效日期、启用日期、年检日期、月票基本次数、月票累计充值次数、月票总余次、月票起始月份、月票截至月份、黑名单标志、密钥卡号。

5.根据权利要求1所述的跨平台的智能卡在线月票充值方法，其特征在于，所述步骤三中的充值密文信息包括：随机数、卡芯片号、卡号、卡类型、月票充值计数器、卡内起始年月日、卡内终止年月日、卡内月票余额、充值起始月份、充值月数、月票基本金额、密钥卡号。

6.根据权利要求1所述的跨平台的智能卡在线月票充值方法，其特征在于，所述步骤四中的合法性检查包括以下检查的一种或多种：根据卡类型及操作员号查询是否有售卡权限、查询是否是黑名单卡、判断充值月份是否合法、判断月票金额是否合法。

7.根据权利要求1所述的跨平台的智能卡在线月票充值方法，其特征在于，所述步骤四中记录卡片当前信息的内容至少包括下述内容中的一种：月票月份、月票余额。

8.根据权利要求1所述的跨平台的智能卡在线月票充值方法，其特征在于，所述步骤四中的充值确认报文内容至少包括下述内容中的一种：随机数、充值时间、卡号、累计充值次数、月票起始月份、月票截止月份、月票总次数、月票基本次数、密钥卡号。

9.根据权利要求1所述的跨平台的智能卡在线月票充值方法，其特征在于，所述步骤六中的现示信息包括：月票起始月份、月票截止月份和月票总余次。

10.据权利要求1所述的跨平台的智能卡在线月票充值方法，其特征在于，所述步骤九中以明文的形式发送给第三方客户端的信息内容包括：卡号、月票起始月份、月票截止月份、月票总余次。