CN108074024A - 风险识别方法、装置及系统 - Google Patents

Abstract

本申请公开了风险识别方法、装置及系统，用以解决现有技术中为进行业务风险识别而建立可信数据数据库需要耗费大量资源，成本较高的问题。所述方法包括：客户端获得其所在设备相关的可信数据，所述可信数据由第一服务端和/或所述客户端生成；所述客户端将所述可信数据发送给第二服务端，以便于所述第二服务端根据所述可信数据，对所述客户端的业务进行风险识别。

Description

风险识别方法、装置及系统

技术领域

本申请涉及计算机软件技术领域，尤其涉及风险识别方法、装置及系统。

背景技术

随着计算机技术和互联网技术的迅速发展，很多业务都可以在网上进行，给用户带来了极大便利，但是网上业务在给用户带来便利的同时，也带来了一些风险，比如，账户盗用等风险。

在现有技术中，服务端往往基于账户相关的可信数据，对该账户所登录客户端上的业务进行风险识别，可信数据由服务端根据账户相关业务的历史数据生成，保存在数据库中，在需要对该业务进行风险识别时则从数据库中读取可信数据并使用。

在实际应用中，随着业务规模的扩大，往往有这样的场景：大规模业务分散在多个区域(比如，多个省)进行，在这种情况下，通常以一个区域的服务端为主，其他区域的服务端为辅进行业务处理，则在对业务的风险识别方面，不仅需要为主服务端建立可信数据的数据库，还需要为每个辅服务端分别建立可信数据的数据库，以提高各区域业务的风险识别效率。

但是，在上述场景下，建立可信数据的数据库需要耗费大量资源，成本较高。

发明内容

本申请实施例提供风险识别方法、装置及系统，用以解决现有技术中为进行业务风险识别而建立可信数据数据库需要耗费大量资源，成本较高的问题。

本申请实施例采用下述技术方案：

本申请实施例提供的一种风险识别方法，包括：

客户端获得其所在设备相关的可信数据，所述可信数据由第一服务端和/或所述客户端生成；

所述客户端将所述可信数据发送给第二服务端，以便于所述第二服务端根据所述可信数据，对所述客户端的业务进行风险识别。

本申请实施例提供的另一种风险识别方法，包括：

第一服务端生成客户端所在设备相关的可信数据；

所述第一服务端将所述可信数据下发给所述客户端，以便于所述客户端将所述可信数据发送给第二服务端，所述可信数据用于所述第二服务端对所述客户端的业务进行风险识别。

本申请实施例提供的再一种风险识别方法，包括：

第二服务端从客户端获得所述客户端所在设备相关的可信数据，所述可信数据由第一服务端和/或所述客户端生成；

所述第二服务端根据所述可信数据，对所述客户端的业务进行风险识别。

本申请实施例提供的一种风险识别装置，所述装置位于客户端，包括：

获得模块，获得其所在设备相关的可信数据，所述可信数据由第一服务端和/或所述客户端生成；

发送模块，将所述可信数据发送给第二服务端，以便于所述第二服务端根据所述可信数据，对所述客户端的业务进行风险识别。

本申请实施例提供的另一种风险识别装置，所述装置位于第一服务端，包括：

生成模块，生成客户端所在设备相关的可信数据；

下发模块，将所述可信数据下发给所述客户端，以便于所述客户端将所述可信数据发送给第二服务端，所述可信数据用于所述第二服务端对所述客户端的业务进行风险识别。

本申请实施例提供的再一种风险识别装置，所述装置位于第二服务端，包括：

获得模块，从客户端获得所述客户端所在设备相关的可信数据，所述可信数据由第一服务端和/或所述客户端生成；

识别模块，根据所述可信数据，对所述客户端的业务进行风险识别。

本申请实施例提供的一种风险识别系统，包括第一服务端、客户端、第二服务端；

所述第一服务端，生成所述客户端所在设备相关的可信数据，以及将所述可信数据下发给所述客户端；

所述客户端，将从所述第一服务端获得的所述可信数据发送给所述第二服务端；

