CN109313776A - 用于按需服务分配车辆的系统和方法 - Google Patents

Abstract

本申请涉及用于按需服务的车辆分配的方法和系统。所述方法包括从用户终端接收服务请求，所述服务请求包括出发地和目的地(510)；基于出发地和目的地，生成包含第一预估价格的所述服务请求订单(520)；将所述订单添加到待分配车辆的第一队列中(530)；向用户终端发送第一显示指令，所述第一显示指令指示用户终端显示与订单状态相关的信息(540)。

Description

用于按需服务分配车辆的系统和方法

本申请要求于2017年3月29日提交的编号为No.201710195830.8的中国专利申请和2017年3月29日提交的编号为No.201710196641.2的中国专利申请优先权，其内容以引用的方式被包含于此。

本申请涉及用于按需服务车辆分配的方法和系统，具体地，涉及用于在用户发起请求服务之后，向用户显示和/或更新车辆分配状态的方法和系统。

背景技术

在在线车辆的分配过程中，用户发起服务请求之后，用户可能不得不等待其发起的服务请求被分配车辆。由于用户可能不知道与服务请求的状态相关的信息(例如，在订单之前的正在等待的订单的数量、正在等待的订单的总数、可用于接单的当前可用车辆的数量等等)，用户不能基于他/她自己的情况和/或与服务请求的状态相关的信息来确定适合他/她的需求的出行模式。因此，需要提供用于在用户发起请求服务之后，向用户显示和/或更新车辆分配状态的系统和方法。

发明内容

根据本申请的一个方面，提供了一个系统。该系统可以包括至少一个计算机可读存储介质，其包括用于为按需服务分配车辆的一组指令，并且至少一个处理器被配置为与所述至少一个计算机可读存储介质通信。当执行所述指令时，所述至少一个处理器用于：从用户终端接收服务请求，所述服务请求可以包括出发地和目的地；基于所述出发地和所述目的地，生成关于所述服务请求的具有第一预估价格的订单；将所述订单添加到待分配车辆的第一队列中；向所述用户终端发送第一显示指令，所述第一显示指令可以指示所述用户终端显示与所述订单的状态相关的信息。

在一些实施例中，与所述订单的状态相关的信息包括以下中的至少一个：所述第一预估价格、订单之前所述第一队列中正在等待的订单的数量、所述第一队列中的所述订单的估计等待时间、所述第一队列中正在等待的订单的总数、或所述第一队列中可用于接单的车辆数量。

在一些实施例中，所述至少一个处理器进一步用于：获取历史等待数据；基于所述历史等待数据确定订单的估计等待时间，其中，所述估计的等待时间表示在第一队列中所述订单将被处理的时间或在第一列中所述订单将被处理的时间段。

在一些实施例中，所述至少一个处理器进一步用于：确定所述第一队列中，在所述订单之前的所述正在等待的订单数量小于订单阈值；向所述用户终端发送第二显示指令，所述第二显示指令指示所述用户终端显示车辆分配状态。

在一些实施例中，所述至少一个处理器进一步用于：确定在所述第一队列中，所述订单的所述估计的等待时间小于第一时间阈值；向所述用户终端发送第二显示指令，所述第二显示指令指示所述用户终端显示车辆分配状态。

在一些实施例中，所述至少一个处理器进一步用于：确定在所述第一队列中，所述订单的所述估计等待时间大于第二时间阈值；向所述用户终端发送第三显示指令，所述第三显示指令指示所述用户终端向用户显示一个或以上建议，以供选择完成所述服务请求，其中所述一个或以上建议包括拼车。

在一些实施例中，为了将所述订单添加到待分配车辆的第一队列中，所述至少一个处理器进一步用于：确定所述第一队列的排队模式；根据所述排队模式将所述订单添加到所述第一队列中，其中所述排队模式包括关于所述订单的确认时间的严格排队模式或关于所述订单的权重的非严格排队模式中的至少一个。

在一些实施例中，所述至少一个处理器进一步用于：确定当前等待时间大于第三时间阈值；向所述用户终端发送第四显示指令，所述第四显示指令指示所述用户终端显示是否继续等待的询问。

在一些实施例中，所述至少一个处理器进一步用于：确定所述当前等待时间大于第四时间阈值，所述第四时间阈值大于所述第三时间阈值；取消所述订单。

在一些实施例中，所述至少一个处理器进一步用于：确定所述订单满足第一条件；向所述用户终端发送第五显示指令，所述第五显示指令指示所述用户终端显示供选择的出行建议，所述供选择的出行建议建议所述服务请求执行第二预估价格，所述第二预估价格大于所述第一预估价格；接收对所述出行建议的选择，所述选择包含所述第二预估价格；将所述订单添加到第二队列中，其中所述第二队列中可用于接单的第二车辆数量与所述第二队列中的第二正在等待的订单数量的第二比率大于所述第一队列中可用于接单的第一车辆数量与所述第一队列中第一正在等待的订单数量的第一比率。

在一些实施例中，为了确定所述订单满足第一条件，所述至少一个处理器进一步用于：基于所述订单的所述出发地确定区域；确定所述区域中，在所述第一队列中可用于接单的车辆数量；确定所述区域中，在所述第一队列中正在等待的订单的总数；确定所述区域中的所述正在等待的订单的总数大于所述区域中，在所述第一队列中可用于接单的所述车辆的数量。

在一些实施例中，为了确定所述订单满足第一条件，所述至少一个处理器进一步用于：确定当前时间在预定时间范围内。

根据本申请的一个方面，提供了一个方法。所述方法可以在具有至少一个处理器、至少一个计算机可读存储介质和连接到网络的通信平台的计算设备上实现。所述方法可以包括从用户终端接收服务请求，所述服务请求可以包括出发地和目的地；基于所述出发地和所述目的地，生成所述服务请求的具有第一预估价格的订单；将所述订单添加到待分配车辆的第一队列中；向所述用户终端发送第一显示指令，所述第一显示指令可以指示用户终端显示与订单的状态相关的信息。

在一些实施例中，与所述订单的状态相关的信息包括以下中的至少一个：所述第一预估价格、订单之前所述第一队列中正在等待的订单的数量、所述第一队列中的所述订单的估计等待时间、所述第一队列中正在等待的订单的总数、或所述第一队列中可用于接单的车辆数量。

在一些实施例中，所述方法进一步用于：确定所述第一队列中的所述正在等待的订单数量小于订单阈值；向所述用户终端发送第二显示指令，所述第二显示指令指示所述用户终端显示车辆分配状态。

在一些实施例中，所述方法进一步包括：确定在所述第一队列中，所述订单的所述估计等待时间小于第一时间阈值；向所述用户终端发送第二显示指令，所述第二显示指令指示所述用户终端显示车辆分配状态。

在一些实施例中，所述方法进一步用于：确定在所述第一队列中，所述订单的所述估计等待时间大于第二时间阈值；向所述用户终端发送第三显示指令，所述第三显示指令指示所述用户终端向所述用户显示一个或多个建议，以供选择以完成所述服务请求，所述一个或多个建议包括拼车。

在一些实施例中，所述方法进一步用于：确定当前等待时间大于第三时间阈值；向所述用户终端发送第四显示指令，所述第四显示指令指示所述用户终端显示是否继续等待的询问。

在一些实施例中，所述方法进一步用于：确定所述订单满足第一条件；向所述用户终端发送第五显示指令，所述第五显示指令指示所述用户终端显示供选择的出行建议，所述供选择的出行建议建议所述服务请求执行第二预估价格，所述第二预估价格大于所述第一预估价格；接收对所述出行建议的选择，所述选择包含所述第二预估价格；将所述订单添加到第二队列中，其中所述第二队列中可用于接单的第二车辆数量与所述第二队列中的第二正在等待的订单数量的第二比率大于所述第一队列中可用于接单的第一车辆数量与所述第一队列中第一正在等待的订单数量的第一比率。

在本申请的另一个方面，提供了一种非暂时性计算机可读介质。所述计算机可读介质可以包括至少一组用于按需服务分配车辆的指令，当由计算机设备的至少一个处理器执行时，所述至少一组指令指示所述至少一个处理器：从用户终端接收服务请求，所述服务请求包括出发地和目的地；基于所述出发地和所述目的地，生成所述服务请求的具有第一预估价格的订单；将所述订单添加到待分配车辆的第一队列中；向所述用户终端发送第一显示指令，所述第一显示指令指示所述用户终端显示与所述订单的状态相关的信息。

附图说明

本申请将结合示例性实施例进一步进行描述。这些示例性的实施例将结合参考图示进行详细描述。这些实施例并非限制性的，在这些实施例中，相同的组件符号表示相同的结构，其中：

图1是根据本申请的一些实施例所示的示例性车辆分配系统的框图；

图2是根据本申请的一些实施例所示的计算设备的示例性硬件和/或软件组件的框图；

图3是根据本申请的一些实施例所示的移动设备的示例性硬件和/或软件组件的框图；

图4是根据本申请的一些实施例所示的处理引擎的示意性框图。

图5是根据本申请的一些实施例所示的用于为服务请求分配车辆的示例性过程的流程图；

图6是根据本申请的一些实施例所示的用于在队列中为订单分配车辆的示例性过程的示意图；

图7是根据本申请的一些实施例所示的用户终端的示例性用户界面；

图8是根据本申请的一些实施例所示的用于确定订单的估计等待时间的示例性过程的流程图；

图9是根据本申请的一些实施例所示的用于向用户终端发送显示指令的示例性过程的流程图；

图10是根据本申请的一些实施例的用户终端的示例性用户界面；

图11是根据本申请的一些实施例所示的用于向用户终端发送显示指令的示例性过程的流程图；

图12是根据本申请的一些实施例的用户终端的示例性用户界面；

图13是根据本申请的一些实施例所示的用于向用户终端发送显示指令的示例性过程的流程图；

图14是根据本申请的一些实施例所示的用于取消订单的示例性过程的流程图；

图15是根据本申请的一些实施例所示的用于为服务请求分配车辆的示例性过程的流程图；

图16a-图16d是根据本申请的一些实施例的用户终端的示例性用户界面；

图17是根据本申请的一些实施例所示的用于确定订单满足第一条件的示例性过程的流程图；

图18a-图18h是根据本申请的一些实施例的用户终端的示例性用户界面；以及

图19a-图19b是根据本申请的一些实施例的用户终端的示例性用户界面。

具体实施方式

