CN107292692A - 拼车方法和系统 - Google Patents

Abstract

本发明涉及一种拼车方法和系统，该方法包括若接收到终端发送的载客请求，判断是否存在与所述载客请求中的剩余行程信息相匹配的订单，所述订单为根据用户设备发送的打车请求生成的订单；若是，则将相匹配的订单发送至所述终端，并将所述终端的所属车辆信息发送至相匹配订单所对应的用户设备。本发明中，当有部分的乘客下车后，终端发出载客请求，当存在与载客请求相匹配的订单时，就可使该相匹配订单所对应打车请求的发出者与车辆内的剩余乘客共乘该车辆。可见，相对于现有技术中当有部分乘客下车后剩余乘客只能单独完成剩余行程的乘车方式来说，本发明提供的拼车方法可以提高行程中的共乘比例，从而提高拼车率。

Description

拼车方法和系统

技术领域

本发明涉及智能交通技术领域，尤其涉及一种拼车方法和系统。

背景技术

随着能源成本的持续增长，以及城市交通的日益堵塞，需要提高现有车辆的利用效率，利用现存的车辆能承载更多的乘客。现有的公共交通虽然具有载客量大、成本低廉的优点，但是它沿规划路线上停若干站，从而延长了乘客的通勤时间，缺乏便利性。因此，提倡共享出行的拼车服务应运而生，既可以在一定程度上提高现有车辆的利用效率，也可以缩短乘客的通勤时间。

在现有的拼车服务中，为了保证乘客的乘车体验和控制乘客行程所耗时间，仅允许两个乘客共享一个行程，因此只要其中一个乘客行程结束下车后，另一乘客的剩余行程不论有多长都需独自完成，这就造成拼车效率较低，浪费资源。

发明内容

为此，本发明提供一种拼车方法和系统，可以提高行程中的共乘比例，从而提高拼车率。

第一方面，本发明提供的拼车方法包括：

若接收到终端发送的载客请求，所述载客请求为所述终端在所属车辆中的至少一个乘客结束行程后发出的包括所述车辆中剩余乘客的剩余行程信息的请求；

则根据所述载客请求，判断是否存在与所述载客请求中的剩余行程信息相匹配的订单，所述订单为根据用户设备发送的打车请求生成的订单；

若是，则将相匹配的订单发送至所述终端，并将所述终端的所属车辆信息发送至相匹配订单所对应的用户设备。

可选的，将相匹配的订单发送至所述终端之前，所述方法还包括：

向相匹配订单所对应的用户设备发送拼车确认信息；

若接收到所述用户设备根据所述拼车确认信息反馈的同意拼车的响应，则允许执行将相匹配的订单发送至所述终端的步骤。

可选的，所述根据所述载客请求，判断是否存在与所述载客请求中的剩余行程信息相匹配的订单，包括：

根据所述剩余行程信息和根据用户设备发送的打车请求所生成的订单中的行程信息，计算所述剩余乘客与发送该订单的用户设备的所属用户拼车时所述剩余乘客的绕路比例和所述所属用户的绕路比例；

判断所述剩余乘客的绕路比例和所述所属用户的绕路比例是否均小于预设值；

若是，则确定该订单为与所述载客请求中的剩余行程信息相匹配的订单。

可选的，判断是否存在与所述载客请求中的剩余行程信息相匹配的订单之前，所述方法还包括：

判断接收到载客请求的时刻是否处于平峰期内；

若是，则允许执行判断是否存在与所述载客请求中的剩余行程信息相匹配的订单的步骤；

否则，向所述终端发送拒绝所述载客请求的提示信息。

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

若不存在与所述载客请求中的剩余行程信息相匹配的订单，则每经历预设时长后执行：

步骤a：根据所述载客请求中的剩余行程信息和所述终端所属车辆的当前位置坐标，确定所述剩余乘客在当前时刻的剩余行程信息；

步骤b：判断是否存在与所述剩余乘客在当前时刻的剩余行程信息相匹配的订单；

若是，则结束步骤a和步骤b的周期性执行，并将与所述剩余乘客在当前时刻的剩余行程信息相匹配的订单发送至所述终端，将所述终端的所属车辆信息发送至与所述剩余乘客在当前时刻的剩余行程信息相匹配的订单所对应的用户设备。

第二方面，本发明提供的拼车系统包括：

