CN108009656B - 网约车订单处理方法、系统、终端及服务器 - Google Patents

Abstract

本发明提出了一种网约车订单处理方法、系统、终端及服务器，其中，网约车订单处理方法，包括：接收乘客终端发送的订单信号；根据订单信号对应的第一车型信息和路线信息，判断对应于第一车型信息和路线信息的第一应答时间是否不小于预设时长，生成第一判断结果；在第一判断结果为是时，在车型集合中确定至少一种备选车型；确定每种备选车型对应于路线信息的第二应答时间；在所有备选车型中确定第二应答时间小于预设时长的至少一种推荐车型；向乘客终端发送对应于至少一个推荐车型的推荐信号。通过本发明的技术方案，可以在众多业务线中将更快的出行路线推荐给乘客，即通过上述技术方案，向乘客提供了更快的出行路线作为参考，节省了乘客的出行时间，为乘客的出行提供了方便。

Description

网约车订单处理方法、系统、终端及服务器

技术领域

本发明涉及网约车应用领域，具体而言，涉及一种网约车订单处理方法、一种网约车订单处理系统、一种计算机设备、一种计算机可读存储介质、一种终端以及一种服务器。

背景技术

目前，随着交通的便利，网约车出行已经成为人们常有的出行方式，而网约车的方式也从以前单一的路边网约车演变为通过相关网约车应用APP直接下发订单网约车。现有技术仅是通过乘客下发订单，司机接单来完成本次的出行。然而通过网约车应用实现成功交易，取决于乘客需求和运力供给两部分的匹配情况，在很多场景会出现供小于求的情况，比如早晚高峰、企业下班、极端天气等，此时乘客会遇到网约车难度较大、叫不到车的情况。在供需失衡时，引入排队机制，用户可以有稳定的预期知道自己预计什么时候能触发，然而又可能出现排队的时间过长。此时乘客需要有更多的出口，让其可以更快出行；另一方面，应用平台存在多个业务线，有些业务线的运力可能是富余的状态。因此，在供需失衡时，排队很久时如何可以更快出行，同时在众多业务线中，应该如何选择更快出行的业务线成为本领域技术人员亟待解决的问题。

发明内容

本发明旨在至少解决现有技术或相关技术中存在的技术问题之一。

为此，本发明的一个目的在于提出了一种网约车订单处理方法。

本发明的再一个目的在于提出了一种网约车订单处理方法。

本发明的再一个目的在于提出了一种网约车订单处理系统。

本发明的再一个目的在于提出了一种网约车订单处理系统。

本发明的又一个目的在于提出一种计算机设备。

本发明的又一个目的在于提出一种计算机可读存储介质。

本发明的又一个目的在于提出一种终端。

本发明的又一个目的在于提出一种服务器。

有鉴于此，本发明第一方面的技术方案提出了一种网约车订单处理方法，用于服务器，包括：接收乘客终端发送的订单信号；根据订单信号对应的第一车型信息和路线信息，判断对应于第一车型信息和路线信息的第一应答时间是否不小于预设时长，生成第一判断结果；在第一判断结果为是时，在车型集合中确定至少一种备选车型；确定每种备选车型对应于路线信息的第二应答时间；在所有备选车型中确定第二应答时间小于预设时长的至少一种推荐车型；向乘客终端发送对应于至少一个推荐车型的推荐信号。

在该技术方案中，当服务器接收到终端发送的订单信号，该订单信号中对应有包括但不限于第一车型信息和路线信息。其中，第一车型信息包含但不限于车的载客人数、车辆种类以及车辆品牌；路线信息包括但不限于对乘客的起点地址和终点地址之间进行规划的最近路线，拥堵路线以及经过红灯最多路线。当确定该第一车型信息和路线信息后，服务器比较对应于第一车型信息和路线信息的第一应答时间是否大于等于预设时长。需要说明的是，预设时长可以是通过相关机构调研得到的，也可以是通过相关出行数据得到的。另外需要说明的是，第一应答时间是相对于业务线需要排队的等待时间；因此，则存在第一车型信息和路线信息的第一应答时间大于或等于预设时间的情况，即乘客排队等待时间过长，此时则可以在车型集合中确定一种备选车型。进一步地，在每种备选车型中确定对应于路线信息的第二应答时间。需要说明的是，第二应答时间是路线信息对应于所有备选车型所需等待时间；当其中的一种车型对应的第二应答时间小于预设时长时，则服务器向乘客终端发送对应于至少一个推荐车型的推荐信号。即在供需失衡时，在排队等待时间过长的情况下，在众多业务线中可以将更快的出行路线推荐给乘客，方便了乘客的出行。

在上述技术方案中，优选地，在车型集合中确定至少一种备选车型，具体包括：确定与乘客终端对应的历史订单数据；确定历史订单数据中，每个车型对应的使用率；确定使用率大于使用阈值的至少一种备选车型。

