一种拼车信息提示的方法及系统与流程

本发明涉及公共交通服务技术领域，尤其涉及一种拼车信息提示方法及系统。

背景技术

目前随着城市生活的发展，出租车资源的紧张，以及费用的不断上涨，拼车己经成为一个流行的出行方式。拼车出行允许多个出行个体共享运输服务，充分利用车辆的载客量，能够进一步降低出行费用，减轻相关的交通污染和能源消耗问题。

当用户通过客户端的拼车软件发出拼车请求时，系统需要花费一定的时间来为用户寻找拼友。如果用户愿意等待越多的时间，系统为用户找到拼友(拼车时与用户同行的其他乘客)的成功率将大大提升。因此，需要提供一种拼车信息提示方法，尽量延长用户愿意为等待拼车成功所花费的时间，进而提高拼车成功率。

技术实现要素：

本发明主要涉及一种拼车信息提示方法、系统及装置。具体包括以下几个方面：

第一方面，本发明披露了一种拼车信息提示方法。该方法包括：获取用户的拼车请求；将所述拼车请求发送给服务器；接收服务器的信息，显示并动态更新所述拼车请求的进程信息以及为用户寻找拼友的状态信息；所述拼车请求的进程信息至少反映用户预计等待时长。

在一些实施例中，所述状态信息至少包括为所述用户确定的至少一名候选拼友的标识信息以及所述候选拼友的匹配度；所述匹配度至少反映候选拼友与所述用户的顺路程度。

在一些实施例中，所述用户预计等待时长包括用户预计等待派车的时长和/或用户预计等待发车的时长。

在一些实施例中，显示并动态更新所述拼车请求的进程信息进一步包括：以倒计时的方式显示所述进程信息。

在一些实施例中，所述拼车信息提示方法还包括接收并显示服务器推送的接驾车辆的车辆信息及其位置信息。

第二方面，本发明披露了一种拼车信息提示系统。该系统包括：获取模块，用于获取用户的拼车请求；传输模块，用于将所述拼车请求发送给服务器；接收模块，用于接收服务器的信息；显示模块，用于显示并动态更新服务器推送的所述拼车请求的进程信息以及为用户寻找拼友的状态信息；所述拼车请求的进程信息至少反映用户预计等待时长。

在一些实施例中，所述状态信息至少包括为所述用户确定的至少一名候选拼友的标识信息以及所述候选拼友的匹配度；所述匹配度至少反映候选拼友与所述用户的顺路程度。

在一些实施例中，所述用户预计等待时长包括用户预计等待派车的时长和/或用户预计等待发车的时长。

在一些实施例中，所述显示模块还用于以倒计时的方式显示所述进程信息。

在一些实施例中，所述显示模块还用于显示服务器推送的接驾车辆的车辆信息及其位置信息。

第三方面，本发明披露了一种拼车信息提示装置。该装置包括至少一个处理器以及至少一个存储器；所述至少一个存储器用于存储计算机指令；所述至少一个处理器用于执行所述计算机指令中的至少部分指令以实现如所述拼车信息提示方法中任意一项所述的操作。

第四方面，本发明披露了一种计算机可读存储介质。所述存储介质存储计算机指令，当所述计算机指令被处理器执行时实现如所述拼车信息提示方法中任意一项所述的操作。

第五方面，本发明披露了一种拼车信息提示方法。该方法包括：获取用户的拼车请求；为所述用户寻找至少一位拼友；将所述拼车请求的进程信息以及为所述用户寻找拼友的状态信息实时发送给客户端；所述拼车请求的进程信息至少反映用户预计等待时长。

在一些实施例中，所述状态信息至少包括为所述用户确定的至少一名候选拼友的标识信息以及所述候选拼友的匹配度；所述匹配度至少反映候选拼友与所述用户的顺路程度。

在一些实施例中，所述用户预计等待时长包括用户预计等待派车时长和/或用户预计等待发车时长。

在一些实施例中，所述为所述用户寻找至少一位拼友包括：在所述用户预计等待发车时长内为所述用户寻找至少一位拼友。

在一些实施例中，所述拼车信息提示方法还包括：在达到用户预计等待派车时长前，为所述用户寻找到至少一位拼友后为所述用户确定接驾车辆；或者，在达到用户预计等待派车时长后，为所述用户确定接驾车辆；将所述接驾车辆的车辆信息及位置信息发送给所述客户端。

在一些实施例中，所述拼车信息提示方法还包括：还包括：获取接驾车辆位置信息；当确定接驾车辆到达拼车请求中的出发地后，满足一下任意条件时，向司机终端发出发车指令：用户预计等待发车时长到达，或为所述用户寻找到至少一位拼友。

在一些实施例中，用户预计等待发车时长为固定时长；或者，用户预计等待发车时长与所述拼车请求中的出发地相关。

在一些实施例中，用户预计等待派车时长为固定时长；或者，用户预计等待派车时长至少与以下信息中的至少一个相关：所述拼车请求中的出发地的供需比，或用户发出拼车请求的位置与拼车请求中的出发地之间的距离；出发地的供需比为出发地一定范围区域内的当前可用车辆数目除以该区域内的当前拼车订单数目。

第六方面，本发明披露一种拼车信息提示系统。该系统包括：获取模块，用于获取用户的拼车请求；拼友匹配模块，用于为所述用户寻找至少一位拼友；传输模块，用于将所述拼车请求的进程信息以及为所述用户寻找拼友的状态信息实时发送给客户端；所述拼车请求的进程信息至少反映用户预计等待时长。

在一些实施例中，所述状态信息至少包括为所述用户确定的至少一名候选拼友的标识信息以及所述候选拼友的匹配度；所述匹配度至少反映候选拼友与所述用户的顺路程度。