判断模块，用于在接收到终端发送的载客请求时，所述载客请求为所述终端在所属车辆中的至少一个乘客结束行程后发出的包括所述车辆中剩余乘客的剩余行程信息的请求；根据所述载客请求，判断是否存在与所述载客请求中的剩余行程信息相匹配的订单，所述订单为根据用户设备发送的打车请求生成的订单；

发送模块，用于在所述判断模块的判断结果为是时，将相匹配的订单发送至所述终端，并将所述终端的所属车辆信息发送至相匹配订单所对应的用户设备。

可选的，该系统还包括：

确认模块，用于向相匹配订单所对应的用户设备发送拼车确认信息；若接收到所述用户设备根据所述拼车确认信息反馈的同意拼车的响应，则允许所述发送模块执行将相匹配的订单发送至所述终端的步骤。

可选的，所述判断模块包括：

计算单元，用于根据所述剩余行程信息和根据用户设备发送的打车请求所生成的订单中的行程信息，计算所述剩余乘客与发送该订单的用户设备的所属用户拼车时所述剩余乘客的绕路比例和所述所属用户的绕路比例；

判断单元，用于判断所述剩余乘客的绕路比例和所述所属用户的绕路比例是否均小于预设值；

确定单元，用于在所述判断单元的判断结果为是时，确定该订单为与所述载客请求中的剩余行程信息相匹配的订单。

可选的，所述判断模块还用于：

判断接收到载客请求的时刻是否处于平峰期内；

若是，则允许所述判断模块执行判断是否存在与所述载客请求中的剩余行程信息相匹配的订单的步骤；

否则，向所述终端发送拒绝所述载客请求的提示信息。

可选的，所述系统还包括循环模块；

所述循环模块用于在不存在与所述载客请求中的剩余行程信息相匹配的订单时，每经历预设时长后执行：

步骤a：根据所述载客请求中的剩余行程信息和所述终端所属车辆的当前位置坐标，确定所述剩余乘客在当前时刻的剩余行程信息；

步骤b：判断是否存在与所述剩余乘客在当前时刻的剩余行程信息相匹配的订单；

若是，则结束步骤a和步骤b的周期性执行，并将与所述剩余乘客在当前时刻的剩余行程信息相匹配的订单发送至所述终端，将所述终端的所属车辆信息发送至与所述剩余乘客在当前时刻的剩余行程信息相匹配的订单所对应的用户设备。

根据以上技术方案，当有部分的乘客下车后，终端发出载客请求，当存在与载客请求相匹配的订单时，就可使该相匹配订单所对应打车请求的发出者与车辆内的剩余乘客共乘该车辆。可见，相对于现有技术中当有部分乘客下车后剩余乘客只能单独完成剩余行程的乘车方式来说，本发明提供的拼车方法可以提高行程中的共乘比例，从而提高拼车率。

附图说明

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

图1示出了本公开一实施例提供的拼车方法的流程示意图；

图2示出了利用本公开一实施例提供的拼车方法进行拼车的车辆行程图；

图3示出了本公开另一实施例提供的拼车方法的流程示意图；

图4示出了本公开另一实施例提供的拼车方法的流程示意图；

图5示出了本公开一实施例提供拼车系统的结构框图。

具体实施方式

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

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

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

本公开实施例中提及的终端为提供服务方，如交通工具叫车服务中的司机，所使用的用于接单的移动终端或PC端等设备。诸如上述呼叫服务方所使用各设备。本实施例中，为了区别乘客和司机，分别采用用户设备和终端来分别表示乘客和司机所持的移动终端等设备。

如图1所示，本公开一实施例提供一种拼车方法，该拼车方法包括如下步骤：

S100、若接收到终端发送的载客请求，所述载客请求为所述终端在所属车辆中的至少一个乘客结束行程后发出的包括所述车辆中剩余乘客的剩余行程信息的请求；

则根据所述载客请求，判断是否存在与所述载客请求中的剩余行程信息相匹配的订单，所述订单为根据用户设备发送的打车请求生成的订单；

载客请求，例如，当车辆中有两个乘客时，其中一个乘客行程结束下车后，终端发出的一个包含未下车的那个乘客的剩余行程信息的请求。

可理解的是，尽管目前为了保证乘客的乘车体验，控制共享出行的乘客在两个以内。当然，在未下车乘客允许的情况下，共享出行的乘客数量也可以适当的增加，例如控制共享出行的乘客在三个以内。这时，当有一个或两个乘客下车时，终端就可以发出载客请求。

可理解的是，打车请求为有乘车需求的用户发出，生成的订单中应当包括该用户的行程信息。