在该技术方案中，通过确定与乘客终端对应的历史订单数据及历史订单中每个车型的使用率，进而选择使用率较高的备选车型。即根据乘客使用偏好确定备选车型，提升用户体验。

在上述技术方案中，优选地，还包括：接收乘客终端发送的订单修改信号；根据订单修改信号，确定与订单修改信号对应的第二车型信息；向与第二车型信息对应的司机终端发送第一派单信号。

在该技术方案中，乘客终端可以实时选择最优的车型及路线，若初始的订单信息有误，则可以及时地修改订单信息，接收到乘客终端发送的订单修改信号之后，根据订单修改信号，服务器确定与订单修改信号对应的第二车型信息，对乘客终端发送的订单车型进行更新，需要说明的是，服务器接收的也可以是乘客终端对订单信号对应的车型信息进行更新之后生成的新订单；服务器确定与订单修改信号对应的第二车型信息；进而向与第二车型信息对应的司机终端发送第一派单信号。即通过上述技术方案，准确为地向乘客提供了更快的出行路线作为参考，节省了乘客的出行时间，为乘客的出行提供了方便。

在上述技术方案中，优选地，还包括：在第一判断结果为否时，向与第一车型信息对应的司机终端发送对应于订单信号的第二派单信号。

在该技术方案中，当第一判断结果为否时，即对应于第一车型信息和路线信息的第一应答时间小于预设时长，说明订单信号对应的排队等待时间在合理范围内，则服务器直接将与第一车型信息对应的司机终端发送对应于订单信号的第二派单信号，实现了为乘客快速匹配出行的车型，进而节省了乘客的出行时间，方便了乘客的出行。

在上述技术方案中，优选地，在根据订单信号对应的车型信息和路线信息，判断对应于第一车型信息和路线信息的第一应答时间是否不小于预设时长，生成第一判断结果之前，还包括：向与第一车型信息对应的司机终端发送对应于订单信号的第三派单信号。

在该技术方案中，服务器在接收到乘客终端发送的订单信号后，根据订单信号对应的第一车型信息发送给与第一车型信息匹配的司机终端进行排队等待接单，在乘客等待接单过程中，对第一应答时间进行判断，为乘客提供更快的出行路线作为参考，有效利用了乘客的排队等待时间，提升了用户体验。

本发明第二方面的技术方案提出了一种网约车订单处理方法，用于乘客终端，包括:接收订单指令；根据订单指令，向服务器发送订单信号；接收服务器发送的推荐信号；根据推荐信号，展示对应于推荐信号的推荐信息。

在该技术方案中，乘客终端接收订单指令，其中，订单指令中包括但不限于输入的起终点，继而根据订单指令，把订单信号发送与服务器；使得服务器准确地接收订单信息，进而选择出最优推荐业务线，并将该最优推荐业务线的信息通过推荐信号发送给乘客终端。即乘客终端接收服务器发送的推荐信号，进而将推荐信号的推荐信息展现与乘客终端。使得乘客可以清晰准确地了解所要出行的推荐业务线，进而方便了乘客的出行。

在上述技术方案中，优选地，还包括：接收订单修改指令；根据订单修改指令，确定订单修改指令对应的第二车型信息；根据第二车型信息生成并向服务器发送订单修改信号。

在该技术方案中，服务器在接收到乘客终端发送的订单信号后，根据订单信号对应的第一车型信息发送给与第一车型信息匹配的司机终端进行排队等待接单，在乘客等待接单过程中，对第一应答时间进行判断，为乘客提供更快的出行路线作为参考，有效利用了乘客的排队等待时间，提升了用户体验。

本发明第三方面的技术方案提出了一种网约车订单处理系统，包括：订单信号接收单元，用于接收乘客终端发送的订单信号；第一判断单元，用于根据订单信号对应的第一车型信息和路线信息，判断对应于第一车型信息和路线信息的第一应答时间是否不小于预设时长，生成第一判断结果；备选车型确定单元，用于在第一判断结果为是时，在车型集合中确定至少一种备选车型；第二应答时间确定单元，用于确定每种备选车型对应于路线信息的第二应答时间；推荐车型确定单元，用于在所有备选车型中确定第二应答时间小于预设时长的至少一种推荐车型；推荐信号确定单元，用于向乘客终端发送对应于至少一个推荐车型的推荐信号。

