代驾行为监管方法、装置和服务器与流程

本申请涉及互联网技术领域，尤其是涉及一种代驾行为监管方法、装置和服务器。

背景技术

代驾平台是一种连接代驾司机和乘客的网络平台，当乘客向代驾平台发起包含有代驾需求的订单时，代驾平台会将该订单分配给与乘客起始地相距较近的代驾司机，收到订单并确认接单的代驾司机可为乘客提供代驾服务。

然而，有些代驾司机为了牟取更高的利益，存在私单行为。例如，有些司机借助代驾平台获取乘客的始发地、目的地和联系方式等信息，自行与乘客联系进行私单交易，目前的代驾平台很难发现这种私单行为，进而难以有效监管代驾司机的代驾行为。

技术实现要素：

有鉴于此，本申请的目的在于提供一种代驾行为监管方法、装置和服务器，以及时发现存在私单行为的司机，进而保障代驾平台的监管效果。

为了实现上述目的，本申请实施例采用的技术方案如下：

第一方面，本申请实施例提供了一种代驾行为监管方法，所述方法包括：检查订单执行过程中是否出现异常情况；如果出现异常情况，获取所述订单的应答司机的驾驶轨迹；当所述驾驶轨迹包括所述订单的目的地时，确定所述应答司机存在私单行为。

在本申请较佳的实施例中，所述检查订单执行过程中是否出现异常情况的步骤，至少包括以下之一：检查订单是否被应答司机或呼叫用户取消，如果取消，确定订单的执行过程出现异常情况；检查订单是否被应答司机提前终止，如果提前终止，确定订单的执行过程出现异常情况；检查订单的应答司机是否在订单执行过程中离线，如果离线，确定订单的执行过程出现异常情况。

在本申请较佳的实施例中，获取所述订单的应答司机的驾驶轨迹的步骤，包括：根据所述订单的起始地和目的地计算所述订单对应的时间信息；获取所述订单的应答司机在所述时间信息对应时段内的驾驶轨迹。

在本申请较佳的实施例中，获取所述订单的应答司机在所述时间信息对应时段内的驾驶轨迹的步骤，包括：按照所述时间信息跟踪所述订单的应答司机的驾驶轨迹；或者，从所述订单的应答司机的历史驾驶轨迹中，提取所述时间信息对应时段内的驾驶轨迹。

在本申请较佳的实施例中，按照所述时间信息跟踪所述订单的应答司机的驾驶轨迹的步骤，包括：如果所述时间信息包括所述订单对应的理论驾驶时长，跟踪所述订单的应答司机的驾驶轨迹，直至跟踪时长达到所述理论驾驶时长时停止跟踪。

在本申请较佳的实施例中，所述方法还包括：如果跟踪过程中所述应答司机离线，监听所述应答司机在所述时间信息对应时段内是否再次在线；如果再次在线，继续跟踪所述应答司机的驾驶轨迹。

在本申请较佳的实施例中，所述方法还包括：根据代驾司机的历史数据统计所述代驾司机在热点区域停留次数和接单次数；根据所述停留次数与所述接单次数判断所述代驾司机是否为存在私单行为的司机。

在本申请较佳的实施例中，所述方法还包括：根据所述停留次数与所述接单次数判断所述代驾司机是否为存在私单行为的司机的步骤，包括：计算所述停留次数与所述接单次数的差值；如果所述差值大于设定的阈值，确定所述代驾司机为存在私单行为的司机。

在本申请较佳的实施例中，所述方法还包括：检查当前时间对应的热点区域内的第一目标司机组；跟踪所述第一目标司机组中各个司机的驾驶轨迹；在跟踪过程中如果有接单司机，将所述接单司机从所述第一目标司机组中删除，得到第二目标司机组；判断所述第二目标司机组中各个司机的驾驶轨迹是否属于订单轨迹；将属于订单轨迹的司机确定为存在私单行为的司机。

在本申请较佳的实施例中，所述判断所述第二目标司机组中各个司机的驾驶轨迹是否属于订单轨迹的步骤，包括：检查所述第二目标司机组中各个司机的驾驶轨迹的暂停时长和驾驶方向；将所述暂停时长小于设定时长，且所述驾驶方向具有明确性的驾驶轨迹确定为订单轨迹。

在本申请较佳的实施例中，所述检查所述第二目标司机组中各个司机的驾驶轨迹的驾驶方向的步骤，包括：跟踪所述第二目标司机组中各个司机的驾驶轨迹；记录跟踪过程中的掉头次数，将掉头次数小于设定次数的驾驶轨迹确定为驾驶方向具有明确性的驾驶轨迹。

在本申请较佳的实施例中，所述热点区域通过以下方式生成：统计目标区域在预设的指定时段内的订单量；将订单量超过设定阈值的目标区域设置为所述指定时段内的热点区域。

在本申请较佳的实施例中，所述方法还包括：对存在私单行为的司机进行处理。

在本申请较佳的实施例中，所述对存在私单行为的司机进行处理的步骤，包括：统计存在私单行为的司机在预设时段内发生私单行为的次数；对超过设定次数的司机进行惩罚处理。

在本申请较佳的实施例中，所述对超过设定次数的司机进行惩罚处理的步骤，至少包括以下之一：为超过设定次数的司机设置私单标签；将超过设定次数的司机的私单惩罚值增加固定值；将超过设定次数的司机加入黑名单。

在本申请较佳的实施例中，所述对存在私单行为的司机进行处理的步骤，包括：向存在私单行为的司机下发处理通知；如果在设定的有效时间内接收到所述司机的提交的申诉申请，验证所述申诉申请是否合法；如果合法，修改所述司机的行为为正常行为。

第二方面，本申请实施例还提供一种代驾行为监管装置，所述装置包括：第一检查模块，用于检查订单执行过程中是否出现异常情况；获取模块，用于如果出现异常情况，获取所述订单的应答司机的驾驶轨迹；第一确定模块，用于当所述驾驶轨迹包括所述订单的目的地时，确定所述应答司机存在私单行为。

