CN110365769A - 一种乘客客户端、服务器及方法、司机客户端及系统 - Google Patents

Abstract

本发明公开一种网约车乘客客户端，包括：目标点信息输入模块，用于输入乘客的目标点信息；拼车模块，用于响应于乘客动作而确认乘客同意拼车；乘车信息输入模块，用于输入乘客乘车信息；送客服务模块和接客服务模块，用于响应于乘客选择而对所述乘客进行服务分类；信息显示模块，用于以群组形式呈现服务器发送的服务信息，其中所述群组包含所述服务器根据所述目标点信息和乘车信息而分配到同一辆网约车的乘客和司机列表，所述服务信息至少包含所述同一辆网约车的车牌号和预定行车路线。本发明能够提高总体经济效应，并且可降低相应的费用。

Description

一种乘客客户端、服务器及方法、司机客户端及系统

技术领域

本发明涉及网络约车技术领域，特别是涉及一种乘客客户端、服务器及方法、司机客户端及系统。

背景技术

现有的网络约车方法，在实现接送客服务时，一般是以预约形式来进行，实现一车对一客的接送服务，一般会要求用户首先选择接客服务/送客服务，然后输入相应的航班号或车次号，选择相应的行程日期，确认后系统会弹出该航班或车次号的具体信息，这样的接送客服务，存在较大的不合理性，首先一对一服务虽然可以满足较高收入人群使用专车接送客的准点性与舒适性，但是并不能满足出行服务的经济性和环保性。

发明内容

为解决背景技术中所提出的技术问题，本发明第一方面提出一种网约车乘客客户端，包括：

目标点信息输入模块，用于输入乘客乘坐的目标点信息；

拼车模块，用于响应于乘客动作而确认乘客同意拼车；

乘车信息输入模块，用于输入乘客乘车信息；

送客服务模块和接客服务模块，用于响应于乘客选择而对所述乘客进行服务分类；

信息显示模块，用于以群组形式呈现服务器发送的服务信息，其中所述群组包含所述服务器根据所述目标点信息和乘车信息而分配到同一辆网约车的乘客和司机列表，所述服务信息至少包含所述同一辆网约车的车牌号和预定行车路线。

可选的，还包括：

乘客信息显示模块，用于响应于乘客对所述乘客和司机列表中乘客或司机的选择，在地图上呈现所述被选择乘客或司机的当前位置。

可选的，在所述服务分类为接客服务的情况下，所述网约车乘客客户端还包括：

上车点确认模块，用于呈现被分配到同一辆网约车的所有乘客的标识，其中以第一颜色显示未到达上车点的乘客标识，以第二颜色显示到达上车点的乘客标识，并且响应于对未到达乘客发送的确认到达消息的验证，而使得该乘客标识从第一颜色变为第二颜色。

可选的，所述乘车信息包括人数、乘客电话、行李数和网约车规格。

可选的，在所述服务分类为送客服务的情况下，所述乘车信息还包括起点和期望接驾时间，所述服务信息还包括乘客的建议上车点和建议上车时间；

和/或

在所述服务分类为接客服务的情况下，所述乘车信息还包括终点，所述服务信息还包括乘客的建议上车点和建议上车时间。

可选的，在所述服务分类为送客服务的情况下，若服务器判断乘客超过所述建议上车时间预定时长后，所述信息显示模块向所述乘客发送另行约车通知。

可选的，还包括：

继续等待模块，响应于已上车乘客的选择而继续等待未上车乘客并启动对所述未上车乘客计等待费，所述选择基于在所述服务分类为接客服务的情况下服务器判断乘客超过所述建议上车时间预定时长后发送的询问信息。

可选的，所述建议上车点和建议上车时间能够被所述群组中的乘客修改。

本发明第二方面提出一种服务器，包括：

目标点信息接收模块，用于接收来自网约车乘客客户端的乘客的目标点信息；

拼车信息接收模块，用于接收来自网约车乘客客户端的乘客同意拼车指令；

乘车信息接收模块，用于接收来自网约车乘客客户端的乘客乘车信息；

服务分类接收模块，用于接收来自网约车乘客客户端的乘客选择的服务分类；

处理模块，用于根据所述目标点信息和乘车信息将乘客加入同车分组并向网约车司机客户端派单；

信息发送模块，用于响应于来自网约车司机客户端的接单信息将被分配到同一辆网约车的乘客与该接单司机在各自客户端上以群组形式呈现，并且向所述群组发送服务信息，其中所述服务信息至少包含所述同一辆网约车的车牌号和预定行车路线。

可选的，当服务分类为送客服务时，所述处理模块被配置为：

根据乘客的起点及期望接驾时间，将乘客分成同车分组，并生成所述预定行车路线，以距离目标点最远的乘客上车点为行程起点，其余同车分组乘客的上车点逐渐靠近目标点，目标点为终点。

