CN110543498B - 一种基于事件触发的多方数据关联查询方法和装置 - Google Patents

Abstract

本发明涉及数据处理技术领域，具体提供了一种基于事件触发的多方数据关联查询方法和装置，方法包括：用户向数据使用方提交业务申请时触发对应的动作事件，并向数据打通平台发送触发请求；数据打通平台接收到触发请求后，按照预存的评估策略进行数据源访问和评估，并将评估结果反馈给数据使用方；数据使用方根据评估结果判断用户是否为当前业务的目标客户，并进行业务处理；其中，评估策略由数据使用方或数据打通平台预先制定，并保存在数据打通平台。本发明在数据使用方和数据源之间设置数据打通平台，数据使用方可根据需求借助该平台自行制定评估策略，既保护了用户隐私，又可使数据使用方根据自身需求获取所需的评估结果。

Description

一种基于事件触发的多方数据关联查询方法和装置

【技术领域】

本发明涉及数据处理技术领域，具体提供了一种基于事件触发的多方数据关联查询方法和装置。

【背景技术】

随着互联网的发展，网络已经成为发布信息、业务推广、服务客户、沟通员工的重要手段，用户越来越多地通过网络来满足自身的需求。当用户通过网站、APP或人工柜台向某个机构申请执行某项操作时，例如，用户通过网站、APP或人工柜台向某银行申请办理信用卡或申请贷款等等，该机构通常会先获取与用户申请的操作相对应的评估结果，然后根据该评估结果来判断用户是否适合执行其申请的操作，判断适合后该机构才会给用户权限来继续执行下一步操作。其中，与用户申请的操作相对应的评估结果是根据用户的历史相关数据得到的，而用户的历史相关数据均保存于数据源(即对应的信息数据库)处；针对不同的申请操作行为，数据源处还保存有相应的评估准则。

以用户申请的操作为办理信用卡为例，当用户通过网站、APP或人工柜台向某银行申请办理信用卡时，会触发银行向数据源处发送与办理信用卡相对应的评估结果获取请求；数据源处接收到请求后会进行相应的数据查询，并基于相应的评估准则和查询到的用户历史相关数据进行评估，得到与办理信用卡相对应的评估结果；最后数据源将得到的评估结果返回给该机构，以便该机构根据评估结果来判断是否允许用户继续办理信用卡。假设该用户之前曾申请过其他一个或多个银行的信用卡，且存在多次拖欠还款的行为，得到的评估结果为信用评分较低，则银行会阻止该用户继续办理信用卡。其中，由于机构需要利用由历史相关数据得到的评估结果，对应的机构也可称为“数据使用方”。

在上述方法中，由于考虑到用户的隐私保护问题，防止银行等数据使用方从数据源处获取到用户的个人信息，进而导致个人信息泄露，数据使用方与数据源之间无法直接打通，即数据使用方只能从数据源处获取到一个最后的评估结果，而该评估结果具体是根据什么评估准则和哪些用户历史相关数据得到，数据使用方一概不能得知；而且，数据使用方也无法根据自身的需求来制定评估准则，进而按照自己制定的评估准则对历史相关数据进行评估，得到所需的评估结果。其中，所述个人信息是指以电子或者其他方式记录的能够单独或者与其他信息结合识别自然人个人身份的各种信息，包括但不限于自然人的姓名、出生日期、身份证件号码、个人生物识别信息、住址等。

鉴于此，克服上述现有技术所存在的缺陷是本技术领域亟待解决的问题。

【发明内容】

本发明需要解决的技术问题是：

当数据使用方需要获取用户的评估结果时，数据使用方与数据源之间无法打通，数据使用方只能从数据源处获取到一个最后的评估结果，而无法得知对应的评估准则，也无法根据自身的需求来制定评估准则，进而得到所需的评估结果。

本发明通过如下技术方案达到上述目的：

第一方面，本发明提供了一种基于事件触发的多方数据关联查询方法，包括：

用户向数据使用方提交业务申请时触发对应的动作事件，并在动作事件的触发作用下向数据打通平台发送触发请求；

数据打通平台接收到所述触发请求后，按照预存的评估策略进行数据源访问和评估，并将得到的评估结果反馈给数据使用方；

数据使用方根据所述评估结果判断所述用户是否为当前业务的目标客户，并进行相应的业务处理；

其中，所述触发请求中携带有当前用户的用户标识，以便数据打通平台基于所述用户标识进行相应的数据源访问；

所述评估策略由数据使用方或数据打通平台预先制定，并保存在数据打通平台。

优选的，所述数据打通平台接收到所述触发请求后，按照预存的评估策略进行数据源访问和评估，并将得到的评估结果反馈给数据使用方，具体为：数据打通平台接收到所述触发请求后，将预存的评估策略传送给数据源，由数据源内部根据评估策略进行数据评估，并将得到的评估结果反馈给数据使用方。

优选的，所述数据打通平台接收到所述触发请求后，按照预存的评估策略进行数据源访问和评估，并将得到的评估结果反馈给数据使用方，具体为：

所述数据打通平台接收到携带用户标识的触发请求后，结合用户标识和预存的评估策略，从一个或多个数据源处进行用户的历史相关数据查询；

所述数据打通平台基于预存的评估策略对查询到的历史相关数据进行分析评估，得到对应的评估结果后反馈给数据使用方。

优选的，当仅有一个数据源时，所述数据打通平台包括数据驱动模块、数据策略定义模块和一个数据源代理，所述一个数据源代理与所述一个数据源对接；则所述评估策略的制定与保存过程具体为：

数据使用方根据自身业务的目标客户条件，通过所述数据策略定义模块制定相应的评估策略；

所述数据策略定义模块将制定好的评估策略发送给所述数据源代理；

其中，所述评估策略中包含与所述一个数据源对应的策略规则。

优选的，所述数据打通平台接收到所述触发请求后，按照预存的评估策略进行数据源访问和评估，并将得到的评估结果反馈给数据使用方，具体包括：

所述数据驱动模块接收到触发请求后，向所述数据源代理发送携带用户标识的驱动请求；

所述数据源代理接收到驱动请求后，结合用户标识和预存的评估策略从所述一个数据源处进行用户的历史相关数据访问查询；

所述数据源代理基于预存的评估策略对查询到的历史相关数据进行评估，并将得到的评估结果反馈给数据使用方。

优选的，当有至少两个数据源时，所述数据打通平台包括数据驱动模块、数据结果融合模块、数据策略定义模块和至少两个数据源代理，所述至少两个数据源代理分别与至少两个数据源对接；则所述评估策略的制定与保存过程具体为：

数据使用方根据自身业务的目标客户条件，通过所述数据策略定义模块制定相应的评估策略；其中，所述评估策略中包含融合规则以及与所述至少两个数据源分别对应的策略规则；

所述数据策略定义模块对制定好的评估策略进行识别和分解，并将分解出的各策略规则分别发送给对应的数据源代理，将分解出的融合规则发送给所述数据结果融合模块。

