CN107103376A - 一种打车方法及系统 - Google Patents

Abstract

本发明公开了一种打车方法及系统，涉及计算机网络技术领域，该方法包括：接收UE发送的货物拼车请求消息，所述货物拼车请求消息中包括有货物信息、发货地点和收货地点；获取所述发货地点的预设范围内的终端；将所述货物拼车请求消息与预设范围内每一终端对应的当前行程信息进行匹配，所述行程信息中包括行车路线和车辆后备箱可用体积；根据匹配结果，分配所述货物拼车请求消息对应的订单。本发明技术方案实现了人、货互拼的打车方式，从而更加高效地利用车辆资源，提升用户体验。

Description

一种打车方法及系统

技术领域

本发明涉及计算机网络技术领域，特别涉及一种打车方法及系统。

背景技术

目前，城市交通拥堵情况越来越严重，很多大城市出现了打车难，上下班时间交通压力大的问题，而为了使得城市用车容量维持在一定限度内，对用户的出行带来很多不便。

现在的打车系统，如滴滴的顺风车、快车业务已经可以实现人的拼单出行，从而缓解上下班时间的交通压力。但是，现有打车系统仍然没有实现车辆资源的最大化利用。而且，当前有很多用户有同城的或跨城的小件物品的配送需求，比如鲜花、蛋糕、外卖餐饮、重要文件等，需要在同城或跨城之间投递，单独运送成本很高，而且车辆资源没有很好利用。因此，急需提供一种能够实现人、货互拼的打车方法及系统，以实现汽车资源的高效利用。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的打车方法及系统，实现人、货互拼的打车方式，从而更加高效地利用车辆资源，提升用户体验。

依据本发明的一个方面，提供了一种打车方法，所述方法包括：

接收UE发送的货物拼车请求消息，所述货物拼车请求消息中包括有货物信息、发货地点和收货地点；

获取所述发货地点的预设范围内的终端；

将所述货物拼车请求消息与预设范围内每一终端对应的当前行程信息进行匹配，所述行程信息中包括行车路线和车辆后备箱可用体积；

根据匹配结果，分配所述货物拼车请求消息对应的订单。

可选地，所述将所述货物拼车请求消息与预设范围内每一终端对应的当前行程信息进行匹配，进一步包括：

将所述货物拼车请求消息中货物信息与预设范围内每一终端对应的行程信息中车辆后备箱可用体积进行匹配；

若匹配成功，则将所述货物拼车请求消息中发货地点和收货地点与预设范围内每一终端对应的行程信息中行车路线进行匹配。

可选地，所述根据匹配结果，分配所述货物拼车请求消息对应的订单，进一步包括：

确定与所述货物拼车请求消息匹配度最高的行程信息对应的终端，并向该终端分配所述货物拼车请求消息对应的订单。

可选地，所述根据匹配结果，分配所述货物拼车请求消息对应的订单，进一步包括：

获取所述发货地点与预设范围内每一终端之间的距离，若所述距离小于预设距离阈值时，按照距离从小到大的顺序，向与所述货物拼车请求消息匹配成功的行程信息对应的终端分配所述货物拼车请求消息对应的订单。

可选地，所述每一终端对应的行程信息中还包括该终端是否存在已接订单以及已接订单对应的乘客的拼车意愿；

相应的，所述将所述货物拼车请求消息与预设范围内每一终端对应的当前行程信息进行匹配，还包括：

当某一终端存在已接订单，且该已接订单对应的乘客的拼车意愿为否时，则确定该终端对应的行程信息与所述货物拼车请求消息匹配失败。

可选地，在所述将所述货物拼车请求消息与预设范围内每一终端对应的当前行程信息进行匹配之前，所述方法还包括：

根据预设范围内每一终端的历史订单信息和/或注册信息确定每一终端对应的当前行程信息。

依据本发明的另一个方面，提供了一种打车系统，所述系统包括：

接收单元，用于接收UE发送的货物拼车请求消息，所述货物拼车请求消息中包括有货物信息、发货地点和收货地点；

获取单元，用于获取所述发货地点的预设范围内的终端；

匹配单元，用于将所述货物拼车请求消息与预设范围内每一终端对应的当前行程信息进行匹配，所述行程信息中包括行车路线和车辆后备箱可用体积；