在一些实施例中，所述用户预计等待时长包括用户预计等待派车时长和/或用户预计等待发车时长。

在一些实施例中，拼友匹配模块还用于在所述用户预计等待发车时长内为所述用户寻找至少一位拼友。

在一些实施例中，所述拼车信息提示系统还包括派车模块，用于在达到用户预计等待派车时长前，为所述用户寻找到至少一位拼友后为所述用户确定接驾车辆；或者，在达到用户预计等待派车时长后，为所述用户确定接驾车辆；所述传输模块还用于将所述接驾车辆的车辆信息及位置信息发送给所述客户端。

在一些实施例中，所述拼车信息提示系统还包括发车控制模块；所述获取模块用于获取接驾车辆位置信息；所述发车控制模块用于当确定接驾车辆到达拼车请求中的出发地后，满足一下任意条件时，向司机终端发出发车指令：用户预计等待发车时长到达，或为所述用户寻找到至少一位拼友。

在一些实施例中，用户预计等待发车时长为固定时长；或者，用户预计等待发车时长与所述拼车请求中的出发地相关。

在一些实施例中，用户预计等待派车时长为固定时长；或者，用户预计等待派车时长至少与以下信息中的至少一个相关：所述拼车请求中的出发地的供需比，或用户发出拼车请求的位置与拼车请求中的出发地之间的距离；出发地的供需比为出发地一定范围区域内的当前可用车辆数目除以该区域内的当前拼车订单数目。

第七方面，本发明披露了一种拼车信息提示装置。该装置包括至少一个处理器以及至少一个存储器；所述至少一个存储器用于存储计算机指令；所述至少一个处理器用于执行所述计算机指令中的至少部分指令以实现如所述拼车信息提示方法中任意一项所述的操作。

第八方面，本发明披露了一种计算机可读存储介质。所述存储介质存储计算机指令，当所述计算机指令被处理器执行时实现如所述拼车信息提示方法中任意一项所述的操作。

第九方面，本发明披露了一种确定用户的预计等待发车时长的方法。该包括：获取用户的拼车请求；基于拼车请求中的出发地确定用户的预计等待发车时长；用户预计等待发车时长为服务器寻找用户拼友的最大时长。

在一些实施例中，所述基于拼车请求中的出发地确定用户的预计等待发车时长包括：确定所述出发地所属的区域；基于所述区域，确定所述用户预计等待发车时长。

在一些实施例中，所述基于拼车请求中的出发地确定用户的预计等待发车时长包括：确定所述出发地的途径率、拼成率、供需比和应答率；确定用户发出拼车请求时的位置到所述出发地的距离；基于所述途径率、拼成率、供需比、应答率和距离中的至少一个信息，计算用户预计等待发车时长；出发地的途径率为出发地一定范围区域内发出的历史拼车订单数目除所述历史拼车订单中途经所述出发地的订单数目；出发地的拼成率为以所述出发地作为出发地的历史拼车订单中拼车成功的拼车订单数目除以所述历史拼车订单的总数；出发地的供需比为出发地一定范围区域内的当前可用车辆数目除以该区域内的当前拼车订单数目；出发地的应答率为以所述出发地作为出发地的历史拼车订单中被接受订单的数目除以所述历史拼车订单的总数。

第十方面，本发明披露了一种确定用户的预计等待发车时长的系统。该系统包括：获取模块，用于获取用户的拼车请求；确定模块，用于基于拼车请求中的出发地确定用户的预计等待发车时长；用户预计等待发车时长为服务器寻找用户拼友的最大时长。

在一些实施例中，所述确定模块还用于：确定所述出发地所属的区域；基于所述区域，确定所述用户预计等待发车时长。

在一些实施例中，所述确定模块还用于：确定所述出发地的途径率、拼成率、供需比和应答率；确定用户发出拼车请求时的位置到所述出发地的距离基于所述途径率、拼成率、供需比、应答率和距离中的至少一个信息，计算用户预计等待发车时长；出发地的途径率为出发地一定范围区域内发出的历史拼车订单中途经所述出发地的订单数目除以出发地一定范围区域内发出的历史拼车订单数目；出发地的拼成率为以所述出发地作为出发地的历史拼车订单中拼车成功的拼车订单数目除以所述历史拼车订单的总数；出发地的供需比为出发地一定范围区域内的当前可用车辆数目除以该区域内的当前拼车订单数目；出发地的应答率为以所述出发地作为出发地的历史拼车订单中被接受订单的数目除以所述历史拼车订单的总数。

第十一方面，本发明披露了一种确定用户的预计等待发车时长的装置。该装置包括至少一个处理器以及至少一个存储器；所述至少一个存储器用于存储计算机指令；所述至少一个处理器用于执行所述计算机指令中的至少部分指令以实现如确定用户的预计等待发车时长的方法中任意一项所述的操作。

第十二方面，本发明披露了一种计算机可读存储介质。所述存储介质存储计算机指令，当所述计算机指令被处理器执行时实现如确定用户的预计等待发车时长的方法中任意一项所述的操作。

附图说明

图1是根据本发明的一些实施例所示的一种按需服务系统的示意图；

图2是用于实现本发明技术方案的专用系统的示例性计算设备的框图；

图3是用于实现本发明技术方案的专用系统的示例性移动设备的框图；

图4是根据本发明的一些实施例所示的一种拼车信息提示方法的流程示意图；

图5是根据本发明的一些实施例所示的一种拼车信息提示装置的功能框图；

图6是根据本发明的一些实施例所示的另一种拼车信息提示方法的流程示意图；

图7是根据本发明的一些实施例所示的另一种拼车信息提示装置的功能框图；

图8是根据本发明的一些实施例所示的一种确定用户的预计等待发车时长的方法的流程示意图；

图9是根据本发明的一些实施例所示的一种确定用户的预计等待发车时长装置的功能框图。

