基于移动终端卡模拟的信用支付方法及装置与流程

本发明涉及通信技术领域，尤其涉及一种基于移动终端卡模拟的信用支付方法及装置。

背景技术：

目前公共交通工具主要包括公交和地铁，而用户在乘坐公共交通工具购票时，主要采用现金或公交卡两种支付方式，现金支付主要针对公交系统，用户可以采用投币的形式购票。同时，用户也可以采用预付费的方式办理公交卡，以刷卡的形式乘坐公交车或地铁出行。

用户在使用现金的方式购票乘坐公交车时，一方面，由于很多公交车为无人售票车，不设找兑，使得用户须事先准备小额票款，给用户出行带来了不便。另一方面，公交系统的工作人员在营业结束后，还需对用户在乘坐无人售票公交车时投入的小额票款清点，给工作人员带来了额外的工作。用户在使用公交卡刷卡乘坐公共交通工具时，由于目前公交卡主要为非接触式射频卡，用户在使用和携带过程中，容易造成公交卡的弯折损坏、卡面的磨损致使卡面图案模糊等人为损耗。当用户乘坐公共交通工具使用单次公交卡时，也大多使用小额票款购买单次公交卡，同样需要工作人员对小额票款进行清点结算。

当用户乘坐公共交通工具使用可复用的预付费公交卡时，由于该可复用的预付费公交卡不记名、不挂失，丢失后会给用户造成很大的损失，并且还需要用户去指定的网点购买、充值和退款，同样给用户造成很大不便。

技术实现要素：

为克服相关技术中存在的问题，本发明提供一种基于移动终端卡模拟的信用支付方法及装置。

根据本发明实施例的第一方面，提供一种基于移动终端卡模拟的信用支付方法，包括：

向预设服务器发送应用授权请求；

接收所述预设服务器发送的应用公钥证书和应用私钥；

将所述应用公钥证书和所述应用私钥保存到所述移动终端的信用支付应用中；

向所述预设服务器发送信用支付数据获取请求；

接收所述预设服务器发送的信用支付数据，并根据所述信用支付数据开通所述移动终端的信用支付功能。

进一步的，还包括：

获取所述移动终端的设备参数信息；

将所述设备参数信息发送给所述预设服务器，以使所述预设服务器根据接收到的所述设备参数信息判断所述移动终端是否满足开通信用支付的硬件条件；

检测是否接收到所述预设服务器发送的信用支付开通信息；

当接收到所述预设服务器发送的信用支付开通信息时，确定所述移动终端满足开通信用支付的硬件条件，并执行所述向预设服务器发送应用授权请求的步骤。

进一步的，还包括：

获取用户身份信息；

将所述用户身份信息发送给所述预设服务器，以使所述预设终端根据接收到的所述用户身份信息判断所述移动终端是否满足开通信用支付的安全认证条件；

检测是否接收到所述预设服务器发送的安全认证通过信息；

当接收到所述预设服务器发送的安全认证通过信息时，确定所述移动终端满足开通信用支付的安全认证条件，并执行所述向预设服务器发送应用授权请求的步骤。

进一步的，还包括：

向所述预设服务器发送获取预设安装文件的请求；所述预设安装文件包括：信用支付安装文件；

获取所述预设服务器发送的所述预设安装文件；

将所述预设安装文件安装在所述移动终端中，执行所述向预设服务器发送应用授权请求的步骤。

进一步的，所述信用支付数据，包括：支付卡号、信用额度、可用额度和交易验证码tac子密钥。

根据本发明实施例的第二方面，提供一种基于移动终端卡模拟的信用支付方法，包括：

接收移动终端发送的应用授权请求；

根据所述应用授权请求分别生成应用公钥和应用私钥；

利用所述预设服务器中保存的信用授权私钥对所述应用公钥签名，生成应用公钥证书；

将所述应用公钥证书和所述应用私钥发送给所述移动终端；

接收所述移动终端发送的信用支付数据获取请求；

根据所述信用支付数据获取请求，生成与所述移动终端相对应信用支付数据，并将所述信用支付数据发送给所述移动终端，以使所述移动终端根据接收到的信用支付数据开通所述移动终端的信用支付功能。

进一步的，还包括：

接收所述移动终端发送的设备参数信息；

根据所述设备参数信息判断所述移动终端是否满足开通信信用支付的硬件条件；

当所述移动终端满足开通信信用支付的硬件条件时，向所述移动终端发送信用支付开通信息，并执行所述接收移动终端发送的应用授权请求的步骤。

进一步的，还包括：

接收所述移动终端发送的用户身份信息；

根据所述用户身份信息判断所述移动终端是否满足开通信信用支付的安全认证条件；

当所述身份信息满足开通信信用支付的安全认证条件时，向所述移动终端发送安全认证通过信息，并执行所述接收移动终端发送的应用授权请求的步骤。

进一步的，还包括：

接收所述移动终端发送的获取预设安装文件的请求，所述预设安装文件包括：信用支付安装文件；

根据所述获取预设安装文件的请求将所述预设安装文件发送给所述移动终端，并执行所述接收移动终端发送的应用授权请求的步骤。

根据本发明实施例的第三方面，提供一种基于移动终端卡模拟的信用支付装置，包括：

应用授权请求发送单元，用于利用所述移动终端中的信用授权系统应用向预设服务器发送应用授权请求；

密钥接收单元，用于接收所述预设服务器发送的应用公钥证书和应用私钥；

