CN110390544A - 司机奖励的下发方法及装置 - Google Patents

Abstract

本发明提供一种司机奖励的下发方法及装置，通过接收乘客客户端发送的订单请求，判断订单请求是否满足预设条件，若满足则获取奖励信息，向司机客户端推送订单请求和奖励信息；若接收到司机客户端发送的订单接受消息，则当接收到司机客户端发送的订单完成消息时，根据奖励信息实时下发奖励到司机客户端对应的账户。本发明通过司机接单前将订单请求和奖励信息推送给司机客户端，可激励司机在特定时间段或特定区域接单的积极性，并且在推送订单请求前即根据订单请求获取奖励信息，可实现订单完成时即实时下发奖励到司机客户端对应的账户，奖励下发速度提高，提高司机客户体验，进一步也能够更合理分配交通资源，提高乘客的出行便利性。

Description

司机奖励的下发方法及装置

技术领域

本发明涉及通信技术领域，尤其涉及一种司机奖励的下发方法及装置。

背景技术

大移动互联网时代下用户现代化出行已改变了传统打车方式，利用移动互联网特点，将线上与线下相融合，改变了传统的司机等客方式，让司机根据乘客目的地按意愿接单，节约司机与乘客沟通成本，降低空驶率，最大化节省司乘双方资源与时间。

现有技术中司机通过司机客户端接收乘客订单，通过抢单、接送乘客、接收乘客付款，从而完成订单。为了合理分配交通资源，提高乘客在不同时间段、不同地域出行便利性，打车平台在司机在特定时间段或特定区域完成的订单给予一定的奖励，例如早晚高峰时间段、深夜、偏僻地域、人员集散区域(火车站、机场)等。

现有技术中打车平台对订单进行奖励通常是在订单完成后，从订单获取车辆行驶路径和订单时间，根据行驶路径和时间判断是否符合奖励条件，若满足，则下发奖励。由于打车平台需要对每一订单都进行获取、判断过程，需要大量时间和计算资源，因此对司机的奖励是非实时发放的，导致司机的客户体验不够好，影响司机接单的积极性。

发明内容

本发明提供一种司机奖励的下发方法及装置，以在司机完成订单时，打车平台实时的将奖励金额下发给司机客户端对应的账户，提高司机接单的积极性，进而提高司机的客户体验。

本发明的一个方面是提供一种司机奖励的下发方法，包括：

接收乘客客户端发送的订单请求，所述订单请求包括约车时间、起点和终点；

判断所述订单请求是否满足预设条件，若满足则获取奖励信息，向司机客户端推送所述订单请求和所述奖励信息；

若接收到所述司机客户端发送的订单接受消息，则当接收到所述司机客户端发送的订单完成消息时，根据所述奖励信息实时下发奖励到所述司机客户端对应的账户。

作为本发明的进一步改进，所述判断所述订单请求是否满足预设条件，具体包括：

判断所述约车时间是否属于预设时间段，所述预设时间段内供预约车辆数量少于所述预设时间段内订单请求总数量；和/或

判断所述起点和终点是否满足预设地域，其中所述预设地域中供预约车辆数量少于起点为所述预设地域的订单请求总数量。

作为本发明的进一步改进，所述根据所述约车时间、起点和终点判断所述订单请求是否满足预设条件前，还包括：

获取所述约车时间对应的天气信息；

所述判断所述订单请求是否满足预设条件，具体包括：

判断所述天气信息是否满足预设天气条件。

作为本发明的进一步改进，所述接收到所述司机客户端发送的订单完成消息后，根据所述奖励信息实时下发奖励到所述司机客户端对应的账户前，还包括：

获取行车里程数，根据所述行车里程数对所述奖励信息进行调整。

作为本发明的进一步改进，所述接收到所述司机客户端发送的订单完成消息后，根据所述奖励信息实时下发奖励到所述司机客户端对应的账户前，还包括：

根据所述订单完成消息及预设的反作弊策略，判断该订单是否为作弊订单，若是则停止发放奖励。

本发明的另一个方面是提供一种司机奖励的下发装置，包括：

接收模块，用于接收乘客客户端发送的订单请求，所述订单请求包括约车时间、起点和终点；

处理模块，用于判断所述订单请求是否满足预设条件，若满足则获取奖励信息；