具体实施方式

为了更清楚地说明本申请的实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其它类似情景。除非从语言环境中显而易见或另做说明，图中相同标号代表相同结构或操作。

如本申请和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其它的步骤或元素。

虽然本申请对根据本申请的实施例的系统中的某些模块或单元做出了各种引用，然而，任何数量的不同模块或单元可以被使用并运行在客户端和/或服务器上。所述模块仅是说明性的，并且所述系统和方法的不同方面可以使用不同模块。

本申请中使用了流程图用来说明根据本申请的实施例的系统所执行的操作。应当理解的是，前面或下面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各种步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。

本申请的实施例可以应用于不同的运输系统，不同的运输系统包括但不限于陆地、海洋、航空、航天等中的一种或几种的组合。例如，出租车、专车、顺风车、巴士、代驾、火车、动车、高铁、船舶、飞机、热气球、无人驾驶的交通工具、收/送快递等应用了管理和/或分配的运输系统。本申请的不同实施例应用场景包括但不限于网页、浏览器插件、客户端、定制系统、企业内部分析系统、人工智能机器人等中的一种或几种的组合。应当理解的是，本申请的系统及方法的应用场景仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其它类似情景。例如，其他类似的引导用户停车系统。

本申请描述的“乘客”、“乘客端”、“用户”、“用户终端”、“顾客”、“需求者”、“服务需求者”、“消费者”、“消费方”、“使用需求者”等是可以互换的，是指需要或者订购服务的一方，可以是个人，也可以是工具。同样地，本申请描述的“司机”、“司机端”、“提供者”、“供应者”、“服务提供者”、“服务者”、“服务方”等也是可以互换的，是指提供服务或者协助提供服务的个人、工具或者其他实体等。另外，本申请描述的“用户”可以是需要或者订购服务的一方，也可以是提供服务或者协助提供服务的一方。

图1是根据本发明的一些实施例所示的一种按需服务系统的示意图。

按需服务系统100可以包括服务器110、网络120、乘客端130、司机端140和存储器150。

服务器110可以是本地的，也可以是远程的。服务器110可以包括用于执行指令(程序代码)，并通过一定的算法为不同的拼车用户确定等待时长。

在一些实施例中，服务器110可以用于对收集的信息进行分析加工以生成分析结果的系统。服务器110可以是一个终端设备，也可以是一个服务器，还可以是服务器群组。所述服务器群组可以是集中式的，例如数据中心。所述服务器群组也可以是分布式的，例如分布式系统。

乘客端130是指发布服务订单的个人、工具或者其他实体。在一些实施例中，乘客端130为发出拼车请求的乘客端用户。在一些实施例中，乘客端130包括但不限于台式电脑130-1、笔记本电脑130-2、机动车的内置设备130-3、移动设备130-4等中的一种或几种的组合。

司机端140是执行服务订单的个人、工具或者其他实体。在一些实施例中，司机端140为接受乘客发出拼车请求的司机端用户。在一些实施例中，司机端140包括但不限于台式电脑140-1、笔记本电脑140-2、机动车的内置设备140-3、移动设备140-4等中的一种或几种的组合。服务器110可以直接访问存取储存在存储器150的数据信息，也可以直接通过网络120访问存取用户130/140的信息。

存储器150可以泛指具有存储功能的设备。存储器150主要用于存储从乘客端130和/或司机端140收集的数据和按需服务系统100工作中产生的各种数据。存储器150可以是本地的，也可以是远程的。系统数据库与系统其他模块间的连接或通信可以是有线的，也可以是无线的。

网络120可以提供信息交换的渠道。网络120可以是单一网络，也可以是多种网络组合的。网络120可以包括但不限于局域网、广域网、公用网络、专用网络、无线局域网、虚拟网络、都市城域网、公用开关电话网络等中的一种或几种的组合。网络120可以包括多种网络接入点，如有线或无线接入点、基站(如120-1，120-2)或网络交换点，通过以上接入点使数据源连接网络120并通过网络发送信息。

图2是用于实现本发明技术方案的专用系统的示例性计算设备200的框图。

如图2所示，计算设备200可以包括处理器210、存储器220、输入/输出接口230和通信通信端口240。

处理器210可以执行计算指令(程序代码)并执行本发明描述的按需服务系统100的功能。所述计算指令可以包括程序、对象、组件、数据结构、过程、模块和功能(所述功能指本发明中描述的特定功能)。例如，处理器210可以处理从按需服务系统100的其他任何组件获得的图像或文本数据。在一些实施例中，处理器210可以包括微控制器、微处理器、精简指令集计算机(risc)、专用集成电路(asic)、应用特定指令集处理器(asip)、中央处理器(cpu)、图形处理单元(gpu)、物理处理单元(ppu)、微控制器单元、数字信号处理器(dsp)、现场可编程门阵列(fpga)、高级risc机(arm)、可编程逻辑器件以及能够执行一个或多个功能的任何电路和处理器等，或其任意组合。仅为了说明，图2中的计算设备200只描述了一个处理器，但需要注意的是本发明中的计算设备200还可以包括多个处理器。

存储器220可以存储从按需服务系统100的任何其他组件获得的数据/信息。在一些实施例中，存储器220可以包括大容量存储器、可移动存储器、易失性读取和写入存储器和只读存储器(rom)等，或其任意组合。示例性大容量存储器可以包括磁盘、光盘和固态驱动器等。可移动存储器可以包括闪存驱动器、软盘、光盘、存储卡、压缩盘和磁带等。易失性读取和写入存储器可以包括随机存取存储器(ram)。ram可以包括动态ram(dram)、双倍速率同步动态ram(ddrsdram)、静态ram(sram)、晶闸管ram(t-ram)和零电容(z-ram)等。rom可以包括掩模rom(mrom)、可编程rom(prom)、可擦除可编程rom(perom)、电可擦除可编程rom(eeprom)、光盘rom(cd-rom)和数字通用盘rom等。

