CN110800007A - 应用地理感知技术进行交通运输结算验证的***和方法 - Google Patents

Abstract

本申请为交通运输服务提供用于自动验证的计算机执行***和方法。该***包括一个或多个数据库，该数据库配置在一个或多个服务器上，通过通信网络与供应商模块、服务提供者模块、司机模块以及非临时计算机可读存储介质进行通信连接，该介质可存储指令，指示一个或多个处理器接收服务请求，生成结算请求，并将服务请求与结算请求进行对比。处理器还可配置为，在生成结算请求时，识别与服务请求相关的司机或乘客是否处于可接受范围内，以便验证服务请求是否完成，或有条件拒绝结算请求。可接受范围可基于收集的数据进行动态更新。

Description

应用地理感知技术进行交通运输结算验证的***和方法

交叉引用相关申请

本申请基于下述两个美国临时专利申请并要求其优先权：2016年11月11日提交的、序列号为62/421,086，标题为“电子结算的方法和***”的美国临时专利申请，以及2017年3月30日提交的、序列号为15/474,685，标题为“应用地理感知技术进行交通运输结算验证的***和方法”的美国非临时专利申请。前述两个专利申请的全部内容通过引用的方式并入本申请。

技术领域

本申请涉及交通运输，具体而言，涉及与提供交通运输服务有关的地理感知验证***和方法，用于进行交通运输服务追踪及电子结算验证。

对相关技术的讨论

全球定位***(GPS)是一种基于卫星的地理定位***，便携式设备可以从GPS卫星获取信号以便对设备的位置进行三角测量。GPS的普及使得该技术获得广泛应用，并导致了交通运输业的革命。

技术的进步，例如全球定位***，造就了叫车服务领域的各种创新。然而，交通运输结算验证，包括但不限于非紧急医疗运输(NEMT)，尚未得到同样的发展，例如，包含用于位置验证的自动GPS追踪功能的追踪和结算***亦如此。非紧急医疗运输通常涉及与医疗有关的非紧急交通运输服务。与其他医疗服务一样，非紧急医疗运输服务通常可向第三方收费，例如医疗保险公司，政府医疗保健部门或代理机构，或代表保险公司或政府机构的代理人。

通常交通运输电子结算验证的一个技术问题是，计算机程序经常拒绝与指定时间或位置不匹配的输入。而这些拒绝往往是随机的。为使所述输入有效，必须使用严格的句法进行输入，而***对于可接受的句法通常过于严格。这将造成耗时的结算拒付纠纷，需要涉及到的一方或多方通过人工操作来解决。

第二个技术问题是，某些编程方式会使计算机***就其可接受的句法过于宽泛，而实际的时间或实际的位置却不合理地偏离指定的时间或指定的位置。这种句法可能与位置输入信息、时间输入信息有关，或者，通常情况下，与这二者的组合有关。如果计算机***对其可接受的句法过于宽泛，那么就计算机验证的目的而言，产生的效果将适得其反，因为如果***在进行验证时过于宽容，将无法实现预防欺诈的目的。

第三个技术问题是，电子结算验证***无法基于可接受的输入进行自行更新，而且就可接受的句法而言，严格和宽泛之间的平衡把握也各不相同。需对那些定义可接受输入的参数须进行专门的编程。事实上，现有***常常拒绝输入值，并且无法自动进行自我校正；在每次需要更新时需重新编程。重新编程极为耗时，且无法对服务变更和实际情况作出动态响应。例如，当把病人送到指定地点时，诸如建筑工地或其他障碍物可能会影响将病人下车的确切地点。因此，当实际目的地偏离医疗服务地点时，现有的电子结算验证***将拒绝合理的付款要求，尽管下车地点可能是司机所能到达的最近地点。

现有的电子结算验证***要么过于严格，要么过于宽泛，或者无法进行频繁更新，所以无法接受交通运输服务的付款要求。虽然交通运输结算在很大程度上已过渡到电子结算验证，但向电子结算验证过渡的过程仍面临很大障碍，技术进步很大程度上忽视了相关的问题。本申请说明的基于前述技术的验证功能提供了技术解决方案，通过建立“可接受范围”验证是否提供了服务，或者结算请求中的时间或位置偏差是否由合法或合理的原因造成的。可接受范围在过于严格的***和过于宽松的***之间提供了一种平衡。

概述

本概述并非旨在识别或指出本申请所述主题的基本特征或对其范围进行限制。下列描述包含一个用于在验证结算请求时建立和更新可接受范围的计算机执行***和方法。***至少包括一个或多个服务器、一个或多个地理信息***(地理信息***)以及一个或多个数据库，数据库通过网络连接到司机模块，进一步包括至少一个地理位置识别器、一个地理感知相机、和一个用于识别当前时间和日期的时钟。该***还包括至少一个非临时性计算机可读存储介质，该介质存储指令以通过程序执行任务。这些任务可通过一个或多个服务器进行配置，包括接收结算请求及其相关数据。

可接受范围是由***建立的，用于进行交通运输服务验证，其中预先确定的规则可用于控制接受范围参数，确定司机在相关的点是否处于可接受范围内。一旦经过确定即可判断司机是否有资格就结算请求中提到的服务获得付款。如果司机在可接受范围内，可对生成的结算请求进行自动调整，以便与接收到的指定信息进行匹配，这样***就可以接受该结算请求。如果司机不在可接受范围内，***会提示其提交一个或多个原因和/或包含地理位置和时间数据的照片。该信息可用来验证司机无法到达可接受范围的理由，并可通过用户参与板块提供。用户参与板块是一个用户界面，可用于从一个或多个用户那里收集一个或多个评价，让用户参与验证司机所提交的信息。有第一手经验的用户可查看司机提供的信息，包括一个或多个理由，以确定司机的理由是否合理。这就是对司机提交信息进行评价的过程。

用户参与板块上提供的那些得到一定数量正面评价的信息将用于对数据库进行动态更新、纠正和补充。此外，控制可接受范围的预定规则在一定程度上与用户参与板块相关联，收集到的数据将用于动态更新这些预定规则。

在某些实施例中，为交通运输服务提供自动计算机验证的计算机实施***包括一个计算机***，该***包括一个或多个数据库，这些数据库位于与通信网络连接的一个或多个服务器上，***还包括供一个供应商模块，该模块配置为发送为乘客提供服务的服务请求。该服务请求包括至少下述中的一项：上车时间、上车地点、下车时间或下车地点。***还包括一个服务提供者模块，该模块配置为接收来自供应商模块的服务请求，将服务请求分配并发送给司机。该***还包括一个司机模块，其配置为接收服务请求、生成结算请求，并将结算请求发送至服务提供者模块，以及包含一个非临时计算机可读存储介质，该存储介质能够存储用于指示一个或多个处理器的指令。处理器被配置为由服务提供者模块通过计算机设备，从供应商模块接收服务请求，并由服务提供者模块将服务请求发送到司机模块，由司机模块生成结算请求，并将服务请求与结算请求进行比较。处理器被配置为在结算请求生成时识别司机或乘客是否处于可接受范围内。基于所识别的司机或乘客是否处于可接受范围内来确认针对乘客服务请求提供的服务是否完成。可接受范围基于一项或多项预定规则，这些规则至少具备下述特征之一：(i)离上车地点的预定距离，(ii)离距下车地点的预定距离，(iii)相对于上车时间的预定时间，或(iv)相对于下车时间的预定时间。

在某些实施例中，为交通运输服务提供自动计算机验证的方法包括由服务提供者模块通过多个计算机设备中的一个，从供应商模块接收服务请求，将服务请求调派给司机，并由服务提供者模块将服务请求发送至司机模块，由司机模块生成结算请求，将服务请求与结算请求进行比较，并在生成结算请求时确定司机或乘客是否处于可接受范围内。可接受范围基于一项或多项预定规则，这些规则具有下述特征之一：(i)与上车地点的预定距离，(ii)与下车地点的预定距离，(iii)相对于上车时间的预定时间，或(iv)相对于下车时间的预定时间。该方法还包括基于识别的司机或乘客是否处于可接受范围内，确认服务请求是否完成。

图表简介

通过参考附图中所述的优选示例性实施例，可对本发明有进一步了解。附图的目的并非旨在限制本发明的范围，本申请后附的或之后修改的权利要求书对本发明的范围进行了限定，附图仅是为了描述本发明并对其举例说明。当参考下述详细说明并结合附图时将很容易对本发明及伴随的各个方面有更为全面的理解：

图1A示意图描述用于电子结算验证和司机追踪的，与一个或多个服务器通信的***组件；

图1B示意图进一步描述电子结算验证和司机追踪***组件；

图2A描述对结算请求进行调整的示例性工作流程图；

图2B描述基于地理位置调整结算请求的方法的流程图；

图2C描述基于时间调整结算请求的方法的流程图；

图3A流程图描述建立和更新可接受范围的方法；

图3B流程图描述在某些情况下建立临时可接受范围的方法；

图3C流程图描述更新临时可接受范围的方法；

图4A示意图描述基于距离的可接受范围的应用示例；

图4B示意图描述基于距离的可接受范围的应用；

图5示意图描述由缓冲区及其中的地理位置坐标建立的可接受范围；

图6示意图描述司机在其计算机设备上可能收到的信息，如果该司机未能到达基于距离的可接受范围内，但又试图提交结算请求的话；

图7示意图描述司机可能在用户参与板块上提交的有关其无法到达可接受范围范围内的一个或多个理由；

图8示意图描述司机在其计算机设备上可能收到的信息，如果该司机无法到达基于时间的可接受范围的话；

图9示意图描述司机计算机设备上的界面，用于输入一个或多个无法到达基于时间的可接受范围的原因；

图10示意图描述用户参与板块上显示的界面；

图11示意图描述有关基于距离的可接受范围的数据库表，描述如何在结算验证***中收集数据，并在用户参与板块或服务提供者模块向服务提供者显示；

图12示意图进一步描述用户参与板块界面，该界面显示有关结算请求的全面信息，该信息可在服务提供者模块上进行访问；

图13示意图描述与基于时间的可接受范围相关的数据库表；

图14示意图描述存储在数据库中的数据以及数据的组织方式；

图15示意图描述由地理信息***执行的潜在地理编码处理功能。

详细说明

在描述本发明附图所述的示例性实施例时，为清晰起见，使用了特定的术语。但是，这里对本发明的批露并非旨在局限于此中所选择的特定术语。应当理解的是，每个特定的要素或这些要素的组合包含了所有以类似方式运作的技术对等物。

本领域的普通技术人员应理解，本发明的示例性实施例还支持车载结算验证计算机设备，用于自动传送和/或提交带有时间戳和地理位置戳的支付请求。该类计算机设备可包括用于获取车辆地理位置信息的地理位置识别器、用于获取本地时间和日期信息的时钟，或用于接收服务请求的输入设备，该服务请求可包括指定的上下车时间和地理位置。处理器可自动生成用于支付的结算请求，包括所获得的车辆的实际地理位置、实际日期和时间信息，以及可能获得的有关服务请求的信息。移动无线通信或其他通信方式可传输自动生成的结算请求。

交通运输领域，包括但不限于非紧急医疗运输(NEMT)领域，至少涉及四方。一般而言，包括涉及交通运输服务的各方，即本申请所述的“司机”和“乘客”。通常还有其他各方参与协调交通运输服务的后勤工作；这里，这些其他各方可称为“供应商”和“服务提供者”。乘客可与供应商协调请求交通运输服务，供应商或者供应商代理人可与服务提供者签订合约提供交通运输服务。服务提供者联系司机，将交通运输服务请求分配给司机。从本质上讲，乘客通过指定的地点信息(如出发地或上车地点、目的地或下车地点)和指定的时间信息(如指定上车时间、下车时间)提出请求，服务供应商负责调派司机。如果乘客所请求的行程得到授权，供应商将针对该信息联系服务提供者。

用户先在***中注册，然后才能访问某些功能。用户为注册信息提交的内容取决于该用户的类型。例如，乘客用户可提供联系信息，如姓名、地址、电子邮件、医疗保健提供者信息或任何其他相关信息。司机用户可提交相关的执照信息或其他资格信息，如驾照或服务许可证、保险信息、个人资料信息，这些信息可包括服务历史和经验、车辆类型、语言等。相关的许可证信息基于服务提供者的公司所在位置不同而有所不同。服务提供者用户需提供调度许可证或其他相关证书，这些证书可与其他注册信息一起提供。供应商或其代理人用户可提交注册信息，确认其有支付能力，同时须确认其合法合理，如处理受保护的乘客健康信息时符合法律法规要求。本领域普通技术人员将理解，“注册信息”或“登记资料”可包含任何或所有各类用户信息，这些信息确立用户的合法性或依照适用法律使用本***和/或提供服务的能力。