本发明第三方面提出一种根据所述的服务器进行网约车的方法，包括以下步骤：

目标点信息接收模块用于接收来自网约车客户端的乘客的目标点信息；

拼车信息接收模块接收来自网约车客户端的乘客同意拼车指令；

乘车信息接收模块接收来自网约车客户端的乘客乘车信息；

服务分类接收模块接收来自网约车客户端的乘客选择的服务分类；

处理模块用于根据所述目标点信息信息和乘车信息将乘客加入同车分组并向网约车司机端派单；

信息发送模块响应于来自网约车司机端的接单信息将被分配到同一辆网约车的乘客与该接单司机在各自客户端上以群组形式呈现，并且向所述群组发送服务信息，其中所述服务信息至少包含所述同一辆网约车的车牌号和预定行车路线。

可选的，当服务分类为送客服务时，所述方法包括：

根据乘客的起点及期望接驾时间，将乘客分成同车分组，并生成所述预定行车路线，以距离目标点最远的乘客上车点为行程起点，其余同车分组乘客的上车点逐渐靠近目标点，目标点为终点。

可选的，所述根据乘客的起点及期望接驾时间将乘客分成同车分组包括：

S1、建立一个同意拼车乘客的起点到达机场或车站的行车路线，得出按此行车路线到达目标点的预计时间，根据乘客需要到达目标点的到达时间，判断该乘客的期望接驾时间是否合理，如果在出发时间的预定时长以内才能到达目标点，则提醒该乘客将接驾时间提前至合理范围；

S2、判断其他同意拼车乘客的起点是否在所述行车路线附近；

S3、如果是，获取从所述其他同意拼车乘客的起点到达所述行车路线的预计时间，判断所述预计时间是否在所述其他同意拼车乘客的期望接驾时间范围内，若在此范围内，则将满足条件的乘客进行同车分组；

S4、若否，则将不在所述行车路线附近的其他同意拼车乘客的起点作为行程起点来建立其他同意拼车乘客的行车路线并重复S1和S2，以此来确定满足条件的乘客；

S5、将满足条件的乘客进行同车分组。

本发明第四方面提出一种网约车司机客户端，与所述的乘客客户端和所述的服务器配合，包括

订单确认模块，用于确认所述服务器发送的派单任务；

乘客信息呈现模块，用于呈现乘客行车路线及上车时间、地点提示；

免费无限等待模块，用于供司机根据目标点的延误信息确定是否继续等待；

改派模块，用于响应于司机不再等待而向服务器发送改派请求。

本发明第五方面提出一种网约车系统，包括

所述的网约车乘客客户端；

所述的服务器；和

所述的司机客户端。

本发明的有益效果如下：

本实施例提出的网约车乘客客户端具有原理明确、设计简单的优点，乘客在进行网约车时，通过拼车模块来响应于乘客动作而确认乘客同意进行拼车，将同意拼车的乘客根据乘车信息以及目标点信息来进行分组，将多个接受拼车的乘客分为一组，并相应的搭乘同一辆网约车来进行接客/送客服务，提高了总体经济效应，并且可降低了相应的费用。

附图说明

下面结合附图对本发明的具体实施方式作进一步详细的说明。

图1示出本发明的一个实施例提出的一种网约车系统的场景架构示意图；

图2示出本发明的另一个实施例提出的一种网约车乘客客户端的结构框图；

图3示出本发明的另一个实施例提出的一种服务器的结构框图；

图4为本发明的另一个实施例提出的一种根据上述的服务器来进行网约车的方法的流程图；

图5示出本发明的另一个实施例提出的一种网约车司机客户端的结构框图；

图6为网约车乘客客户端、服务器与网约车司机客户端之间的流程结构图；

图7示出使用该网约车系统的操作流程图；

图8示出网约车乘客客户端的“集合确认”界面；

图9示出服务器会根据乘客所发送的乘客信息来确定行车路线的示意图。

具体实施方式

为了更清楚地说明本发明，下面结合优选实施例和附图对本发明做进一步的说明。附图中相似的部件以相同的附图标记进行表示。本领域技术人员应当理解，下面所具体描述的内容是说明性的而非限制性的，不应以此限制本发明的保护范围。

为解决背景技术中所提出的问题，图1示出本发明的一个实施例提出的一种网约车系统的场景架构示意图，如图1所示，所述网约车系统包括：网约车乘客客户端、服务器以及网约车司机客户端，其中，网约车乘客客户端、网约车司机客户端以及服务器分别通过通讯网络进行通讯连接。

需要说明的是，在本实施例中，网约车乘客客户端以及网约车司机客户端可以APP的形式安装于移动终端内，并且本实施例中的网约车系统可应用在火车、飞机、码头、客运站等交通工具方面的接车或送车服务中，本实施例对此不作具体限定。

