CN102520988A - 一种智能卡个人化数据的处理方法和系统 - Google Patents

Abstract

本申请提供了一种智能卡个人化数据的处理方法和系统，其中的方法具体包括：依据智能卡个人化数据的格式，对相应的智能卡个人化数据进行处理，所述处理包括：若所述智能卡个人化数据的格式为指令格式，则对所述智能卡个人化数据进行透传处理；若所述智能卡个人化数据的格式为非指令格式，则依据所述智能卡个人化数据组装相应的个人化指令。本申请能够针对不同行业领域的智能卡个人化数据进行处理。

Description

一种智能卡个人化数据的处理方法和系统

技术领域

本申请涉及智能卡个人化技术领域，特别是涉及一种智能卡个人化数据的处理方法和系统。

背景技术

目前，随着智能卡的迅猛发展，智能卡应用的多样化，智能卡个人化变得越来越重要。在制卡商制卡完毕，将智能卡下发至持卡人之前，都需要进行智能卡个人化。智能卡个人化是将交易所需的个人化数据组织并安装到卡片应用上的过程。例如，对于申请的银行卡或者信用卡来说，需要将个人的姓名、卡号、安全等相关信息写入卡内，然后才能发到用户手中。

然而，不同领域、不同行业在发展过程中形成了各自独有的智能卡个人化数据处理方式。例如，某些金融行业对智能卡的APDU(应用协议数据单元，Application Protocol Data Unit)指令进行严格控制，其个人化信息中心对外开放的接口是一系列的APDU指令；而某些行业只关注个人化信息，其个人化信息中心对外开放的接口是包含个人化信息的文件，如XML(可扩展标记语言，Extensible Markup Language)文件、TXT文件等，或者DGI(数据分组标记符，Data Grouping Identifier)分组数据。因此，现有的智能卡个人化数据处理方式只能适用于特定独有的行业领域，并不具有通用性。

总之，需要本领域技术人员迫切解决的一个技术问题就是：如何能够提供一种通用的个人化数据处理方式，其能够针对不同行业领域的个人化机构进行无缝对接。

发明内容

本申请所要解决的技术问题是提供一种智能卡个人化数据的处理方法和系统，能够针对不同行业领域的智能卡个人化数据进行处理。

为了解决上述问题，本申请公开了一种智能卡个人化数据的处理方法，包括：

依据智能卡个人化数据的格式，对相应的智能卡个人化数据进行处理，所述处理包括：

若所述智能卡个人化数据的格式为指令格式，则对所述智能卡个人化数据进行透传处理；

若所述智能卡个人化数据的格式为非指令格式，则依据所述智能卡个人化数据组装相应的个人化指令。

优选的，所述透传处理包括：

接收来自智能卡的个人化请求；

依据所述个人化请求，创建与相应个人化机构的通道；

向所述个人化机构发送连接请求，并依据所述个人化机构对所述连接请求的响应建立到所述个人化机构的连接；

向所述个人化机构发送个人化数据请求；

接收所述个人化机构返回的个人化指令；

对所述个人化指令进行校验，对校验通过的个人化指令进行组织，并将组织完成的个人化指令下发给智能卡。

优选的，所述依据所述智能卡个人化数据组装相应的个人化指令的步骤，包括：

依据所述智能卡个人化数据，组织得到数据分组标识数据；

将所述数据分组标识数据转换为个人化指令。

优选的，所述依据所述智能卡个人化数据，组织得到数据分组标识数据的步骤，包括：

从所述智能卡个人化数据中解析出类型长度值数据；

依据数据分组标识原则，将所述类型长度值数据重组为数据分组标识数据。

优选的，所述将所述数据分组标识数据转换为个人化指令的步骤，包括：

依据智能卡所符合的管理协议规范，通过填充字段方式将所述数据分组标识数据组织为相应的个人化指令。

优选的，所述对个人化指令进行校验的步骤，包括：

校验所述个人化指令的报文完整性；或者，

判断一组个人化指令是否结束，或者，