可将结算请求发送给服务提供者。服务提供者可收集一组结算请求并将其发送给供应商或其代理人。然而，在某些情况下，可考虑将结算请求间接或直接发送给供应商。“间接”意味着服务提供者先审查并接受结算请求，然后将其提交给供应商。“直接”意味着将结算请求直接提交给供应商。司机如何与服务提供者或供应商联系取决于双方在服务合同或协议等文件中事先达成的协议。在描述本发明时，无意在各方之间建立特定的通信框架。

本领域普通技术人员将理解，本发明的示例性实施例还可使用其他术语对各方进行描述，因为这些术语旨在包含多种情况。例如，术语“乘客”可指病人，也可指拥有公司帐户的公司雇员或承包商等。术语“司机”可更广泛地指任何机动车，摩托车或其他车辆的驾驶员，还可包含飞行员。“供应商”可包括政府和非政府组织、民营机构等企业、保险机构、公司、非营利组织、民营公司或其他类型的企业。“供应商”一词在此可理解为服务的付款人，而并非一定是接收服务的人。在非紧急医疗运输中，供应商可以是经纪人或其他第三方。术语“供应商”是指需求准确的、可验证的结算一方。验证结算可应用于许多其他行业，特别是与其他交通运输服务或服务验证相关的行业。例如，准确的电子结算验证可用于公司账户、汽车服务、辅助客运***、公交公司或经纪人、出租车等。公司或供应商也想确保为乘客提供的服务质量，他们会寻求有关服务的可验证信息。电子结算验证***，需要使用地理位置和时间调整，或与其他参数有关的可接受范围。

此外，本申请中“服务提供者”可指一个实体，通过协调一位或多位司机来提供服务，同时与供应商合作。这些服务提供者可以是汽车服务公司，例如专门提供非紧急医疗运输服务的汽车服务公司。服务提供者可以有一个内部结算部门或个人结算人员来管理司机的结算请求，并向供应商出具付款结算请求。最后，本申请中的“用户”可以是与司机、乘客、服务提供者、或隶属于服务提供者的人，或供应商或隶属于供应商的人。此处“用户”可指使用本***的任一方。

需要理解的是，可接受范围也可基于其他变量。这些变量可根据相似性原则组合到不同的类别中。可用一个类别表示服务请求中有关乘客上车信息的一个或多个可接受范围，包括上车时间或上车地点，或二者兼有。用另一种类别表示相关的乘客下车信息，下车信息类别包括下车时间或下车地点，或两者兼有。这些变量也可以是关于其他方面的，可做为第三类或第四类，这些类别可包括服务请求的附加分车程。在该情况下，含多段分车程的服务请求可涉及第三类变量，包括上车时间、上车地点、下车时间和下车地点。

可接受范围适用于服务请求中提供的至少一个地点。例如，对于由乘客专门指定的上车地点而言可以有一个可接受范围。或者，可接受范围还可用于一个或多个地点。根据不同的情况，可使用一个适用于特定地点的可接受范围，要求司机到达该范围内的特定地点。然而，可接受范围还适用于一个或多个特定地点，其中，根据诸如警察行动或道路封闭等实时因素，司机可在这些特定区域内或其中一个地点提供服务。本质上，可接受范围包括一个或多个可接受地点。此外，可接受范围还适用于时间，其中包括批准结算请求的特定时间或时间框架等。

***可被配置为将本申请中使用的“地点”识别为地理位置，地理位置可通过使用经纬度坐标这样的位置格式来描述位置。此外，“地点”可包含人类可识别的格式，如实际地址等。如果需要的话，可通过地理编码来对这些格式进行转换。本申请无意限制在何时何地对服务或服务的结算请求使用可接受范围限制。可接受范围在某些情况下是否适用可由预先确定的规则来确定。

可将一个或多个服务器配置为与一个或多个模块进行通信，通过从移动设备的地理位置识别器和时钟产生地理位置数据和时间数据，这些模块可对有关车辆活动进行追踪，进而追踪司机活动。诸如GPS接收器等地理位置识别器，可设置在司机车辆中，通过无线网络，使用地理位置追踪处理方法，与一个或多个服务器进行通信。因此，一个或多个服务器可接收有关实际地理位置和实际时间的输入信息——服务请求开始和结束的时间和地点。在传输地理位置和时间数据后，一个或多个服务器可将“指定的”地理位置与“实际的”地理位置以及指定的时间与实际时间进行比较，从而确定该司机是否处于一个或多个可接受范围内。这里，“指定”指接收到的有关服务请求的输入信息(例如，作为行程的预期目的地输入的位置)。相反，“实际的”表示通过模块或其他设备(例如，做为下车地点的位置)追踪到的输入。一个或多个服务器可将从司机模块接收到的实际信息与指定信息进行比较，如果实际地理位置或实际时间与指定位置或指定时间之间存在偏差，但结算请求过程仍处于可接受范围内，则可进行自动调整。然后，可使用这些信息以及前述对比信息来确认司机是否提供了交通运输服务，这样，司机就可得到相应的报酬(或确定是否拒绝付款)。基于行程的确认情况对司机进行偿付。

确定司机是否处于可接受范围内，以及其是否得到提示在用户参与板块上提交一个或多个理由，不能仅基于从司机、车辆或司机模块检索到的信息。事实上，这种判断也可基于从乘客或乘客模块收集的信息，因为已对乘客的地理位置和验证信息(如签名或指纹)进行了追踪。可将相关的验证信息及实际地理位置或实际时间一起考虑，然后可将其与相关的指定地理位置和相关指定时间进行比较。在其他示例性实施例中，判断司机是否处于可接受范围内，可依据对司机的追踪信息、对乘客的追踪信息或这二者进行。

如前所述，可基于结算请求信息进行自动调整。一个或多个服务器可在收到结算相关数据或确定结算请求有效后将该数据进行格式化。

本发明的示例性实施例提供了多种***和方法用于确认基于可接受范围做出的调整的真实有效性。通过追踪司机的地理位置，获得上车或下车时间的时间戳，来确定所述上下车地点和时间处于可接受范围内，并基于有关时间范围，和/或距离，和/或位置的预定规则进行调整。然后通过对预定规则的动态更新使得可接受范围更加准确。所述预定规则可基于不间断的数据收集来进一步进行调整。

一个或多个服务器可对有关上车/下车地点的地理位置和/或时间进行调整。根据不同的情况，可进行不同类型的调整。“调整”可意味着，如果记录了多个输入，***可通过编程选择某个输入来代替其他输入。例如，如果满足某些预定规则(如关于可接受范围的规则)，***将选择将指定的地理位置输入替代实际的地理位置输入。调整也意味着用一个输入替代另一个输入。其中的一种调整类型为自动调整；这里的“自动调整”是指，当一个或多个服务器收到结算请求时，如果司机处于可接受范围内，***所作出的调整。司机不必在用户参与板块上提交信息，即可进行这种调整。调整可基于距离和时间进行，控制可接受范围的规则可预先确定，以反映合理的距离或时间。此外，需要理解的是，对结算请求进行的“调整”并不一定意味着以后不能对结算请求进行再次调整。调整后的地理定位仍然可以初始形式记录和存储在数据库中，也可以以调整后的形式存储。对时间的调整亦如此；可以用合适的时间进行调整，同时也可记录原始的时间输入。

此外，可接受范围基于位置的不同可以有不同的参数。例如，相比较小的城市而言，可接受范围参数在人口密集的城市可能需要更大的区域范围，例如曼哈顿，因为较高的建筑物可能会造成信号中断或其他技术限制。本地和附近的Wi-Fi连接可帮助识别地理位置，特别是在GPS信号不足或不够准确的地方。此外，以交通拥堵著称的城市，如洛杉矶，在确定时间时可能会导致使用更大的，基于时间的可接受范围，因为其交通状况相对较小城市而言更加难以预测。

这里的术语“***”指通过在一个或多个模块上或在计算机设备上操作的硬件和软件的组合来实施电子结算验证***，这些组件配置在一个或多个服务器上。该***包括与通信框架或网络内的组件(包括但不限于一个或多个服务器，数据库，移动终端应用程序，门户网站，网络设置等)组合并集成的各种预编程功能。在这些组件的支持下，可实现通过应用程序界面提供的服务，例如可以在某些模块上访问网站或移动应用程序。模块可包括服务提供者模块，司机模块，供应商模块和乘客模块。该***可通过在计算机设备，诸如便携式计算机设备和计算机上运行的硬件和软件的组合来实施，通常这些设备包含与无线广域网(例如，因特网)的一个或多个连接。该***可配置为与网络通信，以便对服务进行协调。

通常，这里描述的过程和方法使用一个或多个计算机设备，这些计算机设备通过软件或其他方式接收指令。这些计算机设备可通过下述各种示例及附图进行描述；然而，本领域的普通技术人员应理解，不同的示例性实施例可使用不同的计算机设备。

在本发明的示例性实施例中，硬件执行的操作可通过计算机可执行指令以编程方式执行。指令可存储于一个或多个服务器、硬件或***中，或也可存储在其他地方。这些操作可以是程序或指令，在计算机设备自动或非自动执行操作前，通过程序或指令可检测到其需要满足的条件。这些程序还可包括为实现这些程序的目的所需要的子程序，它们可以在硬件设备或软件组件或这两者的组合上执行。

依照本发明示例性实施例的软件架构确定了从可用性和功能性角度满足所有技术和操作要求的软件结构，同时可提供优化管理，维护、性能、数据安全等。因此，软件架构被配置为追踪某些功能目标的实现，例如为司机、乘客、供应商和服务提供者提供用户界面，以及数据存储和访问。这些架构及其设计可因情况而异，并影响***应用程序的质量、性能、可维护性和总体可用性。

可通过与每个模块相关联的应用程序，以及单独的应用程序接口和其他组件之间的协作来对结构元素进行确定。根据本发明的示例性实施例，这些结构元素可根据各自的功能组合到***的子***中，而软件和软件结构，可因情况而异。根据用户的角色和需求，可为不同用户提供本***的不同功能。

本领域的普通技术人员将理解，面向乘客的***或子***可包括模块，通过模块，司机，供应商，服务提供者或乘客可访问提供或协调服务请求所需的功能。这些接口可在结构上彼此不同，因为它们可能在编程时着重考虑不同的功能。本领域的普通技术人员将理解服务提供者或供应商的角色与司机角色之间的差异，而这种差异根本上需要通过不同的应用程序界面功能和/或模块功能来完成。所要求的这些功能，可通过在诸如智能手机，智能手表或其他移动设备的硬件上执行的软件，及其相关功能，通过编程的方式提供。

在某些示例性实施例中，计算机执行计算机程序指令，包括多个程序或线程。可同时处理多个程序或线程，以提高一个或多个服务器的利用率，并大大促进同步功能。通过这种实施方式，本申请描述的任何和所有方法、程序代码、程序指令等均可在一个或多个线程中实施。所述一个或多个线程可再生其他线程，这些线程本身可指定与它们相关联的优先级。计算机可根据优先级或程序代码中提供的指令的任何其他顺序处理这些线程。本领域普通技术人员将理解，计算机程序指令可包括计算机可执行代码。可使用多种语言表示计算机程序指令，这些语言包括但不限于C、C++、Java、JavaScript、Python、汇编语言、Lisp等等。

可实施某些逻辑功能，针对必须解决的技术问题提供特定和专门定制的服务，这些功能在执行特定的情况时可能极为复杂，例如执行布尔逻辑函数时。举例来说，可建立和执行逻辑规则，该规则能识别可接受范围的某些参数。适应复杂情况的各种语言可通过诸如Java之类的编程语言来编程和实施。这些语言可包括汇编语言，硬件描述语言，数据库编程语言，函数编程语言，命令式编程语言等。在一些示例性实施例中，可对计算机程序指令进行存储，编译或解读以便在计算机，可编程数据处理器，处理器异构组合或处理器架构上运行。

本申请所述的本发明的示例性实施例不限于涉及传统计算机程序或在所述传统计算机程序上运行的可编程装置的应用。还可包括其它类型的计算机设备，例如量子计算机，模拟计算机等。

流程图中的每个元素描述了计算机实施方法的一个步骤或一组步骤。此外，每个步骤可包含一个或多个子步骤。出于说明的目的，这些步骤通过一定的顺序来呈现(以及本申请描述的任何和所有其他步骤)。可以理解的是，本申请的示例性实施例可包含适应本申请的特定技术的其他顺序的应用步骤。所有此类变更和修改均应在本申请的范围内。任何对特定顺序步骤的描绘和叙述无意排除采用其他不同顺序步骤的示例性实施例，除非明确说明或上下文中清楚表示有特定的要求。

