一种网约车的制作方法

本发明涉及网约车技术领域，具体涉及一种网约车。

背景技术：

目前，随着互联网技术的不断发展，网约车越来越受到人们的欢迎。当乘客需要打车时，可以通过打车软件选择用车时间、希望乘坐的车型、上车地点以及下车地点等信息，并将信息提交给系统平台，在系统平台形成一个订单，发布给在系统平台注册的司机用户，通常司机用户通过司机端与网约车相互绑定，由司机在司机端进行筛选订单，并进行接单操作，在一定程度上方便人们的出行。

但是，在实现本发明过程中，发明人发现现有技术中至少存在以下问题：对于用户的长途出行等有别于一般市内交通的需求，现有网约车并没有将其与一般的打车需求做出区别，服务以及服务的管理也就没有针对性，致使用户体验下降。

技术实现要素：

本发明的目的是提供一种网约车，解决了长途出行类有别于一般市内交通的出行需求的订单没有被区别对待，进而带来用户体验的下降的技术问题。

该网约车内搭载有约车服务系统，约车服务系统包括：

与所述网约车绑定的司机端，用于将所述网约车在控制中心进行注册，并接受控制中心发来的订单；

控制中心，与司机端通过无线通信网络相连接，用于将订单发送至司机端；

所述控制中心包括，

订单获取模块，用于获取用户的订单，所述订单包含有既定路线信息；

存储有司机端注册信息的订单匹配模块，用于根据该既定路线信息，匹配在册司机端中标注有该既定路线信息的司机端；

订单发送模块，用于向匹配到的司机端中的一个或多个发送该订单。

进一步，所述订单还包含有出发时间信息、乘车人数信息和上下车地点信息。

进一步，所述订单还包含有服务类型信息。

进一步，所述订单匹配模块还用于，根据该服务类型信息，在根据所述既定路线信息匹配到司机端中，再次匹配标注有可提供该类服务类型的司机端。

进一步，所述服务类型信息中的服务类型包括：不可拼乘型。

进一步，所述服务类型信息中的服务类型包括：可拼乘站点上车型。

进一步，所述服务类型信息中的服务类型包括：可拼乘非站点上车型。

进一步，所述订单发送模块用于，当所述服务类型信息中的服务类型为可拼乘站点上车型时，将所有匹配到的司机端排列为队列，采用以下策略发送该订单给司机端：

优先发给队列中最前一个已经接有与该订单所包含的既定路线信息相同订单的司机端；

如果该订单的乘车人数加上该司机端已接订单的乘车人数总数超过了该司机端所绑定的网约车的乘坐人数上限，则优先发给队列中下一个已经接有与该订单所包含的既定路线信息相同订单的司机端；

如果该订单的出发时间相较于该司机端已经接到的订单中出发时间最早的一个的时间差超过设定预设值的，则优先发给队列中下一个已经接有与该订单所包含的既定路线信息相同订单的司机端；

如果队列中不再有已经接有与该订单所包含的既定路线信息相同订单的司机端，则发送给队列最前端的司机端；

当队列中有司机端所接订单的乘坐人数总和等于该司机端所绑定的网约车的乘坐人数上限，或者当前时间距离所接订单中最早的出发时间少于预设时间阈值时，将该司机端从队列中剔除。

据权利要求7所述的网约车，其特征在于：所述订单发送模块用于，当所述服务类型信息中的服务类型为可拼乘非站点上车型时，将所有匹配到的司机端中接有订单的司机端按照其最晚的订单接单时间排列为等待序列，采用以下策略发送该订单给司机端；

优先发给等待序列中最前一个已经接有与该订单所包含的既定路线信息相同订单的司机端；

如果该订单的乘车人数加上该司机端已接订单的乘车人数总数超过了该司机端所绑定的网约车的乘坐人数上限，则优先发给等待序列中下一个已经接有与该订单所包含的既定路线信息相同订单的司机端；

如果该订单的出发时间相较于该司机端已经接到的订单中出发时间最早的一个的时间差超过设定预设值的，则优先发给等待序列中下一个已经接有与该订单所包含的既定路线信息相同订单的司机端；