校验一条个人化指令的长度是否符合规定。

优选的，所述对个人化指令进行组织的步骤，包括：

依据智能卡所符合的管理协议规范或者通讯通道所规定的数据字段长度，对所述个人化指令进行分组；

依次将各组个人化指令下发至智能卡。

优选的，所述智能卡包括如下智能卡种类中的一种或多种：native、java、multos；

所述智能卡包括如下卡片物理形态中的一种或多种：SIM、SD、microSD、金融PBOC。

另一方面，本申请还公开了一种智能卡个人化数据的处理系统，其用于依据智能卡个人化数据的格式，对相应的智能卡个人化数据进行处理，所述系统包括：

透传处理模块，用于在所述智能卡个人化数据的格式为指令格式时，则对所述智能卡个人化数据进行透传处理；

组装处理模块，用于在所述智能卡个人化数据的格式为非指令格式时，则依据所述智能卡个人化数据组装相应的个人化指令。

优选的，所述透传处理模块包括：

第一接收子模块，用于接收来自智能卡的个人化请求；

通道创建子模块，用于依据所述个人化请求，创建与相应个人化机构的通道；

第一发送子模块，用于向所述个人化机构发送连接请求；

连接建立子模块，用于依据所述个人化机构对所述连接请求的响应，建立到所述个人化机构的连接；

第二发送子模块，用于向所述个人化机构发送个人化数据请求；

第二接收子模块，用于接收所述个人化机构返回的个人化指令；

校验子模块，用于对所述个人化指令进行校验；

第一组织子模块，用于对校验通过的个人化指令进行组织；及

下发子模块，用于将组织完成的个人化指令下发给智能卡。

优选的，所述组装处理模块包括：

第二组织子模块，用于依据所述智能卡个人化数据，组织得到数据分组标识数据；

转换子模块，用于将所述数据分组标识数据转换为个人化指令。

优选的，所述第二组织子模块包括：

解析单元，用于从所述智能卡个人化数据中解析出类型长度值数据；

重组单元，用于依据数据分组标识原则，将所述类型长度值数据重组为数据分组标识数据。

优选的，所述转换子模块包括：

填充组织单元，用于依据智能卡所符合的管理协议规范，通过填充字段方式将所述数据分组标识数据组织为相应的个人化指令。

优选的，所述校验子模块包括：

完整性校验单元，用于校验所述个人化指令的报文完整性；或者，

结束判断单元，用于判断一组个人化指令是否结束，或者，

长度校验单元，用于校验一条个人化指令的长度是否符合规定。

优选的，所述第一组织子模块包括：

指令分组单元，用于依据智能卡所符合的管理协议规范或者通讯通道所规定的数据字段长度，对所述个人化指令进行分组；

所述下发子模块，具体用于依次将各组个人化指令下发至智能卡。

优选的，所述智能卡包括如下智能卡种类中的一种或多种：native、java、multos；

所述智能卡包括如下卡片物理形态中的一种或多种：SIM、SD、microSD、金融PBOC。

与现有技术相比，本申请具有以下优点：

相对于现有技术只能适用于特定独有的行业领域，并不具有通用性的缺点，本申请能够针对不同行业领域的不同格式的智能卡个人化数据进行处理的技术方案，具体而言，若所述智能卡个人化数据的格式为指令格式，则对所述智能卡个人化数据进行透传处理；若所述智能卡个人化数据的格式为非指令格式，则依据所述智能卡个人化数据组装相应的个人化指令；因此，本申请能够针对不同行业领域的个人化机构进行无缝对接，具有各行业领域智能卡个人化数据处理的通用性；

本申请可适用于电信、金融、通信、交通等不同领域，适用于native卡、java卡、multos卡等不同智能卡种类，适用于SIM、SD、microSD、金融PBOC卡等不同卡片物理形态的多应用管理；可针对不同通讯通道(SMS、GPRS、BIP)的个人化指令的上下行；因此，本申请具有好的灵活性；