在该技术方案中，订单信号接收单元接收到终端发送的订单信号，该订单信号中对应有包括但不限于第一车型信息和路线信息。其中，第一车型信息包含但不限于车的载客人数、车辆种类以及车辆品牌；路线信息包括但不限于对乘客的起点地址和终点地址之间进行规划的最近路线，拥堵路线以及经过红灯最多路线。当确定该第一车型信息和路线信息后，第一判断单元比较对应于第一车型信息和路线信息的第一应答时间是否大于等于预设时长。需要说明的是，预设时长可以是通过相关机构调研得到的，也可以是通过相关出行数据得到的。另外需要说明的是，第一应答时间是相对于业务线需要排队的等待时间；因此，则存在第一车型信息和路线信息的第一应答时间大于或等于预设时间的情况，即乘客排队等待时间过长，此时备选车型确定单元可以在车型集合中确定一种备选车型。进一步地，在每种备选车型中第二应答时间确定单元确定对应于路线信息的第二应答时间。需要说明的是，第二应答时间是路线信息对应于所有备选车型所需等待时间；当推荐车型确定单元确定一种车型对应的第二应答时间小于预设时长时，则推荐信号确定单元向乘客终端发送对应于至少一个推荐车型的推荐信号。即在供需失衡时，在排队等待时间过长的情况下，在众多业务线中可以将更快的出行路线推荐给乘客。

在上述技术方案中，优选地，备选车型确定单元，具体包括：历史数据确定单元，用于确定与乘客终端对应的历史订单数据；使用频率确定单元，用于确定历史订单数据中，每个车型对应的使用率；筛选单元，用于确定使用率大于使用阈值的至少一种备选车型。

在该技术方案中，通过历史数据确定单元确定与乘客终端对应的历史订单数据，进一步地，使用频率确定单元确定历史订单中每个车型的使用率，进而筛选单元选择使用率较高的备选车型。即根据乘客使用偏好确定备选车型，提升用户体验。

在上述技术方案中，优选地，还包括：订单修改信号接收单元，用于接收乘客终端发送的订单修改信号；订单修改信息确定单元，用于根据订单修改信号，确定与订单修改信号对应的第二车型信息；第一派单信号发送单元，用于向与第二车型信息对应的司机终端发送第一派单信号。

在该技术方案中，乘客终端可以实时选择最优的车型及路线，若初始的订单信息有误，则订单修改信号接收单元可以及时地修改订单信息，接收到乘客终端发送的订单修改信号之后，根据订单修改信号，订单修改信号接收单元确定与订单修改信号对应的第二车型信息，对乘客终端发送的订单车型进行更新，需要说明的是，服务器接收的也可以是乘客终端对订单信号对应的车型信息进行更新之后生成的新订单；订单修改信息确定单元确定与订单修改信号对应的第二车型信息；进而第一派单信号发送单元向与第二车型信息对应的司机终端发送第一派单信号。即通过上述技术方案，准确为地向乘客提供了更快的出行路线作为参考，节省了乘客的出行时间，为乘客的出行提供了方便。

在上述技术方案中，优选地，还包括：第二派单信号发送单元，用于在第一判断结果为否时，向与第一车型信息对应的司机终端发送对应于订单信号的第二派单信号。

在该技术方案中，当第一判断结果为否时，即对应于第一车型信息和路线信息的第一应答时间小于预设时长，说明订单信号对应的排队等待时间在合理范围内，第二派单信号发送单元则直接将与第一车型信息对应的司机终端发送对应于订单信号的第二派单信号，实现了为乘客快速匹配出行的车型，进而节省了乘客的出行时间，方便了乘客的出行。

在上述技术方案中，优选地，还包括：第三派单信号发送单元，用于向与第一车型信息对应的司机终端发送对应于订单信号的第三派单信号。

在该技术方案中，乘客所下的订单信息，不用进行排队，第三派单信号发送单元则直接向与第一车型信息对应的司机终端发送对应于订单信号的第三派单信号。即实现了为乘客快速匹配出行的车型，进而节省了乘客的出行时间，方便了乘客的出行。

本发明第四方面的技术方案提出了一种网约车订单处理系统，包括:订单指令接收单元，用于接收订单指令；订单信号发送单元，用于根据订单指令，向服务器发送订单信号；推荐信号接收单元，用于接收服务器发送的推荐信号；推荐信息展示单元，用于根据推荐信号，展示对应于推荐信号的推荐信息。

在该技术方案中，订单指令接收单元接收订单指令，其中，订单指令中包括但不限于输入的起终点，继而根据订单指令，订单信号发送单元把订单信号发送与服务器；使得服务器准确地接收订单信息，进而选择出最优推荐业务线，并将该最优推荐业务线的信息通过推荐信号发送给乘客终端。即推荐信号接收单元接收服务器发送的推荐信号，进而推荐信息展示单元将推荐信号的推荐信息展现与乘客终端。使得乘客可以清晰准确地了解所要出行的推荐业务线，进而方便了乘客的出行。

在上述技术方案中，优选地，还包括：订单修改指令接收单元，用于接收订单修改指令；订单修改信息确定单元，用于根据订单修改指令，确定订单修改指令对应的第二车型信息；订单修改信号发送单元，用于根据第二车型信息生成并向服务器发送订单修改信号。

在该技术方案中，订单修改指令接收单元接收订单的修改指令，并通过订单修改信息确定单元确定订单修改指令对应的第二车型信息，即订单修改信号发送单元及时的生成并发送乘客修改后的订单信息，使得乘客可以及时修改出行路线或者是最佳路线，其中，订单修改信号可以是服务器修改，也可以是乘客终端修改。即实现了为乘客准确而快速匹配出行的车型，进而节省了乘客的出行时间，方便了乘客的出行。