附图中说明的元素暗示元素之间有逻辑边界。然而，根据软件或硬件工程实践，这里所描述的元素及功能可作为整个软件结构的一部分，做为独立软件模块，或者做为部署外部程序，代码，服务等的模块，或者前述任何组合形式进行实施。进行的所有这些实施都应在本申请的范围内。

本领域的普通技术人员应理解，本发明的硬件并不限于前述列举的部分。在一些示例性实施例中，可以通过其他类型的硬件提供附加功能，或者使用目前尚未问世的硬件在未来以更高的效率提供附加功能。有形的硬件组件可以某种特定的方式提供。本领域普通技术人员应理解，对这些组件的配置取决于特定的示例性实施例。而对这些组件的描述并非旨在将***的组成部分限制为一种且仅有一种配置方式。

如上所述，可以理解的是，流程图说明的元素支持用于执行特定功能的各种方式的组合，及用于执行特定功能的步骤的组合，以及用于执行特定功能的程序指令方式等，无论这些步骤是否自动执行。

图1A表示基于本发明示例性实施例的，与一个或多个服务器100通信的，用于进行电子结算验证和司机追踪的***组件示意图。服务器100可与***的每个单独的部分和功能对接，使其统一运行。服务器100允许用户管理和使用复杂的通信网络，以便对某个用户进行访问或对多个用户同时进行***访问。该***可包含多个服务器，该服务器可处于分布式结构中，并得到位于世界各地的数据中心的支持。这些实现可以是通信连接和跨平台的，从而可向操作计算机设备的司机提供与服务请求相关的信息，例如电子地图位置显示，指示符等，这些指示符可显示行程时间，路线，定价信息，用户简档和设置信息，与供应商，乘客，服务提供者等相关的其他信息等。***的功能可通过计算机设备执行，这些计算机设备允许一个或多个服务器100处理和输出方法步骤。服务器端结构可通过软件程序来执行，软件程序可配置为协调模块和后端***之间的通信，后端***允许对数据的提取，示意图处理，存储及某些计算功能等。

服务器100可配置地理信息***102，非暂时性计算机可读存储介质101，该介质可实例化为一个或多个非暂时性计算机可读存储介质，以及数据库103。数据库103及其***功能可通过一个或多个数据库来实例化。服务器100可连接地理信息***102和非暂时性计算机可读存储介质101以提供***功能。数据库103可做为非暂时性计算机可读存储介质101的一部分进行实施，其中可对数据进行存储，组织和分析以获得对所有服务请求和结算请求有用的信息。本领域的普通技术人员还应理解，服务器100可包含处理器123，处理器123可以是一种逻辑处理器，例如一个或多个中央处理器，数字信号处理器等。这些可以通过任何已知的***总线结构进行连接以实施***功能，包括含有存储器控制器的存储器总线，***总线和本地总线等。

非暂时性计算机可读存储介质101可进一步存储由计算机执行的计算机可执行指令，例如程序模块。硬盘和相关联的计算机可读存储介质可以是计算机可读指令，数据结构，程序模块和其他提供非易失性和非暂时性数据存储的方式。程序模块可包括执行特定任务或实现特定数据类型的程序，子程序，对象，组件，数据结构等。计算机程序和数据可以任何形式(例如，源代码形式，计算机可执行形式或中间形式)固定或暂时固定在有形存储介质中，例如半导体存储器设备(例如，RAM，ROM，PROM，EEPROM或闪存可编程RAM)，磁存储设备(例如，软盘或固定硬盘)，光存储设备(例如，CD-ROM或DVD)，PC卡(例如，PCMCIA卡)，或其他存储设备。

计算机程序和数据可以任何形式固定在通过任何通信技术传输到计算机的信号中。这些通信技术包括但不限于模拟技术，数字技术，光学技术，无线技术，网络技术及网络互联技术等。计算机程序和数据可以任何形式分布：做为可移动存储介质(磁带)，预装在计算机***(例如，***ROM或固定硬盘上)，或者通过通信***从服务器或电子公告板分发。应当理解的是，如果需要，任何软件组件均可以ROM(只读存储器)的形式实现。通常，软件组件可以在硬件上实施。

服务器100可以连接到服务提供者模块104，司机模块105(例如，在移动设备上实现的应用和特征)，以及供应商模块106，详情请参看图IB。可通过诸如计算机网络116的通信方式进行连接，并可将信息输出到与模块相关联的一个或多个计算机设备的显示器上。***的通信方式可以通过一个或多个网络传输数据或者将数据连接到***的一个或多个***设备的任何方式。适当的通信方式可包括但不限于用于提供无线连接，有线连接，蜂窝连接，数据端口连接，蓝牙连接或前述任意组合的电路和控制***。也可将很多其他通信方式与本发明的示例性实施例一起使用。

可对用户模块进行不同的配置，且每个用户模块可基于不同的计算机设备组件来执行特定的功能。目前的计算机设备组件形式各异--平板电脑，智能电话，可穿戴技术(例如智能手表，笔记本电脑，PC，甚至服务器)可交互和通信以共享信息。使用该***的用户可通过模块与***交互，这些模块可部分地通过应用程序在其计算机设备上执行。该***可以是跨平台的，并且如果需要，可以通过诸如门户网站和/或移动应用程序之类的不同方式对其进行访问。例如，司机模块105可至少使用司机计算机设备110，例如智能电话，地理位置识别器111和相机112等。***的管理可以通过与司机，供应商，服务提供者和乘客使用的模块不同的另一模块来访问各种管理功能。可以预期，***管理员可提供或执行重要的管理功能，这对于本领域普通技术人员来说是显而易见的，并且需要通过模块来执行。

图1B为根据本发明示例性实施例进一步描述用于电子结算验证和司机追踪的***组件示意图。服务提供者模块104可包括服务提供者应用程序107，其可以在诸如台式计算机的服务提供者计算机设备108上运行。服务提供者(例如，人类用户诸如受雇的或隶属于服务提供者的结算人员)可通过服务提供者模块104将命令和信息输入到***中，其中服务提供者计算机设备108可以是台式计算机或触摸屏设备或包括键盘和/或鼠标的其他输入设备。其他输入设备可包括麦克风，平板电脑，智能手机或其他移动设备。可通过扫描仪等提供附加功能。前述设备通过接口与一个或多个服务器相连接。服务提供者应用程序107可以是不同的应用程序，如台式电脑应用程序，Android应用程序，iOS应用程序，WindowsPhone应用程序等，并且可以在诸如移动设备的计算机设备上运行。该应用程序还可由包含相关监视和/或管理工具的专门维护人员进行维护，并且可由拥有相关经验和技能的工程师进行升级。服务器还允许在服务提供者模块104上进行备份以增加安全性。服务提供者模块104部分地允许服务提供者连接到服务提供者门户网站109，在这些门户网站上，可获取某些结算相关信息(例如待决结算请求，服务请求等)。可向服务提供者提供与其工作有关的特定功能。向服务提供者提供的信息可能比司机更多，以便其获得关于服务的全面信息。例如，为服务请求提供的信息可包括车辆信息，司机和车辆的当前和预期位置，车辆行驶方向等，以便用于所需的任何确认。

司机模块105可包括司机应用程序117，其可以在司机计算机设备110上执行。司机模块105允许追踪诸如地理位置识别器111(例如，GPS接收器)的组件以识别司机的地理位置，其中地理位置识别器111可内置到移动设备中，或者可以是经过特定编程的结算验证设备的一部分。在其他示例性实施例中，地理位置识别器111可安装在司机驾驶的车辆中，并且可以通过网络116地理位置追踪和/或处理方式与服务器100通信。司机模块105还可以通过相机112进行拍照，且时钟113可使用时间戳来获取时间。这些可以是司机计算机设备110的一部分，例如内置于智能手机，或者它们也可以是通过输入设备或由经特定编程的结算验证设备提供的潜在功能。相机112可允许司机拍摄特定位置(例如，下车地点)的照片，并可使用示意图识别技术对照片进行示意图处理以便将照片与已知位置示意图进行交叉参考。例如，到达医生办公室进行预约的患者/乘客可以拍摄医生办公室门口的照片，以便***识别。***可存储相同建筑物入口的示意图或视频记录，并可进一步检查所提供的照片以供确认。这些示意图或视频记录可存储在数据库103中，以便查询。此外，这些示意图可通过应用程序编程接口提供，例如谷歌地图的应用程序编程接口，是由做为Alphabet子公司的Google提供的映射地图定位和分路段导航应用程序，可提供相应于正确地址的街道示意图，可用于验证目的。在司机模块105与服务器100产生通信问题或者连接不稳定时，该功能将会很有用。在这种情况下，可提供解决连接网络中的某些技术缺陷的方法。

司机应用程序117还可允许司机访问门户网站或其他数据输入和/或***访问装置。如司机提交结算请求，结算请求可以发送给服务提供者，也可间接或直接发送给供应商。间接发送可能意味着服务提供者首先审查并接受结算请求，然后将其提交给供应商。直接可意味着将请求直接提交给供应商。另外，可以通过司机模块105向司机提供潜在的行程，可暂时显示行程查询以便于对其进行调派。司机应用程序117还可以允许与模块内的其他独立装置或外部服务器100进行特定的通信。通过服务器100或用户参与板块115，司机可以与门户网站或服务提供者交互。对于司机而言，在结算审查，上诉或其他情况下能够与服务提供者联系是尤为重要的。

此外，当乘客不能为行程签字时，***可依赖司机收集的信息以确认或验证服务请求，例如来自司机模块105上乘客的指纹，语音确认或验证信息。例如乘客忘记将其模块遗忘在家中，出现技术困难等。这里仅列举了司机模块105包含的一部分功能，因未本申请的目的并非将所有各种功能一一列出。

供应商(例如，支付方)可以使用与服务器100通信的供应商模块106来访问***。供应商模块106可包括供应商应用程序118。供应商模块106还可集成供应商计算机设备114以实现供应商应用程序118。然而，本领域普通技术人员可理解，供应商应用程序118的编程可与服务提供者应用程序107有所不同。此外，企业的供应商可以使用内部计算机网络，其中供应商应用程序118可被设计为在上述网络上及一个或多个供应商计算机设备114上运行。供应商计算机设备114也可通过供应商门户网站119向供应商模块106提供供应商访问。供应商模块106可配置为向服务器100或处理器123发送服务请求。然后将该服务请求发送至服务提供者模块104或司机模块105。

乘客可使用乘客模块120来访问某些***功能。乘客应用程序121在乘客计算机设备122上运行。乘客模块120还可包括地理位置识别器111，相机112和时钟113等。一些功能可以通过为乘客提供乘客模块来实现，并且可以与一个或多个服务器通信，同时允许乘客联系相关的供应商或相应的一方。乘客模块可包括应用程序，该应用程序可以是跨平台的，允许乘客使用以下移动设备的功能：智能电话，智能手表，平板电脑，或诸如笔记本电脑或PC等其他计算机设备。该应用程序还可向乘客提供访问乘客模块120的方式，而乘客可以访问以往的路线信息，个人资料信息，医疗信息等。

应当理解的是，虽然服务提供者模块104，司机模块105，供应商模块106和乘客模块120可以包括类似的元件(诸如特定应用程序，或诸如地理位置识别器111，相机112，时钟113之类的组件)，这些元素不需要在每个模块中以相同方式的实施。除了获得有关服务提供者模块104，供应商模块106，乘客模块120或司机模块105的***活动的时间戳之外，地理位置识别器111和时钟113还可分别用于确定***活动的位置。上述记录可在审计时提供有用的信息，或在某些情况下作为安全措施，尤其是在移动计算机设备上使用时。

服务器100还可以提供对用户参与板块115的访问，用户可通过网络116连接到用户参与板块115的一个或多个模块来访问用户参与板块115。用户参与板块115可以是用户界面元素。服务器100可以访问数据库103或一个或多个其他数据库并在用户参与板块115上显示其中的相关数据。服务器100可访问并显示有关特定服务请求或结算请求的所有信息。用户参与板块115可通过诸如在线论坛，留言板或在线讨论相关主题的其他类型的网站加以提供。用户参与板块115可在网络浏览器上进行访问，或作为用户应用程序的一部分提供，或者作为可以在一个或多个计算机设备上运行的应用程序提供。通常情况下均可对用户参与板块115的数据进行访问，取决于查看这些数据的人，可针对保密信息对数据进行编辑。在其他情况下，这些数据可以完整地呈现给某些用户，例如信息涉及的用户。