密钥保存单元，用于将所述应用公钥证书和所述应用私钥保存到所述移动终端的信 用支付应用中；

信用支付数据获取请求发送单元，用于向所述预设服务器发送信用支付数据获取请求；

信用支付数据接收单元，用于接收所述预设服务器发送的信用支付数据；

信用支付完成单元，用于根据所述信用支付数据开通所述移动终端的信用支付功能。

进一步的，还包括：

设备参数信息获取单元，用于获取所述移动终端的设备参数信息；

设备参数信息发送单元，用于将所述设备参数信息发送给所述预设服务器，以使所述预设服务器根据接收到的所述设备参数信息判断所述移动终端是否满足开通信用支付的硬件条件；

第一检测单元，用于检测是否接收到所述预设服务器发送的信用支付开通信息；

硬件条件确定单元，用于在接收到所述预设服务器发送的信用支付开通信息时，确定所述移动终端满足开通信用支付的硬件条件。

进一步的，还包括：

用户身份信息获取单元，用于获取用户身份信息；

用户身份信息发送单元，用于将所述用户身份信息发送给所述预设服务器，以使所述预设终端根据接收到的所述用户身份信息判断所述移动终端是否满足开通信用支付的安全认证条件；

第二检测单元，用于检测是否接收到所述预设服务器发送的安全认证通过信息；

安全认证条件确定单元，用于在接收到所述预设服务器发送的安全认证通过信息时，确定所述移动终端满足开通信用支付的安全认证条件。

进一步的，还包括：

获取预设安装文件请求发送单元，用于向所述预设服务器发送获取预设安装文件的请求；所述预设安装文件包括：信用支付安装文件；

预设安装文件获取单元，用于获取所述预设服务器发送的所述预设安装文件；

安装单元，用于将所述预设安装文件安装在所述移动终端中。

进一步的，所述信用支付数据，包括：支付卡号、信用额度、可用额度和交易验证码tac子密钥。

根据本发明实施例的第四方面，提供一种基于移动终端卡模拟的信用支付装置，包 括：

应用授权请求接收单元，用于接收移动终端发送的应用授权请求；

密钥生成单元，用于根据所述应用授权请求分别生成应用公钥和应用私钥；

应用公钥证书生成单元，用于利用所述预设服务器中保存的信用授权私钥对所述应用公钥签名，生成应用公钥证书；

数据发送单元，用于将所述应用公钥证书和所述应用私钥发送给所述移动终端；

信用支付数据获取请求接收单元，用于接收所述移动终端发送的信用支付数据获取请求；

信用支付数据生成单元，用于根据所述信用支付数据获取请求，生成与所述移动终端相对应信用支付数据；

信用支付数据发送单元，用于将所述信用支付数据发送给所述移动终端，以使所述移动终端根据接收到的信用支付数据开通所述移动终端的信用支付功能。

进一步的，还包括：

设备参数信息接收单元，用于接收所述移动终端发送的设备参数信息；

第一判断单元，用于根据所述设备参数信息判断所述移动终端是否满足开通信信用支付的硬件条件；

信用支付开通信息发送单元，用于在所述移动终端满足开通信信用支付的硬件条件时，向所述移动终端发送信用支付开通信息。

进一步的，还包括：

用户身份信息接收单元，用于接收所述移动终端发送的用户身份信息；

第二判断单元，用于根据所述用户身份信息判断所述移动终端是否满足开通信信用支付的安全认证条件；

安全认证通过信息发送单元，用于在所述身份信息满足开通信信用支付的安全认证条件时，向所述移动终端发送安全认证通过信息。

进一步的，还包括：

预设安装文件请求接收单元，用于接收所述移动终端发送的获取预设安装文件的请求，所述预设安装文件包括：信用支付安装文件；

预设安装文件发送单元，用于根据所述获取预设安装文件的请求将所述预设安装文件发送给所述移动终端。

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

本发明提供的基于移动终端卡模拟的信用支付方法及装置，可以应用在移动终端和交易终端中，当用户开通支付应用之后，可以通过使用移动终端就可以完成对交易终端的离线信用支付，可以快速、安全的完成支付交易，并且无需在线支付，避免了相关技术中，例如用户在乘坐公共交通工具时，还需要用户使用现金或公交卡等方式才能实现支付交易功能。

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

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。

图1是发明实施例中提供的信用授权系统示意图；

图2是根据一示例性实施例示出的一种基于移动终端卡模拟的信用支付方法流程图；

图3是根据另一示例性实施例示出的一种基于移动终端卡模拟的信用支付方法流程图；

图4是根据又一示例性实施例示出的一种基于移动终端卡模拟的信用支付方法流程图；

图5是根据又一示例性实施例示出的一种基于移动终端卡模拟的信用支付方法流程图；

图6是根据又一示例性实施例示出的一种基于移动终端卡模拟的信用支付方法流程图；

图7是根据又一示例性实施例示出的一种基于移动终端卡模拟的信用支付方法流程图；

图8是根据又一示例性实施例示出的一种基于移动终端卡模拟的信用支付方法流程图；

图9是根据又一示例性实施例示出的一种基于移动终端卡模拟的信用支付方法流程图；

图10是根据又一示例性实施例示出的一种基于移动终端卡模拟的信用支付方法流程图；

图11是图10中步骤150的流程图；

图12是根据又一示例性实施例示出的一种基于移动终端卡模拟的信用支付方法流程图；

图13是图12中步骤460的流程图；