发送模块，用于向司机客户端推送所述订单请求和所述奖励信息；

所述接收模块还用于，接收到所述司机客户端发送的订单接受消息和订单完成消息；

奖励下发模块，用于若接收到所述司机客户端发送的订单接受消息，则当接收到所述司机客户端发送的订单完成消息时，根据所述奖励信息实时下发奖励到所述司机客户端对应的账户。

进一步的，所述处理模块具体用于：

判断所述约车时间是否满足预设时间条件，其中所述预设时间条件为所述约车时间属于早晚高峰期或深夜时间；和/或

判断所述起点和终点是否满足预设地域条件，其中所述预设地域条件为所述起点和/或所述终点属于人员集散地区或偏僻地区。

进一步的，所述司机奖励的下发装置还包括：

获取模块，用于获取所述约车时间对应的天气信息；

所述处理模块具体用于：

判断所述天气信息是否满足预设天气条件。

进一步的，所述处理模块还用于：获取行车里程数，根据所述行车里程数对所述奖励信息进行调整。

进一步的，所述处理模块还用于：根据所述订单完成消息及预设的反作弊策略，判断该订单是否为作弊订单，若是则停止发放奖励。

本发明的另一个方面是提供一种司机奖励的下发装置，包括：存储器和处理器；

其中，所述存储器用于存储所述处理器可执行指令；

所述处理器调用所述存储器中存储的所述指令时，执行如权利要求1-5中任一项所述的方法。

本发明提供的司机奖励的下发方法及装置，通过接收乘客客户端发送的订单请求，订单请求包括约车时间、起点和终点；判断订单请求是否满足预设条件，若满足则获取奖励信息，向司机客户端推送订单请求和奖励信息；若接收到司机客户端发送的订单接受消息，则当接收到司机客户端发送的订单完成消息时，根据奖励信息实时下发奖励到司机客户端对应的账户。本发明的方法通过司机接单前将订单请求和奖励信息推送给司机客户端，可激励司机在特定时间段或特定区域接单的积极性，并且在推送订单请求前即根据订单请求获取奖励信息，可实现订单完成时即实时下发奖励到司机客户端对应的账户，奖励下发速度提高，从而提高司机的客户体验，进一步提高司机的积极性，同时也能够更合理分配交通资源，提高乘客的出行便利性。

附图说明

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

图1为本发明实施例提供的司机奖励的下发方法流程图；

图2为本发明另一实施例提供的司机奖励的下发方法流程图；

图3为本发明实施例提供的司机奖励的下发装置的结构图。

具体实施方式

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

图1为本发明实施例提供的司机奖励的下发方法流程图。如图1所示，本实施例提供了一种司机奖励的下发方法，执行主体为打车平台，该方法具体步骤如下：

S101、接收乘客客户端发送的订单请求，所述订单请求包括约车时间、起点和终点。

在本实施例中，乘客通过乘客客户端输入约车时间、起点和终点，乘客客户端根据约车时间、起点和终点生成订单请求，并将订单请求发送到打车平台，打车平台在接收到订单请求后，获取其中的约车时间和起点。更具体的乘客客户端也可通过定位乘客所处位置作为起点，或者提供地图供乘客在地图上标记起点和终点。当然本实施例中的订单请求中并不仅限于包括上述信息，还可包括约车的类型，例如出租车、顺风车等等，此处不再赘述。

S102、判断所述订单请求是否满足预设条件，若满足则获取奖励信息，向司机客户端推送所述订单请求和所述奖励信息。

在本实施例中，打车平台在获取订单请求判断订单请求是否满足预设条件，其中预设条件可以仅对约车时间进行约定，例如当订单请求中的约车时间为早晚高峰期(5:30～10:00及17:00～20:00)或者深夜时间(20:00以后)，司机接受订单则可对该订单给予奖励；也可仅对起点和/或终点处于特定地域进行约定，例如当订单请求中的起点位于偏僻地区或者人员集散地区(车站、机场等)，再如当订单请求中的终点位于偏僻地区，司机接受订单则可对该订单给予奖励；当然预设条件可以也可同时对约车时间、起点和终点进行约定，如对同时满足特定时段、特定地域的订单给予奖励。

