CN110832537A - 一种用于在线服务中的奖励发放***和方法 - Google Patents

Abstract

一种用于在线服务中的奖励发放***和方法。所述方法可以包括接收用户的订单信息。所述方法也可以包括确定订单信息是否满足预设奖励标准。所述方法可以进一步包括如果满足预设奖励标准，则将奖励与服务请求一并发送给司机。所述方法可以进一步包括若司机接受并完成服务请求，将奖励发送给司机。

Description

一种用于在线服务中的奖励发放***和方法

交叉引用

本申请要求2018年4月18日提交的申请号为201810351045.1的中国申请的优先权、2018年5月24日提交的申请号为201810509980.6的中国申请的优先权、2018年3月16日提交的申请号为201810218559.X的中国申请的优先权，其内容通过引用整体并入本文。

技术领域

本申请一般涉及在线服务，更具体地，涉及用于在线服务中奖励发放的***和方法。

背景技术

在移动互联网时代，现代旅游模式改变了传统的出租车模式，将在线模式和离线模式与移动互联网的特点相结合，改变了传统模式，并且允许服务提供者根据自己的意愿提供服务，从而节省了服务提供者与用户之间通信的成本，降低了服务提供者的空车率，节省了服务提供者和用户的资源和时间。

在一个方面，在现有技术中，服务提供者通过安装在服务提供者的终端设备上的用户端接收订单，并通过接收订单、交付用户和接受用户的支付来完成订单。为了更合理地分配运输资源，提高用户在不同时间段和/或不同地区的出行便利性，一个呼叫平台为在特定时间段和/或特定区域接受和完成订单的服务提供者提供奖励，如早高峰时间段、傍晚高峰时间段、深夜、迂回区域、交通枢纽(火车站、机场)等。

在现有技术中，一个呼叫平台在订单完成后向服务提供者提供奖励。呼叫平台获取订单的行驶路线和出发时间，根据行车路线和/或出发时间确定是否满足奖励标准，如果满足奖励标准，则向服务提供者提供奖励。由于呼叫平台需要大量时间和计算来执行上述过程，因此服务提供者的奖励无法实时发放，从而导致用户体验不佳并降低服务提供者接收订单的热情。

另一方面，由于服务提供者在接收订单的过程中是主动的，服务提供者可以根据自己的习惯接收订单，例如每天接收一定数量的订单或者每天在一定时间内不接收订单。为了激励服务提供者尽可能多地接收订单，在现有技术中，通常为服务提供者完成的订单提供一定数量的奖励。通过这种方式，可以分别获取每个订单和奖励，忽略订单之间的关联。它并没有改变服务提供者接受订单的习惯，并没有解决服务提供者在接收订单时缺乏积极性的问题，因此导致没有服务提供者接收订单或者用户需要在叫车服务中等待很长时间并且影响乘客的旅行便利性的情况。

在另一方面，当用户请求叫车服务时，在用户的起始位置附近可能有较少的服务提供者，并且可以将订单发送给远离起始位置的服务提供者。在这种情况下，服务提供者花费更多时间到达起始位置，但是，如果用户需要等待很长时间，则用户可以取消订单。

因此，期望一种用于在叫车服务中提高司机和乘客之间的有效性和匹配成功率的***和方法。

发明内容

根据本申请的一方面，提供一种用于奖励司机的方法。该方法可以在包括至少一个处理器和至少一个计算机可读存储介质的设备上实施。该存储介质可以存储当满足预设奖励标准时授予司机奖励的信息，所述预设奖励标准包括预设时间标准、预设位置标准或预设服务标准中的至少一个。该方法可以包括接收用户的订单信息；确定所述订单信息是否满足所述预设奖励标准；如果满足所述预设奖励标准，则将奖励与服务请求一并发送给司机；以及若所述司机接受并完成所述服务请求，将所述奖励发送给所述司机。

在一些实施例中，所述订单信息包括服务请求时间、起始位置和结束位置。

在一些实施例中，确定所述订单信息是否满足所述预设奖励标准，包括：确定所述服务请求时间、所述起始位置和所述结束位置是否满足所述预设时间标准或所述预设位置标准中的至少一个。

在一些实施例中，确定所述服务请求时间、所述起始位置和所述结束位置是否满足所述预设时间标准或所述预设位置标准中的至少一个，包括：确定所述服务请求时间是否在预设时间内，其中在所述预设时间内，可用的服务提供者的数量小于服务请求的数量。

在一些实施例中，确定所述服务请求时间、所述起始位置和所述结束位置是否满足所述预设时间标准或所述预设位置标准中的至少一个，包括：确定所述起始位置或所述结束位置是否在预设区域内，其中在所述预设区域内，可用的服务提供者的数量小于服务请求的数量。

在一些实施例中，该方法可以进一步包括获取所述起始位置在所述服务请求时间的天气信息。

在一些实施例中，确定所述订单信息是否满足所述预设奖励标准，包括：基于所述起始位置在所述服务请求时间的所述天气信息，确定满足的预设天气条件。

在一些实施例中，该方法进一步包括：获取所述起始位置到所述结束位置的距离；以及基于所述距离调整所述奖励。

在一些实施例中，该方法可以进一步包括：根据反作弊策略确定订单是否为作弊订单；以及响应于所述订单是作弊订单的确定，取消发放所述奖励。

在一些实施例中，所述订单信息包括当前接受时间和先前完成时间。

在一些实施例中，确定所述订单信息是否满足所述预设奖励标准，包括：确定所述当前接受时间与所述先前完成时间之间的时间间隔；根据所述当前接受时间与所述先前完成时间之间的所述时间间隔，确定当前订单是否与上一先前订单连续；以及响应于所述当前订单是连续的确定，确定连续订单的总数是否大于第一预设订单数；以及响应于所述连续订单总数大于所述第一预设订单数的确定，确定满足所述预设服务条件。

在一些实施例中，根据所述当前接受时间与所述先前完成时间之间的所述时间间隔，确定所述当前订单是否与上一先前订单连续，包括：确定所述时间间隔是否小于预设时间段；以及响应于所述时间间隔小于所述预设时间段的确定，确定服务提供者属于连续接单。

在一些实施例中，该方法可以进一步包括：响应于确定所述时间间隔不小于预设时间段，确定所述时间间隔是否在预设时间段内；以及响应于所述时间间隔在预设时间段内的确定，确定所述服务提供者属于连续接单。

在一些实施例中，该方法可以进一步包括：基于所述当前接受时间确定所述奖励。

在一些实施例中，该方法可以进一步包括：获取请求者对所述当前订单的服务提供者的用户评级；以及基于所述用户评级确定所述奖励。

在一些实施例中，该方法可以进一步包括：获取所述服务提供者的账户中的奖励总额；确定所述服务提供者的所述账户中的奖励总额是否大于预设金额；以及响应于所述服务提供者的所述账户中的奖励总额大于所述预设金额的确定，停止发放所述奖励。

在一些实施例中，该方法可以进一步包括：获取连续接单的订单总数；确定所述订单总数是否大于第二预设订单数；以及响应于所述订单总数大于所述第二预设订单数的确定，停止发放所述奖励。

根据本申请的一方面，提供一种用于奖励用户的方法。该方法可以在包括至少一个处理器和至少一个计算机可读存储介质的设备上实施。该存储介质存储当用户需要长时间等待服务提供者时授予所述用户奖励的信息。该方法可以包括：在设备中接收和储存来自用户的终端设备的服务请求，其中服务请求包括订单信息，所述订单信息包括起始位置；基于所述订单信息使用所述处理器为用户分配服务提供者；使用处理器确定服务提供者到达所述起始位置的预估时间段；以及如果预估时间段大于或者等于预设时间段，传输关于服务请求在使用上有限制条件的折扣信息到用户的终端设备，其中所述限制条件包括当实际用户等待时间长于或等于预估时间段和预设误差时间的和时，能够使用折扣。

在一些实施例中，该方法可以进一步包括：获取至少两个先前服务请求；以及基于所述至少两个先前服务请求确定所述预设时间段或者预设误差时间。

在一些实施例中，基于所述至少两个先前服务请求确定所述预设时间段，包括：基于所述至少两个先前服务请求，确定所述等待时间和订单取消概率之间的第一关系；以及根据所述第一关系确定所述预设时间段。

在一些实施例中，根据所述第一关系确定所述预设时间段，包括：根据所述第一关系确定对应于最大订单取消概率的优化的等待时间；以及指定所述优化的等待时间作为所述预设时间段。

在一些实施例中，基于所述至少两个先前服务请求确定所述预设时间段，包括：基于所述至少两个先前服务请求，确定所述预估时间段和订单取消概率之间的第二关系；以及根据所述第二关系确定所述预设时间段。

在一些实施例中，根据所述第二关系确定所述预设时间段，包括：根据所述第二关系确定对应于最大订单取消概率的优化的预估时间段；以及指定所述优化的预估时间段作为所述预设时间段。

在一些实施例中，基于所述至少两个先前服务请求确定所述预设误差时间，包括：基于所述至少两个先前服务请求确定服务提供者到达起始位置的实际时间段和预估时间段的差值；以及基于所述差值确定所述预设误差时间。

在一些实施例中，所述限制条件进一步包括：当服务提供者到达起始位置的实际时间段大于所述预估时间段和所述预设误差时间的和时，能够使用折扣。

根据本申请的一方面，提供一种用于奖励司机的***。该***可以包括存储指令的至少一个存储介质，指令包括当满足预设奖励标准授予司机奖励的信息，所述预设奖励标准包括预设时间标准、预设位置标准或者预设服务标准中的至少一个，以及与至少一个存储介质通信的至少一个处理器，其中当执行所述指令，所述至少一个处理器用于：接收用户的订单信息；确定所述订单信息是否满足所述预设奖励标准；如果满足所述预设奖励标准，则将奖励与服务请求一并发送给所述司机；以及若所述司机接受并完成所述服务请求，将所述奖励发送给所述司机。

根据本申请的另一方面，提供一种用于奖励用户的***。该***可以包括存储指令的至少一个存储介质，指令包括当所述用户需要长时间等待服务提供者时授予所述用户奖励的信息；以及用于与至少一个存储介质通信的至少一个处理器，其中当执行所述指令，所述至少一个处理器用于：在设备中接收和储存来自用户的终端设备的服务请求，其中服务请求包括订单信息，所述订单信息包括起始位置；基于所述订单信息使用所述处理器为用户分配服务提供者；使用处理器确定服务提供者到达所述起始位置的预估时间段；以及如果预估时间段大于或者等于预设时间段，传输关于服务请求在使用上有限制条件的折扣信息到用户的终端设备，其中所述限制条件包括当实际用户等待时间长于或等于预估时间段和预设误差时间的和时，能够使用折扣。

根据本申请的另一方面，提供一种非暂时性计算机可读存储介质。该非暂时性可读介质可以包括至少一组用于奖励司机的指令，其中，所述存储介质存储当满足预设奖励标准授予所述司机奖励的信息，所述预设奖励标准包括至少一个预设时间标准、预设位置标准或者预设服务标准，当计算设备的至少一个处理器执行时，所述至少一组指令使得计算设备实施一种方法。所述方法可以包括：接收用户的订单信息；确定所述订单信息是否满足预设奖励标准；如果满足所述预设奖励标准，则将奖励与服务请求一并发送给司机；以及若所述司机接受并完成所述服务请求，将所述奖励发送给所述司机。

