CN110678884A - 用于交通运输服务的可订制的预先派单调度的系统和方法 - Google Patents

Abstract

一种提供可订制的平台的方法，该可订制平台可基于预计的司机的可用性以及司机与客户的匹配性，促进对交通和配送服务进行预先派单调度。服务提供者和客户之间的匹配可基于首选、次优选或一般这三个优先级以及一个包含首选项、限制项和指示符的调度矩阵进行匹配。客户和服务提供者可根据彼此的反馈创建首选清单、次优选清单和黑名单，以便使客户能够从他们喜爱的服务提供者那里接收服务，反之亦然，该方法可防止将列入黑名单的客户和服务提供者进行匹配。客户和司机还可以至少部分地基于供求关系就所请求的服务进行价格协商。该发明还提供了一种自动安排调度交通服务的方法，在接收服务请求后，可使用微调度系统，基于合作伙伴司机的协调，自动调度服务请求，而不需要现场调派员参与即可完成。

Description

用于交通运输服务的可订制的预先派单调度的系统和方法

本申请要求下述两个美国临时专利申请的权利：2016年9月23日提交的，申请号为62/399,129的美国临时专利申请以及2017年5月12日提交的，申请号为62/505,626的美国临时专利申请。本申请为2016年8月17日提交的，申请号为15/239,783的美国非临时专利申请(下面简称为783申请)的部分接续案。该非临时专利申请要求下述两个美国临时专利申请的权利：2016年4月21日提交的，申请号为62/325,602的美国临时专利申请，以及2016年2月3日提交的，申请号为62/290,778的美国临时专利申请，这两个申请的全部内容通过引用的方式并入本申请。

发明领域

本申请涉及交通运输服务的系统和方法，具体而言，涉及用于交通运输服务的预先派单调度的系统及方法。在该系统中，在指定的服务日期前收到一个或多个服务请求，并基于司机的可用性以及与客户要求的匹配程度来对服务请求作出预先安排或匹配。

背景

用于交通运输服务业的调度和行程安排软件经程序设定为处理与司机和客户有关的各种变量，包括处理从客户和服务提供者处接收的服务请求，并根据这些服务请求与司机进行协调。然而，在编制行程安排表时，该调度软件在搜集信息，及存储信息以备后期处理方面并不完善。错误或冲突会降低处理速度，造成很多问题，最终影响服务。在组织数据库中的信息，进行全面查询以便有效地对服务请求进行调度方面，面临很多挑战，尤其是在系统对司机逐个进行筛选，直到找到初步匹配的司机的情况下，问题尤为突出。找到初步匹配的司机后，还需要有人联系该司机以确定其是否能够提供服务。或者，如果司机收到已经安排好的行程单，如果行程有冲突，需要取消一个或多个行程。

基于常规系统，这些问题对于那些需要提前一天安排行程的调度员而言将是非常困惑且耗时的，同时也增加了计算机系统运行的负担。加之可能的行程取消和预订变更，该过程将更加复杂，特别是当每个行程又分为好几段分行程(例如，将客户从家里送到商店然后再送回家)，同时为几个客户提供服务，或者连续安排多个行程时。更改或取消时需要将服务请求发送回调度“仪表盘”以便重新安排行程，而这种安排通常是人工操作。

司机接到服务请求时，可能认为其能够按时完成，但是由于不可预见的路线改变或预计错误，工作时间可能会超出其期望的交班时间。因此，司机经常会被调派去执行与其日程安排冲突的服务请求，而客户和司机有时不得不在没有提前通知的情况下取消服务请求。调度员并不总是熟悉客户，也可能不了解他们的偏好。有时还会出现以下情况，即调度员将最近的司机调派给客户，但该司机可能对该区域并不熟悉，或者客户并不喜欢该司机。虽然司机就在附近并且可以快速接送客户，但客户可能对服务不满意。此外，有时候即使调派的司机准时到达，但不得不在外面长时间等待尚未准备好出门的客户。调度员无法知道客户何时可以准备好出门以便有效地向司机更新信息。调度交通运输服务是一项复杂的业务，很多领域需要进行系统性改进。传统的调度方法难以适应对服务请求的意外修改。

因此，该领域需要对传统的系统和方法进行改进以解决上述问题，简化过程，提高司机使用率，提高效率，限制使用人工调度，解决客户和司机之间的不满，允许客户和司机进行私人订制服务以便更好地对服务请求进行预先派单调度，并进行技术改进以便执行自动化预先派单调度服务。

发明概述

本发明涉及预先派单调度计算机执行的各种系统和方法。本概述并不旨在指明本申请所述主题的基本特征或限制其范围。本发明涉及对交通运输服务进行预先派单调度的方法和系统，在指定的调度日期之前接收多个服务请求，对其进行预先派单调度，并根据是否有可用的司机，以及司机与客户的匹配程度进行分组，以解决现有调度服务系统的缺陷，本发明的目的可概括为下述几项：

提供可订制预先派单调度服务的方法和系统，其中基于由已知的客户偏好和已知的服务提供者偏好和限制所构成的调度矩阵，将服务提供者和客户进行最佳匹配。

提供一个系统，该系统被配置为可动态更新数据库以显示客户和服务提供者的预设，设置，偏好，限制，反馈或其他信息的变化，以便提供提高服务质量。

使客户能够基于他们的各种偏好在系统中订制其选项，以便从与其最为匹配的服务提供者处获得最佳服务。

基于司机和客户之间的相互反馈创建首选清单，促进客户和服务提供者之间关系的培育和发展，提高服务质量，并使得客户能够选择一个或多个首选/或次优选的服务提供者，其中，首选服务提供者可优先接受其首选清单中的首选客户的服务请求。

使司机能够在他们首选的客户名单上确定客户的优先顺序，以便解决在预先派单调度过程中出现的任何冲突。

使客户或司机能够对他们的偏好或限制类别分别进行优先级排序，以进一步解决在预先派单调度过程中出现的任何冲突。

创建黑名单。在对服务请求进行调度时，被客户列入黑名单的服务提供者将被略过。

为客户和服务提供者提供电子应用平台，他们可至少部分地参照基于供给和需求的默认价格对所请求的服务设定价格或议价。

向客户和/或司机提供各种指示符，便于方便和有效地为服务请求选择最佳匹配。

促进司机和合作司机之间的微调度系统，以大幅减少传统调度系统的工作量。

提供自动化预先派单调度系统，将一批服务请求调派给一个或多个司机。这些司机在系统中预设了一个或多个其愿意提供服务的地理区域。

促进调度员和司机之间的关联性。在调度门户网站以及与被调派执行服务请求的司机所相关联的设备上显示那些对已调派的服务请求做出的更改，并在数据库中动态更新和存储上述更改，而无须进行任何电话沟通。

使客户可以与一位或多位最匹配的司机就服务请求的价格进行协商。

提供全方位调度服务，包括对服务请求进行预先安排，调度服务请求，动态更新及促进服务请求的更改，以及在运输过程中向各方提供实时信息。

本发明的一个示例性实施例提供一种计算机实现方法，用于进行可订制的预先派单调度。该方法包括通过一个或多个计算机设备从客户那里接收服务请求并进行预先派单调度。该客户至少预设了一项客户可选的服务请求偏好，且该服务请求包括至少一个行程，行程须包括下述中的至少一项：上车时间，上车地点，下车时间或下车地点。至少一个客户可选择的预设服务请求偏好，至少包括司机类型，该司机类型包括首选司机，次优选司机或一般司机。

该方法还包括以下内容：通过一个或多个计算机设备接收至少一个司机选择的预设服务请求偏好以及可选的预设地点限制或时间限制；从第一组司机中的多个司机中自动阻止至少一位司机接收该服务请求，如果基于客户预设的服务请求偏好或基于客户的黑名单，该司机无法完成该服务请求的话；生成与第二组司机相关联的至少一个指示符，该第二组司机包含多个与服务请求相关数据匹配的司机；将至少一个指示符发送给客户，其中至少一个指示符与该至少一位客户的预设服务请求偏好相匹配；在至少一个指定日期或时间，确定该至少一位客户的预设服务请求偏好是否与下述中的至少一部分相匹配：所述至少一位司机预设的服务偏好，以及至少一个指示符；将服务请求调派给第二组司机中的至少一位司机；向第二组司机中的至少一位司机发送对服务请求的调度通知；从第二组司机中的至少一位司机处接收其对服务请求的接受指令；并动态更新数据库中的至少一个有关服务数据。

本发明的其他示例性实施例，提供一个计算机执行方法，用于提供可订制自动预先派单交通运输调度。该方法包括以下内容：接收多个服务请求并进行预先派单调度，其中每一个服务请求包括至少一段行程，该段行程须至少包括一个上车时间，上车地点，下车时间或者下车地点；根据一个上车地点或下车地点所在的地理区域对多个服务请求进行筛选；将多个服务请求存储在一个或多个数据库中；从一个或多个数据库中检索下述：(i)与多个服务请求中的每个服务请求相关联的客户信息，该客户信息包括可预先选择设置的服务偏好，首选清单，次优选清单，或者黑名单中的至少一项，(ii)一位或多位司机简档，该司机简档包括司机信息，该司机信息包括地理服务区域以及至少一项可选择的预设服务限制，服务历史，首选清单，黑名单或历史数据，以及(iii)在指定的日期和指定地理区域，从存储的多个服务请求中检索一批服务请求中的至少一个服务请求；与该批服务请求相对应的多个客户简档，客户简档包括客户信息；或与该批待调派的多个司机相对应的多个司机简档，该司机简档包括司机信息；从第一组司机中排除一个或多个司机，这些司机(i)与服务请求不匹配，(ii)在该客户的黑名单上，或(iii)该客户在该司机的黑名单上；根据与服务请求相关的至少一组或多组指示符，客户信息和第二组待调派司机中的一名或多名司机信息，生成调度矩阵。该调度矩阵为上述第二组司机中的每一位司机创建调派优先级顺序。该方法进一步包括以下功能：根据所创建的优先顺序为上述第二组司机中的每一位调派该批服务请求中的一个服务请求；根据所创建的优先顺序，向客户计算机设备发送第二组司机中的部分司机信息；该客户计算机设备接收从该部分司机中选出的最佳匹配司机；并将该服务请求发送给该最佳匹配司机。

本发明的其他实施例提供一种计算机执行方法，为交通运输服务提供可订制的自动微调度，该方法包括：通过一个或多个远程计算机设备，从预设了服务请求偏好的一个或多个客户那里接收服务请求。该服务请求至少包括一段行程；在一个或多个数据库中存储与服务请求相关的信息；至少部分地基于通过一个或多个指示符显示的信息从一组司机中选择一位司机来接收服务请求，并将服务请求调派给所选择的司机；接收该司机对服务请求的接受指令；在微调度系统中识别与所选择的司机相关联的一个或多个合作伙伴司机，所述一个或多个合作伙伴司机通过所述一个或多个远程计算机设备与所选择的司机通信；所选择的司机向所述一个或多个合作伙伴司机中的一位发送重新调派请求，以将其所接受的服务请求重新调派给其合作伙伴司机；向识别的合作伙伴司机发送重新调派通知；接收合作伙伴司机对该重新调派请求的接受指令；自动向客户该合作伙伴司机发送通知，并向客户提供接受或拒绝该合作伙伴司机的选项；以及基于合作伙伴司机对于重新调派请求的接受指令，动态更新一个或多个数据库中的服务相关数据。

本申请的其他示例性实施例提供一种动态和自动更新服务相关数据的方法，这些数据在数据库(存储于服务器计算机系统中)和至少一个远程计算机设备之间进行交换。该方法包括：在服务器计算机设备上接收客户的服务请求，该服务请求包括至少一段行程；在服务器计算机设备上的一个或多个数据库中存储与服务请求相关的服务数据；从一组司机中选择一位司机完成服务请求，并自动将服务请求调派给所选司机；通过一个或多个远程司机计算机设备，接收来自所选司机对服务请求的接受指令；识别与服务请求相关的第一个更新的服务相关数据，该服务相关数据是在服务请求完成前由服务器计算机设备识别的；使用该第一个更新的服务相关数据动态更新数据库；自动将该第一个更新的服务相关数据发送给该司机，以通过一个或多个远程司机计算机设备进行显示；识别与服务请求相关的第二个更新的服务相关数据，该第二个更新的服务相关数据在该司机接受服务请求以后由该司机通过一个或多个远程司机计算机设备识别；自动将第二个更新的服务相关数据发送到服务器计算机设备；使用第二个更新的服务相关数据动态更新数据库；并在显示装置上显示该更新的服务相关数据。

本发明的其它目的，功能和特点，相关结构要素的操作方法和功能，各部分的组合以及开发和制造的经济性特点，在结合下述详细说明和附图考虑时会更加易于理解。这些都是本申请说明书的一部分。

附图简要说明

通过参考附图说明中阐述的优选实施例，可对本发明有进一步的理解。附图并非旨在限制本发明的范围，而仅仅是为了对本发明进行阐述和示例。本发明说明书后附的权利主张对本发明的范围进行了具体阐述。因此，当结合下述详细描述和附图考虑时，容易全面地理解本发明。本发明附图如下：

图1示例性预先派单调度系统示意图，包括计算机系统和用于本发明的各种实施例的一个或多个计算机外围设备；

图2基于本发明的各种实施例的示例性计算机设备和相关组件的示意图；

图3基于本发明的各种实施例的包含示例性调度矩阵的调度操作示意图；

图4A说明基于本发明的各种实施例的示例性调度逻辑流程图；

图4B结合客户或司机取消行程的操作说明基于本发明的各种实施例的示例性交通运输方法流程图。

图5描述客户与司机之间进行价格协商的示例性流程图，无论是否有调度员门户网站；

图6基于本发明的各种实施例说明用于调度多个预先安排的服务请求方法的示例性流程图；

图7A和7B说明依照本发明的各种实施例的基于第一种算法调派多个预先派单调度的服务请求的示例性方法的流程图；

图8依照本发明的各种实施例说明基于第二种算法调派多个预先派单调度的服务请求的示例性方法流程图；

图9基于本发明的各种实施例说明使用伙伴司机和即时叫车方法对多个服务请求进行预先派单调度和重新调度的示例性方法流程图；

图10说明基于本发明的各种实施例的示例性电子地图界面，用于显示不同地理区域内的未调派的服务请求；

优选实施例详述

本申请所披露的内容并不局限于本说明书选择的特定术语，并且应当理解的是，每个特定元素均包括以类似方式操作的所有对应技术术语。实际应用的具体实施例可通过图示和文字说明加以阐述。对于本发明的各种实施例进行的详尽描述旨在使本领域技术人员得以实施这些实施例。应当了解的是，在不脱离本发明范围的情况下可以对其进行逻辑、技术或其它方面的修改。因此，以下详细描述不应被视为限制性的。在描述附图所示的示例性实施例时，为了清楚起见使用了特定的术语。

本申请提供调度交通运输服务的系统和方法。本领域普通技术人员应理解，可以使用各种编程引擎，编程模块，或使用包括一个或多个程序或一个或多个子程序的其他硬件或软件组件来执行一个或多个示例性实施例。这些程序和子程序等可单独使用，也可组合使用，并通过适当的技术方式执行。

还应理解的是，本申请描述的系统和方法所使用的各种模块可部分地通过在支持互联网的移动设备的操作系统(例如，Android，iOS或Windows Phone OS)上使用移动应用程序(App)，并且部分地通过使用互联网门户网站来实现。并且，不同类型的用户可使用该系统的不同功能。用户或认购人可包括例如一个或多个“司机”或客户。这里的“客户”包括任何人，例如一个或多个实体、个人，或者一个或多个请求或订购服务的实体中的个人。“客户”可指在系统中进行注册的任何人，无论是单个个人还是某个实体中的个人，这些人请求或订购服务-无论是哪种类型的服务，如交通运输服务，配送服务或两者兼有。由于客户和服务提供者都使用这里描述的系统和方法，通常可以称他们为“用户”或“多个用户”，当然也可以基于他们在服务请求中扮演的角色用相应的特定用户类型来对其进行分类。至少有两种类型的用户：服务提供者和客户。

这里的“服务”是指三种类型的服务：乘客的交通运输服务，货物的配送服务，以及交通和配送服务两种服务兼有。可预订服务或者即时请求服务。这里的“即时”进一步定义服务在何时依照请求实时发生。“即时服务”是与“预先派单服务”或在未来某个时间(例如几小时或几天后发生)相反的概念。即时叫车服务是即时发生的，而预先派单调度服务发生在预先确定的未来时间，日期或预定的时间范围内。此外，“私人订制”进一步对服务的性质进行修饰，指的是服务中涉及的客户的偏好或服务提供者的限制。无论服务类型如何，本申请中的“服务提供者”可以是单个个人，例如司机，一群人或私人商业实体的附属机构，例如可以提供交通运输服务，配送服务或者该两种服务的汽车服务公司。服务提供者提供服务的能力取决于其可以支配的工具。例如，在某个地方载客，车辆将是必需的，而配送服务请求则不仅可由车辆提供，也可通过步行或骑自行程的人-提供。

这里的“调度员”可包括管理服务请求并进行各种调度操作和预先派单调度的一方。这里的“服务提供者”可以指经纪人或其他商业实体，政府办公室或代理客户或乘客服务的个人。如本申请所述，上述这些不同角色可使用不同的称呼或统称为“用户”，这些用户在系统中进行了注册或以其他方式直接或间接地与系统相关联。

在本申请中，对任何类型的服务的请求被统称为“服务请求”或“行程”。根据本发明的示例性实施例，基于客户的偏好和司机的偏好和/或限制将服务请求调派给司机，为客户调派司机时，基于某种功能或者以前执行的行程，优先考虑某些司机。这里使用的术语“偏好”是指客户希望包括在服务中的各种因素，包括对司机的偏好，司机所使用的车辆以及任何其他相关的因素。这些偏好代表了服务请求中的理想或有利条件。或者，这些偏好可代表服务的先决条件。客户可以在移动设备上设置他/她的偏好，并在任何时候更新偏好，直到对服务质量感到满意为止。客户可以有一个或多个这样的“偏好”。

根据本发明的示例性实施例，术语“限制”可表示司机希望对其提供的服务施加的任何类型的约束。这些限制可包括两大类：有关司机提供服务的时间，地点，方式和对象的个人限制。这些个人限制可包括司机不愿意在某些地理区域提供服务的地点限制，以及司机在某些时间段内不愿提供服务的时间限制。或者，在某些优选实施例中，司机还可以基于其在某些地理区域提供服务的情况，优先接收在该区域的工作。在这些实施例中，司机可根据是否愿意或是否有能力在其偏好的某些区域内提供服务设定地点限制。在该司机不愿意提供服务的时间或时间区域内，预设时间限制。时间限制可包括一天中的几小时，一周中的几天，一年中的几个时间段等。司机还可为位置和时间设置“限制”。例如，司机可能不希望在晚上10点后在某个区域提供服务，但是愿意在该时间后在另一个区域内提供服务。在该实施例中，司机还可指定时间偏好，该时间偏好表示司机倾向于接收服务请求的时间段。司机可设置一个或多个这样的“限制”和/或“偏好”。术语“偏好”和“限制”的目的不是将客户或司机的限制设为仅有偏好或限制。相反，它们旨在将两者进行对比。

根据本发明的示例性实施例，可用多个术语表示与司机建立了正面关系的客户。“首选客户”是司机“首选客户清单”上的客户。与客户建立了正面关系的司机被称为“首选司机”(例如，在客户的“首选清单”上)。这里使用的术语“首选”指的是在服务请求的调派中优先考虑的任何客户或司机(例如，在“首选清单“上)。本领域技术人员将理解，“首选清单”也可用其他可以定义这类清单的词语来替代，如“朋友”，“最佳”，“最优先”。无论具体使用哪个术语，在清单上置顶优先的目的是表示司机与客户之间建立了正面关系，且表明司机和客户的匹配性。

与“首选”相反，这里使用的司机的“黑名单”或客户的“黑名单”是指在将来可以阻止将特定司机和特定客户进行匹配的清单(比如，在对服务请求进行调度时，将排除这两者的匹配)。该领域的专业技术人员将理解，还可以使用其他术语来描述这一概念，例如，“阻止清单”，“禁止清单”，“不喜欢清单”等。无论用哪种术语，其目的是为司机排除其不愿提供服务的客户，或者其不愿联系的客户，同时也为客户排除其不愿匹配的司机。

另外客户还可选择“次优选”司机。次优选司机不在客户首选清单中，是客户直接请求将其列在“次优选清单”上的司机，或者客户请求将其列于“首选清单”，但其请求未经司机同意。无论何种情况，如果司机拒绝了客户的请求，则该司机将不被添加到客户的首选或次优选清单中，反之亦然。因此，在优选实施例中，当双方都同意时，司机和客户将被置于彼此的首选清单中，且当一方或双方直接请求，或当一方请求首选而另一方未作响应时，他们也将被置于次优选清单中。这里使用的“次优选”一词通常是指在调度预先安排的服务请求时用于匹配客户和司机的，低于“首选”的等级。司机和客户可基于这种分类对彼此进行进一步排名，本申请将进一步对此进行讨论。下车地点可能比较复杂，例如，客户在医院或诊所下车，这些地点通常布局相对混乱，可能较难找到正确的入口。因此，当遇到该类地点时，最好将服务请求调派给熟悉特定路线的司机。本申请的某些实施例统一将首选或次优选司机以外的司机称为“一般”司机。该术语实质上意味着该司机不是次优选司机，也未添加到首选清单中。应当理解的是，与司机(即司机类型)相关的特定状态，无论是“首选”，“次优选”还是“一般”，总是相对而言的。对于一位客户来说是次优选的司机可能是另一位客户的首选司机。