优选的，所述数据打通平台接收到所述触发请求后，按照预存的评估策略进行数据源访问和评估，并将得到的评估结果反馈给数据使用方，具体包括：

所述数据驱动模块接收到触发请求后，向所述数据结果融合模块发送携带用户标识的驱动请求；

所述数据结果融合模块接收到驱动请求后，分别向所述至少两个数据源代理发送携带用户标识的数据查询请求；

所述至少两个数据源代理接收到数据查询请求后，分别按照各自预存的策略规则进行对应的数据源访问评估，并将各自得到的评估结果反馈给所述数据结果融合模块；

所述数据结果融合模块对接收到的来自所述至少两个数据源代理的评估结果进行融合，并将融合后的评估结果反馈给数据使用方。

优选的，当所述动作事件具体为数据使用方对用户进行验证时，所述用户向数据使用方提交业务申请时触发对应的动作事件，并在动作事件的触发作用下向数据打通平台发送触发请求，具体为：

用户在数据使用方的网站、APP或人工柜台提交业务申请时，触发数据使用方通过运营商网络对用户进行验证；

在验证过程中，数据使用方或运营商网络向所述数据打通平台发送携带用户标识的触发请求，以便触发所述数据打通平台。

第二方面，本发明还提供了一种基于事件触发的多方数据关联查询装置，包括至少一个处理器和存储器，所述至少一个处理器和存储器之间通过数据总线连接，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令在被所述处理器执行后，用于完成第一方面所述的基于事件触发的多方数据关联查询方法

本发明的有益效果是：

本发明在数据使用方和数据源之间设置数据打通平台，由此将二者之间的交互交给第三方实现，数据使用方可根据需求借助该平台自行制定评估策略，平台再基于评估策略对数据源进行访问和评估，并将评估结果反馈给数据使用方。如此一来，既保护了用户隐私，避免数据使用方获取用户的个人信息导致信息泄露，又可使数据使用方根据自身需求获取所需的评估结果；

同时，当有多个数据源时，数据打通平台内设置有数据结果融合模块以及分别与多个数据源对接的多个数据源代理，通过多个数据源代理完成多个数据源的访问评估，再通过数据结果融合模块将多个评估结果进行融合，从而实现了多方数据的关联查询，评估更加全面、准确。

【附图说明】

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

图1为本发明实施例提供的一种基于事件触发的多方数据关联查询方法的流程图；

图2为本发明实施例提供的一种数据打通平台的交互示意图；

图3为本发明实施例提供的一种利用数据打通平台进行数据访问评估的流程图；

图4为本发明实施例提供的另一种利用数据打通平台进行数据访问评估的流程图；

图5为本发明实施例提供的一种数据打通平台的触发过程流程图；

图6为本发明实施例提供的一种数据使用方进行用户验证及触发数据打通平台时的框架示意图；

图7为本发明实施例提供的一种数据打通平台(与一个数据源对接)及其交互关系的框架图；

图8为本发明实施例提供的一种利用图7的数据打通平台进行数据访问评估的流程图；

图9为本发明实施例提供的另一种数据打通平台(与多个数据源对接)及其交互关系的框架图；

图10为本发明实施例提供的一种利用图9的数据打通平台进行评估策略的制定与保存的流程图；

图11为本发明实施例提供的一种利用图9的数据打通平台进行数据访问评估的流程图；

图12为本发明实施例提供的一种银行为数据使用方时的多方数据关联查询信令图；

图13为本发明实施例提供的一种银行为数据使用方时多方数据关联查询的业务流程框架图；

图14为本发明实施例提供的另一种基于事件触发的多方数据关联查询方法的流程图；

图15为本发明实施例提供的一种基于事件触发的多方数据关联查询装置的架构图。

【具体实施方式】

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明各实施方式的智能终端可以多种形式存在，该智能终端包括但不限于：

(1)移动通信设备：这类设备的特点是具备移动通信功能，并且以提供话音、数据通信为主要目标。这类终端包括:智能手机(例如iPhone)、多媒体手机、功能性手机，以及低端手机等。

(2)超移动个人计算机设备:这类设备属于个人计算机的范畴，有计算和处理功能，一般也具备移动上网特性。这类终端包括：PDA、MID和UMPC设备等，例如iPad。

(3)便携式娱乐设备：这类设备可以显示和播放视频内容，一般也具备移动上网特性。该类设备包括：视频播放器，掌上游戏机，以及智能玩具和便携式车载导航设备。

(4)服务器：提供计算服务的设备，服务器的构成包括处理器、硬盘、内存、系统总线等，服务器和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。例如，在本发明实施例中用户可以利用服务器运行一个或者多个虚拟智能终端，从而可以进行正常用户账号的登录。

此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。下面就参考附图和实施例结合来详细说明本发明。

实施例1：

本发明实施例提供了一种基于事件触发的多方数据关联查询方法，用于解决现有技术中数据使用方在进行数据评估时与数据源之间无法打通，数据使用方只能从数据源处获取到一个最后的评估结果，而无法得知对应的评估准则，也无法根据自身的需求来制定评估准则，进而得到所需的评估结果的问题。

为解决上述问题，本发明在数据使用方和数据源之间引入数据打通平台作为第三方，如图2所示，数据使用方具体可以是银行、医院、各种企业公司等，此处不做限定。借助该平台，本发明实施例提供的多方数据关联查询方法可参考图1，主要包括以下步骤：

步骤201，用户向数据使用方提交业务申请时触发对应的动作事件，并在动作事件的作用下向数据打通平台发送触发请求。

结合图2，用户需要办理某种业务时，通常会通过智能终端的网站或APP向数据使用方来提交业务申请，此时会触发一个相应的动作事件(所述动作事件为联动的线上动作事件，或者说联动的网络动作事件)。例如，数据使用方为银行，当用户通过网站或APP向银行申请贷款时，触发的动作事件为：银行对用户进行验证，一般是通过向智能终端发送随机验证码，再由用户填写验证码的方式来验证。在所述动作事件的触发下，会生成一个触发请求传递至数据打通平台，进而触发所述数据打通平台的后续动作，即步骤202中的一系列动作。

其中，数据源处存储有与多个用户标识相对应(即与多个用户相对应)的历史相关数据。为保证数据打通平台在进行数据访问评估时，及时查询到与当前用户对应的历史相关数据，进而得到对应的评估结果，所述触发请求中可携带有当前用户的用户标识，以便数据打通平台基于所述用户标识进行数据源访问。所述用户标识需能够表征用户的身份，可以是经过用户实名认证的手机号码，或者与所述手机号码绑定的QQ号、微信号、易信号、飞信号、邮箱、储蓄卡号或者信用卡号等。当用户在网站、APP或柜台提交业务申请时，通常会填写对应的用户标识，此时数据使用方就获取了用户标识，进而将用户标识携带在触发请求中发送给数据打通平台。

步骤202，数据打通平台接收到所述触发请求后，按照预存的评估策略进行数据源访问和评估，并将得到的评估结果反馈给数据使用方。