输入/输出接口230可以用于输入或输出信号、数据或信息。在一些实施例中，输入/输出接口230可以使用户与按需服务系统100进行联系。在一些实施例中，输入/输出接口230可以包括输入装置和输出装置。示例性输入装置可以包括键盘、鼠标、触摸屏和麦克风等，或其任意组合。示例性输出设备可以包括显示设备、扬声器、打印机、投影仪等，或其任意组合。示例性显示装置可以包括液晶显示器(lcd)、基于发光二极管(led)的显示器、平板显示器、曲面显示器、电视设备、阴极射线管(crt)等，或其任意组合。通信端口240可以连接到网络以便数据通信。所述连接可以是有线连接、无线连接或两者的组合。有线连接可以包括电缆、光缆或电话线等，或其任意组合。无线连接可以包括蓝牙、wi-fi、wimax、wlan、zigbee、移动网络(例如，3g、4g或5g等)等，或其任意组合。在一些实施例中，通信端口240可以是标准化端口，如rs232、rs485等。在一些实施例中，通信端口240可以是专门设计的端口。例如，通信端口240可以根据数字成像和医学通信协议(dicom)进行设计。

图3是用于实现本发明技术方案的专用系统的示例性移动设备300的框图。

如图3所示，所述移动设备300可以包括通信平台310、显示器320、图形处理器(gpu)330、中央处理器(cpu)340、输入/输出接口350、内存360、存储器370等。在一些实施例中，操作系统361(如，ios，android，windowsphone等)和应用程序362可以从存储器370加载到内存360中，以便由cpu340执行。应用程序362可以包括浏览器或用于从按需服务系统100接收成像、图形处理、音频或其他相关信息的应用程序。

为了实现在本发明中描述的各种模块、单元及其功能，计算设备或移动设备可以用作本发明所描述的一个或多个组件的硬件平台。这些计算机或移动设备的硬件元件、操作系统和编程语言本质上是常规的，并且本领域技术人员熟悉这些技术后可将这些技术适应于本发明所描述的按需服务系统。具有用户界面元件的计算机可以用于实现个人计算机(pc)或其他类型的工作站或终端设备，如果适当地编程，计算机也可以充当服务器。

图4是根据本发明的一些实施例所示的一种拼车信息提示方法400的流程示意图。

拼车信息提示方法400可以由乘客端130(或客户端)实现。

步骤401，获取用户的拼车请求。

乘客端130(例如，手机)可以获取用户输入的拼车请求。拼车请求可以包括但不限于出发地、目的地、发出拼车请求的时间、发出拼车请求时的位置、乘车人数等。

步骤402，将所述拼车请求发送给服务器。

乘客端130可以将所述拼车请求通过网络120发送给服务器110。

步骤403，接收服务器的信息，显示并动态更新所述拼车请求的进程信息以及为用户寻找拼友的状态信息。

乘客端130可以接收服务器110发送的信息；乘客端130的界面上可以显示并动态更新所述拼车请求的进程信息以及为用户寻找拼友的状态信息。其中，所述拼车请求的进程信息至少反映用户预计等待时长。显示并动态更新所述拼车请求的进程信息进一步包括：以倒计时的方式显示所述进程信息。

在一些实施中，用户预计等待时长为用户预计等待派车的时长和/或用户预计等待发车的时长等。在其他实施例中，用户预计等待时长还可以为用户预计等待其他节点的时长，例如：司机达到拼车请求中的出发地这一节点。

用户预计等待派车的时长为乘客端130的界面上显示用户需要等待多久服务器110开始为该用户派车的时长。在一个实施例中，用户预计等待派车的时长为用户发出拼车请求的时刻到服务器110开始为其派车的时刻的时长，例如，在用户发出拼车请求后的1分钟结束之后，服务器110可以为用户派车。在另一实施例中，用户预计等待派车的时长可以是服务器110接收到所述拼车请求的时刻到服务器110开始为所述用户派车时刻之间的时长，例如在服务器110接收到用户拼车请求后的50秒结束后为用户派车。在又一实施例中，用户预计等待派车的时长还可以是当前时刻到服务器110开始为所述用户派车时刻之间的时长。例如，在客户端屏幕上通过倒计时的方式来动态显示这一时长，如50秒后将为您派车。

用户预计等待发车时长为用户需要等待多久可以出发。在一个实施例中，用户预计等待发车的时长为用户发出拼车请求的时刻到接驾车辆接到用户后出发时刻(即，发车时刻)的时长。例如，用户在8点10分发出拼车请求，乘客端130的界面显示8点15分准时出发。在另一实施例中，用户预计等待发车的时长可以是服务器110接收到所述拼车请求的时刻到用户出发时刻的时长。在又一实施例中，用户预计等待发车的时长还可以是当前时刻到用户出发时刻的时长。例如，在客户端屏幕上通过倒计时的方式来动态显示这一时长，如客户端显示4分37秒后出发。

在一些实施例中，所述状态信息可以是已经为所述用户匹配候选拼友的次数，例如“已为您匹配拼友5次”，已经发现的候选拼友人数，例如“已经找到7位可一路同行的候选拼友”、候选拼友的标识信息和/或所述候选拼友的匹配度等。所述匹配度至少反映候选拼友与所述用户的顺路程度。其中，标识信息可以为候选拼友注册的头像或者id信息。例如，乘客端130的界面可以显示候选拼友注册的头像以及该候选拼友与用户的顺路程度(例如，顺路程度为55％)。