以下描述是为了使本领域的普通技术人员能够实施和利用本申请，并在特定应用及其要求的上下文中提供。对于本领域的普通技术人员来讲，对本申请披露的实施例进行的各种修改是显而易见的，并且本文中定义的通则在不背离本申请的精神及范围的情况下，可以适用于其他实施例及应用。因此，本申请不限于所示的实施例，而是符合与权利要求一致的最广泛范围。

应当理解的是，本申请使用的术语“系统”、“引擎”、“单元”、“模块”和/或“块”是用于区分在顺序排列中不同级别的不同组件、元件、部件、部分或组件的一种方法。然而，如果其他表达式可以实现相同的目的，这些术语可以被其他表达式替换。

本申请中所使用的术语仅为了描述特定示例和实施例，并不限制本申请的范围。在本申请中所使用的“一”、“一个”、“所述”等词语并非特指单数，可以包括复数形式，除非上下文明确提示例外情形。还应当理解的是，本申请的术语“包括”和/或“包含”仅提示包括整体、设备、行为、已明确标识的特征、步骤、元件、操作和/或部件，但是不排除一个或多个其他整体、设备、行为、特征、步骤、元件、操作、部件和/或其组合的存在或添加。

在考虑了作为本申请一部分的附图的描述内容后，本申请的特征和特点以及操作方法、结构的相关元素的功能、各部分的组合、制造的经济性变得显而易见然而，应当理解的是，附图仅仅是为了说明和描述的目的，并不旨在限制本申请的范围。应当理解的是附图并不是按比例的。

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

本申请中的术语“乘客”、“请求者”、“服务请求者”和“客户”可用于表示请求或预定服务的个人、实体或工具，并且可互换使用。此外，本申请中的术语“司机”、“提供者”、“服务提供者”和“供应者”可用于指代可提供服务或促进提供服务的个人、实体或工具，并且可互换使用。本申请中的术语“用户”可表示用于请求服务、预定服务、提供服务或促进提供服务的个人、实体或工具。例如，用户可以为乘客、司机、操作员等中的一种或多种的组合。在本申请中，“乘客”、“用户设备”、“用户终端130”和“乘客端”可以互换使用，“司机”和“司机终端”可以互换使用。

本申请的一个方面涉及一种车辆分配方法。根据本申请，在用户终端发起服务请求之后，可以将订单添加到等待队列中以被分配车辆。用户终端可以被指示显示订单的状态(例如，订单是否已经被分配了车辆、订单需等待多长时间才被分配给车辆、等待队列中有多少车辆可用等)，以向用户终端的用户通知订单的状态。该系统和方法还可以确定在当前时间段期间内，在当前区域中发送的服务请求是否超过服务提供者的处理能力。如果在当前时间段期间当前区域中的服务被超额预订，则系统和方法可以向用户提供一个或以上的出行模式，使得用户可以选择变为另一个出行模式以被分配车辆。根据本申请的系统和方法可以通过向用户提供一个或以上选择，以切换到更快的等待队列来分配车辆的来加速服务请求的处理。

图1是根据本申请的一些实施例的示例性车辆分配系统100的框图。例如，系统100可以是用于运输服务的在线运输服务平台，例如汽车服务、司机服务、车辆递送服务、拼车服务、公共汽车服务、司机招聘服务和班车服务等。如图1所示，车辆分配系统100可以包括服务器110、网络120、用户终端130、司机终端140和存储器150。

服务器110可以被配置为处理与服务请求有关的信息和/或数据，例如，用于叫车的服务请求。例如，服务器110可以从用户终端130接收服务请求，并且处理关于服务请求的订单，以将车辆分配给用户终端130。在一些实施例中，服务器110可以是单个服务器或一服务器组。服务器组可以是集中的或分布式的(例如，服务器110可以是分布式系统)。在一些实施例中，服务器110可以是本地的或远程的。例如，服务器110可以通过网络120访问存储在用户终端130、司机终端140和/或存储器150中的信息和/或数据。作为另一示例，服务器110可以直接连接到用户终端130、司机终端140和/或存储器150以访问存储的信息和/或数据。在一些实施例中，服务器110可以在云平台上实施。云平台可以包括私有云、公共云、混合云、社区云、分布云、跨云、多云等中的一种或多种的组合。在一些实施例中，服务器110可以在图2中所示的计算设备200上实现。

在一些实施例中，服务器110可以包括处理引擎111。该处理引擎111可以处理与服务请求相关的信息和/或数据以执行在本申请中的一个或者多个功能。例如，处理引擎111可以基于服务请求中的出发地和目的地生成关于服务请求的，具有第一预估价格的订单。又例如，处理引擎111可以将订单添加到第一队列中。作为又一示例，当用户选择通过提高服务费来选择加速订单时，处理引擎111可以将订单添加到第二队列。在一些实施例中，处理引擎111可包括一个或以上处理引擎(例如，单核处理引擎或多核处理器)。处理引擎111可以包括中央处理单元(CPU)、专用集成电路(ASIC)、专用指令集处理器(ASIP)、图形处理单元(GPU)、物理处理单元(PPU)、数字信号处理器(DSP)、现场可编程门阵列(FPGA)、可编程逻辑器件(PLD)、控制器、微控制器单元、精简指令集计算机(RISC)、微处理器等中的一种或多种的组合。

网络120可以促进信息和/或数据的交换。在一些实施例中，车辆分配系统100(例如，服务器110、用户终端130、司机终端140和存储器150)中的一个或以上组件可以通过网络120发送信息和/或数据到车辆分配系统100中的其他组件。例如，服务器110可以通过网络120从请求者终端130获得/获取服务请求。在一些实施例中，网络120可以是任何类型的有线、无线网络或其组合。网络120可以包括电缆网络、有线网络、光纤网、电信网络、内联网、互联网、局域网络(LAN)、广域网(WAN)、无线局部区域网络(WLAN)、城域网(MAN)、公共电话交换网(PSTN)、蓝牙网络、ZigBee网络、近场通信(NFC)网络等中的一种或多种的组合。在一些实施例中，网络120可以包括一个或多个网络接入点。例如，网络120可以包括有线或无线网络接入点，如基站和/或互联网交换点120-1、120-2等等，通过交换点，车辆分配系统100的一个或以上部件可以连接到网络120以交换数据和/或信息。

在一些实施例中，服务请求者可以是用户终端130的用户。在一些实施例中，用户终端130的用户可以是不同于服务请求者的人。例如，用户终端130的用户A可以使用用户终端130来发送用户B的服务请求，或者从服务器110接收服务和/或信息或指令。在一些实施例中，服务提供者可以是司机终端140的用户。在一些实施例中，司机终端140的用户可以是服务提供者以外的其他人。例如，司机终端140的用户C可以使用司机终端140从服务器110接收用户D的服务请求，和/或信息或指令。

用户终端130可以被配置为从用户接收出发地和/或目的地的输入。可选地，用户终端130可以从服务器110接收指令以获得出发地和/或目的地。在一些实施例中，用户终端130可以向处理引擎111发送服务请求。服务请求可以包括出发地、目的地、用户终端130的用户标识、服务时间、用户终端130发起服务请求的位置、服务类型等中的一种或多种的组合。又例如，用户终端130可以接收由该处理引擎111发出的不同的显示指令(例如，第一显示指令、第二显示指令、第三显示指令、第四显示指令、第五显示指令)。

在一些实施例中，用户终端130可以包括移动设备130-1、平板计算机130-2、膝上型计算机130-3、机动车辆内置装置130-4等中的一种或多种的组合。在一些实施例中，移动设备130-1可以包括智能家居设备、可穿戴设备、智能移动设备、虚拟现实设备、增强现实设备等中的一种或多种的组合。在一些实施例中，智能家居装置可以包括智能照明设备、智能电器的控制设备、智能监控设备、智能电视、智能摄像机、对讲机等中的一种或多种的组合。在一些实施例中，可穿戴设备可包括智能手镯、智能鞋袜、智能眼镜、智能头盔、智能手表、智能衣物、智能背包、智能配饰等中的一种或多种的组合。在一些实施例中，智能移动设备可以包括移动电话、个人数字助理(PDA)、游戏设备、导航设备、销售点(POS)设备等中的一种或多种的组合。在一些实施例中，虚拟现实设备和/或增强现实设备可以包括虚拟现实头盔、虚拟现实眼镜、虚拟现实眼罩、增强现实头盔、增强现实眼镜、增强现实眼罩等中的一种或多种的组合。例如，虚拟现实设备和/或增强现实设备可以包括GoogleGlass^TM、OculusRift^TM、Hololens^TM、GearVR^TM等。在一些实施例中，机动车辆内置设备130-4可以包括车载计算机、车载电视等。在一些实施例中，用户终端130可以是带有定位技术的设备，该定位技术可以用于定位请求者和/或请求者终端130的位置。

在一些实施例中，司机终端140可以是具有用来确定司机或者司机终端140位置的定位技术的装置。在一些实施例中，用户终端130和/或司机终端140可以与其他定位设备通信以确定服务请求者、用户终端130、司机和/或司机终端140的位置。在一些实施例中，乘客终端130和/或司机终端140可以将定位信息发送至服务器110。

存储器150可以存储与服务请求有关的数据和/或指令。在一些实施例中，存储器150可以存储从用户终端130和/或司机终端140获得的数据。在一些实施例中，储存器150可以储存服务器110执行或使用的数据和/或指令，以执行本申请中描述的是示例性方法。例如，存储器150可以被配置为存储历史等待数据。历史等待数据可以包括与至少两个历史订单有关的历史信息，例如，历史订单的出发地、历史订单的目的地、历史订单的订单类型、与历史订单的状态相关的历史信息等中的一种或多种的组合。

在一些实施例中，储存器150可包括大容量储存器、可移式储存器、易失性读写内存、只读存储器(ROM)等中的一种或多种的组合。示例性的大容量储存器可以包括磁盘、软盘、光盘、固态磁盘等。示例性可移式存储器可以包括闪存驱动器、软盘、光盘、存储卡、压缩磁盘、磁带等。示例性的易失性读写存储器可以包括随机存储器(RAM)。示例性的RAM可包括动态RAM(DRAM)、双倍速率同步动态RAM(DDRSDRAM)、静态RAM(SRAM)、晶闸管RAM(T-RAM)和零电容RAM(Z-RAM)等。示例性的ROM可以包括掩蔽型ROM(MROM)、可编程ROM(PROM)、可擦可编程ROM(PEROM)、电可擦可编程ROM(EEPROM)、光盘ROM(CD-ROM)和数字多功能磁盘ROM等。在一些实施例中，存储器150可以在云平台上实现。仅作为示例，云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多云等中的一种或多种的组合。