所述评估策略可由数据使用方或数据打通平台预先制定，并保存在数据打通平台。当由数据使用方制定时，数据使用方根据自身业务的目标客户条件，通过数据打通平台制定相应的评估策略，并将评估策略保存在数据打通平台。当由数据打通平台制定时，数据使用方先将自身业务的目标客户条件或策略制定要求反馈给数据打通平台，所述数据打通平台基于此来制定相应的评估策略并保存；此时，评估策略虽然不是由数据使用方制定，但对数据使用方是透明化的，而且也是根据数据使用方的需求来制定的，满足使用要求。其中，所述评估策略中规定了，评估用户是否适合办理当前业务时所需要的一项或多项历史相关数据、对所述一项或多项历史相关数据进行分析总结的规则或进行评分的计算规则等等，在此不做具体限定。

其中，数据源的数量可以是一个或多个，不同的数据源存储有不同类的历史相关数据，具体数量可根据数据使用方的需求来决定。例如，如果数据使用方当前的业务比较重要，需要借助于更完整的数据源，得到更全面、准确的评估效果，则此时需要多个数据源，利用数据打通平台进行多方数据关联查询，即先分别对各数据源进行访问评估，得到对应各数据源的评估结果，再将各评估结果进行关联融合；如果当前业务比较简单，评估时无需过多的数据分析，则可能仅需要一个数据源即可。数据源的数量越多，包含的数据内容越丰富，评估结果也就越准确；相应地，数据打通平台对接的数据源数量不同，向数据使用方收取的价格也可以设置为不同，由数据使用方根据自身需求来合理地选择。

步骤203，数据使用方根据所述评估结果判断所述用户是否为当前业务的目标客户，并进行相应的业务处理。

如果判断所述用户为当前业务的目标客户，表示用户满足办理其申请业务的条件，则数据使用方同意所述用户的业务申请，用户可继续进行下一步操作；否则，数据使用方拒绝所述用户的业务申请，用户无法继续操作。例如，当用户在银行申请办理贷款时，对应的评估结果可以是所述用户的信用评分，银行可将得到的该信用评分与办理贷款业务的标准信用分进行比较；如果信用评分高于标准信用分，用户为贷款业务的目标客户，则银行同意该用户提交的贷款申请，如果信用评分低于标准信用分，用户不是贷款业务的目标客户，则银行拒绝该用户提交的贷款申请。

本发明提供的上述方法中，在数据使用方和数据源之间设置数据打通平台，由此将二者之间的交互交给第三方实现，数据使用方可根据需求借助该平台自行制定评估策略，平台再基于评估策略对数据源进行访问和评估，并将评估结果反馈给数据使用方。如此一来，既保护了用户隐私，避免数据使用方获取用户的个人信息导致信息泄露，又可使数据使用方根据自身需求获取所需的评估结果。

在所述步骤201-203中，步骤201主要是通过用户的动作来触发所述数据打通平台的动作，步骤202主要是介绍所述数据打通平台在触发下的动作(如数据访问、评估和结果反馈等)，步骤203主要是指数据使用方对评估结果的使用。

其中，所述数据打通平台内预存的评估策略可有一个或多个。当数据使用方的业务类型比较单一，仅有一个业务需要使用数据打通平台来进行数据关联查询，则所述数据打通平台中仅预存一个评估策略即可，该评估策略即与当前用户申请业务相对应的评估策略。

当所述数据打通平台内仅预存一个评估策略时，参考图3，所述数据打通平台接收到所述触发请求后，按照预存的评估策略进行数据源访问和评估，并将得到的评估结果反馈给数据使用方，即步骤202，具体又包括以下步骤：

步骤2021，所述数据打通平台接收到携带用户标识的触发请求后，结合用户标识和预存的评估策略，从一个或多个数据源处进行用户的历史相关数据查询。

所述触发请求用于触发或激活所述数据打通平台，根据所述触发请求中携带的用户标识，所述数据打通平台能够从数据源处获取与当前用户身份相对应的历史相关数据；而根据预存的评估策略，所述数据打通平台能够确定在该用户的历史相关数据中，哪些数据是进行当前评估所需要的。因此，结合用户标识和评估策略，数据打通平台方可更准确地查询到所需要的数据。

步骤2022，所述数据打通平台基于预存的评估策略对查询到的历史相关数据进行分析评估，得到对应的评估结果后反馈给数据使用方。

如果数据源的数量为一个，则所述数据打通平台可直接根据评估策略对查询到的对应当前用户的历史相关数据进行评估，得到最终的评估结果。如果数据源的数量为多个(即至少两个)，则所述数据打通平台需要分别针对从各个数据源查询的数据进行评估，再将各数据源对应的评估结果进行关联融合，将融合后的评估结果反馈给数据使用方。

当数据使用方的业务类型多样化(例如，银行的业务类型有办理贷款、办理信用卡、办理存款等等)，而且多项业务都需要使用数据打通平台来进行数据关联查询时，则不同的业务类型需要制定不同的评估策略。此时，数据使用方为了使用方便，前期制定评估策略时可分别针对不同的业务类型制定相应的评估策略，并将制定好评估策略都预先保存在数据打通平台内，即，所述数据打通平台内预存有多个评估策略，分别对应数据使用方的不同业务。为了区分不同业务对应的评估策略，每个评估策略在制定中携带有对应的业务标识；相应地，除用户标识以外，所述触发请求中还携带有与当前用户申请业务相对应的业务标识，以便后续所述数据打通平台进行匹配。

在上述情况下，所述数据打通平台接收到所述触发请求后，按照预存的评估策略进行数据源访问和评估，并将得到的评估结果反馈给数据使用方，即步骤202，具体可参考图3，包括以下步骤：

步骤2021’，所述数据打通平台接收到携带用户标识和业务标识的触发请求后，结合业务标识从预存的多个评估策略中匹配出与当前业务对应的评估策略。

步骤2022’，所述数据打通平台结合用户标识和匹配出的评估策略，从一个或多个数据源处进行用户的历史相关数据查询。

步骤2023’，所述数据打通平台基于匹配出的评估策略对查询到的历史相关数据进行分析评估，得到对应的评估结果后反馈给数据使用方。

通过步骤2021’-2023’，在所述数据打通平台内预存有多个评估策略时，数据打通平台可根据数据使用方发送的业务标识进行评估策略的匹配，进而直接反馈给所述数据使用方所需要的评估结果。但是，如此一来，一方面所述数据使用方需要发送业务标识，这会增加数据使用方在使用平台时的复杂度；另一方面，有时所述数据使用方可能会出于保护公司内部业务信息和用户办理业务隐私的考虑，不希望所述数据打通平台得知用户当前在数据使用方办理的具体业务类型，而如果在触发请求中携带业务标识就会将相关办理的业务信息泄露给所述数据打通平台，这是数据使用方不希望看到的结果。

因此，鉴于上述考虑，当所述数据打通平台内预存有多个评估策略时，除步骤2021’-2023’以外，所述步骤202具体还可按照以下步骤执行：