分配单元，用于根据匹配结果，分配所述货物拼车请求消息对应的订单。

可选地，所述匹配单元，进一步用于将所述货物拼车请求消息中货物信息与预设范围内每一终端对应的行程信息中车辆后备箱可用体积进行匹配，若匹配成功，则将所述货物拼车请求消息中发货地点和收货地点与预设范围内每一终端对应的行程信息中行车路线进行匹配。

可选地，所述分配单元，进一步用于确定与所述货物拼车请求消息匹配度最高的行程信息对应的终端，并向该终端分配所述货物拼车请求消息对应的订单。

可选地，所述分配单元，进一步用于获取所述发货地点与预设范围内每一终端之间的距离，若所述距离小于预设距离阈值时，按照距离从小到大的顺序，向与所述货物拼车请求消息匹配成功的行程信息对应的终端分配所述货物拼车请求消息对应的订单。

可选地，所述每一终端对应的行程信息中还包括该终端是否存在已接订单以及已接订单对应的乘客的拼车意愿；

相应的，所述匹配单元，还用于当某一终端存在已接订单，且该已接订单对应的乘客的拼车意愿为否时，确定该终端对应的行程信息与所述货物拼车请求消息匹配失败。

可选地，所述系统还包括：

确定单元，用于在所述将所述货物拼车请求消息与预设范围内每一终端对应的当前行程信息进行匹配之前，根据预设范围内每一终端的历史订单信息和/或注册信息确定每一终端对应的当前行程信息。

本发明提供的打车方法及系统，通过综合考虑终端的当前行程信息中行车路线和车辆后备箱可用体积与货物拼车请求消息中的发货地点、货物信息以及收货地点等因素进行打车匹配，并根据匹配结果，对货物拼车请求消息对应的订单进行分配，实现人、货互拼的打车方式，从而更加高效地利用车辆资源，提升用户体验。

附图说明

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

图1是本公开一种实施方式的打车方法的流程图；

图2是本公开另一种实施方式的打车方法的流程图；

图3是本公开一种实施方式的打车系统的结构框图。

具体实施方式

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

以下对本公开实施例中提及的部分词语进行举例说明。

本领域技术人员应当理解，本发明实施例中提及的用户设备(User Equipment，简称UE)是指呼叫服务方，如交通工具叫车服务中的乘客，所使用的移动终端或个人计算机(Personal Computer，简称PC)等设备。例如智能手机、个人数码助理(PDA)、平板电脑、笔记本电脑、车载电脑(carputer)、掌上游戏机、智能眼镜、智能手表、可穿戴设备、虚拟显示设备或显示增强设备(如Google Glass、Oculus Rift、Hololens、Gear VR)等。

本领域技术人员应当理解，本发明实施例中提及的终端为提供服务方，如交通工具叫车服务中的司机，所使用的用于接单的移动终端或个人计算机(Personal Computer，简称PC)等设备。例如智能手机、个人数码助理(PDA)、平板电脑、笔记本电脑、车载电脑(carputer)、掌上游戏机、智能眼镜、智能手表、可穿戴设备、虚拟显示设备或显示增强设备(如Google Glass、Oculus Rift、Hololens、Gear VR)等。

本实施例中，为了区别乘客和司机，分别采用用户设备UE和终端来分别表示乘客和司机所持的移动终端等设备。

图1是本公开一种实施方式的打车方法的流程图。

参照图1，所述打车方法包括以下步骤：

S11：接收UE发送的货物拼车请求消息，所述货物拼车请求消息中包括有货物信息、发货地点和收货地点。

在实际应用中，当用户需要进行货物拼车时，通过UE发送货物拼车请求消息，以将用户的送货需求，如，货物信息、发货地点和收货地点等发送到打车系统。可理解的，所述货物拼车请求消息一般为预约请求，至少15分钟前发送，此时，系统会提示用户尽快打包好待拼车的货物。

进一步地，系统会根据货物信息、发货地点和收货地点，按照预设策略估算货物所需的拼车价格。而且，为了保证货物的尽快送达，乘客还可以自己加价。

需要说明的是，本实施例中的货物信息包括但不限于货物的体积、重量、品类以及其他备注信息。

S12：获取所述发货地点的预设范围内的终端。