在一些实施例中，存储器150可以连接到网络120以与车辆分配系统100中的一个或以上组件(例如，服务器110、用户终端130、司机终端140)通信。车辆分配系统100中的一个或以上组件可以通过网络120访问存储在存储器150中的数据和/或指令。在一些实施例中，存储器150可以直接连接到车辆分配系统100(例如，服务器110，用户终端130，司机终端140)中的一个或以上组件或与之通信。在一些实施例中，储存器150可以是服务器110的一部分。

在一些实施例中，车辆分配系统100中的一个或以上组件(例如，服务器110、用户终端130、司机终端140)可以访问存储器150。在一些实施例中，当满足一个或以上条件时，车辆分配系统100中的一个或以上组件可以读取和/或修改与服务请求者、司机和/或公众有关的信息。例如，在完成一个服务后，服务器110可以读取和/或修改一个或以上用户的信息。又例如，当从乘客终端130接收到一个服务请求时，司机终端140可以访问与请求者相关的信息，但司机终端140不能修改请求者的相关信息。

在一些实施例中，可以通过请求服务来实现交换车辆分配系统100的一个或以上组件的信息交换可以通过请求服务的方式实现。服务请求的客体可以为任一产品。在一些实施例中，该产品可以是有形产品或无形产品。有形产品可以包括食物、医药、商品、化学产品、电器、衣物、汽车、房屋、奢侈品等中的一种或多种的组合。无形产品可以包括服务产品、金融产品、知识产品、互联网产品等中的一种或多种的组合。互联网产品可以包括个人主机产品、网站产品、移动互联网产品、商业主机产品、嵌入式产品等中的一种或多种的组合。移动互联网产品可以用于移动终端的软件、程序、系统等中的一种或多种的组合。移动终端可以包括平板计算机、膝上型计算机、移动手机、掌上计算机(PDA)、智能手表、销售点(POS)设备、车载计算机、车载电视、可穿戴设备等中的一种或多种的组合。例如，产品可以是在计算机或移动电话上使用的任一软件和/或应用。软件和/或应用可以与社交、购物、运输、娱乐、学习、投资等中的一种或多种的组合相关。在一些实施例中，与运输相关联的软件和/或应用可以包括旅游软件和/或应用程序、车辆调度软件和/或应用程序、地图软件和/或应用程序等。在车辆调度软件和/或应用程序中，车辆可包括马、马车、人力车(例如，独轮手推车、自行车、三轮车)、汽车(例如，出租车、公共汽车、私家车)、火车、地铁、船、飞机(例如，飞机、直升机、航天飞机、火箭、热气球)等中的一种或多种的组合。

图2示是根据本申请的一些实施例所示的计算设备200(例如，服务器110)的示例性硬件和/或软件组件的框图。本实施例中的车辆分配系统可以使用功能框图来解释包含一个或多个用户界面的硬件平台。计算机可以是一个通用计算机，也可以是专用计算机。两种计算机都可以被用于实现本申请中的车辆分配系统。计算设备200可以被配置用于实现当前描述的车辆分配所需的信息的任一元件。例如，服务器110可以由诸如计算设备200的计算机的硬件设备、软件程序、固件或其任何组合来实现。仅作为示例，被配置为用于实现服务器110的计算设备200可以基于历史等待数据确定订单的估计等待时间。例如，计算设备200可以根据算法处理历史等待数据以确定订单的估计等待时间。该算法可以包括聚类分析、因子分析、相关分析、对应分析、回归分析、方差分析等中的一种或多种的组合。又例如，计算设备200可以确定第一队列中的估计等待时间大于时间阈值(例如，第一时间阈值、第二时间阈值、第三时间阈值、第四时间阈值)。为简洁起见，图2仅描绘了一台计算机。在一些实施例中，描述的与按需服务的相关的计算机功能可以以分散方式在一组相似的平台上实施，以分散处理负载。

计算设备200可以包括与网络相连接并促进数据通讯的通讯端口250。计算设备200以包括一个中央处理器CPU，可以以一个或以上处理器的形式执行程序指令。示意性计算机平台可以包括内部通信总线210、不同形式的程序存储器和数据存储器，例如，硬盘270、ROM 230、RAM 240，用于存储由计算机处理和/或传输的各种各样的数据文件，以及可能由CPU执行的一些程序指令。计算设备200还可以包括输入/输出设备260，用于支持计算机与其他组件(例如，用户界面)之间的数据流的输入和输出。此外，计算设备200可以通过通信网络接收程序和数据。

图3示出了移动设备300的示例性硬件和/或软件组件的框图，根据本申请的一些实施例，可以在其上实现用户终端130或司机终端140。移动设备300可以包括但不限于智能手机、平板电脑、音乐播放器、便携式游戏机、GPS接收器、可穿戴计算设备(例如眼镜，手表)等。移动设备300可以包括一个或以上CPU 340、一个或以上GPU 330、显示器320、存储器360、天线310(例如，无线通信单元)、存储单元390、以及一个或以上输入/输出(I/O)设备350。此外，移动设备300还可以是任何其他合适的组件，包括但不限于系统总线或控制器(图3中未示出)。如图3所示，移动操作系统370(例如，IOS、Android、WindowsPhone)和一个或以上应用程序380可以从存储单元390加载到存储器360并由CPU 340执行。应用程序380可以包括浏览器或其他移动应用程序，其被配置为接收和处理与移动设备300中的位置有关的信息。

为了实现上述各种模块、单元及其功能时，计算机硬件平台可以用作一个或以上元件的硬件平台(例如在图1的服务器110和/或车辆分配系统100的其他部分)中。由于这些硬件元件，操作系统和程序语言是常见的；可以假设本领域技术人员可以熟悉这些技术，并且他们可以根据本申请中描述的技术提供车辆分配中所需的信息。具有用户界面的计算机可以用作个人计算机(PC)或其他类型的工作站或终端设备。在正确编程之后，具有用户界面的计算机可以用作服务器。可以认为本领域技术人员也可以熟悉这种类型的计算机设备的这种结构、程序或一般操作。因此，没有针对附图描述额外的解释。

图4是根据本申请的一些实施例所示的示例性处理引擎111的示意性框图。处理引擎111可包括接收模块410、订单生成模块420、分配模块430和发送模块440。接收模块410、订单生成模块420、分配模块430和发送模块440可以是处理引擎111的全部或部分的硬件电路。接收模块410、订单生成模块420、分配模块430和发送模块440还可以实现为由处理引擎111读取和执行的应用程序或指令集。此外，接收模块410、订单生成模块420、分配模块430和发送模块440可以是硬件电路和应用/指令的任何组合。例如，当处理引擎正在执行指令的应用/集合时，接收模块410、订单生成模块420、分配模块430和发送模块440可以是处理引擎111的一部分。

在一些实施例中，接收模块410可以被配置为从系统100中的一个或以上组件(例如，用户终端130、司机终端140、存储器150等)接收和/或发送与服务请求有关的信息。例如，接收模块410可以从用户终端130接收服务请求。服务请求可以包括出发地、目的地、用户终端130的用户标识、服务时间、用户终端130发起服务请求的位置、服务类型等中的一种或多种的组合。在一些实施例中，出发地和/或目的地可以包括物理地址、或由经度和纬度信息表示的地理位置。用户终端130可以包括终端(例如，诸如智能电话、平板电脑、膝上型电脑等的无线设备)。由用户(例如，乘客、服务请求者)使用并发起服务请求。例如，用户终端130可以用应用程序来实现，通过该应用程序启动服务请求。

又例如，接收模块410可以获得历史等待数据。在一些实施例中，接收模块410可以从车载设备、市政交通系统、特定数据库(例如，存储装置150)等中的一种或多种的组合获得历史等待数据。特定数据库可以被配置为用于存储和分析大量的历史等待数据的数据库。历史等待数据的详细描述可以在本申请的其他地方找到(例如，结合图5)。

订单生成模块420可以基于出发地和目的地生成关于具有第一预估价格的服务请求的订单。在一些实施例中，订单可以包括响应于不同的服务请求的不同类型的订单。不同服务请求的详细描述可以在本申请的其他地方找到(例如，结合图5)。在一些实施例中，订单生成模块420可以基于出发地、目的地、服务时间、服务类型等中的一种或多种的组合来确定第一预估价格。确定第一预估价格的详细描述可以在本申请的其他地方找到(例如，结合图5)。

分配模块430可以被配置为针对订单将车辆分配给用户终端。分配模块430可以包括第一队列单元431和第二队列单元433。第一队列单元431可以被配置为处理与第一队列中的订单相关的数据。例如，第一队列单元431可以将订单添加到第一队列中用以分配车辆。第一队列可以包括按顺序等待处理的一堆订单。又例如，第一队列单元431可以确定第一队列的排队模式，并将订单添加到第一队列中。排队模式可以包括关于订单的确认时间的严格排队模式和关于订单的权重的非严格排队模式。作为又一示例，第一队列单元431可以确定第一队列中的估计等待时间是否大于第二时间阈值、第一队列中的当前等待时间是否大于第三时间阈值和/或第四时间阈值、订单是否满足第一条件等，或其任何组合。

第二队列单元433可以被配置为处理与第二队列中的订单相关的数据。例如，如果第二队列单元433接收到具有第二预估价格的供选择的出行建议的选择，则第二队列单元433可以将订单添加到第二队列。第二队列和第二预估价格的详细描述可以在本申请的其他地方找到(例如，结合图15)。

发送模块440可以被配置为向用户终端130发送与服务请求有关的信息和/或数据。发送模块440可以包括第一发送单元441、第二发送单元443、第三发送单元445、第四发送单元447和第五发送单元449。第一发送单元441可以被配置为向用户终端130发送第一显示指令。第一显示指令可以指示用户终端130显示与订单的状态相关的信息。在一些实施例中，当订单之前的第一队列中的等待订单的数量大于订单阈值时，第一发送单元441可以将第一显示指令发送到用户终端130。在一些实施例中，当前等待时间大于第一时间阈值时，第一发送单元441可以将第一显示指令发送到用户终端130。在一些实施例中，当在预定情况下生成订单时，第一发送单元441可以将第一显示指令发送到用户终端130。在一些实施例中，第一发送单元441可以向用户终端130重新发送新的第一显示指令。

