CN103312680B - 一种nfc终端应用的迁移方法、装置及系统 - Google Patents

Abstract

本发明实提供一种NFC终端应用的迁移方法、装置及系统，涉及数据技术领域，解决了现有技术中NFC终端更换时，必须到营业厅迁移应用的技术问题。本发明的方法主要包括：在接收到用户的原卡销卡请求后，从安全芯片SE中获取销卡记录；根据所述销卡记录确定所述原卡是否销卡成功；若确定销卡未成功，则通知所述SE返回销卡记录校验信息，并将所述销卡记录验证信息发送到业务平台进行核实；若接收到核实通过的响应，则将所述响应中携带的敏感数据同步验证信息发送到所述SE中进行迁移应用数据的同步安全确定，并根据所述SE的同步安全确定的执行结果显示销卡是否成功；若确定销卡成功，则显示销卡成功信息。

Description

一种NFC终端应用的迁移方法、装置及系统

技术领域

本发明涉及数据技术领域，尤其涉及一种NFC(Near Field Communication，近距离无线通讯技术)终端应用的迁移方法、装置及系统。

背景技术

NFC终端为一种新型的手机终端，并且这种NFC终端的安全芯片(SE)中可以存放金融应用。因为SE中存放的应用多用于电子现金业务，属于脱机业务，交易记录不会实时联网与后台同步，因此当用户想更换原NFC终端时，无法通过从后台下载应用到新NFC终端的SE中的方法来使新NFC终端的SE中应用的涉及敏感数据与网络侧同步。所以当遇到用户更换NFC终端的情况时，必须采用将原NFC终端中SE存放的应用迁移到新NFC终端的SE中的方式。

现有技术中，若用户想要将应用迁移到新NFC终端的SE中时，考虑到SE中敏感数据(如交易余额)的安全性问题，必须要到营业厅办理应用迁移。但是这种方法对于用户来说不仅便利性差，而且对营业厅来说也增加了不少业务上的负担。

发明内容

本发明的实施例提供一种NFC终端应用的迁移方法、装置及系统，无需用户到营业厅便可实现将原NFC终端中SE的应用迁移到新NFC终端的SE中，安全性高，为用户带来便利。

为达到上述目的，本发明的实施例采用如下技术方案：

在接收到用户的原卡销卡请求后，从SE中获取销卡记录；

根据销卡记录确定原卡是否销卡成功；

若确定销卡未成功，则通知SE返回销卡记录校验信息，并将销卡记录验证信息发送到业务平台进行核实；若接收到核实通过的响应，则将响应中携带的敏感数据同步验证信息发送到SE中进行迁移应用数据的同步安全确定，并根据SE的同步安全确定的执行结果显示销卡是否成功；

若确定销卡成功，则显示销卡成功信息。

进一步地，在确定销卡未成功之后，该方法还包括：将所述销卡未成功的消息通知所述SE进行记录。

一种NFC终端应用的迁移方法，其特征在于，包括：

在客户端接收到用户的原卡销卡请求后，将销卡记录发送到应用客户端；

当应用客户端根据销卡记录确定销卡未成功时，接收到应用客户端的销卡未成功通知，并将销卡记录校验信息发送到应用客户端以便业务平台进行核实；

当通过核实且接收到应用客户端转发的敏感数据同步验证信息时，根据敏感数据同步验证信息确定迁移应用的数据是否与业务平台同步；

若确定与业务平台同步，则将确定的执行结果返回到应用客户端。

进一步地，在接收到客户端销卡未成功的通知后，该方法还包括：将所述销卡未成功的记录登记到到所述销卡记录中。

一种NFC终端应用的迁移方法，包括：

在客户端根据SE中的销卡记录确定销卡未成功时，接收到应用客户端发送的销卡记录校验信息；

根据销卡记录校验信息核实销卡未成功的销卡请求的安全性；

若通过核实，则将携带敏感数据同步验证信息的通过核实响应发送到应用客户端。

一种客户端，包括：

销卡记录获取单元，用于在接收到用户的原卡销卡请求后，从SE中获取销卡记录；

销卡记录确定单元，用于根据销卡记录确定原卡是否销卡成功；

销卡通知单元，用于在销卡记录单元确定销卡未成功，通知SE返回销卡记录校验信息，并将销卡记录验证信息发送到业务平台进行核实；

结果显示单元，用于在销卡通知单元接收到核实通过的响应后，将响应中携带的敏感数据同步验证信息发送到SE中进行迁移应用数据的同步安全确定，并根据SE的同步安全确定的执行结果显示销卡是否成功；以及销卡确定单元确定销卡成功时，显示销卡成功信息。

进一步地，销卡通知单元，还用于在所述销卡记录确定单元确定销卡未成功后，通知所述SE进行记录。

一种SE，包括：

存储单元，用于存储用户的销卡记录，并在接收到客户端发送到销卡记录查询请求后，将销卡记录发送到应用客户端；

校验单元，用于在接收到应用客户端根据销卡记录确定销卡未成功时的通知时，将销卡记录校验信息发送到应用客户端以便业务平台进行核实；

同步确定单元，用于在通过核实且接收应用客户端转发的敏感数据同步验证信息时，根据敏感数据同步验证信息确定迁移应用的数据是否与业务平台同步；

执行反馈单元，用于在同步确定单元确定与业务平台同步时，将确定的执行结果返回到应用客户端。

进一步地，还可包括：记录单元，用于在接收到所述客户端根据所述销卡记录确定销卡未成功的通知后，将所述销卡未成功的记录登记到所述存储单元的销卡记录中。

一种业务平台，包括：

记录接收单元，用于接收到应用客户端发送的销卡记录校验信息；

销卡校验单元，用于根据销卡记录校验信息核实销卡未成功的销卡请求的安全性；

销卡通知单元，用于在销卡校验单元核实通过后，将携带敏感数据同步验证信息的通过核实响应发送到应用客户端。

一种NFC终端应用的迁移系统，包括上述客户端、上述SE和上述业务平台。

与将在营业厅执行的用迁移方案相比，实现用于可以不用到营业厅将原卡SE中的应用迁移到新SE中的应用时，除了需要考虑结合空中迁移的技术外，还主要需要靠考虑迁移时，保证原卡SE上应用保留的交易记录等敏感数据能够与网络侧业务平台保留记录同步，以及敏感数据迁移在迁移过程的安全性。这样才能够在实现空中迁移的过程中保证应用中敏感数据的可靠性和安全性，避免给运营商或用户造成损失。

