CN105812370A - 智能卡处理方法、装置及系统 - Google Patents

Abstract

本发明提供一种智能卡处理方法、装置及系统，通过接收终端发送的智能卡认证请求，智能卡认证请求中包含终端内智能卡的属性信息以及智能卡的注册文件信息；根据属性信息对智能卡的注册文件信息进行鉴权，若鉴权不通过，则转发智能卡认证请求到TSM平台进行鉴权，以使TSM平台对智能卡进行鉴权，鉴权通过后向终端反馈认证响应消息；接收终端发送的智能卡业务请求，智能卡业务请求中包含：业务请求的类型；根据业务请求的类型，获取与业务请求的类型相对应的处理信息，并向终端反馈处理信息。从而实现了对智能卡的注册、鉴权，注册后的智能卡通过智能卡处理装置或TSM平台实现多类型的业务处理，提高了智能卡的资源利用率。

Description

智能卡处理方法、装置及系统

技术领域

本发明涉及智能卡技术，尤其涉及一种智能卡处理方法、装置及系统。

背景技术

随着网络技术的发展，移动终端越来越成为人们日常生活的必备装备。

移动终端内的智能卡作为IC卡的一种，其内集成有电路芯片，具备存储和运算能力，内置加密运算协处理器和安全逻辑，具备安全控制能力。相较于移动终端的安全性更高，同时，智能卡成本低，可重复利用，可个性化定制，其所具备的操作系统，可用于安装多种应用，实现一卡多用。然而，现有技术中智能卡却仅仅被作为电信通讯过程中对用户身份进行识别的识别卡，智能卡内的应用的安装和发行是由运营商发卡预制，用户对智能卡的可操作性不高。

综上，目前的智能卡功能单一，利用率不高。亟需利用智能卡的安全性能针对智能卡开发并管理更多的智能卡应用功能。

发明内容

本发明的智能卡处理方法、装置及系统，用以实现对智能卡的注册、鉴权和处理，以使注册后的智能卡可以通过智能卡处理装置或TSM平台获得应用下载、应用管理等丰富的应用功能，充分利用智能卡资源。

根据本发明实施例的第一方面，提供一种智能卡处理方法，包括：

接收终端发送的智能卡认证请求，所述智能卡认证请求中包含所述终端内智能卡的属性信息以及所述智能卡的注册文件信息；所述属性信息以及所述智能卡的注册文件信息为所述终端在预设触发条件下，向所述智能卡发送属性信息获取请求获取到的；

根据所述属性信息对所述智能卡的注册文件信息进行鉴权，若鉴权不通过，则转发所述智能卡认证请求到TSM平台进行鉴权，以使所述TSM平台对所述智能卡进行鉴权，鉴权通过后向所述终端反馈认证响应消息；

接收所述终端发送的智能卡业务请求，所述智能卡业务请求中包含：业务请求的类型；

根据所述业务请求的类型，获取与所述业务请求的类型相对应的处理信息，并向所述终端反馈所述处理信息。

根据本发明实施例的第二方面，提供一种智能卡处理装置，包括：

接收模块，用于接收终端发送的智能卡认证请求，所述智能卡认证请求中包含所述终端内智能卡的属性信息以及所述智能卡的注册文件信息；所述属性信息以及所述智能卡的注册文件信息为所述终端在预设触发条件下，向所述智能卡发送属性信息获取请求获取到的；

鉴权模块，用于根据所述属性信息对所述智能卡的注册文件信息进行鉴权，若鉴权不通过，则转发所述智能卡认证请求到TSM平台进行鉴权，以使所述TSM平台对所述智能卡进行鉴权，鉴权通过后向所述终端反馈认证响应消息；

所述接收模块，还用于接收所述终端发送的智能卡业务请求，所述智能卡业务请求中包含：业务请求的类型；

处理模块，用于根据所述业务请求的类型，获取与所述业务请求的类型相对应的处理信息，并向所述终端反馈所述处理信息。

根据本发明实施例的第三方面，提供一种智能卡处理系统，包括上述任一项所述的智能卡处理装置；还包括：TSM平台、终端、智能卡；

所述智能卡设置在所述终端内；所述终端内安装有用于对所述智能卡进行操作的客户端；所述TSM平台与所述智能卡处理装置连接，以使所述终端通过所述智能卡处理装置接收所述TSM平台对所述智能卡的鉴权处理或者业务请求处理。

本发明的实施例所提供的技术方案可以包括以下有益效果：