在本申请较佳的实施例中，所述第一检查模块采用至少以下方式之一：检查订单是否被应答司机或呼叫用户取消，如果取消，确定订单的执行过程出现异常情况；检查订单是否被应答司机提前终止，如果提前终止，确定订单的执行过程出现异常情况；检查订单的应答司机是否在订单执行过程中离线，如果离线，确定订单的执行过程出现异常情况。

在本申请较佳的实施例中，所述获取模块用于：根据所述订单的起始地和目的地获取所述订单对应的时间信息；获取所述订单的应答司机在所述时间信息对应时段内的驾驶轨迹。

在本申请较佳的实施例中，所述获取模块还用于：按照所述时间信息跟踪所述订单的应答司机的驾驶轨迹；或者，从所述订单的应答司机的历史驾驶轨迹中，提取所述时间信息对应时段内的驾驶轨迹。

在本申请较佳的实施例中，所述获取模块还用于：如果所述时间信息包括所述订单对应的理论驾驶时长，跟踪所述订单的应答司机的驾驶轨迹，直至跟踪时长达到所述理论驾驶时长时停止跟踪。

在本申请较佳的实施例中，所述装置还包括：离线监听模块，用于如果跟踪过程中所述应答司机离线，监听所述应答司机在所述时间信息对应时段内是否再次在线；在线跟踪模块，用于如果再次在线，继续跟踪所述应答司机的驾驶轨迹。

在本申请较佳的实施例中，所述装置还包括：次数统计模块，用于根据代驾司机的历史数据统计所述代驾司机在热点区域停留次数和接单次数；判断模块，用于根据所述停留次数与所述接单次数判断所述代驾司机是否为存在私单行为的司机。

在本申请较佳的实施例中，所述判断模块用于：计算所述停留次数与所述接单次数的差值；如果所述差值大于设定的阈值，确定所述代驾司机为存在私单行为的司机。

在本申请较佳的实施例中，所述装置还包括：第二检查模块，用于检查当前时间对应的热点区域内的第一目标司机组；跟踪模块，用于跟踪所述第一目标司机组中各个司机的驾驶轨迹；删除模块，用于在跟踪过程中如果有接单司机，将所述接单司机从所述第一目标司机组中删除，得到第二目标司机组；轨迹判断模块，用于判断所述第二目标司机组中各个司机的驾驶轨迹是否属于订单轨迹；第二确定模块，用于将属于订单轨迹的司机确定为存在私单行为的司机。

在本申请较佳的实施例中，所述轨迹判断模块用于：检查所述第二目标司机组中各个司机的驾驶轨迹的暂停时长和驾驶方向；将所述暂停时长小于设定时长，且所述驾驶方向具有明确性的驾驶轨迹确定为订单轨迹。

在本申请较佳的实施例中，所述轨迹判断模块用于：跟踪所述第二目标司机组中各个司机的驾驶轨迹；记录跟踪过程中的掉头次数，将掉头次数小于设定次数的驾驶轨迹确定为驾驶方向具有明确性的驾驶轨迹。

在本申请较佳的实施例中，所述热点区域通过以下方式生成：统计目标区域在预设的指定时段内的订单量；以及将订单量超过设定阈值的目标区域设置为所述指定时段内的热点区域。

在本申请较佳的实施例中，所述装置还包括：处理模块，用于对存在私单行为的司机进行处理。

在本申请较佳的实施例中，所述处理模块用于：统计存在私单行为的司机在预设时段内发生私单行为的次数；对超过设定次数的司机进行惩罚处理。

在本申请较佳的实施例中，所述处理模块采用至少以下方式之一：为存在私单行为的司机设置私单标签；将存在私单行为的司机的私单惩罚值增加固定值；将存在私单行为的司机加入黑名单。

在本申请较佳的实施例中，所述处理模块用于：向存在私单行为的司机下发处理通知；如果在设定的有效时间内接收到所述司机的提交的申诉申请，验证所述申诉申请是否合法；在验证结果合法时，修改所述司机的行为为正常行为；在验证结果不合法或在所述有效时间内未接收到申诉申请，对所述司机进行处理。

第三方面，本申请实施例提供了一种服务器，所述服务器包括存储器以及处理器，所述存储器用于存储支持处理器执行第一方面任一项所述方法的程序，所述处理器被配置为用于执行所述存储器中存储的程序。

第四方面，本申请实施例提供了一种计算机存储介质，用于储存为第二方面任一项所述装置所用的计算机软件指令。

本申请实施例提供了一种代驾行为监管方法、装置和服务器，通过检查订单执行过程中是否出现异常情况，可以在订单出现异常情况时，获取应答司机的驾驶轨迹，当其驾驶轨迹包括该订单的目的地时，确定该应答司机存在私单行为。这种方式能够有效判别应答司机是否存在私单行为，进一步完善了代驾平台的监管信息，进而保障了代驾平台对代驾行为的监管效果，有助于代驾平台规范代驾司机的代驾行为并维护代驾服务的市场秩序。

本申请实施例的其他特征和优点将在随后的说明书中阐述，或者，部分特征和优点可以从说明书推知或毫无疑义地确定，或者通过实施本申请实施例的上述技术即可得知。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

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

图1示出了本申请实施例所提供的一种代驾平台应用场景的示意图；

图2示出了本申请实施例所提供的一种代驾行为监管方法流程图；

图3示出了本申请实施例所提供的另一种代驾平台应用场景的示意图；

图4示出了本申请实施例所提供的另一种代驾行为监管方法流程图；

图5示出了本申请实施例所提供的另一种代驾行为的监管方法流程图；

图6示出了本申请实施例所提供的一种代驾行为监管装置的结构框图；

图7示出了本申请实施例所提供的另一种代驾行为监管装置的结构框图；

图8示出了本申请实施例所提供的一种服务器的结构示意图。

具体实施方式

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

移动终端的智能化发展，使人们的生活越来越便捷，例如：移动终端通过第三方支付平台可以为用户提供在线支付服务，移动终端还可以通过代驾平台为用户提供代驾服务等。

参见图1所示的代驾平台应用场景的示意图，在图1中示意出代驾平台的服务器，以及与该代驾平台的服务器分别通信连接的乘客终端和司机终端。其中，乘客终端和司机终端分别安装有代驾平台的乘客客户端(或称为乘客端app)和司机客户端(或称为司机端app)，如果司机登录司机客户端，在代驾平台的服务器上会显示该司机为在线状态，服务器能够获知该司机所在的位置和联系方式等信息。