这里的术语“系统”是指通过操作便携式计算机设备的硬件和软件组合来执行的各种实现过程，包括与基本组件组合和集成的各种预编程功能，这些组件包括但不限于一个或多个服务器，数据库，移动终端应用程序，互联网门户，网络设置等。在这些组件的支持下，系统通过用户界面提供服务，例如网站或移动应用程序。此外，该系统可包含多个服务器，服务器可处于分布式结构中，并且得到来自世界各地的数据中心的支持。这些实施过程可以通信连接且可跨平台，这样，就可以向移动设备(例如，智能电话，平板电脑等)或固定设备(例如，台式计算机等)上的用户提供与其服务请求相关的信息。(例如，显示电子地图，用于显示行程时间的，路线，定价信息的指示符，简档/设置信息等)。这里使用的术语“指示符”旨在以简单，快速和方便的形式向客户或服务提供者或两者发送或显示有关服务的信息的一种方式。

本申请描述的系统的各种实施例提供通过计算机系统进行的预先派单调度。这里描述的计算机系统可包括硬件和软件的任何组合，并且可以通过例如广域网，分组交换网络与多个便携式计算机设备通信，允许用户访问与基本组件整合的各种预编程功能。这些功能和组件可包括但不限于通信网络内的一个或多个服务器，数据库，移动终端应用程序，互联网门户，网络设置等。在这些组件的支持下，这里描述的系统通过用户界面提供服务，例如，便携式计算机设备上的网站或移动应用程序。该系统还可包括置于分布式结构中的多个服务器，其中数据中心可位于世界各地。

本申请描述的系统的某些实施例不限于涉及传统计算机程序或运行程序的可编程装置。例如，本发明的实施例可包括光学计算机，量子计算机，模拟计算机等。

本申请的流程图中的各个元素描述了计算机执行方法中的一个步骤或一组步骤，每个步骤可包含一个或多个子步骤。为了更好地进行说明，将这些步骤(以及识别和描述的任何和所有其他步骤)以特定的逻辑顺序进行呈现。然而，应当注意的是，本申请描述的任何示例性实施例也包含适应本申请披露的技术的特定应用方法的其他步骤顺序，且任何变动和修改需限定在本发明的范围内。对任何特定顺序步骤的描述并非旨在排除包含不同顺序步骤的实施例，除非是基于某个特定应用方法的需求，明确说明，或者从上下文能清楚理解。

参考以下附图便于理解此处描述的系统和方法，下面将对这些附图进行详细描述。首先参看图1。图1描述用于本发明的各种示例性实施例的计算机系统100和多个外围计算机设备。硬件和软件的组合在多个计算机设备128和计算机系统100上执行操作，通常通过一个或多个连接到有线或无线广域网124(例如，互联网)，及通过本地网络界面120与本地设备连接。计算机设备128可以是任何能够通过软件将信息发送到其他移动设备或计算机系统的无线移动硬件设备，使用其地理位置的定位能力确定硬件设备的位置(例如，三角测量，全球定位系统，用户的位置定位等)，并通过网络连接到个人计算机网络或互联网的公共网络。

计算机系统100可包括，例如，服务器102，其包括中央处理器(CPU)104，存储器106，数据库108，端口110，通信装置112，显示装置114，一个或多个输入设备116(例如，键盘，鼠标等)，LAN数据传输控制器118，LAN端口120，网络控制器122和内部总线138。如图所示，该系统可以连接到数据存储设备，例如硬盘，通过有线或无线连接配置一个或多个数据库108。中央计算机系统100可包括与图1中所示的服务器102相同或相似的一个或多个服务器。这些服务器以不同方式配置一个或多个服务器，其可以配置不同的硬件或软件。例如，计算机系统100可包括在诸如数据中心或服务器农场等多处托管的多个服务器。

计算机系统100可被配置为通过通信装置112与网络通信，通信装置112可包括用于通过一个或多个网络或一个或多个外围设备发送数据的任何方法。通信装置112可包括，但是不局限于用于提供无线连接，有线连接，蜂窝连接，数据端口连接，蓝牙连接或其任何组合的电路和控制系统，并且该装置可包括能够使用这种通信方法进行通信的设备。本领域普通技术人员将理解，可以使用多种通信方法。

服务器102和计算机系统100可通过通信装置112和广域网124通信地连接到诸如计算机设备128，服务提供者设备126，管理员设备134和调度设备136的外围设备。计算机设备128可被配置为一个或多个客户计算机设备130C1-130Cn或司机计算机设备132D1-132Dn。计算机设备128可以是用户(例如，客户，司机等)与计算机系统100交互的设备(例如，智能手机，智能手表等)。任何数量(例如，1,2,3，...，n)的司机设备132D1...132Dn或客户设备130C1...130Cn均可与计算机系统100结合使用。

计算机系统100可包含处于分布式结构中的多个服务器102，并得到位于世界各地的数据中心的支持。这些方法的实施可通过通信连接或跨平台，这样就可以向移动设备上的用户提供与服务请求相关的信息，例如电子地图显示器显示行程时间、路线和价格信息，司机简档，设置的指示符。这里描述的系统功能可通过允许处理器处理和输出该方法各步骤的计算机设备来实现。根据本发明的示例性实施例，服务器102协调用户界面并与数据库108交互。根据用户的角色和需求，系统可向用户提供不同的功能。

服务器102可通过服务器端口接收客户输入信息，位置信息和服务请求信息，以及来自司机的信息(例如，位置信息，限制信息，历史信息等)。如上所述，服务器102可通过服务器端口向一个或多个计算机设备发送信息，并且可以将信息输出到计算机设备的显示器上。这些信息可包括与区域有关的信息，如果有相关的区域特定性信息的话，尤其是关于服务请求的地图定位及线路信息。

通过服务器端口接收的服务请求信息可由计算机系统100存储在数据库108中，并可包括例如：服务请求的状态；司机接受服务请求的情况；司机取消服务请求的原因；与调派到的服务请求相关的历史记录；调度员的操作日志；通知内容和确认状态也可记录在系统日志中，且该信息可由计算机系统100的管理员检查。可以理解的是，这并不是系统能记录到的服务请求信息的详尽清单。

存储在计算机系统100的一个或多个数据库108中的数据可由本申请所述的所有用户信息持续更新，并根据此中所述的各种方法进行分析，以实现对预先派单服务的有效预订和调度。在某些实施例中，每当计算机系统100从客户，司机，调度员或其他用户那里获得输入/服务请求时，计算机系统100可首先打开数据库/数据库中心的安全访问通道，然后通过访问通道向数据库管理模块发送查询语句。如果使用关系数据库，则数据表之间可以存在一种关系，例如一对多关系，多对多系以及与其他数据表的一对一关系。基于数据表之间的关系，数据库管理模块可以严格遵循查询语句并通过使用表的ID，表名和列名来查找特定数据表。查找时，可以连接两个或更多数据表，也可以不连接。如果使用非关系数据库而不是数据表，并且数据存储在键-值对中，则数据库管理模块可严格遵循查询语句并通过使用查询语句提供的键来查找特定数据。

计算机系统100可访问存储在一个或多个数据库108中的所有信息。数据库108可包含规则和过程数据，司机数据，管理数据，组合数据，客户数据，地图组件数据和任何与计算机系统100的实施相关的其它数据。规则和程序数据可包括系统价格，促销设置规则和程序，以及指示符，推荐，支付，服务请求，系统管理，系统日志，系统分析和优化的规则和程序。地图组件数据可以存储由GPS和LBS识别的服务请求的地图数据。GPS和LBS数据可以以不同方式，例如，通过接收基于位置的资源，确定计算机设备的位置。司机数据可包括司机的简档，例如个人数据，包括司机的照片和驾龄，性别，国籍和语言能力等。

数据库108还可包括与司机车辆相关的数据，例如品牌和型号，颜色，座位容量以及是否可随时提供服务，保险状态，乃至车辆图片等。司机资料中的其他信息可包括首选清单和黑名单等信息，与邮政编码相关的限制，时间，地点和价格，以及服务数据和记录。数据库108还可包括价格和费率的管理数据，诸如联系人和常见问题信息的系统数据，以及关于客户和司机的登记细节。例如，数据库108可以存储与管理计算机系统100的即时叫车服务应用程序有关的计费信息或其他信息。群组数据可包括基本数据，公司数据，个人数据组或与服务提供者有关的数据。客户数据可包括客户资料，包括个人数据，客户首选司机清单，客户的黑名单，客户偏好，服务请求数据和记录。本领域的普通技术人员会了解，数据库108可以动态地进行同步，使得无论何时进行数据块的改变或更新，服务器102和数据库108都可相应地动态更新数据库以反映最新信息。另外，在主数据库108中+数据丢失的情况下，可以使用至少一个备份数据库来备份数据库108中的主要数据库。本领域的普通技术人员将理解，数据库108的成分可以与此处描述的组件不同。

计算机系统100还可使用一组数据库或数据存储媒介来提供和维护预先派单调度的服务应用程序，以便基于客户的偏好和需求来调派相匹配的司机。数据库108可包含若干数据类别或群组。数据库108的各部分可以是独立的或同步的，以便同时从这两个部分检索信息。这些数据可包括规则和过程数据，管理数据，客户数据，司机数据，由基础数据构成的群组数据，公司数据或个人数据的群组，以及其他与用户类型有关的数据。根据本发明的示例性实施例，可以将所有历史信息分类并存储在数据库108中并从数据库108中检索。可以部分地通过对应于每个服务请求的追踪号，服务请求ID或行程ID追踪历史数据，帮助计算机系统100查询服务请求。通过上述标识分类的信息可包括服务请求的类型，服务请求人及执行人，服务请求和执行的地点(邮政编码，区，县，市，州等)，服务请求路线，服务请求成本，付款时间和方式，以及是否有任何一方将对方添加到首选清单或黑名单。关于客户或司机的偏好或限制，定价和其他可订制的所有信息均可存储在数据库108中。

综合数据库108可存储管理数据和其他信息。管理数据可包括作为预先派单调度服务应用程序的任何信息或数据，且包括诸如联系信息和常见问答信息，客户和司机注册详情之类的系统数据，例如，与管理预先派单调度服务申请有关的计账信息或其他相关信息。举例来说，注册细节可包括用户在系统中注册的时间或者他们使用预先派单调度服务的频率。管理数据可包括来自不同服务对象(如公司)的路线价格和费率等信息。其他存储信息可包括服务规则，程序，价格，以及司机和客户设置的程序等。

根据本发明的示例性实施例，还可在数据库108内存储和维护已完成的服务请求的记录。计算机系统100可以在综合数据库中自动存储任何已完成的服务请求的历史数据记录。可以在预订和完成服务时动态更新数据库108。数据库108可以存储已经请求和完成的每个服务请求的索引，包括客户和司机的注册号或用户标识，如果需要，可以在任何时间检索该注册号或用户标识以供参考。

存储在数据库108中的服务请求信息可包括例如服务请求ID，相关的司机信息，相关的客户信息，请求的接送地点，实际的接送地点，请求的下车地点，实际下车地点，接送时间，下车时间，距离，持续时间，状态，价格，保险公司等。即使客户没有智能手机或使用与系统通信的应用程序，也不会对系统的功能产生不利影响。例如，调度员可以根据他/她的服务请求的状态向客户提供更新的信息，如司机的位置。因为上面描述的开始按钮功能使得司机可以在后端立刻与调度员连接。

相关服务信息可包括诸如车辆号码，名字，姓氏，用户名，电子邮件，密码，电话号码，出生日期，性别，国籍，驾驶经验，司机类型(例如，车主-运营商)，所属公司名称，宠物设施，轮椅设施，语言，签名和简介。相关服务信息还可包括许可证信息，例如许可证号，许可证类别，许可证状态，许可证颁发日，许可证到期日，营运车辆许可证号码，营运车辆许可证颁发日期和营运车辆许可证到期日；驾驶记录发放日期和驾驶记录到期日等驾驶记录信息；车辆信息，如注册状态，注册状态，注册开始日期/结束日期，型号年份，品牌，型号，车辆识别号码，车型，车牌号，营运车辆注册开始/结束日期，营运车辆许可证号和营运车辆许可证；保险和检查信息，如责任状况，保险状况，保险提供者，保险开始日期，保险结束日期，车辆检查和车辆检查结束日期。

综合数据库108还可存储每个特定司机的服务请求细节以供将来参考。数据库108可包括关于司机车辆的数据，例如车辆的类型，型号，颜色，座位容量和可访问性，保险状态以及车辆的照片。司机资料中的其他信息可包括其首选清单和黑名单，偏好以及邮政编码，时间或地点等限制以及服务数据和记录等信息。

还可以相应地更新与数据库108有关的备份数据库以反映最新的变化。在某些实施例中，可以以允许有效分类和检索的方式来组织或构建此类信息。信息可以以非关系或非结构化的方式存储。本领域的普通技术人员将理解，根据这里讨论的本发明的示例性实施例，可以使用在数据库108或其他数据存储介质中提供，存储和组织数据的多种方法。另外，可以理解的是，可以使用至少一个备份数据库不断对主数据库进行备份以防主数据库丢失数据。

存储在数据库中的信息可用于在预先派单调度服务系统100中生成各种指示符(下面将进一步讨论)。与这些指示符相关的图标，形状或其他描绘方式可存储在数据库108中。基于对数据库108中数据，以及图标，形状或其他描绘方式的分析处理结果，向客户、司机和调度员显示这些图标，形状或其他描绘方式以及指示符。使用关于客户和存储在数据库108中司机的信息，预先派单调度服务系统100可以向与其在操作上相关联的任何预先派单调度的服务应用程序提供相关信息。司机信息包括例如司机简档信息，车辆的当前位置及行驶状况，或者距离客户的特定距离或者预计到达客户上车地点的时间。

计算机系统100还可使用一组数据库108或数据存储介质来提供和维护预先派单调度的服务应用程序，以便基于客户的偏好和需求来调派相匹配的司机。数据库108可以包含若干数据类别或分组。数据库108的部分可以是独立的或同步的，以便同时从两个部分检索信息。如本申请所讨论的，这样的数据可包括规则和过程数据，管理数据，客户数据，司机数据，包括基本数据的群组数据，公司的数据，个人数据群组，以及诸如与用户类型有关的数据的其他类型的数据。根据本发明的示例性实施例，数据库108中的所有历史信息可以被分类并存储在数据库108中并从数据库108中检索。可以通过调度的追踪号，服务ID号或行程ID号来部分地追踪历史数据。如果被询问，则帮助计算机系统100的每个服务请求回头参考服务请求。存储的信息可包括请求或提供何种类型的服务请求，谁提出请求以及谁执行请求，服务请求地点，例如邮政编码，区或县，城市或州，使用哪条路线，服务请求的成本，付款的时间和方式，以及是否任何一方将对方添加到首选清单或黑名单。关于客户或司机的偏好或限制，定价和其他可订制信息的所有信息可以存储在计算机系统100的数据库108中。

另外，诸如服务请求的时间和服务请求的价格之类的特定数据可做为客户用以确定平均价格的参考，使得他们可以在预订服务时得到的是公平合理的价格。可对输入并存储在数据库108中的数据进行连续验证。维护综合数据库108还可准确追踪那些客户或司机可能会争议的服务请求。可以从数据库108以有效的方式检索服务请求记录，以便及时地解决任何索赔。

还可在数据库108中输入其他数据，包括但不限于客户前往的地点，首选清单或黑名单，其他交易数据和细节，历史数据，保险单到期日，年检日期，司机驾照到期日，或这些数据的任何组合。这些数据还可包括有关指示符以及指示符显示的相关信息。举例来说，这些数据可包括客户或司机在某个区域，(例如在一个或多个街道，邮政编码，城镇，城市，区，县，州或任何其他用于界定区域的特征内)完成的服务请求，或者计算机系统100将客户和司机匹配的次数等。

可以理解的是，计算机系统100使用的计算机程序指令可包括计算机可执行代码。可使用表达计算机程序指令的各种语言，包括但不限于C，C++，Java，JavaScript，Python，汇编语言，Lisp等。可能需要执行某些逻辑功能，以便为客户和司机提供高度私人订制化的服务，以及解决技术性挑战。可将这些逻辑功能进行预编程以应用于各种偏好和限制，这些逻辑功能可能会非常复杂以便执行特定的场景功能。此外可建立用于识别某些参数的规则以便解释可能出现的多种复杂情况，并且可以通过链接逻辑功能来过滤司机和客户。通过诸如Java之类的编程语言来编程和应用，可以对各种语言功能加以使用。这些语言可包括汇编语言，硬件描述语言，数据库编程语言，编程语言等。在某些实施例中，可以对计算机程序指令加以存储，编译或解释，以便将这些指令在计算机，编程数据处理器，各种处理器的组合等上运行。

现在参考图2，描述计算机设备128的示例性实施例的各种组件的示意图。如上所述，计算机设备128可由客户(例如，通过设备130C1......130Cn)或司机(例如，通过设备132D1...132Dn)使用，或两者均可使用，并且可以与计算机系统100的各种有形或无形组件进行通信。计算机设备128可包含各种内部设备200和外部设备202，并且可以通过移动通信设备220来接收语音，文本和数据，通过广域网124连接到计算机系统100，连接到诸如全球定位系统接收器的位置识别器204，用于识别当前位置。应用程序，地图组件，地图数据和位置识别器204(例如，GPS模块或用于提供基于位置的服务数据)可以集成到一个或多个计算机设备128中用以识别确定位置。位置识别器204可以以不同方式标识计算机设备128的位置，例如，通过接收基于位置的信息。本领域的普通技术人员将理解，存在许多用于提供位置识别和基于位置的服务的方法。支持GPS的系统或设备允许追踪组件以识别计算机设备128的位置。例如，可通过处理计算机设备128的基于位置或地理感知信息接收的GPS数据来对位置识别器204实例化。标识器204可以使用一个或多个应用程序端口(API)从在计算机设备上操作的其他应用程序接收GPS数据。应用程序可以使用位置信息来通过用户界面组件配置用户界面框架。

在优选实施例中，客户可操作与计算机系统100相关联的计算机设备128的客户模块来输入服务请求，该服务请求包括例如客户上车和下车地点之类的行程细节以及预计的上车时间和下车时间。然而，如果客户服务请求与系统不匹配的话(例如，基于从位置识别器204接收的有关一个或多个司机位置和/或数据库108中的司机限制的数据)，系统将通知调度员。

计算机系统100可以作如下配置。当司机进入服务请求中指定的客户上车地点的特定距离范围(例如，一或两英里)内时向客户设备130发出通知。由司机设备132D1...132Dn中的位置识别器204促成的基于地点的服务能够为基于点对点服务的司机生成有效的路线。每个司机设备132D1...132Dn包含一个界面组件，可提供由位置识别器204收集的位置信息，且由广域网124和服务器102将该位置信息发送到客户设备130C1...130Cn的端口组件上。司机设备132D1......132Dn还可包括射频识别技术或其他类似的识别装置或方法，以便通知系统司机是否在车内。

位置识别器204可包括含有GPS的系统或设备，其追踪组件可识别正在进行服务请求的客户的位置以及希望提供服务的司机的位置。计算机系统100可包括应用程序管理器，该应用程序管理器基于客户的当前位置或服务位置，将特定区域的客户界面功能由显示装置212上的客户界面组件输出。客户的特定区域可包括希望预先安排服务的客户当前位置或服务地点。该区域可以通过邮政编码，城市名称等来标识，计算机设备128当前位于该区域，且该区域可以是距离客户当前位置特定距离范围的区域(例如，一英里，五英里等)，或者可以是与其他区域划分开的一个区域。关于预先安排的交通服务的区域特定性信息可以部分地由提供司机位置数据324(图3)的系统给出。可以理解的是，位置相关偏好或限制部分地取决于GPS设备。通过交叉引用数据，这里描述的预先安排服务系统可识别靠近特定地点的位置(例如，商店，餐馆，公寓大楼，场所，街道地址等)，并提供该特定位置信息作为位置数据(例如，作为交通和地图数据326的一部分)。

提供处理器206，以便在计算机设备128上执行软件或一组指令。计算机设备128还可包括存储器208，比如随机存取存储器(RAM)或闪存存储器。输入/输出设备210可用于将计算机设备128连接到其他系统工具，这取决于计算机设备128的可用功能。例如，司机可使用车载导航系统，其可能没有相机，而智能手机可能含内置相机。在这种情况下，摄像机可作为车载导航系统的输入设备。其他输入/输出设备210可包括扫描仪，麦克风和/或扬声器。计算机设备128还可包含显示器212，以接收并向用户显示从计算机系统100接收的通知和/或其他数据。显示器212可以是，例如配置电子触摸屏显示器，以提供用户界面214。计算机设备128还可以使用内部时钟216来确定当前时间。还可以提供加速度计或速度计218作为计算机设备128的一部分和/或与计算机设备128通信，以测量速度，加速度，方向变化等。