本实施例中的奖励信息可以包括一个固定奖励金额，当然也可以为一个预估的奖励金额，例如可以根据里程数给以奖励金额，则此时具体的可以根据起点和终点确定可选路线，进而根据可选路线预估一个奖励金额，生成奖励信息，推送给司机客户端，激励司机接单，而在订单完成时则根据实际里程数计算奖励金额。此外也可根据不同的约车时间、不同的起点和/或终点所属地域，来设定不同的奖励金额。本实施例中向司机客户端推送所述订单请求和所述奖励信息时，可以通过一定的规则进行派单，也即推送给某一个司机客户端，再由该司机客户端决定是否接单；或者也可通过广播的方式同时推送给某些司机客户端，由各司机客户端进行抢单。此外若乘客选择约车的类型，则将该订单请求和奖励信息推送给对应类型的司机客户端。本实施例通过在向司机客户端推送该订单请求时，同时推送该奖励信息，从而鼓励司机接受订单，并且让司机了解到在特定时间段、特定地区的订单具有奖励，从而提高司机在特定时间段、特定地区的接单意愿。

进一步的，在推送该奖励信息的同时，打车平台还可将奖励的预设条件推送给司机客户端，具体可通过语音或文字显示于司机客户端，以便司机进一步了解详细的奖励规则，提高其积极性。此外对于不满足奖励的预设条件的订单，打车平台则向司机客户端发送不满足哪些预设条件，例如订单的起始时间不属于预设时间段等。

S103、若接收到所述司机客户端发送的订单接受消息，则当接收到所述司机客户端发送的订单完成消息时，根据所述奖励信息实时下发奖励到所述司机客户端对应的账户。

在本实施例中，司机通过司机客户端接受订单，于约车时间接送乘客，当完成订单后，司机客户端向打车平台发送订单完成消息，打车平台实时将奖励信息中对应的奖励金额发送到司机客户端对应的账户中，从而提高司机的客户体验，提高司机的积极性。本实施例中，由于打车平台在开始时已经确定需要对该订单进行奖励，因此在订单完成后可以直接进行奖励下发，或者经过简单的判定后进行奖励下发，从而能够实现奖励的实时下发，而不需要如现有技术中对每一订单均进行详细获取和分析判断订单的行驶路径和订单时间等信息，提高了处理速度。

进一步的，打车平台将奖励信息中对应的奖励金额发送到司机客户端对应的账户后，还可向司机客户端发送奖励到账通知。

本实施例提供的司机奖励的下发方法，通过接收乘客客户端发送的订单请求，订单请求包括约车时间、起点和终点；判断订单请求是否满足预设条件，若满足则获取奖励信息，向司机客户端推送订单请求和奖励信息；若接收到司机客户端发送的订单接受消息，则当接收到司机客户端发送的订单完成消息时，根据奖励信息实时下发奖励到司机客户端对应的账户。本实施例的方法通过司机接单前将订单请求和奖励信息推送给司机客户端，可激励司机在特定时间段或特定区域接单的积极性，并且在推送订单请求前即根据订单请求获取奖励信息，可实现订单完成时即实时下发奖励到司机客户端对应的账户，奖励下发速度提高，从而提高司机的客户体验，进一步提高司机的积极性，同时也能够更合理分配交通资源，提高乘客的出行便利性。

进一步的，本实施例中还提供一种奖励查询方法，在司机客户端界面中设置查看全部订单、查看有奖励订单和查看无奖励订单的按钮；当司机客户端接收到用户点击查看全部订单的按钮后，则从打车平台获取该用户的全部订单并显示于第一界面中，其中可具体显示每一订单的起始时间、结束时间、起点和终点等信息，也可具体显示每一订单的奖励金额和奖励总金额；当司机客户端接收到用户点击查看有奖励订单的按钮后，则从打车平台获取该用户获得了奖励的订单并显示于第二界面中，其中同样可具体显示每一订单的起始时间、结束时间、起点和终点等信息，也可具体显示每一订单的奖励金额和奖励总金额；当司机客户端接收到用户点击查看无奖励订单的按钮后，则从打车平台获取该用户无奖励的订单，并同时获取这些订单不满足哪些预设条件，显示于第三界面中，其中同样可具体显示每一订单的起始时间、结束时间、起点和终点等信息。此外司机客户端界面中还可包括奖励预设条件的查看按钮，当接收到用户触发该按钮则在第四界面显示奖励预设条件，此外该按钮也可同时设置在第一界面、第二界面和第三界面中，第四界面中同样也可设置有查看全部订单、查看有奖励订单和查看无奖励订单的按钮。通过上述的奖励查询方法可方便司机用户通过客户端快速查看自己完成订单的奖励情况，提高司机的客户体验，进一步提高司机的积极性。