由于本申请可以通过HTTP连接或者FTP连接或者SOCKET连接等连接方式建立到个人化机构的通信；这样，欲增加不同行业领域的个人化机构时，只需建立到新的个人化机构的通信通道即可，因此，本申请具有好的扩展性。

附图说明

图1是本申请一种智能卡个人化数据的处理方法实施例的流程图；

图2是本申请一种透传处理APDU指令的时序图示例；

图3是本申请一种组装处理APDU指令的时序图示例；

图4是本申请一种数据处理系统的结构示意图；

图5是图4所示数据处理系统的工作时序图示例；

图6是本申请一种智能卡个人化数据的处理系统实施例的结构图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

本申请实施例的核心构思之一在于，提供一种通用的、能够针对不同行业领域的不同格式的智能卡个人化数据进行处理的技术方案，具体而言，若所述智能卡个人化数据的格式为指令格式，则对所述智能卡个人化数据进行透传处理；若所述智能卡个人化数据的格式为非指令格式，则依据所述智能卡个人化数据组装相应的个人化指令。

参照图1，示出了本申请一种智能卡个人化数据的处理方法实施例的流程图，具体可以包括：

步骤101、依据智能卡个人化数据的格式，对相应的智能卡个人化数据进行处理，所述处理可以进一步包括：

本申请可以用于不同行业领域(如金融、通信、交通等)的智能卡个人化数据进行处理。在实际中，这些行业领域的个人化机构(如个人化中心或者卡管系统)是智能卡个人化数据的来源和提供者，它们既可以提供指令格式的智能卡个人化数据，如APDU指令等；也可以提供非指令格式的智能卡个人化数据，如包含应用个人化信息的XML文件、TXT文件，或者DGI分组数据等。本申请的宗旨在于通过对指令格式和非指令格式的智能卡个人化数据进行各自的处理，以提高智能卡个人化数据处理的通用性，而不会对具体的智能卡个人化数据加以限制。

在本申请实施例中，优选的是，所述指令格式为APDU格式，所述指令为APDU指令。本申请对具体的指令和指令格式不加以限制。

步骤111、若所述智能卡个人化数据的格式为指令格式，则对所述智能卡个人化数据进行透传处理；

在所述智能卡个人化数据的格式为指令格式时，采取透传处理策略。透传处理策略的原理是透明传送，不管传输的业务如何，只负责将需要传送的业务传送到目的节点，同时保证传输的质量即可，而不对传输的业务进行处理。在具体实现中，所述透传处理主要负责建立通道，接收个人化机构传送的个人化指令，并保证各指令以正常序列发送给智能卡。

在本申请的一种优选实施例中，所述透传处理可以进一步包括：

子步骤A1、接收来自智能卡的个人化请求；

子步骤A2、依据所述个人化请求，创建与相应个人化机构的通道；

子步骤A3、向所述个人化机构发送连接请求，并依据所述个人化机构对所述连接请求的响应建立到所述个人化机构的连接；

子步骤A4、向所述个人化机构发送个人化数据请求；

子步骤A5、接收所述个人化机构返回的个人化指令；

本优选实施例在智能卡发送个人化申请请求时，实时向个人化机构请求数据，由个人化中心返回个人化指令。

为了保证各通道的隔离性，在实际应用中，本申请可以通过SOCKET(套接字)长连接形式建立与所述个人化机构的通信；当然，为了高效率，可能会建立多个SOCKET连接，但是各个连接之间的通信是独立的。

由于在建立SOCKET连接时，个人化机构会有用户验证的过程，同时，两者交互的关键数据可以采取加密处理，故本申请也能够保证各通道的安全性。

当然除了SOCKET连接方式外，与个人化机构的连接方式还可以包括HTTP(超文本传输协议，HyperText Transfer Protocol)连接或者FTP(文件传输协议，File Transfer Protocol)连接等，本申请对具体的与个人化机构的连接方式不加以限制。

子步骤A6、对所述个人化指令进行校验，对校验通过的个人化指令进行组织，并将组织完成的个人化指令下发给智能卡。