通过接收终端发送的智能卡认证请求，智能卡认证请求中包含终端内智能卡的属性信息以及智能卡的注册文件信息；属性信息以及智能卡的注册文件信息为终端在预设触发条件下，向智能卡发送属性信息获取请求获取到的；根据属性信息对智能卡的注册文件信息进行鉴权，若鉴权不通过，则转发智能卡认证请求到TSM平台进行鉴权，以使TSM平台对智能卡进行鉴权，鉴权通过后向终端反馈认证响应消息；接收终端发送的智能卡业务请求，智能卡业务请求中包含：业务请求的类型；根据业务请求的类型，获取与业务请求的类型相对应的处理信息，并向终端反馈处理信息。从而实现了对智能卡的注册、鉴权，注册后的智能卡通过智能卡处理装置或TSM平台实现多类型的业务处理，提高了智能卡的资源利用率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本发明。

附图说明

图1是根据一示例性实施例示出的一种智能卡处理方法的流程图；

图2是根据另一示例性实施例示出的一种智能卡处理方法的流程图；

图3是根据一示例性实施例示出的一种智能卡处理装置的框图；

图4是根据另一示例性实施例示出的一种智能卡处理装置的框图；

图5是根据一示例性实施例示出的一种智能卡处理系统的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

图1是根据一示例性实施例示出的一种智能卡处理方法的流程图。如图1所示，本实施例的智能卡处理方法可以应用于由终端、智能卡、智能卡处理装置(平台)，还可以包括第三方应用服务器(平台)，共同构成对智能卡进行应用处理、应用管理的系统，该系统实现了电信智能卡为主要载体的应用管理为用户提供卡应用相关的管理，提供智能卡“卡应用”下载与应用管理等支撑能力，实现智能卡能力的开放和对提供第三方应用的合作伙伴的管理。该系统实现了通过在终端内安装智能卡客户端，实现对智能卡应用的下载、安装、实例化、个人化流程，并且将该能力通过开放接口的方式提供给第三方，如移动互联网和行业应用；该系统一方面向终端用户提供智能卡应用管理入口，另一方面面向合作伙伴(包括移动互联网和行业应用)提供智能卡能力调用。此系统可以实现对智能卡的空间管理，对来自移动互联网、行业应用的卡应用进行安全管控，下载、安装、实现统一的安全访问控制。

首先介绍一下该系统的主要组成部分的功能，该智能卡处理装置可以包括智能卡应用下载及智能卡应用管理功能；卡应用客户端可以安装于装载智能卡的终端内，该系统可以提供双模下载管理的工作方式，以满足不同卡应用的业务需求。其中，智能卡处理装置主要负责智能卡应用的下载与应用管理等支撑工作，实现智能卡业务的接入与管理，同时兼具智能卡业务的推广功能。其中，对于智能卡应用下载功能的实现从以下几个方面进行说明：智能卡处理装置可以包括：应用下载模块，该模块可以实现以下功能，1、应用呈现，接收智能卡客户端请求，提供应用的信息。应用信息包括：应用名称、应用介绍、应用图标、应用对应的APK信息(下载地址、包名等)；2、应用列表，接受客户端请求，根据上报的用户或卡标识反馈可下载应用列表、已下载应用列表；此处需要和Java卡平台同步应用数据，包括从Java卡平台获取可供智能卡用户下载的智能卡全部应用列表和信息。3、应用下载安装及管理,接受客户端请求，根据请求信息下载卡应用，删除、更新卡应用，创建安全域删除安全域，卡应用的实例化和个人化。智能卡处理装置还可以包括：密钥管理模块，该模块可以实现以下功能，1、卡片密钥管理，负责卡应用下载、平台接口和业务管理中所需密钥的生成与加密存储。2、安全算法管理，提供卡片应用下载等业务流程中所需加解密算法，包括但不限于3DES、RSA1024、SHA-1等算法。智能卡处理装置还可以包括：对智能卡客户端的管理模块，负责智能卡应用客户端的接入管理，包括客户端注册、接入合法性检测、客户端状态管理、客户端版本管理等。智能卡处理装置还可以包括：智能卡应用管理模块，该模块可以实现以下功能，智能卡应用管理包括应用信息管理、应用状态管理、安全域配置管理和接口权限管理，覆盖从配置到测试的整个业务流程的管理。应用管理模块功能与应用下载模块功能相对应，根据卡应用下载模式的不同，采取相应的应用管理模式。其中，应用信息管理：应用信息应包括但不限于应用名称、应用版本、应用状态、应用类别、业务范围、上/下线时间、应用归属、所属安全域等内容。应用信息由智能卡处理装置统一管理，并同步到外部对接管理平台或系统。用户可对应用信息进行查看。应用状态管理：应用状态应包括但不限于待审核、待测试、待发布、已发布、暂停下载、暂停使用和已下线等。应用状态属于平台自有信息，由平台生成和管理。平台业务管理员具有更改应用状态的权限。应用状态的图表如表1所示，表1中的平台指云端智能卡处理装置平台，合作伙伴为第三方应用的提供方。安全域配置管理：实现卡内主安全域以及辅助安全域的配置和管理。主安全域仅由平台管理员直接配置，其他用户或合作伙伴无权配置。辅助安全域根据其业务属性可选对用户开放，在允许范围内可见。接口权限管理：智能卡处理装置业务管理员以“应用”为单位，配置第三方应用的合作伙伴通过接口操作该应用的权限，包括：能否发起应用下载请求、能否发起应用删除请求、能否发起配置应用状态/应用版本请求，应用个人化请求等。