本发明实施例提供的NFC终端应用的迁移方案中，通过采用在SE中增设销卡记录的技术手段，使NFC终端上的客户端在销卡时可以在确定原卡SE卡未执行过销卡或销卡失败的情况下，执行销卡操作，以便保证当前销卡操作中的敏感数据的有效性，并且通过增设的验证销卡记录在业务平台的验证过程，可以保证敏感数据的安全性，以及原卡SE迁移应用中敏感数据是否与网络侧同步，进而可实现在通过空中方法应用迁移的同时，确保敏感数据可靠性和安全性。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例1中应用迁出的方法流程图；

图2为本发明实施例1中SE内部的结构示意图；

图3为本发明实施例2中的应用下载的方法流程图；

图4为本发明实施例3中的新卡开通的方法流程图；

图5为本发明实施例3中的异常处理方法的流程图；

图6为本发明实施例4中的敏感数据同步至新卡SE的方法流程图；

图7为本发明实施例5中的客户端的结构示意图；

图8为本发明实施例6中的SE的结构示意图；

图9为本发明实施例7中的业务平台的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。并且，以下各实施例均为本发明的可选方案，实施例的排列顺序及实施例的编号与其优选执行顺序无关。

本发明的下述各实施例提供的NFC终端应用的迁移方法，主要从4个过程中描述将应用从原卡SE迁移到新卡SE的过程，包括实施例1提供将原卡SE中的应用迁出的流程；实施例2提供将应用迁入新卡SE的应用下载流程；实施例3提供应用迁入新卡SE后的新卡开通流程，以及开通过程中若遇到异常状况时的异常处理流程；实施例4提供新卡SE开卡后，将原卡SE同步到业务平台侧的敏感数据再备份到新卡SE的应用中。其中，实施例1的应用迁出流程主要保证将原卡SE中应用迁出时，该应用记录的敏感数据与网络侧业务平台保留的记录是否一致，以及迁出时敏感数据的安全性；实施例2中的应用下载流程主要保证应用下载过程中安全性；实施例3中的新卡开通流程中为了保证卡开通的可靠性，业务平台必须在接收到客户端的开卡确定通知后才能将新卡SE的状态修改为已开通；实施例4中的流程主要不同处在于：在将原卡SE同步到业务平台侧的敏感数据再备份到新卡SE的应用之前，先确定新卡SE中应用是否有未经确认的充值交易记录，以保证敏感数据的正确性。

此外，在本发明实施例中，业务平台可以部署在一个平台中，也可以部署在两个平台中，在下述各实施例中，由于服务提供平台和手机支付平台均属于第三方，因此为了详细介绍，以将业务平台分成两个部分，即分别部署到手机支付平台和服务提供平台上为例进行的描述，此时将两平台之间的交互可视为业务平台内的逻辑交互。对于业务平台部署在一个平台上的情况，由于实施方式更为简单，并且实现的功能与部署到上述手机支付平台和服务提供平台上的功能一样，那么基于本领域技术人员根据分开部署的情况可以轻易获知部署在一个平台上的方案，所以在此不赘述。并且，在本发明以及下述各实施例中，原卡SE是指与原SIM绑定的SE；根据SE安装的位置的不同，新卡SE是指与新SIM绑定的SE，新卡SE与原卡SE可以是同一个，也可以是不同的两个。

实施例1

本实施例提供一种NFC终端应用的迁移方法中的应用迁出流程，如图1所示，包括：

本实施例提供方法中，如图2所示，在SE上的电子现金应用上设置销卡记录，用于卡片是否销卡的标记，这样在用户申请销卡时，应用客户端必须判断未销卡或销卡不成功才能够销卡，以保证销卡操作执行的可靠性。

NFC终端上的应用客户端(在本实施例以及下述实施例中可具体为电子现金应用客户端，SE中的应用可具体为电子现金应用)在接收到用户的原卡销卡请求后，从SE中获取销卡记录；如图1中步骤101-103.

101，用户在应用客户端输入贷记账户的交易密码，发起原卡SE销卡请求；

102，应用客户端向原卡SE上的电子现金应用发送请求，读取其内存储的销卡记录；

103，原卡SE返回销卡记录到应用客户端；

应用客户端根据销卡记录确定原卡SE是否销卡成功，如图1中步骤104；

104，应用客户端根据销卡记录的标识(取值为已销卡和正常两种取值)，确定原卡SE是否成功；

若确定销卡成功，则显示销卡成功信息，如图1步骤1051-1081；若确定销卡未成功，则接收到应用客户端的销卡未成功通知，通知原卡SE返回销卡记录校验信息，该销卡记录校验信息包括安全认证码1(如PAN、OTA-AC、ARQC)和敏感数据(如交易余额交易记录等)，原卡SE将销卡记录校验信息发送到应用客户端以便业务平台进行核实，参照图1步骤105到107；

1051，应用客户端a)客户端向中心手机支付平台提交销卡记录；

1061，手机支付平台校验销卡记录中的ARQC(ARQC为授权请求密文、ARPC为授权响应密文，应用密报的一种，是一个采用过程密钥计算的报文鉴别码MAC)，若校验通过，则手机支付平台记录该用户的电子现金账户状态为已销卡；

1071，手机支付平台返回销卡已成功的响应；

1081，应用客户端显示销卡成功信息，结束本流程，不再执行下述步骤。

105，应用客户端通知原卡SE应用销卡未成功；

106，原卡SE的应用校验销卡记录，查看是否可以销卡，若可销卡执行107；否则执行107#

107，原卡SE应用生成相应的销卡记录校验信息(PAN、OTA-TC、ARQC、余额等)，并发送到应用客户端；

107#，返回失败响应到应用客户端；

应用客户端将销卡记录验证信息发送到业务平台进行核实，业务平台接收到应用客户端发送的销卡记录校验信息，并根据销卡记录校验信息核实销卡未成功的销卡请求的安全性；若通过核实，则将携带敏感数据同步验证信息(包括安全验证码2如ARPC，授权响应码、MAC，和敏感数据如清零前余额)的通过核实响应发送到应用客户端(参照步骤109-114)；应用客户端若接收到核实通过的响应，则将响应中携带的敏感数据同步验证信息发送(步骤115)到原卡SE中进行迁移应用数据的同步安全确定(参照步骤116-117)，当原卡SE通过核实且接收到应用客户端转发的敏感数据同步验证信息时，原卡SE根据敏感数据同步验证信息确定迁移应用的数据是否与业务平台同步，若确定与业务平台同步，则将确定的执行结果返回到应用客户端，应用客户端将销卡成功结果发送到业务平台，业务平台根据已销卡登记请求验证请求的安全性；若通过验证，则将SE的状态记录为已注销，并将已注销状态通知TSM平台，使TSM平台更新SE的状态，此外，应用客户端根据SE的同步安全确定的执行结果显示销卡是否成功，(参照步骤118-124)。

