车辆预订平台的制作方法

车辆预订平台
1.相关申请的交叉引用
2.本技术要求于2020年10月28日提交的标题为“车辆预订平台(vehicle reservation platform)”的申请号为63/106,627的美国临时申请的优先权，其全部公开内容通过引用整体并入本文中。


背景技术：

3.传统上，使用专用车辆可能采取拥有车辆的形式，这可能伴随有拥有成本、维护成本、潜在的复杂车辆运输物流、储存空间要求、和/或储存成本。因此，可以以其他方式使用专用车辆的用户可能会被这样的使用障碍阻止。
4.已经针对这些和其他一般考虑描述了实施例。此外，尽管已经讨论了相对具体的问题，但是应当理解，实施例不应当限于解决背景技术中确定的具体问题。


技术实现要素：

5.本公开的方面涉及一种车辆预订平台。在示例中，一个或多个库存合作伙伴经由车辆预订平台使车辆可以用于预订。因此，车辆预订平台的客户能够安排可用车辆的预订。可以提供多种预订类型，例如取车预订类型、交付预订类型、向导式预订类型或自助式预订类型。一旦客户经由车辆预订平台安排预订，车辆预订平台就可以自动与相关联的库存合作伙伴协调，以便便于完成预订。
6.在示例中，客户向车辆预订平台定期交纳(会员费)。车辆预订平台可以提供不同的订购等级，其中，每个订购等级与给定时间段的预定数量的信用相关联，潜在地在循环的基础上。因此，客户可以经由车辆预订平台将与他或她的用户账户相关联的信用兑换成车辆预订，而不是直接购买车辆预订。如果用户账户的信用余额不足，则客户可以购买额外信用来弥补不足。在示例中，车辆预订的信用成本是静态的，或者可以基于各种因素动态确定。
7.提供本发明内容是为了以简化的形式介绍将在以下具体实施方式中进一步描述的一些构思。本发明内容不旨在标识所要求保护的主题的关键特征或必要特征，也不旨在用于限制所要求保护的主题的范围。
附图说明
8.参考以下附图描述了非限制性和非穷举性的示例。
9.图1示出了车辆预订平台的示例系统的概况。
10.图2示出了示例区域的概况，在该示例区域中，使用本文中描述的车辆预订平台的方面来执行车辆预订。
11.图3a示出了由客户设备进行车辆预订的示例方法的概况。
12.图3b示出了经由车辆预订平台生成车辆预订的示例方法的概况。
13.图4示出了由车辆预订平台的库存合作伙伴履行预订的示例方法的概况。
14.图5a至图5c示出了根据本公开的方面的车辆预订平台的示例用户界面方面。
15.图6a示出了用于生成与用户账户相关联的信用的示例方法的概况。
16.图6b示出了根据本文中描述的方面的用于对处理应用信用的指示的示例方法的概况。
17.图7示出了用于实施车辆预订平台的计算系统的示意图。
具体实施方式
18.在下面的详细描述中，参考了构成描述一部分的附图，并且在附图中通过图示示出了具体实施例或示例。在不脱离本公开的情况下，可以组合这些方面，可以利用其他方面，并且可以进行结构改变。实施例可以作为方法、系统或设备来实践。因此，实施例可以采取硬件实现、完全软件实现、或者结合软件和硬件方面的实现的形式。因此，以下详细描述不应被视为限制性的，并且本公开的范围由所附权利要求及其等同物来限定。
19.在示例中，各种障碍可能使用户使用专用车辆变得复杂或以其他方式阻止用户使用专用车辆。示例障碍包括但不限于拥有成本、维护成本、潜在的复杂车辆运输物流、储存空间要求、和/或储存成本。由于这样的障碍，用户可能会避免拥有车辆，以减少的频率参与相关联的动力运动活动，或者甚至完全放弃动力运动活动。示例专用车辆包括多用途车辆和休闲车辆。例如，多用途车辆可以是低速车辆(例如高尔夫球车)、割草机或车队车辆。作为另一个示例，休闲车辆可以是全地形车辆(atv)、并排(sxs)车辆、多用途车辆、摩托车、倒三轮车(slg)、三轮车、雪地车或船只。
20.因此，本公开的方面涉及一种车辆预订平台。在示例中，预订平台提供一个或多个订购等级。订购等级与给定时间段的预定数量的信用相关联，潜在地在循环的基础上。例如，第一等级可以每月提供三个信用额，而第二等级可以每三个月提供六个信用额。订购等级可以具有预定的期限(例如，一个月每周一次、六个月每月一次、一年每季度一次)。用户可以具有车辆预订平台的用户账户，其中，用户账户与车辆预订平台提供的订购等级相关联。在给定时间段内未使用的信用可以由用户的账户保留，从而允许以后使用。例如，如果用户订购了每月提供三个信用额的订购等级，并且用户仅使用一个信用额，则两个信用额仍然与用户账户相关联，并且可以用于将来使用。将会理解，在其他示例中，信用可能到期(例如，在给定时间段之后或者在不同的预定时间段之后)。
21.如本文中所使用的,“信用”充当订购会员成本(例如，在后付费或预付费的基础上)与经由车辆预订平台预订车辆的能力之间的中介。此外，将会理解，所公开的方面的替代示例可以改为使用积分或代币，或者作为另一个示例，可以更直接地与车辆预订相关联(例如，每月一次全天预订或每季度一次两天预订)。虽然关于一个或多个信用描述了示例，但是将会理解，信用额不必是整数，而是可以是分数(例如，用户可以收到0.25个信用或者可以花费1.5个信用)。
22.车辆预订平台有可以用于预订的车辆的库存。库存可以包括一种或多种类型的专用车辆。因此，车辆预订平台的用户可以使用与用户账户相关联的信用从库存预订车辆。如果与车辆预订相关联的信用额大于与用户账户相关联的信用额，则用户可以购买额外信用。可以将购买与由订购等级提供的信用分开的信用的选项限制到向车辆预订平台定期交纳(会员费)的用户，使得非订购者可能不能直接为他们各自的用户账户购买信用。在其他
示例中，由于信用可以在循环的基础上获得，并且可以“滚动”到随后的时间段，因此用户可以选择保存信用，以便最终支付车辆预订。
23.在示例中，车辆的库存的至少一部分由车辆预订平台和/或一个或多个第三方提供，第三方在本文中可被称为“库存合作伙伴”例如，库存合作伙伴可以是车辆经销商(例如，销售专用车辆的第三方)，车辆经销商可以经由车辆预订平台使车辆可用。另一示例库存合作伙伴是车辆旅行用品商(例如，使用专用车辆提供向导式/自助式游的第三方)可以通过车辆预订平台使车辆可用。作为向车辆预订平台提供库存的结果，库存合作伙伴可以收到费用或预订收益的百分比。
24.车辆预订平台可以提供不同的预订类型。例如，取车预订类型、交付预订类型、向导式预订类型、或自助式预订类型。库存合作伙伴可以提供可用预订类型的子集，并且不需要提供经由预订平台可用的每种预订类型的预订。例如，车辆经销商可以提供预订集类型(例如，取车和交付)，而车辆旅行用品商可以提供一组不同的预订类型(例如，引向导和自助式游)。虽然本文中描述了示例库存合作伙伴，但是将会理解，经由车辆预订平台可用的库存可以由各种其他第三方中的任何一者提供。例如，个人可以经由车辆预订平台提供库存并提供相关联的车辆预订。
25.与车辆相关联的信用成本可以根据多种技术中的任何一者来确定。例如，信用成本可以根据车辆类型(例如，品牌、型号、载客量、载货量或容量)、车辆位置(例如，位置是城市还是农村等)、或者车龄来确定。作为另一个示例，信用成本可以根据各种历史和/或预测因素中的任何一者来动态地生成，包括但不限于对特定车辆类型的需求、季节性或假日需求、预订类型或可用车辆与用户的接近度。在一些示例中，不同的定价技术用于不同的订购等级。例如，与一个等级相关联的价格可以根据静态技术来确定，而另一个等级的价格则动态地确定。作为另一个示例，订购等级可以获得降低的价格。
26.用户可以通过除了向车辆预订平台定期交纳(会员费)之外的机制获得信用。在示例中，用户可以拥有专用车辆，并且可以在专用车辆进行维护时接收一个或多个信用。因此，在维修专用车辆的同时，用户可以经由车辆预订平台继续参与动力运动活动。在其他示例中，用户可以保留信用供以后使用。除了其他示例之外，作为另一个示例，用户可以接收一个或多个信用，作为将另一个用户介绍给车辆预订平台、参加活动、或者作为试用会员或忠诚度计划的一部分的交换。
27.在一些情况下，用户可以请求取消向车辆预订平台定期交纳(会员费)。如果在订购期限到期之前(例如，在六个月订购的第四个月)请求取消，则可以向用户评估取消费用。在其他示例中，取消费用可以应用于车辆所有权，从而使得用户能够有效地将车辆预订平台的订购会员“转换”为车辆所有权。类似地，与用户账户相关联的信用可以应用于车辆所有权。因此，取消费用、按比例分配的订购成本和/或与用户账户相关联的剩余信用可以用来相应地降低与车辆相关联的购买价格。
28.虽然本文中的示例是针对信用余额和应用一个或多个这样的信用来描述的，但是将会理解，每个信用不必是可替换的，而是可以是唯一可识别的。例如，信用可以具有相关联的序列号或唯一标识符。这种信用可以具有信用属性集，包括但不限于价值、起始日期和/或时间、指示信用创建原因的来源、和/或到期日和/或时间。尽管根据相关联的序列号或唯一标识符，两个信用可以是唯一可识别的，但是应该理解，两个信用不需要具有不同组
的信用属性。
29.如本文中所使用的,“唯一可识别的信用”是具有相关联序列号或其他标识符的信用。将会理解，从用户的角度来看，这样的唯一可识别的信用不必是唯一可识别的，而是可以表现为与用户账户相关联的其他信用相同或相似。此外，唯一可识别的信用不必是全球唯一的，而是与同一个用户账户相关联的一个或多个其他信用相比可以是唯一可识别的，等等。
30.价值信用属性可以提供与生成信用的背景相关联的信息。例如，价值信用属性可以指示(例如，由用户)为获得信用而发生的成本，例如，作为订购、试用会员、忠诚计划、参加活动或推荐另一个用户等的结果。因此，虽然根据本文中描述的方面，两个信用可以被类似地兑换，但是它们可以各自具有不同的价值信用属性，从而在基于一个或多个相关联的信用属性的各种其他确定中的任何一者中，实现关于与交易相关联的实际信用价值的相关联的确定。
31.例如，第一信用可以具有指示它是促销信用的价值信用属性(例如，具有名义上的关联价值)，而第二信用可以具有指示它是作为定期交纳(会员费)的结果与用户账户相关联生成的信用的价值信用属性(例如，具有与会员等级相关联的价值)。在示例中，两个信用可以一起应用(例如，对于花费两个或更多信用的预订或其他项目/服务)或分开应用(例如，对于两个这样的项目或服务)。当用户应用信用余额时，可以确定信用集(例如，至少部分地基于用户选择、自动地、或其组合等等)并相应地应用该信用集。
32.与每个信用相关联的价值信用属性可以使得实现对一个或多个度量的确定，例如当应用信用集时或者当确定用户账户的信用余额时。例如，实现度量可以基于合计该组已应用信用的每个信用的价值信用属性，并将总价值与该信用集所应用的一个或多个项目/服务的成本进行比较来确定。类似地，总价值可以用于更准确地将信用集应用于项目/服务(例如，对于该项目/服务，用户没有足够的信用)，当用户根据本文中描述的方面将信用集应用于车辆所有权时可能是这种情况，等等。因此，与可以使用平均信用价值的基于余额的评估相比，本文中描述的方面可以基于每个信用的关联信用价值属性更准确地确定该信用集的总价值。
33.在一些示例中，可以确定的是只有信用的子集可以基于相关联的信用属性应用于给定的项目或服务，当给定的信用已经过了其到期日或者项目/服务只能使用非促销信用来获得时就是这种情况。作为另一个示例，可以确定的是信用的总价值低于将兑换该信用集的项目/服务的成本。在这样的情况下，可以确定不同组的信用是否可以应用于该交易(例如，具有更接近或至少等于成本的总价值)，或者这样的交易是否不可以可用于用户选择。
34.根据本文中描述的方面的信用属性可以用于各种其他处理中的任何一者。例如，到期日信用属性可以用于确定是否终止或移除与用户账户相关联的信用。在另一个示例中，到期日信用属性可以导致价值信用属性由于到期日信用所指示的日期/时间已经过去而被更新。
35.用户可以将他们的信用余额的至少一部分从一个用户账户转移到另一个用户账户。用户可以选择一组唯一可识别的信用进行转移，或者作为另一个示例，该信用集可以使用多种技术中的任何一者来自动确定，其示例将在下面进行讨论。在一些情况下，一个或多
个信用属性可以由于转移而被更新。例如，可以设置信用属性来指示从哪个用户转移了信用。作为另一个示例，可以由于转移而减少或者以其他方式改变价值信用属性。在一些情况下，信用可以转移预定的次数，在此之后，它可能不再被转移。在这样的情况下，可以更新相关联的信用属性，以减少剩余转移的数量。虽然描述了示例信用属性，但是将会理解，在其他示例中可以使用额外的、替换的或更少的信用属性。
36.因此，与更简单的基于余额的信用处理相比，本文中描述的方面可以实现否则难以或不可能实现的细度级别和相关联的度量的生成。此外，考虑到生成信用的背景可能随时间而改变(例如，根据地区或场所，基于会员选项的改变，或基于各种其他因素中的任何一者)，维护每个信用的信用属性集可以实现基于这样的因素的额外处理。例如，为第一背景(例如，在区域中或在第一时间)生成的信用可以具有比为第二背景(例如，在不同区域中或在第二时间)生成的信用更低的关联价值，使得第一区域中的交易的实现度量可以不同于第二区域中的交易的实现度量，即使该交易是针对相同或相似的项目/服务。
37.虽然在预订车辆预订平台和相关联的专用车辆的背景中描述了示例，但是将会理解，本文中描述的方面可以应用于各种其他背景中的任何一者。例如，信用集可以应用于不同的订购(例如，应用于软件订购和/或物理项目订购)，以解锁软件或硬件功能，用于一个或多个附件、和/或交换车辆维护，等等。
38.作为另一个示例，除了其他示例之外，在酒店场景中或者作为忠诚度计划的一部分(例如，如本文所述，在用户因为互动赢得信用和/或信用随着时间的推移可能过期或者价值降低的情况下)，可以根据本文中描述的方面来管理信用余额。因此，用户可以类似地将信用应用于体验的各个方面，体验包括住宿、餐饮和/或任何各种其他便利设施。在一些示例中，用户的信用余额可以包括不同类型的唯一可识别的信用，例如可以具体应用于餐饮或者一个或多个便利设施。在其他示例中，将会理解，用户的信用余额不需要特别适用于给定的一组项目/服务。相反，每种体验可以反而具有相关联的信用额度。在这样的示例中，用户可以由于忠诚计划、订购和/或推荐等等来获得信用。
39.因此，本文中描述的车辆预订平台便于根据订购模型进行简单方便的车辆预订。用户使用与用户账户相关联的信用(例如，根据相关联的订购等级获得的信用)来预订专用车辆。作为响应，车辆预订平台可编程地协调与车辆预订相关联的物流(例如，使用或者第一方或者第三方)。这样的方面减少或解决了传统上与访问专用车辆和相关联的动力运动活动相关联的障碍，从而使得更多的用户能够通过所公开的车辆预订平台参与这样的活动并利用专用车辆。
40.图1示出了用于车辆预订平台的示例系统100的概况。如图所示，系统100包括客户设备102、旅行用品商设备104、经销商设备106、网络108和预订平台110。在示例中，客户设备102、旅行用品商设备104、经销商设备106和预订平台110经由网络108进行通信，网络108可以包括局域网、无线网络、或互联网、或其任意组合等。
41.预订平台110可以是服务器计算设备，或者可以是形成分布式计算设备的一组计算设备。客户设备102、旅行用品商设备104和经销商设备106可以各自是各种计算设备中的任何一者，包括但不限于移动计算设备、膝上型计算设备、平板计算设备或台式计算设备。将会理解，虽然系统100示出为包括一个预订平台110和三个设备102、104和106，但是在其他示例中可以使用任意数量的这样的元件。此外，在其他示例中，本文中描述的关于预订平
台110和设备102、104和106的功能可以分布在任何数量的不同计算设备中或者以其他方式实现在任何数量的不同计算设备上。
42.预订平台110示出为包括请求处理器118、调度引擎120、库存管理器122、定价引擎124、预订数据存储126和用户数据存储128。在示例中，请求处理器118与一个或多个其他设备(例如，分别是设备102、104和106的应用程序112、114和116)通信，以提供本文中描述的车辆预订平台的方面。请求处理器118提供关于可用库存的指示(以及，在一些示例中，其中，车辆的相关联信用成本，如可以由定价引擎124确定的)、接收与可用库存相关联的预订请求、从库存合作伙伴接收库存和预订更新、以及提供预订更新等功能。例如，请求处理器118可以生成网站(例如，可以由应用程序112、114和/或116访问)，利用该网站来管理会员、预订车辆、使库存可用于预订、和/或管理预订履行，等等。在其他示例中，请求处理器118提供应用编程接口(api)(例如，应用编程接口(api)可以由应用程序112、114和/或116使用)来执行这些方面，作为网站的替代或补充。因此，将会理解，可以使用多种技术中的任何一者来与预订平台110通信。
43.调度引擎120生成、修改、删除、跟踪或以其他方式管理预订平台110的车辆预订。在示例中，车辆预订存储在预订数据存储126中。可以从客户设备102的客户端应用程序112接收对预订的指示。车辆预订可以与(例如，用户数据存储128的)用户账户相关联，并且可以具有一个或多个相关联的车辆、预订时间(例如，包括时间范围或一个或多个日期)、和/或预订类型(例如，取车、交付、引向导或自助式游)。在一些情况下，车辆预订与多个用户账户相关联，从而使得多个用户能够一起预订一辆或多辆车辆。可以相应地减少与用户账户相关联的信用余额，并且在一些情况下，可以相应地处理对购买额外信用的指示。
44.在一些情况下，调度引擎120(结合请求处理器118)向旅行用品商设备104的预订应用程序114或经销商设备106的库存应用程序116提供预订指示，从而向旅行用品商或经销商警告来自预订平台110的用户的预订请求。在其他示例中，调度引擎120从与用户的预订相关联的旅行用品商设备104或经销商设备106接收更新指示。作为响应，调度引擎120可以更新预订数据存储126中的预订和/或可以生成提供到客户设备102的指示。
45.库存管理器122管理经由预订平台110可用的库存。回到上面的示例，库存管理器122可以从与来自客户端应用程序112的车辆预订相关联的库存中移除一辆或多辆车辆，从而确保另一个用户不会同时预订同一组车辆。另外或替代地，库存管理器122可以从正在维修的库存移除一辆或多辆车辆。另外或替代地，库存管理器122可以向库存添加由客户退回和/或由装备商购买和/或由经销商制造的一辆或多辆车辆。库存管理器122还可以处理来自预订应用程序114和/或库存应用程序116的指示。例如，预订应用程序114可以指示与旅行用品商设备114相关联的旅行用品商已经独立地处理了车辆的预订，使得车辆在特定日期和时间经由预订平台110不可用。作为另一个示例，库存应用程序116可以指示与经销商设备106相关联的经销商已经售出了车辆，从而不再为该车辆进行预订。因此，将会理解，库存管理器122可以处理各种指示中的任何一者(例如，与预订平台110的用户相关联或者来自各种库存合作伙伴中的任何一者)，以便维护可用于预订的车辆的准确库存。
46.定价引擎124可以为预订平台110的车辆预订生成信用成本。在示例中，定价引擎124例如基于车辆类型(例如，品牌、型号、载客量、载货量或容量)、车辆位置(例如，该位置是城市还是农村等)、或者车龄为车辆预订生成静态信用成本。在其他示例中，定价引擎124
根据各种历史和/或预测因素中的任何一者来生成车辆预订的动态信用成本，这些因素包括但不限于对特定车辆类型的需求、季节性或假日需求、预订类型、或可用车辆与用户的接近度。因此，定价引擎124可以根据调度或响应于各种事件中的任何一者，为与车辆库存相关联的车辆预订生成信用成本。例如，在其他示例中，在将车辆添加到车辆库存时和/或响应于对当前可用库存的请求(例如，可以由请求处理器118从客户设备102的客户端应用程序112接收)，信用成本可以由定价引擎124生成。
47.在示例中，定价引擎124可以根据与用户账户相关联的信用集来生成动态信用成本，例如基于相关联的价值信用属性和/或任何各种其他信用属性。类似地，定价引擎124可以响应于用户指示，例如至少部分地基于用户指示、自动地、或其组合，根据用户的信用余额确定要应用的信用集。
48.用户数据存储128存储预订平台110的用户账户。如上所述，请求处理器118处理与预订平台110的会员相关联的请求。例如，向预订平台110定期交纳(会员费)的请求可以接收为注册过程的一部分，这可以指示订购等级。因此，在用户数据存储128中生成指示用户的所选择的订购等级的用户账户。用户账户还可以包括计费信息(例如，信用卡信息和计费地址)、联系信息(例如，电子邮件地址、电话号码和/或邮寄地址)、和/或续订首选项(例如，订购是否应该自动续订或者是否应该在续订之前发送续订通知)。
49.预订平台110可以周期性地向用户数据存储128的用户账户添加信用。如上所述，订购等级可以在给定时间段内提供预定数量的信用。因此，当已经过去了大于预定时间段的时间量时，预订平台110根据用户的订购等级的预定信用数量(可以由与用户账户相关联的订购等级来指示)来增加用户账户的信用余额。在其他示例中，预订平台110生成唯一可识别的信用，并将所生成的信用与用户账户相关联，其示例将在下面参考图6a更详细地讨论。例如，第一用户可以订购每月接收一个信用的等级，第二用户可以订购每月接收三个信用的第二等级，并且第三用户可以订购每月接收九个信用的第三等级。每一等级都可以有一个相关联的期限，比如第一等级和第二等级为12个月，并且第三等级为六个月。将会理解，等级和相关联的成本、信用额、时间段和期限是为了示例性目的而提供的，并且在其他示例中，可以使用其他等级。
50.将会理解，等级可以线性或非线性扩展。例如，第一等级的一个信用可能花费99美元/月(每信用99美元)，而第二等级的三个信用可能花费249美元/月(每信用83美元)。因此，与第一等级的每信用成本相比，第二用户对于三个信用的等级获得50美元/月的折扣。类似地，第三等级的九个信用点可能花费699美元/月(每个信用点77.67美元)，使得第三用户接收三倍于第二等级的信用，但是花费少于三倍。根据本文中描述的方面，当使用信用来预订车辆时，用户账户的信用余额根据所预订车辆的信用成本来减少。用户可以在收到信用期间使用信用，也可以保留信用供以后使用。例如，第三用户可以每个月花费所有九个信用。作为另一个示例，第二用户可以保留三个月的信用(例如，根据第二订购等级，每月三个信用)，以最终做出与第三用户在一个月中做出的预订等效的预订集(例如，花费九个信用)。
51.在一些情况下，信用可以在用户账户之间转移。例如，第一用户可以向第二用户发送信用余额的至少一部分，使得第一用户的用户账户的信用余额减少的额度类似于第二用户的用户账户的信用余额的相应增加的额度。在一些情况下，可以从转移的额度中减去费
用(例如，以绝对值或百分比的形式),从而不会将全部信用余额从第一用户转移到第二用户。在其他情况下，两个用户可以“汇集”他们各自的信用余额，从而可以利用多个用户账户的信用余额进行预订。这样的团体预订的一个或多个车辆的相关联的信用费用可以在多个用户账户中平均分摊，或者根据用户确定的任何其他划分方式分摊。
52.如上所述，由于用户账户之间信用转移，可以添加、删除或修改一个或多个信用属性。此外，在信用成本在多个用户账户之间划分的示例中，可以基于每个用户贡献的该信用集来执行以上关于唯一可识别的信用的处理。例如，考虑到应用该信用集的一个或多个项目/服务的成本(例如，一个或多个专用车辆的团体预订)，可以基于来自每个用户的该信用集组的总价值来确定实现度量。在其他示例中，实现度量可以基于个人或者根据各种其他分组中的任何一者(例如，按地区、按姓氏或者按会员持续时间)来计算，而不是按团体实现度量(和/或其他度量)。
53.将会理解，用户账户不需要与单个个人相关联，并且在一些示例中，可以改为与一组个体(例如，夫妇、家庭等)相关联。作为注册过程的一部分，可以接收一个或多个个人的已执行弃权，并随后相应地与用户账户相关联。除了其他信息之外，紧急联系信息和/或保险信息也可以存储为用户账户的一部分。在示例中，根据本文中描述的方面，用户账户进一步包括可用于进行车辆预订的信用额度。额度可以周期性地递增，这可以基于与用户账户相关联的订购等级来确定。在一些示例中，可以使用预先存在的用户账户。例如，另一个平台或服务可能已经具有典型地将从用户请求的信息的至少一部分，使得可以将其复制或以其他方式并入车辆预订平台的用户账户。
54.客户设备102示出为包括客户端应用程序112。在示例中，客户端应用程序112是网络浏览器、本地应用程序或其组合。如上所述，客户端应用程序112与预订平台110通信，以执行本文中描述的车辆预订方面。例如，客户端应用程序112便于注册过程，其中，向用户呈现可用订购等级集，从而使得用户能够选择订购等级并相应地创建用户账户。类似地，客户端应用程序112可以呈现弃权并收集用户的电子签名以及其他信息(例如，计费信息、联系信息和/或紧急联系信息)。
55.客户端应用程序112可以生成可用车辆的显示，从而使用户能够预订车辆。在示例中，客户端应用程序112从预订平台110的库存接收可用车辆集(例如，可以由请求处理器118结合调度引擎120、库存管理器122和/或定价引擎124生成)。可以至少部分地基于过滤标准集来过滤该组可用车辆(例如，在客户设备102处或通过预订平台110)。该组过滤标准可以在预订平台110处确定和/或由客户设备102的用户提供。示例过滤标准包括但不限于车辆类型(例如，品牌、型号、载客量、载货量或容量)、车辆位置(例如，位于地理位置的预定范围或预定范围内)、可用性信息(例如，特定日期和/或时间，或车辆是否在特定天数内可用)、和/或用户账户信息(例如，是否有足够的信用与用户账户相关联，或限制是否影响特定车辆的可用性或特定季节期间的预订)。虽然这里讨论了示例过滤，但是应该理解，在其他示例中可以使用额外的、替代的或更少的过滤。
56.用户使用客户端应用程序112进行车辆预订。因此，根据所描述的方面，客户端应用程序112与预订平台110通信，以在预订数据存储126中生成预订。与用户账户相关联的信用额度可以相应地减少。在预订的车辆由库存合作伙伴提供的示例中，可以相应地向合作伙伴(例如，向旅行用品商设备104或经销商设备106)提供指示。客户端应用程序112和预订
平台110还可以使用户能够延长预订(例如，从全天预订到过夜预订)。与用户账户相关联的信用余额可以相应地递减，或者在其他示例中，用户可以购买本文中描述的额外信用。
57.在一些示例中，根据本文中描述的方面，减少用户账户的信用余额可以包括从用户账户的信用余额应用特定的唯一可识别的信用集。例如，用户可以提供对要应用的一个或多个信用的指示，从而相应地应用所指示的信用。示例指示包括但不限于对特定信用的指示、对应用即将到期的信用的指示、或对应用在特定背景(例如，由于订购、试用会员、忠诚度计划、参加活动或推荐另一个用户)中获得的信用的指示。
58.在这样的情况下，可以显示呈现与用户账户相关联的信用中的至少一些信用的用户界面，使得用户可以选择所呈现的信用中的一者或多者。在其他示例中，可以呈现指示用户具有一个或多个即将到期的信用的用户界面元素，使得用户可以启动用户界面元素来指示这样的信用应该在与用户账户相关联的其他信用之前应用。虽然公开了示例用户界面方面和相关联的行为，但是将会理解，可以使用各种其他用户体验范例中的任何一者。
59.在其他示例中，一个或多个信用可以自动地确定，例如由于使用各种标准中的任何一者来评估一个或多个信用属性而自动地确定。例如，可以根据先进先出(fifo)方法自动应用信用，使得减少用户的信用余额包括识别一个或多个最早的信用。作为另一个示例，可以根据相关联的价值信用属性来确定信用，其中，在用户信用余额的其他信用之前应用具有最低或最高价值信用属性的信用。在一些情况下，可以使用手动选择和自动信用确定的组合。因此，可以理解，根据本文中描述的方面，可以使用多种技术中的任何一者来确定要应用的信用集。
60.系统100进一步包括旅行用品商设备104和分配者设备106，它们被预订平台110的库存合作伙伴用来预订平台使库存可用，以及管理相关的预订。在示例中，预订应用程序114和库存应用程序116与预订平台110的请求处理器118通信，以管理通过每个相应的库存合作伙伴可用车辆的库存。例如，预订应用程序114和库存应用程序116可以提供关于不再可用的库存的指示(例如，由于独立于预订平台110的预订或售出的库存)。此外，预订应用程序114和库存应用程序可以接收经由预订平台110发出的对预订的指示，从而使得每个相应的库存合作伙伴能够履行预订。例如，预订应用程序114可以随后将向导分配给具有向导式预订类型的预订，或者作为另一个示例，库存应用程序116可以组织与具有交付预订类型的预订相关联的交付物流。虽然本文中描述了示例库存合作伙伴交互，但是也可以使用其他技术。例如，库存合作伙伴可以访问预定的预订列表并选择一个或多个预订来履行，而不是自动将预订分配给库存合作伙伴。
61.在一些示例中，预订应用程序114和库存应用程序116使得能够提供预订更新，可以将预订更新传送到客户设备102和/或将预订更新存储用于审计目的。在一些示例中，经销商设备106是移动设备或者以其他方式与递送驾驶员的移动设备通信，从而使得客户设备102能够提供用户的车辆递送预订的位置的基本上实时的视图。将会理解，预订应用程序114和库存应用程序116不需要提供类似的功能，而是可以反而各自提供上述特征的子集，或者可以进一步提供额外的或替代的特征。此外，预订应用程序114和库存应用程序116不必是独立的应用程序。相反，在其他示例中，这样的功能可以替代地集成到其他软件中。
62.图2示出了示例区域200的概况，在该示例区域200中，使用本文中描述的车辆预订平台的各方面来执行车辆预订。如图所示，区域200包括用户位置202、城市204、服务区206、
库存合作伙伴208、210和212以及拖车头214、216、218和220。在一些情况下，客户应用程序(例如，图1中客户设备102的客户应用程序112)生成类似于区域200的显示。
63.在示例中，车辆预订平台(例如，图1中的预订平台110)使得用户能够在服务区内进行车辆预订。例如，服务区206表示距离城市204两小时的车程。因此，用户可以为服务区206内的任何位置进行车辆交付预订。虽然服务区206示出为以城市204为中心的圆，但是将会理解，服务区可以根据多种约束中的任何一者采取多种形状中的任何一者。作为另一个示例，每个相应的库存合作伙伴可以具有相关联的服务区。此外，将会理解，当用户位于用户位置202时，用户不需要限制于服务区206内的预订。相反，用户可以在各种其他位置和相关服务区中的任何一者处进行车辆预订。例如，用户可以在不同的州或在另一个城市的服务区内针对车辆进行车辆预订。
64.在其他示例中，库存合作伙伴208、210和212可以是分销商和/或旅行用品商。库存合作伙伴208、210和212的车辆可通过本文中描述的预订平台进行预订。例如，用户可以在库存合作伙伴208处进行取车预订，使得用户可以从用户位置202开车到库存合作伙伴208，以便在车辆预订周期间提取车辆。作为另一个示例，用户可以从库存合作伙伴210进行交付预订，由此库存合作伙伴210接收对将车辆交付到用户位置202或用户选择的另一个位置的指示。
65.在一些情况下，用户可以改为选择拖车头214、216、218或220，使得库存合作伙伴相应地接收对将车辆交付到拖车头的指示。在这样的情况下，预定平台可以识别靠近所选择的拖车头的库存合作伙伴，并且在库存中具有所请求的车辆(以及，在一些情况下，可用的向导)以履行预定。例如，可以选择库存合作伙伴212将车辆交付给拖车头218，而可以选择库存合作伙伴210将车辆交付给拖车头214。在一些情况下，库存合作伙伴可能与拖车头等距(例如，库存合作伙伴210和212相对于拖车头220)。在这样的情况下，预订平台可以评估每个库存合作伙伴的库存，以确定哪个库存合作伙伴具有最多的可用库存。将会理解，可以评估多种额外或替代因素中的任何一者，例如历史或预测的需求，以及与车辆交付相关联的估计驾驶时间。
66.在一些情况下，与车辆预订相关联的信用成本是动态确定的(例如，通过定价引擎，例如图1中的定价引擎124)。例如，由于库存合作伙伴212比拖车头220更靠近拖车头218，所以与车辆交付到拖车头218相关联的信用成本可以小于与车辆交付到拖车头220相关联的信用成本。作为另一个示例，在给定日期与车辆交付到尾部220相关联的信用成本可以随着可用库存的减少而增加。例如，库存合作伙伴210和212(其最接近拖车头220)可能没有剩余库存，并且由于库存合作伙伴208离拖车头220的距离，来自库存合作伙伴208的交付的信用成本可能相对更贵。
67.图3a示出了由客户设备(比如图1中的客户设备102)进行车辆预订的示例方法300的概况。方法300的各方面可以由客户端应用程序来执行，比如图1中的客户端应用程序112。方法300开始于操作302，其中，生成可用车辆的显示。显示可以是网站或移动应用的一部分，等等。可以与用于预订相应车辆的信用成本相关联地显示车辆，这可以根据本文中描述的方面静态或动态地确定。可以从预约平台(比如图1中的预约平台110)接收可用车辆。
68.在一些情况下，响应于客户设备的请求，接收该组可用车辆。例如，请求可以包括用户位置、过滤标准集(例如，车辆类型、日期/时间、乘客/货物容量和/或能力)、和/或与用
户账户相关联的会话标识符。在示例中，仅显示可用车辆的子集。例如，可以根据多种标准中的任何一者来过滤可用车辆。在其他示例中，代替由客户设备执行的过滤或者除了由客户设备执行的过滤之外，由预订平台过滤可用车辆。在一些情况下，可用车辆的显示类似于图2中的区域200，或者在其他示例中，显示可以包括作为地图的替代或除地图之外的列表。列表可以根据信用成本、与用户的接近度或受欢迎程度等来排序。
69.在操作304处从用户接收对可用车辆的选择。用户可以通过点击或轻敲在操作302处显示的车辆中的一者来选择车辆。将会理解，在其他示例中可以使用多种其他用户输入技术中的任何一者，比如使用语音输入、或者软件或硬件键盘。在一些情况下，用户需要额外的信息，比如期望的交付地点、取车时间段或预订天数。在用户账户没有相关联的弃权或者与用户账户相关联的弃权过期的情况下，可以提示用户重新执行弃权。将会理解，在操作304处可以向用户请求多种额外或替代信息中的任何一者，并且可以至少部分地基于用户的车辆选择。
70.流程进行到操作306，在操作306处向预订平台提供对所选择的车辆的指示。例如，该指示包括车辆选择、预订的相关联日期/时间和/或在操作304处从用户请求的额外信息。在一些情况下，通过在网站上提交表格或使用api等等来提供指示。可以提供指示来为所选择的车辆生成临时预订，从而确保另一个用户不会在该即时用户之前完成车辆预订过程。在一个示例中，预订平台可以指示用户的账户没有足够的信用来完成预订。
71.在示例中，在操作302处生成的显示可以进一步包括对一个或多个唯一可识别的信用的指示，根据本文中描述的方面，可以由用户选择(例如，在操作304处)。在其他示例中，可以生成提示(例如，由于在操作304处接收到的选择)，这使得用户能够选择一个或多个信用，或者作为另一示例，提供对应用即将到期的一个或多个信用的指示。因此，操作306可以进一步包括提供对与这样的用户输入相关联的指示(例如，对所选择的信用的指示或者对应用即将到期的一个或多个信用的指示，等等)。这样的显示或提示可以选择性地呈现，例如当用户的信用接近到期时(例如，低于预定的阈值天数)。在其他示例中，可以确定，没有信用即将到期，或者与用户账户相关联的每个信用具有相同或相似的信用属性，从而不向用户呈现提供这样的指示的能力。
72.因此，在确定308处确定用户的账户是否具有足够的信用来预订所选择的车辆。在示例中，该确定包括评估接收到的对在操作306处提供的指示的响应，该响应可以指示需要额外信用。在其他示例中，该确定包括与用户账户(例如，可以从预订平台请求或者可以缓存在客户设备上)相比，评估在操作304处接收的车辆选择。
73.如果确定用户没有足够的信用，则流程转向“否”分支到操作310，在操作310处生成信用选项的显示。该显示可以包括一个或多个选项来补充与用户账户相关联的信用余额。在示例中，显示基于从预订平台接收的信用选项集。作为示例，所生成的显示包括购买与用户账户相关联的信用与所选择的车辆的信用成本之间的信用差的选项。
74.在确定312处确定是否接收到对购买额外信用的选择。如果确定用户没有选择购买额外信用，则流程转向“否”分支到操作302，在操作302处再次向用户呈现可用车辆的显示，从而使得能够选择不同的车辆(例如，信用成本等于或低于用户账户的信用余额的车辆)。然而，如果确定用户选择购买额外信用，则流程转而转向“是”分支到操作314，在操作314处将对购买选择的指示提供到预订平台。在示例中，该指示可以包括计费信息，或者在
其他示例中，用户的计费信息存储在用户账户中。因此，预订平台处理交易，并且流程前进到操作316，操作316将在下面进行讨论。
75.返回到确定308，如果确定用户具有足够的信用，则流程转而转向“是”分支并从确定308移动到操作316，在操作316处接收对预订确认的指示。在示例中，该指示包括确认号、预订指令(例如，取车指令、交付指令、向导式/自助式游指令)、可用性估计(例如，估计的交付时间或估计的取车时间，在此之后车辆可以用于取车)、和/或与用户账户相关联的剩余信用余额。
76.流程前进到操作318，在操作318处生成确认的预订的显示。该显示可以包括在操作316处接收的各种信息中的任何一者。例如，该显示可以包括确认号、预订指令中的至少一部分、可用性估计和/或剩余信用余额。在示例中，该显示进一步包括与(例如，库存合作伙伴的)取车位置、拖车头位置或交付位置相关联的地图。使用虚线框示出了操作320，以指示在一些情况下，方法300在操作318处终止。
77.在其他情况下，流程前进到操作320，在操作320处生成预订更新的显示。例如，预订平台可以提供关于对交付驾驶员的位置的指示或者对车辆取车预订准备好接收的指示，等等，使得在操作320处生成的显示相应地反映预订更新。作为另一个示例，作为生成更新的显示的替代或补充，可以生成通知。将会理解，操作320可以被执行任意次。此外，虽然描述了示例用户界面和用户体验方面，但是根据本公开的方面，可以使用多种类似技术中的任何一者来使用户能够进行预订、购买额外信用以及查看车辆预订平台的预订状态。流程最终在操作320处终止。
78.图3b示出了用于经由车辆预订平台生成车辆预订的示例方法350的概况。在示例中，方法350的各方面由预订平台执行，预订平台比如图1中的预订平台110。方法350开始于操作352，在操作352处生成可用车辆集。操作352的各方面可以由调度引擎来执行，调度引擎比如图1中的调度引擎120。在一些情况下，基于作为来自客户设备(例如，图1中的客户设备102)的请求的一部分接收的信息，生成该组可用车辆。例如，请求可以包括用户位置、过滤标准集(例如，车辆类型、日期/时间、乘客/货物容量和/或能力)、和/或与用户账户相关联的会话标识符。可以根据多种标准中的任何一者来过滤所生成的该组可用车辆。在其他示例中，代替由预订平台执行的过滤或者除了由预订平台执行的过滤之外，由客户设备过滤可用车辆。
79.流程进行到操作354，在操作354处向客户设备提供对可用车辆的指示。在示例中，该指示包括其中每个可用车辆的信用成本(例如，可以由比如图1中的定价引擎124之类的定价引擎生成)。在其他示例中，该指示仅包括可用车辆的子集。例如，该组可用车辆可以作为网站的多个页面来提供，或者可以在地图的背景中提供(例如，类似于图2中的区域200)，可以至少部分地基于与用户位置的接近度等等来过滤该地图。在其他示例中，所生成的该组可用车辆经由api等技术提供。
80.在操作356处接收对车辆选择的指示。该指示可以经由请求处理器(比如图1中的请求处理器118)来接收。在示例中，由于客户设备执行图3a中的方法300的操作306的各方面，接收到该指示。该指示还可以包括预订的相关联日期/时间和/或与用户相关联的额外信息。在一些情况下，由于在网站上或经由api等提交表格，接收到指示。
81.如上所述，根据本文中描述的方面，可以接收与一个或多个唯一可识别的信用相
关联的用户输入。因此，在操作356处接收的指示可以进一步包括对这样的用户输入的指示。类似地，下面讨论的确定358可以包括确定将被应用于车辆预订的与用户账户相关联的信用集。根据本文中描述的方面，可以基于用户输入(例如，基于对可以在操作356接收的用户输入的指示)、和/或自动地、或其任意组合来确定该信用集。
82.在确定358处确定是否有足够的与用户账户相关联的信用来预订在操作356处指示的车辆。在示例中，该确定包括比较与用户账户相关联的信用余额和车辆的信用成本(例如，可以由定价引擎生成，定价引擎比如图1中的定价引擎124)。
83.如果确定用户没有足够的信用，则流程转向“否”分支到操作360，在操作360处提供对额外信用选项的指示(例如，可以由执行图3a中方法300的操作310的各方面的客户设备显示)。作为示例，额外信用选项可以包括购买用户账户的信用与所选择的车辆的信用成本之间的信用差的选项。在一些情况下，可以提供额外信用选项。
84.在确定362处确定用户是否选择购买额外信用。如果确定用户没有选择购买额外信用，则流程转向“否”分支到操作352，在操作352处生成可用车辆集。在一些示例中，流程可以改为转向“否”分支到操作356，在操作356处接收对车辆选择的新指示。例如，客户设备可以缓存先前在操作354处提供的该组可用车辆，使得流程转而分支到操作356。
85.在一些情况下，确定362包括接收对购买选择的指示(例如，可以由执行图3a中的方法300的操作314的各方面的客户设备提供)。该指示可以包括计费信息，或者在其他示例中，可以从用户账户访问计费信息(例如，可以由用户数据存储来存储，用户数据存储比如图1中的用户数据存储128)。因此，流程转向“是”分支到操作364，在操作364处更新用户账户以反映用户购买的信用。在示例中，根据本文中描述的方面，更新用户账户可以包括生成与用户账户相关联的一个或多个唯一可识别的信用。在一些示例中，操作364的各方面进一步包括处理与信用购买相关联的支付，这可以根据作为指示的一部分接收的或作为用户账户的一部分存储的支付信息来处理。流程然后继续到操作366，操作366将在下面进行讨论。
86.返回到操作358，如果确定用户具有足够的信用，则流程转而转向“是”分支到操作366，在操作366处生成预订并将其与用户账户相关联。因此，由于与用户账户相关联的信用，不需要为车辆预订处理支付。实际上，在用户具有足够信用的示例中，根本不需要处理支付。此外，在购买额外信用的情况下，用户账户的信用余额可以根据信用购买而增加，并随后减少以完成车辆预订。因此，如上所述，用户账户的信用余额可以充当与订购会员相关联的货币成本(以及额外信用购买)和用户经由车辆预订平台预订车辆的能力之间的中介。在示例中，更新用户账户可以包括应用唯一可识别的信用集(例如，可能已经被手动选择和/或自动确定)，使得信用不再与用户账户相关联和/或被更新以指示它们已经被应用并且因此在将来不可使用。操作366的各方面可以由调度引擎来执行，调度引擎比如图1中的调度引擎120。例如，预订在预订数据存储(例如，图1中的预订数据存储126)中生成，并且与用户数据存储(例如，用户数据存储128)中的用户账户相关联。
87.流程进行到操作368，在操作368处向客户设备提供对预订确认的指示。该指示可以包括确认号、预订指令(例如，取车指令、交付指令、向导式/自助式游指令)、可用性估计(例如，估计交付时间或估计取车时间，在此之后车辆可以取车)、和/或与用户账户相关联的剩余信用余额。在一些情况下，向库存合作伙伴(例如，装备商或经销商)提供指示，该指示可以由装备商设备或经销商设备接收，比如图1中的装备商设备104或经销商设备106。该
指示可以使库存合作伙伴能够执行与履行预订相关联的动作。使用虚线框示出了操作370和372，以指示在一些示例中，方法350在操作368处终止。
88.然而，在其他示例中，流程前进到操作370，在操作370处从库存合作伙伴(例如，在操作368处向其提供了指示)接收对预订更新的指示。例如，该指示可以涉及交付预订(例如，交付驾驶员的位置)或者可以包括对车辆收取预订准备好取车的指示，等等。因此，在操作372处将对预订更新的指示提供到客户设备。在一些情况下，操作372进一步包括基于预订更新相应地更新预订数据存储中的预订。当从库存合作伙伴接收到更新时，可以执行操作720和372任意次。流程最终在操作372处终止。
89.图4示出了用于由车辆预订平台的库存合作伙伴履行预订的示例方法400的概况。在示例中，方法400的各方面可以分别由比如图1中的旅行用品商设备104或经销商设备106之类的旅行用品商设备或经销商设备来执行。方法400开始于操作402，在操作402处接收到预订确认的指示。在示例中，从预订平台接收指示，预订平台比如图1中的预订平台110。预订平台可以执行图3b中的方法300的操作368的各方面。
90.流程前进到操作404，在操作404处基于确认的预订分配库存。在示例中，操作404包括与单独的预订和/或库存系统通信，以将单独系统中的车辆与确认的预订所指示的车辆相关联。在其他示例中，操作404可以包括向车辆预订平台提供对预订被库存合作伙伴接受的指示。
91.方法400根据预定类型在确定406处分支。如果预订是交付预订，则流程转向“交付”分支到操作408，在操作408处调度交付库存。例如，可以识别交付车辆(以及，在一些情况下，以及相关联的驾驶员)并将交付车辆与确认的预订相关联。可以相应地向交付驾驶员的移动设备提供指示。
92.流程前进到操作410，在操作410处向预订平台提供交付更新。在示例中，可以执行操作410多次，从而使得客户能够跟踪与车辆预订相关联的交付车辆。例如，在图3b的方法350的操作370处预订平台可以接收交付更新作为预订更新。最终，流程前进到操作412，在操作412处提供对完成交付的指示。可以再次将该指示提供到预订平台(例如，在操作370处)。流程在操作412处终止。
93.在其他示例中，如果预订是向导式预订，则流程改为从确定406转向“向导式”分支到操作414，在操作414处为预订分配向导。可以基于可用向导的日历或者经由单独的预订系统等等来分配向导。流程前进到操作416，在操作416处给向导提供日程安排指示(例如，作为文本消息、电子邮件、或经由调度门户)。虽然描述了示例调度技术，但是将会理解，可以利用各种其他方面中的任何一者来提供这样的功能。例如，预订平台可以进一步提供向导调度能力，或者作为另一个示例，可以提供上面关于操作408讨论的交付能力。流程在操作416处终止。
94.最后，如果在确定406处预订是取车预订，则流程转向“取车”分支到操作418，在操作418处生成对准备车辆用于取车的指示。例如，该指示可以在队列或其他订单跟踪系统中生成，从而使得库存合作伙伴的个人能够相应地履行取车订单。最终，流程前进到操作420，在操作420处向预订平台提供对取车可用性的指示。例如，个人可以使用设备(例如，图1中的旅行用品商设备104或经销商设备106)来相应地提供指示。流程在操作420处终止。
95.虽然方法400相对于三种订单类型来说明，但是将会理解，可以使用更少的、额外
的或替代的订单类型。另外，不需要实现方法400中所示的所有三种订单类型。例如，图1中的预订设备104的预订应用程序114可以实施操作402至操作406和操作414至操作420，而经销商设备106的库存应用程序116可以实施操作402至操作412。
96.图5a至图5c示出了车辆预订平台的示例用户界面方面。图5a至图5c包括相似的元件和相关联的附图标记，因此没有必要在随后的附图中再次详细描述。参考图5a，用户界面500包括库存合作伙伴栏502、供应类型栏504、供应栏506、信用成本栏508、预订周期栏510和距离栏512。用户界面500可以由于客户设备执行图3a中方法300的操作302的各方面而生成。在用户界面500中列出的车辆可能已经由于预定平台执行图3b中的方法350的操作352的各方面而确定。
97.用户界面500根据预订类型进行分类，如供应类型栏504所示(例如，“定制交付”、“定制取车”和“在路上的旅行用品商”)。虽然公开了示例预定类型，但是将会理解，在其他示例中可以使用额外的、更少的或替换的类型。库存合作伙伴栏502包括关于与可用车辆相关联的库存合作伙伴(例如，图2中的库存合作伙伴208、210和212)的指示。供应栏506指示车辆类型(例如，“运动家(sportsman)570”、“slingshot(弹弓)”、“rzr”、“slg”等)、以及在一些示例中，与车辆预订相关联的拖车头(例如，图2中的拖车头214、216、218和220)。信用栏508指示与车辆预订相关联的信用成本。如上所述，信用栏508可以包括车辆预订的静态信用成本和/或动态信用成本，这可以由定价引擎(比如图1中的定价引擎124)来确定。
98.预订周期栏510指示与车辆预订相关联的时间长度。如上所述，用户可以基于车辆可用的天数来过滤可用车辆。例如，用户界面500可以显示“全天”可用车辆的过滤列表，而其他车辆可以多天或半天可用，等等。距离栏512指示距用户的距离(例如，与到图2中的库存合作伙伴208、210或212或拖车头214、216、218或220中的一者的距离相比的用户位置202)。对于“定制交付”或“定制取车”类型，没有显示距离，因为用户可以为这样的预订类型指定位置。
99.图5b示出了示例用户界面520，在示例用户界面520中，指针522悬停在车辆预订526上方。结果，示出了预订按钮524。因此，用户可以使用指针522来点击预订按钮524，以便启动预订过程，该预订过程可以包括上面参考图3a讨论的方法300的各方面。虽然关于使用指示器522描述了示例方面，但是将会理解，类似的技术可以用于替代输入方法可用的情况，比如触摸输入或键盘输入。在其他示例中，可以给所示列表编号，使得用户可以使用相关联的编号来识别预订。作为另一个示例，可以使用语音用户界面，利用该语音用户界面，用户可以基于与车辆预约相关联的词(例如，说“happy trails提供的在途选项”或“rs1的定制取车预约”)来选择车辆预约。
100.用户界面540示出了用户没有足够的信用来预订车辆的示例。因此，不是显示保留按钮524，而是显示购买信用按钮542。结果，根据本文中描述的方面，用户可以点击按钮来购买额外信用，从而使得用户能够在购买额外信用之后完成预订过程。类似于图5b，可以使用替代的输入技术。例如，用户可以说“购买定制rs1取车的额外信用”，或者可以点击并保持车辆预订，以便访问相关联的选项菜单，在相关联的选项菜单中，可以呈现购买额外信用的选项。
101.因此，尽管本文中描述了示例用户界面和用户体验技术，但是将会理解，根据本文中描述的方面，可以使用各种其他技术中的任何一者。例如，虽然用户界面500、520和540示
出为具有车辆列表，但是将会理解，在其他示例中，用户界面可以进一步包括地图，该地图类似于图2中的区域200的地图。在其他示例中，用户界面可以包括这样的地图，而不是图示的车辆列表。
102.图6a示出了用于生成与用户账户相关联的信用的示例方法600的概况。在示例中，方法600的各方面由预订平台来执行，预订平台比如以上参考图1讨论的预订平台110。
103.方法600开始于操作602，在操作602处接收对生成与用户账户相关联的信用的指示。在示例中，当预定时间段已经过去时，接收到该指示，这可能是当用户账户与订购相关联时的情况。在另一个示例中，该指示可以由于处理从用户接收的支付信息(例如，类似于以上分别关于图3a和3b的操作314和/或364讨论的方面)、或者由于用户参加事件等等来接收。虽然方法600的各方面针对生成单个信用来描述，但是将会理解，类似的技术可以用于生成多个信用。
104.在操作604，确定信用属性集。例如，该信用集属性可以包括值(例如，与生成信用的背景相关联)、起始日期和/或时间、指示导致信用创建的原因的来源、和/或到期日和/或时间。如上所述，价值信用属性可以指示(例如，由用户)为获得信用而发生的费用，例如，作为订购、试用会员、忠诚计划、参加活动或推荐另一个用户等等的结果。虽然描述了示例信用属性，但是将会理解，在其他示例中，可以在操作604处确定多种其他信用属性中的任何一者。
105.流程进行到操作606，在操作606处基于所生成的属性集生成与用户账户相关联的信用。例如，信用可以在数据存储中生成，数据存储比如以上参考图1讨论的用户数据存储128。信用可以被存储为用户账户的一部分，或者作为另一个示例，用户账户可以被更新以包括对所生成的信用的引用(例如，根据序列号或唯一标识符，等等)。虽然描述了示例性的生成和存储技术，但是将会理解，可以使用多种其他技术中的任何一者，例如提供信用或与其相关联的信息以供用户设备存储。
106.在操作608处提供对生成的信用的指示。例如，该指示可以包括序列号或唯一标识符和/或一个或多个信用属性，等等。在一些情况下，该指示可以使得预订平台的处理继续(例如，当用户账户没有足够的信用来完成预订时可能是这种情况)或者可以将该指示提供到客户设备(例如，当用户获得额外信用时可能是这种情况)，等等。方法600在操作608处终止。
107.图6b示出了根据本文中描述的方面的用于处理对应用信用的指示的示例方法650的概况。在示例中，方法650的各方面由预订平台来执行，预订平台比如以上参考图1讨论的预订平台110。
108.方法650开始于操作652，在操作652处接收对应用信用的指示。例如，如上面关于图3a中方法300的操作306至操作314所讨论的，该指示可以由于用户选择的车辆的指示而被接收。作为另一个示例，由于处理这样的指示，可以接收该指示，其示例已经在上文中关于图3b中的方法350的操作356至操作366处进行了讨论。虽然在预订平台的背景中讨论了示例，但是将会理解，类似的技术可以用于各种其他背景中的任何一者。
109.流程前进到操作654，在操作654处识别信用集。在示例中，在操作652处接收对一个或多个信用的用户选择的指示，使得在操作654处识别的该信用集的至少一部分包括这样的用户选择的信用。在其他示例中，例如基于到期日和/或相关联的价值信用属性，自动
确定所识别的信用集的至少一部分。作为另一个示例，可以基于对用户选择的指示来自动确定信用集，例如以应用接近到期的信用。虽然描述了用于识别信用集的示例技术，但是将会理解，在其他示例中可以使用额外的或替代的标准和/或处理。
110.在操作656处，为所识别的信用集确定度量。例如，可以根据与所识别的信用集中的每个信用相关联的价值信用属性来生成实现度量。在其他示例中，操作656包括处理与所识别的信用集中的每个信用相关联的额外或替代信用属性，使得可以确定与所应用的信用相关联的额外或替代度量。
111.在操作658处，提供对所确定的度量的指示。例如，可以将指示提供到数据存储，使得可以将度量存储用于后续评估(例如，由与客户设备相关联的用户或与预订平台相关联的用户，等等)。在示例中，指示可以作为报告的一部分来提供，该报告至少部分地基于在操作656处确定的度量来生成。
112.移动到操作660，应用所识别的信用集。例如，可以解除该信用集与用户账户的关联，并且在一些示例中删除该信用集。作为另一个示例，该信用集可以保持与用户账户相关联，但是可以更新每个信用的信用属性以指示已经应用了它。在一些情况下，可以添加信用属性来指示信用被应用于一个或多个项目和/或服务。方法650在操作660处终止。虽然方法650在其中这样的处理(例如，以上关于操作656和/或658讨论的)作为应用信用的一部分发生的示例中进行描述，但是将会理解，在其他示例中，可以在应用信用之前或之后执行类似的处理。
113.图7示出了用于实现调度专用车辆服务的系统的计算系统700的示意图。例如，预订平台110(例如，包括请求处理器118、调度引擎120、库存管理器122、定价引擎124、预订数据存储126和用户数据存储128)、客户设备102、旅游用品商设备104和/或经销商设备106的一些或所有功能可以由具有与计算系统700类似的部件的计算系统来执行。这个图仅仅是一个示例，不应该不适当地限制权利要求的范围。本领域的普通技术人员将认识到许多变化、替代和修改。
114.计算系统700包括总线702或其他通信机制，用于在处理器704、显示706、光标控制组件708、输入设备710、主存储器712、只读存储器(rom)714、存储单元716和/或网络接口718之间传送信息。在一些示例中，总线702联接到处理器704、显示706、光标控制组件708、输入设备710、主存储器712、只读存储器(rom)714、存储单元716和/或网络接口718。并且，在某些示例中，网络接口718联接到网络720(例如，网络112)。
115.在一些示例中，处理器704包括一个或多个通用微处理器。在一些示例中，主存储器712(例如，随机存取存储器(ram)、高速缓存和/或其他动态存储设备)配置成存储信息和将由处理器704执行的指令。在某些示例中，主存储器712配置成在要由处理器704执行的指令的执行期间存储临时变量或其他中间信息。例如，当指令存储在处理器704可访问的存储单元716中时，指令使计算系统700成为专用机器，该专用机器被定制为执行指令中指定的操作(例如，部件112至部件128)。在一些示例中，rom 714配置成存储用于处理器704的静态信息和指令。在某些示例中，存储单元716(例如，磁盘、光盘或闪存驱动器)配置成存储信息和指令。
116.因此，计算系统700可以包括至少某种形式的计算机可读介质。计算机可读介质可以是可以由处理器704或其他设备访问的任何可用介质。例如，计算机可读介质可以包括计
算机存储介质和通信介质。计算机存储介质可以包括以用于存储比如计算机可读指令、数据结构、程序模块或其他数据的信息的任何方法或技术实施的易失性和非易失性、可移动和不可移动介质。计算机存储介质可以不包括通信介质。
117.在一些实施例中，显示706(例如，阴极射线管(crt)、lcd显示、或触摸屏)配置成向计算系统700的用户显示信息。在一些示例中，输入设备710(例如，字母数字键和其他键)配置成向处理器704传送信息和命令。例如，光标控制708(例如，鼠标、轨迹球、或光标方向键)配置成向处理器704传送额外信息和命令(例如，控制显示706上的光标移动)。
118.提供以下条款作为所公开主题的示例方面：
119.1.一种系统，包括：至少一个处理器；以及存储器，存储指令，当指令由至少一个处理器执行时，使得系统执行一组操作，一组操作包括：从客户设备接收对预订专用车辆的指示，其中，专用车辆与信用成本相关联；确定与客户设备相关联的用户账户的信用余额；以及当与专用车辆相关联的信用成本不超过用户账户的信用余额时：基于与专用车辆相关联的信用成本更新用户账户的信用余额；以及生成针对专用车辆的预订，其中，预订与用户账户相关联。
120.2.根据条款1所述的系统，其中，一组操作进一步包括：当与专用车辆相关联的信用成本超过用户账户的信用余额时：提供对用户账户的信用余额不足以预订专用车辆的指示；接收对购买额外信用的指示；将额外信用与用户账户相关联；基于与专用车辆相关联的信用成本更新用户账户的信用余额；以及生成针对专用车辆的预订，其中，预订与用户账户相关联。
121.3.根据条款2所述的系统，其中，将额外信用与用户账户相关联包括：基于与对购买额外信用的指示相关联的背景，确定与额外信用相关联的信用属性集；生成具有所确定的信用属性集和标识符的额外信用；以及基于标识符，将所生成的信用与用户账户相关联。
122.4.根据条款1至3中任一项所述的系统，其中，与专用车辆相关联的信用成本至少部分地基于以下各者中的一者或多者来动态地确定：对与专用车辆相关联的车辆类型的历史需求；对车辆类型的预测需求；历史季节性需求；预测的季节性需求；历史假日需求；预测的假日需求；与对预订专用车辆的指示相关联的预订类型；或者可用专用车辆的接近度。
123.5.根据条款1至4中任一项所述的系统，其中，一组操作进一步包括：向与专用车辆相关联的库存合作伙伴提供对所生成的预订的指示。
124.6.根据条款5所述的系统，其中，一组操作进一步包括：从库存合作伙伴接收对预订更新的指示；以及向客户设备提供对预订更新的指示。
125.7.根据条款5至6中任一项所述的系统，其中，一组操作进一步包括：从库存中具有专用车辆的库存合作伙伴集中确定库存合作伙伴。
126.8.根据条款1至7中任一项所述的系统，其中：用户账户与订购等级相关联，订购等级在给定时间段内提供预定数量的信用；并且一组操作进一步包括：基于确定已经过了大于给定时间段的时间量，将用户账户的信用余额增加预定数量的信用。
127.9.根据条款8所述的系统，其中，增加用户账户的信用余额包括：基于与订购等级相关联的背景，确定与预定数量的信用中的每一者相关联的信用属性集；生成具有所确定的信用属性集和相关联标识符的预定数量的信用中的每个信用；以及基于标识符将每个所生成的信用与用户账户相关联。
128.10.根据条款1至9中任一项所述的系统，其中，更新用户账户的信用余额包括：从用户账户的信用余额中确定信用集；以及应用所确定的信用集。
129.11.根据条款10所述的系统，其中，更新用户账户的信用余额进一步包括：基于所确定的信用集的每个信用的价值信用属性生成总价值；基于所生成的总价值和与专用车辆的预订相关联的成本生成实现度量；以及以下各者中的至少一者：提供对所生成的实现度量的指示；或者存储所生成的实现度量。
130.12.根据条款10至11中任一项所述的系统，其中，信用集部分地基于对从客户设备接收的用户选择的指示来确定。
131.13.根据条款10至11中任一项所述的系统，其中，信用集基于评估信用集中的信用的信用属性来自动确定。
132.14.根据条款10至13中任一项所述的系统，其中，应用所确定的信用集包括：更新所确定的信用集的每个信用的信用属性，以指示信用已经被应用；或者解除所确定的信用集中的每个信用与用户账户的关联。
133.15.一种经由车辆预约平台预约专用车辆的方法，包括：从车辆预约平台请求专用车辆集；从车辆预订平台接收专用车辆集；基于所接收的专用车辆集的至少一部分生成专用车辆的显示，其中，显示进一步包括用户账户的信用余额；接收对专用车辆的选择，其中，所选择的专用车辆与信用成本相关联；向车辆预订平台提供对预订所选择的专用车辆的指示；以及从车辆预订平台接收用户账户的剩余信用余额和所选择的专用车辆的预订确认。
134.16.根据条款15所述的方法，进一步包括：响应于对预订所选择的专用车辆的指示，接收对用户账户不具备足够信用来预订所选择的专用车辆的指示；生成信用选项集的显示，以增加用户账户的信用余额；接收从信用选项集中对信用选项的选择；以及向车辆预订平台提供对所选择的信用选项的指示。
135.17.根据条款15至16中任一项所述的方法，进一步包括：在向车辆预订平台提供对预订所选择的专用车辆的指示之前：确定与专用车辆相关联的信用成本超过用户账户的信用余额；生成信用选项集的显示，以增加用户账户的信用余额；接收从信用选项集中对信用选项的选择；以及向车辆预订平台提供所选择的对信用选项的指示。
136.18.根据条款15至17中任一项所述的方法，进一步包括：从车辆预订平台接收与所选择的专用车辆的预订确认相关联的预订更新；以及至少部分地基于预订更新生成显示。
137.19.根据条款18所述的方法，其中，基于预订更新所生成的显示包括指示交付车辆的位置的地图。
138.20.根据条款15至19中任一项所述的方法，其中：所接收的对专用车辆的选择进一步包括对预订类型的选择；以及对向车辆预订平台预订所选择的专用车辆的指示进一步指示所选择的预订类型。
139.21.根据条款15至20中任一项所述的方法，进一步包括：接收对延长所选择的专用车辆的预订的选择；向车辆预订平台提供对延长所选择的专用车辆的预订的指示；以及从车辆预订平台接收用户账户的更新的剩余信用余额和所选择的专用车辆的延期预订确认。
140.22.根据条款15至21中任一项所述的方法，其中：显示进一步包括与用户账户的信用余额的至少一个信用相关联的信息；方法进一步包括接收与用户的信用余额相关联的用户输入；以及所提供的对预定所选择的专用车辆的指示进一步包括所接收的用户输入的指
示。
141.23.根据条款22所述的方法，其中，用户输入包括以下各者中的至少一者：对用户的信用余额中的特定信用的选择；或者对应用即将到期的信用的指示。
142.24.一种用于由库存合作伙伴处理车辆预订平台的车辆预订的方法，包括：从车辆预订平台接收对专用车辆的预订的指示，其中，专用车辆与库存合作伙伴相关联，并且其中，预订指示日期和时间；更新库存合作伙伴的库存，以指示专用车辆在预定的日期和时间不可用；以及向车辆预订平台提供预订更新，指示专用车辆预订已经完成。
143.25.根据条款24所述的方法，其中，所述预定更新指示以下各者中的一者：客户取走了专用车辆；专用车辆已交付给客户；以及向导已与客户会面，并利用专用车辆开始游览。
144.26.根据条款24至25中任一项所述的方法，其中，预订是交付预订，并且方法进一步包括：从与专用车辆的交付相关联的交付驾驶员的设备接收设备的位置；以及向车辆预订平台提供对设备的位置的指示。
145.27.根据条款26所述的方法，进一步包括：向车辆预订平台提供包括专用车辆的估计交付时间的预订更新。
146.28.根据条款24至27中任一项所述的方法，进一步包括：向车辆预订平台提供包括专用车辆的估计取车时间的预定更新。
147.29.根据条款24至27中任一项所述的方法，进一步包括：向车辆预订平台提供对在由预订指示的日期之后专用车辆不可以用于预订的指示。
148.30.一种用于维护与用户相关联的用户账户的方法，方法包括：基于确定为用户账户的信用余额生成信用：生成与信用相关联的信用属性集；生成具有所确定的信用属性集和标识符的信用；以及基于标识符，将所生成的信用与用户账户相关联；接收对应用用户账户的信用余额的指示；以及响应于对应用用户账户的信用余额的指示：从用户账户的信用余额中确定信用集；以及应用所确定的信用集。
149.31.根据条款30所述的方法，其中，确定在预定量的时间过去后生成信用。
150.32.根据条款30所述的方法，其中，确定由于与用户账户相关联的用户交互而生成信用。
151.33.根据条款30至32中任一项所述的方法，其中，应用所确定的信用集包括：更新所确定的信用集的每个信用的信用属性，以指示信用已经被应用；或者解除所确定的信用集中的每个信用与用户账户的关联。
152.34.根据条款30至33中任一项所述的方法，进一步包括，响应于对应用用户账户的信用余额的指示：基于所确定的信用集的每个信用的价值信用属性生成总价值；基于所生成的总价值和与对应用信用余额的指示相关联的成本来生成实现度量；以及以下各者中的至少一者：提供对所生成的实现度量的指示；或者存储所生成的实现度量。
153.35.根据条款30至34中任一项所述的方法，其中，信用集部分地基于所接收的对应用用户账户的信用余额的指示来确定。
154.36.根据条款30至35中任一项所述的方法，其中，信用集基于评估信用余额中的一个或多个信用的信用属性而自动确定。
155.例如，上面参考根据本公开的方面的方法、系统和计算机程序产品的框图和/或操
作说明描述了本公开的方面。方框中标注的功能/动作可以不按照任何流程图中所示的顺序发生。例如，连续示出的两个方框实际上可以基本上同时执行，或者这些方框有时可以以相反的顺序执行，这取决于所涉及的功能/动作。
156.本技术中提供的对一个或多个方面的描述和说明并不旨在以任何方式限制或限定所要求保护的本公开的范围。认为本技术中提供的方面、示例和细节足以传达所有权并使他人能够做出并使用所要求保护的公开的最佳模式。不应将所要求保护的公开内容解释为限于本技术中提供的任何方面、示例或细节。不管是组合还是单独地示出并描述，各种特征(结构的和方法的各种特征)都旨在被选择性地包括或省略，以产生具有一组特定特征的实施例。已经提供了本技术的描述和说明，本领域技术人员可以设想落入本技术中体现的总体发明构思的更宽方面的精神内的变化、修改和替代方面，这些变化、修改和替代方面不脱离所要求保护的公开的更宽范围。