表1、应用状态表

智能卡处理装置还提供双模工作模块，涉及两种工作模式分别为托管模式以及透传模式，根据卡应用的安全等级等属性的不同，应用下载功能角色各有不同。双模工作方式在兼容传统业务的同时，能满足新应用业务的需求，适用性更广，系统更完善，能够实现卡能力及卡业务的开放共享。其中，托管模式下，智能卡处理装置功能角色为二级TSM业务聚合平台，实现卡内辅助安全域创建和管理，并完成卡应用数据打包、业务触发、维护等工作。卡应用可直接上传至智能卡处理装置，由智能卡处理装置进行卡应用数据的的处理、维护，以及卡应用的卡内辅助安全域的创建和管理。创建辅助安全域需得到来自原智能卡管理平台的授权(安全支撑)。新的卡应用上传或原有卡应用变更时，智能卡处理装置需通知原有卡管理平台，并将更新后的卡应用列表同步到原有卡管理平台。该模式工作过程中，在保证通信安全的同时，将卡应用与原有卡管理平台系统隔离拉远，降低了原有平台的系统负荷和资源占用同时，提高了系统的安全性，降低了运营风险和准入门槛。适用于安全性相对较低、合作关系相对简单的卡应用业务。透传模式下，卡应用直接上传至智能卡处理装置，由智能卡处理装置进行卡应用数据的的处理、维护，以及卡应用的卡内辅助安全域的创建和管理；卡应用下载管理平台以营业厅仿真模式接入现有智能卡管理平台，模拟电信营业厅POS机的工作完成读卡、写卡、指令透传等工作，对传送的应用数据包不作处理，黑盒透传。新的卡应用上传或原有卡应用变更时，原有平台需通知智能卡处理装置，并将更新后的卡应用列表同步到智能卡处理装置。该模式适用于安全性要求较高，合作关系相对复杂的卡应用业务。这种模式下卡应用的发行方和运营方可以独立管理该卡应用所在的安全域。例如，卡应用由其接入的智能卡处理装置根据卡应用属性进行分类保存，并创建访问下载标识，用以区分应用的下载平台，如归属原有卡管理平台的卡应用(下载)标识为一级，归属智能卡处理装置的卡应用(下载)标识为二级。当用户请求安装下载卡应用时，(下载)标识为一级的卡应用将选择透传工作模式，系统从原有卡管理平台下载并安装卡应用，(下载)标识为二级的卡应用将选择二级TSM平台工作模式，系统从卡应用下载管理平台下载并安装卡应用。当有新的卡应用上传或原有卡应用变更时，所在平台应更新本地卡应用列表，并通知对接管理平台，对接平台将同步更新。卡应用(下载)标识可选对用户可见。