本发明第五方面的技术方案提出了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时执行上述任一项的网约车订单处理方法。

在该技术方案中，计算机设备包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时执行实现如上述第一方面或第二方面技术方案中任一业务推荐的方法，因此具有上述第一方面或第二方面技术方案中任一业务推荐方法的有益效果，在此不再赘述。

本发明第六方面的技术方案提出了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述任一项的网约车订单处理方法。

在该技术方案中，计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现如上述第一方面或第二方面技术方案中任一业务推荐的方法，因此具有上述第一方面或第二方面技术方案中任一业务推荐方法的有益效果，在此不再赘述。

本发明第七方面的技术方案提出了一种服务器，包括上述任一项网约车订单处理系统。

在该技术方案中，服务器包括如上述第三方面技术方案中任一业务推荐的系统，因此具有如上述任一推荐系统的全部有益效果，在此不再赘述。

本发明第八方面的技术方案提出了一种终端，包括第四方面技术方案中任一网约车订单处理系统。

在该技术方案中，终端包括如第四方面技术方案中任一网约车订单处理系统，因此具有如上述任一业务推荐系统的全部有益效果，在此不再赘述。

本发明的附加方面和优点将在下面的描述部分中变得明显，或通过本发明的实践了解到。

附图说明

本发明的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解，其中：

图1示出了根据本发明的一个实施例的网约车订单处理方法的流程示意图；

图2示出了根据本发明的再一个实施例的网约车订单处理方法的流程示意图；

图3示出了根据本发明的再一个实施例的网约车订单处理方法的流程示意图；

图4示出了根据本发明的一个实施例的网约车订单处理系统的结构示意图；

图5示出了根据本发明的再一个实施例的网约车订单处理系统的结构示意图；

图6示出了根据本发明的一个实施例的计算机设备的结构示意图；

图7示出了根据本发明的一个实施例的终端的结构示意图；

图8示出了根据本发明的一个实施例的服务器的结构示意图。

具体实施方式

为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明的保护范围并不受下面公开的具体实施例的限制。

实施例一：

如图1所示，本发明一个实施例提出了一种网约车订单处理方法，用于服务器，包括：步骤S102，接收乘客终端发送的订单信号；步骤S104，根据订单信号对应的第一车型信息和路线信息，判断对应于第一车型信息和路线信息的第一应答时间是否不小于预设时长，生成第一判断结果；步骤S106，在第一判断结果为是时，在车型集合中确定至少一种备选车型；步骤S108，确定每种备选车型对应于路线信息的第二应答时间；S110，在所有备选车型中确定第二应答时间小于预设时长的至少一种推荐车型；S112，向乘客终端发送对应于至少一个推荐车型的推荐信号。

在该实施例中，步骤S102当服务器接收到终端发送的订单信号，该订单信号中对应有包括但不限于第一车型信息和路线信息。其中，第一车型信息包含但不限于车的载客人数、车辆种类以及车辆品牌；路线信息包括但不限于对乘客的起点地址和终点地址之间进行规划的最近路线，拥堵路线以及经过红灯最多路线。当步骤S104确定该第一车型信息和路线信息后，服务器比较对应于第一车型信息和路线信息的第一应答时间是否大于等于预设时长。需要说明的是，预设时长可以是通过相关机构调研得到的，也可以是通过相关出行数据得到的。另外需要说明的是，第一应答时间是相对于业务线需要排队的等待时间；因此，则存在第一车型信息和路线信息的第一应答时间大于或等于预设时间的情况，即乘客排队等待时间过长，此时则步骤S106可以在车型集合中确定一种备选车型。进一步地，步骤S108在每种备选车型中确定对应于路线信息的第二应答时间。需要说明的是，第二应答时间是路线信息对应于所有备选车型所需等待时间；当步骤S110其中的一种车型对应的第二应答时间小于预设时长时，则步骤S112服务器向乘客终端发送对应于至少一个推荐车型的推荐信号。即在供需失衡时，在排队等待时间过长的情况下，在众多业务线中可以将更快的出行路线推荐给乘客，方便了乘客的出行。

在上述实施例中，优选地，在车型集合中确定至少一种备选车型，具体包括：确定与乘客终端对应的历史订单数据；确定历史订单数据中，每个车型对应的使用率；确定使用率大于使用阈值的至少一种备选车型。

在该实施例中，通过确定与乘客终端对应的历史订单数据及历史订单中每个车型的使用率，进而选择使用率较高的备选车型。即根据乘客使用偏好确定备选车型，提升用户体验。

在上述实施例中，优选地，还包括：接收乘客终端发送的订单修改信号；根据订单修改信号，确定与订单修改信号对应的第二车型信息；向与第二车型信息对应的司机终端发送第一派单信号。