首先，所述数据打通平台接收到携带用户标识的触发请求后，结合用户标识和预存的多个评估策略，从一个或多个数据源处进行用户的历史相关数据查询。

然后，所述数据打通平台分别基于预存的多个评估策略对查询到的历史相关数据进行分析评估，得到对应的多个评估结果后反馈给数据使用方，以便数据使用方根据需求从多个评估结果中选择用于支撑当前业务的评估结果。如此一来，所述数据打通平台无法确定用户在数据使用方正在办理的业务类型，因此基于每个评估策略都得到相应的评估结果，最终反馈给数据使用方的是一个包含有多个评估结果的列表，再由数据使用方根据当前业务选择所需要使用的评估结果即可。这样既保护了公司内部信息和用户隐私，避免信息泄露，又能够得到所需的评估结果。

进一步地，在步骤201中，所述动作事件通常为数据使用方对用户进行验证；例如，用户通过网站、APP或人工柜台在银行办理贷款、办理信用卡以及其他各种业务申请时，在用户填写信息过程中，银行会通过向手机发送验证码的方式对用户进行验证，用户将正确的验证码填写至网站、APP或人工柜台后验证成功。在一个具体的实施例中，所述动作事件具体为数据使用方对用户进行验证，参考图5，所述步骤201具体可包括以下步骤：

步骤2011，用户在数据使用方的网站、APP或人工柜台提交业务申请时，触发数据使用方通过运营商网络对用户进行验证。

其中，验证是通过随机发送验证码来完成，所述验证码由网站、APP或人工柜台随机生成，或者由运营商网络的信息平台、行业短信网关、运营商短信网关中心、运营商彩信网关中心或短信内容过滤平台等随机生成。结合图6，智能终端、数据使用方的APP/网站/人工柜台和运营商网络之间构成的闭环即为用户的验证过程。

当所述验证码由网站、APP或人工柜台随机生成时，验证过程具体为：用户通过智能终端，并利用对应的用户标识在数据使用方的网站、APP或人工柜台提交业务申请时，触发所述网站、APP或人工柜台随机生成一个验证码；所述网站、APP或人工柜台将所述用户标识和所述验证码发送至运营商网络；所述运营商网络将所述验证码发送至对应用户标识的智能终端，以便用户在所述网站、APP或人工柜台进行验证码的填写。当用户将正确的验证码填写在网站、APP或人工柜台时，数据使用方对用户的验证成功；其中，所述用户标识通常为手机号码。

当所述验证码由运营商网络随机生成时，验证过程具体为：用户通过智能终端，并利用对应的用户标识在数据使用方的网站、App或人工柜台提交业务申请时，触发所述网站、APP或人工柜台生成携带用户标识的短信验证请求；所述网站、APP或人工柜台将携带用户标识的短信验证请求发送至运营商网络；所述运营商网络接收到短信验证请求后随机生成一个验证码，并将所述验证码发送至对应用户标识的智能终端，以便用户在所述网站、APP或人工柜台进行验证码的填写。当用户将正确的验证码填写在网站、APP或人工柜台时，数据使用方对用户的验证成功；其中，所述用户标识通常为手机号码。

步骤2012，在验证过程中，数据使用方或运营商网络向所述数据打通平台发送携带用户标识的触发请求，以便触发所述数据打通平台。

继续参考图6，在进行用户验证的过程中，可采用两种方式来触发或激活所述数据打通平台的动作，一种是由数据使用方向所述数据打通平台发送携带用户标识的触发请求，另一种则是由运营商网络向所述数据打通平台发送携带用户标识的触发请求(如图中虚线箭头所示)；两种方式择一。其中，当所述数据打通平台预存有对应多个不同业务的多个评估策略时，所述触发请求中还携带有与当前业务相对应的业务标识。所述数据打通平台接收到所述触发请求后，即可在触发作用下执行步骤202中的一系列操作，完成数据访问、评估和反馈。

实施例2：

由实施例1可知，数据源的数量可以是一个或多个，则数据打通平台可基于一方或多方数据源进行数据访问评估。在实施例1的基础上，本发明实施例分别以仅有一个数据源和至少两个数据源为例，结合如图7和图9所示的框架图，提供了两种基于事件触发的多方数据关联查询方法的具体实现过程。同时，本发明实施例以所述数据打通平台内仅预存一个评估策略为例展开，当所述数据打通平台内预存多个评估策略时，在本发明实施例的基础上增加业务标识和评估策略匹配的过程即可，或者在无业务标识的场景下，增加数据使用方根据使用需求从多个评估结果中选择支撑当前业务的评估结果的过程即可，此处不再赘述。

在一个具体的实施例中，仅有一个数据源；参考图7，所述数据打通平台包括数据驱动模块、数据策略定义模块和一个数据源代理，所述一个数据源代理与所述一个数据源对接，处于数据源的私有网络中。图中用户、APP/网站/柜台、数据驱动模块间的实线箭头表示用户动作，导致所述触发请求的生成和发送，其余实线箭头表示数据打通平台在触发请求的触发下进行的一系列相关动作，虚线箭头表示评估策略的定义和分发。

当仅有一个数据源时，所述评估策略的制定与保存过程可参考图7中的虚线箭头，具体为：数据使用方根据自身业务的目标客户条件，通过所述数据策略定义模块制定相应的评估策略；所述数据策略定义模块将制定好的评估策略发送给所述数据源代理保存。其中，所述评估策略中包含与所述一个数据源对应的策略规则，即，该评估策略可基于所述一个数据源处存储的数据进行评估。

进一步参考图8，当仅有一个数据源时，所述数据打通平台接收到所述触发请求后，按照预存的评估策略进行数据源访问和评估，并将得到的评估结果反馈给数据使用方，具体可结合如图6中较粗的实线箭头所示，包括以下步骤：

步骤301，所述数据驱动模块接收到触发请求后，向所述数据源代理发送携带用户标识的驱动请求。

步骤302，所述数据源代理接收到驱动请求后，结合用户标识和预存的评估策略从所述一个数据源处进行用户的历史相关数据访问查询。

根据所述用户标识，所述数据源代理能够从所述数据源处获取与当前用户身份相对应的历史相关数据；而根据评估策略，所述数据源代理能够确定哪些历史相关数据是进行当前评估所需要的。因此，结合用户标识和评估策略，所述数据源代理方可更准确地查询到所需要的数据。

步骤303，所述数据源代理基于预存的评估策略对查询到的历史相关数据进行评估，并将得到的评估结果反馈给数据使用方。

在另一个具体的实施例中，有至少两个数据源，不同数据源分别存储有不同的数据；参考图9，所述数据打通平台包括数据驱动模块、数据结果融合模块、数据策略定义模块和至少两个数据源代理，所述至少两个数据源代理分别与至少两个数据源对接；图中数据源与数据源代理的数量均为N(N≥2)，分别记为数据源1、...、数据源N以及数据源代理1、...、数据源代理N，所述至少两个数据源代理分别与至少两个数据源按照标号顺序一一对应。图中用户、APP/网站/柜台、数据驱动模块间的实线箭头表示用户动作，导致所述触发请求的生成和发送，其余实线箭头表示数据打通平台在触发请求的触发下进行的一系列相关动作，虚线箭头表示评估策略的定义、分解和分发。

