Nothing Special   »   [go: up one dir, main page]

CN110741402A - 用于运力调度的系统和方法 - Google Patents

用于运力调度的系统和方法 Download PDF

Info

Publication number
CN110741402A
CN110741402A CN201880037805.XA CN201880037805A CN110741402A CN 110741402 A CN110741402 A CN 110741402A CN 201880037805 A CN201880037805 A CN 201880037805A CN 110741402 A CN110741402 A CN 110741402A
Authority
CN
China
Prior art keywords
service
area
service providers
available service
determining
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201880037805.XA
Other languages
English (en)
Other versions
CN110741402B (zh
Inventor
张凌宇
汪恭正
张妮萍
李璐
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Didi Infinity Technology and Development Co Ltd
Original Assignee
Beijing Didi Infinity Technology and Development Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from CN201710447357.8A external-priority patent/CN109087502B/zh
Priority claimed from CN201710476717.7A external-priority patent/CN109102135B/zh
Priority claimed from CN201710590255.1A external-priority patent/CN110020215A/zh
Application filed by Beijing Didi Infinity Technology and Development Co Ltd filed Critical Beijing Didi Infinity Technology and Development Co Ltd
Publication of CN110741402A publication Critical patent/CN110741402A/zh
Application granted granted Critical
Publication of CN110741402B publication Critical patent/CN110741402B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/52—Queue scheduling by attributing bandwidth to queues
    • H04L47/522—Dynamic queue service slot or variable bandwidth allocation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06313—Resource planning in a project environment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/20—Monitoring the location of vehicles belonging to a group, e.g. fleet of vehicles, countable or determined number of vehicles
    • G08G1/202—Dispatching vehicles on the basis of a location, e.g. taxi dispatching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/52—Queue scheduling by attributing bandwidth to queues
    • H04L47/525—Queue scheduling by attributing bandwidth to queues by redistribution of residual bandwidth
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
    • H04L47/762—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/78—Architectures of resource allocation
    • H04L47/783—Distributed allocation of resources, e.g. bandwidth brokers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/52—Network services specially adapted for the location of the user terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18—Negotiating wireless communication parameters
    • H04W28/20—Negotiating bandwidth

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Human Resources & Organizations (AREA)
  • Economics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • General Business, Economics & Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Theoretical Computer Science (AREA)
  • Marketing (AREA)
  • Tourism & Hospitality (AREA)
  • Development Economics (AREA)
  • Operations Research (AREA)
  • Biodiversity & Conservation Biology (AREA)
  • Game Theory and Decision Science (AREA)
  • Educational Administration (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本申请涉及运力调度的系统和方法。该系统和方法可以确定目标区域，其中满足预设条件的至少两个服务请求从目标区域发起。该系统和方法可以基于目标区域的信息确定非忙碌区域。非忙碌区域可以包括一个或以上可以自由接受服务请求的可用服务提供者。该系统和方法可以经由网络将与至少两个服务请求相关的调度指令发送至与非忙碌区域中的一个或以上可用服务提供者中的至少一个相关的用户终端。调度指令可以包括询问非忙碌区域中的一个或以上可用服务提供者中的至少一个是否同意前往目标区域的信息。

Description

用于运力调度的系统和方法
交叉引用
本申请基于并要求2017年6月14日提交的中国申请号为201710447357.8的申请的优先权的权益，2017年6月21日提交的中国申请号为201710476717.7和2017年7月19日提交的中国申请号为201710590255.1的优先权的权益，上述申请的全部内容通过引用被包含于此。
技术领域
本申请涉及用于线上到线下服务的系统和方法，尤其涉及用于运力调度的系统和方法。
背景技术
随着互联网技术的发展，基于互联网的线上到线下服务(例如，在线出租车打车服务)变得越来越流行。与线上到线下服务相关联的服务需求在不同情况下可能是不同的。例如，在不同的时间段(例如，高峰时段、非高峰时段)、不同地区(例如，中央商务区、村庄)的服务需求可能不同。因此，期望提供用于运力调度的系统和方法，以有效地满足服务需求。
发明内容
本申请的一个方面涉及一种用于运力调度的系统。该系统可以包括至少一个存储装置，所述存储装置包括一组指令，以及与所述至少一个存储装置通信的至少一个处理器。当执行所述组指令时，所述至少一个处理器可以被配置为使所述系统执行以下一个或以上操作。所述至少一个处理器可以确定目标区域，其中满足预设条件的至少两个服务请求从所述目标区域发起，所述至少两个服务请求通过与至少两个服务请求者相关联的至少两个用户终端发起。所述至少一个处理器可以根据所述目标区域的信息确定非忙碌区域，所述非忙碌区域可以包括一个或以上可自由接受服务请求的可用服务提供者。所述至少一个处理器可以通过网络，将与所述至少两个服务请求相关联的调度指令发送到与所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个相关联的用户终端，所述调度指令可以包括询问所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个是否同意前往目标区域的信息，其中，所述调度指令的至少一部分可以通过所述用户终端执行的应用程序的图形用户界面显示。
本申请的另一方面涉及一种用于运力调度的方法。该方法可以在具有至少一个处理器、至少一个存储装置和连接到网络的通信平台的计算装置上实现。所述方法可以包括一个或以上下述操作。所述至少一个处理器可以确定所述目标区域，其中，满足预设条件的至少两个服务请求从所述目标区域发起。所述至少两个服务请求可以通过与所述至少两个服务请求者相关联的至少两个用户终端发起。所述至少一个处理器可以根据所述目标区域的信息确定非忙碌区域。所述非忙碌区域可以包括一个或以上可以自由接受服务请求的可用服务提供者。所述至少一个处理器可以经由网络将与所述至少两个服务请求相关联的调度指令发送到与所述非忙碌区域中的所述一个或以上可用服务提供者中的所述至少一个相关联的用户终端。所述调度指令可以包括询问所述非忙碌区域中的一个或以上可用服务提供者中的至少一个是否同意前往目标区域的信息，其中，所述调度指令的至少一部分可以通过所述用户终端执行的应用程序的图形用户界面显示。
本申请的另一方面涉及一种非暂时性计算机可读介质。所述非暂时性计算机可读介质可以包括用于运力调度的一组指令。当由所述至少一个处理器执行时，该组指令可以指示所述至少一个处理器实现一种方法。所述方法可以包括一个或以上下述操作。所述至少一个处理器可以确定所述目标区域，其中，满足预设条件的所述至少两个服务请求从所述目标区域发起。所述至少两个服务请求可以通过与所述至少两个服务请求者相关联的至少两个用户终端发起。根据所述目标区域的信息，所述至少一个处理器可以确定非忙碌区域。所述非忙碌区域可以包括一个或以上可自由接受服务请求的可用服务提供者。所述至少一个处理器可以通过网络将与所述至少两个服务请求相关联的调度指令发送到与所述非忙碌区域中的一个或以上所述可用服务提供者中的至少一个相关联的用户终端。所述调度指令可以包括询问所述非忙碌区域中的一个或以上可用服务提供者中的至少一个是否同意前往所述目标区域的信息，其中，所述调度指令的至少一部分可以通过所述用户终端执行的应用程序的图形用户界面显示。
在一些实施例中，所述至少一个处理器可以确定目标半径和目标服务请求数。所述至少一个处理器可以通过使用聚类算法基于所述目标半径和所述目标服务请求数，将预设区域划分为至少两个候选区域。对于所述至少两个候选区域中的至少一个，所述至少一个处理器可以确定分配率是否小于分配率阈值；基于确定所述分配率小于所述分配率阈值的结果，确定所述候选区域中的所述可用服务提供者的数量与所述候选区域中待分配的服务请求的比值是否小于比值阈值；并基于确定所述候选区域中的所述可用服务提供者的所述数量与所述候选区域中所述待分配的服务请求的比值小于所述比值阈值的确定结果，确定所述候选区域为目标区域。
在一些实施例中，所述至少一个处理器可以确定至少两个数据对，所述至少两个数据对中的每一个包括预设半径和预设服务请求数。所述至少一个处理器可以基于聚类算法确定与所述至少两个数据对相对应的至少两个分布熵。所述至少一个处理器可以确定所述至少两个分布熵中的最大分布熵。在所述至少一个处理器可以在至少两个数据对中选择对应于所述最大分布熵的数据对。所述至少一个处理器可以确定与所述所选择的数据对相对应的预设半径和预设服务请求数作为所述目标半径和所述目标服务请求数。
在一些实施例中，所述至少一个处理器可以确定所述目标区域的边界。所述至少一个处理器可以获取与所述目标区域相关联的扩展参数。所述至少一个处理器可以根据所述扩展参数确定调整边界。所述至少一个处理器可以根据所述调整的边界确定所述非忙碌区域。
在一些实施例中，响应于从与所述非忙碌区域中的一个或以上所述可用服务提供者中的至少一个相关联的用户终端接收的调度指令的接受，所述至少一个处理器可以发送所述至少两个服务请求中的至少一个的信息到与所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个相关联的所述用户终端。发送所述至少两个服务请求中的至少一个的信息到与所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个相关联的所述用户终端，可以包括与至少两个服务请求中的至少一个相关联的位置。可以根据与所述至少两个服务请求中的至少一个相关联的用户终端发送的GPS数据，确定与所述至少两个服务请求中的至少一个相关联的位置。
在一些实施例中，所述至少一个处理器可以确定从非忙碌区域中的一个或以上可用服务提供者中的至少一个的用户终端接收到调度指令的接受的第一时间点。所述至少一个处理器可以确定非忙碌区域中的一个或以上可用服务提供者中的至少一个到达目标区域的第二时间点。
在一些实施例中，所述至少一个处理器可以确定预设的时间段。所述至少一个处理器可以基于预设时间段以及第一时间点或第二时间点中的至少一个，确定所述非忙碌区域中的一个或以上所述可用服务提供者中的至少一个的服务时间段。所述至少一个处理器可以在所述服务时间段内，将从所述目标区域发起至少两个服务请求中的至少一个的信息，发送到与所述非忙碌区域中的一个或以上所述可用服务提供者中的至少一个相关联的至少一个所述用户终端。发送到与非忙碌区域中的一个或以上所述可用服务提供者中的至少一个相关联的至少一个所述用户终端的所述至少两个服务请求中的至少一个的信息可以包括与至少两个所述服务请求中的至少一个相关联的位置。可以根据与至少两个服务请求中的至少一个相关联的用户终端发送的GPS数据确定与至少两个服务请求中的至少一个相关联的位置。
在一些实施例中，所述至少一个处理器可以确定第一时间点和第二时间点之间的时间间隔。所述至少一个处理器可以确定时间间隔是否小于时间间隔阈值。所述至少一个处理器可以基于确定所述时间间隔小于所述时间间隔阈值的结果，向与所述非忙碌区域中的至少一个或以上所述可用服务提供者中的至少一个相关联的所述用户终端执行的应用程序发送表示奖励的信息。
在一些实施例中，所述至少一个处理器可以将调度指令发送到与非忙碌区域中的一个或以上可用服务提供者相关联的一个或以上用户终端。所述至少一个处理器可以从所述一个或以上可用服务提供者的一个或以上用户终端接收表示所述一个或以上可用服务提供者的相应部分同意前往目标区域的一个或以上接受。所述至少一个处理器可以确定所接收的一个或以上接受的数量。所述至少一个处理器可以确定一个或以上接受的数量是否大于预设阈值。所述至少一个处理器可以基于确定一个或以上接受的数量大于预设阈值的结果，停止向与非忙碌区域中的一个或以上可用服务提供者相关联的所述一个或以上用户终端发送所述调度指令。
在一些实施例中，所述至少一个处理器可以基于从与一个或以上可用服务提供者中的至少一个相关联的用户终端所执行的应用程序接收的GPS(全球定位系统)的数据，确定非忙碌区域中的一个或以上可用服务提供者中的至少一个的位置。所述GPS数据可以由所述用户终端的GPS芯片组确定。
在一些实施例中，所述至少一个处理器可以识别目标区域中的调度位置，其中，调度位置的预设范围内的服务请求密度大于密度阈值。所述至少一个处理器可以确定所述一个或以上可用服务提供者中的至少一个的位置与所述调度位置之间的距离。所述至少一个处理器可以确定所述一个或以上可用服务提供者中的至少一个的位置与所述调度位置之间的距离是否小于距离阈值。所述至少一个处理器可以基于确定一个或以上可用服务提供者中的至少一个的位置与所述调度位置之间的距离小于距离阈值的确定结果，将调度位置的信息发送到与一个或以上可用服务提供者中的至少一个相关联的用户终端。
在一些实施例中，所述至少一个处理器可以从一个或以上可用服务提供者中的至少一个的所述位置确定到目标区域的估算行程时间。如果一个或以上可用服务提供者中的至少一个到达目标区域，则所述至少一个处理器可以确定与一个或以上可用服务提供者中的至少一个相关联的收益值。所述至少一个处理器可以确定所述收益值与所述估算行程时间的比值是否大于比值阈值。所述至少一个处理器可以基于确定收益值对估算行程时间的比值大于阈值的确定结果，将与至少两个服务请求相关联的调度指令发送到与一个或以上可用服务提供者中的至少一个相关联的用户终端执行的应用程序。
在一些实施例中，所述至少一个处理器可以估算从一个或以上所述可用服务提供者中的至少一个的位置到所述目标区域的行程费用。如果一个或以上所述可用服务提供者中的至少一个到达目标区域，则所述至少一个处理器可以确定向一个或以上所述可用服务提供者中的至少一个被分配服务请求的概率。如果一个或以上所述可用服务提供者中的至少一个到达目标区域，则所述至少一个处理器可以估算分配给一个或以上所述可用服务提供者中的至少一个的所述服务请求的服务费用。所述至少一个处理器可以根据所述行程费用、所述概率和所述服务费用来估算与一个或以上所述可用服务提供者中的至少一个相关联的收益值。
在一些实施例中，所述至少一个处理器可以根据估算行程时间确定预测时间段。所述至少一个处理器可以估算在预测时间段内在所述目标区域中待分配的服务请求的数量和所述目标区域中所述可用服务提供者的数量。所述至少一个处理器可以基于待分配的服务请求数和所述可用服务提供者的数量，确定所述一个或以上所述可用服务提供者中的至少一个被分配服务请求的概率。
其他特征将在以下部分描述中进行阐述，并且在检视以下及随附图标之后，部分特征对于本领域的普通技术人员来讲是显而易见地，或可以通过实例的生产及操作来了解。本申请的特征可以通过对以下描述的具体实施例的各种方法、手段和组合的实践或使用得以实现和达到。
附图说明
本申请将结合示例性实施例进一步进行描述。这些示例性的实施例将结合附图进行详细描述。这些实施例并非限制性的，图中相同标号表示相同结构，其中：
图1是根据本申请的一些实施例所示的示例性按需服务系统的示意图；
图2是根据本申请的一些实施例所示的一种计算装置的示例性硬件和/或软件组件的示意图；
图3是根据本申请的一些实施例所示的一种移动装置的示例性硬件组件和/或软件组件的示意图；
图4是根据本申请的一些实施例所示的基于服务请求分布的运力调度的示例性流程图；
图5是根据本申请的一些实施例所示的基于服务请求分布的运力调度的示例性流程图；
图6是根据本申请的一些实施例所示的基于服务请求分布的运力调度的示例性流程图；
图7是根据本申请的一些实施例所示的基于服务请求分布的运力调度的示例性流程图；
图8是根据本申请的一些实施例所示的基于服务请求分布的运力调度的示例性流程图；
图9是根据本申请的一些实施例所示的基于服务请求分布的运力调度的示例性流程图；
图10是根据本申请的一些实施例所示的示例性运力调度系统的框图；
图11是根据本申请的一些实施例所示的示例性运力调度系统的框图；
图12是根据本申请的一些实施例所示的示例性运力调度系统的框图；
图13是根据本申请的一些实施例所示的示例性运力调度系统的框图；
图14是根据本申请的一些实施例所示的示例性运力调度系统的框图；
图15A至图15D是根据本申请的一些实施例所示的用于基于聚类操作确定至少两个区域的示例性流程的示意图；
图16是根据本申请的一些实施例所示的可分配服务的数量与待分配的服务请求的比值和分配率之间的示例性关系的示意图；
图17是根据本申请的一些实施例所示的用于调度服务提供者的示例性流程的示意图；
图18是根据本申请的一些实施例所示的用于运力调度的示例性流程图；
图19是根据本申请的一些实施例所示的用于运力调度的示例性流程图；
图20是根据本申请的一些实施例所示的示例性服务请求分配装置的框图；
图21是根据本申请的一些实施例所示的示例性服务请求分配装置的框图；
图22是根据本申请的一些实施例所示的示例性服务请求分配模块的框图；
图23是根据本申请的一些实施例所示的示例性服务请求分配装置的框图；
图24是根据本申请的一些实施例所示的示例性服务请求分配装置的框图；
图25是根据本申请的一些实施例所示的示例性服务请求分配装置的框图；
图26是根据本申请的一些实施例所示的用于推送查找服务请求的信息的示例性装置的框图；
图27是根据本申请的一些实施例所示的示例性第一估算模块的框图；
图28是根据本申请的一些实施例所示的示例性估算单元的框图；
图29是根据本申请的一些实施例所示的示例性收益计算单元的框图；
图30是根据本申请的一些实施例所示的用于推送查找服务请求的推荐信息的示例性流程的示意图；
图31是根据本申请的一些实施例所示的用于推荐用于查找服务请求的信息的示例性装置的框图；
图32是根据本申请的一些实施例所示的用于运力调度的示例性流程图；
图33是根据本申请的一些实施例所示的用于运力调度的示例性流程图；
图34是根据本申请的一些实施例所示的示例性处理引擎的框图；
图35是根据本申请的一些实施例所示的用于运力调度的示例性流程图；以及
图36是根据本申请的一些实施例所示的用于确定目标半径和目标服务请求数的示例性流程图。
具体实施方式
下述描述是为了使本领域技术人员能制造和使用本申请，并且在特定的应用场景及其要求的背景下提供该描述。显而易见地，对于本领域的技术人员来说，可以对所披露的实施例作出各种修改，并且在不偏离本申请的原则和范围的情况下，本申请中所定义的普遍原则可以适用于其他实施例和应用场景。因此，本申请不限于所示的一些实施例，而是应被赋予与权利要求一致的最广泛的范围。
本申请中所使用的术语仅用于描述特定示例性实施例，并不限制本申请的范围。如本申请使用的单数形式“一”、“一个”及“该”可以同样包括复数形式，除非上下文明确提示例外情形。还应当理解，本申请中所使用的术语“包括”与“包含”仅提示已明确标识的特征、整体、步骤、操作、组件和/或部件，但并不排除存在或添加其他一个或以上特征、整体、步骤、操作、组件、部件和/或其组合的情况。
根据以下对附图的描述，本申请的这些特征和其他的特征、特点，以及相关结构组件的操作方法和功能，以及部件和制造经济性的组合更加显而易见，这些都构成说明书的一部分。然而，应当理解，附图仅仅是为了说明和描述的目的，并不旨在限制本申请的范围。应当理解的是，附图并不是按比例绘制的。
本申请中使用了流程图用来说明根据本申请的实施例的系统所执行的操作。应当理解的是，流程图中的操作可以不按顺序实施。相反，可以按照倒序或同时处理各种步骤。同时，也可以将一个或以上其他操作添加到这些流程图中。也可以从流程图中删除一个或以上操作。
此外，尽管本申请中披露的系统和方法主要是关于按需服务，但是还应该理解，这仅是一个示例性实施例。本申请的系统和方法可以应用于任何其他类型的按需服务。例如，本申请的系统和方法可以应用于不同的运输系统，包括陆地、海洋、航空航天等或其任意组合。所述运输系统涉及的交通工具可以包括出租车、私家车、顺风车、公交车、火车、动车、高铁、地铁、船舶、飞机、飞船、热气球、无人驾驶的车辆等或其任意组合。运输系统还可以包括应用管理和/或分配的任何运输系统，例如用于发送和/或接收快递的系统。本申请的系统和方法的应用场景可以包括网页、浏览器的插件、客户终端、定制系统、内部分析系统、人工智能机器人等或其任意组合。
本申请中的术语“乘客”、“请求者”、“请求方”、“服务请求者”、“服务请求方”和“客户”可互换使用，用于指代可以请求或订购服务的个人、实体或工具。此外，本申请中的术语“司机”、“提供者”、“服务提供者”和“供应者”可用于表示提供服务或协助提供服务的个人、实体或工具，并且可互换使用。本申请中的术语“用户”可用于表示请求服务、订购服务、提供服务或协助提供服务的个人、实体或工具。在本申请中，术语“请求者”和“请求者终端”可以互换使用，术语“提供者”和“提供者终端”可以互换使用。
本申请中的术语“请求”、“服务”、“服务请求”和“订单”可用于表示由乘客、请求者、服务请求者、顾客、司机、提供者、服务提供者、供应者等或其任意组合发起的请求，并且可互换使用。该服务请求可以被乘客、请求者、服务请求者、顾客、司机、提供者、服务提供者或供应者中的任一者接受。所述服务请求可以是收费的或免费的。
本申请中使用的定位技术可以包括全球定位系统(GPS)、全球卫星导航系统(GLONASS)、北斗导航系统(COMPASS)、伽利略定位系统、准天顶卫星系统(QZSS)、无线保真(WiFi)定位技术等或上述举例的任意组合。以上定位技术中的一个或以上可以在本申请中交换使用。
本申请的一个方面涉及用于与线上到线下服务相关联的运力调度的系统和方法。例如，系统可以确定目标区域，其中可用服务提供者的数量小于服务请求数。系统还可以基于目标区域的信息确定非忙碌区域，并且在非忙碌区域一个或以上可用服务提供者可以自由地接受服务请求。该系统也可以将调度指令发送到与非忙碌区域中的一个或以上可用服务提供者中的至少一个相关联的用户终端，其中可以包括询问与用户终端相关联的用户是否同意前往目标区域的信息。根据运力调度方法，系统可以将非忙碌区域中的可用服务提供者调度到忙碌区域(即目标区域)，这可以提高线上到线下服务的服务效率。
应该指出的是，在线按需服务，例如在线出租车服务，是一种仅在后互联网时代扎根的新形式的服务。它为使用者和服务提供者提供了仅在后互联网时代才可能实现的技术方案。在互联网时代之前，当乘客在街道上叫出租车时，出租车请求和接收仅发生在乘客和与该乘客见面的一辆出租车司机之间。假设乘客通过电话招呼一辆出租车，服务请求和接受可能仅发生在该乘客和一个服务提供者(例如，出租车公司或代理商)之间。然而，在线出租车允许用户实时地和自动地将服务请求分发到与该用户相距一段距离的大量的单个服务提供者(例如，出租车)。它同时允许至少两个服务提供者同时实时地对该服务请求进行响应。因此，通过因特网，按需服务系统可以为用户和服务提供者提供更有效的交易平台，而这些用户和服务提供者可能在传统的因特网前按需服务系统中从未遇到过。
图1是根据本申请的一些实施例所示的示例性按需服务系统的示意图。在一些实施例中，按需服务系统100可以是用于线上到线下服务的系统。例如，按需服务系统100可以是用于运输服务的在线运输服务平台，例如出租车、司机服务、运送车辆、拼车、公共汽车服务、司机雇佣和班车服务。按需服务系统100可以是包括服务器110、网络120、请求者终端130、提供者终端140和存储器150的平台。
在一些实施例中，服务器110可以是单一服务器或服务器组。该服务器组可以是集中式或分布式的(例如，服务器110可以是一分布式系统)。在一些实施例中，服务器110可以是本地的或远程的。例如，服务器110可通过网络120获取储存在请求者终端130、提供者终端140和/或存储器150内的信息和/或数据。又例如，服务器110可以连接请求者终端130、提供者终端140和/或存储器150，以访问存储的信息和/或数据。在一些实施例中，服务器110可以在云平台上实施。仅作为示例，所述云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多层云等或其任意组合。在一些实施例中，服务器110可以在本申请中的图2描述的包含了一个或以上组件的计算装置200上执行。
在一些实施例中，服务器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从提供者终端140接收GPS数据。在一些实施例中，网络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可以为用户D通过提供者终端140接收服务请求和/或从服务器110处接收信息或指令。在一些实施例中，“服务请求者”和“请求者终端”可以互换使用，“服务提供者”和“提供者终端”可以互换使用。
在一些实施例中，请求者终端130可以包括移动装置130-1、平板计算机130-2、膝上型计算机130-3、车载设备130-4等或其任意组合。在一些实施例中，移动装置130-1可以包括智能家居装置、可穿戴装置、智能移动装置、虚拟现实装置、增强现实装置等，或其任意组合。在一些实施例中，智能家居装置可以包括智能照明装置、智能电器控制装置、智能监控装置、智能电视、智能摄像机、对讲机等，或其任意组合。在一些实施例中，可穿戴装置可包括智能手环、智能鞋袜、智能眼镜、智能头盔、智能手表、智能服装、智能背包、智能配件等，或其组合。在一些实施例中，智能移动装置可以包括智能电话、个人数字助理(PDA)、游戏装置、导航装置、销售点(POS)等，或其任意组合。在一些实施例中，虚拟现实装置和/或增强型虚拟现实装置可以包括虚拟现实头盔、虚拟现实眼镜、虚拟现实补丁、增强型虚拟现实头盔、增强型虚拟现实眼镜、增强型虚拟现实补丁等，或其任意组合。例如，虚拟现实装置和/或增强现实装置可以包括Google GlassTM、RiftConTM、FragmentsTM、Gear VRTM等。在一些实施例中，车载设备130-4中的内置装置可包括车载计算机、车载电视等。在一些实施例中，请求者终端130可以是具有用来确定请求者和/或请求者终端130位置的定位技术的装置。
在一些实施例中，提供者终端140可以是与请求者终端130相似，或与请求者终端130相同的装置。在一些实施例中，提供者终端140可以是带有定位技术的装置，用于定位提供者和/或提供者终端140的位置。在一些实施例中，提供者终端140可以周期性地将GPS数据发送到服务器110。在一些实施例中，请求者终端130和/或提供者终端140可以与另一个定位装置通信以确定请求者、请求者终端130、提供者和/或提供者终端140的位置。在一些实施例中，请求者终端130和/或提供者终端140可以向服务器110传送定位信息。
存储器150可以存储数据和/或指令。在一些实施例中，数据存储器150可以储存从请求者终端130和/或提供者终端140处获取的数据。在一些实施例中，存储器150可以存储数据和/或指令，所述数据和/或指令可以由服务器110执行或用于执行本发明中描述的示例性方法。在一些实施例中，存储器150可以包括大容量存储器、可移动存储器、易失性读写存储器、只读存储器(ROM)等，或其组合。示例性的大容量储存器可以包括磁盘、光盘、固态驱动等。示例性可移动存储器可以包括闪存驱动器、软盘、光盘、存储卡、压缩盘、磁带等。示例性易失性读写存储器可以包括随机存取存储器(RAM)。示例性RAM可包括动态随机存取存储器(DRAM)、双倍数据速率同步动态随机存取存储器(DDR SDRAM)、静态随机存取存储器(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发出服务请求时，请求者终端130的处理器可以生成编码服务请求的电信号。然后，请求者终端130的处理器可以将电信号发送到输出端口。假设请求者终端130经由有线网络与服务器110通信，则输出端口可以物理地连接到电缆，该电缆还可以将电信号发送到服务器110的输入端口。假设请求者终端130经由无线网络与服务器110通信，则请求者终端130的输出端口可以是一个或以上天线，其可以将电信号转换为电磁信号。类似地，提供者终端140可以通过其处理器中的逻辑电路的操作来处理任务，并通过电信号或电磁信号从服务器110接收指令和/或服务请求。在电子装置中，如请求者终端130、提供者终端140和/或服务器110在其处理器流程指令发出指令和/或执行动作时，指令和/或者动作通过电信号进行。例如，当处理器从存储介质(例如，存储器150)检索或保存数据时，它可以将电信号发送到存储介质的读/写装置，该读/写装置可以在存储介质中读取或写入结构化数据。该结构数据可以通过电子装置的总线，以电信号的形式传输至处理器。这里，电信号是指一个电信号，一系列电信号和/或至少两个分立的电信号。
图2是根据本申请的一些实施例所示的计算装置200的示例性硬件和软件组件的示意图。在一些实施例中，服务器110、请求者终端130和/或提供者终端140可以是在计算装置200上执行。例如，处理引擎112可以在计算装置200上实施并执行本申请所披露的处理引擎112的功能。
计算装置200可以用来实现本申请所描述的按需服务系统100的任意组件。例如，处理引擎112可以在计算装置200上通过其硬件、软件程序、固件或其组合实现。图中为了方便起见只绘制了一台计算机，但是本实施例所描述的提供按需服务所需要的信息的相关计算机功能是可以以分布的方式、由一组相似的平台所实施的，分散系统的处理负荷。
计算装置200可以例如包括与网络相连接并促进数据通信的通信(COM)端口250。计算装置200还可以包括处理器(例如，处理器220)，其形式为一个或以上处理器(例如，逻辑电路)，用于执行程序指令。例如，处理器可以包括接口电路和其中的处理电路。接口电路可以被配置为从总线210接收电信号，其中电信号编码用于处理电路的结构化数据和/或指令。处理电路可以进行逻辑计算，然后将结论、结果和/或指令编码确定为电信号。然后，接口电路可以经由总线210从处理电路发出电信号。
计算装置200还可以包括不同形式的程序存储和数据存储，包括：例如，磁盘270、以及只读存储器(ROM)230或随机存取存储器(RAM)240，用于由计算装置处理和/或发送的各种数据文件。示例性计算装置也可以包括储存于ROM 230、RAM 240和/或其他形式的非暂时性存储介质中的能够被处理器220执行的程序指令。本申请的方法和/或流程可以以程序指令的方式实现。计算装置200还包括输入/输出端口组件260，支持计算机和其他组件之间的输入/输出。计算装置200也可以通过网络通信接收程序设计和数据。
仅用于说明，图2中仅示出了一个CPU和/或处理器。还可以考虑多个CPU和/或处理器；因此，由本申请中描述的由一个CPU和/或处理器执行的操作和/或方法操作也可以由多个CPU和/或处理器联合或单独执行。例如，假设在本申请中，计算装置200的CPU和/或处理器执行操作A和操作B，应当理解，操作A和操作B也可以由计算装置200中的两个不同的CPU和/或处理器联合或分开执行(例如，第一处理器执行操作A，第二处理器执行操作B，或者第一和第二处理器共同执行操作A和B)。
图3是根据本申请的一些实施例所示的移动装置300的示例性硬件和/或软件组件的示意图。在一些实施例中，请求者终端130或提供者终端140可以在移动装置300上实现。如图3所示，移动装置300可以包括通信模块310、显示器320、图形处理单元(GPU)330、中央处理单元(CPU)340、输入/输出端口350、内存360和存储器390。在一些实施例中，任何其他合适的组件，包括但不限于系统总线或控制器(未示出)，也可包括在移动装置300内。
在一些实施例中，移动操作系统370(如，iOSTM、AndroidTM、Windows PhoneTM等)和一个或多个应用程序380可以从存储器390加载到内存360中，以便由CPU 340执行。应用程序380可以包括浏览器或任何其他合适的移动应用程序，用于从按需服务系统100接收和呈现与按需服务或其他信息有关的信息。用户交互信息可以经由输入/输出350获取，并经由网络120提供给处理引擎112和/或按需服务系统100的其他组件。
为了实施本申请描述的各种模块、单元及其功能，计算机硬件平台可用作本申请中描述之一个或以上组件的硬件平台。具有用户接口组件的计算机可用于实施个人计算机(PC)或任何其他类型的工作站或终端装置。若程控得当，计算机亦可用作服务器。
图4是根据本申请的一些实施例所示的基于服务请求的分布用于运力调度的示例性流程图。流程400可以由按需服务系统100执行。例如，流程400可以为存储在存储ROM 230或RAM 240中的一组指令(例如，应用程序)实现。处理器220和/或图10-14中的模块和/或单元可以执行该组指令，当执行指令时，处理器220，模块和/或单元可以被配置以执行流程400。以下所示过程的操作仅出于说明的目的。在一些实施例中，流程400可以通过未描述的一个或多个以上附加操作和/或没有一个或以上所讨论的操作来完成。另外，如图4所示和下面描述的过程操作的顺序不是限制性的。
在410中，可以确定目标半径和目标服务请求数。
在420中，可以基于目标半径和目标服务请求数将区域划分为至少两个候选区域。
在430中，可以确定至少两个候选区域中的至少一个是否是健康。
在440中，可以基于确定至少两个候选区域中的至少一个是不健康的结果来确定调度指令。
在450中，可以基于至少两个候选区域中的至少一个来确定至少一个可用服务提供者。
在460中，可以基于调度指令将至少一个可用服务提供者调度到至少两个候选区域中的至少一个。
根据基于服务请求的分布的运力调度的方法，确定目标半径和目标服务请求数，根据该目标可以将区域划分为合理的区域。该区域可以基于目标半径和目标服务请求数，合理地被划分为至少两个候选区域。如本申请所用，“合理划分”是指至少两个候选区域的区域数量相对较大，每个候选区域中服务请求的数量相对较大，并且至少两个候选区域的分布相对均匀。应该指出的是，作为一个本领域的普通技术人员应当理解，这里使用的术语“相对”是指相应的参数大于或小于预设的阈值，例如，至少两个候选区域的区域数量大于第一预设阈值，每个候选区域中服务请求的数量大于第二预设阈值，并且至少两个候选区域的分布大于均匀性阈值。在确定至少两个候选区域之后，可以基于分配率和可用服务提供者的数量与要分配给至少两个候选区域中的至少一个的服务请求的数量的比值，确定是否至少两个候选区域中的一个是具有低分配率的不健康(或忙碌)区域以及可用服务提供者的数量与待分配的服务请求的数量不足的比值。根据至少两个候选区域中的至少一个是不健康区域的确定结果，可以确定调度指令，可以确定至少两个候选区域中的至少一个附近的至少一个可用服务提供者，并且可以将至少一个可用服务提供者调度到至少两个候选区域中的至少一个。根据本申请的一些实施例，可用服务提供者在服务要求较低的地区可以被调度到具有高请求密度和可用服务提供者的数量与待分配的服务请求的数量比值不足的区域。因此，可以确保运力调度的及时性和有效性，服务请求的分配率可能会增加，和服务提供者的经验可以得到改善。
应该注意的是，上述仅出于说明性目的而提供，并不旨在限制本申请的范围。对本领域普通技术人员而言，在本申请的指导下可以进行各种变化和修改。然而，变化和修改不会背离本申请的范围。
图5是根据本申请的一些实施例所示的基于服务请求的分布的用于运力调度的示例性流程图。流程500可以由按需服务系统100执行。例如，流程500可以为存储在存储ROM230或RAM 240中的一组指令(例如，应用程序)实现。处理器220和/或图10-14中的模块和/或单元可以执行该组指令，当执行指令时，处理器220，模块和/或单元可以被配置以执行流程500。以下所示过程的操作仅出于说明的目的。在一些实施例中，流程500可以通过未描述的一个或多个以上附加操作和/或没有所讨论的操作的一个或以上来完成。另外，如图5所示和下面描述的过程操作的顺序不是限制性的。
在510中，可以定义最大半径和最小服务请求数。
在520中，可以确定至少两个第一区域，至少两个第一区域中的每一个具有小于或等于最大半径的半径；在至少两个第一区域中可以确定至少两个第二区域，至少两个第二区域中的每一个中的服务请求数大于最小服务请求数。
在530中，可以根据预设等式，基于至少两个第二区域中的服务请求的总数量来确定分布熵。
在540中，可以将使分布熵最大化的服务请求数确定为服务请求的实际数量。
在550中，可以基于服务请求的实际数量来确定目标半径和目标服务请求数。
在560中，可以基于目标半径和目标服务请求数将该区域划分为至少两个候选区域。
在570中，可以确定至少两个候选区域中的至少一个是否是健康。
在580中，可以基于至少两个候选区域中的至少一个是不健康的确定结果来确定调度指令。
在590中，可以基于至少两个候选区域中的至少一个来确定至少一个可用服务提供者。
在5110中，可以基于调度指令将至少一个可用服务提供者调度到至少两个候选区域中的至少一个。
根据本申请的一些实施例，基于服务请求的分布的运力调度方法还可以包括以下技术特征。用于确定目标半径和目标服务请求数的操作可以包括以下操作。可以定义最大半径和最小服务请求数。可以确定至少两个第一区域，至少两个第一区域中的每一个具有小于或等于最大半径的半径。可以在至少两个第一区域中确定至少两个第二区域，至少两个第二区域中的每个区域中的服务请求数大于最小服务请求数。可以根据预设的等式，基于至少两个第二区域中的服务请求的总数量来确定分布熵。最大化分布熵的服务请求数可以被确定为服务请求的实际数量。目标半径和目标服务请求数可以基于服务请求的实际数量来确定。预设等式可表示如下：
Figure BDA0002306194830000281
其中，Er,m是指分布熵，Pi是指第二区域中服务请求的数量与至少两个第二区域中服务请求的总数量的比值，n表示至少两个第二区域的数量。
在一些实施例中，可以定义最大半径和最小服务请求数。在高峰时段，由于服务请求的数量相对较大，为了避免至少两个区域被自动合并，应适当减少最大半径，或者适当增加最小服务请求数。在非高峰时段，由于服务请求的数量相对较小且服务请求的分布相对分散，为避免将服务请求误认为噪声，应适当增加最大半径或适当减少最小服务请求数。在定义最大半径和最小服务请求数之后，可以确定至少两个第一区域，至少两个第一区域中的每一个具有小于或等于最大半径的半径。可以在至少两个第一区域中确定至少两个第二区域，至少两个第二区域中的每个区域中的服务请求数大于最小服务请求数。在至少两个第二区域中的服务请求的总数量可以通过在至少两个第二区域中添加至少两个数量的服务请求来确定，并且可以基于第二区域中的服务请求的总数量来确定分布熵，其中，服务请求的总数量是基于第二区域的数量和第二区域中的每一个的服务请求的数量来确定的。根据等式(1)，分布熵与至少两个第二区域的数量正相关；也就是说，簇的数量越大，分布熵越大，对应于簇的服务请求的分布越均匀，分布熵可能越大。最大化分布的服务请求可以被确定为服务请求和目标半径的实际数量，并且可以基于服务请求的实际数量来确定目标服务请求数。因此，可以确保每个划分区域中的服务请求数相对较大，并且划分区域的分布可以相对均匀，从而提高运力调度的准确性。
应该注意的是，上述仅出于说明性目的而提供，并不旨在限制本申请的范围。对本领域普通技术人员而言，在本申请的指导下可以进行各种变化和修改。然而，变化和修改不会背离本申请的范围。
图6是根据本申请的一些实施例所示的用于基于服务请求的分布的运力调度的示例性流程图。流程600可以由按需服务系统100执行。例如，流程600可以为存储在ROM 230或RAM 240中的一组指令(例如，应用程序)实现。处理器220和/或图10-14中的模块和/或单元可以执行该组指令，并且当执行指令时，处理器220，模块和/或单元可以被配置以执行流程600。以下所示过程的操作仅出于说明的目的。在一些实施例中，流程600可以通过未描述的一个或多个以上附加操作和/或没有一个或以上所讨论的操作来完成。另外，如图6所示和下面描述的过程操作的顺序不是限制性的。
在610中，可以定义最大半径和最小服务请求数；可以确定至少两个第一区域，至少两个第一区域中的每一个具有小于或等于最大半径的半径；在至少两个第一区域中可以确定至少两个第二区域，至少两个第二区域中的区域中的每一个的服务请求数大于最小服务请求数。
在620中，可以根据预设等式，基于至少两个第二区域中的服务请求的总数量来确定分布熵；确定使分布熵最大化的服务请求数作为服务请求的实际数量；并且可以基于服务请求的实际数量确定目标半径和目标服务请求数。
在630中，可以基于目标半径和目标服务请求数将该区域划分为至少两个候选区域。
在640中，可以确定至少两个候选区域中的至少一个的分配率以及在至少两个候选区域中的至少一个中分配的可用服务提供者的数量与待分配的服务请求数的比值。如本申请所用，区域的分配率是指服务提供者接受的服务请求的数量与在预设的时间段(例如，5分钟、10分钟)内在区域中发起的服务请求的总数量的比值。
在650中，可以确定分配率是否小于预设分配率。预设分配率可以是按需服务系统100的默认设置，或者可以在不同情况下是可调节的。例如，正如具有本领域普通技能的人所理解的，在高峰时段，预设分配率可以相对较小；正如具有本领域普通技能的人所理解的，在非高峰时段，预设分配率可以相对较大。
在660中，可以基于确定分配率小于预设分配率的结果来确定至少两个候选区域中的至少一个的估算分配率；并且可以基于估算的分配率来确定可用服务提供者的数量与待分配的服务请求数的估算比值。
在670，可以确定可用服务提供者数量与待分配的服务请求数的比值是否小于可用服务提供数量与待分配服务请求数的估算比值。
在680中，基于确定的结果，即可用服务提供者数量与待分配服务请求数量的比值小于可用服务提供者数量与待分配服务请求数的估算比值，可以将至少两个候选区域中的至少一个确定为不健康或忙碌(即，至少两个候选区域中的至少一个可以被确定为目标区域)；并且可以确定调度指令。
在690中，可以基于至少两个候选区域中的至少一个来确定至少一个可用服务提供者。
在6110中，可以基于调度指令将至少一个可用服务提供者调度到至少两个候选区域中的至少一个。
在一些实施例中，可以确定所述至少两个候选区域中的至少一个的分配率和所述至少两个候选区域中的至少一个可用服务提供者数量与待分配服务请求的数量的比值。假设分配率低于预设的分配率；也就是说，分配率相对较低，可以确定至少两个候选区域中的至少一个的估算分配率。可以基于估算的分配率确定可用服务提供者数量与待分配的服务请求的数量的估算比值，其中，可用服务提供者数量与待分配的服务请求的数量的估算比值可以是估算的分配率的线性函数。例如，线性函数可以表示为下面的等式(2)：
Y＝a×X+b (2)
其中Y指可用服务提供者的数量与待分配的服务请求数的估算比值，X指的是估算的分配率，根据图16所示的线性回归过程，可以根据样本获取a和b。此外，可以确定可用服务提供者数量与待分配的服务请求数的比值是否小于可用服务提供者数量与待分配服务请求数的估算比值。基于确定的结果，即可用服务提供者的数量与待分配的服务请求数的比值小于可用服务提供者的数量与待分配服务请求数的估算比值，至少两个候选区域中的至少一个可以被确定为不健康的。可用服务提供者可以被调度到至少两个候选区域中的至少一个。因此，可以改善至少两个候选区域中的至少一个中的线上出租车服务的成功率和接收服务请求的成功率。
应该注意的是，上述仅出于说明性目的而提供，并不旨在限制本申请的范围。对本领域普通技术人员而言，在本申请的指导下可以进行各种变化和修改。然而，变化和修改不会背离本申请的范围。
图7是根据本申请的一些实施例所示的基于服务请求的分布的运力调度的示例性流程图。流程700可以由按需服务系统100执行。例如，流程700可以为存储在存储ROM 230或RAM 240中的一组指令(例如，应用程序)实现。处理器220和/或图10-14中的模块和/或单元可以执行该组指令，当执行指令时，处理器220，模块和/或单元可以被配置以执行流程700。以下所示过程的操作仅出于说明的目的。在一些实施例中，流程700可以通过未描述和/或没有一个或以上所讨论的操作的一个或以上附加操作来完成。另外，如图7所示和下面描述的过程操作的顺序不是限制性的。
在710中，可以定义最大半径和最小服务请求数；可以确定至少两个第一区域，至少两个第一区域中的每个具有小于或等于最大半径的半径；在至少两个第一区域中可以确定至少两个第二区域，至少两个第二区域中的每个区域中的服务请求数大于最小服务请求数。
在720中，可以根据预设等式，基于至少两个第二区域中的服务请求的总数量来确定分布熵；最大化分布熵的服务请求数可以确定为服务请求的实际数量；并且可以基于服务请求的实际数量来确定目标半径和目标服务请求数。
在730中，可以基于目标半径和目标服务请求数将该区域划分为至少两个候选区域。
在740中，可以确定所述至少两个候选区域中的至少一个的分配率和所述至少两个候选区域中的至少一个中的可用服务提供者的数量与待分配的服务请求的数量的比值。
在750中，可以确定分配率是否小于预设分配率。
在760中，可以基于确定分配率小于预设分配率的结果来确定至少两个候选区域中的至少一个的估算分配率；并且可以基于估算的分配率来确定可用服务提供者的数量与待分配的服务请求数的估算比值。
在770中，可以确定可用服务提供者的数量与待分配的服务请求数的比值是否小于可用服务提供者的数量与待分配服务请求数的估算比值。
在780中，基于确定的结果，即可用服务提供者的数量与待分配的服务请求数的比值小于可用服务者的数量与待分配的服务请求数的估算比值，至少两个候选区域中的至少一个可被确定为不健康(或忙碌)；并且可以确定调度指令。
在790中，可以确定至少两个候选区域中的至少一个的矩形边界；可以通过从矩形边界扩展区域来确定新的矩形边界；区域服务提供者可以确定矩形边界和新矩形边界之间的区别；并且可以将满足预设条件的服务提供者中的至少一个确定为至少一个可用服务提供者。
在7110中，可以基于调度指令将至少一个可用服务提供者调度到至少两个候选区域中的至少一个。
在一些实施例中，可以根据边界确定过程来确定至少两个候选区域中的至少一个的矩形边界。根据边界的确定过程，可以确定至少两个候选区域中的至少一个中的服务请求的起始位置的最大纬度和经度(maxlng、maxlat)和最小纬度和经度(minlng、minlat)，并且区域的边界可以基于由以下四个点表示的矩形来确定，包括(最大纬度，最大经度)、(最大纬度，最小经度)、(最小纬度，最小经度)、(最小纬度，最大经度)。可以通过从矩形边界扩展区域来确定新的矩形边界，其指的是将四个点扩展预设值，分别确定四个新点，并且基于由四个新点表示的矩形确定新的矩形边界。可以确定矩形边界和新矩形边界之间的区域差异。区域差异可以是矩形边界和新矩形边界之间的同心方形区域。可以将满足预设条件的区域差异中的服务提供者中的至少一个确定为至少一个可用服务提供者，其中，预设条件是服务提供者的数量在服务提供者中的至少一个的位置的第一预设范围内小于第一预设服务请求数量并且服务提供者中的至少一个的位置不在具有高服务请求密度的区域中。因此，可以确定服务请求数相对较小且靠近目标调度区域的服务提供者，确保运力调度的有效性和合理性。因此，可以实现可用服务提供者的数量对待分配的服务请求数的更好的供需效果。
应该注意的是，上述仅出于说明性目的而提供，并不旨在限制本申请的范围。对本领域普通技术人员而言，在本申请的指导下可以进行各种变化和修改。然而，变化和修改不会背离本申请的范围。
图8是根据本申请的一些实施例所示的用于基于服务请求的分布的用于运力调度的示例性流程图。流程800可以由按需服务系统100执行。例如，流程800可以为存储在存储ROM 230或RAM 240中的一组指令(例如，应用程序)实现。处理器220和/或图10-14中的模块和/或单元可以执行指令集，并且当执行指令时，处理器220、模块和/或单元可以被配置用于执行流程800。以下所示过程的操作仅出于说明的目的。在一些实施例中，流程800可以通过未描述的一个或多个以上附加操作和/或没有所讨论的操作的一个或以上来完成。另外，如图8所示和下面描述的过程操作的顺序不是限制性的。
在810中，可以定义最大半径和最小服务请求数；可以确定至少两个第一区域，至少两个第一区域中的每一个具有小于或等于最大半径的半径；在至少两个第一区域中可以确定至少两个第二区域，至少两个第二区域中的每个区域中的服务请求数大于最小服务请求数。
在820中，可以根据预设等式，基于至少两个第二区域中的服务请求的总数量来确定分布熵；最大化分布熵的服务请求数可以确定为服务请求的实际数量；并且可以基于服务请求的实际数量来确定目标半径和目标服务请求数。
在830中，可以基于目标半径和目标服务请求数将该区域划分为至少两个候选区域。
在840中，可以确定所述至少两个候选区域中的至少一个的分配率和所述至少两个候选区域中的至少一个的可用服务提供者的数量与待分配的服务请求的数量的比值。
在850中，可以确定分配率是否小于预设分配率。
在860中，可以基于确定分配率小于预设分配率的结果来确定至少两个候选区域中的至少一个的估算分配率；并且可以基于估算的分配率来确定可用服务提供者的数量与待分配的服务请求数的估算比值。
在870中，可以确定可用服务提供者数量与待分配服务请求数的比值是否小于可用服务提供者的数量与待分配服务请求数的估算比值。
在880中，基于确定的结果，即可用服务提供者的数量与待分配的服务请求数的比值小于可用服务提供者的数量与待分配服务请求数的估算比值，确定至少两个候选区域中的至少一个是不健康(或忙碌)；并且可以确定调度指令。
在890中，可以确定至少两个候选区域中的至少一个的矩形边界；可以通过从矩形边界扩展区域来确定新的矩形边界；可以在矩形边界和新矩形边界之间区域差异确定服务提供者；并且可以将满足预设条件的服务提供者中的至少一个确定为至少一个可用服务提供者。
在8110中，可以确定至少两个候选区域中的至少一个中的核心位置(也称为“调度位置”)，其中，在核心位置的第二预设范围内的服务请求的数量大于第二预设服务请求数量；可以获取核心位置的地址信息；并且可以基于核心位置的地址信息和调度指令将至少一个可用服务提供者调度到核心位置。
在一些实施例中，由于至少两个候选区域中的至少一个(即，具有高服务请求密度的区域)相对较大，因此在确定了至少一个可用服务提供者之后，将至少一个可用服务提供者调度到最靠近至少一个可用服务提供者的核心位置是合适的。如这里所使用的，核心位置指的是在距离该位置的预设范围内的服务请求的数量不小于预设的服务请求的位置。可以获取至少两个核心位置的地址信息，并且可以将至少一个可用服务提供者调度到最靠近可用服务提供者的核心位置。因此，可以将服务提供者快速调度到具有高服务请求密度的区域，并且可以提高可用服务提供者的接收率。
应该注意的是，上述仅出于说明性目的而提供，并不旨在限制本申请的范围。对本领域普通技术人员而言，在本申请的指导下可以进行各种变化和修改。然而，变化和修改不会背离本申请的范围。
图9是根据本申请的一些实施例所示的用于基于服务请求的分布的用于运力调度的示例性流程图。流程900可以由按需服务系统100执行。例如，流程900可以为存储在存储ROM 230或RAM 240中的一组指令(例如，应用程序)实现。处理器220和/或图10-14中的模块和/或单元可以执行指令集，并且当执行指令时，处理器220，模块和/或单元可以被配置用于执行流程900。以下所示过程的操作仅出于说明的目的。在一些实施例中，流程900可以通过未描述的一个或多个以上附加操作和/或没有一个或以上所讨论的操作来完成。另外，如图9所示和下面描述的过程操作的顺序不是限制性的。
在905中，可以定义最大半径和最小服务请求数；可以确定至少两个第一区域，至少两个第一区域中的每一个具有小于或等于最大半径的半径；在至少两个第一区域中可以确定至少两个第二区域，并且至少两个第二区域中的每个区域中的服务请求数大于最小服务请求数。
在910中，可以根据预设等式，基于至少两个第二区域中的服务请求的总数量来确定分布熵；最大化分布熵的服务请求数可以确定为服务请求的实际数量；并且可以基于服务请求的实际数量来确定目标半径和目标服务请求数。
在915中，可以基于目标半径和目标服务请求数将该区域划分为至少两个候选区域。
在920中，可以确定所述至少两个候选区域中的至少一个的分配率和所述至少两个候选区域中的至少一个可用服务提供者数量与待分配服务请求的数量的比值。
在925中，可以确定分配率是否小于预设分配率。
在930中，可以基于确定分配率小于预设分配率的结果来确定至少两个候选区域中的至少一个的估算分配率；并且可以基于估算的分配率，确定可用服务提供者数与待分配的服务请求数的估算比值。
在935中，可以确定可用服务提供者的数量与待分配服务请求数的比值是否小于可用服务提供者的数量与待分配服务请求数的估算比值。
在940中，基于确定的结果，即可用服务提供者的数量与待分配的服务请求数的比值小于可用服务提供者的数量与待分配的服务请求数的估算比值，至少两个候选区域中的至少一个可被确定为不健康(或忙碌)；并且可以确定调度指令。
在945中，可以确定至少两个候选区域中的至少一个的矩形边界；可以通过从矩形边界扩展区域来确定新的矩形边界；可以矩形边界和新矩形边界之间区域差异中确定服务提供者；并且可以将满足预设条件的服务提供者中的至少一个确定为至少一个可用服务提供者。
在950中，可以确定至少两个候选区域中的至少一个中的核心位置，其中，在核心位置的第二预设范围内的服务请求的数量大于第二预设服务请求数量。
在955中，可以获取核心位置的纬度和经度；并且可以基于核心位置的纬度和经度来确定核心位置的地址信息。
在950中，可以基于核心位置的地址信息和调度指令将至少一个可用服务提供者调度到核心位置。核心位置的地址信息可以包括区、街道和商业区。
在一些实施例中，可以基于核心位置的纬度和经度来确定核心位置的地址信息，并且核心位置的地址信息包括区、街道和商业区。因此，至少一个可用服务提供者可以快速到达核心位置，可以提高运力调度的效率，可以保证服务提供者中的至少一个可用的到达时间，并且用户可以及时使用运输服务。
应该注意的是，上述仅出于说明性目的而提供，并不旨在限制本申请的范围。对本领域普通技术人员而言，在本申请的指导下可以进行各种变化和修改。然而，变化和修改不会背离本申请的范围。
图10是根据本申请的一些实施例所示的示例性运力调度系统的框图。运力调度系统1000可以包括确定模块1010、划分模块1020、判断模块1030、启动模块1040、服务提供者确定模块1050和调度模块1060。在一些实施例中，运力调度系统1000可以集成到服务器110中。例如，运力调度系统1000可以是处理引擎112的一部分。
确定模块1010可以被配置用于确定目标半径和目标服务请求数。
划分模块1020可以被配置为基于目标半径和目标服务请求数将区域划分为至少两个候选区域。
判断模块1030可以被配置用于确定至少两个候选区域中的至少一个是否是健康。
启动模块1040可以被配置用于基于确定至少两个候选区域中的至少一个是不健康的结果来确定调度指令。
服务提供者确定模块1050可以被配置用于基于至少两个候选区域中的至少一个来确定至少一个可用服务提供者。
调度模块1060可以被配置为基于调度指令将至少一个可用服务提供者调度到至少两个候选区域中的至少一个。
根据一些实施例中所示的运力调度系统1000，确定模块1010可以确定目标半径和目标服务请求数，根据该目标半径和目标服务请求数可以将区域划分为合理的区域。划分模块1020可以基于目标半径和目标服务请求数，合理地将该区域划分为至少两个候选区域。如本申请所用，“合理划分”是指至少两个候选区域的区域数量相对较大，每个候选区域中服务请求的数量相对较大，并且至少两个候选区域的分布相对均匀。在确定至少两个候选区域之后，判断模块1030可以基于至少两个候选区域中的至少一个的分配率和可用服务提供者的数量与待分配服务请求数的比值，确定至少两个候选区域中的至少一个是否是具有低分配率以及可用服务提供者的数量与待分配的服务请求的数量不足的比值的不健康(或忙碌)区域。根据确定至少两个候选区域中的至少一个是不健康区域的结果，启动模块1040可以确定调度指令，服务提供者确定模块1050可以确定至少两个候选区域中的至少一个中的至少一个可用服务提供者，调度模块1060可以将至少一个可用服务提供者调度到至少两个候选区域中的至少一个。根据本申请的一些实施例，可以将在服务请求密度较低的地区中的可用服务提供者调度到服务请求密度较高和可用服务提供者的数量与服务请求数的比值不足的区域。因此，可以确保运力调度的及时性和有效性，可以增加服务请求的分配率，并且可以改善服务提供者的经验。
运力调度系统1000中的模块可以通过有线连接或无线连接彼此连接或通信。有线连接可包括金属电缆、光学电缆、混合电缆等或其任意组合。无线连接可以包括局域网络(LAN)、广域网(WAN)、蓝牙、紫蜂(ZigBee)网络、近场通信(NFC)等或其任意组合。两个或以上模块可以合并成一个模块，以及任意一个模块可以被拆分成两个或以上单元。
图11是根据本申请的一些实施例所示的示例性运力调度系统的框图。如图所示，运力调度系统1100中的模块与运力调度系统1000中的模块相同。为简洁起见，这里省略了对模块的描述。此外，确定模块1010可以包括定义单元1112、簇判断单元1114和第一计算单元1116。在一些实施例中，运力调度系统1100可以集成到服务器110中。例如，运力调度系统1100可以是处理引擎112的一部分。
定义单元1112可以被配置为定义最大半径和最小服务请求数。
簇判断单元1114可以被配置用于确定至少两个第一区域，每个至少两个第一区域具有小于或等于最大半径的半径；并且确定至少两个第一区域中的至少两个第二区域，至少两个第二区域中的每个区域中的服务请求数大于最小服务请求数。
第一计算单元1116可以被配置用于根据预设等式基于至少两个第二区域中的服务请求的总数量来确定分布熵；并确定最大化分布熵的服务请求数作为服务请求的实际数量。此外，确定模块1010可以根据等式(1)基于服务请求的实际数量来确定目标半径和目标服务请求数。
在一些实施例中，定义单元1112可以确定最大半径和最小服务请求数。在高峰时段，由于服务请求的数量比较大，为了避免至少两个区域被自动合并，应适当减少最大半径，或者应适当增加最小服务请求数。在非高峰时段，由于服务请求的数量相对较小且服务请求的分布相对分散，为避免将服务请求误认为噪声，应适当增加最大半径或适当减少最小服务请求数。在定义了最大半径和最小服务请求数之后，簇判断单元1114可以确定至少两个第一区域，至少两个第一区域中的每一个具有小于或等于最大半径的半径。簇判断单元1114还可以确定至少两个第一区域中的至少两个第二区域，至少两个第二区域中的每个区域中的服务请求数大于最小服务请求数。第一计算单元1116可以通过在至少两个第二区域中添加的至少两个数量的服务请求来确定至少两个第二区域中的服务请求的总数量，并根据第二区域服务请求的总数量确定分布熵，其中，服务请求的总数量是基于第二区域的数量和第二区域中的每一个中的服务请求的数量来确定的。根据等式(1)，分布熵与至少两个第二区域的数量正相关；也就是说，聚类的数量越大，分布熵可能越大，并且对应于聚类的服务请求的分布越均匀，分布熵可能越大。确定模块1010可以确定最大化分布熵的一个服务请求数，作为目标半径和服务请求的实际数量，并根据服务请求的实际数量确定目标服务请求数。因此，可以确保每个划分区域中的服务请求数相对较大，并且划分区域的分布可以相对均匀，从而提高运力调度的准确度。
图12是根据本申请的一些实施例所示的示例性运力调度系统的框图。如图所示，运力调度系统1200中的模块与运力调度系统1000或1100中的模块相同。为简洁起见，这里省略了对模块的描述。此外，判断模块1030可以包括获取单元1232和设置单元1234。在一些实施例中，运力调度系统1200可以集成到服务器110中。例如，运力调度系统1200可以是处理引擎112的一部分。
获取单元1232可以被配置用于确定至少两个候选区域中的至少一个的分配率以及在至少两个候选区域中的至少一个可用服务提供者的数量与待分配服务请求的数量之比。
设置单元1234可以被配置用于确定至少两个候选区域中的至少一个的估算分配率，以确定至少两个候选区域中的至少一个的分配率小于预设分配率。基于至少两个候选区域中的至少一个的估算分配率，获取单元1232可以进一步被配置用于确定可用服务提供者的数量与待分配的服务请求数的估算比值。
在一些实施例中，获取单元1232可以确定至少两个候选区域中的至少一个的分配率和至少两个候选区域中的至少一个的可用服务提供者的数量与待分配的服务请求数的比值。假设分配率低于预设的分配率；也就是说，分配率相对较低，设置单元1234可以确定至少两个候选区域中的至少一个的估算分配率。获取单元1232可以基于估算的分配率确定可用服务提供者的数量与待分配的服务请求的数量的估算比值，其中，可用服务提供者的数量与待分配的服务请求的数量的估算比值可以是估算的分配率的线性函数。判断模块1030可以确定可用服务提供者数量与待分配服务请求数的比值是否小于可用服务提供者的数量与待分配服务请求数的估算比值。基于确定的结果，即可用服务提供者的数量与待分配服务请求数的比值小于可用服务提供者的数量与待分配服务请求数的估算比值，判断模块1030可以确定至少两个候选区域中的至少一个是不健康的。可用服务提供者可以被调度到至少两个候选区域中的至少一个。因此，可以改善至少两个候选区域中的至少一个中的线上出租车服务的成功率和接收服务请求的成功率。
图13是根据本申请的一些实施例所示的示例性运力调度系统的框图。如图所示，运力调度系统1300中的模块与运力调度系统1000、1100和/或1200中的模块相同。为简洁起见，这里省略了对模块的描述。此外，服务提供者确定模块1050可以包括第二计算单元1352和服务提供者确定单元1354。在一些实施例中，运力调度系统1300可以集成到服务器110中。例如，运力调度系统1300可以是处理引擎112的一部分。
第二计算单元1352可以被配置用于确定至少两个候选区域中的至少一个的矩形边界。
服务提供者确定单元1354可以被配置为通过从矩形边界扩展区域来确定新的矩形边界；在矩形边界和新矩形边界之间的区域差异中确定服务提供者；确定满足预设条件的服务提供者中的至少一个作为至少一个可用服务提供者，其中，预设条件是在服务提供者中的至少一个的位置的第一预设范围内的服务请求数小于第一预设服务请求数，并且服务提供者中的至少一个的位置不在具有高请求密度的区域中。
在一些实施例中，第二计算单元1352可以根据边界确定方法确定至少两个候选区域中的至少一个的矩形边界。根据边界的确定方法，可以确定至少两个候选区域中的至少一个中的服务请求的起始位置的最大纬度和经度(maxlng，maxlat)和最小纬度和经度(minlng，minlat)，并且区域的边界可以基于由以下四个点表示的矩形来确定，包括(最大纬度，最大经度)、(最大纬度，最小经度)、(最小纬度，最大经度)、(最小纬度，最小经度)。一个新的矩形边界可以通过从矩形边界扩展区域来确定，该区域是指将四个点扩展预设值，分别确定四个新点，并基于由四个新点表示的矩形确定新的矩形边界。服务提供者确定单元1354可以确定矩形边界和新矩形边界之间的区域差异。区域差异可以是矩形边界和新矩形边界之间的同心方形区域。服务提供者确定单元1354可以确定满足预设条件的区域差异中的服务提供者中的至少一个作为至少一个可用服务提供者，其中，预设条件是服务提供者的数量在服务提供者中的至少一个的位置的第一预设范围内小于第一预设服务请求数量并且服务提供者中的至少一个的位置不在具有高服务请求密度的区域中。因此，可以确定服务请求数相对较小且靠近目标调度区域的服务提供者，从而确保运力调度的有效性和合理性。因此，可以实现可用服务提供者的数量对待分配的服务请求的更好的供需效果。
图14是根据本申请的一些实施例所示的示例性运力调度系统的框图。如图所示，运力调度系统1400中的模块与运力调度系统1000、1100、1200和/或1300中的模块相同。为简洁起见，这里省略了对模块的描述。此外，调度模块1060可以包括核心位置确定单元1462和地址信息获取单元1464。在一些实施例中，运力调度系统1400可以集成到服务器110中。例如，运力调度系统1400可以是处理引擎112的一部分。
核心位置确定单元1462可以被配置用于确定至少两个候选区域中的至少一个的核心位置，其中，在核心位置的第二预设范围内的服务请求的数量大于第二预设服务请求数量。
地址信息获取单元1464可以被配置为获取核心位置的地址信息。
在一些实施例中，由于至少两个候选区域中的至少一个(即，具有高服务请求密度的区域)相对较大，在确定至少一个可用服务提供者之后，核心位置确定单元1462应该将至少一个可用服务提供者调度到最靠近至少一个可用服务提供者的核心位置。如本文所述，核心位置是指在距离该位置的预设范围内服务请求的数量不小于预设服务请求数的位置。地址信息获取单元1464可以获取至少两个核心位置的地址信息。调度模块1060可以将至少一个可用服务提供者调度到最接近可用服务提供者的核心位置。因此，可以将服务提供者快速调度到具有高服务请求密度的区域，并且可以提高可用服务提供者的接收率。
在一些实施例中，地址信息获取单元1464可以具体配置用于获取核心位置的纬度和经度，并根据核心位置的纬度和经度确定核心位置的地址信息。如这里所使用的，核心位置的地址信息可以包括区、街道和商业区。
本申请的一些实施例可以采取在一个或以上计算机可读介质中体现的计算机程序产品的形式，该计算机可读介质具有包含在其上的计算机可读程序代码。例如，计算机可读存储介质可以包括但不限于磁盘存储器、CD-ROM和光学存储器。
本申请还可以提供包括第一指令的第一计算机存储介质。当由至少一个处理器执行时，第一指令可以表明至少一个处理器执行本申请中其他地方描述的过程(例如，流程400、流程500、流程600、流程700、流程800、流程900)。
基于根据本申请的一些实施例的聚类操作，图15A至图15D示出确定至少两个区域的示意图。根据一些实施例的运力调度方法可包括以下操作。
1.合理确定区域的区域粒度。
根据Dbscan算法，应该定义最大半径r和最小服务请求数m，并且可以基于这两个参数执行聚类操作。在聚类操作期间，可以自动合并彼此相对接近的相邻区域，并且可以自动识别噪声。如图15A-15D所示，可以选择不同的最大半径r、不同的最小服务请求数m和不同时间段t的服务请求，并且可以确定不同的聚类结果。图15A示出了在“r＝1500米、m＝5、t＝08：00至08：10”的条件下的聚类结果。图15B示出了在“r＝1000米、m＝5、t＝08：00至08：10”的条件下的聚类结果。图15C示出了在“r＝1000米、m＝5、t＝06：36至06：46”的条件下的聚类结果。图15D示出了在“r＝1800米、m＝4、t＝06：36至06：46”的条件下的聚类结果。
比较图15A至图15D，可以看出，当时间段从08：00到08：10的城市中的服务请求为400时，图15B中所示的聚类结果优于图15A中所示的聚类结果。如图15A所示，整个中间区域被确定为簇，而如图15B所示，尽管丢弃点的数量相对较大，但区域粒度相对优于图15A所示。此外，还可以看出，当时间段从06：36到06：46的城市服务请求的数量是167，图15D中所示的聚类结果明显优于图15C中所示的结果。
根据图15A至图15D所示的四种情况，可以看出，由于服务请求的数量在高峰时段相对较大，为了避免至少两个地区自动合并，应适当减少最大半径r或增加最小服务请求数m。由于服务请求的数量相对较小，服务请求的分布在非高峰时段相对分散，为了避免某些服务请求被误认为是噪音，应适当增加最大半径r或适当减少最小服务请求数m。
考虑到业务需求，不同城市的服务请求和区域分布是完全不同的。即使对于特定的城市，服务请求和不同时间段的区域分布也是完全不同的。因此，对于特定城市中的不同城市或不同时间段，需要单独定义Dbscan算法的两个参数r和m。因此，尽管Dbscan算法是无监督的学习算法，但是在不同情况下选择适当的r和m成为基于历史数据的监督学习过程。
估算的群集分布应满足以下目标：
目标1：每个簇中包含的服务请求数不应太小；
目标2：簇的数量不应太小；以及
目标3：至少两个簇的分布应尽可能均匀。
根据这三个目标，图15B和图15D中所示的聚类结果相对较好，并且图15A和图15C中所示的聚类结果相对较差。根据目标1，每个簇中包含的服务请求的数量不应太小。因此，可以为m设置最小值。假设最小值为5，每个簇的最小服务请求数大于5。否则，服务请求可能被识别为噪音。此外，可以考虑与服务请求分配相关联的广播距离。因此，r的最大值不应超过2000米。如这里所使用的，术语“广播距离”指的是距服务请求的起始位置的距离范围，并且服务请求可以被分配给距离范围内的可用服务提供者。
为了评估目标2和目标3，这里介绍了分布熵的概念。分布熵的定义是，对于给定的r和给定的m，在城市中的某个时间段，基于Dbscan算法确定的簇的分布可以表示为等式(1)。根据等式(1)，可以看出Er,m∈[0,logn](即Er,m与n正相关)；也就是说，聚类的数量越多，分布熵可能越大；簇中服务请求的分布越均匀，分布熵可能越大，这与目标2和目标3一致。因此，模型成为一个如下优化问题：
Figure BDA0002306194830000491
其中f(c)或g(c)是线性函数或非线性函数，它们可分别表示为下面的等式(4)和等式(5)：
Figure BDA0002306194830000501
其中c是常数，可以是按需服务系统100的默认设置，或者可以在不同情况下调整，根据目标下的线性回归，可以基于样本数据确定a1、b1、a2和b2。
此外，可以根据以下过程验证模型。如图所示，表1显示了图15A所示情况下的样本数据，表2显示了图15B所示情况下的样本数据，表3显示了图15C所示情况下的样本数据，表4显示了图15D所示情况下的样本数据。
表1
群集序列号 服务请求 服务请求(Pi)的比值
1 39 0.117117
2 257 0.771772
9 9 0.027027
16 8 0.024024
24 6 0.018018
36 8 0.024024
59 6 0.018018
表2
Figure BDA0002306194830000511
表3
群集序列号 服务请求 服务请求(Pi)的比值
12 5 0.121951
23 8 0.195122
26 5 0.121951
31 13 0.317073
75 5 0.121951
91 5 0.121951
表4
Figure BDA0002306194830000512
Figure BDA0002306194830000521
可以确定图15A-15D中所示的聚类结果的分布熵。图15A中所示的聚类结果的分布熵可被确定为Er,m1＝0.26988，并且图15B中所示的聚类结果的分布熵可以被确定为Er,m2＝1.14058。根据分布熵，
Er,m2>Er,m1，这与图15B中所示的聚类结果优于图15A中所示的聚类结果的预期一致。图15C中所示的聚类结果的分布熵可被确定为Er,m3＝0.74241，并且图15D中所示的聚类结果的分布熵可以确定为Er,m4＝0.97075。根据分布熵，Er,m4>Er,m3，这与图15D中所示的聚类结果优于图15C中所示的聚类结果的预期一致。
此外，可以看出Er,m2>Er,m4>Er,m3>Er,m1，因此，服务请求的数量越大，簇的数量越大，簇的分布越均匀，分布熵可能越大。如图15C和图15D所示，群集的分布都相对均匀，但是图15D中所示的聚类结果起比图15C所示的召回更多的点，因此，图15D中所示的簇的数量相对较大。如图15A所示，合并至少两个簇，导致簇的数量相对较小。簇的分布也是不均匀的，因此分布熵最低。
2.确定区域是否为健康的标准。
确定区域是否为健康的标准可以包括分配率和可用服务提供者的数量与待分配的服务请求的数量之比。分配率和可用服务提供者的数量与待分配的服务请求数的比值满足线性关系。对于分配率低的区域，可以确定估算的分配率，可以根据等式(2)确定可用服务提供者的数量与待分配的服务请求数的估算比值，然后，可以将可用服务提供者的数量与待分配的服务请求数的估算比值与可用服务提供者的数量与待分配的服务请求数的当前比值进行比较。此外，可以基于确定的结果来确定调度指令，即可用服务提供者的数量与待分配的服务请求数的比值在一定程度上是不足的。
如本文所用，术语“在一定程度上不足”是指可用服务提供者的数量与待分配的服务请求的数量之差的绝对值，并且可用服务提供者的数量与待分配的服务请求的数量的估算比值大于阈值。根据线性关系，将图15B所示的情况与图15D所示的情况进行比较。对于图15B所示的情况，时间段(8：00至8：10)在早高峰时段内；可以看出，分配率相对较低，且可用服务提供者的数量与待分配的服务请求的数量比值严重不足。表5示出了服务请求相对较大的三个区域，分配率非常低，可用服务提供者的数量与待分配的服务请求的数量的比值明显不足；也就是说，这三个区域严重不健康，并且可以执行用于将服务提供者调度到三个区域的运力调度。
表5
Figure BDA0002306194830000541
对于图15D所示的情况，时间段(6：36到6：46)处于相对非高峰时段，对于服务请求数相对较大的地区，分配率非常低，并且可用服务提供者的数量与待分配的服务请求数量的比值不足，可以对三个地区的服务提供者进行调度的运力调度。表6示出了从表4中所示的区域中选择的四个区域，其中可以执行运力调度。对于表4中所示的簇5，由于分配率是可以接受的，并且可用服务提供者的数量与待分配的服务请求数量的比值相对较高，可以不执行用于将服务提供者调度到对应于簇5的区域的运力调度。
表6
Figure BDA0002306194830000551
考虑到图15B和图15D中所示的上述情况，可以概括的是，可以执行运力调度的区域可以满足以下特征：
特征1：区域中的服务请求数比较大(在服务请求低的情况下，即使服务提供者被调度到区域，服务提供者也可能无法接收服务请求)；也就是说，服务请求数大于服务请求阈值；
特征2：区域的分配率相对较低(这是核心调度目标之一)；也就是说，分配率低于分配率阈值；以及
特征3：区域中可用服务提供者的数与服务请求数的比值不足(可以根据运力调度来解决，如果可用服务提供者的数量与待分配的服务请求数的比值足够，运力调度在某种程度上是无用的)；也就是说，可用服务提供者的数量与待分配的服务请求数的比值低于预设的比值。
对于不同的城市和不同的时间段，上述三个阈值可以不同，并且可以基于历史数据确定阈值的值。对于图15B中所示的情况，服务请求数阈值、分配率阈值和比值阈值可以分别被确定为15、0.6和10；对于图15D所示的情况，服务请求数阈值、分配率阈值和比值阈值可以分别确定为8、0.65和8。
3.如何确定可用服务提供者。
服务提供者的观点应考虑确定可用服务提供者的标准；也就是说，在什么情况下服务提供者愿意接受调度。根据经验，应尽可能满足以下目标：
目标1，服务请求数在服务提供者的预设范围内相对较小；
目标2，目标调度区域中服务请求的数量比较大；
在目标3中，服务提供者的位置与目标调度区域之间的距离相对较小。
为了实现这三个目标，可以执行以下操作。
在操作1中，对于特定的不健康区域，可以根据边界确定方法来确定区域的边界。根据边界的确定方法，可以确定最大纬度和经度(也分别被称为maxlng和maxlat)和区域中服务请求的起始位置的最小纬度和经度(也分别称为minlng和minlat)，并且区域的边界可以基于由以下四个点表示的矩形来确定，包括(最大纬度，最大经度)、(最大纬度，最小经度)、(最小纬度，最大经度)、(最小纬度，最小经度)。
在操作2中，在确定区域的边界之后，第二边界可以通过从边界扩展一个区域来确定，该区域是指将四个点扩展1000米，分别确定四个新点，并根据由四个新点表示的矩形确定第二边界。此外，边界和第二边界之间的区域差异(即，同心方形区域)中的服务提供者可以被确定为可用服务提供者。
在操作3中，满足以下条件的同心方形区域中的服务提供者可被确定为可用服务提供者。如本文所述，条件是指在距离服务提供者的位置的2000米范围内服务请求数量小于3，且服务提供者不在具有高服务请求密度的区域内(即，服务请求密度大于密度阈值的区域)。
在操作4中，在确定可用服务提供者之后，由于具有高服务请求密度的区域(即目标调度区域)的区域相对较大，可以为特定的可用服务提供者确定核心位置。如本文所述，来自核心位置的范围r的服务请求的数量不小于m。
在操作5中，对于每个可用服务提供者，可以确定最近的核心位置，并且可以将调度指令发送到可用服务提供者。
如图17所示，区域A是具有高服务请求密度的区域，区域B(即同心方形区域)为包括可用服务提供者的区域，D1和D2是指可用服务提供者，O1和O2分别指最接近两个可用服务提供者的核心位置。
4.地址信息调度区域的描述。
在确定可用服务提供者和可用服务提供者将被调度的核心位置之后，关键是核心位置的地址描述。可以获取核心位置的纬度和经度，根据地图API(例如，百度地图API)的纬度和经度来确定核心位置的地址信息，并且地址信息可以通过“地区+街道+商业”的组合来表达。
图18是根据本申请的一些实施例所示的运力调度的示例性流程图。流程1800可以由按需服务系统100执行。例如，流程1800可以基于存储在存储ROM 230或RAM 240中的一组指令(例如，应用程序)实现。处理器220和/或图20-25中的模块和/或单元可以执行该组指令，当执行指令时，处理器220和/或模块和/或单元可以被配置以执行流程1800。以下所示过程的操作仅出于说明的目的。在一些实施例中，流程1800可以通过未描述的一个或多个以上附加操作和/或没有一个或以上所讨论的操作来完成。另外，如图18所示和下面描述的过程操作的顺序不是限制性的。
在1810中，响应于检测到目标区域缺少服务提供者，可以将调度指令发送给与目标区域相关的候选服务区域(也称为“非忙碌区域”)中的一个或以上可用服务提供者，其中，调度指令被配置为请求一个或以上可用服务提供者的响应，以表明一个或以上可用服务提供者是否同意前往目标区域。如本文所用，术语“缺乏服务提供者”是指在区域中的可用服务提供者的数量与在区域中待分配的服务请求数之比小于预设的阈值，或区域中的可用服务提供者的数量小于在区域中待分配的服务请求数。
一般来说，为了提高线上到线下服务的服务效率，根据区域划分规则，相对大的区域可以被划分为至少两个服务区域(也被称为结合图6-9描述的“候选区域”)。例如，根据办公楼的分布，可以将区域划分为至少两个服务区域，其中，服务区域是指一个或以上可用服务提供者提供服务的区域。
在本申请的一些实施例中，可用服务提供者是指等待接收服务请求的用户，即提供线上到线下服务的用户。线上出租车的情况下，可用服务提供者是指司机；在外卖交付的情况下，可用服务提供者指的是交付人员。在其他线上到线下服务的场景中，可用服务提供者指的是服务身份的用户。本申请的实施方案不是限制性的。
在本申请的一些实施例中，运力是指服务区域中服务请求的数量与服务区域中可用服务提供者的数量之间的供需关系。例如，运力是指服务区域中可用服务提供者的数量与服务区域中服务请求的数量之比。其中，如果一个服务区域中的服务提供者的数量与服务请求数相近时，则认为该服务区域的运力平衡；如果可用服务提供者的数量远大于服务区域中服务请求的数量(即，服务区域中可用服务提供者的数量与服务区域中服务请求的数量之比大于第一阈值)，则服务区域的运力被认为是丰富的；如果可用服务提供者的数量远小于服务区域中服务请求的数量(即，服务区域中可用服务提供者的数量与服务区域中服务请求的数量之比小于第二阈值)，则服务区域的运力被认为是不足的。
在本申请的一些实施例中，可以通过确定目标区域中服务请求的数量和可用服务提供者的数量来确定目标区域的运力。
在本申请的一些实施例中，目标区域的运力可以实时确定，或者仅在满足某个预设的触发条件时确定。具体地，当检测到预设类型的事件时，可以确定目标区域的运力是否不足，其中，预设类型的事件可以包括预设类型的天气、高峰时间、节日或会议中的至少一个。
在本申请的一些实施例中，预设类型的天气可以包括雨、雪、风、烟雾、冰雹等，或可能影响交通状况的任何其他恶劣天气。节日可以包括很多人集中旅行的一个节日，如国庆节、劳动节等。应当理解，预设类型的事件可以是任何其他事件，例如明星音乐会等。本申请对此并不加以限制。
通常，预设类型的事件可能影响某些服务区域中的交通状况。例如，如果预设类型的事件是“高峰时段”，则具有相对较多办公楼的服务区域的交通状况可能会拥挤。
在本申请的一些实施例中，当前的天气信息可以从气象局或互联网的网站获取，并且可以基于当前天气信息确定当前天气是否是预设类型的天气。如果当前天气是预设类型的天气，可以确定发生了预设类型的事件。或者，可以获取当前时间信息，并且可以基于当前时间信息确定是高峰时间还是节日。
在本申请的一些实施例中，目标区域的候选服务区域可以包括目标区域附近的任何服务区域、目标区域附近具有丰富运力的任何服务区域、或定义的服务区域。本申请的实施方案不是限制性的。
在本申请的一些实施例中，在线上出租车的情况下，候选服务区域中的可用服务提供者是指当前位于候选服务区域中的司机；在外卖交付场景中，候选服务区域中的可用服务提供者是指交付范围在候选服务区域内的交付员工。
在本申请的一些实施例中，通过将相应的消息发送到安装在一个或以上可用服务提供者的终端装置中的线上到线下服务的第三方应用程序，可以将调度指令发送到一个或以上可用服务提供者。线上出租车的情景，安装在终端装置中的线上到线下服务的第三方应用可以是地图应用程序或线上出租车的司机应用程序。在外卖装置的场景中，安装在终端装置中的线上到线下服务的第三方应用可以是外卖应用程序。
在本申请的一些实施例中，当调度指令被传送到安装在一个或以上可用服务提供者的终端装置中的线上到线下服务的第三方应用程序时，线上到线下服务的第三方应用可以以窗口或卡的形式在服务应用程序的用户界面上显示调度指令，并提供用户用于输入反馈信息的界面。
在本申请的一些实施例中，调度指令可以发送到候选服务区域中的一个或以上可用服务提供者。调度指令可以被配置为请求一个或以上可用服务提供者的响应，以表明其是否同意接受线上到线下服务系统的调度。
在1820中，响应于一个或以上可用服务提供者表示同意中前往目标区域的一个或以上接受，将目标区域中的服务请求分配给该一个或以上可用服务提供者。
在本申请的一些实施例中，可用服务提供者提供的响应可以包括接受线上到线下服务系统的调度；也就是说，同意前往目标区域；或者拒绝线上到线下服务系统的调度，即拒绝前往目标区域。
在本申请的一些实施例中，当确定候选服务区域中的一个或以上可用服务提供者接受线上到线下服务系统的调度时，可以将目标区域中的服务请求分配给该一个或以上可用服务提供者。
通常，对应于线上到线下服务的服务请求包括起始位置和目的地。例如，线上出租车的场景中，服务请求是指旅行服务请求，其包括由乘客定义的上车位置(即起始位置)和下车位置(即目的地)。又如，在外卖交付的场景中，服务请求指的是外卖服务请求，其包括商业地址(即起始位置)和顾客地址(即目的地)。在提供服务的过程中，提供服务的用户的旅行路线需要覆盖起始位置或目的地中的至少一个。在本申请的一些实施例中，分配给一个或以上可用服务提供者的服务请求的起始位置和/或目的地应在目标区域内。
具体地，可以获取在线上到线下服务系统中待分配的一个或以上服务请求，可以获取待分配的一个或以上服务请求的起始位置和目的地，并且可以确定在目标区域内具有起始位置和/或目的地的服务请求。最后，服务请求可以分配给接受系统调度的一个或以上可用服务提供者。
以线上出租车的情景为例：在高峰时段，西二旗服务区的旅游服务请求数相对较大，而可用服务提供者的数量相对较小。但是，上地服务区域的可用服务提供者的数量相对较大。在这个情况下，按需服务系统100(例如，线上出租车服务系统)可以在上地服务区域向服务提供者发送调度指令，并在接受调度后，将具有上地服务区域内的起始位置和/或目的地的旅行服务请求分配给服务提供者。
从上述实施例可以看出，当目标区域的运力不足时，可以将其他服务区域中的可用服务提供者调度到目标区域，并且只将目标区域中的服务请求分配给可用服务提供者，使服务资源集中到服务需求高的服务区域，减少了服务资源的浪费。
为了确保候选服务区域中的运力能够满足候选服务区域中的服务需求，在本申请的一些实施例中，目标区域的候选服务区域是指具有丰富运力的服务区域。
在本申请的一些实施例中，可以从目标区域附近的服务区域过滤候选服务区域，或者可以基于大数据处理识别历史时间内运力总是充裕的服务区域并且可以将服务区域确定为目标区域的候选服务区域。本申请的实施方案不是限制性的。
应该注意的是，上述仅出于说明性目的而提供，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，根据本申请的教导可以做出多种变化和修改。然而，变化和修改不会背离本申请的范围。
图19是根据本申请的一些实施例所示的运力调度的示例性流程图。流程1900可以由按需服务系统100执行。例如，流程1900可以为存储在存储ROM 230或RAM 240中的一组指令(例如，应用程序)实现。处理器220和/或图20-25中的模块和/或单元可以执行该组指令，当执行指令时，处理器220和/或模块和/或单元可以被配置以执行流程1900。以下所示过程的操作仅出于说明的目的。在一些实施例中，流程1900可以通过未描述的一个或以上附加操作和/或没有一个或以上所讨论的操作来完成。另外，如图19所示和下面描述的过程操作的顺序不是限制性的。
在1910中，响应于检测到目标区域缺少服务提供者，可以获取目标区域附近的服务区域的运力，并且可以将具有丰富运力的至少一个服务区域确定为候选服务区域。
通常，与不在目标区域附近的服务区域相比，在目标区域附近的服务区域中的一个或以上可用服务提供者可以在接受调度之后更快地到达目标区域。
在本申请的一些实施例中，可以将目标区域附近具有丰富运力的一个或以上服务区域确定为候选服务区域。本申请的实施方案不是限制性的。
在1920中，调度指令可以被传送到候选服务区域中的一个或以上可用服务提供者，其中，调度指令被配置为请求一个或以上可用服务提供者回应，以表明所述一个或以上可用服务提供者是否同意前往目标区域。
根据本申请的一些实施例，操作1920类似于图18中描述的操作1810，因此，这里省略了详细描述。
在1930中，可以基于预设的时间段、接收到来自候选服务区域中的一个或以上可用服务提供者中的至少一个接受运力调度的第一时间点、或者一个或以上可用服务提供者中的至少一个到达目标区域的第二时间点中的至少一个，确定一个或以上可用服务提供者中的至少一个的服务时间段。
通常，服务区域的运力不足状态将被缓解，或者服务区域的运力将在一段时间后恢复平衡。此时，可能没有必要将可用服务提供者从候选服务区域调度到目标区域。因此，在本申请的一些实施例中，可以确定某个服务时间段。在服务时间段期间，目标区域中的服务请求可以分配给一个或以上可用服务提供者；在服务时间段之外，可以应用一般分配策略。如本文所用，术语“一般分配策略”是指服务请求可以分配给服务提供者，该服务提供者的位置在服务请求的起始位置的预设范围(例如，1km、3km)内。
在本申请的一些实施例中，一个或以上可用服务提供者中的至少一个的服务时间段可以基于预设服务时间段和一个或以上可用服务提供者中的至少一个接受调度的时间点确定。例如，预设服务时间段可以表示为ΔT，一个或以上可用服务提供者中的至少一个接受调度的时间点可以由T0表示，一个或以上可用服务提供者中的至少一个的服务时间段可以是(T0，T0+ΔT)。
或者，在本申请的一些实施例中，一个或以上可用服务提供者中的至少一个的服务时间段可以基于预设服务时间段和一个或以上可用服务提供者中的至少一个到达目标区域的时间点来确定。例如，预设服务时间段可以表示为ΔT，一个或以上可用服务提供者中的至少一个到达目标区域的时间点可以由T1表示，一个或以上可用服务提供者中的至少一个的服务时间段可以是(T1，T1+ΔT)。
在1940中，目标区域中的服务请求可以在服务时间段期间被分配给一个或以上可用服务提供者中的至少一个。
在本申请的一些实施例中，在基于预设服务时间段和一个或以上可用服务提供者中的至少一个接受调度的时间点确定服务时间段的情况下，在服务时间段和一个或以上可用服务提供者中的至少一个到达目标区域之前，系统只能将目的地在目标区域内的服务请求分配给一个或以上可用服务提供者中的至少一个；而在一个或以上可用服务提供者中的至少一个到达目标区域后，系统可以仅将起始位置在目标区域内的服务请求或起始位置和目的地均在目标区域内的服务请求分配给一个或以上可用服务提供者中的至少一个。
或者，在本申请的一些实施例中，在基于预设服务时间段和一个或以上可用服务提供者中的至少一个到达目标区域的时间点确定服务时间段的情况下，在服务时间段期间，系统可以将起始位置在目标区域内的服务请求或起始位置和目的地均在目标区域内的服务请求分配给一个或以上可用服务提供者。另外，在一个或以上可用服务提供者中的至少一个到达目标区域之前，系统可以不向一个或以上可用服务提供者分配服务请求，或者仅将目的地在目标区域内的服务请求分配给一个或以上可用服务提供者中的至少一个。
从以上实施例可以看出，候选服务区域可以从目标区域附近的服务区域中选择。与不在目标区域附近的服务区域的服务提供者相比，在目标区域附近的服务区域中的一个或以上可用服务提供者可以在接受调度后更快地到达目标区域，因此，可以提高线上到线下服务的效率。另外，系统可以仅在服务时间段中将目标区域中的服务请求分配给一个或以上可用服务提供者，并在服务时间段以外停止将目标区域中服务请求分配给一个或以上可用服务提供者。因此，可以避免将服务资源长时间集中到一个服务区域，以免浪费服务资源。
为了避免从其他服务区域到目标区域的过度调度，这可能导致目标区域的运力过剩和服务资源的浪费，可以提供一些替代实施例，其中可以添加操作1950和操作1955。
在1950中，可以确定所接收的一个或以上接受调度的数量。
在1955中，系统可以在确定的所接收的一个或以上接受调度的数量大于预设的阈值时，停止向候选服务区域中的一个或以上可用服务提供者发送调度指令。
在本申请的一些实施例中，可以基于能够确保目标区域的运力能够恢复平衡的条件来设置预设阈值。
从上述实施例可以看出，通过控制调度到目标区域的可用服务提供者的数量，可以避免从其他服务区域向目标区域过度调度可用服务提供者，以及可能导致的目标区域的运力过剩和服务资源的浪费。
在本申请的一些备选实施例中，当可用服务提供者在预设时间内到达目标区域时，可以将奖励发送给可用服务提供者。在这种情况下，操作1960和操作1965可以添加到图18或图19中所示的一些实施例中。
在1960中，在一个或以上可用服务提供者中的至少一个同意前往目标区域之后，可以确定一个或以上可用服务提供者中的至少一个是否在预设时间内到达目标区域。
在1965中，当一个或以上可用服务提供者中的至少一个在预设时间内到达目标区域时，可以将奖励发送给一个或以上可用服务提供者中的至少一个。奖励可包括折扣、现金奖励、凭证等。
图20是根据本申请的一些实施例所示的示例性分配服务请求装置的框图。分配服务请求装置2000可以包括信息传输模块2010和服务请求分配模块2020。在一些实施例中，分配服务请求装置2000可以集成到服务器110中。例如，分配服务请求装置2000可以集成到处理引擎112中。
信息传输模块2010可以被配置为响应于检测到目标区域缺少服务提供者，将调度指令发送至与目标区域相关的候选服务区域中的一个或以上可用服务提供者，调度指令被配置为请求一个或以上可用服务提供者回应，以表明一个以上可用服务提供者是否同意前往所述目标区域。
通常，为了提高线上到线下服务的服务效率，可以根据区域划分规则将相对大的区域划分为至少两个服务区域。例如，可以根据办公楼的分布将区域划分为至少两个服务区域，其中服务区域是指一个或以上可用服务提供者提供服务的区域。
在本申请的一些实施例中，可用服务提供者是指等待接收服务请求的用户，即提供线上到线下服务的用户。线上出租车的情况下，可用服务提供者是指司机；在外卖交付的情况下，可用服务提供者指的是交付人员。在其他线上到线下服务的场景中，可用服务提供者指的是服务身份的用户。本申请的实施方案不是限制性的。
在本申请的一些实施例中，运力是指服务区域中服务请求的数量与服务区域中可用服务提供者的数量之间的供需关系。其中，如果一个服务区域中的服务提供者的数量与服务请求数相近时，则认为该服务区域的运力平衡；如果一个服务区域中的服务提供者的数量远大于服务请求数时，则认为该服务区域的运力丰富；如果服务提供者的数量远小于服务区域中服务请求的数量，则认为服务区域的运力不足。
在本申请的一些实施例中，可以通过确定目标区域中服务请求的数量和可用服务提供者的数量来确定目标区域的运力。
在本申请的一些实施例中，目标区域的运力可以实时确定，或者仅在满足某个预设的触发条件时确定。具体地，当检测到预设类型的事件时，可以确定目标区域的运力是否不足，其中，预设类型的事件可以包括预设类型的天气、高峰时间、节日或会议中的至少一个。
在本申请的一些实施例中，预设类型的天气可以包括雨、雪、风、烟雾、冰雹等，或可能影响交通状况的任何其他恶劣天气。节日可以包括很多人集中旅行的一个节日，如国庆节、劳动节等。应当理解，预设类型的事件可以是任何其他事件，例如明星音乐会等。本申请对此并不加以限制。
通常，预设类型的事件可能影响某些服务区域中的交通状况。例如，如果预设类型的事件是“高峰时段”，则具有相对较多办公楼的服务区域的交通状况可能会拥挤。
在本申请的一些实施例中，当前天气信息可以从气象局或互联网的网站获取，并且可以基于当前天气信息确定当前天气是否是预设类型的天气。如果当前天气是预设类型的天气，则可以确定发生了预设类型的事件。或者，可以获取当前时间信息，并且可以基于当前时间信息确定是高峰时间还是节日。
在本申请的一些实施例中，目标区域的候选服务区域可以包括目标区域附近的任何服务区域、目标区域附近具有丰富运力的任何服务区域、或定义的服务区域。本申请的实施方案不是限制性的。
在本申请的一些实施例中，在线上出租车的情况下，候选服务区域中的可用服务提供者是指当前位于候选服务区域中的司机；在外卖交付场景中，候选服务区域中的可用服务提供者是指交付范围在候选服务区域内的交付员工。
在本申请的一些实施例中，通过将相应的消息发送到安装在一个或以上可用服务提供者的终端装置中的线上到线下服务的第三方应用程序，可以将调度指令发送到一个或以上可用服务提供者。线上出租车的场景中，安装在终端装置中的线上到线下服务的第三方应用可以是地图应用或线上出租车的司机应用程序。在外卖装置的场景中，安装在终端装置中的线上到线下服务的第三方应用可以是外卖应用程序。
在本申请的一些实施例中，当调度指令被传送到安装在一个或以上可用服务提供者的终端装置中的线上到线下服务第三方应用程序时，线上到线下服务的第三方应用可以以窗口或卡的形式在服务应用程序的用户界面上显示调度指令，并提供用户用于输入反馈信息的界面。
在本申请的一些实施例中，可以将调度指令发送到候选服务区域中的一个或以上可用服务提供者。调度指令可以被配置为请求一个或以上可用服务提供者的响应，以表明其是否同意接受线上到线下服务系统的调度。
服务请求分配模块2020可以被配置为响应于一个或以上可用服务提供者接受前往目标区域，将目标区域中的服务请求分配给一个或以上可用服务提供者。
在本申请的一些实施例中，可用服务提供者提供的响应可以包括接受线上到线下服务系统的调度，也就是说，同意前往目标区域；或者拒绝线上到线下服务系统的调度，即拒绝前往目标区域。
在本申请的一些实施例中，当确定候选服务区域中的一个或以上可用服务提供者接受线上到线下服务系统的调度时，可以将目标区域中的服务请求分配给一个或以上可用服务提供者。
通常，对应于线上到线下服务的服务请求包括起始位置和目的地。例如，线上出租车的场景中，服务请求是指旅行服务请求，其包括由乘客定义的上车位置(即起始位置)和下车位置(即目的地)。又如，在外卖交付的场景中，服务请求指的是外卖服务请求，其包括商业地址(即起始位置)和顾客地址(即目的地)。在提供服务的过程期间，提供服务的用户的旅行路线需要覆盖起始位置或目的地中的至少一个。在本申请的一些实施例中，分配给一个或以上可用服务提供者的服务请求的开始位置和/或目的地应该在目标区域内。
具体而言，可以获取在线上到线下服务系统中待分配的一个或以上服务请求，可以获取待分配的一个或以上服务请求的起始位置和目的地，并且可以确定在目标区域内具有起始位置和/或目的地的服务请求。最后，服务请求可以分配给接受系统调度的一个或以上可用服务提供者。
以线上出租车的情景为例：在高峰时段，西二旗服务区域的旅游服务请求数相对较大，而可用服务提供者的数量相对较小。但是，上地服务区域的可用服务提供者的数量相对较大。在这个情况下，按需服务系统100(例如，线上出租车服务系统)可以在上地服务区域向服务提供者发送调度指令，并在接受调度后，将具有上地服务区域内的起始位置和/或目的地的旅行服务请求分配给服务提供者。
从上述实施例可以看出，当目标区域的运力不足时，可以将其他服务区域中的可用服务提供者调度到目标区域，并且只将目标区域中的服务请求分配给可用服务提供者，使服务资源集中到服务需求高的服务区域，减少了服务资源的浪费。
为了确保候选服务区域中的运力能够满足候选服务区域中的服务需求，在本申请的一些实施例中，目标区域的候选服务区域是指具有丰富运力的服务区域。
在本申请的一些实施例中，可以从目标区域附近的服务区域过滤候选服务区域，或者可以基于大数据处理识别历史时间内运力总是充裕的服务区域并且可以将服务区域确定为目标区域的候选服务区域。本申请的实施方案不是限制性的。
分配服务请求装置2000中的模块可以通过有线连接或无线连接彼此连接或通信。有线连接可以包括金属线缆、光缆、混合电缆等或其任意组合。无线连接可以包括局域网络(LAN)、广域网(WAN)、蓝牙、紫蜂(ZigBee)网络、近场通信(NFC)等或其任意组合。两个或以上模块可以合并成一个模块，以及任意一个模块可以被拆分成两个或以上单元。
图21是根据本申请的一些实施例所示的示例性分配服务请求装置的框图。根据分配服务请求装置2000，分配服务请求装置2100还可以包括候选服务区域确定模块2130。候选服务区域确定模块2130可以包括运力获取单元2132和候选服务区域确定单元2134。在一些实施例中，分配服务请求装置2100可以集成到服务器110中。例如，分配服务请求装置2100可以集成到处理引擎112中。
运力获取单元2132可以被配置为响应于检测到所述目标区域缺乏服务提供者而获取所述目标区域附近的服务区域的运力。
候选服务区域确定单元2134可以被配置用于确定具有丰富运力的服务区域中的至少一个作为候选服务区域。
通常，与不在目标区域附近的服务区域相比，在目标区域附近的服务区域中的一个或以上可用服务提供者可以在接受调度之后更快地到达目标区域。
在本申请的一些实施例中，可以将目标区域附近具有丰富运力的一个或以上服务区域确定为候选服务区域。本申请的实施方案不是限制性的。
从上述实施例可以看出，候选服务区域可以从目标区域附近的服务区域中选择。与不在目标区域附近的服务区域的服务提供者相比，在目标区域附近的服务区域中的一个或以上可用服务提供者可以在接受调度后更快地到达目标区域，因此，可以提高线上到线下服务的效率。
分配服务请求装置2100中的模块和/或单元可以通过有线连接或无线连接相互连接或相互通信。有线连接可以包括金属线缆、光缆、混合电缆等或其任意组合。无线连接可以包括局域网络(LAN)、广域网(WAN)、蓝牙、紫蜂(ZigBee)网络、近场通信(NFC)等或其任意组合。两个或以上模块可以合并成一个模块，以及任意一个模块可以被拆分成两个或以上单元。
图22是根据本申请的一些实施例所示的示例性服务请求分配模块的框图。服务请求分配模块2020可以包括服务时间段确定单元2210和服务请求分配单元2220。
服务时间段确定单元2210可以被配置用于基于预设时间段以及收到来自一个或以上可用服务提供者中的至少一个接受调度指令的第一时间点、或者一个或以上可用服务提供者中的至少一个到达目标区域的第二时间点中的至少一个，确定候选服务区域中的一个或以上可用服务提供者中的至少一个的服务时间段。
通常，服务区域的运力不足状态将得到缓解，或服务区域的运力将在一段时间后恢复平衡。此时，可能没有必要将可用服务提供者从候选服务区域调度到目标区域。因此，在本申请的一些实施例中，可以确定某个服务时间段。在服务时间段期间，目标区域中的服务请求可以分配给一个或以上可用服务提供者；在服务时间段之外，可以应用一般分配策略。
在本申请的一些实施例中，一个或以上可用服务提供者中的至少一个的服务时间段可以基于预设服务时间段和一个或以上可用服务提供者中的至少一个接受调度的时间点确定。例如，预设服务时间段可以表示为ΔT，一个或以上可用服务提供者中的至少一个接受调度的时间点可以由T0表示，一个或以上可用服务提供者中的至少一个的服务时间段可以是(T0，T0+ΔT)。
或者，在本申请的一些实施例中，一个或以上可用服务提供者中的至少一个的服务时间段可以基于预设服务时间段和一个或以上可用服务提供者中的至少一个到达目标区域的时间点来确定。例如，预设服务时间段可以表示为ΔT，一个或以上可用服务提供者中的至少一个到达目标区域的时间点可以由T1表示，一个或以上可用服务提供者中的至少一个的服务时间段可以是(T1，T1+ΔT)。
服务请求分配单元2220可以被配置为在服务时间段期间将目标区域中的服务请求分配给一个或以上可用服务提供者中的至少一个。
在本申请的一些实施例中，在基于预设服务时间段和一个或以上可用服务提供者中的至少一个接受调度的时间点确定服务时间段的情况下，在服务时间段和一个或以上可用服务提供者中的至少一个到达目标区域之前，系统只能将目的地在目标区域内的服务请求分配给一个或以上可用服务提供者中的至少一个；而在一个或以上可用服务提供者中的至少一个到达目标区域后，系统可以仅将起始位置在目标区域内的服务请求或起始位置和目的地均在目标区域内的服务请求分配给一个或以上可用服务提供者中的至少一个。
或者，在本申请的一些实施例中，在服务时间段期间，在基于预设服务时间段和一个或以上可用服务提供者中的至少一个到达目标区域的时间点确定服务时间段的情况下，系统只能将起始位置在目标区域内的服务请求或起始位置和目的地均在目标区域内的服务请求分配给一个或以上可用服务提供者。另外，在一个或以上可用服务提供者中的至少一个到达目标区域之前，系统可以不向一个或以上可用服务提供者分配服务请求，或者仅将目的地在目标区域内的服务请求分配给一个或以上可用服务提供者中的至少一个。
从以上实施例可以看出，该系统可以只在服务时间段将目标区域中的服务请求分配给一个或以上可用服务提供者，并在服务时间段以外停止向一个或以上可用服务提供者分配目标区域中的服务请求。因此，可以避免将服务资源长时间集中到一个服务区域，从而避免浪费服务资源。
服务请求分配模块2020中的单元可以通过有线连接或无线连接相互连接或相互通信。有线连接可以包括金属线缆、光缆、混合电缆等或其任意组合。无线连接可以包括局域网络(LAN)、广域网(WAN)、蓝牙、紫蜂(ZigBee)网络、近场通信(NFC)等或其任意组合。两个或以上的单元可以组合成单个模块，并且任何一个模块可以分为两个或以上子单元。
图23是根据本申请的一些实施例所示的示例性分配服务请求装置的框图。根据分配服务请求装置2000或2100，分配服务请求装置2300还可包括数量确定模块2330和控制模块2340。在一些实施例中，分配服务请求装置2300可以集成到服务器110中。例如，分配服务请求装置2300可以集成到处理引擎112中。
数量确定模块2330可以被配置用于确定所接收的一个或以上接受调度的数量。
控制模块2340可以被配置为响应于确定的所接收的一个或以上接受调度的数量大于预设阈值时，停止向候选服务区域中的一个或以上可用服务提供者发送调度指令。
在本申请的一些实施例中，可以基于能够确保目标区域的运力能够恢复平衡的条件来设置预设阈值。
从上述实施例可以看出，通过控制调度到目标区域的可用服务提供者的数量，可以避免从其他服务区域向目标区域过度调度可用服务提供者，以及可能导致的目标区域的运力过剩和服务资源的浪费。
分配服务请求装置2300中的模块可以通过有线连接或无线连接相互连接或相互通信。有线连接可以包括金属线缆、光缆、混合电缆等或其任意组合。无线连接可以包括局域网络(LAN)、广域网(WAN)、蓝牙、紫蜂(ZigBee)网络、近场通信(NFC)等或其任意组合。两个或以上模块可以合并成一个模块，以及任意一个模块可以被拆分成两个或以上单元。
图24是根据本申请的一些实施例所示的示例性分配服务请求装置的框图。根据分配服务请求装置2000、2100和/或2300，分配服务请求装置2400还可以包括判断模块2430和奖励传输模块2440。在一些实施例中，分配服务请求装置2400可以集成到服务器110中。例如，分配服务请求装置2400可以集成到处理引擎112中。
当一个或以上可用服务提供者中的至少一个同意前往目标区域时，判断模块2430可以被配置用于确定一个或以上可用服务提供者中的至少一个是否在预设时间内到达目标区域。
当所述一个或以上可用服务提供者中的至少一个在预设时间内到达目标区域时，奖励传输模块2440可以被配置用于将奖励传送到一个或以上可用服务提供者中的至少一个。
分配服务请求装置2400中的模块可以通过有线连接或无线连接彼此连接或通信。有线连接可以包括金属线缆、光缆、混合电缆等或其任意组合。无线连接可以包括局域网络(LAN)、广域网(WAN)、蓝牙、紫蜂(ZigBee)网络、近场通信(NFC)等或其任意组合。两个或以上模块可以合并成一个模块，以及任意一个模块可以被拆分成两个或以上单元。
图25是根据本申请的一些实施例所示的示例性分配服务请求装置的框图。根据分配服务请求装置2000、2100、2300和/或2400，分配服务请求装置2500还可以包括检测模块2530。在一些实施例中，分配服务请求装置2500可以集成到服务器110中。例如，分配服务请求装置2500可以集成到处理引擎112中。
当检测到预设类型的事件时，检测模块2530可以被配置用于确定目标区域的运力是否不足。
在本申请的一些备选实施例中，预设类型的事件可以包括预设类型的天气、高峰时间、节日或会议中的至少一个。
在本申请的一些实施例中，可以仅在满足某个预设触发条件时确定目标区域的运力。具体地，当检测到预设类型的事件时，可以确定目标区域的运力是否不足，其中，预设类型的事件可以包括预设类型的天气、高峰时间、节日或会议中的至少一个。
在本申请的一些实施例中，预设类型的天气可以包括雨、雪、风、烟雾、冰雹等，或可能影响交通状况的任何其他恶劣天气。节日可以包括一个很多人集中旅行的节日，如国庆节、劳动节等。应当理解，预设类型的事件可以是任何其他事件，例如明星音乐会等。本申请对此并不加以限制。
通常，预设类型的事件可能影响某些服务区域中的交通状况。例如，如果预设类型的事件是“高峰时段”，则具有相对较多办公楼的服务区域的交通状况可能会拥挤。
在本申请的一些实施例中，当前天气信息可以从气象局或互联网的网站获取，并且可以基于当前天气信息确定当前天气是否是预设类型的天气。如果当前天气是预设类型的天气，可以确定发生了预设类型的事件。或者，可以获取当前时间信息，并且可以基于当前时间信息确定是高峰时间还是节日。
分配服务请求装置2500中的模块可以通过有线连接或无线连接彼此连接或通信。有线连接可以包括金属线缆、光缆、混合电缆等或其任意组合。无线连接可以包括局域网络(LAN)、广域网(WAN)、蓝牙、紫蜂(ZigBee)网络、近场通信(NFC)等或其任意组合。两个或以上模块可以合并成一个模块，以及任意一个模块可以被拆分成两个或以上单元。
本申请还可以提供包括第二指令的第二计算机存储介质。当由至少一个处理器执行时，第二指令可以表明至少一个处理器执行本申请中其他地方描述的过程(例如，流程1800、流程1900)。
图26是根据本申请的一些实施例所示的推送用于查找服务请求的推荐信息的示例性装置的框图。推送用于查找服务请求的推荐信息装置2600可以包括第一确定模块2610、第一估算模块2620、第二确定模块2630和第一推荐模块2640。在一些实施例中，装置2600可以集成到服务器110中。例如，装置2600可以集成到处理引擎112中。
第一确定模块2610可以被配置用于确定从可用服务提供者的位置到候选区域的估算行程时间。
在本申请的一些实施例中，一个区域可以在地理上划分为N个地理区域，每个地理区域对应于一定范围的地理坐标。关于区域划分的更多描述可以在本申请的其他地方找到(例如，图4-9、18-19及其描述)。在一些实施例中，可用服务提供者的位置(即，与运力调度相关联的司机)可以基于从与可用服务提供者相关联的用户终端(例如，提供者终端140)接收的全球定位系统(GPS)数据来获取。在一些实施例中，GPS数据可以由用户终端的GPS芯片组确定。在确定了可用服务提供者的位置之后，可以确定可用服务提供者所在的地理区域。除了可用服务提供者所在的地理区域之外的任何一个(N-1)个地理区域可以被确定为上述候选区域。
在确定可用服务提供者的位置之后，从可用服务提供者到候选区域的行程距离可以基于可用服务提供者的位置坐标和候选区域的坐标范围来确定。在本申请的一些实施例中，术语“从可用服务提供者到候选区域的行程距离”是指从可用服务提供者的位置到候选区域的中心点的行程距离，或者从可用服务提供者的位置到候选区域的任何一点的行程距离(例如最靠近可用服务提供者所在地的点)，并且行程距离是指计划导航路径的长度。最后，可以基于可用服务提供者的行程距离和估算的行进速度来确定从可用服务提供者的位置到候选区域的估算行程时间T。
在一些实施例中，第一确定模块2610可以被配置用于响应于查找由可用服务提供者发起的查找服务请求，确定从可用服务提供者的位置到候选区域的估算行程时间。如上所述，可用服务提供者可以经由用户终端(例如，提供者终端140)向运力调度服务器(例如，服务器110)发起查找服务请求，其中，可以基于在用户终端上查找由可用服务提供者执行的服务请求的操作来生成查找服务请求。交通工具调度服务器收到查找订单的请求后，第一确定单元101可将根据该查找订单请求对应的找单操作确定从所述用户所处的位置到目标地理区域的估算行程时间。
在一些实施例中，推送用于查找服务请求的推荐信息的装置2600也可以包括警报模块，该警报模块可以被配置用于在可用服务提供者发起查找服务请求后从可用服务提供者的位置到候选区域的估算行程时间尚未确定之前，检测到可用服务提供者等待接收服务请求的时间段大于预设时间阈值(例如，10分钟)时，来提醒可用服务提供者将查找服务请求发送给装置2600。预设时间阈值可以根据实际应用来设置，本申请不是限制性的。例如，当运力调度服务器检测到长时间没有将服务请求分配给可用服务提供者时，运力调度服务器可以推送界面信息，以提醒可用服务提供者向用户终端发起查找服务请求，从而提高可用服务提供者的查找服务请求的效率。
如果可用服务提供者前往候选区域并且被分配服务请求，则第一估算模块2620可被配置用于根据与候选区域的运力调度相关联的交易数据估算收益值。
与候选区域的运力调度相关联的交易数据可以是基于与候选区域中的运力调度相关联的服务请求而生成的各种类型的交易数据，例如与运力调度相关的服务请求的历史数据，包括但不限于历史时间段内的历史数据，例如，与运力调度相关的服务请求、平均服务费用、可用服务提供者数量、运力不足等。
基于确定的收益值与估算行程时间的比值满足预设条件的结果，第二确定模块2630可以被配置用于将候选区域作为查找服务请求的推荐区域(也被称为“目标区域”)。
在一些实施例中，预设条件指的是候选区域的收益值与候选区域的估算行程时间的比值在所有候选区域的收益值率的降序排名的前N(N≥1)。
在一些备选实施例中，预设条件可以指的是候选区域的收益值与估算行程时间的比值大于预设阈值。
应当注意，在一些实施例中，如果在收益值内存在与至少两个候选区域相对应的负收益值，可以在第一次滤除负收益值，然后可以确定对应于候选区域的收益值与估算行程时间的比值是否满足预设条件。
第一推荐模块2640可以被配置为基于推荐区域生成并发送用于查找服务请求的推荐信息给可用服务提供者相关联的用户终端(例如，提供者终端140)。
在一些实施例中，查找服务请求的推荐信息可以包括用于查找服务请求的推荐区域的区域信息(例如，坐标信息、商业区信息)、用于查找服务请求的推荐区域的收益值、从可用服务提供者的位置到用于查找服务请求的推荐区域行程费用、从可用服务提供者的位置到用于查找服务请求的推荐区域的估算行程时间等，或其组合。查找服务请求的推荐信息还可以包括建议可用服务提供者前往某个候选区域接收服务请求等的信息。
在一些实施例中，第一推荐模块2640可以被配置为根据一个或以上推荐区域的收益值和估算行程时间的比值，从高到低排列查找服务请求的一个或以上推荐区域，生成并发送用于查找服务请求的推荐信息给可用服务提供者相关联的用户终端。
装置2600中的模块可以经由有线连接或无线连接彼此连接或通信。有线连接可以包括金属线缆、光缆、混合电缆等或其任意组合。无线连接可以包括局域网络(LAN)、广域网(WAN)、蓝牙、紫蜂(ZigBee)网络、近场通信(NFC)等或其任意组合。两个或以上模块可以合并成一个模块，以及任意一个模块可以被拆分成两个或以上单元。
图27是根据本申请的一些实施例所示的示例性第一估算模块的框图。第一估算模块2620可包括估算单元2710和收益计算单元2720。
估算单元2710可以被配置用于计算如果可用服务提供者到达候选区域，可用服务提供者被分配服务请求的概率，以及基于与候选区域的运力调度相关联的交易数据，确定服务请求分配给可用服务提供者的服务费用。
在一些备选实施例中，可以将候选区域中的服务请求的平均服务费用确定为分配给可用服务提供者的服务请求的服务费用。
在一些替代实施例中，具有最高出现频率的服务费用可以基于与候选区域的运力调度相关联的交易数据从至少两个历史服务费用获取，并且可以被确定为分配给可用服务提供者的服务请求的服务费用。
在一些替代实施例中，可以基于与候选区域的运力调度相关联的交易数据来获取候选区域中的至少两个历史服务费用的分布，并且，在至少两个服务费用间隔中历史服务费用的数量最大的特定服务费用间隔可以被识别并确定为分配给可用服务提供者的服务请求的服务费用。
如果可用服务提供者前往候选区域，则收益计算单元2720可以被配置用于基于概率和分配服务请求的服务费用确定收益值。
第一估算模块2620中的单元可以通过有线连接或无线连接彼此连接或通信。有线连接可以包括金属线缆、光缆、混合电缆等或其任意组合。无线连接可以包括局域网络(LAN)、广域网(WAN)、蓝牙、紫蜂(ZigBee)网络、近场通信(NFC)等或其任意组合。两个或以上的单元可以组合成单个模块，并且任何一个单元可以分为两个或以上子单元。
图28是根据本申请的一些实施例所示的示例性估算单元的框图。估算单元2710可以包括时间确定子单元2810、数量估算子单元2820和概率确定子单元2830。
时间确定子单元2810可以被配置用于基于估算行程时间确定预测时间段。
在一些实施例中，预测时间段可以是在估算的时间点之前的时间段或估算的时间点之后的时间段，在该估算时间点，可用服务提供者根据估算行程时间到达候选区域。例如，如果可用服务提供者到达候选区域的估算时间点是在M日的上午10点，预测时间段可以被确定为从M日的上午10点到11点的一小时。
基于与候选区域的运力调度相关联的交易数据，数量估算子单元2820可以被配置用于确定候选区域的运力不足数量和预测时区段内的候选区域中可用服务提供者的数量。如本文所使用的，运力不足数量是指在预测时间段中服务请求的数量与可用服务提供者的数量之间的差异。
在本申请的一些实施例中，可以基于与对应于预测时间段的至少一个历史时间段中的运力调度相关联的交易数据来预测运力不足数量和可用服务提供者的数量。
在一些实施例中，可以基于与预测时间段对应的至少一个历史时间段中与运力调度相关联的交易数据来预测候选区域的平均运力不足数量和候选区域的可用服务提供者的平均数量，并且可以确定在预测时间段内的候选区域中的运力不足数量和候选区域的可用服务提供者的数量。例如，如果基于估算行程时间确定的预测时间段是在M日的上午10：00到11：00之间，候选区域的平均运力不足数量和候选区域的可用服务提供者的平均数量可以基于候选区域Q中的服务请求数在M日前K天和天数“K”之间的上午10点至11点之间来确定，并且平均运力不足数量和可用服务提供者的平均数量可分别确定为候选区域内运力不足数量和候选区域的可用服务提供者的数量。另外，预测时间段中的运力不足数量和可用服务提供者的数量可以基于与运力调度相关联的交易数据在等于预测时间段的任何其他历史时间段中确定。
概率确定子单元2830可以被配置为确定运力不足数量对可用服务提供者的数量的比值，并且可以将该比值确定为可用服务提供者在候选区域中被分配服务请求的概率。
根据上面的例子，如果确定候选区域Q中在上午10：00至11：00之间的运力不足数量为100，且可用服务提供者的数量为200，则在候选区域Q中可用服务提供者被分配服务请求的概率可以被确定为100/200(即，0.5)。
应当注意可用服务提供者被分配服务请求的概率，也可能受到可用服务提供者的信用评分或评级的影响。例如，对于特定的候选区域，对于具有相对良好的信用评分或相对较高的评级的可用服务提供者，他或她被分配服务请求的概率相对较高；而对于信用评分相对较差或评级相对较低的可用服务提供者，他或她被分配服务请求的概率相对较低。如这里所使用的，可以基于至少两个因素来确定可用服务提供者的信用评分或评级。如历史服务交易的数量、提供服务的拒绝数量、出租车服务质量、与将乘客送达目的地相关联的及时性信息、乘客提供的评估信息等，或其组合。由于确定信用评分或可用服务提供者的评级的过程对于本领域普通技术人员是显而易见的，因此这里不再详细描述。
在一些替代实施例中，运力调度服务器可以为候选区域中具有相对较好的信用评分或相对较高的评级的可用服务提供者提供优先权，因此对于可用服务提供者，其信用评分相对较高或评分较高，他或她被分配服务请求的概率可能高于运力不足数量对可用服务提供者的数量比值，而对于可用服务提供者，信用评分相对较差或评分较低，他或她被分配服务请求的概率可能低于运力不足数量对可用服务提供者的数量比值。例如，如果确定在候选区域中可用服务提供者被分配服务请求的平均概率为0.5，可用服务提供者具有相对较好的信用评分或相对较高评级的被分配服务请求的概率可高于0.5(例如0.8)，然而，可用服务提供者具有相对较差的信用评分或相对较低评级的被分配服务请求的概率可以低于0.5(例如，0.3)。
估算单元2710中的子单元可以经由有线连接或无线连接彼此连接或通信。有线连接可以包括金属线缆、光缆、混合电缆等或其任意组合。无线连接可以包括局域网络(LAN)、广域网(WAN)、蓝牙、紫蜂(ZigBee)网络、近场通信(NFC)等或其任意组合。子单元的两个或以上可以组合成单个单元，并且子单元中的任何一个可以分为两个或以上子单元。
图29是根据本申请的一些实施例所示的示例性收益计算单元的框图。收益计算单元2720可以包括计算子单元2910、行程费用确定子单元2920和利润确定子单元2930。
计算子单元2910可以被配置用于确定可用服务提供者被分配服务请求的概率和服务请求的服务费用的乘积。
行程费用确定子单元2920可以被配置用于确定从可用服务提供者的位置行进到候选区域的可用服务提供者的行程费用。
在一些实施例中，可用服务提供者的位置可以被确定为上车位置，可以将候选区域中的任何点确定为目的地，并且可以根据上车位置和目的地基于计划路线确定行程费用。
利润确定子单元2930可以被配置为通过从乘积中减去行程费用来确定差值，并且如果可用服务提供者进入候选区域并分配服务请求，则将差值确定为收益值。
在一些备选实施例中，收益计算单元2720还可以包括概率和服务费用确定子单元和利润确定子单元。基于与候选区域的运力调度相关联的交易数据，概率和服务费用确定子单元可以被配置用于确定在预设时间段内可用服务提供者在候选区域中被分配服务请求的概率和分配给可用服务提供者的服务请求的服务费用。利润确定子单元可以被配置用于计算概率和服务费用的乘积，并且如果可用服务提供者前往候选区域并且被分配服务请求，则将乘积确定为收益值。
在一些备选实施例中，如果可用服务提供者前往候选区域并且被分配服务请求，则可以将服务请求的服务费用直接确定为收益值。例如，如果可用服务提供者是VIP司机，则运力调度服务器可以优先将服务请求分配给司机，VIP司机被分配服务请求的概率可以视为1。
收益计算单元2720中的子单元可以通过有线连接或无线连接彼此连接或通信。有线连接可以包括金属线缆、光缆、混合电缆等或其任意组合。无线连接可以包括局域网络(LAN)、广域网(WAN)、蓝牙、紫蜂(ZigBee)网络、近场通信(NFC)等或其任意组合。子单元的两个或以上可以组合成单个单元，并且子单元中的任何一个可以分为两个或以上子单元。
图30是根据本申请的一些实施例所示的推送用于查找服务请求的推荐信息的示意图。
如图30所示，假设一个城市在地理上划分为N个地理区域，包括Q0、Q1、Q2、......，并且司机处于查找服务请求的状态，其中，点P指的是司机的位置，地理区域Q0指的是司机所在的区域，点P1和点P2分别是地理区域Q1和地理区域Q2的中心点。可以基于点P和候选区域Q1中心点P1来规划行进路径S1。假设从点P到地理区域Q1基于行进路径S1的估算行程时间被确定为0.3小时，并且如果司机进入地理区域Q1收益值估算为18元人民币，则收益值18与估算行程时间0.3小时的比值为60。此外，可以基于点P和Q2的中心点P2来规划行进路径S2。假设从点P到地理区域Q2基于行进路径S2的估算行程时间被确定为0.5小时，如果司机到地理区域Q2的收益值确定为20元，则收益值20与估算行程时间0.5小时的比值为40。如果预设条件是对应于候选区域的收益值与估算行程时间的比值大于预设阈值50，可以将候选区域Q1确定为用于查找服务请求的推荐区域(即，目标区域)，并且可以生成用于查找服务请求的推荐信息，并将其发送到与司机相关联的用户终端。例如，用于查找服务请求的推荐信息可以包括用于查找服务请求的推荐区域Q1的18元人民币的收益值等信息、从司机位置到查找服务请求的推荐区域Q1的估算行程时间0.3小时、建议司机前往查找服务请求的推荐区域Q1等的信息，或其组合。
根据上面的例子，如果预设条件是对应于候选区域收益值对估算行程时间的比值大于预设阈值30，地理区域Q1和地理区域Q2可以被确定为用于查找服务请求的推荐区域。在这种情况下，地理区域可以基于收益值与估算行程时间的比值从高到低来排名，例如从60到40。因此，可以生成用于查找包括推荐地理区域Q1和推荐地理区域Q2的服务请求的推荐信息，其中与区域Q1相关联的信息可以放置在前方位置，这可以方便司机查看。
根据图30中所示的一些实施例，如果确定司机所在的地理区域Q0在0.3小时的收益值是20，并且收益值20与预设时间段的速率是66.66，这大于预设条件50，可以将地理区域Q0确定为用于查找服务请求的推荐区域，用于查找服务请求的推荐信息可以包括地理区域Q0被生成，并且可以建议司机继续在地理区域Q0中查找服务请求。
图31是根据本申请的一些实施例所示的用于推送用于查找服务请求的推荐信息的示例性装置的框图。用于推送用于查找服务请求的推荐信息的装置3100可以包括第三确定模块3110、第二估算模块3120、第四确定模块3130和第二推荐模块3140。在一些实施例中，装置3100可以集成到服务器110中。例如，装置3100可以集成到处理引擎112中。
第三确定模块3110可以被配置用于确定可用服务提供者基于可用服务提供者的位置定位的候选区域。
在本申请的一些实施例中，区域可以在地理上划分为N个地理区域，每个地理区域对应一定范围的地理坐标。在一些实施例中，可以基于从与可用服务提供者相关联的用户终端接收的全球定位系统(GPS)数据来获取可用服务提供者的位置(即，运力调度的司机)。在确定了可用服务提供者的位置之后，可以确定可用服务提供者所在的地理区域。除了可用服务提供者所在的地理区域之外的任何一个(N-1)个地理区域可以被确定为上述候选区域。
如果可用服务提供者在预设时间段内停留在候选区域并且被分配服务请求，第二估算模块3120可以被配置为根据与候选区域的运力调度相关联的交易数据估算收益值。
在一些实施例中，预设时间段可以是从当前时间点到未来时间点的时间段，例如从当前时间点开始的0.5小时。
在一些实施例中，可以基于与候选区域的运力调度相关联的交易数据来确定，如果可用服务提供者在预设时间段内停留在候选区域被分配服务请求的概率和分配给可用服务提供者的服务请求的服务费用。可以确定概率和服务费用的乘积，并且如果可用服务提供者停留在候选区域并且被分配服务请求，则可以将乘积确定为收益值。关于概率和服务费用的确定的更多描述可以在本申请的其他地方找到(例如，图28及其描述)。
在本申请的一些实施例中，由于可用服务提供者位于候选区域，因此在查找服务请求的过程中的行程费用可以忽略不计。
第四确定模块3130可以被配置用于基于收益值与预设时间段的比值满足预设条件的结果，将候选区域确定用于查找服务请求的推荐区域。可以在本申请的其他地方找到对预设条件的更多描述(例如，图26及其描述)。
第二推荐模块3140可以被配置为基于推荐区域生成并发送用于查找服务请求的推荐信息给可用服务提供者相关联的用户终端。
在一些实施例中，查找服务请求的推荐信息可以包括用于查找服务请求的推荐区域的区域信息、用于查找服务请求的推荐区域的收益值、从可用服务提供者的位置到查找服务请求的推荐区域行程费用、从可用服务提供者的位置到查找服务请求的推荐区域估算行程时间等，或其组合。查找服务请求的推荐信息还可以包括建议可用服务提供者去某个候选区域接收服务请求等的信息。
装置3100中的模块可以经由有线连接或无线连接彼此连接或通信。有线连接可以包括金属线缆、光缆、混合电缆等或其任意组合。无线连接可以包括局域网络(LAN)、广域网(WAN)、蓝牙、紫蜂(ZigBee)网络、近场通信(NFC)等或其任意组合。两个或以上模块可以合并成一个模块，以及任意一个模块可以被拆分成两个或以上单元。
本申请还可以提供包括第三指令的第三计算机存储介质。当由至少一个处理器执行时，第三指令可以表明至少一个处理器执行本申请中其他地方描述的过程(例如，流程3200、流程3300)。
图32是根据本申请的一些实施例所示的运力调度的示例性流程图。流程3200可以由按需服务系统100执行。例如，流程3200可以为存储在存储ROM 230或RAM 240中的一组指令(例如，应用程序)实现。处理器220和/或图26-29中的模块和/或单元可以执行该组指令，并且当执行指令时，处理器220和/或模块和/或单元可以被配置以执行流程3200。以下所示过程的操作仅出于说明的目的。在一些实施例中，流程3200可以通过未描述的一个或多个以上附加操作和/或没有所讨论的操作的一个或以上来完成。另外，如图32所示和下面描述的过程操作的顺序不是限制性的。
在3210中，可以确定从可用服务提供者的位置到候选区域的估算行程时间。
在本申请的一些实施例中，一个区域可以在地理上划分为N个地理区域，每个地理区域对应于一定范围的地理坐标。在一些实施例中，可用服务提供者(即与运力调度相关的司机)的位置可以基于从与可用服务提供者相关联的用户终端(例如，提供者终端140)接收的全球定位系统(GPS)数据来获取。在一些实施例中，GPS数据可以由用户终端的GPS芯片组确定。在确定了可用服务提供者的位置之后，可以确定可用服务提供者所在的地理区域。除了可用服务提供者所在的地理区域之外的任何一个(N-1)个地理区域可以被确定为上述候选区域。
在确定可用服务提供者的位置之后，可以根据可用服务提供者的位置坐标和候选区域的坐标范围确定从可用服务提供者到候选区域的位置的行程距离。在本申请的一些实施例中，术语“从可用服务提供者的位置到候选区域的行程距离”是指从可用服务提供者的位置到候选区域的中心点的行程距离，或者从可用服务提供者的位置到候选区域的任何一点的行程距离(例如最靠近可用服务提供者所在地的点)，并且行程距离是指计划导航路径的长度。最后，可以基于可用服务提供者的行程距离和估算的行进速度来确定从可用服务提供者的位置到候选区域的估算行程时间T。
在一些备选实施例中，从可用服务提供者的位置到候选区域确定估算行程时间可以包括以下操作。从可用服务提供者的位置到候选区域的估算行程时间可以响应于由可用服务提供者发起的查找服务请求。如上所述，可用服务提供者可以经由用户终端(例如，提供者终端140)向运力调度服务器(例如，服务器110)发起查找服务请求，其中，可以基于在用户终端上由可用服务提供者执行的查找服务请求的查找操作来生成查找服务请求。运力调度服务器从可用服务提供者收到查找服务请求后，可以根据查找服务请求的操作来确定从可用服务提供者的位置到候选区域的估算行程时间，该服务请求对应于查找服务请求。
在一些替代实施例中，在确定从可用服务提供者的位置到候选区域估算行程时间之前，该方法还可以包括以下操作。响应于由可用服务提供者发起的查找服务请求，在确定从可用服务提供者的位置到候选区域的估算行程时间之前，检测到可用服务提供者等待接收服务请求的时间段大于预设时间阈值(例如，10分钟)，可以发送消息提醒可用服务提供者将查找服务请求发送到系统。预设时间阈值可以根据实际应用来设置，本申请不是限制性的。例如，当运力调度服务器检测到长时间没有将服务请求分配给可用服务提供者时，运力调度服务器可以推送界面信息，用于提醒可用服务提供者向用户终端发送查找服务请求，以提高可用服务提供者的查找服务请求的效率。
在3220中，如果可用服务提供者前往候选区域并且被分配服务请求，则可以根据与候选区域的运力调度相关联的交易数据来估算收益值。
与候选区域的运力调度相关联的交易数据可以是基于与候选区域中的运力调度相关联的服务请求而生成的各种类型的交易数据，例如与运力调度相关的服务请求的历史数据，包括但不限于各种历史时间段内的历史数据，例如，与运力调度相关的服务请求、平均服务费用、可用服务提供者数量、运力不足等。
在一些备选实施例中，步骤3220可以包括步骤3201和步骤3202。
在3201中，如果可用服务提供者到达候选区域，则可以基于与候选区域的运力调度相关联的交易数据来确定可用服务提供者被分配服务请求的概率和分配给可用服务提供者的服务请求的服务费用。
在一些备选实施例中，可以将候选区域中的服务请求的平均服务费用确定为分配给可用服务提供者的服务请求的服务费用。
在一些备选实施例中，基于与候选区域的运力调度相关联的交易数据，可以从至少两个历史服务费用获取具有最高出现频率的服务费用，并且可以将其确定为分配给可用服务提供者的服务请求的服务费用。
在一些备选实施例中，可以基于与候选区域的运力调度相关联的交易数据来获取候选区域中的至少两个历史服务费用的分布，并且，在至少两个服务费用间隔中历史服务费用的数量最大的特定服务费用间隔可以被识别并确定为分配给可用服务提供者的服务请求的服务费用。
在一些备选实施例中，步骤3201可以包括步骤3211、步骤3221和步骤3231。
在3211中，可以基于估算行程时间确定预测时间段。
在一些实施例中，预测时间段可以是在估算的时间点之前的时间段或估算的时间点之后的时间段，在该估算时间点，可用服务提供者在估算行程时间到达候选区域。例如，如果可用服务提供者到达候选区域的估算时间点是在M日的上午10点，预测时间段可以被确定为从M日的上午10点到11点的一小时。
在3221中，可以基于与候选区域的运力调度相关联的交易数据来确定候选区域内的运力不足数量和候选区域的可用服务提供者的数量。
在本申请的一些实施例中，可以在与预测时间段对应的至少一个历史时间段中基于与运力调度相关联的交易数据来预测运力不足数量和可用服务提供者的数量。
在一些实施例中，可以基于与预测时间段对应的至少一个历史时间段中与运力调度相关联的交易数据来预测候选区域的平均运力不足数量和候选区域的可用服务提供者的平均数量，并且可以确定在预测时间段内的候选区域中的运力不足数量和候选区域的可用服务提供者的数量。例如，如果基于估算行程时间确定的预测时间段是在M日的上午10：00到11：00之间，可以基于服务请求据在候选区域Q中，在M天前的K天和天数“K”之间的上午10：00到11：00之间确定候选区域的平均运力不足和候选区域中可用服务提供者的平均数量，平均运力不足数量和可用服务提供者的平均数量可分别确定为候选区域内运力不足数量和候选区域的可用服务提供者的数量。另外，预测时间段中的运力不足数量和可用服务提供者的数量可以基于与运力调度相关联的交易数据在等于预测时间段的任何其他历史时间段中确定。
在3231中，可以确定运力不足数量对可用服务提供者的数量的比值，并且可以将该比值确定为可用服务提供者在候选区域中被分配服务请求的概率。
根据上面的例子，如果确定候选区域Q中在上午10：00至11：00之间的运力不足数量为100且可用服务提供者的数量为200，则在候选区域Q中可用服务提供者被分配服务请求的概率可以被确定为100/200(即，0.5)。
应当注意，可用服务提供者被分配服务请求的概率也可能受到可用服务提供者的信用评分或评级的影响。例如，对于特定的候选区域，对于可用服务提供信用评分相对较高或评分较高的人，他或她被分配服务请求的概率相对较高；而对于信用评分相对较差或评级相对较低的可用服务提供者，他或她被分配服务请求的概率相对较低。如这里所使用的，可以基于至少两个因素来确定可用服务提供者的信用评分或评级，诸如历史服务交易的数量、提供服务的拒绝数量、出租车服务质量、与将乘客送达目的地相关联的及时性信息、乘客提供的评估信息等，或其组合。由于确定信用评分的过程或可用服务提供者的评级对于本领域普通技术人员是显而易见的，因此这里不再详细描述。
在一些替代实施例中，运力调度服务器可以为候选区域中具有相对较好的信用评分或相对较高的评级的可用服务提供者提供优先权，因此对于可用服务提供者，其信用评分相对较高或评分较高，他或她被分配服务请求的概率可能高于运力不足数量对可用服务提供者的数量，而对于可用服务提供者，信用评分相对较差或评分较低，他或她被分配服务请求的概率可能低于运力不足数量对可用服务提供者的数量。例如，如果确定可用服务提供者在候选区域中被分配服务请求的平均概率为0.5，则可用服务提供者具有相对较好的信用评分或相对较高评级的服务请求的概率可高于0.5(例如0.8)，然而，可用服务提供者具有相对较差的信用评分或相对较低评级的被分配服务请求的概率可以低于0.5(例如，0.3)。
在3202中，如果可用服务提供者前往候选区域并且被分配服务请求，则可以基于概率和服务费用来确定收益值。
在一些实施例中，步骤3202可以包括步骤3212、步骤3222和步骤3232。
在3212中，可以确定可用服务提供者被分配服务请求的概率和服务请求的服务费用的乘积。
在3222中，可以确定从可用服务提供者的位置行进到候选区域的可用服务提供者的行程费用。
在一些实施例中，可用服务提供者的位置可以确定为上车位置，可以将候选区域中的任何一点确定为目的地，并且可以根据上车位置和目的地基于计划路线确定行程费用。
在3232中，可以通过从乘积中减去行程费用来确定差值，并且如果可用服务提供者前往候选区域并且被分配服务请求，则可以将差值确定为收益值。
在一些替代实施例中，操作3202可以进一步包括在预设时间段内基于与候选区域的运力调度相关联的交易数据，确定可用服务提供者在候选区域中被分配服务请求的概率和分配给可用服务提供者的服务请求的服务费用。可以计算概率和服务费用的乘积，并且如果可用服务提供者前往候选区域并且被分配服务请求，则可以将乘积确定为收益值。
在一些备选实施例中，如果可用服务提供者前往候选区域并且被分配服务请求，则可以将服务请求的服务费用直接确定为收益值。例如，如果可用服务提供者是VIP司机，则运力调度服务器可以优先将服务请求分配给司机，VIP司机被分配服务请求的概率可以视为1。
在3230中，可以基于收益值对估算行程时间的比值满足预设条件的确定结果，将候选区域确定为用于查找服务请求的推荐区域。
在一些实施例中，预设条件可以指的是“候选区域”的收益值与估算行程时间的比值在所有候选区域的收益值率的降序排名的前N(N≥1)中。
在一些备选实施例中，预设条件可以指的是候选区域的收益值与估算行程时间的比值大于预设阈值。
在3240，可以生成用于查找服务请求的推荐信息，并基于推荐区域将其发送到与可用服务提供者相关联的用户终端。
在一些实施例中，用于查找服务请求的推荐信息可以是包括用于查找服务请求的推荐区域的区域信息、用于查找服务请求的推荐区域的收益值、从可用服务提供者的位置到用于查找服务的推荐区域的行程费用请求数、从可用服务提供者的位置到用于查找服务请求的推荐区域估算行程时间等，或其组合。查找服务请求的推荐信息还可以包括建议可用服务提供者前往某个候选区域接收服务请求等的信息。
在一些实施例中，确定的用于查找服务请求的一个或以上推荐区域可以根据一个或以上推荐区域对应的收益值与估算行程时间的比值从高到低排序，并且可以生成用于查找服务请求的推荐信息，并基于排序的一个或以上推荐区域将其发送到与可用服务提供者相关联的用户终端。
应该注意的是，上述仅出于说明性目的而提供，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，根据本申请的教导可以做出多种变化和修改。然而，变化和修改不会背离本申请的范围。
图33是根据本申请的一些实施例所示的运力调度的示例性流程图。流程3300可以由按需服务系统100执行。例如，流程3300可以为存储在存储ROM 230或RAM 240中的一组指令(例如，应用程序)实现。处理器220和/或图31中的模块可以执行指令集，并且当执行指令时，处理器220和/或模块可以被配置用于执行处理3300。以下所示过程的操作仅出于说明的目的。在一些实施例中，流程3300可以通过未描述的一个或多个以上附加操作和/或没有所讨论的操作的一个或以上来完成。另外，如图33所示和下面描述的过程操作的顺序不是限制性的。
在3310中，可以基于可用服务提供者的位置来确定可用服务提供者所在的候选区域。
在本申请的一些实施例中，区域可以在地理上划分为N个地理区域，每个地理区域对应于特定范围的地理坐标。在一些实施例中，可以基于从与可用服务提供者相关联的用户终端接收的全球定位系统(GPS)数据来获取可用服务提供者的位置(即，运力调度的司机)。在确定了可用服务提供者的位置之后，可以确定可用服务提供者所在的地理区域。除了可用服务提供者所在的地理区域之外的任何一个(N-1)个地理区域可以被确定为上述候选区域。
在3320中，如果可用服务提供者在预设时间段内停留在候选区域并且被分配服务请求，则可以根据与候选区域的运力调度相关联的交易数据来估算收益值。
在一些实施例中，预设时间段可以是从当前时间点到未来时间点的时间段，例如从当前时间点开始的0.5小时。
在一些实施例中，如果可用服务提供者在预设时间段内停留在候选区域，可以基于与候选区域的运力调度相关联的交易数据确定可用服务提供者被分配服务请求的概率，以及分配给可用服务提供者的服务请求的服务费用。可以确定概率和服务费用的乘积，并且如果可用服务提供者停留在候选区域并且被分配服务请求，则可以将乘积确定为收益值。关于概率和服务费用的确定的更多描述可以在本申请的其他地方找到(例如，操作3201及其描述)。
在本申请的一些实施例中，由于可用服务提供者位于候选区域，因此在查找服务请求的过程中的行程费用可以忽略不计。
在3330中，可以基于收益值对预设时间段的比值满足预设条件的确定结果，将候选区域确定为用于查找服务请求的推荐区域。可以在本申请的其他地方找到对预设条件的更多描述(例如，图26及其描述)。
在3340，可以基于推荐区域生成用于查找服务请求的推荐信息，并将其发送到与可用服务提供者相关联的用户终端。
应该注意的是，上述仅出于说明性目的而提供，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，根据本申请的教导可以做出多种变化和修改。然而，变化和修改不会背离本申请的范围。
图34是根据本申请的一些实施例所示的示例性处理引擎的框图。处理引擎112可包括目标区域确定模块3402、非忙碌区域确定模块3404和调度模块3406。
目标区域确定模块3402可以被配置用于确定目标区域，其中满足预设条件的至少两个服务请求从目标区域发起。可以通过与至少两个服务请求者相关联的至少两个用户终端来发起至少两个服务请求。如这里所使用的，预设条件可以与目标区域的运力相关联。如本申请中其他地方所述，运力可以与目标区域中的可用服务提供者的数量和目标区域中待分配的服务请求数相关联。在一些实施例中，预设条件可以是目标区域中的可用服务提供者的数量小于从目标区域发起的至少两个服务请求的数量。
非忙碌区域确定模块3404可以被配置为基于目标区域的信息确定非忙碌区域，非忙碌区域包括一个或以上可以自由接受服务请求的可用服务提供者。在一些实施例中，如结合图7所描述的，非忙碌区域确定模块3404可以基于目标区域的边界(例如，矩形边界)来确定非忙碌区域。在一些实施例中，如结合图18所描述的，非忙碌区域确定模块3404可以随机选择目标区域附近的候选区域作为非忙碌区域。如这里所使用的，“附近”指的是候选区域的中心点与目标区域的中心点之间的距离小于距离阈值。
调度模块3406可以被配置为通过网络将与至少两个服务请求相关联的调度指令发送到与非忙碌区域中的一个或以上可用服务提供者中的至少一个相关联的用户终端。调度指令可以包括询问非忙碌区域中的一个或以上可用服务提供者中的至少一个是否同意前往目标区域的信息，其中，通过用户终端执行的应用程序的图形用户界面显示调度指令的至少一部分。
处理引擎112中的模块可以通过有线连接或无线连接以互相连接或互相通信。有线连接可以包括金属线缆、光缆、混合电缆等或其任意组合。无线连接可以包括局域网络(LAN)、广域网(WAN)、蓝牙、紫蜂(ZigBee)网络、近场通信(NFC)等或其任意组合。两个或以上模块可以合并成一个模块，以及任意一个模块可以被拆分成两个或以上单元。
图35是根据本申请的一些实施例所示的运力调度的示例性流程图。流程3500可以由按需服务系统100执行。例如，流程3500可以为存储在存储ROM 230或RAM 240中的一组指令(例如，应用程序)实现。处理器220和/或图34中的模块可以执行指令集，并且当执行指令时，处理器220和/或模块可以被配置以执行处理3500。以下所示过程的操作仅出于说明的目的。在一些实施例中，流程3500可以通过未描述的一个或多个以上附加操作和/或没有一个或以上所讨论的操作来完成。另外，如图35所示和下面描述的过程操作的顺序不是限制性的。
在3502中，处理引擎112(例如，目标区域确定模块3402)(例如，处理器220的处理电路)可以确定目标区域，其中满足预设条件的至少两个服务请求从目标区域发起。可以通过与至少两个服务请求者相关联的至少两个用户终端(例如，请求者终端130)来发起至少两个服务请求。如这里所使用的，预设条件可以与目标区域的运力相关联。如本申请中其他地方所述，运力可以与目标区域中的可用服务提供者的数量和在目标区域中待分配的服务请求数相关联。在一些实施例中，预设条件可以是目标区域中的可用服务提供者的数量小于从目标区域发起的至少两个服务请求的数量。
在一些实施例中，为了确定目标区域，处理引擎112可以通过使用聚类算法(例如，Dbscan算法)基于目标半径和目标服务请求数将预设区域(例如，城市、地区、地理区域)划分为至少两个候选区域。在一些实施例中，处理引擎112可以基于预设区域中的建筑物的分布将预设区域划分为至少两个候选区域。此外，处理引擎112可以基于与运力相关联的一个或以上参数从至少两个候选区域中选择目标区域。关于该区域划分的更多描述可以在本申请的其他地方找到(例如，图4-9、18-19及其描述)。
以特定候选区域为例，如结合图6-9所述：处理引擎112可以确定候选区域的分配率是否小于分配率阈值(例如，预设分配率)。根据确定分配率小于分配率阈值的结果，处理引擎112可以确定在候选区域中的可用服务提供者的数量与在候选区域中待分配的服务请求的数量之比是否小于比值阈值(例如，可用服务提供者的数量与待分配的服务请求的数量的估算比值)。根据确定候选区域中可用服务提供者的数量与在候选区域中待分配的服务请求数的比值小于阈值的比值的结果，处理引擎112可以将候选区域确定为目标区域。
还以特定候选区域为例，如结合图18所述：处理引擎112可以将来自至少两个候选区域中缺乏服务提供者的区域识别为目标区域。如本文所用，术语“缺乏服务提供者”是指区域中可用服务提供者的数量与在区域中待分配的服务请求数之比小于预设的阈值或者区域中的可用服务提供者的数量小于在区域中待分配的服务请求数。
在3504中，处理引擎112(例如，非忙碌区域确定模块3404)(例如，处理器220的处理电路)可以根据目标区域的信息确定非忙碌区域，该非忙碌区域包括可以自由接受服务请求的一个或以上可用服务提供者。
在一些实施例中，如结合图7所描述的，处理引擎112可以基于目标区域的边界(例如，矩形边界)来确定非忙碌区域。处理引擎112可以获取与目标区域相关联的扩展参数，并基于扩展参数确定调整边界(例如，新边界)。此外，处理引擎112可以基于调整边界确定非忙碌区域。例如，处理引擎112可以确定目标区域的调整边界和边界之间的区域差异，并将区域差异确定为非忙碌区域。可以在本申请的其他地方找到更多描述(例如，图7及其描述)。
在一些实施例中，扩展参数可以是按需服务系统100的默认设置，或者可以在不同情况下是可调节的。例如，正如具有普通技能的人员所理解的，在高峰时段，扩展参数可能相对较大，正如具有普通技能的人员所理解的，而在非高峰时段，扩展参数可能相对较小。又例如，扩展参数可以与可用服务提供者的数量与在目标区域中待分配的服务请求的数量之比相关。比值越大，扩展参数可能越小；比值越小，扩展参数可能越大。
在一些实施例中，如结合图18所描述的，处理引擎112可以随机选择目标区域附近的候选区域作为非忙碌区域。如这里所使用的，“附近”指的是候选区域的中心点与目标区域的中心点之间的距离小于距离阈值。
在3506中，处理引擎112(例如，调度模块3406)(例如，处理器220的处理电路)可以将与该至少两个服务请求相关联的调度指令经由网络(例如，网络120)发送到与非忙碌区域中的一个或以上可用服务提供者中的至少一个相关联的用户终端(例如，提供者终端140)。调度指令可以包括询问非忙碌区域中的一个或以上可用服务提供者中的至少一个是否同意前往目标区域的信息。调度指令还可以包括诸如与目标区域相关联的交通状况、从一个或以上可用服务提供者中的至少一个的位置到目标区域的估算路线等信息。
在一些实施例中，调度指令可以以文本、图表、图像、音频、视频等的格式或其组合来表达。在一些实施例中，可以经由用户终端(例如，提供者终端140)执行的应用的图形用户界面来显示调度指令的至少一部分。例如，用户终端可以在图形用户界面上显示包括一个或以上用户界面元素(例如，“确认”按钮、“拒绝”按钮)的界面消息。又如例，处理引擎112可以在图形用户界面上显示从一个或以上可用服务提供者中的至少一个的位置到目标区域的路线。
此外，响应于从与非忙碌区域中的至少一个或以上可用服务提供者相关联的用户终端接收的调度指令的接受，处理引擎112可以将至少两个服务请求中的至少一个的信息(例如，起始位置、目的地)发送到与非忙碌区域中的一个或以上可用服务提供者中的至少一个相关联的用户终端。在一些实施例中，至少两个服务请求中的至少一个的起始位置可以是与至少两个服务请求中的至少一个相关联的用户终端(例如，请求者终端130)的位置，这可以根据请求者终端130发送的GPS数据来确定。
在一些实施例中，如结合图8所述，处理引擎112可识别目标区域中的调度位置(也称为“核心位置”)，其中，调度位置的预设范围(例如，100米、200米、500米、1千米)内的服务请求密度大于密度阈值。如这里所使用的，区域的服务请求密度是指区域中服务请求的数量与区域的面积的比值。处理引擎112可以进一步确定所述一个或以上可用服务提供者中的至少一个的位置与调度位置之间的距离，并确定该距离是否小于距离阈值。根据确定距离小于距离阈值的结果，处理引擎112可以将调度位置的信息(例如，地址信息)发送到与一个或以上可用服务提供者中的至少一个相关联的用户终端。调节位置的更多描述可以在本申请的其他地方找到(例如，图8及其描述)。
在一些实施例中，如结合图19所描述的，处理引擎112可以确定在非忙碌区域中从一个或以上可用服务提供者中的至少一个的用户终端接收到调度指令的接受的第一时间点或者非忙碌区域中的至少一个或以上可用服务提供者到达目标区域的第二时间点。处理引擎112可以基于预设时间段(例如，预设服务时间段)和第一时间点或第二时间点中的至少一个确定非忙碌区域中的一个或以上可用服务提供者中的至少一个的服务时间段，在服务时间段内，将从目标区域发起的至少一个服务请求的信息发送到与非忙碌区域中的一个或以上可用服务提供者中的至少一个相关联的用户终端。服务时间段的更多描述可以在本申请的其他地方找到(例如，图19及其描述)。
在一些实施例中，如结合图19所描述的，处理引擎112可以确定第一时间点(即，接收到调度指令的接受的时间点)和第二时间点(即非忙碌区域中的至少一个或以上可用服务提供者到达目标区域的时间点)之间的时间间隔。处理引擎112可以确定时间间隔是否小于时间间隔值，并基于确定时间间隔小于时间间隔阈值的结果将表示奖励的信息发送到与非忙碌区域中的一个或以上可用服务提供者相关联的用户终端执行的应用程序。奖励可包括折扣、现金奖励、凭证等。
在一些实施例中，如结合图19所描述的，处理引擎112可以将调度指令发送到与非忙碌区域中的一个或以上可用服务提供者相关联的一个或以上用户终端，并且可以接收一个或以上接受，表示一个或以上可用服务提供者同意从非忙碌区域中进入目标区域。处理引擎112可以进一步确定所接收的一个或以上接受的数量是否大于预设阈值。根据确定一个或以上接受的数量大于预设阈值的结果，处理引擎112可以停止将调度指令发送到与非忙碌区域中的一个或以上可用服务提供者相关联的一个或以上用户终端。
在一些实施例中，如结合图32所述，如果一个或以上可用服务提供者中的至少一个到达目标区域，处理引擎112可以确定从所述一个或以上可用服务提供者中的至少一个的位置到所述目标区域估算行程时间，以及一个或以上可用服务提供者进入目标区域的收益值。处理引擎112可以进一步确定收益值对估算行程时间的比值是否大于比值阈值。根据确定收益值对估算行程时间的比值大于阈值的结果，处理引擎112将与至少两个服务请求相关联的调度指令发送到由与一个或以上可用服务提供者中的至少一个相关联的用户终端执行的应用程序。在一些实施例中，处理引擎112可以基于从一个或以上可用服务提供者中的至少一个的位置前往目标区域的行程费用、如果一个或以上可用服务提供者中的至少一个到达目标区域一个或以上可用服务提供者被分配服务请求的概率、和/或如果一个或以上可用服务提供者中的至少一个到达目标区域分配给一个或以上可用服务提供者中的至少一个的服务请求的服务费用，确定收益值。可以在本申请的其他地方找到更多描述(例如，图32及其描述)。
应该注意的是，上述仅出于说明性目的而提供，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，根据本申请的教导可以做出多种变化和修改。然而，变化和修改不会背离本申请的范围。例如，可以在示例性流程3500中的其他地方添加一个或以上其他可选操作(例如，存储操作)。在存储操作中，处理引擎112可以在本申请中其他地方披露的任何存储装置(例如，存储器150)中存储目标区域、服务提供者的数量和/或至少两个服务请求的数量。
图36是根据本申请的一些实施例所示的用于确定目标半径和目标服务请求数的示例性流程图。流程3600可以由按需服务系统100执行。例如，流程3600可以为存储在存储ROM 230或RAM 240中的一组指令(例如，应用程序)实现。处理器220和/或目标区域确定模块3402可以执行该组指令，并且当执行指令时，处理器220和/或目标区域确定模块3402可以被配置用于执行流程3600。以下所示过程的操作仅出于说明的目的。在一些实施例中，流程3600可以通过未描述的一个或多个以上附加操作和/或没有所讨论的操作的一个或以上来完成。另外，如图36所示和下面描述的过程操作的顺序不是限制性的。在一些实施例中，可以基于流程3600来执行流程3500的步骤3502。
在3602中，处理引擎112(例如，目标区域确定模块3402)(例如，处理器220的处理电路)可以确定至少两个数据对，至少两个数据对中的每一个包括预设半径和预设的服务请求数。如这里所使用的，预设半径和预设的服务请求数指的是与聚类操作(例如，Dbscan算法)相关联的两个参数。如本申请中其他地方所述，根据Dbscan算法，可以基于这两个参数将区域划分为至少两个区域，至少两个区域的每个半径小于预设半径，并且区域中的服务请求数大于预设的服务请求数。
在一些实施例中，每个数据对中的预设半径和预设服务请求数可以是按需服务系统100的默认设置，或者可以在不同情况下调整。以特定的数据对为例，如结合图15A-15D所述，处理引擎112可以分别根据等式(4)和等式(5)确定预设半径和预设的服务请求数。
在3604中，处理引擎112(例如，目标区域确定模块3402)(例如，处理器220的处理电路)可以基于聚类算法(例如，Dbscan算法)确定对应于至少两个数据对的至少两个分布熵。以特定数据对为例，处理引擎112可根据等式(1)确定对应于特定数据对的分布熵。
在3606中，处理引擎112(例如，目标区域确定模块3402)(例如，处理器220的处理电路)可识别至少两个分布熵中的最大分布熵。
在3608中，处理引擎112(例如，目标区域确定模块3402)(例如，处理器220的处理电路)可以选择至少两个数据对中对应于最大分布熵的数据对。
在3610中，处理引擎112(例如，目标区域确定模块3402)(例如，处理器220的处理电路)可以确定对应于所选择的数据对的预设半径和预设的服务请求数，将其作为目标半径和目标服务请求数。
Dbscan算法和分布的更多描述可以在本申请的其他地方找到(例如，图15A-15D及其描述)。
应该注意的是，上述仅出于说明性目的而提供，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，根据本申请的教导可以做出多种变化和修改。然而，变化和修改不会背离本申请的范围。
上文已对基本概念做了描述，显然，对于阅读此申请后的本领域的普通技术人员来说，上述发明披露仅作为示例，并不构成对本申请的限制。虽然此处并没有明确说明，本领域技术人员可以对本申请进行各种修改、改进和修正。该类修改、改进和修正在本申请中被建议，所以该类修改、改进、修正仍属于本申请示范实施例的精神和范围。
同时，本申请使用了特定词语来描述本申请的实施例。例如，术语“一个实施例”、“一些实施例”和/或“一些实施例”表示特定特征，结合一些实施例描述的结构或特征包括在本申请的至少一个实施例中。因此，应强调并注意的是，本说明书中在不同位置两次或以上提及的“一实施例”、“一个实施例”或“一替代性实施例”并不一定是指同一实施例。此外，本申请的一个或以上实施例中的某些特征、结构或特性可以进行适当的组合。
此外，本领域的技术人员可以理解，本申请的各方面可以通过若干具有可专利性的种类或情况进行说明和描述，包括任何新的和有用的制程、机器、产品或物质的组合，或对其任何新的和有用的改良。相应地，本申请的各个方面可以完全由硬件执行、可以完全由软件(包括固件、常驻软件、微码等)执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“数据块”、“模块”、“引擎”、“单元”、“组件”或“系统”。此外，本申请的各方面可以采取体现在一个或以上计算机可读介质中的计算机程序产品的形式，其中计算机可读程序代码包含在其中。
计算机可读信号介质可能包含一个内含有计算机程序代码的传播数据信号，例如在基带上或作为载波的一部分。此类传播信号可以有多种形式，包括电磁形式、光形式等或任何合适的组合。计算机可读信号介质可以是除计算机可读存储介质之外的任何计算机可读介质，该介质可以通过连接至一个指令执行系统、装置或设备以实现通信、传播或传输供使用的程序。位于计算机可读信号介质上的程序代码可以通过任何合适的介质进行传播，包括无线电、电缆、光纤缆线、RF、或类似介质、或任何上述介质的组合。
本申请各部分操作所需的计算机程序代码可以用任意一种或以上程序设计语言编写，包括面向对象程序设计语言如Java、Scala、Smalltalk、Eiffel、JADE、Emerald、C++、C#、VB.NET、Python等，常规程序化程序设计语言如C程序设计语言、Visual Basic、Fortran2003、Perl、COBOL 2002、PHP、ABAP，动态程序设计语言如Python、Ruby,和Groovy，或其他程序设计语言等。程序代码可以完全在用户计算机上运行、或作为独立的软件包在用户计算机上运行、或部分在用户计算机上运行部分在远程计算机上运行、或完全在远程计算机或服务器上运行。在后种情况下，远程计算机可以通过任何网络形式与用户计算机连接，比如局域网络(LAN)或广域网(WAN)，或连接至外部计算机(例如，通过互联网使用互联网服务提供者)，或在云计算环境中，或作为服务使用如软件即服务(SaaS)。
然而，这些修正和改变仍然在本申请的保护范围之内。此外，处理元素或者序列的列举顺序、数字、字母或者其他名称的使用不是用于限制要求的过程和方法的。尽管上述申请中通过各种示例讨论了一些目前认为有用的发明实施例，但应当理解，此类细节仅起说明的目的，附加的申请专利范围并不仅限于申请的实施例，相反，申请专利范围旨在覆盖所有符合本申请实施例精神和范围的修正和等价组合。例如，虽然以上所描述的系统组件可以通过硬件装置实现，但是也可以只通过软件的解决方案得以实现，如在现有的服务器或移动装置上安装所描述的系统。
同理，应当注意的是，为了简化本申请揭示的表述，从而帮助对一个或以上发明实施例的理解，前文对本申请实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。然而，本申请的该方法不应被解释为反映所声称的待扫描对象物质需要比每个权利要求中明确记载的更多特征的意图。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

Claims (71)

1.一种基于服务请求分布的运力调度方法，包括：
确定目标半径和目标服务请求数；
基于所述目标半径和所述目标服务请求数，将区域划分为至少两个候选区域；
确定所述至少两个候选区域中的至少一个是否健康；
基于确定所述至少两个候选区域中的至少一个不健康的结果，确定调度指令；
基于所述至少两个候选区域中的至少一个，确定至少一个可用服务提供者；以及
基于所述调度指令，将所述至少一个可用服务提供者调度至所述至少两个候选区域中的至少一个。
2.根据权利要求1所述的方法，其特征在于，确定所述目标半径和所述目标服务请求数包括：
定义最大半径和最小服务请求数；
确定至少两个第一区域，所述至少两个第一区域中的每一个具有小于或等于所述最大半径的半径；
在所述至少两个第一区域中，确定至少两个第二区域，所述至少两个第二区域中的每一个的服务请求数大于所述最小服务请求数；
根据预设等式，基于所述至少两个第二区域中服务请求的总数，确定分布熵；
确定使所述分布熵最大化的服务请求数作为服务请求的实际数量；以及
根据所述服务请求的实际数量，确定所述目标半径和所述目标服务请求数，其中，所述预设等式为：
Figure FDA0002306194820000021
其中，Er,m是所述分布熵，Pi是第i个第二区域中的服务请求的数量与在所述至少两个第二区域中的所述服务请求的总数量的比值，以及n是所述至少两个第二区域的数量。
3.根据权利要求1所述的方法，其特征在于，确定所述至少两个候选区域中的至少一个是否健康包括：
确定所述至少两个候选区域中的至少一个的分配率以及所述至少两个候选区域中的至少一个中的可用服务提供者的数量与待分配服务请求数的比值；
确定所述分配率是否小于预设分配率；
根据所述分配率小于所述预设分配率的确定结果，确定所述至少两个候选区域中的至少一个的估算分配率；
根据所述估算分配率，确定所述可用服务提供者的数量与所述待分配服务请求数的估算比值；
确定所述可用服务提供者的数量与所述待分配服务请求数的所述比值是否小于所述可用服务提供者的数量与所述待分配服务请求数的所述估算比值；以及
基于确定的结果，即所述可用服务提供者的数量与所述待分配服务请求数的所述比值小于所述可用服务提供者的数量与所述待分配服务请求数的所述估算比值，确定所述至少两个候选区域中的至少一个是不健康的。
4.根据权利要求1所述的方法，其特征在于，基于所述至少两个候选区域中的至少一个，确定所述至少一个可用服务提供者，包括：
确定所述至少两个候选区域中的至少一个的矩形边界；
通过从所述矩形边界扩展区域确定新的矩形边界；
在所述矩形边界和所述新矩形边界之间的区域差异中确定服务提供者；以及
确定满足预设条件的所述服务提供者中的至少一个作为所述至少一个可用服务提供者，
其中所述预设条件是在所述服务提供者中的至少一个的位置的第一预设范围内的服务请求数小于第一预设服务请求数，以及所述服务提供者中的至少一个的所述位置不在具有高请求密度的区域中。
5.根据权利要求1至4任一项所述的方法，其特征在于，基于所述调度指令，将所述至少一个可用服务提供者调度至所述至少两个候选区域中的至少一个包括：
确定所述至少两个候选区域中的至少一个的核心位置，其中，在所述核心位置的第二预设范围内的服务请求数大于第二预设服务请求数；
获取所述核心位置的地址信息；以及
根据所述调度指令和所述核心位置的地址信息，将所述至少一个可用服务提供者调度至所述核心位置。
6.根据权利要求5所述的方法，其特征在于，获取所述核心位置的所述地址信息包括：
获取所述核心位置的纬度和经度；以及
根据所述核心位置的经度和维度，确定所述核心位置的所述地址信息，其中所述核心位置的所述地址信息包括区、街道和商业区。
7.一种基于服务请求分布的运力调度系统，包括：
确定模块，被配置为确定目标半径和目标服务请求数；
划分模块，被配置为基于所述目标半径和所述目标服务请求数，将区域划分为至少两个候选区域；
判断模块，被配置为确定所述至少两个候选区域中至少一个是否健康；
启动模块，被配置为基于确定所述至少两个候选区域中的至少一个不健康的结果启动调度指令；
服务提供者确定模块，被配置为基于所述至少两个候选区域中的至少一个，确定至少一个可用服务提供者；以及
调度模块，被配置为基于所述调度指令，将所述至少一个可用服务提供者调度至所述至少两个候选区域中的至少一个。
8.根据权利要求7所述的系统，其特征在于，所述确定模块包括：
定义单元，被配置为定义最大半径和最小服务请求数；
判断单元，被配置为确定至少两个第一区域，所述至少两个第一区域中的每一个具有小于或等于所述最大半径的半径，并在所述至少两个第一区域中，确定至少两个第二区域，所述至少两个第二区域中的每一个的服务请求数大于所述最小服务请求数；以及
第一计算单元，被配置为根据预设等式，基于所述至少两个第二区域中服务请求的总数，确定分布熵，并确定使所述分布熵最大化的服务请求数作为服务请求的实际数量；
其中，所述确定模块被配置为根据所述服务请求的实际数量，确定所述目标半径和所述目标服务请求数；
其中所述预设等式为：
Figure FDA0002306194820000051
其中，Er,m是所述分布熵，Pi是第i个第二区域中的服务请求的数量与在所述至少两个第二区域中的所述服务请求的总数量的比值，以及n是所述至少两个第二区域的数量。
9.根据权利要求7所述的系统，其特征在于，所述判断模块包括：
获取单元，被配置为确定所述至少两个候选区域的至少一个的分配率以及所述至少两个候选区域中的至少一个中的可用服务提供者的数量与待分配服务请求数的比值；
其中，所述判断模块被配置为确定所述分配率是否小于预设分配率；以及
设置单元，被配置为根据所述分配率小于所述预设分配率的确定结果，确定所述至少两个候选区域中的至少一个的估算分配率；
其中，所述获取单元进一步被配置为基于所述估算分配率，确定所述可用服务提供者的数量与所述待分配服务请求数的估算比值，
其中，所述判断模块进一步被配置为确定所述可用服务提供者的数量与所述待分配服务请求数的比值是否小于所述可用服务提供者的数量与所述待分配服务请求数的估算比值；以及
基于确定的结果，即所述可用服务提供者的数量与所述待分配服务请求数的比值小于所述可用服务提供者的数量与所述待分配服务请求数的估算比值，确定所述至少两个候选区域中的至少一个是不健康的。
10.根据权利要求7所述的系统，其特征在于，所述服务提供者确定模块包括：
第二计算单元，被配置为确定所述至少两个候选区域中的至少一个的矩形边界；以及
其中，所述服务提供者确定模块被配置为通过从所述矩形边界扩展区域来确定新的矩形边界；
在所述矩形边界和所述新矩形边界之间的区域差异中确定服务提供者；以及
确定满足预设条件的所述服务提供者中的至少一个作为所述至少一个可用服务提供者，
其中所述预设条件是在所述服务提供者中的至少一个的位置的第一预设范围内的服务请求数小于第一预设服务请求数，以及所述服务提供者中的至少一个的所述位置不在具有高请求密度的区域中。
11.根据权利要求7至10任一项所述的系统，其特征在于，所述调度模块包括：
核心位置确定单元，被配置为确定所述至少两个候选区域中的至少一个的核心位置，其中，在所述核心位置的第二预设范围内的服务请求数大于第二预设服务请求数；以及
地址信息获取单元，被配置为获取所述核心位置的地址信息，
其中，所述调度模块被配置为根据所述调度指令和所述核心位置的地址信息，将所述至少一个可用服务提供者调度到所述核心位置。
12.根据权利要求11所述的系统，其特征在于，所述地址信息获取单元被配置为：
获取所述核心位置的纬度和经度；以及
根据所述核心位置的纬度和经度，确定所述核心位置的所述地址信息，其中所述核心位置的所述地址信息包括区、街道和商业区。
13.一种计算机装置，包括存储装置、处理器和存储在所述存储装置中并由所述处理器执行的一组指令，其中，当执行所述组指令时，所述处理器被配置为执行权利要求1-6之一的基于服务请求分布的运力调度方法的操作。
14.一种计算机可读介质，包含一组指令，其中，当由处理器执行时，使所述处理器执行权利要求1-6之一的基于服务请求分布的运力调度方法的操作。
15.一种分配服务请求的方法，包括：
响应于检测到目标区域缺少服务提供者，将调度指令发送至与所述目标区域相关的候选服务区域中的一个或以上可用服务提供者，其中，所述调度指令被配置为请求所述一个或以上可用服务提供者回应，以表明所述一个或以上可用服务提供者是否同意前往所述目标区域；以及
响应于表明所述一个或以上可用服务提供者同意前往所述目标区域的一个或以上接受，将所述目标区域的服务请求分配给所述一个或以上可用服务提供者。
16.根据权利要求15所述的方法，其特征在于，确定与所述目标区域相关的所述候选服务区域包括：
获取所述目标区域附近的服务区域的运力；以及
确定具有丰富运力的所述服务区域中的至少一个作为所述候选服务区域。
17.根据权利要求15所述的方法，其特征在于，将所述目标区域中的所述服务请求分配给所述一个或以上可用服务提供者包括：
基于预设时间段以及收到来自所述一个或以上可用服务提供者中的至少一个接受调度指令的第一时间点，或者所述一个或以上可用服务提供者中的至少一个到达所述目标区域的第二时间点中的至少一个，确定候选服务区域中的所述一个或以上可用服务提供者中的至少一个的服务时间段；以及
在所述服务时间段期间，将所述目标区域中的所述服务请求分配给所述至少一个或以上可用服务提供者。
18.根据权利要求15所述的方法，其特征在于，所述方法还包括：
确定所述已收到的一个或以上接受的数量；以及
基于所述一个或以上接受的数量大于预设阈值的确定结果，停止向所述一个或以上可用服务提供者发送所述调度指令。
19.根据权利要求15所述的方法，其特征在于，所述方法还包括：
确定收到来自所述一个或以上可用服务提供者中的至少一个接受调度指令的第一时间点和所述一个或以上可用服务提供者中的至少一个到达所述目标区域的第二时间点之间的时间间隔是否小于时间间隔阈值；以及
基于所述时间间隔小于所述时间间隔阈值的确定结果，将表示奖励的信息发送至所述一个或以上可用服务提供者中的至少一个。
20.根据权利要求15所述的方法，其特征在于，所述方法还包括：
响应于检测到预设类型的事件发生，检测所述目标区域是否缺少服务提供者。
21.根据权利要求20所述的方法，其特征在于，所述预设类型的事件包括预设类型的天气、高峰时间、节日或会议中的至少一个。
22.一种分配服务请求的装置，包括：
信息传输模块，被配置为响应于检测到目标区域缺少服务提供者，将调度指令发送至与所述目标区域相关的候选服务区域中的一个或以上可用服务提供者，其中，所述调度指令被配置为请求所述一个或以上可用服务提供者回应，以表明所述一个以上可用服务提供者是否同意前往所述目标区域；以及
服务请求分配模块，被配置为响应于表明所述一个或以上可用服务提供者同意前往所述目标区域的一个或以上接受，将所述目标区域中的服务请求分配给所述一个或以上可用服务提供者。
23.根据权利要求22所述的装置，其中，所述装置还包括候选服务区域确定模块，所述候选服务区域确定模块包括：
运力获取单元，被配置为响应于检测到所述目标区域缺乏服务提供者而获取所述目标区域附近的服务区域的运力；以及
候选服务区域确定单元，被配置为确定具有丰富运力的所述服务区域中的至少一个作为所述候选服务区域。
24.根据权利要求22所述的装置，其中所述服务请求分配模块包括：
服务时间段确定单元，被配置为基于预设时间段以及收到来自所述一个或以上可用服务提供者中的至少一个接受调度指令的第一时间点，或者所述一个或以上可用服务提供者中的至少一个到达所述目标区域的第二时间点中的至少一个，确定候选服务区域中的一个或以上可用服务提供者中的至少一个的服务时间段；以及
服务请求分配单元，被配置为在所述服务时间段期间，将所述目标区域中的所述服务请求分配给所述至少一个或以上可用服务提供者。
25.根据权利要求22所述的装置，其中所述装置还包括：
数量确定模块，被配置为确定所述已收到的一个或以上接受的数量；以及
控制模块，被配置为基于所述一个或以上接受的数量大于预设阈值的确定结果，停止向所述一个或以上可用服务提供者发送所述调度指令。
26.根据权利要求22所述的装置，其中所述装置还包括：
判断模块，被配置为确定收到来自所述一个或以上可用服务提供者中的至少一个接受调度指令的第一时间点和所述一个或以上可用服务提供者中的至少一个到达所述目标区域的第二时间点之间的时间间隔是否小于时间间隔阈值；以及
奖励传输模块，被配置为基于所述时间间隔小于所述时间间隔阈值的确定结果，将表示奖励的信息发送至所述一个或以上可用服务提供者中的至少一个。
27.根据权利要求22所述的装置，其中所述装置还包括：
检测模块，被配置为响应于检测到预设类型的事件发生，检测所述目标区域是否缺少可用服务提供者。
28.根据权利要求27所述的装置，其中所述预设类型的事件包括预设类型的天气、高峰时间、节日或会议中的至少一个。
29.一种计算机存储介质，包括一组指令，所述组指令包括：
响应于检测到目标区域缺少服务提供者，将调度指令发送至与所述目标区域相关的候选服务区域中的一个或以上可用服务提供者，其中，所述调度指令被配置为请求所述一个或以上可用服务提供者回应，以表明所述一个或以上可用服务提供者是否同意前往所述目标区域；以及
响应于表明所述一个或以上可用服务提供者同意前往所述目标区域的一个或以上接受，将所述目标区域的服务请求分配给所述一个或以上可用服务提供者。
30.一种推送查找服务请求的推荐信息的方法，包括：
确定从可用服务提供者的位置到候选区域的估算行程时间；
如果所述可用服务提供者前往所述候选区域并被分配服务请求，根据与所述候选区域的运力调度相关的交易数据，估算收益值；
根据所述收益值与所述估算行程时间的比值满足预设条件的确定结果，将所述候选区域确定为用于查找服务请求的推荐区域；以及
根据所述推荐区域，生成并发送用于查找服务请求的推荐信息至与所述可用服务提供者相关的用户终端。
31.根据权利要求30所述的方法，其特征在于，如果所述可用服务提供者前往所述候选区域并被分配服务请求，根据与所述候选区域的运力调度相关的所述交易数据，估算收益值包括：
根据与所述候选区域的运力调度相关的所述交易数据，确定所述可用服务提供者到达所述候选区域后被分配服务请求的概率以及分配给所述可用服务提供者的所述服务请求的服务费用；以及
根据所述概率和所述服务费用估算所述收益值。
32.根据权利要求31所述的方法，其特征在于，根据所述概率和所述服务费用估算所述收益值包括：
确定所述概率和所述服务费用的乘积；
确定所述可用服务提供者从所述可用服务提供者的位置到所述候选区域的行程费用；以及
从所述乘积中减去所述行程费用以确定差值，并将所述差值确定为所述收益值。
33.根据权利要求31所述的方法，其特征在于，确定所述可用服务提供者到达所述候选区域后被分配服务请求的概率包括：
基于所述估算行程时间确定预测时间段；
基于与所述候选区域的运力调度相关的所述交易数据，确定所述预测时间段内所述候选区域的运力不足量和所述候选区域中可用服务提供者的数量；以及
确定所述预测时间段内所述候选区域的所述运力不足量与所述候选区域中可用服务提供者的所述数量的比值作为所述可用服务提供者到达所述候选区域时被分配服务请求的概率。
34.根据权利要求30所述的方法，其特征在于，所述预设条件包括：
所述收益值与所述候选区域的所述估算行程时间的比值在所有候选区域的所述收益值与所述估算行程时间的比值的降序排列中排名前N，N≥1；或者
所述收益值与所述候选区域的所述估算行程时间的比值大于预设阈值。
35.根据权利要求30所述的方法，其特征在于，确定从所述可用服务提供者的所述位置到所述候选区域的所述估算行程时间包括：
响应于所述可用服务提供者查找服务请求的请求，确定从所述可用服务提供者的所述位置到所述候选区域的所述估算行程时间服务请求的请求。
36.根据权利要求35所述的方法，其特征在于，响应于所述可用服务提供者查找服务请求的请求，确定从所述可用服务提供者的所述位置到所述候选区域的所述估算行程时间服务请求的请求之前，所述方法还包括：
响应于检测到所述可用服务提供者等待服务请求的时间段大于预设时间阈值，发送消息提醒所述可用服务提供者发送所述查找服务请求的请求。
37.一种推送查找服务请求的推荐信息的方法，包括：
根据可用服务提供者的位置，确定所述可用服务提供者所在的候选区域；
如果所述可用服务提供者在预设时间段内停留在所述候选区域并被分配服务请求，根据与所述候选区域的运力调度相关的交易数据，估算收益值；
根据所述收益值与所述预设时间段的比值满足预设条件的确定结果，将所述候选区域确定为用于查找服务请求的推荐区域；以及
根据所述推荐区域，生成并发送用于查找服务请求的推荐信息至与所述可用服务提供者相关的用户终端。
38.一种推送用于查找服务请求的推荐信息的装置，包括：
第一确定模块，被配置为确定从可用服务提供者的位置到候选区域的估算行程时间；
第一估算模块，被配置为如果所述可用服务提供者前往所述候选区域并被分配服务请求，根据与所述候选区域的运力调度相关的交易数据，估算收益值；
第二确定模块，被配置为根据所述收益值与所述估算行程时间的比值满足预设条件的确定结果，将所述候选区域确定为用于查找服务请求的推荐区域；以及
第一推荐模块，被配置为根据所述推荐区域，生成并发送用于查找服务请求的推荐信息至与所述可用服务提供者相关的用户终端。
39.根据权利要求38所述的装置，其中所述第一估算模块包括：
估算单元，被配置根据与所述候选区域的运力调度相关的所述交易数据，确定所述可用服务提供者到达所述候选区域后被分配服务请求的概率以及分配给所述可用服务提供者的所述服务请求的服务费用；以及
收益计算单元，被配置为根据所述概率和所述服务费用估算所述收益值。
40.一种推送用于查找服务请求的推荐信息的装置，包括：
第三确定模块，被配置为根据可用服务提供者的位置，确定所述可用服务提供者所在的候选区域；
第二估算模块，被配置为如果所述可用服务提供者在预设时间段内停留在所述候选区域并被分配服务请求，根据与所述候选区域的运力调度相关的交易数据，估算收益值；
第四确定模块，被配置为根据所述收益值与所述预设时间段的比值满足预设条件的确定结果，将所述候选区域确定为用于查找服务请求的推荐区域；以及
第二推荐，被配置为根据所述推荐区域，生成并发送用于查找服务请求的推荐信息至与所述可用服务提供者相关的用户终端。
41.一个电子装置，包括：
处理器和存储装置，包括由所述处理器执行的一组指令，其中所述处理器被配置为：
确定从可用服务提供者的位置到候选区域的估算行程时间；
如果所述可用服务提供者前往所述候选区域并被分配服务请求，根据与所述候选区域的运力调度相关的交易数据，估算收益值；
根据所述收益值与所述估算行程时间的比值满足预设条件的确定结果，将所述候选区域确定为用于查找服务请求的推荐区域；以及
根据所述推荐区域，生成并发送用于查找服务请求的推荐信息至与所述可用服务提供者相关的用户终端。
42.一个电子装置，包括：
处理器和存储装置，包括由所述处理器执行的一组指令，其中所述处理器被配置为：
根据可用服务提供者的位置，确定所述可用服务提供者所在的候选区域；
如果所述可用服务提供者在预设时间段内停留在所述候选区域并被分配服务请求，根据与所述候选区域的运力调度相关的交易数据，估算收益值；
根据所述收益值与所述预设时间段的比值满足预设条件的确定结果，将所述候选区域确定为用于查找服务请求的推荐区域；以及
根据所述推荐区域，生成并发送用于查找服务请求的推荐信息至与所述可用服务提供者相关的用户终端。
43.一种用于运力调度的系统，包括：
至少一个存储装置，包括一组指令；
与所述至少一个存储装置通信的至少一个处理器，其中，当执行所述组指令时，所述至少一个处理器被配置为使所述系统：
确定目标区域，其中满足预设条件的至少两个服务请求从所述目标区域发起，所述至少两个服务请求通过与至少两个服务请求者相关联的至少两个用户终端发起；
根据所述目标区域的信息，确定非忙碌区域，所述非忙碌区域包括一个或以上可自由接受服务请求的可用服务提供者；以及
通过网络，将与所述至少两个服务请求相关联的调度指令发送到与所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个相关联的用户终端，所述调度指令包括询问所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个是否同意前往所述目标区域的信息，其中，所述调度指令的至少一部分通过所述用户终端执行的应用程序的图形用户界面显示。
44.根据权利要求43所述的系统，其特征在于，为了确定所述目标区域，所述至少一个处理器被配置为使所述系统进一步：
确定目标半径和目标服务请求数；
通过使用聚类算法，基于所述目标半径和所述目标服务请求数，将预设区域划分为至少两个候选区域；
对于所述至少两个候选区域中的至少一个，
判断分配率是否小于分配率阈值；
基于所述确定所述分配率小于所述分配率阈值的结果，确定所述候选区域中的可用服务提供者的数量与所述候选区域中待分配的服务请求数的比值是否小于比值阈值；以及
基于所述候选区域中所述可用服务提供者的所述数量与所述候选区域中所述待分配的服务请求数的所述比值小于所述比值阈值的确定结果，确定所述候选区域为所述目标区域。
45.根据权利要求44所述的系统，其特征在于，为了确定所述目标半径和所述目标服务请求数，所述至少一个处理器被配置为使所述系统进一步：
确定至少两个数据对，所述至少两个数据对中的每一个包括预设半径和预设服务请求数；
根据所述聚类算法，确定对应于所述至少两个数据对的至少两个分布熵；
确定所述至少两个分布熵的最大分布熵；
所述至少两个数据对中选择对应所述最大分布熵的数据对；以及
确定对应于所述所选择的数据对的预设半径和预设服务请求数为所述目标半径和所述目标服务请求数。
46.根据权利要求43所述的系统，其特征在于，为了根据所述目标区域的所述信息确定所述非忙碌区域，所述至少一个处理器被配置为使所述系统进一步：
确定所述目标区域的边界；
获取与所述目标区域相关的扩展参数；
根据所述扩展参数确定调整的边界；以及
根据所述调整的边界确定所述非忙碌区域。
47.根据权利要求43所述的系统，其特征在于，所述至少一个处理器被配置为使所述系统进一步：
响应于从所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个相关联的用户终端收到的所述调度指令的接受，发送所述至少两个服务请求中的至少一个的信息到与所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个相关联的用户终端，其中，
发送到与所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个相关联的所述用户终端的所述至少两个服务请求中的至少一个的信息包括与所述至少两个服务请求中的至少一个相关联的位置，根据与所述至少两个服务请求中的至少一个相关联的用户终端发送的GPS数据，确定与所述至少两个服务请求中的至少一个相关联的位置。
48.根据权利要求47所述的系统，其特征在于，所述至少一个处理器被配置为使所述系统进一步：
确定从所述非忙碌区域中的一个或以上可用服务提供者中的至少一个的所述用户终端接收到所述调度指令的所述接受的第一时间点；以及
确定所述非忙碌区域中的一个或以上可用服务提供者中的至少一个到达所述目标区域的第二时间点。
49.根据权利要求48所述的系统，其特征在于，所述至少一个处理器被配置为使所述系统进一步：
确定预设时间段；
基于所述预设时间段和所述第一时间点或所述第二时间点中的至少一个，确定所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个的服务时间段；以及
在所述服务时间段内，将从目标区域发起的所述至少两个服务请求中的至少一个的信息，发送到与所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个相关的所述用户终端，其中
发送到与所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个相关的所述用户终端的所述至少两个服务请求中的至少一个的信息，包括与所述至少两个服务请求中的至少一个相关联的位置，根据与所述至少两个服务请求中的至少一个相关联的用户终端发送的GPS数据确定与所述至少两个服务请求中的至少一个相关联的位置。
50.根据权利要求48所述的系统，其特征在于，所述至少一个处理器被配置为使所述系统进一步：
确定所述第一时间点和所述第二时间点之间的时间间隔；
确定所述时间间隔是否小于时间间隔阈值；以及
基于所述时间间隔小于所述时间间隔阈值的确定结果，向与所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个相关联的所述用户终端所执行的应用程序发送所述表示奖励的信息。
51.根据权利要求47所述的系统，其特征在于，所述至少一个处理器被配置为使所述系统进一步：
将所述调度指令发送到与所述非忙碌区域中的所述一个或以上可用服务提供者相关的一个或以上用户终端；
从所述一个或以上可用服务提供者的所述一个或以上用户终端接收的一个或以上接受，表示所述一个或以上可用服务提供者的相应部分同意前往所述目标区域；
确定所述接收到的一个或以上接受的数量；
确定所述一个或以上接受的数量是否大于预设阈值；以及
基于所述一个或以上接受的数量大于所述预设阈值的确定结果，停止向与所述非忙碌区域中的所述一个或以上可用服务提供者相关的所述一个或以上用户终端发送所述调度指令。
52.根据权利要求43所述的系统，其特征在于，所述至少一个处理器被配置为使所述系统进一步：
基于从与所述一个或以上可用服务提供者中的至少一个相关联的所述用户终端所执行的所述应用程序接收的GPS的数据，确定所述非忙碌区域中的一个或以上可用服务提供者中的至少一个的位置，所述GPS数据由所述用户终端的GPS芯片组确定。
53.根据权利要求52所述的系统，其特征在于，所述至少一个处理器被配置为使所述系统进一步：
识别所述目标区域中的调度位置，其中，所述调度位置的预设范围内的服务请求密度大于密度阈值；
确定所述一个或以上可用服务提供者中的至少一个的位置与所述调度位置之间的距离；
确定所述一个或以上可用服务提供者中的至少一个的位置与所述调度位置之间的距离是否小于距离阈值；以及
基于所述一个或以上可用服务提供者中的至少一个的位置与所述调度位置之间的距离小于所述距离阈值的确定结果，将所述调度位置的信息发送到与所述一个或以上可用服务提供者中的至少一个相关联的用户终端。
54.根据权利要求52所述的系统，其特征在于，将与所述至少两个服务请求相关的所述调度指令发送到与所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个相关联的用户终端，所述至少一个处理器被配置为使所述系统进一步：
确定从所述一个或以上可用服务提供者中的至少一个的所述位置到所述目标区域的估算行程时间；
如果所述一个或以上可用服务提供者中的至少一个到达所述目标区域，确定与所述一个或以上可用服务提供者中的至少一个相关的收益值；
确定所述收益值与所述估算行程时间的比值是否大于比值阈值；以及
根据所述收益值与所述估算行程时间的比值大于所述比值阈值的确定结果，将与所述至少两个服务请求相关联的调度指令发送到与所述一个或以上可用服务提供者中的至少一个相关联的用户终端所执行的应用程序。
55.根据权利要求54所述的系统，其特征在于，为了估算与所述一个或以上可用服务提供者中的至少一个相关的收益值，所述至少一个处理器被配置为使所述系统进一步：
估算所述一个或以上可用服务提供者中的至少一个从一个或以上可用服务提供者中的至少一个的位置到所述目标区域的行程费用；
如果所述一个或以上可用服务提供者中的至少一个到达所述目标区域，确定所述一个或以上可用服务提供者中的至少一个被分配服务请求的概率；
如果所述一个或以上可用服务提供者中的至少一个到达所述目标区域，估算分配给所述一个或以上可用服务提供者中的至少一个的所述服务请求的服务费用；以及
根据所述行程费用、所述概率和所述服务费用，估算与所述一个或以上可用服务提供者中的至少一个相关的收益值。
56.根据权利要求55所述的系统，其特征在于，如果所述一个或以上可用服务提供者中的至少一个到达所述目标区域，确定所述一个或以上可用服务提供者中的至少一个被分配服务请求的概率，所述至少一个处理器被配置为使所述系统进一步：
根据所述估算行程时间确定预测时间段；
估算在所述预测时间段内所述目标区域中待分配的服务请求的数量和所述目标区域中可用服务提供者的数量；以及
基于所述待分配的服务请求的数量和所述可用服务提供者的数量，确定所述一个或以上可用服务提供者中的至少一个被分配服务请求的概率。
57.一种在计算装置上实现的方法，所述计算装置具有至少一个处理器、至少一个存储装置和连接到网络的通信平台，所述方法包括：
确定目标区域，其中，满足预设条件的至少两个服务请求从所述目标区域发起，所述至少两个服务请求通过与至少两个服务请求者相关联的至少两个用户终端发起；
根据所述目标区域的信息确定非忙碌区域，所述非忙碌区域包括一个或以上可自由接受服务请求的可用服务提供者；以及
通过网络将与所述至少两个服务请求相关联的调度指令发送到与所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个相关联的用户终端，所述调度指令包括询问所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个是否同意前往所述目标区域的信息，其中，所述调度指令的至少一部分通过所述用户终端执行的应用程序的图形用户界面显示。
58.根据权利要求57所述的方法，其特征在于，所述确定所述目标区域包括：
确定目标半径和目标服务请求数；
通过聚类算法，基于所述目标半径和所述目标服务请求数，将预设区域划分为至少两个候选区域；
对于所述至少两个候选区域中的至少一个，
确定分配率是否小于分配率阈值；
基于所述分配率小于所述分配率阈值的确定结果，确定所述候选区域中的可用服务提供者的数量与所述候选区域中待分配的服务请求数的比值是否小于比值阈值；以及
基于所述候选区域中的可用服务提供者的数量与所述候选区域中待分配的服务请求数的比值小于所述比值阈值的确定结果，确定所述候选区域为所述目标区域。
59.根据权利要求58所述的方法，其特征在于，所述确定目标半径和目标服务请求数包括：
确定至少两个数据对，所述至少两个数据对中的每一个包括预设半径和预设服务请求数；
基于所述聚类算法，确定与所述至少两个数据对相对应的至少两个分布熵；
确定所述至少两个分布熵的最大分布熵；
在所述至少两个数据对中选择对应于所述最大分布熵的数据对；以及
确定与所述所选数据对相对应的预设半径和预设服务请求数为所述目标半径和所述目标服务请求数。
60.根据权利要求59所述的方法，其特征在于，所述根据所述目标区域的信息确定非忙碌区域包括：
确定所述目标区域的边界；
获取与所述目标区域相关的扩展参数；
根据所述扩展参数确定调整的边界；以及
根据所述调整的边界确定所述非忙碌区域。
61.根据权利要求57所述的方法，其特征在于，所述方法还包括：
响应于从与所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个相关联的用户终端接收到的所述调度指令的接受，向与所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个相关联的所述用户终端发送所述至少两个服务请求中的至少一个的信息，其中
发送到与所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个相关联的所述用户终端的所述至少两个服务请求中的至少一个的信息，包括与所述至少两个服务请求中的至少一个相关联的位置，根据与所述至少两个服务请求中的至少一个相关联的用户终端发送的GPS数据确定与所述至少两个服务请求中的至少一个相关联的位置。
62.根据权利要求61所述的方法，其特征在于，所述方法还包括：
确定从所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个的用户终端接收到调度指令的接受的第一时间点；以及
确定所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个到达目标区域的第二时间点。
63.根据权利要求62所述的方法，其特征在于，所述方法还包括：
确定预设时间段；
基于所述预设时间段和所述第一时间点或所述第二时间点中的至少一个，确定所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个的服务时间段；以及
在所述服务时间段内，将从所述目标区域发起的所述至少两个服务请求中的至少一个的信息，发送到与所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个相关联的所述用户终端，其中
发送到与所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个相关联的所述用户终端的所述至少两个服务请求中的至少一个的信息，包括与所述至少两个服务请求中的至少一个相关联的位置，根据与所述至少两个服务请求中的至少一个相关联的用户终端发送的GPS数据确定与所述至少两个服务请求中的至少一个相关联的位置。
64.根据权利要求62所述的方法，其特征在于，所述方法还包括：
确定所述第一时间点和所述第二时间点之间的时间间隔；
确定所述时间间隔是否小于时间间隔阈值；以及
基于所述时间间隔小于所述时间间隔阈值的确定结果，向与所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个相关联的所述用户终端所执行的所述应用程序发送表示奖励的信息。
65.根据权利要求61所述的方法，其特征在于，所述方法还包括：
将所述调度指令发送到与所述非忙碌区域中的所述一个或以上可用服务提供者相关联的一个或以上用户终端；
从所述一个或以上可用服务提供者的所述一个或以上用户终端接收的一个或以上接受，表示所述一个或以上可用服务提供者的相应部分同意前往所述目标区域；
确定所述接收到的一个或以上接受的数量；
确定所述一个或以上接受的数量是否大于预设阈值；以及
基于所述一个或以上接受的数量大于所述预设阈值的确定结果，停止向与所述非忙碌区域中的所述一个或以上可用服务提供者相关联的所述一个或以上用户终端发送所述调度指令。
66.根据权利要求57所述的方法，其特征在于，所述方法还包括：
基于从所述一个或以上可用服务提供者中的至少一个相关联的所述用户终端所执行的所述应用程序接收的GPS数据，确定所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个的位置，所述GPS数据由所述用户终端的GPS芯片组确定。
67.根据权利要求66所述的方法，其特征在于，所述方法还包括：
识别所述目标区域中的调度位置，其中，所述调度位置的预设范围内的服务请求密度大于密度阈值；
确定所述一个或以上可用服务提供者中的至少一个的位置与所述调度位置之间的距离；
确定所述一个或以上可用服务提供者中的至少一个的位置与所述调度位置之间的所述距离是否小于距离阈值；以及
基于所述一个或以上可用服务提供者中的至少一个的位置和所述调度位置之间的距离小于所述距离阈值的确定结果，将所述调度位置的信息发送到与所述一个或以上可用服务提供者中的至少一个相关联的用户终端。
68.根据权利要求66所述的方法，其特征在于，将与所述至少两个服务请求相关的所述调度指令发送到与所述非忙碌区域中的一个或以上可用服务提供者中的至少一个相关联的所述用户终端包括：
确定从所述一个或以上可用服务提供者中的至少一个的所述位置到所述目标区域的估算行程时间；
如果所述一个或以上可用服务提供者中的至少一个到达所述目标区域，确定与所述一个或以上可用服务提供者中的至少一个相关的收益值；
确定所述收益值与所述估算行程时间的比值是否大于比值阈值；以及
根据所述收益值与所述估算行程时间的比值大于所述比值阈值的确定结果，将与所述至少两个服务请求相关联的所述调度指令发送到与所述一个或以上可用服务提供者中的至少一个相关联的所述用户终端执行的应用程序。
69.根据权利要求68所述的方法，其特征在于，估算与所述一个或以上可用服务提供者中的至少一个相关联的收益值包括：
估算所述一个或以上可用服务提供者中的至少一个从所述一个或以上可用服务提供者中的至少一个的位置到所述目标区域的行程费用；
如果所述一个或以上可用服务提供者中的至少一个到达所述目标区域，确定所述一个或以上可用服务提供者中的至少一个被分配服务请求的概率；
如果所述一个或以上可用服务提供者中的至少一个到达所述目标区域，估算分配给所述一个或以上可用服务提供者中的至少一个的所述服务请求的服务费用；以及
根据所述行程费用、所述概率和所述服务费用，估算与所述一个或以上可用服务提供者中的至少一个相关的收益值。
70.根据权利要求69所述的方法，其特征在于，如果所述一个或以上可用服务提供者中的至少一个到达所述目标区域，确定所述一个或以上可用服务提供者中的至少一个被分配服务请求的概率包括：
根据所述估算行程时间确定预测时间段；
估算在所述预测时间段内所述目标区域中待分配的服务请求的数量和所述目标区域中可用服务提供者的数量；以及
基于所述待分配的服务请求的数量和所述可用服务提供者的数量，确定所述一个或以上可用服务提供者中的至少一个被分配服务请求的概率。
71.一种非暂时性计算机可读介质，包括用于运力调度的一组指令，其特征在于，当由至少一个处理器执行时，所述组指令指示所述至少一个处理器实现一种方法，所述方法包括：
确定目标区域，其中，满足预设条件的至少两个服务请求从所述目标区域发起，所述至少两个服务请求通过与至少两个服务请求者相关联的至少两个用户终端发起；
根据所述目标区域的信息确定非忙碌区域，所述非忙碌区域包括一个或以上可自由接受服务请求的可用服务提供者；以及
通过网络将与所述至少两个服务请求相关联的调度指令发送到与所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个相关联的用户终端，所述调度指令包括询问所述非忙碌区域中的所述一个或以上可用服务提供者中的至少一个是否同意前往所述目标区域的信息，其中，所述调度指令的至少一部分通过所述用户终端执行的应用程序的图形用户界面显示。
CN201880037805.XA 2017-06-14 2018-05-14 用于运力调度的系统和方法 Active CN110741402B (zh)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
CN2017104473578 2017-06-14
CN201710447357.8A CN109087502B (zh) 2017-06-14 2017-06-14 基于订单分布的车辆调度方法、调度系统、计算机设备
CN2017104767177 2017-06-21
CN201710476717.7A CN109102135B (zh) 2017-06-21 2017-06-21 订单分配方法及装置
CN2017105902551 2017-07-19
CN201710590255.1A CN110020215A (zh) 2017-07-19 2017-07-19 找单推荐信息的推送方法及装置、电子设备
PCT/CN2018/086724 WO2018228110A1 (en) 2017-06-14 2018-05-14 Systems and methods for transport capacity scheduling

Publications (2)

Publication Number Publication Date
CN110741402A true CN110741402A (zh) 2020-01-31
CN110741402B CN110741402B (zh) 2023-05-16

Family

ID=64659487

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201880037805.XA Active CN110741402B (zh) 2017-06-14 2018-05-14 用于运力调度的系统和方法

Country Status (4)

Country Link
US (1) US11621921B2 (zh)
CN (1) CN110741402B (zh)
AU (1) AU2018284492A1 (zh)
WO (1) WO2018228110A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111311156A (zh) * 2020-02-21 2020-06-19 拉扎斯网络科技（上海）有限公司 一种数据处理的方法、装置、可读存储介质和电子设备
CN118379866A (zh) * 2024-06-24 2024-07-23 四川万网鑫成信息科技有限公司 基于大数据的车辆调度方法、计算机设备和存储介质

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10277310B2 (en) * 2017-02-15 2019-04-30 Viasat, Inc. Dynamic spatial allocation of satellite capacity based on mobile vessel load forecasting
CN109272126A (zh) * 2017-07-18 2019-01-25 北京嘀嘀无限科技发展有限公司 确定方法、装置、服务器、移动终端和可读存储介质
WO2020159431A1 (en) * 2019-01-28 2020-08-06 Grabtaxi Holdings Pte. Ltd. Transportation method and apparatus
US10657824B1 (en) * 2019-05-16 2020-05-19 Allstate Insurance Company Roadside assistance system
WO2020262721A1 (ko) * 2019-06-25 2020-12-30 엘지전자 주식회사 인공 지능을 이용하여, 복수의 로봇들을 제어하는 관제 시스템
US11568342B1 (en) * 2019-08-16 2023-01-31 Lyft, Inc. Generating and communicating device balance graphical representations for a dynamic transportation system
US11587001B2 (en) * 2020-01-15 2023-02-21 International Business Machines Corporation Rebalancing autonomous vehicles according to last-mile delivery demand
US20230072591A1 (en) * 2020-02-11 2023-03-09 Grabtaxi Holdings Pte. Ltd. Service pricing devices and service pricing method
SG11202113323UA (en) * 2020-02-18 2021-12-30 Grabtaxi Holdings Pte Ltd System and method for partitioning geographical areas into logistical areas for dynamic pricing
CN111915256B (zh) * 2020-07-31 2023-09-26 上海寻梦信息技术有限公司 构建派件围栏的方法、异地签收识别方法及相关设备
US20220335361A1 (en) * 2021-04-20 2022-10-20 At&T Intellectual Property I, L.P. Territory Assignment Optimization
WO2024076292A1 (en) * 2022-10-03 2024-04-11 Grabtaxi Holdings Pte. Ltd. Device and method for controlling a food delivery system

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130204524A1 (en) * 2012-02-08 2013-08-08 Telogis, Inc. System for classifying streets for vehicle navigation
CN103985247A (zh) * 2014-04-24 2014-08-13 北京嘀嘀无限科技发展有限公司 基于城市叫车需求分布密度的出租车运力调度系统
CN104077915A (zh) * 2014-03-27 2014-10-01 中华电信股份有限公司 乘车趋势预测装置及其方法
CN104599088A (zh) * 2015-02-13 2015-05-06 北京嘀嘀无限科技发展有限公司 基于订单的调度方法和调度系统
CN204423429U (zh) * 2015-01-27 2015-06-24 宁夏万象汇通信息科技有限公司 私营车辆运力调度订单管理系统
CN204496697U (zh) * 2015-02-10 2015-07-22 北京东方车云信息技术有限公司 使用运营区域的用车热度来调整运力的用车系统
CN104850976A (zh) * 2015-05-26 2015-08-19 丹阳飓风物流股份有限公司 一种运力调度方法
CN105139089A (zh) * 2015-08-20 2015-12-09 北京嘀嘀无限科技发展有限公司 一种平衡出行供需的方法及设备
CN105825310A (zh) * 2016-04-11 2016-08-03 湖南科技大学 基于信息熵的出租车寻客路线推荐方法
CN106373387A (zh) * 2016-10-25 2017-02-01 先锋智道（北京）科技有限公司 一种车辆调度方法、装置及系统

Family Cites Families (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007249790A (ja) 2006-03-17 2007-09-27 Nec Commun Syst Ltd タクシー予約受付装置およびタクシー配車処理装置
JP4678779B2 (ja) 2006-03-20 2011-04-27 株式会社日立ソリューションズ 携帯型端末を用いたタクシー配車システム
CN1932921A (zh) 2006-09-28 2007-03-21 江苏天泽信息产业有限公司 出租车辆调度中快速定位就近空车的方法
JP2008269347A (ja) 2007-04-20 2008-11-06 Total Kankyo:Kk タクシー配車装置、タクシー端末装置、タクシー配車システム、タクシー配車方法、コンピュータプログラム
CN101996485B (zh) 2009-08-14 2013-03-13 事必达科技股份有限公司 一种派遣车辆方法及装置
SG191453A1 (en) 2011-12-30 2013-07-31 Singapore Technologies Dynamics Pte Ltd System and method for flexible and efficient public transportation
US9066206B2 (en) 2012-07-03 2015-06-23 Uber Technologies, Inc. System and method for providing dynamic supply positioning for on-demand services
GB201300006D0 (en) 2013-01-01 2013-02-13 Tomtom Dev Germany Gmbh Vehicle management system
EP2860673A1 (en) 2013-10-14 2015-04-15 Chaillie, Patrick Server and method for matching a demand request for a transport capacity with supply requests
US9984574B2 (en) * 2014-01-21 2018-05-29 Tribal Rides, Inc. Method and system for anticipatory deployment of autonomously controlled vehicles
CN104320436B (zh) 2014-09-29 2017-10-24 百度在线网络技术（北京）有限公司 一种参考信息的获取方法及装置
CN104463509A (zh) 2014-12-29 2015-03-25 先锋智道（北京）科技有限公司 网络打车的订单推送方法和网络打车的订单确认方法
CN105139228A (zh) 2015-08-20 2015-12-09 北京嘀嘀无限科技发展有限公司 一种订单分配的方法及装置
CN104657933A (zh) 2015-03-04 2015-05-27 北京嘀嘀无限科技发展有限公司 用于通知订单供需密度的方法及设备
CN104867065B (zh) 2015-06-05 2021-07-02 北京嘀嘀无限科技发展有限公司 处理订单的方法和设备
CN105608886A (zh) 2016-01-21 2016-05-25 滴滴出行科技有限公司 用于调度交通工具的方法和设备
US20160335576A1 (en) 2015-05-12 2016-11-17 Uber Technologies, Inc. Location-based prediction of transport services
CN105719111A (zh) * 2015-05-22 2016-06-29 北京小度信息科技有限公司 动态调节运力的方法和装置
US20170041743A1 (en) * 2015-08-03 2017-02-09 Punch Technologies, Inc. Methods and Systems for Reporting and Providing Improved, Close-Proximity Assistance
CN105405285B (zh) * 2015-11-06 2017-11-24 厦门蓝斯通信股份有限公司 自动切换抢单模式和派单模式的车辆调度方法和调度系统
US10846633B2 (en) 2015-12-29 2020-11-24 Lyft, Inc. System for selecting drivers for transportation requests with specified time durations
US9976863B2 (en) * 2016-03-29 2018-05-22 Lyft, Inc. Casual driver ride sharing
CN105894359A (zh) 2016-03-31 2016-08-24 百度在线网络技术（北京）有限公司 订单推送方法、装置及系统
CN105808784B (zh) * 2016-03-31 2020-07-07 北京星选科技有限公司 推荐方法和装置
CN105956908A (zh) 2016-05-13 2016-09-21 深圳市永兴元科技有限公司 订单分配方法及系统
US10395333B2 (en) * 2016-06-07 2019-08-27 Uber Technologies, Inc. Hierarchical selection process
US10325442B2 (en) * 2016-10-12 2019-06-18 Uber Technologies, Inc. Facilitating direct rider driver pairing for mass egress areas
US10171569B2 (en) * 2016-12-02 2019-01-01 Uber Technologies, Inc. Transmission of data to multiple computing devices according to a transmission schedule
US10890457B2 (en) * 2017-01-13 2021-01-12 Uber Technologies, Inc. Method and system for repositioning a service location
US9898791B1 (en) * 2017-02-14 2018-02-20 Uber Technologies, Inc. Network system to filter requests by destination and deadline
CA3055038A1 (en) * 2017-02-20 2018-08-23 Uber Technologies, Inc. Service request matching based on provider compliance state
US10371539B2 (en) * 2017-03-09 2019-08-06 Lyft, Inc. Determining matches using dynamic provider eligibility model
US9769616B1 (en) * 2017-04-04 2017-09-19 Lyft, Inc. Geohash-related location predictions
US10701759B2 (en) * 2017-05-19 2020-06-30 Uber Techologies, Inc. Predictive location selection transportation optimization system
US10628903B2 (en) * 2017-05-22 2020-04-21 Uber Technologies, Inc. Network computer system to implement counter values for arranging services
US10262471B2 (en) * 2017-05-23 2019-04-16 Uber Technologies, Inc. Autonomous vehicle degradation level monitoring
KR102390269B1 (ko) * 2017-05-26 2022-04-25 그랩택시 홀딩스 피티이. 엘티디. 셔틀 서비스 관리 및 셔틀 서비스 루트 및 서비스 도출을 위한 시스템 및 방법

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130204524A1 (en) * 2012-02-08 2013-08-08 Telogis, Inc. System for classifying streets for vehicle navigation
CN104077915A (zh) * 2014-03-27 2014-10-01 中华电信股份有限公司 乘车趋势预测装置及其方法
CN103985247A (zh) * 2014-04-24 2014-08-13 北京嘀嘀无限科技发展有限公司 基于城市叫车需求分布密度的出租车运力调度系统
CN204423429U (zh) * 2015-01-27 2015-06-24 宁夏万象汇通信息科技有限公司 私营车辆运力调度订单管理系统
CN204496697U (zh) * 2015-02-10 2015-07-22 北京东方车云信息技术有限公司 使用运营区域的用车热度来调整运力的用车系统
CN104599088A (zh) * 2015-02-13 2015-05-06 北京嘀嘀无限科技发展有限公司 基于订单的调度方法和调度系统
CN104850976A (zh) * 2015-05-26 2015-08-19 丹阳飓风物流股份有限公司 一种运力调度方法
CN105139089A (zh) * 2015-08-20 2015-12-09 北京嘀嘀无限科技发展有限公司 一种平衡出行供需的方法及设备
CN105825310A (zh) * 2016-04-11 2016-08-03 湖南科技大学 基于信息熵的出租车寻客路线推荐方法
CN106373387A (zh) * 2016-10-25 2017-02-01 先锋智道（北京）科技有限公司 一种车辆调度方法、装置及系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
邹迎: "公交区域调度行车计划编制方法研究", 《交通运输系统工程与信息》 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111311156A (zh) * 2020-02-21 2020-06-19 拉扎斯网络科技（上海）有限公司 一种数据处理的方法、装置、可读存储介质和电子设备
CN111311156B (zh) * 2020-02-21 2023-09-19 拉扎斯网络科技（上海）有限公司 一种数据处理的方法、装置、可读存储介质和电子设备
CN118379866A (zh) * 2024-06-24 2024-07-23 四川万网鑫成信息科技有限公司 基于大数据的车辆调度方法、计算机设备和存储介质
CN118379866B (zh) * 2024-06-24 2024-09-10 四川万网鑫成信息科技有限公司 基于大数据的车辆调度方法、计算机设备和存储介质

Also Published As

Publication number Publication date
CN110741402B (zh) 2023-05-16
WO2018228110A1 (en) 2018-12-20
US20200120037A1 (en) 2020-04-16
US11621921B2 (en) 2023-04-04
AU2018284492A1 (en) 2020-02-27

Similar Documents

Publication Publication Date Title
CN110741402B (zh) 用于运力调度的系统和方法
US11928752B1 (en) Allocation of dynamically batched service providers and service requesters
JP6506460B2 (ja) サービスの供給状況を管理するシステム及び方法
US20200005420A1 (en) Systems and methods for transportation capacity dispatch
JP7235647B2 (ja) 予約オーダーを割り当てるシステム及び方法
WO2019154398A1 (en) Systems and methods for recommending transportation services
JP7253041B2 (ja) 輸送サービスプロバイダを管理する方法、当該方法を実施するための命令を含むコンピュータプログラム、当該方法を実行させる命令を記憶する非一時記憶媒体、及び輸送サービスプロバイダを管理するための装置
US10181111B1 (en) Electronic device communications for item handoffs
US10586273B1 (en) Managing couriers for fast deliveries
US20180225796A1 (en) Resource Allocation in a Network System
CN109673165A (zh) 用于调度车辆的系统和方法
CN109816128B (zh) 网约车订单的处理方法、装置、设备及可读存储介质
JP2018533778A (ja) 共有可能な注文を割り当てるためのシステムおよび方法
KR20180013843A (ko) 오더 할당 시스템 및 방법
CN110175869A (zh) 车辆分配方法及装置、电子设备和计算机可读存储介质
WO2018146622A1 (en) Dynamic selection of geo-based service options in a network system
TWI674510B (zh) 用於推薦搭乘地點的系統和方法
CN111242711A (zh) 信息提示方法、装置、电子设备和存储介质
CN110832513B (zh) 用于按需服务的系统和方法
CN111612286A (zh) 一种订单分配方法、装置、电子设备及存储介质
JP2022521665A (ja) 輸送方法および装置
CN111915043A (zh) 服务数据处理方法、装置、服务器及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant