CN103996290A - 一种提供叫车服务的方法、服务器及系统 - Google Patents

Abstract

本发明实施例提供了一种提供叫车服务的方法、服务器及系统，其中方法包括：接收乘客客户端发送的叫车请求消息，基于距离、空驶条件、路况以及乘客偏好信息和服务车辆评价信息筛选出至少一个服务车辆；将接收到的至少一个接单的车载终端对应的车辆信息返回给发出叫车请求的乘客客户端；接收乘客客户端返回的乘客根据车辆信息选择的服务车辆的信息，将订单成功消息推送至乘客选择的服务车辆的车载终端。本发明全面考虑了乘客对于服务车辆的喜好以及服务车辆司机的工作意愿，尽可能地派送令乘客满意的、服务好的服务车辆为乘客提供叫车服务，提高了用户的使用体验，同时保证了叫车交易的成功率，提高了叫车软件提供的叫车服务的总体效率。

Description

一种提供叫车服务的方法、服务器及系统

技术领域

本发明涉及智能终端的应用领域，尤其涉及一种提供叫车服务方法、服务器及系统。

背景技术

在当前人口密集的城市之中，由于交通状况的复杂性，经常出现下述情况：大量的服务车辆空驶不断寻找需要叫车的乘客，另外一方面，有叫车需求的乘客在出发地附近有很难等到空驶的车辆，这种叫车信息的不对称，导致了城市叫车难的问题，同时也浪费了有限的公共资源、能源资源以及乘客和服务车辆司机的时间资源，为了解决这一难题，目前不断涌现出许多基于手持智能终端的应用即叫车软件，这些叫车软件安装于乘客的手持智能终端上(以下简称乘客客户端)，提供叫车服务的流程如下：

乘客客户端向服务器端发送需要叫车的请求，服务器端根据该请求，生成订单信息向符合距离条件(距离该乘客的起始地址在一定范围内)、空驶条件的服务车辆的车载终端进行推送，当使用车载终端的服务车辆司机根据自己运营情况选择接单时，则订单完成，将服务车辆的联系方式返回给乘客，然后由乘客与服务车辆之间完成具体的叫车交易。

现有的这种叫车服务流程中，由于给乘客推送的司机是基于距离条件、空驶条件挑选出来的服务车辆司机，司机接单后，可能会出现乘客因为对服务车辆不满意而最终不能完成该叫车订单的交易，例如进入撤单流程，这种情况的出现，会造成双方时间和资源的浪费，影响了乘客和服务车辆司机双方的使用体验，同时也降低了叫车软件提供的叫车服务的总体效率。

发明内容

本发明实施例提供一种提供叫车服务的方法、服务器及系统，用于提高叫车软件提供的叫车服务的总体效率。

一方面，本发明实施例提供一种提供叫车服务的方法，包括：

接收乘客客户端发送的叫车请求消息，所述叫车请求信息中携带有乘客的起始地址信息以及目的地址信息；

根据当前各服务车辆与所述乘客的起始地址的距离、路况、是否处于空驶状态、以及乘客偏好信息和服务车辆评价信息，筛选出至少一个服务车辆；

将所述叫车请求消息推送至所述至少一个服务车辆上的车载终端；

当接收到至少一个车载终端返回的接单响应消息时，将所有接单的车载终端对应的车辆信息返回给发出叫车请求的乘客客户端；

接收乘客客户端返回的乘客根据所述车辆信息选择的服务车辆的信息，将订单成功消息推送至乘客选择的服务车辆的车载终端。

另一方面，本发明实施例提供一种提供叫车服务的服务器，包括：

接收模块，用于接收乘客客户端发送的叫车请求消息，所述叫车请求信息中携带有乘客的起始地址信息以及目的地址信息；接收车载终端返回的接单响应；以及接收乘客客户端返回的乘客根据所述车辆信息选择的服务车辆的信息；

筛选模块，用于根据当前各服务车辆与所述乘客的起始地址的距离、路况、是否处于空驶状态、以及乘客偏好信息和服务车辆评价信息，筛选出至少一个服务车辆；