当有至少两个数据源时，所述评估策略的制定与保存过程可参考图9中的虚线箭头和图10，具体包括：

步骤101，数据使用方根据自身业务的目标客户条件，通过所述数据策略定义模块制定相应的评估策略；其中，所述评估策略中包含融合规则以及与所述至少两个数据源分别对应的策略规则。

其中，各策略规则需基于对应的数据源处存储的数据进行分析评估，对应于不同数据源的不同策略规则，在制定过程中可分别设置不同的标签，融合规则也相应地设置区别于各策略规则的标签。

步骤102，所述数据策略定义模块对制定好的评估策略进行识别和分解，并将分解出的各策略规则分别发送给对应的数据源代理，将分解出的融合规则发送给所述数据结果融合模块。

在进行识别和分解时，具体可根据各策略规则和融合规则所携带的标签来判断各条规则的归属，判断完成后进行分发。在图9中，数据源与数据源代理的数量均为N，则评估策略相应地可分解出N个策略规则，分解完成后，策略规则1发送至数据源代理1，策略规则2发送至数据源代理2，...，策略规则N发送至数据源代理N，融合规则发送至所述数据结果融合模块。

进一步参考图11，当有至少两个数据源时，所述数据打通平台接收到所述触发请求后，按照预存的评估策略进行数据源访问和评估，并将得到的评估结果反馈给数据使用方，具体可结合如图9中较粗的实线箭头所示，包括以下步骤：

步骤301’，所述数据驱动模块接收到触发请求后，向所述数据结果融合模块发送携带用户标识的驱动请求。

步骤302’，所述数据结果融合模块接收到驱动请求后，分别向所述至少两个数据源代理发送携带用户标识的数据查询请求。

步骤303’，所述至少两个数据源代理接收到数据查询请求后，分别按照各自预存的策略规则进行对应的数据源访问评估，并将各自得到的评估结果反馈给所述数据结果融合模块。

结合图9，数据源代理1接收到数据查询请求后，结合用户标识和自身预存的策略规则1，对数据源1进行数据访问评估，并将得到的评估结果1反馈给所述数据结果融合模块；按照对应关系以此类推，数据源代理N接收到数据查询请求后，结合用户标识和自身预存的策略规则N，对数据源N进行数据访问评估，将得到的评估结果N反馈给所述数据结果融合模块。

步骤304’，所述数据结果融合模块对接收到的来自所述至少两个数据源代理的评估结果进行融合，并将融合后的评估结果反馈给数据使用方。

所述数据结果融合模块接收到来自N个数据源代理的评估结果1、评估结果2、...、评估结果N后，按照自身预存的融合规则对N个评估结果进行融合，将融合后的评估结果反馈给数据使用方。

在上述两个具体实施例中，当办理业务比较简单，仅有一个数据源时，可采用如图7所示的数据打通平台来完成数据使用方和数据源之间的交互，由于仅有一个数据源，可无需设置数据结果融合模块，在评估过程中也无需进行融合，流程更简单，评估速度更快。当办理业务比较复杂，需要更多的数据源时，可采用如图9所示的数据打通平台来完成数据使用方和多个数据源之间的交互，此时需要设置数据结果融合模块，在评估过程需对各数据源代理的评估结果进行融合，虽然流程变复杂，但最终得到的评估结果更全面、更准确。因此，两种装置和方法各有一定的优势，数据使用方可根据自身需求选用合适的数据打通平台，来完成对用户的评估。

实施例3：

在上述实施例2的基础上，本发明实施例以数据使用方为银行为例，结合图12所示的信令结构图，阐述了办理三种不同银行业务的应用场景下，基于事件触发的多方数据关联查询方法的具体实现过程。

其中，此处银行选取的数据打通平台对接的数据源有两个，分别为银行数据源和运营商数据源；所述银行数据源存有银行自身的用户数据，所述运营商数据源存有运营商的网络行为数据，可反映用户的行为情况。图中虚线框内的结构表示数据打通平台，所述数据打通平台包括数据策略定义模块、数据驱动模块、数据结果融合模块和两个数据源代理，两个数据源代理分别记为银行侧数据源代理和运营商侧数据源代理，并分别与银行数据源和运营商数据源对接。

在本发明实施例中，针对银行的三种不同应用场景分别为：场景一，银行使用本平台进行用户贷前审核；场景二，银行使用本平台进行用户关怀；场景三，银行使用本平台跟踪已贷款客户的贷款使用情况。

对于场景一(即银行使用本平台进行用户贷前审核)，参考图12，具体实现过程如下：

在步骤401中，银行通过所述数据策略定义模块，针对贷前审核业务进行策略定义，制定出相应的评估策略。

其中，该评估策略中包含了分别对应银行数据源和运营商数据源的策略规则，以及融合规则。对应银行数据源的策略规则中，规定银行数据源中可反应用户经济情况的相关数据为重要参考；对应运营商数据源的策略规则中，规定用户的网龄、用户注册的互联网金融公司情况等为重要参考。

在步骤402、402’和402”中，所述数据策略定义模块对制定好的评估策略进行识别和分解，分别将分解出的融合规则送入所述数据结果融合模块，将属于银行数据源的对应策略规则送入所述银行侧数据源代理，将属于运营商数据源的对应策略规则送入所述运营商侧数据源代理。

在步骤403中，当用户通过银行的APP或网站或柜台向银行申请某种信贷业务时，触发银行的验证流程，使得银行通过运营商网络对用户进行验证。具体可通过发送验证码的形式来验证，详见实施例1中的相关介绍。

在步骤404中，银行通过运营商网络对用户进行验证的过程中，向所述数据驱动模块发送携带用户标识的触发请求，以便触发所述数据打通平台动作。

在步骤405中，所述数据驱动模块接收到触发请求后，向所述数据结果融合模块发送携带用户标识的驱动请求。

在步骤406和406’中，所述数据结果融合模块接收到驱动请求后，分别向银行侧数据源代理和运营商侧数据源代理发送携带用户标识的数据查询请求。

在步骤407和407’中，所述银行侧数据源代理接收到数据查询请求后，按照用户标识以及预存的属于银行数据源的策略规则，对银行数据源进行访问评估，得到银行侧的评估结果；所述运营商侧数据源代理接收到数据查询请求后，按照用户标识以及预存的属于运营商数据源的策略规则，对运营商数据源进行访问评估，得到运营商侧的评估结果。

在步骤408和408’中，所述银行侧数据源代理将银行侧的评估结果反馈给所述数据结果融合模块，所述运营商侧数据源代理将运营商侧的评估结果反馈给所述数据结果融合模块。

