用于对车辆选择路线并且安排车辆搭乘的系统和方法与流程
本申请要求2017年1月30日提交的标题为″vehicleroutingproblemwithprescheduleddrivermatchwithinventoriedrides″的第62/443,339号美国临时专利申请的优先权，通过引用将该美国临时专利申请的内容并入本案。
本公开涉及车辆调度，并且更具体地说明涉及用于对车辆选择路线并且安排车辆搭乘的系统和方法。
背景技术：
传统的拼车服务通常取决于利用私有车辆对希望从一个地点行进到另一个地点乘客提供服务的驾驶员。一些传统的拼车服务为在线零售商递送包裹及递送从餐馆订的餐，存在某些可能妨碍传统拼车服务的有效性的因素。例如，在客户使用拼车服务开始搭乘之前，拼车服务不知道客户何时会请求搭乘，此外，拼车服务也不知道乘客需要在哪里搭乘，无法回答这些问题使得拼车服务不能知晓预定地点需要多少车辆，并且这可能导致客户乘车等待时间的延长。当特定地点没有足够的车辆或没有安排足够的车辆时，这最终可能会降低拼车服务的有效性，并且当驾驶员不能快速并且有效服务客户时，司机的收入将减少。
例如，潜在乘客可能想要一辆车，或者包裹递送人和收件人可能需要由快递服务来提供包裹递送服务。在这两种情况中，可将潜在乘客和包裹递送人或收件人统称为″乘客″或″搭乘人″。此外，在这两种情况中，乘客或包裹递送人或收件人都试图利用也称为″tnc″或运输网络公司的拼车服务安排“搭乘″。一般来说，这些乘客或搭乘人正在彼此大约10英里的半径内等待。从每个乘客或搭乘人需要搭乘车辆的时间到车辆到达的时间或需要快递服务提供服务的时间，每个乘客或搭乘人可能愿意等待至多约15分钟的时间。tnc能够管理或辅助管理平台或网络而为驾驶员和乘客提供服务，tnc可能希望为所有乘客提供服务，但tnc不确切知道每个乘客何时通过平台或网络请求搭乘，tnc也不确切知道每个乘客需要在何地搭接或在何地需要快递服务提供服务。因此，乘客或搭乘人通过平台或网络决定搭接的或包裹递送的时间和地方后，tnc就可决定在10英里半径内及周围保留约100辆车，以尽量快速满足每个乘客或搭乘人的需求。
一般来说，传统的tnc不拥有车辆，但是独立驾驶员拥有并且运营为tnc提供服务的车辆。因此，一般来说，tnc不关心运营车辆的成本，包含不关心空载里程，也不关心100辆车辆中的每个车辆为了被派往等待的乘客或搭乘人而需要在周围等待的时长。对于传统的tnc，主要关心(1)尽可能快速地满足每个乘客或搭乘人对可承受的搭乘或包裹递送的请求，以及(2)确保tnc有足够的车辆满足tnc的需求，从而满足最初的关心。
对用于对tnc的乘客或搭乘人提供服务的平台或网络进行管理的传统tnc存在许多缺陷。
技术实现要素：
本公开的实施例涉及用于对车辆选择路线并且安排车辆搭乘的系统和方法。此外，本公开的特定实施例可涉及用于对车辆选择路线并且安排与包裹递送关联的车辆搭乘的系统和方法。
根据本公开的一个示例性实施例，能够提供用于对车辆选择路线并且安排车辆搭乘的系统和方法。例如，假定在互相10英里的半径内有50个潜在程控或包裹递送收件人(此外，统称为″乘客″或″搭乘人″)，并且每个乘客或搭乘人要车或者需要具有包裹递送的快递服务提供服务。对于搭乘或快递服务提供服务，每个乘客或搭乘人可通过在特定截止时间之前经tnc平台或网络指出愿意等待车辆至少15分钟。tnc获知每个乘客或搭乘人还准备好在搭接之前提供确切地点和具体搭接时间或递送时间。在该例中，tnc事先知晓50个乘客或搭乘人中的每个的确切搭接或递送时间和地点。由于对此知情，所以tnc能够确定为50个乘客或搭乘人的车辆需要提供服务仅需要18个车辆，并且全部18个车辆不必都在10英里的半径内和周围等待。即，tnc能够时进时出地对18个车辆中的每个进行安排、排序和选择路线，以满足50个乘客或搭乘人的需要。
由于tnc可不拥有车辆，并且独立驾驶员拥有并且运营为tnc网络提供服务的车辆，所以tnc可能关心驾驶员各自运营车辆的成本，包含关心将无载英里数降低到最小，并且tnc还可关心对其提供通过tnc平台或网络请求车辆的乘客或搭乘人的每个车辆在周围等待的时间长度。因此，tnc能够(1)在要求的确切时间和地方满足每个乘客对付得起的搭乘或递送的请求；并且(2)针对乘客需要在何时和何地提供服务，将每个驾驶员的不确定性降低到最小，使得最小化或减小每个车辆的运行成本。
根据本公开的一个示例性实施例，能够提供用于对车辆选择路线并且安排车辆搭乘的系统。该系统可包含：计算机处理器，该计算机处理器可操作地执行计算机可执行指令；以及存储器，该存储器包括计算机可执行指令。该计算机可执行指令能够可操作地接收一个或者多个驾驶员输入，该驾驶员输入包括每个驾驶员的开始时间、每个驾驶员的结束时间、每个驾驶员的开始地点、以及每个驾驶员的结束地点。该指令还能够可操作地接收一个或者多个车辆搭乘请求，该请求包括每个搭乘的开始地点和每个搭乘的结束地点。此外，该指令能够可操作地对于第一驾驶员，在预定截止时间之前并且至少部分地基于第一驾驶员的开始时间和第一驾驶员的结束时间，生成第一驾驶员的车辆搭乘的顺序目录。此外，该指令能够可操作地在预定截止时间之前，确定第一驾驶员的开始时间与第一驾驶员的结束时间之间的潜在收入每小时增量。此外，该指令能够可操作地至少部分地基于元启发式算法(metaheuristicalgorithm)的执行并且在预定截止时间之后，修改第一驾驶员的顺序目录。该指令还能够可操作地通过图形用户界面对第一驾驶员输出修改的顺序目录，其中图形用户界面包括一系列优化车辆搭乘。
在一个实施例的一个方案中，顺序目录进一步至少部分地基于：离开第一驾驶员的开始地点的预定半径、离开第一驾驶员的结束地点的预定半径、最靠近第一驾驶员的开始地点的搭乘、最靠近第一驾驶员的结束地点的搭乘、全部搭乘的总估计时长、在第一驾驶员的开始时间与第一驾驶员的结束时间之间完成搭乘的能力、将无载英里数降低到最小、以及将搭乘之间的等待时间缩短到最短。
在一个实施例的一个方案中，驾驶员可以是自动驾驶车辆。
在一个实施例的一个方案中，车辆搭乘可以是人、包裹或宠物的搭乘。
在一个实施例的一个方案中，元启发式算法的执行可包括计算机可执行指令，该计算机可执行指令可操作地：检验离开第一驾驶员的开始地点和第一驾驶员的结束地点预定距离内的搭乘的清单；生成包含最靠近第一驾驶员的开始地点的搭乘和最靠近第一驾驶员的结束地点的搭乘的初始受限目录；至少部分地基于搭乘的总估计时长或在第一驾驶员的开始时间与第一驾驶员的结束时间之间完成搭乘的能力，将清单中的搭乘划入初始受限目录中；将无载英里数降低到最小；并且将搭乘之间的等待时间缩短到最短。
在一个实施例的一个方案中，计算机可执行指令可进一步包括指令，所述指令可操作地：使第一驾驶员接收来自递送收件人的修改递送的请求；至少部分地基于来自递送收件人的请求并且在所述预定截止时间之后进一步修改第一驾驶员的顺序目录；并且通过图形用户界面对第一驾驶员输出进一步修改的顺序目录，其中图形用户界面包括包含对递送收件人的递送的一系列优化车辆搭乘。
在一个实施例的一个方案中，递送可包括包裹或宠物。
根据本公开的一个示例性实施例，能够提供一种用于对车辆选择路线并且安排车辆搭乘的计算机实现方法、该方法可包含：接收一个或者多个驾驶员输入，该驾驶员输入包括每个驾驶员的开始时间、每个驾驶员的结束时间、每个驾驶员的开始地点、以及每个驾驶员的结束地点。该方法可进一步包含接收一个或者多个车辆搭乘请求，该请求包括每个搭乘的开始地点和每个搭乘的结束地点。该方法可进一步包含对于第一驾驶员，在预定截止时间之前并且至少部分地基于第一驾驶员的开始时间和第一驾驶员的结束时间，生成第一驾驶员的车辆搭乘的顺序目录。此外，该方法可包含在预定截止时间之前，确定第一驾驶员的开始时间与第一驾驶员的结束时间之间的潜在收入每小时增量。此外，该方法可包含至少部分地基于元启发式算法的执行并且在预定截止时间之后，修改第一驾驶员的所述顺序目录。该方法还可包含通过图形用户界面对第一驾驶员输出修改的顺序目录，其中图形用户界面包括一系列优化车辆搭乘。
在一个实施例的一个方案中，顺序目录可进一步至少部分地基于：离开第一驾驶员的开始地点的预定半径、离开第一驾驶员的结束地点的预定半径、最靠近第一驾驶员的开始地点的搭乘、最靠近第一驾驶员的结束地点的搭乘、全部搭乘的总估计时长、在第一驾驶员的开始时间与第一驾驶员的结束时间之间完成搭乘的能力、将无载英里数降低到最小、以及将搭乘之间的等待时间缩短到最短。
在一个实施例的一个方案中，驾驶员可以是自动驾驶车辆。
在一个实施例的一个方案中，车辆搭乘可以是人、包裹或宠物的搭乘。
在一个实施例的一个方案中，元启发式算法的执行可包含：检验离开第一驾驶员的开始地点和第一驾驶员的结束地点预定距离内的搭乘的清单；生成包含最靠近第一驾驶员的开始地点的搭乘和最靠近第一驾驶员的结束地点的搭乘的初始受限目录；至少部分地基于搭乘的总估计时长或在第一驾驶员的开始时间与第一驾驶员的结束时间之间完成搭乘的能力，将清单中的搭乘划入初始受限目录中；将无载英里数降低到最小；并且将搭乘之间的等待时间缩短到最短。
在一个实施例的一个方案中，该计算机实现方法可包含：第一驾驶员接收来自递送收件人的修改递送的请求；至少部分地基于来自递送收件人的请求并且在预定截止时间之后进一步修改第一驾驶员的顺序目录；并且通过图形用户界面对第一驾驶员输出进一步修改的顺序目录，其中图形用户界面包括包含对递送收件人的递送的一系列优化车辆搭乘。
在一个实施例的一个方案中，递送可包含包裹或宠物。
根据本公开的一个示例性实施例，能够提供一种用于对车辆选择路线并且安排车辆搭乘的计算机可读介质。该计算机可读介质可包含计算机可读指令，该计算机可读指令可操作地：接收一个或者多个驾驶员输入，该驾驶员输入包括每个驾驶员的开始时间、每个驾驶员的结束时间、每个驾驶员的开始地点、以及每个驾驶员的结束地点。该指令进一步可操作地接收一个或者多个车辆搭乘请求，该请求包括每个搭乘的开始地点和每个搭乘的结束地点。该指令进一步可操作地对于第一驾驶员，在预定截止时间之前并且至少部分地基于第一驾驶员的开始时间和第一驾驶员的结束时间，生成第一驾驶员的车辆搭乘的顺序目录。此外，该指令可操作地在预定截止时间之前，确定第一驾驶员的开始时间与第一驾驶员的结束时间之间的潜在收入每小时增量。此外，该指令可操作地至少部分地基于元启发式算法的执行并且在预定截止时间之后，修改第一驾驶员的所述顺序目录。此外，该指令可操作地通过图形用户界面对第一驾驶员输出修改的顺序目录，其中图形用户界面包括一系列优化车辆搭乘。
在一个实施例的一个方案中，顺序目录可进一步至少部分地基于：离开第一驾驶员的开始地点的预定半径、离开第一驾驶员的结束地点的预定半径、最靠近第一驾驶员的开始地点的搭乘、最靠近第一驾驶员的结束地点的搭乘、全部搭乘的总估计时长、在第一驾驶员的开始时间与第一驾驶员的结束时间之间完成搭乘的能力、将无载英里数降低到最小、以及将搭乘之间的等待时间缩短到最短。
在一个实施例的一个方案中，驾驶员可以是自动驾驶车辆。
在一个实施例的一个方案中，车辆搭乘可以是人、包裹或宠物的搭乘。
在一个实施例的一个方案中，元启发式算法的执行可包含计算机可执行指令，该计算机可执行指令可操作地：检验离开第一驾驶员的开始地点和第一驾驶员的结束地点预定距离内的搭乘的清单；生成包含最靠近第一驾驶员的开始地点的搭乘和最靠近第一驾驶员的结束地点的搭乘的初始受限目录；至少部分地基于搭乘的总估计时长或在第一驾驶员的开始时间与第一驾驶员的结束时间之间完成搭乘的能力，将清单中的搭乘划入初始受限目录中；将无载英里数降低到最小；并且将搭乘之间的等待时间缩短到最短。
在一个实施例的一个方案中，计算机可执行指令可进一步包含指令，该指令可操作地：使第一驾驶员接收来自递送收件人的修改递送的请求；至少部分地基于来自递送收件人的请求并且在预定截止时间之后进一步修改第一驾驶员的顺序目录；并且通过图形用户界面对第一驾驶员输出进一步修改的顺序目录，其中图形用户界面包括包含对递送收件人的递送的一系列优化车辆搭乘。
在一个实施例的一个方案中，递送可包含包裹或宠物。
下面将参考附图更全面描述本公开，附图示出本公开的示例性实施例。然而，可以许多不同方式实现本公开，并且不应当将本公开理解为局限于在此阐述的示例性实施例，相反，提供这些实施例是为了使本公开满足适用法律要求。在整个说明书中类似的参考编号指类似的要素。应当明白，在此使用特定单词和术语仅为了方便起见，并且应当将这些单词和术语理解为指，本技术领域内的普通技术人员通常以各种形式和等同理解的各种对象和动作。例如，在此使用的单词″例子″旨在指没有排斥性意义并且没有限制性意义。更具体地说，在此使用的单词″示例性″指几个例子中的一个例子，并且应当明白，不过分强调所描述的特定例子的重要性或优先性。根据下面结合附图所做的描述，本公开的其他实施例和方案变得显而易见。
附图说明
因此，尽管已经以通用术语描述了本公开，但是现在参考附图，附图未必按比例示出，并且其中
图1和2示出根据本公开的特定实施例的系统和方法的示例性处理流程。
图3-5示出根据本公开的特定实施例的系统和方法的示例性用户界面。
图6-13示出根据本公开的特定实施例的系统和方法的示例性模型示意图。
图14示出根据本公开的特定实施例的系统和方法的示例性流程图。
图15-19示出根据本公开的特定实施例的系统和方法覆盖于示例性区域上的示例性模型示意图。
图20-22示出根据本公开的特定实施例的系统和方法的其他示例性用户界面。
图23示出根据本公开的特定实施例通过网络与驾驶员/车辆和乘客或搭乘人通信的示例性环境和计算机网络架构。
表1-9示出根据本公开的特定实施例的系统和方法的示例性实现。
具体实施方式
就总体概述而言，在此描述的系统和方法的特定实施例能够选择车辆路线并且安排车辆搭乘。
在一个实施例中，系统利用移动电信和基于云的技术来配对潜在驾驶员/车辆，其中每个″驾驶员/车辆″可以是在各自的潜在搭乘人或包裹递送收件人愿意支付或已经支付点到点运输费的情况下，在有人驾驶或无人驾驶的情况下，执行驾驶功能的人或自动驾驶车辆。每个″搭乘人″或″乘客″可以是人、动物、包裹或它们中的两个或者多个的组合。一般而言，驾驶员/车辆是利用个人的车辆或公司提供的车辆提供服务的独立承包人。在一些实施例中，车辆可以是自主的，也可以是半自主的，但是仍可以是私人拥有的、公司拥有的和/或公司出租的车辆。″搭乘″或″行程″指从一个点到另一个点的或从开始地点到结束地点的单个业务。一般而言，在任何情况下，与每个驾驶员/车辆的搭乘人业务以及与每个驾驶员/车辆的公司业务都是非现金业务，并且通过与tnc或运输网络公司管理的或辅助管理的平台或网络通信，利用在智能电话或基于处理器的其他设备上执行的各自app或应用进行处理。
图1和2示出根据本公开的特定实施例的示例性系统和方法的处理流程。一般而言，处理流程100示出通过在基于云的处理器或其他处理器上处理的任意数量的算法以及智能电话或基于处理器的其他设备上执行的app或应用，对任意数量的搭乘或行程以及驾驶员/车辆进行重新安排、配对、排序及路线选择。
一般而言，搭乘人能够在搭接时间和/或递送时间之前安排搭乘或行程，并且在安排的搭接时间与可能实际发生搭接/递送的时间之间存在最短时间。与传统的tnc不同，搭乘人不能招手搭乘或行程并且不能接受基于最近的服务驾驶员/车辆的服务，但是使用新tnc的搭乘人能够提前例如15分钟知晓派去搭接的驾驶员/车辆的详情。操作102-138解释根据本公开的实施例的搭乘安排过程。
在操作102，搭乘人通过智能电话或基于处理器的其他设备上执行的app或应用进行预约(reservation)。操作102之后是操作104，在操作104，搭乘人通过app或应用选择搭接时间。操作104之后是操作106，在操作106，搭乘人通过app或应用录入并且确认搭接地点和卸落地点。操作106之后是操作108，在操作108，搭乘人通过app或应用选择汽车类型。汽车类型可包含但并不局限于零担车、标准车、豪华轿车、运动型多用途车(suv)、厢式汽车(van)、高级轿车和宠物专用车。各自的这些选项仅作为例子示为操作110、112、114、116、118、120和122。根据需要，可存在其他类型的汽车，并且搭乘人可通过app或应用选择其他类型的汽车。
执行了操作110的选择后，搭乘人或该例中的递送人指出希望利用车辆托运包裹。通过智能电话或基于处理器的其他设备上的用户界面对递送人提供表格，以输入关于要递送的包裹的详情。这些详情可包含但并不局限于：尺寸、重量、图片、视频、搭接地点、卸落地点、电话号码、电子邮件、用户名称、递送收件人以及与通知或邮递有关的其他优先信息。在某些情况下，递送人可以是希望将tnc用作后勤履职服务从而搭接或卸落客户或包裹递送收件人的一个或者多个包裹的公司或组织的代表。收到正确托运信息后，平台创建托运业务，并且该业务变成搭乘对象，平台可将该搭乘对象看作搭乘，区别是例如p＝包裹。能够与乘客或搭乘人的搭乘或行程类似，对驾驶员/车辆受限候选对象目录(rcl)的分配做处理，并且因此，能够提供该分配、对该分配排序并且利用该区别规范能够与任何其他搭乘对象类似对驾驶员/车辆选择路线，以将搭乘对象类型通知驾驶员。操作110之后是下面描述的操作130。
操作112、114、116、118和120之后是判定框124，在判定框124，搭乘人选择乘客的数量。如果搭乘人做出″1″的选择，则在判定框126，诸如通过问″您接受合乘吗？″来询问搭乘人是否接受汽车合乘(carpool)。如果搭乘人回应″是″，则沿该分支到操作128，在操作128，如果车辆沿搭乘人的路线搭接另一个乘客，则能对该搭乘人提供折扣。可将该折扣计到与搭乘人关联的账号上，也可将该折扣应用于搭乘人的本次搭乘或本次路线的费用。操作128之后是下面描述的操作134。
执行了操作122的选择后，搭乘人或本例中的宠物的看护人指出希望用车辆托运宠物或动物。平台能够对该请求作与搭乘人或乘客的搭乘请求类似的处理。收到正确搭乘信息后，平台能够创建业务，并且该业务变成搭乘对象，平台能够对该搭乘对象做与其他搭乘类似的处理，区别是例如p＝宠物。能够与乘客或搭乘人的搭乘或行程类似对驾驶员/车辆受限候选对象目录(rcl)的分配做处理，并且因此，能够提供该分配、对该分配排序并且利用区别规范能够与任何其他搭乘对象类似对驾驶员/车辆选择路线，以将搭乘对象类型通知驾驶员。操作122之后是下面描述的操作130。
返回判定框126，如果搭乘人做出″否″的选择，则沿该分支到操作130，在操作130，对于该搭乘或行程，对该搭乘人收全价或费用。操作130之后是下面描述的操作134。
返回判定框124，如果搭乘人做出″两个或者多个″的选择，则在操作132，能够对客户收全价，并且能够基于额外客户报价，对每个额外客户收费。
操作128、130和132之后是操作134，在操作134，进行支付。例如，由于支付是非现金支付，所以支付处理器能够处理信用卡或借记卡。能够将信用卡或借记卡或者其他支付账户详情传送到一个或者多个支付处理器进行处理，并且能够与在该业务中作为商家的tnc结清支付收入。可利用一种或多种支付方法对收到的支付额作出支付，并且收到的支付额可包含tnc签发的或接受的优惠券或折扣代码，以抵扣一些或全部支付额。
操作134之后是判定框136，在判定框136，确定支付处理是否成功。即，支付处理器确定支付处理是否成功，并且通过平台与tnc通信关于支付处理是否成功。如果支付处理不成功，则沿″否″分支到达操作138，在操作138，对搭乘人返回错误消息，并且tnc平台不预订搭乘。执行了操作138后，该方法返回操作106，对搭乘人提供另一次机会，以通过app或应用录入并且确认新搭接地点和新卸落地点。
返回判定框136，如果支付处理成功，则沿″是″分支到操作140，在操作140，确认搭乘人的行程，产生确认该行程的通信，并且通过app或应用，将确认该行程的通信发送到搭乘人，并且能够产生日历条目，并且通过app或应用能够将日历条目发送到搭乘人。操作140之后是操作142，在操作142，搭乘人的行程存储于主搭乘人清单中，供进一步处理。能够将一个或者多个搭乘人的搭乘或行程请求置于存储于数据库存储器或其他储存设备中的主搭乘清单内。主搭乘清单是一个或者多个搭乘人请求的搭乘或行程的初始清单目录。
返回图2，在操作202，驾驶员/车辆能够与智能电话或基于处理器的其他设备上的用户界面交互，以产生工作计划，以行使该平台对所创建并且确认的工作计划可智能地对驾驶员/车辆提供的一个或者多个路线。选择了创建工作计划的选项后，操作202之后是操作204，在操作204，平台对驾驶员/车辆提供选择开始行使时间的选项。例如，驾驶员/车辆能够判定在上午6：00开始工作计划，并且选择对应于上午8：00的用户选项。操作204之后是操作206，在操作206，驾驶员/车辆能够提供实际开始地点。驾驶员/车辆能够与智能电话或基于处理器的其他设备上的用户界面交互，并且对他/她指出实际开始地点，诸如，实际地址″123northavenue″，或地图上的图钉。操作206之后是操作208，在操作208，选择工作窗口。即，驾驶员/车辆选择了开始时间和开始地点后，驾驶员/车辆就能够至少部分地基于可选选项目录安排工作窗口，也称为工作计划。工作窗口是一个时间段，即，驾驶员/车辆希望工作的确定时段。例如，在操作210-218，驾驶员/车辆能够选择工作窗口选项，诸如，2、4、6、8或10小时。可存在其他工作窗口增量。在任何情况下，驾驶员/车辆都可在任意时间提前选择工作窗口，诸如，在要求的工作开始时间之前几分钟、几小时、几天、几周或几个月。在选择时间段时，驾驶员/车辆提前主动声明所选工作窗口的开始时间并且选择时间段，选择工作窗口的结束时间。
不考虑已选的所选增量，在选择例如2小时的工作窗口增量时，从判定框208沿″是″分支到达操作210，然后，到达判定框220，在判定框220，确定驾驶员/车辆是否要返回开始地点而终止该工作窗口。如果驾驶员/车辆选择″是″，则沿该分支到达操作222，在操作222，所选或所指开始地点是该工作窗口的终点，并且该方法继续到达下面描述的操作224。如果驾驶员/车辆选择″否″，则沿该分支到达操作226，在操作226，驾驶员/车辆在地图上对该工作窗口的终点选择或指出地址或图钉，并且该方法继续到达下面描述的操作224。
在任何情况下，例如，当驾驶员/车辆选择或指出开始地址时，能够将该地址转换为一组坐标，诸如，x1，y1，并且还能够将工作窗口终止地点转换为一组坐标，诸如，x2，y2。平台能够利用地图程序服务或其他技术将开始地点或地址和终止地点或地址转换为gps坐标，诸如，x1，y1和x2，y2。
返回图3，根据本公开实施例，示出在智能电话或基于处理器的其他设备上执行的app或应用的示例性用户界面300。在该例中，驾驶员/车辆可利用驾驶员/车辆app通过平台与tnc通信。所示的用户界面能够对驾驶员/车辆显示″我的计划″页面，具有要求的工作窗口所需的各种参数，例如，开始时间302和日期304、工作窗口增量306或时长、开始地点308和终止或结束地点310。地图312也能够显示于用户界面中，并且可指出驾驶员/车辆的当前地点314，并且在需要时或当驾驶员/车辆指出时，可指出开始地点308和终止或结束地点310。
驾驶员/车辆指出所需工作窗口的要求开始时间、开始地点和终止或结束地点后，平台能够利用事先存储于一个或者多个存储器、数据储存设备或处理器中的一个或者多个元启发式算法由主搭乘清单创建初始受限候选对象目录(rcl)，在图1中的操作142进行了描述。主搭乘清单可包含预订的并且平台尚未提供服务的一个或者多个搭乘。
返回图1，搭接例程开始于操作144，其中至少部分地基于平台执行的一个或者多个算法，首先对每个单独驾驶员/车辆各自的rcl或受限候选对象目录分配一个或者多个搭乘。平台能够执行各种算法，包含利用下面描述的算法元启发式搜索(algorithmicmetaheuristicsearch)方式确定一个或者多个搭乘，以分配给每个单独驾驶员/车辆各自的rcl或受限候选对象目录。
图4示出根据本公开的实施例的另一个示例性用户界面。智能电话或基于处理器的其他设备上执行的app或应用能够简化图4所示的示例性用户界面400。在该例中，驾驶员/车辆能够看到生成的rcl或受限候选对象目录，包含预测计划402和确认计划404。预测计划402可包含对特定活动工作窗口的驾驶员/车辆初始分派的一个或者多个搭乘，但是平台尚未对驾驶员/车辆最终敲定的一个或者多个搭乘的目录。示例性确认计划404中所列的目录包含，在满足平台对驾驶员/车辆设定的优化目标的时间(直到特定切入时间)可用的一组优化的搭乘406、408。
在任何情况下，平台生成的并且通过用户界面400对驾驶员/车辆输出的初始rcl可包含试图在所选工作窗口的每个小时内使驾驶员/车辆的潜在收入最大化的一个或者多个搭乘，并且此外，其中在工作窗口的开始时间和终止时间内可完成搭乘，同时信守驾驶员/车辆设定的开始地点和终止地点。
图4作为例子示出如上解释的临时对特定驾驶员/车辆分派的2个搭乘406、408。在这样做时，平台试图基于使驾驶员/车辆的利用率最大化使搭乘与驾驶员/车辆配对，其中利用率由等待时间(支付费用的搭乘之间的时间，即，没有载有支付费用的搭乘人的时间)和空载/无载英里数(未载有支付费用的搭乘人的情况下驾驶的英里数)确定。在该例中，最大化驾驶员/车辆的利用率意味着将驾驶员/车辆在所选工作窗口的每个小时内发生的等待时间和空载/无载英里数降低到最短。
返回图1，操作144之后是操作146(与图2所示的操作230类似)，在操作146，平台能够对初始rcl执行、应用、运行和再运行一个或者多个算法，以实现一个或者多个优化目标和/或目的，可以为每个驾驶员/车辆提供来自各个驾驶员/车辆工作窗口的主清单的最优化搭乘组合。下面将参考图6-13描述诸如算法元启发式搜索方式的示例性算法和一组优化目标和/或目的。
操作146之后是操作148(与图2所示的操作232和234类似)，在操作148，平台对一个或者多个搭乘生成驾驶员/车辆的最终rcl。
操作148之后是操作150(与图2所示的操作236类似)，在操作150，将包含顺序、搭乘信息和路线详情的最终rcl通知每个驾驶员/车辆。通常，平台生成最终rcl，并且通过智能电话或基于处理器的其他设备上的用户界面，将其输出到驾驶员/车辆。此外，操作148之后还有操作152，可与操作150同时或稍许早于或稍许晚于操作150执行操作152，并且操作152包括将包含驾驶员/车辆详情的确认搭乘详情通知rcl中所列搭乘中标出的单独搭乘人。
图5示出根据本公开的实施例的另一个用户界面。智能电话或基于处理器的其他设备上执行的app或应用能够简化图5所示的示例性用户界面500。在该例中，平台能够生成对驾驶员/车辆指出最终rcl目录中的任意数量的确认搭乘的确认工作窗口404。在对预定搭乘分派驾驶员/车辆之前，最终rcl中的驾驶员/车辆和搭乘人能够由平台通过它们的智能电话或基于处理器的其他设备上执行的各自的app或应用对它们互相提供联系信息，诸如，手机号码、车辆品牌/型号/颜色、牌照号码或车辆登记号码、电子邮件、名称、昵称、身份证号码以及/或其他识别信息。
在此描述的操作150之后是操作154，在操作154，关于确认rcl工作计划和对搭乘人的搭乘义务，平台或在驾驶员/车辆的智能电话或基于处理器的其他设备上执行的app或应用及时提供提醒通知。平台以及驾驶员/车辆智能电话或基于处理器的其他设备上执行的app或应用能够访问平台或app或应用上运行的时钟，从而对各种搭乘时间进行比较，并且能够在每次搭乘之前，例如，在搭乘开始时间前5分钟生成提醒。能够考虑到驾驶员/车辆到达搭乘开始点的行使时间在搭乘开始时间之前生成提醒。在任何情况下，提醒或其他通知都能够由平台生成，并且能够利用文本、消息或在驾驶员/车辆智能电话或基于处理器的其他设备上执行的app或应用内将该提醒或其他通知发送到驾驶员/车辆。类似地，app或应用能够生成提醒或通知，并且能够利用文本、信息或在app或应用内将该提醒或通知发送到驾驶员/车辆。
返回操作152，在操作152后面与操作154同时执行或稍许早于或稍许晚于操作154执行的操作是操作156，在操作156，对即将到来的搭乘的搭乘人或乘客提供通知或提醒。与对驾驶员/车辆生成通知或提醒类似，对于每个搭乘人或乘客的确认搭乘义务，平台或在乘客的或搭乘人的智能电话或基于处理器的其他设备上执行的app或应用及时提供提醒通知。平台以及搭乘人或乘客的智能电话或基于处理器的其他设备上执行的app或应用能够访问平台或app或应用上运行的时钟，从而对各种搭乘时间进行比较，并且能够在每次搭乘之前，例如，在搭乘开始时间前5分钟生成提醒。能够考虑到搭乘人或乘客到达搭乘开始点的行程时间在搭乘开始时间之前生成提醒。在任何情况下，提醒或其他通知都能够由平台生成，并且能够利用文本、信息或在搭乘人或乘客的智能电话或基于处理器的其他设备上执行的app或应用内将该提醒或其他通知发送到搭乘人或乘客。类似地，app或应用能够生成提醒或通知，并且能够利用文本、信息或在app或应用内将该提醒或通知发送到搭乘人或乘客。
在任何情况下，操作154和操作156之后是操作158，在操作158，在驾驶员/车辆到达搭乘开始地点时，平台通知搭乘人或乘客。即，当驾驶员/车辆行驶到指定的搭乘开始地点来搭接搭乘人或乘客时，通过跟踪与驾驶员/车辆关联的智能电话或基于处理器的其他设备的gps坐标，平台监视驾驶员/车辆向搭乘开始地点行进和与搭乘开始地点的近度。当驾驶员/车辆的gps坐标与搭乘开始地点的gps坐标的比较指出驾驶员/车辆处于离开搭乘开始地点例如500英尺的预定距离或例如约1分钟的预定时间时，平台能够生成通知，并且利用文本、信息、呼叫或电子邮件将该通知发送到搭乘人或乘客。
操作158之后是操作160，在操作160，通知了到达的驾驶员/车辆后，对搭乘人或乘客给予预定时间，以便进入车辆。平台对驾驶员/车辆和搭乘人或乘客都提供诸如约5分钟的预定时间，以对双方确认从搭乘开始地点搭接搭乘人或乘客。通常，驾驶员/车辆的智能电话和搭乘人或乘客的智能电话上执行的app或应用能够对驾驶员/车辆以及搭乘人或乘客提供各自的选项，以确认从搭乘开始地点搭接。
操作160之后是操作162，在操作162，驾驶员/车辆和搭乘人或乘客在操作160执行搭接确认后，搭乘开始，并且搭乘人或乘客的行程付诸实施。
操作162之后是操作164，在操作164，通过利用gps坐标和地图应用、程序或服务跟踪驾驶员/车辆，平台能够对驾驶员/车辆提供导航指令。
操作164之后是操作166，在操作166，在搭乘结束地点或点卸落搭乘人或乘客，并且该搭乘或行程结束。该搭乘或行程终止后，平台能够确定最终价格或成本，该最终价格或成本能够包含行使距离、一天中的时间、车辆类型和额外乘客的数量。
在此描述的实施例能够提供特定技术效果，包含比传统tnc提高效率。传统tnc的特征在于基于距该乘客的最近通过车辆使该车辆与乘客匹配，而与该车辆空车等待多长时间和/或在该乘客的附近空车行使多长无关。此外，为tnc提供服务的每个驾驶员/车辆是独立承包人，即，他/她自己的业务的主人，而非传统雇员。这意味着tnc的每个驾驶员/车辆都没有设定时刻表。尽管这样使得特定tnc将劳动成本降低到最低，但是它还不允许tnc强迫驾驶员/车辆在特定地方和时间出现。传统tnc因为缺乏控制而不太有效。平台使得驾驶员/车辆有能力通过所选工作窗口主动设定计划和时刻表，如在此所述。另外，在初始建立后给予驾驶员/车辆截止时间，在初始建立中，工作窗口计划和时刻表如果尚未确认则将作为初始工作窗口计划和时刻表，如驾驶员/车辆从未对平台确认到对平台确认的变更状态所指出的。然而，驾驶员/车辆对平台确认驾驶员/车辆工作窗口计划和时刻表后，驾驶员/车辆可不再变更为确认工作窗口计划和时刻表，并且此时，平台创建该驾驶员/车辆专用rcl。因此，这样强迫(通过驾驶员/车辆自行动作)指定驾驶员/车辆在特定地方和时间出现，并且与传统tnc和平台相比，能够提供tnc的平台的效率。
如上所述，平台能够对搭乘人提供提前预定搭乘的机会。能够生成主和/或初始清单目录，能够由该主和/或初始清单目录创建子目录，能够将每个子目录描述为受限类目录(rcl)。每个rcl能够为确认驾驶员/车辆工作计划所专用。驾驶员/车辆专用rcl的初始创建与驾驶员/车辆的截止时间(驾驶员/车辆确认并且活动工作窗口失效之前的某个时间)之间，当在主清单目录内预定新搭乘时，平台能够执行一个或者多个算法，以基于为了实现对驾驶员/车辆在驾驶员/车辆工作窗口的每个小时的潜在收入实现最大化的目标能够获得的较好驾驶员/车辆利用率来搜索主清单目录。在不再允许驾驶员/车辆改变工作窗口时刻表的截止时间与驾驶员/车辆的实际工作窗口将开始的时间之间，平台选择预定时间，在该预定时间内，平台使rcl的更新挂起。当发生这种情况时，生成搭乘的最终rcl目录，并且对于驾驶员/车辆，该最终rcl中的搭乘自动排序。然后，要求驾驶员/车辆依照平台提供的该顺序和路线搭接和卸落包含于最终rcl中的搭乘人。
在至少一个实施例中，平台能够执行一个或者多个算法，以实现上面描述的技术效果和/或一个或者多个下列目的。
(1)将搭乘之间的驾驶员/车辆等待时间缩短到最短并且让驾驶员/车辆提前知晓下一个搭乘地点、搭接时间和卸落/递送点。
(2)将驾驶员/车辆无载英里数缩短到最短，这样确保驾驶员/车辆在未载有支付费用的搭乘人的情况下行使尽可能少的英里数，并且对于确认的工作计划，让驾驶员/车辆提早知晓其工作负荷，同时允许驾驶员/车辆对选择工作计划确定开始地点和结束地点。
(3)因为实现了上述(1)和(2)中的目标，所以能够将驾驶员/车辆在每个小时和/或活动工作窗口的潜在收入提高到最高，并且确保根据时刻表及时搭接搭乘人。
在该示例性实施例中，采用下面的术语和计算值。
●″净驾驶员/车辆″支出是对搭乘人或乘客收取的费用的百分比(％)。
●对搭乘人或乘客收取的费用基于取决于与每个行程的距离+对每个行程估计的行使时间挂钩的费率的数量。
●对每个行程估计的距离是，搭乘人(pi)的搭接地点与卸落地点之间的gps坐标绘出的全部可用路线中点到点路线的距离和/或时间的计算值。
●基于上面在计算距离中采用的距离除以该路线上的最低法定允许限速的公式计算估计的行使时间，或如基于所选行程时间的点到点路线的第三方gps计算值估计该行驶时间。
在该示例性实施例中，利用一些或全部下列变量执行算法元启发式搜索方式：
●p1＝基于有载行程距离对第一行程的净驾驶员/车辆支出。
●p2＝基于有载行程距离对第二行程的净驾驶员/车辆支出。
●p3＝基于有载行程距离对第三行程的净驾驶员/车辆支出。
●pn＝基于有载行程距离对第n行程的净驾驶员/车辆支出。
●pn+1＝基于有载行程距离对第n+1行程的净驾驶员/车辆支出。
●pw＝p1+p2+p3+pn+pn+1＝在给定的工作窗口内基于全部有载行程距离的总和的净支出，其中基于一天中某个时间时每英里的费率乘以距离计算p1，p2，p3，pn及pn+1，距离由两个地点(x1，y1)(x2，y2)之间的gps坐标参数的差值求得。
●t1＝基于实际行程分钟数对第一行程的净驾驶员/车辆支出。
●t2＝基于实际行程分钟数对第二行程的净驾驶员/车辆支出。
●t3＝基于实际行程分钟数对第三行程的净驾驶员/车辆支出。
●tn＝基于实际行程分钟数对第n行程的净驾驶员/车辆支出。
●tn+1＝基于实际行程分钟数对第n+1行程的净驾驶员/车辆支出。
●tw＝t1+t2+t3+tn+tn+1＝在给定的工作窗口内基于全部实际行程分钟数的总和的净支出，其中基于一天中某个时间时每分钟的费率乘以实际行程分钟数计算t1，t2，t3，tn及tn+1。
●r1＝p1+t1＝基于组合的有载行程距离和实际有载行程分钟数对第一行程的净驾驶员/车辆支出。
●r2＝p2+t2＝基于组合的有载行程距离和有载行程分钟数对第二行程的净驾驶员/车辆支出。
●r3＝p3+t3＝基于组合的有载行程距离和有载行程分钟数对第三行程的净驾驶员/车辆支出。
●rn＝pn+tn＝基于组合的有载行程距离和有载行程分钟数对第n行程的净驾驶员/车辆支出。
●rn+1＝pn+1+tn+1＝基于组合的有载行程距离和有载行程分钟数对第n+1行程的净驾驶员/车辆支出。
●rw＝pw+tw＝在给定的工作窗口内基于全部有载行程英里数的总和及全部有载行程分钟数的总和的净支出。
●du＝无载距离(英里)
●l1＝驾驶员/车辆地点1(卸落第一搭乘人)
●l1＝驾驶员/车辆地点2(搭接第二搭乘人)
●du＝l2-l1任意两个地点之间的无载英里数。
●yδ＝地点1与地点2之间的搭接时间。
●y1＝搭接时间1(第一搭乘人的搭接时间)。
●y2＝搭接时间2(第二搭乘人的搭接时间)。
●yδ＝y2-y1＝任意两个搭乘人之间的搭接时间差。
●yw＝等待时间，其中yw≤yδ。
利用一些或全部上述变量，算法元启发式搜索方式能够在每个驾驶员/车辆确认计划或工作窗口内采用一些或全部下列优化规则。
总体优化规则：
●规则a-使每小时的收入(rw)最大化到＞(例如)每小时20美元。
●规则b-最小化无载英里数(du)。
●规则c-最小化搭乘之间的等待时间(yw)。
在最终敲定搭乘的预定平台驾驶员/车辆截止时间之前对驾驶员/车辆预分配搭乘、安排日程、排序以及对最终搭乘安排路线的规则能够包含例如下面的操作：
(1)如图6中所示，例如，在驾驶员/车辆开始窗口及最终敲定对驾驶员/车辆指定的搭乘之前，第一操作是平台检验离开驾驶员/车辆开始地点诸如例如≤10英里并且例如还在离开驾驶员/车辆要求结束地点≤10英里的预定合理半径内的搭乘的主清单。在图6中，ri＝在对驾驶员/车辆1(d1)和驾驶员/车辆(d1)’的开始地点(dsl)和结束地点(del)指定搭乘的第一迭代开始时搭乘清单中的初始搭乘。
(2)如图7中所示，构成算法元启发式搜索方式的下一个操作是创建仅含有驾驶员/车辆搭接的两个搭乘的初始受限候选对象目录(rcl)，其中r1等于最接近驾驶员/车辆开始点的搭乘，并且r7等于最靠近驾驶员/车辆要求的结束点的搭乘。
(3)构成算法元启发式搜索方式的下一个操作是基于(a)行程搭乘的总估计时长+等待时间余量(例如，≤每个行程10分钟)，(b)工作窗口内完成搭乘的能力(例如，允许比工作窗口的持续时间长或短约10分钟)，从初始主清单中对驾驶员/车辆指定附加搭乘。
(4)如图8-13所示，构成算法元启发式搜索方式的下一个操作是考虑到其他优化目标，对驾驶员/车辆分派搭乘。下面是该操作的子操作：
(a)检验每个驾驶员/车辆开始地点与第一搭乘搭接点之间的距离，应用总体优化规则b，将上面定义的无载英里数(du)降低到最少。
(b)对每个驾驶员/车辆检验估计时间以完成分配的第一搭乘，并且确定是否：
(i)完成第一搭乘花费的时间≤1小时吗？如果是，则：
通过回答问题-净支出r1＝p1+t1≥$20吗？检验关于第一搭乘对驾驶员/车辆的净支出(r1＝p1+t1)
○如果
■″是″
●则基于总体优化规则b和规则c(以该顺序)对rcl分派第三搭乘。
■″否″
●则基于规则a，分派第三搭乘，但是检验在1小时内能够完成第一搭乘+第二搭乘。
●检验关于第一搭乘+第二搭乘对驾驶员/车辆的净支出(r1+r2)-净支出r1+r2≥$20吗？
●如果
○″是″
■则基于总体优化规则b和规则c(以该顺序)，分派第四搭乘。
○″否″
■则基于总体优化规则a，分派下一个搭乘，但检验在1小时内能够完成第一搭乘+第二搭乘+第三搭乘。
●检验关于第一搭乘+第二搭乘+第三搭乘对驾驶员/车辆的净支出(r1+r2+r3)-净支出r1+r2+r3≥$20吗？
■重复此过程，如果在该小时循环到r1+r2+r3+rn+rn+1≥$20，则转移到下一个小时。
(ii)完成第一搭乘花费的时间＞1小时吗？
●检验关于第一搭乘对驾驶员/车辆的净支出(r1＝p1+t1)-净支出r1＝p1+t1≥$20吗？
○如果
■″是″
●基于总体优化规则b和规则c(以该顺序)，分派第二搭乘。
●继续基于(a)行程搭乘的总估计时长+等待时间余量(每个行程≤10分钟)，以及(b)可在工作窗口内完成(允许比时间窗口长或短约10分钟)，对驾驶员/车辆添加主清单中的附加搭乘。
■″否″
●不分派第一搭乘-基于总体优化规则a和规则b(以该顺序)，返回搭乘清单并且重新启动rcl，利用新第一搭乘(r4)代替原始第一搭乘(r1)。
●返回，以开始上述优化规则(4)，并且再次重复该过程。
(5)构成算法元启发式搜索方式的下一个操作是结束对驾驶员/车辆分派搭乘的操作。这可通过下面的子操作实现。
(a)对每个工作窗口内的每个小时重复上述算法过程。
(i)重复上面描述的过程，但是大约在此时，如图12所示，添加在del处结束循环的限制，其中最后搭乘是最近搭乘人(r7)，上面参考图7所述，在规则(2)中，最近搭乘人(r7)添加到rcl中。
(b)在各自的每个驾驶员/车辆安排时间窗口结束时，对每个驾驶员/车辆结束算法元启发式搜索方式。
在一个实施例中，当不再允许算法规划时，对驾驶员/车辆在要求的驾驶员/车辆截止时间搭接的搭乘进行最终搭乘分派、安排和路线选择的过程可包含下面的操作。
在预先安排与最终安排截止点之间，能够将新搭乘添加到初始搭乘清单中。
添加的这些新搭乘能够导致(a)新搭接点和卸落点较靠近最初在第一rcl目录中提供的搭接点和卸落点，并且(b)不同的优化路径。因此，此时，算法元启发式搜索方式能够继续更新和再更新rcl，这样能够在上面描述的算法元启发式搜索方式中改善优化。
上面描述的优化过程能够更好在截止时间之前停止重复，在该截止时间，不再允许变更。
转到图14，对根据本公开的特定实施例的特定系统和方法，提供示例性流程图。在图14所示的例子中，方法1400以操作1402开始，在操作1402，能够接收包括每个驾驶员的开始时间、每个驾驶员的结束时间、每个驾驶员的开始地点以及每个驾驶员的结束地点的一个或者多个驾驶员输入。
操作1402之后是操作1404，在操作1404，能够接收一个或者多个车辆搭乘请求，该请求包括每个搭乘的开始地点和每个搭乘的结束地点。
操作1404之后是操作1406，在操作1406，对于第一驾驶员，在预定截止时间之前并且至少部分地基于第一驾驶员的开始时间和第一驾驶员的结束时间，能够生成第一驾驶员的车辆搭乘顺序目录。
操作1406之后是操作1408，在操作1408，在预定截止时间之前，能够确定第一驾驶员的开始时间与第一驾驶员的结束时间之间潜在收入的每小时增量。
操作1408之后是操作1410，在操作1410，至少部分地基于元启发式算法的执行并且在预定截止时间之后，能够修改第一驾驶员的顺序目录。
操作1410之后是操作1412，在操作1412，可通过图形用户界面对第一驾驶员输出修改的顺序目录，其中图形用户界面包括一系列优化车辆搭乘。
在图14描述的示例性方法1400的一个方案中，顺序目录可至少部分地进一步基于：离开第一驾驶员的开始地点的预定半径、离开第一驾驶员的结束地点的预定半径、最靠近第一驾驶员的开始地点的搭乘、最靠近第一驾驶员的结束地点的搭乘、全部搭乘的总估计时长、在第一驾驶员的开始时间与第一驾驶员的结束时间之间完成搭乘的能力、将无载英里数降低到最小、以及将搭乘之间的等待时间缩短到最短。
在图14描述的示例性方法1400的另一个方案中，驾驶员可以是自动驾驶车辆。
在图14描述的示例性方法1400的又另一个方案中，车辆搭乘可以是人、包裹或宠物的搭乘。
在图14描述的示例性方法1400的又另一个方案中，执行元启发式算法可包含：检验离开第一驾驶员的开始地点和第一驾驶员的结束地点预定距离内的搭乘的清单；生成包含最靠近第一驾驶员的开始地点的搭乘和最靠近第一驾驶员的结束地点的搭乘的初始受限目录；至少部分地基于搭乘的总估计时长或在第一驾驶员的开始时间与第一驾驶员的结束时间之间完成搭乘的能力，将清单中的搭乘划入初始受限目录中；将无载英里数降低到最小、以及将搭乘之间的等待时间缩短到最短。
在图14描述的示例性方法1400的又另一个方案中，计算机执行方法可包含：第一驾驶员接收来自递送收件人的修改递送的请求；至少部分地基于来自递送收件人的请求并且在预定截止时间之后进一步修改第一驾驶员的顺序目录；以及通过图形用户界面对第一驾驶员输出进一步修改的顺序目录，其中该图形用户界面包括包含对递送收件人的递送的一系列优化车辆搭乘。
在图14描述的示例性方法1400的又另一个方案中，递送可包含包裹或宠物。
根据本公开的实施例的其他系统和方法能够执行或包含一些或全部上述操作和方案，而其他实施例可具有较少的操作和方案。
转到图15，在本公开的实施例的示例性执行中，考虑到离开城市中心1502半径约10英里的都市区1500，如图15所示。如图15所示，都市区1500可包含各种不同类型的建筑1504-1524及路网1526。每个建筑1504-1524可具有示为(xi，yi)的一个或者多个gps纵向坐标和横向坐标。在图15所示的该例中，i＝1至13。能够对路网1526中的每条公路1528编号，并且例如，能够从1号公路到31号公路编号。
图16示出含有与图15相同信息的相同都市区1500，但是图16在带有各自的坐标点(xi，yi)的建筑1504-1524中的每个建筑中和周围有载有过重负荷的潜在乘客1600或搭乘人。
图17示出含有与图16相同的信息和相同都市区1500。然而，图16示出来自潜在乘客或搭乘人1600的全部搭乘请求的附加信息，该附加信息带冻结到下午3：00的快照。基于要求的搭接时间，对搭乘r1至r7编号，并且将其置于地图上。在该例中，当该搭乘被预订时，其就没什么关系了，而更重要的是，例如，至少在下午3：00前约15分钟知晓该搭乘被预订。因此，如图17所示，在冻结到下午3：00的快照上，在主清单目录中有7个搭乘。主清单目录中的搭乘ri可以是不同的类型。例如，可将搭乘r1划分为″标准″搭乘，对应于乘客(p1)对标准车辆的车辆选择/请求。可将搭乘r2划分为″豪华″搭乘，对应于乘客(p36)对豪华车辆的车辆选择/请求。可将搭乘r7划分为″宠物″搭乘，对应于乘客(p50)对宠物友好/指定车辆的车辆选择/请求。因此，参考表1，表1示出下午3：00时的主清单目录，此时的主清单中的全部搭乘(在下午2：00看到的)是7个，并且这些搭乘包含不同类型的搭乘。应当注意，如表2所示，平台可对每种类型的搭乘采用不同的费率(每英里的费率和/或每分钟的费率)对搭乘定价，并且甚至对于每种类型的搭乘，依据其他因素诸如一天中的时间或给予的促销，搭乘类型可具有不同的费率。
如上参考平台执行的一个或者多个算法所做的描述，要满足的第一条件是在驾驶员/车辆截止时间之前对驾驶员/车辆预先分派搭乘，以便最终敲定搭乘、安排最终搭乘、对最终搭乘排序、以及对最终搭乘选择路线。可执行下面的5个操作。
1.在驾驶员/车辆开始窗口并且在对驾驶员/车辆最终敲定分派搭乘之前，平台首先执行对离开驾驶员/车辆开始地点和驾驶员/车辆要求的结束地点预定半径(例如，≤10英里)内的搭乘检验主清单(表1所示的例表)。平台能够在比如2：00之前对已经建立确认工作窗口或确认计划的驾驶员/车辆执行搜索/检验。基于该检验，平台可注意到有5个驾驶员/车辆，如图18所示。在图18中，在开始对5个驾驶员/车辆/(d1)至(d5)及各自的开始地点(dsl)和结束地点(del)分派搭乘的第一迭代时，搭乘清单中的ri＝7初始搭乘。
2.第二操作是对每个驾驶员/车辆建立仅含有这5个驾驶员/车辆的适当搭乘搭接的初始受限候选对象目录(rcl)，其中比如r1＝最靠近驾驶员/车辆d1的开始点的搭乘，而r7＝最靠近驾驶员/车辆d1的要求结束点的搭乘。可对这5个驾驶员/车辆重复该过程。在此为了简洁起见，可假定每个驾驶员/车辆可用于一种或者多种搭乘。平台能够智能地使驾驶员/车辆提供该车辆是否可用于一种或者多种搭乘类或类型的信息，并且基于该特定驾驶员/车辆允许的搭乘类或类型，创建驾驶员/车辆rcl。为了能够创建每个驾驶员/车辆rcl，平台可首先查看与如表1所示的主清单中的搭乘有关的驾驶员/车辆参数，如表3所示。基于驾驶员/车辆开始工作窗口是下午2：50(该搭乘需要在下午3：00搭接)、驾驶员/车辆工作计划的指定开始地点和搭乘的搭接点约为3英里(小于允许的例如约5英里的最大距离)以及等待或行驶到该搭乘的时间(统称为等待时间)约为8分钟(小于允许的例如约10分钟的最长时间)，平台能够对驾驶员/车辆d1分派搭乘r1。对每个驾驶员/车辆执行该初始分配检验/搜索及第一搭乘的分配过程，如表3所示，其中首先基于施加的限制，仅对驾驶员/车辆d1、d4和d5分派搭乘。尽管平台在下午2：00进行检验时主清单中有4个其他搭乘，但是也可不分派这些其他搭乘，因为受特定限制(搭接搭乘的时间、其他驾驶员/车辆离搭乘的距离、到搭乘的行使时间或等待时间)。然而，当预期新搭乘将在下午3：00截止时间之前进入时，平台能够持续进行检验，并且最后分派其他4个搭乘。在搭乘截止时间之前未获得分派的情况下，平台能够取消该限制，以在最后时刻甚或在使驾驶员/车辆工作计划活动之后，对驾驶员/车辆提供搭乘(驾驶员/车辆在活动工作计划内开始完成搭乘)。
假定所研究的地理区域是都市区，则平台可对驾驶员/车辆行驶到该地理区域的不同子区段配置不同的最长无载(没有搭乘的情况下行使的英里数)英里数。例如，地理区域可以是美国佐治亚州的亚特兰大的都市区。然而，亚特兰大的都市区由不同的自治市或城市构成，比如，亚特兰大、士麦那(smyrna)、阿尔法利塔(alpharetta)、科利奇帕克(collegepark)、以及玛丽埃塔(marietta)。此外，平台可以判定对活动确认的驾驶员/车辆的工作计划的驾驶员/车辆分派的第一搭乘允许最长允许英里数，例如，约10英里，但是在对驾驶员/车辆分派第一搭乘之后，可对全部搭乘或一些搭乘允许不同的最长允许英里数，例如，约5英里。平台也可对第一搭乘及对驾驶员/车辆分派的第一搭乘与最后搭乘之间的搭乘的等待时间(等待搭乘的时间/行驶到搭乘的时间)实现类似的可配置变量。图20中的示例性用户界面2000示出平台如何配置实现这些特征中的一些或全部特征的示意图。图20中的具体选项包含：选择预定规则名称、国家、城市、州、无载英里数、第一搭乘的时间、第一搭乘的无载时间、搭乘之间的无载时间、以分钟为单位的最后搭乘时间检验、搭接时间后的搭乘取消、搭乘之间的等待时间、以分钟为单位的开始容限值、以分钟为单位的终止容限值，以及每小时对驾驶员的支付额的选项。根据本公开的特定实施例，用于选择或输入数据的其他选项和技术能够用于该界面。
3.第三操作是基于(a)行程搭乘的估计总时长+等待时间余量(例如，每个行程≤10分钟)；(b)工作窗口内完成搭乘的能力(例如，允许比工作窗口的时间长或短约10分钟)，对驾驶员/车辆分配初始主清单中的附加搭乘。
表4示出基于上面描述的限制和示出上述时间时的主搭乘清单的表1中所示的搭乘的信息，每个驾驶员/车辆的更新rcl的示例。在图17所示的基本情况下，通过对每个搭乘和驾驶员/车辆施加该限制并且执行该第三步骤，现在从表4中的示例能够看出，平台现在已为驾驶员/车辆d1分派第二搭乘r2，并且已为驾驶员/车辆d4分派第二搭乘r3。这能对主搭乘清单中的每个其他驾驶员/车辆执行。例如，能够将所示的搭乘分派给驾驶员/车辆d2(r10和r34)和d3(r16、r21和r37)。
4.第四操作是平台继续例如每隔约1分钟对新搭乘和驾驶员/车辆工作窗口检验主搭乘清单并且考虑到一些或全部其他优化目标及规则对驾驶员/车辆单独rcl分配搭乘。图19提供图15-18示出的同一个都市区1500在下午2：45时的快照的示例。如图19所示，在下午2：45，有50个搭乘和18个有确认工作窗口或工作计划的驾驶员/车辆。平台能够在该时间点之后挂起对已分派第一搭乘的驾驶员/车辆rcl更新搭乘，并且其中第一搭乘被安排到在下午3：00开始。然而，此时之前，平台已对每个驾驶员/车辆执行了下面的操作：
a)检验驾驶员/车辆开始地点与第一搭乘搭接点之间的距离，应用上面定义的优化规则b。
b)检验完成第一搭乘的估计时间，并且确定：
i完成第一搭乘花费的时间是否≤1小时？如果是，则
●通过回答问题-净支出r1＝p1+t1≥$20吗？检验关于第一搭乘对驾驶员/车辆的净支出(r1＝p1+t1)。
○如果
■″是″
●则基于规则b和规则c(以该顺序)对rcl分派第二搭乘-因此，如果参考表2，则对于驾驶员/车辆d1，分派的第一搭乘不满足该条件，因为挣得的金额已是$18.50(示于表2第一行最后一格中)。
■″否″
●则基于规则a，分派第二搭乘，但是检验在1小时内能够完成第一搭乘+第二搭乘。现在，在对驾驶员/车辆d1完成第一初始rcl的第一迭代中，第二搭乘r2包含于表4所列的驾驶员/车辆预报工作计划(对驾驶员/车辆试探地提供)中。然而，根据表1提供的说明性数据，估计该搭乘r2的时长是40分钟。因此，r1+r2时长是35+40＝75分钟，其比60分钟(1小时)长[不包含搭乘之间的等待时间/行使时间]。因此，从驾驶员/车辆d1初始rcl中删除搭乘r1或r2(返回主清单目录)，并且为了满足该条件，利用一个或者多个搭乘更新。参考表6，在该例中，从驾驶员/车辆d1rcl中删除搭乘r2，并且利用新搭乘r11更新。参考图19，在学校搭接搭乘r11，并且在汽车旅馆卸落搭乘r11，这仅约5英里的距离和约8分钟的驾驶。参考表5，表5示出关于无载英里数和等待时间的数据。平台现在重新将搭乘r2分派给驾驶员/车辆d14。
●检验关于第一搭乘+第二搭乘对驾驶员/车辆的净支出(r1+r2)-净支出r1+r2≥$20吗？-如果现在假定搭乘r11具有(pi+ti)费率＝$12.50，则r1+r2＝$18.50+$12.50＝$31.00≥$20。因此，头两个搭乘已满足该条件。
○如果
■″是″
●则基于规则b和规则c(以该顺序)，分派第三搭乘，以开始驾驶员/车辆确认工作计划的第二小时。
■″否″
●则基于规则a，分派下一个搭乘，但检验在1小时内能够完成第一搭乘+第二搭乘+第三搭乘。
●检验关于第一搭乘+第二搭乘+第三搭乘对驾驶员/车辆的净支出(r1+r2+r3)-净支出r1+r2+r3≥$20吗？
●重复此过程，如果在该小时循环到r1+r2+r3+rn+rn+1≥$20，则转移到下一个小时。
ii完成第一搭乘花费的时间＞1小时吗？
●检验关于第一搭乘对驾驶员/车辆的净支出(r1＝p1+t1)-净支出r1＝p1+t1≥$20吗？
○如果
■″是″
●基于规则b和规则c(以该顺序)，分派第二搭乘，以开始驾驶员/车辆确认工作计划的第二小时。
●继续基于(a)行程搭乘的总估计时长+等待时间余量(每个行程≤10分钟)，以及(b)可在确认工作窗口内完成(允许比时间窗口长或短约10分钟)，对驾驶员/车辆添加主清单中的附加搭乘。
因此，如果参考表2中示出的数据，则对于驾驶员/车辆d5，第一搭乘r7满足该条件，因为估计花费的时间(搭乘时间)是70分钟，并且挣得的金额已是$43.50。应当注意，尽管该搭乘将头一个1小时延长10分钟，但是平台能够考虑到下面的因素，(a)驾驶员/车辆为70分钟的搭乘挣得$43.50，因此，满足并且胜过$20最低支出的优化目标a；(b)基于此因素(a)在驾驶员/车辆确认工作计划的第二个1小时对驾驶员/车辆分派的(多个)搭乘将分派搭乘。
■″否″
●不分派第一搭乘-基于该顺序的规则a和规则b，返回搭乘清单并且重新启动rcl，利用新第一搭乘r24代替原始第一搭乘(r1)。
●返回，以开始上述段落，并且再次重复该过程。
5.第五操作是结束对驾驶员/车辆分派搭乘的操作。这是通过下面的两个子操作实现的。
a)对每个工作窗口或工作计划内的每个小时重复上述算法。
i.重复上面描述的处理，但是大约在此时，对活动确认驾驶员/车辆工作计划添加结束最近点处的循环的限制。
ii.驾驶员/车辆rcl中的最后搭乘具有最接近正结束的驾驶员/车辆活动工作计划的结束点。
参考表6所示的数据，可注意到最后对驾驶员/车辆d7分派在仓库开始而在郊区住宅结束的搭乘r50。然而，d7工作计划结束点是体育场n，假定体育场在29号公路的路线上少约3英里，行驶时间或等待时间少约10分钟。
b)在驾驶员/车辆安排时间窗口结束时结束优化过程。
a.对于每个算法搜索，重复上述算法。
b.如果基于先前更新，对于驾驶员/车辆，成功满足全部优化条件，但是就较高的净小时支出、较短的无载英里数或搭乘之间较短的等待时间而言，较好配对驾驶员/车辆的新搭乘进入主清单，则如果通过这样做，另一个驾驶员/车辆优化目标或目的未受损，就更新驾驶员/车辆rcl。
当不再允许算法规划并且/或者算法规划被暂停时，对驾驶员/车辆在截止时间搭接的搭乘进行最终搭乘分派、安排和路线选择的过程能够由下列操作实现。
i.在预先安排与最终安排截止点之间，能够将新搭乘添加到初始主搭乘清单中。
ii.添加的这些新搭乘能够导致(a)新搭接点和卸落点更靠近每个驾驶员/车辆的第一rcl目录中最初提供的搭接点和卸落点，并且(b)不同地优化路径。因此，此时平台搜索过程能够继续更新和再更新每个驾驶员/车辆rcl，这样能够有助于改善优化上面描述的算法过程。
iii.当不再允许更新时或者当至少将更新暂停时，上面描述的优化过程能够刚好在截止时间之前使进行中的重复停止。因为几个原因，可满足暂停条件。在此，暂停意味着软件系统在指定的截止时间临时停止对驾驶员/车辆确认工作计划添加搭乘。然而，在驾驶员/车辆已开始完成确认工作计划中的搭乘后，则平台可在活动工作窗口计划期间添加或移除搭乘。因为下列原因发生暂停。
a.驾驶员/车辆可取消已确认最终敲定的搭乘的整个工作窗口，并且这些搭乘之后必须被重新分配给在确认规则计划中已开始完成搭乘的另一个驾驶员/车辆。
b.搭乘人也可在最后时刻取消搭乘，并且一个或者多个驾驶员/车辆最终敲定rcl需要通过移除取消的(多个)搭乘和利用(多个)新搭乘代替其来更新。
c.对于在截止时间时搭乘未满并且对于确认的工作窗口的时长具有足够多的搭乘的确认的长工作计划(例如＞4小时)，可对驾驶员/车辆确认rcl添加新搭乘。
上面概括的详细描述提供表明驾驶员/车辆正在对每个搭乘选择路线并且一次一个地顺序完成其的特定例子。然而，这种情况可包含″合乘″搭乘，在同一个地点或在不同地点搭接一个以上的搭乘，和在同一个地点和/或不同地点卸落搭乘，同时遵守所施加的优化目标或优化目的的特定限制。
当平台完成驾驶员/车辆的确认rcl后，该优化rcl就以将完成搭乘的顺序和序列告知驾驶员/车辆的格式存在。表7示出可投入图形显示从而对驾驶员/车辆显示该信息的数据类型的示例。请注意，如表6所示，所示的驾驶员/车辆d7数据具有确认工作窗口，该确认工作窗口具有下午4：30的开始时间、城市坐标的开始地点、郊区住宅坐标的结束地点、以及4小时的工作窗口或工作计划。表6所示的该信息以及图18-19所示信息的组合能够用于辅助产生表7和8所示的信息。
表中的信息还能够用于对驾驶员/车辆提供gps路线选择信息，允许根据rcl对gps系统智能地提供的搭乘排列顺序进行导航。
通过上面描述的算法元启发式搜索方式，能够显示要对每个驾驶员/车辆执行的一些或全部下列优化规则。
目标a-将每小时收入(rw)最大化到＞每小时$20(例如)。
目标b-最小化无载英里数(du)
目标c-最小化搭乘之间的等待时间(yw)
转到驾驶员/车辆d7和平台对驾驶员/车辆提供的并且以表9提供的说明性数据为基准的最终敲定rcl的例子，可观察到下列内容：
对于具有4小时时长的驾驶员/车辆d7确认工作计划中的每小时，能够实现目标a。例如，对于第一小时，pw＝$23.50并且tw＝$5.70，这样得出rw＝pw+tw＝$23.50+$5.70＝$29.20＞$20。
参考表7提供的说明性数据，驾驶员/车辆d7确认工作计划的第一小时的全部无载英里数du是3(0+3+0)英里。因为该第一小时的有载英里数与无载英里数的比值为22∶3，所以实现最小化无载英里数的目标。即，目的是使无载英里数除以有载英里数的分数(在该例中，
参考表7提供的说明性数据，驾驶员/车辆d7确认工作计划的第一小时的搭乘人yw之间的总等待时间是17(5+7+5)英里。因为在该第一小时行驶时间(对搭乘人的行驶时间)与搭乘人之间的等待时间的比值为45∶17，所以能够实现最小化搭乘人之间的等待时间的目标。即，目的是使搭乘之间的等待时间除以对搭乘人的行驶时间的分数(在该例中，
因此，平台的新颖特征和实现能够允许分析并且审查整个驾驶员/车辆确认工作计划，从而智能地确定如果驾驶员/车辆rcl中没有足够的搭乘用于确认工作计划、该工作计划时长中的任意给定小时、要实现的优化目标，则通过在同一个驾驶员/车辆工作计划的一个或者多个小时内进行弥补或者进行补偿，平台能够弥补一个小时内的故障，使得能够对确认工作计划的时长实现一些或全部优化目标。
随着时间的推移，如果要表达上述全部搭乘的平均总收入rw、平均总有载英里数x1以及平均总行程(载有乘客的情况下)时间x2，则将其表达为如下：rw＝ax1+bx2+z，其中a、b是分别与收入rw有关的两个输入变量x1和x2的变化率(系数)。随着时间的推移，因为平台已应用的唯一元启发式算法搜索原理，所以对于给定的任意驾驶员/车辆确认工作计划，利用几组地址坐标之间平均总x1和x2值以及每个搭乘ri的时长的时间t最大化收入rw。
随着时间的推移，平台实现的另一个总体目标可表示为平台如何实现将确认工作计划期间每个驾驶员/车辆的机会收入总损失y0最小化。在每个驾驶员/车辆确认工作计划期间，通过最小化每个搭乘的无载英里数di和搭乘yi之间的时间，平台能够实现此目标。平均总无载英里数
在另一个实施例中，特定系统和方法能够对处理选择路线并且安排与包裹递送关联的车辆搭乘。参考前面图1和2描述了在主清单中指定搭乘的能力和关联选项。例如，可将每个搭乘定义为利用至少一种车辆使人、动物和/或包裹从开始地点移动到结束地点的各自对象。然后，能够根据任意数量的驾驶员/车辆确认工作计划的优化目标和/或目的，将主清单中的搭乘组织成或划分成较小″小组(bin)″，将该小组归入rcl类。尽管搭乘位于特定驾驶员/车辆rcl中，但是存在截止时间，在该截止时间内，平台使rcl的更新停止或暂停。在平台通常允许更新rcl的时间，如果搭乘或对象是包裹递送请求，则平台能够提供允许包裹的收件人对与包裹递送请求关联的特定参数(例如，收件人的名称、递送地址、递送时间)进行更新的功能。该功能的一个方案是平台能够为收件人提供在将包裹递送到收件人之前，在不涉及初始托运人的情况下，更新托运信息的能力，并且其中初始托运人可以是也可以不是使用该平台提供包裹递送服务的第三方实体。
图21和22示出根据本公开的实施例的用户界面。智能电话或基于处理器的其他设备上执行的app或应用能够分别促进简化图21所示的示例性用户界面2100和图22所示的示例性用户界面2200。在图21所示的例子中，通过智能电话或基于处理器的其他设备上执行的app或应用，平台能够生成用户界面2100，示出如何为包裹收件人显示关于指定从一个或者多个托运人递送到该收件人的一个或者多个包裹的信息。如图21所示，例如，有四个被平台表上记号的搭乘或包裹递送2102、2104、2106、2108要递送到收件人。用于获取关于包裹的更详细信息的每个包裹递送的参数，诸如，搭接日期和时间2110、搭接地址递送日期和时间2112、搭接地点2114、递送地点2116、以及选项2118为收件人可用。用户界面2100进一步示出允许收件人点击以重新安排递送的重新安排按钮2120。当收件人激活″重新安排″按钮2120后，平台能够提供独立用户界面，以允许收件人对所选包裹递送业务更新原始参数，如图22所示。
在图22所示的示例性用户界面2200中，能够显示原始包裹递送详情2202。能够提供其他选项和数据字段，诸如，在用户界面2200上能够提供选择新递送日期和时间的选项2204和指定新递送地址的选项2206。在录入新包裹递送信息时，平台能够接收该信息，并且特定搭乘或包裹递送能够更新为新的或收到的递送信息。
图23示出根据本公开的特定实施例，通过网络与驾驶员/车辆和乘客或搭乘人通信的示例性环境和计算机网络架构。图23所示的示例性环境2300和示例性路线选择与安排服务器2302基于本公开的实施例。更具体地说，环境2300可以是计算机网络环境，包含路线选择与安排服务器2302，该路线选择与安排服务器2302与诸如例如驾驶员/车辆通信设备2304、搭乘人或乘客通信设备2306以及递送收件人通信设备2308的智能电话和/或基于处理器的设备的一个或者多个通信设备通信。此外，路线选择与安排服务器2302能够与一个或者多个支付处理器2310通信。路线选择与安排服务器2302与各种通信设备2304、2306、2308以及支付处理器2310的通信是通过网络2312进行的，网络2312可包含无线通信、有线通信或这两种类型的通信。
路线选择与安排服务器2302还称为″路线选择与安排平台″或″平台″，可用于接收、分析并且处理驾驶员/车辆数据、搭乘人或乘客请求以及与任意数量的搭乘、行程和/或递送请求关联的递送收件人数据。路线选择与安排服务器2302可包含存储器2312，该存储器2312存储程控逻辑2314(例如，软件、非临时性计算机可读介质、计算机可读指令等)并且可存储数据2316，诸如，主清单、受限候选对象目录(rcl)、初始rcl、最终rcl、优化目标和/或目的、一个或者多个算法、一组常数等。存储器2312还可包含操作系统2318。
处理器2320可利用操作系统2318执行程控逻辑2314，并且在这样做时，还可使用数据2316。数据总线2322可在存储器2312与处理器2320之间提供通信。用户可通过输入/输出(i/o)接口2324与路线选择与安排服务器2302交互，至少一个诸如显示器、键盘、鼠标、控制面板或能够与路线选择与安排服务器2302通信数据的任何其他设备的用户接口设备可连接到该路线选择与安排服务器2302或与其通信。在操作时，路线选择与安排服务器2302可通过输入/输出(i/o)接口2324与一个或者多个通信设备2304、2306、2308通信。此外，应当明白，诸如数据库、基于云的处理器或储存设备或多个其他系统和/或部件的其他外部设备可通过输入/输出(i/o)接口2324与路线选择与安排服务器2302通信。在本公开的一些实施例中，由此实现的路线选择与安排服务器2302和程控逻辑2314可包含软件、硬件、固件或它们的任意组合。还应当明白，可采用多个路线选择与安排服务器，因此，可在一个或者多个不同服务器上执行在此描述的不同特征。
图23所示的通信设备2304、2306、2308中的每个都可包含各自的处理器2326、2328、2330；存储器2332、2334、2336；以及用户接口2338、2340、2342。通信设备2304、2306、2308的处理器2326、2328、2330和存储器2332、2334、2336中的每个都可与上面对路线选择与安排服务器2302描述的处理器2320和存储器2312并且可与其具有类似的功能。通信设备2304、2306、2308的处理器2326、2328、2330中的每个还可包含gps能力或功能，也能够采用用于识别特定通信设备在地图上的地点或地理坐标的一个或者多个地点服务。
图23所示的(多个)支付处理器2310可以是能够处理诸如信用卡、借记卡、付费卡及一个或者多个优惠券或折扣代码的支付设备的一个或者多个支付服务器运行的、为主机的或辅助的第三方支付处理器。
参考根据本公开的示例性实施例的系统、方法、装置和计算机程序产品的方框图。应当明白，方框图中的至少一些方框及该方框图中的方框的组合可至少部分地由计算机程序指令执行。这些计算机程序指令可装载于通用计算机、专用计算机、基于专用硬件的计算机或其他可编程数据处理装置上，以产生机器，使得计算机或其他可编程数据处理装置上执行的指令创建用于执行方框图中的至少一些方框的或所讨论的方框图中的方框的组合的功能的单元。
这些计算机程序指令还可存储于计算机可读存储器中，这些计算机程序指令能够使计算机或其他可编程数据处理装置以特定方式工作，使得存储于计算机可读存储器中的指令产生包含执行一个或者多个方框中指明的功能的指令单元的制品。计算机程序指令还可装载于计算机或其他可编程数据处理装置上，使得在该计算机或其他可编程数据处理装置上执行一系列操作步骤，以产生计算机执行过程，使得该计算机或其他可编程数据处理装置上执行的指令提供执行一个或者多个方框中指明的功能的步骤。
通过运行于计算机的操作系统上的应用程序，可实现在此描述的系统的一个或者多个部件及方法的一个或者多个要素。在此描述的系统的一个或者多个部件及方法的一个或者多个要素还可由其他计算机系统配置实施，包含手持设备、多处理器系统、基于微处理器的或可编程的消费类电子产品、迷你计算机、主机计算机等。
作为在此描述的系统和方法的部件的应用程序可包含实现特定抽象数据类型并且执行特定任务或动作的例程、程序、部件、数据结构等。在分布式计算环境中，可将应用程序(全部或部分地)安置于本地存储器或其他储存器中。此外，或者作为另一种选择，可将应用程序(全部或部分地)安置于远程存储器或储存器中，以便用于由通过通信网络链接的远程处理设备执行任务的环境。
因为受益于上面的描述和关联附图中的教导，将想到在此阐释的示例性描述的、这些描述涉及的许多修改和其他实施例。因此，应当明白，可以许多方式实现本公开，并且本公开不应当局限于上面描述的示例性实施例。因此，应当明白，本公开并不局限于所公开的特定实施例，并且修改和其他实施例旨在包含于所附权利要求的范围内。尽管在此采用了特定术语，但是这些术语仅以通用描述性意义使用，而没有限制性意义。
- 还没有人留言评论。精彩留言会获得点赞！