推送模块，用于将所述叫车请求消息推送至所述至少一个服务车辆上的车载终端；当所述接收模块接收到至少一个车载终端返回的接单响应时，将所有接单的车载终端对应的车辆信息返回给发出叫车请求的乘客客户端；以及当所述接收模块接收乘客客户端返回的乘客根据所述车辆信息选择的服务车辆的信息时，将订单成功消息推送至乘客选择的服务车辆的车载终端。

另一方面，本发明实施例提供一种提供叫车服务的系统，包括：至少一个乘客客户端、至少一个司机侧的车载终端以及本实施例提供的上述服务器；其中：

所述至少一个乘客客户端，用于向所述服务器发出叫车请求消息，所述叫车请求信息中携带有乘客的起始地址信息以及目的地址信息；接收所述服务器返回的所有接单的车载终端对应的车辆信息；并将乘客根据所述车辆信息选择的服务车辆的信息返回给所述服务器；

所述至少一个司机侧的车载终端，用于接收所述服务器推送的叫车请求消息，并将所述司机的接单响应消息返回给所述服务器，以及当被乘客选择时，接收服务器返回的订单成功消息。

本发明实施例的有益效果包括：

本发明实施例提供了一种提供叫车服务的方法、服务器及系统，服务器侧基于距离条件、空驶条件、路况以及乘客偏好信息和服务车辆评价信息筛选出至少一个服务车辆，并将至少一个接单的车载终端对应的车辆信息返回给发出叫车请求的乘客客户端，接收到乘客客户端返回的乘客根据所述车辆信息选择的服务车辆的信息后，订单达成。本发明实施例在筛选给乘客推送的服务车辆时，不仅考虑距离条件、空驶条件、路况等客观信息，同时还考虑乘客的偏好以及该服务车辆评价信息等乘客方的主观信息，在推送给乘客服务车辆信息时，将各服务车辆的车辆信息也发送给乘客让乘客选择，这种方式，充分考虑了乘客对于服务车辆的喜好，尽可能地派送令乘客满意的、服务好的服务车辆为乘客提供叫车服务，提高了用户的使用体验，同时保证了叫车交易的成功率，提高了叫车软件提供的叫车服务的总体效率。

附图说明

图1为本发明实施例提供的提供叫车服务的方法的流程图；

图2为本发明实施例提供的获取服务星级信息的流程图；

图3为本发明实施例提供的参考司机的特定偏好进行筛选的流程图；

图4为本发明实施例提供的提供叫车服务的系统的乘客客户端选择界面图；

图5为本发明实施例提供的提供叫车服务的系统的聊天界面图；

图6为本发明实施例提供的提供叫车服务的服务器的结构示意图；

图7为本发明实施例提供的提供叫车服务的系统的结构示意图。

具体实施方式

下面结合说明书附图，对本发明实施例提供的一种提供叫车服务的方法的具体实施方式进行说明。

本发明实施例提供的一种提供叫车服务的方法，如图1所示，在服务器侧，具体包括以下步骤：

S101、接收乘客客户端发送的叫车请求信息；该叫车请求信息中携带有乘客的起始地址信息以及目的地址信息；

S102、根据当前各服务车辆与所述乘客的起始地址的距离、路况、是否处于空驶状态、以及乘客偏好信息和服务车辆评价信息，筛选出至少一个服务车辆；

S103、将该叫车请求消息推送至所筛选的至少一个服务车辆上的车载终端；

S104、当接收到至少一个车载终端返回的接单响应消息时，将所有接单的车载终端对应的车辆信息返回给发出叫车请求的乘客客户端；

S105、接收到乘客客户端返回的乘客根据车辆信息选择的服务车辆的信息，将订单成功消息推送至该乘客选择的服务车辆的车载终端。

下面分别对上述各步骤进行详细的说明：

上述步骤S102中，距离和空驶状态是进行筛选的首选条件，即首先筛选出距离在设定范围内(例如3公里内)和处于空驶状态的司机，然后再根据路况、乘客偏好信息和服务车辆评价信息中至少一个条件进一步进行筛选；

进一步地，上述步骤S102中距离的确定是通过下述过程实现的：服务器侧接收到司机侧的车载终端实时传送的地理位置信息，并予以记录并实时更新，这样，根据各司机侧的车载终端的当前地理位置，以及上述步骤S101中接收到的乘客客户端发送的叫车请求中携带的起始地址信息，可以确定司机和乘客之间的距离；