图14是根据又一示例性实施例示出的一种基于移动终端卡模拟的信用支付方法流程图；

图15是信用授权系统应用、信用支付应用及信用授权系统的服务端之间信令图；

图16是移动终端与公交闸机之间的数据交互的信令图；

图17是公交闸机与信用授权系统的服务端之间的数据交互流的信令图；

图18是根据一示例性实施例示出的一种基于移动终端卡模拟的信用支付装置示意图；

图19是根据又一示例性实施例示出的一种基于移动终端卡模拟的信用支付装置示意图；

图20是根据又一示例性实施例示出的一种基于移动终端卡模拟的信用支付装置示意图；

图21是根据又一示例性实施例示出的一种基于移动终端卡模拟的信用支付装置示意图；

图22是根据又一示例性实施例示出的一种基于移动终端卡模拟的信用支付装置示意图；

图23是根据又一示例性实施例示出的一种基于移动终端卡模拟的信用支付装置示意图；

图24是根据又一示例性实施例示出的一种基于移动终端卡模拟的信用支付装置示意图；

图25是根据又一示例性实施例示出的一种基于移动终端卡模拟的信用支付装置示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如 所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。

移动支付(mobilepayment)，也称手机支付，用户可以使用移动终端对所购买的商品或者服务进行账务支付。移动终端可以采用nfc(nearfieldcommunication，近场通信)与交易终端通信，实现支付交易。其中，nfc又称近距离通信，是一种短距离的高频无线通信技术，允许电子设备之间进行非接触式点对点数据传输交换数据。由于近场通信具有天然的安全性，因此，nfc技术在支付等领域具有很大的应用前景。

卡模拟是nfc技术的三种工作模式之一，这个卡模拟其实就是相当于一张采用rfid(radiofrequencyidentification，射频识别)技术的ic(integratedcircuit，集成电路)卡，可以替代大量的ic卡(包括信用卡)使用的场合，如商场刷卡、公交卡、门禁管制，车票，门票等等。此种方式下，有一个极大的优点，那就是卡片通过非接触读卡器的rf域来供电，即使寄主设备(如手机)没电也可以工作。

为了便于本领域技术人员理解和实施本发明，首先简要说明本发明实施例中涉及到的移动终端、支付终端及服务器之间的相互关系，如上述各终端之间的数据如何传输和处理等。由于本发明可以用在包括移动支付在内的很多领域，为了便于说明，本发明实施例中以用户乘坐公共交通工具时，通过刷手机进行信用支付为例进行说明。

如图1所示，本发明实施例中提供的信用授权系统应用包括：移动终端100、交易终端200和服务器300。其中，移动终端100可以是带有支付交易功能的手机；交易终端200可以是公交闸机，公交闸机是指公交、地铁系统中使用的pos机；服务器300是信用授权系统应用的服务端。在用户通过移动终端100与交易终端200进行支付交易之前，还需要通过服务器300开通移动终端100的信用支付交易功能，然后才能实现移动终端100与交易终端200的支付交易。并且交易终端200会定期上传移动终端100的交易日志给服务器300，服务器300会对移动终端100对应的账户内扣除相应的金额，并将该金额支付给公交公司。

在本发明提供的实施例中，移动终端中可安装有两个应用，一个是信用支付应用，例如信用支付应用applet，该应用applet对于java卡来讲，sun公司定了applet作为其上运行的applet的对象。移动终端上的另一应用可以是信用授权系统应用。可以理解，该两个应用的功能也可以是同一个应用来实现。

交易终端200会使用严格的身份安全认证机制，保证只有身份通过安全认证，而且有足够信用额度的用户才能开通公交信用支付应用。

信用支付应用applet安装在具有nfc功能移动终端100中，在个人化时生成应用公私密钥对，并将应用私钥保存在信用支付应用中，由信用支付应用保证其数据在任何条件下均不可被盗取，应用公钥由信用授权系统应用的私钥签发成应用公钥证书，保存到 信用支付应用中。信用授权系统应用的公钥会提供给交易终端200，保存位置由交易终端200决定，由于其为公钥，所以对安全方面可以不需要强制性的要求。

提供信用支付交易时，交易终端200在读取到信用支付应用中的应用公钥证书以后，使用信用授权系统应用的公钥验签，恢复出应用公钥。信用支付应用会使用应用私钥生成支付授权许可，交易终端200使用应用公钥对支付授权许可进行验签，通过后再对授权许可中的安全因子进行检查，确认安全后进行信用记账，随后在指定时间再向相应的信用账户进行结算。为了保证安全，当使用次数，额度和间隔时间任一因素超过指定阀值，均需要移动终端联网对用户的身份信息进行验证，需重新授权，确保信用支付的安全性。

为了解决相关技术问题，本发明实施例首先提供了一种基于移动终端卡模拟的信用支付方法，用于在移动终端开通信用支付的过程中，如图2所示，该方法可以包括如下步骤：

在步骤s110中，向预设服务器发送应用授权请求。

信用授权系统应用安装在移动终端中，移动终端可以通过授权系统应用向信用授权系统的服务端发送应用授权请求。

在步骤s120中，接收预设服务器发送的应用公钥证书和应用私钥。

信用授权系统的服务端根据接收到的应用授权请求，生成一对应用公私钥，即应用公钥和应用私钥，服务端利用本地存储的授权私钥对应用公钥签名，生成应用公钥证书，将得到的应用公钥证书和应用私钥分别发送给移动终端。