所述第二服务端，根据从所述客户端获得的所述可信数据，对所述客户端的业务进行风险识别。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：可以由客户端直接提供其所在设备相关的可信数据给进行风险识别的服务端，或者由客户端将一服务端提供的所述可信数据发送给进行风险识别的另一服务端，进而无需为服务端建立可信数据数据库，即可对所述客户端的业务进行风险识别，有利于降低成本，因此，可以部分或全部地解决现有技术中的问题。

附图说明

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

图1为本申请实施例提供的一种风险识别方法的流程示意图；

图2为本申请实施例提供的一种可信数据计算方案的原理示意图；

图3为本申请实施例提供的另一种风险识别方法的流程示意图；

图4为本申请实施例提供的再一种风险识别方法的流程示意图；

图5为本申请实施例提供的对应于图1的一种风险识别装置的结构示意图；

图6为本申请实施例提供的对应于图3的一种风险识别装置的结构示意图；

图7为本申请实施例提供的对应于图4的一种风险识别装置的结构示意图；

图8为本申请实施例提供的一种风险识别系统的结构示意图；

图9为本申请实施例提供的一种支付业务场景下，上述风险识别系统的一种具体实施示意图；

图10为本申请实施例提供的图9的场景下，客户端的业务流程示意图。

具体实施方式

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

本申请的发明的核心思想是：无需为各服务端建立可信数据数据库，而是由某个服务端生成可信数据后将其分别下发给对应设备上的客户端，或者由对应设备上的客户端自己生成可信数据；由客户端暂时在设备本地保存自己的可信数据，以及在适当的时候将可信数据发送进行风险识别的服务端使用。

不仅如此，相比于现有技术以账户为中心，采用账户相关的可信数据的方案，本申请则是以设备为中心，采用设备相关的可信数据，更能够适应于个人移动设备普及的实际环境。

下面对本申请的方案进行详细说明。

本申请的方案的具体实施可以涉及客户端、第一服务端、第二服务端这三端的动作，也可以只涉及客户端、第二服务端这两端的动作，其中，第一服务端和第二服务端一般是不同服务端，但也可以是同一服务端。为了便于理解，分别从每端的角度进行说明。

图1为本申请实施例提供的一种风险识别方法的流程示意图，该流程主要对应于客户端。从设备角度而言，该流程的执行主体可以包括但不限于可搭载客户端的以下设备：手机、平板电脑、智能手表、车机、个人计算机、大中型计算机、计算机集群等。

在本申请实施例中，“客户端的业务”可以指客户端直接提供的业务，也可以指另一端在客户端的辅助而提供的业务。风险识别方法用于对客户端的业务进行识别，本申请对业务的具体内容并不做限定，只要是可以在网上进行的业务均可适用，比如，电子支付业务、通讯业务、电子游戏业务等。

图1中的流程可以包括以下步骤：

S101：客户端获得其所在设备相关的可信数据，所述可信数据由第一服务端和/或所述客户端生成。

在本申请实施例中，可信数据可以反映客户端所在设备与客户端的业务所涉及指定风险因子之间的可信程度，其中，风险因子指在业务中可以直接或间接地代表用户利益的因子和/或所述业务中的特定属性，比如，账户、银行卡、用户身份信息、业务涉及的时间点或地点等。

本申请对可信数据的具体格式和形式并不做限定，取决于具体实施方案。比如，可信数据具体可以是表示设备与账户、或设备与银行卡、或设备与用户身份信息等之间可信等级的表征值；又比如，可信数据具体可以是证明设备与账户、或设备与银行卡、或设备与用户身份信息之间具有绑定关系的安全证书；再比如，可信数据具体可以是表示设备与业务发生时间点、设备与业务发生地点之间具有匹配关系的匹配规则表达式；等等。

在本申请实施例中，可信数据通常可以由第一服务端和/或客户端预先生成，如此，有利于在需要使用可信数据时立即提供。基于同样的理由，当可信数据由第一服务端生成时，第一服务端可以在生成可信数据后在适当的时候将其预先下发给对应的客户端，如此还有利于第一服务端均衡下发所带来的负载。

S102：所述客户端将所述可信数据发送给第二服务端，以便于所述第二服务端根据所述可信数据，对所述客户端的业务进行风险识别。

在本申请实施例中，客户端可以在适当时候(比如，需要第二服务端对客户端的业务进行风险识别时，或客户端空闲时等)将可信数据发送给第二服务端使用。所述“发送”动作可以是客户端主动执行的，也可以是客户端应第二服务端的请求而执行的。