如图2所示，在上述实施例的基础上，S102中所述的判断所述订单请求是否满足预设条件，若满足则获取奖励信息，向司机客户端推送所述订单请求和所述奖励信息，具体可以包括：

S1021、判断所述约车时间是否属于预设时间段，所述预设时间段内供预约车辆数量少于所述预设时间段内订单请求总数量；和/或，判断所述起点和终点是否满足预设地域，其中所述预设地域中供预约车辆数量少于起点为所述预设地域的订单请求总数量。

S1022、若满足则获取奖励信息，向司机客户端推送所述订单请求和所述奖励信息。

在本实施例中，对于一些预设时间段如早晚高峰期和深夜时间，由于该时间段内供预约车辆数量少于该时间段内订单请求总数量，导致供需失衡，也即早晚高峰期打车的乘客较多，而供预约车辆数量较少，可能导致乘客难以约到车，而深夜时间则是供预约车辆数量较少，乘客一般也很难约到车，为鼓励更多的司机在早晚高峰期、深夜时间出车，方便乘客出行，所以可以对约车时间为早晚高峰期或深夜时间等预设时间段的订单进行奖励。对于一些预设地域如机场、车站等人员集散区域和一些偏僻地区，由于该预设地域中供预约车辆数量少于起点为预设地域的订单请求总数量，也会导致供需失衡，也即如机场、车站等人员集散区域人流量较大，打车的乘客较多，而供预约车辆数量较少，可能导致乘客难以约到车，而一些偏僻地区很可能存在空车往返，并且可能不利于司机拿到冲单奖励等，供预约车辆数量也可能较少，乘客一般也很难约到车，为鼓励更多的司机到预设地域接单，可以对订单起点或终点为预设地域的订单进行奖励，有利于人员集散区域的疏散以及偏僻地区乘客的快速出行。当然本实施例中可以根据偏远地区适当调整奖励信息，为司机提供更多的保证，提升司机安全感。

本实施例中的预设时间段和预设地域可以根据历史数据统计获得，，通过历史不同时间和区域的应答率，判断供需失衡时间段和供需失衡地域，作为所述的预设时间段和预设地域，并对所述预设时间段和预设地域设定相应的奖励金额或者奖励倍率；也可实时获取所述的预设时间段和预设地域，也即在接收乘客客户端发送的订单请求时，获取当前时段内供预约车辆数量与当前时间段内订单请求总数量，根据当前时段内供预约车辆数量与当前时间段内订单请求总数量确定一个时间段作为预设时间段，也可获取订单请求起点所在地域中供预约车辆数量与该地域的订单请求总数量，根据订单请求起点所在地域中供预约车辆数量与该地域的订单请求总数量确定一个地域作为预设地域。

作为上述实施例的进一步改进，所述判断所述订单请求是否满足预设条件前，还可包括：

获取所述约车时间对应的天气信息；

所述判断所述订单请求是否满足预设条件，具体包括：

判断所述天气信息是否满足预设天气条件。

在本实施例中，打车平台还可获取天气信息，若天气信息满足预设天气条件，则打车平台根据该预设天气条件确定奖励信息，对接单司机进行奖励。具体的，预设天气条件可以为雨雪天、大雾、雾霾、沙尘暴、台风或者其他极端天气，以鼓励司机在一些特殊天气情况下出车，保证乘客能够在特殊天气下快速出行。

此外，打车平台还可判断约车时间所在的日期是否属于节假日，例如春节、国庆节等，对接单司机进行奖励。当约车时间属于节假日，如春节期间，司机的出车意愿较低，可通过一定的奖励鼓励司机出车。再如国庆节，对于一些旅游景点处交通过于拥挤，司机通常不愿去景点附近接单，打车平台可根据约车时间所述日期及起点位置是否属于热门旅游景点，判断是否需要对订单予以奖励，可增加节假日旅游景点附近的交通资源，便于游客的快速出行。

需要说明的是，上述实施例中所述的各种预设条件可以随意组合，并不仅限于一种预设条件。