用户界面214可根据用户的选择和偏好显示各种内容。可以理解的是，可以将计算机设备128的一个或多个组件进行组合以提供关于用户选择和用户位置等的特定功能。可以向用户显示这些选项，用户可使用用户界面214显示信息。例如，用户界面214可以对应于下载到智能手机或其他便携式计算机设备(例如平板计算机或个人数字助理(PDA))上的程序。用户可以在一个或多个计算机设备128上下载并安装应用程序并在系统中进行注册。在某些实施例中，基于某些规则协议或基本组件的集成方法来使用计算机设备128的预编程功能，诸如服务器，数据库108，移动终端应用程序，互联网门户，网络设置等。该应用程序可以是专为Android(由谷歌和开放手机联盟开发的移动平台)，IOS(由Apple，Inc开发的移动平台)，Windows Phone(由微软公司开发的移动平台)等编写的应用程序。

所有类型的用户均可以在系统中进行注册，以便系统进行追踪。可以通过诸如向每个用户分配用户ID的方式来追踪，这样只有在输入用户ID时，用户才能访问系统功能。另外，可以通过IP地址追踪用户对系统设备的访问，并且可以使用时间戳或类似方法追踪用户活动并存储在数据库108中。以这种方式，系统管理员可以追踪访问系统用户，用户访问的设备，设备的位置，以及访问的时间。这些功能允许调度员追踪用户活动，一旦发生错误，例如服务请求的地址输入错误，则易于判断和发现错误原因。目前的缺点是无法检测和定位该类错误，尤其是当调度员不想承认错误时。可以理解的是，这种功能还提供了一种增加安全性的手段。系统可以忽略从未经授权的计算机输入的任何服务请求。除非给予计算机设备128访问许可，否则它不能访问那些只有注册用户才可执行的功能。允许调度系统一部分由调度员来运行，这样可在必要时增加灵活性和执行功能，因为可能出现需要人为判断的特殊情况。

根据本发明的示例性实施例，用户界面214可以是例如主页，调度门户访问通道(针对司机)，服务请求模块(针对客户)，数据库108的访问端口。或者用户访问本申请描述的任何一个功能或这些功能的组合。系统可检索存储在数据库108中的用户信息和其他数据，其可以在本地和/或远程提供。本领域的普通技术人员将理解，可使用大量其他用户界面与用户界面214一起使用或代替用户界面214。

每个客户设备130C1...130Cn均可以使用客户界面在显示地理信息的地图上显示各种指示符。每个指示符可以表示计算机系统100从，例如，客户，服务提供者或从任何从客户那里接收预先安排服务请求300的任何应用程序。客户设备130C1......130Cn还可以包含基于客户输入的选项来动态将同步内容的应用功能。

客户计算机设备130C1...130Cn上的用户界面214可包括但不限于主页客户界面，用于识别服务请求细节的服务请求面板，偏好细节，摘要客户界面，位置搜索客户界面，确认页界面或任何这些功能的组合。举例来说，如果客户的当前位置与最初请求的上车地点不同，则客户可以手动选择与存储在计算机设备128或计算机系统100中的最初服务请求的位置所不同的新的上车地点。

可以在计算机设备128，例如司机设备132D1...132Dn上提供一个开始按钮功能。一个或多个司机移动设备132D1...132Dn的显示器可以向司机显示关于行程清单的相关信息，比如，从清单所列的下一行程开始，显示行程的细节，例如上车地点和上车时间，目的地及预定的下车时间。司机可以点击“开始”按钮(例如，司机设备132D上的按钮或触摸屏界面)，以便让调度员或管理员知道他/她已经开始行程，正在路上。移动设备上的显示器还可以显示清单中的剩余行程，以便司机查看细节。该开始按钮功能有助于解决各方之间通信过程的缺陷，因为调度员可以轻松识别正在执行的服务请求。另外，它提供了一种方法，通过该方法，已被调派执行下一个行程的客户可以让司机知道其下段行程信息。在通过电话操作的传统调度系统中，司机的当前位置和客户下一行程的预约状态可能是未知的。因此，如果调度员在协调服务请求时无法联系到司机或客户，则他们别无选择只能通过猜测进行操作。然而当司机在服务请求的每个分行程开始时按下开始按钮的话，系统即可将状态记录在数据库108中。如果服务请求的各分程由多位司机执行，则该项功能可便于追踪行程。

可以理解的是，本申请披露的系统和方法提供的功能相比传统调度服务方法更加能促进顺利和有效的调度过程。按下“开始”按钮即可触发影响调度后端系统的一系列过程，并且可以借助各种软件和硬件工具执行该系列过程。例如，按下“开始”按钮可以将司机的位置转发到例如Waze的第三方地图和导航服务，该项服务可基于司机当前速度以及该线路相关的距离，为执行每条线路的司机配置各种路线的选项和预计到达时间。该信息可以实时传送给调度，客户，并返回给司机。

在某些实施例中，用户界面可包括开始按钮，其数据库108中触发一系列有关数据存储的操作，其中司机的地理位置由位置识别器204进行追踪，作为与服务请求，客户、司机等相关的记录的一部分。如果没有该“开始”按钮功能，GPS设备仍可检测到司机的当前位置和线路。但是，当提供预先派单调度服务时，司机会有很长的预先安排的行程清单，如果司机不能确认其正要去接客户的话，没有方法能确定司机当前驶向的地点将是客户的接送地点。因此，开始按钮是一项强大的功能，可以为其他各方的调度员提供司机实时状态的即时更新。

其他功能可能对非紧急医疗运输比较有用，包括为诊所端的用户提供的功能。诊所雇员或操作员可管理(例如，搜索/添加/删除/修改)与诊所相关的看诊预约，并且通过使用开始按钮的功能，将任何可能的变化通知诊所的其他雇员和客户。例如，诊所操作员或客户可以通过按下开始按钮来通知其他用户看诊已经开始。例如，如果看诊开始的时间晚于预约时间，则系统可进行任何必要的更改，例如将预约时间移到其他时间或通知客户这一改变将如何影响他们的预约。另外，在某些实施例中，被指派在客户看诊结束时接送客户的司机可以获得关于客户状态的实时通知，例如“登记”，“看医生”，“几乎完成”，“完成”等，使得司机对预定的接送时间即时了解任何有关接送时间的更改。

客户设备130C1...130Cn可被配置为允许客户通过输入地址(例如，街道号，街道名称，城市，州等)或通过操做和移动服务位置图形/图标来手动进行位置输入并显示在做为客户界面一部分的电子地图显示器上。为回应该客户选择，在客户设备130C1...130Cn中的一个或多个设备上运行的预先派单调度服务应用程序可以将位置数据提供给计算机系统100。

一旦启动了开始按钮，计算机系统100可计算预计到达时间。通过上述界面向司机提供潜在的工作单，显示查询结果以便派单。司机模块可促进启用司机在车辆中的移动设备上的界面。当客户无法在行程单上签字时，司机可从他/她的手机上接收客户签名。

在优选实施例中，系统100在服务请求开始之前或期间可动态地更新和存储对服务请求的任何变更，或者服务请求的状态更新，并且在调度员的网络门户，以及与被调派司机相关联的司机设备132的界面上实时显示这些变更。例如，如果客户取消服务请求或需要更改上车时间或地点，则客户可以通过客户设备130将该信息输入系统100.然后新信息将被存储在数据库108中。调度员的网络门户一旦更新，则将通过司机设备132立即向与服务请求相关联的司机发送更改通知。然后，该司机可优先获得调度员的网络门户中显示的与服务请求相关的信息。另外，在优选实施例中，可以将之前输入的有关服务请求，以及客户的新信息(例如，电话号码，电子邮址，对偏好的改变等)发送到调度员门户网站以及被调度的司机设备132的用户界面。只需对相关的司机设备进行客户信息的更新(例如，与客户的服务请求相关的司机设备)。

当司机在每个行程或服务请求开始时按下开始按钮时，可以在调度员的门户网站和客户设备130中更新行程状态。可以理解的是，这样客户就可以提前查看司机的预计到达时间。该功能将减少或消除调度员的工作量，因为调度不需要电话通知司机任何有关服务的变更。

本领域的专业技术人员将理解，这些功能仅仅是示例性的，也可使用司机界面的其他功能。

外部设备202(即，附加移动设备，平板电脑，笔记本电脑或其他计算机设备)可有线或无线连接到计算机设备128。可以理解的是，这些外部设备202可包括可以向计算机设备128提供附加或增强功能的任何设备。计算机设备128是移动设备，例如平板电脑或智能电话，车载导航系统，或其他类型的计算机设备。

可以理解的是，计算机系统100可集成针对各行业的不同功能，包括非紧急医疗运输业。非紧急医疗运输业的常规做法是接收来自经纪人的服务请求，这些经纪人请求在指定的两个位置之间的特定时间段提供服务。可以理解的是，这些具体规定的目的是为打击欺诈并确保正确完成服务请求。但是，对于该行业的司机来说，按指定的确切时间和地址执行行程有时是不太可能的。意外的交通拥堵或施工会阻止司机准时到达接送地点。由于有停车规定，客户上车和下车规定，常规禁令或其他适用法律或罚款，因此司机可能无法按照要求将客户载往指明的地点。司机可能需要等待一段时间或者是在目的地旁边的街区或拐角让乘客下车，但在这些地方停车和下车可能是违法的。

在某些实施例中，这里披露的系统和方法可与2017年3月提交的名为“地理感知交通运输账单核验的系统和方法”的美国专利申请(系列号15/474,685)一起使用。对前述申请的批露以引用的方式并入本说明书。这些针对账单进行的调整可通过使用位置识别器204追踪客户地理位置来确认，以及在客户上车或下车时分配时间戳以确保客户上车和下车时间和地点处于先前确定的可接受范围内，例如在指定地点的150英尺或15分钟时间段内。如果某服务请求在上述预先确定的接受范围之外，则可展开调查以便查明出现偏差的原因。这样，处理账单的员工即可节约宝贵时间，而司机不必冒被罚款的风险，经纪人也会知道预订的服务请求实际已完成。

如图3所示，可以理解的是，调度系统的任务是接收，组织，协调和调派大量服务请求。公平有效地将司机调派给客户可能很具挑战性。在对服务请求作预先派单调度时，客户在选择司机时可能会对司机要求很高。例如，讲西班牙语的客户可能对不会说西班牙语的司机不满意。本发明可以基于客户的偏好对服务请求进行分类，并且基于各种因素优先考虑某类司机。

图3表示根据本发明的各种实施例的包含示例性调度矩阵的示例性调度操作的示意图。描述计算机系统100的操作的示例性实施例，其中，接收服务请求300，基于调度矩阵322调度司机，以完成所接收的服务请求300。客户可通过客户设备130C1...130Cn中的一个设备(或由供应商通过供应商设备126来代表客户)提交的有关服务请求300的信息也将被包含在调度矩阵中。可以理解的是，客户也可以使用传统手机输入或提交服务请求300。

一旦特定客户或服务提供者提交服务请求300，处理器104即可执行用于从数据库108检索与特定客户信息302有关的相关数据指令。数据可以优选地被分类存储在数据库108内并且被动态更新，以确保在预先派单调度过程中使用最新更新的信息。

客户信息302可包含与客户有关的任何信息，包括例如客户的交通运输需求，一个或多个客户偏好，客户首选清单，客户黑名单，客户联系信息，客户账单信息等。客户信息302还可包括客户的家庭住址，客户的营业地点，客户偏好，历史信息，例如关于客户请求服务的位置的信息，推荐的兴趣点等。当客户选择推荐兴趣点作为当前位置和/或上车地点时，系统可检索各种类型的历史和当前司机位置数据324。如图所示，计算机系统100可以从数据库108中检索司机简档信息310。司机简档信息310可包括司机服务限制，司机历史和/或服务历史，司机首选清单，司机黑名单等。可以理解的是，数据库108可存储多个客户和司机的客户信息302和司机简档信息310，以及所需的任何其他数据308。

司机可预设各种限制，这些限制旨在限制该司机想要提供的服务请求的范围，并且在确定为客户的服务请求寻求匹配司机时加以考虑。例如，有关司机当前位置距离客户上车地点距离的限制可防止计算机系统100显示设定该类限制的司机，如果司机当前位置与客户上车地点的距离超过了司机设置的距离限制的话。司机可优先考虑各种预设限制，以防止冲突。另外，到客户上车地点的距离的预设限制可以防止将不可用服务请求1010显示在电子地图显示器1000上。同样，如果预先派单调度服务切换到即时叫车服务的话，则将不会将司机作为潜在选项向客户显示。

计算机系统100为每位司机检索的历史数据可包括有关该司机以前是由处理当前批次司机的特定调度员调派还是由计算机系统100自动调派的信息，司机是否保留了他/她更愿意提供服务的特定区域的邮编，司机先前在服务请求的(直接或间接)的路线上完成过服务请求的次数，以及司机的评级(例如，用户评级，取消行程和/或被客户拒绝或列入黑名单等的次数)。可以通过计算机系统100为这些因素分配特定权重。历史数据还可包括司机身份证号或姓名，家庭地址，优选服务地点或地理区域，优选工作时间，合作伙伴清单，首选清单，黑名单，预定行程清单和已被接受的行程清单。当将司机调派给服务请求或其分行程时，可以使用与客户偏好，司机限制以及与客户和司机相关联的其他信息相关的这些其他因素。根据这里讨论的系统和方法，可以使用各种算法和加权因子来进行司机调派。可以理解的是，如果针对某批服务请求最初检索识别的一组潜在司机中没有某个司机(以下将进一步讨论)，但该司机与服务请求的上车位置非常接近并且可用，那么计算机系统100将调派这样的司机，只要这样的司机与客户匹配(例如，不在客户的黑名单中，该客户不在其黑名单中，并且不会由于客户偏好和司机限制之间存在完全不匹配状况而被排除)。