S200、若存在与所述载客请求中的剩余行程信息相匹配的订单，则将相匹配的订单发送至所述终端，并将所述终端的所属车辆信息发送至相匹配订单所对应的用户设备。

可理解的是，相匹配的订单，是指与载客请求中的剩余行程信息相匹配的订单。

举例来说，如图2所示，乘客A和乘客B共乘一段路程后，乘客B下车，乘客C上车，乘客A与乘客C共乘一段路程后，乘客A下车，而后乘客C下车。可见，整个过程中乘客A分别与乘客B、乘客C共享一段路程，提高了行程中的共乘比例。

本实施例提供的拼车方法中，当有部分的乘客下车后，终端发出载客请求，当存在与载客请求相匹配的订单时，就可使该相匹配订单所对应打车请求的发出者与与车辆内的剩余乘客共乘该车辆。可见，相对于现有技术中当有部分乘客下车后剩余乘客只能单独完成剩余行程的乘车方式来说，本实施例提供的拼车方法可以提高行程中的共乘比例，从而提高拼车率。

本实施例中，当S100中的判断结果为不存在与所述载客请求中的剩余行程信息相匹配的订单，此时无法进行拼车，因此本实施例提供的拼车方法还可包括：

若不存在与所述载客请求中的剩余行程信息相匹配的订单，则每经历预设时长后执行：

步骤a：根据所述载客请求中的剩余行程信息和所述终端所属车辆的当前位置坐标，确定所述剩余乘客在当前时刻的剩余行程信息；

步骤b：判断是否存在与所述剩余乘客在当前时刻的剩余行程信息相匹配的订单；

若是，则结束步骤a和步骤b的周期性执行，并将与所述剩余乘客在当前时刻的剩余行程信息相匹配的订单发送至所述终端，将所述终端的所属车辆信息发送至与所述剩余乘客在当前时刻的剩余行程信息相匹配的订单所对应的用户设备。

可理解的是，若在接收到载客请求时，经判断没有与载客请求中的剩余行程信息相匹配的订单，而由于车辆一直在行驶中，因此剩余乘客的剩余行程是一直发生变化的，因此再次进行匹配判断时需要重新计算剩余乘客的剩余行程，确定剩余行程信息。举例来说，在接收到载客请求时，剩余行程信息为从A地到C地的10公里，而经历一个预设时长后，重新确定的剩余行程信息为从B地到C地的9.55公里。

可以理解的是，预设时长可以根据实际需求设定，例如1秒。

可理解的是，上述判断过程中若一直不存在相匹配的订单，则在剩余乘客结束行程前的一段时间内便不再执行循环过程。

本实施例中S100的具体判断过程可以有多种不同的实现方法，这里不做限定，其中一种实现方法可包括图中未示出的：

S101、根据所述终端的所属车辆中剩余乘客的剩余行程信息和在所述预设时间段内接收到的每一订单信息中的行程信息，计算所述剩余乘客与发送该订单信息的用户共乘时所述剩余乘客的绕路比例和发送该订单信息的用户的绕路比例；

S102、判断所述剩余乘客的绕路比例和所述所属用户的绕路比例是否均小于预设值；

S103、在判断结果为是时，确定该订单为与所述载客请求中的剩余行程信息相匹配的订单。

其中，预设值可以根据需要进行设定，例如1.2。

例如，车辆内的剩余乘客在不继续拼车的情况下，剩余行程为100公里。若继续拼车的话，可能需要一定的绕路接送拼车用户，假如与其他人拼车后需要走110公里才能到达目的地，则该剩余乘客的绕路比例为1.1，在此过程中，拼车用户的原本行程为50公里，若与该剩余乘客共乘的情况下，需要走60公里才能达到目的地，这样的话该拼车用户的绕路比例为1.2。

这里通过判断绕路比例的方式判断匹配度，简单、方便，同时可以保证乘客的用户体验。

如图3所示，本公开另一实施例提供一种拼车方法，本实施例提供的拼车方法中的S100’、S400’与上述实施例中的S100、S200相同，本实施例提供的拼车方法中除了S100’、S400’外还包括：

S200’、向相匹配订单所对应的用户设备发送拼车确认信息；

S300’、判断是否接收到所述用户设备根据所述拼车确认信息反馈的同意拼车的响应，若是，则允许执行S400’。

可以理解的是，若反馈信息为不同意拼车，则向终端发送拼车失败的提示信息。