在该实施例中，乘客终端可以实时选择最优的车型及路线，若初始的订单信息有误，则可以及时地修改订单信息；接收到乘客终端发送的订单修改信号之后，根据订单修改信号，服务器确定与订单修改信号对应的第二车型信息，对乘客终端发送的订单车型进行更新，需要说明的是，服务器接收的也可以是乘客终端对订单信号对应的车型信息进行更新之后生成的新订单；服务器确定与订单修改信号对应的第二车型信息；进而向与第二车型信息对应的司机终端发送第一派单信号。即通过上述技术方案，准确为地向乘客提供了更快的出行路线作为参考，节省了乘客的出行时间，为乘客的出行提供了方便。

实施例二：

如图2所示，本发明一个实施例提出了一种网约车订单处理方法，用于服务器，包括：步骤S202，接收乘客终端发送的订单信号；步骤S204，根据订单信号对应的第一车型信息和路线信息，判断对应于第一车型信息和路线信息的第一应答时间是否不小于预设时长，生成第一判断结果；步骤S206，在第一判断结果为是时，在车型集合中确定至少一种备选车型；步骤S208，在第一判断结果为否时，向与第一车型信息对应的司机终端发送对应于订单信号的第二派单信号；步骤S210，确定每种备选车型对应于路线信息的第二应答时间；S212，在所有备选车型中确定第二应答时间小于预设时长的至少一种推荐车型；S214，向乘客终端发送对应于至少一个推荐车型的推荐信号。

在该实施例中，步骤S202当服务器接收到终端发送的订单信号，该订单信号中对应有包括但不限于第一车型信息和路线信息。其中，第一车型信息包含但不限于车的载客人数车辆种类以及车辆品牌；路线信息包括但不限于对乘客的起点地址和终点地址之间进行规划的最近路线，拥堵路线以及经过红灯最多路线。当步骤S204确定该第一车型信息和路线信息后，服务器比较对应于第一车型信息和路线信息的第一应答时间是否大于等于预设时长。需要说明的是，预设时长可以是通过相关机构调研得到的，也可以是通过相关出行数据得到的。另外需要说明的是，第一应答时间是相对于业务线需要排队的等待时间；因此，则存在第一车型信息和路线信息的第一应答时间大于或等于预设时间的情况，即乘客排队等待时间过长，此时则步骤S206可以在车型集合中确定一种备选车型。当步骤S208第一判断结果为否时，即对应于第一车型信息和路线信息的第一应答时间小于预设时长，说明订单信号对应的排队等待时间在合理范围内，则服务器直接将与第一车型信息对应的司机终端发送对应于订单信号的第二派单信号。进一步地，步骤S210在每种备选车型中确定对应于路线信息的第二应答时间。需要说明的是，第二应答时间是路线信息对应于所有备选车型所需等待时间；当步骤S212其中的一种车型对应的第二应答时间小于预设时长时，则步骤S214服务器向乘客终端发送对应于至少一个推荐车型的推荐信号。即在供需失衡时，在排队等待时间过长的情况下，在众多业务线中可以将更快的出行路线推荐给乘客。进而实现了为乘客快速匹配出行的车型，进而节省了乘客的出行时间，方便了乘客的出行。

在上述实施例中，优选地，在根据订单信号对应的车型信息和路线信息，判断对应于第一车型信息和路线信息的第一应答时间是否不小于预设时长，生成第一判断结果之前，还包括：向与第一车型信息对应的司机终端发送对应于订单信号的第三派单信号。

在该实施例中，乘客所下的订单信息，不用进行排队，则服务器直接向与第一车型信息对应的司机终端发送对应于订单信号的第三派单信号。即实现了为乘客快速匹配出行的车型，进而节省了乘客的出行时间，方便了乘客的出行。

实施例三：

如图3所示，本发明再一个实施例提出了一种网约车订单处理方法，用于乘客终端，包括:步骤302，接收订单指令；步骤304，根据订单指令，向服务器发送订单信号；步骤306，接收服务器发送的推荐信号；步骤308，根据推荐信号，展示对应于推荐信号的推荐信息。

在该实施例中，步骤302乘客终端接收订单指令，其中，订单指令中包括但不限于输入的起终点，继而步骤304根据订单指令，把订单信号发送与服务器；使得服务器准确地接收订单信息，进而选择出最优推荐业务线，并将该最优推荐业务线的信息通过推荐信号发送给乘客终端。即步骤306乘客终端接收服务器发送的推荐信号，进而步骤308将推荐信号的推荐信息展现与乘客终端。使得乘客可以清晰准确地了解所要出行的推荐业务线，进而方便了乘客的出行。

在上述实施例中，优选地，还包括：接收订单修改指令；根据订单修改指令，确定订单修改指令对应的第二车型信息；根据第二车型信息生成并向服务器发送订单修改信号。