108，应用客户端向手机支付平台发送原卡销卡请求，请求中转发销卡记录验证信息(包括卡号(PAN)、OTA-TC、ARQC、余额等数据)；

109，手机支付平台校验ARQC、电子现金账户状态；若安全验证码2ARQC正确且电子现金账户状态正常，则执行110；若ARQC错误或电子现金账户状态异常，则执行111#；

110，手机支付平台向服务提供平台发送原卡销卡请求，包含卡号、敏感数据等；

111#或113#，支付平台向客户端返回错误信息，流程结束，

111，服务提供平台校验用户的贷记账户状态，若通过校验则冻结原卡；

112，服务提供平台返回校验结果，若校验结果为通过，则执行113；否则执行113#；

113，手机支付平台记录电子现金账户的状态为“销卡申请中”，同时生成安全验证码ARPC；

114，手机支付平台返回销卡响应，包含敏感数据同步验证信息(安全验证码2，如ARPC、授权响应码、MAC；和敏感数据，如清0前的余额、)；

115，应用客户端将敏感数据同步验证信息发至原卡SE的应用；

116，原卡SE的应用校验ARPC、清0前的余额(销卡记录中的余额与该余额值一致鉴权通过，否则鉴权失败)、MAC，若通过校验则执行将余额清零；

117，原卡SE的应用返回校验执行结果，其中包括生成的安全验证码3(ARQC)、PAN、OTA-TC、和敏感数据(余额)等信息；

118，应用客户端将上述执行结果，如ARQC传至手机支付平台；

119，手机支付平台校验ARQC，若通过将原卡记为已销卡；

120，手机支付平台向应用客户端返回执行响应；

121客户端显示执行响应；

122，手机支付平台将原卡记为已销卡后，将销卡结果通知TSM平台；

123，TSM(Trust Service Manager，信任服务管理)平台更新NFC终端应用的状态；

124，TSM平台返回执行响应。

需要说明的是：在本实施例中，当客户端确定销卡为成功时，将销卡未成功的消息通知所述SE进行记录。SE在接收到客户端销卡未成功的通知后，将所述销卡未成功的记录登记到到所述销卡记录中。其中，客户端该通知销卡未成功的消息可以是上述步骤105，也可以在步骤105后再另行发送的消息，也可以是在步骤120中，接收到的返回执行响应中带有销卡未成功的信息后，再另行发送通知SE进行记录的消息。相应地，SE可以是在接收到步骤105中的消息后将销卡未成功的记录登记到销卡记录中，也可以在步骤120后，SE接收到客户端发送的销卡未成功通知时，再将销卡未成功的记录登记到销卡记录中。

本实施例提供的方法，通过在销卡前必须确定该销卡操作的未执行或未成功执行的技术手段，保证空中执行应用迁移的可靠性，并且应用只有校验验证码2ARPC通过，且比对平台下发的余额无误后，才能够清余额，以及手机支付平台只有验证验证码3ARQC通过后，再修改卡内余额值及卡应用的状态，以保证空中迁移过程及敏感数据的安全性。

实施例2

本实施例提供的NFC终端应用的迁移方法中，主要描在原卡SE销卡成功后，向新卡SE中下载应用的流程。由于此时新卡SE还没有相应的应用客户单，因此该过程由部署在NFC终端上管理客户端代替执行。该方法主要包括：

管理客户端在接收到用户的新卡下载应用的请求后，向新卡SE发送获取新卡SE信息请求，从新卡SE获取SE标识；新卡SE将SE标识发送到应用客户端用于TSM平台和业务平台下载资格验证；

管理客户端将SE标识发送到TSM平台和业务平台请求进行下载资格验证，TSM平台和业务平台根据请求中携带的SE标识确定新卡SE是否有资格下载应用，若通过业务平台的下载资格验证请求，则通知TSM平台允许新卡SE下载应用，TSM转发该允许的通知到管理客户端。

管理客户端若接收到来自TSM平台的通过下载资格和安全验证的消息，则下载应用到新卡SE。

如图3所示，上述方法的具体流程可包括：

201，用户通过管理客户端发起新卡SE下载请求；

202，管理客户端向新卡SE读取SE标识(SEID)信息；

203，新卡SE返回SEID信息；

204，客户端向TSM平台发送新卡下载卡请求，包含SEID信息；

205，TSM平台校验手机号是否已开通电子现金应用，若已开通则代表已经下载应用，则校验失败，执行206#；否则校验通过，执行206；

206#，TSM平台返回错误原因，流程结束；

206，TSM平台向中心手机支付平台发送新卡下载请求，包含下载资格验证信息，如手机号、NFC终端IMEI信息；

207，手机支付平台校验手机号是否已销卡或尚未开通业务；若手机号尚未销卡，执行208#；若用户已销卡或尚未开通业务则返回成功响应，则执行208；

208#，手机支付平台返回错误原因，客户端显示错误原因，流程结束，

208，，保存NFC终端IMEI信息，同时中心手机支付平台向浦发银行系统发送鉴权请求，包含手机号信息；

209，服务提供平台校验该手机号是否已完成实名验证，同时验证用户是否已处于正式挂失状态；若尚未完成实名验证或未处于正式挂失状态，则执行210#；否则执行210；

210#，返回错误原因，流程结束，

210，向手机支付平台返回鉴权成功的响应，其中含有“是否申请小额授信”的信息，手机支付平台保存该信息；

211，手机支付平台向TSM返回新卡下载请求的响应；

212，TSM平台与SE交互下载应用；

213，应用下载成功后，TSM平台向中心手机支付平台发送下载结果通知，同时获取个人化数据，请求中包含手机号信息；

214，手机支付平台提取个人化的数据；

215，手机支付平台向TSM平台返回个人化数据；

216，TSM平台与SE交互完成个人化；

217，TSM平台与管理客户端交互下载应用客户端；

218，TSM平台完成个人化操作后，向手机支付平台发送个人化结果通知；

219，手机支付平台返回响应。

本实施例提供了一种在应用迁移后，空中下载应用客户端的流程，由于下载前的鉴权过程，可提高空中下载应用安全性，可实现无需用户到营业厅办理，自动执行的技术效果。