在实际应用中，本申请与智能卡之间可以通过Internet(因特网)、SMS(短消息服务short message services)、GSM(全球移动通讯系统，globalsystem for mobile communications)或者GPRS(通用分组无线服务技术，General Packet Radio Service)等通讯方式中的一者进行通讯，本申请对针对智能卡的具体通讯方式不加以限制。

在本申请的另一种优选实施例中，所述对个人化指令进行校验的步骤，可以进一步包括如下校验方式中的一种或多种：

校验方式1、校验所述个人化指令的报文完整性；

所述报文完整性检验能够进一步保证本申请透传处理的安全性。例如，APDU指令通常包括一个必备的4字节的指令头(CLA、INS、P1、P2)和一个可选的可变长度的数据体(Lc、Data、Le)，表1示出了一种APDU指令的示例。

表1

校验方式2、判断一组个人化指令是否结束；

校验方式3、校验一条个人化指令的长度是否符合规定。

由于最终的APDU指令还需要借助通讯通道下发至智能卡，对于某些通讯通道，如SMS通道对传输长度有限制，因此，在下发前还需要校验每条APDU指令的长度。

在本申请的再一种优选实施例中，所述对个人化指令进行组织的步骤，可以进一步包括：

依据智能卡所符合的管理协议规范或者通讯通道所规定的数据字段长度，对所述个人化指令进行分组；

依次将各组个人化指令下发至智能卡。

在实际应用中，个人化机构返回的不是一条APDU指令，而是多条APDU指令，例如：

对于数据量较大的个人化指令，将多条APDU指令下发至智能卡并不是明智之举，故为了提高传输的安全性和准确性，本优选实施例组织其中的一部分下发给智能卡(如长度小于1K)。但是，组织的时候，必须保证正常序列传送，即发送的次序必须按照个人化中心提供的APDU次序发送。另外，需要注意的是，每条APDU是最小的下发单元，不能分割。

在采用透传处理下发个人化指令后，本申请还可以同样透传处理智能卡返回的的执行结果。透传处理执行结果的一个例子可以是，直接把执行结果生成与个人化机构通信的报文，并上报给个人化机构。

在本申请的一种优选实施例中，本申请还可以处理过程中的异常情况，相应地，所述处理还可以包括如下情形中的一种或多种：

在与个人化机构的连接断开时，重新向所述个人化机构发送连接请求；或者，

在校验不通过时，重新向所述个人化机构发送个人化数据请求；或者，

在执行所述透传处理的过程中出现异常时，抛出错误，并记录错误日志。

为使本领域技术人员更好地理解本申请，本申请可以将上述透传处理的方法流程集成在数据处理系统中，参照图2，示出了本申请一种透传处理APDU指令的时序图示例，具体可以包括；

步骤1、接收来自智能卡的个人化请求；

步骤2、依据所述个人化请求，创建与相应个人化中心/卡管的通道；

步骤3、向所述个人化中心/卡管发送连接请求；

步骤3.1、依据所述个人化中心/卡管对所述连接请求的响应建立到所述个人化中心/卡管的连接；

步骤4、向所述个人化中心/卡管请求个人化数据；

步骤4.1、接收所述个人化机构返回的个人化APDU指令组；

步骤5、校验并组织所述个人化APDU指令组；

步骤6、依次向智能卡发送APDU指令；

步骤6.1、智能卡执行APDU指令；

步骤6.2、智能卡返回执行结果；

步骤6.2.1、处理智能卡返回的执行结果；

步骤6.2.2、向所述个人化中心/卡管返回处理结果。

步骤112、若所述智能卡个人化数据的格式为非指令格式，则依据所述智能卡个人化数据组装相应的个人化指令。

由于智能卡仅能执行指令格式的数据也即个人化指令，故在个人化机构传送XML文件、TXT文件等文件或者DGI分组数据等智能卡个人化数据时，本申请对这些智能卡个人化数据进行组装处理。