图2示出本发明的另一个实施例提出的一种网约车乘客客户端的结构框图，如图2所示，在本实施例中，网约车乘客客户端主要包括：目标点信息输入模块、拼车模块、乘车信息输入模块、送客服务模块和接客服务模块以及信息显示模块，其中，目标点信息输入模块主要用于输入乘客的目标点信息；拼车模块主要用于相应于乘客动作而确定乘客同意拼车；乘客信息输入模块主要用于输入乘客乘车信息；送客服务模块和接客服务模块主要用于响应于乘客选择而对所述乘客进行服务分类；信息显示模块主要用于以群组形式呈现服务器发送的服务信息，其中所述群组包含所述服务器根据所述目标点信息和乘车信息而分配到同一辆网约车的乘客和司机列表，所述服务信息至少包含所述同一辆网约车的车牌号和预定行车路线。

也就是说，乘客在使用本实施例中的网约车乘客客户端进行乘车时，首先会通过目标点信息输入模块来输入乘客的目标点信息(目标点信息可包括：航班、列车、客车或轮船的车次、到达时间以及其他相关的信息)，然后通过拼车模块来选择是否同意拼车，当乘客不同意拼车的话，服务器则会按照如背景技术中的示例所示的常规接送车服务模式进行网络约车。

当乘客选择同意拼车后，乘客通过乘车信息输入模块输入乘客乘车信息(乘车信息包括人数、乘客电话、行李数和网约车规格)，然后乘客通过送客服务模块和接客服务模块来选择接客或送客服务，送客服务模块和接客服务模块相应的响应于乘客的选择来对乘客进行服务分类，当乘客需要接客服务时，乘客通过送客服务模块和接客服务模块来选择接客服务选项，同理，当乘客需要送客服务时，乘客也可通过网约车乘客客户端选择相应的送客服务选项。

然后，服务器会根据目标点信息以及乘车信息来将乘客加入至同车分组内，根据乘车人数、行李数确定网约车车型，并向符合该网约车车型的网约车司机进行派单，而网约车司机则通过网约车客户端进行接单，在这里，网约车司机可通过抢单或者服务器下派的方式来进行接单，接单后，服务器会将至少包含有同一辆网约车的车牌号以及预定行车路线发送至网约车乘客客户端，网约车乘客客户端中的信息显示模块则以群组形式来呈现服务器所发送的至少包含所述同一辆网约车的车牌号和预定行车路线的服务信息，其中，群组主要为服务器根据所述目标点信息和乘车信息而分配到同一辆网约车的乘客和司机列表，需要说明的是，加入同一群组内的所有乘客以及司机也可拨通彼此电话，方便沟通，在这里，电话可以是由中转号码服务提起的“隐号”服务。

优选地，在本实施例的一个具体实施方式中，服务器可将选择接客服务的乘客分为同一聊天列表内，而将选择送客服务的乘客分为另一个聊天列表内，方便选择同一服务的乘客在聊天列表内进行交谈与相识，加深彼此之间的沟通。

进一步的，在本实施例中，所述网约车乘客客户端还包括：

乘客信息显示模块，用于响应于乘客对所述乘客和司机列表中乘客或司机的选择，在地图上呈现所述被选择乘客或司机的当前位置。

具体的，由于网约车乘客客户端以及网约车司机客户端可通过APP的形式安装在移动终端中，而移动终端往往是手机，现有的手机通常安装有GPS定位模块，当群组中的一个乘客使用网约车乘客客户端进行接客或送客服务时，GPS定位模块可获取移动终端的实时位置，而乘客信息显示模块则可将此实时位置进行显示，并且服务器可将此实时位置发送至处于同一个群组中的其他乘客的网约车乘客客户端以及司机的网约车司机客户端，这样，乘客便可通过上述的乘客信息显示模块来显示位于同一群组中的乘客和司机列表中的乘客的当前位置，从而使得乘客能够实时了解到同一群组内的其他乘客以及司机的具体位置。

进一步的，在本实施例中，在所述服务分类为接客服务的情况下，所述网约车乘客客户端还包括：

上车点确认模块，用于呈现被分配到同一辆网约车的所有乘客的标识，其中以第一颜色显示未到达上车点的乘客标识，以第二颜色显示到达上车点的乘客标识，并且响应于对未到达乘客发送的确认到达消息的验证，而使得该乘客标识从第一颜色变为第二颜色。

具体的，通过上车点确认模块能够在网约车乘客客户端中呈现被分配到同一辆网约车的所有乘客的标识，并可通过以两种不同的颜色来作为乘客是否到达上车点的乘客标识，其中，以第一颜色显示未到达上车点的乘客标识，以第二颜色来显示到达上车点的乘客标识，当乘客到达上车点后可发送确认到达消息，网约车乘客客户端基于此确认到达消息来确定移动终端所生成的实时位置是否与上车点一致，从而实现对确认到达消息是否正确，当验证成功后，上车点确认模块来使得该乘客的乘客标识由第一颜色转变为第二颜色，示例性的，第一颜色可为红色，第二颜色可为绿色。