在一些实施例中，动态更新所述状态信息可以是：当前时刻，客户端显示候选拼友a的头像信息、位置信息以及匹配度75％，下一时刻客户端切换显示候选拼友b的头像信息、位置信息以及匹配度82％，再下一时刻客户端切换显示候选拼友c的头像信息、位置信息以及匹配度95％等。当拼友确定后，客户端显示屏不再切换候选拼友，而是将最终确定的拼友信息一直显示。

在其他实施例中，还可以随时拼车进程的推进，加快候选拼友信息的切换速度。

在一些实施例中，所述拼车信息提示方法400还包括接收并显示服务器推送的接驾车辆的车辆信息及其位置信息。例如，当用户预计等待派车时长达到后或者为用户寻找到了至少一位拼友后，在客户端上显示接驾车辆的车牌号、车型、颜色等，以及接驾车辆到所述出发地的路径信息、地图信息等等。

图5是根据本发明的一些实施例所示的一种拼车信息提示装置的功能框图。

拼车信息提示装置500可以由乘客端130(或客户端)实现。为描述方便，拼车信息提示装置500也可以称为拼车信息提示系统。

拼车信息提示装置500可以包括获取模块510、传输模块520、接收模块530和显示模块540。

获取模块510，用于获取用户的拼车请求。

传输模块520，用于将所述拼车请求发送给服务器。

接收模块530，用于接收服务器的信息。

显示模块540，用于显示并动态更新服务器推送的所述拼车请求的进程信息以及为用户寻找拼友的状态信息。所述拼车请求的进程信息至少反映用户预计等待时长。

在一些实施例中，所述状态信息至少包括为所述用户确定的至少一名候选拼友的标识信息以及所述候选拼友的匹配度；所述匹配度至少反映候选拼友与所述用户的顺路程度。

在一些实施例中，所述用户预计等待时长包括和用户预计等待派车的时长、用户预计等待发车的时长和/或用户预计等待司机到达所述出发地的时长等等。

在一些实施例中，所述显示模块540还用于以倒计时的方式显示所述进程信息。

在一些实施例中，所述显示模块540还用于显示服务器推送的接驾车辆的车辆信息及其位置信息。

在一些实施例中，拼车信息提示装置500可以包括至少一个处理器以及至少一个存储器；所述至少一个存储器用于存储计算机指令；所述至少一个处理器用于执行所述计算机指令中的至少部分指令以实现如图4所述的拼车信息提示方法。

在一些实施例中，本发明涉及一种计算机可读存储介质，所述存储介质存储计算机指令，当所述计算机指令被处理器执行时实现如图4所述的拼车信息提示方法。

需要说明的是，上述各个模块可以是通过计算机指令实现的软件模块。

图6是根据本发明的一些实施例所示的另一种拼车信息提示方法600的流程示意图。

拼车信息提示方法600可以由服务器110实现。

步骤601，获取用户的拼车请求。

服务器110可以通过网络120获取乘客端130发送的用户的拼车请求。拼车请求可以包括但不限于出发地、目的地、发出拼车请求的时间、发出拼车请求时的位置等。

步骤602，为所述用户寻找至少一位拼友。

服务器110可以为所述用户寻找至少一位拼友。为用户寻找拼友的方法可以为现有技术中任一种匹配方法，在此不再赘述。例如，服务器110可以确定用户出发地到目的地之间的导航路径与拼友出发地到目的地之间的导航路径重合度来确定用户与拼友的顺路程度，进而将顺路程度大于设定值，例如90％，的候选拼友作为所述用户的拼友。

步骤603，将所述拼车请求的进程信息以及为所述用户寻找拼友的状态信息实时发送给客户端。

服务器110可以通过网络120将所述拼车请求的进程信息以及为所述用户寻找拼友的状态信息实时发送给客户端(即乘客端130)。所述拼车请求的进程信息至少反映用户预计等待时长。

在一些实施例中，所述拼车请求的进程信息至少反映用户预计等待时长。所述用户预计等待时长包括用户预计等待派车时长和/或用户预计等待发车时长等。关于拼车请求进程信息可以参见图4相关说明中的详细阐述。

在一些实施例中，用户预计等待发车时长可以为固定时长，例如6分钟；或者，根据所述拼车请求中的出发地确定相应的用户预计等待发车时长。关于根据出发地确定用户预计等待发车时长的更多内容可以参见图8相关说明中的详细阐述。

在一些实施例中，用户预计等待派车时长为固定时长，如1分钟；或者，用户预计等待派车时长至少与以下信息中的至少一个相关：所述拼车请求中的出发地的供需比，或用户发出拼车请求的位置与拼车请求中的出发地之间的距离。其中，出发地的供需比为出发地一定范围区域内的当前可用车辆数目除以该区域内的当前拼车订单数目。例如，严重缺少可用车辆时，用户预计等待派车时长更长；可用车辆较少时，用户预计等待派车时长为1分钟；供需比较大，可用车辆较多时，用户预计等待派车时长为2分钟；对于供需比很大的冷门区域，用户预计等待派车时长为30秒。在另一些实施例中，当用户发出拼车请求的位置到出发地的距离越长，因为用户到达出发地需要花费更多的时间，因此用户预计得到派车时长可以适当延长。

服务器110可以根据寻找拼友的情况、接驾车辆的位置、路况信息等定期或不定期的更新拼车请求的进程信息，并推送到所述用户的客户端。例如，服务器110可以根据上述情形对用户预计等待派车时长和/或用户预计等待发车时长进行调整，如延长或缩短，并即时发送给客户端显示。仅作为示例，当接驾司机前往拼车请求的出发地途中突发了交通事故，服务器110可以将预计用户等待发车时长由原来的5分钟延长至7分钟。又例如，服务器110并未调整预先确定的用户预计等待派车时长和/或用户预计等待发车时长，只是将这两种时长的倒计时剩余时长实时发送给客户端显示。