对于实现智能卡应用管理功能，智能卡处理装置主要负责智能卡能力的接入和部署，主要包括卡能力的内部部署应用和外部分发交互、卡内数据和能力的安全访问控制、用户数据的同步和管理等。智能卡处理装置可以包括：1、内部能力部署模块，该模块可以实现以下功能，智能卡上能力的内部管理和部署，如敏感信息的安全存储，卡上数据的保护保密及安全访问，安全模块的加解密算法及秘钥管理等。内部能力部署模块使得卡内空间及卡能力的管理更为合理有效。2、能力开放网关，负责面向业务平台(智能卡应用业务平台和外部业务平台)开发智能卡机卡通信功能和智能卡能力调用功能。3、安全访问控制，负责对卡上数据及应用的安全访问控制。智能卡的安全性和保密性在其使用过程中至关重要，卡上操作系统通过卡上安全模块和安全算法对卡上数据及应用对应的“文件”系统进行保护，实现外部对卡内数据及应用的安全访问控制。4、数据管理与同步，数据管理与同步主要负责智能卡数据的本地管理及其与外部对接平台或系统的数据同步。智能卡数据又分为应用数据、业务数据和用户数据，其中用户数据又包括卡应用开发者用户数据以及卡应用使用者用户数据。智能卡相关数据可选按照预设数据属性分类进行保存，需与外部对接平台或系统保持同步，可选通过主被动方式对智能卡数据进行实时同步或定期同步。

对于卡应用客户端，智能卡应用客户端安装在用户移动终端，主要包括用户自服务管理，如注册、修改、查看、注销等；还包括对应的卡应用业务相关的卡、终端应用管理，如应用的下载、安装、删除、更新等。智能卡应用客户端通过终端内部机卡通道OMAPI与智能卡进行交互，通过外部接口与智能卡处理装置进行对接，共同完成用户的注册、登录、查询、交易等行为指令，并将所得结果以人机界面的形式显示于用户终端，使得人卡交互更为可视化、人性化，更具可操作性。智能卡应用客户端的行为指令应同步更新到相应对接平台，如用户信息、卡应用版本变更等应同步到智能卡处理装置的对应用户数据库中，各终端、平台及其他业务节点的智能卡应用相关数据应保持同步。

以下以应用于智能卡处理装置中来举例说明业务流程，本实施例提供的智能卡处理方法具体包括如下步骤：

步骤101、接收终端发送的智能卡认证请求。

具体的，智能卡认证请求中包含终端内智能卡的属性信息以及智能卡的注册文件信息；其中，属性信息以及智能卡的注册文件信息为该终端在预设触发条件下，向智能卡发送属性信息获取请求获取到的。

步骤102、根据属性信息对智能卡的注册文件信息进行鉴权，若鉴权不通过，则转发智能卡认证请求到TSM平台进行鉴权，以使TSM平台对智能卡进行鉴权，鉴权通过后向终端反馈认证响应消息。

步骤103、接收终端发送的智能卡业务请求，智能卡业务请求中包含：业务请求的类型。

步骤104、根据业务请求的类型，获取与业务请求的类型相对应的处理信息，并向终端反馈处理信息。

综上所述，本实施例提供的智能卡处理方法，通过接收终端发送的智能卡认证请求，智能卡认证请求中包含终端内智能卡的属性信息以及智能卡的注册文件信息；属性信息以及智能卡的注册文件信息为终端在预设触发条件下，向智能卡发送属性信息获取请求获取到的；根据属性信息对智能卡的注册文件信息进行鉴权，若鉴权不通过，则转发智能卡认证请求到TSM平台进行鉴权，以使TSM平台对智能卡进行鉴权，鉴权通过后向终端反馈认证响应消息；接收终端发送的智能卡业务请求，智能卡业务请求中包含：业务请求的类型；根据业务请求的类型，获取与业务请求的类型相对应的处理信息，并向终端反馈处理信息。从而实现了对智能卡的注册、鉴权，注册后的智能卡通过智能卡处理装置或TSM平台实现多类型的业务处理，提高了智能卡的资源利用率。

图2是根据另一示例性实施例示出的一种智能卡处理方法的流程图。如图2所示，在上述实施例的基础上，本实施例提供的智能卡处理方法具体包括如下步骤：

步骤201、接收终端发送的智能卡认证请求。

具体的，智能卡认证请求中包含终端内智能卡的属性信息以及智能卡的注册文件信息；其中的属性信息包含以下至少一项：ICCID、IMSI。属性信息以及智能卡的注册文件信息为该终端在预设触发条件下，向智能卡发送属性信息获取请求获取到的。该预设触发条件包含以下至少一种：终端自启动、用户触发智能卡认证指令、智能卡服务器推送认证邀请。其中，预设触发条件可能的情景包括但不限于，用户激活终端内安装的智能卡应用的客户端，开机自启动，点击应用客户端运行认证请求，智能卡客户端后台恢复等情况。具体流程可以为，由终端内的智能卡客户端通过客户端的应用接口API或者向智能卡发送APDU指令，以取得智能卡的ICCID、IMSI等号码信息，以及该智能卡的注册文件等数据，注册文件信息可以包括用户名、密码等表征智能卡身份的注册数据。该认证请求(User_Auth_Req，Level＝0/1)的具体格式可以为表2所示。