需要说明的是，本实施例中预设范围的具体取值可根据发货地点和/或终端所属城市、城区以及终端当前所处的地理位置进行确定，本发明对此不作具体限定。

在实际应用中，获取所述发货地点的预设范围内的终端，具体通过获取发货地点的坐标信息，然后获取该坐标信息的预设范围内的各个终端实现。

其中，对于发货地点的坐标信息，既可以由乘客使用其用户设备启动打车系统乘客端来键入或者说出，也可以经由乘客的用户设备中的定位系统，例如全球定位系统、基站定位系统等，所获得的定位信息来确定，还可以在适当的情况下经由其他信息来确定，其中，该其他信息可以包括但不限于公交车站、地铁站、特定路口和特定建筑物以及在这些位置处所张贴的二维码信息等。

S13：将所述货物拼车请求消息与预设范围内每一终端对应的当前行程信息进行匹配。

其中，所述行程信息中包括行车路线和车辆后备箱可用体积。

S14：根据匹配结果，分配所述货物拼车请求消息对应的订单。

需要说明的是，货物拼车请求消息对应的订单中包括如下信息：订单的始发地(发货地点)、订单的目的地(收货地点)、乘客愿意额外支付的附加费、乘客愿意等待的时间等。

本发明实施例提供的打车方法，通过综合考虑终端的当前行程信息中行车路线和车辆后备箱可用体积与货物拼车请求消息中的发货地点、货物信息以及收货地点等因素进行打车匹配，并根据匹配结果，对货物拼车请求消息对应的订单进行分配，实现人、货互拼的打车方式，从而更加高效地利用车辆资源，提升用户体验。

图2是本公开另一种实施方式的打车方法的流程图。

参照图2，所述打车方法包括以下步骤：

S21：接收UE发送的货物拼车请求消息，所述货物拼车请求消息中包括有货物信息、发货地点和收货地点。

S22：获取所述发货地点的预设范围内的终端；

S23：将所述货物拼车请求消息中货物信息与预设范围内每一终端对应的行程信息中车辆后备箱可用体积进行匹配，若匹配成功，则将所述货物拼车请求消息中发货地点和收货地点与预设范围内每一终端对应的行程信息中行车路线进行匹配。

其中，所述行程信息中包括行车路线和车辆后备箱可用体积。

S24：根据匹配结果，分配所述货物拼车请求消息对应的订单。

本发明实施例提供的打车方法，通过将货物拼车请求消息中货物信息与预设范围内每一终端对应的行程信息中车辆后备箱可用体积进行匹配，在匹配成功时，进一步将货物拼车请求消息中发货地点和收货地点与预设范围内每一终端对应的行程信息中行车路线进行匹配，实现订单的精准分配，有效减少司机接单的行驶里程和乘客等待时间，进而实现人、货互拼的打车方式，从而更加高效地利用车辆资源，提升用户体验。

在本公开的一种可选实施例中，所述每一终端对应的行程信息中还包括该终端是否存在已接订单以及已接订单对应的乘客的拼车意愿。

进一步地，所述将所述货物拼车请求消息与预设范围内每一终端对应的当前行程信息进行匹配，还包括：当某一终端存在已接订单，且该已接订单对应的乘客的拼车意愿为否时，则确定该终端对应的行程信息与所述货物拼车请求消息匹配失败。

实际应用中，在将货物拼车请求消息与预设范围内每一终端对应的当前行程信息进行匹配时，要求：终端所属的车辆的后备箱可用体积足够大、距离发货起始点近、且车内无乘客或车内乘客愿意拼车。司机看到送货订单后可以接单，具体的：

如果车辆后备箱可用体积*冗余系数<货物体积，则匹配失败，货物拼车请求消息对应的订单不发送给对应终端；

如果车辆距离发货起始地点的距离>预设距离阈值，则匹配失败，货物拼车请求消息对应的订单不发单给对应终端；

如果车内有乘客且乘客不愿意拼车，则匹配失败，货物拼车请求消息对应的订单不发单给对应终端。

在本公开的一种可选实施例中，所述根据匹配结果，分配所述货物拼车请求消息对应的订单，进一步包括：确定与所述货物拼车请求消息匹配度最高的行程信息对应的终端，并向该终端分配所述货物拼车请求消息对应的订单。