根据本申请的又一方面，提供一种非暂时性计算机可读介质。该非暂时性计算机可读介质可以包括至少一组用于奖励用户的指令，其中，所述存储介质存储当所述用户需要长时间等待服务提供者时授予所述用户奖励的信息，当计算设备的至少一个处理器执行时，所述至少一组指令使得计算设备实施一种方法。该方法可以包括：在设备中接收和储存来自用户的终端设备的服务请求，其中服务请求包括订单信息，所述订单信息包括起始位置；基于所述订单信息使用所述处理器为用户分配服务提供者；使用处理器确定服务提供者到达所述起始位置的预估时间段；以及如果预估时间段大于或者等于预设时间段，传输关于服务请求在使用上有限制条件的折扣信息到用户的终端设备，其中所述限制条件包括当实际用户等待时间长于或等于预估时间段和预设误差时间的和时，能够使用折扣。

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

附图说明

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

图1是根据本申请的一些实施例所示的示例性奖励发放***的示意图；

图2是根据本申请的一些实施例所示的计算装置的示例性组件的示意图；

图3是根据本申请的一些实施例所示的示例性用户终端的示例性硬件和/或软件组件的示意图；

图4是根据本申请的一些实施例所示的向服务提供者提供奖励的过程400的流程图；

图5是根据本申请的一些实施例所示确定服务请求是否满足预设标准的过程500的流程图；

图6是根据本申请的一些实施例的奖励提供设备的方框图；

图7是根据本申请的一些实施例所示的奖励连续接单的过程700的流程图；

图8是根据本申请的一些实施例所示的奖励连续接单的过程800的流程图；

图9是根据本申请的一些实施例的服务奖励设备的结构图；

图10是根据本申请的一些实施例所示的用于奖励用户的过程1000的流程图；

图11是根据本申请的一些实施例所示的用于奖励用户的过程1100的流程图；

图12是根据本申请的一些实施例所示的用于奖励用户的过程1200的流程图；

图13是根据本申请的一些实施例的实现用户奖励方法的用户的终端设备的接口的示意图；

图14是根据本申请的一些实施例的实现用户奖励方法的用户的终端设备的接口的示意图；

图15是根据本申请的一些实施例的用户奖励设备的示意图；

图16是根据本申请的一些实施例的用户奖励设备的示意图；以及

图17是根据本申请的一些实施例的用户奖励设备的示意图。

具体实施方式

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

如本申请和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。需进一步理解的是，本申请中使用的术语“包括”和/或“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，还可以包括其它的步骤和元素。

虽然本申请对根据本申请的实施例的***中的某些模块做出了各种引用，然而，任何数量的不同模块可以被使用并运行在用户端和/或服务器上。这些模块旨在说明，而不是为了限制条件本申请的范围。可以在***和方法的不同方面使用不同的模块。

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

参考如下所述的附图描述本申请的实施例的技术方案。显然，所描述的实施例并非详尽无遗并且不是限制条件性的。基于本申请中所述的实施例，本领域普通技术人员在没有任何创造性工作的情况下获取的其他实施例均在本申请的范围内。

本申请的一些实施例涉及适用于例如按需服务的在线奖励提供功能，该服务是仅在后互联网时代植根的新兴服务或需求。它为用户提供技术解决方案，这些解决方案只能在后互联网时代兴起。在互联网时代之前，如果没有大量的数据采集和计算，就不可能实时向乘客和司机提供奖励。因此，本解决方案深深植根于并且旨在解决仅在后互联网时代发生的问题。

图1示出了根据本申请的一些实施例的奖励发放***的示例性网络环境。奖励发放***100可以是用于提供旅行相关服务的在线服务平台。奖励发放***100可以包括服务器110、网络120、用户终端130、司机设备140和存储设备150。在一些实施例中，奖励发放***100还可包括定位设备160(图1中未示出)。

奖励发放***100可以适用于至少两个服务。示例***可包括旅行计划服务、导航服务、按需服务(例如，出租车服务、司机服务、快车服务、拼车服务、公共叫车服务或司机租用服务)等，或其组合。

服务器110可以处理来自奖励发放***100的一个或以上组件或外部数据源(例如，云数据中心)的数据和/或信息。服务器110可以与用户终端130和/或司机设备140通信，以提供在线服务的各种功能。在一些实施例中，服务器110可以是单个服务器，也可以是服务器组。服务器组可以是经由接入点连接到网络120的集中式服务器组，或者经由一个或以上接入点分别连接到网络120的分布式服务器组。在一些实施例中，服务器110可以本地连接到网络120或者与网络120远程连接。例如，服务器110可以经由网络120访问存储在用户终端130、司机设备140和/或存储设备150中的信息和/或数据。又例如，存储设备150可以用作服务器110的后端数据存储器。在一些实施例中，服务器110可以在云平台上实施。仅作为示例，该云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多层云等或其任意组合。在一些实施例中，服务器110可以在本申请中的图2描述的包含了一个或以上组件的计算装置200上执行。

在一些实施例中，服务器110可以包括处理设备112。处理设备112可以处理与本申请中描述的一个或以上功能相关的信息和/或数据。在一些实施例中，处理设备112可以执行奖励发放***100的主要功能。在一些实施例中，处理设备112可以处理奖励相关信息以向司机或乘客提供奖励，以改善司机和乘客之间的匹配成功。在一些实施例中，处理设备112可以执行与本申请中描述的方法和***相关的其他功能。

在一些实施例中，处理设备112可包括一个或以上处理单元(例如，单核处理设备或多核处理设备)。仅作为范例，处理设备112可包括一中央处理器(CPU)、特定应用集成电路(ASIC)、特定应用指令集处理器(ASIP)、图像处理单元(GPU)、物理运算处理单元(PPU)、数字信号处理器(DSP)、现场可编程门阵列(FPGA)、可编程逻辑设备(PLD)、控制器、微控制器单元、精简指令集计算机(RISC)、微处理器等或其任意组合。

网络120可以促进信息和/或数据的交换。在一些实施例中，奖励发放***100中的一个或以上组件(例如，服务器110、用户终端130、司机设备140、存储设备150)可以经由网络120将信息和/或数据发送到奖励发放***100中的其他组件。在一些实施例中，网络120可以为任意形式的有线或无线网络，或其任意组合。仅作为示例，网络120可以包括缆线网络、有线网络、光纤网络、远程通信网络、内部网络、互联网、局域网络(LAN)、广域网络(WAN)、无线局域网络(WLAN)、城域网(MAN)、公共交换电话网络(PSTN)、蓝牙网络、紫蜂网络、近场通信(NFC)网络等或其任意组合。在一些实施例中，网络120可以包括一个或以上网络接入点。例如，网络120可以包括有线或无线网络接入点，例如基站和/或互联网交换点120-1、120-2……通过奖励发放***100的一个或以上组件可以连接到网络120以交换数据和/或信息。

用户终端130和/或司机设备140可以经由网络120与服务器110通信。在一些实施例中，乘客可以是用户终端130的所有者。在一些实施例中，用户终端130的所有者可以是除乘客之外的其他人。例如，用户终端130的所有者A可以使用用户终端130来发送针对乘客B的服务请求，和/或从服务器110接收服务确认和/或信息或指令。在一些实施例中，司机可以是司机设备140的用户。在一些实施例中，司机设备140的用户可以是除司机之外的其他人。例如，司机设备140的用户可以使用司机设备140来接收对司机D的服务请求，和/或来自服务器110的信息或指令。在一些实施例中，可以指定司机使用司机设备140中的一个至少一段时间。例如，当司机可用于提供按需服务时，可以指派他/她使用接收最早请求的司机终端和推荐执行按需服务类型的车辆。在一些实施例中，“乘客”和“终端设备”可以互换使用，“司机”和“司机设备”可以互换使用。在一些实施例中，司机设备140可以与一个或以上司机(例如，夜班司机、日班司机或通过随机换档的司机池)相关联。

用户可以通过用户终端130接收行程的服务响应。在一些实施例中，用户终端130可以经由网络120从处理设备112获取旅程的ETA。用户终端130可以包括移动设备130-1、平板计算机130-2、膝上型计算机130-3、车辆的内置设备130-4等，或其任何组合。在一些实施例中，移动设备130-1可以包括智能家居设备、可穿戴设备、智能移动设备、虚拟现实设备、增强现实设备等，或其任意组合。在一些实施例中，智能家居设备可以包括智能照明设备、智能电器控制设备、智能监控设备、智能电视、智能摄像机、对讲机等，或其任意组合。在一些实施例中，该可穿戴设备可包括智能手镯、智能鞋袜、智能眼镜、智能头盔、智能手表、智能衣服、智能背包、智能配件等或其任意组合。在一些实施例中，智能移动设备可以包括智能电话、个人数字助理(PDA)、游戏设备、导航设备、销售点(POS)等，或其任意组合。在一些实施例中，虚拟现实设备和/或增强型虚拟现实设备可以包括虚拟现实头盔、虚拟现实眼镜、虚拟现实眼罩、增强现实头盔、增强现实眼镜、增强现实眼罩等，或其任意组合。例如，虚拟现实设备和/或增强现实设备可以包括Google Glass^TM、Oculus Rift^TM、Hololens^TM或Gear VR^TM等。在一些实施例中，车辆的内置设备130-4可以包括内置计算机、车载内置电视、内置平板电脑等。在一些实施例中，用户终端130可以包括信号发送器和信号接收器，用于与定位设备170通信，用于定位乘客和/或用户终端130的位置，并确定从他/她的位置到道路的相对距离。

司机可以通过司机设备140接收服务请求。司机设备140可包括至少两个司机设备140-1、140-2、……、140-n。在一些实施例中，司机设备140可以与用户终端130类似或相同。在一些实施例中，可以基于从处理设备112获取的旅行相关信息定制司机设备140以来实现在线服务。

存储设备150可以存储数据和/或指令。数据可以包括地理位置信息、时间信息、司机信息和/或外部环境。仅出于说明目的，与地理位置信息相关的数据可包括起始位置、结束位置、起始位置和结束位置之间的距离等。与时间信息有关的数据可包括出发时间、订单接受时间、订单完成时间等。与司机相关的数据可能包括司机识别(ID)、司机的用户档案、司机帐户等。在一些实施例中，存储设备150可以存储从用户终端130和/或司机设备140获取的数据。例如，存储设备150可以存储与用户终端130相关联的日志。

在一些实施例中，存储设备150可以存储处理设备112可以执行的数据和/或指令，以向服务提供者和/或用户提供奖励，如本申请中所描述的。在一些实施例中，存储设备150可包括大容量存储器、可移动存储器、易失性读写存储器、只读存储器(ROM)等或其任意组合。示例性的大容量存储器可以包括磁盘、光盘、固态磁盘等。示例性可移动存储器可以包括闪存驱动器、软盘、光盘、存储卡、压缩盘、磁带等。示例性易失性读写存储器可以包括随机存取存储器(RAM)。示例性RAM可包括动态随机存取存储器(DRAM)、双倍数据速率同步动态随机存取存储器(DDR SDRAM)、静态随机存取存储器(SRAM)、晶闸管随机存取存储器(T-RAM)和零电容随机存取存储器(Z-RAM)等。示例性只读存储器可以包括掩模型只读存储器(MROM)、可编程只读存储器(PROM)、可擦除可编程只读存储器(EPROM)、电可擦除可编程只读存储器(EEPROM)、光盘只读存储器(CD-ROM)和数字多功能磁盘只读存储器等。在一些实施例中，所述存储设备150可在云平台上实现。仅作为示例，该云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多层云等或其任意组合。

在一些实施例中，奖励发放***100中的一个或以上组件可以经由网络120访问存储在存储设备150中的数据或指令。在一些实施例中，存储设备150可以作为后端存储器直接连接到服务器110。