在该实施例中，服务器在接收到乘客终端发送的订单信号后，根据订单信号对应的第一车型信息发送给与第一车型信息匹配的司机终端进行排队等待接单，在乘客等待接单过程中，对第一应答时间进行判断，为乘客提供更快的出行路线作为参考，有效利用了乘客的排队等待时间，提升了用户体验。

实施例四：

如图4所示，本发明再一个实施例提出了一种网约车订单处理系统400，包括：订单信号接收单元402，用于接收乘客终端发送的订单信号；第一判断单元404，用于根据订单信号对应的第一车型信息和路线信息，判断对应于第一车型信息和路线信息的第一应答时间是否不小于预设时长，生成第一判断结果；备选车型确定单元406，用于在第一判断结果为是时，在车型集合中确定至少一种备选车型；第二应答时间确定单元408，用于确定每种备选车型对应于路线信息的第二应答时间；推荐车型确定单元410，用于在所有备选车型中确定第二应答时间小于预设时长的至少一种推荐车型；推荐信号确定单元412，用于向乘客终端发送对应于至少一个推荐车型的推荐信号。

在该实施例中，订单信号接收单元402接收到终端发送的订单信号，该订单信号中对应有包括但不限于第一车型信息和路线信息。其中，第一车型信息包含但不限于车的载客人数车辆种类以及车辆品牌；路线信息包括但不限于对乘客的起点地址和终点地址之间进行规划的最近路线，拥堵路线以及经过红灯最多路线。当确定该第一车型信息和路线信息后，第一判断单元404比较对应于第一车型信息和路线信息的第一应答时间是否大于等于预设时长。需要说明的是，预设时长可以是通过相关机构调研得到的，也可以是通过相关出行数据得到的。另外需要说明的是，第一应答时间是相对于业务线需要排队的等待时间；因此，则存在第一车型信息和路线信息的第一应答时间大于或等于预设时间的情况，即乘客排队等待时间过长，此时备选车型确定单元406可以在车型集合中确定一种备选车型。进一步地，在每种备选车型中第二应答时间确定单元408确定对应于路线信息的第二应答时间。需要说明的是，第二应答时间是路线信息对应于所有备选车型所需等待时间；当推荐车型确定单元410确定一种车型对应的第二应答时间小于预设时长时，则推荐信号确定单元412向乘客终端发送对应于至少一个推荐车型的推荐信号。即在供需失衡时，在排队等待时间过长的情况下，在众多业务线中可以将更快的出行路线推荐给乘客。

在上述实施例中，优选地，备选车型确定单元406，具体包括：历史数据确定单元4062，用于确定与乘客终端对应的历史订单数据；使用频率确定单元4064，用于确定历史订单数据中，每个车型对应的使用率；筛选单元4066，用于确定使用率大于使用阈值的至少一种备选车型。

在该实施例中，通过历史数据确定单元确定4062与乘客终端对应的历史订单数据，进一步地，使用频率确定单元4064确定历史订单中每个车型的使用率，进而筛选单元4066选择使用率较高的备选车型。即根据乘客使用偏好确定备选车型，提升用户体验。

在上述实施例中，优选地，还包括：订单修改信号接收单元414，用于接收乘客终端发送的订单修改信号；订单修改信息确定单元416，用于根据订单修改信号，确定与订单修改信号对应的第二车型信息；第一派单信号发送单元418，用于向与第二车型信息对应的司机终端发送第一派单信号。

在该实施例中，乘客终端可以实时选择最优的车型及路线，若初始的订单信息有误，则订单修改信号接收单元414可以及时地修改订单信息；订单修改信息确定单元确416定与订单修改信号对应的第二车型信息；接收到乘客终端发送的订单修改信号之后，根据订单修改信号，订单修改信息确定单元确416确定与订单修改信号对应的第二车型信息，对乘客终端发送的订单车型进行更新，需要说明的是，服务器接收的也可以是乘客终端对订单信号对应的车型信息进行更新之后生成的新订单；进而第一派单信号发送单元418向与第二车型信息对应的司机终端发送第一派单信号。即通过上述技术方案，准确为地向乘客提供了更快的出行路线作为参考，节省了乘客的出行时间，为乘客的出行提供了方便。

在上述实施例中，优选地，还包括：第二派单信号发送单元420，用于在第一判断结果为否时，向与第一车型信息对应的司机终端发送对应于订单信号的第二派单信号。

在该实施例中，当第一判断结果为否时，即对应于第一车型信息和路线信息的第一应答时间小于预设时长，说明订单信号对应的排队等待时间在合理范围内，第二派单信号发送单元420则直接将与第一车型信息对应的司机终端发送对应于订单信号的第二派单信号，实现了为乘客快速匹配出行的车型，进而节省了乘客的出行时间，方便了乘客的出行。

在上述实施例中，优选地，还包括：第三派单信号发送单元422，用于向与第一车型信息对应的司机终端发送对应于订单信号的第三派单信号。

