CN111932046A - 一种服务场景下处理风险的方法、计算机设备、存储介质 - Google Patents

Abstract

本申请实施例公开了一种服务场景下处理风险的方法，包括：获取服务事件的事件属性，所述事件属性包括事件环境属性、事件状态属性和事件主体属性中至少一种；根据所述事件属性确定所述服务事件具有对应事件主体的风险以及本次风险的风险等级；执行与所确定的风险等级对应的风险处理方案。相比于简单根据事件目标进行判定的方式，可以更准确地对事件风险进行监控，提高了事件主体的安全性。

Description

一种服务场景下处理风险的方法、计算机设备、存储介质

技术领域

本申请涉及数据处理技术领域，具体涉及一种服务场景下处理风险的方法、一种计算机设备、一种计算机可读存储介质。

背景技术

电子商务发展到今天，已经占据中国零售市场主导地位，随着“新零售”模式的逐步落地，线上和线下将从原来的相对独立、相互冲突逐渐转化为互为促进、彼此融合，从而产生越来越多的线上线下关联的服务场景。例如通过打车软件实现打车服务，线上订购线下送货上门服务或线下取货服务、线上订购到店取货服务等等。

线下服务场景的增多，用户与服务人员之间发生面对面接触，导致用户遭遇风险的可能性大大增加，从而对风险的预判识别以及风险的处理都提出了需求。

目前相关的风险识别方案，仅仅是根据是否达到目标来进行判断，例如根据用户是否实际到达行驶目的地判断用户是否具有风险，这种识别粒度相当粗糙，并且有伪造的可能，并无法有效保证用户安全。

发明内容

鉴于上述问题，提出了本申请以便提供一种克服上述问题或者至少部分地解决上述问题的服务场景下处理风险的方法、以及计算机设备、计算机可读存储介质。

依据本申请的一个方面，提供了一种服务场景下处理风险的方法，包括：

获取服务事件的事件属性，所述事件属性包括事件环境属性、事件状态属性和事件主体属性中至少一种；

根据所述事件属性确定所述服务事件具有对应事件主体的风险以及本次风险的风险等级；

执行与所确定的风险等级对应的风险处理方案。

可选地，所述获取所述服务事件的事件属性包括：

获取服务客户端针对服务事件提交的事件属性。

可选地，所述获取所述服务事件的事件属性还包括：

将所提交的事件属性与标准属性进行比对得到偏移数据，以所述偏移数据作为事件属性。

可选地，所述方法还包括：

从当前服务系统的关联系统中调取历史数据，解析所述历史数据得到针对业务事件的标准属性。

可选地，所述根据所述事件属性确定所述服务事件具有对应事件主体的风险以及本次风险的风险等级包括：

采用风险预测数据确定所述服务事件具有对应事件主体的风险以及本次风险的风险等级，所述风险预测数据包括至少一种事件规则和/或风险模型。

可选地，所述服务事件包括打车事件，所述事件属性包括行驶区域的风险级别、行驶区域中的行驶时间、行驶路线的偏移角度、行驶路线的偏移长度、行驶节点信息和司机信用等级中至少一种；

所述事件规则包括在风险行驶区域的行驶时间是否符合设定范围、所述行驶路线的偏移值是否符合设定范围、所述行驶节点信息是否符合设定范围以及所述司机信息是否符合设定等级中至少一种。

可选地，所述执行与所确定的风险等级对应的风险处理方案包括：

根据所确定的风险等级调用至少一个关联系统，以通过所述关联系统执行对应所述事件主体的风险解决方案。

可选地，所述关联系统包括风险处理系统、服务客户端和其他服务系统中至少一种。

可选地，所述方法还包括：

调用用户信用系统对所述关联系统的用户进行风险评价，获得符合信用条件的用户执行所述风险解决方案。

可选地，所述执行与所确定的风险等级对应的风险处理方案包括：

将本次风险提示至所述事件主体。

可选地，所述方法还包括：

根据对本次风险的处理结果调整本次风险的风险等级。

可选地，所述方法还包括：

监控针对本次风险的风险提示信息，并根据所述风险提示信息调整本次风险的风险等级。

可选地，所述方法还包括：

执行对应调整后的风险等级的风险处理方案。

可选地，所述风险提示信息包括事件主体的风险上报，和/或，非事件主体的风险上报。

本申请还提供了一种打车场景下处理风险的方法，包括：

通过解析历史行驶数据，创建标准行驶规则；

监控打车事件中行驶属性，所述行驶属性包括行驶环境、行驶路线、行驶节点信息和司机信息中至少一种；

通过比对所述标准行驶规则和所述行驶属性，确定所述打车事件具有对应乘客的风险；

调用至少一个关联系统，以通过所述关联系统执行对应乘客的风险解决方案。

本申请还提供了一种数据处理方法，包括：

获取事件的属性数据；

通过比较属性数据与标准数据，确定偏移数据；

采用至少一种数据预测规则和/或数据预测集合对所述偏移数据进行度量，获得特征事件的度量结果；

执行与所述度量结果对应的数据处理流程。

本申请还提供了一种一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述的一个或多个的方法。

本申请还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述一个或多个的方法。

依据本申请实施例，通过获取服务事件的事件属性，例如事件环境属性、事件状态属性、事件主体属性等，并以此判断服务事件中的事件主体是否具有一定的风险，如有风险，则进一步根据风险等级进行相应的风险处理，相比于简单根据事件目标进行判定的方式，可以更准确地对事件风险进行监控，提高了事件主体的安全性。

