Search within
Search within the title, abstract, claims, or full patent document: You can restrict your search to a specific field using field names.
Use TI= to search in the title, AB= for the abstract, CL= for the claims, or TAC= for all three. For example, TI=(safety belt).
Search by Cooperative Patent Classifications (CPCs): These are commonly used to represent ideas in place of keywords, and can also be entered in a search term box. If you're searching forseat belts, you could also search for B60R22/00 to retrieve documents that mention safety belts or body harnesses. CPC=B60R22 will match documents with exactly this CPC, CPC=B60R22/low matches documents with this CPC or a child classification of this CPC.
Learn More
Title
Abstract
Claims
Full Document
Find patents
Keywords and boolean syntax (USPTO or EPO format): seat belt searches these two words, or their plurals and close synonyms. "seat belt" searches this exact phrase, in order. -seat -belt searches for documents not containing either word.
For searches using boolean logic, the default operator is AND with left associativity. Note: this means safety OR seat belt is searched as (safety OR seat) AND belt. Each word automatically includes plurals and close synonyms. Adjacent words that are implicitly ANDed together, such as (safety belt), are treated as a phrase when generating synonyms.
Learn More
Search by
Chemistry searches match terms (trade names, IUPAC names, etc. extracted from the entire document, and processed from .MOL files.)
Substructure (use SSS=) and similarity (use ~) searches are limited to one per search at the top-level AND condition. Exact searches can be used multiple times throughout the search query.
Searching by SMILES or InChi key requires no special syntax. To search by SMARTS, use SMARTS=.
To search for multiple molecules, select "Batch" in the "Type" menu. Enter multiple molecules separated by whitespace or by comma.
Learn More
Patent numbers
Search specific patents by importing a CSV or list of patent publication or application numbers.
针对运输请求优化对驾驶员的选择
CN105917376A
China
Description
translated from
背景技术
存在安排由车辆驾驶员为用户提供运输的按需服务。例如，在很多情况下，可向请求运输服务的用户提供第一可用驾驶员或最靠近用户请求的接人位置的驾驶员。
附图说明
图1A说明在一个实例中的用于安排按需服务的示例系统。
图1B说明根据实例的用于以优化运输请求的接人时间的方式来选择所述运输请求的驾驶员的优化子系统的第一实施方案。
图1C说明根据实例的用于以共同优化运输请求群组的接人时间的方式来选择运输请求的驾驶员的优化子系统的第二实施方案。
图2说明根据实例的用于为用户安排按需服务的示例方法。
图3A和图3B说明根据实例的用于确定能够提供按需服务的提供者的示例方法。
图4说明根据一个或多个实例的用于针对运输请求来优化对驾驶员(或车辆)的选择的方法。
图5A说明根据实例的用于基于优化考虑的驾驶员指派和随后变化的示例顺序图。
图5B说明根据另一实例的基于优化考虑的旅程(或驾驶员)交换的另一示例顺序图。
图6A至图6C说明根据一个或多个实例的用于实施驾驶员选择算法的实例，其中进行驾驶员/乘车人配对以实现最小化接人时间的优化目标。
图7是说明计算机系统的框图，在所述计算机系统上可实施本文中描述的实例。
图8是说明移动计算装置的框图，在所述移动计算装置上可实施本文中描述的实例。
具体实施方式
本文中描述的实例提供一种智能按需服务调度系统，该系统为请求按需服务的用户优化对服务提供者的选择。在至少一些实例中，当用户做出按需服务的请求时，基于所述用户提供的位置信息和服务提供者的当前状态和/或位置信息，所述系统可确定能够为用户提供按需服务的多个服务提供者。
在一些实例中，当系统接收到来自用户的运输请求时，系统可选择已经在向另一顾客提供运输的驾驶员，如果该驾驶员最适合向所述用户提供运输的话(例如，尽管有未被用户占用的其他可用驾驶员)。例如，系统可确定驾驶员将在某一时间让他或她的顾客在与请求用户的接人位置接近的位置下车。在另一实例中，系统可确定驾驶员的当前位置(和/或沿着预计驾驶路线的多个位置)接近请求用户的接人位置，并且请求用户的目的地接近驾驶员的当前顾客的目的地。系统可将此类驾驶员确定成用于向请求用户提供运输的最佳候选人。
根据一些实例，系统可接收来自第一用户的计算装置的运输请求。所述运输请求可包括有关第一用户的接人位置的信息。响应于接收到所述运输请求，系统可确定能够为所述第一用户提供运输的多个驾驶员。通过确定每个正在驾驶未被其他用户占用的车辆的驾驶员的第一集合(例如，在忙碌着或在上班但没有在使用中的驾驶员)以及确定每个正在向去往各自目的地位置(所述各自目的地位置是在第一用户的接人位置的阈值距离或阈值预计行程时间内)的其他用户提供运输服务的驾驶员的第二集合，系统可确定多个驾驶员。系统可从所述多个驾驶员中选择第一驾驶员来为第一用户提供运输服务。
在一个实例中，通过识别当前位置在第一用户的接人位置的预定义距离内或者在第一用户的接人位置的预定义区域内的此类驾驶员，系统确定正在驾驶未被其他用户占用的车辆的驾驶员的第一集合。例如，所述预定义距离或区域可关于或对应于城市或城市范围或者用户的接人位置所在的地理区域。例如，与用户的接人位置相距一百英里的可用驾驶员将被确定为不在用户的接人位置的预定义距离(例如，十五英里)内，并且因此将确定为不能够为第一用户提供运输。
在另一实例中，通过(i)识别当前位置在第一用户的接人位置的预定义距离或预定义区域内的使用中驾驶员(例如，已经在向其他用户提供运输服务的驾驶员)、(ii)针对每个识别的驾驶员确定从该各自目的地位置到第一用户的接人位置的第一预计行程时间以及(iii)针对每个识别的驾驶员将第一预计行程时间与阈值预计行程时间相比较，系统还可确定驾驶员的第二集合。
根据实例，通过定期监控或跟踪个别驾驶员的状态和位置和/或在各种时间接收来自个别驾驶员的状态信息，系统可确定有关驾驶员的信息。例如，驾驶员的第一集合中的每个驾驶员可更新他或她的状态，并且将更新的状态提供到系统，从而向系统表明该驾驶员可用于提供运输服务(例如，在忙碌着或在上班，但不在使用中)。例如，驾驶员可能刚完成让用户在目的地下车，或者可能结束休息或刚开始他或她的轮班，并且可随后使用各自计算装置更新他或她的状态。
在一些实例中，系统也可接收来自当前向用户提供运输的驾驶员的目的地位置信息。正在运输顾客的使用中驾驶员可将目的地位置输入到他或她的计算装置(例如，使用指定应用程序)，所述计算装置随后将目的地信息提供到系统。系统可使用所述目的地信息来确定所述驾驶员是不是能够为另一请求用户提供运输的可行候选人。
根据一些实例，提供一种系统和方法，以优化对用于提供运输的驾驶员的选择。在为运输请求选择驾驶员时执行的优化可包括使用优化目标，所述优化目标以个体或群组为基础最小化运输请求的接人时间。
根据另一方面，一种计算系统操作以同时处理多个运输请求，所述多个运输请求中的每个指定地理区域内的接人位置。在所述多个运输请求中的每个都是开放时的给定时间间隔期间，确定能够在阈值持续时间内履行所述运输请求中的一个或多个的所述地理区域内的候选驾驶员池。为所述多个运输请求中的每个选择驾驶员。在选择所述驾驶员时，所述计算机系统实施优化过程，以便最小化所述多个运输请求中的至少一个的预计接人时间。
根据一个方面，优化过程包括基于驾驶员池来最小化多个运输请求中的至少一些的预计接人时间的聚合。在变型中，优化过程包括基于驾驶员池来最小化个别运输请求的接人时间。
更进一步，通过允许在选择驾驶员之后进行驾驶员重新指派，一些变型为增加驾驶员池做准备。可进行各种类型的重新指派，包括针对给定运输请求调换驾驶员，或者在两个运输请求之中交换驾驶员。在变型中，可响应于一个或多个优化确定来进行重新指派。
术语“最佳”、“优化”或其变型旨在意指通过明智且深思熟虑的考虑来实现对于特定方面或参数而言更期望的结果或后果的行为。与替代过程或者没有深思熟虑地考虑特定方面或参数就执行的过程相比，参考给定过程使用此类术语未必意指实现了最佳结果或后果，而是可意指对于特定方面或参数而言更期望的结果或后果。
如本文中所使用，客户端装置、驾驶员装置和/或计算装置是指对应于台式计算机、蜂窝装置或智能电话、个人数字助理(PDA)、膝上型计算机、平板装置、电视(IP电视)等可提供网络连接性和处理资源，以便通过网络与系统通信。驾驶员装置还可对应于车辆计算系统或自定义硬件等。客户端装置和/或驾驶员装置还可操作被配置成与智能调度系统通信的指定应用程序。
更进一步，尽管本文中描述的一些实例涉及运输服务，但所述系统可使得能够在个人与服务提供者之间安排基于位置的按需服务(例如，快餐车服务、递送服务、娱乐服务)。例如，用户可使用智能调度系统来请求按需服务，诸如，递送服务(例如，食品递送、消息服务、快餐车服务或产品装运)或娱乐服务(例如，墨西哥流浪乐队、弦乐四重奏)，并且所述系统可选择服务提供者(诸如，驾驶员、食品提供者、乐队等)，以便为用户提供按需服务。
本文中描述的一个或多个实例规定由计算装置执行的方法、技术和动作按编程方式或作为计算机实施的方法执行。如本文中所使用，按编程方式意指通过使用代码或计算机可执行指令。这些指令可存储在计算装置的一个或多个存储器资源中。按编程方式执行的步骤可为或可非为自动的。
本文中描述的一个或多个实例可使用编程模块、引擎或部件实施。编程模块、引擎或部件可包括能够执行一个或多个阐明的任务或功能的程序、子例程、程序的一部分或者软件部件或硬件部件。如本文中所使用，模块或部件可独立于其他模块或部件而存在于硬件部件上。可替代地，模块或部件可以是其他模块、程序或机器的共享元件或进程。
本文中描述的一些实例可大体需要使用计算装置，包括处理资源和存储器资源。例如，本文中描述的一个或多个实例可整个地或部分地实施在计算装置上，诸如，服务器、台式计算机、蜂窝电话或智能电话、个人数字助理(例如，PDA)、膝上型计算机、打印机、数码相框、网络设备(例如，路由器)以及平板装置。存储器资源、处理资源和网络资源可全部用于建立、使用或执行本文中描述的任何实例(包括执行任何方法或实施任何系统)。
此外，本文中描述的一个或多个实例可通过使用可由一个或多个处理器执行的指令来实施。这些指令可能携带在计算机可读介质上。下文结合附图示出或描述的机器提供处理资源和计算机可读介质，在所述计算机可读介质上可携载和/或执行用于实施实例的指令。具体而言，结合实例示出的很多机器包括处理器以及用于保存数据和指令的各种形式的存储器。计算机可读介质的实例包括永久存储器存储装置，诸如，个人计算机或服务器上的硬盘驱动器。计算机存储介质的其他实例包括便携式存储单元，诸如，CD或DVD单元、闪存(诸如，携载于智能电话、多功能装置或平板上)以及磁存储器。计算机、终端机、具有网络功能的装置(例如，移动装置，诸如蜂窝电话)都是使用处理器、存储器以及存储在计算机可读介质上的指令的机器和装置的实例。另外，实例可以计算机程序或能够实施此类程序的计算机可用载体介质的形式实施。
系统描述
图1A说明根据实例的用于安排按需运输服务的示例调度系统。根据一些实例，可实施系统100以接收来自计算装置的运输请求，所述计算装置操作以传达运输请求和对应的接人位置。在一些实例中，可实施系统100以接收和处理来自用户的计算装置的运输请求，以实现为计算装置的用户安排运输。尽管参考用于将车辆运输服务提供给乘客的系统100描述了很多实例，但各种实例所提供的运输服务的类型可扩展到其中人或对象将从接人位置被运输到目的地的任何服务。在一个实施方案中，至少部分地基于用户指定的接人位置，系统100针对一个或多个运输请求确定驾驶员池。系统100也基于个别驾驶员的服务状态以及个别驾驶员的位置信息(例如，当前位置、目的地位置)来确定驾驶员池。如更详细地描述，通过使用驾驶员池中的驾驶员的服务状态和位置信息，系统100对个别运输请求作出响应从而为运输请求选择驾驶员。
根据一个实例，系统100包括调度110、客户端装置接口120、驾驶员装置接口130、请求管理器140以及管理员接口160。系统100还包括用于存储记录和信息的多个数据库，包括至少客户端数据库150、规则数据库165以及驾驶员数据库116。多个客户端装置170和多个驾驶员装置180可使用(例如)各自的指定服务应用程序(例如，被配置成与系统100通信)通过一个或多个网络与系统100通信。系统100的部件组合起来以：(i)接收来自客户端装置170的运输请求171；以及(ii)针对运输请求171优化对驾驶员的选择。运输请求的优化可针对个别运输请求或者同时针对群组(例如，两个或更多)运输请求。可用各种应用程序(例如，软件)和/或用实施系统100的计算机系统的硬件来实施逻辑。
取决于实施方案，系统100的一个或多个部件可在网络侧资源上实施，诸如，在一个或多个服务器上实施。系统100也可通过替代架构(例如，对等网络等)中的其他计算机系统实施。作为补充或替代例，系统100的一些或所有部件可在客户端装置上实施，诸如，通过在客户端装置170和/或驾驶员装置180上操作的应用程序。例如，可执行诸如服务应用程序等客户端应用程序，以实施由系统100的各种部件描述的过程中的一个或多个。系统100可通过网络经由网络接口(例如，无线或使用有线)通信，以与一个或多个客户端装置170和一个或多个驾驶员装置180通信。
系统100可通过一个或多个网络分别使用客户端装置接口120和装置接口130与客户端装置170和驾驶员装置180通信。装置接口120、130可每个管理系统100与各自计算装置170、180之间的通信。在本文所述的一些实例中，客户端装置170和驾驶员装置180可每个操作服务应用程序，所述服务应用程序可分别与装置接口120、130建立接口，以与系统100通信。根据一些实例，应用程序可包括或使用应用程序设计接口(API)(诸如，面向外部的API)，以与装置接口120、130传达数据。面向外部的API可通过网络使用任何数量的方法经由安全访问通道来提供对系统100的访问，诸如，基于网络的形式、经由restful API的编程访问、简单对象访问协议(SOAP)、远程过程调用(RPC)、脚本访问等。
在本文所述的实例中，当生成对应的运输请求171时，客户端装置170执行对应的服务应用程序。在一个实施方案中，例如，当请求从接人位置的运输时，响应于对应用户提供输入(例如，响应于用户选择从应用程序的执行中提供的用户接口特征)，可自动生成运输请求171。在一个实例中，来自个别用户的运输请求171可指定用户标识符(ID)121和接人位置123。在一些变型中，运输请求171指定车辆类型125(或替代地，服务类型)和/或目的地位置127。例如，接人位置123可对应于客户端装置170的当前位置(例如，作为默认设置)、客户端装置170的将来位置和/或由来自客户端170用户的手动输入指定的位置。例如，客户端装置170可接收对应于运输请求的用户输入。客户端装置170的服务应用程序可利用地理感知资源(诸如，通过个别装置的全球定位系统(“GPS”)部件提供)，以便将各自客户端装置170的当前位置自动确定为接人位置。作为变型，用户可提供对应于地址、街道十字路口或者地名(例如，商店、餐厅、建筑物、公园、相关地点等)的输入。更进一步，客户端装置170的用户可使用各自客户端装置170的地理感知资源，以便指定并非装置的当前位置而是用户指定的地图位置的接人位置。例如，用户可以移动显示在地图上的可选特征，以便按编程方式生成接人位置123。
在图1A的实例中，系统100接收来自客户端装置170的运输请求171。运输请求171可通过一个或多个网络(例如，通过蜂窝网络)经由客户端装置接口120传达到系统100。在一个实例中，通过关于请求用户来更新有关运输请求171的信息并将其存储在客户端数据库150中，请求管理器140可处理个别运输请求171。例如，每个运输请求171可与对应的用户ID 121相关联。请求管理器140可管理请求用户的事务，例如，通过(i)与调度110通信以确定驾驶员的状态、(ii)将有关请求的运输服务的状态的通信提供到客户端装置170、(iii)确定是否完成运输服务、(iv)针对用户的支付来与金融实体通信以及(v)维持和更新客户端数据库150中的用户的客户端信息。
在一个实例中，请求管理器140可处理个别运输请求171(或来自运输请求171的相关信息，诸如，接人位置123、车辆类型125和/或目的地位置127)并将其转发到调度110，诸如，转发到调度110的接人确定部件114。在一个实例中，接人确定部件114可确定是为请求用户提供运输的候选人的池(或多个驾驶员)。至少部分地基于对应用户的接人位置123以及有关候选驾驶员的位置和其他信息，通过执行计算来确定有关一个或多个运输请求171的度量，接人确定部件114可确定哪些驾驶员是为用户提供运输的候选人。在忙碌着的驾驶员的位置信息113可从驾驶员数据库116中检索到。
更具体而言，在一些变型中，有关驾驶员的信息可存储在驾驶员数据库116中。驾驶员跟踪112可经由驾驶员装置接口130接收来自多个驾驶员装置180的驾驶员服务状态信息131。例如，驾驶员服务状态131可指定个别驾驶员的服务状态。根据一些变型，个别驾驶员的服务状态131可包括：(i)开放状态，即驾驶员在忙碌着并且可用，但未被指派给任何运输请求；(ii)占用状态，其中驾驶员被指派给运输请求；和/或(iii)初步指派状态，其中驾驶员被指派给运输请求并且所述指派满足新近的条件或其他条件。如结合一些实例所述，一些变型说明驾驶员池中的驾驶员具有变化的服务状态131。
可从系统100跟踪指派、路线以及各自驾驶员的可用性来确定服务状态131。驾驶员装置180也可提供有关驾驶员的位置信息连同驾驶员的标识符(ID)133、驾驶员的当前位置135(其可由驾驶员装置180的GPS部件确定)和/或驾驶员的目的地位置137。驾驶员跟踪112可针对每个各自驾驶员(使用驾驶员ID 133)用驾驶员信息来实时更新驾驶员数据库116。通过这种方式，调度110可持续(或定期)监控系统100的驾驶员的当前位置115和服务状态131。
根据实例，关于驾驶员到达由给定运输请求指定的接人位置所需的时间量(也称为“接人时间”)，可以针对运输请求优化对驾驶员的选择。例如，基于请求用户的接人位置123，接人确定部件114可(例如)从可能的授权驾驶员中确定能够为给定的运输请求提供运输的驾驶员池或多个驾驶员。
在一些实例中，接人确定部件114访问驾驶员数据库116，以确定在忙碌着(例如，在上班)并且可用(例如，当前没有开车将顾客送往目的地和/或当前没有开车去接特定顾客)的驾驶员的第一集合。在变型中，可在从给定地理区域中生成的多个运输请求的群组层次上做出这个确定(接人确定部件114的输出)。
在一个实施方案中，接人确定部件114可访问驾驶员数据库116，以基于驾驶员的当前位置信息113识别在接人位置123的预定义距离内、在接人位置123的预计行程时间内(基于预计的预测路线)和/或在接人位置123的预定义区域内的驾驶员。例如，预定义距离(诸如，十英里、十五英里等)、预计行程时间(诸如，以分钟为单位等)或者预定义区域(诸如，城镇或城市的区域，或者自定义和配置的地理区域)可由系统100的管理员指定(例如，经由使用管理员接口160提供给系统100的管理员输入161)。例如，针对每个授权驾驶员，接人确定部件114可计算或确定给定接人位置123与所述驾驶员的当前位置113之间的距离，并且将该距离与预定义距离相比较。作为补充或替代例，调度110可包括每个被指定用于在特定地理区域(例如，每一大城市地区、每一城市、每一州等)中营运的驾驶员的多个驾驶员数据库116。基于接人位置123所在的区域，接人确定部件114可(i)确定在该区域中的当前位置是在各自接人位置123的预定义距离或区域内的授权驾驶员，或者替代地(ii)例如，针对该区域中的每个授权驾驶员，计算接人位置123与该驾驶员的当前位置113之间的距离并且将所述距离与预定义距离相比较。
接人确定部件114可从较大的驾驶员池中过滤掉不在接人位置123的预定义距离或区域内的驾驶员，例如，过滤掉被分类或确定成离用户的接人位置123太远的驾驶员。接人确定部件114也可访问驾驶员数据库116，以便从在接人位置123的预定义距离、预计行程时间或区域内的驾驶员中确定具有使得他们成为为开放的运输请求提供运输的候选人的服务状态131的那些驾驶员(例如，营业中的驾驶员)。如结合一些实例所述，当各自服务状态的驾驶员具有满足专用于特定服务状态的一个或多个条件的位置或状态时，具有不同服务状态(例如，占用、初步指派)的驾驶员可被视作可用于给定的运输请求。例如，如果具有占用服务状态的驾驶员在特定时刻到达目的地的时间或距离少于阈值，那么所述驾驶员可被视作可用于给定地理区域中的运输请求。同样地，如果驾驶员的接人选择满足一些标准，诸如，具有少于给定阈值时间(例如，自初步做出驾驶员的指派之后少于两分钟)的寿命的接人指派，那么具有途中服务状态(或初步接人指派)的驾驶员可被视作可用于运输请求。满足此类条件(其可取决于实施方案和所考虑的服务状态而变化)的驾驶员可被识别为将运输服务提供给个别运输请求的候选人。
通过另一实例，接人确定部件114可将候选驾驶员识别为下列所述驾驶员：(i)在使用中；(ii)基于驾驶员的当前位置信息113(诸如，上文所述)而在接人位置123的预定义距离内和/或在接人位置123的预定义区域内；以及(iii)正在为另一运输请求提供运输，其中目的地位置在请求用户的接人位置123的阈值距离或预计行程时间内。通过这种方式，如果驾驶员的目的地(例如，当前顾客的下车位置)靠近或接近给定的接人位置，那么调度110可确定使用中驾驶员(当前正在为另一顾客提供运输服务)可以是为请求用户提供服务的可能候选驾驶员。在这个背景下，术语“接近”可以是两个参考点之间的距离和/或预计行程时间的参考。
在实例中，具有占用服务状态131的驾驶员可与目的地位置137相关联(即，其中占用驾驶员的旅客可能到达终点)。目的地位置137可由(例如)请求运输的用户(例如，乘客)或具有占用状态的驾驶员手动输入。在变型中，目的地位置137可通过编程分析确定，诸如，通过具有使用中状态的驾驶员的给定乘客先前在哪里下车的历史分析。在变型中，接人确定部件114可以基于下列至少一个来预计或预测目的地位置或者预计目的地位置所在的区域：(i)使用中驾驶员的当前行程方向；(ii)请求用户的先前接人位置和目的地位置；(iii)正由驾驶员运输的用户的频繁目的地位置；或(iv)其他因素，诸如，一天中的时间、地理区域或城市中的事件日历等。
在一个实例中，针对具有占用服务状态131和当前(或未来预计)位置在当前接人位置123的预定义距离内的每个使用中驾驶员，接人确定部件114可确定(i)从驾驶员的各自目的地位置到请求用户的接人位置123的距离，和/或(ii)从所述驾驶员的各自目的地位置到请求用户的接人位置123的第一预计行程时间。取决于实施方案，接人确定部件114可使用来自其他源的信息111来预测预计行程时间(例如，来自其他外部/远程数据库或源，或者来自系统100的其他数据库，图1A中未示出)。例如，针对具有占用服务状态131的每个驾驶员，通过预测或确定驾驶员从各自目的地位置到接人位置123将采用的最可能路线，接人确定部件114确定从所述驾驶员的各自目的地位置到接人位置123的距离和/或预计行程时间。
另外，可基于许多不同因素来确定预计行程时间和最可能路线，诸如，(i)关于先前驾驶路线的驾驶员的历史信息(其可存储在驾驶员数据库116和/或历史数据库中)、(ii)当前交通状况、(iii)日期和/或一天中的时间(例如，早上、下午、深夜、高峰时间等)、(iv)当前天气状况、(v)来自地图数据库的地图信息(例如，附近是哪种类型的道路、隧道、桥梁、单行道等)、(vi)驾驶员的当前位置113和接人位置123(例如，位置在什么样的邻近地区)以及其他信息(例如，街道车速限制、列车时刻表、城市事件日历、建筑区域等)。此类信息可从其他源接收或检索到(例如，信息111)。例如，在工作日的下午7点，当时加利福尼亚州的旧金山(San Francisco)正在下雨，接人确定部件114可确定从点A(使用中驾驶员的目的地位置)到点B(请求用户的接人位置123)的预计行程时间比相同点A和B在晴天的星期六上午10点的预计行程时间要长。
对于具有占用服务状态131的驾驶员而言，如果从目的地位置到接人位置123的确定距离和/或预计行程时间在阈值距离和/或阈值预计行程时间内，那么接人确定部件114可将该驾驶员识别为向特定运输请求或运输请求的群组提供运输的候选人。阈值距离和/或阈值预计行程时间也可由系统100的管理员经由管理员接口160进行配置。
对于具有初步指派的服务状态131的驾驶员而言，驾驶员跟踪112可经由驾驶员装置接口130来监控自从特定驾驶员被指派有运输请求时算起的时间或距离。如果自从驾驶员被指派有运输请求时算起的时间或距离小于阈值，那么其特定驾驶员也可被视作运输请求或运输请求的群组的候选人。
在一些实例中，运输请求171可请求或以其他方式专用于车辆类型125(例如，轿车、SUV、豪华轿车、混合动力车、非黑色小轿车等)。在此类实例中，接人确定部件114可从驾驶员数据库116中确定具有对应车辆类型125的可能授权驾驶员。从具有对应车辆类型125的驾驶员中，接人确定部件114可确定能够为请求用户提供运输的驾驶员群组(例如，包括在忙碌着的并且可用的驾驶员的第一集合，以及满足距离和/或预计行程时间阈值的使用中驾驶员的第二集合(例如，具有占用服务状态的那些驾驶员)，如所论述)。
根据一些实例，优化子系统184可具备调度110，以便通过优化个别运输请求的接人时间来优化对驾驶员的选择。如更详细地描述，优化子系统184可包括逻辑部件和过程，其共同操作以利用可用驾驶员与个别运输请求之间的距离和时间测量。在图1A的实例中，优化子系统184包括接人确定部件114、驾驶员选择部件(“驾驶员选择118”)、优化逻辑128和/或规则集(例如，规则数据库165)。在接人确定部件114识别能够为请求用户提供运输的多个驾驶员(包括驾驶员的第一集合和第二集合)之后，接人确定部件114可将度量117(例如，驾驶员的当前位置信息115、确定的距离和/或预计行程时间信息、驾驶员的服务状态131)以及对应的驾驶员ID 133提供到驾驶员选择118。驾驶员选择118可实施优化逻辑128，以便基于优化目标和相关联的标准针对驾驶请求选择驾驶员。根据一些实例，优化子系统184可基于预计接人时间关于运输请求来优化对驾驶员的选择。取决于实施方案，优化子系统184可基于单个或个别运输请求针对运输请求来优化对驾驶员的选择。在变型中，优化子系统184也可基于群组针对运输请求来优化对驾驶员的选择。当针对运输请求选择驾驶员时，驾驶员选择118使用接人请求的接人位置123(例如，单个运输请求优化)，或者多个运输请求中的每个的接人位置(例如，群组运输请求优化)。针对每个接人位置123，驾驶员选择118使用度量117以针对所述运输请求选择驾驶员。驾驶员选择118也可接收来自驾驶员数据库116的有关在忙碌着的驾驶员的位置信息115以及来自客户端数据库150的有关请求用户155的信息，以实现驾驶员选择的目的。
在一些实例中，基于有关针对特定运输请求的候选驾驶员的集合之中的最低预计接人时间的确定，驾驶员选择118可执行驾驶员选择过程。在变型中，根据针对运输请求群组来优化接人时间的目标，驾驶员选择118可基于群组来实施优化。在做出确定的过程中，驾驶员选择118可实施优化逻辑128，所述优化逻辑可提供过程或基于规则的方法，以便针对个别运输请求来优化接人时间。例如，优化逻辑128可实施递归过程，以基于可识别候选驾驶员的距离范围的变化、考虑使用的可用服务状态和/或在做出驾驶员选择之前的等待时间来针对一个或多个运输请求确定最佳接人时间。
作为补充或变型，驾驶员选择118可将一个或多个规则167用于为个别运输选择驾驶员。规则167可进一步定义优化，或者可替代地对驾驶员的确定提供限制、约束或过滤。在一个实施方案中，规则167可为预定的并且提供在规则数据库165中。在一些变型中，基于优化逻辑128的结果，可对规则进行参数化和/或加权。更进一步，在一些变型中，系统100的管理员可访问管理员接口160，以提供对应于操作参数163的输入161。这些参数163可作为规则167存储在规则数据库165中，调度110可使用所述规则以便(i)确定哪些驾驶员能够或有资格为请求用户提供运输服务以及(ii)从多个识别的驾驶员中为请求用户选择驾驶员。例如，参数163可将优化逻辑128配置用于驾驶员选择。
例如，规则数据库165可存储有关由接人确定部件114用来确定足够靠近以便为用户提供运输服务的多个驾驶员(例如，在请求用户的接人位置123的预定义距离或预定义区域内的那些驾驶员)的预定义距离或区域的信息。规则数据库165也可提供接人确定部件114用于确定特定使用中驾驶员是否能够为请求用户提供运输服务的阈值距离和阈值预计行程时间。提供给这些参数中的每个的值可根据优化目标而变化(例如，针对个别运输请求减少接人时间，针对群组中的每个运输请求减少接人时间的聚合)。例如，如一个或多个规则167所指定，如果使用中驾驶员的总预计行程时间(包括从使用中驾驶员的当前位置135到目的地位置137的预计行程时间与从目的地位置137到请求用户的接人位置123的预计行程时间的总和)等于或大于阈值预计行程时间，那么接人确定部件114并不将该使用中驾驶员包括作为能够为用户提供运输服务的驾驶员池的一部分。
更进一步，一个或多个规则167也可动态指定基于各自驾驶员的当前位置135和运输请求的接人位置123为个别授权驾驶员调整调度范围(dispatch radius)(例如，阈值距离和/或阈值预计行程时间)。不同的驾驶员可与用于确定该驾驶员是不是为用户提供运输的候选人(例如，基于驾驶员状态和/或位置)的不同调度范围相关联。例如，驾驶员A和驾驶员B都可以在旧金山并且在接人位置123(即，旧金山的街道十字路口)的预定义距离或预定义区域内。然而，基于驾驶员A和驾驶员B中的每个的当前位置和/或用户的接人位置123，驾驶员A的阈值距离(例如，两英里)可以比驾驶员B的阈值距离(例如，四英里)小。例如，驾驶员A可能在旧金山的高度拥塞闹市区，具有大量的十字路口和红绿灯，而驾驶员B可能在不太拥塞和/或车速限制较高或红绿灯较少的区域。类似地，例如，当前在郊区或在交通快速移动的高速公路上的驾驶员可增大他或她的调度范围(与当该驾驶员在城市中时他或她的调度范围相比)。当调度范围增大时，驾驶员被视作能够为请求用户提供运输的概率更高。
作为补充或替代例，例如，特定驾驶员或驾驶员群组的调度范围可被设置为零，以便禁止特定驾驶员或多个驾驶员(例如，阻止驾驶员接送用户)。在特定地理区域(诸如，由地图上的三个或更多点(例如，由管理员使用管理员接口160输入)指定的预先配置的区域)中的多个驾驶员可每个具有动态调整成零的调度范围，以便驾驶员在处于特定区域中时不能被调度。
在其他实例中，规则数据库165可存储规则167，驾驶员选择118可使用所述规则从有能力的驾驶员中为请求用户选择驾驶员。根据一些实例，规则167可指定驾驶员选择118可如何对驾驶员排列优先顺序或排名，并且选择最高优先级或排名的驾驶员。例如，优先级或排名可由调度110使用，以便如果第一被选驾驶员不接受提供运输服务的邀请，那么选择下一排名或优先级的驾驶员并邀请其提供运输服务，依次类推。规则167可指定基于下列一个或多个对有能力的驾驶员排列优先顺序：(i)在忙碌着的驾驶员从她的当前位置113到请求用户的接人位置123的距离、(ii)在忙碌着的驾驶员从她的当前位置113到接人位置123的预计行程时间、(iii)使用中驾驶员从她的当前位置113到接人位置123的总距离(从她的当前位置113到各自目的地位置的第一距离与从该目的地位置到接人位置123的第二距离的总和)和/或(iv)使用中驾驶员从她的当前位置113到接人位置123的总预计行程时间(从各自目的地位置到接人位置123的第一行程时间与从她的当前位置113到各自目的地位置的第二行程时间的总和)。在一个实例中，规则167可指定基于总距离对有能力的驾驶员进行排名，以使得最短距离的优先顺序高于较长距离，或者基于总预计行程时间对有能力的驾驶员进行排名，以使得最短预计行程时间的优先顺序高于较长预计行程时间。
另外，规则167也可指定基于下列一个或多个对有能力的驾驶员排列优先顺序：(i)驾驶员的反馈信息(例如，驾驶员的等级)、(ii)请求用户的反馈信息、(iii)有能力的驾驶员中的任一个先前是否为该请求用户提供运输服务(例如，如果该请求用户对先前使用的驾驶员给出良好反馈，则与其他有能力的驾驶员相比，选择或优先考虑先前使用的驾驶员)、(iv)驾驶员偏好、(v)用户偏好、(vi)有关驾驶员的个人信息(例如，性别、年龄等)、(vii)有关用户的个人信息(例如，来自客户端数据库150)、(viii)驾驶员的车辆的车龄(例如，与较老的车辆相比，优先考虑较新的车辆)以及其他因素。上述因素的任一组合可由驾驶员选择118用来优先考虑能够为用户提供运输的所确定的驾驶员，并且为该用户选择驾驶员。例如，在一个实施方案中，规则167可使得能够将不同权重应用于不同的因素，以实现优先考虑有能力的驾驶员的目的。
作为实例，接人确定部件114确定能够为请求在加利福尼亚州旧金山(San Francisco,CA)的接人位置123进行运输的用户提供运输的五个驾驶员(D1、D2、D3、D4和D5)。D1和D2可能是可用的在忙碌着的驾驶员，而D3、D4和D5可能是正开往各自目的地的使用中驾驶员。基于不同的配置规则167，在一个实例中，接人确定部件114可基于从各自的当前位置到接人位置123的最短预计行程时间对驾驶员进行排名或排列优先顺序，诸如，D3(四分钟)、D2(五分钟)、D4(八分钟)、D1(十分钟)和D5(十一分钟)，并且选择具有最短预计行程时间的D3来接送用户。在另一实例中，接人确定部件114可确定D2先前为该用户提供运输服务，并且该用户为D2指出正面反馈或等级(例如，五星中的五星)。接人确定部件114可与D3相比优先考虑D2和/或如果D2的预计行程时间并不明显比D3的预计行程时间长(例如，在阈值时间差内)，则选择D2而不是D3(即使D3具有更短预计行程时间)。根据其他实例，基于规则167，接人确定部件114可基于距离、预计行程时间、驾驶员的状态(例如，驾驶员是可用还是在使用中)、车辆类型、车辆的车龄、用户/驾驶员偏好等的组合中的任一个来对驾驶员排列优先顺序。例如，预计行程时间(和/或距离)与车辆的年龄(例如，在预计行程时间基本上相似的情况下，可在较老车辆之前优先考虑较新的车辆)的组合可用于对有能力的驾驶员排列优先顺序。
响应于选择驾驶员，调度110可经由驾驶员装置接口130将邀请消息183传输到所选择的驾驶员的对应驾驶员装置180(例如，使用驾驶员ID 133)。邀请消息183可被视作在驾驶员装置180上运行的服务应用程序的接口的一部分。邀请消息183可包括有关请求用户的信息、用户的接人位置，并且提供可选特征以使得驾驶员能够接受运输服务或者驳回/拒绝运输服务。例如，当驾驶员已经在驾车将另一顾客送往各自目的地时，驾驶员可接收邀请消息183，甚至在让另一顾客下车之前驾驶员就可接受所述邀请消息。如果驾驶员拒绝运输服务，那么调度110接收驳回，并且驾驶员选择118为请求用户选择另一驾驶员。在一个实例中，每次接收到驳回，驾驶员选择118都可继续选择驾驶员，直到再没有可用的有能力的驾驶员为止。当没有驾驶员可用时，调度110可通知请求管理器140错误或者没有驾驶员可用，以使得请求管理器140可将状态信息126提供到请求用户的客户端装置170以通知用户无法安排运输。
如果驾驶员接受运输服务，那么调度110可将有关驾驶员的信息提供到请求管理器140(或者驾驶员ID 133，以使得请求管理器140可从驾驶员数据库116中检索必要的驾驶员信息)。通过经由客户端装置接口120将状态消息126传输到请求用户的客户端装置170，请求管理器140可通知请求用户已经选择了驾驶员。状态消息126可包括信息，诸如，有关驾驶员的信息(例如，驾驶员的图像和姓名、车牌照号码)和有关运输服务的信息(例如，预计到达时间)。请求管理器140可管理请求用户的事务，并且当已经完成运输服务时，安排支付和更新客户端数据库150中的用户的客户端信息(例如，记录旅程、生成收据)。
通过这种方式，甚至当驾驶员的服务状态131是在使用中或已指派时，调度110也可智能地选择为用户提供运输的驾驶员。何时指派此类驾驶员的确定可从优化逻辑128的实施方案来确定，所述优化逻辑可实施减少单个运输请求或多个运输请求的接人时间的目标。参考图1B、图1C、图4和图5A以及图5B的实例进一步描述用于实施优化以减少接人时间的这些和其他实例。
多方乘车共享
根据一些实例，接人确定部件114也可将驾驶员的第三集合(“乘车共享驾驶员集合”)确定为针对给定运输请求提供运输的候选人(例如，除了上文所论述的驾驶员的第一集合和驾驶员的第二集合之外)。更具体而言，根据一些实例，驾驶员的乘车共享驾驶员集合可包括当前在使用中但也被视作能够为请求用户提供运输的驾驶员，依据的是(i)在让当前顾客下车的行程期间的驾驶员的各自当前位置、(ii)驾驶员的各自目的地(例如，当前顾客的目的地)、(iii)用户的接人位置以及(iv)用户的各自目的地。
例如，接人确定部件114可访问驾驶员数据库116，以识别下列驾驶员：(i)在使用中、(ii)具有在接人位置123的第一阈值距离和/或第一阈值预计行程时间内的各自当前位置113以及(iii)具有在从请求用户的目的地位置127算起的第二阈值距离和/或第二预计行程时间内的各自目的地位置137。通过这种方式，如果当前正将顾客带往目的地的驾驶员足够靠近请求用户的接人位置并且如果两个目的地位置相对靠近彼此，那么该驾驶员可被分类成能够为请求用户提供运输。调度110可假设顾客和请求用户两者的行程和目的地的大体方向足够靠近，以使得顾客和请求用户将同意共享乘车并且分摊车费。例如，使用第一阈值距离或预计行程时间，以使得使用中驾驶员(和当前顾客)将不必走得很远并且顺路就能接到请求用户进行乘车共享，而使用第二阈值距离或预计行程时间，以使得使用中驾驶员不必将当前顾客和请求用户(一旦接到他或她)带到远离彼此的两个不同位置或方向。接人确定部件114可包括池中的这些驾驶员(作为乘车共享驾驶员的第三集合)或者能够向请求用户提供运输的多个驾驶员。
在此类实例中，请求用户可提供输入(例如，使用在客户端装置170上运行的应用程序的接口)，以便(i)当请求用户做出运输请求171时选择他或她愿意共享乘车或不愿意共享乘车的选项(例如，通过选择“乘车共享”车辆类型125)，或者(ii)在用户的简介中指定他或她愿意共享乘车或不愿意共享乘车。例如，用户可操作客户端装置170来提供输入，以更新用户的简介(例如，账户信息、支付信息、乘车共享信息)，并且系统100可更新客户端数据库150中的客户简介。当用户做出运输请求171时，请求管理器140可访问用户的简介，以确定共享信息151(例如，请求用户是否愿意共享乘车)和/或接收共享信息151作为运输请求171的一部分。类似地，正在由使用中驾驶员提供运输的现有顾客也可能在先前做出请求时已经指定有“乘车共享”车辆类型125，或者可能已经在他或她的简介中指定有共享信息151。
通过这种方式，对于愿意共享乘车的请求用户而言，接人确定部件114可确定满足一个或多个条件(基于规则167)的乘车共享驾驶员的集合(例如，除了如上文所论述的在忙碌着的驾驶员的第一集合和使用中驾驶员的第二集合之外)，例如，下列驾驶员：(i)在使用中(和/或已提供输入：车辆中有至少一个可用座位，例如，具有空位)、(ii)具有在接人位置123的第一阈值距离和/或第一阈值预计行程时间内的各自当前位置113以及(iii)具有在从请求用户的目的地位置127算起的第二阈值距离和/或第二预计行程时间内的各自目的地位置137。另外，在一个实例中，针对乘车共享驾驶员中的每个，正被运输的各自顾客将具有表示他或她愿意与其他用户共享乘车的对应共享信息151。
如上文所论述，一旦接人确定部件114确定能够向请求用户提供运输的多个驾驶员，驾驶员选择118便可对有能力的驾驶员排列优先顺序或排名，并且为请求用户选择驾驶员。使用指定驾驶员的优先级和/或选择的一个或多个规则167，驾驶员选择118可选择第一驾驶员，并且调度110可将邀请消息183传输到第一驾驶员的驾驶员装置180。例如，在一个实例中，驾驶员选择118可使用距离或预计行程时间度量117和驾驶员的状态(例如，驾驶员是在第一集合中、在第二集合中还是在第三集合中)，以将有能力的驾驶员排列优先顺序。乘车共享集合中的那些驾驶员比第一或第二集合中的驾驶员可被排列更高的优先顺序，以使得对于请求用户而言，运输服务可更便宜(例如，由于分摊了车费)。其他因素和规则167可由驾驶员选择118用来将驾驶员排列优先顺序并且选择驾驶员。
在一个实例中，所选择的驾驶员(诸如，第三集合中的驾驶员)可接收邀请消息183并且确定她是否想要接受运输请求。邀请消息183可包括有关请求用户和该用户的接人位置的信息，以使得驾驶员可做出是否接送该用户的最终决定(例如，如果驾驶员确定用户太远或者目的地不顺路，那么她可能不想要接送用户)。如果驾驶员接受请求，那么请求管理器140接收该信息，并且向请求用户的客户端装置170提供通知。在另一实例中，驾驶员可能先前已指定(当登录为上班时)车辆类型。此类车辆类型可对应于“乘车共享”车辆类型。当驾驶员指定此类车辆类型以准许接送多个请求用户时，邀请消息183可由驾驶员服务应用程序自动接受(例如，因为驾驶员已经同意提供乘车共享服务)。
根据一个实例，当乘车共享集合的驾驶员接受请求时，从接受调度的时间到当前顾客或请求用户中的一个在目的地位置下车的时间的车费可在顾客与请求用户之间平均分摊。这可为正被带离道路以接送请求用户的当前顾客提供激励。另外，当另一用户做出请求时，尽管车辆中有两个当前用户去往两个不同的目的地，但同一使用中驾驶员仍可以是为随后用户提供运输的候选人。类似地，基于使用中驾驶员接受调度的时间，车费可以在乘车共享用户之间分摊。
通过这种方式，当用户做出运输请求时，至少部分地基于用户提供的位置信息(接人位置和/或目的地位置)和驾驶员的当前状态和/或位置信息，调度系统可针对所述用户优化对驾驶员的选择。尽管没有完成运输，但当前正向其他用户提供运输的驾驶员仍可被识别为请求用户的候选驾驶员。
用于单个或群组目标的优化子系统
图1B说明根据实例的用于以优化运输请求的接人时间的方式来选择所述运输请求的驾驶员的优化子系统184的第一实施方案。图1C说明根据实例的用于以共同优化运输请求群组的接人时间的方式来选择运输请求的驾驶员的优化子系统184的第二实施方案。
参考图1B，优化子系统184包括接人路线确定186、接人确定188以及驾驶员选择118(例如，诸如图1A中描述)。接人路线确定186和接人确定188可由图1A的实例的接人确定部件114实施。路线确定186接收下列项作为输入：(i)请求用户的接人位置185(例如，如由请求171提供)以及(ii)驾驶员位置信息115。在一个实施方案中，驾驶员位置信息115包括具有开放的服务状态的驾驶员。在变型中，驾驶员位置信息115包括具有使用中的服务状态的候选驾驶员，包括近乎完成现有运输的驾驶员和/或已被新指派给特定运输请求的驾驶员(例如，在去往运输请求的接人位置的途中的驾驶员)。
接人路线确定186计算可用或候选驾驶员与接人位置185之间的路线。在一个实施方案中，接人路线确定186为每个可用或候选驾驶员选择到达接人位置185的路线(“驾驶员到接人路线187”)。驾驶员到接人路线187可基于一个或多个标准，包括最短距离、多数使用的公路、实时交通报告和/或其他考虑。接人时间确定188可基于驾驶员到接人路线187为每个驾驶员确定驾驶员接人时间189。第三方地图服务191可用来确定会影响路线选择和行程时间两者的道路和/或交通状况。在变型中，由接人路线确定186和/或接人时间确定188提供的功能可基本上或部分地通过第三方地图服务来提供，例如，该服务可提供两个点(例如，驾驶员的当前或预期位置与运输请求的接人位置)之间的路线选择和/或行程时间。
在图1B的实例中，驾驶员选择118通过比较驾驶员接人时间189来为运输请求选择驾驶员。例如，对驾驶员配对193的确定可基于最小驾驶员接人时间189。通过这种方式，可针对接人时间对驾驶员配对193进行优化。
某些参数可影响可用或候选驾驶员的数量，并且因此影响所选择的驾驶员配对193的接人时间。一个此类参数是在确定可用或候选驾驶员时的持续时间。持续时间越长，可针对特定运输请求考虑的驾驶员越多。然而，用于确定驾驶员池的持续时间(“池持续时间195”)表示优化的成本，这是因为如果池持续时间195太长，那么给定运输请求的最终接人时间可被这个参数单独延长。在一个实施方案中，优化逻辑128可与驾驶员选择118一起操作，以便调整或选择池持续时间195，从而优化所选择的驾驶员的接人时间。例如，优化逻辑128可接收驾驶员配对193的接人时间，并且随后将该时间与将在替代池持续时间中被选择的驾驶员的假设接人时间进行比较。例如，统计或学习模型可用来基于一些因素来设置池持续时间195，所述因素诸如可用或候选驾驶员的数量、一天中的时间、交通量等。
可影响可用或候选驾驶员的数量的另一参数是从中可确定可用或候选驾驶员的地理范围参数196。较大的地理范围可增加从中可进行选择的池中的驾驶员的数量。但如果范围太大，那么为特定运输请求识别合适驾驶员的可能性会变得更小。优化逻辑128也可扩展或缩短与特定运输请求相关的地理范围，以便获得从中可确定驾驶员配对193合适的驾驶员池。
因此，在一些变型中，可实施优化逻辑128，以调节或调整可直接或间接影响确定驾驶员配对的优化目标的参数。在图1B的实例中，当确定路线确定186和/或接人时间确定188的输入时，优化逻辑128可用信号通知或设置最佳池持续时间195和地理范围196。
参考图1C，优化子系统184实施替代优化目标，以优化运输请求群组的接人时间的聚合。例如，在高峰期并且在给定地理区域中，在给定时间(例如，可在大约类似时间做出多个请求)m个运输请求可开放并且未指派(或未履行)，并且取决于用于确定驾驶员可用性和候选人的规则和初始参数(例如，地理范围、池持续时间、可成为候选人的驾驶员的服务状态等)，可用的驾驶员池的范围可在r与p之间。实例识别出当优化目标涉及单个运输请求而不是作为整体的群组时，个别运输请求的接人时间可以优化，但群组的接人时间可变成不是最佳的。因此，作为诸如图1B提供的其他实例的补充或替代例，优化子系统184可实施在任何一个时间最小化用于运输请求的聚合的接人时间的目标。
与图1B的实例一样，优化子系统184可包括接人确定部件114和驾驶员选择118的过程。接人确定部件114可包括接人路线确定186和接人时间确定188，而驾驶员选择118包括群组接人时间计算器192以及群组驾驶员和运输请求选择194(“群组选择194”)。群组驾驶员和运输请求选择194的输出可包括多个驾驶员和运输请求配对193。路线确定186接收下列项作为输入：(i)接人位置190，表示在给定的持续时间期间由多个运输请求171提供的接人位置(例如，见图1A)；以及(ii)驾驶员位置信息115。与其他实例一样，驾驶员位置信息115可包括具有开放的服务状态的驾驶员，以及具有使用中的服务状态的候选驾驶员的驾驶员位置信息115(例如，近乎完成现有运输的驾驶员和/或已被新指派给特定运输请求的驾驶员)。
接人路线确定186计算可用或候选驾驶员与表示运输请求的群组的多个接人位置190中的每个之间的路线。假设可用和候选驾驶员与接人位置足够地接近，那么接人路线确定部件可确定每个可用或候选驾驶员与每个接人位置之间的路线。在一个实施方案中，例如，接人路线确定186使用诸如多数使用的公路、实时交通报告和/或其他考虑的标准为多个接人位置190中的每个确定驾驶员到接人路线187。接人时间确定188可为每个驾驶员到多个接人位置190中的每个来确定驾驶员接人时间189。与其他实例一样，第三方地图服务191可用来确定道路和/或交通状况，这些状况可影响路线选择和在每个驾驶员与每个接人位置之间确定的路线的行程时间两者。在变型中，由接人路线确定186和/或接人时间确定188提供的功能可基本上或部分地通过第三方地图服务191来提供，例如，该服务可提供两个点(例如，驾驶员的当前或预期位置与未决运输请求提供的多个接人位置中的一个)之间的路线选择和/或行程时间。
在实例中，群组接人时间计算器192将运输请求群组的接人位置的接人时间进行聚合，以确定驾驶员和运输请求配对的每个可能组合的聚合接人时间。例如，聚合接人时间可基于群组的每个运输请求与每个可用或候选驾驶员之间的驾驶员和接人位置配对的每种组合，从而将预计接人路线和/或接人时间用于由(例如)地图服务191和/或路线确定186与接人时间确定188的组合提供的每个接人/驾驶员配对。群组接人时间计算器192的输出可表示为群组标识符(“GI198A”)和群组的聚合接人时间(“APT 198B”)。
从群组标识符198A和聚合接人时间198B，群组选择194根据优化目标(例如，整体减少接人时间)对可用或候选驾驶员与运输请求进行配对。群组选择194的输出可包括多个驾驶员和运输请求配对(例如，第一驾驶员与第一用户，第二驾驶员与第二用户等)。在一个实施方案中，群组选择194选择具有最小总聚合接人时间的特定群组。例如，此类选择可基于最小化群组中的每个运输请求的平均接人时间。在变型中，群组选择194可选择表示运输请求群组之中的最小中值接人时间的特定群组。许多此类变型是可能的。例如，根据异常运输请求无论如何都将等待相对较长时间的基本原理，群组选择194可利用规则从优化目标中排除异常运输请求。更进一步，另一变型可利用混合方法，其中群组选择194针对一些运输请求实施单一优化，并且对剩余的运输请求实施群组优化。更进一步，群组选择194可在给定的持续时间内针对运输请求的子集实施优化，并且将其他运输请求翻转到另一群组，以便随后确定。通过这种方式，用于确定特定优化目标的标准和条件可取决于设计选择、业务考虑或其他因素而变化。
进一步参考图1C的实例，可实施优化逻辑128以便在驾驶员被持续指派给运输请求时重复和继续优化过程。在一个实施方案中，甚至在确定群组优化目标时，仍可计算并且基于可用或候选驾驶员的数量的变化来重新计算驾驶员到运输请求的指派。通过继续运行，优化逻辑128的变型可使用具有变化的服务状态(诸如，在途中(或初步指派)或者在使用中(完成旅程))的驾驶员来扩展或缩短各自的驾驶员池。
另外，与图1B的实例一样，优化逻辑128可调节或以其他方式选择可影响驾驶员配对的结果的输入参数。例如，诸如池持续时间195(例如，其中针对运输请求的特定集合考虑可用或候选驾驶员的持续时间)和地理范围196的参数可影响驾驶员池和运输请求或接人池两者的构成要素。优化逻辑128可将地理范围196和池持续时间195的现有值用作输入，并且在相同持续时间内运行假设群组聚合接人时间的样本，以便获得(例如)统计或学习模型(例如，一天中的时间、需求或供应量等)，从而确定池持续时间195和/或群组大小。
通过群组配对，结果也可受到参数的影响，所述参数针对运输请求197(例如，特定群组中的运输请求的绝对最大值，可用或候选驾驶员与接人请求之比等)以及可用驾驶员199(例如，给定群组或比例的最多驾驶员、服务状态和阈值(例如，开放之前在目的地的x分钟或y英里内的使用中驾驶员))来设置群组大小。例如，这些参数可用来在给定例子或持续时间针对优化和池化来过滤或选择运输请求以及候选或可用驾驶员。
运输请求优化
图2说明根据实例的用于为用户安排按需服务的示例方法。例如，使用结合图1A的实例描述的部件，可实施诸如由图2的实例描述的方法。因此，参考图1A的元件以便说明用于执行所描述的步骤或子步骤的适当元件或部件。
参考图2，系统100可从第一用户的客户端装置170接收运输请求171(210)。在一个实例中，运输请求171可包括用户ID 121、接人位置123、车辆类型125以及目的地位置127。调度110可接收运输请求171(或者有关运输请求171的信息)，并且基于第一用户的接人位置123来确定能够为第一用户提供运输的驾驶员池或多个驾驶员(220)。
例如，调度110的接人确定部件114可确定具有按需服务系统100的授权和注册驾驶员中有哪些驾驶员满足使得驾驶员有资格能够为第一用户提供运输的条件。接人确定部件114可访问驾驶员数据库116，以确定可用于(例如，驾驶未被占用的车辆)提供运输并且具有在接人位置123的预定义距离内和/或在接人位置123的预定义区域内的当前位置113的驾驶员的第一集合(222)。
例如，第一用户可具有在加利福尼亚州旧金山的接人位置123。接人确定部件114可确定正在驾驶未被占用的车辆的哪些可用驾驶员是在接人位置123的五英里内或者在旧金山的城市范围内(或者在接人位置123的特定邻近地区内)。预定义距离或区域可由系统100的管理员指定。
接人确定部件114也可访问驾驶员数据库116，以确定当前正在提供运输(例如，使用中的驾驶员)并且也满足与第一用户的接人位置123相关的一个或多个条件的驾驶员的第二(和/或第三)集合(224)。例如，接人确定部件114可识别下列驾驶员的第二集合：(i)在使用中、(ii)具有在接人位置123的预定义距离内和/或在接人位置123的预定义区域内的各自当前位置以及(iii)正在向其他用户提供去往各自目的地位置的运输服务，所述各自目的地位置是在第一用户的接人位置123的阈值距离或阈值预计行程时间内。在另一实施例中，接人确定部件114也可识别下列驾驶员的第三集合：(i)在使用中、(ii)具有在接人位置123的第一阈值距离和/或第一阈值预计行程时间内的各自当前位置以及(iii)具有在第一用户的目的地位置127的第二阈值距离和/或第二预计行程时间内的各自目的地位置。
基于第一用户的接人位置127、在忙碌着的驾驶员的当前位置、使用中驾驶员的当前位置、使用中驾驶员的目的地位置、第一用户的目的地位置以及其他因素(诸如，交通状况、预测或最可能的路线、驾驶员和/或用户的历史信息、一天中的时间、事件日历等)，接人确定部件114可确定距离度量和预计行程时间度量。
一旦确定了能够为第一用户提供运输的多个驾驶员，调度110便可从所述多个驾驶员中为第一用户选择驾驶员(230)。根据一些实施例，驾驶员选择118可将多个驾驶员排列优先顺序或排名和/或基于一个或多个参数或规则从多个驾驶员中选择驾驶员。取决于实施方案，驾驶员选择118可基于下列一个或多个或者下列一个或多个的组合来将驾驶员排列优先顺序：(i)在忙碌着的驾驶员从她的当前位置到第一用户的接人位置123的距离、(ii)在忙碌着的驾驶员从她的当前位置到接人位置123的预计行程时间、(iii)使用中驾驶员从她的当前位置到接人位置123的总距离、(iv)使用中驾驶员从她的当前位置到接人位置123的总预计行程时间、(v)驾驶员的反馈信息、(vi)请求用户的反馈信息、(vii)有能力的驾驶员中的任一个先前是否为该请求用户提供过运输服务、(viii)驾驶员偏好、(ix)用户偏好、(x)有关驾驶员的个人信息、(xi)有关用户的个人信息、(xii)驾驶员的车辆的车龄以及其他因素。
响应于选择驾驶员，调度110可将邀请传输到所选择的驾驶员，以使得驾驶员能够接受或拒绝为第一用户提供服务(240)。所述邀请可包括有关第一用户的信息(例如，姓名、用户名、照片、用户的等级信息)和第一用户的接人位置(例如，地图上的GPS坐标、地址、街道十字路口等)。当所选择的驾驶员操作他或她的驾驶员装置时，邀请可使得驾驶员能够选择两个可选特征中的一个，诸如，“接受”或“拒绝”。在另一实例中，所选择的驾驶员的应用程序可自动接受邀请(因为驾驶员先前通过指定乘车共享车辆类型同意提供乘车共享服务)。调度系统随后可确定驾驶员是否接受邀请或者自动确定驾驶员已接受邀请(250)。如果驾驶员驳回或拒绝邀请，那么拒绝消息通过一个或多个网络提供到调度系统，并且调度系统可为第一用户(从多个有能力的驾驶员中)选择另一驾驶员。每次驾驶员拒绝邀请时，调度系统都可继续为用户选择随后的驾驶员，直到没有能够提供运输的驾驶员或者达到时间阈值为止(例如，从做出请求的时间算起、从系统100接收到请求的时间算起或者从选择第一驾驶员的时间算起，没有驾驶员在三分钟内接受邀请)。如果驾驶员接受邀请，那么已为第一用户安排运输，并且有关运输的事务的信息存储在系统100的数据库中(260)。另外，第一用户可从调度系统接收已经为该用户选择了驾驶员的通知或状态消息。
图3A和图3B说明根据实例的用于确定能够提供按需服务的提供者的示例方法。例如，使用结合图1A的实例描述的部件，可实施诸如由图3A和图3B的实例描述的方法。因此，参考图1A的元件以便说明用于执行所描述的步骤或子步骤的适当元件或部件。
图3A说明根据实施例的用于确定能够为请求用户提供运输的多个使用中驾驶员的示例方法。在一个实例中，图3A的方法(例如，步骤320到355)可对应于图2的步骤224。在调度110从第一用户装置接收运输请求(310)之后，接人确定部件114可识别正向其他用户提供运输并且具有在第一用户(例如，请求用户)的接人位置的预定义区域、距离和/或预计行程时间内的当前位置的使用中驾驶员(320)。在一个实例中，接人确定部件114可访问驾驶员数据库116，以确定有关授权或注册驾驶员的实时信息。
针对每个识别的使用中驾驶员，接人确定部件114可确定对应的各自目的地位置(例如，使用中驾驶员正为之提供运输的当前用户的目的地)。针对每个识别的使用中驾驶员，接人确定部件114可执行计算或确定从各自目的地到第一用户的接人位置的第一预计行程时间(330)。在一个实例中，至少部分地基于从各自目的地到接人位置的预计行程路线的行程距离、当前交通状况、驾驶员和/或正被提供运输的当前用户采用的历史路线、一天中的时间、天气状况等，接人确定部件114可确定预计行程时间。
接人确定部件114可为每个识别的使用中驾驶员确定第一预计行程时间是否在阈值时间内(340)。如果特定使用中驾驶员的第一预计行程时间在阈值时间内，那么接人确定部件114将所述驾驶员包括作为能够为第一用户提供运输的驾驶员(350)。另一方面，如果特定使用中驾驶员的第一预计行程时间超出阈值时间，那么接人确定部件114不将所述驾驶员包括作为能够为第一用户提供运输的驾驶员(365)。
作为补充或替代例，接人确定部件114可为每个识别的使用中驾驶员确定从各自目的地到第一用户的接人位置的距离，并且确定所述距离是否在阈值距离内。如果驾驶员的所述距离在阈值距离内，那么接人确定部件114可将所述驾驶员包括作为能够为第一用户提供运输的驾驶员。另一方面，如果驾驶员的所述距离超出阈值距离，那么接人确定部件114不将所述驾驶员包括作为能够为第一用户提供运输的驾驶员。
图3B说明在至少一些实例中的用于确定能够为请求用户提供运输的多个使用中驾驶员的另一示例方法。在一个实例中，图3B的方法(例如，步骤370到395)可由调度110结合图3A的方法执行和/或也可对应于图2的步骤224。图3B的方法对应于两个或多个用户之间的乘车共享，例如，请求运输服务的第一用户和已经由对应驾驶员提供运输的第二用户。
在图3B的实例中，假设第一用户和第二用户每个向系统100表明他或她愿意与另一用户共享乘车或运输。例如，第一用户和第二用户中的每个可能已经通过指定乘车共享车辆类型(当做出请求时)来请求运输。在另一实例中，第一用户和第二用户中的每个可操作他或她的客户端装置170，以作为用户的简介的一部分或更新用户的简介来指定他或她是否愿意共享运输，并且调度110可访问客户端数据库150，以确定第一用户是否愿意共享乘车。在一个实例中，如果第一用户不愿意共享运输，那么接人确定部件114不执行图3B的方法。类似地，如果正被提供运输的第二用户不愿意共享乘车，那么接人确定部件114不将对应驾驶员包括作为可在同时向第二用户提供运输的同时接送第一用户的驾驶员。
在调度110从第一用户的装置接收运输请求(360)之后，接人确定部件114可识别正向其他用户提供运输并且具有在第一用户(例如，请求用户)的接人位置的预定义区域、距离和/或预计行程时间内的当前位置的使用中驾驶员(370)。接人确定部件114可访问驾驶员数据库116，以确定有关授权或注册驾驶员的实时信息。针对每个识别的使用中驾驶员，接人确定部件114可确定(i)从该驾驶员的当前位置到第一用户的接人位置的第一预计行程时间以及(ii)从各自目的地位置(例如，使用中驾驶员正为之提供运输的当前用户的目的地)到第一用户的目的地位置的第二预计行程时间(380)。在一些实例中，至少部分地基于从各自目的地到接人位置的预计行程路线的行程距离、当前交通状况、驾驶员和/或正被提供运输的当前用户采用的历史路线、一天中的时间、天气状况等，接人确定部件114可确定第一和第二预计行程时间。
接人确定部件114可为每个识别的使用中驾驶员确定第一预计行程时间是否在第一阈值时间内以及第二预计行程时间是否在第二阈值时间内(390)。如果特定使用中驾驶员的第一预计行程时间在第一阈值时间内并且该驾驶员的第二预计行程时间在第二阈值时间内，那么接人确定部件114将所述驾驶员包括作为能够为第一用户提供运输的驾驶员(3993)。另一方面，如果特定使用中驾驶员的第一预计行程时间超出第一阈值时间和/或该驾驶员的第二预计行程时间超出第二阈值时间，那么接人确定部件114不将所述驾驶员包括作为能够为第一用户提供运输的驾驶员(395)。
作为补充或替代例，接人确定部件114可为每个识别的使用中驾驶员确定从该驾驶员的当前位置到第一用户的接人位置的第一距离以及从各自目的地位置到第一用户的目的地位置的第二距离。接人确定部件114可确定第一距离是否在第一阈值距离内以及第二距离是否在第二阈值距离内。如果第一距离在第一阈值距离内并且第二距离在第二阈值距离内，那么接人确定部件114可将该驾驶员包括作为能够为第一用户提供运输的驾驶员。另一方面，如果第一距离超出第一阈值距离和/或第二距离超出第二阈值距离，那么接人确定部件114不将该驾驶员包括作为能够为第一用户提供运输的驾驶员。
图4说明根据一个或多个实例的用于针对运输请求来优选对驾驶员(或车辆)的选择的方法。例如，使用诸如结合图1A的实例描述的系统和诸如结合图1B或图1C描述的子系统，可实施诸如结合图4的实例描述的方法。因此，可参考图1A的元件，以便说明用于执行所描述的步骤或子步骤的适当部件或元件。
参考图4的实例，可在给定的地理区域内确定配对池(410)，从而反映给定地理区域在给定时刻的需求(运输请求412)和供给(驾驶员池414)。
在给定持续时间，取决于实施方案变型，运输请求池可包括预先接人请求(415)、开放接人请求(416)和/或初步履行接人请求(417)中的一个或多个。预先接人请求可从客户端装置170中生成，所述客户端装置以表明将要做出运输请求的概率或可能性较高的方式操作。通过实例，客户端装置170可包括(当实施作为网络服务时)用于与系统100通信的服务应用程序，所述服务应用程序可生成表示用户意图请求运输的背景通信。因此，例如，预先接人请求可对应于通过系统100的客户端装置接口120检测到的活动，包括在客户端装置中的一个中启动服务应用程序，以及其他活动(诸如，来自服务应用程序的位置信息的通信)，所述活动表明用户正走向已知是用户或其他个体从中做出运输请求的位置的角落或位置。在一个实施方案中，针对在给定持续时间(例如，一分钟)中从特定地理区域(例如，城市的平方英里)传达的一个或多个运输请求，确定驾驶员池。
开放运输请求是指未得到履行的所传达的运输请求(416)。运输请求可通过在其上执行服务应用程序的客户端装置的操作生成。例如，通过选择图标输入，用户可生成运输请求，从而导致(i)按编程方式确定用户位置(例如，当前位置或用户提供的地图输入或地址)以及(ii)将指定或嵌入客户端装置170的确定或指定位置的运输请求传达到系统100。
更进一步，运输请求的池也可包括最近得到履行但指示为初步的那些运输请求(417)。如其他实例所述，例如，当有可能可以在将来的短时间内向特定运输请求提供更好配对时，可由系统100作出此类指示。
在供给侧，驾驶员池可包括可用驾驶员和候选驾驶员。可用驾驶员包括具有开放服务状态的那些驾驶员，这意指驾驶员操作对应车辆，所述车辆在被考虑的时刻位于所考虑的地理区域内。然而，驾驶员不在使用中，并且他们没有被指派给特定运输请求(425)。
在一些变型中，驾驶员池可包括在使用中并且也在所考虑的地理区域或接人位置的阈值距离内的候选车辆(426)。由于针对他们各自的当前旅客的可能下车位置，此类驾驶员可以是驾驶员池的候选人。例如，在一个实施方案中，候选驾驶员可包括下列那些驾驶员：(i)具有使用中的服务状态、(ii)具有在所考虑的地理区域内的可能或已知下车位置和/或(iii)当前在他们各自下车点的指定或阈值范围内。
在一些变型中，驾驶员池可包括已被指派给运输请求但恰好在做出确定之前的短时间段内的那些车辆(427)。例如，此类候选驾驶员可包括就在前60秒内指派给运输请求的那些驾驶员。为了让此类驾驶员被视作候选人可能需要满足的其他条件包括：(i)特定驾驶员尚未到达他或她的指派接人位置；和/或(ii)驾驶员的重新指派将不会违反任何业务逻辑规则，否则，所述规则会在特定时刻阻止重新指派该驾驶员(例如，如果驾驶员最近被重新指派，并且规则在给定持续时间内阻止再一次重新指派一个驾驶员)。
一旦针对给定的持续时间和地理区域确定了运输请求和驾驶员的各自池，便可在运输请求与驾驶员之间进行候选配对(430)。在一个实施方案中，需求池中的每个运输请求都假设与供给池中的每个驾驶员配对，以便确定每个假设配对的接人时间。因此，例如，如果需求包括三个运输请求并且可用的供给包括三个驾驶员，那么可能有九个假设配对，并且针对每个配对来确定接人时间。从假设配对的接人时间确定中，可根据优化目标来确定最佳接人时间(432)。在一个实例中，优化目标是找到单个运输请求与多个驾驶员池之间的最佳配对(434)。因此，如果同时存在多个运输请求，那么每个运输请求可被个别地处理，并且例如，选择以先到先服务为基础来处理。给定运输请求的最佳配对可对应于具有该运输请求的最小接人时间的驾驶员。
在变型中，优化目标可对应于最小化多个运输请求的群组的平均或聚合接人时间(436)。因此，如果同时存在多个运输请求，那么优化确定可将驾驶员与运输请求配对，以使得在特定时刻或持续时间给定驾驶员池的情况下每个运输请求的平均接人时间被最小化。
基于最佳接人时间确定，可做出驾驶员接人选择(440)。例如，当优化目标是优化个别运输请求的接人时间时，那么可针对在时间上最靠近到达接人位置来为特定运输请求选择驾驶员。当优化目标是优化多个运输请求的接人时间时，那么基于最小化运输请求的特定群组中的所有运输请求的聚合接人时间来对驾驶员和运输配对进行优化，例如，以便将运输请求的群组的平均接人时间最小化。在变型中，基于其他参数(诸如，最小化群组中的运输请求的中值接人时间，或者在考虑优化目标时排除异常接人时间)，可将特定群组中的所有运输请求的聚合接人时间最小化。可利用在单个或群组运输请求模型上执行优化的方式的许多变型，从而导致明智且深思熟虑的驾驶员和有运输请求配对，从而(例如)与随机配对或其他选择过程(例如，将每个运输请求投入到驾驶员群组中以获得第一应答者的“贪婪”过程等)相比减少接人时间。
驾驶员到运输请求的指派可包括新驾驶员指派(442)和驾驶员重新指派(444)。在一些变型中，新驾驶员指派包括初步指派(445)和承诺指派(446)。初步指派反映允许调度110将运输请求从一个驾驶员指派到另一驾驶员的系统设置。另一方面，承诺指派是最终选择。在一个实施方案中，调度110可只确定承诺指派。在变型中，调度110可在一些情况下确定初步指派，并且在满足某一条件之后(例如，自从初步指派驾驶员的时间推移、驾驶员与接人位置的接近度和/或驾驶员到达接人位置)，初步指派可变成承诺或最终指派。
驾驶员重新指派可包括改变特定运输请求的驾驶员的那些重新指派(447)(见图5A)以及交换驾驶员(或运输请求)的那些重新指派(448)(见图5B)。例如，当(i)将可更快到达特定接人位置的另一驾驶员添加到驾驶员池、(ii)将提供更佳结果以便当前指派的驾驶员去处理的另一运输请求添加到库存池和/或(iii)无论(i)或(ii)时，当重新指派导致更好的群组优化时，可基于优化确定从特定接人位置重新指派驾驶员。
在发生条件或事件时，可触发诸如结合图4的实例描述的优化过程以便实施(450)。所述条件可包括时间推移(452)。例如，可在离散时间间隔(例如，每分钟)并且针对具体地理区域(例如，英里直径)做出库存(运输请求)和供给(驾驶员)的确定。可替代地，可在持续的基础上确定驾驶员或运输池(例如，连续或定期重复图4中描述的步骤)(460)。更进一步，用于接人时间的优化功能的实施可通过运输请求的库存来渐进地实施，并且随着时间的推移，输入并作为池的一部分提供新运输请求。在变型中，可通过事件的发生来触发优化过程，诸如，在给定时间段，开放库存达到给定大小(454)。
更进一步，可基于事件或条件的发生来选择使用中的特定优化目标。例如，在一个实施方案中，当驾驶员供给容易满足运输请求的需求时，可使用单个运输请求目标。此外，当驾驶员供给没有满足运输请求的需求时，优化目标可切换到群组目标。
图5A说明根据实例的用于基于优化考虑的驾驶员指派和随后变化的示例顺序图。在图5A的实例中，可由例如图1A的系统100实施服务520，以便将运输提供到从中做出运输请求511的客户端装置510。运输请求511可从客户端装置510中生成，以便传达接人位置513。运输请求511和接人位置513可由服务520接收。服务520还可接收来自在接人位置的指定地理区域内的一个或多个驾驶员(操作驾驶员装置530)的位置信息531。传达位置信息的驾驶员可具有多个可用服务状态533中的任一个，包括使用中状态、开放状态和/或初步指派状态。取决于实施方案，基于无论个别地考虑还是作为运输请求群组的一部分考虑运输请求511的优化目标，都可由服务520优化运输请求511。在前一种情况下，服务520实施优化过程522，以在T＝1处根据优化目标确定驾驶员532。
可在给定时间或持续时间做出从驾驶员池530中的驾驶员532的选择521。如图5A的实例所示，驾驶员532的选择至少在给定持续时间内可以是初步的，这意指针对客户端510的驾驶员的选择可以改变。所述改变可由做出选择521之后的替代优化结果触发。在做出初始选择521之后，服务520可用信号向客户端装置510通知确认525。然而，在驾驶员532的选择是初步的时间段期间，来自网络服务520的确认通信525可以是不确切的。例如，可不显示有关所选择的驾驶员532的信息。
另外，当在T＝1处做出选择521时，驾驶员532可操作车辆，以朝向客户端装置510的接人位置行进。然而，即使驾驶员532已开始朝向接人位置行进，图5A的实施方案仍假设：在初始选择驾驶员532之后的持续时间内，指派给运输请求511的驾驶员是可以重新指派的。
更详细地说，第二驾驶员534(操作对应的驾驶员装置)可到达或以其他方式在运输请求的地理区域内被识别(例如，驾驶员534打开驾驶员装置180)。第二驾驶员534可传达位置信息535和服务状态537，以便被检测和评估是否包括在驾驶员群组中。例如，当第二驾驶员首先被检测到在所述地理区域内或者在接人位置的某一阈值距离内时，可将第二驾驶员534添加到驾驶员池530。在一个实施方案中，如果(i)第二驾驶员534可到达接人位置和/或(ii)第一驾驶员532的指派时间在对应的阈值时间段(例如，少于一分钟)内，那么第二驾驶员可接收运输请求511的重新指派。在变型中，如果满足优化目标，那么第二驾驶员可接收运输请求511的重新指派。例如，如果使用单个运输请求目标，那么可确定第二驾驶员534与第一驾驶员532之间的接人时间的比较。另一方面，如果在使用中的是群组运输请求目标，那么重新指派将需要也满足群组目标(例如，导致整个群组的平均接人时间减少)。在提供的实例中，在确定第二驾驶员534提供更佳接人时间的过程中，相比于接人位置，更新的优化过程524比较第一驾驶员532和第二驾驶员534的位置。在T＝2处，服务520将选择523传达到第二驾驶员534的装置180，并且进一步将第二驾驶员534的标识符527传达到客户端装置510。在一个实施方案中，一旦驾驶员的标识符被传达到接人位置装置，那么第二驾驶员的选择便成为承诺。另外，一旦选择第二驾驶员，第一驾驶员532便接收到取消订单529。
图5B说明根据另一实例的基于优化考虑的旅程(或驾驶员)交换的另一示例顺序图。在图5B的实例中，可由例如图1A的系统100实施服务560，以便将运输提供到从中做出运输请求551的客户端装置(或运输请求)池550。运输请求551可从客户端装置552中生成，以便传达第一运输请求551和接人位置553。运输请求551和接人位置553可由服务560接收。额外的运输请求可由网络服务560从其他客户端装置接收，包括来自第二客户端装置554的第二运输请求555和接人位置557。
与图5A的实例一样，服务560可接收来自一个或多个驾驶员(操作驾驶员装置，示为驾驶员池570)的位置信息571。可选择在接人位置的指定地理区域内的所识别的驾驶员572、574。传达位置信息571的驾驶员可具有多个可能状态573中的任一个，包括使用中状态、开放状态和/或初步指派状态。
在图5B的实例中，多个运输请求551、555最初由客户端装置552、554生成，以形成客户端装置(或需求)池550。每个运输请求551、555可与对应的接人位置553、557相关联。在T＝1处，服务560实施优化过程562，以便为第一客户端装置552从驾驶员池570中选择581驾驶员572。同样，第二驾驶员574可传达位置信息571，所述位置信息用来为第二客户端装置554选择第二驾驶员。优化过程562可选择581、583下列中的每个：(i)为第一客户端装置552从驾驶员池570中选择第一驾驶员572；以及(ii)为第二客户端装置554从驾驶员池570中选择第二驾驶员574。选择可从优化过程562中生成，所述优化过程提供考虑，诸如，用于第一客户端装置552的第一驾驶员的接人时间。通过每个选择581、583，用信号通知对应的客户端装置552、554省略了驾驶员标识的确认567、569。
通过监控第一驾驶员572和第二驾驶员574的位置571、573以及各自第一装置552和第二装置554的接人位置553、557，网络服务可检测将导致它重新考虑初始驾驶员选择的优化确定的事件或变化。例如，一个客户端装置的接人位置可改变，或者一个驾驶员可遇到交通问题。更进一步，运输请求的需求池可通过请求运输的新用户进行扩展。这些事件可需要在驾驶员和车辆的有限供给之中重新评估最佳配对。在这些和其他情况下，服务560可执行更新的优化过程564，以便为客户端装置和他们各自的运输请求551、555中的每个来持续或重复地计算最佳驾驶员选择。在一个实例中，在确定更佳的解决方案(例如，就群组接人时间而言)是交换第一驾驶员572和第二驾驶员574的指派之后，服务560执行旅程交换。在已做出初始驾驶员指派之后，可在T＝2处执行旅程交换。为了交换指派，将重新选择583传达到第一驾驶员572，以提供来自第二运输请求555的接人位置557和其他信息。另外，将重新选择587传达到第二装置574，以提供第一运输请求551的接人位置553和其他信息。另外，将第二驾驶员的驾驶员标识561传达到第一客户端装置552，并且将第一驾驶员的驾驶员标识563传达到第二客户端装置554。
群组优化的实例
图6A到图6C说明根据一个或多个实例的用于实施驾驶员选择算法的实例，其中进行驾驶员/乘车人配对以实现最小化接人时间的优化目标。尽管图6A至图6C的实例说明相对较少数量的乘车人和驾驶员，但提供的实例旨在说明所描述的概念的应用，并且因此，结合图6A只图6C描述的实例可在应用中扩大到更大的乘车人和驾驶员池。
在图6A中，需求池(做出运输请求610的客户端装置)包括第一装置612和第二装置614。供给池或驾驶员池620(可用的驾驶员)可包括第一驾驶员622和第二驾驶员624。为了根据群组目标功能进行驾驶员/乘车人配对，确定每个驾驶员与接人位置之间的接人时间(描述为预计到达时间，或ETA)。
在所提供的实例中，可能有四个假设配对，并且系统100为下列每个确定接人时间：(i)第一装置612和第一驾驶员622(5分钟的接人时间)、(ii)第二装置614和第二驾驶员624(8分钟的接人时间)、(iii)第一装置612和第二驾驶员624(6分钟的接人时间)以及(iv)第二装置614和第一驾驶员622(2分钟的接人时间)。为了个别地优化每个驾驶员的接人时间，那么首先优化一个驾驶员(例如，在时间上首先请求运输)。例如，如果首先优化第一装置612，那么第一装置612与第一驾驶员622配对，从而让第二乘车人614与第二驾驶员624配对。这将导致平均6.5分钟的群组接人时间。尽管这个结果对第一驾驶员612比较有利(例如，使用单个运输请求优化目标)，但当考虑到群组(第一驾驶员612和第二驾驶员614)时，该配对不是最佳的。当优化的目标扩大到群组时，最佳配对是将第二乘车人614与第一驾驶员622配对以及将第一乘车人612与第二驾驶员624配对。这可导致平均4分钟的群组接人时间，但第一驾驶员的接人时间增加了一分钟。
关于是使用单个还是群组优化目标的确定可以是设计或实施选择中的一个。在一些变型中，可基于结果的比较来确定使用群组还是单个运输目标。例如，如果一个优化目标(单个优化目标)对一个乘车人而言会产生更好的结果，而对于另一驾驶员而言不会花费大量时间(例如，对于一些或更多其他驾驶员而言，单个和群组优化之间的差异小于阈值)，那么可确定至少对获得较大益处的一个乘车人使用单个优化目标，而其余乘客使用单个或群组优化目标。
在图6B中，示出一个变型，其中驾驶员池620中的一个驾驶员626具有使用中的服务状态，而其他驾驶员622、624具有开放(或未在使用中)的服务状态。使用中驾驶员626可被添加到候选驾驶员池，但对于乘车人612、614中的一个而言，使用中驾驶员的接人时间包括额外时间，所述额外时间包括到现有旅客(正在运输的顾客)下车的时间以及下车时间。使用中驾驶员626的下车时间可被视作附加常量(例如，1分钟，表示现有旅客离开车辆的时间)，并且在途中的驾驶员626的接人时间可计算为下列的总和：(i)到达目的地的时间(例如，图6B中的2分钟)、(ii)附加常量(例如，图6B中的1分钟)以及(iii)从目的地的点到接人点的行程时间(例如，图6B中的3分钟)。在有额外驾驶员的情况下，可执行单个或群组目标优化。例如，在群组目标下，驾驶员626被指派给第二乘车人614，并且第一驾驶员622被指派给第一乘车人612，从而使得两个乘车人的平均接人时间是5分钟。如图6B的实例所示，相对于至少第二乘车人614，使用中驾驶员626表示比第二驾驶员624更好的替代者，并且使用中驾驶员626的替代减少了两个乘车人612、614的接人时间的聚合测量。
在图6C中，驾驶员池620包括添加的途中(或初步指派的)驾驶员628。基于他的当前位置，可以将途中驾驶员考虑是在驾驶员池中。具体而言，例如，如果满足群组优化目标，那么可将途中驾驶员628重新指派给第二乘车人614。然而，途中驾驶员628的初始乘车人616已失去了他的驾驶员，并且必须等待新的驾驶员，从而导致更长的等待。在这方面，乘车人616的重新指派增加了表示将新驾驶员指派给第三乘车人616所花的时间的成本(c)。在图6C的实例中，在分钟或时间方面测量成本(c)。尽管对于聚合而言，将驾驶员628重新指派给乘车人612、614中的一个可节省时间，但它增加了至少初始乘车人616的时间。如果聚合优化中包括初始第三乘车人616，那么重新指派的时间成本可减少或忽略，因为计算会固有地将第三乘车人的重新指派计算在内。然而，即使在此类情况下，重新指派仍表示增加成本，因为重新指派的驾驶员需要得到通知并且随后改变路线(例如，执行U形转弯，回头)。增量成本可以建模，以考虑事件，诸如，风险(例如，重新指派的驾驶员无法最佳地过渡到新乘车人)和失去商誉(例如，乘车人616错过接人时间)。在一个实施方案中，可用时间单位表示增量成本。
为进一步描述图6C的实例，驾驶员可被重新指派给已经接收到驾驶员指派的乘车人，这意指在发生驾驶员重新指派时可失去一个驾驶员。驾驶员损失也可由用时间表达的成本(c)(例如，驾驶员接收新指派的预期时间)或其他测量来表示。因此，成本(c)可包括重新指派的乘客与驾驶员之间的重新指派无效以及商誉损失。
硬件图解
图7是说明计算机系统的框图，在所述计算机系统上可实施本文中描述的实例。例如，在图1的背景下，系统100可使用诸如图7所述的计算机系统来实施。系统100也可使用如图7所述的多个计算机系统的组合来实施。
在一个实施方案中，计算机系统700包括处理资源710、主存储器720、只读存储器(ROM)730、存储装置740以及通信接口750。计算机系统700包括用于处理信息的至少一个处理器710以及用于存储信息和由处理器710执行的指令的主存储器720(诸如，随机存取存储器(RAM)或其他动态存储装置)。主存储器720也可用于在由处理器710执行的指令的执行期间存储临时变量或其他中间信息。计算机系统700也可包括用于为存储器710存储静态信息和指令的ROM 730或者其他静态存储装置。诸如磁盘或光盘的存储装置740用于存储信息和指令，诸如，实施图1A的调度110和优化逻辑128的指令，以及各种数据库。
通信接口750可使得计算机系统700能够通过使用网络链路(无线或有线)与一个或多个网络780(例如，蜂窝网络)通信。使用网络链路，计算机系统700可与一个或多个计算装置以及一个或多个服务器通信。在一些变型中，计算机系统700可经由网络链路从用户的客户端装置接收运输请求752。运输请求752可包括用户的用户标识符、接人位置、目的地位置以及车辆类型选择。运输请求752可由处理器710处理，以确定能够为用户提供运输服务的多个驾驶员。处理器710可基于用户的接人位置和驾驶员的各自状态、驾驶员的各自当前位置以及驾驶员的各自目的地位置来确定多个驾驶员。当从多个驾驶员中选择一个驾驶员时，处理器710可通过网络780将状态消息754传输到客户端装置(例如，做出运输请求的客户端装置)从而通知用户已经选择了驾驶员(例如，基于优化)，和/或传输到所选择的驾驶员的计算装置从而通知他或她已被选择来为用户提供运输服务。
计算机系统700还可包括显示装置760，诸如，阴极射线管(CRT)、LCD监控器或者电视机，例如，以用于将图形和信息显示给用户。输入机构770(诸如，包括字母键和其他键的键盘)可联接到计算机系统700，以将信息和命令选择传达到处理器710。输入机构770的其他非限制性说明实例包括鼠标、跟踪球、触敏屏或光标方向键，以用于将方向信息和命令选择传达到处理器710并且控制显示器760上的光标移动。
本文中描述的实例涉及将计算机系统700用于实施本文中描述的技术。根据一个实例，响应于处理器710执行主存储器720中含有的一个或多个指令的一个或多个序列，由计算机系统700执行那些技术。此类指令可从另一机器可读介质(诸如，存储装置740)读取到主存储器720中。主存储器720中含有的指令的序列的执行导致处理器710执行本文所述的过程步骤。在替代实施方案中，硬连线电路可代替或与软件指令结合使用，以实施本文所述的实例。因此，所述实例不限于硬件电路和软件的任何具体组合。
图8是说明移动计算装置的框图，在所述移动计算装置上可实施本文中描述的实例。在一个实施例中，计算装置800可对应于移动计算装置，诸如，能够打电话、发消息和进行数据服务的移动装置。计算装置800可对应于客户端装置或驾驶员装置。此类装置的实例包括用于蜂窝电话运营商的智能电话、手机或者平板装置。计算装置800包括处理器810、存储器资源820、显示装置830(例如，诸如触敏显示装置)、一个或多个通信子系统840(包括无线通信子系统)、输入机构850(例如，输入机构可包括触敏显示装置或是其一部分)以及一个或多个位置检测机构(例如，GPS部件或接收器)860。在一个实例中，通信子系统840中的至少一个通过数据通道和语音通道来发送和接收蜂窝数据。
处理器810被配置有软件和/或其他逻辑，以执行结合实施方案所述的一个或多个过程、步骤和其他功能，诸如，由图1至图7以及申请中的其他地方描述。处理器810被配置成通过存储在存储器资源820中的指令和数据来操作服务应用程序，如图1到图7所述。例如，用于操作服务应用程序以便显示用户接口的指令可存储在计算装置800的存储器资源820中。
用户可操作客户端装置(诸如，计算装置800)，以操作服务应用程序以便对运输服务做出请求。位置数据点865(诸如，对应于计算装置800的当前位置的位置数据点)可从GPS部件870中确定。位置数据点865可经由通信子系统840无线传输到系统，以作为针对运输服务的请求的一部分。在另一实例中，用户可将与计算装置的当前位置不同的位置数据点指定为接人位置(例如，通过输入地址，或经由输入机构850在地图上做出选择)，以便作为运输请求的一部分传输。智能调度系统可接收来自计算装置800的请求，并且为用户执行驾驶员选择过程。系统可经由通信子系统840将有关驾驶员选择的状态消息845传输到计算装置800。状态消息845可由处理器810处理，以作为显示器830上的用户接口815的一部分将状态信息提供给用户。
例如，通过执行存储在存储器资源820中的指令和/或应用程序，处理器810可将多种内容提供到显示器830。一个或多个用户接口815可由处理器810提供，诸如，用于服务应用程序的用户接口，其可包括对应于状态消息845的信息。尽管针对移动计算装置说明了图8，但可在其他类型的装置上实施一个或多个实施例，包括全功能计算机(诸如，笔记本电脑和台式机(例如，PC))。
本文中描述的实例预期扩展至本文中描述的单个元件和概念，但与其他概念、观点或系统无关，且本文中描述的实例预期包括本申请中各处所述的元件组合。尽管本文中参考附图详细描述了实例，但应理解，概念不限于这些明确实例。因此，概念的范围旨在由所附权利要求书及其等效物定义。此外，预期无论是单独描述还是作为实例的一部分描述的特定特征可以与其他单独描述的特征或其他实施例的部分相结合，即使其他特征和实例没有提到此特定特征。因此，未对组合作出描述不应排出对此类组合的权利。
Claims (40)
Hide Dependent
translated from
Claims (40)
Hide Dependent
translated from
1.一种用于提供运输服务的方法，所述方法由服务器的一个或多个处理器执行并且包括：
同时处理多个运输请求，所述多个运输请求中的每个指定地理区域内的接人位置；
在所述多个运输请求中的每个都是开放时的给定时间间隔期间，(i)确定能够在阈值持续时间内履行所述运输请求中的一个或多个的所述地理区域内的候选驾驶员池；以及(ii)为所述多个运输请求中的每个选择驾驶员，其中选择所述驾驶员包括实施优化过程，以最小化所述多个运输请求中的至少一个的预计接人时间。
2.根据权利要求1所述的方法，其中实施所述优化过程包括最小化所述多个运输请求中的至少一些的预计接人时间的聚合。
3.根据权利要求1所述的方法，其中实施所述优化过程包括最小化所述多个运输请求中的全部的预计接人时间的聚合。
4.根据权利要求1所述的方法，其中确定所述候选驾驶员池包括：(i)确定用来履行运输请求的驾驶员的第一集合；以及(ii)确定每个履行去往各自目的地位置的运输请求的驾驶员的第二集合，所述各自目的地位置是在与所述多个运输请求中的至少一个的所述接人位置的定义接近度阈值内。
5.根据权利要求1所述的方法，其中确定所述候选驾驶员池包括确定每个被选择用于对应运输请求但有资格重新指派到所述多个运输请求中的至少一个的驾驶员的第三集合，所述第三集合中的每个驾驶员由于关于所述驾驶员被选择用于所述对应运输请求满足的一个或多个条件而有资格进行重新指派。
6.根据权利要求5所述的方法，其中针对所述第三集合中的所述驾驶员中的每个，所述一个或多个条件包括下列至少一个：(i)自从所述驾驶员被选择用于所述对应运输请求以来的持续时间；(ii)到所述对应运输请求的接人位置的距离；或者(iii)相比于所述多个运输请求中的一个或多个的接人位置，到所述对应运输请求的所述接人位置的预计到达时间。
7.根据权利要求1所述的方法，其中为所述多个运输请求中的每个选择所述驾驶员包括为所述多个运输请求中的第一运输请求选择第一驾驶员，随后当所述第一驾驶员在去往所述第一运输请求的接人位置的途中时，将所述第一驾驶员重新指派到所述多个运输请求中的第二运输请求。
8.根据权利要求7所述的方法，其中将所述第一驾驶员重新指派到所述第二运输请求是响应于：确定与所述第一运输请求的所述接人位置相比在让所述第一驾驶员在所述第二运输请求的接人位置提供运输的过程中的时间节约。
9.根据权利要求8所述的方法，其中在所述给定时间间隔期间但在接收到所述第一运输请求并且为所述第一运输请求选择所述第一驾驶员之后，接收所述第二运输请求。
10.根据权利要求1所述的方法，其中为所述多个运输请求中的每个选择所述驾驶员包括选择所述多个运输请求中的第一运输请求以从所述候选驾驶员池中获得第一驾驶员，并且接着随后在所述第一驾驶员到达所述第一运输请求的接人位置之前，选择所述多个运输请求中的所述第一运输请求以从所述候选驾驶员池中获得第二驾驶员。
11.根据权利要求10所述的方法，其进一步包括将所述第一运输请求的接人取消指示发送到所述第一驾驶员。
12.根据权利要求10所述的方法，其中响应于与所述第一驾驶员相比在让所述第二驾驶员到达所述第一运输请求的所述接人位置的过程中的时间节约，执行选择所述第一运输请求以获得所述第二驾驶员。
13.根据权利要求10所述的方法，其中响应于为所述第一运输请求选择所述第一驾驶员，将确认驾驶员被选择用于所述第一运输请求的第一通信发送到所述第一运输请求的计算装置，所述第一通信没有识别所述第一驾驶员。
14.根据权利要求13所述的方法，其中响应于为所述第一运输请求选择所述第二驾驶员，将第二通信发送到所述第一运输请求的所述计算装置，所述第二通信识别所述第二驾驶员。
15.根据权利要求1所述的方法，其中实施所述优化过程包括选择优化目标以及根据所述优化目标来实施所述优化目标。
16.根据权利要求15所述的方法，其中所述优化目标包括针对个别运输请求来最小化接人时间。
17.根据权利要求16所述的方法，其中实施所述优化目标包括：通过以个体为基础最小化所述多个运输请求中的每个的所述接人时间，同时最小化所述多个运输请求中的每个的所述接人时间。
18.根据权利要求16所述的方法，其中所述优化目标包括：基于多个运输请求的群组的平均或中值接人时间，最小化所述运输请求群组的接人时间。
19.一种计算系统，其包括：
存储器，其存储指令集；
一个或多个处理器，其使用存储在存储器中的指令，以便：
同时处理通过网络接收到的多个运输请求，所述多个运输请求中的每个指定地理区域内的接人位置；
在所述多个运输请求中的每个都是开放时的给定时间间隔期间，(i)确定能够在阈值持续时间内履行所述运输请求中的一个或多个的所述地理区域内的候选驾驶员池；以及(ii)通过实施优化过程以最小化所述多个运输请求中的至少一个的预计接人时间，为所述多个运输请求中的每个选择驾驶员。
20.一种非暂时计算机可读介质，其存储指令集，所述指令在被一个或多个处理器执行时使所述一个或多个处理器的计算系统执行操作，所述操作包括：
同时处理多个运输请求，所述多个运输请求中的每个指定地理区域内的接人位置；
在所述多个运输请求中的每个都是开放时的给定时间间隔期间，(i)确定能够在阈值持续时间内履行所述运输请求中的一个或多个的所述地理区域内的候选驾驶员池；以及(ii)为所述多个运输请求中的每个选择驾驶员，其中选择所述驾驶员包括实施优化过程，以最小化所述多个运输请求中的至少一个的预计接人时间。
21.一种用于安排运输服务的方法，所述方法由服务器的一个或多个处理器执行并且包括：
从第一用户的计算装置接收运输请求，所述运输请求包括有关所述第一用户的接人位置的信息；
响应于接收到所述运输请求，通过以下步骤来确定能够为所述第一用户提供运输的多个驾驶员：(i)确定每个正在驾驶未被其他用户占用的车辆的驾驶员的第一集合；以及(ii)确定每个正在向去往各自目的地位置的一个或多个其他用户提供运输服务的驾驶员的第二集合，所述各自目的地位置在所述第一用户的所述接人位置的阈值距离或阈值预计行程时间内；以及
从所述多个驾驶员中选择第一驾驶员以为所述第一用户提供所述运输服务。
22.根据权利要求21所述的方法，其中确定驾驶员的所述第一集合包括确定驾驶员的所述第一集合中的每个驾驶员已更新了表明所述驾驶员可用于提供运输服务的各自状态。
23.根据权利要求21所述的方法，其中驾驶员的所述第二集合中的每个使用对应计算装置将有关所述各自目的地位置的信息通过一个或多个网络传输到所述服务器。
24.根据权利要求21所述的方法，其中确定正在驾驶未被用户占用的车辆的驾驶员的所述第一集合包括识别当前位置在所述第一用户的所述接人位置的预定义距离内的正在驾驶未被用户占用的车辆的驾驶员。
25.根据权利要求24所述的方法，其中确定驾驶员的所述第二集合包括：(i)识别正在向其他用户提供运输服务的驾驶员，所述识别的驾驶员具有在所述第一用户的所述接人位置的所述预定义距离内的当前位置；(ii)针对每个识别的驾驶员，确定从所述各自目的地位置到所述第一用户的所述接人位置的第一预计行程时间；以及(iii)针对每个识别的驾驶员，将所述第一预计行程时间与所述阈值预计行程时间相比较。
26.根据权利要求25所述的方法，其进一步包括：
针对驾驶员的所述第一集合中的每个驾驶员，确定从所述驾驶员的当前位置到所述第一用户的所述接人位置的预计行程时间；以及
针对驾驶员的所述第二集合中的每个驾驶员，确定总预计行程时间，所述总预计行程时间对应于所述第一预计行程时间与从所述驾驶员的所述当前位置到所述各自目的地位置的第二预计行程时间的总和。
27.根据权利要求26所述的方法，其中选择所述第一驾驶员为所述第一用户提供所述运输服务包括从所述多个驾驶员中选择具有最少总预计行程时间的驾驶员。
28.根据权利要求21所述的方法，其进一步包括：
将邀请所述第一驾驶员为所述第一用户提供所述运输服务的消息传输到所述所选择的第一驾驶员的计算装置，所述消息使得所述第一驾驶员能够接受或驳回所述运输服务。
29.一种非暂时计算机可读介质，其存储指令，所述指令在由服务器的一个或多个处理器执行时使所述服务器执行操作，所述操作包括：
从第一用户的计算装置接收运输请求，所述运输请求包括有关所述第一用户的接人位置的信息；
响应于接收到所述运输请求，通过以下步骤来确定能够为所述第一用户提供运输的多个驾驶员：(i)确定每个正在驾驶未被其他用户占用的车辆的驾驶员的第一集合；以及(ii)确定每个正在向去往各自目的地位置的一个或多个其他用户提供运输服务的驾驶员的第二集合，所述各自目的地位置在所述第一用户的所述接人位置的阈值距离或阈值预计行程时间内；以及
从所述多个驾驶员中选择第一驾驶员以为所述第一用户提供所述运输服务。
30.根据权利要求29所述的非暂时计算机可读介质，其中所述指令使所述服务器通过确定驾驶员的所述第一集合中的每个驾驶员已更新了表明所述驾驶员可用于提供运输服务的各自状态来确定正在驾驶未被用户占用的车辆的驾驶员的所述第一集合。
31.根据权利要求29所述的非暂时计算机可读介质，其中驾驶员的所述第二集合中的每个使用对应计算装置将有关所述各自目的地位置的信息通过一个或多个网络传输到所述服务器。
32.根据权利要求29所述的非暂时计算机可读介质，其中所述指令使所述服务器通过识别当前位置在所述第一用户的所述接人位置的预定义距离内的正在驾驶未被用户占用的车辆的驾驶员来确定正在驾驶未被用户占用的车辆的驾驶员的所述第一集合。
33.根据权利要求32所述的非暂时计算机可读介质，其中所述指令使所述服务器通过以下步骤来确定驾驶员的所述第二集合：(i)识别正在向其他用户提供运输服务的驾驶员，所述识别的驾驶员具有在所述第一用户的所述接人位置的所述预定义距离内的当前位置；(ii)针对每个识别的驾驶员，确定从所述各自目的地位置到所述第一用户的所述接人位置的第一预计行程时间；以及(iii)针对每个识别的驾驶员，将所述第一预计行程时间与所述阈值预计行程时间相比较。
34.根据权利要求33所述的非暂时计算机可读介质，其中所述指令使所述服务器执行操作，所述操作进一步包括：
针对驾驶员的所述第一集合中的每个驾驶员，确定从所述驾驶员的当前位置到所述第一用户的所述接人位置的预计行程时间；以及
针对驾驶员的所述第二集合中的每个驾驶员，确定总预计行程时间，所述总预计行程时间对应于所述第一预计行程时间与从所述驾驶员的所述当前位置到所述各自目的地位置的第二预计行程时间的总和。
35.根据权利要求34所述的非暂时计算机可读介质，其中所述指令使所述服务器通过从所述多个驾驶员中选择具有最少总预计行程时间的驾驶员来选择所述第一驾驶员为所述第一用户提供所述运输服务。
36.根据权利要求29所述的非暂时计算机可读介质，其中所述指令使所述服务器执行操作，所述操作进一步包括：
将邀请所述第一驾驶员为所述第一用户提供所述运输服务的消息传输到所述所选择的第一驾驶员的计算装置，所述消息使得所述第一驾驶员能够接受或驳回所述运输服务。
37.一种用于安排运输服务的方法，所述方法由服务器的一个或多个处理器执行并且包括：
从第一用户的计算装置接收运输请求，所述运输请求包括有关所述第一用户的接人位置的信息；
响应于接收到所述运输请求，确定每个正在向去往各自目的地位置的一个或多个其他用户提供运输服务的多个驾驶员，所述各自目的地位置在所述第一用户的所述接人位置的阈值预计行程时间内；以及从所述多个驾驶员中选择第一驾驶员以为所述第一用户提供所述运输服务。
38.根据权利要求37所述的方法，其中确定所述多个驾驶员包括：(i)识别正在向其他用户提供运输服务的驾驶员，所述识别的驾驶员具有在所述第一用户的所述接人位置的所述预定义距离内的当前位置；(ii)针对每个识别的驾驶员，确定从所述各自目的地位置到所述第一用户的所述接人位置的第一预计行程时间；以及(iii)针对每个识别的驾驶员，将所述第一预计行程时间与所述阈值预计行程时间相比较。
39.根据权利要求37所述的方法，其进一步包括：
针对所述多个驾驶员中的每个驾驶员，确定总预计行程时间，所述总预计行程时间对应于所述第一预计行程时间与从所述驾驶员的所述当前位置到所述各自目的地位置的第二预计行程时间的总和；以及
其中选择所述第一驾驶员为所述第一用户提供所述运输服务包括从所述多个驾驶员中选择具有最少总预计行程时间的驾驶员。
40.根据权利要求37所述的方法，其进一步包括：
将邀请所述第一驾驶员为所述第一用户提供所述运输服务的消息传输到所述所选择的第一驾驶员的计算装置，所述消息使得所述第一驾驶员能够接受或驳回所述运输服务。