进一步的，在所述服务分类为送客服务的情况下，所述乘车信息还包括起点和期望接驾时间，所述服务信息还包括乘客的建议上车点和建议上车时间；和/或

在所述服务分类为接客服务的情况下，所述乘车信息还包括终点，所述服务信息还包括乘客的建议上车点和建议上车时间。

具体的，当乘客通过网约车乘客客户端选择送客服务时，乘客需要将起点和期望接驾时间通过乘车信息输入模块来进行输入，服务器基于目标点信息信息和乘车信息生成的服务信息还包括有：乘客的建议上车点以及建议上车时间；当乘客通过网约车乘客客户端选择接客服务时，乘客需要将终点通过乘车信息输入模块来进行输入，而服务器基于目标点信息和乘车信息生成的服务信息还包括有：乘客的建议上车点以及建议上车时间。

进一步的，在本实施例中，在所述服务分类为送客服务的情况下，若服务器判断乘客超过所述建议上车时间预定时长后，所述信息显示模块向所述乘客发送另行约车通知。

具体的，在送客服务下，服务器根据目标点信息和乘车信息生成包含有乘客的建议上车点以及建议上车时间的服务信息，当处于同一群组中的一个未上车乘客超过建议上车时间预定时长后仍没有上车时，服务器会发送另行约车通知至迟到的乘客的网约车乘客客户端，也就能够通知此迟到的乘客需要另行进行约车，避免让其他乘客长时间进行等待而耽误送客，在这里，预定时长可自行进行设定，其具体数值本实施例不做具体限定，示例性的，预定时间可为15分钟。

进一步的，在本实施例中，所述网约车乘客客户端还包括有继续等待模块，响应于已上车乘客的选择而继续等待未上车乘客并启动对所述未上车乘客计等待费，所述选择基于在所述服务分类为接客服务的情况下服务器判断乘客超过所述建议上车时间预定时长后发送的询问信息。

具体的，在接客服务下时，当同一群组中的一个未上车乘客迟到的时间超过建议上车预设时长后，服务器会发送询问信息给其他已上车的乘客的网约车乘客客户端，其他已上车的乘客基于此询问信息来选择是否继续等待迟到的未上车乘客，当选择继续等待时，继续等待模块会对未上车的乘客进行计等待费，在这里，等待费可分摊给司机以及其他已上车乘客，并且同时，服务器也可规定乘客在进行接客或送客服务前需要交付车费50％的定金，以防乘客爽约、迟到等情况的出现，当未上车的乘客迟到的时间超过预定时长后，其他已上车的乘客若不同意继续等待，则未上车乘客所交付的定金不予进行退回。

进一步的，在本实施例中，所述建议上车点和建议上车时间能够被所述群组中的乘客修改。

具体的，群组中的乘客可通过彼此之间的沟通来对服务器所生成的建议上车点以及建议上车时间进行修改。

本实施例提出的网约车乘客客户端具有原理明确、设计简单的优点，乘客在进行网约车时，通过拼车模块来响应于乘客动作而确认乘客同意进行拼车，将同意拼车的乘客根据乘车信息以及目标点信息来进行分组，将多个接受拼车的乘客分为一组，并相应的搭乘同一辆网约车来进行接客/送客服务，提高了总体经济效应，并且可降低了相应的费用。

图3示出本发明的另一个实施例提出的一种服务器的结构框图，如图3所示，所述服务器包括：目标点信息接收模块、拼车信息接收模块、乘车信息接收模块、服务分类接收模块、处理模块以及信息发送模块。

具体的，在本实施例中，目标点信息接收模块主要用于接收来自网约车乘客客户端的乘客的目标点信息；拼车信息接收模块主要用于接收来自网约车乘客客户端所发送的同意拼车指令；乘车信息接收模块主要用于接收来自网约车乘客客户端的乘客乘车信息；服务分类接收模块主要用于接收来自网约车乘客客户端的乘客选择的服务分类；处理模块主要用于根据目标点信息以及乘车信息来将乘客加入同车分组内并将网约车司机客户端进行派单；信息发送模块主要用于响应于来自网约车司机客户端的接单信息将被分配到同一辆网约车的乘客与该接单司机在各自客户端上以群组形式呈现，并且想所述群组发送服务信息，其中，所述服务信息至少包含同一辆网约车的车牌号和预定行车路线。