在步骤s130中，将应用公钥证书和应用私钥保存到移动终端的信用支付应用中。

移动终端将服务端发送的应用公钥证书及应用私钥保存到移动终端的信用支付应用中。

在步骤s140中，向预设服务器发送信用支付数据获取请求。

在步骤s150中，接收预设服务器发送的信用支付数据，并根据信用支付数据开通所述移动终端的信用支付功能。

信用支付数据可以是个人化脚本，其中，个人化脚本可包括：支付卡号、信用额度、可用额度、tac子密钥。其中，支付卡号是信用授权系统为每一个用户的信用支付应用生成的唯一特征码。可用额度是用户当前可以使用的金额。并且tac子密钥是信用授权系统服务端使用tac母密钥根据卡号散列得到的。

在本发明提供的又一实施例中，基于图2，如图3所示，在步骤s110之前，还可以包括如下步骤：

在步骤s101中，获取移动终端的设备参数信息。

移动终端的设备参数信息可以是移动终端的硬件信息，需要根据该设备参数信息检测该移动终端是否具备支付交易所具备的硬件条件，如是否具有nfc功能等。当然，设备参数信息还可以是移动终端的设备型号、rom版本、系统型号(如android版本)和应用版本等信息。

在步骤s102中，将设备参数信息发送给预设服务器。

移动终端将获取到自身的设备参数信息发送给信用授权系统的服务端，以使服务端根据接收到的设备参数信息判断该移动终端是否满足开通信用支付的硬件条件。

在步骤s103中，检测是否接收到预设服务器发送的信用支付开通信息。

如果移动终端满足开通信用支付的硬件条件，那么服务端会向移动终端发送信用支付开通信息。其中，该信用支付开通信息可以是信用支付应用开通页面。

如果移动终端不满足开通信用支付的硬件条件，那么服务端不会向移动终端发送信用支付开通信息。

当接收到预设服务器发送的信用支付开通信息时，执行步骤s104。

在步骤s104中，确定移动终端满足开通信用支付的硬件条件，随后执行步骤s110。

除了需要检测移动终端是否满足开通信用支付的硬件条件，基于图2，在步骤s110之前，如图4所示，还需要检测移动终端是否满足安全认证条件，因此，在本发明提供的又一实施例中，本发明提供的基于移动终端卡模拟的信用支付方法，还可以包括以下步骤：

在步骤s105中，获取用户身份信息。

用户的身份信息，可以是用户的身份证号码、姓名、银行卡号、邮箱及支付宝账号等信息。

在步骤s106中，将用户身份信息发送给预设服务器。以使预设终端根据接收到的用户身份信息判断移动终端是否满足开通信用支付的安全认证条件。

移动终端将用户身份信息发送给信用授权系统的服务端，以使服务端对用户身份信息进行验证，如验证银行卡号是否正常提供服务，该用户账号是否有信用不良交易记录等。

在步骤s107中，检测是否接收到预设服务器发送的安全认证通过信息。

服务端在接收到移动终端发送的用户信息之后，会对该用户信息进行检查，如果满足开通信用支付的安全认证条件，那么会向移动终端发送安全认证通过信息。

当接收到预设服务器发送的安全认证通过信息时，在步骤s108中，确定移动终端满足开通信用支付的安全认证条件，随后执行步骤s110。

当移动终端接收到服务端发送的安全认证通过信息时，确定移动终端满足开通信用支付的安全认证条件。

当移动终端没有接收到服务端发送的安全认证通过信息时，确定移动终端不满足开通信用支付的安全认证条件。

基于图2，在步骤s110之前，如图5所示，还需要在移动终端安装相关应用，因此，本发明提供的基于移动终端卡模拟的信用支付方法，还包括如下步骤：

在步骤s160中，向预设服务器发送获取预设安装文件的请求。

预设安装文件包括：信用支付安装应用。

在步骤s170中，获取预设服务器发送的预设安装文件。

在步骤s180中，将预设安装文件安装在移动终端中。随后执行步骤s110。

将信用支付应用和注册脚本分别安装移动终端后，相当于移动终端的用户个人化完成。那么移动终端侧开通信用支付功能的流程结束，结合上述实施例，下面对移动终端开通信用支付功能的信用授权系统的服务端侧的执行流程做出详细阐述。

在本发明提供的又一实施例中，如图6所示，本发明提供的基于移动终端卡模拟的信用支付方法，在服务器(信用授权系统的服务端)的执行流程，可以包括以下步骤：

在步骤s210中，接收移动终端发送的应用授权请求。

在步骤s220中，根据应用授权请求分别生成应用公钥和应用私钥。

在步骤s230中，利用预设服务器中保存的信用授权私钥对应用公钥签名，生成应用公钥证书。

在步骤s240中，将应用公钥证书和应用私钥发送给移动终端。

信用授权系统的服务端根据接收到的应用授权请求，生成一对应用公私钥，即应用公钥和应用私钥，服务端利用本地存储的授权私钥对应用公钥签名，生成应用公钥证书，将得到的应用公钥证书和应用私钥分别发送给移动终端。

在步骤s250中，接收移动终端发送的信用支付数据获取请求。

在步骤s260中，根据信用支付数据获取请求，生成与移动终端相对应信用支付数据，并将信用支付数据发送给移动终端，以使移动终端根据接收到的信用支付数据开通所述移动终端的信用支付功能。