第二发送单元443可以被配置为当在订单之前的第一队列中的等待订单的数量小于订单阈值，或者第一队列中的估计的等待时间小于第一时间阈值时，向用户终端130发送第二显示指令。关于订单阈值，第一时间阈值的详细描述可以在本申请的其他地方找到(例如，结合图5)。第二显示指令可以指示用户终端130显示车辆分配状态。

在一些实施例中，第二发送单元443可以被配置为在正常时间期间将第二显示指令直接发送到用户终端130。正常时间可以指可用车辆的数量大于或近似等于队列中的订单数量(例如，第一队列、第二队列等)的时间段。

第三发送单元445可被配置为当第一队列中的估计等待时间大于第二时间阈值时，向用户终端130发送第三显示指令。第三显示指令可以指示用户终端130向用户显示一个或以上建议，以供选择以完成服务请求。一个或以上建议可以包括一个或以上替代出行模式，例如拼车、共享班车服务或任何其他类型的服务，以及与其相关的信息。

第四发送单元447可以被配置为当第一队列中的当前等待时间大于第三时间阈值时，可以向用户终端130发送第四显示指令。第四显示指令可以指示用户终端130显示关于是否继续等待的询问。

当订单满足第一条件时，第五发送单元449可以被配置为向用户终端130发送第五显示指令。第五显示指令可以指示用户终端130向用户显示供选择的出行建议，以便针对具有第二预估价格的服务进行选择。

处理引擎111中的模块和/或单元可以通过有线连接或无线连接彼此连接或通信。有线连接可以包括金属线缆、光缆、混合电缆等或其任意组合。无线连接可以包括局域网络(LAN)、广域网路(WAN)、蓝牙、Zigbee，近场通讯(NFC)等中的一种，或类似或其任意组合。两个或以上的模块和/或单元可以组合为单个模块，并且任何一个模块可以分为两个或以上单元。例如，第一队列单元431可以集成在第二队列单元433中作为一个模块，可以将车辆分配给用户终端。发送模块440中的五个发送单元的两个或以上可以集成为一个单元，以将显示指令发送到用户终端。

图5是根据本申请的一些实施例所示的用于为服务请求分配车辆的示例性过程500的流程图。在一些实施例中，过程500中的一个或以上步骤可以在图1中所示的车辆分配系统100中实现。例如，过程500中的一个或以上步骤可以作为指令的形式存储在存储器150和/或存储器(例如，ROM 230、RAM 240等)中，并且被调用和/或由服务器110执行(例如，服务器110中的处理引擎111、或服务器110中的处理引擎111的CPU 220)。

在510中，处理引擎111(或接收模块410)可以从用户终端接收服务请求。服务请求可以包括出发地、目的地、用户终端的用户标识、服务时间、用户终端发起服务请求的位置、服务类型等，或者任意组合它们。在一些实施例中，出发地和/或目的地可以包括物理地址、或由经度和纬度信息表示的地理位置。

用户终端可以包括用户(例如，乘客、服务请求者)使用的终端(例如，诸如智能手机、平板电脑，膝上型计算机等的无线设备)来发起服务请求。例如，用户终端可以用启动服务请求的应用程序来实现。例如，当用户打算通过按需服务从兴华胡同前往北海北门时，用户可以在安装在用户的移动手机中的应用程序中输入出发地兴华胡同和目的地北海北门。用户可以通过输入文本、录音语音、通过GPS自动定位选择并在安装在用户移动手机中的地图应用中显示的位置，基于用户的历史使用，从所述应用程序推荐的一个或多个地点中选择的地址，或其任何组合，来输入出发地和/或目的地。然后，用户可以通过应用程序将包括出发地和目的地的服务请求发送到处理引擎111。

在520中，处理引擎111(或订单生成模块420)可以基于出发地和目的地生成具有第一预估价格的服务请求的订单。

在一些实施例中，一旦确认包括出发地和目的地的服务请求，处理引擎111就可以生成订单。在一些实施例中，订单可以包括响应于不同的服务请求的不同类型的订单。例如，订单可以包括出租车订单、拼车订单、代驾订单等。又例如，订单可以包括基于用户终端的用户标识符的个人订单和企业订单。作为又一示例，订单可以包括基于出发地和服务时间的活动订单。活动订单可以由服务时间相同和/或大致相同、出发地相同和/或大致相同的至少两个用户发起。例如，当音乐会或聚会结束时，大量的用户可以发送至少两个服务请求。处理引擎111可以基于至少两个服务请求生成至少两个活动订单。

在一些实施例中，处理引擎111可以基于出发地、目的地、服务时间、服务类型等或其任何组合来确定第一预估价格。例如，处理引擎111可以基于出发地和目的地之间的行驶距离来确定第一预估价格。作为又一示例，处理器可以基于出发地和目的地之间的行驶距离以及服务时间来确定第一预估价格。作为又一示例，处理器可以基于出发地和目的地之间的行驶距离以及服务类型来确定第一预估价格。

在530中，处理引擎111(或分配模块430、第一队列单元431)可以将订单添加到第一队列中用以分配给车辆。

在一些实施例中，处理引擎111可以确定第一队列的排队模式，并将订单添加到第一队列中。排队模式可以包括关于订单的确认时间的严格排队模式。第一队列可以包括按顺序等待处理的一堆订单。订单越早被确认，订单就越早在第一队列中，订单处理就越快。例如，根据第一队列的严格排队模式，在早上9:00确认的订单，则在第一队列中，该订单可能会在早上9:06确认的订单之前并在早上08：57之后确认的订单之后。在一些实施例中，排队模式可以包括关于订单的权重的非严格排队模式。订单加权越大，订单在第一队列中越早，即订单处理越快。订单的权值可以与出发地、订单的目的地、出发地和目的地之间的行驶距离、生成订单的区域等相关。例如，具有相对长的驾驶距离的订单可以具有比具有相对短的驾驶距离的订单更大的权值。因此，在第一队列中，具有相对长的行驶距离的订单可以在相对短的行驶距离的订单之前。在一些实施例中，处理引擎111可以基于实时情况动态地确定第一队列的排队模式。例如，在供不应求情况下(例如，下雨天、当大量用户请求服务时的下雪天)，处理引擎111可以将订单添加到待分配的第一队列中。又例如，在可用车辆的数量足以供应请求服务的用户的情况下，处理引擎111可以根据非严格排队模式将订单添加到第一队列中用以分配给车辆。

在一些实施例中，第一队列可以包括基于不同订单的至少两个第一子队列。至少两个第一子队列可包括出租车队列、拼车队列、司机队列、个人队列、企业队列、活动队列等，或其任何组合。例如，处理引擎111可以将出租车订单添加到第一队列的出租车队列中以分配给出租车。又例如，处理引擎111可以将活动订单添加到待分配车辆的第一队列的活动队列中。在一些实施例中，不同的子队列可以具有不同的排队模式，这些模式导致子队列中的订单的不同处理优先级。例如，在同一时间或大约同一时间，在音乐会结束时间周围的活动队列中的订单可以比出租车队列中的订单被处理得更快。

在540中，处理引擎111(或发送模块440、第一发送单元441)可以向用户终端发送第一显示指令。第一显示指令可以指示用户终端显示与订单的状态相关的信息。与订单的状态相关的信息可以包括第一预估价格、第一队列中在所述订单前的正在等待的订单的数量、第一队列中所述订单的估计等待时间、第一队列中正在等待的订单的总数、或者第一队列中可用于接单的当前可用车辆的数量，或其任何组合。确定第一队列中所述订单的估计等待时间的详细描述可以在本申请的其他地方找到(例如，结合图8)。

在一些实施例中，处理引擎111(或发送模块440、第一发送单元441)可以在当第一队列中订单之前的正在等待的订单的数量大于订单阈值时，将第一显示指令发送到用户终端。订单阈值可以是在系统100中配置为应用于所有订单的预定值。或者，可以基于与订单相关的信息(例如，区域、服务时间等)动态地确定订单阈值。又例如，订单阈值可以在不同区域和/或不同服务时间中变化。在一些实施例中，可以基于出发地来确定该区域。例如，处理引擎111可以将地图划分为至少两个网格。该区域可以包括出发地点位于地图中的一个网格，出发地位于其在地图中的一个或以上相邻网格，地图上以出发地为中心、具有预设半径的圆形区域，或基于经度和纬度信息划分的区域等。

在一些实施例中，当当前等待时间大于第一时间阈值时，处理引擎111(或发送模块440、第一发送单元441)可以将第一显示指令发送到用户终端。第一时间阈值可以是在系统100中配置为应用于所有订单的预定值。或者，可以基于与订单相关的信息(例如，区域、服务时间等)动态地确定第一时间阈值。又例如，第一时间阈值可以在不同区域和/或不同服务时间中变化。

在一些实施例中，当在预定情况下生成订单时，处理引擎111(或发送模块440、第一发送单元441)可以将第一显示指令发送到用户终端。例如，当在第一队列中接受订单的可用车辆被过度预订时，处理引擎111可以发送第一显示指令。又例如，处理引擎111可以在一天中的高峰时间(例如，上午7:30至上午9:30，下午5:00至下午7:00)、下雨天或者下雪天发送第一显示指令等。高峰时间可以指队列中可用车辆的数量小于队列中的订单数量的时间段。

在一些实施例中，与订单状态相关的信息还可以包括第二预估价格、第二队列中所述订单前的正在等待的订单的数量、第二队列中的所述订单的估计等待时间、第二队列中正在等待的订单的总数、或第二队列中可用于接单的当前可用车辆的数量，或其任何组合。第二预估价格可以高于第一预估价格。第二队列可以与第二服务类型或车辆分配的另一种方式相关。确定第二队列中订单的估计等待时间的详细描述可以在本申请的其他地方找到(例如，结合图8)。

在一些实施例中，用户可以刷新与订单的状态相关的信息。处理引擎111(或发送模块440、第一发送单元441)可以向用户终端重新发送新的第一显示指令。所述第一显示指令可以包括与订单的状态相关的当前信息。在一些实施例中，车辆分配系统100(或处理引擎111)可以定时自动刷新与订单的状态相关的信息。刷新信息的频率可以由处理引擎111预先确定或由用户手动确定。

图6是根据本申请的一些实施例所示的用于在队列中为订单分配车辆的示例性过程的示意图。