下面结合上述的网约车乘客客户端来对本实施例中提出的服务器来进行进一步的介绍，网约车乘客客户端可向发送乘客所输入的目标点信息，并且服务器会基于此向网约车乘客客户端发送是否拼车的询问信息，乘客相应的通过网约车乘客客户端向服务器发送同意拼车指令，服务器接收到同意拼车指令后接收来自于网约车乘客客户端的乘客乘车信息以及服务分类，优选的，为了能够增加乘客间的沟通与交流，服务器可将选择同种服务的乘客分为同一聊天列表中，这样位于同一聊天列表中的乘客来提前进行沟通以及交流，加深彼此之间的了解，接着，服务器会根据乘客所发送的目标点信息以及乘车信息将乘客加入到同车分组中并向网约车客户端进行派单，随后服务器响应于网约车客户端的接单信息，将分配在同一网约车的乘客与接单司机在各自的客户端上以群组形式来进行呈现，并将包含有同一辆网约车的车牌号以及预定行车路线的服务信息发送给群组，来让群组内的乘客以及司机接收到相应的服务信息，从而进一步的进行接客或送客服务。

进一步的，在本实施例中，当服务分类为送客服务时，所述处理模块被配置为：

根据乘客的起点及期望接驾时间，将乘客分成同车分组，并生成所述预定行车路线，以距离目标点最远的乘客上车点为行程起点，其余同车分组乘客的上车点逐渐靠近目标点，目标点为终点。

具体的，由上述实施例可知，当乘客选择送客服务时，乘客所输入的乘车信息还包括起点以及期望接驾时间，而服务器会根据乘客输入的起点以及期望接驾时间来将多个乘客分为同车分组，并根据多个乘客的起点来生成预定行车路线，在这里，预定行车路线的生成会以距离目标点最远的乘客的上车点来作为行程终点，同车分组内的其他乘客的上车点逐渐靠近目标点，然后以目标点来作为预定行车路线的终点。

图4为本发明的另一个实施例提出的一种根据上述的服务器来进行网约车的方法的流程图，如图4所示，所述方法包括以下步骤：

目标点信息接收模块用于接收来自网约车客户端的乘客乘坐的目标点信息；

拼车信息接收模块接收来自网约车客户端的乘客同意拼车指令；

乘车信息接收模块接收来自网约车客户端的乘客乘车信息；

服务分类接收模块接收来自网约车客户端的乘客选择的服务分类；

处理模块用于根据所述目标点信息和乘车信息将乘客加入同车分组并向网约车司机端派单；

信息发送模块响应于来自网约车司机端的接单信息将被分配到同一辆网约车的乘客与该接单司机在各自客户端上以群组形式呈现，并且向所述群组发送服务信息，其中所述服务信息至少包含所述同一辆网约车的车牌号和预定行车路线。

进一步的，在本实施例中，当服务分类为送客服务时，所述方法还包括：

根据乘客的起点及期望接驾时间，将乘客分成同车分组，并生成所述预定行车路线，以距离机场或火车站最远的乘客上车点为行程起点，其余同车分组乘客的上车点逐渐靠近机场或火车站，机场或火车站为终点。

乘客选择送客服务时，服务器会根据乘客的起点及期望接驾时间来将乘客分为同车分组，其具体步骤如下：

S1、建立一个同意拼车乘客的起点到达机场或车站的行车路线，得出按此行车路线到达目标点的预计时间，根据乘客需要到达目标点的到达时间，判断该乘客的期望接驾时间是否合理，如果在出发时间的预定时长以内才能到达目标点，则提醒该乘客将接驾时间提前至合理范围；

S2、判断其他同意拼车乘客的起点是否在所述行车路线附近；

S3、如果是，获取从所述其他同意拼车乘客的起点到达所述行车路线的预计时间，判断所述预计时间是否在所述其他同意拼车乘客的期望接驾时间范围内，若在此范围内，则将满足条件的乘客进行同车分组；

S4、若否，则将不在所述行车路线附近的其他同意拼车乘客的起点作为行程起点来建立其他同意拼车乘客的行车路线并重复S1和S2，以此来确定满足条件的乘客；

S5、将满足条件的乘客进行同车分组。

具体的，由于每一个同意拼车乘客的起点不同，因此为了能够避免司机在送客的过程中绕太多的原路，因此，需要对同意拼车乘客进行同车分组，同车分组的方法如下述所示：首先，服务器会获取一个同意拼车乘客的起点到达目标点的行车路线，计算从该起点到达目标点的时间是否在这一个同意拼车乘客的期望接驾时间内，如果在，则表面该乘客的期望接驾时间为合理的，如果不在，则表明，司机在该乘客的期望接驾时间进行接驾后，可能会发生晚点的现象，因此需要提醒该乘客对期望接驾时间进行修改，然后服务器会判断其他同意拼车乘客的起点是否在该乘客的行车路线附近，若在附近的话，则表明司机按照该行车路线进行依次接驾时，不会绕过多的路，因此，可以将满足这一条件的其他同意拼车乘客来分为同车分组，而当其他同意拼车乘客的起点不在该乘客的行车路线附近的话，则表明司机按照该行车路线进行依次接驾时，可能会绕过多的路，从而造成时间的浪费，因此，可以将不满足这一条件的其他同意拼车乘客再另行进行分组。