进一步地，上述步骤S102中，路况可以根据需求设定为若干个状态，例如可以设定为顺畅、一般、拥堵、极拥堵四个状态，也可以设定为其他多个状态，在本发明实施例中不做限定。

进一步地，上述步骤S102中乘客偏好信息，在具体实施时，可以根据乘客在完成叫车服务后是否在叫车软件中收藏了某服务车辆的相关信息来确定；

例如，在一次叫车服务结束后，乘客A在叫车软件中收藏了某个服务车辆例如服务车辆B的相关信息，即可认为乘客A对该服务车辆B有一定的偏好，则服务器会将该收藏信息作为该乘客A的偏好信息进行保存。

对于乘客A来说，如果再次叫车，服务车辆B满足为其服务的其他条件的话，那么该乘客优先选择服务车辆B的可能性较大，这种偏好信息有利于最终叫车服务交易的完成。

进一步地，上述步骤S102中服务星级的信息，可以通过如图2所示的流程获取，该流程包括：

S21、周期性地统计各乘客对每个服务车辆司机的历史评价分值；

本步骤中，每个服务车辆司机的历史评价分值是通过下述过程得到的：针对每个服务车辆，在叫车服务结束后，如果乘客通过乘客客户端对服务车辆服务进行评分，则服务器侧实时采集评分结果并存入数据库中作为该服务车辆的一项历史评价分值；

S22、计算当前周期内，每个服务车辆司机对应的所有历史评价分值的均值；

例如乘客对服务车辆司机的评分值满分为10分，在设定的时间内(例如10天内)，有三位乘客使用过服务车辆C，并且叫车服务结束后这三位乘客均通过乘客客户端对服务车辆C进行了评分(_还可以给予留言评价)，分别为：5分、6分、8分，服务器侧将接收到的本周期内所有对该服务车辆的历史评分分值进行求和，用平均值法求其均值：(5+6+8)/3＝6.3；

S23、根据该均值对应的服务星级，确定每个服务车辆司机对应的服务星级。

服务星级可以包含若干个级别，例如一星～五星。一般来说，S22中计算出来的均值越高所对应的服务星级越高，例如均值在90-100之间的服务星级为五星，均值在80-90之间的服务星级为四星，均值在70-80之间的服务星级为三星，均值在60-70之间的服务星级为两星，均值在60以下的服务星级为一星。

需要说明的是，上述步骤S102中对服务车辆的筛选条件可以根据需求来设定或者调整，如可以将筛选条件设定为：处于空驶状态、在设定距离3公里范围内、路况为一般状态以上、服务星级为四颗星以上等等。

进一步地，基于上述步骤S102的筛选的结果中，还可以进一步参考司机的特定偏好来筛选，如图3所示，该流程具体包括下述各步骤：

S301、判断上述筛选结果中是否存在特定偏好的司机的服务车辆；

S302、判断乘客的起始地址信息或者目的地址信息是否位于该司机偏好的特定区域内；和/或判断叫车请求信息的发出时间是否位于该司机偏好的特定工作时间内；

S303、若是，则将各个存在特定偏好的司机的服务车辆作为最终筛选结果；

本步骤中是的情况分为两种：若上述步骤S302中两个判断条件为和的关系，那么这两个判断条件都要满足即为是；若上述步骤S302中两个判断条件为或的关系，那么这两个判断条件中至少一个满足即为是；

S304、若否，则保留原筛选结果。

这种筛选司机的特定偏好信息的筛选方式，充分考虑了司机的工作意愿，缩小了可筛选的服务车辆的范围，提高了叫车软件的筛选效率，同时保证了叫车交易的成功率，进而提高了叫车软件提供的叫车服务的总体效率。

进一步地，上述特定偏好的确定，例如通过使用聚类法统计服务车辆司机在设定时间内(例如60天内)接单的区域和时间；

例如经过若干天时间的统计，得到司机刘师傅经常在D区接单，而且接单时间为周六和周日两天，那么在数据库中刘师傅的服务车辆所对应的用户号下存储其偏好的接单时间和偏好的接单区域的经纬度信息；