一旦确认了包括出发地和目的地的服务请求，处理引擎111(或订单生成模块420)可以基于服务请求生成订单并将订单添加到第一队列中以分配车辆。如图6所示，可以根据时间顺序发送来自用户终端的订单并将其放入车辆队列中。越早发送订单，该订单越早处于第一队列中，即订单越早被分配车辆。其他类型的订单，如拼车订单、被拒绝的订单等，可以被赋予更高的优先级并且被放在车辆队列中的出租车订单前面。又例如，在将订单分配给服务提供者之后，服务提供者可以拒绝向服务请求者提供服务。在这种情况下，处理引擎111可以为拒绝的订单分配更高的优先级，并将拒绝的订单放回第一队列中以进行重新分配。处理引擎111可以将拒绝的订单放在第一队列的顶部以分配第一可用车辆。在一些实施例中，处理引擎111可以确定分配规则，为车辆队列中的被拒绝的订单和拼车订单分配车辆。例如，如果在同一时间或大约同时请求拼车订单和被拒绝的订单，则如果拼车订单已经有多于一名乘客，则处理引擎111可以为拼车订单分配比被拒绝的订单更高的优先级。又例如，如果拼车订单没有除所述服务请求者之外的任何乘客，则处理引擎111可以为被拒绝的订单分配比拼车订单更高的优先级。

在一些实施例中，车辆队列中的订单可包括各种类型，例如出租车订单、拼车订单、代驾订单、被取消的订单等。在一些实施例中，车辆队列可包括出租车队列、拼车队列、司机队列、个人队列、企业队列、活动队列等。

图7是根据本申请的一些实施例的用户终端的示例性用户界面。用户界面可以在高峰时间显示与订单的状态相关的信息。可以通过结合图5的第一显示指令来指示与订单的状态相关的信息。

在生成订单并将订单添加到基于服务请求分配给车辆的第一队列之后，处理引擎111(或发送模块440、第一发送单元441)可以发送第一显示指令到用户终端。显示指令可以指示用户终端在用户界面上显示与订单相关的信息。图7示出了与用户界面上的订单相关的至少两条信息。“等待应答”可以指示用户此时可能必须等待被分配给车辆。“分配车辆的高峰时间；您的编号：100，总共120人排队；在5分钟内应答”可以指在第一队列中订单之前的正在等待的订单的数量可以是99，第一队列中的正在等待的订单的总数可以是120，并且显示所述订单状态时间或前后，所述订单在第一队列中估计的等待时间可以是5分钟。“兴华胡同”可以指示订单的出发地是兴华胡同。“等待00:20；为您搜索车辆”可以指示用户可能已等待20秒。由于第一队列中的订单的估计等待时间是5分钟，因此在处理引擎111将车辆分配给用户之前，用户将不得不等待大约4分40秒。用户可以通过在用户界面的触摸屏上按下“取消订单”来取消订单。

应当注意与图7中显示的订单的状态相关的信息仅仅是出于说明目的而提供的，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，根据本申请的教导可以做出多种变形和修改。然而，变形和修改不会背离本申请的范围。例如，与订单的状态相关的信息可以以各种方式显示，例如图片、文字、图标、颜色等，或其任何组合。

在一些实施例中，用户可以手动刷新与订单的状态相关的显示信息。在一些实施例中，车辆分配系统100可以自动刷新与订单的状态相关的显示信息。自动刷新与订单状态相关的信息的频率可以由处理引擎111预先确定或由用户手动确定。例如，可以每5秒、每10秒、每15秒等刷新与订单状态相关的显示信息。在一些实施例中，一旦订单被处理并被分配车辆，显示的信息就可以被刷新。

图8是根据本申请的一些实施例所示的用于确定订单的估计等待时间的示例性过程800的流程图。在一些实施例中，过程800中的一个或以上步骤可以在图1中所示的车辆分配系统100中实现。例如，过程800中的一个或以上步骤可以存储在存储器150和/或存储器(例如，ROM 230、RAM 240等)中)作为指令的形式，并且由服务器110调用和/或执行(例如，服务器110中的处理引擎111、或服务器110中的处理引擎111的CPU 220)。

在810中，处理引擎111(或接收模块410)可以获得历史等待数据。在一些实施例中，处理引擎111可以从车载设备、市政交通系统、特定数据库等或其任何组合获得历史等待数据。特定数据库可以指被配置为用于存储和分析大量的历史等待数据的数据库。历史等待数据可以包括与至少两个历史订单相关的历史信息，例如，每个历史订单的出发地、每个历史订单的目的地、每个历史订单的订单类型、与每个历史订单的状态等相关的历史信息，或其任何组合。与每个历史订单的状态相关的历史信息可以包括第一队列中的每个订单的历史等待时间、第一队列中的历史等待订单的总数、以及第一队列中历史可用车辆的数量等，或其任何组合。与每个历史订单的状态相关的历史信息还可以包括第二队列中每个订单的历史估计等待时间、第二队列中历史等待订单的总数、以及第二队列中历史可用车辆的数量等，或其任何组合。

在820中，处理引擎111(或分配模块430)可以基于历史等待数据确定订单的估计等待时间。例如，处理引擎111可以根据算法处理历史等待数据。该算法可以包括聚类分析、因子分析、相关分析、对应分析、回归分析、方差分析等，或其任何组合。聚类分析可以包括分区方法、分层方法、基于密度的方法、基于网格的方法、基于模型的方法等。因子分析可以包括k均值算法、期望最大化等。又例如，处理引擎111可以获得其特征与待估计的订单相同或相似的至少两个历史订单。例如，处理引擎111可以获得在相同或相似时间并且在相同或相似的起始区域内请求的相同订单类型的历史订单。处理引擎111可以确定这些订单的历史等待时间的平均值，以将其设置为订单的估计等待时间。

在一些实施例中，订单的估计等待时间可以表明在队列(例如，第一队列、第二队列)中所述订单将被处理的的实际时长。例如，当订单的估计等待时间是3分15秒时，在车辆分配系统100将车辆分配给订单之前，用户可能不得不等待3分15秒。

在一些实施例中，估计的等待时间可以表明在队列中(例如，第一队列、第二队列)，所述订单将被处理的一个最接近阈值的时间段。当基于历史等待数据的订单的估计等待时间在0到59秒的范围内时，在用户终端显示的估计时间可以是1分钟。例如，当基于历史等待数据估计的订单等待时间是30秒时，在用户终端显示的估计时间可以是1分钟。当基于历史等待数据的订单的估计等待时间在1分钟至1分59秒的范围内时，在用户终端显示的估计时间可以是3分钟。例如，当基于历史等待数据的订单的估计等待时间是1分40秒时，在用户终端显示的估计时间可以是3分钟。当基于历史等待数据的订单的估计等待时间在2分钟到4分59秒的范围内时，在用户终端显示的估计时间可以是5分钟。例如，当基于历史等待数据的订单的估计等待时间是3分30秒时，在用户终端显示的估计时间可以是5分钟。当基于历史等待数据的订单的估计等待时间在5分钟到8分59秒的范围内时，在用户终端显示的估计时间可以是10分钟。当基于历史等待数据的订单的估计等待时间在9分钟到10分钟的范围内时，在用户终端上显示的估计时间可以是11分钟。

在一些实施例中，处理引擎111可以在每个预定的时间间隔更新历史等待数据。预定时间间隔可以是在系统100中被配置为预定值，以应用于所有订单。或者，可以基于与订单相关的信息(例如，区域、服务时间，订单类型等)来动态地确定预定的时间间隔。又例如，预定时间间隔可以在不同区域、不同服务时间、不同订单类型等或其任何组合。在一些实施例中，处理引擎111可以在道路重建完成之后更新历史等待数据。例如，当新铁路开通时，可以改变与新铁路相关联的不同道路的道路状况。又例如，主要拥挤道路可能变成不太拥挤的道路，因此，可以改变与较不拥挤的道路相关联的估计的订单等待时间。处理引擎111可以基于更新的历史等待数据确定订单的估计等待时间。

应该理解，估计的等待时间可以随着用户等待的时间而变化。例如，用户等待的时间越长，估计的等待时间可能越短。例如，当用户等待1分钟时，估计的等待时间是2分钟。当用户等待1.5分钟时，估计的等待时间是1.5分钟。又例如，用户等待的时间越长，在订单之前第一队列中的等待订单的数量就越少。例如，当用户等待1分钟时，订单前第一队列中的等待订单数量为50。当用户等待2分钟时，在订单之前的第一队列中的等待订单的数量是20。

图9是根据本申请的一些实施例所示的用于向用户终端130发送显示指令的示例性过程900的流程图。在一些实施例中，过程900中的一个或以上步骤可以在图1中所示的车辆分配系统100中实现。例如，过程900中的一个或以上步骤可以存储在存储器150和/或存储器(例如，ROM 230、RAM 240等)中。作为指令的形式，并且由服务器110调用和/或执行(例如，服务器110中的处理引擎111、或服务器110中的处理引擎111的CPU 220)。

在910中，处理引擎111(或分配模块430、第一队列单元431)可以确定第一队列中在订单之前的的正在等待的订单的数量小于订单阈值，或者在第一队列中估计等待时间小于第一时间阈值。订单阈值和/或第一时间阈值的详细描述可以在本申请的其他地方找到(例如，结合图5)。

在一些实施例中，在某些情况下，处理引擎111可以确定在第一队列中订单之前的的正在等待的订单的数量小于订单阈值或者在第一队列中的估计等待时间小于第一时间阈值，例如在高峰时段(例如，在一天中的上午7:30至上午9:30，下午5:00至晚上8:00)、下雨天或下雪天等。

在920中，处理引擎111(或发送模块440、第二发送单元443)可以向用户终端发送第二显示指令。第二显示指令可以指示用户终端显示车辆分配状态。车辆分配状态可以指示车辆分配系统100正在为用户分配车辆。与车辆分配状态相关的其他信息，例如在第一队列中订单之前的的正在等待的订单的数量、订单在第一队列中的估计等待时间、在第一队列中的正在等待的订单的总计数、第一队列中可用于接单的当前可用车辆的数量、用户等待的时间等或其任何组合，可以与车辆分配状态一起显示。

仅作为示例，订单阈值被配置为4。当第一队列中的等待订单的数量小于4(例如，1、2、3)时，其表示在订单之前的队列中仅存在少于4的订单，处理引擎111可以将第二显示指令发送到用户终端。又例如，第一时间阈值是59秒。当第一队列中的估计等待时间小于59秒(例如，30秒、45秒等)其指示车辆分配系统100将很快为订单分配车辆，处理引擎111可以将第二显示指令发送到用户终端。

