CN107545486A - 一种用车订单处理方法及服务器 - Google Patents

Abstract

本发明实施例公开一种用车订单处理方法及服务器。所述方法包括：接收用车订单信息，所述用车订单信息至少包括乘车出发地；若距离所述乘车出发地在第一预设范围内的司机终端在接单时间间隔内没有进行接单响应，则向第二预设范围内的司机终端发送所述用车订单信息。本实施例公开的服务器用于执行上述方法。所述方法可扩大点播用车订单的预设范围，从而提高车辆资源调度效率，降低用户等待时间，因而增加用户的叫车体验。

Description

一种用车订单处理方法及服务器

技术领域

本发明实施例涉及互联网技术领域，具体涉及一种用车订单处理方法及服务器。

背景技术

服务器收到用户终端发出的用车订单信息后，会在第一时间将用车订单信息向以乘车出发地为中心的预设范围内的司机终端点播发送，直至有司机终端成功接单。

然而，在预设范围内的车辆资源相对不足的情况下，此种方式效率低，导致用户终端发出用车订单信息后需长时间等待接单响应，甚至无司机终端接单的后果。这极大地降低了用户的叫车体验。

因此，如何提供一种方法，使得车辆资源调度效率提高，增加用户的叫车体验，成为亟待解决的问题。

发明内容

针对现有技术中的缺陷，本发明实施例提供一种用车订单处理方法及服务器。

一方面，本发明实施例提出一种用车订单处理方法，包括：

接收用车订单信息，所述用车订单信息至少包括乘车出发地；

若距离所述乘车出发地在第一预设范围内的司机终端在接单时间间隔内没有进行接单响应，则向第二预设范围内的司机终端发送所述用车订单信息。

本发明实施例提供的车辆资源调度处理方法，可在距离乘车出发地在第一预设范围内的司机终端在接单时间间隔内没有接单响应的情况下，扩大发送用车订单的预设范围，从而提高车辆资源调度效率，降低用户等待时间，因此增加用户的叫车体验。

另一方面，本发明实施例提出一种服务器，包括：

接收单元，接收用车订单信息，所述用车订单信息至少包括乘车出发地；

播单单元，若距离所述乘车出发地在第一预设范围内的司机终端在接单时间间隔内没有进行接单响应，则向第二预设范围内的司机终端发送所述用车订单信息。

本发明实施例提供的服务器，可在距离乘车出发地在第一预设范围内的司机终端在接单时间间隔内没有接单响应的情况下，扩大发送用车订单的预设范围，从而提高车辆资源调度效率，降低用户等待时间，因此增加用户的叫车体验。

附图说明

图1为本发明用车订单处理方法实施例的流程示意图；

图2为本发明服务器实施例的结构示意图；

图3为本发明服务器实施例的一种实体结构示意图。

具体实施方式

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

参看图1，本实施例公开一种用车订单处理方法，包括：

S1、接收用车订单信息，所述用车订单信息至少包括乘车出发地；

在用户通过用户终端发送用车订单时，服务器会接收用户终端发送的用车订单信息。所述用车订单具体指实时单，即用户叫车当时即需要用车的订单。其中，所述用车订单信息至少包括乘车出发地。

S2、若距离所述乘车出发地在第一预设范围内的司机终端在接单时间间隔内没有进行接单响应，则向第二预设范围内的司机终端发送所述用车订单信息。

具体地，在服务器接收用车订单信息后，会向以乘车出发地为圆心，以一定距离例如2km为半径的第一预设范围内的司机终端发送所述用车订单信息，等待司机终端进行接单响应。所述发送所述用车订单信息的方式包括广播、点播和指派。其中，广播为同时将订单信息发送给符合要求的多个司机终端，使司机终端抢单，最早确定接单的司机终端将承接该订单；点播为使用一定的规则对司机终端进行排序，首先将订单发送给排序最高的司机终端，如果在预订的时间内该司机终端没有接单，则将订单发送给排序次高的司机终端，以此类推；指派为按一定的规则，将订单分配给排序最高的司机终端，司机终端无法主动选择接单或拒绝，在订单分配给司机终端后，司机终端只能申请改派订单。本发明方法实施例中，若在一定的接单时间间隔例如10s内，无司机终端接单，服务器则向第二预设范围内的司机终端发送所述用车订单信息。优选地，所述第二预设范围可以为以乘车出发地为圆心，以3km为半径的圆形区域。