司机可通过司机模块105访问用户参与板块115，司机可以上传照片，提交其不在可接受范围内的原因等。可以在用户参与板块115上显示司机上传的照片，这些照片可包括含有地理标记信息的元数据或与拍摄照片的时间有关的时间戳。

用户参与板块115还可通过服务提供者模块104和供应商模块106进行访问，用户可访问信息以进行验证。从用户参与板块115上，经授权的账单人员(可以是服务提供者或供应商)可查看结算案例情况和其他信息，并且可以联系一个或多个司机以验证结算请求。

***将通知司机，在相关用户参与板块115上提交与结算有关的数据。一位或多位司机通过用户参与板块115提交的的数据将用于动态更新、更正和补充数据库103。当在一个或多个用户参与板块115上提交结算相关数据并收到预定数量的正面评价时，或根据其他预定规则进行了验证时，可将其用于实时更新数据库103。对数据库103的更新可用于更新一个或多个可接受范围。通过该种方式，可接受范围将被动态更新并相应地纳入数据库103中。根据在一个或多个用户参与板块提交的资料，可部分确定一个可接受范围是否准确，以及是否应保持有效、停用或作为半活跃可接受范围纳入，如图3b和3c所示。任何有第一手经验的用户，包括对结算相关信息，地理位置或时间有第一手经验的任何用户，无论是服务提供者，司机，供应商，乘客还是在***内注册的其他个人，都可以在用户参与板块115上提交数据。第一手经验可以至少通过地理位置追踪数据来确定，其中第一手经验的确定方法为：用户正在靠近或曾经在地理上接近有关位置。在某些情况下，有关位置可能是结算请求中的实际地理位置。例如，接近度可以定义为距离某个位置小于50英尺，或者也可以是其他定义方式如基于诸如30或40英尺的预定规则。如果用户处于基于某个地理位置数据的预定半径范围内，则表明他/她具有第一手经验并因此有资格对用户参与板块上的信息进行评价。接近度的确定也可不基于半径；也可基于在同一个街区或街道上，或基于地理边界。可在任何时间预设或建立这些规则。众包数据或信息不需要向***的其他用户提供。如果收到预定数量的正面评价，确认任何众包数据或信息有用的话，则可奖励提交该数据或信息的用户。这将鼓励用户使用并在用户参与板块115上提交信息。本领域普通技术人员应当理解，***功能也可通过未在这些示意图中描述或定义的其它方式执行。

用户参与板块115可以一种或多种不同方式组织构建，用户参与板块可以有一个或多个，其中每个可接受范围均有其对应的用户参与板块115。此外，一个用户参与板块115可以有其自己的数据存储方式，其中一个或多个数据库可存储与一个或多个服务请求相关的一个或多个位置的所有相关数据信息。此外，可使用中央用户参与板块，该板块包含一个或多个分区，这些板块的分区适用于单个可接受范围或多个可接受范围。

图2A描述在提供服务过程中进行结算请求调整的示例性工作流程图。该过程的第一步是接收服务请求信息(步骤200)，其可以包括与服务请求相关的指定位置和指定时间，还可以包括供应商信息，例如供应商的某些可接受范围。地理信息***102或服务器100可以执行地理编码处理(步骤201)，包括将位置输入作为地址进行地理编码，包括例如经度和纬度坐标。这可以使用第三方地理编码应用程序编程接口(例如谷歌地图)来实现。服务器100可部分地基于在服务请求中提交的信息，使用在服务请求中输入的值，并基于动态调整的预定规则来建立可接受范围。地理编码部分地允许建立地理位置的可接受范围(步骤202)，这一过程是通过将位置转变为地理位置来实现的。此外，关于时间的可接受范围可以部分地基于服务请求的输入来建立可接受范围(步骤203)。一旦建立了一个或两个或任何其他相关的可接受范围，且服务请求正在进行的话，***可一直追踪司机的位置，并且接收结算相关数据(步骤204)，其中司机模块105通过诸如GPS接收器之类的功能，向服务器100发送，有关司机模块105的位置的结算请求信息。可以在特定情况发生时(例如，车辆停止了一定的时间，或者在距离指定位置的特定距离范围内停下)或在进行信息请求时(例如，服务提供者，供应商或其他***监视器，请求手动更新车辆状态)时周期性地发送或以其他方式接收结算相关数据。

根据服务请求信息和结算相关数据，包括实际的上车地理位置和时间，实际的下车地理位置和时间，以及其他相关信息，如定价信息和里程信息等，来确定司机是否在可接受范围内，以便提交结算请求(决定205)。这也可以在司机模块自动将结算请求信息传送到服务器100之后发生。如果被追踪的信息在可接受范围内或与服务请求信息匹配，则可以进行自动调整：批准结算请求(步骤206)。有关调整的信息，例如更改了哪些值以及何时进行的更改，将记录在***中。记录可包含对服务请求和结算请求信息和其他类似信息的完整信息记录。如果司机不在可接受范围内，须查看发生这种情况的原因，在此情况下，服务器100可通过司机模块105，通过一个或多个短信提醒司机其可能不在可接受范围。如前所述，该确定可基于从乘客收集的信息，其中从乘客收集的信息可以与司机模块信息一起使用或者单独使用。当司机不在一个或多个可接受范围内时，条件性拒绝或最终拒绝可最终导致对付款的临时取消或永久取消。该种情况下，可验证服务请求是否被执行。，当司机无法到达可接受范围时，服务器100可向司机发送短息，这可认为是条件性拒绝。该短信可提示司机提供一个或多个原因和照片说明其未能在可接受范围内的原因(步骤207)。司机解释其为何无法在指定时间到达指定地点，或者也可用包含时间和地理位置数据的照片作为证据。

司机通过用户参与板块115提交结算相关数据(步骤208)。用户可查看结算相关数据，包括司机提供的一个或多个原因，并确认或否认司机提供的原因是否合理。这是对司机提交的信息进行评价的过程的示例。用户可调查司机提交的原因(包括一个或多个其他司机)，以便确定出现的问题，以及出现的问题是否合理。因为出现的问题可能是诚实的错误，可能是欺诈性的，或者无法确定的。此外，在某些情况下，司机可从乘客处那里收集签名或其他确认信息比如指纹，表明其试图提供服务请求但未能完成。此外司机可拍摄照片并将照片与情况的书面说明一起上传(例如“由于游行，第五大道封路，在第六大道放下乘客”)。乘客验证可发生在服务开始，服务期间或服务结束时。可在司机模块105上，在专用设备上，或者甚至是为乘客专门提供的模块上收集乘客验证。

当在用户参与板块115上提交结算相关数据时，有第一手经验的一个或多个其他用户可对其进行评价。如果结算相关数据在预定时间内收到预定数量的评价时(决定209)，则可进行调整(例如，付款)，批准结算请求(步骤206)，因为评价已经证明了提交的信息的准确性。这些评价可能是正面评价或确定性评价，或任何其他类型的评价，其所传达的信息表明提交的一个或多个原因是合理的。当然，这些评价也可能是负面评价。如果信息在预定时间内没有收到预定数量的评价(决定209)，则可进行最终拒绝(步骤210)。如果司机认为其付款请求不合理或在预定时间内没有提出争议(决定211)，则可保持最终拒绝(步骤212)。如果司机认为他/她的付款请求是合理的，并且在预定时间范围内提出争议(决定211)，则服务提供者可以进行案例审查。在案例审查中，服务提供者可能忽略了司机提交的原因，照片或其他信息。提供给服务提供者的信息可能与用户参与板块115收到的信息相同或更详细。如果服务提供者或本发明的某些示例性实施例中的供应商不认为司机的付款要求是合理的，但却批准了结算请求(决定213)，那么服务提供者可以保留最终的拒绝决定(步骤212)。如果服务提供者决定批准结算请求(决定213)，因为有许多合理的原因导致司机无法到达正确的位置，可对其进行调整，因为结算请求已被批准(步骤206)。其中原因可包括停车限制，道路规则，建筑工地和临时路障。在某些情况下，原因指示因为乘客在指定地点下车会不安全，司机判断让乘客在附近地点下车将会更安全。因特殊安全事件，游行，集会或抗议活动导致的道路封闭也可导致死机无法到达正确的位置。所有这些均可能导致对司机的位置或时间差异进行验证。