本申请还可以调用至少一个关联系统协助进行风险处理，丰富了风险处理方案，提高了风险处理的效率，所调调用的关联系统可以经过用户信用系统进行风险评价，进一步确保风险处理的可靠性。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了根据本申请实施例一的一种服务场景下处理风险的方法实施例的流程图；

图2示出了根据本申请实施例二的一种服务场景下处理风险的方法实施例的流程图；

图3示出了根据本申请实施例三的一种打车场景下处理风险的方法实施例的流程图；

图4示出了根据本申请实施例四的一种数据处理的方法实施例的流程图；

图5示出了打车场景下风险控制示意图；

图6示出了行驶路线偏移示意图；

图7示出了根据本申请实施例五的一种服务场景下处理风险的装置实施例的结构框图；

图8示出了根据本申请实施例六的一种服务场景下处理风险的装置实施例的结构框图；

图9示出了根据本申请实施例七的一种打车场景下处理风险的装置实施例的结构框图；

图10示出了根据本申请实施例八的一种打车场景下处理风险的装置实施例的结构框图；

图11示出了可被用于实现本公开中所述的各个实施例的示例性系统。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

为使本领域技术人员更好地理解本申请，以下对本申请涉及的概念进行说明：

服务场景下，一方提出需求，提供服务另一方实现需求，这一过程为基于服务场景下产生的服务事件，事件主体是其中提出需求的一方。在新零售环境下，通常是提出需求的事件主体通过服务客户端在线上提交需求，提供解决方案的事件主体通过线下服务的方式满足需求。例如打车场景下，甲用户通过打车软件发布打车需求，乙服务人员将甲用户载至目的地；又如送货场景下丙用户通过购物软件发布购物需求，丁服务人员将物品配送给丙用户。

由此可见，服务场景下用户与服务人员之间发生面对面接触，从而使得用户的风险增大。因此需要提供相应的风险识别和风险处理方案。

事件属性是指事件的相关信息，包括但不限于事件环境属性、事件状态属性、事件主体属性等之中的一种或多种。其中，事件环境属性用于描述服务事件所处的环境，例如服务事件所处地理位置、行政区域、环境标识等，也可以是该环境的其他信息，比如该环境的群体特征、温度特征等。事件状态属性用于描述服务事件的进行状态，例如事件轨迹、事件进度、事件方向等。事件主体也即是用户，事件主体属性描述参与服务事件的用户的信息，例如用户信用信息、用户身份信息、用户身体特征等。

事件属性可以是通过服务客户端提交的原始数据，可以来自用户输入，也可以来自客户端采集。事件属性还可以是原始数据与标准数据进行对比后得到的偏移数据。各种属性的种类和来源可以根据实际场景需求设定，本申请对此并不做限制。

以打车场景为例，事件环境属性可以包括行驶区域标识等，事件状态属性可以包括行驶路线、行驶方向等，事件主体属性可以包括司机信用数据等。若以偏移数据为事件属性，则事件环境属性可以包括行驶区域的风险级别、行驶区域中的行驶时间等；事件状态属性可以包括行驶路线的偏移值、行驶节点信息(例如红绿灯行驶时间)等，行驶路线的偏移值可以是行驶路线相比正常路线的偏移角度、行驶路线相比正常路线的偏移长度等；事件主体属性可以包括司机信用等级等。

本申请通过获取服务事件的事件属性，并以此判断服务事件中的事件主体是否具有风险，如有风险，则进一步根据风险等级进行相应的风险处理，相比于简单根据事件目标进行判定的方式，可以更准确地对事件风险进行监控，提高了事件主体的安全性。

其中，可以使用风险预测数据判断服务事件中事件主体是否具有风险时，风险预测数据可以是事件规则，根据事件属性与一个或多个规则的匹配结来确定风险。根据前述事件属性的例子，事件规则可以相应包括在风险行驶区域的行驶时间是否符合设定范围、行驶路线的偏移值是否符合设定范围、行驶节点信息是否符合设定范围以及司机信息是否符合设定等级中至少一种。

风险预测数据也可以是风险模型，例如神经网络模型，将事件属性输入风险模型，输出是否具有风险的预测结果。

本申请还涉及到对关联系统的调用，关联系统可以是与当前服务系统存在业务相关的系统，也可以是具有调用权限的任一系统。调用至少一个关联系统协助进行风险处理，可以丰富风险处理方案，提高了风险处理的效率。以打车场景为例，可以调用派送系统(例如外卖系统、快递系统等)中的个人用户或是店铺用户，协助处理对乘客或是司机的风险。

其中，所调调用的关联系统可以经过用户信用系统进行风险评价，进一步确保风险处理的可靠性。用户信用系统可以是银行信用系统、网络金融信用系统、公益信用系统等。

本申请的方案可以在服务客户端上执行，也可以在服务客户端对应的云端服务器上执行。在服务客户端上执行时，根据事件属性确定风险和风险风机的步骤可以在服务客户端上完成，也可以上传至云端服务器完成，并获得服务器反馈的结果。之后可以是客户端执行风险处理方案，也可以是服务器执行风险处理方案。

其中，风险等级的一种示例可以包括高、中、低风险，具体可以根据实际需求设置，针对不同的风险等级，可以相应配置不同的风险解决方案。

参照图1，示出了根据本申请实施例一的一种服务场景下处理风险的方法实施例的流程图，该方法具体可以包括以下步骤：

步骤101，获取服务事件的事件属性，所述事件属性包括事件环境属性、事件状态属性和事件主体属性中至少一种。

本步骤获取事件属性可以是客户端采集服务事件的事件属性，也可以是客户端采集后提供至云端服务器，因此云端服务器获取到服务客户端提交的事件属性。事件属性是自定义的形式，在后续进行分析时提取关键信息，也可以是规范的形式，云端服务器所获取到的事件属性可以携带有对应服务事件的标识，以区分多个不同的服务事件。

步骤102，根据所述事件属性确定所述服务事件具有对应事件主体的风险以及本次风险的风险等级。

本申请根据事件环境属性、事件状态属性和事件主体属性中至少一种判断服务事件是否具有对应事件主体的风险，并在确定具有风险后，进一步根据事件属性确定本次风险的风险等级。

步骤103，执行与所确定的风险等级对应的风险处理方案。

可以预先配置针对不同风险等级的风险处理方案，执行风险等级对应的风险处理方案。风险等级的具体设置、风险等级与风险处理方案的对应关系、风险处理方案的具体内容等，均可以根据实际需求设定，本申请对此并不做限制。

需要说明的是，针对同一风险等级的不同服务事件，可以配置不同的风险处理方案，本申请对此并不做限制。例如，可以根据判定服务事件具有风险时所匹配的事件规则来对应不同的风险处理方案，例如偏离正常行驶路线和在高风险区域(例如事故频发或有严重事故案件的区域)中行驶均可以确定为高风险服务事件，对于前者可以保持高度关注，对于后者则可以在保持高度关注的同时，对事件主体进行风险告知。

依据本申请实施例，通过获取服务事件的事件属性，例如事件环境属性、事件状态属性、事件主体属性等，并以此判断服务事件中的事件主体是否具有一定的风险，如有风险，则进一步根据风险等级进行相应的风险处理，相比于简单根据事件目标进行判定的方式，可以更准确地对事件风险进行监控，提高了事件主体的安全性。

参照图2，示出了根据本申请实施例二的一种服务场景下处理风险的方法实施例的流程图，该方法具体可以包括以下步骤：

步骤201，获取服务事件的事件属性，所述事件属性包括事件环境属性、事件状态属性和事件主体属性中至少一种。

其中，服务事件的事件属性可以由服务客户端提交至云端服务器，因此，获取所述服务事件的事件属性的步骤可以包括：获取服务客户端针对服务事件提交的事件属性。

事件属性可以替换为原始提交的事件属性与标准属性之间的偏移数据，因此，获取所述服务事件的事件属性还可以包括：将所提交的事件属性与标准属性进行比对得到偏移数据，以所述偏移数据作为事件属性。

其中，标准数据是指事件属性的标准值，可以通过从当前服务系统的关联系统中调取历史数据，解析历史数据得到。此处所述关联系统与前述协助进行风险处理的系统可以是同一系统，也可以是不同系统。以打车场景为例，打车服务中涉及到的行驶路线、行驶节点信息等，可以从地图系统中解析获得，地图系统中通常包括了各类非营运类车辆的正常行驶数据，从而可以确定正常行驶路线，以此作为标准行驶路线；地图系统通常记录了各个行驶节点信息，例如某线路的日间行驶时间、夜间行驶时间、某路口红灯时间、绿灯时间、堵车概率等。行驶区域的风险级别可以基于警务系统获得，基于警务信息可以对行驶区域的治安状态进行划分，从而得到各个行驶区域的风险级别。

此处对关联系统的调用可以由服务客户端访问关联系统对应的云端服务器获得，也可以通过访问关联客户端获得，或者由服务客户端对应的云端服务器访问关联系统对应的云端服务器获得。

步骤202，根据所述事件属性确定所述服务事件具有对应事件主体的风险以及本次风险的风险等级。

可以采用风险预测数据确定所述服务事件具有对应事件主体的风险以及本次风险的风险等级，其中，风险预测数据包括至少一种事件规则与风险模型中至少一种，风险模型可以优选神经网络模型。

以服务事件为打车事件为例，事件属性包括行驶区域的风险级别、行驶区域中的行驶时间、行驶路线的偏移角度、行驶路线的偏移长度、行驶节点信息和司机信用等级中至少一种时，事件规则可以相应包括在风险行驶区域的行驶时间是否符合设定范围、所述行驶路线的偏移值是否符合设定范围、所述行驶节点信息是否符合设定范围以及所述司机信息是否符合设定等级中至少一种。

步骤203，执行与所确定的风险等级对应的风险处理方案。

在一种优选的实施例中，执行与所确定的风险等级对应的风险处理方案时，可以根据所确定的风险等级调用至少一个关联系统，以通过关联系统执行对应所述事件主体的风险解决方案。

其中，关联系统可以包括风险处理系统、服务客户端和其他服务系统中至少一种。

优选的，可以调用用户信用系统对所述关联系统的用户进行风险评价，获得符合信用条件的用户执行所述风险解决方案。

在另一种优选的实施例中，在执行与所确定的风险等级对应的风险处理方案时，可以将本次风险提示至所述事件主体。具体的提示可以是静默提醒，例如在检测到特定指纹后，通过显示特定暗语对事件主体进行提示，或是在服务客户端所在的终端发起伪装来电。事件主体可以通过多种方式发起报警，例如输入预先约定的字符，则确定发生风险，直接报警。若事件主体并未发起报警，也可以通过震动终端的方式进行提示。以打车场景为例，可以在行驶路线规划时，若无法绕开风险区域，则提示乘客在特定时间将会经过风险区域，并提示乘客注意安全。确定发生风险后，则可以伪装来电或是震动提示。

步骤204，根据对本次风险的处理结果调整本次风险的风险等级。

对风险成功处理后，可以将风险等级降级，以关注未处理的风险等级较高的服务事件；或，若风险未能成功处理，或是因处理结果发现问题升级，则可以将风险等级提高，以关注该服务事件，直至问题解决。

步骤205，监控针对本次风险的风险提示信息，并根据所述风险提示信息调整本次风险的风险等级。

风险提示信息来源于第三方或是服务事件的事件主体本身，因已经发出了风险提示信息，则说明事件主体的风险较大，已被本身或是第三方关注，需要提高本次风险的风险等级。

其中，风险提示信息包括如下至少一种：事件主体的风险上报，非事件主体的风险上报。例如打车场景下，事件主体的风险上报可以是司机或是乘客的报警，非事件主体的风险上报可以是紧急联系人的报警。

步骤206，执行对应调整后的风险等级的风险处理方案。

针对处理后等级调整的服务事件，可以执行针对当前等级的风险处理方案，比如降级至中风险后，可以继续监控，电话回访等，升级至高风险后，则可以调用关联系统协助解决风险。

依据本申请实施例，通过获取服务事件的事件属性，例如事件环境属性、事件状态属性、事件主体属性等，并以此判断服务事件中的事件主体是否具有一定的风险，如有风险，则进一步根据风险等级进行相应的风险处理，相比于简单根据事件目标进行判定的方式，可以更准确地对事件风险进行监控，提高了事件主体的安全性。

本申请还可以调用至少一个关联系统协助进行风险处理，丰富了风险处理方案，提高了风险处理的效率，所调调用的关联系统可以经过用户信用系统进行风险评价，进一步确保风险处理的可靠性。

参照图3，示出了根据本申请实施例三的一种打车场景下处理风险的方法实施例的流程图，该方法具体可以包括以下步骤：

步骤301，通过解析历史行驶数据，创建标准行驶规则。

步骤302，监控打车事件中行驶属性，所述行驶属性包括行驶环境、行驶路线、行驶节点信息和司机信息中至少一种。

步骤303，通过比对所述标准行驶规则和所述行驶属性，确定所述打车事件具有对应乘客的风险。

步骤304，调用至少一个关联系统，以通过所述关联系统执行对应乘客的风险解决方案。

上述步骤的具体实现原理和实现方式可以参见前述实施例中的描述，此处不另赘述。

依据本申请实施例，通过解析历史行驶数据，创建标准行驶规则，并监控打车事件中的行驶属性，例如行驶环境、行驶路线、行驶节点信息、司机信息等，并以此确定打车事件具有对应乘客的风险，如有风险，调用至少一个关联系统，以通过所述关联系统执行对应乘客的风险解决方案。相比于简单根据是否到达打车目的地进行判定的方式，可以更准确地对打车场景下的风险进行监控，提高乘客的安全性。同时丰富了风险处理方案，提高了风险处理的效率。

参照图4，示出了根据本申请实施例四的一种数据处理方法实施例的流程图，该方法具体可以包括以下步骤：

步骤401，获取事件的属性数据。

事件的属性数据是指事件的相关信息，包括但不限于事件环境属性数据、事件状态属性数据、事件主体属性数据等之中的一种或多种。

步骤402，通过比较属性数据与标准数据确定偏移数据。

本实施例中，属性数据包括通过服务客户端提交的原始数据，进一步将原始数据与标准数据进行对比后得到偏移数据，用于后续的判定。

其中，标准数据是属性数据的标准值，可以通过从当前服务系统的关联系统中调取历史数据，解析历史数据得到。

步骤403，采用至少一种数据预测规则和/或数据预测集合对所述偏移数据进行度量，获得特征事件的度量结果。

数据预测规则可以根据实际需求设定，用于对偏移数据进行判定，数据预测集合可以是适用的数据模型，以偏移数据为输入，则输出为针对偏移数据的判定结果。

本申请实施例通过比较事件的属性数据与标准数据获得偏移数据，并以此判定事件是否为特征事件，相比于简单根据事件目标进行判定的方式，可以更准确地对事件进行监控。

步骤404，执行与所述度量结果对应的数据处理流程。

数据处理流程可以包括针对不同判定结果执行的处理方案，具体的执行可以由关联系统实现，从而丰富了数据处理方案，提高了数据处理的效率，所调调用的关联系统还可以经过信用系统的评价，进一步确保数据处理的可靠性。

本实施例的具体实现可以参照上述方法实施例，此处不再赘述。

为使本领域技术人员更好地理解本申请，以下结合打车场景通过具体的示例对本申请的一种服务场景下处理风险的方法进行说明。

参照图5所示的打车场景下风险控制示意图，包括数据采集、数据拆分与计算、数据库建立、风险事件判断和风险处理操作等内容，如下具体详述：

1、数据采集

数据采集是为了建立相应的事件规则，用以根据事件属性识别风险，具体可以包括日常行车路线采集、区域安全状况采集、司机或派送员行为信息采集、停留时间的采集。

2、数据拆分与计算

进一步根据采集的数据建立规则，包括：

通过采集时间最短的路线得到所有正常行驶路线。

通过对区域安全状况采集，进一步按照警务范围划分，得到区域的安全级别，例如一周内报警不低于X次，则为高风险区域，以后内报警不低于Y次，同时低于X次，则为中风险区域，相应的低于Y次，则为低风险区域。听过采集司机或是派送员的行为信息，包括违章记录量、用户好评量、投诉量，则可以建立司机的信用等级。通过采集线路的日间行驶时间和夜间行驶时间，路口的红灯时间和绿灯时间，堵车概率等数据，可以据此建立行驶节点信息。

3、数据库的建立

根据正常行驶路线的收集，可以得到最佳行驶路线、正常行驶路线区域、安全行驶路线等数据。根据行驶区域的安全级别可以将行驶区域划分为高风险区域、中风险区域、低风险区域等。根据司机的行为信息可以将司机划分为优质司机、信用正常司机、信用低司机、新司机等不同的信用等级。根据节点信息的采集可以获得行驶路线中各个节点的正常停留时间。

4、风险事件判断

通过上述事件属性可以进行风险事件的判断，包括如下几种情况：

监测当前行驶路线，与正常行驶路线进行比较，当出现超出正常行驶路线的非正常行驶时，判断非正常行驶路线超出N公里，与正常行驶方向偏移角度大于α度，则可以确认为风险事件，可以将事件放入高风险池进行高度关注。参照图6所示的行驶路线偏移示意图。从起点到终点有多条行驶路线，其中直线距离为最近路线，上方一条路线为最快路线，灰度区域部分为正常行驶区域，斜线框内为风险区域，如图6所示的行驶路线从正常行驶区域驶入了风险区域，且偏移角度为异常角度，则可判定为风险事件。

监测到行驶入风险区域，且在风险区域中行驶时长满足一定条件，例如在高风险区域行驶超过X分钟，在中风险区域行驶Y分钟，则可以将事件放入高风险池，并保持高度关注，并在进行风险区域时提前告知。

监测到司机的信用等级较低，或是，监测到在某个节点的停留时间等于或是超出了正常值，则可以将事件放入中风险池，并保持中度关注。

根据接收到乘客的报警，将该事件放入危机池，重点关注。或是，根据紧急联系人报警，第三方来咨询该服务事件的情况，对该服务事件放入高风险池，保持高度关注。

5、对风险池的操作

针对情况紧急的危机池中的服务事件，可以通过与外卖、送货等系统对接，请周边骑手、配送员、加盟店进行协同处理风险，在此之前，可以采用一些信用软件预先对骑手、配送员、加盟店进行筛选，避免引入风险，提高风险处理的效率。还可以通过通讯软件、邮件等将风险事件同步至警务系统进行处理，并可以实时更新或是按频率更新。危机池中的风险解除后，可以进行风险降级处理，将事件转入高风险池。

高风险池中的风险事件可以直接同步至警务系统，或是通过电话回访司机或乘客确定问题，或是通过震动、暗语提示用户确认安全。高风险池中的风险解除后，可以进行风险降级处理，将事件转入中风险池。

中风险池中的风险事件可以进行数据监控，根据后续发展再做处理。

在对风险池中的风险事件进行处理后，可以根据处理结果对识别风险事件的规则进行修正。

参照图7，示出了根据本申请实施例五的一种服务场景下处理风险的装置实施例的结构框图，具体可以包括：

属性获取模块501，用于获取服务事件的事件属性，所述事件属性包括事件环境属性、事件状态属性和事件主体属性中至少一种；

风险确定模块502，用于根据所述事件属性确定所述服务事件具有对应事件主体的风险以及本次风险的风险等级；

风险处理模块503，用于执行与所确定的风险等级对应的风险处理方案。

依据本申请实施例，通过获取服务事件的事件属性，例如事件环境属性、事件状态属性、事件主体属性等，并以此判断服务事件中的事件主体是否具有一定的风险，如有风险，则进一步根据风险等级进行相应的风险处理，相比于简单根据事件目标进行判定的方式，可以更准确地对事件风险进行监控，提高了事件主体的安全性。

参照图8，示出了根据本申请实施例六的一种服务场景下处理风险的装置实施例的结构框图，具体可以包括：

属性获取模块601，用于获取服务事件的事件属性，所述事件属性包括事件环境属性、事件状态属性和事件主体属性中至少一种。

风险确定模块602，用于根据所述事件属性确定所述服务事件具有对应事件主体的风险以及本次风险的风险等级。

风险处理模块603，用于执行与所确定的风险等级对应的风险处理方案。

第一等级调整模块604，用于根据对本次风险的处理结果调整本次风险的风险等级。

第二等级调整模块605，用于监控针对本次风险的风险提示信息，并根据所述风险提示信息调整本次风险的风险等级。

方案执行模块606，用于执行对应调整后的风险等级的风险处理方案。

本申请实施例中，优选地，所述风险提示信息包括事件主体的风险上报，和/或，非事件主体的风险上报。

本申请实施例中，优选地，所述属性获取模块可以用于获取服务客户端针对服务事件提交的事件属性。

本申请实施例中，优选地，所述属性获取模块还可以用于将所提交的事件属性与标准属性进行比对得到偏移数据，以所述偏移数据作为事件属性。

本申请实施例中，优选地，所述装置还可以包括：

历史数据调用模块，用于从当前服务系统的关联系统中调取历史数据；

历史数据解析模块，用于解析所述历史数据得到针对业务事件的标准属性。

本申请实施例中，优选地，所述风险确定模块，具体用于采用风险预测数据确定所述服务事件具有对应事件主体的风险以及本次风险的风险等级，所述风险预测数据包括至少一种事件规则和/或风险模型。

本申请实施例中，优选地，所述服务事件包括打车事件，所述事件属性包括行驶区域的风险级别、行驶区域中的行驶时间、行驶路线的偏移角度、行驶路线的偏移长度、行驶节点信息和司机信用等级中至少一种；

所述事件规则包括在风险行驶区域的行驶时间是否符合设定范围、所述行驶路线的偏移值是否符合设定范围、所述行驶节点信息是否符合设定范围以及所述司机信息是否符合设定等级中至少一种。

本申请实施例中，优选地，所述风险处理模块，用于根据所确定的风险等级调用至少一个关联系统，以通过所述关联系统执行对应所述事件主体的风险解决方案。

本申请实施例中，优选地，所述风险处理模块，用于将本次风险提示至所述事件主体。

本申请实施例中，优选地，所述关联系统包括风险处理系统、服务客户端和其他服务系统中至少一种。

本申请实施例中，优选地，所述装置还包括：

信用评价模块，用于调用用户信用系统对所述关联系统的用户进行风险评价，获得符合信用条件的用户执行所述风险解决方案。

依据本申请实施例，通过获取服务事件的事件属性，例如事件环境属性、事件状态属性、事件主体属性等，并以此判断服务事件中的事件主体是否具有一定的风险，如有风险，则进一步根据风险等级进行相应的风险处理，相比于简单根据事件目标进行判定的方式，可以更准确地对事件风险进行监控，提高了事件主体的安全性。

本申请还可以调用至少一个关联系统协助进行风险处理，丰富了风险处理方案，提高了风险处理的效率，所调调用的关联系统可以经过用户信用系统进行风险评价，进一步确保风险处理的可靠性。

参照图9，示出了根据本申请实施例七的一种打车场景下处理风险的装置实施例的结构框图，具体可以包括：

规则创建模块701，通过解析历史行驶数据，创建标准行驶规则。

属性监控模块702，监控打车事件中行驶属性，所述行驶属性包括行驶环境、行驶路线、行驶节点信息和司机信息中至少一种。

风险识别模块703，通过比对所述标准行驶规则和所述行驶属性，确定所述打车事件具有对应乘客的风险。

风险解决模块704，调用至少一个关联系统，以通过所述关联系统执行对应乘客的风险解决方案。

依据本申请实施例，通过解析历史行驶数据，创建标准行驶规则，并监控打车事件中的行驶属性，例如行驶环境、行驶路线、行驶节点信息、司机信息等，并以此确定打车事件具有对应乘客的风险，如有风险，则进一步调用至少一个关联系统，以通过所述关联系统执行对应乘客的风险解决方案。相比于简单根据是否到达打车目的地进行判定的方式，可以更准确地对打车场景下的风险进行监控，提高乘客的安全性。同时丰富了风险处理方案，提高了风险处理的效率。

参照图10，示出了根据本申请实施例八的一种数据处理装置实施例的结构框图，具体可以包括：

数据获取模块801，用于获取事件的属性数据；

比较模块802，通过比较属性数据与标准数据确定偏移数据；

判定模块803，采用至少一种数据预测规则和/或数据预测集合对所述偏移数据进行度量，获得特征事件的度量结果；

处理模块804，执行与所述度量结果对应的数据处理流程。

本申请实施例通过比较事件的属性数据与标准数据获得偏移数据，并以此判定事件是否为特征事件，相比于简单根据事件目标进行判定的方式，可以更准确地对事件进行监控。

本申请实施例可以调用至少一个关联系统协助进行数据处理，丰富了数据处理方案，提高了数据处理的效率，所调调用的关联系统可以经过信用系统评价，进一步确保数据处理的可靠性。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本公开的实施例可被实现为使用任意适当的硬件，固件，软件，或及其任意组合进行想要的配置的系统。图11示意性地示出了可被用于实现本公开中所述的各个实施例的示例性系统(或装置)900。

对于一个实施例，图11示出了示例性系统900，该系统具有一个或多个处理器902、被耦合到(一个或多个)处理器902中的至少一个的系统控制模块(芯片组)904、被耦合到系统控制模块904的系统存储器906、被耦合到系统控制模块904的非易失性存储器(NVM)/存储设备908、被耦合到系统控制模块904的一个或多个输入/输出设备910，以及被耦合到系统控制模块906的网络接口912。

处理器902可包括一个或多个单核或多核处理器，处理器902可包括通用处理器或专用处理器(例如图形处理器、应用处理器、基频处理器等)的任意组合。在一些实施例中，系统900能够作为本申请实施例中所述的浏览器。

在一些实施例中，系统900可包括具有指令的一个或多个计算机可读介质(例如，系统存储器906或NVM/存储设备908)以及与该一个或多个计算机可读介质相合并被配置为执行指令以实现模块从而执行本公开中所述的动作的一个或多个处理器902。

对于一个实施例，系统控制模块904可包括任意适当的接口控制器，以向(一个或多个)处理器902中的至少一个和/或与系统控制模块904通信的任意适当的设备或组件提供任意适当的接口。

系统控制模块904可包括存储器控制器模块，以向系统存储器906提供接口。存储器控制器模块可以是硬件模块、软件模块和/或固件模块。

系统存储器906可被用于例如为系统900加载和存储数据和/或指令。对于一个实施例，系统存储器906可包括任意适当的易失性存储器，例如，适当的DRAM。在一些实施例中，系统存储器906可包括双倍数据速率类型四同步动态随机存取存储器(DDR4SDRAM)。

对于一个实施例，系统控制模块904可包括一个或多个输入/输出控制器，以向NVM/存储设备908及(一个或多个)输入/输出设备910提供接口。

例如，NVM/存储设备908可被用于存储数据和/或指令。NVM/存储设备508可包括任意适当的非易失性存储器(例如，闪存)和/或可包括任意适当的(一个或多个)非易失性存储设备(例如，一个或多个硬盘驱动器(HDD)、一个或多个光盘(CD)驱动器和/或一个或多个数字通用光盘(DVD)驱动器)。

NVM/存储设备908可包括在物理上作为系统900被安装在其上的设备的一部分的存储资源，或者其可被该设备访问而不必作为该设备的一部分。例如，NVM/存储设备908可通过网络经由(一个或多个)输入/输出设备910进行访问。

(一个或多个)输入/输出设备910可为系统900提供接口以与任意其他适当的设备通信，输入/输出设备910可以包括通信组件、音频组件、传感器组件等。网络接口912可为系统900提供接口以通过一个或多个网络通信，系统900可根据一个或多个无线网络标准和/或协议中的任意标准和/或协议来与无线网络的一个或多个组件进行无线通信，例如接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合进行无线通信。

对于一个实施例，(一个或多个)处理器902中的至少一个可与系统控制模块904的一个或多个控制器(例如，存储器控制器模块)的逻辑封装在一起。对于一个实施例，(一个或多个)处理器902中的至少一个可与系统控制模块904的一个或多个控制器的逻辑封装在一起以形成系统级封装(SiP)。对于一个实施例，(一个或多个)处理器902中的至少一个可与系统控制模块904的一个或多个控制器的逻辑集成在同一模具上。对于一个实施例，(一个或多个)处理器902中的至少一个可与系统控制模块904的一个或多个控制器的逻辑集成在同一模具上以形成片上系统(SoC)。

在各个实施例中，系统900可以但不限于是：浏览器、工作站、台式计算设备或移动计算设备(例如，膝上型计算设备、手持计算设备、平板电脑、上网本等)。在各个实施例中，系统900可具有更多或更少的组件和/或不同的架构。例如，在一些实施例中，系统900包括一个或多个摄像机、键盘、液晶显示器(LCD)屏幕(包括触屏显示器)、非易失性存储器端口、多个天线、图形芯片、专用集成电路(ASIC)和扬声器。

其中，如果显示器包括触摸面板，显示屏可以被实现为触屏显示器，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。

本申请实施例还提供了一种非易失性可读存储介质，该存储介质中存储有一个或多个模块(programs)，该一个或多个模块被应用在终端设备时，可以使得该终端设备执行本申请实施例中各方法步骤的指令(instructions)。

在一个示例中提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如本申请实施例的方法。

在一个示例中还提供了一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如本申请实施例的一个或多个的方法。

本申请实施例公开了一种信息提供方法和装置，示例1包括一种服务场景下处理风险的方法，包括：

获取服务事件的事件属性，所述事件属性包括事件环境属性、事件状态属性和事件主体属性中至少一种；

根据所述事件属性确定所述服务事件具有对应事件主体的风险以及本次风险的风险等级；

执行与所确定的风险等级对应的风险处理方案。

示例2可包括示例1所述的方法，其中，所述获取所述服务事件的事件属性包括：

获取服务客户端针对服务事件提交的事件属性。

示例3可包括示例2所述的方法，其中，所述获取所述服务事件的事件属性还包括：

将所提交的事件属性与标准属性进行比对得到偏移数据，以所述偏移数据作为事件属性。

示例4可包括示例1所述的方法，其中，所述方法还包括：

从当前服务系统的关联系统中调取历史数据，解析所述历史数据得到针对业务事件的标准属性。

示例5可包括示例1所述的方法，其中，所述根据所述事件属性确定所述服务事件具有对应事件主体的风险以及本次风险的风险等级包括：

采用风险预测数据确定所述服务事件具有对应事件主体的风险以及本次风险的风险等级，所述风险预测数据包括至少一种事件规则和/或风险模型。

示例6可包括示例5所述的方法，其中，所述服务事件包括打车事件，所述事件属性包括行驶区域的风险级别、行驶区域中的行驶时间、行驶路线的偏移角度、行驶路线的偏移长度、行驶节点信息和司机信用等级中至少一种；

所述事件规则包括在风险行驶区域的行驶时间是否符合设定范围、所述行驶路线的偏移值是否符合设定范围、所述行驶节点信息是否符合设定范围以及所述司机信息是否符合设定等级中至少一种。

示例7可包括示例1所述的方法，其中，所述执行与所确定的风险等级对应的风险处理方案包括：

根据所确定的风险等级调用至少一个关联系统，以通过所述关联系统执行对应所述事件主体的风险解决方案。

示例8可包括示例7所述的方法，其中，所述关联系统包括风险处理系统、服务客户端和其他服务系统中至少一种。

示例9可包括示例7所述的方法，其中，所述方法还包括：

调用用户信用系统对所述关联系统的用户进行风险评价，获得符合信用条件的用户执行所述风险解决方案。

示例10可包括示例1所述的方法，其中，所述执行与所确定的风险等级对应的风险处理方案包括：

将本次风险提示至所述事件主体。

示例11可包括示例1所述的方法，其中，所述方法还包括：

根据对本次风险的处理结果调整本次风险的风险等级。

示例12可包括示例1所述的方法，其中，所述方法还包括：

监控针对本次风险的风险提示信息，并根据所述风险提示信息调整本次风险的风险等级。

示例13可包括示例11或12所述的方法，其中，所述方法还包括：

执行对应调整后的风险等级的风险处理方案。

示例14可包括示例12所述的方法，其中，所述风险提示信息包括事件主体的风险上报，和/或，非事件主体的风险上报。

示例15包括一种打车场景下处理风险的方法，其中，包括：

通过解析历史行驶数据，创建标准行驶规则；

监控打车事件中行驶属性，所述行驶属性包括行驶环境、行驶路线、行驶节点信息和司机信息中至少一种；

通过比对所述标准行驶规则和所述行驶属性，确定所述打车事件具有对应乘客的风险；

调用至少一个关联系统，以通过所述关联系统执行对应乘客的风险解决方案。

示例16包括一种数据处理方法，其中，包括：

获取事件的属性数据；

通过比较属性数据与标准数据，确定偏移数据；

采用至少一种数据预测规则和/或数据预测集合对所述偏移数据进行度量，获得特征事件的度量结果；

执行与所述度量结果对应的数据处理流程。

示例16包括一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述计算机程序时实现如示例1-16一个或多个的方法。

示例18包括一种计算机可读存储介质，其上存储有计算机程序，其中，该程序被处理器执行时实现如示例1-16一个或多个的方法。

虽然某些实施例是以说明和描述为目的的，各种各样的替代、和/或、等效的实施方案、或计算来达到同样的目的实施例示出和描述的实现，不脱离本申请的实施范围。本申请旨在覆盖本文讨论的实施例的任何修改或变化。因此，显然本文描述的实施例仅由权利要求和它们的等同物来限定。

Claims (18)

1.一种服务场景下处理风险的方法，其特征在于，包括：

获取服务事件的事件属性，所述事件属性包括事件环境属性、事件状态属性和事件主体属性中至少一种；

根据所述事件属性确定所述服务事件具有对应事件主体的风险以及本次风险的风险等级；

执行与所确定的风险等级对应的风险处理方案。

2.根据权利要求1所述的方法，其特征在于，所述获取所述服务事件的事件属性包括：

获取服务客户端针对服务事件提交的事件属性。

3.根据权利要求2所述的方法，其特征在于，所述获取所述服务事件的事件属性还包括：

将所提交的事件属性与标准属性进行比对得到偏移数据，以所述偏移数据作为事件属性。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

从当前服务系统的关联系统中调取历史数据，解析所述历史数据得到针对业务事件的标准属性。

5.根据权利要求1所述的方法，其特征在于，所述根据所述事件属性确定所述服务事件具有对应事件主体的风险以及本次风险的风险等级包括：

采用风险预测数据确定所述服务事件具有对应事件主体的风险以及本次风险的风险等级，所述风险预测数据包括至少一种事件规则和/或风险模型。

6.根据权利要求5所述的方法，其特征在于，所述服务事件包括打车事件，所述事件属性包括行驶区域的风险级别、行驶区域中的行驶时间、行驶路线的偏移角度、行驶路线的偏移长度、行驶节点信息和司机信用等级中至少一种；

所述事件规则包括在风险行驶区域的行驶时间是否符合设定范围、所述行驶路线的偏移值是否符合设定范围、所述行驶节点信息是否符合设定范围以及所述司机信息是否符合设定等级中至少一种。

7.根据权利要求1所述的方法，其特征在于，所述执行与所确定的风险等级对应的风险处理方案包括：

根据所确定的风险等级调用至少一个关联系统，以通过所述关联系统执行对应所述事件主体的风险解决方案。

8.根据权利要求7所述的方法，其特征在于，所述关联系统包括风险处理系统、服务客户端和其他服务系统中至少一种。

9.根据权利要求7所述的方法，其特征在于，所述方法还包括：

调用用户信用系统对所述关联系统的用户进行风险评价，获得符合信用条件的用户执行所述风险解决方案。

10.根据权利要求1所述的方法，其特征在于，所述执行与所确定的风险等级对应的风险处理方案包括：

将本次风险提示至所述事件主体。

11.根据权利要求1所述的方法，其特征在于，所述方法还包括：

根据对本次风险的处理结果调整本次风险的风险等级。

12.根据权利要求1所述的方法，其特征在于，所述方法还包括：

监控针对本次风险的风险提示信息，并根据所述风险提示信息调整本次风险的风险等级。

13.根据权利要求11或12所述的方法，其特征在于，所述方法还包括：

执行对应调整后的风险等级的风险处理方案。

14.根据权利要求12所述的方法，其特征在于，所述风险提示信息包括事件主体的风险上报，和/或，非事件主体的风险上报。

15.一种打车场景下处理风险的方法，其特征在于，包括：

通过解析历史行驶数据，创建标准行驶规则；

监控打车事件中行驶属性，所述行驶属性包括行驶环境、行驶路线、行驶节点信息和司机信息中至少一种；

通过比对所述标准行驶规则和所述行驶属性，确定所述打车事件具有对应乘客的风险；

调用至少一个关联系统，以通过所述关联系统执行对应乘客的风险解决方案。

16.一种数据处理方法，其特征在于，包括：

获取事件的属性数据；

通过比较属性数据与标准数据，确定偏移数据；

采用至少一种数据预测规则和/或数据预测集合对所述偏移数据进行度量，获得特征事件的度量结果；

执行与所述度量结果对应的数据处理流程。

17.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1-16一个或多个的方法。

18.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-16一个或多个的方法。

Images