前面提到，个人化机构是智能卡个人化数据的来源和提供者，在实际应用中，可以通过如下方式获取到组装处理所用到的智能卡个人化数据：

获取方式1、

获取方式1的原理与透传处理获取智能卡个人化数据的原理相似，也是，在智能卡发送个人化申请请求时，实时向个人化机构请求数据；也即，执行子步骤A1-子步骤A5，不过不同的是，个人化机构返回的是个人化数据文件或者DGI组；然后对这些个人化数据文件或者DGI组进行组装处理。

获取方式2、

获取方式2的原理是，个人化机构主动传送智能卡个人化数据(文件或者DGI组)，所述传送方式可以是FTP、SOCKET、HTTP等方式。在传送完毕后，可以保存所述智能卡个人化数据，然后，在智能卡发送个人化申请请求时取出保存的智能卡个人化数据，进行相应的组装处理。

在本申请的一种优选实施例中，所述依据所述智能卡个人化数据组装相应的个人化指令的步骤，可以进一步包括：

依据所述智能卡个人化数据，组织得到数据分组标识数据；

将所述数据分组标识数据转换为个人化指令。

优选的，所述依据所述智能卡个人化数据，组织得到数据分组标识数据的步骤，可以进一步包括：

从所述智能卡个人化数据中解析出类型长度值数据；

依据数据分组标识原则，将所述类型长度值数据重组为数据分组标识数据。

数据通信领域中，报文的可选信息往往以TLV(类型长度值数据，type-length-value)字段形式出现，其中，T、L字段的长度往往固定(通常为1～4bytes)，V字段长度可变；也即，T字段表示报文类型，L字段表示报文长度、V字段往往用来存放报文的内容。

由于智能卡个人化数据的最小单元是TLV格式，无论是XML文件、TXT文件，还是DGI分组，都可以解析分割出TLV数据。在解析完成后，可以根据用户的卡商代码及智能卡卡商所制定的DGI分组规则进行TLV数据的重组，通常地，DGI分组规则可以包括：分组标识+加密标识+所含TAG(标签)组+应用场景标识(如移动SIM(客户识别模块，Subscriber IdentityModule)，金融借记，金融贷记等)。

在本申请的再一种优选实施例中，所述将所述数据分组标识数据转换为个人化指令的步骤，可以进一步包括：

依据智能卡所符合的管理协议规范，通过填充字段方式将所述数据分组标识数据组织为相应的个人化指令。

参照表2，示出了本申请一种管理协议规范的数据格式示例。

表2

所述填充字段方式的原理主要是依据所述数据分组标识数据对管理协议规范的格式的数据格式中的各字段进行赋值，并组织给个人化(APDU)指令的过程。以表2为例，可以为CLA字段赋值“84”，为INS字段赋值“E2；另外，P1，P2的值也需要根据具体的数据分组标识数据来确定和填充。本申请对具体的管理协议规范的格式的数据格式中各字段值的确定方式和填充方式不加以限制。

在采用组装处理下发个人化指令后，本申请还可以处理智能卡返回的的执行结果，例如，可以直接把执行结果生成与个人化机构通信的报文，并上报给个人化机构。

在本申请实施例中，与个人化机构的连接方式可以包括HTTP连接或者FTP连接或者SOCKET连接等。

在本申请的一种优选实施例中，本申请还可以处理过程中的异常情况，相应地，所述处理还可以包括如下情形中的一种或多种：

在与个人化机构的连接断开时，重新向所述个人化机构发送连接请求；或者，

在校验不通过时，重新向所述个人化机构发送个人化数据请求；或者，

在执行所述透传处理的过程中出现异常时，抛出错误，并记录错误日志。

其中，所述重新向所述个人化机构发送连接请求或者个人化数据请求，均是针对智能卡个人化数据的获取方式1而言的，在实际中，本领域技术人员可以灵活使用。

为使本领域技术人员更好地理解本申请，本申请可以将上述组装处理的方法流程集成在数据处理系统中，参照图3，示出了本申请一种组装处理APDU指令的时序图示例，具体可以包括；