如果等待序列中不再有已经接有与该订单所包含的既定路线信息相同订单的司机端，向匹配到的所有未接单的司机端发送该订单的抢单信息；

当得知有司机端抢到该订单并接单时，将该司机端标记为已接单司机端，得知时间为接单时间；

当队列中有司机端所接订单的乘坐人数总和等于该司机端所绑定的网约车的乘坐人数上限，或者所接订单总数达到最大订单数阈值，或者当前时间距离所接订单中最早的出发时间少于预设时间阈值时，将该司机端从队列中剔除。

进一步，所述司机端还包括路线显示模块，用于根据订单中的上下车地点信息获取并显示行驶路线。

综上所述，本发明利用订单携带既定路线信息来定向订单的分配和接受，无需复杂的算法即可实现，网约车与既定路线间存在对应关系，服务的提供和管理更有针对性，方便了司机接受定向的订单，此类订单被定向后，也减少了被拒绝接单的概率，服务供求双方更容易达成共识，大大提高了满载拼乘的概率，对于司机和用户均有益。

附图说明

图1为本发明实施例的逻辑框图。

图2为本图1中的控制中心的逻辑框图。

具体实施方式

下面通过具体实施方式进一步详细说明：

如图1所示，本实施网约车内搭载有约车服务系统，约车服务系统包括：

与所述网约车绑定的司机端，用于将所述网约车在控制中心进行注册，并接受控制中心发来的订单；

控制中心，与司机端通过无线通信网络相连接，用于将订单发送至司机端。

本领域技术人员应当理解，本发明实施例中提及的司机端是提供服务方，即约车服务中的司机，所使用的移动终端或个人计算机等设备。例如智能手机、个人数码助理(pda)、平板电脑、笔记本电脑、车载电脑(carputer)、掌上游戏机、智能眼镜、智能手表、可穿戴设备、虚拟显示设备或显示增强设备(如googleglass、oculusrift、hololens、gearvr)等。

如图2所示，图1中的控制中心包括:

订单获取模块，用于获取用户的订单，所述订单包含有既定路线信息；

存储有司机端注册信息的订单匹配模块，用于根据该既定路线信息，匹配在册司机端中标注有该既定路线信息的司机端；

订单发送模块，用于向匹配到的司机端中的一个或多个发送该订单。

在实际应用中，用户通过打车软件发送约车请求信息，请求约车服务。因此，可将乘车出发地和乘车目的地置于约车请求信息中，以供约车系统通过解析所述约车请求，实现从约车请求信息中获取用户的乘车出发地和乘车目的地。

本发明实施例中，当用户开启约车程序后，首先通过预定的操作发送约车请求信息，其中，约车请求信息中包括但不限于乘车出发地和乘车目的地等信息。约车系统通过接收用户设备发送的约车请求信息，以获取用户本次出行的乘车出发地和乘车目的地，以供后续订单的生成。

在本发明中的既定路线信息指向一路线出发地和路线目的地间的始终关系，并不会指向特定的行驶路线，所以路线出发地和路线目的地指向地理上的某个区域，区域的划分可以是约定俗成的，也可以是行政上划分的行政区域或行政区域的集合；

例如：乘车出发地所属行政区为a市-b县/区，乘车目的地所属行政区为c市-d县/区，同一市中的不同的区/县间也可存在既定路线；另外由于主城区间距离近且交通方便，可以将主城区内的区级行政区合并为一个或多个片区，即存在a市主城区/a市f片区-d县/区这样的既定路线。

本发明中的既定路线信息，可以由用户手动输入，也可以利用地理信息服务系统获取乘车出发地和乘车目的地各自所属的行政区来实现，还可以是其他本领域技术人员所熟知的技术手段，在此不做赘述。通过设订单的既定路线信息，有别于市内交通的其他约车服务需求，特别是长途出行约车需求，可以得到快速识别，从而给予针对性的分配，从而快速匹配服务，后台也可以通过添加删除和修改既定路线来控制和管理订单中的特定路线信息。

进一步的实施例中，所述订单还包含有出发时间信息、乘车人数信息和上下车地点信息。

进一步的实施例中，所述订单还包含有服务类型信息，所述服务类型信息中的服务类型包括：不可拼乘型、可拼乘站点上车型及可拼乘非站点上车型中的一种或多种；