定位设备170可以确定与对象相关联的信息，例如，用户终端130的一个或以上、司机设备140等。例如，定位设备170可以确定用户终端130的当前位置。在一些实施例中，定位设备170可以是全球定位***(GPS)、全球导航卫星***(GLONASS)、罗盘导航***(COMPASS)、北斗导航卫星***、伽利略定位***、准天顶卫星***(QZSS)等。由定位设备170提供的信息可以包括对象的位置、高度、速度或加速度，和/或当前时间。该位置可以是坐标的形式，例如纬度坐标和经度坐标等。定位设备170可以包括一个或以上卫星或与之关联。卫星可以独立地或联合地确定上述信息。定位设备170可以经由网络120将上述信息发送到用户终端130或者司机设备140。

本领域的普通技术人员将理解，当奖励发放***100的元件执行时，该元件可以通过电信号和/或电磁信号执行。例如，当用户终端130处理任务时，例如计划从一个地方到另一个地方的旅行，用户终端130可以在其处理器中操作逻辑电路以处理这样的任务。当用户终端130向服务器110发出指令时，用户终端130的处理器可以生成编码该指令的电信号。然后，用户终端130的处理器可以将电信号发送到输出端口。若用户终端130经由有线网络与服务器110通信，则输出端口可物理连接至电缆，其进一步将电信号传输给服务器110的输入端口。如果用户终端130经由无线网络与服务器110通信，则用户终端130的输出端口可以是一个或以上天线，其将电信号转换为电磁信号。类似地，司机设备140可以通过其处理器中的逻辑电路的操作来处理任务，并且经由电信号或电磁信号从服务器110接收指令和/或信息。在电子设备内，例如用户终端130、司机设备140和/或服务器110，当处理器处理指令，发出指令和/或执行动作时，指令和/或动作通过电信号进行。例如，当处理器从存储介质(例如，存储设备150)检索数据(例如，道路网络)时，它可以将电信号发送到存储介质的读取设备，其可以读取存储介质中的结构化数据。该结构化数据可以电信号的形式经由电子设备的总线传输至处理器。此处，电信号可以指一个电信号、一系列电信号和/或至少两个不连续的电信号。

图2是根据本申请的一些实施例所示的计算装置的示例性组件的示意图。根据本申请的一些实施例，服务器110、存储设备120、信息提供器130和/或通信平台140可以在计算装置200上实现。本实施例中的特定***利用功能框图描述了一个包含用户界面的硬件平台。这种计算机可以是一个通用目的的计算机，也可以是一个有特定目的的计算机。根据本申请的一些实施例，两种类型的计算机可以被配置为实现任何特定***。计算装置200可以被配置用于实现执行本申请中披露的一个或以上功能的任何组件。例如，计算装置200可以实现如本文所述的奖励发放***100的任何组件。在图1-2中，仅出于方便的目的仅示出了一个这样的计算机设备。本领域普通技术人员在提交本申请时将理解，与本文所述的服务有关的计算机功能可以在多个类似平台上以分布式方式实现，以分配处理负载。

例如，计算装置200可以包括与网络相连接通信端口250，以实现数据通信。计算装置200还可以包括处理器(例如，处理器220)，其形式为一个或以上处理器(例如，逻辑电路)，用于执行程序指令。例如，处理器包括其中的接口电路和处理电路。接口电路可以被配置为从总线210接收电信号，其***号编码用于处理电路的结构化数据和/或指令。处理电路可以进行逻辑计算，然后将结论、结果和/或指令编码确定为电信号。然后，接口电路可以经由总线210从处理电路发出电信号。

示例性计算装置可以包括内部通信总线210，程序存储和不同形式的数据存储，包括：例如，磁盘270，以及只读存储器(ROM)230或随机存取存储器(RAM)240，用于由计算装置处理和/或发送的各种数据文件。示例性计算装置还可以包括存储在ROM 230、RAM 240和/或由处理器220执行的其他类型的非暂时性存储介质中的程序指令。本申请的方法和/或流程可以以程序指令的方式实现。计算装置200还包括输入/输出(I/O)组件260，支持计算机和其他组件之间的输入/输出。计算装置200还可以经由网络通信接收编程和数据。

仅用于说明，图2中仅示出了一个处理器和/或处理器。还可以考虑多个CPU和/或处理器；因此，由本申请中描述的一个CPU和/或处理器执行的操作和/或方法步骤也可以由多个CPU和/或处理器联合或单独执行。例如，如果在本申请中，计算装置200的CPU和/或处理器执行操作A和操作B，应当理解，操作A和操作B也可以由计算装置200中的两个不同的CPU和/或处理器联合或分开执行(例如，第一处理器执行操作A，第二处理器执行操作B，或者第一和第二处理器共同执行操作A和B)。

图3是根据本申请的一些实施例所示的示例性请求者终端的示例性硬件和/或软件组件的框图。根据本申请的一些实施例，信息提供器130或通信平台140可以在移动设备300上实现。如图3所示，移动设备300可以包括通信模块310、显示器320、图形处理单元(GPU)330、中央处理单元(CPU)340、I/O 350、内存360和存储器390。CPU 340可以包括接口电路和类似于处理器220的处理电路。在一些实施例中，任何其他合适的组件，包括但不限于***总线或控制器(未示出)，也可包括在移动设备300内。在一些实施例中，移动操作***370(例如，iOS^TM、Android^TM、Windows Phone^TM等)和一个或以上应用程序380可以从存储器390加载到内存360中，以便由CPU 340执行。应用程序380可以包括浏览器或任何其他合适的移动应用程序，用于从移动设备300上的奖励发放***接收和呈现与服务请求或其他信息有关的信息。用户与信息流的交互可以通过I/O设备350实现，并通过网络150提供给处理设备112和/或奖励发放***100的其他组件。

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

图4是根据本申请的一些实施例所示的用于向服务提供者提供奖励的过程400的流程图。在一些实施例中，图4中所示的过程400可以在图1中所示的奖励发放***100中实现。例如，过程400的至少一部分可以作为指令的形式存储在存储设备(例如，计算装置200的磁盘270)中，并且由服务器110(例如，计算装置200的处理器220)调用和/或执行。在一些实施例中，过程400的一部分可以在终端设备上实现。以下呈现的所示过程400的操作旨在是说明性的。在一些实施例中，过程400可以利用未描述的一个或以上附加操作，和/或没有所讨论的一个或以上操作来完成。另外，如图4所示和下面描述的过程400的操作的顺序不是限制条件性的。

在401中，可以从用户的终端设备接收服务请求，该服务请求包括诸如服务请求时间、起始位置和结束位置的服务请求参数。在一些实施例中，用户的终端设备可以由用户终端130实现。

在一些实施例中，用户可以通过终端设备输入服务请求时间、起始位置和结束位置。终端设备可以基于服务请求时间、起始位置和结束位置生成服务请求，并且将服务请求发送到呼叫平台。在一些实施例中，可以在服务器110中实现呼叫平台。当收到服务请求时，呼叫平台可以获取服务请求时间和起始位置。在一些实施例中，终端设备可以将用户的当前位置确定为起始位置，或者为用户提供标记起始位置和结束位置的地图。服务请求可以不限于上面披露的信息，还可以包括任何类型的叫车服务，例如出租车服务、拼车或乘车服务等。

在402中，可以基于服务请求参数来确定服务请求是否满足预设标准。如果服务请求满足预设标准，则可以生成包括奖励信息的奖励，并且可以将奖励信息与服务请求一并发送给服务提供者的终端设备。

呼叫平台可以获取服务请求，并基于服务请求参数确定服务请求是否满足预设标准。在一些实施例中，预设标准可以包括预设时间标准。预设时间标准可以涉及服务请求时间。例如，当服务请求中的服务请求时间处于早上高峰时间段或晚上高峰时间段(5：30～10：00或17：00～20：00)或深夜(20:00后)时，如果服务提供者接受并满足服务请求，则可以确定满足预设标准，并且可以向服务提供者的帐户发放奖励。在一些实施例中，预设标准可以包括预设位置标准。预设位置标准可以涉及特定区域中的起始位置和/或结束位置。例如，如果服务请求中的起始位置位于迂回区域或交通枢纽(例如，车站、机场等)。又例如，如果服务请求中的结束位置是一个迂回区域，则当服务提供者收到订单时，可以提供奖励。在一些实施例中，预设标准可以包括预设时间标准和预设位置标准。换句话说，预设标准可以涉及所有出发时间、起始位置和结束位置。例如，可以向在某个时间段以及特定区域中接受并完成服务请求的服务提供者提供奖励。

在一些实施例中，奖励信息可以包括用于奖励的特定金额，或者可以是用于奖励的预估金额。例如，可以根据起始位置到结束位置之间的行驶里程来预估金额。具体地，服务器110可以根据起始位置和结束位置确定起始位置到结束位置之间的可选路线，基于可选路线估算金额，生成奖励信息，将奖励信息发送给服务提供者，这可以激励服务提供者接收订单。可以基于订单完成后的实际行驶里程来确定奖励的金额。在一些实施例中，可以根据出发时间所属的时间段或者起始位置和/或结束位置所属的区域来确定用于奖励的金额。在一些实施例中，当服务请求和奖励信息被发送到服务提供者的终端设备时，服务器110可以按照特定的订单分配规则来分配订单。订单分配规则可以是服务器110将服务请求和奖励信息推送到服务提供者的终端设备，并且服务提供者通过他/她的终端设备确定是否接受服务请求。订单分配规则可以是服务器110通过广播同时将服务请求和奖励信息推送到多个服务提供者的终端设备，并且任何一个服务提供者都可以通过他/她的终端设备接受订单。此外，如果用户请求某种类型的叫车服务，则服务器110可以将订单信息和奖励信息推送到提供相应类型的服务的服务提供者的终端设备。在一些实施例中，可以将奖励信息与服务请求一起推送到服务提供者的终端设备，从而激励服务提供者接受订单，使服务提供者意识到指向特定区域和/或特定时间段的订单可以提供奖励，并提高服务提供者接受和完成指向特定区域和/或特定时期的订单的积极性。

此外，虽然奖励信息被发送到服务提供者的终端设备，但是呼叫平台也可以将服务提供者的预设标准推送到他/她的终端设备。更具体地，以声音或文本的形式，这样，服务提供者可能会知道有关提供奖励的规则的更多细节，并且可能会增加他/她的热情。另外，如果不满足预设标准，则呼叫平台可以发送关于不满足标准的提示信息，例如，服务请求的出发时间不属于预设时间段，到服务提供者的终端设备。

在403中，如果服务提供者接受并完成服务请求，则服务器110可以在确认服务请求的完成时，基于奖励信息将奖励发放到服务提供者的账户。

在一些实施例中，服务提供者可以通过终端设备140接收订单，并在出发时间接收用户。当订单被完成时，终端设备140可以将关于服务请求的实现的确认发送到呼叫平台。响应于确认，呼叫平台可以将与奖励信息对应的奖励金额实时发放到服务提供者的账户，从而提高了服务提供者的用户体验，提高了服务提供者的积极性。在一些实施例中，由于呼叫平台已经决定对接受订单的服务提供者进行奖励，因此，呼叫平台可以立即发放该奖励，或者在短时间内判断该订单被完成，从而实时发放奖励，而不是获取和执行行驶路线、服务请求时间和其他信息的详细分析，这提高了处理速度。

在一些实施例中，呼叫平台可以在奖励之后向服务提供者的帐户发送通知给服务提供者(例如，司机设备140)的终端设备，其中对应于奖励信息的金额被发放到服务提供者的帐户。