本实施例中在生成拼车信息之前确认发送相匹配订单信息的用户是否同意拼车，只有在该用户同意拼车的前提下才会发出拼车信息。本实施例中考虑到部分用户可能不愿意与其他人拼车，通过确认的方式保证这部分用户的乘车体验。

如图4所示，本公开另一实施例提供一种拼车方法，本实施例提供的拼车方法中的S200”、S300”与上述实施例中的S100、S200相同，本实施例提供的拼车方法中除了S200”、S300”外还包括：

S100”、判断接收到载客请求的时刻是否处于平峰期内。

若是，则允许执行S200”；

否则，执行S400”：向所述终端发送拒绝所述载客请求的提示信息。

可见，只有在平峰期时才允许连续拼车，在高峰期是不允许进行连续拼车的，由于在高峰期道路比较拥挤，若连续拼车的话，可能会影响乘客的乘客体验。所谓的连续拼车，在限定车辆中的乘客数量最多为两人时，对于某个乘客来说，在完成行程的过程中至少与两个人共乘。

如图5所示，本公开另一实施例提供一种拼车系统500，该系统500包括：

判断模块501，用于在接收到终端发送的载客请求时，所述载客请求为所述终端在所属车辆中的至少一个乘客结束行程后发出的包括所述车辆中剩余乘客的剩余行程信息的请求；根据所述载客请求，判断是否存在与所述载客请求中的剩余行程信息相匹配的订单，所述订单为根据用户设备发送的打车请求生成的订单；

发送模块502，用于在所述判断模块的判断结果为是时，将相匹配的订单发送至所述终端，并将所述终端的所属车辆信息发送至相匹配订单所对应的用户设备。

本实施例中，该系统还可包括图中未示出的：

确认模块，用于向相匹配订单所对应的用户设备发送拼车确认信息；若接收到所述用户设备根据所述拼车确认信息反馈的同意拼车的响应，则允许所述发送模块执行将相匹配的订单发送至所述终端的步骤。

本实施例中，所述判断模块501包括图中未示出的：

计算单元，用于根据所述剩余行程信息和根据用户设备发送的打车请求所生成的订单中的行程信息，计算所述剩余乘客与发送该订单的用户设备的所属用户拼车时所述剩余乘客的绕路比例和所述所属用户的绕路比例；

判断单元，用于判断所述剩余乘客的绕路比例和所述所属用户的绕路比例是否均小于预设值；

确定单元，用于在所述判断单元的判断结果为是时，确定该订单为与所述载客请求中的剩余行程信息相匹配的订单。

本实施例中，所述判断模块501还用于：

判断接收到载客请求的时刻是否处于平峰期内；

若是，则允许所述判断模块执行判断是否存在与所述载客请求中的剩余行程信息相匹配的订单的步骤；

否则，向所述终端发送拒绝所述载客请求的提示信息。

本实施例中，该系统还包括图中未示出的循环模块；

所述循环模块用于在不存在与所述载客请求中的剩余行程信息相匹配的订单时，每经历预设时长后执行：

步骤a：根据所述载客请求中的剩余行程信息和所述终端所属车辆的当前位置坐标，确定所述剩余乘客在当前时刻的剩余行程信息；

步骤b：判断是否存在与所述剩余乘客在当前时刻的剩余行程信息相匹配的订单；

若是，则结束步骤a和步骤b的周期性执行，并将与所述剩余乘客在当前时刻的剩余行程信息相匹配的订单发送至所述终端，将所述终端的所属车辆信息发送至与所述剩余乘客在当前时刻的剩余行程信息相匹配的订单所对应的用户设备。

本领域普通技术人员可以理解：实现上述方法实施例的全部或者部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储在计算机可读取的存储介质中，该程序在执行时，执行包括上述方法实施例的步骤。

本发明的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

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

Claims (10)

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

若接收到终端发送的载客请求，所述载客请求为所述终端在所属车辆中的至少一个乘客结束行程后发出的包括所述车辆中剩余乘客的剩余行程信息的请求；

则根据所述载客请求，判断是否存在与所述载客请求中的剩余行程信息相匹配的订单，所述订单为根据用户设备发送的打车请求生成的订单；

若是，则将相匹配的订单发送至所述终端，并将所述终端的所属车辆信息发送至相匹配订单所对应的用户设备。

2.根据权利要求1所述的方法，其特征在于，所述将相匹配的订单发送至所述终端之前，所述方法还包括：

向相匹配订单所对应的用户设备发送拼车确认信息；