进一步地，上述步骤S104中存储在数据库中的车辆信息可以以图4所示的形式展示在乘客客户端上：服务车辆车辆信息采用列表方式来显示，第一条为车辆1的车辆信息，包括：车辆颜色、车辆品牌、车况、司机的服务星级、累计接单数量；其他车辆信息与此类似，不再详述。

进一步地，上述步骤S105完成之后，当接收到乘客客户端和/或司机车载终端的即时通信请求时，向乘客客户端和司机车载终端推送用于即时通信的聊天界面；当接收乘客客户端和/或司机车载终端的聊天消息时，将聊天消息展示在乘客客户端和司机车载终端的聊天界面上；

用于即时通信的聊天界面可以采用如图5所示的界面，首先司机开始向乘客打招呼：“您好，很高兴为您服务！我是XX公司的服务车辆司机付师傅，本次服务将由我来完成，车牌号为京B******”，乘客进行应答：“您好，付师傅，您现在到哪了？还有多久可以到达”，付师傅回答：“我到XX地了，还有15分钟就到”。这种即时通信的方式，为司机和乘客提供了直接交流的平台，在这个平台上，司机还可以为乘客提供更个性化的服务，提升了乘客的使用体验。

基于同一发明构思，本发明实施例还提供了一种提供叫车服务的服务器及系统，由于该服务器和系统所解决问题的原理与前述提供叫车服务的方法相似，因此该服务器和系统的实施可以参见前述方法的实施，重复之处不再赘述。

本发明实施例提供的提供叫车服务的服务器，如图6所示，包括：

接收模块601，用于接收乘客客户端发送的叫车请求消息，该叫车请求信息中携带有乘客的起始地址信息以及目的地址信息；接收车载终端返回的接单响应；以及接收乘客客户端返回的乘客根据车辆信息选择的服务车辆的信息；

筛选模块602，用于根据当前各服务车辆与乘客的起始地址的距离、路况、是否处于空驶状态、以及乘客偏好信息和服务车辆评价信息，筛选出至少一个服务车辆；

推送模块603，用于将叫车请求消息推送至至少一个服务车辆上的车载终端；当接收模块601接收到至少一个车载终端返回的接单响应时，将所有接单的车载终端对应的车辆信息返回给发出叫车请求的乘客客户端；以及当接收模块601接收乘客客户端返回的乘客根据车辆信息选择的服务车辆的信息时，将订单成功消息推送至乘客选择的服务车辆的车载终端；

进一步地，本发明实施例提供的提供叫车服务的服务器，如图6所示，还可以包括：存储模块604，用于存储乘客收藏的服务车辆司机的信息作为乘客偏好信息；以及存储每个服务车辆司机对应的服务星级信息作为各个服务车辆评价信息；

进一步地，本发明实施例提供的提供叫车服务的服务器，如图6所示，还可以包括:评定模块605，用于周期性地统计各乘客对每个服务车辆司机的历史评价分值；计算当期周期内，每个服务车辆司机对应的所有历史评价分值的均值；根据该均值对应的服务星级，确定每个服务车辆司机对应的服务星级；

进一步地，本发明实施例提供的提供叫车服务的服务器中的筛选模块602还可以用于在筛选出的至少一个服务车辆中，判断是否存在特定偏好的司机的服务车辆；该特定偏好包括：对特定区域的偏好和/或对特定工作时间的偏好；当判断存在特定偏好的司机的服务车辆时，判断乘客的起始地址信息或者目的地址信息是否位于该司机偏好的特定区域内；和/或判断叫车请求信息的发出时间是否位于该司机偏好的特定工作时间内；若是，将各个存在特定偏好的司机的服务车辆作为最终筛选结果；若否，保留原筛选结果。

进一步地，本发明实施例提供的提供叫车服务的服务器，如图6所示，还可以包括：即时通信模块606，用于在将订单成功消息推送至乘客选择的服务车辆的车载终端之后，接收乘客客户端和/或司机车载终端的即时通信请求，向乘客客户端和司机车载终端推送用于即时通信的聊天界面；接收乘客客户端和/或司机车载终端的消息并展示在乘客客户端和司机车载终端的聊天界面上；

本发明实施例提供的一种提供叫车服务的系统，如图7所示，包括：