在一些实施例中，所述状态信息可以是已经为所述用户匹配候选拼友的次数，已经发现的候选拼友人数，候选拼友的标识信息以及所述候选拼友的匹配度等。所述匹配度至少反映候选拼友与所述用户的顺路程度。其中，标识信息可以为候选拼友注册的头像或者id信息。例如，乘客端130的界面可以显示候选拼友注册的头像以及该候选拼友与用户的顺路程度(例如，顺路程度为55％)。

服务器110将在为用户寻找拼友时筛选拼友的过程发送给客户端显示。可以理解为，首先，服务器110为从其他拼车请求中确定其他用户与所述用户的匹配度，将匹配度大于设定阈值，如70％以上，的其他用户作为所述用户的候选拼友。将候选拼友的信息发送给所述用户的客户端，之后服务器110继续寻找候选拼友，并将匹配度更高的候选拼友信息推送给客户端，以此类推，直到确定一位最终的拼友，并将拼友的信息推送给客户端。例如，服务器110为用户寻找到一位候选友a，将候选拼友a的头像信息(可以从服务器数据库中调取)、位置信息(可以通过该拼友的客户端获取)、匹配度75％推送给所述用户的客户端，下一时刻服务器110为用户寻找到了另一位候选拼友b，并将候选拼友b的头像信息、位置信息以及匹配度82％推送给客户端，再下一时刻服务器110将候选拼友c的头像信息、位置信息以及匹配度95％推送给所述用户客户端等。直到拼友确定后，服务器110将最终确定的拼友信息推送到所述用户客户端，并停止寻找拼友。

在一些实施例中，所述为所述用户寻找至少一位拼友包括：在所述用户预计等待发车时长内为所述用户寻找至少一位拼友。可以理解为，将所述用户预计等待发车时长作为服务器为用户寻找拼友的最大时长。例如，当接驾车辆到达出发地并接上所述用户后，服务器110还未找到合适的拼友，接驾车辆不会发车，此时服务器110还可以继续为所述用户寻找拼友。若用户预计等待发车时长已经到达，即使服务器110还未找到拼友，接驾车辆则可以出发，无需等待了。

在一些实施例中，所述拼车信息提示方法600，还包括：

步骤604，在达到用户预计等待派车时长前，为所述用户寻找到至少一位拼友后为所述用户确定接驾车辆；或者，在达到用户预计等待派车时长后，为所述用户确定接驾车辆。

可以理解为，如果服务器未能找到合适的拼友，而时间还未达到用户预计等待派车时长，服务器110不会进行派车，而是继续为用户寻找拼友。

在一些实施例中，在达到用户预计等待派车时长前，服务器110就成功为所述用户寻找到至少一位拼友。此时，服务器110可以为所述用户以及拼友组成的行程确定接驾车辆。

在一些实施例中，如果用户预计等待时长达到后服务器110仍未找到合适的拼友，则立即为所述用户确定接驾车辆。

为用户指派接驾车辆的方法可以使用现有技术中任意一种派车方法，在此不再赘述其详细过程。步骤605，将所述接驾车辆的车辆信息及位置信息发送给所述客户端。

服务器110可以通过网络120将所述接驾车辆的车辆信息及位置信息发送给所述客户端。在一些实施例中，所述拼车信息提示方法600，还包括：

步骤606，获取接驾车辆位置信息。

服务器110可以通过网络120获取接驾车辆的位置信息。

步骤607，当确定接驾车辆到达拼车请求中的出发地后，满足一下任意条件时，向司机终端发出发车指令：用户预计等待发车时长到达，或为所述用户寻找到至少一位拼友。

在一些实施例中，接驾车辆到达拼车请求中的出发地后，且用户预计等待发车时长已到达，服务器110将向司机终端(即司机端140)发出发车指令。

在一些实施例中，接驾车辆到达拼车请求中的出发地后，且为所述用户寻找到至少一位拼友，服务器110将向司机终端(即司机端140)发出发车指令。

图7是根据本发明的一些实施例所示的另一种拼车信息提示装置的功能框图。

拼车信息提示装置700可以由服务器110实现。为描述方便，拼车信息提示装置700也可以称为拼车信息提示系统。

拼车信息提示装置700可以包括获取模块710、拼友匹配模块720和传输模块730。

获取模块710，用于获取用户的拼车请求。

拼友匹配模块720，用于为所述用户寻找至少一位拼友。

传输模块730，用于将所述拼车请求的进程信息以及为所述用户寻找拼友的状态信息实时发送给客户端。所述拼车请求的进程信息至少反映用户预计等待时长。

在一些实施例中，所述状态信息至少包括为所述用户确定的至少一名候选拼友的标识信息以及所述候选拼友的匹配度；所述匹配度至少反映候选拼友与所述用户的顺路程度。

在一些实施例中，所述用户预计等待时长包括用户预计等待派车时长和/或用户预计等待发车时长。

在一些实施例中，拼友匹配模块720还用于在所述用户预计等待发车时长内为所述用户寻找至少一位拼友。

在一些实施例中，拼车信息提示装置700还包括派车模块，用于在达到用户预计等待派车时长前，为所述用户寻找到至少一位拼友后为所述用户确定接驾车辆；或者，在达到用户预计等待派车时长后，为所述乘客确定接驾车辆。所述传输模块730还用于将所述接驾车辆的车辆信息及位置信息发送给所述客户端。

在一些实施例中，拼车信息提示装置700还还包括发车控制模块；所述获取模块710用于获取接驾车辆位置信息；所述发车控制模块用于当确定接驾车辆到达拼车请求中的出发地后，满足一下任意条件时，向司机终端发出发车指令：用户预计等待发车时长到达，或为所述用户寻找到至少一位拼友。

在一些实施例中，用户预计等待发车时长为固定时长；或者，用户预计等待发车时长与所述拼车请求中的出发地相关。