图10是根据本申请的一些实施例的用户终端的示例性用户界面。用户界面可以在高峰时间显示与车辆分配状态相关的信息。可以通过结合图9的第二显示指令来指示与车辆分配状态相关的信息。

如图10所示，“等待应答”可以指示用户此时可能不得不等待被分配给车辆。“分配车辆的高峰时间；你的编号：3；正在分配车辆，请等待”可以指示在订单之前第一队列中的正在等待的订单的数量是2，并且车辆分配系统100正在向用户分配车辆。“兴华胡同”可以指示订单的出发地是兴华胡同。“等待03:20；为您搜索车辆“可以指示用户可能已经等待3分20秒。用户可以通过在用户界面的触摸屏上按下“取消订单”来取消订单。

在一些实施例中，处理引擎111(或发送模块、第二发送单元443)可以在正常时间期间将第二显示指令直接发送到用户终端。正常时间可以指可用车辆的数量大于或近似等于队列中(例如，第一队列、第二队列等)的订单数量的时间段。例如，正常时间可以指除一天中的高峰时间之外的时间段。正常时间可能包括一天中的早上10点到11点，下午1点到3点等等。

图11是根据本申请的一些实施例所示的用于向用户终端130发送显示指令的示例性过程1100的流程图。在一些实施例中，过程1100中的一个或以上步骤可以在图1中所示的车辆分配系统100中实现。例如，过程1100中的一个或以上步骤可以存储在存储器150和/或存储器中(例如，ROM 230、RAM 240等)。作为指令的形式，并且由服务器110调用和/或执行(例如，服务器110中的处理引擎111、或服务器110中的处理引擎111的CPU 220)。

在1110中，处理引擎111(或分配模块430、第一队列单元431)可以确定第一队列中的估计等待时间大于第二时间阈值。在一些实施例中，第二时间阈值可以大于第一时间阈值。在一些实施例中，第二时间阈值可以是在系统100中配置为预定值以应用于所有订单，例如，10分钟、20分钟、30分钟等在一些实施例中，可以基于与订单相关的信息(诸如区域、服务时间等)来动态地确定第二时间阈值。例如，第二时间阈值可以在不同区域和/或不同服务时间中变化。

在1120中，处理引擎111(或发送模块440，第三发送单元445)可以向用户终端发送第三显示指令。第三显示指令可以指示用户终端向用户显示一个或以上建议，以供选择以完成服务请求。一个或以上建议可以包括一个或以上替代出行模式，例如拼车、共享班车服务或任何其他类型的服务，以及与其相关的信息。与拼车相关的信息可包括第一拼车预估价格、第一队列中拼车的估计等待时间等，或其任何组合。用户终端可以显示与订单的状态和与拼车有关的信息。

在一些实施例中，如果用户选择拼车，则车辆分配系统100可根据拼车分配规则分配车辆。例如，拼车分配规则可以指示必须存在至少两个用户共享同一车辆。车辆分配系统100可以根据多个拼车请求者中的服务请求时间为所述至少两个用户分配车辆。

图12是根据本申请的一些实施例的用户终端的示例性用户界面。用户界面可以显示与完成服务请求的建议有关的信息。可以通过结合图11的第三显示指令来指示与建议有关的信息。

如图12所示，“等待应答”可以指示用户此时可能不得不等待被分配给车辆。“分配车辆的高峰时间；您的编号：100，总共120人；回复超过10分钟；建议拼车”可以指示在订单之前的第一队列中的等待订单的数量是99，并且第一队列中的等待订单的总数可以是120，并且在第一队列订单的估计等待时间可能超过10分钟。如果用户想要加速订单，则用户可以通过在用户界面的触摸屏上按“拼车”来选择拼车。“兴华胡同”可以表示订单的出发地可能是兴华胡同。用户终端可以显示“等待00:20；为您搜索车辆”，并且它可以指示用户可能已经等待了20秒。用户可以通过在用户界面的触摸屏上按下“取消订单”来取消订单。

在一些实施例中，当第一队列中的订单之前的正在等待的订单的数量大于订单阈值或第一队列中估计的等待时间大于第一时间阈值时，处理引擎111可以将第三显示指令发送到用户终端。第三指令可以指示用户终端显示与订单的状态和与拼车有关的信息有关的信息。

图13是根据本申请的一些实施例所示的用于向用户终端130发送显示指令的示例性过程1300的流程图。在一些实施例中，过程1300中的一个或以上步骤可以在图1中所示的车辆分配系统100中实现。例如，过程1300中的一个或以上步骤可以存储在存储器150和/或存储器(例如，ROM 230、RAM 240等中)中。作为指令的形式，并且由服务器110调用和/或执行(例如，服务器110中的处理引擎111、或服务器110中的处理引擎111的CPU 220)。

在1310中，处理引擎111(或分配模块430、第一队列单元431)可以确定第一队列中的当前等待时间大于第三时间阈值。在一些实施例中，第三时间阈值可以大于第二时间阈值。在一些实施例中，第三时间阈值可以是在系统100中配置为预定值，以应用于所有订单，例如30分钟。40分钟、50分钟等。在一些实施例中，可以基于与订单相关的信息(诸如区域、服务时间等)来动态地确定第三时间阈值。例如，第三时间阈值可以在不同区域和/或不同服务时间中变化。

在1320中，处理引擎111(或发送模块440、第四发送单元447)可以向用户终端发送第四显示指令。第四显示指令可以指示用户终端显示关于是否继续等待的询问。当用户选择继续等待时，车辆分配系统100可以继续显示与订单的状态、与拼车有关的信息等或其任何组合有关的信息。当用户选择不等待时，车辆分配系统100可以取消订单。

图14是根据本申请的一些实施例所示的用于取消订单的示例性过程1400的流程图。在一些实施例中，过程1400中的一个或以上步骤可以在图1中所示的车辆分配系统100中实现。例如，过程1400中的一个或以上步骤可以存储在存储器150和/或存储器中(例如，ROM 230、RAM 240等)作为指令的形式，并且由服务器110(例如，服务器110中的处理引擎111、或服务器110中的处理引擎111的CPU 220)调用和/或执行。

在1410中，处理引擎111(或分配模块430、第一队列单元431)可以确定第一队列中的当前等待时间大于第四时间阈值。第四时间阈值可以大于第三时间阈值。第四时间阈值可以是在系统100中配置为预定值，以应用于所有订单，例如40分钟、50分钟、60分钟等。在一些实施例中，可以基于与订单相关的信息(诸如区域、服务时间等)来动态地确定第四时间阈值。例如，第四时间阈值可以在不同区域和/或不同服务时间中变化。在1420，处理引擎111可以取消订单。

图15是根据本申请的一些实施例所示的用于为服务请求分配车辆的示例性过程1500的流程图。在一些实施例中，过程1500中的一个或以上步骤可以在图1中所示的车辆分配系统100中实现。例如，过程1500中的一个或以上步骤可以存储在存储器150和/或存储器中(例如，ROM 230、RAM 240等)。作为指令的形式，并且由服务器110调用和/或执行(例如，服务器110中的处理引擎111、或服务器110中的处理引擎111的CPU 220)。

在1510中，处理引擎111(或分配模块430、第一队列单元431)可以确定订单满足第一条件。在一些实施例中，第一条件可以包括以下条件：区域中的正在等待的订单的总数大于该区域中第一队列可接单的车辆的数量。可以基于订单的出发地来确定该区域。例如，处理引擎111可以将地图划分为至少两个网格(例如，六边形网格)。该区域可以包括地图上出发地点所在的网格，地图上以出发地所在的一个或以上相邻网格，以出发地为中心、预定半径范围内的圆形区域，或基于经度和纬度信息划分的区域等。

在一些实施例中，第一条件可以包括以下条件：区域中的等待订单总数与该区域中第一队列中可接单的车辆数量之间的差值大于预定阈值。预定阈值可以是在车辆分配系统中配置为预定值，以应用于所有订单。或者，可以基于该区域确定预定阈值。例如，面积越大，预定阈值越大。

在一些实施例中，第一条件可以包括当前时间在预定时间段内的条件。预定时间段可以是在车辆分配系统100中配置为预定值，以应用于所有订单。或者，可以基于该区域确定预定阈值。例如，预定时间段可以包括一天内的高峰时间，例如早上7:30到9:30，下午5：00到8：00。

在一些实施例中，第一条件可以包括其他供不应求条件。例如，第一条件可以包括当大量用户请求服务时的下雨天、下雪天等。确定订单满足第一条件的详细描述可以在本申请的其他地方找到(例如，结合图18)。

在1520中，处理引擎111(或发送模块440、第五发送单元449)可以向用户终端发送第五显示指令。第五显示指令可以指示用户终端显示关于具有第二预估价格的服务的供选择的出行建议。供选择的出行建议还可以包括拼车、其他类型的服务等，或其任何组合。在一些实施例中，用户终端可以显示与具有第二预估价格的订单的状态相关的信息、与具有第一预估价格的订单的状态相关的信息、与拼车有关的信息等中的一种或多种的组合。

第二预估价格可以大于第一预估价格。在一些实施例中，第二预估价格和第一预估价格之间的差值可以是预定值。在一些实施例中，可以基于订单的路线信息确定第二预估价格和第一预估价格之间的差值。路线信息可以包括订单的出发地、订单的目的地、订单的行驶距离等，或其任何组合。例如，订单的行驶距离越长，第二预估价格与第一预估价格之间的差值越大。在一些实施例中，第二预估价格与第一预估价格之间的差值可以是由用户确定的值。例如，用户可以根据他/她自己的意愿将小费添加到第一预估价格。

在1530中，处理引擎111可以接收对具有第二预估价格的供选择的出行建议的选择。如果用户接受提高的服务费(例如，第二预估价格)，则车辆分配系统100可以加速向用户分配车辆。在一些实施例中，处理引擎111还可以接收拼车、共享班车服务，其他类型的服务等的选择。例如，用户可以同时接受所提出的服务费并选择拼车建议以加速将订单分配给车辆。

在1540中，处理引擎111(或分配模块430、第二队列单元433)可以将订单添加到第二队列中。其中第二队列中可用于接单的第二车辆数量与第二队列中第二正在等待的订单的数量的第二比率大于第一队列中可用于接单的第一车辆数量与第一队列中第一正在等待的订单的数量第一比率，这可能表明第二队列中的订单可能比第一队列中的订单更早被分配给车辆。