至少一个乘客客户端701，用于向服务器702发出叫车请求消息，该叫车请求信息中携带有乘客的起始地址信息以及目的地址信息；接收服务器702返回的所有接单的车载终端对应的车辆信息；并将乘客根据车辆信息选择的服务车辆的信息返回给服务器702；

服务器702，用于接收乘客客户端701发送的叫车请求消息；根据当前各服务车辆与乘客的起始地址的距离、路况、是否处于空驶状态、以及乘客偏好信息和服务车辆评价信息，筛选出至少一个服务车辆；将叫车请求消息推送至至少一个服务车辆上的车载终端703；当接收到至少一个车载终端703返回的接单响应消息时，将所有接单的车载终端703对应的车辆信息返回给发出叫车请求的乘客客户端701；接收乘客客户端701返回的乘客根据车辆信息选择的服务车辆的信息，将订单成功消息推送至乘客选择的服务车辆的车载终端703。

至少一个司机侧的车载终端703，用于接收服务器702推送的叫车请求消息，并将司机的接单响应消息返回给服务器702，以及当被乘客选择时，接收服务器702返回的订单成功消息。

进一步地，服务器702还可以接收乘客客户端701和/或司机车载终端703的即时通信请求，向乘客客户端701和司机车载终端703推送用于即时通信的聊天界面；接收乘客客户端701和/或司机车载终端703的聊天消息并展示在乘客客户端701和司机车载终端端703的聊天界面上。

本发明实施例提供了一种提供叫车服务的方法、服务器及系统，服务器侧基于距离条件、空驶条件、路况以及乘客偏好信息和服务车辆评价信息筛选出至少一个服务车辆，并将至少一个接单的车载终端对应的车辆信息返回给发出叫车请求的乘客客户端，接收到乘客客户端返回的乘客根据所述车辆信息选择的服务车辆的信息后，订单达成。本发明实施例在筛选给乘客推送的服务车辆时，不仅考虑距离条件、空驶条件、路况等客观信息，同时还考虑乘客的偏好以及该服务车辆评价信息等乘客方的主观信息，在推送给乘客服务车辆信息时，将各服务车辆的车辆信息也发送给乘客让乘客选择，这种方式，充分考虑了乘客对于服务车辆的喜好，尽可能地派送令乘客满意的、服务好的服务车辆为乘客提供叫车服务，提高了用户的使用体验，同时保证了叫车交易的成功率，提高了叫车软件提供的叫车服务的总体效率。

本领域技术人员可以理解附图只是一个优选实施例的示意图，附图中的模块或流程并不一定是实施本发明所必须的。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (12)

1.一种提供叫车服务的方法，其特征在于，包括：

接收乘客客户端发送的叫车请求消息，所述叫车请求信息中携带有乘客的起始地址信息以及目的地址信息；

根据当前各服务车辆与所述乘客的起始地址的距离、路况、是否处于空驶状态、以及乘客偏好信息和服务车辆评价信息，筛选出至少一个服务车辆；

将所述叫车请求消息推送至所述至少一个服务车辆上的车载终端；

当接收到至少一个车载终端返回的接单响应消息时，将所有接单的车载终端对应的车辆信息返回给发出叫车请求的乘客客户端；

接收乘客客户端返回的乘客根据所述车辆信息选择的服务车辆的信息，将订单成功消息推送至乘客选择的服务车辆的车载终端。

2.如权利要求1所述的方法，其特征在于，所述乘客偏好信息为存储的该乘客收藏的服务车辆司机的信息；

所述服务车辆评价信息为存储每个服务车辆司机对应的服务星级信息。

3.如权利要求2所述的方法，其特征在于，所述服务星级信息，通过下述方式确定：

周期性地统计各乘客对每个服务车辆司机的历史评价分值；

计算当前周期内，每个服务车辆司机对应的所有历史评价分值的均值；

根据所述均值对应的服务星级，确定每个服务车辆司机对应的服务星级。

4.如权利要求1-3任一项所述的方法，其特征在于，还包括：在筛选出的至少一个服务车辆中，判断是否存在特定偏好的司机的服务车辆；所述特定偏好包括：对特定区域的偏好和/或对特定工作时间的偏好；