在该实施例中，服务器在接收到乘客终端发送的订单信号后，第三派单信号发送单元422根据订单信号对应的第一车型信息发送给与第一车型信息匹配的司机终端进行排队等待接单，在乘客等待接单过程中，对第一应答时间进行判断，为乘客提供更快的出行路线作为参考，有效利用了乘客的排队等待时间，提升了用户体验。

实施例五：

如图5所示，本发明又一个实施例提出了一种网约车订单处理系统500，包括:订单指令接收单元502，用于接收订单指令；订单信号发送单元504，用于根据订单指令，向服务器发送订单信号；推荐信号接收单元506，用于接收服务器发送的推荐信号；推荐信息展示单元508，用于根据推荐信号，展示对应于推荐信号的推荐信息。

在该实施例中，订单指令接收单元502接收订单指令，其中，订单指令中包括但不限于输入的起终点，继而根据订单指令，订单信号发送单元504把订单信号发送与服务器；使得服务器准确地接收订单信息，进而选择出最优推荐业务线，并将该最优推荐业务线的信息通过推荐信号发送给乘客终端。即推荐信号接收单元506接收服务器发送的推荐信号，进而推荐信息展示单元508将推荐信号的推荐信息展现与乘客终端。使得乘客可以清晰准确地了解所要出行的推荐业务线，进而方便了乘客的出行。

在上述实施例中，优选地，还包括：订单修改指令接收单元510，用于接收订单修改指令；订单修改信息确定单元512，用于根据订单修改指令，确定订单修改指令对应的第二车型信息；订单修改信号发送单元514，用于根据第二车型信息生成并向服务器发送订单修改信号。

在该实施例中，订单修改指令接收单元510接收订单的修改指令，并通过订单修改信息确定单元512确定订单修改指令对应的第二车型信息，即订单修改信号发送单元514及时的生成并发送乘客修改后的订单信息，进而使得乘客可以及时修改出行路线或者是最佳路线，其中，订单修改信号可以是服务器修改，也可以是乘客终端修改。即实现了为乘客准确而快速匹配出行的车型，进而节省了乘客的出行时间，方便了乘客的出行。

实施例六：

如图6所示，本发明又一个实施例提出了一种计算机设备600，包括存储器602、处理器604及存储在存储器602上并可在处理器604上运行的计算机程序，处理器执行计算机程序时执行上述任一项的网约车订单处理方法。

在该实施例中，计算机设备600包括存储器602、处理器604及存储在存储器上602并可在处理器604上运行的计算机程序，处理器604执行计算机程序时执行实现如上述任一项实施例业务推荐的方法的全部有益效果，在此不再赘述。

实施例七：

如图7所示，本发明又一个实施例提出了一种终端700，包括上述任一项用于终端的网约车订单处理系统500。

在该实施例中，终端700包括如上述任一项实施例的网约车订单处理系统500，因此具有如上述任一项实施例的业务推荐的系统500的全部有益效果，在此不再赘述。

实施例八:

如图8所示，本发明又一个实施例提出了一种服务器800，包括上述任一项用于服务器的网约车订单处理系统400。

在该实施例中，服务器800包括如上述任一项实施例的网约车订单处理系统400，因此具有如上述任一项实施例的业务推荐的系统400的全部有益效果，在此不再赘述。

以上结合附图详细说明了本发明的实施例，一种网约车订单处理方法、系统、终端及服务器，通过本发明的技术方案，可以在供需失衡时，在排队等待的情况下，在众多业务线中可以将更快的出行路线推荐给乘客，即通过上述技术方案，准确为地向乘客提供了更快的出行路线作为参考，节省了乘客的出行时间，为乘客的出行提供了方便。

在本说明书的描述中，术语“一个实施例”、“一些实施例”、“具体实施例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或实例。而且，描述的具体特征、结构、材料或特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

以上仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (18)

1.一种网约车订单处理方法，用于服务器，其特征在于，包括：

接收乘客终端发送的订单信号；

根据所述订单信号对应的第一车型信息和路线信息，判断对应于所述第一车型信息和所述路线信息的第一应答时间是否不小于预设时长，生成第一判断结果，所述第一应答时间是订单相对于业务线需要排队的等待时间，所述预设时长是通过相关出行数据得到的；

在所述第一判断结果为是时，在车型集合中确定至少一种备选车型；

确定每种所述备选车型对应于所述路线信息的第二应答时间；

在所有所述备选车型中确定所述第二应答时间小于所述预设时长的至少一种推荐车型；

向所述乘客终端发送对应于至少一个所述推荐车型的推荐信号。

2.根据权利要求1所述的网约车订单处理方法，其特征在于，所述在车型集合中确定至少一种备选车型，具体包括：

确定与所述乘客终端对应的历史订单数据；

确定所述历史订单数据中，每个车型对应的使用率；

确定所述使用率大于使用阈值的至少一种备选车型。

3.根据权利要求2所述的网约车订单处理方法，其特征在于，还包括：

接收所述乘客终端发送的订单修改信号；

根据所述订单修改信号，确定与所述订单修改信号对应的第二车型信息；