实施例3

本实施例提供一种NFC终端应用的迁移过程中，在销卡成功之后，开通新卡SE时的方法，主要包括：

在存在新卡SE应用的情况下，应用客户端发送新卡开卡请求从新卡SE获取卡注册验证信息，新卡SE应用接收到应用客户端发送的开卡请求，并将注册验证信息(包括验证码(如卡号、ARQC)和敏感数据)发送到应用客户端用于在业务平台进行注册，具体参照图4的步骤301-304；

应用客户端将卡注册验证信息发送到业务平台进行注册，业务平台接收到应用客户端发送的新卡SE的开卡请求后，根据开卡请求中的卡注册验证信息进行开卡注册，若注册成功，则将新卡SE的状态修改为已注册，并返回已注册响应到应用客户端，已注册响应中携带新卡SE的写卡脚本，具体参照图4的步骤305-312；

应用客户端若接收到来自业务平台的已注册响应，则将响应中携带的写卡脚本信息发送到新卡SE中执行；新卡SE的应用接收到应用客户端转发的业务平台下发的写卡脚本信息；执行写卡脚本后，发送响应消息到应用客户端，具体参照图4的步骤313-315。

应用客户端在确定新卡SE执行写卡脚本并在业务平台处已开通后，显示开卡成功信息；并通知业务平台，业务平台在接收到应用客户端确定新卡SE执行写卡脚本的通知后，将新卡SE的状态修改为已开通，具体参照图4的步骤316-320。应用客户端在无法确定新卡SE执行写卡脚本并在业务平台处已开通时，按照异常开卡流程处理，具体参照图2各步骤。

上述开通新卡具体流程如图4所示，包括：

301，用户启动应用客户端，若SE上有应用，执行第302步，否则提示用户先下载新卡，参见实施例2新卡应用下载流程；

302，用户通过电子现金应用客户端发起新卡开卡请求；

303，客户端向SE发送写卡开卡请求；

304，新卡SE返回响应，包括注册验证信息，如卡号、余额、ARQC；

305，应用客户端提示用户输入原卡密码、新卡密码；

306，应用客户端向手机支付平台发送新卡开卡请求，包含卡号、原卡密码、新卡密码、余额及ARQC；

307，手机支付平台校验ARQC、余额及电子现金账户状态；若ARQC错误，或余额不为0，或电子现金账户状态异常，则手机支付平台执行308#；否则执行308；

308，手机支付平台向浦发银行系统提交新卡开卡请求，包含卡号、原卡密码、新卡密码及手机号信息；

308#，返回错误信息，流程结束；

309，服务提供平台校验原卡密码，若通过校验，则解绑原卡，绑定新卡，并设置新卡密码，激活新卡，并执行310；若原卡密码校验失败，则执行310#；

310，返回开卡成功响应；

310#，返回错误提示，流程结束；

311，手机支付平台修改原卡状态，创建新的电子现金账户，同时生成ARPC并生成持卡人信息写入脚本，设置新卡为“已注册”的状态；

312，手机支付平台返回响应，包含ARPC及写卡脚本；

313，应用客户端向电子现金应用发送写卡脚本；

314，新卡SE的应用校验ARPC，若校验通过执行写卡脚本；

315，新卡SE的应用返回响应；

316，应用客户端向手机支付平台发送开卡确认，含脚本执行成功与否的结果；

317，若返回的执行结果为脚本执行成功，则中心手机支付平台设置新卡为“已开卡”的状态；

318，手机支付平台返回开卡确认响应；

319，应用客户端显示开卡成功；

320，手机支付平台向TSM平台发送开卡结果，TSM记录开卡结果并返回响应。

在本实施例中，异常开卡流程的触发条件“无法确定新卡SE执行写卡脚本并在业务平台处已开通”包括：未将响应中携带的写卡脚本信息发送到新卡SE中执行，未接收到新卡SE执行写卡脚本的响应，或者未向业务平台发送新卡开卡确认消息；

结合图4具体而言，若正常流程的步骤313步、315、316丢失，导致手机支付平台未知卡片是否执行脚本成功，则应用客户端应执行相应的异常流程：

即：在第315步返回超时，则应用客户端应重发新卡开卡请求，若平台收到该请求后，发现卡应用的状态为“已注册”，则平台直接组装持卡人信息写入脚本，并返回至客户端，由客户端发送给SE的应用执行脚本；

在客户端在发送步骤313步或步骤316步，或接收步骤315步时，刚好由于手机终端断电而未能发送或接收消息成功，则应用客户端重新登录后应按照以下异常开卡流程处理，包括：

应用客户端检查业务平台中新卡SE是否为已注册状态；若为未开通状态，则发送从新卡SE处获取卡开通信息请求，参照图5步骤501-504；新卡SE提供卡开通信息(包括验证码，如卡号、ARQC)到应用客户端，应用客户端将开通信息发送到业务平台以重新获取新卡SE执行的写卡脚本，业务平台接收到新卡SE的开通信息后，根据开通信息进行安全校验，并在安全通过校验后，返回新卡SE的写卡脚本至应用客户端，应用客户端将写卡脚本发送到新卡SE中执行，参照图5步骤505-509。

新卡SE重新接收到客户端转发的业务平台下发的写卡脚本信息，并再次执行写卡脚本，参照步骤510-516。

上述异常处理的具体流程如图5所示，包括：

501，应用客户端向手机支付平台发送状态检查的请求；

502，手机支付平台组装平台的状态字，并在响应中返回；

503，应用客户端判断卡应用的开卡状态，若为“未注册”，则按照正常流程提示用户开卡，若为“已开卡”，则显示开卡成功，若为“已注册”，则执行下一步；

504，应用客户端向新卡SE发送获取卡开通信息的请求；

505，新卡SE返回卡开通信息，其中包含卡号、ARQC等信息；

506，应用客户端向手机支付平台发送获取持卡人信息写入脚本的请求，其中包含卡开通信息(卡号、ARQC等)；

507，手机支付平台校验ARQC，若校验成功，则生成ARPC并生成持卡人信息写入脚本，执行508；否则执行508#；

508#，反馈校验错误信息，并结束流程；

508，手机支付平台返回应用客户端校验通过响应，包含ARPC及写卡脚本；

509，应用客户端向应用发送写卡脚本；

510，新卡SE校验ARPC，若校验通过执行写卡脚本；

511，新卡SE返回响应至；

512，应用客户端向手机支付平台发送开卡确认，含脚本执行成功与否的结果；