本申请中提供的奖励发放方法包括从用户的终端设备接收服务请求，该服务请求包括服务请求时间、起始位置和结束位置；确定服务请求是否满足预设标准；如果满足预设标准，则获取奖励信息并将奖励信息与服务请求一起发送给服务提供者的终端设备；基于奖励信息，向服务提供者的账户发放奖励。该实施例中提供的方法可以通过在服务提供者接受订单之前将服务请求和奖励信息推送到服务提供者的终端设备，激励服务提供者在特定时间段或特定区域内接收订单。在服务请求被推送到服务提供者之前，可以基于服务请求获取奖励信息，这可以使得能够在完成订单时实时地将奖励发放到服务提供者的账户中，从而提高了发放奖励的速度，增强了服务提供者的用户体验，进一步激励了服务提供者，更有条理地分配运输资源，并使乘客受益。

在一些实施例中，在本申请中进一步提供了一种奖励查询方法。服务提供者的终端设备的接口可以包括用于检查所有订单，具有奖励的订单和/或没有奖励的订单的按钮。当服务提供者的终端设备收到用户点击按钮查看所有订单的信号时，所有与用户相关的订单都可以从呼叫平台获取并显示在服务提供者的终端设备的第一界面中，其中每个订单的信息例如，可以显示起始时间(即，服务请求时间)、结束时间、起始位置、结束位置。在一些实施例中，也可以在第一界面中显示每个订单的奖励金额和所有订单的奖励总额。当服务提供者的终端设备接收到用户点击按钮查看带有奖励的订单的信号时，可以从呼叫平台获取具有奖励的订单并显示在服务提供者的终端设备的第二界面中。其中每个订单的信息例如，可以类似地显示起始时间(即，服务请求时间)、结束时间、起始位置、结束位置。在一些实施例中，也可以在第二界面中显示用于奖励每个具有奖励的订单的金额和用于奖励具有奖励的订单的总额。当服务提供者的终端设备接收到用户点击按钮查看订单而没有奖励的信号时，没有奖励的订单以及没有奖励的每个订单不满足的标准可以从呼叫平台获取并显示在服务提供者的终端设备的第三界面中，其中每个订单的信息例如，可以类似地显示起始时间(即，服务请求时间)、结束时间、起始位置、结束位置。在一些实施例中，服务提供者的终端设备可以进一步包括用于查看奖励的预设标准的按钮的第四界面，其也可以设置在第一界面、第二界面和/或第三界面中。第四界面还可以包括用于检查所有订单，具有奖励的订单和/或没有奖励的订单的按钮。司机可以通过奖励查询方法快速检查与其订单相关的奖励，从而改善用户体验和司机的积极性。

图5是示出根据本申请的一些实施例的用于确定服务请求是否满足预设标准的过程500的流程图。在一些实施例中，可以根据过程500的502和503中的操作来执行过程400的402中描述的操作。在过程500中，如果服务请求满足预设标准，则可以获取奖励信息并将其和服务请求推送到服务提供者的终端设备。

在501中，可以从用户的终端设备接收服务请求，该服务请求包括诸如服务请求时间、起始位置和结束位置的服务请求参数。

在502中，可以确定是否满足至少一个预设标准。在一些实施例中，可以基于服务请求参数的一个或以上来确定：包括(1)如果服务请求时间在预设时间内，其中在预设时间内，可用的服务提供者的数量小于发起的服务请求的数量，和/或(2)如果服务请求的起始位置和结束位置在预设区域内，其中，在预设区域中，可用的服务提供者的数量小于发起的服务请求的数量。预设标准可以包括预设时间标准和/或预设位置标准。例如，如果服务请求时间在预设时间段内，在此期间服务供应小于服务请求(即，可用的服务提供者的数量小于发起的服务请求的数量)，服务器110可以确定满足预设时间标准。又例如，如果起始位置和/或结束位置在预设区域内，其中服务供应小于服务请求(即，可用的服务提供者的数量小于发起的服务请求的数量)，服务器110可以确定满足预设时间标准。

在503中，如果满足预设标准，则可以生成包括奖励信息的奖励，并将其与服务请求一起发送到服务提供者的终端设备。

在504中，服务器110可以基于奖励信息在服务提供者接受订单并确认完成服务请求后将奖励发放到该服务提供者的账户。

在一些实施例中，在预设时间段期间，例如早晨高峰时间段、晚上高峰时间段和/或深夜，服务供应可能小于服务请求，表明服务供应和服务请求之间的不平衡。换句话说，可用的服务提供者的数量少于早上高峰时间段和晚上高峰时间段提供的服务请求数量，但是车辆渲染服务可能相对较少，这增加了用户请求叫车服务的难度。为了激励更多服务提供者在早上繁忙时间、晚上繁忙时间和/或深夜提供服务，以便使用户受益，因此，司机接受并完成服务请求时间的订单可能会达到高峰时间段或深夜等预设时间段。在一些实施例中，在预设区域中，例如机场、车站和迂回区域等交通枢纽，服务供应可能小于服务请求，表明服务供应和服务请求之间的不平衡。换句话说，可用的服务提供者的数量少于机场和车站等交通枢纽的服务请求数量，但是车辆渲染服务可能相对较少，这增加了用户请求叫车服务的难度。接受在迂回区域内有终点位置的订单的服务提供者更容易空车返回，并且可能难以获取与连续接单相关的奖励，因此，在迂回区域中服务供应可能相对较少，并且用户可能难以请求叫车服务。关于与连续接单相关联的奖励的详细描述可以在别处披露，例如，图7和图8以及其解决方案。为了鼓励更多服务提供者接受预设区域的订单，接受在预设区域中具有起始位置或终点位置的订单的服务提供者可以获得奖励，这可以有益于交通枢纽中的乘客的疏散并且促进用户在迂回区域中的快速流动。在一些实施例中，可以适当调整用于指定迂回区域的订单，以便为服务提供者提供更多的经济保障，并提高服务提供者的安全性。

在一些实施例中，可以通过收集和分析历史数据来确定预设时间段和/或预设区域。仅出于说明的目的，可以将服务供应和服务请求不平衡的时间段和区域分别指定为预设时间段和预设区域。可以为预设时间段和/或预设区域设置用于奖励的一定金额或用于奖励的特定比率(例如，订单费用的两倍)。在一些实施例中，可以实时获取预设时间段和/或预设区域。例如，当从用户的终端设备接收到服务请求时，可以获取当前时间段中的服务供应和服务请求，并且如果服务供应小于当前时间段中的服务请求，则可以将当前时间段指定为预设时间段。类似地，可以获取包括起始位置的区域中的服务供应和服务请求，并且如果服务供应小于该区域中的服务请求，则可以将该区域指定为预设区域。

作为上述实施例的进一步改进，该方法还可以包括：在服务器110确定服务请求是否满足预设标准之前，获取起始位置在服务请求时间的天气信息。为了确定服务请求是否满足预设标准，可以考虑预设的天气标准。预设天气标准可以涉及起始位置的天气状况、结束位置和/或在旅行期间从起始位置到结束位置的路线中的任何位置。

在一些实施例中，呼叫平台还可以从例如天气广播平台获取天气信息。如果天气信息满足预设的天气标准，呼叫平台可以根据预设的天气标准确定包括奖励信息的奖励，并且当服务提供者接受订单时，将对应于奖励信息的奖励发放给服务提供者。具体地，预设天气标准可以是起始位置当前具有特殊天气条件，例如，下雨、下雪、下雾、雾霾、沙尘暴、台风或其他极端天气。特殊天气下的用户行程可以通过仍然提供服务的奖励服务提供者来确定。

另外，呼叫平台还可以确定服务请求时间下落的日子是否是假日，例如春节、国庆等，以便相应地奖励服务提供者。例如，如果出发时间的那一天是假期，例如，春节，服务提供者不太愿意提供服务，可以发放奖励以鼓励服务提供者提供服务。又如例，在国庆节，旅游景点可能很拥挤，服务提供者往往不愿接收景点附近的订单，则呼叫平台可以根据服务请求的日期和起始位置确定是否有必要向服务提供者发放奖励，从而增加了旅游景点附近的交通资源，使游客可以快速呼叫服务。

应当注意，可以进行上述各种预设标准的任何组合，这不是限制条件性的。

作为上述实施例的进一步改进，在确认满足服务请求后，根据奖励信息实时发放奖励到服务提供者账户的操作可以进一步包括从起始位置到结束位置获取服务提供者的行程里程，并根据行程里程调整奖励信息。

在一些实施例中，可以根据行程里程确定奖励的金额。换句话说，当奖励信息发送给服务提供者时，奖励信息可以包括奖励的预估金额，并且可以根据订单完成后的旅行里程调整奖励的预估金额。

作为上述实施例的进一步改进，在将奖励发放到服务提供者的帐户之前，该方法还包括根据指示订单被完成的订单完成消息执行反作弊检测。

具体地，可以基于订单完成消息和一个或以上反作弊策略来确定订单是否是作弊订单。在一些实施例中，根据奖励发放***100的默认设置，可以由用户设置反作弊策略。如果订单是作弊订单，则可以取消奖励的管理。

在一些实施例中，可以在完成订单时对订单执行反作弊操作。如果订单被确定为作弊订单，则可以取消服务提供者的奖励，否则，可以实时发放奖励。反作弊检测可以防止服务提供者进行自我交易，恶意欺骗奖励，从而确保叫车服务的公平性。在一些实施例中，可以使用反作弊模型。反作弊模型可以是各种反作弊策略的集合。使用反作弊模型确定的作弊订单可以实时传送到作弊订单库。仅出于说明的目的，可以在分配奖励之前将每个订单发送到反作弊界面。反作弊界面可以基于与订单相关联的订单完成消息和一个或以上反作弊策略来确定订单是否是作弊订单。如果订单是作弊订单，则可以取消奖励。在一些实施例中，也可以施加惩罚。反作弊检测可以是任何作弊检测方法或其组合，其未详细描述。

图6是根据本申请的一些实施例的奖励发放设备的框图。如图6所示，奖励发放设备可以包括接收模块601、处理模块602、传输模块603和奖励模块604。

接收模块601可以被配置为从用户的终端设备接收服务请求，该服务请求包括诸如服务请求时间、起始位置和结束位置的参数。

处理模块602可以是配置用于基于服务请求参数确定服务请求是否满足预设标准。如果满足预设标准，则可以生成包括奖励信息的奖励。

传输模块603可以是配置用于将奖励信息与服务请求一并发送到服务提供者的终端设备。

接收模块601还可以被配置为接收对服务请求完成的确认。

在确认服务请求的实现时，奖励模块204可以将奖励发放到服务提供者的账户。

此外，处理模块602可以是配置用于确定服务请求时间是否在预设时间内，其中，在预设时间内，可用的服务提供者的数量少于服务请求的数量，或者服务请求的起始位置和结束位置是否在预设区域内，其中，在预设区域中，可用的服务提供者的数量小于发起的服务请求的数量。

此外，接收模块601可以被配置为获取起始位置在服务请求时间的天气信息。处理模块602可以确定天气信息是否满足预设的天气标准。

进一步地，处理模块602还可以被配置为从起始位置到结束位置获取服务提供者的行程里程，并根据行程里程调整奖励信息。

此外，处理模块202还被配置为基于订单完成消息和一个或以上反作弊策略来确定订单是否是作弊订单，并且在确定订单是作弊订单时取消奖励响应。

奖励发放设备可以实现图4和5中的操作。本申请中提供的奖励发放设备可以执行以下操作的一个或以上。一个或以上操作包括从用户的终端设备接收服务请求，该服务请求包括服务请求时间、起始位置和结束位置；确定服务请求是否满足预设标准；如果满足预设标准，则获取奖励信息并将奖励信息与服务请求一起发送给服务提供者的终端设备；基于奖励信息，向服务提供者的账户发放奖励。该实施例中提供的设备可以通过在服务提供者接受订单之前将服务请求和奖励信息推送到服务提供者的终端设备，有助于激励服务提供者在特定时间段或特定区域内接收订单。在服务请求被推送到服务提供者之前，可以基于服务请求获取奖励信息，这可以使得能够在完成订单时实时地将奖励发放到服务提供者的账户中，从而提高了发放奖励的速度，增强了服务提供者的用户体验，进一步激励了服务提供者，更有条理地分配运输资源，并使乘客受益。

