用于为用户确定接单模式的系统和方法与流程

交叉引用

本申请要求于2017年7月18日提交的申请号为201710585426.1的中国申请的优先权，其全部内容通过引用的方式包含于此。

本申请一般涉及用于处理线上到线下服务的出租车订单的系统和方法，尤其涉及用于确定线上到线下服务的用户的接单模式的系统和方法。

背景技术：

线上到线下服务，如在线网约车呼叫服务，利用互联网技术，因其便利性而越来越受欢迎。为在线网约车司机确定合适的接单模式对于在线网约车司机和服务提供者有效地为用户服务非常重要。当在线网约车司机没有适合的接单模式时，可能会影响服务质量并恶化线上到线下服务的用户体验。因此，希望提供用于确定司机的接单模式的有效系统和方法。

技术实现要素：

本申请的一个方面，提供了一个系统。该系统可以被配置为操作线上到线下服务平台。该系统可以包括至少一个存储介质，包括用于确定与线上到线下服务平台相关联的服务提供者终端的接单模式的第一组指令。该系统还可以包括与至少一个存储介质通信的至少一个处理器，其中，当执行第一组指令时，所述至少一个处理器用于：接收用于确定目标服务提供者终端的接单模式的请求；响应于所述请求，获取与目标服务提供者终端相关联的目标服务提供者的接单评估参数；并基于接单评估参数确定目标服务提供者的接单模式。所述接单模式包括派单模式、抢单模式或急速接单模式中的至少一种。

在一些实施例中，接单评估参数包括与目标服务提供者相关联的历史行驶评分或与目标服务提供者相关联的服务提供者终端所在的地理区域的运力中的至少一个。

在一些实施例中，确定接单模式的请求包括登录系统的请求。

在一些实施例中，为基于接单评估参数确定目标服务提供者的接单模式，至少一个处理器用于：将与目标服务提供者相关联的历史行驶评分与第一阈值和第二阈值进行比较；响应于确定目标服务提供者相关联的行驶评分小于第一阈值，将急速接单模式指定为目标服务提供者的接单模式；响应于确定目标服务提供者相关联的订单驱动得分大于或等于第一阈值且小于或等于第二阈值，将派单模式指定为目标服务提供者的接单模式；并且响应于确定目标服务提供者相关联的历史行驶评分大于第二阈值，将抢单模式指定为目标服务提供者的接单模式。

在一些实施例中，与目标服务提供者相关联的历史行驶评分是基于与目标服务提供者相关联的历史服务数据、与目标服务提供者相关联的历史成交率和行驶评分估计模型来确定的。

在一些实施例中，为基于接单评估参数确定目标服务提供者的接单模式，所述至少一个处理器用于：确定地理区域的运力相对应的可用服务提供者的第一数量；确定可用服务提供者的第一数量是否大于或等于运力阈值；响应于确定可用服务提供者的第一数量大于或等于运力阈值，将抢单模式指定为目标服务提供者的接单模式；并且响应于确定可用服务提供者的第一数量小于运力阈值，将派单模式指定为目标服务提供者的接单模式。

在一些实施例中，为基于接单评估参数确定目标服务提供者的接单模式，所述至少一个处理器用于：确定与所述地理区域的运力相对应的未处理订单的第一数量；确定未处理订单的第一数量是否大于或等于订单阈值；响应于确定未处理订单的第一数量大于或等于订单阈值，将急速接单模式指定为目标服务提供者的接单模式；并且响应于确定未处理订单的第一数量小于订单阈值，将派单模式指定为目标服务提供者的接单模式。

在一些实施例中，确定接单模式的请求包括模式切换请求，用于将与目标服务提供者相关联的接单模式从派单模式切换到抢单模式，并基于接单评估参数确定目标服务提供者的接单模式，至少一个处理器用于：确定对应于运力的可用服务提供者数量是否大于运力阈值；并且响应于确定对应运力的可用服务提供者大于运力阈值，将接单模式从派单模式切换到抢单模式。

在一些实施例中，为基于接单评估参数确定目标服务提供者的接单模式，所述至少一个处理器用于：确定目标服务提供者相关联的历史行驶评分是否大于或等于第二阈值；以及响应于确定与目标服务提供者相关联的历史行驶评分大于或等于第二阈值时，将接单模式从派单模式切换到抢单模式。

在一些实施例中，至少一个处理器还用于指示目标服务提供者终端基于所述确定的接单模式显示初始接单界面。

在一些实施例中，当确定的接单模式为派单模式时，所述至少一个处理器还用于指示目标服务提供者终端在初始接单界面的第一区域中显示与订单有关的时间信息，并在初始接单界面的第二区域中显示接单标识，或当确定接单模式是抢单模式或急速接单模式时，所述至少一个处理器进一步用于指示目标服务提供者终端在初始接单界面的第一区域中显示与订单有关的距离信息，并且在初始接单界面的第二区域中显示抢单标识。

在一些实施例中，在派单模式下，订单通过线上到线下服务平台发送到服务提供者终端，并在预定时间段内收到接收后指定给服务提供者终端。

在一些实施例中，在抢单模式下，订单通过线上到线下服务平台向至少两个服务提供者终端播报，并指定给至少两个服务提供者终端中首先响应的服务提供者终端。

在一些实施例中，在急速接单模式下，订单直接指定给服务提供者终端。

在一些实施例中，所述至少一个存储介质还包括用于播报目标订单的第二组指令，其中，当至少一个处理器执行所述第二组指令时，至少一个处理器还用于：从服务请求者终端接收目标订单，其中，目标订单与目标起始位置相关联；确定目标订单的播单模式；在目标起始位置周围的预定范围内识别至少两个候选服务提供者终端；对于至少两个候选服务提供者终端中的每一个，执行第一组指令以确定接单模式；从至少两个候选服务提供者的终端中识别接单模式与目标订单的播单模式相对应的一个或以上服务提供者终端；并播报目标订单至一个或以上识别的服务提供者终端。

在一些实施例中，为确定目标订单的播单模式，至少一个处理器还用于：确定目标地理区域围绕目标起始位置的目标运力；并基于目标地理区域的目标运力确定目标订单的播单模式。

在一些实施例中，基于目标地理区域的目标运力来确定目标订单的播单模式，所述至少一个处理器还用于：确定与所述目标地理区域的目标运力相对应的可用服务提供者的第二数量；确定可用服务提供者的第二数量是否大于或等于运力阈值；响应于确定可用服务提供者的第二数量大于或等于运力阈值，将对应于抢单模式的第一播单模式指定为目标订单的播单模式；响应于确定可用服务提供者的第二数量小于运力阈值，将对应于派单模式的第二播单模式指定为目标订单的播单模式。

在一些实施例中，基于目标地理区域的目标运力确定目标订单的播单模式，所述至少一个处理器还用于：确定与所述目标地理区域的目标运力相对应的未处理订单的第二数量；确定未处理订单的第二数量是否大于或等于订单阈值；响应于确定未处理订单的第二数量大于或等于订单阈值，将对应于急速接单模式的第三播单模式作为目标订单的播单模式；以及响应于确定未处理订单的数量小于订单阈值，将对应于派单模式的第二播单模式指定为目标订单的播单模式。

本申请的另一方面，提供了一种用于确定接单模式的方法。该方法可以在具有至少一个处理器、至少一个存储介质和连接到网络的线上到线下服务平台的计算设备上实现。该方法可以包括接收用于确定目标服务提供者终端的接单模式的请求；响应于所述请求，获取与目标服务提供者终端相关联的目标服务提供者的接单评估参数；基于接单评估参数确定目标服务提供者的接单模式。

本申请的又一个方面，提供了一种非暂时性计算机可读介质。非暂时性计算机可读介质可以包括至少一组用于确定服务提供者的接单模式的指令。当由计算机设备的至少一个处理器执行时，至少一组指令指示至少一个处理器：接收用于确定目标服务提供者终端的接单模式的请求；响应于所述请求，获取与目标服务提供者终端相关联的目标服务提供者的接单评估参数；以及基于接单评估参数确定目标服务提供者的接单模式。

在本申请的又一个方面，提供了一种用于操作线上到线下服务平台的系统。该系统可以包括请求获取模块，其被配置为接收用于确定目标服务提供者终端的接单模式的请求；评估参数确定模块，其被配置为响应所述请求，获取与目标服务提供者终端相关联的目标服务提供者的接单评估参数；以及接单模式确定模块，其被配置为基于接单评估参数确定目标服务提供者的接单模式。

本申请的一部分附加特性可以在下面的描述中进行说明。通过对以下描述和相应附图的研究或者对实施例的生产或操作的了解，本申请的一部分附加特性对于本领域技术人员是明显的。本申请的特征可以通过对以下描述的具体实施例的各种方面的方法、手段和组合的实践或使用得以实现和达到。

附图说明

本申请将通过示例性实施例进行进一步描述。这些示例性实施例将通过附图进行详细描述。附图未按比例绘制。这些实施例是非限制性的示例性实施例，在这些实施例中，各图中相同的编号表示相似的结构，其中：

图1是根据本申请的一些实施例所示的的示例性线上到线下服务系统的方框图；

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

图3是根据本申请的一些实施例所示的示例性设备的示意图；

图4a是根据本申请的一些实施例所示的服务器中的示例性处理引擎的框图；

图4b是根据本申请的一些实施例所示的服务器中的示例性接单模式确定模块的框图；

图4c是根据本申请的一些实施例所示的服务提供者终端中的示例性处理器的框图；

图4d是根据本申请的一些实施例所示的服务提供者终端中的示例性接单模式显示模块的框图；

图4e是根据本申请的一些实施例所示的服务器中的示例性处理引擎的框图；

图4f是根据本申请的一些实施例所示的示例性评估参数确定模块的框图；

图4g是根据本申请的一些实施例所示的示例性接单模式确定模块的框图；

图4h是根据本申请的一些实施例所示的示例性播单模式确定模块的框图；

图5a是根据本申请的一些实施例所示的用于确定目标服务提供者的接单模式的示例性过程的流程图；

图5b是根据本申请的一些实施例所示的用于在服务提供者终端中生成初始接单界面的示例性过程的流程图；

图6是根据本申请的一些实施例所示的用于确定目标服务提供者的接单模式的示例性过程的流程图；

图7是根据本申请的一些实施例所示的用于基于目标服务提供者的历史行驶评分确定目标服务提供者的接单模式的示例性过程的流程图；

图8a到8d是根据本申请的一些实施例所示的用于基于运力确定目标服务提供者的接单模式的示例性过程的流程图；

图9是根据本申请的一些实施例所示的用于切换目标服务提供者的接单模式的示例性过程的流程图；

图10a是根据本申请的一些实施例所示的用于根据运力切换目标服务提供者的接单模式的示例性过程的流程图；

图10b是根据本申请的一些实施例所示的用于基于历史行驶评分切换目标服务提供者的接单模式的示例性过程的流程图；

图11是根据本申请的一些实施例所示的用于播报目标订单的示例性过程的流程图；

图12a和12b是根据本申请的一些实施例所示的用于确定目标订单的播单模式的示例性过程的流程图；以及

图13a至13c是根据本申请的一些实施例所示的在不同的接单模式下的服务提供者终端的示例性初始接单界面的示意图。

具体实施方式

以下描述是为了使本领域的普通技术人员能够实施和利用本申请，并且该描述是在特定的应用场景及其要求的环境下提供的。对于本领域的普通技术人员来讲，显然可以对所披露的实施例作出各种改变，并且在不偏离本申请的原则和范围的情况下，本申请中所定义的普遍原则可以适用于其他实施例和应用场景。因此，本申请并不限于所描述的实施例，而应该被给予与权利要求一致的最广泛的范围。