技术特征：
1.一种系统，包括：至少一个处理器；和存储器，存储指令，当所述指令由所述至少一个处理器执行时，使得所述系统执行一组操作，所述一组操作包括：从客户设备接收对预订专用车辆的指示，其中，所述专用车辆与信用成本相关联；确定与所述客户设备相关联的用户账户的信用余额；以及当与所述专用车辆相关联的所述信用成本不超过所述用户账户的所述信用余额时：基于与所述专用车辆相关联的所述信用成本更新所述用户账户的所述信用余额；以及生成针对所述专用车辆的预订，其中，所述预订与所述用户账户相关联。2.根据权利要求1所述的系统，其中，所述一组操作进一步包括：当与所述专用车辆相关联的所述信用成本超过所述用户账户的所述信用余额时：提供对所述用户账户的所述信用余额不足以预订所述专用车辆的指示；接收对购买额外信用的指示；将额外信用与所述用户账户相关联；基于与所述专用车辆相关联的所述信用成本更新所述用户账户的所述信用余额；以及生成针对所述专用车辆的预订，其中，所述预订与所述用户账户相关联。3.根据权利要求2所述的系统，其中，将额外信用与所述用户账户相关联包括：基于与对购买额外信用的指示相关联的背景，确定与所述额外信用相关联的信用属性集；生成具有所确定的信用属性集和标识符的所述额外信用；以及基于所述标识符，将所生成的信用与所述用户账户相关联。4.根据权利要求1至3中任一项所述的系统，其中，与所述专用车辆相关联的所述信用成本至少部分地基于以下各者中的一者或多者来动态地确定：对与所述专用车辆相关联的车辆类型的历史需求；对所述车辆类型的预测需求；历史季节性需求；预测的季节性需求；历史假日需求；预测的假日需求；与对预订所述专用车辆的指示相关联的预订类型；或者可用专用车辆的接近度。5.根据权利要求1至4中任一项所述的系统，其中，所述一组操作进一步包括：向与所述专用车辆相关联的库存合作伙伴提供对所生成的预订的指示。6.根据权利要求5所述的系统，其中，所述一组操作进一步包括：从所述库存合作伙伴接收对预订更新的指示；以及向所述客户设备提供对所述预订更新的指示。7.根据权利要求5至6中任一项所述的系统，其中，所述一组操作进一步包括：从库存中具有所述专用车辆的库存合作伙伴集中确定所述库存合作伙伴。8.根据权利要求1至7中任一项所述的系统，其中：
所述用户账户与订购等级相关联，所述订购等级在给定时间段内提供预定数量的信用；并且所述一组操作进一步包括：基于确定已经过了大于所述给定时间段的时间量，将所述用户账户的所述信用余额增加所述预定数量的信用。9.根据权利要求8所述的系统，其中，增加所述用户账户的所述信用余额包括：基于与所述订购等级相关联的背景，确定与所述预定数量的信用中的每一者相关联的信用属性集；生成具有所确定的信用属性集和相关联标识符的所述预定数量的信用中的每个信用；以及基于所述标识符将每个所生成的信用与所述用户账户相关联。10.根据权利要求1至9中任一项所述的系统，其中，更新所述用户账户的所述信用余额包括：从所述用户账户的所述信用余额中确定信用集；以及应用所确定的信用集。11.根据权利要求10所述的系统，其中，更新所述用户账户的所述信用余额进一步包括：基于所确定的信用集的每个信用的价值信用属性生成总价值；基于所生成的总价值和与所述专用车辆的所述预订相关联的成本生成实现度量；以及以下各者中的至少一者：提供对所生成的实现度量的指示；或者存储所生成的实现度量。12.根据权利要求10至11中任一项所述的系统，其中，所述信用集部分地基于对从所述客户设备接收的用户选择的指示来确定。13.根据权利要求10至11中任一项所述的系统，其中，所述信用集基于评估所述信用集中的信用的信用属性来自动确定。14.根据权利要求10至13中任一项所述的系统，其中，应用所确定的信用集包括：更新所确定的信用集的每个信用的信用属性，以指示所述信用已经被应用；或者解除所确定的信用集中的每个信用与所述用户账户的关联。15.一种经由车辆预约平台预约专用车辆的方法，包括：从所述车辆预约平台请求专用车辆集；从所述车辆预订平台接收所述专用车辆集；基于所接收的专用车辆集的至少一部分生成专用车辆的显示，其中，所述显示进一步包括用户账户的信用余额；接收对专用车辆的选择，其中，所选择的专用车辆与信用成本相关联；向所述车辆预订平台提供对预订所选择的专用车辆的指示；以及从所述车辆预订平台接收所述用户账户的剩余信用余额和所选择的专用车辆的预订确认。16.根据权利要求15所述的方法，进一步包括：
响应于对预订所选择的专用车辆的指示，接收对所述用户账户不具备足够信用来预订所选择的专用车辆的指示；生成信用选项集的显示，以增加所述用户账户的所述信用余额；接收从所述信用选项集中对信用选项的选择；以及向所述车辆预订平台提供对所选择的信用选项的指示。17.根据权利要求15至16中任一项所述的方法，进一步包括：在向所述车辆预订平台提供对预订所选择的专用车辆的指示之前：确定与所述专用车辆相关联的所述信用成本超过所述用户账户的所述信用余额；生成信用选项集的显示，以增加所述用户账户的所述信用余额；接收从所述信用选项集中对信用选项的选择；以及向所述车辆预订平台提供对所选择的信用选项的指示。18.根据权利要求15至17中任一项所述的方法，进一步包括：从所述车辆预订平台接收与所选择的专用车辆的所述预订确认相关联的预订更新；以及至少部分地基于所述预订更新生成显示。19.根据权利要求18所述的方法，其中，基于所述预订更新所生成的显示包括指示交付车辆的位置的地图。20.根据权利要求15至19中任一项所述的方法，其中：所接收的对所述专用车辆的选择进一步包括对预订类型的选择；以及对向所述车辆预订平台预订所选择的专用车辆的指示进一步指示所选择的预订类型。21.根据权利要求15至20中任一项所述的方法，进一步包括：接收对延长所选择的专用车辆的所述预订的选择；向所述车辆预订平台提供对延长所选择的专用车辆的所述预订的指示；以及从所述车辆预订平台接收所述用户账户的更新的剩余信用余额和所选择的专用车辆的延期预订确认。22.根据权利要求15至21中任一项所述的方法，其中：所述显示进一步包括与所述用户账户的所述信用余额的至少一个信用相关联的信息；所述方法进一步包括接收与所述用户的所述信用余额相关联的用户输入；以及所提供的对预定所选择的专用车辆的指示进一步包括对所接收的用户输入的指示。23.根据权利要求22所述的方法，其中，所述用户输入包括以下各者中的至少一者：对所述用户的所述信用余额中的特定信用的选择；或者对应用即将到期的信用的指示。24.一种用于由库存合作伙伴处理车辆预订平台的车辆预订的方法，包括：从所述车辆预订平台接收对专用车辆的预订的指示，其中，所述专用车辆与所述库存合作伙伴相关联，并且其中，所述预订指示日期和时间；更新所述库存合作伙伴的库存，以指示所述专用车辆在所述预定的所述日期和所述时间不可用；以及向所述车辆预订平台提供预订更新，指示所述专用车辆预订已经完成。25.根据权利要求24所述的方法，其中，所述预定更新指示以下各者中的一者：
客户取走了所述专用车辆；所述专用车辆已交付给所述客户；以及向导已与所述客户会面，并利用所述专用车辆开始游览。26.根据权利要求24至25中任一项所述的方法，其中，所述预订是交付预订，并且所述方法进一步包括：从与所述专用车辆的交付相关联的交付驾驶员的设备接收所述设备的位置；以及向所述车辆预订平台提供对所述设备的所述位置的指示。27.根据权利要求26所述的方法，进一步包括：向所述车辆预订平台提供包括所述专用车辆的估计交付时间的预订更新。28.根据权利要求24至27中任一项所述的方法，进一步包括：向所述车辆预订平台提供包括所述专用车辆的估计取车时间的预订更新。29.根据权利要求24至27中任一项所述的方法，进一步包括：向所述车辆预订平台提供对在由所述预订指示的所述日期之后所述专用车辆不可以用于预订的指示。30.一种用于维护与用户相关联的用户账户的方法，所述方法包括：基于确定为所述用户账户的信用余额生成信用：生成与所述信用相关联的信用属性集；生成具有所确定的信用属性集和标识符的所述信用；以及基于所述标识符，将所生成的信用与所述用户账户相关联；接收对应用所述用户账户的所述信用余额的指示；以及响应于对应用所述用户账户的所述信用余额的所述指示：从所述用户账户的所述信用余额中确定信用集；以及应用所确定的信用集。31.根据权利要求30所述的方法，其中，确定在预定量的时间过去后生成所述信用。32.根据权利要求30所述的方法，其中，确定由于与所述用户账户相关联的用户交互而生成所述信用。33.根据权利要求30至32中任一项所述的方法，其中，应用所确定的信用集包括：更新所确定的信用集的每个信用的信用属性，以指示所述信用已经被应用；或者解除所确定的信用集中的每个信用与所述用户账户的关联。34.根据权利要求30至33中任一项所述的方法，进一步包括，响应于对应用所述用户账户的所述信用余额的指示：基于所确定的信用集的每个信用的价值信用属性生成总价值；基于所生成的总价值和与对应用所述信用余额的指示相关联的成本来生成实现度量；以及以下各者中的至少一者：提供对所生成的实现度量的指示；或者存储所生成的实现度量。35.根据权利要求30至34中任一项所述的方法，其中，所述信用集部分地基于所接收的对应用所述用户账户的所述信用余额的指示来确定。
36.根据权利要求30至35中任一项所述的方法，其中，所述信用集基于评估所述信用余额中的一个或多个信用的信用属性而自动确定。

技术总结
本公开的方面涉及一种车辆预订平台(VRP)。在示例中，一个或多个库存合作伙伴经由VRP使车辆可用于预订。因此，车辆预订平台的客户能够安排可用车辆的预订。VRP可以提供不同的订购等级，其中，潜在地在循环的基础上，每个订购等级与给定时间段的预定数量的信用相关联。因此，客户可以经由VRP将与他或她的用户账户相关联的信用交换成车辆预订，而不是直接购买车辆预订。如果用户账户的信用余额不足，则客户可以购买额外信用来弥补不足。在示例中，车辆预订的信用成本是静态的，或者可以基于各种因素来动态确定。种因素来动态确定。种因素来动态确定。


技术研发人员：N
受保护的技术使用者：北极星工业有限公司
技术研发日：2021.10.27
技术公布日：2023/8/9