信用支付数据可以是个人化脚本，其中，个人化脚本包括：支付卡号、信用额度、可用额度、tac子密钥。其中，支付卡号是信用授权系统为每一个用户的信用支付应用生成的唯一特征码。可用额度是用户当前可以使用的金额。并且tac子密钥是信用授权系统服务端使用tac母密钥根据卡号散列得到的。

基于图6，如图7所示，在本发明提供的又一实施例中，服务器(信用授权系统的服务端)根据移动终端发送的设备参数信息，判断该移动终端是否满足开通信用支付的硬件条件，因此，本发明实施例中提供的基于移动终端卡模拟的信用支付方法，在步骤s210之前，还可以包括以下步骤：

在步骤s201中，接收移动终端发送的设备参数信息。

在移动终端开通信用支付功能的过程中，可以通过网络等方式与信用授权系统的服务端(即服务器)通信，信用授权系统的服务端可以接收移动终端发送的设备参数信息。

在步骤s202中，根据设备参数信息判断移动终端是否满足开通信信用支付的硬件条件。

移动终端发送的参数信息，可以是移动终端的设备型号、rom版本、系统型号(如android版本)和应用版本等信息等。服务端可以根据移动终端发送的上述信息检测移动终端是否有具备nfc功能等。

如果服务端检测到移动终端满足开通信用支付的硬件条件，那么服务端会向移动终端发送信用支付开通信息。其中，该信用支付开通信息可以是信用支付应用开通页面。用户可以在移动终端上的信用支付应用开通界面上输入用户信息上传到服务端。

如果服务端检测到移动终端不满足开通信用支付的硬件条件，那么服务端不会向移动终端发送信用支付开通信息。

当移动终端满足开通信信用支付的硬件条件时，在步骤s203中，向移动终端发送信用支付开通信息。随后执行步骤s210。

信用授权系统的服务端除了要检测移动终端发送的设备参数信息，还需要检测移动终端发送的用户身份信息，判断移动终端对应的用户是否满足安全认证条件。因此，基于图6，如图8所示，本发明提供的基于移动终端卡模拟的信用支付方法，在移动终端开通信用支付功能的过程中，在步骤s210之前，还可以包括如下步骤：

在步骤s204中，接收移动终端发送的用户身份信息。

该用户身份信息可以是用户的身份证号码、姓名、银行卡号、邮箱及支付宝账号等信息。

在步骤s205中，根据用户身份信息判断移动终端是否满足开通信信用支付的安全认 证条件。

示例性的，服务端可以检测用户身份信息中的一银行卡号是否正常提供服务，是否有不良交易记录等。

如果服务端检测到移动终端满足开通信用支付的安全认证条件，那么会向移动终端发送安全认证通过信息。

当身份信息满足开通信信用支付的安全认证条件时，在步骤s206中，向移动终端发送安全认证通过信息。随后执行步骤s210。

移动终端在开通信用支付时，还需要安装信用支付应用，而这些安装文件都需要信用支付系统的服务端发送给移动终端。因此，基于图6，如图9所示，在本发明提供的又一实施例中，本发明提供的基于移动终端卡模拟的信用支付方法，在步骤s210之前，还可以包括如下步骤：

在步骤s207中，接收移动终端发送的获取预设安装文件的请求。

其中，预设安装文件包括：信用支付安装文件。

在步骤s208中，根据获取预设安装文件的请求将预设安装文件发送给移动终端，随后执行步骤s210。

下面首先对移动终端在支付交易时与交易终端之间的数据交互进行说明。

为了解决相关技术问题，本发明实施例提供了一种基于移动终端卡模拟的信用支付方法，应用于移动终端侧，如图10所示，该方法可以包括如下步骤：

在步骤110中，当检测到交易终端时，向交易终端发送交易信息。

为了便于说明，以交易终端为公交闸机为例进行说明。

在用户手持移动终端贴近公交闸机进行支付交易时，由于公交闸机上能够产生射频场，当移动终端贴近公交闸机时，移动终端可以检测到公交闸机产生的射频场，进而可以检测到公交闸机。在移动终端检测到公交闸机时，移动终端向公交闸机发送交易信息。

在步骤120中，接收交易终端发送的应用公钥证书读取指令。

在公交闸机接收到移动终端发送的交易信息之后，公交闸机经过对该交易信息的处理确认，会向移动终端发送应用公钥证书读取指令。移动终端在接收到公交闸机发送的应用公钥证书读取指令之后，移动终端中的信用支付应用会读取预先生成并存放在移动终端中的应用公钥证书。

在步骤130中，根据应用公钥证书读取指令将应用公钥证书发送给交易终端。

移动终端中的信用支付应用根据应用公钥证书读取指令将读取到的应用公钥证书发 送给公交闸机。

在步骤140中，接收交易终端根据交易信息发送的本次支付交易的扣款信息。

公交闸机在接收到移动终端发送的应用公钥证书之后，会对该应用公钥证书验签，生成本次支付交易的扣款信息，并将该扣款信息发送给移动终端，移动终端接收公交闸机发送的扣款信息。

在步骤150中，根据扣款信息和交易信息，利用移动终端中安装的信用支付应用生成支付授权许可。

移动终端生成的支付授权许可包括：签名数据和tac(transactionauthenticationcode，交易验证码)。

在步骤160中，将支付授权许可发送给交易终端，以使交易终端根据接收到的支付授权许可完成本次支付交易。