513，若脚本执行成功，则手机支付平台设置新卡为“已开卡”的状态；

514，手机支付平台返回开卡确认响应到应用客户端，；

515，应用客户端显示开卡成功；

516，手机支付平台向TSM平台发送开卡结果，TSM记录开卡结果并返回响应。

本实施例提供的新卡开通及异常处理方法中，保证业务平台在接收到应用客户端的开通确定消息后再将新卡的状态修改为已开卡，可保证业务平台开卡状态的准确性和有效性。

实施例4

本实施例提供NFC众多应用迁移过程中，将原卡SE中的敏感数据同步到新卡SE中的过程。主要包括：

应用客户端接收到来自用户的将已销卡的SE的敏感数据同步到新卡SE的请求后，向新卡SE查询是否存在未确定的敏感数据变更记录，新卡SE提供未确定的敏感数据(如充值交易记录)变更记录到应用客户端。应用客户端根据敏感数据变更记录若确定没有为确定的敏感数据变更记录，则按照正常流程修改敏感数据；否则执行冲正流程，参照图6步骤601-604。

其中，正常充值流程和充值流程均同现有技术，下面仅以正常充值流程为例进行描述，冲正流程是本领域技术人员可以根据本实施例中的内容轻易得知的，不再赘述。

如图6所示，本实施例的方法流程具体包括：

601，用户在应用客户端选择原卡余额充值的功能；

602，应用客户端向电子现金应用(SE)发送指令查询未确认充值交易记录；

603，新卡SE返回响应；

604，应用客户端判断新卡SE是否有未确认充值记录，，若没有未确认充值记录，则执行步骤605；否则，按照现有冲正流程执行；

605，应用客户端向手机支付平台获取原卡电子现金余额；

606，应用客户端向新卡SE发送充值初始化指令；

607，新卡SE判断是否已经存在未确认充值交易记录，若没有未确认充值记录，则ATC+1，并生成一条未确认充值交易记录，同时生成ARQC，再执行608；若存在未确认充值记录，则向应用客户端返回错误响应，不执行下述流程；

608，新卡SE向应用客户端返回响应，响应中包括ATC、卡号、充值余额、ARQC；

609，应用客户端向中心手机支付平台发送圈存请求，请求中包括ATC、卡号、余额、充值余额、ARQC；

610，手机支付平台验证ATC(若ATC重复，则丢弃)、ARQC；

611，圈存请求验证通过后，手机支付平台进行账务处理，电子现金账户余额更新；

612，手机支付平台生成ARPC、构造脚本命令PUT DATA，指令中包含MAC、新余额等信息；

613，手机支付平台向客户端返回响应，响应中包含了ARPC、圈存脚本等信息；

614，若应用客户端在规定时间内没收到圈存请求的响应，则执行冲正流程；应用客户端向新卡SE发送充值命令，指令中包含了ARPC、圈存脚本等信息；

615，新卡SE验证ARPC，并执行脚本更新余额，更新未确认充值记录为成功；

616，新卡SE向应用客户端返回充值指令执行结果；

617，应用客户端向手机支付平台发送圈存确认；

618，手机支付平台修改圈存状态为“已成功”；

619，手机支付平台返回响应；

620，应用客户端显示充值结果。

本实施例提供的方法中，在将原卡SE中的敏感数据同步到新卡SE中之前，增加了确认是否有未确定的敏感数据变更记录的技术手段，保证了敏感数据同步之前，数据的可靠性。

实施例5

本实施例提供一种客户端，该客户端可部署在手机等终端上，作为应用客户端或管理客户端，如图7所示，包括：销卡记录获取单元71，销卡记录确定单元72，销卡通知单元73，结果显示单元74。

销卡记录获取单元71，用于在接收到用户的原卡销卡请求后，从SE中获取销卡记录；销卡记录确定单元72，用于根据销卡记录确定原卡是否销卡成功；销卡通知单元73，用于在销卡记录单元确定销卡未成功，通知SE返回销卡记录校验信息，并将销卡记录验证信息发送到业务平台进行核实；结果显示单元74，用于在销卡通知单元73接收到核实通过的响应后，将响应中携带的敏感数据同步验证信息发送到SE中进行迁移应用数据的同步安全确定，并根据SE的同步安全确定的执行结果显示销卡是否成功；以及销卡确定单元确定销卡成功时，显示销卡成功信息。

进一步地，销卡通知单元73，还用于在销卡记录确定单元72确定销卡未成功后，通知所述SE进行记录。

进一步地，还可包括如下可选单元：

客户端应用下载单元，用于在接收到用户的新卡下载应用的请求后，从新卡SE获取SE标识，并将SE标识发送到TSM平台和业务平台进行下载资格验证，若接收到来自TSM平台的通过下载资格和安全验证的消息，则下载应用到新卡SE。

客户端开通单元，用于在存在新卡SE应用的情况下，从新卡SE获取卡注册验证信息，并将卡注册验证信息发送到业务平台进行注册；若接收到来自业务平台的已注册响应，并将响应中携带的写卡脚本信息发送到新卡SE中执行；在确定新卡SE执行写卡脚本并在业务平台处已开通后，显示开卡成功信息；在无法确定新卡SE执行写卡脚本并在业务平台处已开通时，按照异常开卡流程处理。

其中，客户端开通单元包括：

开通异常处理模块，用于在未将响应中携带的写卡脚本信息发送到新卡SE中执行，未接收到新卡SE执行写卡脚本的响应，或者未向业务平台发送新卡开卡确认消息时，检查业务平台中新卡SE是否为已注册状态，若为未开通状态，则从新卡SE处获取卡开通信息，并发送到业务平台以重新获取写卡脚本，并将写卡脚本发送到新卡SE中执行。

客户端新卡同步单元，用于在接收到来自用户的将已销卡的SE的敏感数据同步到新卡SE的请求后，向新卡SE查询是否存在未确定的敏感数据变更记录，若确定没有为确定的敏感数据变更记录，则按照正常流程修改敏感数据；否则执行冲正流程。

实施例6

本实施例提供一种SE，该SE可部署在手机等终端上，实现实施例1-4任意一方法中的新卡SE或原卡SE的功能。如图8所示，包括：存储单元81，校验单元82，同步确定单元83，执行反馈单元84。