如果用户需要代驾服务(例如预约出租车或预约代驾人员)，可以通过乘客客户端进行预约下单，乘客客户端会生成订单并发送至服务器，该订单通常包括用户所在位置和用户的联系方式等信息。服务器根据用户所在位置，将订单推送至距离较近的司机，司机接收到订单后可以与用户建立通信，完成代驾服务。

乘客终端具体可以为乘客的手机等移动终端，司机终端具体可以为司机的手机、ipad等移动终端，也可以为司机车辆内安装的车载设备等。

针对代驾服务中的私单行为，本实施例提供了一种代驾行为监管方法、装置和服务器，该私单行为不仅包括：代驾司机取消订单或者提前结束订单后继续给乘客提供代驾服务，还包括乘客取消订单，但是代驾司机继续给乘客提供代驾服务，以及代驾司机通过代驾平台上的信息私下为乘客提供代驾服务等行为。

实施例一

参见图2所示的一种代驾行为监管方法流程图，该方法可以应用于代驾平台的服务器，该服务器可以在线实时监管司机的私单行为，也可以线下对订单关联的历史数据(如订单数据库)进行分析，监管司机是否存在私单行为。当然，如果线下分析，该方法也可以应用于第三方服务器，第三方服务器可以对代驾平台提供的历史数据进行大数据分析，进而确定有私单行为的司机。参见表1所示的订单历史数据的一种形式，本申请实施例的订单历史数据并不限定为表格形式，也可以是其它数据格式。

表1

其中，初始地和目的地可以从乘客申请订单中获取，即该目的地是乘客预计前往的地点。

图2所示的代驾行为监管方法以应用在代驾平台的服务器为例进行说明，该方法包括如下步骤：

步骤s202，检查订单执行过程中是否出现异常情况，该异常情况可以包括有订单在应答后被取消，或者订单在应答后且在未到达目的地前被终止。基于此，具体实现时，本步骤至少包括以下之一：

(1)检查订单是否被应答司机或呼叫用户取消，如果取消，确定订单的执行过程出现异常情况。

如果代驾司机在线，其可以在听单过程中应答订单，应答后，司机终端的客户端上可以显示“取消订单”和“结束订单/结束行程”的提示框，如果“取消订单”提示框被选中，会直接取消订单或者跳转至再次确认是否取消订单的对话框，再次确认取消后该订单取消，这种取消方式，司机终端会向服务器发送订单取消消息，服务器在订单历史数据中记录订单被取消的时间和发起方为应答司机，并向乘客终端转发订单取消消息。结束订单的过程与取消订单过程类似，这里不再赘述。

本实施例中的服务器既可以在订单执行过程中，检查该订单是否被取消，也可以根据订单历史数据检查是否有订单被取消。

(2)检查订单是否被应答司机提前终止，如果提前终止，确定订单的执行过程出现异常情况。

对于订单是否属于提前终止的情况，服务器可以在接收到司机终端发送的订单结束指令时，获取司机终端当前所处位置，然后比对司机所处位置与订单中的目的地，如不一致，即可确定订单被提前终止，订单执行异常。

(3)检查订单的应答司机是否在订单执行过程中离线，如果离线，确定订单的执行过程出现异常情况。

考虑到司机为了躲避服务器的私单监管，可能会在订单执行过程中关闭司机端app，进而防止服务器获取其行驶数据，如果服务器在订单执行过程中监测到应答司机不在线，则即可确定司机离线，订单执行异常。对于通过订单历史数据检查的方式，服务器也可以通过订单历史数据确定司机是否有离线行为，基于此，订单历史数据中还可以采用表2所示的数据形式。

表2

表2中，应答司机信息中的离线时间和在线时间可以仅在时间信息对应的时间段内，发生离线事件时，进行记录。如果订单执行过程中，应答司机一直在线，则离线时间和在线时间可以为空。时间信息中的理论时长可以根据订单的初始地和目的地计算得到，例如：理论时长＝总路程(初始地与目的地间多条路线统计的平均距离)/理论速度。或者该理论时长也可以根据初始地和目的地对应的其它历史订单的时间信息得到，例如：由a至b，假设在a至b的历史订单中，实际行驶时长通常为40分钟，则当前a至b的订单对应的理论时长可以设置为40分钟+设定值(例如20分钟)。

表2中的初始地/目的地可以从乘客申请订单中获取，即初始地为乘客在订单中指定的上车地点，目的地是乘客预计前往的地点。而实际目的地是订单终止时，乘客终端或司机终端所在的实际位置。具体实现时，乘客终端的客户端或司机终端的客户端在订单结束或终止时，将当前的定位信息上传至服务器进行保存。

当然，以上仅示例性列举出了三种订单执行异常的情况，如果司机将乘客按照订单从初始地送达目的地，并在目的地结束订单，则代驾平台确认订单执行正常，除此之外的其它情况均可归属为订单执行异常，在此不再一一赘述。

步骤s204，如果出现异常情况，获取订单的应答司机的驾驶轨迹。

如果是在线监管方式，应答司机的驾驶轨迹可以通过跟踪的方式及时得到，如果是线下监管方式，应答司机的驾驶轨迹可以从订单历史数据中提取。基于此，本步骤具体可以包括：(1)根据订单的起始地和目的地获取订单对应的时间信息，例如订单对应的理论时长，或者订单对应的起始时间和结束时间；(2)获取该订单的应答司机在上述时间信息对应时段内的驾驶轨迹。通过基于订单对应的时间信息获取应答司机的驾驶轨迹的方式，可以剔除大部分干扰数据，简化分析处理的数据量。

上述驾驶轨迹可以在线跟踪，例如：按照上述时间信息跟踪该订单的应答司机的驾驶轨迹；或者也可以线下获取，例如：从订单的应答司机的历史驾驶轨迹中，提取上述时间信息对应时段内的驾驶轨迹。