本发明实施例，通过确定出与货物拼车请求消息匹配度最高的行程信息对应的终端，优先向匹配度最高的行程信息对应的终端分配订单，实现订单的精准分配，有效减少司机接单的行驶里程和乘客等待时间，从而提升用户体验。

在本公开的另一种可选实施例中，所述根据匹配结果，分配所述货物拼车请求消息对应的订单，进一步包括：获取所述发货地点与预设范围内每一终端之间的距离，若所述距离小于预设距离阈值时，按照距离从小到大的顺序，向与所述货物拼车请求消息匹配成功的行程信息对应的终端分配所述货物拼车请求消息对应的订单。

在一个具体实施例中，所述获取所述发货地点与预设范围内每一终端之间的距离，进一步包括：获取所述发货地点的坐标信息和该坐标信息的预设范围内的各个终端，以及每一终端的坐标信息，根据发货地点所属城市的交通地图信息、该发货地点的坐标信息和每一终端的坐标信息，获取所述发货地点到每一终端的路面距离。

可理解的是，上面提到的获取所述发货地点与预设范围内每一终端之间的距离的方式仅是举例，除了上述情况之外还可以包括其他的情况。本领域技术人员需要根据实际应用进行设置。

其中，所述预设距离阈值的大小可根据可根据终端所属城市、城区以及终端当前所处的地理位置的交通状况以及当前时间进行确定，如交通状况良好，则距离对应的预设距离阈值的取值可以确定的大一些，如交通状况拥堵，为了保证及时到达发货地点，则预设距离阈值的取值可以确定的小一些，本发明对此不作具体限定。

本发明实施例，通过按照发货地点与预设范围内每一终端之间的距离的远近程度，确定向匹配成功的行程信息对应终端分配货物拼车请求消息对应订单的顺序，优先向距离发货地点近的终端分配订单，实现订单的精准分配，有效减少司机接单的行驶里程和乘客等待时间，从而提升用户体验。

在本公开的一种可选实施例中，在所述将所述货物拼车请求消息与预设范围内每一终端对应的当前行程信息进行匹配之前，所述方法还包括：根据预设范围内每一终端的历史订单信息和/或注册信息确定每一终端对应的当前行程信息。

需要说明的是，本实施例中，每一历史订单信息中包括如下信息：订单的始发地(发货地点)、订单的目的地(收货地点)、乘客愿意额外支付的附加费、乘客愿意等待的时间、乘客是否携带大件货物以及货物的信息等。注册信息，既可以由司机使用其终端启动打车系统司机端时键入或者语音输入的车辆信息。打车系统可根据该车辆信息确定车辆后备箱的体积，并根据历史接单情况确定车辆后备箱的使用状况以及可用体积，并根据历史接单情况确定车辆的行车路线，进而确定每一终端对应的当前行程信息。

下面通过一个具体实施例对本发明公开技术方案进行详细、清楚的说明。

在具体实施例中：冗余系数＝0.6，其中，车厢内的体积并不都能装满东西；预设距离阈值的取值：2km；

场景1：用户A发一筐水果给领导，所述水果的体积为：0.2*0.3*0.4＝0.024立方米。

接收UE发送的货物拼车请求消息后，打车系统根据预估价格或用户加价后的最终价格生成订单。系统根据算法匹配到附近2km内有4辆车，分别为A、B、C和D，其中：

A:一个后备箱可用体积＝0.21立方米的无乘客快车，距离200m；

B:一个后备箱可用体积＝0.03立方米的无乘客快车，距离300m；

C:一个后备箱可用体积＝0.21立方米的有乘客但不愿意拼车，距离500m；

D:一个后备箱可用体积＝0.21立方米的有乘客愿意拼车，距离800m

这时，

0.21立方米后备箱的车：后备箱可用体积*冗余系数＝0.21*0.6＝0.126，

0.03立方米后备箱的车：后备箱可用体积*冗余系数＝0.03*0.6＝0.018，

通过算法进行匹配,发现：B后备箱可用体积不符合要求，C乘客意愿不符合要求，A和D都符合要求，但是由于A距离发货点距离更近，所以选择先向A车辆对应的终端分配订单，如果A车辆的司机A拒单，再发送给D车辆对应的终端分配订单。

当然，也可以采用先向A车辆对应的终端分配订单，再向D车辆对应的终端分配订单的方法实现订单分配。