存储单元81，用于存储用户的销卡记录，并在接收到客户端发送到销卡记录查询请求后，将销卡记录发送到应用客户端；校验单元82，用于在接收到应用客户端根据销卡记录确定销卡未成功时的通知时，将销卡记录校验信息发送到应用客户端以便业务平台进行核实；同步确定单元83，用于在通过核实且接收应用客户端转发的敏感数据同步验证信息时，根据敏感数据同步验证信息确定迁移应用的数据是否与业务平台同步；执行反馈单元84，用于在同步确定单元83确定与业务平台同步时，将确定的执行结果返回到应用客户端。

优选地，该SE还可包括如下可选单元：

记录单元，用于在接收到客户端根据销卡记录确定销卡未成功的通知后，将所述销卡未成功的记录登记到存储单元81的销卡记录中。

SE端应用下载单元，用于接收到来自客户端的获取SE标识的请求，并将SE标识发送到应用客户端用于TSM平台和业务平台下载资格验证，在应用客户端接收到通过下载资格和安全验证的消息后，下载应用。

SE端开通单元，用于接收到应用客户端发送的开卡请求，并将注册验证信息发送到应用客户端用于在业务平台进行注册，若在业务平台成功注册，则接收到应用客户端转发的业务平台下发的写卡脚本信息，并在执行写卡脚本后，发送响应消息到应用客户端。

其中，SE端开通单元还包括：

开通异常处理模块，用于当为接收到应用客户端转发的业务平台下方的写卡脚本信息，或为发送响应消息到应用客户端时，提供卡开通信息到应用客户端，重新接收到客户端转发的业务平台下发的写卡脚本信息，并再次执行写卡脚本。

SE端新卡同步单元，用于在应用客户端接收到来自用户的将已销卡的SE的敏感数据同步到新卡SE的请求后，提供未确定的敏感数据变更记录到应用客户端。

实施例7

本实施例提供一种业务平台，该业务平台可以看作是手机支付平台和服务提供平台的整体，用于实现实施例1-4任意一方法中的手机支付平台和服务提供平台的功能，由于在上述实施例1-4的方法对该业务平台中手机支付平台和服务提供平台的描述足够详细，因此，在此不对单元具体归属于手机支付平台还是服务提供平台作细分。如图9所示，包括：记录接收单元91，销卡校验单元92，销卡通知单元93。

记录接收单元91，用于接收到应用客户端发送的销卡记录校验信息；销卡校验单元92，用于根据销卡记录校验信息核实销卡未成功的销卡请求的安全性；销卡通知单元93，用于在销卡校验单元核实通过后，将携带敏感数据同步验证信息的通过核实响应发送到应用客户端。

优选地，该业务平台还可包括如下可选单元：

状况确定单元，用于接收到应用客户端发送的已销卡登记请求，根据已销卡登记请求验证请求的安全性，若通过验证，则将SE的状态记录为已注销，并将已注销状态通知TSM平台，使TSM平台更新SE的状态。

业务平台端下载确定单元，用于接到TSM平台发送的新卡SE下载资格验证的请求，根据请求中携带的SE标识确定新卡SE是否有资格下载应用，若通过下载资格和安全验证请求，则通知TSM平台允许新卡SE下载应用。

业务平台端开通单元，用于接收到应用客户端发送的新卡SE的开卡请求，根据开卡请求中的卡注册验证信息进行开卡注册，若注册成功，则将新卡SE的状态修改为已注册，并返回已注册响应到应用客户端，已注册响应中携带新卡SE的写卡脚本，在接收到应用客户端确定新卡SE执行写卡脚本的通知后，将新卡SE的状态修改为已开通。

其中，业务平台端开通单元包括：

开通异常处理模块，用于在未接收到应用客户端确定新卡SE执行写卡脚本的通知时，将新卡SE是否已注册的状态通知应用客户端，在新卡SE为已注册状态的情况下，接收到应用客户端发送到新卡SE的开通信息，并根据开通信息返回新卡SE的写卡脚本至应用客户端，以使新卡SE重新执行写卡脚本。

实施例8

本实施例提供一种NFC终端应用的迁移系统，包括实施例5中描述的客户端、实施例6中描述的SE和实施例7中描述的业务平台。

本实施例提供的系统中对原卡SE的应用进行迁出，在NFC终端应用中增加销卡记录，以及在NFC终端的SE、应用客户端、手机支付平台、TSM平台增加相应的验证机制，保证应用中敏感数据的安全迁出，以及保证不会因迁出的异常而产生纠纷，并且对应用的敏感数据(余额)进行处理，可以在新终端中迁入原卡SE的敏感数据(例如余额)可实现安全、可靠的在新终端中迁入应用。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。

Claims (35)

1.一种近距离无线通讯技术NFC终端应用的迁移方法，其特征在于，包括：

在接收到用户的原卡销卡请求后，从安全芯片SE中获取销卡记录；

根据所述销卡记录确定所述原卡是否销卡成功；

若确定销卡未成功，则通知所述SE返回销卡记录校验信息，并将所述销卡记录校验信息发送到业务平台进行核实；若接收到核实通过的响应，则将所述响应中携带的敏感数据同步验证信息发送到所述SE中进行迁移应用数据的同步安全确定，并根据所述SE的同步安全确定的执行结果显示销卡是否成功；

若确定销卡成功，则显示销卡成功信息。

2.根据权利要求所述的NFC终端应用的迁移方法，其特征在于，在确定销卡未成功之后，该方法还包括：

将所述销卡未成功的消息通知所述SE进行记录。

3.根据权利要求1所述的NFC终端应用的迁移方法，其特征在于，在所述销卡成功之后，向新卡SE下载应用时，该方法还包括：

在接收到用户的新卡下载应用的请求后，从所述新卡SE获取SE标识；

将所述SE标识发送到信任服务管理TSM平台和业务平台进行下载资格验证；若接收到来自所述TSM平台的通过下载资格验证的消息，则下载所述应用到所述新卡SE。

4.根据权利要求1所述的NFC终端应用的迁移方法，其特征在于，在销卡成功之后，将开通新卡SE时，该方法还包括：

在存在所述新卡SE应用的情况下，从所述新卡SE获取卡注册验证信息，并将所述卡注册验证信息发送到所述业务平台进行注册；

若接收到来自所述业务平台的已注册响应，并将所述响应中携带的写卡脚本信息发送到所述新卡SE中执行；

在确定所述新卡SE执行所述写卡脚本并在所述业务平台处已开通后，显示开卡成功信息；

在无法确定所述新卡SE执行所述写卡脚本并在所述业务平台处已开通时，按照异常开卡流程处理。