在本申请实施例中，若可信数据由第一服务端生成，则客户端相当于在第一服务端与第二服务端之间传输可信数据的中继节点。这样的方案相比于由第一服务端将可信数据直接发送给第二服务端的方案至少以下两点优势：

第一、若第一服务端是预先发送各客户端的可信数据给第二服务端，则带来了与背景技术相同的问题，即需要为第二服务端建立可信数据数据库，而本申请的方案各客户端分别保存以及中继传输自己的可信数据，无需第一服务端和/或第二服务端专门建立数据库保存，降低了成本；

第二、若第一服务端是在第二服务端需要对客户端的业务进行风险识别时再发送可信数据，由于同时可能有很多客户端的业务需进行风险识别，则会加重第一服务端的处理负担，也会加重第一服务端与第二服务端之间的网络传输负担。

通过图1的方法，可以由客户端直接提供其所在设备相关的可信数据给进行风险识别的服务端，或者由客户端将一服务端提供的所述可信数据发送(比如，中继传输)给进行风险识别的另一服务端，进而无需为服务端建立可信数据数据库，即可对所述客户端的业务进行风险识别，有利于降低成本，因此，可以部分或全部地解决现有技术中的问题。

不仅如此，目前，随着移动设备的普及，几乎人人都有自己专用的个人移动设备(通常是每个用户随身携带的一台手机)，并且用户大多都用个人移动设备进行网上业务，个人移动设备本身几乎已经可以代表用户本人，而用户在不同应用上可能采用不同账户、甚至在同一个应用上可以有多个账户，个人移动设备相比于这些账户被盗用的可能性小，因此，用个人移动设备代表用户更具有普适性和可靠性。在现有技术中采用的可信数据是以账户为中心的，而本申请基于上述理由采用了以设备为中心的可信数据，更能够适应于实际环境。

基于图1的方法，本申请实施例还提供了该方法的一些具体实施方案，以及扩展方案，下面进行说明。

在本申请实施例中，对于步骤S101，当所述可信数据由第一服务端生成时，所述客户端获得其所在设备相关的可信数据，具体包括：所述客户端获得所述第一服务端预先下发的与所述客户端所在设备相关的可信数据；或者，所述客户端向第一服务端发送可信数据获取请求，接收所述第一服务端返回的与所述客户端所在设备相关的可信数据。前面已经陈述了“预先下发”这种方式的优点，这里不再赘述。

当然，上一段只是列举了步骤S101的两种具体实施方式，并非穷举。比如，客户端还可以通过自己计算获得可信数据，或者第一服务端通过诸如生成后实时下发等其他发送方式，提供可信数据给客户端。

在本申请实施例中，前面已经提到，所述可信数据反映所述客户端所在设备与所述客户端的业务所涉及指定风险因子之间的可信程度。在实际应用中，判断一个对象可信与否往往是以该对象的历史行为依据的，历史行为又是通过相应的历史数据反映，本申请中的可信数据可以基于这样的思路生成。

例如，所述可信数据可以由第一服务端和/或所述客户端按照如下方式生成：

获得所述客户端处于所述设备时所进行业务的历史数据；根据特定维度和所述指定风险因子，对所述历史数据进行分析，生成所述可信数据；所述特定维度包括以下至少一种：时间维度、频率维度、业务资源维度。

其中，所述历史数据具体获取于何处并不做限定，比如，其可以获取于第一服务端、或客户端等。

在实际应用中，指定风险因子以及特定维度并不限于上面列举的几种，客户端所在设备和/或其涉及的业务的任意属性都有可能作为指定风险因子或特定维度。

为了便于理解，以一种实际应用场景下的一种具体实施方式为例对照说明。