向与所述第二车型信息对应的司机终端发送第一派单信号。

4.根据权利要求1至3中任一项所述的网约车订单处理方法，其特征在于，还包括：

在所述第一判断结果为否时，向与所述第一车型信息对应的司机终端发送对应于所述订单信号的第二派单信号。

5.根据权利要求1至3中任一项所述的网约车订单处理方法，其特征在于，在所述根据所述订单信号对应的第一车型信息和路线信息，判断对应于所述第一车型信息和所述路线信息的第一应答时间是否不小于预设时长，生成第一判断结果之前，还包括：

向与所述第一车型信息对应的司机终端发送对应于所述订单信号的第三派单信号。

6.一种网约车订单处理方法，用于乘客终端，其特征在于，包括:

接收订单指令；

根据所述订单指令，向服务器发送订单信号；

接收所述服务器发送的推荐信号，其中所述推荐信号是所述服务器基于针对订单的第一应答时间是否小于预设时长而确定的，所述第一应答时间是订单相对于业务线需要排队的时间，所述预设时长是通过相关出行数据得到的；

根据所述推荐信号，展示对应于所述推荐信号的推荐信息。

7.根据权利要求6所述的网约车订单处理方法，其特征在于，还包括：

接收订单修改指令；

根据所述订单修改指令，确定所述订单修改指令对应的第二车型信息；

根据所述第二车型信息生成并向所述服务器发送订单修改信号。

8.一种网约车订单处理系统，其特征在于，包括：

订单信号接收单元，用于接收乘客终端发送的订单信号；

第一判断单元，用于根据所述订单信号对应的第一车型信息和路线信息，判断对应于所述第一车型信息和所述路线信息的第一应答时间是否不小于预设时长，生成第一判断结果，所述第一应答时间是订单相对于业务线需要排队的等待时间，所述预设时长是通过相关出行数据得到的；

备选车型确定单元，用于在所述第一判断结果为是时，在车型集合中确定至少一种备选车型；

第二应答时间确定单元，用于确定每种所述备选车型对应于所述路线信息的第二应答时间；

推荐车型确定单元，用于在所有所述备选车型中确定所述第二应答时间小于所述预设时长的至少一种推荐车型；

推荐信号确定单元，用于向所述乘客终端发送对应于至少一个所述推荐车型的推荐信号。

9.根据权利要求8所述的网约车订单处理系统，其特征在于，所述备选车型确定单元，具体包括：

历史数据确定单元，用于确定与所述乘客终端对应的历史订单数据；

使用频率确定单元，用于确定所述历史订单数据中，每个车型对应的使用率；

筛选单元，用于确定所述使用率大于使用阈值的至少一种备选车型。

10.根据权利要求9所述的网约车订单处理系统，其特征在于，还包括：

订单修改信号接收单元，用于接收所述乘客终端发送的订单修改信号；

订单修改信息确定单元，用于根据所述订单修改信号，确定与所述订单修改信号对应的第二车型信息；

第一派单信号发送单元，用于向与所述第二车型信息对应的司机终端发送第一派单信号。

11.根据权利要求8至10中任一项所述的网约车订单处理系统，其特征在于，还包括：

第二派单信号发送单元，用于在所述第一判断结果为否时，向与所述第一车型信息对应的司机终端发送对应于所述订单信号的第二派单信号。

12.根据权利要求8至10中任一项所述的网约车订单处理系统，其特征在于，还包括：

第三派单信号发送单元，用于向与所述第一车型信息对应的司机终端发送对应于所述订单信号的第三派单信号。

13.一种网约车订单处理系统，其特征在于，包括:

订单指令接收单元，用于接收订单指令；

订单信号发送单元，用于根据所述订单指令，向服务器发送订单信号；

推荐信号接收单元，用于接收所述服务器发送的推荐信号，其中所述推荐信号是所述服务器基于针对订单的第一应答时间是否小于预设时长而确定的，所述第一应答时间是订单相对于业务线需要排队的时间，所述预设时长是通过相关出行数据得到的；

推荐信息展示单元，用于根据所述推荐信号，展示对应于所述推荐信号的推荐信息。

14.根据权利要求13所述的网约车订单处理系统，其特征在于，还包括：

订单修改指令接收单元，用于接收订单修改指令；

订单修改信息确定单元，用于根据所述订单修改指令，确定所述订单修改指令对应的第二车型信息；

订单修改信号发送单元，用于根据所述第二车型信息生成并向所述服务器发送订单修改信号。

15.一种计算机设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时执行如权利要求1至5中任一项所述的网约车订单处理方法或如权利要求6或7所述的网约车订单处理方法。

16.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至5中任一项所述的网约车订单处理方法或如权利要求6或7所述的网约车订单处理方法。

17.一种服务器，其特征在于，包括：权利要求8至12中任一项所述的网约车订单处理系统。

18.一种终端，其特征在于，包括：权利要求13或14所述的网约车订单处理系统。