如果在线跟踪，当上述时间信息包括订单对应的理论驾驶时长时，可以在判断出订单异常(例如订单在应答后被取消或者被提前终止等)时，开始跟踪该订单的应答司机的驾驶轨迹，直至跟踪时长达到理论驾驶时长时停止跟踪。

以在线监管方式为例，在订单执行过程中出现诸如取消订单、订单提前终止或司机离线等异常情况时，可能存在司机接私单的情况，此时，可以继续跟踪司机的驾驶轨迹，以进一步监测司机是否存在私单行为。在跟踪应答司机的驾驶轨迹时，可以采用实时跟踪方式，诸如实时从司机终端获取该司机的地理位置；也可以采用周期性跟踪方式，诸如每隔5分钟从司机终端获取该应答司机的地理位置。

在具体实施时，可以根据订单的起始地和目的地计算订单对应的时长；在该时长内跟踪订单的应答司机的驾驶轨迹。诸如，订单的起始地x到目的地y一般用时20min～30min之间，可以设定该订单对应的时长为30min，并在确认订单异常后的30min内跟踪该订单的应答司机的驾驶轨迹。其中，两个地点之间的预计时长可以根据两个地点的距离以及常规车速而计算得出，在计算时长的过程中，还可以考虑当前时间是否为高峰时段，或者起始地和目的地之间的路径是否拥堵，而确定合理时长。

此外，还可以在两地预计时长的基础上额外设定时间余量，诸如，两地预计时长为30min，设定该订单对应的时长为40min。对于提前结束订单的应答司机，订单对应的时长可以根据订单结束地与目的地的距离而设置，诸如订单的起始地x到目的地y预计用时30min，而代驾平台检测到应答司机在中间地z结束订单，此时中间地z到目的地y预计用时20min，则代驾平台在余下的20min内继续跟踪订单的应答司机的驾驶轨迹，在此不再赘述。

考虑到应答司机可能在订单执行期间离线，上述方法还包括：如果跟踪过程中应答司机离线，监听该应答司机在上述时间信息对应时段内是否再次在线；如果再次在线，继续跟踪该应答司机的驾驶轨迹，继续跟踪的时长可以是上述理论驾驶时长，也可以跟踪到当前时间点不在上述时间信息对应时段内停止。可以理解的是，应答司机如果采用离线方式逃避代驾平台的监管而接私单，通常会在完成私单交易后继续上线，以便通过代驾平台继续获取有代驾需求的乘客信息，因而应当在司机再次在线时，代驾平台可继续跟踪应答司机的驾驶轨迹。

步骤s206，当上述驾驶轨迹包括订单的目的地时，确定应答司机存在私单行为。如果获取到应答司机的驾驶轨迹包括订单的目的地，说明应答司机可能在取消订单或提前终止订单后，与乘客私下交易，并继续将乘客送往目的地，由此可确定应答司机存在私单行为。

本申请实施例提供的上述代驾行为监管方法，通过检查订单执行过程中是否出现异常情况，可以在订单出现异常情况时，获取应答司机的驾驶轨迹，当其驾驶轨迹包括该订单的目的地时，确定该应答司机存在私单行为。这种方式能够有效判别应答司机是否存在私单行为，进一步完善了代驾平台的监管信息，进而保障了代驾平台对代驾行为的监管效果，有助于代驾平台规范代驾司机的代驾行为并维护代驾服务的市场秩序。

参见图3所示的另一种代驾平台应用场景的示意图，简单示意出乘客a、代驾平台的服务器以及代驾司机执行订单的场景。乘客a通过乘客终端向服务器发起包含有初始地和目的地的订单，服务器接收到乘客a的订单后，会将该订单分配给一名或多名合适的代驾司机，诸如，服务器查找到与该订单中的初始地相距500米范围内有三名代驾司机，分别为代驾司机b1、代驾司机b2和代驾司机b3，如图3所示，服务器将该订单分发给代驾司机b1、b2和b3，此时代驾司机b1、b2和b3均可通过司机终端接收到该订单。

代驾司机在收到上述订单时，可根据自身情况选择确认接单或不接单。第一个选择确认接单的代驾司机作为最终为乘客a提供代驾服务的司机，即上述应答司机。如图3所示，代驾司机b2在接收到a乘客订单后最先确认接单，服务器在接收到代驾司机b2通过司机终端发起的确认接单指令后，可确认乘客a与代驾司机b2达成代驾协议，代驾司机b2可通过服务器与乘客a联系，例如通过服务器提供的乘客a的网络电话拨叫乘客a，与乘客a通话，并前往乘客a所在的初始地，将乘客a送达至目的地。

在订单有效期间(即未被终止的期间)，服务器会持续追踪代驾司机的驾驶轨迹，对代驾司机进行监管。当代驾司机b2将乘客a送达目的地后，代驾司机b2向服务器发起订单结束消息，此时服务器确定代驾司机b2已完成订单，不再跟踪代驾司机b2的驾驶轨迹，该订单结束。

然而，代驾司机b2接单后，可能存在上述订单异常情况，诸如，服务器在线监测到代驾司机b2在接单后3min之内取消订单，根据a乘客订单中的初始地x和目的地y，获知a乘客订单对应的理论时长(可以为订单的起始地x到目的地y的一般用时)，在该理论时长内跟踪代驾司机b2的驾驶轨迹，如果监测到代驾司机b2的驾驶轨迹包括有目的地y，则确定代驾司机b2存在私单行为。

又诸如，初始地x与目的地y相距20公里；而服务器在线监测到代驾司机b2在将乘客a从初始地x送往目的地y的过程中，在中间地z(与初始地x相距3公里或相距起步计费距离)就结束订单，则继续在a乘客订单对应的理论时长之内跟踪代驾司机b2的驾驶轨迹，如果监测到代驾司机b2的驾驶轨迹包括有目的地y，则确定代驾司机b2存在私单行为。

又诸如，服务器监测到代驾司机b2在订单执行过程离线，服务器还可以监听代驾司机b2是否再次在线，如代驾司机b2在线时出现在目的地y，则确定代驾司机b2存在私单行为。

通过上述方法，可以有效分析出代驾司机b2是否存在私单行为，完善了代驾平台的监管功能，进而保障了代驾平台对代驾行为的监管效果，有助于代驾平台规范代驾司机的代驾行为并维护代驾服务的市场秩序。