本公开实施例提供的打车方法，通过距离、后备箱可用体积及乘客货物体积比较、车上乘客意愿等因素结合的算法来撮合人、货互拼订单，实现人、货互拼的打车方式，从而更加高效地利用车辆资源，提升用户体验。

对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本公开实施例并不受所描述的动作顺序的限制，因为依据本公开实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本公开实施例所必须的。

图3是本公开一种实施方式的打车系统的结构框图。

参照图3，所述打车系统包括接收单元301、获取单元302、匹配单元303和分配单元304，其中：

所述接收单元301，用于接收UE发送的货物拼车请求消息，所述货物拼车请求消息中包括有货物信息、发货地点和收货地点；

所述获取单元302，用于获取所述发货地点的预设范围内的终端；

所述匹配单元303，用于将所述货物拼车请求消息与预设范围内每一终端对应的当前行程信息进行匹配，所述行程信息中包括行车路线和车辆后备箱可用体积；

所述分配单元304，用于根据匹配结果，分配所述货物拼车请求消息对应的订单。

在本公开的一种可选实施例中，所述匹配单元303，进一步用于将所述货物拼车请求消息中货物信息与预设范围内每一终端对应的行程信息中车辆后备箱可用体积进行匹配，若匹配成功，则将所述货物拼车请求消息中发货地点和收货地点与预设范围内每一终端对应的行程信息中行车路线进行匹配。

在本公开的一种可选实施例中，所述分配单元304，进一步用于确定与所述货物拼车请求消息匹配度最高的行程信息对应的终端，并向该终端分配所述货物拼车请求消息对应的订单。

在本公开的一种可选实施例中，所述分配单元304，进一步用于获取所述发货地点与预设范围内每一终端之间的距离，若所述距离小于预设距离阈值时，按照距离从小到大的顺序，向与所述货物拼车请求消息匹配成功的行程信息对应的终端分配所述货物拼车请求消息对应的订单。

在本公开的一种可选实施例中，所述每一终端对应的行程信息中还包括该终端是否存在已接订单以及已接订单对应的乘客的拼车意愿。

进一步地，所述匹配单元303，还用于当某一终端存在已接订单，且该已接订单对应的乘客的拼车意愿为否时，确定该终端对应的行程信息与所述货物拼车请求消息匹配失败。

在本公开的一种可选实施例中，所述系统还包括附图中未示出的确定单元。所述确定单元，用于在所述将所述货物拼车请求消息与预设范围内每一终端对应的当前行程信息进行匹配之前，根据预设范围内每一终端的历史订单信息和/或注册信息确定每一终端对应的当前行程信息。

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

综上所述，根据上述本公开实施例提供的打车方法及系统，通过综合考虑终端的当前行程信息中行车路线和车辆后备箱可用体积与货物拼车请求消息中的发货地点、货物信息以及收货地点等因素进行打车匹配，并根据匹配结果，对货物拼车请求消息对应的订单进行分配，实现人、货互拼的打车方式，从而更加高效地利用车辆资源，提升用户体验。

本公开的实现和本文中提供的所有功能操作可以用数字电子电路、或者用计算机软件、固件或硬件，包括本说明书及其结构等同方案中所公开的结构、或者其中的一个或多个的组合来实现。本公开的实现可以实现为一个或多个计算机程序产品，即在计算机可读介质上编码的计算机程序指令的一个或多个模块，这些指令由数据处理装置来执行或者用以控制数据处理装置的操作。该计算机可读介质可以是机器可读存储设备、机器可读存储基片、存储器设备、影响机器可读传播信号的组合物或者其中的一个或多个的组合。术语“数据处理装置”涵盖用于处理数据的所有装置、设备和机器，包括例如可编程处理器、计算机或者多个处理器或计算机。除了硬件之外，该装置可以包括为所描述的计算机程序创建执行环境的代码，例如构成处理器固件、协议栈、数据库管理系统、操作系统或者其中的一个或多个的组合的代码。