表2、认证请求消息(User_Auth_Req)

步骤202、根据属性信息对智能卡的注册文件信息进行鉴权，若鉴权不通过，则转发智能卡认证请求到TSM平台进行鉴权，以使TSM平台对智能卡进行鉴权，鉴权通过后向终端反馈认证响应消息。

具体的，智能卡处理装置(平台)收到智能卡认证请求后，会进行鉴权操作，该鉴权操作分为内部鉴权：查询智能卡处理装置(平台)内部数据库；或者外部鉴权：当内部鉴权失败时，智能卡处理装置向TSM平台查询智能卡的注册文件信息。鉴权通过后，智能卡处理装置(平台)可以将用户的码号信息返回给终端内的智能卡应用客户端，该认证响应消息(User_Auth_Resp)的具体格式可以为表3所示。

表3、认证响应消息(User_Auth_Resp)

此外，若用户的智能卡卡片首次认证或用户换卡等情况，则智能卡应用客户端还可以发起卡片信息同步操作请求，以从智能卡处理装置(平台)处获取卡片空间等信息。

步骤203、接收终端发送的智能卡业务请求，智能卡业务请求中包含：业务请求的类型。

具体的，业务请求的类型包含以下至少一项：应用查询请求；应用详情查询请求；应用删除请求、应用下载请求、应用锁定请求、应用解锁请求、应用升级请求、OAT应用个人化请求、OAT信息同步请求、OTA写卡请求。

业务请求的类型为应用查询请求，执行步骤204～步骤205；

业务请求的类型为应用详情查询请求，相应的，智能卡业务请求中还包含：待查询应用的标识，执行步骤206。

步骤204、根据应用查询请求，获取智能卡的应用列表信息。

步骤205、向终端反馈应用列表信息。

其中，应用列表信息包含：已下载的应用列表，和/或允许智能卡下载的应用列表。其中，终端内的智能卡应用客户端可以向智能卡处理装置(平台)发起应用查询请求(Applet_List_Req)，请求中还可以根据参数选择查询“可下载应用列表”，和/或“已下载应用列表”。该应用查询请求(Applet_List_Req)的格式请参见表4所示。相应的，智能卡处理装置向终端反馈的应用列表信息的响应消息(Appet_List_Resp)的格式如表5所示。

表4、业务请求的类型为应用查询请求(Applet_List_Req)

表5、应用列表信息的响应消息(Appet_List_Resp)

步骤206、根据待查询应用的标识，查询与待查询应用标识对应的应用的详情信息，并向终端反馈详情信息。

其中，详情信息包含：应用版本、应用类型、应用大小、应用客户端下载信息。具体的，终端内的智能卡应用客户端可以向智能卡处理装置(平台)发起应用详情查询请求(Appet_Info_Req)，请求中需要携带待查询应用的标识，即应用的AID标识。应用详情查询请求(Appet_Info_Req)的具体格式可以参考表5所示。

表5、业务请求的类型为应用详情查询请求(Appet_Info_Req)

相应的，向终端反馈的详情信息的应用详情查询结果(Appet_Info_Resp)的格式如表6所示。

表6、应用详情查询结果(Appet_Info_Resp)

进一步地，在步骤203、接收终端发送的智能卡业务请求中，智能卡业务请求中包含：业务请求的类型，还可以包含：与业务请求的类型相关联的应用标识。相应的，在步骤203之后还可以包括：识别应用标识对应的应用的预设权限；若预设权限为托管DM模式，根据业务请求的类型，获取与业务请求的类型相对应的处理信息，并向终端反馈处理信息；若预设权限为TSM模式，向TSM平台发送业务请求，接收TSM平台根据业务请求的类型，获取与业务请求的类型相对应的处理信息，并将处理信息反馈给终端。

具体的，用户可以在终端上通过智能卡应用客户端发起相关的智能卡操作请求，请求中携带有业务请求的类型，以及若该业务请求关联到具体的应用，则还需要携带有相应的应用标识，该智能卡业务请求(Card_APDU_Req)的格式可以如表7所示。

表7、智能卡业务请求(Card_APDU_Req)