图2B为基于本发明示例性实施例的示例性工作流程图，其中描述了针对地理位置调整结算请求的步骤。在一些示例性实施例中，服务器100接收包含指定的上车和下车地点的位置输入(步骤214)，或多个上车地点和下车地点。然后对这些位置进行地理编码，将输入位置转换为地理位置(步骤215)。地理位置可用于从数据库103中检索与该地理位置相关联的预定规则(步骤216)(例如，检索有关该地理位置的可接受范围的预定规则，并确定可接受范围须基于与指定地理位置相距120英尺范围内的区域。

这些预定规则创建“缓冲参数”的维度，允许通过地理信息***102(例如ArcGIS--由Esri提供的地理定位映射平台，可提供空间分析软件和/或服务器100创建可接受范围(步骤217)。使用空间分析软件，具有某些属性的坐标可以在缓冲区内组合在一起。缓冲区可基于中间的一组坐标。在地理编码过程中，这组坐标是从输入的服务请求地址转变来的。缓冲器被配置为包含距离中心点某个特定距离范围内的所有坐标作为其参数。与地理位置相关联的坐标都满足某些标准，因此可以基于这种相似性进行组合。

一旦建立了可接受范围，服务器100就可以接收由司机模块105生成的结算请求中的实际地理位置输入(步骤218)。根据输入，可确定实际地理位置是否处于可接受范围内(决定219)，因而是“合格的地理位置”。如果是这样，则可进行基于地理位置的自动调整(步骤220)，选择指定的位置输入以便处理结算请求。例如，基于预定规则建立的可接受范围，其要求200英尺的范围，其中可接受范围的中心坐标基于40°45'23.2"N，73°58'35.8"W的指定地理位置。如果司机在40°45'23.6"N,73°58'35.0"W处下客，距离指定的下车地点105英尺，服务器100可以自动选择指定的输入地点而非实际下车地点做为下车地点地理位置，40°45'23.2“N，73°58'35.8”W。在其他示例性实施例中，可接受范围可基于编程的“锁位偏差”，例如在地理信息***102中，可将位置信息在地图上分组定位。除了基于坐标的分析之外，确定地理位置是否处于可接受范围内可通过确定两个输入点之间的距离来完成，例如英尺，米或其他测量值。在一些示例性实施例中，可以将地理位置转换为人类可读地址(步骤229)。

如果实际的地理位置不在可接受范围内，则将不对地理位置进行自动调整(步骤221)；然而，***仍然可以在数据库103中记录和存储实际的地理位置输入。地理位置输入可以被逆向处理回到人类可读地址(步骤229)。因此，可以将实际地理位置通过地理编码处理转换回实际位置。

图2C为流程图描述根据本发明示例性实施例的示例性工作流程，阐述了基于时间调整结算请求的步骤。一旦供应商或其他相关方提交了服务请求，服务器100即可接收指定的上车时间和下车时间输入(步骤222)。基于服务请求，通过从数据库103检索信息(步骤223)，可确定是否有基于时间的可接受范围的预定规则。这可通过引用特定的ID号或通过其他服务请求标识符来执行。该标识符可用向数据库103查询相关信息。一旦检索到指定的上车时间和下车时间，以及基于服务请求时间的，有关可接受范围的预定规则，就可创建基于预定规则的可接受范围(步骤224)。

基于时间的可接受范围可将时间按属性分组，在此情况下，所定义的属性可基于预定时间或其他限制。然后可执行服务请求，并且可以从司机模块105接收结算请求中输入的实际时间(步骤225)。基于所接收的实际时间，可确定司机是否处于基于时间的可接受范围内(决定226)。指定时间为已知时间值，用于与实际时间进行比较，相关规则可规定任何在指定时间窗之外的时间均不是合格时间，因此将被拒绝。该规则可规定什么是合格时间，例如在指定时间的10分钟范围内的任何时间输入。例如，指定时间是上午9:15，预定规则规定只有10分钟范围内的时间才是合格的时间，则服务器100或其他处理装置可以接受上午9:05到9:25之间的所有时间输入。在其他示例性实施例中，可根据预定规则创建基于时间的可接受范围，该预定规则规定在指定时间之前5分钟时间范围内的时间均为合格时间，同时创建一个10分钟后的可接受范围。这意味着在该示例性实施例中，针对上午9:15的指定时间，合格时间范围为上午9:10和上午9:25之间。可基于创建时间段的逻辑功能来进行比较，时间段可通过计算机设备执行和编写，以便由计算机设备执行。如果时间输入处于可接受范围内，则可对时间输入进行自动调整(步骤227)，并选择指定的地理位置输入以便进行结算请求的处理。可基于某种规则，通过编程来针对时间对结算请求进行调整，或者可以在由服务提供者审查后以编程方式或手动方式进行调整。如果时间不合格，则不会自动进行时间调整(步骤228)；然而，实际时间输入仍然可以记录在数据库103中。

应当理解的是，图2b和图2c可做为子程序来举例说明，这些子程序旨在描述建立图2a所述可接受范围的具体步骤，而不是描述建立一个或多个可接受范围的过程的图表。此外定义可接受范围的预定规则可能会变化。可接受范围可涉及下述方面：如司机达到：一定速度，平均为某个速度，行驶一定的总距离，沿某一路线行驶，遵守交通规则，保持安全跟随距离等。预定规则也可以基于所收集的数据进行改变，在一些示例性实施例中可以通过人工智能来分析。人工智能可确定那些在某些条件下会导致可接受范围变化的模式。例如，天气状况会影响司机到达某些地点的能力，或者可能会增加交通拥堵。在这种情况下并且在相关的情况下，人工智能可基于预定规则改变可接受范围。本领域的普通技术人员应理解，基于数据收集改变可接受范围的方法可以应用于不限于天气条件的许多其他因素。此外，基于距离的可接受范围不需要基于特定半径。在另一示例性实施例中，基于距离的可接受范围可以是一个有地理边界的区域，该区域的多个边的长度，高度或其他尺寸或参数各不同。本领域普通技术人员应理解，在某些示例性实施例中，这也可以通过更新可接受范围来实现。

但是，为了有资格获得结算请求中要求的付款，司机需满足所有或一定数量的变量要求。例如，为了有资格获得付款，司机需按要求提供服务，或者之后进行自动调整，通过用户参与板块进行调整或对争议进行调整来调整结算请求变量。但是，尽管司机提供了服务，但可能需要对一个或多个变量进行调整的情况。例如，如果司机没有合理的理由在与指定的上车地点不同的位置上客，但仍然在指定的正确时间将乘客送到指定的目的地。在这种情况下，可以收集和分析司机未能在指定位置上车的一个或多个原因，但由于司机的确提供了服务请求并且提交了结算请求，因此可以对司机进行付款。可支付全部，部分款项或根本不予支付，因为在确定支付时存在很多情况，付款的支付由服务提供者，一个或多个其他用户，供应商或***来自行决定。在其他示例性实施例中，某些情况下，也可不基于上述自行决定向司机支付结算请求中要求的正确金额。

可能出现这样的情况：司机或乘客没有出现，或者一方无法确定另一方的位置，如未到场(例如未露面)。如果司机未露面，则表示未提供任何服务，则无法生成结算请求。如果乘客未露面，则没有来自乘客的验证。还可能存在司机或乘客在服务之前或期间取消服务请求的情况。针对这种情况可提供经过编程的变通解决方案，如果满足某些验证因素的话，可对这种情况进行验证。验证因素可包括追踪到的地理位置和时间信息，以便确定司机是否在可接受范围内，而在此情况下的可接受范围涉及时间，地理位置或时间和地理位置二者兼有。例如，为满足验证要求，需要司机到达某个地理位置并在那里停留一段时间，例如10或15分钟或其他预定时间。如果司机在此期间由于停车规则无法找到停车位，他/她可能会绕过该区域或在附近的其他位置等侯，如果合理的话，这可以被视为等待时间。另一个验证因素涉及联系另一方所做的努力。对于乘客而言，可以是联系供应商，服务提供者或司机的一次或多次尝试。对于司机而言，可以是联系乘客，供应商或服务提供者的一次或多次尝试。可在移动设备上进行输入，以便司机或乘客登记另一方的未显示的信息，该信息可通过用户参与板块115提交或包括在结算请求中。如果乘客确实露面但是迟到的话，可基于司机在哪里等待多长时间，考虑在其等待乘客的时间内向司机支付额外的费用，如果他/她有电话记录等证明其尝试联系乘客，则可使用相关的用户模块或通信方式将电话记录等集成到***中。

乘客未露面的情况或类似的情况可能与可接受范围有关，也可能无关；然而，乘客模块120，司机模块105，服务提供者模块104或供应商模块106可实现多种功能，用于解决可能出现的各种情况，例如让服务提供者输入某些澄清信息等。如果乘客未露面，司机仍然可以手动或自动提交结算请求(例如，经编程处理的计时器在司机到达时即启动，但如果司机不将其终止，计时器将不会停止计时)。如果司机没有到达可接受范围内，则该司机仍可通过用户参与板块115调整结算请求；即使没有乘客验证，在某些情况下也可以确认一个或多个原因；***可提供用于在未提供乘客验证信息的情况下处理结算请求的方法，并可基于预定规则来决定批准还是拒绝结算请求。

图3A描述建立和更新可接受范围方法的流程图。需要指出的是，有义务支付所提供服务一方是有权建立可接受范围的一方。因此，作为本发明的示例性实施例中的一般规则，司机或乘客将不会建立可接受范围。虽然服务提供者也可能没有该权限，但在某些情况下，服务提供者可以与供应商或代理商进行有关可接受范围的协商，特别是如果存在一些适用于提供服务的特殊规则。

建立可接受范围的方法包括不同的阶段，在这些不同的阶段，可接受范围参数不同。可接受范围至少有三种“类型”。基于供应商或代理商自行决定或基于常识，即随机决定或基于历史数据(如果有的话)，或者也可基于默认参数，建立“初步”可接受范围(步骤300)，这可由供应商，供应商的代理或其他相关方预先确定。默认参数可以是随机的，基于交通运输服务的提供方式进行更新的。另一个阶段为数据收集(步骤301)，记录预定数量的服务请求(将乘客送到指定地点的数量，接载乘客的数量或两者兼有等)。在该阶段，用户参与板块可以用于收集信息或数据，这些信息或数据可帮助最终将初步可接受范围转换为更准确的永久性可接受范围。数据收集可帮助建立更准确的永久性可接受范围，并且数据收集过程可根据需要在任何时间段内进行。收集的数据可存储在数据库103中。然而，这里可以应用于可接受范围的“永久性”并不表示无法更改该永久性的可接受范围。在本申请中，术语“永久性”表示可以在很长的一个时间段内适用的可接受范围。在某些情况下，永久性范围可基于收集的数据发生变化或重置，例如永久性的街道封闭或停车规则或法规的变更。

可不断收集结算相关数据，包括但不限于实际上车地点和下车地点。如果由同类合理原因支持的调整后的结算请求的数量达到预定数量，则停用初步可接受范围，并转换为永久性可接受范围。通常，如果收集的数据显示司机反复到达初步可接受范围以外，则基于收集的相关数据，停用初步可接受范围并且转换为更大的永久性可接受范围。另一方面，如果收集的数据显示司机反复到达指定位置附近而不是初步可接受范围确定的最大范围，则初步可接受范围将被停用并转换为较小的永久性可接受范围。基于数据收集阶段收集的数据建立永久性可接受范围(步骤302)，永久性可接受范围更准确地反映了司机在实际服务提供过程中可能在何时或何地下客或上客。但是，由于实际情况会影响服务的提供，因此可能需要对可接受范围进行更新。

可接收结算请求(步骤303)，基于结算请求确定司机是否在永久性可接受范围内(决定304)。如果司机不在永久性可接受范围内，则可发出条件性拒绝，并提示司机通过用户参与板块以一个或多个原因或照片的形式提交结算相关数据(步骤305)，解释其无法到达可接受范围的原因。如图2A所示，视具体情况而定，司机的结算请求可能受到完全或条件性拒绝。一旦司机通过用户参与板块提交了结算相关数据，则对这些数据将进行评价。如果评价在预定时间内达到预定数量，则可对司机的结算请求进行调整。反之，司机的结算请求将被拒绝。但是，司机仍有机会在预定时间内对该拒绝提出异议。

如果司机处于永久性可接受范围内，则可基于实际输入和指定输入对司机的结算请求进行调整(步骤306)。可收集结算请求数据，并对司机在永久性可接受范围内到达的位置作出回应，如果该永久性可接受范围比其需要的更广，则可以对该范围进行调整。另一方面，如果永久性可接受范围过于严格狭窄，那么可对建立该永久性可接受范围的规则进行更新，将永久性可接受范围扩大。基于预定规则，可以确定所收集的数据是否能构成对永久性可接受范围的更新(决定307)。这可以通过评估实际输入(例如，对于实际地理位置或实际时间)是否比最大可允许输入更准确来进行确定。举一个关于地理位置的例子，如果有指定的地理位置，且可接受范围接受100英尺以内的输入，则100英尺则是“最大允许输入”。如果下车地点距指定位置25英尺，那么下车地点距离指定位置要比100英尺近；这表明可接受范围过大。如果实际输入没有明显不同，则所收集的数据不构成对永久性可接受范围的更新(步骤308)。如果所收集的数据支持更新永久性可接受范围，则将基于预定规则对永久性可接受范围进行更新(步骤309)。可基于结算相关数据通过更新来定制永久性可接受范围的相应大小(例如，可接受范围可以缩小或扩大)。

本领域的普通技术人员应该理解，根据本发明的示例性实施例，在给定时间范围内只有一个可接受范围是完全有效的。此外，本发明的示例性实施例可向司机发出提示信息，通知司机处于可接受范围内，可以进行上客/下客。如果司机收到通知提示其不在可接受范围内且需要靠近指定位置时，则司机可以靠近所述指定位置，这样才可接收对其结算请求的自动调整。

图3B流程图说明在某些情况下建立临时可接受范围的方法。可接受范围还可能有第三个类别，称为“临时”可接受范围。可在需要时建立临时可接受范围，且可部分地通过用户参与板块115建立。当司机在永久性可接受范围之外时，司机将得到提示其须在用户参与板块115提交结算相关数据(步骤305)。临时可接受范围可在司机无法到达指定位置或永久性可接受范围(例如建筑工地或警察执行公务场所)的情况下建立。可基于预定规则建立临时可接受范围，其中一个规则是确定在用户参与板块115上提交信息之后是否对结算请求进行了调整(决定315)。如果没有进行调整，则可将提交的信息，相关结算请求和其他数据记录在数据库103中(步骤311)。如果做出了调整，则下一步可确定是否有预定数量的类似的调整(例如，基于位置，基于原因的调整)(决定312)。如果这些调整尚未达到预定数量，则可将提交的信息，相关结算请求和其他数据记录在数据库103中(步骤311)。如果已经进行了预定数量的调整，则可分析调整的原因。临时可接受范围的建立可取决于调整的原因是否为长期原因(决定313)。一些原因或照片反映了影响可接受范围的长期因素，例如停车规则的变更，例如禁止随时停车的规定，不允许司机在规定生效的情况下上客或下客等。如果确定原因是长期的，则可以基于预定规则更新永久性可接受范围(步骤313)。如果原因不是长期的，则可基于预定规则建立临时可接受范围(步骤314)，该规则可用于确定可接受范围的大小，而该规则的订立可基于在先前步骤中或通过其它方式收集的数据。临时可接受范围可根据在用户参与板块115上提供的原因或照片建立，并且该临时可接受范围可持续数小时，数天，数周等不等。

给定地点的以前的永久性可接受范围参数也可存在于临时可接受范围内。先前的永久参数可被称为“半活跃”永久性可接受范围。由于临时可接受范围确实是暂时的，在某些情况下，将其恢复到永久性可接受范围可能是更为适当的，因此通过建立“半活跃”永久性可接受范围来保留永久性可接受范围的参数将是很有益的(步骤315)。

可接受范围的状态可以是例如活跃，不活跃或半活跃状态。因为提交给用户参与板块115的信息通常涉及可接受范围的适用性，已验证司机不在可接受范围的结算请求也可通过手动或自动方式对用户参与板块进行访问，以进一步验证结算相关数据。可接受范围的活跃状态可部分由用户参与板块115上提交的一个或多个的数据确定，根据预定规则可确定在用户参与板块115上提交的哪些数据是准确的。这可以动态进行。这里的“活跃”可接受范围旨在表示当前适用的可接受范围，其可应用于结算请求中的时间或位置。“不活跃”可接受范围指已被停用的可接受范围，因为它在当前被认为是不准确，不适用的。“半活跃”指与临时可接受范围结合的永久性可接受范围，其中，当根据预定规则停用临时可接受范围时，半活跃永久性可接受范围将被完全激活为永久性可接受范围，如图3C所示。此外，如果不满足这些条件，半活跃永久性可接受范围可能保持其半活跃状态。关于所有可接受范围的信息，无论是活跃、不活跃还是半活跃，都可存储在数据库103中，并可用作历史数据，以便使一个或多个其他可接受范围更为准确。

图3C流程图描述用于更新临时可接受范围的方法。如图3B步骤314和315所示，当建立临时可接受范围时，司机可提交与所建立的临时可接受范围相关的结算请求(步骤316)。提交所述结算请求可以是在建立临时可接受范围之后，或与其相关的任何时间。然后确定司机是否处于临时可接受范围内(步骤317)。如果司机不在临时可接受范围内，则可提示司机在用户参与板块115上提交结算相关数据(步骤305)以进行调整。如果司机在临时可接受范围内，则可基于实际输入和指定输入对司机的结算请求进行调整(步骤306)。然而，一系列情况可能导致临时可接受范围一旦建立即被停用。当检测到司机处于可接受的临时范围内并进行调整时(步骤306)，可以进一步检测司机是否在半活跃永久性可接受范围内(步骤318)。如果司机处于半活跃永久性可接受范围内，则表明临时可接受范围不再适用。这种情况可触发对临时可接受性范围的停用以及对半活跃永久性可接受范围的完全激活(步骤319)。例如，由于一个施工现场持续施工了一周，建立了临时可接受范围，在施工现场被移除后，司机可能再次到达施工现场所在的位置，这可能在半活跃永久性可接受范围内。如果司机不处于半活跃永久性可接受范围内，但仍在临时可接受范围内，临时可接受范围仍可适用于下一个相关的结算请求。

图4A描述基于距离的可接受范围的应用示意图。车辆400(其可以包括司机模块105)可由提供服务请求的司机驾驶，其中指定的下车地点401位于拐角附近。然而，在本图中，由于402号公路被施工路障挡住，司机无法让乘客在指定的下车地点401下车。由于障碍物导致司机无法在指定的下车地点401下车，司机可能必须靠向街道的路肩，以便在与实际下车地点403不同的地点安全或合理地让乘客下车。然而，由于司机无法基于距离半径404到达可接受范围内，因此可以提示司机在用户参与板块115上提交结算相关数据以证明他/她无法到达指定的下车地点401。司机可能还有许多其他无法到达指定地点正当理由。这些因素可包括停车限制，道路或停车规则以及其他临时道路堵塞。在某些情况下，乘客下车可能根本不安全，司机认为开到附近的地点下车可能更安全。特殊安全事件，游行，集会或抗议活动导致的道路封闭也可能使得到达指定地点不切实际或不可能，无论指定地点是下车地点还是上车地点。所有这些构成了验证司机的位置或时间偏差的潜在原因。

图4B示意图描述对基于距离的可接受范围的应用。车辆400(包括司机模块105)由提供服务请求的司机驾驶，其中指定的下车地点401在街道的右边路肩上。然而，在该例中，由于道路正在进行施工，道路405被堵，司机无法将车辆停靠到路边，因而无法让乘客在指定地点下车。司机须在拐角处行驶，以便使乘客安全或合法地在一个偏离指定地点的实际下车地点403处下车。基于该图中所示的距离范围404的可接受范围提供了一个区域，在该区域内，如果实际下车地点403处于距离指定下车地点401的某个距离范围内，则可对该实际的下车地点进行自动调整。

然而，如果司机在不同于指定地点的其他位置让乘客下车的话，不需要特别给出通知。如果指定的下车地点401在实际下车地点403的特定距离范围内，则基于该图所示的距离404的可接受范围提供可对实际下车地点进行自动调整。在图4A和4B中，将基于距离404的可接受范围描绘为二维椭圆。然而，该图示例无意使基于距离404的可接受范围受制于该二维范围约束；由于GPS和地理位置技术(以及其他地理位置技术)允许三维地图映射，也可将这些特征纳入可接受范围。例如，当目的地是机场的出发入口时，出发口可与到达口不同，即使到达口可能位于出发口正下方，但坐标相同。

图5所述示意图描述根据缓冲区和其中的地理位置坐标建立可接受范围。该图显示指定位置500及其相关坐标。在本图中，基于距离404的可接受范围是根据离指定位置(500)150英尺范围的预定规则建立的。该图显示了两个合格的地理位置502和503的例子，司机如果在这两个位置接送乘客，则可对其地理位置进行自动调整。由于这两个位置在可接受范围内，所以是合格的地理位置。另一个地理位置504不是合格的地理位置，因为其不处于基于距离404的可接受范围内，其不在距离指定位置150英尺距离范围内。在此情况下，如果司机让乘客在该位置下车，则可能无法对该地理位置进行自动调整以匹配指定的位置500。

应当理解的是，车辆400的坐标信息可由地理位置识别器111自动捕获并通过计算机网络116发送到服务器100，作为自动生成和发送的所提交的账单/***/保险的一部分。根据本发明示例性实施例之一，司机模块105可并入类似出租车计价器中，使其在提交电子结算验证时免受篡改，因为GPS数据和时间戳数据是从出租车仪表直接获取的。

图6为一个示意图描述司机在其计算机设备110上可能收到的信息，如果司机试图提交结算请求的话，即使司机不在基于距离404的可接受范围内。在此情况下，司机将会收到信息600，通知其距离指定地理位置和/或指定位置不够近，无法进行自动调整。这将促使司机将车辆驶近指定的地理位置(如果可疑的话)。如果司机无法将车辆靠近，则进一步确定司机无法到达指定地理位置的原因的有效性，以加快结算请求的审查过程。因此，可以提示司机拍摄街道601的照片并通过用户参与板块115提交一个或多个原因，用户参与板块115可由具有第一手经验的一个或多个其他用户查看，以验证司机提交的信息的准确性。与服务提供者或供应商相关的结算员也可在司机对拒付提出上诉的情况下，审查结算相关数据(例如结算请求和/或一张或多张含元数据的照片，包括时间戳和地理标注信息或地址信息)，服务提供者可以通过至少确认司机的地理位置来确定司机提交内容的有效性。

司机接送乘客的意图可自动识别或由司机进行人工识别，由司机自行决定。如果采用自动识别，则该意图可以至少通过加速计和/或速度计124对车辆的速度和速度变化加以分析。该加速计和/或速度计124可连接司机模块105，前述速度和速度变化与预定的司机与指定地点的接近度相关，与预定的接近度可通过地理位置识别器111加以确定。该预定接近度是指到指定位置的预定距离，司机可以预设预定距离，或者预定距离也可基于***默认。速度计可测量车辆的瞬时速度，加速计可测量车辆的速度变化，而速度和速度变化可以部分用于识别意图-例如，通过加速计记录司机正在减速，而加速计与速度计相关，速度计表示司机正以每小时2英里速度行驶，这时***会收到提示，司机可能打算让乘客下车。对于接近度的分析还可与时钟113所识别的时间一起使用。由于电子地图或数字地图或第三方地图应用程序编程接口可集成在***中，如果车辆因交通拥堵或其他原因减速或停在道路中央，且距离指定地理位置太远或距指定时间太长的话，通过GPS坐标和速度数据该地理位置，***将不会将其作为预期上车或下车地点。为确保司机事实上有意接送乘客，即使该意图已被自动识别，***也可提示司机确认其接送乘客的意图。

当***通过手动输入确定了司机意图时，司机可按下司机计算机设备110上的按钮，例如移动设备，该设备通过特定的编程通知***司机接送乘客的意图，或者***可结合语音识别功能，通过一个或多个麦克风识别司机的意图。例如，司机可能会输入语音命令“请接受我让乘客上车的意图(上客)。”司机还可设置当其距离指定位置某个预定的距离或接近度时(例如60英尺的距离)通知***其上客或下客的意图。

当自动或手动识别到司机意图(例如，上车意图或下车意图)后，可确定司机是否在可接受范围内。如果确定司机在可接受范围内，则可自动生成和调整结算请求。如果确定司机有让乘客上车或下车意图并在可接受范围之外，则***可以向司机发出通知，提示司机更接近指定地理位置。如果司机在提示后无法靠近指定地理位置，则***可向司机发出条件拒绝并提示通过用户参与板块115提交结算相关数据。但是，如果司机经提示后接近指定地理位置，并且确定当前处于可接受范围内，可进行自动调整。因此，此类提示可帮助司机通过用户参与板块115提交结算相关数据后避免收到条件性拒绝，这样可节省处理结算请求的时间和资源。

本领域普通技术人员应理解，关于司机在可接受范围之内或之外的提醒可基于用户的偏好进行设置。司机也可以选择不接收此类提醒通知。供应商也可选择是否使用该功能。

通过整合乘客验证信息(例如乘客签名，乘客指纹，乘客密码输入等)来确认司机的地理位置。此外，乘客验证也有例外情况，比如乘客因残疾或其他情况无法在行程完成后签名。在此情况下，可以由诸如保姆或乘客的家人等来帮助签名或验证。如上所述，乘客验证可以在服务开始时，服务期间或服务结束时进行。乘客的验证可以在司机模块105，乘客模块120，专用设备上，或者甚至在为乘客专门提供的模块上进行收集。此外，这些概念可用于多个分车程或甚至多位乘客的行程，而司机可表示其打算让某位乘客下车而不是让另一位乘客下车，或其打算再接一位乘客。当一位或多位乘客在同一地点上车或下车时(例如，一个家庭的多个成员，去同一个医院的乘客等)，信息可包含一个或多个服务请求的信息，以便该司机区分并正确执行这些服务请求。在多乘客行程中，服务提供者可能需要提供一个或多个正在执行的服务请求的可接受范围信息。该司机可接收的信息可以按顺序发送或基于其相关性进行整理。例如，车内有两名乘客，乘客1和乘客2：乘客1目前正在下车，而乘客2将在5英里内下车。如果该司机不在基于乘客1服务请求的地理位置的可接受范围内-但仍试图让乘客1下车，则司机收到的信息只可能是有关乘客1而不是乘客2的特定服务请求。

图7所述示意图描述司机通过用户参与板块115提交结算相关信息的预览图，用于证明其无法到达一个或多个可接受范围内。该图中，司机计算机设备110在用户参与板块115上显示对司机提交信息的预览700。该司机可输入无法到达可接受范围的一个或多个原因701。在该例中，该司机输入了西50街正在施工的信息，并提供施工现场702的照片。然后，该司机可点击“提交”按钮703，通过用户参与板块115提交该信息，以供具有第一手经验的其他用户进一步验证。

图8所述示意图描述司机在司机计算机设备110上收到的无法进入基于时间的可接受范围的信息。当司机即将迟到或者当其指示将无法按时接到乘客或放下乘客时将显示该信息，这种情况下司机无法处于基于时间的可接受范围内。在移动设备的显示器上显示信息800，通知该司机将晚于指定上车时间到达。该信息可表示该司机未能到达基于时间的可接受范围内。该信息可提示司机点击“下一步”按钮801，此处“下一步”按钮801位于交互式触摸屏显示器上，该按钮可将司机带入用户参与板块115界面，在该界面，司机可输入有关迟到原因的详细信息。

图9所述示意图描述司机计算机设备110上的可能界面，用于输入其无法到达基于时间的可接受范围的一个或多个原因。***可提示司机在文本区902中键入原因。在该例中，文本区901中的标题将提示司机提供其迟到的原因。然后，司机可以在文本区902中输入或口述原因，并可通过点击“提交”按钮903提交这些原因。为了最终确定结算请求，司机须输入这些原因，因为，如果每个未能满足有关可接受范围的规则规定的结算请求都附有司机提供的原因的话，结算审查过程将会相对容易些。

图10为示意图，显示用户参与板块115的可能界面。对用户参与板块115的访问可通过用户计算机设备1000实现，用户可以是司机。关于由司机通过用户参与板块115提交的结算请求的信息可基于用户当前位置或附近位置1001，或者基于照片1002，以及由***提示司机提供的一个或多个原因。通过用户参与板块115，用户可通过点击“是1003”确认或通过点击“否1004”拒绝，基于用户根据第一手经验确定所提供的原因是否准确来进行投票。如果存在投票争议(例如，当确认达到预定数量的正面评价，但也存在预定数量的负面评价)时，该案例可由相关方进一步开案和审查，相关方可以是与服务提供者有关的结算人员或供应商或其代理商的结算人员。对案例的审查可通过提供任何能补充的信息，这些补充信息包括例如一张或多张地理标记照片或乘客验证信息。用户还可为评价1005提供一个或多个原因。如果用户不能确认或否认一个或多个原因，则用户可单击“跳过”按钮1006。任何有第一手服务请求、地理位置或时间经验的用户，无论是服务提供者，司机，供应商还是其他，都可以通过用户参与板块115提供数据。如果确定任何众包数据或信息有用，无论通过通知其他用户或其已经收到预定数量的正面评价，则可奖励提交该信息的用户。奖励可以是货币或非货币形式，例如礼品等。这种奖励可激励用户使用用户参与板块115提交相关信息。

图11所述示意图说明与基于距离404的可接受范围相关的数据表1100，描述如何在结算验证***内收集数据并通过用户参与板块115或服务提供者模块104上的其他地方向服务提供者显示数据。例如，表1100包含与结算请求相关的地理位置数据，并具体描述下车信息。最左边一列显示行程ID信息1101。每个指定下车地点的坐标1102也予显示，该坐标可从每个输入地址中检索并将地理编码转为地理位置坐标。此外，还显示实际下车地点1103的坐标。最右列显示坐标之间的偏差1104，该偏差可表示实际下车地点是否处于可接受范围内。该图还显示如果图中地点处于可接受范围内，则结算***将不予警示。然而，表中一个结算请求记录的旁边的确有一个指示符1105，因为下车地点的偏差太大。这可以作为服务提供者在某些情况下打开关于该信息的案例审查的视觉提示。服务提供者可通过点击提示符1105核查产生这种偏差的原因，指示符1105可以调出用户参与板块115的另一个界面，显示关于结算请求1106的更全面的信息。该图还显示司机，司机的照片，姓名以及司机ID。司机详细信息1107也将显示，其中行程ID，乘客ID以及指定和实际的下车地理位置被转换为人类可读地址1108。此外，详细信息还包括由司机提供的说明，说明其在不同于指定地点的位置让乘客下车的原因1109。依照示意图，司机提供的原因是西50街正在施工，所以必须到其他地方让乘客下车。司机还上传照片1110，显示街景中有施工现场作为其证据，其中照片可附上地理标记信息和时间信息，以提供证据证明司机的理由合理。

图12进一步显示用户参与板块115的潜在界面图，描述关于结算请求1106的综合信息，该信息可在服务提供者模块104上访问。当结算请求被标记审查或争议时，可由计算机设备或服务提供者进行审查和确认。在审查过程中，如果点击“查看更多信息”按钮1202，则可在其他显示界面1201上获得详细信息。该显示界面可显示乘客签名以及其他相应信息1203，包括签名的地理标签和时间戳。乘客验证信息可包括指纹，虹膜扫描或可实施的其他类型的物理验证。另外，验证信息可通过电子邮件或SMS代码进行双重身份验证等。在该显示界面上，还可显示从照片1204挖掘的数据和信息，这些信息可包括时间，人类可读位置，以及照片的地理位置坐标以及拍照人。乘客确认的地理位置或时间也可做为分析可接受范围的基础，可接受范围是基于乘客的位置，该位置可通过乘客的移动设备获得。指定的地理位置和与照片相关联的地理位置之间可能存在偏差1205，这可帮助***或服务提供者基于距离404确定司机未能进入一个或多个可接受范围的原因的有效性。

图13示意图描述与基于时间的可接受范围相关的数据库。这可通过用户参与板块115提供给服务提供者。图中描述对应于特定行程ID 1300的数据表。与每个行程ID相关的是在各列中显示的与行程ID相关的信息。其中指定的上车地址1301，指定的上车时间1302，实际上车时间1303，以及偏差值1304，该偏差基于指定的上车时间和实际上车时间之间的时间差。行程ID中前四个行程显示的偏差比较小，分别为52秒到2分21秒；最后一个行程ID显示的偏差超过55分钟。服务器100可通过用户参与板块115提示司机提供一个或多个原因，比如由于时间偏差太大无法到达可接受范围内，因此无法进行自动调整。该结算请求可由提示符1305进行标记，该提示符1305可提示通知服务提供者或其他相关方注意某些情况。其发生的时间点为:在预定时间内，通过用户参与板块115提交的一个或多个理由收到了预定数量的评价之前或之后。当服务提供者或其他相关方审核结算请求细节的情况下，用户通过点击提示符1305可以做这样的检查，提示符1305可以显示详细的司机信息1106和有关结算请求1306的进一步细节，以及司机因迟到提供的原因1307--在该例中，司机表示，前面的行程耽误了时间，且通往乘客上车地点的路线有严重交通拥堵。

图14所述示意图显示存储在数据库103中的数据，以及这些数据在数据库中的组织整理方式。可使用多种方法提供数据库和数据存储介质，用于整理和检索特定数据，本发明的示例性实施例适用于任何适当的数据库或存储方式。在一些实施例中，可远程定位和访问数据库103。此外，可以理解的是，这里所说的数据库103可包括但不限于数据存储介质，无论是结构化的还是非结构化的，关联的，或其他类型的。当预订服务和完成服务时可动态更新数据库103。数据库103可存储已经请求和完成的每个服务请求的索引，包括乘客和司机的登记号或用户身份标识。如果需要，可在任何时间检索该登记号或用户身份标识。数据库103还可为每个特定的司机，乘客，供应商或服务提供者存储服务请求或结算请求的细节以供将来参考。数据库103可包含服务请求数据1400，例如服务请求是何时何地提出的，提出服务请求的人，提供服务请求的人，乘客就诊的医生姓名等。此外，通过用户参与板块115(用户参与板块数据1401)提供的数据可依照数据自身的类别进行存储，并可划分为子类别。

可通过手动方式，如在计算机设备上输入关键字段，提供全部或部分服务请求数据1400，当然也可通过自动方式提供。也可上载或导入以前提供的或在其他地方提供的，与乘客有关的数据。服务器100可通过编程生成行程标识符(“行程ID”)，并将该标识符分配给服务请求。这样做是为整理数据库103中的数据以及对服务请求进行整理。对服务请求数据1400进行整理以及为每个服务请求分配行程ID，以应对潜在的争议或审计，例如司机针对拒绝的结算请求提出上诉的情况。行程ID可以是字母，数字或字母数字，可随机生成或基于加密或未加密的密钥生成。例如，可根据重要的服务请求数据对在特定日期从A点到B点的司机进行编目分类。例如，服务请求细节可包含在行程标识符内，有一种算法可将其转换为基础数据。行程标识符可用于直接对数据库103中的相关数据进行编辑。

此外，服务请求数据1400可包括乘客姓名，证件号码，出生日期以及乘客就诊的医生或机构名称，相关ID和地址，以及司机的姓名，ID和地址等。此外，还可包括已经请求或预授权的医疗护理或服务代码，以及授权请求提交和/或发出的日期。其中一些信息可能只对某些方可见；例如，某些受保护的健康信息或其他机密信息可能无法供司机使用。一些潜在的有争议的案件可能与授权信息有关，因为在某些情况下，超过指定时间后授权将会失效，且司机在有效日期之后提供服务将无法获得偿付。服务请求的预授权适用于非紧急医疗运输业。例如，许多供应商为某些乘客提供常规订单，这些订单是基于每个相同的交通运输服务请求安排的经常性预约。对于本领域普通技术人员来说，常规订单及其相关细节通常是提前知道的，安排的服务请求可使用关于先前输入的相同或类似信息(例如，对于在发生在同一地点的每周两次的预约，从乘客家出发到同一个诊所)。此外，供应商可能对如何执行服务请求有一定的规定，且他们提供输入这些规定的方法。这可包括定义可接受范围大小的规定。

服务器100可包括验证***和一个或多个接口，在一些示例性实施例中，这些接口被配置为通过电子数据交换(EDI)从供应商诸如经纪人或保险公司接收数据，数据可存储于数据库103中。在一些实施例中，验证***连接行程安排信息，行程安排信息包括指定的地理位置和指定时间。

数据库103还可存储地理位置调整数据1402，例如指定的和实际的地理位置以及每个地理位置的缓冲参数和/或可接受范围。另外，数据库103可存储时间调整数据1403，还可存储关于缓冲区参数和/或与时间调整相关的可接受范围数据。数据库103还可存储服务提供者数据1404，供应商数据1405，司机数据1406和乘客数据1407。这些数据可反映每个用户生成的任何和所有记录，包括个人资料，服务请求历史，结算请求历史等。数据库103可存储结算请求数据1408，数据库103可被配置为对限定可接受范围的预定规则1409进行分类，这些规则可与某些服务请求，一个或多个位置或时间，一个或多个供应商相关联。通过这种方式，服务器100可在必要时从数据库103检索适用的预定规则。另外，数据库103可存储所有用户的注册数据1410。另外，数据库103可存储地图组件数据1411，这些数据可供查询并用作地理信息***102的地图或其他相关目的。地图组件数据1411可包含从诸如谷歌地图的第三方地理编码应用程序编程接口检索的数据。此外，数据库103还可被配置为存储与管理数据1412中的***管理有关的数据，以及与电子结算验证有关的任何其他数据1413。

如果是关系数据库，则该数据库表与其他数据表之间的关系可能是，例如一对多关系，多对多关系以及与一对一关系。每当***从供应商或司机那里获得输入或请求时，服务器100可先打开通向数据库103或相关数据库中心的安全访问通道，然后通过访问通道将查询语句发送到数据库管理模块。根据下面描述的数据库表之间的关系，数据库管理模块可完全遵循查询语句，通过连接两个或多个数据库表，或也可不连接数据库表，并通过使用表的ID，表名和列名来查找特定的数据库表。对于管理模块，则完全遵循查询语句，并通过使用查询语句提供的密钥查找特定数据。无论是关系数据库还是非关系数据库，在服务器100，通过数据库管理模块或通过其他方式检索到目标数据之后，将通过安全的访问通道将搜索结果发送回服务器100。然后关闭安全通道，直到下次再次打开。

本领域技术人员应该理解，一旦数据变化或更新，数据库103即可进行动态更新和同步；服务器100可动态更新数据以反映最新变化，例如有关可接受范围的预定规则的变化，乘客地址，供应商信息，新数据或从用户参与板块提交的信息(例如，来自用户的众包信息)等的变化。此外，如果某些数据或对数据的更新被证明是错误的，可提供一种方法将这些数据更改回原来的状态。可将数据以某种方式进行整理或构造以便有效分类和检索。在另一示例性实施例中，数据可以以非关系或非结构化方式存储。本领域普通技术人员将理解，有很多方法可用于为数据库或其他数据存储介质提供，存储和整理数据，本发明的示例性实施例可与任何适当的数据库或数据存储介质一同使用。此外，可至少设有一个备份数据库对主数据库的数据进行备份，以防止数据丢失。备份数据库中与数据库103相关的数据也可根据数据库的变化而改变。

图15所述示意图，说明由地理信息***102执行的潜在地理编码处理功能。地理信息***102接收输入数据1500，这些数据可以是由司机模块105或供应商模块106提供的地理位置坐标。在其他实例中，输入的信息可以是服务请求中提供的地址。地理信息***102可捕获，显示和分析数据，并可集成电子或数字地图以便在计算机设备上进行查看，如智能电话，门户网站等(诸如谷歌地图)。通过集成，可至少根据地图数据显示道路情况。地理信息***102可集成不同的层级，而具有相似属性的数据点可被分离并作为层级输出。该输出层级将显示有类似属性的所有数据点。地理信息***102可安置在服务器100上，也可单独与一个或多个服务器共享通信连接，例如有线或无线连接。通过该连接，可以发送诸如结算请求或服务请求规则之类的信息。地理信息***102可使用缓冲工具1501和/或接近度分析来建立可接受范围，并且与第三方地理编码应用程序编程接口1503连接(例如，谷歌地图或公开地址，全球地址应用程序编程接口将地址转换为坐标以及将坐标转换为地址。处理器123可建立可接受范围，无论是否借助地理信息***102。基于数据输入和输出需要，地理信息***102可生成输出1504，服务器100或其他相关***组件可通过通信方式共享该输出。

地理信息***102可与服务器100，非暂时性计算机可读存储介质101和数据库103一起使用，用于捕获，显示，存储，管理和分析地理信息。为完成某些查询操作，地理信息***102可从数据库103中提取和分析数据。数据库中存储的数据由数据库管理***进行管理。地理信息***102可用于将数据进行可视化处理，从而提供一种方式对数据进行排序，访问和查看。地理信息***102包括下述重要组件，以便有效地执行其基本功能，这些组件包括：硬件，需要中央计算机或可促进地理信息***102功能的该计算机的任何辅助设备；软件：使用可执行编程语言编写的运算法，用于存储，分析和显示地理数据和信息；以及数据：任何需要分析的信息，如上车地点，下车地点，路线等。地理信息***102由技术人员或其他了解如何正确维护程序的合格人员进行维护。地理信息***102的不同类别或型号也可用于不同的应用程序。例如，可能需要使用诸如现场模型的地理信息***来分析在连续的区域内发生的数据变化。可用离散模型分析与二维空间中的点相关的数据。最后，可用网络模型来分析由一系列点连接的两个点，例如沿高速公路或一般道路的点。

如上所述，车辆400可包括安装在车内的司机模块105，例如，防篡改结算验证设备的一部分。该结算验证设备可接收来自车辆驾驶员的输入，该输入信息包括乘客的医疗保险信息，或者乘客可访问安装在车辆400后座区域的终端(可与设备通信)，乘客可使用该终端提供健康保险信息(或其他付款人信息)并确认下车地点和时间。到达下车地点时，结算验证设备可最终确定行程，时间戳和地理位置信息记录，使用例如集成到结算验证设备中的蜂窝无线电，自动将记录发送给指定的保险公司或其他付款人。服务器100可由保险公司/付款人或由中介实体进行维护，该实体可将***记录重新格式化成保险公司/付款人期望的正式提交格式，并通过电子提交发送给适当的保险公司/付款人。GPS坐标/时间戳数据可作为正式提交文件的一部分，并可根据上述方法确定是接受还是拒绝提交。可使用一种或多种加密技术将记录传送到一个或多个服务器，以及从一个或多个服务器传送给保险公司/付款人，以便对依照1996健康保险便利和责任法案(HIPAA)和其他类似法律法规要求的方式对敏感医疗数据进行保密，这些敏感数据包括患者约诊的地点和时间等。

通过该种方式，本发明的示例性实施例可提供一种用于非紧急医疗运输的医疗运输车辆，其可自动向保险公司或其他付款人发送电子提交文件。

这里描述的示例性实施例是说明性的，在不背离本发明的精神或本申请后附的权利要求的范围的情况下可以引入多种变更。例如，在本发明的范围内，不同示例性实施例的元素和/或特征可彼此组合和/或替换。因此，没有描述这种组合并不排除本申请对这种组合的权利。尽管本申请参考附图对一些实施例进行了详细描述，但是应该理解的是，本申请所述的概念并不受这些实施例的限制。因而，本发明旨在使用下述权利要求及其同等文件对这些概念的范围进行限定。

Claims (30)

1.一种为交通运输服务提供自动计算机验证的计算机执行***。该***包括：

一个计算机***，包括一个或多个数据库，其中数据库配置在与通信网络连接的一个或多个服务器上；

一个供应商模块，配置为发送服务请求，为乘客提供服务，所述服务请求包括下述中的至少一个：乘客上车时间、乘客上车地点、乘客下车时间或乘客下车地点；

一个服务提供者模块，配置为从所述供应商模块接收所述服务请求、将所述服务请求调派给司机，并将所述服务请求发送给所述司机；

一个司机模块，配置为接收所述服务请求、生成结算请求并将所述结算请求发送到所述服务提供者模块；以及

一个非临时性计算机可读存储介质，用于存储指令，指示一个或多个处理器进行下述操作：

由所述服务提供者模块通过多个计算机设备中的至少一个设备接收来自所述供应商模块的所述服务请求；

由所述服务提供者模块将所述服务请求发送到所述司机模块；由所述司机模块生成述结算请求；

将所述服务请求与所述结算请求进行比较；

识别该司机或该乘客在结算请求生成时是否处于可接受范围内，所述可接受范围基于一条或多条预定规则，这些规则至少具有以下特点之一：(i)距离上车地点的预定距离(ii)距离下车地点的预设距离，(iii)相对于所述上车时间的预定时间，或(iv)相对于所述下车时间的预设时间；以及

如果识别到所述司机或所述乘客在所述可接受范围内，则确认所述服务请求完成。

2.根据权利要求1所述***，其中所述一个或多个处理器被配置为：

在生成所述结算请求之前，确定下述中的至少一项(a)实际上车地理位置、(b)实际下车地理位置、(c)实际上车时间，或(d)实际下车时间；以及

在所述结算请求中包括至少下述中的一项(e)所述实际上车地理位置，(f)所述的实际下车地理位置，(g)所述实际上车时间，或(h)所述实际下车时间。

3.根据权利要求1所述的***，其所述可接受范围涉及时间以及地理位置或地址中的一个。

4.根据权利要求1所述***，所述结算请求至少包括一个或多个上车地点、上车时间、下车地点或下车时间。

5.根据权利要求1的***，所述***进一步包括：

一个乘客模块，其配置为发送来自所述乘客的信息，以便确认所述司机完成所述服务请求；

其中，所述信息至少包括下述中的一项：签名、密码、指纹、其他生物数据或用于确认所述乘客的所述结算请求的任何其他方法。

6.根据权利要求5的***，其中所述信息至少包括时间戳或位置数据，并在所述服务开始、结束或与所述服务有关的任何其他时间提供。

7.根据权利要求1所述***，其中用于进行比较的指令包括对下述中的一个或多个进行比较以确定所述司机是否处于所述可接受范围：(a)所述上车地点和实际上车地点，(b)所述下车地点和实际下车地点,(c)所述上车时间和实际上车时间，或(d)所述下车时间和实际下车时间。

8.根据权利要求1所述***，其中所述一个或多个处理器被配置为：

识别所述司机接载所述乘客上车的意图，或所述司机让乘客下车的意图；

提示所述司机确认所述上客意图或所述下客意图；

确定所述司机或所述乘客是否处于所述可接受范围内；及

提示所述司机：所述司机或所述乘客是否位于所述可接受范围内；

其中，所述上客意图或所述下客意图是基于所述司机距离所述上客地点或所述下客地点某个预定距离范围内的预定速度。

9.根据权利要求8所述***，其中，在确认所述上客意图或所述下客意图后，所述一个或多个处理器被配置为提示所述司机其未能处于所述可接受范围内。

10.根据权利要求8所述***，其中，所述一个或多个处理器配置为：

在确认所述服务请求完成后，调整所述结算请求以匹配所述服务请求；或

基于所述司机未能处于所述可接受范围内的事实对所述结算请求进行有条件拒绝。

11.根据权利要求1所述***，其中，所述一个或多个处理器被配置为：

当司机未能到达所述可接受范围内时，提示其通过所述多个计算机设备中的至少一个提交所述结算相关数据；

从结算相关数据中挖掘时间戳或地理位置；并且

用所述结算相关数据动态更新所述一个或多个数据库；

其中，所述结算相关数据包括在试图完成所述服务请求时未能到达所述可接受范围的一个或多个理由，所述一个或多个理由至少包括下述中的一项：文本数据、音频数据、图像数据或视频数据。

12.根据权利要求11所述***，其中，所述一个或多个处理器被配置为：

通过所述多个计算机设备中的至少一个，从对所述结算相关数据有第一手经验的一个或多个用户处接收所述结算相关数据的一个或多个验证；

其中，所述第一手经验是这样确定的：所述一个或多个用户曾去过离一个或多个实际地理位置某个预定距离范围内，所述实际地理位置基于所述结算数据。

13.根据权利要求11所述***，其中，所述一个或多个处理器被配置为：

当所述结算相关数据在预定时间内达到预定数量的正面评价时，调整所述结算请求，使其与所述服务请求相匹配；且

动态更新所述可接受范围。

14.根据权利要求1的***，其中，所述一个或多个处理器被配置为：拒绝对所述结算相关数据作出响应的所述结算请求，所述数据未能在预定时间内接收到预定数量正面评价。

15.根据权利要求1所述***，其中，所述一个或多个处理器被配置为：

通过所述一个或多个计算机设备，从对所述结算相关数据有第一手经验的一个或多个用户处收集众包结算相关数据。

16.根据权利要求15所述***，其中，所述一个或多个处理器被配置为：

基于所述结算相关数据和所述众包结算相关数据动态更新所述一个或多个数据库。

17.根据权利要求1所述***，其中，所述可接受范围至少具有以下特征之一：初步可接受范围、永久性可接受范围或暂时性可接受范围；以及

在所述初步可接受范围、所述永久性可接受范围或所述临时可接受范围三者中，依次只能有一个为有效状态。

18.根据权利要求17所述***，其中，所述一个或多个处理器被配置为：

基于一个或多个预先确定的默认参数，将所述可接受字范围确定为所述服务请求的所述初步可接受范围。

19.根据权利要求17所述***，其中，所述一个或多个处理器配置为：

通过所述一个或多个用户参与板块收集所述结算相关数据；并根据所述结算相关数据，基于所述预定规则将所述初步可接受范围重新定义为所述永久性可接受范围；

其中，所述永久性可接受范围的特征为其处于完全活跃状态，以及

所述初步可接受范围和所述临时可接受范围的特征为其处于不活跃状态。

20.根据权利要求17所述***，其中，所述一个或多个处理器被配置为：

基于司机在所述位置的所述永久性可接受范围之外完成服务的预定数量，将所述可接受范围描述为所述临时可接受范围；以及

基于司机在所述临时可接受范围内完成所述服务的数量，将所述临时可接受范围重新定义为新的永久性可接受范围。

21.根据权利要求17所述***，其中所述一个或多个处理器被配置为：

基于司机在所述位置的所述永久性可接受范围外完成服务的预定数量将所述永久性可接受范围描述为半活跃；

其中，所述永久性可接受范围保持半活跃状态，直到：(a)所述临时性可接受范围转换为所述新的永久性可接受范围；或者(b)至少有一个上述司机在上述半活跃可接受范围内完成上述服务。

22.根据权利要求17所述***，其中，所述一个或多个处理器被配置为：

动态变更可接受范围的性质：

(a)从所述初步可接受范围变更为所述永久性可接受范围，

(b)从所述永久性可接受范围变更为所述临时可接受范围，或

(c)从所述临时可接受范围变更为永久性可接受范围，

以上变更是基于下述中的一项进行的：

(d)从距离上车地点和下车地点某个预定范围内的多个远程计算机设备接收的结算相关数据，

(e)在所述永久性可接受范围外完成服务请求的司机的第一个预定数量，或者(f)在永久性可接受范围内完成服务请求的司机的第二个预定数量。

23.根据权利要求1所述***，其中，所述一个或多个处理器被配置为：当所述乘客未能在预定时间内确认所述服务请求时，确认所述乘客未出现在所述上车地点。

24.根据权利要求23所述***，其中，所述一个或多个处理器被配置为：追踪所述司机在所述上车地点等待所述乘客的时间；

接收所述司机联系所述乘客的证据；以及

将所述证据发送到所述服务提供者模块，并至少提供所述结算请求的一部分，以验证所述乘客未露面。

25.根据权利要求1所述***，其中，所述一个或多个处理器被配置为：从所述多个计算机设备接收结算相关数据，这些计算机设备位于离所述指定上车地点某个预定的距离范围内，或位于距离所述指定下车地点某个预定距离范围内；

将所述结算相关数据存储于所述一个或多个数据库中；以及

根据所述结算相关数据动态更新所述预定规则。

26.根据权利要求1所述***，其中，所述结算相关数据至少包括下述中的一项(a)对应于一个或多个地理位置的多个GPS数据，或者(b)对应于传送所述结算相关数据的一个或多个时间的时间数据。

27.根据权利要求26所述***，其中，所述一个或多个处理器被配置为：使用所述多个GPS数据连续识别所述多个计算机设备是否处于离所述上车地点某个预定距离范围内或离所述下车地点某个预定距离范围内；

其中，所述结算相关数据是连续执行的。

28.根据权利要求27所述***，其中，所述结算相关数据包括与至少下述一项相关的信息：交通密度、人口密度、施工路障、道路关闭、车道关闭、天气条件、停车限制、道路规则、建筑工地、临时路障、特殊安全事件、游行、集会、抗议活动。

29.根据权利要求1所述***，所述***进一步包括：

一种地理感知相机，配置为使所述司机能够捕获数据并作为结算相关数据信息提交给所述***，提交的这些数据信息表明司机无法到达所述可接受范围的原因。

其中，所述多个计算机设备被配置为使一个或多个用户能够对所述结算相关数据进行正面评价或负面评价。

30.一种为交通运输服务提供自动计算机验证的方法，所述方法包括以下步骤：

由服务提供者模块通过多个计算机设备中的一个接收来自供应商模块的服务请求；

将所述服务请求分配给司机；

由所述服务提供者模块将所述服务请求发送到司机模块；根据所述司机模块生成结算请求；

将所述服务请求与所述结算请求进行比较；

确定生成结算请求时所述司机或乘客是否处于可接受范围内，所述可接受范围基于一个或多个预定规则，这些规则至少具有以下特征之一(i)距上车地点的预定距离(ii)距下车地点的预定距离，(iii)相对于上车时间的预定时间，或者(iv)相对于下车时间的预定时间；以及

基于所述司机或所述乘客是否处于所述可接受范围内，确定所述服务请求是否完成。

Images