作为上述实施例的进一步改进，S103所述的接收到所述司机客户端发送的订单完成消息之后，根据所述奖励信息实时下发奖励到所述司机客户端对应的账户之前，还包括：

获取行车里程数，根据所述行车里程数对所述奖励信息进行调整。

本实施例中，具体的奖励金额可根据行程里程数来确定，也即可以在推送奖励信息时预估一个奖励金额，而在订单完成后根据行车里程数对奖励信息进行调整。

作为上述实施例的进一步改进，所述接收到所述司机客户端发送的订单完成消息后，根据所述奖励信息实时下发奖励到所述司机客户端对应的账户前，还包括：根据所述订单完成消息进行反作弊检测。

具体的，根据所述订单完成消息及预设的反作弊策略，判断该订单是否为作弊订单，若是则停止发放奖励。

在本实施例中，当订单完成后可以对该订单进行反作弊检测，若为作弊情况则停止奖励的实时下发，若不为作弊情况则继续实时下发奖励，通过反作弊检测，以防止司机刷单，恶意赚取奖励，提高公平性。本实施例采用反作弊模型是多种反作弊策略的集合，实时产出作弊订单到作弊订单库，每笔奖励发放前，进入反作弊接口，根据订单完成消息及反作弊策略，判断订单是否为作弊订单，如果确定作弊订单则不发放奖励或者进行一定的处罚。反作弊检测也可以为现有技术中的任意检测方法，此处不再赘述。

图2为本发明实施例提供的司机奖励的下发装置的结构图。本实施例提供一种司机奖励的下发装置，可以执行司机奖励的下发方法实施例提供的处理流程，如图2所示，本实施例的司机奖励的下发装置包括：接收模块201、处理模块202、发送模块203以及奖励下发模块204。

其中，接收模块201，用于接收乘客客户端发送的订单请求，所述订单请求包括约车时间、起点和终点；

处理模块202，用于判断所述订单请求是否满足预设条件，若满足则获取奖励信息；

发送模块203，用于向司机客户端推送所述订单请求和所述奖励信息；

所述接收模块201还用于，接收到所述司机客户端发送的订单接受消息和订单完成消息；

奖励下发模块204，用于若接收到所述司机客户端发送的订单接受消息，则当接收到所述司机客户端发送的订单完成消息时，根据所述奖励信息实时下发奖励到所述司机客户端对应的账户。

进一步的，所述处理模块202具体用于：

判断所述约车时间是否满足预设时间条件，其中所述预设时间条件为所述约车时间属于早晚高峰期或深夜时间；和/或

判断所述起点和终点是否满足预设地域条件，其中所述预设地域条件为所述起点和/或所述终点属于人员集散地区或偏僻地区。

进一步的，所述司机奖励的下发装置还可包括：

获取模块，用于获取所述约车时间对应的天气信息；

所述处理模块202具体用于：

判断所述天气信息是否满足预设天气条件。

进一步的，所述处理模块202还用于：获取行车里程数，根据所述行车里程数对所述奖励信息进行调整。

进一步的，所述处理模块202还用于：根据所述订单完成消息及预设的反作弊策略，判断该订单是否为作弊订单，若是则停止发放奖励。

本发明实施例提供的司机奖励的下发装置可以具体用于执行上述图1所提供的方法实施例，具体功能此处不再赘述。

本实施例提供的司机奖励的下发装置，通过接收乘客客户端发送的订单请求，订单请求包括约车时间、起点和终点；判断订单请求是否满足预设条件，若满足则获取奖励信息，向司机客户端推送订单请求和奖励信息；若接收到司机客户端发送的订单接受消息，则当接收到司机客户端发送的订单完成消息时，根据奖励信息实时下发奖励到司机客户端对应的账户。本实施例的方法通过司机接单前将订单请求和奖励信息推送给司机客户端，可激励司机在特定时间段或特定区域接单的积极性，并且在推送订单请求前即根据订单请求获取奖励信息，可实现订单完成时即实时下发奖励到司机客户端对应的账户，奖励下发速度提高，从而提高司机的客户体验，进一步提高司机的积极性，同时也能够更合理分配交通资源，提高乘客的出行便利性。

本发明的另一实施例提供一种司机奖励的下发装置，包括：存储器和处理器；

其中，所述存储器用于存储所述处理器可执行指令；