在一些实施例中，用户预计等待派车时长为固定时长；或者，用户预计等待派车时长至少与以下信息中的至少一个相关：所述拼车请求中的出发地的供需比，或用户发出拼车请求的位置与拼车请求中的出发地之间的距离；出发地的供需比为出发地一定范围区域内的当前可用车辆数目除以该区域内的当前拼车订单数目。

在一些实施例中，拼车信息提示装置700可以包括至少一个处理器以及至少一个存储器；所述至少一个存储器用于存储计算机指令；所述至少一个处理器用于执行所述计算机指令中的至少部分指令以实现如图6所述的拼车信息提示方法。

在一些实施例中，本发明涉及一种计算机可读存储介质，所述存储介质存储计算机指令，当所述计算机指令被处理器执行时实现如图6所述的拼车信息提示方法。

需要说明的是，上述各个模块可以是通过计算机指令实现的软件模块。

用户预计等待发车时长可以是固定的(例如，6分钟)，也可以视拼车请求的具体情况确定该时长。

图8是根据本发明的一些实施例所示的一种确定用户的预计等待发车时长的方法800的流程示意图。

确定用户的预计等待发车时长的方法800可以由服务器110实现。

步骤801，获取用户的拼车请求。

服务器110可以通过网络120获取乘客端130发送的用户的拼车请求。拼车请求可以包括但不限于出发地、目的地、发出拼车请求的时间、发出拼车请求时的位置等。

步骤802，基于拼车请求中的出发地确定用户的预计等待发车时长。其中，用户预计等待发车时长为服务器寻找用户拼友的最大时长。

针对于步骤802，基于拼车请求中的出发地确定用户的预计等待发车时长，本发明实施例提供了两种实现方法。

第一种实现方法包括：

步骤s11，确定所述出发地所属的区域。

具体地，服务器110可以预先将城市划分为不同的区域。以北京市为例，北京市可以被划分为海淀区、昌平区、顺义区等。又例如，可以按交通方式将北京市划分为地铁区域、火车站区域、飞机场区域和汽车站区域等。

服务器110在确定出用户的出发地后，可以进一步确定出用户的出发地所属的区域。

需要注意的是，以上关于将北京市划分为不同区域的描述，仅作为示例说明和描述方便，并不能把本申请限制在所举实施例范围之内。诸如此类的将城市划分为不同区域的方法，均在本申请的保护范围之内。

步骤s12，基于所述区域，确定所述用户预计等待发车时长。

具体地，不同的区域预先设定不同的预计等待发车时长。服务器110预先设置不同的区域对应各自的预计等待发车时长。

以北京市为例，北京市被划分为海淀区、昌平区、顺义区等。海淀区对应的预计等待发车时长为6分钟、昌平区对应的预计等待发车时长为5分钟、顺义区对应的预计等待发车时长对应7分钟等。当所述用户的出发地为中关村地铁站时，服务器110可以确定出所述用户的出发地属于海淀区。进一步地，服务器110可以确定所述用户的出发地所属的海淀区对应的预计等待发车时长为6分钟。

又例如，按交通方式将北京市划分为地铁区域、火车站区域、飞机场区域和汽车站区域等。地铁区域对应的预计等待发车时长为6分钟、火车站区域对应的预计等待发车时长为9分钟、飞机场区域对应的预计等待发车时长为15分钟和汽车站区域对应的预计等待发车时长为10分钟。当所述用户的出发地为北京火车站时，服务器110可以确定出所述用户的出发地属于火车站区域。进一步地，服务器110可以确定所述用户的出发地所属的火车站区域对应的预计等待发车时长为9分钟。

第二种实现方法包括：

步骤s21，确定所述出发地的途径率、拼成率、供需比和应答率。

其中，出发地的途径率(p1)为出发地一定范围区域内发出的历史拼车订单中途经所述出发地的订单数目(m2)除以出发地一定范围区域内发出的历史拼车订单数目(m1)，即p1＝m2/m1；出发地的拼成率(p2)为以所述出发地作为出发地的历史拼车订单中拼车成功的拼车订单数目(n2)除以所述历史拼车订单的总数(n1)，即p2＝n2/n1；出发地的供需比(p3)为出发地一定范围区域内的当前可用车辆数目(c2)除以该区域内的当前拼车订单数目(c1)，即p3＝c2/c1；出发地的应答率(p4)为以所述出发地作为出发地的历史拼车订单中被接受订单的数目(d1)除以所述历史拼车订单的总数(n1)，即p4＝d1/n1。

步骤s22，确定用户发出拼车请求时的位置到所述出发地的距离。

具体地，乘客端130(例如，移动终端130-4)可以通过内置的gps装置确定出所述用户发出拼车请求时的位置。服务器110可以通过网络120获取所述用户发出拼车请求时的位置。进一步地，服务器110可以确定出所述用户发出拼车请求时的位置到所述出发地的距离(p5)。

步骤s23，基于所述途径率、拼成率、供需比、应答率和距离中的至少一个信息，计算用户预计等待发车时长。

在一些实施例中，可以采用机器学习的方法，将历史数据中不同地点的上述信息以及历史数据中这些地点的拼车时等待发车或者寻找拼友的时长作为训练数据对机器模型进行训练，训练好的模型可以根据当前拼车请求中的出发地的相关信息精确计算出用户预计等待发车时长。

在另一些实施例中，服务器110可以基于所述途径率、拼成率和距离计算用户预计等待发车时长。例如，途径率、拼成率和所述用户发出拼车请求时的位置到所述出发地的距离，可以对应不同的权重。途径率(p1)对应的权重为w1、拼成率(p2)对应的权重为w2和所述用户发出拼车请求时的位置到所述出发地的距离(p5)对应的权重为w3。所述用户预计等待发车时长可以通过如下公式计算：