订单匹配模块还用于，根据该服务类型信息，在根据所述既定路线信息匹配到司机端中，再次匹配标注有可提供该类服务类型的司机端。

订单发送模块，用于向匹配到的司机端中的一个或多个发送该订单。

既定路线信息、提供何类服务类型这些信息的标注，可以在司机端注册时，即网约车绑定司机端时完成，也可以是注册后由系统后台进行标注，同一司机端可以被标注有多个既定路线信息，或是被标注为适合所有的既定路线，这等同于被标注了所有的既定路线信息，自然的，后期也可以对这些标注进行删除、增加和修改。

在一具体的实施例中，所述订单发送模块用于，当所述服务类型信息中的服务类型为可拼乘站点上车型时，将所有匹配到的司机端排列为队列，采用以下策略发送该订单给司机端：

优先发给队列中最前一个已经接有与该订单所包含的既定路线信息相同订单的司机端；

如果该订单的乘车人数加上该司机端已接订单的乘车人数总数超过了该司机端所绑定的网约车的乘坐人数上限，则优先发给队列中下一个已经接有与该订单所包含的既定路线信息相同订单的司机端；

如果该订单的出发时间相较于该司机端已经接到的订单中出发时间最早的一个的时间差超过设定预设值的，则优先发给队列中下一个已经接有与该订单所包含的既定路线信息相同订单的司机端；

如果队列中不再有已经接有与该订单所包含的既定路线信息相同订单的司机端，则发送给队列最前端的司机端；

当队列中有司机端所接订单的乘坐人数总和等于该司机端所绑定的网约车的乘坐人数上限，或者当前时间距离所接订单中最早的出发时间少于预设时间阈值时，将该司机端从队列中剔除。

在该实施例中，所述订单发送模块还用于，当所述服务类型信息中的服务类型为可拼乘非站点上车型时，将所有匹配到的司机端中接有订单的司机端按照其最晚的订单接单时间排列为等待序列，采用以下策略发送该订单给司机端；

优先发给等待序列中最前一个已经接有与该订单所包含的既定路线信息相同订单的司机端；

如果该订单的乘车人数加上该司机端已接订单的乘车人数总数超过了该司机端所绑定的网约车的乘坐人数上限，则优先发给等待序列中下一个已经接有与该订单所包含的既定路线信息相同订单的司机端；

如果该订单的出发时间相较于该司机端已经接到的订单中出发时间最早的一个的时间差超过设定预设值的，则优先发给等待序列中下一个已经接有与该订单所包含的既定路线信息相同订单的司机端；

如果等待序列中不再有已经接有与该订单所包含的既定路线信息相同订单的司机端，向匹配到的所有未接单的司机端发送该订单的抢单信息；

当得知有司机端抢到该订单并接单时，将该司机端标记为已接单司机端，得知时间为接单时间；

当等待序列中有司机端所接订单的乘坐人数总和等于该司机端所绑定的网约车的乘坐人数上限，或者所接订单总数达到最大订单数阈值，或者当前时间距离所接订单中最早的出发时间少于预设时间阈值时，将该司机端从等待序列中剔除。

本实施例中，利用既定路线来组织长途拼乘，对于愿意承接此类订单的司机来说，接单率很高，所以提高了司机端资源的利用率，在保证收益的同时，可以降低消费者的支出。为了更好的降低运输成本，通过利用站点上车的方式使得司机和乘客快速达成共识，使得司机更容易接送乘客，减少在接送时由于上的车点不易找到或定位/输入有误的情况，由此带来的成本降低，相应的可以降低用户的支出。还可以分配空间较大的车型来完成此类订单，通过增加拼乘人数/单数来分担成本，进一步降低用户的支出，用户也相应的会损失乘坐的舒适性和接送的实时性作为代价。由此，本实施例通过服务类型区分开费用支出等级、失乘坐的舒适性和接送的实时性，不可拼乘型具有最高的费用支出、乘坐的舒适性和接送的实时性；可拼乘非站点上车型次之，于是拼乘人数/单数较可拼乘站点上车型更少，例如用采用5座的轿车提供服务，拼乘的订单数不超过两单，上车地点由乘客指定不需要是推荐的乘车站点；可拼乘非站点上车型，采用7座以上的车型提供服务，拼乘的订单数不限，当然总人数不可超过乘坐上限，上车地点必须是乘车站点。利用时间阈值，可以避免同一司机端所接的订单的出发时间相隔过久，可以设定阈值的为例如一小时，避免过多耽误用户的时间；还可以限制订单的最早出发时间使得从发出约车请求到出发前有着足够的时间促成拼乘，对于具有长途出行需求的用户来说，提前较多的时间约车普遍是可以接受的。实际中，针对不同既定路线的用户需求量等实际情况，可以选择性的开通上述服务类型中的一种或多种。