步骤1、接收个人化中心/卡管传送的智能卡个人化数据(文件/DGI分组数据)；

步骤1.1、将所述智能卡个人数据转换为通用的DGI分组数据；

步骤1.2、依据所述通用的DGI分组数据，生成并组装APDU指令组；

步骤1.3、依次发送APDU指令；

步骤1.3.1、智能卡执行APDU指令；

步骤1.3.2、智能卡返回执行结果；

步骤1.3.2.1、智能卡对所述执行结果进行处理；

步骤1.3.2.2、智能卡向个人化中心/卡管返回处理结果。

总之，本申请具有如下优点：

1、相对于现有技术只能适用于特定独有的行业领域，并不具有通用性的缺点，本申请能够针对不同行业领域的不同格式的智能卡个人化数据进行处理的技术方案，具体而言，若所述智能卡个人化数据的格式为指令格式，则对所述智能卡个人化数据进行透传处理；若所述智能卡个人化数据的格式为非指令格式，则依据所述智能卡个人化数据组装相应的个人化指令；因此，本申请能够针对不同行业领域的个人化机构进行无缝对接，具有各行业领域智能卡个人化数据处理的通用性；

2、本申请可适用于电信、金融、通信、交通等不同领域，适用于native卡、java卡、multos卡等不同智能卡种类，适用于SIM(用户身份识别模块，Subscriber Identity Module)、SD(安全数码卡，Secure Digital Memory Card)、microSD(快闪存储器卡)、金融PBOC(中国人民银行，The People′s Bank ofChina)卡等不同卡片物理形态的多应用管理；可针对不同通讯通道(SMS、GPRS、BIP)的个人化指令的上下行；因此，本申请具有好的灵活性；

3、由于本申请可以通过HTTP连接或者FTP连接或者SOCKET连接等连接方式建立到个人化机构的通信；这样，欲增加不同行业领域的个人化机构时，只需建立到新的个人化机构的通信通道即可，因此，本申请具有好的扩展性。

在实际应用中，可以将本申请的方法集成在数据处理系统中，参照图4，示出了本申请一种数据处理系统的结构示意图，其向上可以与不同领域(金融、通信、交通等行业)内的个人化中心/卡管建立通信连接，向下可以利用通道(GSM/GRPS/Internet等通道)将个人化指令传送给智能卡，具体可以包括：透传APDU指令通道401、组装APDU指令通道402、处理智能片返回的执行结果403和错误处理404。

为使本领域技术人员更好地理解本申请，下面通过图5的例子说明图4所示数据处理系统的工作时序图示例，具体可以包括：

步骤1、接收智能卡的个人化请求；

步骤2、判断智能卡的合法性；

步骤3、向个人化中心(金融/交通/电信等行业)请求个人化数据；

步骤4、接收个人化中心返回的个人化数据；

步骤5、判断个人化数据的格式，若为文件或DGI分组数据，则执行步骤6，若为APDU指令，则执行步骤7；

步骤6、组转(等同于前述的组装)APDU指令处理；

步骤7、透传APDU指令处理；

步骤8、向智能卡下发APDU指令；

步骤9、接收智能卡返回的指令执行结果；

步骤10、处理执行结果。

与前述方法实施例相应，本申请还公开了一种智能卡个人化数据的处理系统，其可用于依据智能卡个人化数据的格式，对相应的智能卡个人化数据进行处理，参照图6，所述系统具体可以包括：

透传处理模块601，用于在所述智能卡个人化数据的格式为指令格式时，则对所述智能卡个人化数据进行透传处理；

组装处理模块602，用于在所述智能卡个人化数据的格式为非指令格式时，则依据所述智能卡个人化数据组装相应的个人化指令。

在本申请实施例中，优选的是，所述指令格式可以为APDU格式，所述指令可以为APDU指令。

在本申请的一种优选实施例中，所述透传处理模块601可以进一步包括：

第一接收子模块，用于接收来自智能卡的个人化请求；