在本实施例中，判断其他同意拼车乘客的起点是否在该乘客的行车路线附近可由下述的方法来实现：判断其他同意拼车乘客的起点到达该乘客的行车路线之间的最短距离是否在预设距离内，若在，则表明，其他同意拼车乘客的起点在该乘客的行车路线的附近，若不在，则表明，其他同意拼车乘客的起点不在该乘客的行车路线的附件，在这里，预设距离可自行进行设定，本实施例对此不做具体限定，示例性的，预设距离可为2KM。

优选地，为了避免乘客在起点等待网约车接驾的时间过长，因此，在对乘客进行同车分组时，可以初步判断从以其中一个同意拼车乘客的起点来制定的行车路线到达其他同意拼车乘客的起点所需要的时间是否超过其他同意拼车乘客的期望接驾时间，若时间超过，则将此其他同意拼车乘客来进行重新同车分组，从而能够节省其他同意拼车乘客的等待时间，并且在进行同车分组前，同意拼车的乘客也可根据自身需求来设定等待时长，若网约车接驾的时间与其期望接驾时间之间的差值小于等待时长时，可不用对该乘客重新进行同车分组，而若网约车接驾的时间与其期望接驾时间之间的差值大于等待时长时，则对该乘客重新进行同车分组。

进一步的，当乘客选择接客服务时，服务器可根据乘客所发送的包含终点的乘车信息来对乘客进行同车分组，其具体分组方法如下：首先以一个同意拼车乘客的终点作为行车路线的终点，从而依次判断其他同意拼车乘客的终点是否在该行车路线的附近，若在附近的话，则表明司机按照该行车路线进行依次接客服务时，不会绕过多的路，因此，可以将满足这一条件的其他同意拼车乘客来分为同车分组，而当其他同意拼车乘客的起点不在该乘客的行车路线附近的话，则表明司机按照该行车路线进行依次接客服务时，可能会绕过多的路，从而造成时间的浪费，因此，可以将不满足这一条件的其他同意拼车乘客再另行进行分组。

需要说明的，在接客服务中，判断其他同意拼车乘客的起点是否在该乘客的行车路线附近的具体方法可依据在送客服务中所使用的方法，因此，本实施例不再进行赘述。

图5示出本发明的另一个实施例提出的一种网约车司机客户端的结构框图，本实施例中的网约车司机客户端主要用于与上述的网约车乘客客户端以及服务器进行配合，如图5所示，所述网约车司机客户端主要包括：订单确认模块、乘客信息呈现模块、免费无限等待模块以及改派模块。

在图5的示例中，订单确定模块主要用于确认服务器所发送的派单任务：乘客信息呈现模块主要用于呈现乘客行车路线及上车时间、地点提示；免费无限等待模块主要用于供司机根据目标点的延误信息确定是否继续等待；改派模块主要用于响应于司机不再等待而向服务器发送改派请求。

下面结合图6对本实施例提出的一种网约车司机客户端做进一步的介绍，其中，图6为网约车乘客客户端、服务器与网约车司机客户端之间的流程结构图，如图6所示，服务器将同意拼车乘客分为同车分组后会向网约车司机客户端进行派单，而司机会通过网约车司机客户端来确认服务器所发送的派单任务，服务器接收到确认消息后将分为同车分组的乘客与接单的司机分派到一个群组内，并向群组内发送相应的服务信息，网约车司机客户端为司机呈现乘客的行车路线、上车时间以及地点提示，司机以此进行接客或送客服务，当司机进行接客服务时，若目标点的到达时间出现延误时(例如：飞机延误、火车延误等)，网约车司机客户端会提供给司机目标点的延误信息，司机根据此延误信息确定是否继续进行等待，若选择等待的话，则该订单不会被转派，司机因此也需要继续在接客地点进行等待，而司机不选择等待的话，司机则可通过网约车司机客户端发送改派请求，服务器基于司机的改派请求将此订单进行改派，避免司机长时间的等待，提高了总体经济效应。

最后，结合实际应用场景对如图1所示的网约车系统进行进一步介绍，其中，图7示出使用该网约车系统的操作流程图，如图7所示，首先，乘客可使用网约车乘客客户端向服务器发送相关的目标点信息，并选择是否同意拼车，当乘客同意拼车后，服务器会将乘客进行相应的同车分组，而当乘客选择不拼车时，服务器则按照常规约车模式进行约车；

选择同意拼车的乘客会向服务器发送乘车信息，服务器基于此乘车信息向，网约车乘客客户端发送接客/送客服务选项，而乘客则可根据这两个选项来选择相应的服务内容并进行同车分组；