在步骤409中，所述数据结果融合模块接收到银行侧和运营商侧的评估结果后，按照预存的融合规则将两个评估结果进行融合，并将融合后的评估结果反馈给银行。

在步骤410中，银行根据数据打通平台反馈回来的评估结果，判断用户是否为办理信贷业务的目标客户；如果是目标客户，则同意用户提交的信贷业务申请，如果不是目标客户，则拒绝用户提交的信贷业务申请；相应的审核结果(即同意或拒绝)会通过相应的APP或网站或柜台显示给用户，以便用户及时知晓审核结果。

例如，假设银行侧的评估结果为：当前用户的经济能力中等，无不良记录；运营商侧的评估结果为：当前用户网龄不足6个月，且用户注册的互联网金融公司数量超过10个；融合后的评估结果显示：当前用户办理信贷业务的风险结果高于平均值；那么，最终银行根据该评估结果拒绝用户提交的信贷业务申请。

对于场景二(即银行使用本平台进行用户关怀)，具体实现过程仍可参考图11，与场景一的不同之处在于：

在步骤401中，银行通过所述数据策略定义模块，针对客户关系维护业务进行策略定义，制定出相应的评估策略。其中，该评估策略中包含了分别对应银行数据源和运营商数据源的策略规则，以及融合规则。对应银行数据源的策略规则中，规定银行数据源中可反应用户客户级别的相关数据为重要参考；对应运营商数据源的策略规则中，规定用户的出行方式、出行频率、用户的网站访问情况等为重要参考。

在步骤403中，当用户通过银行的APP或网站或柜台在银行办理业务时，触发银行的验证流程。其余各流程均可参考场景一对应的相关介绍，在此不做赘述。

其中，假设银行目前正在推出的业务为：高端客户易登机业务和积分换视频网站VIP的活动业务。银行侧的评估结果为：当前用户符合VIP用户标准；运营商侧的评估结果为：当前用户的出差频率为1月4次以上，且均搭乘飞机出行；融合后的评估结果显示：当前用户在银行推出的高端客户易登机业务匹配度为90％，而在银行推出的积分换视频网站VIP的活动业务匹配度为25％。那么，最终银行根据客户关怀业务匹配结果给用户提供高端客户易登机业务，方便客户在机场享受银行VIP业务。

对于场景三(即银行使用本平台跟踪已贷款客户的贷款使用情况)，具体实现过程仍可参考图11，与场景一的不同之处在于：

在步骤401中，银行通过所述数据策略定义模块，针对贷后信息跟踪调查业务进行策略定义，制定出相应的评估策略。其中，该评估策略中包含了分别对应银行数据源和运营商数据源的策略规则，以及融合规则。对应银行数据源的策略规则中，规定银行数据源中可反应用户还款情况的相关数据为重要参考；对应运营商数据源的策略规则中，规定用户是否有其他银行的通讯记录、是否有新增银行账户绑定记录等为重要参考。

在步骤403中，当用户通过银行的APP或网站或柜台提交银行下发的线上贷后信息跟踪调查表时，触发银行的验证流程。其余各流程均可参考场景一对应的相关介绍，在此不做赘述。

其中，假设银行侧的评估结果为：当前用户在还款期间有1到2笔的短时逾期，无逾期罚息；运营商侧的评估结果为：当前用户在还款期间有新增银行账户绑定记录，并有其他银行的被叫通讯记录，频率为1周4次；融合后的评估结果显示：当前用户的多头共债情况匹配度为75％。那么，最终银行根据该评估结果，将当前用户判定为重点观察客户，安排客户经理跟进，并重新规划客户的还款计划。

当然，除上述三种典型的应用场景以外，银行办理其他业务时的多方数据关联查询方法具体实现过程也可参考图12和上述的步骤介绍。

实施例4：

在实施例3的基础上，本发明实施例继续结合图13所示的框架图，阐述一种基于事件触发的多方数据关联查询方法的具体实现过程。结合图13，在该场景下，数据使用方仍为银行，具体又包括银行业务部门、银行数据部门和银行需求部门；其中，用户通过APP或网站或柜台办理业务时，所述银行业务部门用于进行业务对接处理；所述银行数据部门用户数据的接收、处理和发送，与所述银行业务部门提供数据支撑；所述银行需求部门掌握着银行的业务需求，因此可负责评估策略的制定。

此处银行选取的数据打通平台对接的数据源有N个(N≥2)，分别记为数据源1、...、数据源N，所述数据打通平台包括数据策略定义模块、数据驱动模块、数据结果融合模块和N个数据源代理，N个数据源代理分别记为数据源代理1、...、数据源代理N，并分别与数据源1、...、数据源N，对接。所述银行需求部门与所述数据策略定义模块之间通过需求管理平台连接，所述数据结果融合模块与所述银行数据部门之间通过增强网关连接。

其中，在所述数据打通平台中，所述数据策略定义模块相当于管理服务部分，所述数据结果融合模块相当于控制服务部分；此处银行通过运营商网络的信息平台来进行用户验证，因此所述数据驱动模块具体也可称为短信处理模块。

当数据使用方为银行时，参考图13中的数据打通平台框架图，基于事件触发的多方数据关联查询方法的具体实现过程如下：

在步骤501中，所述银行需求部门根据自身业务的目标客户条件，通过所述需求管理平台进行策略定义。

在步骤502中，所述需求管理平台将相关的策略定义传递给所述数据策略定义模块，由所述数据策略定义模块根据策略定义制定相应的评估策略。其中，所述评估策略中包含对应于各数据源的策略规则，以及融合规则，各规则分别设置有不同的标签。

在步骤503中，所述数据策略定义模块根据各规则的标签，对制定好的评估策略进行识别和分解，并将分解出的各策略规则分别发送给对应的数据源代理，将分解出的融合规则发送给所述数据结果融合模块。

在步骤504中，用户通过智能终端的APP或网站或柜台向所述银行业务部门提交业务申请。

在步骤505中，所述银行业务部门接收到业务申请后，通过所述信息平台对用户进行验证。其中，验证是通过随机发送验证码来完成，具体验证过程可参考实施例1中的步骤2011：一种是由网站、APP或柜台随机生成一个验证码，并由所述银行业务部门将用户标识和验证码发送至信息平台，所述信息平台再将验证码发送至对应用户标识的智能终端，以便用户进行验证码的填写；另一种方法是网站、APP或柜台生成携带用户标识的短信验证请求，并发送给信息平台，由所述信息平台随机生成一个验证码，并将所述验证码发送至对应用户标识的智能终端。当用户将正确的验证码填写在银行的网站或、APP或柜台时，用户验证成功。

在步骤506中，所述银行业务部门通过信息平台对用户进行验证时，通过发送触发请求来触发所述数据打通平台。具体有两种方式：一种是由所述银行业务部门发送携带用户标识的触发请求来通知所述数据驱动模块(短信处理模块)；另一种是由所述信息平台发送携带用户标识的触发请求来通知所述数据驱动模块(短信处理模块)；两种方式择一即可。