本申请的另一实施例提供了一种包括内存和处理器的奖励发放设备。内存被配置为存储计算机可执行指令。

当处理器调用存储在内存中的指令时，处理器可以根据本申请的一些实施例执行用于管理服务提供者的奖励的方法。在一些实施例中，处理器可以被配置为从用户的终端设备接收服务请求，该服务请求包括服务请求时间、起始位置和结束位置，确定服务请求是否满足预设标准，如果满足预设标准，则获取奖励信息并将奖励信息与服务请求一起发送给服务提供者的终端设备，并基于奖励信息向服务提供者的账户发放奖励。

在一些实施例中，接收模块601还可以被配置为从服务提供者的终端设备获取当前接受时间和先前完成时间。

处理模块602还可以被配置用于基于当前接受时间和先前完成时间之间的时间间隔来确定当前订单是否与上一先前订单连续。

如果当前订单是连续的，则奖励模块604还可以被配置为将当前连续订单添加到服务提供者的累积的先前完成的连续订单以获取连续订单的总数；当前订单完成时，如果连续订单的总数大于第一预设订单数，确定奖励，并将奖励发放到服务提供者的帐户。

在一些实施例中，奖励模块604还被配置为：根据当前订单的接受时间确定奖励量。

在一些实施例中，接收模块601可以从用户获取服务提供者的用户评级。奖励模块604可以根据用户评级确定奖励量。

此外，接收模块601还可以被配置为在服务提供者的帐户中获取奖励的总额。如果服务提供者的账户中的奖励的总额大于预设金额，则奖励模块604可以停止奖励的发放。

在一些实施例中，处理模块602可以确定连续订单的总数是否大于第二预设订单数。第二预设订单数可以由用户根据奖励发放***100的默认设置来设置。如果连续订单的总数大于第二预设订单数，则奖励模块604可以停止向服务提供者发放奖励。

奖励发放设备还可以实现图7和8中的操作。

本申请中描述的奖励发放设备可以执行一个或以上操作，包括获取与服务提供者相关联的服务信息，包括当前接受时间和先前完成时间的服务信息，确定当前接受时间与先前完成时间之间的时间间隔，如果时间间隔小于预设间隔，则确定服务提供者属于连续接单中，如果连续订单的总数大于第一预设订单数，则在订单完成时向服务提供者发放奖励。奖励发放设备可以通过奖励实时连续接单中的服务提供者来帮助增强服务提供者的用户体验，从而激励服务提供者尽可能多地接收订单，提高服务提供者接收订单的热情，减少请求服务的用户的等待时间，并促进用户的快速的行程。

图7是根据本申请的一些实施例所示的用于奖励连续接单的过程700的流程图。在一些实施例中，图7中所示的过程700可以在图1中所示的奖励发放***100中实现。例如，过程700的至少一部分可以作为指令的形式存储在存储设备(例如，计算装置200的磁盘270)中，并且由服务器110(例如，计算装置200的处理器220)调用和/或执行。在一些实施例中，过程700的一部分可以在终端设备上实现。下面呈现的所示过程700的操作旨在说明性的。在一些实施例中，过程700可以利用未描述的一个或以上附加操作，和/或没有所讨论的一个或以上操作来完成。另外，如图7所示和下面描述的过程700的操作的顺序不是限制条件性的。

在701中，可以从服务提供者的终端设备获取当前接受时间和先前完成时间。

在一些实施例中，当服务提供者完成上一先前订单(即，最新订单)时，可以通过服务提供者的终端设备将上一先前的完成的订单的订单信息上载到服务器100。在一些实施例中，订单信息可以包括上一先前完成的订单的完成时间。当服务提供者接收到当前订单时，服务器110可以从服务提供者的终端设备获取当前订单的订单接受时间(也称为“当前接受时间”)，并确定当前接受时间和先前完成时间之间的时间间隔。应当注意订单的订单信息也可以包括当前接受时间和先前完成时间。在一些实施例中，可以在完成当前订单之后从当前订单的订单信息获取当前接受时间。在一些实施例中，当服务提供者的终端设备接受当前订单时，可以立即将当前接受时间上传到服务器110。

在702中，可以基于当前接受时间和先前完成时间之间的时间间隔确定当前订单是与上一先前订单连续。时间间隔可以用于确定服务提供者是否属于连续接单(即，当前订单是连续的)。如这里所使用的，连续接单指的是服务提供者呈现叫车服务的状态。连续接单中的司机可被确定为全职服务提供者。在一些实施例中，连续接单中的服务提供者可以获取更多奖励。

在一些实施例中，可以确定当前接受时间和先前完成时间之间的时间间隔。服务器110可以基于时间间隔确定服务提供者是否属于连续接单。在一些实施例中，如果时间间隔小于预设间隔，则可以在连续接单中确定服务提供者。根据订单分配***的默认设置，用户可以设置预设间隔。在一些实施例中，预设间隔可以是常数，例如0.5小时。在一些实施例中，可以根据实际需要设置不同的预设间隔值。例如，服务器110可以确定先前完成时间是否落入特定时间段，例如午休时间(例如，12：00-14：00)。可以将预设间隔调整为更长的时间段，例如，如果服务器110确定先前的完成时间落入午休时间，则为2小时，以便为服务提供者提供足够的用餐和休息时间。在预设时间是常数的情况下，可以允许在特定时间段(例如午休时间)中的较长时间中断，并且服务器110可以识别出服务提供者正在进行午休，这可能不被视为连续接单的终止。然而，可以将特定时间段之外的较长时间中断确定为连续接单的终止。

在703中，如果当前订单是连续的，则可以将当前连续订单添加到服务提供者的累积的先前完成的连续订单，以获取连续订单的总数。如果连续订单的总数大于第一预设订单数，则在完成当前订单时确定奖励，并将奖励发放到服务提供者的帐户。

在一些实施例中，703中的操作可以涉及预设标准。如果满足预设标准，则可以确定奖励的奖励信息，并且当完成当前订单时，可以根据奖励信息执行相应的操作。在一些实施例中，预设标准包括预设服务标准。预设服务标准可以涉及服务提供者的连续接单。仅作为示例，如果服务提供者属于连续接单(即当前订单是连续的)并且连续接单中完成的订单总数(即连续订单总数)大于第一预设订单数，则可以确定满足预设服务标准。

在一些实施例中，响应于当前订单是连续的确定，可以将当前连续订单添加到服务提供者的累积的先前完成的连续订单中以获取连续订单的总数。如这里所使用的，累积的先前完成的连续订单是指在服务提供者接受当前订单之前完成的连续订单。服务器110可以确定连续订单的总数是否大于第一预设订单数。如果连续订单的总数大于第一预设订单数，则可以确定包括奖励信息的奖励，并且当完成当前订单时，可以根据奖励信息执行相应的操作。在一些实施例中，奖励信息可以包括用于奖励的金额。相应的操作可以包括将奖励发放到服务提供者的账户的至少一个操作。仅仅为了说明，奖励发放***100可以在连续订单的总数达到第一预设订单数的条件下将奖励发放到服务提供者的帐户，例如，第一预设订单数可以是3。当连续订单的总数为3时，如果服务提供者在他/她接受第四个订单时被确定为处于连续接单中，则当完成第四个订单时，可以向服务提供者发放奖励，从而激励服务提供者尽可能多地接收订单，提高服务提供者接受订单的积极性。

本申请中描述的连续接单奖励方法包括获取与服务提供者相关联的服务信息，服务信息包括当前接受时间和先前完成时间，确定当前接受时间和先前完成时间之间的时间间隔，如果时间间隔小于预设间隔，则确定服务提供者属于连续接单中，如果连续订单的总数大于第一预设订单数，则在订单满足时向服务提供者发放奖励。连续接单奖励方法通过奖励实时连续接单中的服务提供者来增强服务提供者的用户体验，从而激励服务提供者尽可能多地接收订单，提高服务提供者接受订单的热情，减少请求服务的用户的等待时间，并促进用户的快速的行程。

图8是根据本申请的一些实施例所示的用于奖励连续接单的过程800的流程图。在一些实施例中，可以结合过程700来描述过程800。

在801中，可以从服务提供者的终端设备获取当前接受和先前完成时间。

在802中，可以确定当前接受时间和先前完成时间之间的时间间隔。

在803中，可以进行关于时间间隔是否小于预设时间的确定。如果时间间隔小于预设时间，则可以执行804中的操作。如果时间间隔大于或等于预设时间，则可以执行806中的操作。

在804中，可以将当前连续订单添加到服务提供者的累积的先前完成的连续订单，以获取连续订单的总数。可以确定当前订单是连续订单(即，服务提供者属于连续接单)。如果当前订单是连续订单，则可以通过将当前连续订单添加到服务提供者的累积的先前完成的连续订单来确定连续订单的总数。

在805中，如果连续订单的总数大于第一预设订单数，则可以在当前订单完成时将奖励发放到服务提供者的账户。

在806中，确定时间间隔是否在预设时间段内。如果时间间隔在预设时间段内，则可以执行804中的操作，并且可以确定当前订单是连续订单。如果时间间隔不在预设时间段内，则可以执行807中的操作。

在807中，连续订单的总数可以设置为零。如果时间间隔不在预设时间段内，则可以确定当前订单不是连续订单，可以将连续订单的总数设置为零。

此外，在一些实施例中，奖励的金额可以是常数，例如，每个订单1元。在一些实施例中，奖励的金额也可以根据实际要求进行调整。例如，可以根据订单接受时间或来自乘客的订单的评估等来确定用于奖励的不同金额。

在一些实施例中，为了确定如703所述的服务提供者的奖励信息，服务器110还可以根据当前接受时间确定奖励的金额。

仅仅为了说明，可以增加奖励的金额，以鼓励服务提供者在早高峰时间段和/或晚上高峰时间段响应更多的服务请求。换句话说，如果确定当前的接受时间是早上高峰时间或晚上高峰时间，那么奖励的金额可能会更高，并且在完成订单后，可以将奖励发放到服务提供者的账户。

在一些实施例中，为了确定如703所述的服务提供者的奖励信息，服务器110还可以从乘客获取关于当前订单的评估的信息，并根据关于当前订单的评估的信息确定奖励的金额。

仅仅为了说明，可以从用户的终端设备获取评估，例如准时、对用户的态度、熟悉从起始位置到结束位置的路线等，并且可以根据评估调整奖励的金额。如果评估显示服务提供者具有良好的性能，则奖励的金额可以调整为更高，否则，奖励的金额可以调整为更低，从而激励服务提供者提高他/她的服务质量。

此外，如果呼叫平台收到来自服务提供者的请求以验证不良评估或来自用户的投诉，则呼叫平台可以验证不良评估或投诉，并生成验证信息。在一些实施例中，可以基于验证信息来调整奖励。具体而言，如果用户对订单评价不佳或投诉，则在评估不良或投诉得到验证后，可以调整与订单相关的服务提供者的奖励。例如，如果证实投诉是真实的，则奖励的金额可能会减少或取消。如果证实投诉不成立，则可以发放该奖励。又如，如果投诉是由用户引起的，并且服务提供者采取有效措施处理投诉，则可以增加奖励的金额，以鼓励服务提供者积极处理问题。

在一些实施例中，为了确定如703所述的服务提供者的奖励信息，服务器110还可以在服务提供者的账户中获取奖励的总额。如果服务提供者的帐户中的奖励的总额大于预设金额，则服务器110可以停止提供奖励。在一些实施例中，服务器110可以确定连续订单的总数是否大于第二预设订单数。第二预设订单数可以由用户根据奖励发放***100的默认设置来设置。如果连续订单的总数大于第二预设订单数，则服务器110可以停止向服务提供者发放奖励。