5.根据权利要求4所述的NFC终端应用的迁移方法，其特征在于，所述无法确定所述新卡SE执行所述写卡脚本并在所述业务平台处已开通包括：未将所述响应中携带的写卡脚本信息发送到所述新卡SE中执行，未接收到所述新卡SE执行所述写卡脚本的响应，或者未向所述业务平台发送新卡开卡确认消息；所述异常开卡流程包括：

检查所述业务平台中所述新卡SE是否为已注册状态；

若为未开通状态，则从所述新卡SE处获取卡开通信息，并发送到所述业务平台以重新获取所述写卡脚本，并将所述写卡脚本发送到所述新卡SE中执行。

6.根据权利要求1所述的NFC终端应用的迁移方法，其特征在于，在销卡成功，且新卡SE开通后，该方法还包括：

接收到来自用户的将已销卡的SE的敏感数据同步到新卡SE的请求；

向所述新卡SE查询是否存在未确定的敏感数据变更记录；

若确定没有为确定的敏感数据变更记录，则按照正常流程修改敏感数据；否则执行冲正流程。

7.一种NFC终端应用的迁移方法，其特征在于，包括：

在客户端接收到用户的原卡销卡请求后，将销卡记录发送到所述客户端；

当所述客户端根据所述销卡记录确定销卡未成功时，接收到所述客户端的销卡未成功通知，并将销卡记录校验信息发送到所述客户端以便业务平台进行核实；

当通过核实且接收到所述客户端转发的敏感数据同步验证信息时，根据所述敏感数据同步验证信息确定迁移应用的数据是否与所述业务平台同步；

若确定与所述业务平台同步，则将确定的执行结果返回到所述客户端。

8.根据权利要求7所述的NFC终端应用的迁移方法，其特征在于，在接收到客户端销卡未成功的通知后，该方法还包括：

将所述销卡未成功的记录登记到到所述销卡记录中。

9.根据权利要求7所述的NFC终端应用的迁移方法，其特征在于，在所述销卡成功之后，向新卡SE下载应用时，该方法还包括：

接收到来自客户端的获取SE标识的请求；

将SE标识发送到所述客户端用于TSM平台和业务平台下载资格验证；

在所述客户端接收到TSM平台的通过下载资格和安全验证的消息后，下载应用。

10.根据权利要求7所述的NFC终端应用的迁移方法，其特征在于，在销卡成功之后，将开通新卡SE时，该方法还包括：

接收到所述客户端发送的开卡请求；

将注册验证信息发送到所述客户端用于在业务平台进行注册；

若在业务平台成功注册，则接收到所述客户端转发的所述业务平台下发的写卡脚本信息；

执行所述写卡脚本后，发送响应消息到所述客户端。

11.根据权利要求10所述的NFC终端应用的迁移方法，其特征在于，当为接收到所述客户端转发的所述业务平台下方的写卡脚本信息，或为发送响应消息到所述客户端时，该方法还包括：

提供卡开通信息到所述客户端；

重新接收到客户端转发的所述业务平台下发的写卡脚本信息，并再次执行所述写卡脚本。

12.根据权利要求7所述的NFC终端应用的迁移方法，其特征在于，在销卡成功，且新卡SE开通后，该方法还包括：

在所述客户端接收到来自用户的将已销卡的SE的敏感数据同步到新卡SE的请求后，提供未确定的敏感数据变更记录到所述客户端。

13.一种NFC终端应用的迁移方法，其特征在于，包括：

在客户端根据SE中的销卡记录确定销卡未成功时，接收到所述客户端发送的销卡记录校验信息；

根据所述销卡记录校验信息核实所述销卡未成功的销卡请求的安全性；

若通过核实，则将携带敏感数据同步验证信息的通过核实响应发送到所述客户端。

14.根据权利要求13所述的NFC终端应用的迁移方法，其特征在于，当所述客户端接收到SE返回的同步安全确定的执行结果后，或者在客户端根据SE中的销卡记录确定销卡成功时，该方法还包括：

接收到所述客户端发送的已销卡登记请求；

根据所述已销卡登记请求验证所述请求的安全性；

若通过验证，则将所述SE的状态记录为已注销，并将所述已注销状态通知TSM平台，使所述TSM平台更新所述SE的状态。

15.根据权利要求13所述的NFC终端应用的迁移方法，其特征在于，在所述销卡成功之后，向新卡SE下载应用时，该方法还包括：

接到TSM平台发送的新卡SE下载资格验证的请求；

根据所述请求中携带的SE标识确定所述新卡SE是否有资格下载应用；

若通过所述下载资格和安全验证请求，则通知所述TSM平台允许所述新卡SE下载应用。

16.根据权利要求13所述的NFC终端应用的迁移方法，其特征在于，在销卡成功之后，将开通新卡SE时，该方法还包括：

接收到所述客户端发送的所述新卡SE的开卡请求；

根据所述开卡请求中的卡注册验证信息进行开卡注册；

若注册成功，则将所述新卡SE的状态修改为已注册，并返回已注册响应到所述客户端，所述已注册响应中携带所述新卡SE的写卡脚本；

在接收到所述客户端确定所述新卡SE执行所述写卡脚本的通知后，将所述新卡SE的状态修改为已开通。

17.根据权利要求16所述的NFC终端应用的迁移方法，其特征在于，该方法还包括：

若未接收到所述客户端确定所述新卡SE执行所述写卡脚本的通知，则将所述新卡SE是否已注册的状态通知所述客户端；

在所述新卡SE为已注册状态的情况下，接收到所述客户端发送到所述新卡SE的开通信息；

根据所述开通信息返回所述新卡SE的写卡脚本至所述客户端，以使所述新卡SE重新执行所述写卡脚本。

18.一种客户端，其特征在于，包括：

销卡记录获取单元，用于在接收到用户的原卡销卡请求后，从SE中获取销卡记录；

销卡记录确定单元，用于根据所述销卡记录确定所述原卡是否销卡成功；

销卡通知单元，用于在所述销卡记录单元确定销卡未成功，通知所述SE返回销卡记录校验信息，并将所述销卡记录校验信息发送到业务平台进行核实；

结果显示单元，用于在销卡通知单元接收到核实通过的响应后，将所述响应中携带的敏感数据同步验证信息发送到所述SE中进行迁移应用数据的同步安全确定，并根据所述SE的同步安全确定的执行结果显示销卡是否成功；以及所述销卡确定单元确定销卡成功时，显示销卡成功信息。

19.根据权利要求18所述的客户端，其特征在于，