当乘客选择接客服务时，司机可驾车前往预先确定的建议上车点，一般情况下，司机需要在上车时间前三十分钟到达建议上车点来对所有乘客进行接驾，建议上车点可为机场的出口或车站的出口，其中，图8示出网约车乘客客户端的“集合确认”界面，如图8所示，例如当乘客所输入的目标点信息为所要乘坐的航班信息时，当航班到达后，所述乘客的网约车乘客客户端会进入“集合确认”界面，在图8中，界面下方显示乘客头像，未到达上车点的头像显示为第一颜色，而到达上车点的头像则显示为第二颜色，当乘客到达上车点时，乘客通过点击“确认到达”来发送确定到达消息，网约车乘客客户端基于此确认到达消息来确定移动终端所生成的实时位置是否与上车点一致，当验证成功后，界面下方的乘客头像则会由第一颜色变为第二颜色，相应的，其他乘客到达上车点且匹配成功后，其头像也会变为第二颜色，当乘客到达后，之后便是联系彼此位置，进行集合，确认会面，在进行集合时，当乘客之间确认会面后，可通过点击界面中的“会面”按钮来向服务器发送会面确定信息，此外，各个乘客也可以在聊天界面上进行聊天，也可以通过电话与其他乘客进行通话，当所有的乘客头像都变为绿色时，则代表所有乘客均已到达上车点，为了防止乘客出现迟到或爽约的现象，服务器可规定乘客需预付定金，乘客上车后，司机与乘客双方需要确认乘客信息，确认完毕后，司机开始进行接客行程，并逐个送达，当到达行车路线的终点后，结束行程、系统结算、司机收款，其中，如果超过建议上车时间仍有乘客没有到达上车点，则已上车的乘客可开始选择计费或直接出发，由于此时已上车的乘客都在等待某一个或某数个乘客，因此，若所有的已上车的乘客选择继续等待，则可向迟到的乘客收取额外的费用，按照人头数平均配分给司机以及已上车的乘客，并相应的降低等待的已上车的费用，若已到达的已上车的乘客不选择继续等待，则该迟到的乘客会被强制剔除出同车分组，而服务器则会将该迟到的乘客的派代任务转派给其他司机；

当乘客选择送客服务时，服务器会根据乘客所发送的乘客信息来确定行车路线，示例性的，图9示出服务器会根据乘客所发送的乘客信息来确定行车路线的示意图，在图9中，行车路线的起点为“京东方显示技术南门”，行车路线的终点为机场，预计16:55到达，确认完毕后，服务器向司机发送派单任务，派单成功后，分为同车分组的所有的乘客可与同车的司机进行通讯连接，服务器生成相应的聊天列表，所有的乘客与司机可相互之间进行聊天，根据个人的情况来修订期望接驾时间，为了防止乘客出现迟到或爽约的现象，服务器可规定乘客需预付定金，一般情况下，司机需要提前在行车路线的起点等待第一位乘客上车，乘客上车后，司机与乘客双方需要确认乘客信息，确认完毕后，依次接驾其他的乘客，当到达行车路线的终点后，结束行程、系统结算、司机收款，其中，当某一个乘客出现迟到的现象时，则服务器则可将该乘客进行剔除同车分组，并且其定金不予退回，并将此迟到乘客的派单任务转派给其他司机。

显然，本发明的上述实施例仅仅是为清楚地说明本发明所作的举例，而并非是对本发明的实施方式的限定，对于所属领域的普通技术人员来说，在上述说明的基础上还可以做出其它不同形式的变化或变动，这里无法对所有的实施方式予以穷举，凡是属于本发明的技术方案所引伸出的显而易见的变化或变动仍处于本发明的保护范围之列。

Claims (15)

1.一种网约车乘客客户端，其特征在于，包括：

目标点信息输入模块，用于输入乘客的目标点信息；

拼车模块，用于响应于乘客动作而确认乘客同意拼车；

乘车信息输入模块，用于输入乘客乘车信息；

送客服务模块和接客服务模块，用于响应于乘客选择而对所述乘客进行服务分类；

信息显示模块，用于以群组形式呈现服务器发送的服务信息，其中所述群组包含所述服务器根据所述目标点信息和乘车信息而分配到同一辆网约车的乘客和司机列表，所述服务信息至少包含所述同一辆网约车的车牌号和预定行车路线。

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

乘客信息显示模块，用于响应于乘客对所述乘客和司机列表中乘客或司机的选择，在地图上呈现所述被选择乘客或司机的当前位置。

3.根据权利要求1所述的客户端，其特征在于，在所述服务分类为接客服务的情况下，所述网约车乘客客户端还包括：

上车点确认模块，用于呈现被分配到同一辆网约车的所有乘客的标识，其中以第一颜色显示未到达上车点的乘客标识，以第二颜色显示到达上车点的乘客标识，并且响应于对未到达乘客发送的确认到达消息的验证，而使得该乘客标识从第一颜色变为第二颜色。

4.根据权利要求1所述的客户端，其特征在于，

所述乘车信息包括人数、乘客电话、行李数和网约车规格。

5.根据权利要求4所述的客户端，其特征在于，

在所述服务分类为送客服务的情况下，所述乘车信息还包括起点和期望接驾时间，所述服务信息还包括乘客的建议上车点和建议上车时间；