计算机程序(也称为程序、软件、软件应用、脚本或代码)可以用任何形式的编程语言(包括编译语言或解释语言)来编写，并且计算机程序可以用任何形式来部署，包括作为独立程序或者作为模块、部件、子例程或者适合在计算环境中使用的其他单元。计算机程序并非必须对应于文件系统中的文件。程序可以存储在保持其他程序或数据(例如标记语言文档中所存储的一个或多个脚本)的文件的部分中，存储在专用于所描述的程序的单个文件中，或者存储在多个协同文件(例如存储一个或多个模块、子程序或者代码的部分的文件)中。计算机程序可以被部署成在一个计算机上来执行，或者在位于一个站点处或分布在多个站点处且通过通信网络互连的多个计算机上来执行。

本公开中所描述的过程和逻辑流可以由执行一个或多个计算机程序的一个或多个可编程处理器来执行以通过操作输入数据并且生成输出来执行功能。该过程和逻辑流也可以由专用逻辑电路来执行，并且装置也可以实现为该专用逻辑电路，该专用逻辑电路例如为FPGA(现场可编程门阵列)或者ASIC(专用集成电路)。

适合执行计算机程序的处理器包括例如通用和专用微处理器二者、以及任何种类的数字计算机的任何一个或多个处理器。通常，处理器从只读存储器或者随机存取存储器或者二者接收指令和数据。计算机的元件可以包括用于执行指令的处理器以及用于存储指令和数据的一个或多个存储器设备。通常，计算机还将包括一个或多个海量

存储设备以便存储数据，或者该计算机在操作上耦合以从海量存储设备接收或向海量存储设备传送数据或者二者，该海量存储设备例如是磁盘、磁光盘或者光盘。然而，计算机不需要具有这样的设备。此外，计算机可以嵌入在另一设备中，该另一设备例如为移动电话、个人数字助理(PDA)、移动音频播放器、全球定位系统(GPS)接收器等。适合存储计算机程序指令和数据的计算机可读介质包括所有形式的非易失性存储器、介质和存储器设备，包括例如：半导体存储器设备，如EPROM、EEPROM和闪存设备；磁盘，如内置硬盘或可移除盘；磁光盘；以及CD ROM和DVD-ROM盘。该处理器和存储器可以用专用逻辑电路来补充或者并入该专用逻辑电路中。

为了提供与用户的交互，本公开的实现可以在具有用于向用户显示信息的显示设备(例如CRT(阴极射线管)或LCD(液晶显示器)监视器)以及键盘和定点设备(例如鼠标或跟踪球，通过其用户可以向计算机提供输入)的计算机上来实现。也可以使用其他种类的设备来提供与用户的交互；例如，向用户提供的反馈可以是任何形式的感觉反馈，例如视觉反馈、听觉反馈或者触觉反馈；并且来自用户的输入可以以任何形式来接收，包括听觉、语音或触觉输入。

虽然本公开包括一些细节，然而不应当将这些细节理解为对本公开或者要求保护的内容的范围的限制，而是应当被理解为对本公开的示例实现的特征的描述。本公开中在单独实现的情境中描述的某些特征还可以与单个实现组合来提供。相反地，在单个实现的情境中描述的各个特征也可以分别在多个实现中来提供或者在任何合适的子组合中来提供。此外，虽然以上可以将特征描述为以某种组合来执行并且甚至初始就要求这样保护，然而在一些情况下可以从组合中去掉来自要求保护的组合的一个或多个特征，并且要求保护的组合可以涉及子组合或子组合的变化。

类似地，虽然在附图中按照特定顺序来描绘操作，然而这不应当被理解为要求这样的操作按照所示的特定顺序或者按照相继顺序来执行，或者要求所有图示操作都被执行，以实现期望的结果。在一些

境况下，多任务和并行处理可能是有利的。此外，以上描述的实现中的各种系统部件的分离不应当被理解为在所有实现中都要求这样的分离，而且应当理解，所描述的程序部件和系统通常可以在单个软件产品中集成在一起或者被封装成多个软件产品。

以上实施方式仅适于说明本发明，而并非对本发明的限制，有关技术领域的普通技术人员，在不脱离本发明的精神和范围的情况下，还可以做出各种变化和变型，因此所有等同的技术方案也属于本发明的范畴，本发明的专利保护范围应由权利要求限定。

Claims (12)

1.一种打车方法，其特征在于，所述方法包括：

接收UE发送的货物拼车请求消息，所述货物拼车请求消息中包括有货物信息、发货地点和收货地点；

获取所述发货地点的预设范围内的终端；