本申请中所使用的术语仅用于描述特定的示例性实施例，并不限制本申请的范围。如本申请使用的单数形式“一”、“一个”及“该”可以同样包括复数形式，除非上下文明确提示例外情形。还应当理解，如在本申请说明书中，术语“包括”和/或“包含”仅提示存在所述特征、整体、步骤、操作、组件和/或部件，但并不排除存在或添加一个或以上其他特征、整体、步骤、操作、组件、部件和/或其组合的情况。

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

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

此外，虽然本申请中披露的系统和方法主要涉及确定目标服务提供者的接单模式并确定目标订单的播单模式，还应该理解，这仅是一个示例性实施例。本申请的系统或方法可以应用于任何其他类型的线上到线下服务平台的用户。例如，本申请的系统或方法可以应用于不同运输系统中的用户，包括陆地、海洋、航空航天等，或其任何组合。所述运输系统的交通工具可以包括出租车、私家车、顺风车、公交车、火车、动车、高铁、地铁、船舶、飞机、飞船、热气球、无人行驶的车辆等或其任意组合。所述运输系统运输系统还可以包括应用管理和/或分配的任何运输系统，例如，接收/发送快递的系统。本申请的系统或方法的应用场景可以包括网页、浏览器插件、客户端、定制系统、内部分析系统、人工智能机器人等或其任意组合。

本申请中的服务起始点可以通过嵌入在无线设备(例如，乘客终端、服务提供者终端等)中的定位技术来获取。本申请中使用的定位技术可以包括全球定位系统(gps)、全球导航卫星系统(glonass)、北斗导航系统(compass)、伽利略定位系统、准天顶卫星系统(qzss)、无线保真(wi-fi)定位技术等，或其任何组合。以上定位技术中的一个或以上可以在本申请中交换使用。例如，基于gps的方法和基于wi-fi的方法可以一起作为定位无线电设备的定位技术。

本申请的一个方面涉及一种线上到线下服务系统和/或具有人工智能的方法，用于确定目标服务提供者的接单模式。为此，线上到线下服务系统可以首先接收请求(例如，从服务提供者终端)以确定接单模式。线上到线下服务系统可以获取关于与目标服务提供者终端相关联的目标服务提供者的接单评估参数以响应所述请求。接单评估参数可包括与目标服务提供者或地理区域的运力相关联的历史行驶评分。然后线上到线下服务系统可以基于历史行驶评分或运力确定目标服务提供者的接单模式。线上到线下服务系统可以根据服务提供的接单模式向服务提供者播报或分发订单。因此，针对不同服务提供者的接单模式的确定更符合实际需要，满足不同服务提供者的需求，从而提高线上到线下服务平台的运行效率。

应当注意本解决方案依赖于收集与在线上到线下系统注册的用户终端(例如，服务请求者终端、服务提供者终端)有关的数据(例如，位置信息)，这是一种新形式的数据收集手段，仅限于后互联网时代。它提供了仅在后互联网时代才能提出的用户终端的详细信息。在前互联网时代，gps不可用，并且不可能实时和/或基本上实时地获取数十万个用户终端的位置。然而，线上到线下服务允许线上到线下服务系统使用gps实时和/或基本实时地监视数以万计的用户终端的位置，然后根据用户终端的位置提供更好的服务方案。因此，本解决方案深入人心，旨在解决仅在后互联网时代发生的问题。

图1是根据本申请的一些实施例所示的示例性线上到线下服务系统的框图。例如，线上到线下服务系统100可以是用于运输服务的在线运输服务平台，如出租车服务、代驾服务、快车服务、拼车服务、公交车服务、代驾服务和班车服务。线上到线下服务系统100可以包括服务器110、网络120、服务请求者终端130、服务提供者终端140和存储器150。服务器110可以包括处理引擎112。

服务器110可以处理与服务请求有关的信息和/或数据。服务请求可以包括用于确定目标服务提供者的接单模式的请求(在此也称为模式确定请求)、用于确定是否为目标服务提供者切换接单模式的请求(在此也称为模式切换请求)、用于确定目标订单的播单模式的请求等，或其任何组合。在一些实施例中，服务器110可以是单个服务器，也可以是服务器组。所述服务器组可以是集中式的，也可以是分布式的(例如，服务器110可以是分布式的系统)。在一些实施例中，服务器110可以是本地的，也可以是远程的。例如，服务器110可以经由网络120访问存储在服务请求者终端130、服务提供者终端140和/或存储器150中的信息和/或数据。又例如，服务器110可以直接连接到服务请求者终端130、服务提供者终端140和/或存储器150以访问信息和/或数据。在一些实施例中，服务器110可以在云平台上实施。仅作为示例，该云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多层云等或其任意组合。在一些实施例中，服务器110可以在本申请中的图2描述的包含了一个或以上组件的计算设备上执行。

在一些实施例中，服务器110可以包括处理引擎112。该处理引擎112可以处理与服务请求相关的信息和/或数据，以执行本申请中描述的服务器110的一个或以上功能。例如，处理引擎112可以获取关于目标服务提供者的接单评估参数，并基于接单评估参数确定目标服务提供者的接单模式。又例如，处理引擎112可以确定是否为目标服务提供者切换接单模式。作为又一示例，处理引擎112可以确定目标订单的播单模式。在一些实施例中，所述处理引擎112可包括一个或以上处理引擎(例如，单芯片处理引擎或多芯片处理引擎)。仅作为示例，处理引擎112可包括一中央处理器(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)、蓝牙网络、无线个域网、近场通讯(nfc)网络、全球移动通讯系统(gsm)网络、码分多址(cdma)网络、时分多址(tdma)网络、通用分组无线服务(gprs)网络、增强数据速率gsm演进(edge)网络、宽带码分多址接入(wcdma)网络、高速下行分组接入(hsdpa)网络、长期演进(lte)网络、用户数据报协议(udp)网络、传输控制协议/互联网协议(tcp/ip)网络、短讯息服务(sms)网络、无线应用协议(wap)网络、超宽带(uwb)网络、红外线等，或其任意组合。在一些实施例中，服务器110可以包括一个或以上网络接入点。例如，服务器110可以包括有线或无线网络接入点，例如基站和/或互联网交换点120-1、120-2......，线上到线下服务系统100的一个或以上组件可以通过其连接到网络120以交换数据和/或信息。

服务请求者终端130可以由用户(例如，乘客)使用以请求线上到线下服务(例如，运输服务)。例如，服务请求者终端130的用户可以使用服务请求者终端130来为他/她自己或另一用户发送服务请求，或者从服务器110接收服务和/或信息或指令。服务提供者终端140可以由服务提供者(例如，司机)用来回复线上到线下服务(例如，运输服务)。例如，服务提供者终端140的用户可以使用服务提供者终端140来接收来自服务请求者终端130的服务请求，和/或来自服务器110的信息或指令。在一些实施例中，术语“乘客”、“客户”和“服务请求者”可以互换使用，术语“司机”和“服务提供者”可以互换使用。在一些实施例中，用户可以根据具体情况指代服务请求者或服务提供者。在一些实施例中，术语“用户终端”、“乘客终端”和“服务请求者终端”可以互换使用。在一些实施例中，术语“用户终端”、“司机终端”和“服务提供者终端”可以互换使用。

在一些实施例中，服务请求者终端130可以包括移动设备130-1、平板电脑130-2、膝上型计算机130-3、机动车辆中的内置设备130-4等，或其任何组合。在一些实施例中，移动设备130-1可以包括智能家居设备、可穿戴设备、智能移动设备、虚拟现实设备、增强现实设备等，或其任意组合。在一些实施例中，智能家居设备可以包括智能照明设备、智能电器控制设备、智能监控设备、智能电视、智能摄像机、对讲机等，或其任意组合。在一些实施例中，该可穿戴设备可包括智能手镯、智能鞋袜、智能眼镜、智能头盔、智能手表、智能衣服、智能背包、智能配件等，或其任意组合。在一些实施例中，智能移动设备可以包括智能电话、个人数字助理(pda)、游戏设备、导航设备、销售点(pos)设备等或其任意组合。在一些实施例中，虚拟现实设备和/或增强型虚拟现实设备可以包括虚拟现实头盔、虚拟现实眼镜、虚拟现实眼罩、增强现实头盔、增强现实眼镜、增强现实眼罩等，或其任意组合。例如，虚拟现实设备和/或增强现实设备可以包括googleglass、oculusrift、hololens或gearvr等。在一些实施例中，机动车内置设备130-4可以包括车载计算机、车载电视等。在一些实施例中，服务请求者终端130可以是具有定位技术的无线设备，用于定位用户和/或服务请求者终端130的位置。

在一些实施例中，服务提供者终端140可以与服务请求者终端130类似或相同。在一些实施例中，服务提供者终端140可以是具有定位技术的无线设备，用于定位司机和/或服务提供者终端140的位置。在一些实施例中，服务请求者终端130和/或服务提供者终端140可以与其他定位设备通信以确定乘客、服务请求者终端130、司机和/或服务提供者终端140的位置。在一些实施例中，服务请求者终端130和/或服务提供者终端140可以将定位信息发送到服务器110。