在该应用场景下，客户端的业务为电子支付业务，指定风险因子可以包括账户、银行卡、用户身份信息(比如，身份证号、护照号码、驾照等证件号码，指纹、声纹等生物特征信息)等。所述设备相关的可信数据可以包括一组或多组数据，每组数据分别包括：客户端所处设备的标识(比如，设备名称、设备唯一标识码等)、某一指定风险因子、该设备与该指定风险因子之间的可信等级(为表征值，假定为1～6级，数字越小表示越可信，则生成可信数据即为计算可信等级。

时间维度可以为基于指定风险因子的支付时间(比如，某账户或某银行卡在该设备上最近一次支付距今时间，记作Recency，简称R)，频率维度可以为基于指定风险因子的支付次数(比如，某账户或某银行卡在该设备上的支付总次数，记作Frequency，简称F)，业务资源维度可以为基于指定风险因子的支付金额(比如，某账户或某银行卡在该设备上的支付总金额，记作Moentary，简称M)，R、F、M均可以从历史数据得到，根据经验，R、F、M越大，通常越可信，对应计算出的可信等级也越小。

比如，可以设定达到1级可信等级需满足：R＞55以及M＞779.99；达到2级可信等级需满足：R＞55以及M≤779.99以及M＞100；达到3级可信等级需满足：R≤55以及R＞25以及F＞1。

上例是简单地通过限定R、F、M的取值区间而限定出对应的可信等级，在实际应用中，还可以采用更复杂的策略计算可信等级。为了便于描述，可以将这些用于计算可信等级的策略用一个自定义的可信函数表示，比如，将用于计算设备与账户之间的可信等级的可信函数记作：

Trusted_Object{D,A}＝Condition(R,F,M)，其中，D表示设备，A表示账户；

产生Condition函数的方式可以有多种，比如决策树、专家经验加案件验证等，本申请对此不做限定。

上面对设备与账户之间的可信等级的计算方式进行了举例说明，诸如设备与银行卡之间的可信等级、设备与其他风险因子之间的可信等级也可以按照类似的方式进行定义和计算，不再赘述。

更直观地，根据上面说明，本申请实施例还提供了一种可信数据计算方案的原理示意图，如图2所示。

在图2中，指定风险因子为账户、银行卡这两种，根据R、F、M可以计算出设备加账户的一个或多个组合的可信等级、设备加银行卡一个或多个组合的可信等级。可以预先为可信等级设定阈值，若计算出的可信等级不小于该设定阈值，则可以认为该可信等级对应的组合为可信对象。

上面从客户端的角度对本申请的方案进行了说明，下面再从第一服务端的角度对本申请的方案进行说明。

图3为本申请实施例提供的另一种风险识别方法的流程示意图，该流程主要对应于第一服务端，该流程与图1中流程的其中一种情况是相互对应的。从设备角度而言，该流程的执行主体可以包括但不限于以下设备：手机、平板电脑、智能手表、车机、个人计算机、大中型计算机、计算机集群等，在这种情况下，这些设备可以作为服务器。

图3中的流程可以包括以下步骤：

S301：第一服务端生成客户端所在设备相关的可信数据。

S302：所述第一服务端将所述可信数据下发给所述客户端，以便于所述客户端将所述可信数据发送给第二服务端，所述可信数据用于所述第二服务端对所述客户端的业务进行风险识别。

通过图3的方法，可以由客户端将一服务端提供的可信数据发送给进行风险识别的另一服务端，进而无需为服务端建立可信数据数据库，即可对客户端的业务进行风险识别，有利于降低成本，因此，可以部分或全部地解决现有技术中的问题。

不仅如此，基于图3的方法，第一服务端、客户端和第二服务端三者之间可以形成一条可信数据传递链路，客户端可以作为为链路上的中级传输可信数据的中继节点，可以分担服务端的处理负担，有利于提高风险识别效率。

基于图3的方法，本申请实施例还提供了该方法的一些具体实施方案，以及扩展方案，下面进行说明。有部分方案及其技术效果在上面对图1的说明中已经进行了详细分析，对于这部分方案，就不再重复分析，只是简单介绍，后面的图4也是同理。

在本申请实施例中，对于步骤S301，所述第一服务端生成客户端所在设备相关的可信数据，具体可以包括：第一服务端获得所述客户端处于所述设备时所进行业务的历史数据；根据特定维度和所述指定风险因子，对所述历史数据进行分析，生成所述可信数据；所述特定维度包括以下至少一种：时间维度、频率维度、业务资源维度。

所述客户端的业务可以为电子支付业务，所述指定风险因子可以包括以下至少一种：账户、银行卡、用户身份信息。

进一步地，下面还从第二服务端的角度对本申请的方案进行说明。

图4为本申请实施例提供的再一种风险识别方法的流程示意图，该流程主要对应于第二服务端，该流程与图1中的流程是相互对应的。从设备角度而言，该流程的执行主体可以包括但不限于以下设备：手机、平板电脑、智能手表、车机、个人计算机、大中型计算机、计算机集群等，在这种情况下，这些设备可以作为服务器。

图4中的流程可以包括以下步骤：

S401：第二服务端从客户端获得所述客户端所在设备相关的可信数据，所述可信数据由第一服务端和/或所述客户端生成。

S402：所述第二服务端根据所述可信数据，对所述客户端的业务进行风险识别。

上面已经对可信数据的生成进行了详细阐述，这里不再赘述。

在本申请实施例中，第二服务端当识别出客户端的业务有风险时，可以阻止其继续进行或者将其转交给风险识别能力更强的服务端进行深度分析。

通过图4的方法，可以由客户端将一服务端提供的可信数据发送给进行风险识别的另一服务端，进而无需为服务端建立可信数据数据库，即可对客户端的业务进行风险识别，有利于降低成本，因此，可以部分或全部地解决现有技术中的问题。

在本申请实施例中，客户端作为了中继传输可信数据的节点，但是在实际应用中，由于某些情况可能导致客户端本身具有风险(比如，客户端被木马侵入、客户端所在设备被合法用户以外的他人盗用、客户端的某些关键数据被清空等)，则由客户端中继传输得到的可信数据已不适于作为风险识别依据。针对这种问题，本申请的方案也提供了应对措施，列举两种措施如下：

第一种措施，第二服务端上可以部署有针对一个或多个客户端的开关，当开关处于开启状态时，第二服务端拒绝接收来自这些客户端的可信数据或者将接收到的可信数据丢弃。所述开关可以为软件开关也可以为硬件开关。

如此，可以在确定客户端本身存在风险时，将该开关开启，采用其他方式进行对客户端的业务进行风险识别，或者直接拒绝客户端的业务。

第二种措施，第一服务端可以将可信数据压缩和/或加密后再发送给客户端，第二服务端可以解压缩和/或解密，而客户端不能，则客户端难以篡改可信数据，从而可以加强可信数据的安全性。

上面分别从三端角度对本申请实施例提供的风险识别方法进行了说明，进一步地，本申请实施例还提供了对应于这些风险识别方法的风险识别装置，如图5、图6、图7所示。

图5为本申请实施例提供的对应于图1的一种风险识别装置的结构示意图，该装置可以位于图1中流程的执行主体(以客户端为例)上，包括：

获得模块501，获得其所在设备相关的可信数据，所述可信数据由第一服务端和/或所述客户端生成；

发送模块502，将所述可信数据发送给第二服务端，以便于所述第二服务端根据所述可信数据，对所述客户端的业务进行风险识别。

图6为本申请实施例提供的对应于图3的一种风险识别装置的结构示意图，该装置可以位于图3中流程的执行主体上(以第一服务端为例)，包括：

生成模块601，生成客户端所在设备相关的可信数据；

下发模块602，将所述可信数据下发给所述客户端，以便于所述客户端将所述可信数据发送给第二服务端，所述可信数据用于所述第二服务端对所述客户端的业务进行风险识别。

图7为本申请实施例提供的对应于图4的一种风险识别装置的结构示意图，该装置可以位于图4中流程的执行主体(以第二服务端为例)上，包括：

获得模块701，从客户端获得所述客户端所在设备相关的可信数据，所述可信数据由第一服务端和/或所述客户端生成；

识别模块702，根据所述可信数据，对所述客户端的业务进行风险识别。

上面分别从三端角度对本申请的方案进行了说明，更进一步地，为了便于从整体上理解本申请的方案，本申请实施例中还提供了包含这三端的一种风险识别系统，如图8所示。

图8为本申请实施例提供的一种风险识别系统的结构示意图，该系统包括第一服务端801、客户端802、第二服务端803；

所述第一服务端801，生成所述客户端所在设备相关的可信数据，以及将所述可信数据下发给所述客户端802；所述客户端802，将从所述第一服务端801获得的所述可信数据发送给所述第二服务端803；所述第二服务端803，根据从所述客户端802获得的所述可信数据，对所述客户端802的业务进行风险识别。

可选地，所述可信数据反映所述客户端802所在设备与所述客户端802的业务所涉及指定风险因子之间的可信程度。

可选地，所述生成所述客户端802所在设备相关的可信数据，具体包括：

获得所述客户端802处于所述设备时所进行业务的历史数据；根据特定维度和所述指定风险因子，对所述历史数据进行分析，生成所述可信数据；所述特定维度包括以下至少一种：时间维度、频率维度、业务资源维度。

可选地，所述客户端802的业务为电子支付业务，所述指定风险因子包括以下至少一种：账户、银行卡、用户身份信息。

可选地，所述时间维度具体包括基于所述指定风险因子的支付时间；和/或所述频率维度具体包括基于所述指定风险因子的支付次数；和/或所述业务资源维度具体包括基于所述指定风险因子的支付金额。

进一步地，本申请实施例还提供了一种支付业务场景下，上述风险识别系统的一种具体实施示意图，如图9所示。

在该支付场景下，第一服务端位于城市A，为总服务端，负责安全所有方面的部署，第二服务端位于城市B，为辅服务端，提供了一个安全接口SC(Security Core)。客户端位于任意用户的终端上，比如手机上。

若不采用本申请的方案，需为第二服务端建立可信数据数据库，否则基于可信数据的风险识别工作只能由第一服务端完成，第二服务端难以分担，也会影响业务；当然，也可以不为第二服务端建立可信数据数据库，而是由第二服务端在需要时实时地从第一服务端获取所需的可信数据，但是，这种方式前面也有分析，对服务端和网络带宽有较大压力，也会也会影响业务。

而若采用本申请的方案，第一服务端可以预先将可信数据下发至对应的每个客户端所在设备上，在客户端发起交易(涉及电子支付)时，可以将交易数据和自己的可信数据通过SC接口发送给第二服务端进行可信计算，以识别交易风险，当结果可信时，继续交易对应的业务流程，否则，可以进行深度分析或直接拒绝后续业务流程。

更具体地，在该支付场景下，第一服务端上涉及上述动作的主要模块为“EDGE管理后台”，客户端上涉及上述动作的主要模块为“EDGE中继模块”，客户端上涉及上述动作的主要模块为“SC接口及其对应的处理逻辑”。需要说明的是，这些名称只是示例，并非对本申请的限定。

在该支付场景下，可信数据包括两类，分别为：客户端所在设备与一个或多个账户之间的可信等级、该设备与一张或多张银行卡之间的可信等级。上述的交易数据中应包含当前使用的账户和/或银行卡，第二服务端通过对交易数据与可信数据进行比对，可以识别出当前交易是否存在风险。

进一步地，本申请实施例还提供了图9的场景下，客户端的业务流程示意图，如图10所示。图10中的EDGE风险识别系统包含有客户端和/或第二服务端的上述模块。

本申请实施例提供的装置、系统与方法是一一对应的，因此，装置、系统也具有与其对应的方法类似的有益技术效果，由于上面已经对方法的有益技术效果进行了详细说明，因此，这里不再赘述对应装置、系统的有益技术效果。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

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

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (20)

1.一种风险识别方法，其特征在于，包括：

客户端获得其所在设备相关的可信数据，所述可信数据由第一服务端和/或所述客户端生成；

所述客户端将所述可信数据发送给第二服务端，以便于所述第二服务端根据所述可信数据，对所述客户端的业务进行风险识别。

2.如权利要求1所述的方法，其特征在于，当所述可信数据由第一服务端生成时，所述客户端获得其所在设备相关的可信数据，具体包括：

所述客户端获得所述第一服务端预先下发的与所述客户端所在设备相关的可信数据。

3.如权利要求1所述的方法，其特征在于，所述可信数据反映所述客户端所在设备与所述客户端的业务所涉及指定风险因子之间的可信程度。

4.如权利要求3所述的方法，其特征在于，所述可信数据由第一服务端和/或所述客户端按照如下方式生成：

获得所述客户端处于所述设备时所进行业务的历史数据；

根据特定维度和所述指定风险因子，对所述历史数据进行分析，生成所述可信数据；

所述特定维度包括以下至少一种：时间维度、频率维度、业务资源维度。

5.如权利要求4所述的方法，其特征在于，所述客户端的业务为电子支付业务，所述指定风险因子包括以下至少一种：账户、银行卡、用户身份信息。

6.如权利要求5所述的方法，其特征在于，所述时间维度具体包括基于所述指定风险因子的支付时间；和/或所述频率维度具体包括基于所述指定风险因子的支付次数；和/或所述业务资源维度具体包括基于所述指定风险因子的支付金额。

7.一种风险识别方法，其特征在于，包括：

第一服务端生成客户端所在设备相关的可信数据；

所述第一服务端将所述可信数据下发给所述客户端，以便于所述客户端将所述可信数据发送给第二服务端，所述可信数据用于所述第二服务端对所述客户端的业务进行风险识别。

8.如权利要求7所述的方法，其特征在于，所述第一服务端生成客户端所在设备相关的可信数据，具体包括：

第一服务端获得所述客户端处于所述设备时所进行业务的历史数据；

根据特定维度和所述指定风险因子，对所述历史数据进行分析，生成所述可信数据；

所述特定维度包括以下至少一种：时间维度、频率维度、业务资源维度。

9.如权利要求8所述的方法，其特征在于，所述客户端的业务为电子支付业务，所述指定风险因子包括以下至少一种：账户、银行卡、用户身份信息。

10.如权利要求9所述的方法，其特征在于，所述时间维度具体包括基于所述指定风险因子的支付时间；和/或所述频率维度具体包括基于所述指定风险因子的支付次数；和/或所述业务资源维度具体包括基于所述指定风险因子的支付金额。

11.一种风险识别方法，其特征在于，包括：

第二服务端从客户端获得所述客户端所在设备相关的可信数据，所述可信数据由第一服务端和/或所述客户端生成；

所述第二服务端根据所述可信数据，对所述客户端的业务进行风险识别。

12.如权利要求11所述的方法，其特征在于，所述第二服务端上部署有开关，当所述开关处于开启状态时，所述第二服务端拒绝接收所述可信数据或者将接收到的所述可信数据丢弃。

13.一种风险识别装置，其特征在于，所述装置位于客户端，包括：

获得模块，获得其所在设备相关的可信数据，所述可信数据由第一服务端和/或所述客户端生成；

发送模块，将所述可信数据发送给第二服务端，以便于所述第二服务端根据所述可信数据，对所述客户端的业务进行风险识别。

14.一种风险识别装置，其特征在于，所述装置位于第一服务端，包括：

生成模块，生成客户端所在设备相关的可信数据；

下发模块，将所述可信数据下发给所述客户端，以便于所述客户端将所述可信数据发送给第二服务端，所述可信数据用于所述第二服务端对所述客户端的业务进行风险识别。

15.一种风险识别装置，其特征在于，所述装置位于第二服务端，包括：

获得模块，从客户端获得所述客户端所在设备相关的可信数据，所述可信数据由第一服务端和/或所述客户端生成；

识别模块，根据所述可信数据，对所述客户端的业务进行风险识别。

16.一种风险识别系统，其特征在于，包括第一服务端、客户端、第二服务端；

所述第一服务端，生成所述客户端所在设备相关的可信数据，以及将所述可信数据下发给所述客户端；

所述客户端，将从所述第一服务端获得的所述可信数据发送给所述第二服务端；

所述第二服务端，根据从所述客户端获得的所述可信数据，对所述客户端的业务进行风险识别。

17.如权利要求16所述的系统，其特征在于，所述可信数据反映所述客户端所在设备与所述客户端的业务所涉及指定风险因子之间的可信程度。

18.如权利要求17所述的系统，其特征在于，所述生成所述客户端所在设备相关的可信数据，具体包括：

获得所述客户端处于所述设备时所进行业务的历史数据；

根据特定维度和所述指定风险因子，对所述历史数据进行分析，生成所述可信数据；

所述特定维度包括以下至少一种：时间维度、频率维度、业务资源维度。

19.如权利要求18所述的系统，其特征在于，所述客户端的业务为电子支付业务，所述指定风险因子包括以下至少一种：账户、银行卡、用户身份信息。

20.如权利要求19所述的系统，其特征在于，所述时间维度具体包括基于所述指定风险因子的支付时间；和/或所述频率维度具体包括基于所述指定风险因子的支付次数；和/或所述业务资源维度具体包括基于所述指定风险因子的支付金额。