第二队列的排队模式可以包括关于订单的确认时间的严格排队模式和关于订单的权重的非严格排队模式。严格排队模式和/或非严格排队模式的详细描述可以在本申请的其他地方找到(例如，结合图5)。

在一些实施例中，第二队列可以包括基于不同订单的至少两个第二子队列。至少两个第二队列可包括出租车队列、拼车队列、司机队列、个人队列、企业队列、活动队列等，或其任何组合。在一些实施例中，不同的子队列可以具有不同的排队模式，这些模式引导子队列中的订单的不同处理优先级。例如，在音乐会结束时间周围的活动队列中的订单可以在同一时间或大约同时被处理得比出租车队列中的订单更快。

在一些实施例中，处理引擎111可以不接收具有第二预估价格的供选择的出行建议的选择，表明用户选择不通过接受提高的服务费以加速订单。订单可以保留在第一队列中以分配给车辆。

图16a-图16d是根据本申请的一些实施例的用户终端的示例性用户界面。用户界面可以显示与供选择的出行建议有关的信息，以完成服务请求。可以通过结合图15的第五显示指令来指示与供选择的出行建议有关的信息。

如图16a所示，“确认呼叫”可以指示用户可以确认用户界面上显示的与订单相关的信息是否正确。“快车专车出租车拼车代驾”可以指示不同的订单类型，并且用户可以从不同的订单类型中选择订单类型。“兴华胡同”可以指示订单的出发地可以是兴华胡同。“北海北门”可以指示订单的目的地可以是北海北门。“4分钟，上车位置”可以指示由处理引擎111分配的车辆将在4分钟内到达上车位置(例如，出发地)。“拼车18.0元”可以表示基于出发地的订单的第一预估价格，并且如果用户选择拼车，则到达目的地可以是18.0元。“不拼车32.8元”可以表示基于出发地的订单的第一预估价格，如果用户选择不拼车，则到达目的地可以是32.8元。例如，用户可以通过在用户界面的触摸屏上按“拼车”然后按“呼叫车辆”以确认订单来选择拼车。又例如，用户可以通过在用户界面的触摸屏上按下“不拼车”然后按“呼叫车辆”来选择不拼车。

在用户确认订单后，处理引擎111可以将订单添加到第一队列中以分配给车辆。用户界面可以显示图16b中所示的信息。“等待应答”可以指示用户此时可能不得不等待被分配给车辆。“在你前面有100人等待；在10分钟内应答”可以指示在订单之前第一队列中的正在等待的订单的数量可以是99，并且在所述订单状态被显示的时间或时间左右，第一队列中的订单的估计等待时间可以是10分钟。“添加12元；加速分配”可以指示如果用户同意将服务费提高12元，则处理引擎111可以加速将车辆分配给用户，以及第二预估价格与第一预之间的差值估价格可能是12元人民币。用户可以通过按下用户界面的触摸屏上的“取消订单”来取消订单。

当用户选择加速以分配给车辆时，用户界面可以显示图16c中所示的信息。“加速分配；请等待”可以指示订单已经加速，并且用户此时可能不得不等待被分配给车辆。“等待00:20；为您搜索车辆”可以指示用户可能已经等待了20秒。

当用户选择不加速以分配给车辆时，用户界面可以显示图16d中所示的信息。“有很多人选择加速订单，并且可用车辆不够，请等待”可以指示用户可能不得不等待相对较长的时间才能被分配给车辆。

图17是根据本申请的一些实施例所示的用于确定订单满足第一条件的示例性过程1700的流程图。在一些实施例中，过程1700中的一个或以上步骤可以在图1中所示的车辆分配系统100中实现。例如，过程1700中的一个或以上步骤可以存储在存储器150和/或存储器(例如，ROM 230、RAM 240等中)中。作为指令的形式，并且由服务器110调用和/或执行(例如，服务器110中的处理引擎111、或服务器110中的处理引擎111的CPU 220)。

在1710中，处理引擎111(或分配模块430、第一队列单元431)可以基于订单的出发地和目的地来确定区域。可以基于订单的出发地来确定该区域。例如，处理引擎111可以将地图划分为至少两个网格(例如，六边形网格)。该区域可以包括地图中出发地点所在的网格，地图中出发地所在的一个或以上相邻网格，以出发地为中心、预定半径范围内的圆形区域，或基于经度和纬度信息划分的区域等。

在1720中，处理引擎111(或分配模块430、第一队列单元431)可以从第一队列确定区域中可用于接单的车辆的数量。在1730，处理引擎111(或分配模块430、第一队列单元431)可以从第一队列确定该区域中的正在等待的订单的总数。

在1740中，处理引擎111(或分配模块430、第一队列单元431)可以确定该区域中的正在等待的订单的总数大于第一队列中该区域中可接单的可用的车辆的数量。如果该区域中的正在等待的订单的总数大于从第一队列中该区域可接单的车辆的数量，则处理引擎111可以确定订单满足第一条件。

应当理解的是，与确定订单是否满足图17中的第一条件有关的描述仅仅是出于说明目的而提供的，并不旨在限制本申请的范围。处理引擎111可以确定其他标准以确定订单是否满足第一条件。例如，处理引擎111可以进一步确定该区域中的正在等待的订单总数与该区域中第一队列中可接单的车辆数量之间的差值大于预定阈值。又例如，处理引擎111可以进一步确定当前时间在预定时间段内或在大量用户请求服务的下雨天、下雪天等等。

图18a-图18h是根据本申请的一些实施例的用户终端的示例性用户界面。当订单满足第一条件时，用户界面可以显示与供选择的出行建议有关的信息，以完成服务请求。可以通过结合图15的第五显示指令来指示与供选择的出行建议有关的信息。

当处理引擎111接收到满足第一条件的订单时，用户界面可以显示图18a所示的信息。“加价”可以指示第一队列中的可用车辆的数量可能小于第一队列中的订单数量。“添加12元，在5分钟内回复”可以表明，如果用户同意将服务费提高12元，处理引擎111可以在5分钟内加速向用户分配车辆。“添加0元，在20分钟内回复”可以指示用户可能不得不在车辆分配系统100将车辆分配给用户之前等待大约20分钟。

在用户同意提高服务费用之后，用户界面可以显示图18b中所示的信息。“4分钟，上车位置”可以指示由处理引擎111分配的车辆将在4分钟内到达上车位置(例如，出发地)。“拼车18.0元；添加12元”可以表示第一预估价格与第二预估价格之间的差值可以是12元，如果用户选择拼车，则订单的第二预估价格可以是18.0元。“不拼车32.8元；添加12元”可以指示如果用户选择不拼车，订单的第二预估价格可以是32.8元。例如，用户可以通过在用户界面的触摸屏上按下“拼车”然后按下“呼叫车辆”以确认订单来选择拼车。又例如，用户可以通过在用户界面的触摸屏上按下“不拼车”然后按“呼叫车辆”来选择不拼车。

在用户以第二预估价格呼叫车辆之后，用户界面可以显示图18c中所示的信息。用户可以通过在用户界面的触摸屏上在两分钟内按下“在2分钟内确认”来再次确认添加服务费用。

在用户重新确认添加服务费用之后，用户界面可以显示图18d中所示的信息。“加速分配；请等待”可以指示订单已经加速，并且用户此时可能不得不等待被分配给车辆。“等待00:20；为您搜索车辆”可以指示用户可能已经等待了20秒。

在用户不同意提高服务费用之后，用户界面可以显示图18e中所示的信息。“4分钟，上车位置”可以指示由处理引擎111分配的车辆将在4分钟内到达上车位置(例如，出发地)。“拼车18.0元”可以表明如果用户选择拼车，订单的第一预估价格可以是18元。“不拼车”可以指示如果用户选择不拼车，订单的第一预估价格可以是32.8元。例如，用户可以通过在用户界面的触摸屏上按“拼车”然后按下“呼叫车辆”以确认订单来选择拼车。又例如，用户可以通过在用户界面的触摸屏上按下“不拼车”然后按“呼叫车辆”来选择不拼车。

在用户通过第一预估价格呼叫车辆之后，处理引擎111可以要求用户通过提高服务费来再次确认是否加速订单。用户界面可以显示图18f中所示的信息。“有100人在你前面等候；在10分钟内应答”可以指示在订单之前第一队列中的正在等待的订单的数量可以是99，并且在显示该订单状态的时间或时间前后，第一队列中的订单的估计等待时间可以是10分钟。“添加12元；在3分钟内应答”可以指示如果用户同意将服务费用增加12元，处理引擎111可以加速以在3分钟内将车辆分配给用户。

在用户通过接受提升的服务费选择加速订单之后，如图18g所示，用户界面可以显示与图18d有关的信息。

当存在大量加速订单并且第二队列中的可用车辆的数量不足时，用户界面可以显示图18f中所示的信息。用户可以通过在用户界面的触摸屏上按“取消订单”来选择取消订单。

图19a-图19b是根据本申请的一些实施例的用户终端的示例性用户界面。当订单不满足第一条件时，用户界面可以显示与具有第一预估价格的订单的状态相关的信息、与拼车有关的信息等，或其任何组合。

如图19a所示，“分配车辆的高峰时间；你的编号：118；总共120个；在2分钟内回复”可以指示在订单之前第一队列中的正在等待的订单的数量可以是2。“拼车6元”可以表示如果用户选择拼车，基于出发地的订单的第一预估价格，则到达目的地可以是6元。“不拼车”可以指示如果用户选择不拼车，则订单的第一预估价格可以是20.8元。例如，用户可以通过在用户界面的触摸屏上按“拼车”来选择拼车。又例如，用户可以通过在用户界面的触摸屏上按“不拼车”来选择不拼车。用户可以通过在用户界面的触摸屏上按“取消订单”来取消订单。

如图19b所示，“已分配车辆；您已经等待：00：20”可以指示处理引擎111可能将车辆分配给了用户，并且用户可能已经等待了20秒。

上文已对基本概念做了描述，显然，对于阅读此申请后的本领域的普通技术人员来说，上述发明披露仅作为示例，并不构成对本申请的限制。虽然此处并未明确说明，但本领域的普通技术人员可以进行各种修改、改进、修正。这类修改、改进和修正在本申请中被建议，所以此类修改、改进、修正仍属于本申请示范实施例的精神和范围。