仅仅为了说明，可以考虑到奖励的成本以及避免服务提供者的疲劳驾驶来设定上限。在一些实施例中，上限可以是奖励金额的上限。在一些实施例中，上限可以是连续接单中完成的订单总数的上限。换句话说，可以确定关于服务提供者的账户中的奖励的总额是否大于或等于预设金额。如果服务提供者的账户中奖励的总额大于或等于预设金额，则可以取消奖励。在一些实施例中，可以确定连续订单的总数是否大于第二预设订单数。如果连续订单的总数大于第二预设订单数，则可以取消奖励。此外，当奖励的管理停止时，服务器110可以向服务提供者发送提示信息，使得服务提供者可以知道连续订单的总数达到上限。此外，奖励连续接单的重复周期可以设置为例如1天。连续订单的总数可以在每天零时设置为零。在一些实施例中，可以将重复周期设置为任何其他时间，例如，3天、一周、一个月等。

图9是根据本申请的一些实施例的服务奖励设备的结构图。

如图9所示，服务奖励设备可以包括处理器901、存储器902。

存储器902可以存储计算机程序。当处理器901执行计算机程序时，可以实现图7和8中所示的服务奖励方法。

在一些实施例中，服务奖励设备还可以包括总线903和通信接口904。处理器901、通信接口904和存储器902可以通过总线903连接。

存储器902可以包括高速随机存取存储器(RAM)，也可以包括非易失性存储器，例如至少一个磁盘存储器。由至少一个通信接口(例如，通信接口403)实现的通信连接(有线或无线)可以使用因特网、广域网、本地网络、城域网等。

总线903可以是ISA总线、PCI总线或EISA总线等。总线903可以分为地址总线、数据总线、控制总线等。为简洁起见，双侧箭头用于表示如图9所示的总线903，但是，它并不意味着只有一个总线或只有一种类型的总线。

存储器902可以用于存储计算机程序。处理器400在接收到执行指令时可以执行计算机程序。流程图中描述的上述方法可以应用于处理器901或由处理器901实现。

处理器901可以是具有信号处理能力的集成电路芯片。在一些实施例中，上述过程中的操作可以在硬件的集成逻辑电路或处理器901中的软件形式的指令中实现。处理器901可以是通用处理器，包括中央处理单元(CPU)、网络处理器(Network Processor，简称NP)等。它也可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成的可编程门阵列(FPGA)、或其他可编程逻辑设备、分立栅极、晶体管逻辑器件或分立硬件组件。本申请中披露的方法，操作和逻辑框图可以由处理器901实现或执行。处理器可以是微处理器或通用处理器，或任何传统处理器。本申请中披露的方法的操作可以由硬件解码处理器直接实现，或者可以由解码处理器中的硬件和软件模块的组合来执行。软件模块可以种植在传统的存储介质中，例如随机存取存储器、闪存、只读存储器、可编程只读存储器、电可擦除可编程存储器、寄存器等。存储介质可以由存储器902、处理器901读取存储器902中的信息实现，并在硬件上完成上述方法的操作。

上述实施例提供了一种应用于叫车服务的服务奖励设备，其被配置为从服务提供者的终端设备获取当前接受时间和先前完成时间，基于当前接受时间和先前完成时间之间的时间间隔确定当前订单是否与上一先前的订单连续的，如果当前订单是连续的，则将当前连续订单添加到服务提供者的累计先前已完成的连续订单，以获取连续订单的总数。如果连续订单的总数大于第一预设订单数，则在当前订单满足时确定奖励，并将奖励发放到服务提供者的帐户。

服务提供设备通过奖励实时连续接单中的服务提供者来增强服务提供者的用户体验，从而激励服务提供者尽可能多地接收订单，提高服务提供者接收订单的热情，减少请求服务的用户的等待时间，并促进用户的快速的行程。

在一些实施例中，应该理解，所披露的设备和方法可以以其他方式实现。例如，上述设备仅用于说明。又例如，模块仅由逻辑功能分开。例如，可以将多个模块或组件组合或集成到另一个***中，或者可以省略一些特征。另外，本申请中的耦合或通信连接可以是通过接口、设备或单元的间接耦合或通信连接，其可以是电、机械或其他类型。

图10是根据本申请的一些实施例所示的用于奖励用户的过程1000的流程图。过程1000中所示的用户奖励方法可以由服务器实现，例如，在线叫车服务器、指定的驾驶服务器等。在一些实施例中，图11中所示的过程1000可以在图1所示的奖励发放***100中实现。例如，过程1000的至少一部分可以作为指令的形式存储在存储设备(例如，计算装置200的DISK 270)中，并且由服务器110(例如，计算装置200的处理器220)调用和/或执行。在一些实施例中，过程1000的一部分可以在终端设备上实现。以下呈现的所示过程1000的操作旨在是说明性的。在一些实施例中，过程1000可以利用未描述的一个或以上附加操作，和/或没有所讨论的一个或以上操作来完成。另外，如图10所示和下面描述的过程1000的操作的顺序不是限制条件性的。

在1001中，可以从用户的终端设备获取包括起始位置的订单的订单信息。

在一些实施例中，订单可以是汽车订单或指定的行驶订单。订单信息可以包括诸如用户的起始位置、用户的结束位置等信息。

在1002中，可以根据订单信息分配服务提供者。

在一些实施例中，本文中的服务提供者可以根据订单的类型而变化。例如，如果订单是在线汽车订单，则服务提供者可以是车辆的司机。又例如，如果订单是指定的行驶订单，则服务提供者可以是指定的司机。该订单的应当注意类型不限于上述两种类型，并且服务提供者也不限于上述两种类型。

在一些实施例中，可以确定包括起始位置的地图上的圆圈。圆的中心可以是起始位置，并且圆的半径可以等于第一预设距离。服务器110可以搜索和分配位于圆圈中的服务提供者。在一些实施例中，可以为订单分配最靠近起始位置的服务提供者。在一些实施例中，如果很少的服务提供者位于圆圈中，则圆的半径可以延伸到第二预设距离。第二预设距离可以大于第一预设距离。例如，第一预设距离可以是3千米，第二预设距离可以是5千米。在一些实施例中，根据奖励发放***100的默认设置，第一预设距离和/或第二预设距离可以由用户设置。

在1003中，可以确定服务提供者到达起始位置的预估时间段是否大于或等于预设时间段。

如这里所使用的，预估时间段是指由服务器确定的服务提供者到达起始位置的时间段。在一些实施例中，服务器110可以确定从服务提供者的当前位置到起始位置的路线，并获取当前位置和起始位置之间的距离以及路线上的平均速度。可以基于距离和平均速度来确定预估时间。在一些实施例中，服务器110可以例如从服务提供者的当前位置获取一个或以上司机的历史行驶时间到起始位置。历史行驶时间的平均值可以被指定为预估时间。

在一些实施例中，可以根据服务提供者的当前位置与起始位置之间的距离来确定服务提供者到达起始位置的预估时间。在一些实施例中，当服务器110确定预估时间时，还可以考虑诸如道路状况、天气等的信息，以便更准确地计算预估时间。根据订单分配***100的默认设置，用户可以设置预设时间。在一些实施例中，可以根据实际需要或通过对大数据的分析来确定预设时间。用于确定预设时间的各种方式可以在本申请的其他地方提供，例如，图11和12，以及其描述。

在1004中，服务器110可以在预估时间大于或等于预设时间时，传输关于订单的在使用上有限制条件的折扣信息到用户的终端设备，其中折扣的限制条件包括实际用户等待时间长于或等于预估时间与其误差之和时，能够使用折扣。

预估时间的误差也可以被称为误差时间，即服务提供者与预估时间相比较晚或提前到达起始位置。关于预估时间的误差的确定的详细描述(即，误差时间)可以在本申请的其他地方披露，例如，图12及其描述。

在一些实施例中，折扣信息可包括折扣，例如，20％折扣。在一些实施例中，折扣信息可包括用于奖励的金额。如果用户等待服务提供者的到来，则金额可能是对用户的奖励。

在一些实施例中，如果服务提供者到达起始位置的预估时间大于或等于预设的时间，则表明服务提供者可能需要很长时间才能到达起始位置。在这种情况下，用户可能会取消订单。

通过将折扣信息发送给用户的终端设备，并且当其中折扣的限制条件包括实际用户等待时间长于或等于预估时间及其误差的总和时，能够使用折扣。用户可能等待，以便根据折扣信息在订单中获取折扣，以在他/她收到折扣信息时满足限制条件。这样，用户的等待时间可以增加到大于或等于预估时间和预设误差时间的总和，从而在预估时间及其误差的总和的时间范围内减少订单取消概率。

另外，当等待时间大于或等于预估时间与预设误差时间之和时，能够使用折扣信息，而不是等待时间大于或等于预设时间，因此，当出现小于预设误差时间的延迟时，错误地避免折扣信息的可用性，并减少了呼叫平台的损失。当服务提供者开车到起始位置时，由于意外情况导致的事故可能导致延迟。

图11是根据本申请的一些实施例所示的用于奖励用户的过程1100的流程图。可以结合过程1000来描述过程1100。与过程1000相比，过程1100还包括操作1101和1102。

在1101中，服务器110可以根据历史数据确定在用户等待服务提供者的时间段期间等待时间时间与订单取消概率之间的第一关系。

在一些实施例中，例如，可以从存储设备150或云存储器(未示出)获取一个或以上用户的至少两个历史订单。历史数据可以包括至少两个历史订单的信息。

在1102中，服务器110可以使用第一关系来确定对应于最大订单取消概率的优化的等待时间时间，并将优化的等待时间时间指定为第一预设时间。

在一些实施例中，服务器110可以获取用户取消的历史订单。在从用户的终端设备接收到包括起始位置的订单信息之前。服务器110可以获取得每个取消订单中的用户的等待时间，并确定等待时间间和订单取消概率之间的第一关系。在一些实施例中，第一关系可以以二维坐标系中的拟合曲线或离散点的形式表示。坐标系的横轴可以是每个订单的等待时间，纵轴可以是用户取消的历史订单的数量。在一些实施例中，服务器110可以基于至少两个历史订单的大数据来确定第一关系。然后，服务器110可以根据大数据确定对应于最大订单取消概率的优化的等待时间。可以将优化的等待时间设定为预设时间。

例如，服务器110可以获取10000个历史订单，用户等待15分钟后取消了5000个订单，用户等待10分钟后取消了2500个订单，用户等待12分钟后取消2000个订单，用户等待17分钟后取消了500个订单。可以确定优化的等待时间可以是15分钟，其对应于最大订单取消概率。然后，服务器110可以将预设时间确定为15分钟。

参考过程1100，在确定预估时间之后，用户可能需要至少等待服务提供者的预估时间。如果预估时间大于或等于预设时间，则等待时间也可以大于或等于预设时间，因此用户取消订单的概率可能更大。在这种情况下，具有限制条件的折扣信息可以被发送到用户的终端设备，以减少用户取消订单的可能性。如果预估时间小于预设时间，则用户取消订单的概率可能更小，并且可能不需要将折扣信息发送到用户的终端设备。

图12是根据本申请的一些实施例所示的用于奖励用户的过程1200的流程图。可以结合过程1000来描述过程1200。与过程1000相比，过程1200还包括操作1201和1202。

在1201中，服务器110可以根据历史数据确定预估时间和订单取消概率之间的第二关系。在一些实施例中，例如，可以从存储设备150或云存储器(未示出)获取一个或以上用户的至少两个历史订单。历史数据可以包括至少两个历史订单的信息。

