一种风险识别方法及装置与流程

本申请涉及计算机
技术领域：
，尤其涉及一种风险识别方法及装置。
背景技术：
目前，在互联网技术的支持下，在线支付日渐盛行。但用户所使用的、具有支付功能的账户有被盗取的风险，一旦账户被非法盗取，那么，非法用户便可进行非法支付。现有技术中，为了减少或避免非法支付给合法用户带来的影响，通常采用两种风险识别方式：方式一、预先将已发生的正常支付和非法支付所对应的支付信息，分别作为正负样本进行训练，得到相应的识别模型。进一步使用预先训练得到的识别模型，针对基于账户当前发生的支付行为进行风险识别，用以监控可能的非法支付。方式二、基于经验预先设置相应的风险识别规则，如果某次基于账户的支付行为符合预设的规则，则将该次支付列为高风险的支付行为，并进行监控。然而，上述的风险识别方式仍存在一定的缺陷，具体地：对于方式一而言，特别是在用户所使用的支付卡账户(如：银行卡账户)被盗取的情况下，非法用户可能会使用新注册的账户与盗取的支付卡账户绑定后进行非法支付。此类新注册的账户的历史支付数据通常较少，甚至在本次非法支付前从未进行过支付。那么，也就会造成识别过程中模型的变量缺失率较高，进而导致并不能有效实现对非法支付的识别。对于方式二而言，由于监控规则的建立通常依赖于人为的经验和理解，存在一定的主观性，对识别的准确性有一定程度的影响。技术实现要素：本申请实施例提供一种风险识别方法及装置，用以解决目前对非法支付的风险识别存在一定缺陷的问题。本申请实施例提供的一种风险识别方法，包括：监测并获取当前支付操作所对应的支付数据；获取所述当前支付操作的相关账户的历史支付数据；确定所述支付数据和历史支付数据的各支付维度；确定所述支付数据与所述历史支付数据在所述各支付维度之间的差异；根据所述差异，对所述当前支付操作进行风险识别。本申请实施例提供的一种风险识别装置，包括：监测模块，监测并获取当前支付操作所对应的支付数据；历史数据获取模块，获取所述当前支付操作的相关账户的历史支付数据；维度确定模块，确定所述支付数据和历史支付数据的各支付维度；差异计算模块，确定所述支付数据与所述历史支付数据在所述各支付维度之间的差异；风险识别模块，根据所述差异，对所述当前支付操作进行风险识别。本申请实施例提供一种风险识别方法及装置，通过该方法，支付平台监测到当前支付操作后，可获取该当前支付操作的支付数据，以及当前支付操作的相关账户的历史支付数据。基于此，支付平台可以进一步确定出支付数据和历史支付数据中的各支付维度，根据各支付维度，可以确定出支付数据和历史支付数据之间的差异，这里的差异也就能够在一定程度上反映出当前支付操作是否符合原有的支付习惯。从而，支付平台可根据上述差异对当前支付操作进行风险识别。相较于现有技术，本申请中的风险识别方法并不依赖黑白样本作为风险识别的依据，特别是针对使用支付卡账户进行支付的场景下，即使与支付卡账户绑定的网络账户中没有任何历史支付数据，也可根据支付卡账户自身或收入账户的历史支付数据，确定出当前支付操作与历史的支付操作之间的差异，同时，确定出的差异是基于实际产生的数据，也就无需依赖主观性较强的规则识别方式。附图说明此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：图1a为本申请实施例提供的风险识别过程所基于的架构示意图；图1b为本申请实施例提供的风险识别过程；图2为本申请实施例提供的风险识别过程所基于的另一种架构示意图；图3a为本申请实施例提供的一种风险识别的逻辑架构的示意图；图3b为本申请实施例提供的另一种风险识别的逻辑架构的示意图；图4为本申请实施例提供的风险识别装置结构示意图。具体实施方式为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。基于前述内容，本申请实施例中提供了一种风险识别方法，在不依赖黑白样本进行训练的同时，可直接根据支出账户的历史支付数据、收入账户的历史支付数据等实现对非法支付的风险识别。需要说明的是，在本申请实施例中，所述的支出账户，可理解为自身存储有支付资源，并根据支付操作将指定数量的支付资源转出的账户。可包括：网络账户和/或支付卡账户。其中，网络账户，可以是用户在支付平台上注册的账户，该账户内可存储支付资源。支付卡账户，可以包括：银行卡账户、预付卡账户和/或充值卡账户等。所述的收入账户，可理解为接收到转入的支付资源的账户。收入账户也可包括：网络账户、银行卡账户等。这里的支付资源包括但不限于：款项、虚拟货币、可交易的虚拟物品、存储资源(如：云存储空间)、计算资源(如：计算线程、计算设备)等等。本申请实施例中所述的风险识别方法，可采用如图1a所示的架构。图1a中的架构包含支付用户、收款用户以及支付平台，在支付平台的支持下，支付用户和收款用户之间可进行在线支付(图1a中的虚线箭头，代表支付用户向收款用户发起支付，该支付通过支付平台实现)。其中：所述的支付用户，可认为是使用支出账户进行在线支付的用户，可以是个人用户或是企业用户。所述的收款用户，可认为是能够向支付用户提供有偿业务服务的用户，同样可以是个人用户或是企业用户。为了使用支付平台提供的支付业务，收款用户和支付用户均在支付平台上注册相应的网络账户。所述的支付平台，可以是诸如网站、银行等支付业务提供方后台的服务器或服务器集群。当然，在实际的支付场景中，支付用户可通过终端主动发起支付(终端并未展示在图1a所示的架构中)。这里的终端包括但不限于：智能手机、平板电脑、智能手表、移动pos机等移动终端，或是计算机、atm机等设备。应理解，图1a中的支付用户，可能包括合法用户，也可能包括非法用户，支付平台将通过本申请中的风险识别方法，对每一笔支付进行识别判定。如图1b所示，本申请实施例中的风险识别过程包括如下步骤：步骤s101：监测并获取当前支付操作所对应的支付数据。在如图1a所示的架构基础上，当前支付操作，可包括：在当前时刻，支付平台接收到由支付用户发出的、基于支出账户的支付指令。除此之外，支付平台接收到所述的支付指令后所做出的部分响应，也可理解为是所述的当前支付操作所包含的范围。需要说明的是，上述的部分响应，通常可以是：支付平台基于支付指令生成相应的序号(如：交易单号)，支付平台基于支付指令从支付用户的支出账户中扣款等响应。上述的部分响应通常不包括：支付平台将扣除的款项转移给收款用户的收入账户。换言之，在支付平台的角度，对支付操作的监测，也就是监测支付用户发出基于支出账户的支付指令，以及支付平台将款项转移给收款用户之前，针对支付指令所做出的一系列响应。在实际的业务场景中，任一次支付操作都会产生相应的支付数据，如：支付时间、所要支付的额度、发出支付操作所基于的终端等。而支付数据将是本申请实施例中的风险识别的判断依据，故将获取当前支付操作的支付数据。步骤s102：获取所述当前支付操作的相关账户的历史支付数据。在本申请实施例中，当前支付操作需要将支付资源转出，也就需指定相应的支出账户，此外，当前支付操作中也需指定相应的收入账户，故这里的支出账户和收入账户，便可认为是当前支付操作的相关账户。那么，可获取相关账户的历史支付数据，作为风险识别的判断基础。具体而言，支付平台可确定所述当前支付操作对应的相关账户的账户信息，并根据所述账户信息，获取所述相关账户的历史支付数据。当然，在本申请实施例中，对当前支付操作的监控及对应的支付数据、历史支付数据的获取，可由支付平台的支付服务功能实现。这里并不作具体限定。步骤s103：确定所述支付数据和历史支付数据的各支付维度。在本申请实施例中，历史支付数据中包含了历史上已发生过的历次支付操作的诸如支付时间、支付额度等不同的维度。相应地，当前支付操作的支付数据中，也同样包含这些维度。可以理解，某些维度可能并不能用于风险识别，如：交易号、订单号等，那么，可在支付数据和历史支付数据中确定出能够用于后续风险识别的部分或全部的维度。在本申请实施例中，将能够用于后续风险识别的维度，称为支付维度。步骤s104：确定所述支付数据与所述历史支付数据在所述各支付维度之间的差异。考虑到在实际应用中，非法用户进行的非法支付，与合法用户在正常状态下的支付操作之间会存在一定程度的差异。那么，在本申请实施例中，可确定出上述的差异。其中，作为本申请实施例中的一种可行方式，为了直观的展现这种差异，可量化出当前支付操作的支付数据与历次历史支付操作的历史支付数据之间差异的值，如：离散度、相似度等等。步骤s105：根据所述差异，对所述当前支付操作进行风险识别。可以理解地，如果支付数据与历史支付数据之间的差异较大，也就表明当前的支付操作不符合该支出账户持有人的支付习惯，进而，当前支付操作是非法支付的可能性较高。在本申请实施例中，针对当前支付操作进行风险识别后，可以生成相应的识别结果。该识别结果既可以展示给相关人员(如：支出账户的实际持有人)，也可以直接输入至相应的风控系统中，以实现对当前支付操作的风险控制。当然，具体可以根据实际应用的需要进行设定，这里并不应构成对本申请的限定。通过上述步骤，对于支付用户发出的当前支付操作，支付平台可以获取到当前支付操作的支付数据，以及当前支付操作的相关账户的历史支付数据。基于此，支付平台可以进一步确定出支付数据和历史支付数据中的各支付维度，根据各支付维度，可以确定出支付数据和历史支付数据之间的差异，这里的差异也就能够在一定程度上反映出当前支付操作是否符合原有的支付习惯。从而，支付平台可根据上述差异对当前支付操作进行风险识别。相较于现有技术，本申请中的风险识别方法并不依赖黑白样本作为风险识别的依据，可根据支出账户或收入账户等相关账户的历史支付数据，确定出当前支付操作与历史的支付操作之间的差异，同时，确定出的差异是基于实际产生的数据，也就无需依赖主观性较强的规则识别方式。这里需要说明的是，本申请实施例中的风险识别方法，能够较好地适用于支付卡账户的风险识别，以下将基于支付卡账户(为便于描述，以下简称为：支付卡)的场景，对本申请实施例中的风险识别方法进行详细说明。在实际的支付场景下，用户可将支付卡与自身的网络账户绑定关联，便可使用支付卡进行在线支付。一旦支付卡被非法盗取，则非法用户便可将盗取的支付卡与非法用户自身的网络账户进行绑定关联，以进行盗卡支付。正如前述，非法用户新注册的网络账户，其历史支付数据通常较少，甚至完全没有历史支付数据。针对上述场景，当支付平台监测到了支付用户的基于支付卡的支付操作后，可获取支付卡的历史支付数据以及收入账户的历史收款数据。可以理解地，对于图1a所示的架构而言，作为一种可能的扩展方式，可如图2所示的架构。相较于图1a所示的架构，图2中的架构中增加了相应的数据库，可以理解地，每一次支付所产生的支付数据(包括支出账户对应的数据以及收入账户对应的数据)，均存储在该数据库中。该数据库可以是支付业务提供方所提供的数据库，也可以是银行数据库。这里不作具体限定。那么，基于图2中的架构，支付平台基于当前支付操作，可以确定出当前支付操作中所使用的支付卡的相关信息(如：支付卡的标识)，进而可在数据库中进一步查询到该支付卡的历史支付数据(以下为便于描述，将支付卡的历史数据，称作为“卡历史xx”，这里并不应作为对本申请的限定)。类似地，支付平台也可确定出当前支付操作所对应的收款用户的相关信息(如：收入账户的账户名)，在数据库中获取到收入账户的历史收款数据。在本申请实施例中，基于支付卡的历史支付数据以及收入账户的历史收款数据中，可确定出多种不同的支付维度，每一种支付维度，都可认为是用户支付习惯的一种体现，具体可如表1所示。支付维度支付卡收入账户支付时间卡历史支付时间分布支出方历史支付时间分布使用设备卡历史设备分布支出方历史设备分布设备os卡历史设备os分布支出方历史设备os分布支付金额卡历史支付金额分布支出方历史支付金额分布wifimac卡历史wifimac分布支出方历史wifimac分布ip城市卡历史ip城市分布支出方ip城市分布表1其中，支付时间的维度取值，具体可以是预先划分的时间段，如：凌晨、上午、下午等。使用设备的维度取值，具体可包括：计算机、智能手机、平板电脑等，使用设备这一维度可根据支付用户所使用的终端的设备标识所确定，这里不进行过多赘述。设备os是指支付用户所使用终端的操作系统(operatingsystem，os)，可包括：安卓(android)系统、ios系统、windows系统等。支付金额是支付操作所对应的支付额度。wifimac可认为是支付用户使用终端发出支付操作时，终端所使用wifi的mac地址。ip城市是指发出支付操作的终端的网络ip地址所在的城市。当然，表1中所列举出的各维度仅是一种示例，并不应作为对本申请的限定。另需要注意的是，收款用户的收入账户，可能会收到来自于不同支付卡或支出账户所支付的支付资源，可以理解，其他支付卡或支出账户所支付的支付资源，并不能用于对当前支付卡的支付操作的风险识别。故上述获取到的收入账户的历史收款数据，是基于历史上使用该支付卡进行支付所产生的。换言之，在本申请实施例中，当所述相关账户包含收入账户时，获取所述相关账户的历史支付数据的过程可以为：在所述收入账户的所有历史支付数据中，获取与所述支出账户相关的历史支付数据。此外，在本申请实施例中，可以使用离散度来量化当前支付操作的支付数据与历史支付数据、历史收款数据之间的差异，其表征某一次支付操作偏离整体支付习惯的程度。具体而言，在获取到上述的数据后，便可以计算离散度。在本申请实施例中，可以采用基于属性值频率(attributevaluefrequency，avf)算法，计算各支付维度所对应的avf值，并进一步计算出离散度，计算公式如下：其中，m是支付维度；xi表示第i次支付操作；f(xij)是xi第j个支付维度值出现的频率；outlinex表示支付操作的离散度。基于上述公式，假设支付用户发出的当前支付操作以及支付卡的历史支付操作的各支付维度取值如下表2所示。支付维度当前支付历史支付1历史支付2历史支付3历史支付4支付时间凌晨下午下午上午上午客户端类型appappappappapp设备osandroidiosiosiosandroidip城市成都杭州杭州杭州杭州表2可以进一步计算出当前支付操作的支付数据与卡历史支付数据之间的离散度：可见，在上述支付卡所发生的历次支付中，当前支付操作的离散度outline当前支付最高，从获取的历史支付数据中也可以看出，当前支付离散度最高的原因是当前支付操作的时间和ip城市在该支付卡的历次支付中都是首次出现，而操作系统“android”只出现过两次，其风险也相对较高。通过上述分析，上述离散度计算的方式，可以体现出当前支付操作与历史上历次支付操作之间的差异，也就可以通过离散度来识别盗卡支付。以上是根据支付卡的卡历史支付数据计算得到的离散度，基于同样方法，也可根据收入账户的历史收款数据计算得到相应的离散度，这里便不再过多赘述。应理解的是，获取到的历史支付数据越丰富，对离散度的计算也就越充分，相应地，也就能更加精准地体现出当前支付操作与历史上历次支付操作之间的差异，更有利于对盗卡支付的风险识别。当然，基于avf值计算离散度并非仅限于上述的公式，从前述的计算结果可知，avf值与离散度之间呈负相关，那么，还可以采用诸如：倒数等计算方式，得到与avf值负相关的数据，作为离散度。此外，上述计算离散度的过程仅是一种可行方式，在实际应用中，并不限于使用avf值计算离散度，还可以采用诸如统计方法、分布密度等算法，这里不做过多赘述。在计算得到离散度的情况下，便可以基于离散度对当前的支付操作进行风险识别。作为本申请实施例中的一种可行方式，如图3a所示，根据所述差异，对所述当前支付操作进行风险识别，可包括：将计算得到的所述离散度输入至预先建立的风险识别模型，对所述当前支付操作进行风险识别。在图3a中可见，经过上述计算得到的离散度，仅是风险识别模型的其中一种输入，该风险识别模型还可具有其他的输入，以便较为准确地实现风险识别。这里不做过多赘述。而作为本申请实施例中的另一种可行方式，如图3b所示，可直接基于计算得到的离散度进行风险识别，也即，根据所述差异，对所述当前支付操作进行风险识别，具体包括：根据计算得到的所述离散度以及预设的风险阈值，对所述当前支付操作进行风险识别。以上两种实现方式并不应作为对本申请的限定。以上为本申请提供的风险识别方法的几种实施例，基于同样的思路，本申请还提供了风险识别装置的实施例，如图4所示。图4中的风险识别装置包括：监测模块401，监测并获取当前支付操作所对应的支付数据；历史数据获取模块402，获取所述当前支付操作的相关账户的历史支付数据；维度确定模块403，确定所述支付数据和历史支付数据的各支付维度；差异计算模块404，确定所述支付数据与所述历史支付数据在所述各支付维度之间的差异；风险识别模块405，根据所述差异，对所述当前支付操作进行风险识别。所述历史数据获取模块402，确定所述当前支付操作对应的相关账户的账户信息，根据所述账户信息，获取所述相关账户的历史支付数据；其中，当前支付操作的相关账户包括：当前支付操作所对应的支出账户和/或收入账户。当所述相关账户包含收入账户时，所述维度确定模块403，在所述收入账户的所有历史支付数据中，获取与所述支出账户相关的历史支付数据。所述差异计算模块404，针对任一维度，确定所述支付数据与所述历史支付数据的属性值频率avf值，根据所述avf值，计算所述支付数据与所述历史支付数据之间的离散度。所述风险识别模块405，将计算得到的所述离散度输入至预先建立的风险识别模型，对所述当前支付操作进行风险识别。所述风险识别模块405，根据计算得到的所述离散度以及预设的风险阈值，对所述当前支付操作进行风险识别。所述支出账户包括：网络账户和/或支付卡账户；其中，所述支付卡账户至少包括：银行卡账户、预付卡账户和/或充值卡账户。在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(programmablelogicdevice,pld)(例如现场可编程门阵列(fieldprogrammablegatearray，fpga))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片pld上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logiccompiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(hardwaredescriptionlanguage，hdl)，而hdl也并非仅有一种，而是有许多种，如abel(advancedbooleanexpressionlanguage)、ahdl(alterahardwaredescriptionlanguage)、confluence、cupl(cornelluniversityprogramminglanguage)、hdcal、jhdl(javahardwaredescriptionlanguage)、lava、lola、myhdl、palasm、rhdl(rubyhardwaredescriptionlanguage)等，目前最普遍使用的是vhdl(very-high-speedintegratedcircuithardwaredescriptionlanguage)与verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(applicationspecificintegratedcircuit，asic)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：arc625d、atmelat91sam、microchippic18f26k20以及siliconelabsc8051f320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定事务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行事务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。当前第1页12