实施例二

考虑到代驾司机还可能通过听单方式获取乘客信息，虽不确认接单，却私下与乘客联系并交易，诸如，有些代驾司机经常活跃在代驾需求较多的热点区域，通过代驾平台推送的订单获知乘客位置，自行前往接私单。基于此，上述方法还包括：根据代驾司机的历史数据统计代驾司机在热点区域的停留次数和接单次数；根据统计出的停留次数与接单次数判断代驾司机是否为存在私单行为的司机。例如：计算停留次数与接单次数的差值；如果差值大于设定的阈值，确定代驾司机为存在私单行为的司机。该方式基于历史数据分析司机是否有私单行为，能够在一定程度上筛选出私单司机，进一步完善代驾行为的监管。

参见图4所示的代驾行为监管方法的流程图，该方法以在线监管热点区域内的司机为例进行说明，包括如下步骤：

步骤s402，检查当前时间对应的热点区域内的第一目标司机组。其中，第一目标司机组包含有位于热点区域内的多名司机。

考虑到不同时间段，热点区域可能不同，本实施例的热点区域可以通过以下方式生成：统计目标区域在预设的指定时段内的订单量；将订单量超过设定阈值的目标区域设置为指定时段内的热点区域。或者，上述热点区域也可以由平台侧预先设置。例如：如果是上班/上学时段(诸如7:00～9:00)，该热点区域可以为居民区等；如果是下班/放学时段(诸如17:00～20:00)，该热点区域可以为办公楼集中的区域或者学校等；如果非工作时段，热点区域还可能是商场所在区、旅游景点所在区等；此外，无论是何时段，火车站、飞机场、商业区等公共区域均可能是热点区域。通常接私单的代驾司机可能经常出现在热点区域，不通过代驾平台而擅自接客。

可以理解的是，代驾平台通过司机终端可定位各代驾司机的所在位置，因而在当前时间可将位于热点区域的代驾司机作为需检查是否接私单的目标司机。

步骤s404，跟踪第一目标司机组中各个司机的驾驶轨迹。具体实施时，可以在预设时间段内跟踪第一目标司机组中各个司机的驾驶轨迹。诸如，将位于热点区域m的代驾司机b1、b2和b3作为第一目标司机组，并在30min之内持续跟踪代驾司机b1、b2和b3的驾驶轨迹。其中，预设时间段可以设定为一个检查周期，在该检查周期的时长可以为统计得到的一个订单完成的平均时长。

步骤s406，在跟踪过程中如果有接单司机，将接单司机从第一目标司机组中删除，得到第二目标司机组。诸如，跟踪过程中如有代驾司机b1确认接单，则将代驾司机b1从第一目标司机组中排除，得到包含有代驾司机b2和b3的第二目标司机组。而代驾司机b1接单后是否存在私单行为，可以应用上述实施例一中的监管方法，这里不再赘述。

步骤s408，判断第二目标司机组中各个司机的驾驶轨迹是否属于订单轨迹。

考虑到接单司机通常会持续行驶，不会在某个地点过长时间停留，即使红绿灯停车或者堵车停车，也很少会在一个比较固定的地点停留较长时间。并且接单司机行驶过长中，与马路上空载的出租车也不同，通常接单司机的驾驶方向很明确，不会多次重复往返同一路径。基于此，在判别是否属于订单轨迹的一种实施方式中，可以检查第二目标司机组中各个司机的驾驶轨迹的暂停时长和驾驶方向；将暂停时长小于设定时长，且驾驶方向具有明确性的驾驶轨迹确定为订单轨迹。通过这种方式，可以有效判别出当前跟踪到的驾驶轨迹是否为订单轨迹，进而保障监管私单行为的准确性。

具体的，在检查第二目标司机组中各个司机的驾驶轨迹的驾驶方向时，可以跟踪第二目标司机组中各个司机的驾驶轨迹；并记录跟踪过程中的掉头次数，将掉头次数小于设定次数的驾驶轨迹确定为驾驶方向具有明确性的驾驶轨迹。具体实现时，代驾平台能够通过司机终端获取司机的驾驶轨迹，并根据驾驶轨迹判别驾驶方向，如驾驶方向变为与原方向相反，则确定车辆掉头，并记录掉头次数。通常情况下，接有乘客的代驾司机的驾驶轨迹明确，极少出现掉头返回现象。

在判别是否属于订单轨迹的另一种实施方式中，可以检查第二目标司机组中各个司机的驾驶轨迹是否在多个热点区域来回往返，往返路径可认为是订单轨迹；往返次数越多，接私单行为越明显；还可以检查第二目标司机组中各个司机是否经常出现在诸如商场、车站等打车需求量较多的热点区域。

步骤s410，将属于订单轨迹的司机确定为存在私单行为的司机。

通过本实施例的监管方法，可以对通过听单方式对私自拉客的代驾司机进行检查，能够进一步提升平台监管效果，规范代驾司机的代驾行为。

例如，商场m为晚上8-10点时段的热点区域，代驾司机b通过代驾平台发现该热点信息后，可能在该时段内经常出现在商场m附近，通过上述图4所示方法的监管过程，发现代驾司机b尽管经常出现在该热点区域，但是通常没有接单行为，且其驾驶轨迹又符合订单轨迹，如果这种驾驶轨迹统计的量达到一定程度，则该代驾司机b很有可能是有意接私单的司机。

实施例三

为了能够较好地对代驾司机进行监管，降低代驾司机的接私单概率，本实施例还可以进一步对存在私单行为的司机进行处理，参见图5所示的另一种代驾行为的监管方法流程图，图5中所示的步骤s202～步骤s206可参见实施例一中的图2的相关描述，在此不再赘述。图5在图2的基础上，新增了如下步骤：步骤s502，统计存在私单行为的司机在预设时段内发生私单行为的次数。诸如，统计存在私单行为的司机在一周内发生私单行为的次数。

在一种实施方式中，代驾平台的服务器可以查询该司机的在预设时段内的订单历史数据，在该订单历史数据中，还可标记有是否有私单行为。基于此，订单历史数据中还可以采用表3所示的数据形式。

表3

在另一种实施方式中，代驾平台的服务器还可以在司机账号中直接查找历史预设时段内发生私单行为的次数。诸如，司机账号信息可以采用表4所示的数据形式；其中，表4中的预设时段为1个月(本月)，在实际应用中，可以灵活设置，诸如设置为1天接单数量/接私单行为、1周接单数量/接私单行为等。

表4

步骤s504，对超过设定次数的司机进行惩罚处理。其中，设定次数可以根据实际情况而灵活设置，该设定次数可以为零次，也可以为多次。一方面该设定次数可体现代驾平台对接私单行为的司机的容忍度，另一方面考虑到可能存在误判现象，误将正常行为的代驾司机确定为接私单行为，对超过设定次数的司机进行惩罚处理也可以在一定程度上防止误处理。假设服务器统计得到存在私单行为的司机b在一周内发生私单行为的次数为10次，而设定次数为3次，则对司机b进行惩罚处理。

在具体实施时，可参照以下方式对超过设定次数的司机进行惩罚处理，具体包括：

(1)为超过设定次数的司机设置私单标签。具体实现时，由于每个代驾司机都在代驾平台上注册有账号以及身份信息等，代驾平台可以给该代驾司机的账号上设置私单标签，以便于将该代驾司机列为重点检测对象。

(2)将超过设定次数的司机的私单惩罚值增加固定值。具体实现时，每个代驾司机都可以设置有私单惩罚值，私单惩罚值的初始值均为0，如果代驾司机被发现有私单行为，如果超过设定次数，则该代驾司机的私单惩罚值增加某固定值，该固定值可以灵活设置，诸如设定为1。代驾司机的私单惩罚值越高，证明该代驾司机的接私单行为越严重。

(3)将超过设定次数的司机加入黑名单。将代驾司机加入黑名单后，该代驾司机无法再使用代驾平台。

在实际应用中，可以根据情况而灵活采用上述方式中的一种或多种，也可以根据司机的接私单行为次数而相应选用上述惩罚措施，诸如，如果代驾司机b超过1次，则给代驾司机b的私单惩罚值加1；如果代驾司机b超过2次，则给代驾司机设置私单标签；如果代驾司机b超过3次，则将代驾司机b加入黑名单。

通过图5所示的上述监管方法，能够有效规范代驾司机的代驾行为，降低代驾司机接私单的概率，提升代驾平台的监管力度。

考虑到可能出现误判现象，诸如，代驾司机b虽然取消了乘客a发起的订单，而且驾驶轨迹也包含有乘客a的目的地，但仅是巧合行为，代驾司机b确实没有载客，为了确保监管可靠性，可以向存在私单行为的司机下发处理通知；如果在设定的有效时间内接收到司机的提交的申诉申请，验证申诉申请是否合法；如果合法，修改司机的行为为正常行为。具体的，可以采用人工方式验证申请合法性，也可以采用关键词识别方式验证申请合法性等。

诸如，代驾平台给提前终止订单，且驾驶轨迹包含有该订单目的地的代驾司机b下发处理通知，在该处理通知上写明处理事由，该处理通知可以为“您在地点x提前终止了a乘客订单，但又继续出现在a乘客订单的目的地y，涉嫌有接私单行为，如有误可在24小时内提出申诉”。如果司机在有效时间内提交了申诉申请，代驾平台可以验证申诉申请的合法性，如果合法，则修改将原认定的代驾司机b的接私单行为修改为正常行为。

通过对存在私单行为的司机进行处理，能够达到较好地规范司机行为的管理效果，有效降低了代驾司机私自接单的行为概率，提升了代驾平台的监管效果，也有助于代驾平台维护自身利益。

实施例四

为便于理解，本实施例提供了代驾平台采用前述实施例提供的监管方法对代驾行为进行监管的具体应用实例。

场景1

(1)乘客a向代驾平台发起订单请求，司机b通过代驾平台确认接单，进行应答。

(2)代驾平台如监测到司机b在短时间内(比如1分钟之内)取消订单，则追踪司机b是否在合理时间(车辆从始发地到目的地的预估时长)到达订单目的地；具体的，可以在合理时间内持续对b的行车轨迹进行追踪，也可以在达到预估时长时直接定位b所在的地理位置，判断b是否出现在订单目的地。

(3)如果司机b出现在订单目的地，则确定司机b存在接私单行为，并采取相应的处理措施，诸如给司机b的代驾记录贴附私单标签，或者给司机b的私单惩罚值加1，或者给司机b信用值减1等。

场景2

(1)乘客a向代驾平台发起订单请求，司机b通过代驾平台确认接单。

(2)代驾平台如监测到司机b提前结束订单(结束订单的地理位置与订单目的地不符)，继续在预设时长内持续监测a的运行轨迹，判断a是否出现在目的地并停留。其中，上述预设时长可以为司机b从结束订单地到订单目的地的预估时长。

(3)如果司机b出现在订单目的地，则确定司机b存在接私单行为，并采取相应的处理措施，诸如给司机b的代驾记录贴附私单标签，或者给司机b的私单惩罚值加1，或者给司机b信用值减1等。

场景3

(1)乘客a向代驾平台发起订单请求，代驾平台将该订单请求推送给与订单起始位置相距预设范围内的多名司机(假设推送给三名司机b1、b2和b3)，将司机b1、b2和b3作为监视目标。

(2)如果监测到该订单在指定时长内(诸如20min内)一直未成交或乘客a取消该订单，根据乘客a的订单起始地和订单目的地，生成至少一条监视路径；该监视路径为起始地到目的地的可行路径。

(3)跟踪司机b1、b2和b3的行车路线，将行车路线与上述监视路径匹配的监视目标作为可疑目标。

(4)如果可疑目标仅为一个(比如仅有司机b1)，将司机b1确定为最终目标；最终目标即为确定接私单行为的司机。如果可疑目标为多个(比如有b2和b3)，则根据b2和b3的代驾历史记录中确定最终目标，其中，代驾历史记录中可以记载有各司机的诚信值、接私单行为记录等信息，根据代驾历史记录，从司机b2和b3中选取接私单可能性最大的司机作为最终目标。

(5)对最终目标采取相应的处理措施，诸如给最终目标的代驾记录贴附私单标签，或者给最终目标的私单惩罚值加1，或者给最终目标的信用值减1等。

场景4

(1)乘客a向代驾平台发起订单请求，代驾平台将该订单请求推送给与订单起始位置相距预设范围内的多名司机(假设推送给三名司机b1、b2和b3)，将司机b1、b2和b3作为监视目标。

(2)如果监测到该订单在指定时长内(诸如20min内)一直未成交或乘客a取消该订单，跟踪监视目标是否掉线；

(3)如果有掉线的监视目标，对掉线的监视目标的离线时长进行计时；若计时时长与乘客a的订单对应的预测执行时长匹配，则该监视目标为可疑目标；也可以监视该监视目标再次在线时的地理位置，判断监视目标再次在线的位置是否与订单目标地相匹配，如匹配，确定该监视目标为可疑目标。

(4)如果可疑目标仅为一个(比如仅有司机b1)，将司机b1确定为最终目标；最终目标即为确定接私单行为的司机。如果可疑目标为多个(比如有b2和b3)，则根据b2和b3的代驾历史记录中确定最终目标，其中，代驾历史记录中可以记载有各司机的诚信值、接私单行为记录等信息，根据代驾历史记录，从司机b2和b3中选取接私单可能性最大的司机作为最终目标。

(5)对最终目标采取相应的处理措施，诸如给最终目标的代驾记录贴附私单标签，或者给最终目标的私单惩罚值加1，或者给最终目标的信用值减1等。

场景5

(1)乘客a向代驾平台发起订单请求，代驾平台将该订单请求推送给与订单起始位置相距预设范围内的多名司机(假设推送给四名司机b1、b2、b3和b4)，将司机b1、b2、b3和b4作为第一监视目标组。

(2)如果监测到该订单在指定时长内(诸如20min内)一直未成交或乘客a取消该订单，根据订单的起始地和目的地预测该订单的执行时长，在该执行时长内监测第一监视目标组b1、b2、b3和b4的业务状态。

(3)如果在执行时长内监测到b1接收并执行其它订单，确定b1为可信目标，将b1从第一监视目标组筛除，得到第二监视目标组b2、b3和b4。

(4)根据执行时长确定订单结束时间段，在订单结束时间段查找位于订单目的地的司机，将位于订单目的地的司机b4和b5确定为第三监视目标组。

(5)比较第二监视目标组b2、b3和b4和第三监视目标组b4和b5，得到重合目标b4，将重合目标b4作为最终目标，如果重合目标有多个，可以根据多个重合目标的代驾历史记录确定最终目标。

(6)对最终目标采取相应的处理措施，诸如给最终目标的代驾记录贴附私单标签，或者给最终目标的私单惩罚值加1，或者给最终目标的信用值减1等。

场景6

(1)乘客a向代驾平台发起订单请求，代驾平台将该订单请求推送给与订单起始位置相距预设范围内的多名司机(假设推送给四名司机b1、b2、b3和b4)，将司机b1、b2、b3和b4作为第一监视目标组。

(2)如果监测到该订单在指定时长内(诸如20min内)一直未成交或乘客a取消该订单，根据订单的起始地和目的地预测该订单的执行时长，在该执行时长内监测第一监视目标组b1、b2、b3和b4的业务状态。

(3)如果在执行时长内监测到b1接收并执行其它订单，确定b1为可信目标，将b1从第一监视目标组筛除，得到第二监视目标组b2、b3和b4。

(4)根据执行时长确定订单结束时间段，在订单结束时间段定位b2、b3和b4所在的地理位置，假设确定b2出现在订单目的地，则b2为最终目标。如果b2和b3均出现在订单目的地，可根据b2和b3的代驾历史记录确定最终目标。

(5)对最终目标采取相应的处理措施，诸如给最终目标的代驾记录贴附私单标签，或者给最终目标的私单惩罚值加1，或者给最终目标的信用值减1等。

场景7

(1)代驾平台在当前时间检查属于热点的区域。

(2)搜索位于热点区域的司机(假设三名司机b1、b2和b3)，将b1、b2和b3作为监控目标组。

(3)在指定的时间段(例如：8：00～10:00等出行高峰时间)内跟踪监控目标组中的各个司机b1、b2和b3的行为特征，该行为特征可以包括行车轨迹、司机终端是否持续在线、是否一直未接单或者出行订单执行异常等情况；

(4)如果行为特征符合接私单行为，诸如，司机b1一直没有接订单，却在热点区域往返、在多个热点区域停留；或者，司机b1在收到代驾平台推送的订单后离线，再次在线时处于订单的目的地等。

(5)检查司机b1的代驾历史记录，如果代驾历史记录中显示有该司机b1曾有多次接私单历史，对司机b1采取相应的处理措施，诸如给最终目标的代驾记录贴附私单标签，或者给最终目标的私单惩罚值加1，或者给最终目标的信用值减1等。

实施例五

对应于前述代驾行为监管方法，本实施例提供了一种代驾行为监管装置，该装置应用于代驾平台的服务器，参见图6所示的一种代驾行为监管装置的结构框图，包括：

第一检查模块62，用于检查订单执行过程中是否出现异常情况；

获取模块64，用于如果出现异常情况，获取订单的应答司机的驾驶轨迹；

第一确定模块66，用于当驾驶轨迹包括订单的目的地时，确定应答司机存在私单行为。

本申请实施例提供的上述代驾行为监管装置，通过检查订单执行过程中是否出现异常情况，可以在订单出现异常情况时，获取应答司机的驾驶轨迹，当其驾驶轨迹包括该订单的目的地时，确定该应答司机存在私单行为。这种装置能够有效判别应答司机是否存在私单行为，进一步完善了代驾平台的监管信息，进而保障了代驾平台对代驾行为的监管效果，有助于代驾平台规范代驾司机的代驾行为并维护代驾服务的市场秩序。

在具体实施时，第一检查模采用至少以下方式之一：

检查订单是否被应答司机或呼叫用户取消，如果取消，确定订单的执行过程出现异常情况；

检查订单是否被应答司机提前终止，如果提前终止，确定订单的执行过程出现异常情况；

检查订单的应答司机是否在订单执行过程中离线，如果离线，确定订单的执行过程出现异常情况。

在一种实施方式中，上述获取模块64用于：根据订单的起始地和目的地获取订单对应的时间信息；获取订单的应答司机在时间信息对应时段内的驾驶轨迹。

在具体实现时，上述获取模块64还用于：按照时间信息跟踪订单的应答司机的驾驶轨迹；或者，从订单的应答司机的历史驾驶轨迹中，提取时间信息对应时段内的驾驶轨迹。如果时间信息包括订单对应的理论驾驶时长，跟踪订单的应答司机的驾驶轨迹，直至跟踪时长达到理论驾驶时长时停止跟踪。

在另一种实施方式中，上述装置还可以包括：离线监听模块，用于如果跟踪过程中应答司机离线，监听应答司机在时间信息对应时段内是否再次在线；在线跟踪模块，用于如果再次在线，继续跟踪应答司机的驾驶轨迹。

在另一种实施方式中，上述装置还可以包括：次数统计模块，用于根据代驾司机的历史数据统计代驾司机在热点区域停留次数和接单次数；判断模块，用于根据停留次数与接单次数判断代驾司机是否为存在私单行为的司机。具体实现时，判断模块用于：计算停留次数与接单次数的差值；如果差值大于设定的阈值，确定代驾司机为存在私单行为的司机。

参见图7所示的另一种代驾行为监管装置的结构框图，图7中示意出该装置在图6的基础上，还可以包括如下模块：

第二检查模块71，用于检查当前时间对应的热点区域内的第一目标司机组；其中，热点区域可以通过以下方式生成：统计目标区域在预设的指定时段内的订单量；以及将订单量超过设定阈值的目标区域设置为指定时段内的热点区域。

跟踪模块72，用于跟踪第一目标司机组中各个司机的驾驶轨迹；

删除模块73，用于在跟踪过程中如果有接单司机，将接单司机从第一目标司机组中删除，得到第二目标司机组；

轨迹判断模块74，用于判断第二目标司机组中各个司机的驾驶轨迹是否属于订单轨迹；

第二确定模块75，用于将属于订单轨迹的司机确定为存在私单行为的司机。

在具体实施时，上述轨迹判断模块74用于：检查第二目标司机组中各个司机的驾驶轨迹的暂停时长和驾驶方向；将暂停时长小于设定时长，且驾驶方向具有明确性的驾驶轨迹确定为订单轨迹。进一步，轨迹判断模块74还用于：跟踪第二目标司机组中各个司机的驾驶轨迹；记录跟踪过程中的掉头次数，将掉头次数小于设定次数的驾驶轨迹确定为驾驶方向具有明确性的驾驶轨迹。

本实施例提供的上述监管装置还可以包括处理模块，用于对存在私单行为的司机进行处理。该处理模块可以与第一确定模块和/或第二确定模块分别相连。

在一种实施方式中，处理模块用于：统计存在私单行为的司机在预设时段内发生私单行为的次数；对超过设定次数的司机进行惩罚处理。

在具体实施时，处理模块采用至少以下方式之一：为存在私单行为的司机设置私单标签；将存在私单行为的司机的私单惩罚值增加固定值；将存在私单行为的司机加入黑名单。

在另一种实施方式中，处理模块用于：向存在私单行为的司机下发处理通知；如果在设定的有效时间内接收到司机的提交的申诉申请，验证申诉申请是否合法；在验证结果合法时，修改司机的行为为正常行为；在验证结果不合法或在有效时间内未接收到申诉申请，对司机进行处理。

本实施例所提供的装置，其实现原理及产生的技术效果和前述实施例相同，为简要描述，装置实施例部分未提及之处，可参考前述方法实施例中相应内容。

本申请实施例提供了一种服务器，该服务器包括存储器以及处理器，存储器用于存储支持处理器执行前述任一项代驾行为监管方法的程序，处理器被配置为用于执行存储器中存储的程序。

参见图8所示的一种服务器的结构示意图，具体包括处理器80，存储器81，总线82和通信接口83，处理器80、通信接口83和存储器81通过总线82连接；处理器80用于执行存储器81中存储的可执行模块，例如计算机程序。

其中，存储器81可能包含高速随机存取存储器(ram，randomaccessmemory)，也可能还包括非易失性存储器(non-volatilememory)，例如至少一个磁盘存储器。通过至少一个通信接口83(可以是有线或者无线)实现该系统网元与至少一个其他网元之间的通信连接，可以使用互联网，广域网，本地网，城域网等。

总线82可以是isa总线、pci总线或eisa总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图8中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

其中，存储器81用于存储程序，处理器80在接收到执行指令后，执行程序，前述本申请实施例任一实施例揭示的流过程定义的装置所执行的方法可以应用于处理器80中，或者由处理器80实现。

处理器80可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器80中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器80可以是通用处理器，包括中央处理器(centralprocessingunit，简称cpu)、网络处理器(networkprocessor，简称np)等；还可以是数字信号处理器(digitalsignalprocessing，简称dsp)、专用集成电路(applicationspecificintegratedcircuit，简称asic)、现成可编程门阵列(field-programmablegatearray，简称fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器81，处理器80读取存储器81中的信息，结合其硬件完成上述方法的步骤。

本实施例提供的代驾行为的监管方法可以由上述服务器执行，亦或，本实施例提供的代驾行为的监管装置可以设置于上述服务器侧。

进一步，本实施例还提供了一种计算机存储介质，用于储存为前述任一项代驾行为监管装置所用的计算机软件指令。

本申请实施例所提供的代驾行为监管方法、装置和服务器的计算机程序产品，包括存储了程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行前面方法实施例中所述的方法，具体实现可参见方法实施例，在此不再赘述。

另外，在本申请实施例的描述中，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本申请中的具体含义。

在本申请的描述中，需要说明的是，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。

最后应说明的是：以上所述实施例，仅为本申请的具体实施方式，用以说明本申请的技术方案，而非对其限制，本申请的保护范围并不局限于此，尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本申请实施例技术方案的精神和范围，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。