在步骤507中，所述数据驱动模块接收到触发请求后，向所述数据结果融合模块发送携带用户标识的驱动请求。

在步骤508中，所述数据结果融合模块接收到驱动请求后，分别向各数据源代理(数据源代理1、...、数据源代理N)发送携带用户标识的数据查询请求。

在步骤509中，各数据源代理接收到数据查询请求后，按照用户标识和各自预存的策略规则对相对接的数据源进行访问评估，得到各自的评估结果。

在步骤510中，各数据源代理将各自的评估结果反馈给所述数据结果融合模块。

在步骤511中，所述数据结果融合模块接收到来自各数据源代理的评估结果后，对各评估结果进行融合，并将融合后的评估结果发送至增强网关。

在步骤512中，所述增强网关接收到融合后的评估结果后，将所述评估结果推送给所述银行数据部门。

在步骤513中，所述银行数据部门将所述评估结果转发给所述银行业务部门，为所述银行业务部门提供业务处理的参考。

实施例5：

上述实施例1-实施例4提供的基于事件触发的多方数据关联查询方法中，有一个共同之处：所述数据打通平台可获取数据源处的相关数据，获取数据后再根据评估策略进行数据评估，并将评估结果反馈给数据使用方。然而，在实际使用过程中，有些数据源出于保护自身数据的考虑，并不希望所述数据打通平台直接从数据源处获取相应的数据，也就是说并不会向所述数据打通平台开放数据获取权限。鉴于上述考虑，本发明实施例提供了一种区别于前述各实施例的多方数据关联查询方法。

与前述实施例的不同之处在于：本发明实施例中所述数据打通平台不会获取数据源处的相关数据，而是将评估策略传送给数据源，由数据源内部进行评估后将对应的评估结果反馈给数据打通平台。如此一来，就可避免数据源处的数据外泄给数据打通平台，保护数据安全。如图14所示，本发明实施例提供的多方数据关联查询方法主要包括以下步骤：

步骤201’，用户向数据使用方提交业务申请时触发对应的动作事件，并在动作事件的作用下向数据打通平台发送触发请求。

步骤202’，数据打通平台接收到所述触发请求后，将预存的评估策略传送给数据源，由数据源内部根据评估策略进行数据评估，并将得到的评估结果反馈给数据使用方。

当所述数据打通平台内仅预存一个评估策略时，所述数据打通平台接收到携带用户标识的触发请求后，直接将对应的用户标识和预存的评估策略传送给数据源；数据源基于接收到的用户标识和评估策略，对自身内部关于该用户的相关数据进行分析评估，得到对应的评估结果后反馈给所述数据打通平台，再由数据打通平台将评估结果反馈给数据使用方。

当所述数据打通平台内预存有多个评估策略时，所述数据打通平台接收到携带用户标识和业务标识的触发请求后，结合业务标识从预存的多个评估策略中匹配出与当前业务对应的评估策略，然后将用户标识和匹配出的评估策略传送给数据源；数据源基于接收到的用户标识和评估策略，对自身内部关于该用户的相关数据进行分析评估，得到对应的评估结果后反馈给数据打通平台，再由数据打通平台将评估结果反馈给数据使用方。

或者，当所述数据打通平台内预存有多个评估策略时，所述数据打通平台接收到携带用户标识的触发请求后，直接将对应的用户标识和预存的多个评估策略传送给数据源；数据源基于接收到的多个评估策略，分别对自身内部关于该用户的相关数据进行分析评估，得到对应的多个评估结果后反馈给所述数据打通平台，再由数据打通平台将多个评估结果反馈给数据使用方，以便数据使用方根据需求从多个评估结果中选择用于支撑当前业务的评估结果。

步骤203’，数据使用方根据所述评估结果判断所述用户是否为当前业务的目标客户，并进行相应的业务处理。

其中，步骤201’的具体介绍可参考实施例1中的步骤201，步骤203’的具体介绍可参考实施例1中的步骤203，在此不再赘述。

需要说明的是，本发明实施例与前述各实施例的区别仅在于：数据打通平台无法从数据源处获取数据，因此将评估策略传送给数据源后由数据源进行数据评估，数据打通平台仅从数据源处获取相应的评估结果。除此以外，其余的执行过程仍可参考前述各实施例，具体的模块结构组成也可参考前述各实施例，区别仅在于数据源代理的功能发生变化，即不能再从数据源处获取数据，而是传送评估策略给数据源，再从数据源处获取相应的评估结果。因此，前述各实施例中描述的具体执行步骤仍可适用于本发明实施例，在此不一一赘述。

实施例6：

在上述实施例1-实施例5提供的基于事件触发的多方数据关联查询方法的基础上，本发明还提供了一种可用于实现上述方法的基于事件触发的多方数据关联查询装置，如图15所示，是本发明实施例的装置架构示意图。本实施例的基于事件触发的多方数据关联查询装置包括一个或多个处理器21以及存储器22。其中，图15中以一个处理器21为例。

所述处理器21和所述存储器22可以通过总线或者其他方式连接，图15中以通过总线连接为例。

所述存储器22作为一种基于事件触发的多方数据关联查询方法非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块，如实施例1-实施例5中的基于事件触发的多方数据关联查询方法。所述处理器21通过运行存储在所述存储器22中的非易失性软件程序、指令以及模块，从而执行基于事件触发的多方数据关联查询装置的各种功能应用以及数据处理，即实现实施例1-实施例5的基于事件触发的多方数据关联查询方法。

所述存储器22可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，所述存储器22可选包括相对于所述处理器21远程设置的存储器，这些远程存储器可以通过网络连接至所述处理器21。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

所述程序指令/模块存储在所述存储器22中，当被所述一个或者多个处理器21执行时，执行上述实施例1-实施例5中的基于事件触发的多方数据关联查询方法，例如，执行以上描述的图1、图3和图4所示的各个步骤。

本领域普通技术人员可以理解实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取存储器(RAM，RandomAccessMemory)、磁盘或光盘等。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (12)

1.一种基于事件触发的多方数据关联查询方法，其特征在于，包括：

用户向数据使用方提交业务申请时触发对应的动作事件，并在动作事件的触发作用下向数据打通平台发送触发请求；

数据打通平台接收到所述触发请求后，按照预存的评估策略进行数据源访问和评估，并将得到的评估结果反馈给数据使用方；

数据使用方根据所述评估结果判断所述用户是否为当前业务的目标客户，并进行相应的业务处理；

其中，所述触发请求中携带有当前用户的用户标识，以便数据打通平台基于所述用户标识进行相应的数据源访问；

所述评估策略由数据使用方或数据打通平台预先制定，并保存在数据打通平台；

当仅有一个数据源时，所述数据打通平台包括数据驱动模块、数据策略定义模块和一个数据源代理，所述一个数据源代理与所述一个数据源对接；则所述评估策略的制定与保存过程具体为：

数据使用方根据自身业务的目标客户条件，通过所述数据策略定义模块制定相应的评估策略；