通道创建子模块，用于依据所述个人化请求，创建与相应个人化机构的通道；

第一发送子模块，用于向所述个人化机构发送连接请求；

连接建立子模块，用于依据所述个人化机构对所述连接请求的响应，建立到所述个人化机构的连接；

第二发送子模块，用于向所述个人化机构发送个人化数据请求；

第二接收子模块，用于接收所述个人化机构返回的个人化指令；

校验子模块，用于对所述个人化指令进行校验；

第一组织子模块，用于对校验通过的个人化指令进行组织；及

下发子模块，用于将组织完成的个人化指令下发给智能卡。

在本申请实施例中，优选的是，所述校验子模块可以进一步包括：

完整性校验单元，用于校验所述个人化指令的报文完整性；或者，

结束判断单元，用于判断一组个人化指令是否结束，或者，

长度校验单元，用于校验一条个人化指令的长度是否符合规定。

在本申请实施例中，优选的是，所述第一组织子模块可以进一步包括：

指令分组单元，用于依据智能卡所符合的管理协议规范或者通讯通道所规定的数据字段长度，对所述个人化指令进行分组；

所述下发子模块，具体用于依次将各组个人化指令下发至智能卡。

在本申请实施例中，优选的是，与个人化机构的连接方式可以包括HTTP连接或者FTP连接或者SOCKET连接。

在本申请实施例中，优选的是，所述系统还可以包括错误处理模块，可以进一步包括：

连接请求重发子模块，用于在与个人化机构的连接断开时，重新向所述个人化机构发送连接请求；或者，

个人化数据请求重发子模块，用于在校验不通过时，重新向所述个人化机构发送个人化数据请求；或者，

异常错误处理子模块，用于在执行所述透传处理的过程中出现异常时，抛出错误，并记录错误日志。

在本申请的另一种优选实施例中，所述组装处理模块602可以进一步包括：

第二组织子模块，用于依据所述智能卡个人化数据，组织得到数据分组标识数据；

转换子模块，用于将所述数据分组标识数据转换为个人化指令。

在本申请实施例中，优选的是，所述第二组织子模块可以进一步包括：

解析单元，用于从所述智能卡个人化数据中解析出类型长度值数据；

重组单元，用于依据数据分组标识原则，将所述类型长度值数据重组为数据分组标识数据。

在本申请实施例中，优选的是，所述转换子模块可以进一步包括：

填充组织单元，用于依据智能卡所符合的管理协议规范，通过填充字段方式将所述数据分组标识数据组织为相应的个人化指令。

对于系统实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

以上对本申请所提供的一种智能卡个人化数据的处理方法和系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (16)

1.一种智能卡个人化数据的处理方法，其特征在于，包括：

依据智能卡个人化数据的格式，对相应的智能卡个人化数据进行处理，所述处理包括：

若所述智能卡个人化数据的格式为指令格式，则对所述智能卡个人化数据进行透传处理；

若所述智能卡个人化数据的格式为非指令格式，则依据所述智能卡个人化数据组装相应的个人化指令。

2.如权利要求1所述的方法，其特征在于，所述透传处理包括：

接收来自智能卡的个人化请求；

依据所述个人化请求，创建与相应个人化机构的通道；

向所述个人化机构发送连接请求，并依据所述个人化机构对所述连接请求的响应建立到所述个人化机构的连接；

向所述个人化机构发送个人化数据请求；

接收所述个人化机构返回的个人化指令；

对所述个人化指令进行校验，对校验通过的个人化指令进行组织，并将组织完成的个人化指令下发给智能卡。

3.如权利要求1所述的方法，其特征在于，所述依据所述智能卡个人化数据组装相应的个人化指令的步骤，包括：

依据所述智能卡个人化数据，组织得到数据分组标识数据；

将所述数据分组标识数据转换为个人化指令。

4.如权利要求3所述的方法，其特征在于，所述依据所述智能卡个人化数据，组织得到数据分组标识数据的步骤，包括：