若在所述第二预设范围内的司机终端在所述接单时间间隔内仍没有进行接单响应，则向第三预设范围内的司机终端发送所述用车订单信息。其中，所述接单时间间隔可以为10s，所述第三预设范围可以优选为以乘车出发地为圆心，以4km为半径的圆形区域。

其中，所述第二预设范围、所述第三预设范围还可以是临近第一预设范围的，运力富余的区域。所述运力富余的区域指该区域内有符合条件的可接单的司机终端。所述第二预设范围、所述第三预设范围的形状还可以为临近第一预设范围的环形、方形、六边形、不规则形状等，本实施例对此不作限定。例如，所述第二预设范围还可以为以乘车出发地为圆心，以3km为半径的圆形区域与第一预设范围非重合的环形区域；所述第三预设范围还可以为以乘车出发地为圆心，以4km为半径的圆形区域与所述第一预设范围、所述第二预设范围非重合的环形区域。

与现有技术相同的是，本发明实施例中的服务器在收到用车订单信息后，会在第一时间将所述用车订单信息向预设范围内的司机终端发送，等待司机终端进行接单响应。然而，在预设范围内的车辆资源相对不足的情况下，此种方式会不可避免地延长用户等待用车时间，降低用户叫车体验。而本发明实施例中，若距离所述乘车出发地在预设范围内的司机终端在接单时间间隔内没有进行接单响应，则逐步扩大发送用车订单的预设范围，从而提高车辆资源调度效率，降低用户等待时间，因此增加用户的叫车体验。

可以理解的是，本发明实施例中的预设范围可以根据实际情况进行设定，不同地域/不同时间下对应的预设范围可以是不同的，即所述第一预设范围、所述第二预设范围和所述第三预设范围根据不同地域、不同时间段动态调整。当然，所述接单时间间隔也可以根据需要动态调整，本实施例对此不作限定。例如，在B市郊区的C公园附近，在17:00-18:00时间段内，接单时间间隔可以为10s，第一预设范围设为以乘车出发地为圆心，半径为1.5km的圆形区域，第二预设范围设为以乘车出发地为圆心，半径为2km的圆形区域，第三预设范围半径为以乘车出发地为圆心，半径为2.5km的圆形区域；而在相同时间段内，在B市中心的大厦Z附近由于用车需求相对较高，接单时间间隔可以为15s，第一预设范围设为以乘车出发地为圆心，半径为2km的圆形区域，第二预设范围设为以乘车出发地为圆心，半径为3km的圆形区域，第三预设范围半径为以乘车出发地为圆心，半径为4km的圆形区域；而在18:01-19:00时间段内，由于在B市中心的大厦Z附近用车需求进一步增加，导致运力紧张，则接单时间间隔可以动态调整为20s，第一预设范围半径可以动态调整为3km，第二预设范围半径可以动态调整为4km，第三预设范围可以动态调整为5km。

参看图2，本发明实施例提出一种服务器，包括：接收单元1和播单单元2；其中：

接收单元1，接收用车订单信息，所述用车订单信息至少包括乘车出发地；

播单单元2，若距离所述乘车出发地在第一预设范围内的司机终端在接单时间间隔内没有进行接单响应，则向第二预设范围内的司机终端发送所述用车订单信息。

具体地，在用户通过用户终端发送用车订单时，服务器的接收单元1会接收用户终端发送的用车订单信息。所述用车订单具体指实时单，即用户叫车当时即需要用车的订单。其中，所述用车订单信息至少包括乘车出发地。

在服务器接收单元1接收用车订单信息后，播单单元2会向以乘车出发地为圆心，以一定距离例如2km为半径的第一预设范围内的司机终端发送所述用车订单信息，等待司机终端进行接单响应。所述发送所述用车订单信息的方式包括广播、点播和指派。其中，广播为同时将订单信息发送给符合要求的多个司机终端，使司机终端抢单，最早确定接单的司机终端将承接该订单；点播为使用一定的规则对司机终端进行排序，首先将订单发送给排序最高的司机终端，如果在预订的时间内该司机终端没有接单，则将订单发送给排序次高的司机终端，以此类推；指派为按一定的规则，将订单分配给排序最高的司机终端，司机终端无法主动选择接单或拒绝，在订单分配给司机终端后，司机终端只能申请改派订单。若在一定的接单时间间隔例如10s内，无司机终端接单，播单单元2则向第二预设范围内的司机终端发送所述用车订单信息。优选地，所述第二预设范围可以为以乘车出发地为圆心，以3km为半径的圆形区域。