所述数据策略定义模块将制定好的评估策略发送给所述数据源代理；

其中，所述评估策略中包含与所述一个数据源对应的策略规则。

2.根据权利要求1所述的基于事件触发的多方数据关联查询方法，其特征在于，所述数据打通平台内预存有当前用户申请业务对应的一个评估策略，则所述数据打通平台接收到所述触发请求后，按照预存的评估策略进行数据源访问和评估，并将得到的评估结果反馈给数据使用方，具体为：

所述数据打通平台接收到携带用户标识的触发请求后，结合用户标识和预存的评估策略，从一个或多个数据源处进行用户的历史相关数据查询；

所述数据打通平台基于预存的评估策略对查询到的历史相关数据进行分析评估，得到对应的评估结果后反馈给数据使用方。

3.根据权利要求1所述的基于事件触发的多方数据关联查询方法，其特征在于，所述数据打通平台内预存有多个评估策略，分别对应数据使用方的不同业务，且每个评估策略中携带有对应的业务标识；相应地，所述触发请求中还携带有当前用户申请业务对应的业务标识；

则所述数据打通平台接收到所述触发请求后，按照预存的评估策略进行数据源访问和评估，并将得到的评估结果反馈给数据使用方，具体为：

所述数据打通平台接收到携带用户标识和业务标识的触发请求后，结合业务标识从预存的多个评估策略中匹配出与当前业务对应的评估策略；

所述数据打通平台结合用户标识和匹配出的评估策略，从一个或多个数据源处进行用户的历史相关数据查询；

所述数据打通平台基于匹配出的评估策略对查询到的历史相关数据进行分析评估，得到对应的评估结果后反馈给数据使用方。

4.根据权利要求1所述的基于事件触发的多方数据关联查询方法，其特征在于，所述数据打通平台内预存有多个评估策略，分别对应数据使用方的不同业务；则所述数据打通平台接收到所述触发请求后，按照预存的评估策略进行数据源访问和评估，并将得到的评估结果反馈给数据使用方，具体为：

所述数据打通平台接收到携带用户标识的触发请求后，结合用户标识和预存的多个评估策略，从一个或多个数据源处进行用户的历史相关数据查询；

所述数据打通平台分别基于预存的多个评估策略对查询到的历史相关数据进行分析评估，得到对应的多个评估结果后反馈给数据使用方，以便数据使用方根据需求从多个评估结果中选择用于支撑当前业务的评估结果。

5.根据权利要求1所述的基于事件触发的多方数据关联查询方法，其特征在于，所述数据打通平台接收到所述触发请求后，按照预存的评估策略进行数据源访问和评估，并将得到的评估结果反馈给数据使用方，具体包括：

所述数据驱动模块接收到触发请求后，向所述数据源代理发送携带用户标识的驱动请求；

所述数据源代理接收到驱动请求后，结合用户标识和预存的评估策略从所述一个数据源处进行用户的历史相关数据访问查询；

所述数据源代理基于预存的评估策略对查询到的历史相关数据进行评估，并将得到的评估结果反馈给数据使用方。

6.根据权利要求1所述的基于事件触发的多方数据关联查询方法，其特征在于，当有至少两个数据源时，所述数据打通平台包括数据驱动模块、数据结果融合模块、数据策略定义模块和至少两个数据源代理，所述至少两个数据源代理分别与至少两个数据源对接；则所述评估策略的制定与保存过程具体为：

数据使用方根据自身业务的目标客户条件，通过所述数据策略定义模块制定相应的评估策略；其中，所述评估策略中包含融合规则以及与所述至少两个数据源分别对应的策略规则；

所述数据策略定义模块对制定好的评估策略进行识别和分解，并将分解出的各策略规则分别发送给对应的数据源代理，将分解出的融合规则发送给所述数据结果融合模块。

7.根据权利要求6所述的基于事件触发的多方数据关联查询方法，其特征在于，所述数据打通平台接收到所述触发请求后，按照预存的评估策略进行数据源访问和评估，并将得到的评估结果反馈给数据使用方，具体包括：

所述数据驱动模块接收到触发请求后，向所述数据结果融合模块发送携带用户标识的驱动请求；

所述数据结果融合模块接收到驱动请求后，分别向所述至少两个数据源代理发送携带用户标识的数据查询请求；

所述至少两个数据源代理接收到数据查询请求后，分别按照各自预存的策略规则进行对应的数据源访问评估，并将各自得到的评估结果反馈给所述数据结果融合模块；

所述数据结果融合模块对接收到的来自所述至少两个数据源代理的评估结果进行融合，并将融合后的评估结果反馈给数据使用方。

8.根据权利要求1所述的基于事件触发的多方数据关联查询方法，其特征在于，当所述动作事件具体为数据使用方对用户进行验证时，所述用户向数据使用方提交业务申请时触发对应的动作事件，并在动作事件的触发作用下向数据打通平台发送触发请求，具体为：

用户在数据使用方的网站、APP或人工柜台提交业务申请时，触发数据使用方通过运营商网络对用户进行验证；

在验证过程中，数据使用方或运营商网络向所述数据打通平台发送携带用户标识的触发请求，以便触发所述数据打通平台。

9.根据权利要求8所述的基于事件触发的多方数据关联查询方法，其特征在于，所述用户在数据使用方的网站、APP或人工柜台提交业务申请时，触发数据使用方通过运营商网络对用户进行验证，具体为：

用户利用对应的用户标识在数据使用方的网站、APP或人工柜台提交业务申请时，触发所述网站、APP或人工柜台随机生成一个验证码；

所述网站、APP或人工柜台将所述用户标识和所述验证码发送至运营商网络；

所述运营商网络将所述验证码发送至对应用户标识的智能终端，以便用户在所述网站、APP或人工柜台进行验证码的填写。

10.根据权利要求8所述的基于事件触发的多方数据关联查询方法，其特征在于，所述用户在数据使用方的网站、APP或人工柜台提交业务申请时，触发数据使用方通过运营商网络对用户进行验证具体为：

用户利用对应的用户标识在数据使用方的网站、App或人工柜台提交业务申请时，触发所述网站、APP或人工柜台生成携带用户标识的短信验证请求；

所述网站、APP或人工柜台将携带用户标识的短信验证请求发送至运营商网络；

所述运营商网络接收到短信验证请求后随机生成一个验证码，并将所述验证码发送至对应用户标识的智能终端，以便用户在所述网站、APP或人工柜台进行验证码的填写。

11.根据权利要求1-10任一所述的基于事件触发的多方数据关联查询方法，其特征在于，所述用户标识为经过用户实名认证的手机号码，或者与所述手机号码绑定的QQ号、微信号、易信号、飞信号、邮箱、储蓄卡号或者信用卡号。

12.一种基于事件触发的多方数据关联查询装置，其特征在于，包括至少一个处理器和存储器，所述至少一个处理器和存储器之间通过数据总线连接，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令在被所述处理器执行后，用于完成权利要求1-11任一所述的基于事件触发的多方数据关联查询方法。

Images