基于客户信息302和司机简档信息310，可生成调度矩阵322以排除由于服务请求300的一个或多个方面无法满足而无法为服务请求300提供服务的一个或多个司机。理想的状况是基于与“匹配性”相关的一组规则向特定客户提供服务。例如，如果司机的限制(包括在司机简档310中)以某种方式与服务请求300冲突(例如，如果服务请求300包括从布鲁克林到曼哈顿的行程，但是司机简档信息310表示司机选择不在曼哈顿提供服务，或者如果服务请求300要求在早上7点接送，但是司机简档信息310表示司机最早能接客户的时间为早上8点，这样即可排除将这些司机包括在由计算机系统100生成的匹配司机集合320中。

在某些实施例中，司机位置数据324和/或交通和地图数据326可以由计算机系统100检索，并且系统基于这些数据确定司机是否与客户匹配以包括在匹配司机组320中。司机位置数据324可包括司机的预设和/或相对当前位置或特定时间的司机位置。交通和/或地图数据326可包括与特定区域相关的地理，交通和行程时间信息。可以理解的是，数据库108可包括多个司机的位置数据324以及用于广泛的地理区域的地图数据326。

在某些实施例中，计算机系统100通过处理含不同优先级的不同变量的处理功能通过服务请求300，客户信息302，司机简档310和/或司机位置数据324生成匹配司机组320和调度矩阵322。例如，所接收的服务请求300可包括许多细节，诸如一个或多个客户的行程时间和位置信息。另外客将司机位置数据324和交通/地图数据326(例如，路线，包括交通模式的交通信息，拥堵等)考虑在计算中。此外，可以建立司机优先级，其包括分配给司机的特定“权重”，该权重表示某一特定司机与服务请求300、客户的偏好和客户首选清单的匹配程度、其有能力到达预定上车地点(司机位置数据324)进行服务的可行性，以及预计交通模式(交通和地图数据326)。

例如，熟悉某个服务请求300的路线并且与服务请求300的服务限制没有冲突的两位匹配司机320可以基于这些因素被分配相同的权重优先级。但是，如果两位司机中的一位在客户的首选清单中而另一位却没有，则可以将首选清单上的司机优先调派而不调派不在首选清单上的司机。基于在调度矩阵322中为匹配司机320建立的各种司机优先级，计算机系统100创建调度输出330。调度输出330可包括显示选定的潜在司机，并且可以通过计算机系统100自动发送给客户，或由例如操作计算机系统100的第三方管理员134审阅，然后发送给客户。调度输出330可以是匹配的司机组320的子集或整个匹配司机320，这取决于有多少司机包含在匹配司机组320中，并取决于该客户想查阅多少司机选项。然后客户可以从调度输出330中的司机名单中自行选择一位司机，被该客户选中的司机可选择接受或自动调派。(以下参照图4B作进一步讨论)。

如果司机接受服务请求，则其可以在其服务请求清单上看到被接受的服务请求的状态，标记为“已接受”。然后，该司机可以选择一个或多个服务请求，并一起启动。在该司机选择多个服务请求并开始执行第一个服务请求后，可以通过司机设备132D1...132Dn向该司机提供所有选择的服务请求的清单以供参考，并且该司机可以更新每个服务请求的状态。例如，每个服务请求设有“导航”，“到达上车地点”，“开始行程”，“到达下车地点”等的按钮。如果由该司机同时处理多个服务请求，则该司机可以依次接送。也可在系统中添加签名功能，以便客户在服务请求完成之前或之后进行电子签名。

司机设备132D1...132Dn中的每一个还可包括锁定屏幕功能，该功能可阻止其他功能，使得所显示的唯一项目为询问司机是否确认接受行程。该类通知可显示行程的详细信息，例如上车地点，上车时间，目的地和下车时间，但除了询问对于行程确认回答“是”或“否”之外没有任何其他互动功能。

预先派单调度的服务请求可显示在清单中，每个清单的状态列上标有“已调派”或“未调派”。司机可以有两种选择：接受或拒绝。如果司机接受服务请求，则在服务请求清单的状态列中显示“已接受”。如果司机拒绝服务请求，则服务请求在状态列中显示“已拒绝”，并且可以显示预先调派的司机姓名以供参考。基于数据库108中的记录从更新的清单或版本中删除的服务请求，或者在更新的版本中标记为“已取消”的服务请求可以作为取消的服务请求存储在计算机系统100中。如果某些取消的服务请求已调派给司机并已开始执行，系统可以将它们标记或存储为“开始执行后取消”，并且可以另外记录司机的姓名以供进一步参考。如果接收到未包含在先前服务请求更新中的新服务请求时，可向调度员显示该新服务请求，并且可以向调度员分配高优先级以便提醒调度员寻找司机并发送这些服务。如果调度员通过例如电话，电子邮件，文本消息等接收新的服务请求，则可以将这些请求手动输入到服务请求清单中，并随后调派给可以接受或拒绝它们的司机。

在某些实施例中，系统可以通过比较与每个用户的限制和偏好有关的各种因素来确定客户和司机针对某个服务请求的匹配性。例如，如果司机不讲普通话但客户更喜欢讲普通话的司机，那么所有不会说普通话的服务提供者都被系统认为不匹配。关于时间限制，可以将司机的时间限制与完成客户服务请求的预计行程时间进行比较，如果预计的行程时间超出了司机的时间限制(例如，司机将无法到达他/她在某个时间所需的位置)，那么司机或服务提供者可能被认为与该特定服务请求不匹配。系统还可以将司机的位置限制与服务请求的路线进行比较。如果司机表明他/她不会去某些区域，那么在客户的接送或下车地点涉及这些区域中的至少一个区域的情况下，司机将被视为不匹配。客户可以订制哪些因素或属性与其偏好相关，以及每个属性的相关程度以便系统在预先安排服务时与司机匹配。该系统可被配置为基于客户关于司机，司机的车辆，司机的能力预设的优先级进行加权计算。

可以理解的是，位置限制可能极大地影响司机最终提供服务的位置，且本申请的示例性实施例着重有效的调度系统，可以在调度服务请求时使用其他定义的地理区域。这些区域可以按国家/地区，例如州，县或区，社区，甚至邮政编码来定义。系统的配置能识别发生服务请求的位置，特别是起始位置和结束位置，因为这些涉及服务请求被调度的时间，并且可以按区域对它们进行分组。可以理解的是，使用数据库108中的信息进行分组将带来比随机调度更高的效率。例如，在诸如纽约的大城市中，司机可能会在任何时间被随机调派到任意地点。例如，在非紧急医疗运输行业，司机可能会在布朗士下车，并立即被调派去接送位于皇后区Far Rockaway的另一位客户。虽然这两个地点都位于纽约市区内，但它们在地理位置上相对较远。此外，在考虑到纽约常见的交通和导航困难后，这两个地点之间的行程很容易超过一小时或需要更长时间。基于地理区域和通过追踪司机对服务请求进行分组，可以更有效地执行调度，使司机能够在更短的时间内完成更多的服务请求。可以理解的是，这种分组方式将使调度员更容易以更高的效率对服务请求进行预先派单调度。

可以理解的是，这里描述的系统和过程将允许预先调派服务请求和司机，无论这种预先安排是针对同一天服务，提前几小时的服务，还是提前几天或几周的服务请求。通过以上述方式存储客户信息，司机简档信息，司机位置数据和交通地图数据，计算机系统100能够快速排除数据库108中的多个司机，并为服务请求提供最匹配的司机清单，兼顾考虑司机的位置或预计位置。可以理解的是，这种处理使得计算机系统100可以更有效地操作，因为它可以快速地找出更匹配及地理位置更接近的司机。

图4A表示基于本发明的实施例的示例性调度操作流程图。该过程始于计算机系统100下载或以其他方式接收服务请求300(步骤400)，其可以由服务提供者上载和/或由客户提交。计算机系统100可基于程序步骤自动下载服务请求300，或者调度员可以通过例如点击门户网站中的下载链接或刷新待处理的请求页面来手动下载服务请求。计算机系统100可以被配置为动态更新服务请求以反映任何变更。例如，计算机系统100可以被配置为访问相关的服务提供者互联网门户或应用程序端口(API)用以下载服务请求清单。为了确保服务请求清单反映最新的变化，计算机系统100可以以特定间隔(例如，每5分钟，每15分钟，每30分钟等)重复执行下载。服务提供者还可通过服务提供者模块(例如，通过服务提供者设备126)对服务请求进行编辑。计算机系统100将处理已更新的服务请求清单，并基于存储在数据库108内的历史记录将它们与过去的服务请求进行比较，以确定是否存在相似性(步骤402)。

然后，计算机系统100确定其细节是否与存储在数据库108中的任何以前的服务请求记录匹配(步骤404)，例如匹配的客户姓名，上车和/或下车地点。如果没有找到位置匹配，则向调度员发送新服务请求300进行调度(步骤406)。然而，在调度服务请求300之前，系统将识别所有过滤条件(408)(例如，对路线的熟悉程度，先前为客户完成的服务请求数量，车辆类型等)。服务请求300可以通过例如将它们与数据库108中的司机限制的相关部分进行比较来调整过滤条件，将某些司机排除选择以完成服务请求(例如，服务请求要求司机会讲某种语言，但司机不具备该种语言能力)。如果找到匹配的记录(步骤404)或者在处理了新的服务请求之后(步骤406/408)，计算机系统100搜索数据库108中的记录以确定请求服务的客户的首选司机是否可用于执行服务请求300(步骤410)。

如果确定首选司机可用(是，步骤410)，则计算机系统100将服务请求300发送给首选司机确定是否能提供服务(步骤412)。如果确定没有首选司机可用(否，步骤410)，则计算机系统100搜索数据库108以确定次优选司机是否可用(步骤414)。如果次优选司机可用(是，步骤414)，则计算机系统100将服务请求300发送到该次优选的司机(步骤412)。如果没有首选或次优选司机可用(否，步骤414)，则计算机系统100需识别是否有一般司机可用(步骤416)。如果一般司机可用(是，步骤416)，则计算机系统100将服务请求发送给该一般司机以供接受(步骤412)。如果没有一般司机可用(否，步骤416)，则计算机系统100继续查阅所有司机以便识别和调度下一个可用司机(步骤420)。一旦识别到可用的司机，就可以将服务请求300发送到所识别的可用司机(步骤412)。

如果在步骤412发送服务请求300时司机不接受服务请求，则系统可以重复该过程直到识别出另一位可用司机(步骤420)。当司机在他/她的司机设备132D1...132Dn上接收到服务请求300时，司机可以选择接受或拒绝该请求(步骤418)。如果司机接受服务请求300，则调派该司机以完成服务请求(步骤422)。然而，如果司机拒绝服务请求300，则计算机系统100循环回到步骤410并再次检查是否有可用的首选司机。如果没有首选、次优选或一般司机可用，则在经过一定的时间后，则通知调度员识别下一位可在可的司机(步骤420)。

在完成服务请求之后，可以将司机添加到客户的首选清单和/或客户黑名单中。例如，可以询问该司机是否对客户满意。如果该司机对客户不满意，那么可将客户添加到司机的客户黑名单中，在该种情况下，在将来匹配服务请求时系统不会将司机和客户进行再次匹配。如果该司机对客户的反馈时中性，那么司机不需采取行动，而客户也不会被添加到司机首选清单或司机黑名单中。如果司机对客户满意，则其可以向客户发送请求以授权其将司机添加到首选清单中。如果客户拒绝请求，则其不会被添加到司机的首选客户清单中。如果客户接受该请求，则其将被添加到该司机的首选客户清单中。当司机将来向客户提供服务时，可以再次询问司机是否对客户满意。如果满意，那么司机可将客户保留在其首选客户清单上。在每个服务请求结束时可以询问司机对客户的满意度。如果司机对客户不满意，则他/她可以选择从司机首选客户清单中移除该客户。

在完成服务请求之后，客户同样可以将司机添加到首选清单和/或黑名单中。如果客户对该司机不满意，则他/她可以将其添加到黑名单中，在这种情况下，在未来的服务请求中客户和司机将不再被匹配。如果客户对司机的反馈为中性，那么客户不需采取行动，并且司机将不会被添加到客户首选司机清单或客户的司机黑名单中。如果客户对司机感到满意，则客户可以向司机发送请求以授权将司机添加到其首选清单中。在这样的实施例中，司机可以步骤是否接受该请求。如果其拒绝该请求，则其不会被添加到客户首选清单中。如果司机接受请求，则其将被添加到客户首选清单中。当司机再次向客户提供服务时，系统会再次询问客户是否对该司机满意。如果满意的话，客户可以将该司机保留在其首选清单上。如果客户对司机不满意，则客户可以选择从他/她首选清单中删除该司机。计算机系统100可以被配置为确定哪位司机完成服务请求的次数最多，并尝试将其添加到客户的首选清单中。如果该司机不可用，则计算机系统100可以被配置为调派另一位首选司机，该司机针对客户完成的服务请求次数为第二多，第三多，等等。

当客户表明其想要将司机添加到其黑名单时，系统将提示客户输入原因。可以理解的是，略过黑名单上的司机将提高服务客户的效率并加快计算机系统100在创建调度矩阵322和调度输出330时的处理速度。同样可以理解的是，司机黑名单可作为激励工具，提高司机整体服务水平。司机可能意识到他/她需要改进服务以获得更多业务。

司机可在其首选客户清单上推荐一位客户给另一位司机。例如，涉及该过程的两位司机可以被称为司机1和司机2，而客户称为客户1。司机1可以指示其想要将首选客户-客户1推荐给另一位司机-司机2。首先将授权请求发送给客户1，让便他/她选择是否授权该项推荐。如果客户1未授权，则不会进行推荐。如果客户1授权确认了推荐，则会通知司机2进行选择是否接受推荐。如果司机2不接受推荐，则推荐不会发生。如果司机2接受推荐，则向其提供服务请求，然后可以将客户1添加到司机2的首选客户清单中。同样，可以将司机2添加到客户首选司机清单中。

计算机系统100的用户可以向其他计算机系统100的用户进行推荐，只要两个用户都已注册。对于在黑名单或首选清单中接收某人推荐的用户，可以向接收该推荐的用户提供个人资料信息等信息。计算机系统100同样可以向被引用方提供关于被引用方的用户的信息。例如，第二个接收到关于某位司机的信息的客户可能会在该司机的配置文件信息中看到他/她过去被发现并未出现，并且客户可能会选择不将该司机添加到他/她首选清单中。

客户也可以将司机从黑名单推荐给其他客户。推荐客户时可将单个司机、司机组合或黑名单中的整个司机清单推荐给一位或多为其他客户。而司机可以将客户从他们首选清单中推荐给其他司机。推荐司机可以将单个客户、客户组或整个首选清单推荐给到一位或多为其他司机。一位司机可包括一个或多个预先设置的原因或说明为什么他/她正在推荐首选一位或多为客户。例如，这样一个过程可能从客户1表示他想将客户l首选司机清单中的司机1推荐给另一位客户客户2开始。然而，在推荐之前，会向司机1发送一个授权请求，司机1可以选择是否授权推荐。如果司机1没有授权推荐，则不会推荐。如果司机1接受推荐，那么客户2可以选择是否接受推荐。如果客户2不接受推荐，则不发生推荐。如果客户2接受了推荐，那么司机1将被添加到客户2首选司机清单中。同样，客户2可能会添加到司机1的首选客户清单中。

计算机系统100可以向调度员提供信息，显示哪些服务请求仍未调派。这些信息可用地图显示器呈现，使用标签标识服务请求或客户编号。在该显示器上，调度员可能在未调派的服务请求的位置附近查看到司机。可在视觉显示器上使用各种视觉指示符来区分可用(可载客)司机和不可用(不能载客)司机，以便调度员可以立即知晓其应该将服务请求调派给哪位司机。例如，可用司机可以用显示为白色汽车的指示符来标识，而不可用司机可以用显示为黑色汽车的指示符来标识。本领域的专业技术人员应理解，这里描述的指示符并不旨在限制。相反，作为本发明的示例性实施例，他们时说明性的。

因此，该系统可以提供多组指示符，以便更好地帮助用户，包括司机和客户，安排预先派单调度服务。所提供的各种指示符简化了信息的传递过程。各类指示符可通过一个或多个字母、数字、图标、符号或其他图形来描述信息，这些信息可以显示在用户界面上。例如，可以提供一组指示符来表示从客户的上车地点到服务请求中指定的客户的下车地点的预计行程时间。如果经预先派单调度的服务请求含有多个分行程，则该服务请求可能包含多个客户上车和下车地点。这组表示预计行程时间的指示符在预先派单调度的服务请求中连接与客户的上车地点和客户的下车地点相关的位置信息。这组指示符能告知客户的上车时间，或者告知司机完成服务请求所需的预计行程时间。该组指示符可以是基于从上车地点到下车地点的预计行程时间，可由第三方地图API如谷歌地图提供信息。从司机的角度来看，它可能是从当前位置到上车位置和从上车位置到下车位置这一段时间。如果客户的服务请求在进行预先派单调度时具有多个停靠点，以上步骤可能会发生变化。这些指示符还可包括司机从下车地点回到其预计的返回地点所需的时间，如果司机设置了适用的返回地点限制的话。从司机的角度来看，预计行程时间意味着完成服务请求的时间。但是，从客户的角度来看，完成的服务请求时间只是从上车地点到下车地点的时间。

还可以提供一组指示符来表示司机当前位置和司机返回位置信息。这些指示符可以在电子地图上同时显示给客户和调度员，司机的指示符只有其在上班期间才会显示在电子地图上。这些指示符还可包括司机预设的关于哪天和/或哪个时间可载客的信息。例如，这些指示符可显示其可用性以及其可用性可持续多长时间。如果司机已下班或正在执行某个服务请求，则可以删除相应的指示符。此外，可用这些指示符来确定客户的服务请求是否已调派给司机。这些指示符可在电子地图上显示给调度员，从而可直观显示哪些行程仍在等候安排，可以对这些指示符进行配置，以便当服务请求一旦被调派给司机时(例如，服务请求状态不再是未调派)其便从调度员界面上自动消失。

如果司机预先设置了返回位置，可用一组指示符来表达关于司机当前地理位置和司机返回位置的信息。可提供该类指示符供调度员在其触摸屏电子地图显示器上查看，以便调度员将服务请求调派给最匹配的司机。在另一个实施例中，可以提供一组指示符，以表示客户要求的有关指定的上车地点和下车地点以及服务请求的第一和第二分行程的地点的信息。这些指示符可以在触摸屏电子地图显示器上向调度员或司机显示与服务请求相关的位置信息。触摸屏显示器使得客户可以服务请求进行选择，并可以在触摸屏显示器中配置可点击的传感器。触摸屏显示器内的传感器接收到的信号可能是处理器接收到的输入信号，这些信号可转换成输出，指示系统执行客户或司机做出的选择。

还可提供一组指示符，向客户显示司机到达其所请求的上车地点的预计时间(预计到达时间)。为了生成司机的预计到达时间，系统在第三方API如Waze的协助下，可识别司机的当前实时车速，如司机从当前位置到客户上车地点这段路线的速度。此外，还可提供一组指示符，向司机显示客户的预计能准备好上车的时间(ETR)。这些指示符可以显示，例如，如果客户已经安排了第二段车程，那么客户认为何时可以准备好开始第二段车程。例如，正在看诊的客户可以进入一个或多个客户设备130C1…130Cn预计其将可以在三十(30)分钟内返程。ETR指示符的功能可以提高预先派单调度服务的效率。这种调度方法和ETR的预计可以帮助司机避免或减少浪费时间。在ETR指示符的帮助下，司机将对客户当前状态有所了解，如果ETR时间足够长，那么司机可以在等待期间完成另一个服务请求。

该功能对含有多段分行程的工作单而言尤其有用。根据客户的ETR，为该客户的第一分行程提供服务的司机可以步骤是等待该客户为其提供第二分行程的服务，还是接受第另一个不同的服务请求。如果客户的ETR显示他/她可能需要较长一段时间，暂时无法开始第二分行程，那么司机可以步骤其可以在等待该客户的时间内接受并完成另一个服务请求以便之后可以开始客户的第二分行程的服务。如果系统根据司机的预计到达时间预计该司机无法按时执行客户的第二分行程的服务，那么系统将通知客户。此时，该客户可以选择要么等待该司机来完成他/她的第二分行程的服务请求，要么请求将第二分行程重新调派给另一位司机。如果第二分行程被调派给另一位司机，则该司机将收到关于其何时需要到达客户第二分行程上车地点的预计时间，该预计时间可通过ETR指示符发送。

本系统提供多组指示符，以便更好地帮助客户为服务请求选择最匹配的服务提供者。客户和服务提供者都可以进行各种订制。然而大量的信息，包括但不限于定价、已完成的服务请求数量的标识、对服务请求中的路线的熟悉程度等，对于用户在达成有关服务请求的交易而言可能比较复杂。由于客户和服务提供者需要的信息不同，可根据不同的需求来显示不同的指示符。服务提供者和客户可以通过各种指示符来订制他们的体验、期望和偏好。本发明的示例性实施例提供至少二十六(26)组可订制的指示符，以简化信息。为避免混淆，系统将显示统一的指示符，但用户可以选择更改某些指示符。例如，用户可能想用自己的符号替换默认的符号或图标，比如一个表情符号或他/她的用户ID缩写。此外，还可提供对每个指示符的含义的解释，客户和服务提供者可以选择打开/关闭这些解释，或将其暂时隐藏。如果关闭这些功能，客户仍可以打开其中的一个或所有功能。例如，新用户可能希望看到解释，而那些已经使用该服务一段时间并且非常熟悉服务的人可能不需要看到解释以及各种指示符的含义。如果客户和服务提供者希望优先处理某组指示符而不是另一组指示符，他们还可以更改指示符的显示顺序。

指示符是以一种简单、快速、方便的方式向客户或服务提供者传递或显示服务相关信息的一种手段。多组指示符可帮助在接收和提供服务的这两类用户之间进行匹配，并允许客户和服务提供者进行各种私人订制。客户和服务提供者在各自的界面上可看到不同的指示符。如果他们希望的话，也可以看到彼此的指示符。此外，某些指示符，可能会有一个层级系统，其中包括含有最小和最大的数字范围，且每一层级对不同的客户和服务提供者表示不同的含义。下面对优选指示符进行了简要描述。783申请对这些指示符进行了更为全面的描述，并在此作通过引用的方式在本申请中进行说明。

第一组指示符可以识别司机的用户类型，分三类，包括但不限于首选司机、次优选司机和一般司机。第二组指示符可以将客户分成三类来标识用户类型，包括但不限于首选、次优选和一般客户。第三组指示符用于识别服务提供者的可用性，可连接服务提供者针对服务请求保持可用性的时间。第四组指示符可识别客户当前是否正在请求服务，可连接客户服务请求保持有效的时间。第五组指示符可以基于服务提供者执行的服务请求数量，连接历史数据。也就是说，指示符可通过连接数字来反映服务提供者在一定时间内执行的服务请求的总数，其中，服务请求的总数根据一定时间进一步划分，并由数字、层级或其组合来反映。第六组指示符可基于一个或多个或客户预先设置的相应搜索参数的任何组合显示一个或多个或任何地理区域的组合。第七组指示符可根据第六组指示符提供的数据和信息，进一步比较潜在可用服务提供者的总数和潜在可用客户的总数。第八组指示符连接有关定价的数字，有助于简化服务提供者响应客户提议价格的定价信息。第九组指示符可以显示由服务提供者发起的关于价格的信息，在客户发送服务请求而没有报价的情况下，服务提供者以提议价格进行回应，提议价格可以是可协商的，也可以设置为不可协商。第十组指示符可连接历史数据和地理位置数据，反映有关区域信息的信息，该信息基于服务提供者在客户指示服务请求的上车地点的地理区域内完成的服务请求的总数。并且，第十一组指示符可将历史数据和地理位置数据连接起来，以反映相关区域信息，这些信息是基于服务提供者在客户指示服务请求的下车地点所在地理区域内完成的服务请求总数。

第十二组指示符可传达服务提供者对服务请求的路线的熟悉程度，至少通过百分比或层级等其他描述方法加以表述，熟悉程度是通过对客户服务请求中指明的上车地点和下车地点之间的路线的计算得到的，并与一个或多个服务提供者存储在数据库中的历史数据进行匹配。计算机系统100的管理员(如调度员)可使用这些特有的功能来协调司机与客户之间的各种关系。这种协调可以通过线路匹配软件自动完成，也可以由人工调度员手动完成，确定谁可以为服务请求提供服务等。

该组指示符可以通过将请求的路线信息与存储在数据库中的服务提供者的服务记录连接而生成。对于某个交通请求，该信息可包括服务提供者对服务请求中指明的路线的熟悉程度；对于配送服务，则可能是服务提供者的经验或对路线的熟悉程度等信息。无论是何种服务请求，均可调整指示符以显示相关的信息。百分比本身可以通过百分比来显示；或者可分为层级来显示；例如，E层级表示熟悉程度为0-19％，D层级20-39％，C层级40-59％，B级层为60–79％，A层级为80-100％。“层级”的表示不需要局限于用A到E表示，甚至不需要用字母表示，因为层级可以用依照等级来划分熟悉程度百分比的单个描述方法或多个组合形式来表达。也可将层级和百分比一起显示。这组指示符对于服务提供者来说可能很有用，可用来评估他/她在哪里接载了很多客户，或者他/她在哪里只接载了少数客户。该组指示符可用于评估服务提供者在哪里的经验最多或最有价值，或者客户可以基于服务提供者的服务请求的经验来选择最匹配的服务提供者。

服务提供者的熟悉程度可分为“直接”熟悉和“间接”熟悉。直接熟悉度指的是服务提供者对某条路线的熟悉程度，比如从上车地点到下车地点的路线。相反，间接熟悉程度是指服务提供者对上下车地点之间的路线的熟悉程度的计算，这种熟悉程度是通过对路线的零星体验得来的。例如，两个服务提供者对某条路线有100％的熟悉程度；第一个服务提供者之前曾为客户提供过相同路线的服务，即从相同的上车地点到相同的下车地点。这是一种直接的熟悉性，除了100％的匹配评级之外，还可以通过数字或层表示此服务提供者载相同的路线上提供了服务。第二个服务提供者也有100％的熟悉度—但是，一部分路线是为某个客户提供，而另一部分路线是包含在为另一个客户提供的另一个服务请求中。虽然服务提供者也提供过整个路线的服务，但它不包含在从相同的上车地点到相同的下车地点的一个服务请求中。服务提供者对路线的熟悉程度是间接的。对服务请求路线的熟悉程度的计算，无论是直接或间接的，是通过追踪请求的路线的全部或部分路线与以前完成的路线的相同程度，通过比较服务请求的路线与服务提供者以前完成的路线来进行的。服务提供者对所请求路线的熟悉程度在以下情况尤为重要：所请求路线的任何部分位于已知的GPS信号微弱或没有信号的区域内，或者在天黑后执行服务请求时，使得追踪导航方向更加困难。

第十三组指示符基于客户和服务提供者被匹配并一起完成的服务请求的次数。第十四组指示符可以将服务提供者的位置信息与客户上车地点连接，显示服务提供者可以载客的时间、预计到达时间等。第十五组指示符基于服务请求中所示的从客户上车地点到客户下车地点的预计行程时间(ETT)。第十六组指示符连接地理位置数据，以至少反映服务请求中指明的客户的上下车地点。第十七组指示符传递关于客户请求和完成的服务请求总数的信息。第十八组指示符基于服务提供者预先设置的一个或多个或任何搜索参数组合确定一个或多个地理区域、或其组合。第十九组指示符可以基于第十八组指示符进一步显示潜在可用服务提供者的数量与潜在可用客户的数量。第二十组指示符可简化客户发起的对价格提议的显示，连接并显示有关价格信息的数字。第二十一组指示符提供关于对服务提供者提议价格进行响应的客户提议价格的详细信息，其中关于价格信息的数字通过这组指示符进行连接和显示。第二十二组指示符连接关于客户服务请求历史记录和地理位置数据的历史数据，从而基于上车地点所在地理区域的客户请求数量和完成的服务请求的数量来对客户进行标识。第二十三组连接地理位置数据和历史服务请求数据，基于下车地点所在地理区域的客户请求数量和完成的服务请求的数量来标识客户。第二十四组指示符可以连接历史服务请求数据，显示服务提供者和客户匹配并一起完成服务的次数。第二十五组指示符可以标识为服务提供者完成服务请求所需的预计行程时间。第二十六组指示符可以在服务提供者预设返回位置的情况下，在执行服务请求后，将服务提供者的地理位置数据与服务提供者预设返回位置的地理位置数据连接起来。

此外，任何至少部分基于可计数字的指示符，也可以按层级反映。系统所分配的层级，取决于其对象是客户或服务服务提供者，可以是一个包含最大和最小临界值的数字范围，也取决于其是用于交通运输服务、配送服务，或同时应用于交通及配送服务。它们可以以字母、形状、颜色或任何其他能显示每一层级间差异的方式表示。客户和服务提供者的指示符可以有不同的含义。这些指示符表示相对于他们的用户类型、类别和子类别的活动。由于系统将服务请求记录存储在系统的数据库中，因此可以使用时间戳将何时执行服务请求加以量化，以及通过请求细节将在何地执行服务请求加以量化等。这些关于时间或其他数字的记录可以按比例放大或缩小，客户可以划分相关的时间框架，例如一天或数天、一月或数月，或者一年或数年。所有这些关于时间、时间框架、区域或其他数字的可调整搜索参数都是可订制的，这样客户和服务提供者就可以对他们希望看到的信息进行个性化和优先排序。

与服务提供者相关联的供应与需求，可以由客户根据其预计上车地点，上车时间、从上车地点算起的距离，以及客户愿意针对服务请求与其议价的服务提供者数量预设的搜索参数来显示。基于时间的搜索参数可生成一个搜索距离半径，并可包括识别的所有可能正在通往上车地点线路上的服务提供者，确定其在每一个可能的路线上的实时行驶速度，将客户预设的其允许的最长行程时间乘以沿着每一条可能路线的每个服务提供者的行程速度，用以计算服务提供者在客户预设的最长时间内能够行驶的最长距离，识别客户上车地点为搜索半径的中心点，并确定搜索半径的极点，该极点可以是服务提供者在搜索参数范围内的或客户预设的最远位置。在搜索参数范围内，服务请求的供求关系可以为客户显示潜在可用服务提供者数量与潜在可用服务提供者需求数量的对比。

客户预设的搜索参数可包括预设的理想的服务提供者数量，通过识别以上车地点为中心的搜索半径创建一个搜索半径，还包括确定搜索半径极点为服务提供者距离中心点最远的位置。搜索半径可以小于或大于基于时间或距离的搜索半径，可以在指示符的帮助下为客户确定服务提供者预计到达的时间。在搜索半径范围内确定的服务提供者的数量可以优先用于客户的价格谈判。

客户和服务提供者各自界面上显示的指示符可以各不相同。其中一些指示符可能与用户类型相关，无论是提供服务还是请求服务。有些指示符对客户更有用，而有些指示符对服务提供者更有用。但是，指示符并非仅显示给服务提供者或仅显示给客户，因为优先显示给一方的指示符可能反映对另一方有用的信息。但是，如果用户愿意，他们可以通过系统查看自己的信息。如果他们有兴趣看到自己的指示符或服务请求历史以确保其他用户看到关于他们的服务请求历史的指示符是正确的，他们可以通过他们的个人信息或其他任何系统指定的方式来实现，系统会显示所有适用于他们的指示符。该项服务请求历史记录可包括其他各方可以看到的信息，例如关于已完成或请求的服务请求总数的指示符。服务请求历史记录还可提供其他各方无法看到的信息，比如关于他们赚了多少钱或花了多少钱的私人信息。所有这些指示符都旨在为客户和服务提供者提供可订制的信息，这些信息可帮助他们分别选择最匹配的服务提供者或客户，从而为彼此提供最佳的交易。可以理解的是的是，还可以通过一个或多个计算机设备创建和/或使用其它的指示符，来通过视觉方式直观传达其他类型的有关资料。

司机接受服务请求的第一个行动是按下司机设备132D1……132Dn上的“接受”按钮。当司机准备开始服务时，他/她可以按下“开始”按钮，表示他/她正在前往上车地点的路上。司机也可以打电话通知客户其正在路上。如果司机在按下“开始”键后的任何时候需要取消预约，例如，如果他/她的轮胎爆了，或者司机的车辆发生了机械故障，或者有任何其他正当理由取消预约，在这种情况下，司机可以提供取消预约的原因并取消服务请求，然后服务请求将被重新调派给另一位司机，如该司机的合作伙伴司机。

如果需要的话，司机可随时取消服务请求。如果司机提前一天取消，那么可不必报告取消原因。在这种情况下，调度员可以重新将服务请求调派给其他司机。如果司机在服务请求日期取消服务请求，那么司机可以提供取消的原因，从潜在的默认原因中进行选择，或者通过文本输入填写原因。如果在取消之后没有任何司机接受服务请求，那么服务请求将被返回到主门户网站的服务请求清单上，以便调派给其他司机。调度员重新调派服务请求后，计算机系统100可以配置向客户发送通知，通知包括之前的司机的姓名，其不能为客户提供服务的原因，新司机的姓名，电话号码，车辆型号、颜色、上车时间等。客户可以随时更改或取消服务请求。如果客户在上车后希望更改目的地，司机可以重新制定到目的地所需的线路。当司机和客户到达下车地点后，司机可以要求客户在服务申请表上签字，以确认所提供的服务是正确的和/或令人满意的。完成这些步骤后，服务请求即结束。

可以理解的是，预先安排对司机的调度可以让司机自行步骤接受或拒绝哪种服务请求。计算机系统100可提供一种功能，让司机选择潜在的服务请求，例如，电子地图显示当天、第二天、下一周等的可用路线。使用当前和/或未来预测的交通和其他可能影响行程时间的事件(如建筑、道路封闭、事故等)或司机的地点限制来计入司机对时间和地点的限制。这些数据可以存储在数据库108中，并可作为交通流量和地图数据326的一部分提供给调度矩阵322(见图3)。

图4B所示为流程图，描述客户或司机按照图4A的示例调度操作取消已预订的服务请求的一系列示例步骤，以及替换取消行程司机的流程。司机或客户可随时取消预先派单调度的服务请求。如果司机(或客户)提前在足够长的时间(如一天、一周等)内取消预先派单调度服务，则司机(或客户)无需报告取消原因。在这种情况下，如果客户取消了服务请求，调度员或计算机系统100将简单地取消服务请求，或者将服务请求重新调派给其他司机。但是，如果该司机在短时间内取消服务请求，则使用其他方法替换该司机。

具体来说，如图4B所示，一旦将服务请求300调派给某位司机(步骤422)，计算机系统100就可以向客户发送一个通知(步骤424)，表明服务请求300已经被调派。如果该司机没有取消该项服务请求(步骤426)，而客户也没有将其取消(步骤428)，那么服务请求将如期执行完成(步骤430)，流程结束(步骤432)。然后该司机可以开始计费过程。但是，如果客户取消(步骤428)服务请求，例如通过客户设备130C1……130Cn取消该项服务请求，那么客户可能被要求提供取消的原因(例如，预约取消、由他人接送、不再需要服务等)(步骤434)，流程就此结束(步骤432)，也不需要计费收费。然后，被调度的司机可被调派去其他地点。如果司机取消(步骤426)，那么计算机系统100须派送一个新的司机。在一个实施例中，如果客户预先设置了允许伙伴司机的权限，则基于取消司机认同的的一位或多位伙伴司机，计算机系统100对服务请求300进行重新调派(步骤435)。向合作伙伴司机发送调派通知等待接受(步骤437)。如果客户没有预先设置允许合作伙伴司机的权限，那么可以将服务请求发送给调度员处理(步骤439)。对于伙伴司机的调派可以存储在数据库108中，以便通过计算机系统100进行快速查询。在这种情况下，服务请求300可能被发送到合作伙伴司机(步骤436)以完成服务请求300。另一选择为，服务请求300可以发送给多个潜在的合作伙伴司机，并可显示这些最佳匹配的合作伙伴司机的清单，供客户从中选择。如果客户选择的伙伴司机接受服务请求(步骤437)，那么该伙伴司机应针对该服务请求提供服务(步骤438)。

用于为服务请求提供服务(或可能会为服务请求提供服务的合作伙伴的司机清单)选择合作伙伴司机的方法可以类似于上面图3所讨论的生成匹配司机和调度矩阵的方法。换句话说，可包括为潜在的合作伙伴司机分配司机优先评级、评估可用性、限制等。客户可使用这些因素自行考虑作出选择。或者，可以将每个司机与单个伙伴司机相关联，以便在将先前调派的司机取消时自动将一个伙伴司机调派给服务请求(如果可用且不在客户黑名单上)。在确认用伙伴司机替代被取消司机后，伙伴司机完成服务(步骤438)，流程结束(步骤432)。然后，合作伙伴司机可以启动计费流程。

如果客户提前取消服务请求300的时间足够长(如半个小时的阈值)，则服务请求300可标记为“取消”，计算机系统100可立即通知司机。一旦该司机收到取消通知，系统可以配置为要求该司机确认其收到了取消通知。否则，如果该司机未确认收到取消通知，则在相关司机设备132D1上运行的应用程序……132n可能被锁定，在确认收到取消通知之前，该司机不能在应用程序中执行任何操作。然而，如果客户在短时间内取消服务请求(例如,少于接客前一个半小时)，那么可以为该个客户提供一种方法使其在最后一刻取消服务请求，如客户可以表明“上车之前取消了5分钟。”在预定的最后一分钟和/或完全取消后，客户可能会被添加到系统的黑名单中，以便计算机系统100在一定时间内不再为该客户提交任何服务请求。计算机系统100可以进行配置向客户发送通知，警告客户如果再发生两次半小时内取消预订的情况，他/她将被列入系统黑名单。如果客户有任何疑问，计算机系统100也可以提供联系方式。

如果客户的服务请求在最后一刻被司机取消，那么该服务请求将立即被重新调派。此流程的第一步是将该项取消行为通知客户，其中可包括重新调派的详细信息。在这种情况下，计算机系统100首先可以确定服务请求与客户首选清单上的任一位司机的匹配性。如果有多个司机是匹配的，那么系统可以服务请求通知这些司机，并将服务请求调派给首选司机中最先接受服务请求的那位。

可以对计算机系统100进行配置，使司机可以选择将客户添加到其预先设置的黑名单中。一旦司机将客户添加到司机的黑名单中，当为同一客户的服务请求搜索匹配的司机时，计算机系统100将跳过该司机。为了避免冲突，系统可配置为，当其收到司机黑名单上的客户的服务请求时，计算机系统100会自动将该请求发送给另一位司机和略过任何将该客户添加到各自的黑名单的司机。

当司机将客户列入黑名单时，这就排除了将黑名单上的客户添加到司机首选客户清单中。换句话说，被列入黑名单的客户不能同时出现在司机的黑名单和首选清单中。调度员也可以得到计算机系统100关于某些司机被某些客户列入黑名单的通知，反之亦然，这样他们就会知道哪些司机不应被调派执行特定服务请求。“黑名单”本质上是针对“难相处”的客户或“表现不佳”的司机。但是，可以理解的是，司机或客户可以因为任何原因被列入彼此的黑名单。被列入黑名单的客户和司机将自动被排除与某些相应的司机或客户匹配，或完全被排除被调度。

存储在数据库108并被被动态更新的为客户预设的“偏好”可包括、但不限于与下述相关的偏好：上车地点、下车地点、车辆品牌、型号、车辆类型、执驾年长、载客人数、性别、语言、轮椅设施、医疗设备、宠物设施、及婴儿座位等。上车地点偏好允许客户识别其上车地点。下车地点偏好允许客户识别其下车地点。“车辆品牌、型号及车辆类别偏好”允许客户指定其服务请求所需的车辆品牌、型号及车辆类别。“驾龄”偏好允许客户预先设定他/她可能希望他/她的司机拥有的驾驶年数。“载客人数偏好”允许客户为其服务请求指定乘客数量。性别偏好允许客户选择特定性别的司机。“语言”选项允许客户选择说某种语言的司机。“轮椅设施”允许客户设置针对车辆配备的特殊需要偏好。“医疗设备”偏好使客户能够确保运输车辆具有某些设备，如氧气罐或其他医疗设备。“宠物设施”偏好允许客户为含有宠物的服务请求预先设置偏好。“婴儿座位”偏好允许客户要求司机提供婴儿座椅。

客户可能还会优先考虑司机对服务请求的特定路线有多熟悉。司机的熟悉程度可以是“直接”熟悉，也可以是“间接”熟悉，两者都可以通过客户设备130C1…130cn上的客户界面传达给客户。例如，直接熟悉度可能是计算司机对从上车地点到下车地点的路线的熟悉程度。间接熟悉度可能指的是司机对上下车地点之间的路线熟悉程度，但这种熟悉程度是通过对路线的零散体验来计算的。例如，两个司机可能100％(100％)熟悉给定的路线，但这是通过不同的经验。第一位司机可能为同一路线提供服务，即从同一上车地点到同一下车地点。这种经验将构成直接的熟悉程度，除了对匹配的路线进行100％的评分外，还会有一个数字或层次，表明该司机使用相同的路线提供过服务。第二位司机可能在过去为不同的客户服务了该路线的一部分，而为另一个服务请求服务了该路线的另一部分。即使第二位司机已经穿越了服务请求的整个路线，但它不是从相同的上车地点到相同的下车地点。因此，第二位司机将间接熟悉当前服务请求的路线。

对行驶的路线的熟悉程度，无论是直接的或间接的，可通过将请求路线与同一司机以前完成的服务请求的路线相比较，并通过追踪请求路线的全部或任一部分与之前司机完成的路线有多少共同之处计算而得。可以理解的是，当请求路线的人一部分位于已知信号薄弱或没有GPS信号的区域时，和/或服务请求发生在天黑的情况下，司机对请求路线的熟悉程度尤为重要，因为这种情况下导航较难。还应理解的是，应在数据库108中持续存储和动态更新数据每位司机的GPS数据，以便于自动追踪，用来验证司机对给定路线的熟悉程度。

系统订制部分地基于客户的偏好和司机的限制。这里讨论的偏好概念涉及给客户选择，以便其为服务请求设置某些选择条件。本领域的技术人员会理解，“偏好”一词无意以任何方式限制这一概念。也可用其他术语，如“条件”、“过滤条件”或“限定条件”替代该术语。术语“限制”也并非以任何方式限制允许司机对接受服务请求设置限制的概念。可以用“限制”或“界限”等术语来代替“限制”。此外，术语“偏好”和“限制”可以相互对照使用，这种对照旨在传达客户和司机之间的用户类型差异，而不是将“偏好”和“限制”作为根本对立的概念。应当理解的是，有偏好的客户可能也有局限性，或者有局限性的司机可能也有某些偏好。

司机对服务的限制可包括但不限于与服务时间、返回地点和时间、服务区域、对特殊需要的满足、乘客人数、过敏、婴儿座椅限制以及任何其他相关限制。服务时间限制允许司机预先设置他/她不能提供服务的时间。返回位置和时间限制允许司机预先设置他/她想要在特定时间到达的特定位置。服务区域限制允许司机预设一个或多个他/她不愿意提供服务的地理区域，例如，基于邮政编码、区、市、州等。一位司机可以在相关司机设备132D1…132Dn之一的司机界面上通过交互式地图为地理区域设置限制。司机可以点击地图上的邮政编码以确定他/她是否愿意提供服务的位置。关于选择地理位置的司机限制可能需要在服务请求被分批处理并按分组分发给司机，如以下图6-9所示。

例如，布鲁克林的司机可能会看到地图上布鲁克林的邮政编码反映了布鲁克林的分区。该司机可以点击每分区来表示特定的服务区域。提供可点击的地图界面(即交互式地图界面)使得司机快速有效地设置其限制条件(例如，允许司机选择其想要工作的地理区域)。根据本发明的示例性实施例，司机的可点击地图也可以作为附加或替换与另一位司机(如合作伙伴司机)的可点击地图结合。通过结合司机和合作伙伴司机的服务区域，计算机系统100可潜在地为调度员生成和显示司机以及该司机的合作伙伴司机提供服务的范围。除个人地点限制外，司机可预先设定与工作轮班有关的个人时间限制。计算机系统100可将邮政编码在数据库108中分区或县、镇、市或州组合成地图数据。一旦计算机系统100识别出邮政编码或其他位置限制信息，就可在生成调度矩阵322和调度输出330时越过具有相关位置限制的司机，从而不向这些司机发送涉及该司机限制区域的服务请求。本领域的普通技术人员会理解，这里描述的司机的服务限制清单不是排他性的，而且司机可以有关于其服务的其他限制。

涉及位置的限制可能会大大影响司机最终提供服务的地点。可以理解的是，本发明的示例性实施例提供了允许使用其他方法定义的区域来调度服务请求的高效调度系统。计算机系统100可识别哪些服务请求将在何处发生，特别是开始和结束位置，因为它们与预先安排的时间相关，并且可以按区域对其进行分组。在当前实践中，调度几乎是随机执行的。在像纽约这样的大都市里，司机可能会在任意时间被派往任意地点。通过按地理区域对服务请求进行分组和追踪司机，调度员可以更有效地对服务请求进行预先派单调度，司机可以在更短的时间内完成服务请求。

参看图5。图5显示了服务提供者(如司机)和客户之间的价格谈判的典型工作流程。在本发明的示例性实施例中，客户可以向系统提交其服务请求的提议价格(步骤501)。客户的提议价格可基于默认价格，一个或多个处理器可确定提议价格高于、低于或等于默认价格。交通服务的默认价格可能与配送服务的价格不同。当客户请求服务组合时，默认价格可来自每个交通服务和配送服务的默认价格。

为简便起见，图5仅描述了客户发起交通服务价格议价的情况。系统询问客户想要将提议的价格发送给谁，但这取决于客户是否有任何首选服务供应者(或任何首选服务供应者可用)(步骤502)。如果有首选服务提供者可用，那么客户可步骤是否将价格提议发送给这些首选服务提供者中的一位或多位(步骤503)。如果客户希望将价格提议发送到这些首选服务提供者，他/她将另外步骤他/她的提议价格是否可以与首选服务提供者协商(步骤504)。如果没有首选服务提供者、没有首选服务提供者可用、或者如果客户不想将其提出价格发送给他/她的任何首选服务提供者，那么客户可以步骤他/她提出的价格对于次优选或一般服务提供者是否可协商(步骤505)。无论服务提供者是首选服务提供者还是一般服务提供者，一旦服务提供者确定客户是否将与一个或多个服务提供者进行协商，流程都是相同的。

当客户设定一个可以协商的价格时，通知服务提供者该价格可协商(步骤506)。然后由服务提供者步骤是否进行协商(步骤507)。服务提供者针对可协商的价格提议有三个选项。如果服务提供者根本不想接受服务请求，他/她将拒绝协商和请求，请求将过期(步骤508)。如果服务提供者不希望协商，但仍然希望提供服务请求，那么他/她将接受原来的可协商价格(步骤513)，然后进行被调派(步骤514)。服务提供者的第三个选择是协商价格。服务提供者提出一个还价(步骤509)，该还价被发送给客户。然后客户可以选择是否接受该还价(步骤510)。如果客户接受，则由系统调派服务提供者(步骤514)。如果客户不接受，那么客户对该还价进一步进行还价(步骤511)，然后协商循环回到服务提供者。服务提供者步骤是否接受还价(步骤512)。如果服务提供者接受还价价格，则服务提供者会被调派(步骤514)。如果服务提供者不接受还价，那么他/她将再次进行还价(步骤509)。该过程将重复进行，直到服务提供者和客户都同意价格，最后服务提供者将被调派(步骤514)。

当客户设置了不可协商价格时，请求就被发送到客户首选服务提供者(或任何其他服务提供者，如果客户的首选清单中没有可用的服务提供者)，后者要么接受要么不接受不可协商的价格(步骤515)。如果服务提供者接受不可协商的价格，那么他/她将被调派(步骤514)。如果服务提供者不接受请求，则通知客户服务请求没有按照他/她提议的价格被接受(步骤516)。客户可以在接到通知后修改原来的服务请求并重新提交新的价格提议(步骤501)。

本领域的普通技术人员会了解，图5只描述了服务提供者和客户之间进行价格谈判的许多可能场景中的一种，系统可以从服务提供者或客户那里收到初始提议价格。因此，最初的提议价格可能被客户和服务提供者还价。此外，可以理解的是，这里描述的过程不是排他性的，不需要运用这里描述的特定步骤顺序来达到理想的结果。

图6描述了示例性批量预先派单调度方法流程图。计算机系统100可能会收到多个服务请求(例如，由客户/乘客和/或由第三方服务提供者发出，或由代表需要交通运输服务的患者的保险公司上传)，并对这些服务请求分配识别号(ID)(步骤600)。这些上传操作可由客户使用一个或多个客户计算机设备130C1…130Cn，客户或第三方服务提供者通过互联网端口使用该服务提供者设备126以电子方式完成，和/或调度员通过电话、短信、电子邮件或书面接收到服务请求和相关日程安排后，使用调度员设备136手动完成。此外，系统可采用互动语音识别技术及/或话音文本转换技术，通过传统电话系统自动接收服务请求。

服务请求300会按行程中的每一部分(例如，上车地点、下车地点等)分成若干段分行程(步骤620)。服务请求可包括在地点A上车和地点B下车，以及在稍后的时间在地点B上车和在地点A下车。然而应当理解的是，一项请求可能包含三个或多个下车地点和/或不同的上车地点，并且可能在一天中分段进行。例如，服务请求300可包括客户家(位置A)、医院(位置B)和工作地点(位置C)，并且有三段分行程，A到B、B到C、C到A。三段分行程将按时间顺序执行，但时间段不同。服务请求、分行程及其有关的所有资料，包括每段分行程上下车地点对应的邮政编码，以及所需的上下车时间，均可储存在数据库108中。

调度员可以使用调度员设备136指定一个特定的地理区域(例如纽约市的五大区之一)和一个特定日期(例如同一天、第二天、从今天算起的今后几天，从今天起算的一个星期，等等)，在这些时段内，调度员通过计算机系统100将尚未调派的服务请求调派给司机(步骤610)。或者，可以将计算机系统100预先设置为在所请求的服务日期之前的预定天数自动批量处理服务请求。例如，对于计划在8月18日进行的服务请求，可以将计算机系统100预先设置为在8月17日执行批量处理分配过程。调度员可以通过调度员设备136上的端口，按时间顺序或其他方式按各自的服务请求日期查看计算机系统100中接收到的未调派服务请求的清单。调度员或计算机系统100可以从保留在计算机系统100中的尚未调派的服务请求中未来最早的日期开始开始调度活动。计算机系统100还可以配置为自动选择特定的日期(例如，任何未调派的服务请求在系统中保留的最早日期)的第一个地理区域(例如曼哈顿、皇后区等)在该日期进行安排。

接收到特定日期和特定地理区域后，计算机系统100从上传的存储的多个未调派服务请求中检索一批未调派的服务请求(步骤630)。检索的尚未调派的批量服务请求一般会包括分行程，其上车地点和下车地点位于指定的特定地理区域内(或至少有一个相应的上车和下车的位置位于指定的特定地理区域内)，并且请求的上车时间或下车时间在特定日期(指定日期)(步骤620)。计算机系统100还可检索与该批未调派的服务请求相关联的多个客户相对应的客户信息，以及根据指定的特定地理区域和特定日期调派给该批次服务请求的潜在司机组对应的司机资料。客户信息可包括客户ID号或姓名、服务偏好、首选清单、次优选清单和黑名单。司机资料可以包含一个或多个服务限制、服务历史、首选清单、黑名单和历史数据的司机信息。

计算机系统100可针对一批服务请求识别一组潜在可用的和匹配的司机(步骤640)，并将这些司机调派给该批服务请求。可以理解的是，系统可以在收到的调派日之前执行步骤640和650，因此，司机将被初步调派执行服务请求，系统在收到具体的调度日期之前使用用算法(步骤650)对司机进行动态更新及调派。在从调度员那里接收到特定的调派日期后，系统可打印一份特定调度日期时间表。如图所示，计算机系统100在标识可用和匹配的司机和分派司机之间循环，这是因为每次调派都可能会改变执行下一个预先派单调度的服务请求的特定司机的可用性(步骤640,650)。司机的可用性可以依据司机预设的限制以及司机针对未调派的服务请求的上车时间预估位置加以评估。(例如，司机可能已经被调派执行某个服务请求的分行程，该请求已经存储在数据库108)。而该司机的下车地点和时间使其能够步骤为该尚未调派的服务请求提供服务的可行性或不可行性。

例如，如果之前服务请求的最后一段分行程中客户要求于Ti时点在Xi地点下车，而其第一段分行程请求于T2时刻在X2地点上车，那么，如果Xi和X2相对距离较近(例如，两者处于同一邮政编码内)，而Ti和T2在时间上也很接近，以致该司机有时间从时点Ti地点Xi赶到地点X2(时刻T2)(例如，根据用储存交通和地图数据326中的预估行程时间)。这样，在考虑了客户和司机的偏好/限制之后，计算机系统100将认为可将该司机调派给该未调派的服务请求。计算机系统100可有效地将服务请求调派给该司机。

对于执行该批未调派服务请求的潜在一组司机，其匹配性是根据一种或多种算法或标准进行评估的，这些算法或标准是基于如本申请所讨论的是否列在客户黑名单、首选清单或次优选清单上的司机。在首选的实施例中，客户首选清单上的可用司机被列为最高优先级，然后是客户次优选清单上的可用司机。客户黑名单上的可用司机不会被调派执行该客户的服务请求。客户的首选清单(如果需要的话，还有次优选清单)上的所有可用司机都可以通过计算机系统100进行评审和考虑，以进行潜在的调派。

计算机系统100按照预先确定的算法(步骤650)调派司机。计算机系统100可以从第一次服务请求开始，检查司机的对地点、时间冲突、黑名单、行程冲突，等等，并排除任何不能服务于未调派的服务请求的司机，不能提供服务的原因包括停运、黑名单、预计上车时间地理位置、预计午休时间或停运时间、或任何其他原因。下一步，计算机系统100可以查看是否有未排除的司机(例如，在上车时间和日期，哪些司机应该在上车地点附近，并且合理地接近上车地点)在客户的首选或次优选清单中。如果是这样，那么该司机可以被赋予高优先级调派。

此外，在执行步骤650时，基于首要标准匹配性，将调派同一位司机执行服务请求的所有分行程，以最大限度地提高客户满意度。但是可以理解的是，服务请求的第二段分行程(例如，返回段)可能由其他司机提供服务，而不是由调派的第一段分行程的司机提供。另外，计算机系统100可将第一位司机调派给第一个服务请求的第二行程，同时将第一位司机在两段分行程之间的状况保持为“可用”，随后在那一段可用时间内将另一项服务请求的另一条段分行程调派给第一位司机，条件是，当时确实出现这段分行程，且第一位司机满足匹配性--这是计算机系统100对该批次服务请求进行处理的结果。计算机系统100可以配置成为服务请求的不同分行程预订一位或多位司机，但同时也遵循客户和司机的偏好和限制。

可以理解的是，司机在轮班期间载客时，等待时间可缩到最短，因为系统自动为司机安排工作，但司机载客时间总的会增加。此外，还应当理解的是，对司机的调度和工作流程可以在由于取消、延迟或其他问题而出现的情况下进行动态更新。接收到服务请求并提前对其进行组合、调派时，司机的工作时间表会提前排满，计算机系统100可以在司机可用性发生变化时(例如，当司机打电话请病假、改变他们的工作时间，等等)最大化提高效率，动态更新对其的调度，迎合客户和司机的需要。

计算机系统100可配置为将依照步骤650中使用的算法/标准未调派给司机的批量服务请求中的剩余服务请求存储到工作单库中(660)，以便多个可用司机可以通过远程司机计算机设备132D1…..132Dn选择至少一项剩余的未调派服务请求。计算机系统100可以限制单个司机从工作库中选择的未调派服务请求的数量。

如图10所示，工作单库中未调派的服务请求可以由司机通过其设备132Dn…132dn访问可点击电子地图显示器1000显示出来。电子地图显示器1000可显示不同地理区域，对应于多个未调派服务请求的上下车地点所在地的六个分区(即，I，II，III，IV，V，VI)标注。未调派的服务请求可以以可点击的指示符1010显示。虽然这里用“星星”来显示，可以理解的是也可以使用任何类型的形状、图标、字符或图像，并且可以使用多种类型的指示符来标识。司机可以通过相关司机设备132D1…132D选择(例如，点击)I到VI的多个分区，和/或选择一个或多个可点击的指示符1010来请求不同的调派区域或相应的未调派的服务请求。司机还可以使用地图显示器1000为服务指定其初始限制或其他预设。例如,司机在计算机系统100司机进行默认设置，选择I到VI的六个分区之一，指定一天或多天，指定首选的工作区域。司机的默认首选的工作区域可以设置一个对应于司机的家庭地址的区域。

再次参看图6，一旦某一特定司机被调派了足够的服务请求，且在指定日期所剩余的可用性将极小，则计算机系统100可以将预先派给该司机的单发给司机查阅和确认(步骤670)。

该司机可以接受或拒绝被调派的服务请求。司机可以在，例如，在服务请求指定日期前的数天甚至数周，也可以在调派日期临近时确认。

客户还可以随时向其首选清单、次优选清单或黑名单中添加司机，司机也同样可以向其黑名单或首选清单中添加客户(只要客户或司机同意该请求)。例如，在完成批量调派服务请求之后，可能会出现该类添加操作。用户可以查看以前的司机和客户的个人资料，并将该请求发送至彼此的首选清单中。可以提供一个搜索功能来查找客户和司机的帐户。将客户添加至司机黑名单或将司机添加至客户黑名单的操作不会由于相互通知或批准而发生或不会发生，可以理解的是，在未通知对方的情况下单向授权黑名单将避免冲突或出现客户和司机之间的尴尬状况。如果有两位司机都同意，司机可以在任何时候添加一位合作伙伴司机。

当司机拒绝(或取消)预先派单调度的服务请求，计算机系统100将配置为使用微调度系统和/或程序，在该系统中，取消请求的司机可将服务请求转给其合作伙伴司机。如果该合作伙伴司机正在工作并接受请求，只要其不在客户黑名单上或不在司机黑名单上，则计算机系统100向该合作伙伴司机调派该服务请求。如果，例如，司机接受了某项服务请求但不能及时赶到上车地点，也同样可以使用这些合作伙伴司机。如果计算机系统100允许根据合作伙伴司机与客户的匹配性发送服务请求，那么该司机可以将服务请求发送给合作伙伴司机。在微调度系统中，每位司机可以有多个伙伴司机。司机可以选择将已调派、但被取消的服务请求转给另一位非合作伙伴司机，计算机系统100可以将该司机取消的请求调派给该位其他司机，只要该位其他司机接受、在上班、并被认为是与客户相匹配(例如，该其他司机不在客户的黑名单中)。

如果司机拒绝调派，则计算机系统100可以在取消的时间段内将司机的状态和服务请求的状态从“已调派”转换为“未调派”，并使用上面讨论的相同标准/算法(步骤680)为服务请求寻找配替代司机并作调派。数据库108中存储的对司机的预先调派将被动态更新并重新调派司机(步骤680)。如果司机拒绝了某个特定的服务请求，那么计算机系统100可以将被拒绝的服务请求添加到工作单库(步骤660)中，或者可以自动将服务请求重新调派给其合作伙伴司机，前提是该合作伙伴司机可用。当司机同意或拒绝调派的全部或部分服务请求时，工作单库可以不断地动态更新。这些更新资料可以存储在数据库108中。

在某些实施例中，可以将计算机系统100配置为：如果司机拒绝任何已作预先派单调度的服务请求或其分行程，则该司机将会失去优先级。基于客户偏好和司机的限制，计算机系统100可快速识别与一项尚未调派服务请求相匹配的司机。例如，一位没有限制的司机和一位没有偏好的客户可以被识别为匹配的。或者，如果任何设置(例如，司机的限制、客户偏好等)彼此冲突，那么司机和客户可能被认为是不匹配的，从而无法匹配。全面披露服务请求细节、司机的限制以及客户的偏好将改善客户和司机的体验。

图7A-7B描述了根据本发明的示例性实施例，调派多个(或批量)预先派单调度服务请求的算法示例。一旦计算机系统100检索出待调派的司机和一批指定日期和地理位置的服务请求(例如，图6步骤630)，调派批量服务请求和尽可能多地对司机调派服务请求的循环过程就此开始(步骤700)。理想的做法是，考虑执行服务请求的潜在司机必须对他/她将接受工作的地理区域预先设置好限制。

首先是识别该批次中未调派的服务请求、相关客户，以及指定时间对上下车地点和/或时间的要求(步骤710)。查阅待调派司机(根据调度员或系统指定的日期和地理区域初步检索出)并排除客户黑名单上的任何待调派司机，排除被司机列在黑名单的任何客户(步骤712)。然后确定是否有可载客的司机可用来服务未调派的服务请求(步骤714)。司机的可用性(可载客)可根据司机预先设定的限制和司机在上述未调派服务请求的上车时间之前的预计位置来评估。例如，司机可以地点X1在时间T赶到地点X2，这是基于历史上该段路程的交通状况以及存储在地图数据326和数据库108中的数据而获得的，但该司机可能对他/她在相应服务请求中分行程之间愿意行驶多远预设了限制。如果系统认为司机不可调派，那么他/她的状态会被设置为“不可用”，并且会被排除在该特定未调派服务请求的可调派司机之外。如果所有潜在司机都不可调派，那么该项服务请求将被发送回工作单库，在该工作单库中，其他可调派的司机可以查看服务请求，并根据本申请描述被其他可调派司机选择。该调派过程将再次开始(步骤700)，识别第二项未调派的服务请求，以及与第二项服务请求关联的客户、地点以及时间的信息(步骤710)。

如果计算机系统100识别到可载客的司机(步骤714)，则确定这些司机是否在该客户的首选清单中(步骤716)。然后确定是否有一个或多个首选司机可调派(步骤718)。如果有首选司机可用，那么就将其调派给尚未调派的服务请求(步骤720)。如果司机在执行先前调派的服务请求时，接收到第二项服务请求的调派，则该司机可能可以接受第二项服务请求，这取决于客户的偏好。例如，预先设置了返回位置的司机可能愿意等待第二个服务请求，因为该服务请求的下车地点和下车时间与该司机的返回地点和时间相符。理想的状态是，计算机系统100可配置成避免空车返回，为司机匹配一位客户，其预设的返回地点和预设返回时间与客户的服务请求相符。

如果有多位首选司机可用，那么计算机系统100可以查阅多位首选司机(步骤722)，以确定其中经验最丰富的一位(例如，先前曾服务于该客户的服务请求数量最多等)(步骤724)。步骤630检索的历史数据可以提供该信息。数据库108中存储的该类历史数据和其他数据能够在本申请披露的流程的各个步骤中进行检索。经验最丰富的首选司机将获得未调派的服务请求(步骤726)。

如果识别了多位有经验的首选司机(步骤724)，计算机系统100即可识别其中哪一位距离最近，即在指定日期的预计地点到达指定日期的客户上车地点的最短的时间(例如，上述有关地点X1,X2和时间Ti和T2的例子)。然后将距离最近、最有经验的首选司机调派执行该未调派的服务请求。一旦将司机调派执行服务请求(步骤726)，则开始处理下一个未调派的服务请求(步骤710)。

如果客户的首选清单中没有待调派的司机，则须确定客户次优选清单中是否有任何可调派的司机(步骤732)。如果有次优选司机可用(步骤734)，则将该次优选司机调派给未调派的服务请求(步骤736)。如果计算机系统100检索识别到多位次优选司机(步骤738)可供调派，计算机系统将根据客户预设的偏好和司机及其车辆各种功能或限制这两者之间的匹配程度确定一位最匹配或最有经验的次优选司机(步骤740)。该最匹配或最有经验的次优选司机可以调派执行服务请求(步骤742)。可使用历史数据根据先前为客户执行的服务请求的总数确定这些次优选司机中对客户最有经验的司机。

客户的预设偏好和司机的预设偏好/限制，这两者之间的匹配特征可包括，例如:汽车类型、汽车大小、颜色、品牌、型号、双门、四门、司机国籍、驾车年数、车辆类型、品牌及型号、载客人数、车辆内部空间、载重量、轮椅提供、婴儿座椅设置、宠物设备、司机语言能力、司机性别、驾驶经验、司机对路线的熟悉程度、司机处理某类货物的经验、易碎货物或需要其他特殊包装或运输方式的货物的安排，或任何其他属性或偏好。匹配的这些属性的数量可以作为将次优选司机调派给未调派的服务请求的基础，而不是该次优选司机前几次载运客户的数量。用于选择多个可用次优选司机之一的标准或算法可以使用这些概念的组合。例如，与客户最为匹配的首选司机应优先调派请求，然后是先前为客户服务次数最多的那位，再后，如果两位或两位以上的次优选司机同样根据这些标准被视为匹配，根据地点和时间预计最近的那位可得以调派。

当没有首选或次优选的司机可供调派时，未调派的服务请求可被调派给一般司机(步骤744)。计算机系统100首先评估是否只有一位司机可调派，或者是否有多位司机可调派(步骤746)。如果只有一位一般司机可供调派(步骤746)，则将该一般司机调派给未调派的服务请求(步骤748)。如果有多位次优选司机(步骤746)可供调派，则计算机系统100可查阅可用的多位一般司机(步骤750)并确定一位最匹配的或者最有经验的一般司机(步骤752)，再基于客户预设的偏好和司机和他/她及其车辆各种属性或限制的匹配的数量之间选择他/她。该最匹配或最有经验的一般司机将调派给未调派的服务请求(步骤754)。也可使用历史数据根据以前为客户或特定区域内执行的服务请求的总数来确定这些一般司机中对客户最有经验的司机。须注意的是，该司机的一个预设限制(或客户的偏好)可能会阻止在任何步骤将司机调派给特定的服务请求。如果由于任何原因，没有一般司机可用(步骤744)，则计算机系统100可以将未调派的服务请求放入工作单库(步骤716)。

如果剩余的多个一般司机中有两位或以上司机之前为客户执行了相同数量的服务请求，则计算机系统100可以根据一般司机从他/她的预估位置到服务请求的上车位置的最短预计时间来确定最近的司机。计算机系统100可以为未调派的服务请求调派最接近和最有经验的一般司机(步骤754)。一旦有一位司机被调派执行请求(步骤748或754)，将处理下一个未调派的服务请求(步骤710)。

在优选实施例中，如果客户有多位首选司机和/或多位次优选司机，则客户可选择预设其首选司机和次优选司机，并为每位首选司机和次优选司机设置特定的层级。司机也可为首选或次优选的客户预设特定的排名。例如，如果一个客户的首选清单中有4位首选司机，则该客户可针对其4位首选司机分别预设排名1、2、3和4。客户还可以预先设置给予两个或多个司机同样的首选排名或次优选排名。因此，可以理解的是可以有多个排名方案。第一种场景，可预先设置分类(首选、次优选)，但对分类的首选和次优选司机/客户不做任何排名。第二个场景，预先设置司机/客户的分类和排名。第三种场景，预先设置司机/客户的分类和排名，但一类中的两位或多位司机/客户排名相同。第四种场景，由客户指定司机的分类和排名，但是司机只对客户分类而不排名，等等。如果有多位排名排名相同的首选或次优选司机可用，则系统会将排名相同的服务请求随机调派给其中一名司机，或者使用在本申请中讨论的其他实施例中的标准进行调派，如先前为客户服务过的服务请求的数量、对线路熟悉程度，等等。因此，可以将系统配置为在调派服务请求时首先查看客户可用的首选司机，然后按首选司机级别进行调派(如果确定了多位首选司机)，而不考虑哪位首选司机是最有经验的或最接近的。如果没有可用的首选司机，则系统可以类似地按次优选司机的级别调派。通过这种方式，客户可以明确其所想要的司机的调派等级结构。

该系统还可以配置为在进行任务调派时，考虑到司机对其首选或次优选客户清单上的客户的分类和排名。换句话说，司机对客户的排名和客户对司机的排名可用于对客户的服务请求进行匹配的一部分匹配标准。然而，由于司机通常想要尽可能多的业务，客户的偏好将在首选实施例中优先考虑。系统在向司机调派客户服务请求时，可以使用所有预设的信息。所有预设数据都可以通过一个或多个门户网站或计算机设备来完成(例如130ci-130cn,132di-132dh)。如果客户或司机没有完成设置，则可以选择使用默认设置，或使用其他设置。

如果在指定的调派日期，特定首选或次优选司机不可用或其取消了服务，客户还可以预先设置是否允许将合作伙伴司机调派执行服务请求。合作伙伴司机将结合图9进一步描述。如果客户不希望任何合作伙伴司机处理其请求，那么系统可以使用优先级排名，或使用图7A-9中描述的算法来循环筛选首选和次优选司机。当被调派的司机(例如，首选或次优选)取消服务或不可用时，如果客户希望伙伴司机处理其服务请求，则系统可指定一位合作伙伴司机，条件是该合作伙伴司机不在客户的黑名单上，或因未能满足客户的其它服务请求或偏好要求而被排除。客户可预先设置合作伙伴司机的层级结构，通过这个层级结构，可以将合作伙伴司机纳入预先处理的服务请求的调派中(例如，系统是否查看下一个最高级别的首选司机，还是首选司机的某个特定级别的合作伙伴司机)。如果客户没有预先设置某些标准，则可以使用该类算法的默认设置。因此，本申请披露的合作伙伴司机方法不仅可以用于预先派单调度实施例中(当被调派的司机取消、拒绝服务请求或无法执行请求时，或者当客户改变服务请求，如图9)，并且可以用于对单个服务请求或一批服务请求中的多个服务请求的初始预先派单调度。

当本申请中描述的两位或两位以上的司机相互合作时，这种合作就创建了一个微调度系统，它减轻或消除了传统的人工调派。该微调度系统使用计算机设备(司机设备132、调派员设备136)，通过服务器102和网络124动态连接并更新总调度系统100。当服务请求在合作伙伴司机之间发送时，所有客户和司机偏好和限制仍然适用，因此当服务请求不能在合作伙伴司机之间发送时，可以将服务请求按照以上偏好和限制发送到工作单库，或者按照本申请披露的任何其他方法进行处理。

图8基于本发明的各种示例性实施例描述了调派多项服务请求的第二种算法。如图所示，在使用客户首选和次优选清单之前，可以使用一种对客户偏好和司机限制匹配进行优先排序的算法。一旦针对指定的日期和地理位置检索出潜在的多位司机和一批尚未调派的服务请求(见图6，步骤630)，计算机系统100则开始将该批次中未调派的服务请求调派给尽可能多的司机的循环操作。可以理解的是，除了使用其他匹配标准，系统可给予首选和次优选分类一个加权排名(而不是像某些实施例中所述的先看分类和排名，再看匹配特征，系统可预设在匹配标准计算中给予匹配分类一个加权值用于确定最佳匹配司机)。

计算机系统100可识别一批服务请求中的一个未调派的服务请求，包括任何与客户有关的相关信息、上下车地点/时间等(步骤810)。根据指定日期和司机限制所指定的地理区域检索第一组潜在的司机，如果这些司机出现在客户的黑名单上或客户黑名单上则被排除(步骤812)。下一步，步骤剩余的潜在司机是否可用(例如，基于时间、位置等，(见图7A-7B))(步骤814)。如果某位司机不可用，那么他/她的状态将被设为“不可用”，并被排除在第一组潜在司机之外。如果第一组潜在司机都不可用，那么服务请求被发送到工作单库(步骤816)，工作单库其他可用司机可以查看和选择该服务请求。然后，识别该批服务请求中的第二个未调派的服务请求，识别与该第二服务请求相关的客户地点和时间信息，该过程继续，直到该批次所有服务请求被调派，而任何未调派的请求被发送回工作单库中。

如果确定有潜在的司机可用，则计算机系统100可以查询这些司机是否可供调派(步骤815)(例如，是否有任何客户偏好或司机限制阻止将服务请求调派给这些司机)。如果发现至少有一位司机可调派，计算机系统100将查询是否只有一位，还是有多位可用的和可调派的司机(步骤818)。如果只有一位司机可用并可调派，则将该司机调派给该服务请求(步骤820)。接着系统识别下一位未调派的服务请求以进行处理。

如果确定有多位可用的和可调派的司机，则计算机系统100可根据与客户偏好匹配的特性来确定每位司机的匹配因素(步骤822)。在某些实施例中，该类匹配因素可能优先于司机是否在客户首选或次优选清单中。基于客户信息和司机个人资料信息，系统100排除一位或多位司机，因为这些司机基于服务请求、客户偏好和/或司机限制其中的一个或多个方面而被认为与客户的匹配度不够。这些方面或匹配因素可以由客户按照其希望的优先级进行排序。系统可提供一种处理功能，将与该类偏好、限制和/或服务请求需求相关的不同变量/特性指定不同的优先级进行处理。该匹配标准可根据在美国专利申请第15/239,783号中披露的实施例来使用。该专利申请题为“即时叫车服务订制服务的方法和系统”(“783专利申请”)，其内容通过引用的方式并入本申请中。

计算机系统100可确定是否存在最匹配司机(例如，具备最高匹配因素的司机(步骤824)，并将服务请求调派给最匹配的可调派司机(步骤826)。然后识别另一个服务请求进行处理(步骤810)。如果系统确定了多位匹配司机具有最高匹配因素，但匹配程度相等或基本相等，则计算机系统100可根据地点和时间估算出其中哪位司机最为接近服务请求的上车地点(步骤828)。然后计算机系统100将服务请求调派给匹配因素最高的多位司机中最接近的一位司机(步骤830)。之后计算机系统识别下一项未调派的服务请求(步骤810)。

图9根据本发明的各种实施例描述使用合作伙伴司机和即时叫车服务方法对检索出的一批服务请求进行预先派单调度和重新调派的流程图。使用本申请讨论的算法或标准之一(例如，图7A，7B和8中显示和讨论的算法)，计算机系统100在2017年8月15日可对一批指定日期例如，2017年8月18日的服务请求进行预先安排(步骤90)对司机进行预先派单调度。在该例中，从2017年8月15日至2017年8月17日，理想的做法是：计算机系统100在司机接受/拒绝调派给他们的服务请求时动态更新和完成对该批次的司机调派工作，而计算机系统100将按照本申请所讨论的各种实施例重新调派服务请求(步骤902)。然后在指定的调派日期(如2017年8月18日)收到与该批次特定服务请求Xc相对应的客户通知，表明该客户需要将该服务请求的上车时间从下午2点更改为下午5点(步骤904)。可以理解的是，客户可能还希望进行其他更改，例如，上车地点或与之相关的服务请求或客户偏好等。

在收到客户对服务请求的更改要求后，计算机系统100将该请求Xc通知已调派的司机(步骤906)。客户可直接与该被调派的司机沟通以请求更改。例如，这种沟通可以直接在相关的客户设备130C1…130Cn、司机设备132D1…132Dn、服务提供者设备126、管理员设备134、调派员设备136或前述任何组合之间进行。被调派的司机将收到提示询问其是否接受对服务请求的更改(步骤908)。可以理解的是，司机接受该更改的服务请求可能会导致和该司机的其他服务请求相冲突，且计算机系统100可被配置为允许被调派的司机接受更改后服务的请求，无论其是否影响以后的服务请求；或者，计算机系统100可被配置为防止司机接受上述更改，并重新调派另一位的司机，如合作伙伴司机，来执行该服务请求。或者，如果预计这种更改只会对后续服务请求造成少许干扰，则允许司机接受这一更改。如果被调派的司机接受更改(步骤908)，计算机系统100则将该服务请求调派给同一位司机(步骤910)。

如果被调派的司机不接受更改(步骤908)，则计算机系统100可识别被调派的司机是否有合作伙伴司机(步骤912)。如果有的话，计算机系统100可基于他们的当前或预计位置、任何潜在的冲突如黑名单，或任何其它限制项和客户首选项之间的冲突等确定这些伙伴司机是否可以提供服务(步骤914)。当一名或多名合作伙伴司机可用时，计算机系统100将向可用的最匹配或距离最近的合作伙伴司机发送请求(步骤916)。距离的远近可通过使用历史和最新的交通和地图数据326来确定。匹配性可基于首选清单、次优选清单或匹配标准，以及本申请所述的客户偏好和司机限制来确定。合作伙伴司机回应其是否接受拒绝请求(步骤918)。如果接受服务请求Xc，计算机系统100将该服务请求重新调派给合作伙伴司机(步骤920)。如果拒绝，计算机系统100可自动将合作伙伴司机(步骤922)的状态从“可用”切换到“不可用”，并再次查看是否有任何其他可用的合作伙伴司机(步骤914)。

当没有可用合作伙伴司机时(步骤912、914)，计算机系统100可使用客户偏好、司机限制和其他匹配标准识别至少一位最佳匹配的可用司机(步骤924)。当预先安排的服务请求规定的上车时间越来越近时，一旦出现问题(例如，最后一分钟司机取消或客户更改，或服务请求仍未调派)，计算机系统100可按照“783申请”中说明和描述的各种即时叫车服务实施例进行操作。

基于客户偏好和司机限制之间的匹配，以及基于地点、时间和预设限制(如果有的话)的司机可用性来识别最佳匹配的可用司机。计算机系统100可自动地，周期性地追踪，客户设备103C1……130Cn和司机设备132D1…132Dn的地理位置，并结合交通流量和地图数据326和司机位置数据324，识别那些可以完成服务请求的司机。数据库108可动态更新客户设备103C1…130Cn的地理位置、司机设备132D1…132dn、工作单库716/816，电子地图1000，以显示客户和司机的预设、设置、偏好、限制、反馈或其他信息的变化，促进提供优质服务。在识别至少一位最佳匹配的司机的过程中，基于客户偏好和司机限制矩阵可将服务提供者(例如，司机)和客户进行适当匹配，并可提高效率，同时继续迎合客户的个人偏好。考虑到客户的偏好和司机预设的限制，在对服务请求进行预先派单调度和提供即时叫车服务时，可以为双方提供私人订制的体验。

反馈可包括正面、中性或负面反馈。正面反馈和负面反馈可根据对服务提供者的绩效的评估，分别以预先设定的正面/负面原因的形式提供。评估可以由客户提供，也可以由最佳匹配的服务提供者提供，两者可进一步选择将对方添加到首选清单或黑名单中。中性反馈或无反馈不会影响客户与服务提供者在未来调派服务请求时的匹配。服务提供者和客户可以相互出现在对方的首选清单或黑名单中，但不能同时出现在对方的黑名单和首选清单中。客户可以在黑名单中添加一个或多个实体，也可将与该实体有关的所有服务提供者都添加到黑名单中。

另外，也可通过预设的负面原因提供负面反馈，将客户列入服务提供者的黑名单，对客户进行匿名评分。负面原因可包括不卫生，未出车，噪音大，言语或肢体虐待，拒绝付款或其他类似原因。同样，也可以通过将服务提供者置于客户的黑名单中，通过匿名对服务提供者评价的方式提供负面反馈。这里，负面原因可包括没礼貌、言语或肢体虐待、车内凌乱、驾驶技术差、对街道不熟悉、不能遵照客户指示、货物处置不当、损坏或丢失、交货延误或其他类似原因。在提供负面反馈后，客户和服务提供者可能会在一段时间后才收到通知，告知其收到了负面反馈和/或收到这些反馈的原因。基于这些负面反馈，客户和/或服务提供者可能被暂停提供该项服务。

计算机系统100可向客户显示一组最匹配的司机(如司机1、司机2、司机3、司机4等)，并通过指示符表示每位司机的详细信息(步骤926)。这些信息可包括与客户的距离或时间、路线信息、对路线的熟悉程度等。还可使用一组指示符，方便客户从系统提议的一组匹配司机中，有效地为其服务请求选择一位最佳匹配司机。系统收到客户选择，确定最匹配的一位司机(步骤928)，并通知该司机(步骤930)。系统询问所选的最佳匹配司机是否愿意接受服务请求(步骤932)。如果被选中的司机不接受服务请求，则计算机系统100则基于客户偏好、司机限制和其他匹配标准识别另一位最佳匹配的可用司机(步骤924)。如果被选择的司机接受服务请求，计算机系统100将服务请求Xc重新调派给该被选司机(步骤934)。

可以理解的是，在某些首选实施例中，本申请所介绍的概念可根据需要以各种组合的形式使用，以便在下述各种情况下，使用各种匹配算法为客户和司机订制预先派单调度服务：单个客户的单个服务请求、单个客户的多个服务请求、或分派给一个或多个司机的多个客户的多项服务请求，服务请求发生于指定调派日期之前，或于指定调派日期当天。此外，本申请所披露的预先派单调度方法可以与即时叫车服务结合使用，并且该系统可以根据情况在预先派单调度和即时叫车服务调派之间进行切换，反之亦然。例如，客户可能会向系统输入单个服务请求，并收到最佳匹配司机清单和一组对应于每位最佳匹配司机的指示符，这是基于客户有兴趣查看的司机的特定信息(例如，匹配司机特征、对某特定路线的熟悉程度和经验等)，选择一个或多个最佳匹配的司机来执行服务请求。或者，客户可能会收到被调派司机在最后一刻取消服务的通知，并可从最佳匹配的司机清单中重新进行选择。同样，例如，如果一位客户选择了即时叫车服务，但突然获悉其医生将晚到，需要取消即时叫车服务请求且需要请求在数小时后甚至另一天的服务，系统可从即时叫车服务方法切换到预先派单调度方法。

可以理解的是，系统预设的客户和司机信息越多，系统可可以更好地订制预先调派人员、越能减轻或消除人工调派(如提供自动化订制调派)，为系统的所有用户提供更多的信息和选项。客户可以选择性地预先设置一个或多个匹配标准，这些匹配标准用于将司机调派给不同的服务请求，或者干脆不设置任何标准，只设置服务请求本身的要求(例如，上车时间、下车时间、日期和位置)。

此外可以理解的是，合作伙伴司机首选的地理区域可能与推荐他/她的司机所在的地理区域不同，因为合作伙伴司机系统的目的是最大程度减少调派。例如，如果司机取消了服务请求，那么他/她可以按下一个按钮，看到其合作伙伴司机的当前状态和他们各自的位置，向其中一个合作伙伴司机发送建议或通知。然后，如果系统允许的话，合作伙伴司机可以接受请求(例如，如果系统确定该服务请求的合作伙伴司机和客户不在彼此的黑名单上，或者没有其他预先设置的标准或原因排除两者的匹配)。该功能可使得司机即便在最后一分钟不得不取消服务时，仍然有办法保留该业务，使客户满意。

本申请所述的“可用”和“不可用”是指司机在某一特定日期是否有空以及该司机能否在某个规定日期时间抵达某一特定的上车地点，基于下述两条确定司机的可用性：(1)预计司机在指定日期和时间所在的位置(2)根据已知交通状况及地图数据，预计司机到达上车地点的时间。可以理解的是，系统可被配置为灵活确定司机是否“可用”，因为司机可以为了提供服务而作出调整，与客户配合，安排适合的上车时间或地点。客户可在系统中预先设置这种灵活性(例如，可以接受比要求的上车时间晚半小时到达该客户地点的首选司机)。

在某些实施例中，系统于指定日期预先安排多项服务请求，每个司机对接收工作单的地理区域和时间段的偏好预先加以设定，以及有关其在首选的地理区域内的地理位置的限制，或有关司机首选的时间段的限制。例如，如果司机在系统中预设特定地理区域(例如，在地图界面上点击和/或放大地图上的某一特定地理区域)，那么他/她可通过系统接收多个需要预先派单调度服务的请求，每个服务请求都包含该地理区域内的一个上车和下车地点/地点。如果该司机不希望在该地理区域内提供服务，他/她可通过手动输入或单击地图显示界面在系统内指定这些限制。如果在某个特定的时间段内，该司机更愿意在他/她预先设定的地理区域内接受工作，那么该司机可在系统中预设该特定的时间段偏好。如果司机不希望在指定时间段内(例如，在午餐时间或白天的私人约会期间)接受工作，那么该司机也可在系统中预先设置该时间限制。通过这种方式，系统可以准确、高效地对多个服务请求进行预先派单调度。可以理解的是，对于单个预先派单调度服务请求，并不需要提供客户和司机在时间和地点方面的偏好，因为在日程安排上有更大的灵活性——司机可以由客户单独通知和/或选择。因此，司机对地理区域和时间的偏好可作为一项选择预先加以设置，但是在某些实施例中，这些偏好是必须预设的，这是因为需要考虑在指定日期调派多个请求。当系统中包含司机预设的对于地理区域的偏好数据时，其可更有效地调派多项服务请求，因为大多数服务请求将会分布在司机指定的特定地理区域内(例如，在曼哈顿、皇后区、布鲁克林，第30街和90街之间，等等)。

在某些实施例中，系统可基于其配置执行的预设数据和算法来将工作单库中的服务请求推荐或通知给那些系统认为匹配的司机660、716。例如，系统可能会向那些状态突然变为可用和/或进入特定地理区域和/或满足客户匹配标准的司机推荐工作单库中的服务请求。系统可以给司机一个预定的接受时间。如果该司机不接受，则系统可将该可用的服务请求通知其他司机等。在其它一些实施例中，系统会把即将被置入工作单库中的服务请求通知给司机(也可能因为某位已被调派的司机取消服务、或者因为基于预设的偏好使系统无法对服务请求进行预先派单调度)，并使司机得以在服务请求置入工作单库之前选择该服务请求，和/或修改他们预设的偏好和限制。司机一般会接受推荐的服务请求，因为一旦将其置入工作单库，如果另一位司机选择该请求，先前该司机对该服务请求的专有权将会丧失。在某些实施例中，可以将系统配置为对工作单库中的服务请求执行更具包容性或限制性更小的算法(例如，消除一个或多个标准或减少其权重)，以便能识别先前未能识别的潜在司机。更具包容性的算法将减少对任何与可用性相关的预设限制。例如，熟悉某个地理区域的司机能够在相对较短时间内处理服务请求，并可与客户联系，就不同的上车时间达成一致。这种联系可帮助解决调派问题。

还应理解的是，系统的新客户，或想在新的地理区域获得服务的现有客户，可能在新的地理区域内没有首选或次优选司机。因此，在某些实施例中，系统可根据，例如，司机对给定路线的熟悉程度和/或司机通常在该地理区域内执行的服务请求的数量，向客户推荐司机。所有数据都可以从数据库108中检索和分析，并在客户和司机更改其预设选项时以及在完成服务请求以后通过系统进行动态更新。

在首选实施例中，数据库108可针对以下各信息进行动态更新：司机位置数据324、交通状况及地图数据326、工作单库660，716、地图显示数据1000。而当服务请求开始、完成、更改、选择、取消、调派时，任何客户设备130ci-130cn和司机设备132di-132dn上的用户界面可进行实时动态更新。

在某些实施例中，可使用本申请所述的司机最佳匹配步骤来为客户安排服务请求，并结合图5所述的价格谈判步骤。客户查看最佳匹配司机清单及与特定司机相关的指示符，并选择一位或多位司机进行价格协商。

可以理解的是，此中所披露的指示符组合可帮助客户评估供求因素，这可能是客户设置价格，进行谈判价格的关键，因为客户可能在需求较低时设置较低的价格，也可在需求较高时设置较高的价格。在数据库108中，可动态更新可提供服务的可用服务提供者的数量和当前在特定区域请求服务的客户数量。任何提供与客户服务请求中请求的服务类型相同的服务提供者都可包含在潜在可用服务提供者库中，只要该服务提供者位于该地理区域内且可用。客户可通过客户设备130打开或关闭显示给客户的各项指示符。如果客户关闭了一组指示符，那么他/她将不会在他/她的显示器上看到这些指示符。然而，系统仍将客户的服务请求算在相应子类别的所有可用服务请求中。

各种指示符可通过司机设备132显示给服务提供者(例如，司机)，这些指示符便于司机基于各种类型的客户信息为服务请求设置价格。在某些实施例中，服务提供者可能希望查看并获得显示给客户的相同搜索结果或供求信息。在某些实施例中，系统可能允许客户和服务提供者交换显示给他们的全部或部分信息，这些结果和信息使协商过程更加透明。可以理解的是，向司机提供代表客户特性的指示符，不仅用于价格谈判，而且用于本申请讨论的各种其他实施例。例如，当司机需要评估是否要从工作单库中选择某个工作单，或者是否要接受某个新的服务请求时，该系统可配置为使该司机能够访问与服务请求相关的客户信息，并查阅与所需客户信息有关指示符。通过这种方式，司机就可以在知情的情况下步骤是否接受服务请求。

根据本发明的示例性实施例，系统可使用一组指示符来帮助简化服务提供者对客户的提议价格做出的回应价格信息，便于客户与多位最佳匹配的司机同时协商价格。在某些实施例中，当客户发送不含报价的服务请求时，服务提供者以提议价格(可协商或不可协商)进行回应时，系统可使用一组指示符表示由该司机向客户提出的价格。如果提议的价格可协商，则谈判可能会反复进行，直到最后达成一致，或者无法达成一致。

基于某些实施例，根据发起提议价格的一方的不同情况可使用各种不同的指示符。指示符可表示价格是否高于、低于或等于系统提供的默认价格。例如，对于高于默认价格的初始价格，系统可用绿色指示符或向上箭头表示，对于低于默认价格的价格，系统可能显示红色指示符或向下的箭头。与默认价格完全匹配的价格可以用黄色或圆点显示。这三种不同的颜色表达了三种情况下的明显区别，使得用户基于易于辨别的视觉表达方式快速识别。例如，这种表达方法中包括实际提议价格，以及以美元金额或百分比来比较提议价格和默认价格之间的差别。这组指示符可以关闭，也可以根据用户的判断有选择地显示某个或任何部分。在预先派单调度服务请求期间，如果未就最终价格达成一致，则系统可配置为暂停协商，或允许客户选择在服务请求的日期和时间之前继续协商。用户还可通过设置高于或低于默认价格的价格阈值来设置自动拒绝价格提议的限制。在理想的情况下，这些指示符将同时显示给客户和服务提供者。可以向系统中的任何用户类型显示各种指示符。向服务提供者请求价格提议的客户可以在设置中预先设置不查看高于或等于默认价格50％的任何价格提议。否则，自动拒绝价格提议。客户可根据价格差异自行选择要查看的价格指示符。

还可以为客户显示一个指示符，该指示符可根据服务提供者在客户指示的服务请求上车地点地理区域内完成的服务请求总数反映有关区域信息。该指示符可代表从数据库108检索到的历史数据。可以理解的是，该指示符可为客户提供一种直观的表达方法，迅速传达服务提供者在上车地点的经验或熟悉程度。这些信息可帮助客户了解，哪个服务提供者在该地理区域有更多服务经验，更适合他们的服务请求。

还可使用一组指示符显示每个地理区域内的潜在可用服务提供者的数量与潜在可用客户数量的对比，显示潜在可用服务提供者库和潜在可用客户库，以及基于下述搜索参数的地理区域，这些参数包括：数量、时间和距离或这些参数的任意组合。该组指示符可根据搜索参数提供有关每个地理区域内的供应和需求的信息，可将这些参数考虑到定价中。在某些实施例中，服务提供者还可将其显示限制为仅显示来自首选客户、次优选客户、一般客户或新客户的请求。

还应理解的是，本申请披露的系统和方法的各种实施例基于以下原因大大减少或消除了人工调派：使用计算机设备和一个或多个远程计算机设备经过动态部署相关信息提供自动化调派，使得客户、司机以及调派员可以更好的沟通，启用全面调派服务，包括预先安排服务请求、调派服务请求，动态更新和促进服务请求的更改，并在客户的交通运输过程中向各方提供实时信息。

可以理解的是，此处使用的短语或术语是为了进行描述而非限制。通过各种首选实施例对本发明进行了展示和描述，本领域的专业人士应该理解的是，在不背离权利主张中定义的本发明的精神和范围的情况下可对其进行各种变更和/或修改。这里描述的示例性实施例仅是说明性的，并且可以在不背离此中批露的内容和权利主张的范围的情况下可引入多种变体。例如，不同示例性实施例的元素和/或功能可以彼此组合和/或相互替换。因此，本发明的范围应仅由本说明书后附的权利主张来加以定义，并且对于本领域的专业人士而言，显而易见的是，在不背离本发明的精神和原则的情况下，可在细节上进行大量修改。

Claims (30)

1.提供可订制的预先派单调度的计算机实施方法，该方法包括：

通过一台或多台计算机设备从客户那里接收服务请求进行预先派单调度，该客户至少有一项可选的预设服务请求偏好。所述服务请求包含至少一个车程，该车程至少包括下述中的一项：上车时间，上车地点，下车时间或下车地点，而所述“至少一项可选的预设服务请求偏好”至少包含司机类型，该司机类型包括：首选司机，次优选司机或一般司机；

通过所述一台或多台计算机设备接收，至少一项司机可选的预设服务请求偏好，该偏好包括可选的预设地点限制或时间限制；

如果基于所述至少一项客户可选的预设服务请求偏好，或基于所述客户的黑名单，所述第一组司机中的至少一个司机不能完成所述服务请求时，自动阻止所述至少一位司机接收所述服务请求；

生成与所述第二组司机中的多个司机相关联的、与服务相关数据相对应的指示符；

向所述客户发送所述至少一个指示符，其中所述至少一个指示符与所述至少一项客户可选预设服务请求偏好相对应；

在至少一个指定日期或时间，步骤所述至少一项客户可选预设服务请求偏好是否与下述中的至少一部分相匹配：

所述至少一项司机可选预设服务偏好；及

所述至少一个指示符；

将所述服务请求调派给所述包含多个司机的第二组司机中的至少一个司机；

向所述包含多位司机的第二组司机中的至少一位司机发送至少一条通知；

从所述包含多位司机的第二组司机中的至少一位司机那里接收其对所述服务请求的接受；以及

在至少一个数据库中动态更新所述服务请求相关数据。

2.根据权利要求1的方法，该方法进一步包括：

当所述服务请求未被调派给所述包含多位司机的第二组司机时，产生至少一项与所述由多位司机组成的第三组司机相关联的、对应于服务相关数据的辅助指示符，所述服务相关数据包含下述中的至少一项：识别状态，可用性，当前位置，返回地点，预计上车时间或熟悉程度；

发送至少一条通知，将所述服务请求调派给所述由多位司机组成的第三组司机中的至少一位司机；以及

从所述包含多位司机的第三组司机中的至少一位司机那里接收其对所述服务请求的接受。

3.根据权利要求2的方法，所述方法进一步包括:

当所述服务请求未调派给所述包含多位司机的第二组或第三组司机时，所述服务请求将被存储于工作单库中，该工作单库可由至少一位或多位可用司机通过所述一台或多台计算机设备进行访问；并且

所述一位或多位可用司机可通过所述一台或多台计算机设备在工作单库中选择至少一项服务请求。

4.根据权利要求1的方法，所述方法还包括：

确定包含所述多位司机的第二组司机是否都不在该客户的首选清单中；

如果所述含多位司机的第二组司机都不在该客户首选清单中，则基于具有一项或多项匹配属性的所述匹配次优选司机，向该客户提供匹配次优选司机，而该匹配属性至少与一项客户可选预设服务请求偏好相匹配；并且

将所述服务请求调派给具有最多所述匹配属性的所述匹配次优选司机，或者基于先前为所述客户执行的服务请求的总数，为所述客户提供最有经验的次优选司机。

5.根据权利要求1的方法，所述方法还包括：

基于至少一项所述司机的可选预设服务请求偏好与所述客户可选的预设服务请求偏好之间的一项或多项匹配属性，当所述第二组司机中没有所述首选司机，或次优选司机，为所述客户确定匹配的一般司机；并且

将所述服务请求调派给所述相匹配的一般司机。

6.根据权利要求1的方法，所述方法还包括：

由所述已被调派的司机发送重新调派请求，将其已接受的服务请求发送给其所述合作伙伴司机；

向所述合作伙伴司机发送一个或多个重新调派通知；并且

接收所述合作伙伴司机对于所述服务请求的接受。

7.根据权利要求1所述方法，其中，所述司机类型包括所述首选司机、所述次优选司机或所述一般司机，而所述首选司机、次优选司机或一般司机按优先级排序。

8.根据权利要求1所述方法，其中通过确定所述服务请求的执行路线与所述第二组司机中至少一位司机相关联的路线数据之间的重叠量来计算所述熟悉程度，所述重叠量可以通过下述中的至少一种方式显示：层级，层级范围，级别，级别范围，分数，分数范围，百分比，百分比范围或任何其他描述。

9.根据权利要求1所述方法，其中所述至少一位客户使用所述至少一种指示符与所述包含多位司机的第一组和第二组司机中的至少一位司机协商与所述服务请求相关的价格。所述指示符与所述含多位司机的第二组司机中的至少一位司机相关联。

10.根据权利要求1所述方法，其中所述至少一种指示符表示下述中的至少一项：司机的用户类型，顾客的用户类型，从所述上车地点到所述下车地点的预计车程，所述司机的可用性，所述司机保持其可用性状态的时长，未调派的服务请求，所述司机的当前位置，所述司机的返回位置，所述上车地点，所述下车地点，价格，所述司机对所述上下车地点之间路线的熟悉程度，所述第二组司机的识别状况，用于执行所述客户的所述服务请求的第二组司机的的可用性，所述第二组司机为潜在执行一个或多个服务请求而保持其可用性的时间，所述第二组司机的一个或多个当前位置，所述第二组司机的一个或多个返程回位置，所述预计上车时间，由所述一位或多位司机执行的服务请求的总数，基于预设搜索参数范围内的潜在可用服务请求的总数与潜在可用客户的总数的供应和需求，所述一位或多位司机在所述上车地点或所述下车地点标识的区域范围内执行服务请求的频率，所述客户与所述一位或多位司机完成的服务请求的总数；

其中所述客户的用户类型或所述司机的用户类型包括以下中的至少一项：首选，次优选或一般；并且

其中所述调派司机至少是部分地基于由至少一种所述指示符提供的信息。

11.一种提供可订制自动预先派单调度的计算机实施方法，所述方法包括：

接收多个服务请求进行预先派单调度。其中所述多个服务请求至少包含一个行程，该行程至少包括下述至少一项：上车时间，上车地点，下车时间或下车地点；

根据所述上车地点或所述下车地点之一所在地理区域对所述多个服务请求进行排序；

将所述多个服务请求存储在一个或多个数据库中；

从该一个或多个数据库中检索：(i)与所述多个服务请求中每个服务请求相关联的客户信息,该客户信息包括至少一项客户选择预设的服务偏好,首选清单,次优选清单或黑名单,(2)一位或多位司机个人资料,所述一位或多位司机个人资料包含司机信息,该司机信息包括一个服务地理区域和至少一项选择预设的服务限制、服务历史、首选清单、黑名单或历史数据，以及(iii)在指定日期指定地理区域内至少包括以下一项:

所存储的多个服务请求中一批服务请求；

与所述一批服务请求，所述包含客户信息的客户个人资料相关联的多个客户对应的多个客户资料信息；或

与所述一批服务请求，所述包含司机信息的司机个人资料相关联的多个司机对应的多个司机资料信息；

基于下述原因排除第一组司机中一位或多位司机(i)与上述服务请求不匹配，(ii)在所述客户的黑名单上，或(iii)该客户出现在该司机的黑名单上；

基于至少一组或多组指示符，使用下述各项生成调度矩阵：所述服务请求,所述客户信息,以及第二组司机中所述一位或多位司机的个人资料。通过所述调度矩阵创建对于所述第二组司机中每位司机的调派优先级；

根据所述优先级，将所述一批服务请求分派给所述第二组司机中每位司机；

根据所述优先级，将所述第二组司机中的一些司机发送给客户计算机设备；

从所述客户计算机设备接收从所述司机组中选出的一位最佳匹配司机；并且

将所述服务请求发送给所述选出的最佳匹配司机。

12.根据权利要求11的方法,所述客户选择预设的服务偏好包括下述中的至少一个:所述客户优先选择其首选清单中的至少一位首选司机,或所述客户优先选择其次优选清单中至少一位次优选司机,以及

所述司机的选择性预设服务限制包括所述司机在其首选清单中对至少一位首选客户进行优先排序；

所述优先排序是在所述客户选择所述最佳匹配司机之前某个时间实现的；所述客户可动态改变其优先次序。

13.根据权利要求11的方法，其中所述调度矩阵提供输出信息以确定所述客户和所述司机之间的匹配程度。所述方法是基于以下因素:所述司机接受所述客户所述服务请求的可用性；所述司机在所述客户的首选清单、所述客户的次优选清单或所述客户黑名单上；或所述司机选择预设的服务限制与所述客户选择预设的服务偏好相匹配。

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

生成一组指示符用于表示至少下述信息：司机的用户类型、客户的用户类型、从上车地点到下车地点预计行驶时间、所述司机可用性、所述司机保持可用性的时间、未被调派的服务请求，所述司机当前位置，所述司机返回位置，上车地点，下车地点，价格，所述司机对所述上车地点和所述下车地点之间路线的熟悉程度，所述包含多位司机的第二组司机的标识状态，所述第二组司机中一位或多位司机执行所述客户的所述服务请求的可用性，所述第二组司机保持可用以便潜在执行一个或多个服务请求的时长，所述第二组司机的一个或多个当前位置，上述第二组司机的一个或多个返程位置，所述预计上车时间，所述一位或多位司机执行服务请求的总数，基于潜在可用服务请求总数与预设搜索参数范围内潜在可用客户总数的供求关系，所述一位或多位司机在所述上车地点标识或所述下车地点标识的区域内执行服务请求的频率，所述客户与所述一位或多位司机之间完成的服务请求总数；其中，所述客户的用户类型或所述司机的用户类型包括以下至少一项：首选、次优选或一般；其中所述被选择调派的一位执行所述服务请求的最佳匹配司机至少部分地基于由所述一组或多组指示符提供的信息。

15.根据权利要求14的方法，所述熟悉程度由下述中的至少一项表示：百分比、层级或其他表示不同熟悉程度的描述方法；所述熟悉程度是通过至少确定所述服务请求的线路与所述第二组司机中的一位或多位司机相关联的历史路线数据之间的重叠度来计算的；所述历史路线数据是在所述一位或多位司机完成所述服务请求时通过对其自动追踪，并将所述数据存储在所述一个或多个数据库而获得的；所述熟悉程度至少包括间接熟悉或直接熟悉。

16.根据权利要求15所述方法，所述方法还包括：

将所述熟悉程度显示为对所述服务请求的所述线路的所述间接熟悉程度，其中共同部分短于所述服务请求的路线；

将所述服务请求的路线与所述第二组司机中的一位或多位司机完成的一个或多个服务请求的一条或多条线路进行比较，识别所述一个或多个共同部分；

将所述第二组司机中一位或多位司机中的每一位司机完成的一项或多项服务请求中的所述一个或多个共同部分进行加总；将所述一个或多个共同部分的总和除以所述服务请求的所述路线的总距离；

将对所述服务请求路线的熟悉程度显示为所述直接熟悉程度，其中所述一个或多个共同部分中的至少一个长于或等于所述服务请求的所述路线。

17.根据权利要求11所述方法，所述地理服务区域可包括邮政编码、市、州、街道、街道组、邻里、区、县或其他区域定义特征。

18.根据权利要求11所述方法，所述方法进一步包括以下步骤：

根据以下一项或多项确定一位或多位司机的优先级：在所述客户的首选清单上并可以接受所述客户服务请求，完成服务请求次数最多，发起的提议价格最低，对所述客户起价的回应价最低，对所述服务请求的所述上车地点的所述下车地点之间的线路最熟悉，在所述上车地点所在地理区域内执行的服务请求次数最多，在所述下车地点所在的地理区域内执行的服务请求次数最多，与所述客户完成的服务请求次数最多，预计到达时间最短，从当前位置到所述上车地点距离最近，预设了返程位置，所述预设返程位置包括在所述一位或多位司机的预计行程时间的计算中，而所述预设返程时间和位置与所述服务请求的所述下车时间和下车地点相匹配；所述优先排序是根据所述可选预设服务偏好来进行的，且在所述客户选择所述最佳匹配司机之前的任何时间；所述客户可动态改变所述优先级。

19.根据权利要求11方法，所述方法进一步包括以下步骤:

使所述司机能够使用交互式电子接口设置至少一项所述地理服务区域或服务时间限制。

20.根据权利要求11方法，所述方法进一步包括以下各步骤:

在司机计算机设备上显示电子地图，所述地图划分为多个可点击的地理区域；

使所述司机能够通过所述司机计算机设备从所述电子地图中选择所述地理服务区域；以及

在一位或多位司机选择所述地理服务区域之一时动态更新所述数据库。

21.根据权利要求11所述方法，所述方法还包括：

当至少有一项所述服务请求未被分派给至少一位所述司机时，生成对应于服务相关数据的与第三组司机相关联的辅助指示符；

当所述服务请求未被分配给所述第二组或所述第三组的多位司机时，所述服务请求将被存储于工作单库中。所述工作单库可由至少一位或多位可用司机通过所述一台或多台计算机设备进行访问；

使所述一位或多位可用司机通过所述一台或多台计算机设备在所述工作单库中选择至少一项剩余所述服务请求。

22.权利要求21中所述方法，所述方法还包括以下步骤：

将所述工作单库中的每个未分配的所述服务请求显示为电子地图显示器上的一位或多个可点击图标；且

当所述一个或多个可用司机在所述工作单库中选择所述服务请求时动态更新所述工作单库和所述电子地图的显示，

所述电子地图被划分为多个地理区域。

23.根据权利要求11所述的方法，所述方法还包括下述步骤：

在电子地图显示器上划分的多个地理区域中显示每个可用的司机；

自动且周期性追踪每位所述可用司机的所述一台或多台远程计算机设备的随时间变化的地理位置；

基于所述一台或多台远程计算机设备的所述随时间变化的地理位置，动态更新所述一个或多个数据库和所述电子地图显示器；

并使所述客户能够从所述地图中选择所述可用司机。

24.根据权利要求11所述方法，其所述可选的预设服务偏好由所述客户提供，并包括与下述一项或多项相关的偏好:车辆类型,车辆品牌和型号,车辆座位数,车辆容量,车辆载重能力,轮椅无障碍设施,婴儿座椅可用性,宠物设施,司机语言能力,司机性别,司机驾驶经验,司机熟悉所述线路程度,司机处理某些类型商品的经验,容纳易碎物品或需要其它特殊包装、交货方式。

25.根据权利要求11所述方法，其中所述可选的预设服务限制由所述一位或多位司机提供，并包括一项或多项个人限制或一项或多项法律限制；

所述一项或多项个人限制包括基于所述地理服务区域的一项或多项地点限制以及与以下一项或多项相关的一项或多项其他限制：到达预设返程地点的预计时间，预计行程时间，预计行程距离，商品类型，商品数量，商品重量，商品尺寸，宠物过敏和宠物设施；

所述一项或多项法律限制与以下一个或多个因素有关：本地法规。这些法规包括基于在所述地理服务区域中提供服务的所述一位或多位司机的非法性的一项或多项地点限制，与下述相关的一项或多项其他限制：服务时间，乘客数量，婴儿座椅可用性和无障碍设施；

如果所述一项或多项法律限制阻止所述一位或多位司机执行所述服务请求，则实施所述一项或多项法律限制以阻止所述一位或多位司机接收所述服务请求。

26.根据权利要求11所述方法，如果选中的最佳匹配司机不能完成所述已调派的服务请求，则所述已调派的服务请求将通过以下方式重新调派给与选中的最佳匹配司机相关联的合作伙伴司机:

将所述已调派的服务请求的重新调派请求发送给所述合作伙伴司机；

从所述合作伙伴司机处接收其对所述重新调派请求的接受指令；

向与所述服务请求相关的所述客户发送所述重新调派服务请求的通知；

并接收所述客户对于所述重新调派请求的接受指令。

27.根据权利要求11所述方法，所述方法还包括以下步骤：

当基于所述偏好识别出不止一位首选司机时，确定最高优先级首选司机，并将所述服务请求分派给所述最高优先级首选司机；

当所述最高优先级首选司机不可用时，确定第二优先级首选司机，并将所述服务请求分派给所述第二优先级首选司机；

当识别到不止一位首选客户时，确定最高优先级首选客户，并将所述司机分派给所述最高优先级首选客户；

当所述优先级首选客户已被分配，确定第二优先级首选客户，并将所述第二优先级首选客户分配给所述司机。

28.根据权利要求11所述方法，所述方法还包括：通过与一台或多台计算机设备相连接的一台或多台显示装置，显示所述一个或多个指示符，所述显示器上的显示可使所述客户能够选择匹配司机，而在所述首选清单上与所述服务请求不相匹配的一位或多位司机则不通过所述一组或多组指示符进行显示，所述一组或多组指示符以不同的方式进行显示。

29.一个用于交通运输服务的可订制的自动化微调度计算机实施方法，所述方法包括:

通过一台或多台远程计算机设备接收含有一项或多项可选的预设服务请求偏好的客户的服务请求以便进行预先派单调度，所述服务请求包括服务请求路线中的至少一段分行程；

将与所述服务请求有关的信息存储在一个或多个数据库中；

至少部分地基于通过一个或多个指示符显示的信息从司机组中选择一位司机接收所述服务请求，并将所述服务请求调派给所述选中的司机；

接收被选中地司机对所述服务请求的接受指令；

在微调度系统中识别与所述选定司机关联的一位或多位合作伙伴司机，所述一位或多位伙伴司机通过所述一台或多台远程计算机设备与所述选定司机进行沟通；

由所述选定司机将所述已接受服务请求的重新调派请求发送给所述已识别的一位或多位伙伴司机中的一位；

向所述已识别的合作伙伴司机发送重新调派通知；

从所述合作伙伴司机处接收其对所述重新调派请求的接受指令；

自动将所述已识别的合作伙伴司机通知给所述客户，并为所述客户提供接受或拒绝所述已识别的合作伙伴司机的选项；

基于从所述合作伙伴司机处接收的对所述重新分派请求的所述接受指令，动态更新所述一个或多个数据库中的所述服务请求相关数据。

30.一个动态和自动更新服务相关数据的方法，这些服务相关数据是在存储与服务器计算机系统上的数据库和至少一台远程计算机设备之间进行交换的，所述方法包括：

在服务器计算机设备上接收来自客户的服务请求，所述服务请求包括至少一个分行程；

在所述服务器计算机设备上一个或多个数据库中存储与所述服务请求有关的服务相关数据；

从一组司机中选择一位司机完成所述服务请求，并自动将所述服务请求调派给所选择的司机；

通过一台或多台远程司机计算机设备接收来自所述选定司机对所述服务请求的接受指令；

识别与所述服务请求相关的第一个更新的服务相关数据，所述第一个更新服务相关数据是在所述服务请求完成之前由所述服务器计算机设备识别的；

用所述第一个更新的服务相关数据动态更新所述数据库；

自动将所述第一个更新的服务相关数据发送给所述司机，通过所述一位或多位司机远程计算机设备显示；

识别与所述服务请求相关的第二个更新服务相关数据，所述第二个更新的服务相关数据在所述司机接受所述服务请求之后由所述司机通过所述一台或多胎远程司机计算机设备识别；

自动将所述第二个更新的服务相关数据发送到所述服务器计算机设备；

用所述第二个更新的服务相关数据动态更新所述数据库；并在显示装置上显示所述第二个更新的服务相关数据。

Images