所述处理器调用所述存储器中存储的所述指令时，执行司机奖励的下发方法实施例提供的处理流程。

具体的，处理器可以被配置为：

接收乘客客户端发送的订单请求，所述订单请求包括约车时间、起点和终点；

判断所述订单请求是否满足预设条件，若满足则获取奖励信息，向司机客户端推送所述订单请求和所述奖励信息；

若接收到所述司机客户端发送的订单接受消息，则当接收到所述司机客户端发送的订单完成消息时，根据所述奖励信息实时下发奖励到所述司机客户端对应的账户。

在本发明所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (11)

1.一种司机奖励的下发方法，其特征在于，包括：

接收乘客客户端发送的订单请求，所述订单请求包括约车时间、起点和终点；

根据所述约车时间、起点和终点判断所述订单请求是否满足预设条件，若满足则获取奖励信息，向司机客户端推送所述订单请求和所述奖励信息；

若接收到所述司机客户端发送的订单接受消息，则当接收到所述司机客户端发送的订单完成消息时，根据所述奖励信息实时下发奖励到所述司机客户端对应的账户。

2.根据权利要求1所述的方法，其特征在于，所述根据所述约车时间、起点和终点判断所述订单请求是否满足预设条件，具体包括：

判断所述约车时间是否属于预设时间段，所述预设时间段内供预约车辆数量少于所述预设时间段内订单请求总数量；和/或

判断所述起点和终点是否满足预设地域，其中所述预设地域中供预约车辆数量少于起点为所述预设地域的订单请求总数量。

3.根据权利要求1所述的方法，其特征在于，所述判断所述订单请求是否满足预设条件前，还包括：

获取所述约车时间对应的天气信息；

所述判断所述订单请求是否满足预设条件，具体包括：

判断所述天气信息是否满足预设天气条件。

4.根据权利要求1-3中任一项所述的方法，其特征在于，所述接收到所述司机客户端发送的订单完成消息后，根据所述奖励信息实时下发奖励到所述司机客户端对应的账户前，还包括：

获取行车里程数，根据所述行车里程数对所述奖励信息进行调整。

5.根据权利要求4所述的方法，其特征在于，所述接收到所述司机客户端发送的订单完成消息后，根据所述奖励信息实时下发奖励到所述司机客户端对应的账户前，还包括：

根据所述订单完成消息及预设的反作弊策略，判断该订单是否为作弊订单，若是则停止发放奖励。

6.一种司机奖励的下发装置，其特征在于，包括：

接收模块，用于接收乘客客户端发送的订单请求，所述订单请求包括约车时间、起点和终点；

处理模块，用于判断所述订单请求是否满足预设条件，若满足则获取奖励信息；

发送模块，用于向司机客户端推送所述订单请求和所述奖励信息；

所述接收模块还用于，接收到所述司机客户端发送的订单接受消息和订单完成消息；

奖励下发模块，用于若接收到所述司机客户端发送的订单接受消息，则当接收到所述司机客户端发送的订单完成消息时，根据所述奖励信息实时下发奖励到所述司机客户端对应的账户。

7.根据权利要求6所述的装置，其特征在于，所述处理模块具体用于：

判断所述约车时间是否满足预设时间条件，其中所述预设时间条件为所述约车时间属于早晚高峰期或深夜时间；和/或

判断所述起点和终点是否满足预设地域条件，其中所述预设地域条件为所述起点和/或所述终点属于人员集散地区或偏僻地区。

8.根据权利要求6所述的装置，其特征在于，还包括：

获取模块，用于获取所述约车时间对应的天气信息；

所述处理模块具体用于：

判断所述天气信息是否满足预设天气条件。

9.根据权利要求6-8中任一项所述的装置，其特征在于，所述处理模块还用于：

获取行车里程数，根据所述行车里程数对所述奖励信息进行调整。

10.根据权利要求9所述的装置，其特征在于，所述处理模块还用于：

根据所述订单完成消息及预设的反作弊策略，判断该订单是否为作弊订单，若是则停止发放奖励。

11.一种司机奖励的下发装置，其特征在于，包括：存储器和处理器；

其中，所述存储器用于存储所述处理器可执行指令；

所述处理器调用所述存储器中存储的所述指令时，执行如权利要求1-5中任一项所述的方法。