用户预计等待发车时长＝p1*w1+p2*w2+p5*w3(1)

当途径率(p1)、拼成率(p2)或所述用户发出拼车请求时的位置到所述出发地的距离(p5)越大时，所述用户预计等待发车时长将越长。例如，当所述用户发出拼车请求时的位置到所述出发地的距离(p5)越大时，用户到达所述出发地花费的时间将越长，所述用户预计等待发车时长将越长，从而更容易拼车成功。

在一些实施例中，服务器110可以基于供需比和应答率计算用户预计等待发车时长。例如，服务器110可以预先将拼车场景划分为不同的场景类型。例如，基于供需比和应答率，服务器110将拼车场景划分供需失衡场景、高热场景、低热场景和冷门场景等其他场景类型。

当供需比和应答率同时满足条件1时，拼车场景为供需失衡场景。例如，当供需比小于第一阈值且应答率小于第二阈值时，拼车场景为供需失衡场景。

当供需比和应答率同时满足条件2时，拼车场景为高热场景。例如，当供需比超过第一阈值小于第三阈值且应答率超过第二阈值小于第四阈值时，拼车场景为高热场景。

当供需比和应答率同时满足条件3时，拼车场景为低热场景。例如，当供需比超过第三阈值小于第五阈值且应答率超过第四阈值小于第六阈值时，拼车场景为低热场景。

当供需比和应答率同时满足条件4时，拼车场景为冷门场景。例如，当供需比超过第五阈值小于第七阈值且应答率超过第六阈值小于第八阈值时，拼车场景为冷门场景。

当供需比和应答率同时不满足条件1到4时，拼车场景为其他场景。

在一些实施例中，所述第一阈值、第三阈值、第五阈值和第七阈值逐渐增大，所述第二阈值、第四阈值、第六阈值和第八阈值逐渐增大。

不同的拼车场景类型对应各自的预计等待发车时长。例如，供需失衡场景对应的预计等待发车时长为t1分钟、高热场景对应的预计等待发车时长为t2分钟、低热场景对应的预计等待发车时长为t3分钟和冷门场景对应的预计等待发车时长为t4分钟和其他场景类型对应的预计等待发车时长为t5分钟。

当所述出发地的供需比(p3)和所述出发地的应答率(p4)满足相应的条件时，服务器110可以确定所述出发地所属的拼车场景类型。

进一步地，基于所述出发地所属的拼车场景类型，确定所述用户预计等待发车时长。

具体地，基于所述出发地所属的拼车场景类型，服务器110可以确定所述出发地所属的拼车场景类型对应的预计等待发车时长。例如，当所述出发地所属的拼车场景类型为低热场景时，所述用户预计等待发车时长为t3分钟。

需要注意的是，以上关于将拼车场景划分为不同类型的描述，仅作为示例说明和描述方便，并不能把本申请限制在所举实施例范围之内。诸如此类的将拼车场景划分为不同类型的方法，均在本申请的保护范围之内。

图9是根据本发明的一些实施例所示的一种确定用户的预计等待发车时长装置的功能框图。

确定用户的预计等待发车时长装置900可以由服务器110实现。为描述方便，确定用户的预计等待发车时长装置900也可以称为确定用户的预计等待发车时长的系统。

确定用户的预计等待发车时长装置900可以包括获取模块910和确定模块920。

获取模块910，用于获取用户的拼车请求。

确定模块920，用于基于拼车请求中的出发地确定用户的预计等待发车时长。用户预计等待发车时长为服务器110寻找用户拼友的最大时长。

在一些实施例中，所述确定模块910还用于：确定所述出发地所属的区域；基于所述区域，确定所述用户预计等待发车时长。

在一些实施例中，所述确定模块还用于：确定所述出发地的途径率、拼成率、供需比和应答率；确定用户发出拼车请求时的位置到所述出发地的距离；基于所述途径率、拼成率、供需比、应答率和距离中的至少一个信息，计算用户预计等待发车时长。其中，出发地的途径率为出发地一定范围区域内发出的历史拼车订单中途经所述出发地的订单数目除以出发地一定范围区域内发出的历史拼车订单数目；出发地的拼成率为以所述出发地作为出发地的历史拼车订单中拼车成功的拼车订单数目除以所述历史拼车订单的总数；出发地的供需比为出发地一定范围区域内的当前可用车辆数目除以该区域内的当前拼车订单数目；出发地的应答率为以所述出发地作为出发地的历史拼车订单中被接受订单的数目除以所述历史拼车订单的总数。

在一些实施例中，确定用户的预计等待发车时长装置900可以包括至少一个处理器以及至少一个存储器；所述至少一个存储器用于存储计算机指令；所述至少一个处理器用于执行所述计算机指令中的至少部分指令以实现如图8所述的拼车信息提示方法。

在一些实施例中，本发明涉及一种计算机可读存储介质，所述存储介质存储计算机指令，当所述计算机指令被处理器执行时实现如图8所述的拼车信息提示方法。

需要说明的是，上述各个模块可以是通过计算机指令实现的软件模块。

上文所描述的各个模块和单元并不是必须的，对于本领域的专业人员来说，在了解本申请内容和原理后，都可能在不背离本技术原理、结构的情况下，对该系统进行形式和细节上的各种修正和改变，各个模块可以任意组合，或者构成子系统与其它模块连接，而这些修正和改变仍在本申请的权利要求保护范围之内。

本申请实施例可能带来的有益效果包括但不限于：用户可以及时了解到拼车的进程信息以及拼车的状态信息，使用户能够更加耐心地等待接驾车辆，避免用户取消拼车请求。需要说明的是，不同实施例可能产生的有益效果不同，在不同的实施例里，可能产生的有益效果可以是以上任意一种或几种的组合，也可以是其他任何可能获得的有益效果。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。