若在所述第二预设范围内的司机终端在所述接单时间间隔内仍没有进行接单响应，播单单元2则向第三预设范围内的司机终端发送所述用车订单信息。其中，所述接单时间间隔可以为10s，所述第三预设范围可以优选为以乘车出发地为圆心，以4km为半径的圆形区域。

与现有技术相同的是，本发明实施例中的服务器在收到用车订单信息后，会在第一时间将所述用车订单信息向预设范围内的司机终端发送，等待司机终端进行接单响应。然而，在预设范围内的车辆资源相对不足的情况下，现有技术会不可避免地延长用户等待用车时间，降低用户叫车体验。而本发明实施例中，若距离所述乘车出发地在预设范围内的司机终端在接单时间间隔内没有进行接单响应，服务器则逐步扩大发送用车订单的预设范围，从而提高车辆资源调度效率，降低用户等待时间，因此增加用户的叫车体验。

可以理解的是，本发明实施例中的预设范围可以根据实际情况进行设定，不同地域/不同时间下对应的预设范围可以是不同的，即所述第一预设范围、所述第二预设范围和所述第三预设范围根据不同地域、不同时间段动态调整。当然，所述接单时间间隔也可以根据需要动态调整，本实施例对此不作限定。

图3示例了一种服务器的实体结构示意图，如图3所示，该服务器可以包括：处理器(processor)310、通信接口(Communications Interface)320、存储器(memory)330和总线340，其中，处理器310，通信接口320，存储器330通过总线340完成相互间的通信。通信接口340可以用于服务器与智能电视之间的信息传输。处理器310可以调用存储器330中的逻辑指令，以执行如下方法：接收用车订单信息，所述用车订单信息至少包括乘车出发地；若距离所述乘车出发地在第一预设范围内的司机终端在接单时间间隔内没有进行接单响应，则向第二预设范围内的司机终端发送所述用车订单信息。

此外，上述的存储器330中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

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

Claims (10)

1.一种用车订单处理方法，其特征在于，包括：

接收用车订单信息，所述用车订单信息至少包括乘车出发地；

若距离所述乘车出发地在第一预设范围内的司机终端在接单时间间隔内没有进行接单响应，则向第二预设范围内的司机终端发送所述用车订单信息。

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

若所述第二预设范围内的司机终端在所述接单时间间隔内仍没有进行接单响应，则向第三预设范围内的司机终端发送所述用车订单信息。

3.根据权利要求2所述的方法，其特征在于，所述第一预设范围、所述第二预设范围和所述第三预设范围根据不同地域、不同时间段动态调整。

4.根据权利要求1或2或3所述的方法，其特征在于，所述接单时间间隔动态调整。

5.根据权利要求1或2所述的方法，其特征在于，所述发送所述用车订单信息的方式包括广播、点播和指派。

6.一种服务器，其特征在于，包括：

接收单元，接收用车订单信息，所述用车订单信息至少包括乘车出发地；

播单单元，若距离所述乘车出发地在第一预设范围内的司机终端在接单时间间隔内没有进行接单响应，则向第二预设范围内的司机终端发送所述用车订单信息。

7.根据权利要求6所述的服务器，其特征在于，所述播单单元还用于：

若所述第二预设范围内的司机终端在所述接单时间间隔内仍没有进行接单响应，则向第三预设范围内的司机终端点播发送所述用车订单信息。

8.根据权利要求7所述的服务器，其特征在于，所述第一预设范围、所述第二预设范围和所述第三预设范围根据不同地域、不同时间段动态调整。

9.根据权利要求6或7或8所述的服务器，其特征在于，所述接单时间间隔动态调整。

10.根据权利要求6或7所述的服务器，其特征在于，所述发送所述用车订单的方式包括广播、点播和指派。