智能卡处理装置(平台)进行智能卡业务请求的处理，识别应用标识对应的应用的预设权限；若预设权限为托管DM模式，根据业务请求的类型，获取与业务请求的类型相对应的处理信息，并向终端反馈处理信息；若预设权限为TSM模式，向TSM平台发送业务请求，接收TSM平台根据业务请求的类型，获取与业务请求的类型相对应的处理信息，并将处理信息反馈给终端。即进行a)内部处理：判断是否执行DM应用下载流程，否则执行外部处理；b)外部处理：智能卡处理装置(平台)向TSM平台发起智能卡业务请求。TSM平台受理业务请求后，则向智能卡处理装置(平台)发起APDU透传请求，智能卡处理装置(平台)收到TSM平台APDU透传请求后，向终端即智能卡应用客户端返回与业务请求的类型相对应的处理信息(Card_APDU_Resp)，其中包括：APDU_List、APDU序号、指令及期望SW(状态字)等信息，以使智能卡应用客户端依据APDU_List的指令顺序，向智能卡卡片发起写卡操作，获取卡片响应数据(R-APDU)，同时对比预期SW；智能卡应用客户端执行完全部APDU指令或任一一条APDU指令执行结果与预期不符时，将再次向智能卡处理装置(平台)发起APDU获取请求(Card_APDU_Req)，请求中将携带最后一条APDU(LastAPDU)的执行结果；智能卡处理装置(平台)再次收到智能卡APP的APDU获取请求后，会将LastAPDU执行结果返回给TSM平台；TSM平台若还有APDU发送，则会再发起APDU透传请求，智能卡处理装置(平台)则将APDU脚本集转换为APDUList返回给智能卡应用客户端(Card_APDU_Resp)，否则TSM平台直接返回智能卡的业务处理结果，智能卡处理装置(平台)对于智能卡应用客户端的响应(Card_APDU_Resp)中APDUList填空；智能卡应用客户端通过终端显示屏将业务处理结果向用户展示。其中，对智能卡业务请求的处理信息(Card_APDU_Resp)的格式可以如表8所示。

表8、对智能卡业务请求的处理信息(Card_APDU_Resp)

图3是根据一示例性实施例示出的一种智能卡处理装置的框图。如图3所示，该智能卡处理装置可以通过软件、硬件或者两者的结合实现成为电子设备的部分或者全部。本实施例提供的智能卡处理装置具体可以应用在智能卡处理方法中，以实现上述智能卡处理方法的各个步骤，其具体实现过程在此不再赘述。

该智能卡处理装置可以包括：

接收模块31，用于接收终端发送的智能卡认证请求，智能卡认证请求中包含终端内智能卡的属性信息以及智能卡的注册文件信息；属性信息以及智能卡的注册文件信息为终端在预设触发条件下，向智能卡发送属性信息获取请求获取到的。

鉴权模块32，用于根据属性信息对智能卡的注册文件信息进行鉴权，若鉴权不通过，则转发智能卡认证请求到TSM平台进行鉴权，以使TSM平台对智能卡进行鉴权，鉴权通过后向终端反馈认证响应消息。

接收模块31，还用于接收终端发送的智能卡业务请求，智能卡业务请求中包含：业务请求的类型。

处理模块33，用于根据业务请求的类型，获取与业务请求的类型相对应的处理信息，并向终端反馈处理信息。

综上所述，本实施例提供的智能卡处理装置，通过接收终端发送的智能卡认证请求，智能卡认证请求中包含终端内智能卡的属性信息以及智能卡的注册文件信息；属性信息以及智能卡的注册文件信息为终端在预设触发条件下，向智能卡发送属性信息获取请求获取到的；根据属性信息对智能卡的注册文件信息进行鉴权，若鉴权不通过，则转发智能卡认证请求到TSM平台进行鉴权，以使TSM平台对智能卡进行鉴权，鉴权通过后向终端反馈认证响应消息；接收终端发送的智能卡业务请求，智能卡业务请求中包含：业务请求的类型；根据业务请求的类型，获取与业务请求的类型相对应的处理信息，并向终端反馈处理信息。从而实现了对智能卡的注册、鉴权，注册后的智能卡通过智能卡处理装置或TSM平台实现多类型的业务处理，提高了智能卡的资源利用率。

图4是根据另一示例性实施例示出的一种智能卡处理装置的框图。如图4所示，在上述实施例的基础上，属性信息包含以下至少一项：ICCID、IMSI；预设触发条件包含以下至少一种：终端自启动、用户触发智能卡认证指令、智能卡服务器推送认证邀请。