所述销卡通知单元，还用于在所述销卡记录确定单元确定销卡未成功后，通知所述SE进行记录。

20.根据权利要求18所述的客户端，其特征在于，还包括：

客户端应用下载单元，用于在接收到用户的新卡下载应用的请求后，从新卡SE获取SE标识，并将所述SE标识发送到TSM平台和业务平台进行下载资格验证，若接收到来自所述TSM平台的通过下载资格和安全验证的消息，则下载所述应用到所述新卡SE。

21.根据权利要求18所述的客户端，其特征在于，还包括：

客户端开通单元，用于在存在新卡SE应用的情况下，从所述新卡SE获取卡注册验证信息，并将所述卡注册验证信息发送到所述业务平台进行注册；若接收到来自所述业务平台的已注册响应，并将所述响应中携带的写卡脚本信息发送到所述新卡SE中执行；在确定所述新卡SE执行所述写卡脚本并在所述业务平台处已开通后，显示开卡成功信息；在无法确定所述新卡SE执行所述写卡脚本并在所述业务平台处已开通时，按照异常开卡流程处理。

22.根据权利要求21所述的客户端，其特征在于，所述客户端开通单元包括：

开通异常处理模块，用于在未将所述响应中携带的写卡脚本信息发送到所述新卡SE中执行，未接收到所述新卡SE执行所述写卡脚本的响应，或者未向所述业务平台发送新卡开卡确认消息时，检查所述业务平台中所述新卡SE是否为已注册状态，若为未开通状态，则从所述新卡SE处获取卡开通信息，并发送到所述业务平台以重新获取所述写卡脚本，并将所述写卡脚本发送到所述新卡SE中执行。

23.根据权利要求18所述的客户端，其特征在于，还包括：

客户端新卡同步单元，用于在接收到来自用户的将已销卡的SE的敏感数据同步到新卡SE的请求后，向所述新卡SE查询是否存在未确定的敏感数据变更记录，若确定没有为确定的敏感数据变更记录，则按照正常流程修改敏感数据；否则执行冲正流程。

24.一种SE，其特征在于，包括：

存储单元，用于存储用户的销卡记录，并在接收到客户端发送到销卡记录查询请求后，将销卡记录发送到所述客户端；

校验单元，用于在接收到所述客户端根据所述销卡记录确定销卡未成功时的通知时，将销卡记录校验信息发送到所述客户端以便业务平台进行核实；

同步确定单元，用于在通过核实且接收所述客户端转发的敏感数据同步验证信息时，根据所述敏感数据同步验证信息确定迁移应用的数据是否与所述业务平台同步；

执行反馈单元，用于在所述同步确定单元确定与所述业务平台同步时，将确定的执行结果返回到所述客户端。

25.根据权利要求24所述的SE，其特征在于，还包括：

记录单元，用于在接收到所述客户端根据所述销卡记录确定销卡未成功的通知后，将所述销卡未成功的记录登记到所述存储单元的销卡记录中。

26.根据权利要求24所述的SE，其特征在于，还包括：

SE端应用下载单元，用于接收到来自客户端的获取SE标识的请求，并将SE标识发送到所述客户端用于TSM平台和业务平台下载资格验证，在所述客户端接收到通过下载资格和安全验证的消息后，下载应用。

27.根据权利要求24所述的SE端，其特征在于，还不包括：

SE端开通单元，用于接收到所述客户端发送的开卡请求，并将注册验证信息发送到所述客户端用于在业务平台进行注册，若在业务平台成功注册，则接收到所述客户端转发的所述业务平台下发的写卡脚本信息，并在执行所述写卡脚本后，发送响应消息到所述客户端。

28.根据权利要求27所述的SE，其特征在于，所述SE端开通单元还包括：

开通异常处理模块，用于当为接收到所述客户端转发的所述业务平台下方的写卡脚本信息，或为发送响应消息到所述客户端时，提供卡开通信息到所述客户端，重新接收到客户端转发的所述业务平台下发的写卡脚本信息，并再次执行所述写卡脚本。

29.根据权利要求24所述的SE，其特征在于，还包括：

SE端新卡同步单元，用于在所述客户端接收到来自用户的将已销卡的SE的敏感数据同步到新卡SE的请求后，提供未确定的敏感数据变更记录到所述客户端。

30.一种业务平台，其特征在于，包括：

记录接收单元，用于接收到客户端发送的销卡记录校验信息；

销卡校验单元，用于根据所述销卡记录校验信息核实销卡未成功的销卡请求的安全性；

销卡通知单元，用于在销卡校验单元核实通过后，将携带敏感数据同步验证信息的通过核实响应发送到所述客户端。

31.根据权利要求30所述的业务平台，其特征在于，还包括：

状况确定单元，用于接收到所述客户端发送的已销卡登记请求，根据所述已销卡登记请求验证所述请求的安全性，若通过验证，则将SE的状态记录为已注销，并将所述已注销状态通知TSM平台，使所述TSM平台更新所述SE的状态。

32.根据权利要求30所述的业务平台，其特征在于，还包括：

业务平台端下载确定单元，用于接到TSM平台发送的新卡SE下载资格验证的请求，根据所述请求中携带的SE标识确定新卡SE是否有资格下载应用，若通过所述下载资格和安全验证请求，则通知所述TSM平台允许所述新卡SE下载应用。

33.根据权利要求30所述的业务平台，其特征在于，还包括：

业务平台端开通单元，用于接收到所述客户端发送的新卡SE的开卡请求，根据所述开卡请求中的卡注册验证信息进行开卡注册，若注册成功，则将所述新卡SE的状态修改为已注册，并返回已注册响应到所述客户端，所述已注册响应中携带所述新卡SE的写卡脚本，在接收到所述客户端确定所述新卡SE执行所述写卡脚本的通知后，将所述新卡SE的状态修改为已开通。

34.根据权利要求30所述的业务平台，其特征在于，所述业务平台端开通单元包括：

开通异常处理模块，用于在未接收到所述客户端确定新卡SE执行写卡脚本的通知时，将所述新卡SE是否已注册的状态通知所述客户端，在所述新卡SE为已注册状态的情况下，接收到所述客户端发送到所述新卡SE的开通信息，并根据所述开通信息返回所述新卡SE的写卡脚本至所述客户端，以使所述新卡SE重新执行所述写卡脚本。

35.一种NFC终端应用的迁移系统，其特征在于，包括如权利要求18-23中任意一项所述的客户端、如权利要求24-29中任意一项所述的SE和如权利要求30-34中任意一项所述的业务平台。