当判断存在特定偏好的司机的服务车辆时，判断所述乘客的起始地址信息或者目的地址信息是否位于该司机偏好的特定区域内；和/或判断所述叫车请求信息的发出时间是否位于该司机偏好的特定工作时间内；

若是，将各个存在特定偏好的司机的服务车辆作为最终筛选结果；

若否，保留原筛选结果。

5.如权利要求2或3所述的方法，其特征在于，所述车辆信息包括至少一个下述信息：

车辆品牌、车辆颜色、车况、累计接单数量、司机的服务星级。

6.如权利要求1-3任一项所述的方法，其特征在于，将订单成功消息推送至乘客选择的服务车辆的车载终端之后，还包括：

接收乘客客户端和/或司机客户端的即时通信请求，向所述乘客客户端和所述司机客户端推送用于即时通信的聊天界面；

接收乘客客户端和/或司机客户端的聊天消息并展示在所述乘客客户端和所述司机客户端的聊天界面上。

7.一种提供叫车服务的服务器，其特征在于，包括：

接收模块，用于接收乘客客户端发送的叫车请求消息，所述叫车请求信息中携带有乘客的起始地址信息以及目的地址信息；接收车载终端返回的接单响应；以及接收乘客客户端返回的乘客根据所述车辆信息选择的服务车辆的信息；

筛选模块，用于根据当前各服务车辆与所述乘客的起始地址的距离、路况、是否处于空驶状态、以及乘客偏好信息和服务车辆评价信息，筛选出至少一个服务车辆；

推送模块，用于将所述叫车请求消息推送至所述至少一个服务车辆上的车载终端；当所述接收模块接收到至少一个车载终端返回的接单响应时，将所有接单的车载终端对应的车辆信息返回给发出叫车请求的乘客客户端；以及当所述接收模块接收乘客客户端返回的乘客根据所述车辆信息选择的服务车辆的信息时，将订单成功消息推送至乘客选择的服务车辆的车载终端。

8.如权利要求7所述的服务器，其特征在于，还包括：存储模块，用于存储该乘客收藏的服务车辆司机的信息作为所述乘客偏好信息；以及存储每个服务车辆司机对应的服务星级信息作为所述服务车辆评价信息。

9.如权利要求8所述的服务器，其特征在于，还包括：评定模块，用于周期性地统计各乘客对每个服务车辆司机的历史评价分值；计算当期周期内，每个服务车辆司机对应的所有历史评价分值的均值；根据所述均值对应的服务星级，确定每个服务车辆司机对应的服务星级。

10.如权利要求7-9任一项所述的服务器，其特征在于，筛选模块，还用于在筛选出的至少一个服务车辆中，判断是否存在特定偏好的司机的服务车辆；所述特定偏好包括：对特定区域的偏好和/或对特定工作时间的偏好；当判断存在特定偏好的司机的服务车辆时，判断所述乘客的起始地址信息或者目的地址信息是否位于该司机偏好的特定区域内；和/或判断所述叫车请求信息的发出时间是否位于该司机偏好的特定工作时间内；若是，将各个存在特定偏好的司机的服务车辆作为最终筛选结果；若否，保留原筛选结果。

11.如权利要求7-9任一项所述的服务器，其特征在于，还包括：

即时通信模块，用于在将订单成功消息推送至乘客选择的服务车辆的车载终端之后，接收乘客客户端和/或司机车载终端的即时通信请求，向所述乘客客户端和所述司机车载终端推送用于即使通信的聊天界面；接收乘客客户端和/或司机车载终端的消息并展示在所述乘客客户端和所述司机车载终端的聊天界面上。

12.一种提供叫车服务的系统，其特征在于，包括：至少一个乘客客户端、至少一个司机侧的车载终端以及如权利要求7-11任一项所述的服务器；

所述至少一个乘客客户端，用于向所述服务器发出叫车请求消息，所述叫车请求信息中携带有乘客的起始地址信息以及目的地址信息；接收所述服务器返回的所有接单的车载终端对应的车辆信息；并将乘客根据所述车辆信息选择的服务车辆的信息返回给所述服务器；

所述至少一个司机侧的车载终端，用于接收所述服务器推送的叫车请求消息，并将所述司机的接单响应消息返回给所述服务器，以及当被乘客选择时，接收服务器返回的订单成功消息。