进一步地，业务请求的类型包含以下至少一项：应用查询请求；应用详情查询请求；应用删除请求、应用下载请求、应用锁定请求、应用解锁请求、应用升级请求、OAT应用个人化请求、OAT信息同步请求、OTA写卡请求。

进一步地，还包括：业务请求的类型为应用查询请求，处理模块33，具体用于根据应用查询请求，获取智能卡的应用列表信息；向终端反馈应用列表信息；应用列表信息包含：已下载的应用列表，和/或允许智能卡下载的应用列表。

进一步地，还包括：业务请求的类型为应用详情查询请求；相应的，智能卡业务请求中还包含：待查询应用的标识；处理模块33，具体用于根据待查询应用的标识，查询与待查询应用标识对应的应用的详情信息；向终端反馈详情信息；详情信息包含：应用版本、应用类型、应用大小、应用客户端下载信息。

进一步地，智能卡业务请求中还包含：与业务请求的类型相关联的应用标识；相应的，该装置还包括：识别模块34，用于识别应用标识对应的应用的预设权限。

处理模块33包括：

第一处理子模块331，用于当预设权限为托管DM模式时，根据业务请求的类型，获取与业务请求的类型相对应的处理信息，并向终端反馈所述处理信息。

第二处理子模块332，用于当预设权限为TSM模式时，向TSM平台发送业务请求；接收TSM平台根据业务请求的类型，获取与业务请求的类型相对应的处理信息，并将处理信息反馈给终端。

本实施例的装置，可用于执行图2所示方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

图5是根据一示例性实施例示出的一种智能卡处理系统的结构示意图。如图5所示，该系统包括上述任一实施例的智能卡处理装置51；还包括：TSM平台52；终端53；智能卡54；智能卡54设置在终端53内；终端53内安装有用于对智能卡54进行操作的客户端；TSM平台52与智能卡处理装置51连接，以使终端53通过智能卡处理装置51接收TSM平台52对智能卡54的鉴权处理或者业务请求处理本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (13)

1.一种智能卡处理方法，其特征在于，包括：

接收终端发送的智能卡认证请求，所述智能卡认证请求中包含所述终端内智能卡的属性信息以及所述智能卡的注册文件信息；所述属性信息以及所述智能卡的注册文件信息为所述终端在预设触发条件下，向所述智能卡发送属性信息获取请求获取到的；

根据所述属性信息对所述智能卡的注册文件信息进行鉴权，若鉴权不通过，则转发所述智能卡认证请求到TSM平台进行鉴权，以使所述TSM平台对所述智能卡进行鉴权，鉴权通过后向所述终端反馈认证响应消息；

接收所述终端发送的智能卡业务请求，所述智能卡业务请求中包含：业务请求的类型；

根据所述业务请求的类型，获取与所述业务请求的类型相对应的处理信息，并向所述终端反馈所述处理信息。

2.根据权利要求1所述的方法，其特征在于，所述属性信息包含以下至少一项：ICCID、IMSI；所述预设触发条件包含以下至少一种：终端自启动、用户触发所述智能卡认证指令、智能卡服务器推送认证邀请。

3.根据权利要求1所述的方法，其特征在于，所述业务请求的类型包含以下至少一项：应用查询请求；应用详情查询请求；应用删除请求、应用下载请求、应用锁定请求、应用解锁请求、应用升级请求、OAT应用个人化请求、OAT信息同步请求、OTA写卡请求。

4.根据权利要求3所述的方法，其特征在于，还包括：所述业务请求的类型为所述应用查询请求，所述根据所述业务请求的类型，获取与所述业务请求的类型相对应的处理信息，并向所述终端反馈所述处理信息包括：

根据所述应用查询请求，获取所述智能卡的应用列表信息；

向所述终端反馈所述应用列表信息；所述应用列表信息包含：已下载的应用列表，和/或允许所述智能卡下载的应用列表。

5.根据权利要求3所述的方法，其特征在于，还包括：所述业务请求的类型为所述应用详情查询请求；相应的，所述智能卡业务请求中还包含：待查询应用的标识；所述根据所述业务请求的类型，获取与所述业务请求的类型相对应的处理信息，并向所述终端反馈所述处理信息包括：

根据所述待查询应用的标识，查询与所述待查询应用标识对应的应用的详情信息，并向所述终端反馈所述详情信息；所述详情信息包含：应用版本、应用类型、应用大小、应用客户端下载信息。