公交闸机在接收到移动终端发送的支付授权许可后，会对该支付许可进行验证，如果验证正确，将确定完成本次支付交易。

本发明实施例提供的基于移动终端卡模拟的信用支付方法，在用户利用移动终端与交易终端进行支付交易时，在移动终端依据交易终端发送的相关指令信息依次将交易信息、应用公钥证书及生成的支付授权许可分别发送给交易终端，交易终端根据移动终端发送的信息完成本次支付交易。与相关技术存在的问题相比，本发明实施例提供的基于移动终端卡模拟的信用支付方法，用户在利用移动终端与交易终端交易时，可以使移动终端和交易终端分别处于离线模式，并且可以对移动终端的用户账户采用信用记账消费，在用户利用移动终端消费之后才进行结算，可以避免用户采用现金交易时产生的资金损失风险。

为了详细说明本发明实施例移动终端是如何生成支付授权许可，以便交易终端根据移动终端发送的授权许可完成本次支付交易，作为图10方法的细化，在本发明的另一实施例中，如图11所示，步骤150还可以包括如下步骤：

在步骤151中，根据扣款信息，利用移动终端中存储的应用私钥生成签名数据。

应用私钥是预先生成的，并且存储在移动终端中，信用支付应用利用该应用私钥对扣款信息签名，生成签名数据。其中，扣款信息包括：扣款金额、本次支付交易日期、本次支付交易时间、本次支付交易进出站标志和本次支付交易的站点信息。

在步骤152中，根据扣款信息和交易信息，利用移动终端中预先生成的交易验证码tac子密钥生成tac。

根据扣款信息和交易信息，移动终端中的信用支付应用对扣款金额、本次支付交易 日期、本次支付交易时间、支付卡号、可用额度和信用额度加密，生成tac。其中，信用额度是是信用授权系统授权给用户在离线状态下的最大可用金额。

在步骤153中，将签名数据和tac均作为支付授权许可。

信用支付应用可以将签名数据和tac作为支付授权许可分别发送给公交闸机，也可以将签名数据和tac作为信用授权许可一起发送给公交闸机。

另外，上述交易信息，包括：支付卡号、可用额度、进出站标志和上笔交易信息。其中，支付卡号是信用授权系统为每一个用户的信用支付应用生成的唯一特征码。可用额度是用户当前可以使用的金额。并且tac子密钥是信用授权系统服务端使用tac母密钥根据卡号散列得到的。

基于图10，该方法还可以包括如下步骤：

在步骤11中，根据本次支付交易扣款信息中的扣款金额，将交易信息中的可用额度减去扣款金额，得到当前可用额度。

在步骤12中，将当前可用额度作为移动终端中对应用户的可用额度。随后执行步骤150

为了详细说明移动终端与交易终端之间的交易支付过程，本发明实施例提供的一种基于移动终端卡模拟的信用支付方法，在交易终端侧的执行流程，如图12所示，该方法可以包括如下步骤：

在步骤410中，在接收移动终端发送的交易信息后，向移动终端发送应用公钥证书读取指令。

公交闸机接收移动终端发送的交易信息，该交易信息包括：支付卡号、可用额度、进出站标志和上笔交易信息。公交闸机会对该交易信息中的内容进行检查，例如：检查移动终端对应账户的可用额度、进出站标志位等信息。当检查合格后，公家闸机会向移动终端发送应用公钥证书读取指令。

在步骤420中，接收预设移动终端发送的应用公钥证书。

当公交闸机将应用公钥证书读取指令发送给移动终端之后，移动终端会根据该指令向公交闸机发送应用公钥证书，公交闸机将移动终端发送的应用公钥证书接收。

在步骤430中，利用交易终端本地存储的信用授权公钥对应用公钥证书验签。

为了识别接收到的应用公钥证书是否正确，以及为了使用公钥证书中的相关信息，需要利用信用授权公钥对应用公钥证书验签。其中，信用授权公钥可以是预先存储在公交闸机中。

在步骤440中，当验签过程中从应用公钥证书中恢复出应用公钥时，生成本次支付交易的扣款信息。

公交闸机对移动终端发送的应用公钥证书验签，如果验签不通过，那么结束本次支付交易。如果从应用公钥证书中恢复出应用公钥，说明验签通过，生成本次支付交易的扣款信息。需要说明的是，本次支付交易的扣款信息还可以说是扣款指令，目的在于移动终端接收到公交闸机发送的扣款信息(扣款指令)后，生成支付授权许可。

本次支付交易的扣款信息包括：扣款金额、本次支付交易日期、本次支付交易时间、本次支付交易进出站标志和本次支付交易的站点信息。其中，扣款金额是指公交闸机根据本次支付交易的进出站标志等信息计算得到。

在步骤450中，将扣款信息发送给移动终端。

公交闸机将生成的扣款信息发送给移动终端，使得移动终端在接收到该扣款信息后，根据扣款信息和交易信息，利用移动终端中安装的信用支付应用生成支付授权许可。

在步骤460中，当接收到支付授权许可时，根据支付授权许可确定本次支付交易完成。

支付授权许可包括：签名数据和tac。公交闸机会对支付授权许可中的签名数据验签，如果验签未通过，那么结束本次支付交易，如果验签通过记录本次支付交易的交易日志。

为了详细说明本发明实施例交易终端如何根据移动终端发送的授权许可完成本次支付交易，作为图12方法的细化，在本发明的另一实施例中，如图13所示，步骤460还可以包括如下步骤：