在1202中，服务器110可以使用第二关系来确定对应于最大订单取消概率的优化的预估时间，并将优化的预估时间指定为第二预设时间。

在一些实施例中，服务器110可以在从用户的终端设备接收到包括起始位置的订单信息之前获取用户取消的历史订单。服务器110可以获取每个取消订单的预估时间，并确定预估时间和订单取消概率之间的第二关系。在一些实施例中，第二关系可以以二维坐标系中的拟合曲线或离散点的形式表示。坐标系的水平轴可以是每个订单的预估时间，垂直轴可以是用户取消的历史订单的数量。在一些实施例中，服务器110可以基于至少两个历史订单的大数据来确定第二关系。然后，服务器110可以根据大数据确定对应于最大订单取消概率的优化的预估时间。可以将优化的预估时间设想为预设时间。

例如，服务器110可以获取10000个历史订单，其中当预估时间为15分钟时，用户取消了5000个订单，当预估时间为10分钟时，用户取消了2500个订单，当预估时间为12分钟时，用户取消了2000个订单，当预估时间为17分钟时，用户取消了500个订单。可以确定优化的预估时间可以是15分钟，其对应于最大订单取消概率。然后，服务器110可以将预设时间确定为15分钟。

参考过程1000，在确定预估时间之后，服务器可以将预估时间发送到用户的终端设备。如果预估时间大于或等于预设时间，则用户取消订单的概率可能更大。在这种情况下，具有限制条件的折扣信息可以被发送到用户的终端设备，以减少用户取消订单的可能性。如果预估时间小于预设时间，则用户取消订单的概率可能更小，并且可能不需要将折扣信息发送到用户的终端设备。

在一些实施例中，服务器110还可以基于历史订单确定服务提供者到达起始位置的实际时间与预估时间之间的差异。在一些实施例中，可以基于差异来确定预设误差时间(即，预估时间的误差)。如这里所使用的，实际时间可以表示服务提供者实际到达起始位置的时间段，其也被称为“实际用户等待时间”。

在一些实施例中，可以在执行过程1000中的1001中的操作之前基于历史订单确定服务提供者到达起始位置的实际时间与预估时间之间的差异。服务器110可以获取具有至少两个历史订单的大数据，并且可以基于大数据来确定差异。例如，服务器110可以获取10000个历史订单，其中5000个订单可以对应于5分钟的差异，2500个订单可能相当于2分钟的差异，2000个订单可能对应0分钟的差异，500个订单可能相当于-2分钟的差异。

在一些实施例中，服务器110可以将差的最大正值指定为预设误差时间。仅仅为了说明，在上面的例子中，可以将与5000个历史订单相对应的5分钟的差异确定为预设误差时间。在一些实施例中，可以将所有阶数的差的平均值设计为预设误差时间。如果需要，也可以使用其他方法确定预设误差时间。

在一些实施例中，折扣信息的限制条件还可以包括：在服务提供者到达起始位置的实际时间大于预估时间和预设误差时间的总和的条件下，折扣信息是可用的。

仅仅是为了说明，当服务提供者到达起始位置的实际时间大于预估时间时，可以基于过程1000进一步限制条件折扣信息，即能够使用折扣。在一些实施例中，如果服务提供者未能到达预估时间内的起始位置，则用户能够使用折扣信息中的折扣。一方面，订单取消概率可能会减少，另一方面，如果服务提供者在预计时间段内到达起始位置，则折扣信息中的折扣可能是不可用的，这可能增加呼叫平台的利润。

在一些实施例中，折扣信息的限制条件还可以包括：如果服务提供者到达起始位置的实际时间小于或等于预估时间，则可以减少折扣信息中的折扣金额。这样，如果用户仍然需要等待很长时间，可以为用户提供一定的折扣，从而在确保用户可能对他/她的订单有折扣的基础上提高平台的利润。

图13是根据本申请的一些实施例的实现用户奖励方法的用户的终端设备的接口的示意图。

仅仅通过示例的方式，如图13所示，预设时间设置为10分钟，并且服务提供者到达起始位置的预估时间是10分钟，即预估时间等于预设时间。预设误差时间设定为1分钟。服务器110可以将关于订单的具有使用限制条件的折扣信息发送给用户的终端设备。终端设备的界面显示，例如，当前时间是15:23，限制条件可以是“如果服务提供者未在15:34到达起始位置，您将收到3元人民币的优惠券”。

图14是根据本申请的一些实施例的实现用户奖励方法的用户的终端设备的接口的示意图。

如图14所示，服务提供者尚未在15:34到达起始位置，界面向用户显示提示信息，即折扣信息中的折扣可供使用。例如，提示信息为“您的帐户中收到3元人民币的优惠券，可以在此订单中使用”。换句话说，当服务提供者到达起始位置的实际时间大于预估时间和预设误差时间的总和时，折扣信息是可用的。在这种情况下，如果用户愿意等待很长时间，则用户可以获取折扣作为补偿，以便用户可以接受等待服务提供者，从而减少订单取消概率。

图15是根据本申请的一些实施例的用户奖励设备的示意图。上述实施例中描述的用户奖励方法可以由服务器实现，例如，出租车服务器、服务提供者服务器。如图15所示，用户机构设备可以包括接收模块1501、查询模块1502、确定模块1503和奖励模块1504。

接收模块1501可以被配置为接收来自用户的终端设备的包括起始位置的订单信息。

查询模块1502可以被配置为根据订单信息分配服务提供者。

确定模块1503可以被配置用于确定服务提供者到达起始位置的预估时间是否大于或等于预设时间。

在预估时间大于或等于预设时间时，奖励模块1504可以被配置为用于传输关于订单的在使用上有限制条件的折扣信息到用户的终端设备，其中，限制条件包括当实际用户等待时间长于或等于预估时间与其误差的总和时，能够使用折扣。

图16是根据本申请的一些实施例的用户奖励设备的示意图。如图16所示，与图15相比，用户奖励设备还可以包括第一关系确定模块1601和第一预设时间确定模块1602。

第一关系确定模块1601可以根据历史数据确定在用户等待服务提供者的时间段内等待时间时间与订单取消概率之间的第一关系。

第一时间确定模块1602可以被配置为使用第一关系来确定对应于最大订单取消概率的优化的等待时间，并将优化的等待时间指定为第一预设时间。

图17是根据本申请的一些实施例的用户奖励设备的示意图。如图17所示，与图15相比，用户奖励设备还可以包括第二关系确定模块1701和第二预设时间确定模块1702。

第二关系确定模块1701可以是配置用于根据历史数据确定预估时间和订单取消概率之间的第二关系。

第二时间确定模块1702可以被配置为使用第二关系来确定对应于最大订单取消概率的优化的预估时间，并将优化的预估时间指定为第二预设时间。

在一些实施例中，用户奖励设备还可以包括差异确定模块。差异确定模块可以被配置用于确定服务提供者到达起始位置的实际时间与基于历史订单的预估时间之间的差异，并基于这些差异确定预设的误差时间。

在一些实施例中，限制条件还包括当服务提供者到达起始位置的实际时间大于预估时间和预设误差时间的总和时，能够使用折扣。

折扣信息是可用的，条件是服务提供者到达起始位置的实际时间大于预估时间和预设误差时间的总和。

对于用户奖励设备，由于它基本上对应于图10、11和12中描述的用户奖励方法，所以关于用户奖励设备的模块的细节可以参考用户奖励方法的描述。

上述用户奖励设备仅用于说明。被描述为单独组件的模块可以或可以不在物理上彼此分离，并且被示为模块的组件可以是或可以不是物理模块，即，模块或组件可以位于一个地方，或者可以分布到多个网络模块。

可以根据实际需要选择一个或以上模块来实现用户奖励过程。本领域的普通技术人员可以在没有任何创造性努力的情况下理解和实现相同或类似的设备。

本申请的实施例还提供了一种电子设备，包括至少一个处理器，以及至少一个存储器，用于存储可执行指令。至少一个处理器可以被配置为接收包括来自用户的终端设备的起始位置的订单的订单信息，根据订单信息发送服务提供者，确定服务提供者到达起始位置的预估时间是否大于或等于预设时间，并且在预估时间大于或等于预设时间时，传输关于订单的在使用上有限制条件的折扣信息到用户的终端设备，其中，限制条件包括当实际用户等待时间长于或等于预估时间与其误差之和时，能够使用折扣。

本申请的实施例还可以提供存储计算机程序的计算机可读存储介质。该程序在由处理器执行时实现以下操作。操作可以包括从用户的终端设备接收包括起始位置的订单的订单信息，根据订单信息分配服务提供者，确定服务提供者到达起始位置的预估时间是否大于或等于预设的时间，并且，在预估时间大于或等于预设时间时，传输关于订单的在使用上有限制条件的折扣信息到用户的终端设备，其中限制条件包括，当实际用户等待时间长于或等于预估时间与其误差之和时，能够使用折扣。

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

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

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

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

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

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

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

Claims (52)

1.一种用于奖励司机的***，其特征在于，包括：

存储指令的至少一个存储介质，所述指令包括当满足预设奖励标准时授予司机奖励的信息，所述预设奖励标准包括预设时间标准、预设位置标准或预设服务标准中的至少一个；以及

用于与所述至少一个存储介质通信的至少一个处理器，其中当执行所述指令时，所述至少一个处理器用于：

接收用户的订单信息；

确定所述订单信息是否满足预设奖励标准；

如果满足所述预设奖励标准，则将奖励与服务请求一并发送给司机；以及

若所述司机接受并完成所述服务请求，将所述奖励发送给所述司机。

2.根据权利要求1所述的***，其特征在于，所述订单信息包括服务请求时间、起始位置和结束位置。

3.根据权利要求2所述的***，其特征在于，为确定所述订单信息是否满足所述预设奖励标准，所述至少一个处理器用于：

确定所述服务请求时间、所述起始位置和所述结束位置是否满足预设时间标准或预设位置标准中的至少一个。

4.根据权利要求3所述的***，其特征在于，为确定所述服务请求时间、所述起始位置和所述结束位置是否满足所述预设时间标准或所述预设位置标准中的至少一个，所述至少一个处理器用于：

确定所述服务请求时间是否在预设时间内，其中在所述预设时间内，可用的服务提供者的数量小于服务请求的数量。

5.根据权利要求3所述的***，其特征在于，为确定所述服务请求时间、所述起始位置和所述结束位置是否满足所述预设时间标准或所述预设位置标准中的至少一个，所述至少一个处理器用于：

确定所述起始位置或所述结束位置是否在预设区域内，其中在所述预设区域内，可用的服务提供者的数量小于服务请求的数量。

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

获取所述起始位置在所述服务请求时间的天气信息。

7.根据权利要求6所述的***，其特征在于，为确定所述订单信息是否满足所述预设奖励标准，所述至少一个处理器用于：

基于所述起始位置在所述服务请求时间的所述天气信息，确定满足的预设天气条件。

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

获取所述起始位置到所述结束位置的距离；以及

基于所述距离调整所述奖励。

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

根据反作弊策略确定订单是否为作弊订单；以及

响应于所述订单是作弊订单的确定，取消发放所述奖励。

10.根据权利要求1所述的***，其特征在于，所述订单信息包括当前接受时间和先前完成时间。

11.根据权利要求10所述的***，其特征在于，为确定所述订单信息是否满足所述预设奖励标准，所述至少一个处理器用于：

确定所述当前接受时间与所述先前完成时间之间的时间间隔；

根据所述当前接受时间与所述先前完成时间之间的所述时间间隔，确定当前订单是否与上一先前订单连续；以及

响应于所述当前订单是连续的确定，