存储器150可以储存数据和/或指令。在一些实施例中，存储器150可以存储从服务请求者终端130和/或服务提供者终端140获取/取得的数据。在一些实施例中，存储器150可以储存服务器110用来执行或使用来完成本申请中描述的示例性方法的数据和/或指令。在一些实施例中，存储器150可包括大容量存储器、可移动存储器、易失性读写存储器、只读存储器(rom)等，或其任意组合。示例性的大容量存储器可以包括磁盘、光盘、固态磁盘等。示例性可移动存储器可以包括闪存驱动器、软盘、光盘、存储卡、压缩盘、磁带等。示例性易失性读写存储器可以包括随机存取存储器(ram)。示例性随机存取存储器可以包括动态随机存取存储器(dram)、双倍数据速率同步动态随机存取存储器(ddrsdram)、静态随机存取存储器(sram)、晶闸管随机存取存储器(t-ram)和零电容随机存取存储器(z-ram)等。示例性只读存储器可以包括掩模只读存储器(mrom)、可编程只读存储器(prom)、可擦除可编程只读存储器(eprom)、电可擦除可编程只读存储器(eeprom)、光盘只读存储器(cd-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可以读取和/或修改一个或以上用户的信息。又例如，服务提供者终端140可以在从服务请求者终端130接收到服务请求时访问与服务请求者有关的信息，但服务提供者终端140可能不会修改服务请求者的相关信息。

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

本领域普通技术人员将理解，当线上到线下服务系统100的要素执行时，该要素可以通过电信号和/或电磁信号执行。例如，当服务请求者终端130处理任务时比如发起对运输服务的请求，服务请求者终端130可以在其处理器中操作逻辑电路以执行这样的任务。当服务请求者终端130向服务器110发送服务请求时，服务器110的处理器可以生成编码该请求的电信号。然后，服务器110的处理器可以将电信号发送到输出端口。如果服务请求者终端130经由有线网络与服务器110通信，则输出端口可以物理地连接到电缆，电缆进一步将电信号发送到服务器110的输入端口。如果服务请求者终端130通过一无线网络与服务器110通讯，服务请求者终端130的输出端口可以是一个以上的天线，该天线可以将电信号转换为电磁信号。类似地，服务提供者终端140可以通过其处理器中的逻辑电路的操作来处理任务，并且经由电信号或电磁信号从服务器110接收指令和/或服务请求。在电子设备中，例如服务请求者终端130、服务提供者终端140和/或服务器110，当处理器处理指令时，发出指令和/或执行动作，指令和/或动作通过电信号进行。例如，当处理器从存储介质中检索或保存数据时，它可以将电信号发送到存储介质的读/写设备，其可以在存储介质中读取或写入结构化数据。该结构化数据可以电信号的形式经由电子设备的总线传输至处理器。此处，电信号可以指一个电信号、一系列电信号和/或至少两个不连续的电信号。

图2是根据本申请的一些实施例所示的计算设备的示例性硬件和软件组件的示意图，其上服务器110、服务请求者终端130和/或服务提供者终端140可以被实现。例如，处理引擎112可以在计算设备200上实现，并且被配置用于执行本申请中披露的处理引擎112的功能。

计算设备200可用于实现本申请的线上到线下系统。计算设备200可以实现如本文所述的线上到线下服务的任何组件。在图2中，仅出于方便的目的示出了一个这样的计算机设备。在提交本申请时，本领域普通技术人员将理解，与本文所述的线上到线下服务有关的计算机功能可以在多个类似平台上以分布式方式实现，以分散处理负荷。

例如，计算设备200可以包括与网络相连接通信端口250，以实现数据通信。计算设备200还可以包括一个中央处理器220，可以以一个或多个处理器的形式执行程序指令。示例性计算机平台可以包括内部通信总线210、程序存储器和不同形式的数据存储器，例如，磁盘270，以及只读存储器(rom)230或随机存取存储器(ram)240，供计算机处理和/或发送的各种数据文件之用。示例性的计算机平台也可以包括储存在只读存储器230、随机存取存储器240和/或其他类型的非暂时储存介质，其供处理器220执行。本申请的方法和/或流程可以以程序指令的方式实现。计算设备200还包括输入/输出组件260，用来支持计算机和其他组件之间进行输入/输出。计算设备200也可以通过网络通信接收程序设计和数据。

仅用于说明，计算设备200中仅示例性绘制了一个处理器。但是，应该注意的是，本申请中的计算设备200还可以包括多个处理器，因此，如本申请中所描述的由一个处理器220执行的操作和/或方法步骤也可以由多个处理器联合或单独执行。例如，如果在本申请中，计算设备200的处理器220执行步骤a和步骤b，应当理解的是，步骤a和步骤b也可以由计算设备200的两个不同的处理器共同地或独立地执行(例如，第一处理器执行步骤a、第二处理器执行步骤b、或者第一和第二处理器共同地执行步骤a和步骤b)。

图3是示出根据本申请的一些实施例所示的可以在其上实现服务请求者终端130和/或服务提供者终端140的示例性设备的示例性硬件和/或软件组件的示意图。该设备可以是移动设备，例如乘客或司机的移动电话。该设备也可以是安装在由司机行驶的车辆上的电子设备。如图3所示，设备300可以包括通信平台310、显示器320、图形处理单元(gpu)330、中央处理单元(cpu)340、i/o350、内存360和存储器390。在一些实施例中，任何其他合适的组件，包括但不限于系统总线或控制器(未示出)，也可以包括在设备300中。在一些实施例中，操作系统370(例如，ios^tm、android^tm、windowsphone^tm等)和一个或以上应用程序380可从存储器390下载至内存360以由cpu340执行。应用程序380可以包括浏览器或任何其他合适的移动应用程序，用于接收和呈现与线上到线下服务有关的信息或来自服务器110的其他信息，并且将与线上到线下服务或其他信息有关的信息发送给服务器110。用户与信息流的交互可以通过i/o350实现，并通过网络120提供给服务器110和/或线上线下服务系统100的其他组件。在一些实施例中，设备300可以包括用于捕获语音信息的设备，例如麦克风315。

图4a是根据本申请的一些实施例所示的服务器中的示例性处理引擎的框图。

在一些实施例中，服务器110可以包括内存、处理器(例如，处理引擎112)，以及存储在内存中并由处理器执行的计算机程序。当执行计算机程序时，处理器可以执行用于确定在线网约车服务的接单模式的过程中的任何一个操作。在一些实施例中，如图4a所示，处理引擎112可包括接单模式确定模块410。接单模式确定模块410可以实现图5a和图6至10b中描述的过程中的任何一个操作。

图4b是根据本申请的一些实施例所示的服务器110中的示例性接单模式确定模块的框图。

在一些实施例中，接单模式确定模块410可包括生成单元411。生成单元411可以根据司机终端(这里也称为服务提供者终端)的一个或以上接单评估参数生成接单模式以响应用于确定接单模式的请求(这里也称为接单模式确定请求)。所述接单模式可以包括派单模式、抢单模式或急速接单模式。

在本申请中，在接收到接单模式确定请求之后，可以根据接单模式确定请求获取司机终端的接单评估参数。然后可以基于接单评估参数确定接单模式。接单模式也可以反馈给司机终端并显示在司机终端的界面上。因此，基于接单评估参数确定接单模式更符合实际需要，满足不同运营司机的使用需要，从而提高了运营效率。还可以实现线上到线下服务平台的功能整合。

在一些实施例中，接单模式确定模块410可包括获取单元412。例如，当接单模式确定请求是登录线上到线下服务系统的请求时，获取单元412可以获取司机的历史行驶评分。在一些实施例中，当检测到历史行驶评分小于第一阈值时，生成单元411还可以生成急速接单模式。当检测到历史行驶评分大于或等于第一阈值并且历史行驶评分小于或等于第二阈值时，生成单元411还可以生成派单模式。在一些实施例中，当检测到历史行驶评分大于第二阈值时，生成单元411还可以生成抢单模式。所述第二阈值大于所述第一阈值。

在一些实施例中，接单模式确定模块410可包括确定单元413。确定单元413可以根据与司机终端有关的历史服务数据、历史订单成交率和预定评估模型来确定历史行驶评分。

在一些实施例中，服务器110可以包括用于存储司机的历史评分的数据库。当司机每次完成订单时，服务器110还可以更新数据库。

在一些实施例中，确定单元413还可以基于司机的位置信息确定司机所在的地理区域的运力。在一些实施例中，当地理区域中存在可用的运力并且可用的运力大于运力阈值时，生成单元411还可以生成抢单模式。在一些实施例中，当可用运力大于运力阈值时，生成单元411还可以生成派单模式。在一些实施例中，当检测到存在多余的订单并且多余订单的数量小于订单阈值时，生成单元411可以生成派单模式。在一些实施例中，当多余订单的数量大于或等于订单阈值时，生成单元411可以生成急速接单模式。

在一些实施例中，接单模式确定请求可以包括用于切换接单模式的请求(在此也称为模式切换请求)，所述请求由司机的司机终端发出。确定单元413还可以基于与司机相关联的运力和/或历史行驶评分来确定是否响应模式切换请求。

在一些实施例中，接单模式确定模块410可包括检测单元414。例如，当模式切换请求是将接单模式从派单模式切换到抢单模式的请求时，检测单元414可以检测地理区域中是否存在可用的运力。检测单元414还可以检测历史行驶评分是否大于或等于预定阈值。

在一些实施例中，接单模式确定模块410还可以包括响应单元415。当检测单元414检测到存在可用的运力和/或历史行驶评分大于或等于预定阈值时，响应单元415可以响应模式切换请求以将接单模式从派单模式切换到抢单模式。

图4c是根据本申请的一些实施例所示的服务提供者终端(例如，司机终端)中的示例性处理器的框图。

司机终端402可以包括内存、处理器和存储在内存中并由处理器执行的计算机程序。当执行计算机程序时，处理器可以执行用于显示用于在线网约车服务的接单模式的过程中的任何一个操作。在一些实施例中，司机终端402中的处理器可以包括如图4c所示的接单模式显示模块420。接单模式显示模块420可以执行图5b中描述的过程中的任何一个操作。

图4d是根据本申请的一些实施例所示的服务提供者终端中的示例性接单模式显示模块的框图。服务提供者终端(例如，司机终端)中的示例性接单模式显示模块420可以包括生成单元421。生成单元421可以生成与每个接单模式对应的初始接单界面，包括派单模式、急速接单模式或抢单模式。

在一些实施例中，接单模式显示模块420还可以包括显示单元422。当接单模式是派单模式时，显示单元422可以显示与初始接单界面的第一区域中的订单有关的时间信息。当接单模式为急速接单模式或抢单模式时，显示单元422还可以显示与初始接单界面的第一区域中的订单有关的距离信息。

在一些实施例中，当接单模式为派单模式时，显示单元422还可以在初始接单界面的显示区域中显示接单标识。当接单模式是抢单时，显示单元422还可以在初始接单界面的第二区域中显示抢单标识。

图4e是根据本申请的一些实施例所示的服务器中的示例性处理引擎的框图。示例性处理引擎112可以包括请求获取模块430、订单获取模块440、评估参数确定模块450、接单模式确定模块460、播单模式确定模块470、服务提供者选择模块480。每个模块都可以是用于执行下述操作的硬件电路、一组存储于一个或以上存储介质的指令和/或该硬件电路和一个或以上存储介质的组合。处理引擎112中的模块可以经由有线连接或无线连接彼此连接或通信。有线连接可以包括金属线缆、光缆、混合电缆等或其任意组合。无线连接可以包括局域网络(lan)、广域网(wan)、蓝牙、紫蜂网络、近场通讯(nfc)等，或其任意组合。

请求获取模块430可以与服务请求者终端130和/或服务提供者终端140通信。例如，请求获取模块430可以从服务提供者终端140接收模式确定请求和/或模式切换请求。

订单获取模块440可以从服务请求者终端130获取订单。订单可以是实时订单或预约订单。

评估参数确定模块450可以确定一个或以上接单评估参数。接单评估参数可包括与每个服务提供者相关的历史行驶评分、与每个时间段中的地理区域相关的运力等或其任何组合。地理区域中的运力可以与可用服务提供者的数量和未处理订单的数量相关。

图4f是根据本申请的一些实施例所示的示例性评估参数确定模块的框图。评估参数确定模块450可包括行驶评分确定单元451和运力确定单元452。行驶评分确定单元451可以确定服务提供者的历史行驶评分，例如，基于与服务提供者有关的历史服务数据，比如，服务提供者已接受的历史订单总数、服务提供者已完成的历史订单总数、基于服务请求者反馈的服务提供者的服务质量、历史订单成交率、历史订单接单率、历史订单拒单率等或其任何组合。运力确定单元452可以确定地理区域中的运力。在一些实施例中，运力确定单元452还可以获取服务提供者终端的位置信息，并确定位于特定地理区域中的服务提供者的数量。在一些实施例中，运力确定单元452还可以基于服务提供者的服务状态来确定特定地理区域中的可用服务提供者的数量。在一些实施例中，运力确定单元452还可以确定地理区域中的未处理订单的数量或多余订单的数量。特定时间段内特定地理区域的多余订单数量可以指特定时间段内起始位置在特定地理区域中未处理的订单数量与特定时间段内特定地理区域中可用服务提供者的数量(或在特定时间段内将在特定地理区域内的可用服务提供者的数量)之间的差值。

接单模式确定模块460可以确定服务提供者的接单模式。在一些实施例中，当请求获取模块430接收到模式切换请求时，接单模式确定模块460还可以确定是否响应模式切换请求。

图4g是根据本申请的一些实施例所示的服务器中的示例性接单模式确定模块的框图。在一些实施例中，接单模式确定模块460可以包括评估参数获取单元461、比较单元462、条件判断单元463和接单模式确定单元464。评估参数获取单元461可以从评估参数确定模块450获取一个或以上接单评估参数。例如，评估参数获取单元461可以从行驶评分确定单元451获取服务提供者的历史行驶评分。又例如，评估参数获取单元461可以从运力确定单元452获取地理区域的运力。运力可以包括地理区域中的可用服务提供者的数量、起始位置在该地理区域中未处理订单的数量。

比较单元462可以将一个或以上接单评估参数(例如，历史行驶评分、可用服务提供者的数量、未处理订单的数量、可用服务提供者的数量与未处理订单的数量之间的差值等)与一个或以上阈值进行比较。条件判断单元463可以确定接单评估参数是否大于、小于或等于阈值。

接单模式确定单元464可以基于从条件判断单元463获取的结果来确定服务提供者的接单模式。例如，当请求获取模块430获取的请求是模式确定请求时，接单模式确定单元464可以确定服务提供者的接单模式。又例如，当请求获取模块430获取的请求是模式切换请求时，接单模式确定单元464可以将接单模式从初始接单模式切换到目标接单模式。

当处理引擎112接收订单时，播单模式确定模块470可以确定播单模式。订单可以是实时订单或预约订单。可以以三个播单模式中的任何一个模式来播报订单。三个播单模式中的每一个播单模式可以对应于为服务提供者确定的三个接单模式中的一个。出于说明目的，与抢单模式相对应的播单模式在此可称为第一播单模式或抢单播单模式；对应于派单模式的播单模式在此可以称为第二播单模式或派单播单模式；对应于急速接单模式的播单模式在此可称为第三播单模式、急速播单模式和急速派单模式。

图4h是根据本申请的一些实施例所示的示例性播单模式确定模块的框图。在一些实施例中，播单模式确定模块470可以包括评估参数获取单元471、比较单元472、条件判断单元473和播单模式确定单元474。

评估参数获取单元471可以从评估参数确定模块450获取一个或以上接单评估参数。例如，评估参数获取单元464可以例如从运力确定单元452获取地理区域的运力，包括地理区域中可用服务提供者的数量、起始位置在该地理区域中的未处理订单的数量。

比较单元462可以将一个或以上评估参数(例如，可用服务提供者的数量、未处理订单的数量、可用服务提供者的数量和未处理订单的数量之间的差值)与一个或以上阈值进行比较。条件判断单元473可以确定评估参数是否大于、小于或等于阈值。

播单模式确定单元474可以基于从条件判断单元473获取的结果来确定订单的接单模式。

在一些实施例中，处理引擎112还可以包括服务提供者选择模块480。服务提供者选择模块480可以从至少两个服务提供者中识别具有特定的接单模式的服务提供者。

应当注意以上关于处理引擎112和/或接单模式确定模块410或460的描述仅仅是示例，而不是限制性的。在一些实施例中，接单模式确定模块410中描述的一个或以上单元可以对应于图4e中所示的示例性处理引擎112的一个或以上模块、图4e所示的示例性评估参数确定模块450的一个或以上单元、图4g中示出的示例性接单模式确定模块460的一个或以上单元。例如，生成单元411可以对应于图4e中所示的接单模式确定模块460。又例如，获取单元412可以对应于图4e所示的请求获取模块430。作为又一示例，确定单元413和检测单元414可以对应于评估参数确定模块450(包括图4f中所示的行驶评分确定单元451、运力确定单元452)、比较单元462和/或图4g中所示的条件判断单元463。作为又一示例，响应单元415可以对应于图4g中所示的接单模式确定单元464。

在一些实施例中，任何两个单元可以组合为单个单元。例如，评估参数确定单元461和评估参数确定单元471可以组合为单个单元。又例如，比较单元462和比较单元472可以组合为单个单元；条件判断单元463和条件判断单元473可以组合为单个单元。作为又一示例，比较单元462、比较单元472、条件判断单元463和条件判断单元473可以组合为单个单元。

在一些实施例中，任何一个模块可以分为两个或以上子模块。例如，接单模式确定模块460可以分成两个子模块。两个子模块中的第一子模块可以响应接单模式确定请求以确定服务提供者的接单模式。两个子模块中的第二子模块可以响应模式切换请求以将接单模式从初始接单模式切换到目标接单模式。

图5a是根据本申请的一些实施例所示的用于确定目标服务提供者的接单模式的示例性过程的流程图。

根据本发明的实施例，用于确定在线网约车服务的目标服务提供者的接单模式的过程500可以适用于服务器。如图5a所示，过程500可以包括：在510中，响应于服务提供者终端(例如，司机终端)的模式确定请求，根据获取的司机终端的接单评估参数，生成与相应的接单模式有关的指令，并将与相应的接单模式有关的指令反馈给司机终端。接单模式可以包括派单模式、抢单模式或急速接单模式。

在本实施例中，在接受了司机终端的模式确定请求之后，可以根据模式确定请求获取司机终端的接单评估参数，以便基于接单评估参数生成相应的接单模式。然后，接单模式可以反馈给司机终端并显示在司机终端的界面上，以确定司机终端的接单模式。这样，一方面，接单模式是基于接单评估参数确定的，这样接单模式的确定可能更符合实际需要，可以满足不同运营司机的需要，从而提高了运营效率。另一方面，可以实现司机终端的应用平台的功能整合。

接单评估参数可包括实时工况参数和历史行驶参数。实时工况参数可以表征当前运营环境，包括与运力、路况信息、订单信息等有关的信息。历史行驶参数可以表征根据司机的行驶经历确定的司机评分，包括接受订单的数量、拒绝订单的数量、服务质量等或其任何组合。

在一些实施例中，接单评估参数还可以包括司机终端当前所在的运营区域的运力和/或司机终端的历史行驶评分。运营区域可以指具有资格接受线上到线下服务系统订单的运营区域。运力可以指具有接受线上到线下服务系统订单资格的司机的数量。

在一些实施例中，与司机终端有关的运营区域可以指代在司机位置周围的地理区域。地理区域可以是任何形状或大小。例如，地理区域可以是圆形区域，其具有以司机终端的位置为中心的两公里半径。特定时间段内地理区域的运力可以是在特定时间段内位于地理区域中的有资格接受订单的在线司机的数量。

在本申请中，可以提供三种评估环境：(i)接收评估参数可以仅基于司机终端当前所在的运营区域的运力来确定，时效性更强；(ii)接单评估参数可仅基于司机终端的历史行驶评分而确定，这可能有助于司机的运营效率及运营质量；(iii)接单评估参数可基于运力和历史行驶评分确定。在一些实施例中，权值可以指定给运力和历史行驶评分，例如，根据对运力或历史行驶评分的侧重性，从而使接单模式的确定更合理。

在一些实施例中，根据获取的司机终端的接单评估参数生成相应的接单模式可以包括：当模式确定请求是从司机终端登录系统的请求(这里也称为登录请求)时，获取历史行驶评分；当检测到历史行驶评分小于第一预定阈值时，产生急速接单模式；当检测到历史行驶评分大于或等于第一预定阈值且小于或等于第二预定阈值时，产生派单模式；当检测到历史行驶评分大于第二预定阈值时，产生抢单模式，其中所述第二预定阈值大于所述第一预定阈值。

在一些实施例中，当模式确定请求是司机终端的登录请求时，系统还可以获取与司机终端相关联的司机的历史行驶评分，并将历史行驶评分与预定的评分阈值间隔进行比较。例如，可以将第一预定阈值和第二预定阈值作为分割点，以便将范围划分为第一阈值间隔、第二阈值间隔和第三阈值间隔。当检测到历史行驶评分小于第一预定阈值时，也就是当历史行驶评分属于第一阈值间隔时，可以生成派单模式；当检测到历史行驶评分大于或等于第一预定阈值且小于或等于第二预定阈值时，可以产生急速接单模式，也就是说，历史行驶评分属于第二阈值区间；当检测到历史行驶评分大于第二预定阈值时，即当历史行驶评分属于第三阈值区间时，可以生成抢单模式，因此可以实现通过使用历史行驶评分作为接单评估参数来确定接单模式的功能。

关于基于司机的历史行驶评分确定司机的接单模式的详细描述可以在图7和相关描述中找到。

急速接单模式、派单模式和抢单模式可以从低优先级到高优先级排序，即从被动模式到主动模式。具体而言，司机可能无权在急速接单模式中选择或拒绝订单，司机可能有权拒绝派单模式中的订单，并且司机在抢单模式中可能具有相对较高的自主性，例如，司机可以通过抢单的方式来选择他想要接受的订单。具体地，当司机登录系统时，可能需要确定登录后的接单模式。此时，登录系统的请求可以是确定司机的接单模式的请求，通过登录后自动匹配接单模式，这可能有助于司机终端的整合使用。

在一些实施例中，当模式确定请求是司机终端的登录请求时，在获取历史行驶评分之前，过程500还可以包括根据历史服务数据、历史订单成交率和/或预定评估模型来确定历史行驶评分。

在一些实施例中，历史行驶评分可以根据与司机终端有关的历史服务数据、历史订单成交率和预定评估模型来确定，从而可以确定历史行驶评分并将其作为接单评估参数。

在一些实施例中，预定评估模型可以包括在简单模型结构中的历史服务数据和历史订单成交率所相对应的权值。

在一些实施例中，服务器可以包括评分数据库，用于存储与一个或以上与司机有关的一个或以上评分。在每次司机完成订单之后，可以更新评分数据库中的评分。

在一些实施例中，根据获取的司机终端的接单评估参数生成接单模式可以包括：当接收到司机终端的登录请求时，根据获取的司机终端的位置信息，确定司机终端当前所在的运营区域的运力情况；当在运营区域中检测到可用的运力并且可用的运力大于或等于预定的运力阈值时，生成抢单模式；当检测到可用的运力小于预定的运力阈值时生成派单模式，或者检测到多余的订单并且多余的订单的数量小于预定的订单阈值，生成派单模式；当检测到多余订单的数量大于或等于预定订单阈值时，产生急速接单模式。

地理区域的可用运力可以指地理区域中的可用司机。可用的运力也可以指可用的司机或可用的服务提供者。地理区域中的多余订单可以指尚未处理(例如，未被分配)且起始位置落在该地理区域中的订单。在一些实施例中，多余订单的数量可以等于未处理订单的数量。然而在一些其他实施例中，多余订单的数量可以指未处理订单的数量与可用的司机的数量之间的差值。

关于针对目标司机的接单模式的确定的详细描述可以在图8a至8d及其相关描述中找到。

在一些实施例中，当收到司机终端的登录请求时，司机终端的位置信息可以由司机终端的定位设备获取，以根据司机终端的位置信息确定司机终端当前所在的运营区域，并进一步确定运营区域的运力。当检测到可用的运力并且可用的运力大于或等于预定的运力阈值时，可以生成抢单模式；当检测到可用的运力小于预定的运力阈值，或者检测到多余的订单并且多余订单的数量小于预定的订单阈值时，可以生成派单模式；当检测到多余订单的数量大于或等于预定的订单阈值时，可以生成急速接单模式。基于运营区域的运力确定接单模式的方式可以有助于运力的合理分配，也可以有助于提高司机的订单接受效率。

在一些实施例中，预约订单也可以在上述接单模式下接单。

具体地，当检测到较多的可用司机时，即，当司机的数量大于用户(即乘客)的数量时，可以设置抢单模式。因此，一方面，通过司机主动控制接单，可以提高接受订单的公平性，另一方面，还可以提醒用户(例如，司机、乘客)关于当前区域中的剩余运力。当检测到用户(即乘客)的数量大于司机的数量时，可以设置急速接单模式，在这种情况下，与抢单模式或派单模式相比，效率更高。当检测到司机的数量等于订单的数量时，可以设置为派单模式，以便平衡司机和订单。

在一些实施例中，对于三线城市，由于司机数量有限，当司机登录系统时，服务器可以直接确定急速接单模式为三线城市中司机的接单模式。在这种情况下，当在系统后台接收到订单信息时，系统可以根据司机与订单相关的乘客的接送点之间的距离，识别具有急速接单模式的至少一个司机直接分配订单。

另外，当司机登录系统时，可能需要确定登录后的接单模式。此时，司机终端的登录请求可以被视为确定接单模式的请求，并且可以在登录后自动匹配接单模式，这可以有助于司机终端的整合使用。

在一些实施例中，根据获取的司机终端的接单评估参数确定接单模式可以包括：当模式确定请求是从司机终端发送的接单模式切换请求时，根据运力和/或历史行驶评分确定是否响应接单模式切换请求。

在一些实施例中，当接收的模式确定请求是接单模式切换请求时，可以根据运力和/或历史行驶评分确定是否执行切换操作。因此，一方面，当满足切换条件时，可以切换接单模式，另一方面，根据运营动力和/或历史行驶评分确定是否响应切换请求，有利于动力平衡，从而提高了司机终端的服务质量。

在一些实施例中，当模式确定请求是司机终端发送的接单模式切换请求时，根据运力和/或历史行驶评分确定是否响应接单模式切换请求可以包括：当接单模式切换请求从派单模式切换到抢单模式时，检测运营区域中是否存在可用的运力和/或检测历史行驶评分是否大于或等于预定的评估阈值；当检测到运营区域中存在可用的运力和/或历史行驶评分大于或等于预定的评估阈值时，响应接单模式切换请求，以便从派单模式切换到抢单模式。

在一些实施例中，当接单模式切换请求是从派单模式切换到抢单模式时，通过检测运营区域中是否存在可用的运力和/或历史行驶评分是否大于或等于预定的评价阈值，当检测到在运营动力中存在可用的运力和/或历史行驶评分大于或等于预定的评价阈值时，可以执行切换操作。检测是否存在可用运力的目的是检测运行状态并确定是否需要切换到抢单模式。检测历史行驶评分是否大于或等于预定评价阈值的目的是确定司机是否具有切换请求的资格。

在一些实施例中，当接单模式是派单模式时，服务器可以向特定的司机终端发送订单接受指令，并检测在预定时间段内是否接收到由特定司机终端反馈的确认信息，以确认该订单是否已被接受。当接单模式是抢单模式时，服务器可以向至少两个司机终端发送抢单指令，并根据至少两个司机终端的响应状态从至少两个司机终端确定接受订单的司机终端。当接单模式为急速接单模式时，服务器可以直接向特定的司机终端发送订单。

图5b是根据本申请的一些实施例所示的用于在服务提供者终端中生成初始接单界面的示例性过程的流程图。

用于确定生成初始接单界面的过程550可以适用于司机终端。如图5b所示，过程550可以包括：在520中，响应于服务器生成的接单模式，在模式确定请求被发送到服务器之后生成与接单模式相对应的初始接单界面。接单模式可以包括派单模式、抢单模式和急速接单模式。

在一些实施例中，在模式确定请求由司机终端发送到服务器之后，可以根据模式确定请求获取与司机终端相关的接单评估参数，以便基于接单评估参数生成相应的接单模式。然后，接单模式可以反馈给司机终端并显示在司机终端的界面上，以确定用于司机终端的接单模式。这样，一方面，接单模式是基于接单评估参数确定的，这样接收模式的确定可能更符合实际需要，可以满足不同司机的需要，从而提高了运营效率。另一方面，可以实现司机终端应用平台的功能整合。

在一些实施例中，模式确定请求可以是司机终端的登录请求，或者是登录后从司机终端发送的接单模式切换请求。

在一些实施例中，生成与接单模式相对应的初始接单界面可以包括：当接单模式为派单模式时，在第一区域(也称为第一显示区域)中显示订单的时间信息，当接单模式为抢单模式或急速接单模式时，在第一区域中显示与订单有关的距离信息。

当接单模式为派单模式时，在第一区域中显示订单的时间信息，并且当接单模式为抢单模式或急速接单模式时，在第一区域显示订单距离信息。在派单模式时，通过显示订单的时间信息时，能够使司机更加关注接客户的时间。对于抢单模式和急速接单模式，由于具有实时性的特点，通过在第一区域中显示订单的距离信息，特别是在抢单模式下，可以为用户是否执行抢单提供参考。

在一些实施例中，生成与接单模式相对应的初始接单界面还可以包括：当接单模式为派单模式时，在第二区域(也称为第二显示区域)中显示接单标识，当接单模式为抢单模式时，在第二区域中显示抢单标识。

当接单模式为派单模式时，在第二区域中显示接单标识的方式，以及在接单模式为抢单模式时第二区域中的抢单标识可以提醒用户(例如，司机)执行接单、拒单或抢单，从而有利于提升用户体验。

图6是根据本申请的一些实施例所示的用于确定目标服务提供者的接单模式的示例性过程的流程图。在一些实施例中，过程600可以在如图1所示的线上到线下服务系统100中实现。例如，过程600可以作为指令的形式存储在存储器150和/或其他存储器(例如，rom230、ram240)中，并且由服务器110(例如，服务器110中的处理引擎112、服务器110中的处理引擎112的处理器220、服务器110中的处理引擎112的一个或以上模块)调用和/或执行。以下所示过程的操作仅出于说明的目的。在一些实施例中，过程600可以通过未描述的一个或多个以上附加操作和/或一个或以上没有所讨论的操作来完成。另外，如图6所示和下面描述的过程600的操作的顺序不是限制性的。

在610中，处理引擎112(例如，请求获取模块430)可以接收用于确定目标服务提供者的接单模式的请求(在此也称为模式确定请求)。在一些实施例中，模式确定请求可以由目标服务提供者通过与目标服务提供者相关联的用户终端(例如，服务提供者终端140)发起。例如，当目标服务提供者发起登录线上到线下服务系统110的请求(这里也称为登录请求)时，处理引擎112可以立即获取登录请求并确定目标服务提供者的接单模式。在这种情况下，登录请求可以被视为模式确定请求。在一些实施例中，模式确定请求可以由处理引擎112确定。处理引擎112可以检测是否确定目标服务提供者的接单模式。例如，当目标服务提供者登录线上到线下服务系统100时，处理引擎112可以指示目标服务提供者选择接单模式并发送所选择的接单模式以显示在与目标服务提供者相关联的服务提供者终端140的用户界面上。又例如，一旦检测到目标服务提供者登录线上到线下服务系统100，处理引擎112可以指示目标服务提供者发送要在服务提供者终端140的用户界面上显示的查询，以确定是否需要确定接单模式。如果目标服务提供者需要确定接单模式，即目标服务提供者发起模式确定请求或确认模式确定查询，处理引擎112可以确定目标服务提供者的接单模式。又例如，当目标服务提供者登录线上到线下服务系统100并且没有进一步的动作，例如在预定时间段内选择接单模式，处理引擎112可以自动确定目标服务提供者发起确定接单模式的请求。

当处理引擎112接收到请求时，处理引擎112(例如，评估参数确定模块112)可以在620中确定关于目标服务提供者的接单评估参数。在一些实施例中，接单评估参数可以包括与目标服务提供者相关联的历史行驶评分、与目标服务提供者相关联的目标服务提供者终端140所在的地理区域的运力。地理区域可以是任何形状或大小。对于实时订单，运力可能与当前时间有关。对于预约订单，运力可以与预约订单的开始时间相关。

在630中，处理引擎630(例如，接单模式确定模块460)可以基于接单评估参数确定目标服务提供者的接单模式。在一些实施例中，处理引擎112可以仅基于与目标服务提供者相关联的历史行驶评分来确定接单模式。在一些实施例中，处理引擎112可以仅基于与目标服务提供者相关联的目标服务提供者终端140所处的地理区域的运力来确定接单模式。在一些实施例中，处理引擎112可以基于历史行驶评分和运力来确定接单模式。

在一些实施例中，处理引擎112可以为同一运营区域(例如，城市)中的所有服务提供者确定相同的接单模式。例如，在小城市的交通高峰期，要分配的订单数量可能远大于可用服务提供者的数量。为了有效地服务于小城市中的服务请求者，处理引擎112可以为城市中的所有服务提供者指定急速接单模式。

在一些实施例中，当确定接单模式时，处理引擎112可以向目标服务提供者发送通知，请求服务提供者确认所确定的接单模式。该通知可以通过网络120发送，并以文本、图像、音频、视频等形式显示在服务提供者终端140上。在一些实施例中，处理引擎112可以将所确定的接单模式分配给目标服务提供者而无需请求确认。

图7是根据本申请的一些实施例所示的用于基于目标服务提供者的历史行驶评分来确定目标服务提供者的接单模式的示例性过程的流程图。在一些实施例中，过程700可以在如图1所示的线上到线下服务系统100中实现。例如，过程700可以作为指令的形式存储在存储器150和/或其他存储器(例如，rom230、ram240)中，并且由服务器110(例如，服务器110中的处理引擎112、服务器110中的处理引擎112的处理器220、服务器110中的处理引擎112的一个或以上模块)调用和/或执行。以下所示过程的操作仅出于说明的目的。在一些实施例中，过程700可以通过未描述的一个或多个以上附加操作和/或一个或以上没有所讨论的操作来完成。另外，如图7a所示和下面描述的过程700的操作的顺序不是限制性的。在一些实施例中，可以根据过程700执行过程600的操作620。

在710中，处理引擎112(例如，评估参数获取单元461)可以从评估参数确定模块450，例如，行驶评分确定单元451，获取与目标服务提供者相关联的历史行驶评分。在一些实施例中，行驶评分确定单元451可以基于与目标服务提供者相关的历史服务数据来确定历史行驶评分，例如，目标服务提供者已接受的历史订单总数、目标服务提供者已完成的历史订单总数、基于服务请求者反馈的目标服务提供者的服务质量、历史订单成交率、历史订单接单率、历史订单拒单率等或其任何组合。历史订单成交率可以是目标服务提供者已完成的历史订单总数与目标服务提供者已接受的历史订单总数之间的比率。在一些实施例中，行驶评分确定单元451可以使用基于目标服务提供者的历史服务数据(例如，历史订单成交率)的预定评估模型来确定与目标服务提供者相关联的历史行驶评分。

在720中，处理引擎112(例如，比较单元462)可以将历史行驶评分与第一阈值和第二阈值进行比较。所述第二阈值可以大于所述第一阈值。在一些实施例中，第一阈值和/或第二阈值可以是由线上到线下服务系统100设置的默认值。在一些实施例中，第一阈值和/或第二阈值可以根据各种因素进行调整，例如，不同的时间段、不同的位置等。

在730中，处理引擎112(例如，条件判断单元463)可以确定历史行驶评分是否小于第一阈值。

响应于确定历史行驶评分小于第一阈值，在740，处理引擎112(例如，接单模式确定模块460的接单模式确定单元464)可以将急速接单模式指定为目标服务提供者的接单模式。

响应于确定历史行驶评分等于或大于第一阈值，在750，处理引擎112(例如，条件判断单元463)可进一步确定历史行驶评分是否大于第二阈值。

响应于确定历史行驶评分大于第二阈值，在770，处理引擎112(例如，接单模式确定单元464)可以将抢单模式指定为目标服务提供者的接单模式。

响应于确定历史行驶评分小于或等于第二阈值，在760，处理引擎112(例如，接单模式确定单元464)可以将派单模式指定为目标服务提供者的接单模式。

在一些实施例中，处理引擎112可以在操作730之前执行操作750。在一些实施例中，处理引擎112可以同时执行操作730和750。

图8a是根据本申请的一些实施例所示的用于基于运力确定目标服务提供者的接单模式的示例性过程的流程图。在一些实施例中，过程800可以在如图1所示的线上到线下服务系统100中实现。例如，过程800可以作为指令的形式存储在存储器150和/或其他存储器(例如，rom230、ram240)中，并且由服务器110(例如，服务器110中的处理引擎112、服务器110中的处理引擎112的处理器220、服务器110中的处理引擎112的一个或以上模块)调用和/或执行。以下所示过程的操作仅出于说明的目的。在一些实施例中，过程800可以通过未描述的一个或多个以上附加操作和/或一个或以上没有所讨论的操作来完成。

在801中，处理引擎112(例如，评估参数获取单元461)可以从运力确定单元452获取目标服务提供者周围的地理区域中可用的服务提供者的数量(在此也称为可用服务提供者的第一数量)。地理区域可以是任何形状或大小。可用的服务提供者可以指可以接受地理区域中的订单的服务提供者。在一些实施例中，运力确定单元452可以通过服务提供者终端的定位模块获取服务提供者的位置信息，并识别位于地理区域中的所有服务提供者。然后运力确定单元452可以基于服务提供者的服务状态来确定可用服务提供者的第二数量。

在处理引擎112获取目标服务提供者周围的地理区域中的可用服务提供者的第一数量之后，处理引擎112(例如，比较单元462)可以将可用服务提供者的第一数量与运力阈值进行比较。在一些实施例中，运力阈值可以是由线上到线下服务系统100设置的默认值。在一些实施例中，运力阈值可以根据各种因素进行调整，例如，不同的时间段、不同的位置等。

在802中，处理引擎112(例如，条件判断单元463)可以确定可用服务提供者的第一数量是否大于或等于运力阈值。

响应于确定可用服务提供者的第一数量大于或等于运力阈值，在803，处理引擎112(例如，接单模式确定单元464)可以将抢单模式指定为目标服务提供者的接单模式。

响应于确定可用服务提供者的第一数量小于运力阈值，在804，处理引擎112(例如，接单模式确定单元464)可以将派单模式指定为目标服务提供者的接单模式。

图8b是根据本申请的一些实施例所示的用于基于运力确定目标服务提供者的接单模式的示例性过程的流程图。在一些实施例中，过程810可以在如图1所示的线上到线下服务系统100中实现。例如，过程810可以作为指令的形式存储在存储器150和/或其他存储器(例如，rom230、ram240)中，并且由服务器110(例如，服务器110中的处理引擎112、服务器110中的处理引擎112的处理器220、服务器110中的处理引擎112的一个或以上模块)调用和/或执行。以下所示过程的操作仅出于说明的目的。在一些实施例中，过程810可以通过未描述的一个或多个以上附加操作和/或一个或以上没有所讨论的操作来完成。

在811中，处理引擎112(例如，评估参数单元461)可以从运力确定单元452获取与目标服务提供者周围的地理区域中的运力相关的未处理订单的第一数量(在此也称为未处理订单的第一数量)。未处理订单可以指代由服务器110接受但尚未分配给服务提供者的订单。在一些实施例中，服务器110可以从至少两个服务请求者获取订单。每个订单可以与一个起始位置相关联。订单的起始位置可以指上车位置。起始位置可以与服务请求者的当前位置相同或不同。运力确定单元452可以在至少两个订单中识别起始位置落在地理区域中并且尚未分配的订单。

处理引擎112在目标服务提供者周围的地理区域中获取未处理订单的第一数量后，处理引擎112(例如，比较单元462)可以将未处理订单的第一数量与订单阈值进行比较。在一些实施例中，订单阈值可以是由线上到线下服务系统100设置的默认值。在一些实施例中，可以根据各种因素(例如，不同的时间段、不同的位置等)来调整订单阈值。

在812中，处理引擎112(例如，条件判断单元463)可以确定未处理订单的第一数量是否大于或等于订单阈值。

响应于确定未处理订单的第一数量大于或等于订单阈值，在813中，处理引擎112(例如，接单模式确定单元464)可以将急速接单模式指定为目标服务提供者的接单模式。

响应于确定未处理订单的第一数量大于或等于订单阈值，在814中，处理引擎112(例如，接单模式确定单元464)可以将派单模式指定为目标服务提供者的接单模式。

图8c和8d是根据本申请的一些实施例所示的用于基于运力确定目标服务提供者的接单模式的示例性过程的流程图。在一些实施例中，过程820和/或830可以在如图1所示的线上到线下服务系统100中实现。例如，过程820和/或830可以作为指令的形式存储在存储器150和/或其他存储器(例如，rom230、ram240)中，并且由服务器110(例如，服务器110中的处理引擎112、服务器110中的处理引擎112的处理器220、服务器110中的处理引擎112的一个或以上模块)调用和/或执行。以下呈现的所示过程的操作旨在说明。在一些实施例中，过程820和/或830可以通过未描述的一个或多个以上附加操作和/或一个或以上没有所讨论的操作来完成。

在821中，处理引擎112(例如，评估参数单元461)可以从运力确定单元452获取目标服务提供者周围的地理区域中的可用服务提供者的数量和未处理订单的数量。

在822中，处理引擎112(例如，比较单元462)可以将可用服务提供者的数量与未处理的订单的数量进行比较。

在823中，处理引擎112(例如，条件判断单元463)可以确定可用服务提供者的数量是否大于未处理订单的数量。

响应于确定可用服务提供者的数量大于未处理订单的数量，在824中，处理引擎112(例如，接单模式确定模块460的差值确定单元(图4g中未示出))可以确定可用服务提供者数与未处理订单的数量之间的第一差值。

在处理引擎112确定可用服务提供者的数量与未处理订单的数量之间的第一差值之后，处理引擎112(例如，比较单元462)可以将第一差值与第三阈值进行比较。在825中，处理引擎112(例如，条件判断单元463)可以确定第一差值是否大于第三阈值。

响应于确定第一差值大于第三阈值，在826中，处理引擎112(例如，接单模式确定单元464)可以将抢单模式指定为目标服务提供者的接单模式。

响应于确定可用服务提供者的数量大于未处理订单的数量且第一差值小于或等于第三阈值，在827中，处理引擎112(例如，接单模式确定单元464)可以将派单模式指定为目标服务提供者的接单模式。

响应于确定可用服务提供者的数量小于或等于未处理订单的数量，过程820可以进行到图8d所示的过程830(在图8c中表示为“a”)。

在831中，处理引擎112(例如，接单模式确定单元460中的差值确定单元(图4g中未示出))可以确定未处理订单数与可用服务提供者数之间的第二个差值。

在处理引擎112确定未处理订单的数量与可用服务提供者的数量之间的第二差值之后，处理引擎112(例如，比较单元462)可以将第二差值与第四阈值进行比较。第四阈值可以与第三阈值相同或不同。在832中，处理引擎112(例如，条件判断单元463)可以确定第二差值是否大于第四阈值。

响应于确定第二差异大于第四阈值，在833中，处理引擎112(例如，接单模式确定单元464)可以将急速接单模式指定为目标服务提供者的接单模式。

响应于确定可用服务提供者的数量小于或等于未处理订单的数量且第二差值小于或等于第四阈值，在834中，处理引擎112(例如，接单模式确定单元464)可以将派单模式指定为目标服务提供者的接单模式。

图9是根据本申请的一些实施例所示的用于确定是否为目标服务提供者切换接单模式的示例性过程的流程图。在一些实施例中，过程900可以在如图1所示的线上到线下服务系统100中实现。例如，过程900可以作为指令的形式存储在存储器150和/或其他存储器(例如，rom230、ram240)中，并且由服务器110(例如，服务器110中的处理引擎112、服务器110中的处理引擎112的处理器220、服务器110中的处理引擎112的一个或以上模块)调用和/或执行。以下所示过程的操作仅出于说明的目的。在一些实施例中，过程900可以通过未描述的一个或多个以上附加操作和/或一个或以上没有所讨论的操作来完成。另外，如图6所示和下面描述的过程600的操作的顺序不是限制性的。

在910中，处理引擎112(例如，请求获取模块430)可以接收用于切换目标服务提供者的接单模式的请求(这里也称为模式切换请求)。模式切换请求可以包括将接单模式从初始接单模式切换到目标接单模式的请求。初始接单模式可以是急速接单模式、派单模式或抢单模式中的任何一种。目标接单模式也可以是急速接单模式、派单模式或抢单模式中的任何一种。在一些实施例中，订单切换请求可以来自与目标服务提供者相关联的服务提供者终端140。例如，在服务提供者接受派单模式或派单模式的订单的一段时间后，他/她想要在下一个时间段接受更多订单，或者他/她只想选择具有特定属性(例如，目的地与机场相关的订单)的订单来接受，他/她可以发起将接单模式从派单模式或派单模式切换到抢单模式的请求。

在一些实施例中，模式确定请求可以由处理引擎112本身生成。例如，处理引擎112可以实时检测与目标服务提供者相关联的地理区域的运力。当运力满足预定条件时，处理引擎112可以自动切换目标服务提供者的接单模式。在这种情况下，可以将对预定条件的满足视为切换接单模式的请求。例如，特定时间段中的订单数量是n1，并且下一时间段中的订单数量是n1+m，其中m大于阈值是预定条件。当满足预定条件时，即m大于阈值，服务器110可以将接单模式从派单模式切换到急速接单模式。又例如，处理引擎112可以在不同时间段(例如，不同日期)为服务提供者指定不同的接单模式，并且预定条件可以是服务提供者登录线上到线下服务系统100。当满足预定条件时，即服务提供者登录线上到线下服务系统100，处理引擎112可以将接单模式从为星期一分配的接单模式切换到为星期日分配的接单模式。作为又一示例，处理引擎112可以为不同的区域(例如，不同的城市、不同的地区)指定不同的接单模式，预定条件可以是服务提供者从对应于第一接单模式的区域移动到对应于第二接单模式的区域。当满足预定条件时，即服务提供者从对应于第一接单模式的区域移动到对应于第二接单模式的区域，处理引擎112可以将服务提供者的接单模式从第一接单模式切换到第二接单模式。

当处理引擎112(例如，接单模式确定模块460)接收到模式切换请求时，在920中，处理引擎112(例如，评估参数确定模块450)可以获取关于目标服务提供者的接单评估参数。在一些实施例中，接单评估参数可以包括与目标服务提供者相关联的历史行驶评分、与目标服务提供者相关联的目标服务提供者终端140所处的地理区域的运力。地理区域可以是任何形状或大小。对于实时订单，运力可能与当前时间有关。对于预约订单，运力可以与与预约订单的开始时间有关。

在930中，处理引擎112(例如，接单模式确定模块460)可以基于接单评估参数和模式切换请求来确定是否切换目标服务提供者的接单模式。在一些实施例中，处理引擎112可以仅基于与目标服务提供者相关联的历史行驶评分来确定是否切换接单模式。在一些实施例中，处理引擎112可以仅基于与目标服务提供者相关联的目标服务提供者终端140可能位于的地理区域的运力来确定是否切换接单模式。在一些实施例中，处理引擎112可以基于历史行驶评分和运力来确定是否切换接单模式。

当处理引擎112(例如，接单模式确定模块460)确定对于目标服务提供者的接单模式可以从初始接单模式切换到目标接单模式时，接单模式确定模块460可以将接单模式从初始接单模式切换到目标接单模式。

在一些实施例中，当处理引擎112(例如，接单模式确定模块460)对于目标服务提供者切换接单模式时，处理引擎112可以向目标服务提供者发送通知，请求服务提供者确认接单模式已被切换并确认目标接单模式。该通知可以通过网络120发送，并以文本、图像、音频、视频等形式显示在服务提供者终端140上。在一些实施例中，处理引擎112可以将目标接单模式分配给目标服务提供者而无需请求确认。

图10a是根据本申请的一些实施例所示的用于基于运力确定是否对于目标服务提供者将接单模式从派单模式切换到抢单模式的示例性过程的流程图。在一些实施例中，过程1000可以在如图1所示的线上到线下服务系统100中实现。例如，过程1000可以作为指令的形式存储在存储器150和/或其他存储器(例如，rom230、ram240)中，并且由服务器110(例如，服务器110中的处理引擎112、服务器110中的处理引擎112的处理器220、服务器110中的处理引擎112的一个或以上模块)调用和/或执行。以下所示过程的操作仅出于说明的目的。在一些实施例中，过程1000可以通过未描述的一个或多个以上附加操作和/或一个或以上没有所讨论的操作来完成。

在1010中，处理引擎112(例如，请求获取模块430)可以获取用于将接单模式对于目标服务提供者从派单模式切换到抢单模式的请求。在一些实施例中，处理引擎112可以从与目标服务提供者相关联的终端(例如，服务提供者终端140)获取请求。

在1020中，处理引擎112(例如，评估参数获取单元461)可以从运力确定单元452获取目标服务提供者周围的地理区域中的运力(例如，可用服务提供者的数量)。地理区域可以是任何形状或大小。在一些实施例中，运力确定单元452可以识别位于地理区域中的所有服务提供者，并基于服务提供者的服务状态确定可用服务提供者的数量。例如，运力确定单元452可以通过服务提供者终端的定位模块获取位置信息。

在处理引擎112获取目标服务提供者周围的地理区域中的可用服务提供者的数量之后，处理引擎112(例如，比较单元462)可以将可用服务提供者的数量与运力阈值进行比较。在一些实施例中，运力阈值可以是由线上到线下服务系统100设置的默认值。在一些实施例中，运力阈值可以根据各种因素进行调整，例如，不同的时间段、不同的位置等。

在1030，处理引擎112(例如，条件判断单元463)可以确定可用服务提供者的数量是否大于或等于运力阈值。

响应于确定可用服务提供者的数量大于或等于运力阈值，在1040中，处理引擎112(例如，接单模式确定单元464)可以将目标服务提供者的接单模式从派单模式切换到抢单模式。

响应于确定可用服务提供者的第一数量小于运力阈值，处理引擎112(例如，接单模式确定单元464)可能不响应模式切换请求。

还应该注意，以上关于基于与运力相对应的可用服务提供者的数量来切换目标服务提供者的接单模式的过程的描述仅仅是一个示例，并不旨在限制性的。在一些实施例中，处理引擎112还可以基于目标服务提供者周围地理区域中未处理订单的数量，确定是否将目标服务提供者的接单模式从派单模式切换到抢单模式。在一些实施例中，处理引擎112还可以基于目标服务提供者周围的地理区域中未处理订单的数量和可用服务提供者的数量，确定是否将目标服务提供者的接单模式从派单模式切换到抢单模式。

图10b是根据本申请的一些实施例所示的用于基于目标服务提供者的历史行驶评分将目标服务提供者的接单模式从派单模式切换到抢单模式的示例性过程的流程图。在一些实施例中，过程1001可以在如图1所示的线上到线下服务系统100中实现。例如，过程1001可以作为指令的形式存储在存储器150和/或其他存储器(例如，rom230、ram240)中，并且由服务器110(例如，服务器110中的处理引擎112、服务器110中的处理引擎112的处理器220、服务器110中的处理引擎112的一个或以上模块)调用和/或执行。以下所示过程的操作仅出于说明的目的。在一些实施例中，过程1001可以通过未描述的一个或以上附加操作和/或一个或以上没有所讨论的操作来完成。

在1015中，处理引擎112(例如，请求获取模块430)可以获取关于将目标服务提供者的接单模式从派单模式切换到抢单模式的请求。在一些实施例中，处理引擎112可以从与目标服务提供者相关联的终端(例如，服务提供者终端140)获取请求。

在1025中，处理引擎112(例如，评估参数获取单元461)可以从评估参数确定模块450获取与目标服务提供者相关联的历史行驶评分，例如，行驶评分确定单元451。在一些实施例中，行驶评分确定单元451可以基于与目标服务提供者相关的历史服务数据来确定历史行驶评分，例如，目标服务提供者已接受的历史订单总数、目标服务提供者已完成的历史订单总数、基于服务请求者反馈的目标服务提供者的服务质量、历史订单成交率、历史订单接单率、历史订单拒单率等或其任何组合。历史订单成交率可以是目标服务提供者已完成的历史订单总数与目标服务提供者已接受的历史订单总数之间的比率。在一些实施例中，行驶评分确定单元451可以使用基于目标服务提供者的历史服务数据(例如，历史订单成交率)的预定评估模型来确定与目标服务提供者相关联的历史行驶评分。

在处理引擎112获取与目标服务提供者相关联的历史行驶评分之后，处理引擎112(例如，比较单元462)可以将历史行驶评分与第二阈值进行比较。在一些实施例中，第二阈值可以是由线上到线下服务系统100设置的默认值。在一些实施例中，第二阈值可以根据各种因素进行调整，例如，不同的时间段、不同的位置等。

在1035中，处理引擎112(例如，条件判断单元463)可以确定历史行驶评分是否大于或等于第二阈值。

响应于确定历史行驶评分大于或等于第二阈值，处理引擎112(例如，接单模式确定单元464)可以将目标服务提供者的接单模式从派单模式切换到抢单模式。

在一些实施例中，处理引擎112可以基于与目标服务提供者相关联的运力和历史行驶评分，确定是否将目标服务提供者的接单模式从派单模式切换到抢单模式。只有当运力满足运力条件并且历史行驶评分满足评分条件时，例如，只有当可用服务提供者的数量大于或等于运力阈值且目标服务提供者的历史评分大于或等于第二阈值时，处理引擎112可以将目标服务提供者的接单模式从派单模式切换到抢单模式。

当处理引擎12确定服务提供者的接单模式时，服务提供者可以以相应的接单模式接受订单。

图11是根据本申请的一些实施例所示的用于播报目标订单的示例性过程的流程图。在一些实施例中，过程1100可以在如图1所示的线上到线下服务系统100中实现。例如，过程1100可以作为指令的形式存储在存储器150和/或其他存储器(例如，rom230、ram240)中，并且由服务器110(例如，服务器110中的处理引擎112、服务器110中的处理引擎112的处理器220、服务器110中的处理引擎112的一个或以上模块)调用和/或执行。以下所示过程的操作仅出于说明的目的。在一些实施例中，过程1100可以通过未描述的一个或多个以上附加操作和/或一个或以上没有所讨论的操作来完成。另外，如图9a所示和下面描述的过程900的操作的顺序不是限制性的。

在一些实施例中，可以以三种播单模式中的一种来播报订单。三个播单模式中的每一个可以对应于用于服务提供者的三个接单模式中的一个。出于说明目的，与抢单模式相对应的播单模式在此可称为第一播单模式或抢单播单模式；对应于派单模式的播单模式在此可以称为第二播单模式或派单播单模式；对应于急速接单模式的播单模式在此可称为第三播单模式、急速播单模式或急速派单模式。

在1110中，处理引擎112(例如，订单获取模块440)可以从服务请求者终端获取目标订单。与目标订单有关的信息可以包括目标订单的目标起始位置、目标订单的目标目的地、与服务请求者终端相关联的当前位置、起始时间等，或其任何组合。目标订单可以是实时订单或预约订单。

在1120中，处理引擎112(例如，播单模式确定模块470)可以确定目标订单的播单模式。在一些实施例中，处理引擎112可以基于目标订单的起始位置确定目标订单的播单模式。例如，如果目标订单的起始位置在城市中并且城市中的服务提供者的接单模式被配置为特定的接单模式(例如，急速接单模式)，处理引擎112(例如，播单模式确定模块470)可以将对应于特定接单模式的播单模式指定为目标订单的播单模式。然后，处理引擎112可以在所确定的播单模式中播报目标订单。

在一些实施例中，处理引擎112(例如，播单模式确定模块470)可以基于目标订单的起始位置周围的运力来确定目标订单的播单模式。可以在图12a和12b及其相关描述中找到基于目标订单的起始位置周围的运力确定目标订单的播单模式。

在一些实施例中，当确定播单模式后，处理引擎112可以识别一个或以上接单模式与所确定的播单模式相对应的服务提供者。在一些实施例中，当处理引擎112播报订单时，处理引擎112可以仅在订单的起始位置周围的预定范围内向服务提供者播报订单。在一些实施例中，当服务提供者以不同的接单模式接单时，处理引擎112还可以选择接单模式与订单的播单模式相对应的服务提供者。在一些实施例中，如果服务提供者处于合适的接单模式，但服务提供者的位置(例如，对应于订单起始时间的位置)远离订单的起始位置，处理引擎112可以不将该订单播报给服务提供者。

因此，要为目标订单确定合适的服务提供者，在1130中，处理引擎112(例如，服务提供者选择模块480)可以在目标订单的目标起始位置周围的预定范围内识别一个或以上候选服务提供者。预定范围可以是任何形状或大小。例如，预定范围可以是圆形区域，其具有以目标订单的目标起始位置为中心的两公里半径。在一些实施例中，预定范围可以是固定的或可通过线上到线下服务系统100调节。在一些实施例中，对于不同的播单模式，预定范围可以是相同的。在一些实施例中，预定范围可根据不同的播单模式进行调整。

在1140中，处理引擎112(例如，服务提供者选择模块480)可以进一步从至少两个候选服务提供者中识别一个或以上服务提供者。一个或以上所识别的服务提供者可以具有对应于所确定的目标订单的播单模式的接单模式。

在1150中，处理引擎112可以以所确定的播单模式中将目标订单播报到一个或以上识别的服务提供者。

在一些实施例中，如果目标订单的播单模式对应于急速接单模式，即，目标订单的播单模式是第三播单模式，处理引擎112可以直接将目标订单发送给一个或以上识别的服务提供者中的一个服务提供者。在一些实施例中，接受目标订单的服务提供者可以是一个或以上识别的服务提供者中的任何一个。在一些实施例中，可以根据某些因素来选择接受目标订单的服务提供者，例如，一个或以上所识别的服务提供者的历史行驶评分。

如果目标订单的播单模式对应于派单模式，即目标订单的播单模式是第二播单模式，处理引擎112还可以根据一些因素，例如，一个或以上识别的服务提供者的历史行驶评分，从一个或以上识别的服务提供者中选择一定数量(例如，两个、三个、四个、五个)服务提供者播报目标订单。例如，在处理引擎112将目标订单播报到所选择的服务提供者之后，处理引擎112可以将目标订单发送给所选择的服务提供者中的一个服务提供者。如果该服务提供者在预定时间段(例如，15秒、30秒)内不接受目标订单，处理引擎112还可以将目标订单发送给所选择的服务提供者的另一个服务提供者，直到目标订单被接受。在一些实施例中，如果所选择的服务提供者都没有接受目标订单，处理引擎112可以从一个或以上识别的服务提供者中重新选择服务提供者，或者调整预定范围以重新确定候选服务提供者。

如果目标订单的播单模式对应于抢单模式，即目标订单的播单模式是第一播单模式，处理引擎112还可以根据一些因素播报，例如，一个或以上确认的服务提供者的历史行驶评分，从一个或以上识别的服务提供者中选择一定数量(例如，两个、三个、四个、五个)服务提供者目标订单。在这种情况下，所选择的服务提供者的数量可以大于当播单模式是第二播单模式时所选择的服务提供者的数量。处理引擎112以抢单模式将目标订单播报到选定的服务提供者之后，处理引擎112可以确定对目标订单的播报做出响应的服务提供者。然后，处理引擎112可以将目标订单指定给首先响应的服务提供者。在一些实施例中，两个或以上服务提供者可同时作出回应，然后处理引擎112可以确定两个或以上服务提供者中的一个(也称为最终服务提供者)来接受目标订单。在一些实施例中，最终服务提供者可以是两个或以上服务提供者中的任何一个。在一些实施例中，处理引擎112可以根据某些因素，例如，两个或以上服务提供者的历史行驶评分，从两个或以上服务提供者确定最终服务提供者。

图12a是根据本申请的一些实施例所示的用于确定目标订单的播单模式的示例性过程的流程图。在一些实施例中，过程1200可以在如图1所示的线上到线下服务系统100中实现。例如，过程1200可以作为指令的形式存储在存储器150和/或其他存储器(例如，rom230、ram240)中，并且由服务器110(例如，服务器110中的处理引擎112、服务器110中的处理引擎112的处理器220、服务器110中的处理引擎112的一个或以上模块)调用和/或执行。以下所示过程的操作仅出于说明的目的。在一些实施例中，过程1200可以通过未描述的一个或多个以上附加操作和/或一个或以上没有所讨论的操作来完成。另外，如图12a所示和下面描述的过程1200的操作的顺序不是限制性的。在一些实施例中，可以根据过程1200执行过程1100的操作1120。

在1210中，处理引擎112(例如，评估参数获取单元471)可以从运力确定单元452获取目标订单的目标起始位置周围的目标地理区域内的可用服务提供者的数量(在此也称为可用服务提供者的第二数量)。目标地理区域可以是任何形状或大小。可用服务提供者可以指在目标地理区域中可用的服务提供者。在一些实施例中，运力确定单元452可以通过服务提供者终端的定位模块获取服务提供者的位置信息，并识别位于目标地理区域内的所有服务提供者。然后，运力确定单元452可以基于服务提供者的服务状态来确定可用服务提供者的第二数量。

在处理引擎112获取目标起始位置周围的目标地理区域内可用服务提供者的第二数量之后，处理引擎112(例如，比较单元472)可以将可用服务提供者的第二数量与运力阈值进行比较。在一些实施例中，运力阈值可以是由线上到线下服务系统100设置的默认值。在一些实施例中，运力阈值可以根据各种因素进行调整，例如，不同的时间段、不同的位置等。

在1220中，处理引擎112(例如，条件判断单元473)可以确定可用服务提供者的第二数量是否大于或等于运力量阈值。

响应于确定可用服务提供者的第二个数量大于或等于运力阈值，在1230中，处理引擎112(例如，播单模式确定单元474)可以将对应于抢单模式的第一播单模式指定为目标订单的播单模式。

响应于确定可用服务提供者的第二数量小于运力阈值，在1240中，处理引擎112(例如，播单模式确定模块470的播单模式确定单元474)可以将对应于派单模式的第二播单模式指定为目标订单的播单模式。

图12b是根据本申请的一些实施例所示的用于确定目标订单的播单模式的示例性过程的流程图。在一些实施例中，过程1250可以在如图1所示的线上到线下服务系统100中实现。例如，过程1250可以作为指令的形式存储在存储器150和/或其他存储器(例如，rom230、ram240)中，并且由服务器110(例如，服务器110中的处理引擎112、服务器110中的处理引擎112的处理器220、服务器110中的处理引擎112的一个或以上模块)调用和/或执行。以下所示过程的操作仅出于说明的目的。在一些实施例中，过程1250可以通过未描述的一个或多个以上附加操作和/或没有一个或以上所讨论的操作来完成。另外，如图12b所示和下面描述的过程1250的操作的顺序不是限制性的。在一些实施例中，可以根据过程1250执行过程900的操作1120。

在1215中，处理引擎112(例如，评估参数单元471)可以从运力确定单元452获取目标订单的目标起始位置周围的目标地理区域内的未处理订单的数量(在此也称为未处理订单的第二数量)。未处理订单可以指代由服务器110接受但尚未分配给服务器提供者的订单。在一些实施例中，服务器110从至少两个服务请求者获取订单。每个订单可以与一个起始位置相关联。订单的起始位置可以指上车位置。起始位置可以与服务请求者的当前位置相同或不同。运力确定单元452可以在至少两个订单中识别起始位置处在目标地理区域中并且尚未被分配的订单。

处理引擎112获取了在目标起始位置周围的地理区域中未处理订单的第二数量后，处理引擎112(例如，比较单元472)可以将未处理订单的第二数量与订单阈值进行比较。在一些实施例中，订单阈值可以是由线上到线下服务系统100设置的默认值。在一些实施例中，可以根据各种因素(例如，不同的时间段、不同的位置等)来调整订单阈值。

在1215中，处理引擎112(例如，条件判断单元473)可以确定未处理订单的第二数量是否大于或等于订单阈值。

响应于确定未处理订单的第二数量大于或等于订单阈值，在1235中，处理引擎112(例如，播单模式确定单元474)可以将对应于急速接单模式的第三播单模式指定为目标订单的播单模式。

响应于确定未处理订单的第二数量大于或等于订单阈值，在1245中，处理引擎112(例如，播单模式确定单元474)可以将对应于派单模式的第二播单模式指定为目标订单的播单模式。

应当注意过程1200和1250仅仅是用于确定目标订单的播单模式的示例，而不是限制性的。在一些实施例中，处理引擎112(例如，播单模式确定模块470)可以基于目标订单的目标起始位置周围的目标地理区域中可用服务提供者数量和未处理订单数量，确定目标订单的播单模式。例如，处理引擎112(例如，播单模式确定模块470)可以将可用服务提供者的数量与目标地理区域中的未处理订单的数量进行比较。如果可用服务提供者的数量大于未处理订单的数量，处理引擎112还可以确定可用服务提供者的数量与未处理订单的数量之间的差值(在此也称为第三差值)。只有当第三个差值大于阈值时，处理引擎112(例如，播单模式确定模块470)可以将第一播单模式指定为目标订单的播单模式。在一些实施例中，可用服务提供者的数量大于未处理订单的数量，且第三个差值小于或等于阈值，处理引擎112(例如，播单模式确定模块470)可以将第二播单模式指定为目标订单的播单模式。

在一些实施例中，当可用服务提供者的数量小于或等于未处理订单的数量时，处理引擎112可以确定未处理订单的数量与可用服务提供者的数量之间的差值(这里也称为第四差值)。只有当第四差值大于阈值时，处理引擎112(例如，播单模式确定模块470)可以将第三播单模式指定为目标订单的播单模式。在一些实施例中，当未处理订单的数量大于可用服务提供者的数量且第四差值小于或等于阈值时，处理引擎112(例如，播单模式确定模块470)可以将第二播单模式指定为目标订单的播单模式。

图13a至13c是根据本申请的一些实施例所示的不同的接单模式下的服务提供者终端的初始接单界面的示意图。

如图13a至13c所示，假设订单的起始位置为“海淀区东北旺西路10号|中关村软件园”，订单目的地为“海淀区得实大厦”。如图13a所示，在派单模式中，订单时间信息，例如“今天16:10”显示在初始接单界面的第一区域中；订单类型，例如，“普通预约”显示在初始接单界面的顶部；并且在初始接单界面的第二区域中显示包括操作按钮“接单”、操作反馈状态和剩余可操作时间(例如，13秒)的接单标识。如图13b和13c所示，在抢单模式或急速接单模式中，在初始接单界面的第一区域中显示订单距离信息，例如“距您300米”；在抢单模式中，在初始接单界面的第二区域中显示抢单标识，包括操作按钮(例如“抢单”)、操作反馈状态和剩余可操作时间(例如，13秒)。

在实施例中，当接单模式为派单模式时，订单时间信息显示在第一区域中，当接单模式为抢单或急速接单模式时，订单距离信息显示在第一区域中。在派单模式中，当订单时间信息显示在初始接单界面的第一区域时，司机可能会更加注意与订单有关的接送乘客的时间。在抢单模式和急速接单模式中，由于具有实时性特性，当距离信息显示在初始接单界面的第一区域时，司机可能会更加注意距离信息。特别是在抢单模式中，它可以为司机决定是否抢单提供参考。另外，当接单模式为派单模式时，接单标识显示在第二区域中，当接单模式为抢单模式时，抢单标识显示在第二区域中，以这种方式，可以提醒用户执行接单、拒单或抢单的操作，从而提升用户体验。

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

同时，本申请使用了特定词语来描述本申请的实施例。例如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本申请至少一个实施例相关的某一特征、结构或特性。因此，应当强调并注意的是，本说明书中在不同位置两次或以上提及的“一实施例”或“一个实施例”或“一替代性实施例”并不一定是指同一实施例。此外，本申请的一个或以上实施例中的某些特征、结构或特点可以进行适当的组合。

此外，本领域的普通技术人员可以理解，本申请的各方面可以通过若干具有可专利性的种类或情况进行说明和描述，包括任何新的和有用的过程、机器、产品或物质的组合，或对其任何新的和有用的改良。相应地，本申请的各个方面可以完全由硬件执行、可以完全由软件(包括韧体、常驻软件、微代码等)执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“单元”、“模块”或“系统”。此外，本申请的各方面可以采取体现在一个或以上计算机可读介质中的计算机程序产品的形式，其中计算机可读程序代码包含在其中。

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

本申请各方面操作所需的计算机程序码可以用一种或以上程序语言的任意组合编写，包括面向对象程序设计，如java、scala、smalltalk、eiffel、jade、emerald、c++、c#、vb.net、python等，常规程序编程语言，如"c"编程语言，visualbasic、fortran2003、perl、cobol2002、php、abap，动态编程语言如python、ruby和groovy或其它编程语言。该程序代码可以完全在用户计算机上运行、或作为独立的软件包在用户计算机上运行、或部分在用户计算机上运行部分在远程计算机运行、或完全在远程计算机或服务器上运行。在后种情况下，远程计算机可以通过任何网络形式与用户计算机连接，包括局域网(lan)或广域网(wan)，或连接至外部计算机(例如通过因特网)，或在云计算环境中，或作为服务使用如软件即服务(saas)。

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

同理，应当注意的是，为了简化本申请披露的表述，从而帮助对一个或以上发明实施例的理解，前文对本申请实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。然而，本申请的该方法不应被解释为反映所声称的待扫描对象物质需要比每个权利要求中明确记载的更多特征的意图。相反，发明的主体应具备比上述单一实施例更少的特征。

在一些实施例中，表达数量、性质等的数字，用于描述和要求本申请的一些实施例，应理解为在某些情况下通过术语“约”、“近似”或“基本上”进行修改。除非另外说明，“大约”、“近似”或“大体上”表明所述数字允许有±20％的变化。相应地，在一些实施例中，说明书和权利要求中使用的数值参数均为近似值，该近似值根据个别实施例所需特点可以发生改变。在一些实施例中，数值参数应考虑规定的有效数位并采用一般位数保留的方法。尽管本申请一些实施例中用于确认其范围广度的数值域和参数为近似值，在具体实施例中，此类数值的设定在可行范围内尽可能精确。

本文中提及的所有专利、专利申请、专利申请公布和其他材料(如论文、书籍、说明书、出版物、记录、事物和/或类似的东西)均在此通过引用的方式全部并入本文以达到所有目的，与上述文件相关的任何起诉文档记录、与本文件不一致或冲突的任何上述文件或对迟早与本文件相关的权利要求书的广泛范畴有限定作用的任何上述文件除外。举例来说，如果与任何所包含的材料相关的术语的描述、定义和/或使用与本文件相关的术语之间存在任何不一致或冲突，以本文件中的术语的描述、定义和/或用法为准。

最后，应当理解的是，本申请中所述实施例仅用以说明本申请实施例的原则。其他的变形也可能属于本申请的范围。因此，作为示例而非限制，本申请实施例的替代配置可视为与本申请的教导一致。相应地，本申请的实施例不仅限于本申请明确介绍和描述的实施例。