在进一步的实施例中，所述司机端还包括路线显示模块，用于根据订单中的上下车地点信息获取并显示行驶路线。

在司机端获取订单后，随即获得了一个或多个用户的上下车地点信息，利用该信息，采取现有的导航技术，便可以规划出可以途径所有用户的上下车地点的行驶路线，现有的导航技术由各导航/地图服务平台提供，如腾讯地图、高德地图等，司机端的路线显示模块在发出请求后，即可接入这些服务，并获取和现实这些服务所规划出的行驶路线，本实施例通过直接请求这样的服务，无需司机输入各上下车地点信息，使得司机的出行更加便捷。

可理解的是，上述服务类型仅用于对本发明实施例进行解释说明，并非对本发明技术方案的限定，而且后续还可增加更多出行方式对应的服务类型，本发明对此不作具体限定。

值得注意的是，本发明实施例中提到的绑定、打车软件、抢单，发送订单、司机端当前订单情况的获知、司机端当前订单状态的改变等技术名词或技术手段均为网约车领域中被人所熟知的内容，在此也不做赘述。

综上所述，本发明利用订单携带既定路线信息来定向订单的分配和接受，无需复杂的算法即可实现，网约车与既定路线间存在对应关系，服务的提供和管理更有针对性，方便了司机接受定向的订单，此类订单被定向后，也减少了被拒绝接单的概率，服务供求双方更容易达成共识，大大提高了满载拼乘的概率，对于司机和用户均有益。

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

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

本实施例中所描述的过程和逻辑流可以由执行一个或多个计算机程序的一个或多个可编程处理器来执行以通过操作输入数据并且生成输出来执行功能。该过程和逻辑流也可以由专用逻辑电路来执行，并且装置也可以实现为该专用逻辑电路，该专用逻辑电路例如为fpga(现场可编程门阵列)或者asic(专用集成电路)。适合执行计算机程序的处理器包括例如通用和专用微处理器二者、以及任何种类的数字计算机的任何一个或多个处理器。通常，处理器从只读存储器或者随机存取存储器或者二者接收指令和数据。计算机的元件可以包括用于执行指令的处理器以及用于存储指令和数据的一个或多个存储器设备。通常，计算机还将包括一个或多个海量存储设备以便存储数据，或者该计算机在操作上耦合以从海量存储设备接收或向海量存储设备传送数据或者二者，该海量存储设备例如是磁盘、磁光盘或者光盘。然而，计算机不需要具有这样的设备。此外，计算机可以嵌入在另一设备中，该另一设备例如为移动电话、个人数字助理(pda)、移动音频播放器、全球定位系统(gps)接收器等。适合存储计算机程序指令和数据的计算机可读介质包括所有形式的非易失性存储器、介质和存储器设备，包括例如：半导体存储器设备，如eprom、eeprom和闪存设备；磁盘，如内置硬盘或可移除盘；磁光盘；以及cdrom和dvd-rom盘。该处理器和存储器可以用专用逻辑电路来补充或者并入该专用逻辑电路中。

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

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

类似地，虽然在附图中按照特定顺序来描绘操作，然而这不应当被理解为要求这样的操作按照所示的特定顺序或者按照相继顺序来执行，或者要求所有图示操作都被执行，以实现期望的结果。在一些境况下，多任务和并行处理可能是有利的。此外，以上描述的实现中的各种系统部件的分离不应当被理解为在所有实现中都要求这样的分离，而且应当理解，所描述的程序部件和系统通常可以在单个软件产品中集成在一起或者被封装成多个软件产品。

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