将所述货物拼车请求消息与预设范围内每一终端对应的当前行程信息进行匹配，所述行程信息中包括行车路线和车辆后备箱可用体积；

根据匹配结果，分配所述货物拼车请求消息对应的订单。

2.如权利要求1所述的方法，其特征在于，所述将所述货物拼车请求消息与预设范围内每一终端对应的当前行程信息进行匹配，进一步包括：

将所述货物拼车请求消息中货物信息与预设范围内每一终端对应的行程信息中车辆后备箱可用体积进行匹配；

若匹配成功，则将所述货物拼车请求消息中发货地点和收货地点与预设范围内每一终端对应的行程信息中行车路线进行匹配。

3.如权利要求1所述的方法，其特征在于，所述根据匹配结果，分配所述货物拼车请求消息对应的订单，进一步包括：

确定与所述货物拼车请求消息匹配度最高的行程信息对应的终端，并向该终端分配所述货物拼车请求消息对应的订单。

4.如权利要求1所述的方法，其特征在于，所述根据匹配结果，分配所述货物拼车请求消息对应的订单，进一步包括：

获取所述发货地点与预设范围内每一终端之间的距离，若所述距离小于预设距离阈值时，按照距离从小到大的顺序，向与所述货物拼车请求消息匹配成功的行程信息对应的终端分配所述货物拼车请求消息对应的订单。

5.如权利要求1所述的方法，其特征在于，所述每一终端对应的行程信息中还包括该终端是否存在已接订单以及已接订单对应的乘客的拼车意愿；

相应的，所述将所述货物拼车请求消息与预设范围内每一终端对应的当前行程信息进行匹配，还包括：

当某一终端存在已接订单，且该已接订单对应的乘客的拼车意愿为否时，则确定该终端对应的行程信息与所述货物拼车请求消息匹配失败。

6.如权利要求1-5任一项所述的方法，其特征在于，在所述将所述货物拼车请求消息与预设范围内每一终端对应的当前行程信息进行匹配之前，所述方法还包括：

根据预设范围内每一终端的历史订单信息和/或注册信息确定每一终端对应的当前行程信息。

7.一种打车系统，其特征在于，所述系统包括：

接收单元，用于接收UE发送的货物拼车请求消息，所述货物拼车请求消息中包括有货物信息、发货地点和收货地点；

获取单元，用于获取所述发货地点的预设范围内的终端；

匹配单元，用于将所述货物拼车请求消息与预设范围内每一终端对应的当前行程信息进行匹配，所述行程信息中包括行车路线和车辆后备箱可用体积；

分配单元，用于根据匹配结果，分配所述货物拼车请求消息对应的订单。

8.如权利要求7所述的系统，其特征在于，所述匹配单元，进一步用于将所述货物拼车请求消息中货物信息与预设范围内每一终端对应的行程信息中车辆后备箱可用体积进行匹配，若匹配成功，则将所述货物拼车请求消息中发货地点和收货地点与预设范围内每一终端对应的行程信息中行车路线进行匹配。

9.如权利要求7所述的系统，其特征在于，所述分配单元，进一步用于确定与所述货物拼车请求消息匹配度最高的行程信息对应的终端，并向该终端分配所述货物拼车请求消息对应的订单。

10.如权利要求7所述的系统，其特征在于，所述分配单元，进一步用于获取所述发货地点与预设范围内每一终端之间的距离，若所述距离小于预设距离阈值时，按照距离从小到大的顺序，向与所述货物拼车请求消息匹配成功的行程信息对应的终端分配所述货物拼车请求消息对应的订单。

11.如权利要求7所述的系统，其特征在于，所述每一终端对应的行程信息中还包括该终端是否存在已接订单以及已接订单对应的乘客的拼车意愿；

相应的，所述匹配单元，还用于当某一终端存在已接订单，且该已接订单对应的乘客的拼车意愿为否时，确定该终端对应的行程信息与所述货物拼车请求消息匹配失败。

12.如权利要求7-11任一项所述的系统，其特征在于，所述系统还包括：

确定单元，用于在所述将所述货物拼车请求消息与预设范围内每一终端对应的当前行程信息进行匹配之前，根据预设范围内每一终端的历史订单信息和/或注册信息确定每一终端对应的当前行程信息。