6.根据权利要求1所述的方法，其特征在于，所述智能卡业务请求中还包含：与所述业务请求的类型相关联的应用标识；相应的，所述根据所述业务请求的类型，获取与所述业务请求的类型相对应的处理信息，并向所述终端反馈所述处理信息之前，还包括：

识别所述应用标识对应的应用的预设权限；

相应的，所述根据所述业务请求的类型，获取与所述业务请求的类型相对应的处理信息，并向所述终端反馈所述处理信息包括：

若所述预设权限为托管DM模式，则根据所述业务请求的类型，获取与所述业务请求的类型相对应的处理信息，并向所述终端反馈所述处理信息；

若所述预设权限为TSM模式，则向所述TSM平台发送所述业务请求；

接收所述TSM平台根据所述业务请求的类型，获取与所述业务请求的类型相对应的处理信息，并将所述处理信息反馈给所述终端。

7.一种智能卡处理装置，其特征在于，包括：

接收模块，用于接收终端发送的智能卡认证请求，所述智能卡认证请求中包含所述终端内智能卡的属性信息以及所述智能卡的注册文件信息；所述属性信息以及所述智能卡的注册文件信息为所述终端在预设触发条件下，向所述智能卡发送属性信息获取请求获取到的；

鉴权模块，用于根据所述属性信息对所述智能卡的注册文件信息进行鉴权，若鉴权不通过，则转发所述智能卡认证请求到TSM平台进行鉴权，以使所述TSM平台对所述智能卡进行鉴权，鉴权通过后向所述终端反馈认证响应消息；

所述接收模块，还用于接收所述终端发送的智能卡业务请求，所述智能卡业务请求中包含：业务请求的类型；

处理模块，用于根据所述业务请求的类型，获取与所述业务请求的类型相对应的处理信息，并向所述终端反馈所述处理信息。

8.根据权利要求7所述的装置，其特征在于，所述属性信息包含以下至少一项：ICCID、IMSI；所述预设触发条件包含以下至少一种：终端自启动、用户触发所述智能卡认证指令、智能卡服务器推送认证邀请。

9.根据权利要求7所述的装置，其特征在于，所述业务请求的类型包含以下至少一项：应用查询请求；应用详情查询请求；应用删除请求、应用下载请求、应用锁定请求、应用解锁请求、应用升级请求、OAT应用个人化请求、OAT信息同步请求、OTA写卡请求。

10.根据权利要求9所述的装置，其特征在于，还包括：

所述业务请求的类型为所述应用查询请求，所述处理模块具体用于根据所述应用查询请求，获取所述智能卡的应用列表信息；向所述终端反馈所述应用列表信息；所述应用列表信息包含：已下载的应用列表，和/或允许所述智能卡下载的应用列表。

11.根据权利要求9所述的装置，其特征在于，还包括：

所述业务请求的类型为所述应用详情查询请求；相应的，所述智能卡业务请求中还包含：待查询应用的标识；

所述处理模块具体用于根据所述待查询应用的标识，查询与所述待查询应用标识对应的应用的详情信息；向所述终端反馈所述详情信息；所述详情信息包含：应用版本、应用类型、应用大小、应用客户端下载信息。

12.根据权利要求7所述的装置，其特征在于，所述智能卡业务请求中还包含：与所述业务请求的类型相关联的应用标识；相应的，所述装置还包括：识别模块，用于识别所述应用标识对应的应用的预设权限；

所述处理模块包括：

第一处理子模块，用于当所述预设权限为托管DM模式时，根据所述业务请求的类型，获取与所述业务请求的类型相对应的处理信息，并向所述终端反馈所述处理信息；

第二处理子模块，用于当所述预设权限为TSM模式时，向所述TSM平台发送所述业务请求；接收所述TSM平台根据所述业务请求的类型，获取与所述业务请求的类型相对应的处理信息，并将所述处理信息反馈给所述终端。

13.一种智能卡处理系统，其特征在于，包括权利要求7～12任一项权利要求所述的智能卡处理装置；还包括：TSM平台、终端、智能卡；

所述智能卡设置在所述终端内；所述终端内安装有用于对所述智能卡进行操作的客户端；所述TSM平台与所述智能卡处理装置连接，以使所述终端通过所述智能卡处理装置接收所述TSM平台对所述智能卡的鉴权处理或者业务请求处理。