确定连续订单总数是否大于第一预设订单数；以及

响应于所述连续订单总数大于所述第一预设订单数的确定，

确定满足的预设服务条件。

12.根据权利要求11所述的***，其特征在于，为根据所述当前接受时间与所述先前完成时间之间的所述时间间隔，确定所述当前订单是否与上一先前订单连续，所述至少一个处理器用于：

确定所述时间间隔是否小于预设间隔；以及

响应于所述时间间隔小于所述预设间隔的确定，

确定服务提供者属于连续接单。

13.根据权利要求12所述的***，其特征在于，所述至少一个处理器进一步用于：

响应于确定所述时间间隔不小于所述预设时间间隔，

确定所述时间间隔是否在预设时间段内；以及

响应于所述时间间隔在预设时间段内的确定，

确定所述服务提供者属于连续接单。

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

基于所述当前接受时间确定所述奖励。

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

获取请求者对所述当前订单的服务提供者的用户评级；以及

基于所述用户评级确定所述奖励。

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

获取服务提供者的账户中的奖励总额；

确定所述服务提供者的所述账户中的奖励总额是否大于预设金额；以及

响应于所述服务提供者的所述账户中的奖励总额大于所述预设金额的确定，

停止发放所述奖励。

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

获取连续接单的订单总数；

确定所述订单总数是否大于第二预设订单数；以及

响应于所述订单总数大于所述第二预设订单数的确定，

停止发放所述奖励。

18.一种用于奖励用户的***，包括：

存储指令的至少一个存储介质，所述指令包括当用户需要长时间等待服务提供者时授予所述用户奖励的信息；以及

用于与所述至少一个存储介质通信的至少一个处理器，其中当执行所述指令时，所述至少一个处理器用于：

在设备中接收和储存来自用户的终端设备的服务请求，其中所述服务请求包括订单信息，所述订单信息包括起始位置；

基于所述订单信息使用所述处理器为用户分配服务提供者；

使用所述处理器确定所述服务提供者到达所述起始位置的预估时间段；以及

如果所述预估时间段大于或者等于预设时间段，传输关于服务请求在使用上有限制条件的折扣信息到所述用户的终端设备，其中所述限制条件包括当实际用户等待时间长于或等于预估时间段和预设误差时间的和时，能够使用折扣。

19.根据权利要求18所述的***，其特征在于，所述至少一个处理器进一步用于：

获取至少两个先前服务请求；以及

基于所述至少两个先前服务请求确定所述预设时间段或者所述预设误差时间。

20.根据权利要求19所述的***，其特征在于，为基于所述至少两个先前服务请求确定所述预设时间段，所述至少一个处理器用于：

基于所述至少两个先前服务请求，确定等待时间和订单取消概率之间的第一关系；以及

根据所述第一关系确定所述预设时间段。

21.根据权利要求20所述的***，其特征在于，为根据所述第一关系确定所述预设时间段，所述至少一个处理器用于：

根据所述第一关系确定对应于最大订单取消概率的优化的等待时间；以及

指定所述优化的等待时间作为所述预设时间段。

22.根据权利要求19所述的***，其特征在于，为基于所述至少两个先前服务请求确定所述预设时间段，所述至少一个处理器用于：

基于所述至少两个先前服务请求，确定所述预估时间段和订单取消概率之间的第二关系；以及

根据所述第二关系确定所述预设时间段。

23.根据权利要求22所述的***，其特征在于，为根据所述第二关系确定所述预设时间段，所述至少一个处理器用于：

根据所述第二关系确定对应于最大订单取消概率的优化的预估时间段；以及

指定所述优化的预估时间段作为所述预设时间段。

24.根据权利要求19所述的***，其特征在于，为基于所述至少两个先前服务请求确定所述预设误差时间，所述至少一个处理器用于：

基于所述至少两个先前服务请求确定服务提供者到达起始位置的实际时间段和预估时间段的差值；以及

基于所述差值确定所述预设误差时间。

25.根据权利要求18所述的***，其特征在于，所述限制条件进一步包括：

当服务提供者到达起始位置的实际时间段大于所述预估时间段和所述预设误差时间的和时，能够使用折扣。

26.一种在包括至少一个处理器和至少一个计算机可读存储介质的设备上实现的用于奖励司机的方法，其特征在于，所述存储介质存储当满足预设奖励标准授予司机奖励的信息，所述预设奖励标准包括预设时间标准、预设位置标准或者预设服务标准中的至少一个，所述方法包括：

接收用户的订单信息；

确定所述订单信息是否满足预设奖励标准；

如果满足所述预设奖励标准，则将奖励与服务请求一并发送给司机；以及

若所述司机接受并完成所述服务请求，将所述奖励发送给所述司机。

27.根据权利要求26所述的方法，其特征在于，所述订单信息包括服务请求时间、起始位置和结束位置。

28.根据权利要求27所述的方法，其特征在于，确定所述订单信息是否满足所述预设奖励标准包括：

确定所述服务请求时间、所述起始位置和所述结束位置是否满足预设时间标准或预设位置标准中的至少一个。

29.根据权利要求28所述的方法，其特征在于，确定所述服务请求时间、所述起始位置和所述结束位置是否满足所述预设时间标准或所述预设位置标准中的至少一个包括：

确定所述服务请求时间是否在预设时间内，其中在所述预设时间内，可用的服务提供者的数量小于服务请求的数量。

30.根据权利要求28所述的方法，其特征在于，确定所述服务请求时间、所述起始位置和所述结束位置是否满足所述预设时间标准或所述预设位置标准中的至少一个包括：

确定所述起始位置或所述结束位置是否在预设区域内，其中在所述预设区域内，可用的服务提供者的数量小于服务请求的数量。

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

获取所述起始位置在所述服务请求时间的天气信息。

32.根据权利要求31所述的方法，其特征在于，确定所述订单信息是否满足所述预设奖励标准包括：

基于所述起始位置在所述服务请求时间的所述天气信息，确定满足预设天气条件。

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

获取所述起始位置到所述结束位置的距离；以及

基于所述距离调整所述奖励。

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

根据反作弊策略确定订单是否为作弊订单；以及

响应于所述订单是作弊订单的确定，

取消发放所述奖励。

35.根据权利要求26所述的方法，其特征在于，所述订单信息包括当前接受时间和先前完成时间。

36.根据权利要求35所述的方法，其特征在于，确定所述订单信息是否满足所述预设奖励标准包括：

确定所述当前接受时间与所述先前完成时间之间的时间间隔；

根据所述当前接受时间与所述先前完成时间之间的所述时间间隔，确定当前订单是否与上一先前订单连续；以及

响应于所述当前订单是连续的确定，

确定连续订单的总数是否大于第一预设订单数；以及

响应于所述连续订单总数大于所述第一预设订单数的确定，

确定满足的预设服务条件。

37.根据权利要求36所述的方法，其特征在于，根据所述当前接受时间与所述先前完成时间之间的所述时间间隔，确定所述当前订单是否与上一先前订单连续包括：

确定所述时间间隔是否小于预设间隔；以及

响应于所述时间间隔小于所述预设间隔的确定，

确定服务提供者属于连续接单。

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

响应于确定所述时间间隔不小于预设间隔，

确定所述时间间隔是否在预设时间段内；以及

响应于所述时间间隔在预设时间段内的确定，

确定所述服务提供者属于连续接单。

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

基于所述当前接受时间确定所述奖励。

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

获取请求者对所述当前订单的服务提供者的用户评级；以及

基于所述用户评级确定所述奖励。

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

获取服务提供者的账户中的奖励总额；

确定所述服务提供者的所述账户中的奖励总额是否大于预设金额；以及

响应于所述服务提供者的所述账户中的奖励总额大于所述预设金额的确定，

停止发放所述奖励。

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

获取连续接单的订单总数；

确定所述订单总数是否大于第二预设订单数；以及

响应于所述订单总数大于所述第二预设订单数的确定，

停止发放所述奖励。

43.一种在包括至少一个处理器和至少一个计算机可读存储介质的设备上实现的用于奖励用户的方法，其特征在于，所述存储介质存储当所述用户需要长时间等待服务提供者时授予所述用户奖励的信息，所述方法包括：

在设备中接收和储存来自用户的终端设备的服务请求，其中所述服务请求包括订单信息，所述订单信息包括起始位置；

基于所述订单信息使用所述处理器为用户分配服务提供者；

使用所述处理器确定所述服务提供者到达所述起始位置的预估时间段；以及

如果所述预估时间段大于或者等于预设时间段，传输关于服务请求在使用上有限制条件的折扣信息到所述用户的终端设备，其中所述限制条件包括当实际用户等待时间长于或等于预估时间段和预设误差时间的和时，能够使用折扣。

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

获取至少两个先前服务请求；以及

基于所述至少两个先前服务请求确定所述预设时间段或者所述预设误差时间。

45.根据权利要求44所述的方法，其特征在于，基于所述至少两个先前服务请求确定所述预设时间段包括：

基于所述至少两个先前服务请求，确定等待时间和订单取消概率之间的第一关系；以及

根据所述第一关系确定所述预设时间段。

46.根据权利要求45所述的方法，其特征在于，根据所述第一关系确定所述预设时间段包括：

根据所述第一关系确定对应于最大订单取消概率的优化的等待时间；以及

指定所述优化的等待时间作为所述预设时间段。

47.根据权利要求44所述的方法，其特征在于，基于所述至少两个先前服务请求确定所述预设时间段包括：

基于所述至少两个先前服务请求，确定所述预估时间段和订单取消概率之间的第二关系；以及

根据所述第二关系确定所述预设时间段。

48.根据权利要求47所述的方法，其特征在于，根据所述第二关系确定所述预设时间段包括：

根据所述第二关系确定对应于最大订单取消概率的优化的预估时间段；以及

指定所述优化的预估时间段作为所述预设时间段。

49.根据权利要求44所述的方法，其特征在于，基于所述至少两个先前服务请求确定所述预设误差时间包括：

基于所述至少两个先前服务请求确定服务提供者到达起始位置的实际时间段和预估时间段的差值；以及

基于所述差值确定所述预设误差时间。

50.根据权利要求43所述的方法，其特征在于，所述限制条件进一步包括：

当服务提供者到达起始位置的实际时间段大于所述预估时间段和所述预设误差时间的和时，能够使用折扣。

51.一种在包括至少一个处理器和至少一个计算机可读存储介质的设备上实现的用于奖励司机的方法，其特征在于，所述存储介质存储当满足预设奖励标准授予司机奖励的信息，所述预设奖励标准包括预设时间标准、预设位置标准或者预设服务标准中的至少一个，当计算设备的所述至少一个处理器执行时，所述方法包括：

接收用户的订单信息；

确定所述订单信息是否满足预设奖励标准；

如果满足所述预设奖励标准，则将奖励与服务请求一并发送给司机；以及

若所述司机接受并完成所述服务请求，将所述奖励发送给所述司机。

52.一种包括至少一组奖励用户的指令的计算机可读存储介质，其特征在于，所述存储介质存储当所述用户需要长时间等待服务提供者时授予所述用户奖励的信息，当计算设备的至少一个处理器执行时，至少一组指令用于使所述计算设备执行方法，所述方法包括：

在设备中接收和储存来自用户的终端设备的服务请求，其中所述服务请求包括订单信息，所述订单信息包括起始位置；

基于所述订单信息使用所述处理器为用户分配服务提供者；

使用所述处理器确定所述服务提供者到达所述起始位置的预估时间段；以及

如果所述预估时间段大于或者等于预设时间段，传输关于服务请求在使用上有限制条件的折扣信息到所述用户的终端设备，其中所述限制条件包括当实际用户等待时间长于或等于预估时间段和预设误差时间的和时，能够使用折扣。

Images