在步骤461中，利用应用公钥对签名数据验签。

应用公钥是公交闸机从移动终端发送的支付授权许可中恢复出而得到的，应用公钥会检查签名数据中的相关信息是否与应用公钥中对应的信息是否匹配，如果匹配，确定验签通过。

在步骤462中，当签名数据验签成功时，生成交易日志。

当公交闸机对签名数据验签通过之后，生成本次支付的交易日志。其中，交易日志包括：扣款金额、交易日期、交易时刻、交易终端id、支付卡号、可用额度和tac。

在步骤463中，将交易日志发送给预设服务器，以使得预设服务器根据交易日志扣除移动终端对应的用户账户中相应的金额。

如图14所示，在本发明提供的又一实施例中，本发明实施例中提供的基于移动终端 卡模拟的信用支付方法在交易终端侧的执行流程还可以包括如下步骤：

在步骤470中，判断交易信息中的可用额度是否大于或者等于预设阈值。

如果可用额度大于或者等于预设阈值，执行步骤480。

在步骤470中，检查所述交易信息中的进出站标志是否为已出站状态。

如果所述进出站标志为已出站状态，执行步骤410。

该步骤470主要是为了公交闸机根据移动终端发送的交易信息，检查移动终端对应的用户账户的可用额度是否足以支付本次支付交易所用的金额，如果可用额度不足，那么拒绝本次支付交易，如果可用额度足够，那么公交闸机会检查交易信息中的进出站标志是否为0，如果进出站标志不为0，那么拒绝本次支付交易；如果进出站标志为0，那么继续本次支付交易。需要说明的是，进出站标志中1表示用户手持移动终端为已进站状态，那么拒绝本次支付交易；进出站标志中0表示用户手持移动终端为已出站状态，那么表示可以结账，进行本次支付交易。

其中，交易信息，包括：支付卡号、可用额度、进出站标志和上笔交易信息。

在本发明提供的又一实施例中，如图15所示，本发明提供的基于移动终端卡模拟的信用支付方法，在实施例中，以手机代表移动终端，信用授权系统的服务端代表服务器进行说明，在手机开通信用支付功能时，手机中的信用授权系统应用、信用支付应用及信用授权系统的服务端之间的流程包括：

步骤1001、获取手机的设备参数信息；

步骤1002、上传设备参数信息；

步骤1003、判断手机收是否满足开通信用支付的硬件条件；

步骤1004、返回判断结果；

步骤1005、判断结果是：展示开通信用支付应用界面；

步骤1006、上传用户身份信息；

步骤1007、判断手机收是否满足开通信用支付的安全认证条件；

步骤1008、返回判断结果；

步骤1009、用户选择开通信用支付应用；

步骤1010、激活信用支付应用；

步骤1011、返回激活成功结果；

步骤1012、请求应用私钥、应用公钥证书和信用支付数据；

步骤1013、生成一对公私钥对，使用信用授权私钥生成应用公钥证书；生成支付卡；号、散列生成应用tac子密钥、子密钥和信用支付数据；

步骤1014、返回应用私钥、应用公钥证书和信用支付数据；

步骤1015、发送应用私钥、应用公钥证书和信用支付数据；

步骤1016、保存应用私钥、应用公钥证书和信用支付数据；

步骤1017、返回个人化结果；

步骤1018、发送信用支付开通结果；

步骤1019、记录开通结果；

步骤1020、返回处理完成通知；

步骤1021、提示用户信用支付应用开通成功。

在本发明提供的又一实施例中，如图16所示，本发明提供的基于移动终端卡模拟的信用支付方法，移动终端在支付交易的过程中，移动终端与公交闸机之间的数据交互流程如下：

步骤2001、公交闸机选择信用授权系统应用；

步骤2002、信用授权系统应用读取需要返回的数据；

步骤2003、信用授权系统应用返回支付卡号、可用额度、进出站标志、上次交易信息；

步骤2004、公交闸机检查可用额度、进出站标志；检查不通过，提示拒绝信息；

步骤2005、公交闸机计算扣款金额；

步骤2006、公交闸机根据扣款金额、交易时间、进出站标志和交易信息进行扣款；

步骤2007、信用授权系统应用生成支付授权许可，包括：签名数据和tac；

步骤2008、信用授权系统应用返回签名数据和tac；

步骤2009、公交闸机使用应用公钥对数据签名验签；验签通过，记录交易日志；验签不通过，提示拒绝信息。

另外，如图17所示，公交闸机还需要定期上传交易日志信用授权系统，以及更新黑名单列表。本发明提供的基于移动终端卡模拟的信用支付方法，公交闸机(交易终端)与信用授权系统的服务端之间的数据交互流程如下：

步骤3001、定期上传交易日志；

步骤3002、结算，查询系统中的黑名单是否有更新，若有更新，准备黑名单列表返回；

步骤3003、返回交易日志接收结果和黑名单列表；

步骤3004、检查是否存在黑名单列表；

步骤3005、公交闸机更新黑名单列表；

步骤3006、更新；

步骤3007、返回更新完成结果。

通过以上的方法实施例的描述，所属领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：只读存储器(rom)、随机存取存储器(ram)、磁碟或者光盘等各种可以存储程序代码的介质。

本发明实施例中，上述是以在公交支付过程中的应用为例进行说明，可以理解的是，根据需要，可以在其它支付场景下应用，例如地铁支付，线下购物支付场景中等。具体应用场景不做特别限制。