从所述智能卡个人化数据中解析出类型长度值数据；

依据数据分组标识原则，将所述类型长度值数据重组为数据分组标识数据。

5.如权利要求3所述的方法，其特征在于，所述将所述数据分组标识数据转换为个人化指令的步骤，包括：

依据智能卡所符合的管理协议规范，通过填充字段方式将所述数据分组标识数据组织为相应的个人化指令。

6.如权利要求2所述的方法，其特征在于，所述对个人化指令进行校验的步骤，包括：

校验所述个人化指令的报文完整性；或者，

判断一组个人化指令是否结束，或者，

校验一条个人化指令的长度是否符合规定。

7.如权利要求2所述的方法，其特征在于，所述对个人化指令进行组织的步骤，包括：

依据智能卡所符合的管理协议规范或者通讯通道所规定的数据字段长度，对所述个人化指令进行分组；

依次将各组个人化指令下发至智能卡。

8.如权利要求1至7中任一项所述的方法，其特征在于，所述智能卡包括如下智能卡种类中的一种或多种：native、java、multos；

所述智能卡包括如下卡片物理形态中的一种或多种：SIM、SD、microSD、金融PBOC。

9.一种智能卡个人化数据的处理系统，其特征在于，其用于依据智能卡个人化数据的格式，对相应的智能卡个人化数据进行处理，所述系统包括：

透传处理模块，用于在所述智能卡个人化数据的格式为指令格式时，则对所述智能卡个人化数据进行透传处理；

组装处理模块，用于在所述智能卡个人化数据的格式为非指令格式时，则依据所述智能卡个人化数据组装相应的个人化指令。

10.如权利要求9所述的系统，其特征在于，所述透传处理模块包括：

第一接收子模块，用于接收来自智能卡的个人化请求；

通道创建子模块，用于依据所述个人化请求，创建与相应个人化机构的通道；

第一发送子模块，用于向所述个人化机构发送连接请求；

连接建立子模块，用于依据所述个人化机构对所述连接请求的响应，建立到所述个人化机构的连接；

第二发送子模块，用于向所述个人化机构发送个人化数据请求；

第二接收子模块，用于接收所述个人化机构返回的个人化指令；

校验子模块，用于对所述个人化指令进行校验；

第一组织子模块，用于对校验通过的个人化指令进行组织；及

下发子模块，用于将组织完成的个人化指令下发给智能卡。

11.如权利要求9所述的系统，其特征在于，所述组装处理模块包括：

第二组织子模块，用于依据所述智能卡个人化数据，组织得到数据分组标识数据；

转换子模块，用于将所述数据分组标识数据转换为个人化指令。

12.如权利要求11所述的系统，其特征在于，所述第二组织子模块包括：

解析单元，用于从所述智能卡个人化数据中解析出类型长度值数据；

重组单元，用于依据数据分组标识原则，将所述类型长度值数据重组为数据分组标识数据。

13.如权利要求11所述的系统，其特征在于，所述转换子模块包括：

填充组织单元，用于依据智能卡所符合的管理协议规范，通过填充字段方式将所述数据分组标识数据组织为相应的个人化指令。

14.如权利要求10所述的系统，其特征在于，所述校验子模块包括：

完整性校验单元，用于校验所述个人化指令的报文完整性；或者，

结束判断单元，用于判断一组个人化指令是否结束，或者，

长度校验单元，用于校验一条个人化指令的长度是否符合规定。

15.如权利要求10所述的系统，其特征在于，所述第一组织子模块包括：

指令分组单元，用于依据智能卡所符合的管理协议规范或者通讯通道所规定的数据字段长度，对所述个人化指令进行分组；

所述下发子模块，具体用于依次将各组个人化指令下发至智能卡。

16.如权利要求9至15中任一项所述的系统，其特征在于，所述智能卡包括如下智能卡种类中的一种或多种：native、java、multos；

所述智能卡包括如下卡片物理形态中的一种或多种：SIM、SD、microSD、金融PBOC。

Images