同时，某些术语已被用于描述本申请的实施例。例如，术语“一个实施例”、“一实施例”、和/或“一些实施例”意指与本申请至少一个实施例相关的某一特征、结构或特性。因此，应该理解的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一替代性实施例”并不一定是指同一实施例。此外，本申请的一个或多个实施例中的某些特征、结构或特性可以进行适当的组合。

此外，本领域的普通技术人员可以理解，本申请的各方面可以通过若干具有可专利性的种类或情况进行说明和描述，包括任何新的和有用的工序、机器、产品或物质的组合，或对其任何新的和有用的改进。因此，本申请的各方面可以完全由硬件执行，完全由软件执行(包括固件、常驻软件、微代码等)或软件和硬件组合执行，其在本文中通常都可称为“数据块”、“模块”、“引擎”、“单元”、“组件”或“系统”。此外，本申请的各方面可以呈现为位于一个或多个计算机可读媒体中的计算机产品，该产品具有计算机可读程序编码。

计算机可读信号介质可能包含一个内含有计算机程序编码的传播数据信号，例如在基带上或作为载波的一部分。此类传播讯号可以有多种形式，包括电磁形式、光形式等或任何合适的组合。计算机可读信号介质可以是除计算机可读存储介质之外的任何计算机可读介质，该介质可以通过连接至指令执行系统、装置或设备，以实现通讯、传播或传输供使用的程序。位于计算机可读信号介质上的程序编码可以通过任何合适的介质进行传播，包括无线电、电缆、光纤电缆、RF、或任何上述介质的组合。

本申请各方面操作所需的计算机程序码可以用一种或多种程序语言的任意组合编写，包括面向对象编程语言如Java、Scala、Smalltalk、Eiffel、JADE、Emerald、C++、C#、VB.NET、Python等，常规程序编程语言如C语言、VisualBasic、Fortran1703、Perl、COBOL1702、PHP、ABAP，动态编程语言如Python、Ruby和Groovy等或其它编程语言。程序代码可以完全在用户计算机上运行、或作为独立的软件包在用户计算机上运行、或部分在用户计算机上运行部分在远程计算机上运行、或完全在远程计算机或服务器上运行。在后种情况下，远程计算机可以通过任何网络形式与用户计算机连接，比如局域网(LAN)或广域网(WAN)、或连接至外部计算机(例如通过互联网)、或在云计算环境中，或作为服务使用如软件即服务(SaaS)。

此外，除非权利要求中明确说明，否则述处理元素或序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本申请流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的发明实施例，但应当理解的是，此类细节仅起说明的目的，附加的权利要求并不仅限于披露的实施例，相反，权利要求旨在覆盖所有符合本申请实施例的精神和范围的修正和等价组合。例如，虽然以上所描述的系统组件可以通过硬件设备实现，但是也可以只通过软件的解决方案得以实现，如在现有的服务器或移动设备上安装所描述的系统。

同理，应当理解的是，为了简化本申请揭示的表述，从而帮助对一个或多个发明实施例的理解，前文对本申请实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。然而，此揭示方法并不意味着本申请所需的特征比权利要求中涉及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

Claims (20)

1.一种系统，包括：

至少一个计算机可读存储介质，包括用于为按需服务分配车辆的一组指令；以及

至少一个处理器，被配置为与所述至少一个计算机可读存储介质通信，其中，当执行所述指令时，所述至少一个处理器被配置为：

从用户终端接收服务请求，所述服务请求包括出发地和目的地；

基于所述出发地和所述目的地，生成包含第一预估价格的所述服务请求的订单；

将所述订单添加到待分配车辆的第一队列中；以及

向所述用户终端发送第一显示指令，所述第一显示指令指示所述用户终端显示与所述订单的状态相关的信息。

2.根据权利要求1所述的系统，其特征在于，与所述订单的状态相关的信息包括以下中的至少一个：

所述第一预估价格、订单之前所述第一队列中正在等待的订单的数量、所述第一队列中的所述订单的估计等待时间、所述第一队列中正在等待的订单的总数、或所述第一队列中可用于接单的车辆数量。

3.根据权利要求2所述的系统，其特征在于，所述至少一个处理器进一步用于：

获取历史等待数据；以及

基于所述历史等待数据确定所述订单的估计等待时间，其中

所述估计等待时间表示在所述第一队列中的所述订单将被处理的时间或在所述第一队列中的所述订单将被处理的时间段。

4.根据权利要求2所述的系统，其特征在于，所述至少一个处理器进一步用于：

确定在所述订单之前所述第一队列中的所述正在等待的订单数量小于订单阈值；以及

发送第二显示指令到所述用户终端，所述第二显示指令指示所述用户终端显示车辆分配状态。

5.根据权利要求2所述的系统，其特征在于，所述至少一个处理器进一步用于：

确定所述第一队列中所述订单的估计的等待时间小于第一时间阈值；以及

发送第二显示指令到所述用户终端，所述第二显示指令指示所述用户终端显示车辆分配状态。

6.根据权利要求2所述的系统，其特征在于，所述至少一个处理器进一步用于：

确定所述第一队列中所述订单的估计的等待时间大于第二时间阈值；以及

发送第三显示指令到所述用户终端，所述第三显示指令指示所述用户终端向所述用户显示一个或以上建议，以供选择完成所述服务请求，其中

所述一个或以上建议包括拼车。

7.根据权利要求1所述的系统，其特征在于，为了将所述订单添加到待分配车辆的第一队列中，所述至少一个处理器进一步用于：

确定所述第一队列的排队模式；以及

基于所述排队模式将所述订单添加到所述第一队列中，其中

所述排队模式包括关于所述订单的确认时间的严格排队模式或关于所述订单的权重的非严格排队模式中的至少一个。

8.根据权利要求1所述的系统，其特征在于，所述至少一个处理器进一步用于：

确定当前等待时间大于第三时间阈值；以及

发送第四显示指令到所述用户终端，所述第四显示指令指示所述用户终端显示是否继续等待的询问。

9.根据权利要求8所述的系统，其特征在于，所述至少一个处理器进一步用于：

确定所述当前等待时间大于第四时间阈值，所述第四时间阈值大于所述第三时间阈值；以及

取消所述订单。

10.根据权利要求1所述的系统，其特征在于，所述至少一个处理器进一步用于：

确定所述订单满足第一条件；

发送第五显示指令到所述用户终端，所述第五显示指令指示所述用户终端显示供选择的出行建议，所述供选择的出行建议建议所述服务请求执行第二预估价格，所述第二预估价格大于所述第一预估价格；

接收对所述出行建议的选择，所述选择包含所述第二预估价格；以及

将所述订单添加到第二队列中，其中所述第二队列中可用于接单的第二车辆数量与所述第二队列中第二正在等待的订单的数量的第二比率大于所述第一队列中可用于接单的所述第一车辆数量与所述第一队列中所述第一正在等待的订单的数量第一比率。

11.根据权利要求10所述的系统，其特征在于，为了确定所述订单满足第一条件，所述至少一个处理器进一步用于：

基于所述订单的所述出发地确定一个区域；

确定所述区域内，在所述第一队列中可用于接单的车辆数量；

确定所述区域中，在所述第一队列中正在等待的订单的总数；以及

确定所述区域中所述正在等待的订单总数大于所述区域中在所述第一队列中可用于接单的所述车辆数量。

12.根据权利要求10所述的系统，其特征在于，为了确定所述订单满足所述第一条件，所述至少一个处理器进一步用于：

确定当前时间在预定时间范围内。

13.一种在具有至少一个处理器、至少一个计算机可读存储介质、以及连接到网络的通信平台的计算设备上实现的方法，所述方法包括：

从用户终端接收服务请求，所述服务请求包括出发地和目的地；

基于所述出发地和所述目的地，生成包含第一预估价格的所述服务请求的订单；

添加所述订单到待分配车辆的第一队列；以及

发送第一显示指令到所述用户终端，所述第一显示指令指示所述用户终端显示与所述订单的状态相关的信息。

14.根据权利要求13所述的方法，其特征在于，与所述订单的状态相关的信息包括以下中的至少一个：

所述第一预估价格、订单之前所述第一队列中正在等待的订单的数量、所述第一队列中的所述订单的估计等待时间、所述第一队列中正在等待的订单的总数、或所述第一队列中可用于接单的车辆数量。

15.根据权利要求14所述的方法，其特征在于，进一步包括：

确定在所述订单之前所述第一队列中的所述正在等待的订单数量小于订单阈值；以及

发送第二显示指令到所述用户终端，所述第二显示指令指示所述用户终端显示车辆分配状态。

16.根据权利要求14所述的方法，进一步包括：

确定所述第一队列中所述订单的估计的等待时间小于第一时间阈值；以及

发送第二显示指令到所述用户终端，所述第二显示指令指示所述用户终端显示车辆分配状态。

17.权利要求14的方法，其特征在于，进一步包括：

确定所述第一队列中所述订单的估计的等待时间大于第二时间阈值；以及

发送第三显示指令到所述用户终端，所述第三显示指令指示所述用户终端向所述用户显示一个或以上建议，以便选择建议完成所述服务请求，其中

所述一个或以上建议包括拼车。

18.根据权利要求13所述的方法，其特征在于，进一步包括：

确定当前等待时间大于第三时间阈值；以及

发送第四显示指令到所述用户终端，所述第四显示指令指示所述用户终端显示是否继续等待的询问。

19.根据权利要求13所述的方法，其特征在于，进一步包括：

确定所述订单满足第一条件；

发送第五显示指令到所述用户终端，所述第五显示指令指示所述用户终端显示供选择的出行建议，所述供选择的出行建议建议所述服务请求执行第二预估价格，所述第二预估价格大于所述第一预估价格；

接收对所述出行建议的选择，所述选择包含所述第二预估价格；以及

添加所述订单到第二队列中，其中所述第二队列中可用于接单的所述第二车辆数量与所述第二队列中第二正在等待的订单的数量第二比率大于所述第一队列中可用于接单的所述第一车辆数量与所述第一队列中所述第一正在等待的订单的数量第一比率。

20.一种非暂时性计算机可读介质，包括至少一组用于按需服务分配车辆的指令，当由计算机设备的至少一个处理器执行时，所述至少一组指令指示所述至少一个处理器：

从用户终端接收服务请求，所述服务请求包括出发地和目的地；

基于所述出发地和所述目的地，生成包含第一预估价格的所述服务请求的订单；

将所述订单添加到待分配车辆的第一队列中；以及

向所述用户终端发送第一显示指令，所述第一显示指令指示所述用户终端显示与所述订单的状态相关的信息。