若接收到所述用户设备根据所述拼车确认信息反馈的同意拼车的响应，则允许执行将相匹配的订单发送至所述终端的步骤。

3.根据权利要求1所述的方法，其特征在于，所述根据所述载客请求，判断是否存在与所述载客请求中的剩余行程信息相匹配的订单，包括：

根据所述剩余行程信息和根据用户设备发送的打车请求所生成的订单中的行程信息，计算所述剩余乘客与发送该订单的用户设备的所属用户拼车时所述剩余乘客的绕路比例和所述所属用户的绕路比例；

判断所述剩余乘客的绕路比例和所述所属用户的绕路比例是否均小于预设值；

若是，则确定该订单为与所述载客请求中的剩余行程信息相匹配的订单。

4.根据权利要求1所述的方法，其特征在于，判断是否存在与所述载客请求中的剩余行程信息相匹配的订单之前，所述方法还包括：

判断接收到载客请求的时刻是否处于平峰期内；

若是，则允许执行判断是否存在与所述载客请求中的剩余行程信息相匹配的订单的步骤；

否则，向所述终端发送拒绝所述载客请求的提示信息。

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

若不存在与所述载客请求中的剩余行程信息相匹配的订单，则每经历预设时长后执行：

步骤a：根据所述载客请求中的剩余行程信息和所述终端所属车辆的当前位置坐标，确定所述剩余乘客在当前时刻的剩余行程信息；

步骤b：判断是否存在与所述剩余乘客在当前时刻的剩余行程信息相匹配的订单；

若是，则结束步骤a和步骤b的周期性执行，并将与所述剩余乘客在当前时刻的剩余行程信息相匹配的订单发送至所述终端，将所述终端的所属车辆信息发送至与所述剩余乘客在当前时刻的剩余行程信息相匹配的订单所对应的用户设备。

6.一种拼车系统，其特征在于，包括：

判断模块，用于在接收到终端发送的载客请求时，所述载客请求为所述终端在所属车辆中的至少一个乘客结束行程后发出的包括所述车辆中剩余乘客的剩余行程信息的请求；根据所述载客请求，判断是否存在与所述载客请求中的剩余行程信息相匹配的订单，所述订单为根据用户设备发送的打车请求生成的订单；

发送模块，用于在所述判断模块的判断结果为是时，将相匹配的订单发送至所述终端，并将所述终端的所属车辆信息发送至相匹配订单所对应的用户设备。

7.根据权利要求6所述的系统，其特征在于，还包括：

确认模块，用于向相匹配订单所对应的用户设备发送拼车确认信息；若接收到所述用户设备根据所述拼车确认信息反馈的同意拼车的响应，则允许所述发送模块执行将相匹配的订单发送至所述终端的步骤。

8.根据权利要求6所述的系统，其特征在于，所述判断模块包括：

计算单元，用于根据所述剩余行程信息和根据用户设备发送的打车请求所生成的订单中的行程信息，计算所述剩余乘客与发送该订单的用户设备的所属用户拼车时所述剩余乘客的绕路比例和所述所属用户的绕路比例；

判断单元，用于判断所述剩余乘客的绕路比例和所述所属用户的绕路比例是否均小于预设值；

确定单元，用于在所述判断单元的判断结果为是时，确定该订单为与所述载客请求中的剩余行程信息相匹配的订单。

9.根据权利要求6所述的系统，其特征在于，所述判断模块还用于：

判断接收到载客请求的时刻是否处于平峰期内；

若是，则允许所述判断模块执行判断是否存在与所述载客请求中的剩余行程信息相匹配的订单的步骤；

否则，向所述终端发送拒绝所述载客请求的提示信息。

10.根据权利要求6所述的系统，其特征在于，还包括循环模块；

所述循环模块用于在不存在与所述载客请求中的剩余行程信息相匹配的订单时，每经历预设时长后执行：

步骤a：根据所述载客请求中的剩余行程信息和所述终端所属车辆的当前位置坐标，确定所述剩余乘客在当前时刻的剩余行程信息；

步骤b：判断是否存在与所述剩余乘客在当前时刻的剩余行程信息相匹配的订单；

若是，则结束步骤a和步骤b的周期性执行，并将与所述剩余乘客在当前时刻的剩余行程信息相匹配的订单发送至所述终端，将所述终端的所属车辆信息发送至与所述剩余乘客在当前时刻的剩余行程信息相匹配的订单所对应的用户设备。