另外，作为对上述各实施例的实现，本发明实施例还提供了一种基于移动终端卡模拟的信用支付装置，该装置位于移动终端中，如图18所示，该装置包括：应用授权请求发送单元10、密钥接收单元20、密钥保存单元30、信用支付数据获取请求发送单元40、信用支付数据接收单元50和信用支付完成单元60，其中，

应用授权请求发送单元10，用于利用所述移动终端中的信用授权系统应用向预设服务器发送应用授权请求；

密钥接收单元20，用于发送的应用公钥证书和应用私钥；

密钥保存单元30，用于将所述应用公钥证书和所述应用私钥保存到所述移动终端的信用支付应用中；

信用支付数据获取请求发送单元40，用于向所述预设服务器发送信用支付数据获取请求；

信用支付数据接收单元50，用于接收所述预设服务器发送的信用支付数据；

信用支付完成单元60，用于根据所述信用支付数开通所述移动终端的信用支付功能。

在本发明又一实施例中，基于图18，如图19所示，该装置还包括：

设备参数信息获取单元71，用于获取所述移动终端的设备参数信息；

设备参数信息发送单元72，用于将所述设备参数信息发送给所述预设服务器，以使所述预设服务器根据接收到的所述设备参数信息判断所述移动终端是否满足开通信用支付的硬件条件；

第一检测单元73，用于检测是否接收到所述预设服务器发送的信用支付开通信息；

硬件条件确定单元74，用于在接收到所述预设服务器发送的信用支付开通信息时，确定所述移动终端满足开通信用支付的硬件条件。

在本发明又一实施例中，基于图18，如图20所示，该装置还包括：

用户身份信息获取单元75，用于获取用户身份信息；

用户身份信息发送单元76，用于将所述用户身份信息发送给所述预设服务器，以使所述预设终端根据接收到的所述用户身份信息判断所述移动终端是否满足开通信用支付的安全认证条件；

第二检测单元77，用于检测是否接收到所述预设服务器发送的安全认证通过信息；

安全认证条件确定单元78，用于在接收到所述预设服务器发送的安全认证通过信息时，确定所述移动终端满足开通信用支付的安全认证条件。

在本发明又一实施例中，基于图18，如图21所示，该装置还包括：

获取预设安装文件请求发送单元81，用于向所述预设服务器发送获取预设安装文件的请求；所述预设安装文件包括：信用支付安装文件；

预设安装文件获取单元82，用于获取所述预设服务器发送的所述预设安装文件；

安装单元83，用于将所述预设安装文件安装在所述移动终端中。

本发明实施例还提供了一种基于移动终端卡模拟的信用支付装置，该装置位于交易终端中，如图22所示，该装置包括：应用授权请求接收单元11、密钥生成单元12、应用公钥证书生成单元13、数据发送单元14、信用支付数据获取请求接收单元15、信用支付数据生成单元16和信用支付数据发送单元17，其中，

应用授权请求接收单元11，用于接收移动终端发送的应用授权请求；

密钥生成单元12，用于根据所述应用授权请求分别生成应用公钥和应用私钥；

应用公钥证书生成单元13，用于利用所述预设服务器中保存的信用授权私钥对所述应用公钥签名，生成应用公钥证书；

数据发送单元14，用于将所述应用公钥证书和所述应用私钥发送给所述移动终端；

信用支付数据获取请求接收单元15，用于接收所述移动终端发送的信用支付数据获取请求；

信用支付数据生成单元16，用于根据所述信用支付数据获取请求，生成与所述移动终端相对应信用支付数据；

信用支付数据发送单元17，用于将所述信用支付数据发送给所述移动终端，以使所述移动终端根据接收到的信用支付数据开通所述移动终端的信用支付功能。

在本发明又一实施例中，基于图22，如图23所示，该装置还包括：

设备参数信息接收单元91，用于接收所述移动终端发送的设备参数信息；

第一判断单元92，用于根据所述设备参数信息判断所述移动终端是否满足开通信信用支付的硬件条件；

信用支付开通信息发送单元93，用于在所述移动终端满足开通信信用支付的硬件条件时，向所述移动终端发送信用支付开通信息。

在本发明又一实施例中，基于图22，如图24所示，该装置还包括：

用户身份信息接收单元94，用于接收所述移动终端发送的用户身份信息；

第二判断单元95，用于根据所述用户身份信息判断所述移动终端是否满足开通信信用支付的安全认证条件；

安全认证通过信息发送单元96，用于在所述身份信息满足开通信信用支付的安全认证条件时，向所述移动终端发送安全认证通过信息。

在本发明又一实施例中，基于图19，如图25所示，该装置还包括：

预设安装文件请求接收单元97，用于接收所述移动终端发送的获取预设安装文件的请求，所述预设安装文件包括：信用支付安装文件；

预设安装文件发送单元98，用于根据所述获取预设安装文件的请求将所述预设安装文件发送给所述移动终端。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

本发明提供的基于移动终端卡模拟的信用支付方法及装置，可以应用在移动终端和交易终端中，当用户开通支付应用之后，可以通过使用移动终端就可以完成对交易终端的离线信用支付，可以快速、安全的完成支付交易，并且无需在线支付，避免了相关技术中，例如用户在乘坐公共交通工具时，还需要用户使用现金或公交卡等方式才能实现 支付交易功能。

可以理解的是，本发明可用于众多通用或专用的计算系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络pc、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

本发明可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本发明，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由下面的权利要求指出。

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。