和/或

在所述服务分类为接客服务的情况下，所述乘车信息还包括终点，所述服务信息还包括乘客的建议上车点和建议上车时间。

6.根据权利要求5所述的客户端，其特征在于，

在所述服务分类为送客服务的情况下，若服务器判断乘客超过所述建议上车时间预定时长后，所述信息显示模块向所述乘客发送另行约车通知。

7.根据权利要求5所述的客户端，其特征在于，还包括：

继续等待模块，响应于已上车乘客的选择而继续等待未上车乘客并启动对所述未上车乘客计等待费，所述选择基于在所述服务分类为接客服务的情况下服务器判断乘客超过所述建议上车时间预定时长后发送的询问信息。

8.根据权利要求5所述的客户端，其特征在于，

所述建议上车点和建议上车时间能够被所述群组中的乘客修改。

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

目标点信息接收模块，用于接收来自网约车乘客客户端的乘客的目标点信息；

拼车信息接收模块，用于接收来自网约车乘客客户端的乘客同意拼车指令；

乘车信息接收模块，用于接收来自网约车乘客客户端的乘客乘车信息；

服务分类接收模块，用于接收来自网约车乘客客户端的乘客选择的服务分类；

处理模块，用于根据所述目标点信息和乘车信息将乘客加入同车分组并向网约车司机客户端派单；

信息发送模块，用于响应于来自网约车司机客户端的接单信息将被分配到同一辆网约车的乘客与该接单司机在各自客户端上以群组形式呈现，并且向所述群组发送服务信息，其中所述服务信息至少包含所述同一辆网约车的车牌号和预定行车路线。

10.根据权利要求9所述的服务器，其特征在于，

当服务分类为送客服务时，所述处理模块被配置为：

根据乘客的起点及期望接驾时间，将乘客分成同车分组，并生成所述预定行车路线，以距离目标点最远的乘客上车点为行程起点，其余同车分组乘客的上车点逐渐靠近目标点，目标点为终点。

11.一种根据权利要求9或10中任一项所述的服务器进行网约车的方法，其特征在于，所述方法包括以下步骤：

目标点信息接收模块用于接收来自网约车客户端的乘客的目标点信息；

拼车信息接收模块接收来自网约车客户端的乘客同意拼车指令；

乘车信息接收模块接收来自网约车客户端的乘客乘车信息；

服务分类接收模块接收来自网约车客户端的乘客选择的服务分类；

处理模块用于根据所述目标点信息和乘车信息将乘客加入同车分组并向网约车司机端派单；

信息发送模块响应于来自网约车司机端的接单信息将被分配到同一辆网约车的乘客与该接单司机在各自客户端上以群组形式呈现，并且向所述群组发送服务信息，其中所述服务信息至少包含所述同一辆网约车的车牌号和预定行车路线。

12.根据权利要求11所述的方法，其特征在于，

当服务分类为送客服务时，所述方法包括：

根据乘客的起点及期望接驾时间，将乘客分成同车分组，并生成所述预定行车路线，以距离目标点最远的乘客上车点为行程起点，其余同车分组乘客的上车点逐渐靠近目标点，目标点为终点。

13.根据权利要求12所述的方法，其特征在于，所述根据乘客的起点及期望接驾时间将乘客分成同车分组包括：

S1、建立一个同意拼车乘客的起点到达目标点的行车路线，得出按此行车路线到达目标点的预计时间，根据乘客需要到达目标点的到达时间，判断该乘客的期望接驾时间是否合理，如果在出发时间的预定时长以内才能到达目标点，则提醒该乘客将接驾时间提前至合理范围；

S2、判断其他同意拼车乘客的起点是否在所述行车路线附近；

S3、如果是，获取从所述其他同意拼车乘客的起点到达所述行车路线的预计时间，判断所述预计时间是否在所述其他同意拼车乘客的期望接驾时间范围内，若在此范围内，则将满足条件的乘客进行同车分组；

S4、若否，则将不在所述行车路线附近的其他同意拼车乘客的起点作为行程起点来建立其他同意拼车乘客的行车路线并重复S1和S2，以此来确定满足条件的乘客；

S5、将满足条件的乘客进行同车分组。

14.一种网约车司机客户端，与权利要求1-8中任一项所述的网约车乘客客户端和权利要求9-10任一项所述的服务器配合，其特征在于，包括

订单确认模块，用于确认所述服务器发送的派单任务；

乘客信息呈现模块，用于呈现乘客行车路线及上车时间、地点提示；

免费无限等待模块，用于供司机根据目标点的延误信息确定是否继续等待；

改派模块，用于响应于司机不再等待而向服务器发送改派请求。

15.一种网约车系统，其特征在于，包括

权利要求1-8中任一项所述的网约车乘客客户端；

权利要求9-10任一项所述的服务器；和

权利要求14所述的司机客户端。