CN105683970B - 基于预测的估计器 - Google Patents

Abstract

本文描述了用于基于车辆维修数据库来确定与车辆有关的潜在维修信息的方法和设备。根据示例方法，计算设备能够接收包括用于车型的车辆标识符的车辆信息。然后，计算设备可以基于车辆信息来确定第一类维修通知单条目中的至少前两个维修通知单条目。例如，至少前两个维修通知单条目可以与第一车型有关，并且根据第一类维修通知单条目中的与第一车型有关的多个维修通知单条目来确定。示例方法可以进一步涉及到由计算设备来提供第一类维修通知单条目中的至少前两个维修通知单条目的图形表示的显示。

Description

基于预测的估计器

相关申请的交叉引用

本申请要求享有于2013年9月5日递交的、美国专利申请序列No.14/019,503以及于2014年9月4日递交的、美国专利申请序列No.14/477,407的优先权，这两个专利申请的全部内容以引用方式并入本文。

背景技术

制造商生产的全部车辆有时必须进行维修。在一些情况下，车主会注意到他们车辆的性能的变化，提示车主将车辆带到维修店从而诊断问题，以及可能维修车辆。在其它情况下，车辆的电子控制模块可以检测到错误并且经由车辆的仪表盘来提供故障指示。如果车主注意到所述指示，则所述车主可以将他们的车带到维修店进行检修。在任一方案中，车主可能不知道需要对车辆执行何种类型的检修以及与维修相关的花费和工时。

当操作员将他们的车辆带到维修店进行检修时，维修店在进行车辆维修之前为客户提供收费估计是通常是期望的并且在很多时候是合法要求。在许多情况下，(作为上述的示例)，必须付出诊断努力来确定根本原因，并且因此得到解决车辆所呈现的症状所需的维修估计。目前，维修店可以提供的是诊断车辆并且随后一旦标识出根本原因就联系车主。在已经标识出根本原因之后，检修撰写人可以准备维修花费和时间的修正估计。在很多情况下，在已经准备好具体维修估计时，车主不在现场。例如，车主可能工作，或者在家，并且不容易联系到。另外，在一些实例中，维修店还可以对车主收取诊断费来涵盖维修店标识出车辆故障的根本原因以及准备估计所需的时间。因此，期望进行改进。

发明内容

目前，当将车辆带到维修店而不执行已知的维修时，不存在用于检修撰写人的对于可能的收费和关联收费给出指导的高效的方法。本文所描述的是用于基于车辆信息和车辆维修数据库的内容来确定与车辆的至少一个潜在车辆修理有关的估计信息的方法和设备。在一些实例中，车辆维修数据库可以包括从多个维修店采集到的关于由多个维修店对各种车辆执行的维修的数据。如本文所描述的，车辆维修数据库的数据能够用于基于特定车辆或车型的历史故障数据来确定车辆出现问题的频率以及可能导致的关联收费。

此外，本文描述了用于与车辆诊断记录交互以利于诊断车辆故障的根本原因的方法和设备。在一些实例中，通过将车辆信息与车辆诊断记录相关联，接收车辆信息的第一客户端设备可以与车辆诊断记录交互。通过访问车辆诊断记录以及当诊断车辆故障的根本原因时参考关联的车辆信息，第二客户端设备也可以与车辆诊断记录交互。第二客户端设备可以利用车辆信息来确定至少一类维修通知单条目中的与车型有关的几个前面的维修通知单条目，并且提供前面的维修通知单条目的图形表示。例如，前面的维修通知单条目可以包括用于特定车型的至少前两个维修组件。在一些实例中，检修技师可以利用图形表示来快速地校验前面的维修组件中的任何一个是否是检修技师正在诊断的特定车辆的故障。当如上所述的与车辆诊断记录进行交互时，第一或第二客户端设备也可以执行其他各种功能。

在一个示例方面中，提供了涉及到在计算设备处接收车辆信息的方法。该车辆信息可以包括车辆标识符以及用于车辆的车辆使用数据。该方法还涉及到：由计算设备并且基于车辆信息来从车辆维修数据库中确定与车辆有关的维修信息。维修信息可以包括对于给定故障的至少一个潜在车辆修理。该方法进一步涉及到由计算设备确定与至少一个潜在车辆修理有关的估计信息。与至少一个潜在车辆修理有关的估计信息可以包括维修时间和维修花费中的至少一项。另外，该方法涉及到从计算设备向通信网络提供与至少一个潜在车辆修理有关的估计信息。

在另一示例方面中，提供了包括至少一个处理器和计算机可读介质的计算设备。该计算机可读介质被配置为存储指令，当由至少一个处理器执行时，所述指令使所述计算设备执行功能。该功能包括：接收车辆信息，该车辆信息包括车辆标识符和用于车辆的车辆使用数据。该功能还可以包括：基于车辆信息，从车辆维修数据库中确定与车辆有关的维修信息。该维修信息可以包括对于给定故障的至少一个潜在车辆修理。该功能进一步包括：确定与至少一个潜在车辆修理有关的估计信息。与至少一个潜在车辆修理有关的估计信息可以包括维修时间和维修花费中的至少一项。另外，该功能包括：向通信网络提供与至少一个潜在车辆修理有关的估计信息。

在另一示例方面中，提供了涉及到经由计算设备的接口来接收车辆信息的方法。该车辆信息可以包括车辆标识符和用于车辆的车辆使用数据。该方法进一步涉及到通过计算设备来将车辆信息提供给通信网络。另外，该方法涉及到在计算设备处从通信网络接收与用于车辆的至少一个潜在车辆修理有关的估计信息。与至少一个潜在车辆修理有关的估计信息可以包括维修时间和维修花费中的至少一项。

在另一示例方面中，提供了包括至少一个处理器和计算机可读介质的计算设备。计算机可读介质被配置为存储指令，当由至少一个处理器执行时，所述指令使所述计算设备执行功能。该功能包括经由计算设备的接口来接收车辆信息。车辆信息可以包括车辆标识符和用于车辆的车辆使用数据。该功能还包括将车辆信息提供给通信网络。该功能进一步包括：在接口处并且从通信网络接收与对于给定故障的至少一个潜在车辆修理有关的估计信息。与至少一个潜在车辆修理有关的估计信息可以包括维修时间和维修花费中的至少一项。

在另一示例方面中，提供了涉及到由计算设备确定包括用于第一车辆的第一车辆标识符的车辆信息的方法。该方法还涉及到由计算设备并且基于车辆信息来确定第一类维修通知单条目中的至少前两个维修通知单条目。第一类维修通知单条目中的至少前两个维修通知单条目与第一车型有关，并且其是从第一类维修通知单条目中的与第一车型有关的多个维修通知单条目当中确定的。另外，该方法涉及到：由计算设备提供并且用于显示的第一类维修通知单条目中的至少前两个维修通知单条目的图形表示。

在另一示例方面中，提供了包括至少一个处理器和计算机可读介质的计算设备。所述计算机可读介质被配置为存储指令，当由至少一个处理器执行时，所述指令使所述计算设备执行功能。该功能包括确定车辆信息，该车辆信息包括用于第一车型的第一车辆标识符。该功能还包括：基于车辆信息来确定第一类维修通知单条目中的至少前两个维修通知单条目。第一类维修通知单条目中的至少前两个维修通知单条目与第一车型有关，并且其是从第一类维修通知单条目中的与第一车型有关的多个维修通知单条目中当中确定的。并且，该能够还包括提供用于第一类维修通知单条目中的至少前两个维修通知单条目的图形表示的显示。

在又一示例方面中，提供了包括第一客户端设备和第二客户端设备的系统。第一客户端设备被配置为经由在第一客户端设备上提供的第一接口来接收包括用于第一车型的第一车辆标识符的车辆信息；以及将车辆信息与对应于第一车辆的第一车辆诊断记录相关联。该第二客户端设备被配置为基于与车辆诊断记录相关联的车辆信息来确定第一类维修通知单条目中的至少前两个维修通知单条目。第一类维修通知单条目中的至少前两个维修通知单条目与第一车型有关，并且其是从第一类维修通知单条目中的与第一车型有关的多个维修通知单条目中当中确定的；以及提供用于第一类维修通知单条目中的至少前两个维修通知单条目的图形表示的显示。

前面的概述仅为示例性的，并且不意在以任何方式限制。除了上述的示例方面、实施例和特征之外，通过参考附图和下面的详细说明，进一步的方面、实施例和特征将变得显而易见。

附图说明

图1示出了示例系统。

图2是用于确定估计信息的示例方法的框图。

图3A、3B、4A、4B和4C是计算设备的示例接口的特征的概念图示。

图5是用于确定估计信息的另一示例方法的框图。

图6是用于确定特定维修店的维修花费信息的示例方法的流程图。

图7是用于确定维修花费的范围的示例方法的流程图。

图8是用于确定一个或多个未来车辆检修的示例方法的流程图。

图9是用于确定潜在维修信息的示例方法的框图。

图10、11、12A、12B、12C、13A、13B、13C、14和15是计算设备的示例接口的特征的概念图示。

图16A和16B是用于与车辆诊断记录进行交互的示例流程图。

图17是示出了根据本文所描述的至少一些实施例布置的计算系统中使用的示例计算设备的功能框图。

图18是示出了根据本文所描述的至少一些实施例布置的包括用于在计算设备上执行计算机处理的计算机程序的示例计算机程序产品的概念局部图的示意图。

具体实施方式

下面的详细说明参考附图描述了公开的系统和方法的各个特征和功能。在图中，除非上下文明确指定，否则类似的附图标记指代类似的组件。本文所描述的示例性的系统和方法实施例不意在限制。易于理解的是，公开的系统和方法的一些方面能够以各种各样不同的构造来布置和组合，全部都在本文中构思出。

示例实施例能够应用于各种可维修物品，诸如车辆或某其他类型的可维修物品。为了该说明的目的，车辆可以包括汽车、摩托车、半拖车、轻型卡车、中型卡车、重型卡车、农用机械、帆船或舰船、发电机、飞机、钻油钻具或某其他类型的车辆。车辆可以包括或使用任何适合的电压源或电流源，诸如电池、交流发电机、燃料电池、电容器等等，其提供了任何适合的电流和/或电压，诸如大约12伏、大约42伏，等等。车辆可以包括或者使用任何期望的系统或引擎。那些系统或引擎可以包括使用如汽油、天然气、丙烷等化石燃料，如由电池、磁电机、燃料电池、太阳能电池等产生的电、风能或者它们的混合物或组合物的物品。

本公开公开了基于车辆信息以及车辆维修数据库的内容来确定与用于车辆的至少一个潜在车辆修理有关的估计信息的方法和设备以及其他。在一些实例中，车辆维修数据库可以包括从多个维修店采集的关于由多个维修店对各种车辆执行的维修的数据。例如，车辆维修数据库的数据能够用于基于特定车辆或车型的历史故障数据来确定车辆可能发生的问题以及可能导致的关联的收费的估计。

根据示例方法，计算设备能够接收车辆信息，该车辆信息包括车辆标识符和用于车辆的车辆使用数据。在一个实施例中，计算设备可以包括被配置为经由通信网络与客户端计算设备通信的服务器中的计算设备。车辆信息可以包括车辆的年份、品牌和型号(YMM)或者车辆标识号(VIN)。VIN可以包括建造日期、建造地点、引擎类型或其他关于车辆的信息。车辆信息还可以包括区分不同型号或类型的车辆的其他类型的信息，诸如指代对车辆的具体选项或修改的常规生产选项(RPO)码。例如，车辆信息可以指示车辆包括车辆能够被制造有或装备有的挂车牵引包或其他各种组件。

车辆使用数据可以是指示车辆已经使用多少的数据。车辆使用典型地按行驶英里数或千米数或操作小时数来测量。例如，如果车辆是汽车或卡车，则车辆使用数据可以是指示车辆行驶的英里数的里程计读数。在另一实例中，车辆可以是帆船、航空器、发电机、钻油钻具，并且车辆使用数据可以是指示操作小时数的小时米读数。因此，车辆使用数据可以提供车辆使用的指示。也可以存在其他车辆使用数据的示例。虽然该公开的部分是参考车辆的里程计读数或英里数来描述的，但是示例不意在限制。

另外，在一些示例中，车辆信息可以包括描述车辆状况的症状信息。作为示例，症状信息可以是“引擎起动停顿”或者“引擎过热”。在其他示例中，车辆信息可以包括一个或多个诊断故障码(DTC)。DTC可以是普通的或者制造商特定的码，其用于标识车辆问题，诸如“节流阀/踏板位置传感器/开关故障”或“传动控制系统故障”。在另外的示例中，车辆信息可以包括车辆的故障指示灯照亮的指示。还可以存在其他示例。

基于车辆信息，计算设备可以确定与车辆有关的车辆维修数据库的维修信息。该维修信息可以包括对于给定故障的至少一个潜在车辆修理。在一个示例中，维修信息可以包括在车辆的里程范围内车辆最频繁执行的车辆修理中的一项或多项。例如，如果车辆是具有47,000英里的Toyota Tundra，则维修信息可以包括对于具有在40,000和55,000英里之间的Toyota Tundra的十个最频繁执行的车辆修理。其他示例是可能的，并且示例不意在限制。

在车辆信息包括症状信息或DTC的实例中，维修信息还可以包括与症状信息或DTC相关联的成功修理百分比。例如，成功修理百分比能够指示具有与通过对类似车辆执行至少一个潜在车辆修理而成功修理的相同或相似症状信息的类似车辆的百分比。

计算设备还可以确定与至少一个潜在车辆修理有关的估计信息。该估计信息可以包括例如维修时间和/或维修花费。维修花费可以是执行车辆修理的花费。也即，维修花费可以是对客户收取的用于执行车辆修理的花费。因此，维修花费可以包括劳力花费，并且还可以包括一个或多个零件的花费，以及任何其他与执行维修相关联的花费。估计信息还可以提供给通信网络，使得估计信息能够提供给另外的计算设备(例如，维修店的客户端计算设备)。

在一些示例中，估计信息能够使检修撰写人准备对于至少一个车辆检修的估计。如果维修信息标识多种车辆修理，则检修撰写人能够使用与各车辆修理中的每一个有关的估计信息来从车主请求多项可能维修中的一项或多项的请求预批准。例如，当车主将车辆带到维修店时，如果技师判定出车辆需要所述维修中的一种，则检修撰写人能够请求车主关于执行一种或多种维修的批准。

类似地，示例方法能够允许检修撰写人在车辆被带到维修店之前将估计提供给车主并且寻求一种或多种维修的预批准(例如，通过电话、通过网页、通过基于网络的应用，等等)。在一个示例中，如果车主能够直接访问基于网络的应用，则经由基于网络的应用提供给车主的估计信息可以标识估计的维修花费和/或维修时间，而不标识需要执行的特定车辆检修。

根据另一示例方法，计算设备能够确定车辆信息，所述车辆信息包括用于第一车型的第一车辆标识符。第一车辆标识符可以包括标识车辆的特定实例的特定车辆标识符，或者第一车辆标识符可以包括标识包括车辆的特定实例以及车辆的一个或多个其他额外实例的车型的普通车辆标识符。特定车辆标识符可以例如包括VIN，VIN包括车辆的特定实例的唯一序列号。普通车辆标识符可以例如包括YMM或VIN的部分，而没有唯一序列号。

计算设备可以是被配置为经由通信网络与服务器通信的客户端设备。例如，客户端设备可以访问或接收包括车辆信息的车辆诊断记录。

车辆诊断记录可以通过多种方式来配置。在一个示例中，车辆诊断记录可以是数据文件或数据结构或者数据文件组或数据结构组，其能够“穿行”多个计算设备(例如，由检修撰写人使用的第一客户端设备以及由技师使用的第二客户端设备)(例如，由多个计算设备访问)。因此，在该公开的部分中，车辆诊断记录可以称为旅行者。

在一个实施例中，车辆诊断记录可以是上传到中央服务器以便存储在云计算环境中的数据文件或数据结构。车辆诊断记录能够由一个或多个客户端设备来访问，并且一个或多个客户端设备中的每一个能够利用云协作技术来访问、补充和/或修正车辆诊断记录的信息。例如，服务器可以集中地群集用于与车辆诊断记录交互的软件，并且客户端设备可以通过经由网络浏览器执行薄客户端来访问车辆诊断记录。可选地，客户端设备可以利用应用编程接口来访问车辆诊断记录。

在另一实施例中，车辆诊断记录可以是计算设备从另一计算设备(例如，服务器或客户端设备)接收的数据文件。通过示例方式，计算设备能够经由通信网络来接收车辆诊断记录的副本。计算设备随后能够修正或补充车辆诊断记录，并且将车辆诊断记录发回到从其接收到车辆诊断记录的计算设备(或者另一计算设备)。

利用车辆信息，计算设备能够确定与第一车型有关的潜在维修信息。例如，计算设备能够确定在一个或者可能多个类别的维修通知单条目中的至少前两个的维修通知单条目。一般地，维修通知单条目可以包括在车辆维修数据库的维修通知单中列出的任何条目。通过示例方式，维修通知单可以包括各种类型的维修通知单条目，诸如维修的组件、报告的诊断故障码、报告的症状(例如，客户抱怨)、症状原因以及症状的校正以及其他可能的条目。此外，维修通知单条目可以与特定类别相关联，诸如维修的组件类别、报告的诊断故障码类别、以及报告的症状类别。因此，在一些示例中，利用车辆信息，计算设备能够确定如下中的一个或其任意组合：与车型有关的至少前两个的维修组件，与车型有关的至少前两个的报告DTC，以及与车型有关的至少前两个的报告症状。在其他示例中，计算设备可以提供与第一车型有关的少于两个的前面的维修通知单条目。例如，计算设备能够确定与车型有关的零个或仅单个最前面的的维修组件、零个或仅单个报告的诊断故障码和/或零个或仅单个最前面的的报告症状。根据上述，计算设备能够通过查询车辆维修数据库来确定潜在维修信息，所述车辆维修数据库包括从多个维修店采集的关于由多个维修店对各车辆执行的维修的数据。

此外，计算设备能够提供所确定的与第一车型有关的潜在维修信息的图形表示的显示。例如，计算设备能够提供与第一车型有关的至少前两个的维修组件中的一个或任意组合的显示、与第一车型有关的至少前两个的报告DTC的显示，以及与第一车型有关的至少前两个的报告症状的显示。在一个示例中，计算设备能够提供所确定的潜在维修信息以便显示在计算设备的接口上。技师或其他用户随后能够与计算设备交互以确定与潜在维修信息相关联的附加信息。

作为一个示例，技师能够选择一类中的至少前两个维修通知单条目中的特定维修通知单条目。响应于接收到选择，计算设备能够提供与特定维修通知单条目相关联的一个或多个潜在车辆修理的显示。另外地或者可选地，计算设备可以提供对于特定维修通知单条目的车辆使用简档的显示。例如，车辆使用简档可以指示多个维修通知单在多个车辆使用间隔上的分布。

如下文进一步描述的，用户同样能够通过各种其他方式与由计算设备提供的图形表示进行交互。例如，用户能够使用接口来访问与特定DTC或特定症状相关联的潜在车辆修理或车辆使用简档。此外，用户能够利用计算设备的接口来选择一个或多个潜在车辆修理。在一个实例中，一个或多个潜在车辆修理可以是包括在维修估计内的车辆修理。例如，当在维修店诊断特定车辆时，技师能够使用计算设备的接口来查看潜在车辆修理并且选择要执行的一个或多个适当的车辆修理以便维修车辆。响应于接收到潜在车辆修理的选择，计算设备能够将潜在车辆修理与对应于特定车辆的车辆诊断记录相关联。结果，当检修撰写人或其他用户随后访问车辆诊断记录时，检修撰写人能够查看由技师选择的潜在车辆修理。

进一步根据上述，在一些示例中，维护车辆诊断记录的服务器或另一计算设备能够确定与车辆诊断记录相关联的潜在车辆修理有关的估计信息。例如，估计信息可以包括维修时间和/或维修花费。并且，服务器还能够将估计信息与车辆诊断记录相关联，使得检修撰写人或其他用户能够在访问车辆诊断记录时查看估计信息。

如上所述，该说明书描述了若干示例实施例。在该说明书内，冠词“一(a)”或“一个(an)”用于引入示例实施例的要素。使用那些冠词的目的在于，存在该要素中的一个或多个。在至少两项的描述列表内使用连词“或者”的目的是表明所列项中的任何一个或所列项的任意组合。诸如“第一”、“第二”、“第三”等序数词的使用是要区分相应的要素，而不是表示那些要素的特定次序。序数词可以写成第一(1st)、第二(2nd)、第三(3rd)等形式。该申请特此通过参考的方式并入于2013年9月5日递交的、美国专利申请序列号No.14/019,503的全部内容。

下面还将参考附图来描述所描述的方法和计算设备的额外的功能和示例。

现在参考附图，图1示出了示例系统100。如图1所示，示例系统100包括一个或多个客户端设备102、服务器104、车辆维修数据库106和通信网络108。客户端设备102能够表示任意类型的移动或固定计算设备。通过示例的方式，客户端设备102可以是位于维修店中的一个或多个计算机。然而，示例不意在限制。在其他示例中，客户端设备102可以是膝上型计算机、平板设备、蜂窝电话、可佩戴式计算设备或其他类型的计算设备。

服务器104类似地可以为任何类型的计算设备。在一个实例中，服务器104可以位于远离客户端设备102(例如，在云计算环境中)。例如，服务器104可以是台式计算机、工作站或被配置为在客户端-服务器体系结构内操作的其他类型的计算设备。在另一实例中，服务器104可以是位于维修店中的计算设备。例如，服务器104可以是维修店用来管理用于诊断和检修车辆的维修通知单或店内装备的计算设备。还可构思其他配置。

每个客户端设备102均可以包括处理器110和存储器112。类似地，服务器104还可以包括处理器114和存储器116。处理器110和处理器114可以是任意类型的处理器，诸如微处理器、数字信号处理器、多核处理器等，其分别与存储器112和存储器116耦合。存储器112和存储器116可以是任何类型的存储器，诸如易失性存储器如随机存取存储器(RAM)、动态随机存取存储器(DRAM)、静态随机存取存储器(SRAM)，或非易失性存储器如只读存储器(ROM)、闪速存储器、磁盘或光盘、数字多功能盘只读存储器(DVD-ROM)、或压缩盘只读存储器(CD-ROM)，以及用于临时地或者永久的存储数据或程序的其他设备。

另外，每个客户端设备102均可以包括通信接口118，并且服务器104可以包括通信接口120。通信接口118和通信接口120能够根据一种或多种有线或无线通信标准而与用于客户端设备102和服务器104的通信网络108进行通信。例如，通信接口118和通信接口120能够经由网络链路122、124和126来实现数据通信。通信接口118和通信接口120可以包括发送数据的发送器和接收数据的接收器。可替换地，通信接口118和通信接口120可以包括被配置为发送和接收数据的收发机。

车辆维修数据库106可以为数据存储设备或者可以包括数据存储设备，诸如非暂时性计算机可读存储设备。虽然车辆维修数据库显示为经由通信网络108连接到服务器104，但是在另一实施例中，车辆维修数据库106能够直接连接到服务器104(未示出)或作为服务器104的组件。车辆维修数据库106能够存储多个维修通知单。每个维修通知单可以包括关于维修车辆的信息。另外地或者可选地，每个维修通知单均可以包括其他信息，诸如关于对车辆执行预防性维护的信息。维修通知单能够以电子格式生成或者能够以纸质格式准备并且手动输入到计算机中或者转换(例如，扫描)成电子格式。扫描的维修通知单的文本还能够利用光学字符标识(OCR)技术来进行标识。在一些示例中，维修通知单能够被布置为结构化的查询语言(SQL)文件。可选地或者另外地，维修通知单能够被布置为可扩展的标记语言(XML)文件。

通过示例方式，维修通知单可以包括服务提供商标识符、服务标识符日期、指示寻求给定车辆检修的客户的客户标识符、指示给定车辆的车辆信息、指示客户请求的抱怨或检修的检修请求、指示为检修给定车辆而获得的零件的零件信息以及对给定车辆实施的检修程序信息中的任一个的组合。

服务提供商标识符可以包括例如指示服务提供商的名称和地理位置的信息。车辆信息可以包括与给定车辆相关联的VIN、车辆的年份、品牌、以及型号(YMM)，车辆的年份、品牌、型号和引擎(YMME)，或者车辆的年份、品牌、型号、引擎和系统(YMMES)。注意的是，车辆的系统有时可替代地称为类别。车辆的系统/类别的几个示例包括例如制动、转向和悬置。检修程序信息可以包括指代对给定车辆执行的特定操作的劳动操作码(LOC)。LOC能够符合那些由车辆制造商、生成维修通知单的服务提供商、诸如加利福尼亚的LLC，Poway的Mitchell Repair Information的服务信息提供商或某其他实体定义的LOC。检修程序信息还可以标识该检修的总花费。类似地，零件信息可以包括标识与维修通知单相关联的任何零件的零件描述、零件号和/或定价信息。

在一个实施例中，维修通知单能够存储在维修店的本地计算系统中，并且能够备份，以及基于频率(例如，每小时、每天、每周等)发送给车辆维修数据库106。当接收到对估计信息的请求时，服务器104能够搜索车辆维修数据库106的维修通知单。在一些实例中，车辆维修数据库106还能够存储搜索查询和来自先前的搜索的关联的搜索结果，以实现从车辆维修数据库106中快速取回信息。例如，服务器104能够被配置为在搜索整个车辆维修数据库106之前访问先前的搜索列表以标识出对于给定搜索搜索结果是否已由车辆维修数据库106存储。存储的搜索结果也可以由车辆维修数据库106周期性地更新。例如，当车辆维修数据库106更新了新的维修通知单时，服务器104或单独的计算设备可以重新搜索车辆维修数据库106以更新存储的搜索结果。

如上文简要描述的，车辆维修数据库的数据能够由维修店的检修撰写人使用来实现对用于执行检修的花费和/或时间进行估计。现在转到图2，图2是用于确定估计信息的示例方法200的框图。图2所示的方法200呈现了能够例如例如图1的客户端设备102、或者通过图1的客户端设备102的组件，或者更一般地通过各种计算设备使用或实现的方法的实施例。方法200可以包括如框202-206中的一个或多个所示出的一个或多个操作、功能或动作。虽然顺序示出了这些框，但是这些框也能够并行地执行，和/或按不同于本文所描述的顺序来执行。而且，各个框能够组合成较少的框，划分成额外的框，和/或基于期望的实现方式来移除。

另外，对于方法200以及本文公开的其他过程和方法，框图示出了本实施例的一个可能的实现方式的功能和操作。在这方面，每个框能够代表模块、区段或程序代码的部分，其包括能够由处理器或计算设备执行以用于实现过程中的具体逻辑功能或步骤的一条或多条指令。程序代码能够存储在任意类型的计算机可读介质上，例如，诸如包括磁盘或硬盘驱动器的存储设备。计算机可读介质可以包括非暂时性计算机可读介质，例如，诸如在短时间段内存储数据的计算机可读介质，如寄存器存储器、处理器高速缓存以及随机存取存储器(RAM)。计算机可读介质还可以包括非暂时性介质，诸如辅助或永久性长期存储设备，类似例如只读存储器(ROM)、光盘或磁盘、压缩盘只读存储器(CD-ROM)。计算机可读介质还可以是任何其他易失性或非易失性存储系统。计算机可读介质能够视为例如计算机可读存储介质，或者有形存储设备。

另外，对于方法200以及本文公开的其他过程和方法，图2中的每个框能够表示接线以执行过程中的具体逻辑功能的电路系统。

最初，在框202中，方法200包括：经由计算设备的接口来接收车辆信息，车辆信息包括车辆标识符和用于车辆的车辆使用数据。在一个实例中，检修撰写人或车主能够通过键入或以其他方式经由计算设备的用户接口来选择车辆标识符和里程计读数来手动地输入车辆标识符和里程计读数。在另一实例中，检修撰写人或车主能够利用计算设备的用户接口来手动地输入车辆标识符和小时米读数。可选地，计算设备可以通过有线或无线车辆数据总线来从车辆的电子控制单元请求车辆信息、或车辆信息的一部分。在另一示例中，计算设备可以从车辆的远程诊断系统(例如，OnStar或另一源)来接收车辆诊断报告(例如，电子邮件)。计算设备随后能够自动地解析电子邮件来确定车辆信息。车辆标识符能够确定特定的车辆。例如，车辆标识符可以是VIN。在另一示例中，车辆标识符能够标识出特定的车型。例如，车辆标识符可以包括YMM、YMME或YMMES。

车辆信息还可以包括描述车辆状况的症状信息。症状信息能够标识例如如客户所报告的车辆状况。作为示例，症状信息能够指示车辆所呈现的和/或车主所报告的症状，诸如“引擎起动停顿”、“运转不稳的引擎怠速”、“引擎启动但是不能起动”、“差的气体里程”或者“检查引擎灯亮”。检查引擎灯还可以称为故障指示灯，当在车辆的仪表盘上照亮时，该故障指示灯指示车辆的计算机引擎管理系统的故障。可选地或者另外地，车辆信息可以包括一个或多个DTC和/或车辆的故障指示灯照亮的指示。

在框204中，方法200包括由计算设备将车辆信息提供给通信网络。在一个示例中，在接收到指示确定与一个或多个潜在维修服务有关的估计信息的请求的数据时，计算设备能够借助通信网络将车辆信息提供给另一计算设备(例如，服务器)。例如，检修撰写人能够点击或以其它方式选择图标、按下按钮或键、或以其它方式触发取回估计信息的请求。计算设备随后能够基于经由接口提供的车辆信息来生成用于估计信息的请求。请求随后能够由计算设备的通信接口发送到通信网络。

在框206中，方法200包括：在计算设备处从通信网络接收与用于车辆的至少一个潜在车辆修理有关的估计信息。在一个示例中，响应于将车辆信息提供给通信网络，计算设备能够接收估计信息。与至少一个潜在车辆修理有关的估计信息可以包括维修时间和/或维修花费。在车主正在直接(例如，经由基于网络的应用)请求估计信息的实施例中，估计信息可以标识维修时间和/或维修花费，而不标识潜在车辆修理。如上所述，维修花费可以包括与执行至少一个潜在车辆修理相关联的任何花费，诸如劳力花费和零件花费。在实施例中，车辆信息包括症状信息，与至少一个潜在车辆修理有关的估计信息可以包括与症状信息相关联的成功修理百分比。

另外地，或者可选地，估计信息可以包括用于至少一个潜在车辆修理的维修花费的范围。例如，维修花费的范围可以指示近来由特定维修店的竞争者(例如，在特定维修店的位置的预定地理区域内的维修店)所执行过的服务维修的维修花费。在该实例中，特定维修店可以基于提供车辆信息的计算设备的标识号来进行标识。例如，计算设备能够向提供估计信息的实体进行注册，使得特定维修店的位置是已知的。

在一些示例中，方法200可以进一步包括经由计算设备的接口来提供估计信息以用于显示。例如，估计信息可以被提供用于显示来辅助检修撰写人准备用于车主的估计。在该方面，图1的客户端设备102可以包括显示器和用户接口(未示出)。

在另一示例中，方法200可以进一步包括经由车辆的显示器来提供估计以用于显示。例如，如果车辆信息由计算设备从车辆的远程诊断系统接收到，则估计信息可以经由通信网络提供给远程诊断系统，以用于在车辆内显示。

在其它示例中，方法200还可以包括从通信网络接收与用于车辆的至少一个未来车辆检修有关的估计信息。在一些实例中，与未来车辆检修有关的估计信息可以辅助检修撰写人为车主准备维护计划。与未来车辆检修有关的估计信息还可以包括维修花费和/或维修时间。未来车辆检修可以基于功能上与该车辆类似的车辆的故障趋势来进行确定。

在一些实例中，功能上类似的车辆可以是特定车型(例如，相同的YMM、YMME或YMMES)的车辆。作为示例，如果车辆是具有75,000英里的2007 Chevy Cobalt，则未来车辆检修可以是维修或更换定时链导板。该检修可以被留意，例如，因为车辆维修数据库的数据表明，对于2007 Chevy Cobalt，定时链导板通常在85,000英里与90,000英里之间用坏。在其它示例中，功能上类似的车辆可以是具有相同引擎或动力系的车辆。功能上类似的车辆的示例还可以包括作为姐妹车的车辆，诸如2008 Ford Explorer和2008 MercuryMountaineer，或者2002 Chevy Camaro和2002 Pontiac Firebird等。

在进一步的示例中，方法200还可以包括从通信网络接收与一个或多个有关的零件或服务相关联的估计信息。例如，如果估计信息标识涉及到移除和更换车辆的特定零件的潜在车辆修理，则估计信息还可以包括标识一个或多个零件和/或与特定零件有关的服务的信息。作为示例，有关零件可以是车辆的与特定零件或连接到特定零件的零件相同的系统的零件。例如，特定零件可能是水泵，有关零件可以包括水软管。

作为另一示例，相关服务可以是与当单独执行时相比，当与潜在车辆修理相结合执行时更高效地执行的服务。例如，如果潜在车辆修理是涉及到移除车辆的一个或多个组件来接近水泵的更换水泵，则相关服务可以是还涉及到移除车辆相同组件的更换定时带。在一些情况下，从通信网络接收到的估计信息可以包括花费比较，其表明与潜在车辆修理相结合执行相关服务的花费以及独立于潜在车辆修理(例如，在稍后执行单独维修期间)而执行相关服务的花费。也即，计算设备可以从通信网络接收到指示如下的数据：与在单个维修期间执行潜在车辆修理和相关检修相关联的维修花费；以及与在单独的维修期间执行潜在车辆修理和相关检修相关联的维修花费。

图3A和3B是计算设备的示例接口300的特征的概念图示。例如，示例接口300可以是正执行图2的方法200的计算设备的接口。在一个示例中，接口300可以是在网页内提供的基于网络的接口。在另一示例中，接口300可以是在计算设备上执行的应用的应用接口。

在一个实例中，检修撰写人能够经由接口300来指定车辆信息302。通过示例的方式，接口300显示包括车辆标识符(2007 Chevy Cobalt)、里程(58,456)和症状(引擎起动停顿)的车辆信息302。响应于请求与车辆信息302有关的估计信息，估计信息304能够经由接口300被接收到并且被提供以用于显示。

如图3A所示，估计信息304可以包括用于车辆的一个或多个潜在车辆修理。在图3A的示例中，示出了两个潜在车辆修理：节流阀位置传感器R&R以及氧气传感器R&R。R&R可以指代移除且更换。对于每个潜在车辆修理，提供维修花费和维修时间。

如图3A中进一步示出的，在一些示例中，估计信息可以包括对应于每个潜在车辆修理的成功修理百分比。通过示例的方式，表明节流阀位置传感器R&R具有70％的成功修理百分比。在一个实例中，70％的成功修理百分比可以由检修撰写人来解释而意味着在所有已知的具有大约58,000英里以及展现出引擎起动停顿症状的2007 Chevy Cobalts中，通过执行节流阀位置传感器R&R检修而成功解决了症状。关于成功修理百分比的进一步的信息在下文参考图5进行描述。

如图3B所示，根据一个示例实施例，当用户犹豫不决或者选择了用于车辆修理的维修花费时，能够经由接口300提供维修花费308的范围以用于显示。下文将参考图7来描述能够由例如图1的服务器104执行的用于确定维修花费的范围的示例方法。在图3B所示的示例中，当用户对于节流阀位置传感器R&R检修的花费犹豫不决时，显示出维修花费的范围。在一个实例中，维修花费的范围能够基于在特定维修店的地理位置的预定范围内的维修店已经报告的用于对2007 Chevy Cobalts执行检修的花费来确定。在另一实例中，维修花费的范围能够基于在整个国家内的维修店已经报告的用于对2007 Chevy Cobalts执行检修的花费来确定。

另外，示出了用于在特定维修店执行特定维修的估计如何与客户在其它维修店支付的价格进行比较的指示器310也可以经由接口300提供以便用于显示。其它维修店可以是例如在特定维修店的地理位置的预定范围内的维修店。

其它实现方式也是可能的，并且图3B中示出的示例不意味着限制。虽然维修花费308的范围被示出为覆盖接口300的图形，但是在其它示例中，维修花费的范围能够与估计信息304邻近地提供(例如，在旁边、前面的、下方)或者在单独的显示窗中提供。

图4A-4C是计算设备的另一示例接口400的特征的概念图示。在一个实例中，接口400可以是正执行图2中的方法200的计算设备的接口。如图4A所示，检修撰写人能够经由接口400来指定车辆信息402。通过示例的方式，图4A所示的车辆信息402包括车辆标识符(VIN)和里程(65462)。注意的是，车辆的YMM可以通过利用客户端设备102来对VIN进行解码而自动地确定。估计信息404也可以经由接口400被提供以便显示。

另外，图4A所示的接口400示出了能够允许检修撰写人确定关于对车辆的未来车辆检修的信息的特征。在一种情况下，当用户犹豫不决或者选择了接口400的预测图标406时，在预测窗408中显示出用于指定车辆类型的车辆使用相关问题。例如，预测窗408显示已经报告了具有大约或近似65,000英里的2008 Chevy Silverados的未来车辆检修列表。在一个示例中，预测窗408的车辆检修按频率以升序显示。例如，“定时带更换”可以是所报告的执行最频繁的检修，而“重校准TPMS(轮胎压力监控系统)有效性计数器”可以是所报告的执行最不频繁的检修。下文参考图8来描述用于确定未来车辆检修的示例方法。

在一些示例中，接口400能够允许用户点击或者以其它方式选择特定车辆检修来显示关于特定车辆检修的更多信息。通过示例的方式，图4B示出了能够经由图4A的接口400提供的车辆检修描述窗410。在一个实例中，车辆检修描述窗410能够提供于覆盖接口400的窗口中。在其它实例中，车辆检修描述窗410能够提供于单独的显示窗中。车辆检修描述窗410提供与“定时带更换”车辆检修有关的信息，诸如维修花费、维修时间、问题描述以及问题的结果。

在一些示例中，接口400还允许检修撰写人记录关于未来车辆检修中的一个或多个的车主评论。例如，如果车主表明他们对在未来执行未来车辆检修中的一项或多项感兴趣，则检修撰写人能够高亮显示或以其它方式选择未来车辆检修。接口400还可以生成能够触发检修撰写人后来提醒车主关于所选的未来车辆检修的提醒。

图4C示出了能够响应于用户从接口400选定预测图标406而提供的另一示例预测窗412。注意的是，选定预测图标406仅是方法的一个示例，其使接口用于提供预测窗412。在其它实例中，预测窗412可以响应于检修撰写人输入包括车辆标识符和车辆使用数据的车辆信息而提供。

预测窗412列出了用于车辆(2008 Chevrolet Impala)的前面的模式故障。模式故障可以按最频繁报告的模式故障的顺序来进行分类。可选地，模式故障可以按字母分类。对于每种故障，提供直方图。直方图能够基于从车辆维修数据库的其它维修通知单采集的车辆使用数据来确定。例如，用于“拉杆端部”故障的直方图可以通过标识车辆维修数据库的涉及到对2008 Chevrolet Impala维修拉杆端部的全部维修通知单以及基于报告的里程计读数将所标识维修通知单分类到仓中来确定。在图4C的示例中，每个仓代表10,000英里范围。也即，第一仓是0-10,000英里，第二仓是10,001-20,000英里，第三仓20,001-30,000英里，等等。在其它示例中，可以使用其它增量。直方图可以是标准化的直方图。也即，每个仓的高度可以对应于百分比。

另外，在预测窗412中能够容易地标识每个直方图的模式。通过示例的方式，每个直方图的模式由加阴影的仓来示出。实际上，每个直方图的模式可以以不同于直方图的其它仓的颜色来显示，使得模式能够容易地为用户所标识。此外，如图4C所示，能够显示出车辆使用指示器414。车辆使用指示器414指示出用于特定车辆的车辆使用数据。在一些实施例中，用户可以基于车辆使用指示器与直方图的一个或多个模式之间的关系来选择一个或多个车辆检修来创建估计或者添加到现有的估计中。例如，由于“球窝接头”故障的直方图指示出通常在30,000英里与40,000英里之间维修球窝接头，所以检修撰写人可以选中“球窝接头”故障旁边的复选框。响应于检修撰写人选择复选框，可以确定用于维修球窝接头的估计。可选地，用于维修球窝接头的估计可以添加到现有估计中。

在其它示例中，可以提供另外类型的预测信息。例如，用户能够选择一个或多个制表符416来使其它预测信息显示出。通过示例的方式，附加的预测信息可以包括对于特定车型所报告的前面的DTC或者对于特定车型所报告的前面的症状。其它预测信息也能够利用与图4C所示的直方图类似的直方图来进行图形表示。也可构思其它示例。

现在转到图5，图5是用于确定估计信息的另一示例方法500的框图。图5所示的方法500呈现了可以由例如图1的服务器104或者由图1的服务器104的组件或者更一般地由各种计算设备中的任一种来使用或实现的方法的实施例。方法500可以包括如框502-508中的一个或多个所图示的一个或多个操作、功能或动作。虽然按顺序示出框，但是这些框也能够并行地和/或按不同于本文所描述的那些次序来执行。而且，各框可以组合成较少的框，划分成额外的框，和/或基于期望的实现方式来移除。每个框能够代表模块、区段或程序代码的一部分，其包括能够由处理器执行用于实现处理器中的具体逻辑功能或步骤的一条或多条指令。另外，图5中的每个框能够表示接线以执行过程中的具体逻辑功能的电路系统。

最初，在框502中，方法500包括在计算设备处接收包括车辆标识符和用于车辆的车辆使用数据的车辆信息。在一个实例中，计算设备可以是从客户端计算设备(例如，在维修店中的计算设备)接收指示车辆信息的数据的服务器。

在一个示例中，车辆标识符能够标识特定的车辆。例如，车辆标识符可以是VIN。在另一示例中，车辆标识符可以标识特定车型。例如，车辆标识符可以包括YMM、YMME或YMMES。车辆使用数据可以是例如里程计读数或小时米读数。

车辆信息还可以包括或附带症状信息。可选地，症状信息能够独立于车辆信息而发送或接收。症状信息能够标识由例如客户所报告的车辆状况。作为示例，症状信息可以指示由车辆所呈现的和/或由车主所报告的症状，诸如“引擎起动停顿”、“加速差”等。在一些实例中，车辆信息可以进一步包括一个或多个DTC或标识车辆的故障指示灯照亮的信息。

在一些示例中，计算设备还能够接收标识特定维修店的维修店信息。例如，如果检修撰写人从特定维修店中的客户端计算设备发送车辆信息到计算设备，则还能够提供标识特定维修店的和/或特定维修店的客户端计算设备的信息。维修店信息可以包括唯一维修店ID、维修店名称、客户端计算设备ID，等等。计算设备能够使用维修店信息来利于将估计信息提供给客户端计算设备。计算设备还能够使用维修店信息来利于确定定制的估计信息。

在框504中，方法500包括：基于车辆信息，通过计算设备来从车辆维修数据库确定与车辆有关的维修信息。如上所述，车辆维修数据库能够存储多个维修通知单，每个维修通知单均包括关于维修车辆和/或执行预防性维护的信息。通过示例的方式，维修通知单可以包括服务提供商标识符、服务标识符日期、指示客户寻求给定车辆的检修的客户指示器、指示给定车辆的车辆信息、指示客户所请求的抱怨或检修的检修请求、指示针对检修给定车辆所获得的零件的零件信息以及对给定车辆实施的检修程序信息中的任一个的组合。在一个实施例中，维修通知单能够存储在维修店的本地计算系统中并且能够备份并且基于频率(例如，每小时、每天、每周等)发送到车辆维修数据库。

在一个示例中，计算设备能够被配置为将车辆信息与车辆维修数据库的内容匹配从而标识出与车辆信息有关的维修通知单。将接收到的车辆信息与车辆维修数据库的维修通知单匹配可以包括搜索或查询车辆维修数据库以将车辆标识符、里程、DTC和/或症状信息与车辆维修数据库的维修通知单的内容相关。在一个示例中，YMM、YMME或YMMES和里程的组合能够用于过滤车辆维修数据库的维修通知单。随后，所标识的维修通知单能够基于将症状信息的关键词与所标识的维修通知单的关键词进行匹配或者基于一个或多个DTC来进一步过滤。车辆维修数据库还能够被配置为或布置为利于将接收到的车辆信息与一个或多个维修通知单进行匹配。

在计算设备还接收到维修店信息的示例中，车辆维修数据库的内容还能够任选地基于提供车辆信息的特定维修店的地理位置来过滤。例如，计算设备能够被配置为标识与车辆信息相匹配的并且与位于特定维修店的预定地理范围内(例如，在25英里内、100英里内，等等)的或者位于与特定维修店相同城市内的维修店相关联的维修通知单。

基于匹配车辆信息的车辆维修数据库的内容，计算设备能够确定维修信息。维修信息可以包括对于给定故障的至少一个潜在车辆修理。在一个示例中，要确定潜在车辆修理，计算设备能够标识匹配车辆信息的车辆维修数据库的维修通知单，并且能够标识根据每个维修通知单而执行的检修。计算设备随后能够从所标识的维修通知单中确定最经常进行的检修。在另一示例中，车辆维修数据库可以存储按车辆信息组织(例如，组合在一起或者进行分类)的预定的维修信息。要确定维修信息，计算设备能够执行针对车辆信息的数据查找。例如，给定特定车辆的车辆标识符和里程，计算设备能够从车辆维修数据库中取回针对该特定车辆的预定维修信息的列表。通过示例的方式，预定的维修信息可以标识针对该特定车辆的最频繁执行的检修(例如，前十个最频繁执行的检修、前五个最频繁执行的检修，等等)。在其它示例中，预定的维修信息可以标识针对该特定车辆的已经执行了多于预定次数的任何检修(例如，已经执行了多于五十次的任何检修，已经执行了多于一百次的任何检修，等等)。

在一些示例中，维修信息还可以包括与症状信息相关联的成功修理百分比。在一个实例中，能够基于报告由特定车辆检修成功修理的症状信息的类似车辆的数量来确定与特定车辆修理相关联的成功修理百分比。例如，如果车辆信息是具有50,000英里以及症状为“引擎起动停顿”的2007 Chevy Cobalt，则计算设备能够标识出具有40,000英里与60,000英里之间的以及症状类似于“引擎起动停顿”的2007 Chevy Cobalst的一百个维修通知单。计算设备还能够确定在一百个标识出的维修通知单中，七十个维修通知单表明节流阀位置传感器被更换。因此，被提供用于节流阀位置传感器R&R检修的成功修理百分比可以是70％。在一些实例中，如果计算设备不能标识出对应于车辆里程的多于阈值数量的维修通知单，则里程范围可以扩大或者甚至用作过滤项。

在框506中，方法500包括：通过计算设备来确定与至少一个潜在车辆修理有关的估计信息。在一个示例中，计算设备能够估计与已经确定的任何潜在车辆修理相关联的维修时间和/或维修花费。维修花费可以包括与执行至少一个潜在车辆修理相关联的任何花费。在一个实例中，计算设备能够基于检修劳动时间标准的数据库来确定潜在车辆修理的维修时间。检修劳动时间标准的数据库可以包括执行各种车辆检修/维修所需的时间的基准。

在一些示例中，计算设备能够通过将估计的维修时间(例如，基准维修时间)乘以店内人工工资率来估计维修花费。店内人工工资率可以是特定维修店的人工工资率。例如，如果计算设备接收到或者以其它方式确定维修店信息，则计算设备能够标识该特定维修店的店内人工工资率。计算设备能够从特定维修店使用的多个比率中选出人工工资率(例如，正常小时比率、小时后比率、假期比率、周末比率、高龄公民比率，等等)。在一个实例中，计算设备能够接收使用哪个人工工资率的指示以及维修店信息。例如，计算设备可以在接收到维修店信息时接收标识使用哪个人工工资率的数据，并且基于该数据，标识出适当的人工工资率。诸如零件花费以及材料处置花费的附加花费也能够算入维修花费中。要确定零件花费或材料处置花费，计算设备能够访问一个或多个电子零件目录(EPC)或者访问车辆维修数据库中的存储有关于零件价格或材料处置价格的信息的表格。

在其它示例中，车辆维修数据库可以存储用于多种车辆修理的预定的估计信息，并且计算设备能够通过执行针对潜在车辆修理的数据查找来确定估计信息。

在一些示例中，计算设备还能够确定潜在车辆修理中的一个或多个的维修花费的范围。例如，计算设备可以基于一组维修通知单所报告的花费来确定维修花费的范围。在一个示例中，维修通知单可以是在与特定维修店位于同一城市内或者在特定维修店的地理范围内的维修店的维修通知单。该信息能够使特定维修店的检修撰写人查看估计的维修花费与竞争者维修店对通用的车辆修理进行收费的价格相比如何。

在其它示例中，计算设备还能够基于特定维修店的店内工作负荷来确定维修时间。例如，计算设备可以访问维修店调度表来确定目前多少车辆正在检修并且对车辆的检修安排何时完成(使得检修技师将有空进行维修)。另外地，或者可选地，计算设备可以判定维修所需的任何零件是否可用(基于维修店的库存)。如果一个或多个零件不可用，则计算设备可以将获得不可用零件的估计运送时间并入估计的维修时间中。在框508中，方法500包括从计算设备向通信网络提供与至少一个潜在车辆修理有关的估计信息。在一个示例中，估计信息可以经由通信网络被提供给维修店的客户端计算设备，使得检修撰写人能够为车主准备好估计。例如，如果检修技师判定出应当执行车辆修理来解决车主车辆所呈现的症状，则检修撰写人可以使用估计信息来寻求执行一个或多个潜在车辆修理的预批准。

在一些示例中，计算设备还能够确定与更换一个或多个零件相关联的估计信息，所述一个或多个零件与潜在车辆修理有关或者执行与潜在车辆修理有关的服务。例如，如果估计信息标识出涉及到移除并且更换车辆的特定零件的潜在车辆修理，则计算设备还能够确定如下的维修时间和/或维修花费：移除并且更换一个或多个零件，所述一个或多个零件与移除并且更换特定零件有关；和/或执行与移除并且更换特定零件有关的一个或多个相关服务。

作为示例，相关零件可以是与特定零件位于车辆中同一系统的零件或者与该特定零件连接的零件。作为另一示例，相关检修可以是与当单独执行时相比当与潜在车辆修理相结合执行时更高效执行的检修。作为又一示例，相关零件可以是接近特定零件的零件。作为又一示例，相关零件可以是在接近用于更换的特定零件的同时不移除任何其它零件而能够接近以便更换的零件。

作为又一示例，相关零件可以是在接近用于更换的特定零件的同时仅移除最少量额外零件之后能够接近以便更换的零件。最少量的零件可以为例如1、2、3、4、5、6、7、8、或某其它数量的零件。计算设备可以被配置为选择最少数量的零件或者车辆维修数据库可以基于移除并且更换特定零件所指定的时间量来指定最少数量的零件。根据至少一些示例性实施例，选定的最少数量零件随着移除并且更换特定零件的时间量增加而变多。

作为又一示例，相关零件可以是在接近用于更换的特定零件的同时执行需要比最少时间量少的任务而能够接近以便更换的零件。计算设备所使用的最少时间量可以基于小时的十分之几，其中一个小时的每个十分之一等于六分钟。最少量的时间可以为例如1、2、3、4、5、6、7、8或某其它数量的小时的十分之几。计算设备能够被配置为选择最少量的小时的十分之几或者车辆维修数据库可以基于指定用于移除并且更换特定零件的时间量来指定最少量的小时的十分之几。根据至少一些示例性实施例，选定的最少量的小时的十分之几随着移除和更换特定零件的时间量增加而变多。

在一个示例中，车辆维修数据库可以存储关于与车辆修理有关的零件和/或检修的信息。要确定与特定车辆修理有关的零件和/或检修，计算设备能够执行针对特定车辆修理的数据查找。

如上文简要描述的，在一些示例中，执行方法500的计算设备能够确定特定于特定维修店的维修花费估计。图6是用于确定特定维修店的维修花费信息的示例方法600的流程图。方法600的每个框能够由诸如图1的服务器104的计算设备来实施。如图6所示，在框602中，能够确定潜在车辆修理。该潜在车辆修理能够基于匹配车辆的车辆信息的车辆维修数据库的内容来确定。给定潜在车辆修理，在框604中，计算设备能够确定潜在车辆修理的维修时间。例如，计算设备能够访问检修劳动时间标准数据库来确定适当的维修时间。作为示例，潜在车辆检修可以是“更换质量空气流传感器”，并且根据检修劳动时间标准，检修技师更换质量空气流传感器的批准维修时间可以是一个半小时。

另外，在框606中，能够确定特定维修店的店内人工工资率。在一个示例中，计算设备能够访问用户账户数据库中的特定维修店的用户账户。该用户账户能够表明特定维修店的店内人工工资率(例如，75$/小时)。

进一步，在框608中，可以确定与潜在车辆修理相关联的任何零件的零件花费。例如，可以通过查询一个或多个EPC来确定一个或多个零件的花费(例如，用于特定车辆的质量空气流传感器的花费)。

随后，在框610中，要确定维修花费估计，计算设备可以将所确定的维修时间乘以确定的店内人工工资率来计算劳动花费。劳动花费然后能够与零件花费相结合来确定维修花费估计。在维修花费估计已经确定之后，在框612中，计算设备能够经由通信网络将维修数据花费估计提供给客户端计算设备。

在其它示例中，作为方法500的部分，计算设备能够确定用于特定维修店的定制维修花费的范围。图7是用于确定维修花费的范围的示例方法700的流程图。方法700的每个框能够由诸如图1中的服务器104的计算设备来实施。最初，在框702中，计算设备能够确定潜在车辆修理。例如，车辆修理可以基于由计算设备接收到的车辆信息和车辆维修数据库的内容来确定。

在框704中，计算设备能够确定靠近特定维修店的位置执行的维修通知单。在一个示例中，计算设备能够接收维修信息以及与特定车辆或车型有关的估计信息的请求。基于特定维修店的标识号和位置，计算设备能够标识出在靠近特定维修店的位置的维修店执行的用于潜在车辆修理的维修通知单。在一个示例中，其它维修店可以是位于与该特定维修店同一城市的维修店。在另一示例中，其它维修店可以是位于特定维修店的预定范围内(例如，25英里、100英里、邮政编码范围，等等)的维修店。

在标识出与在特定维修店附近执行的潜在车辆修理相关联的维修通知单之后，在框706中，计算设备能够确定维修花费的范围。计算设备能够通过标识出维修通知单所指定的最大维修花费和最小维修花费来确定维修花费的范围。随后在框708中，所确定的维修花费的范围能够经由通信网络提供给客户端计算设备。

在另外的示例中，作为方法500的部分，计算设备还能够确定对于特定车辆或车型所需执行的一个或多个未来车辆检修。图8是用于确定一个或多个未来车辆检修的示例方法800的流程。方法800的每个框能够由诸如图1的服务器104的计算设备来实施。如图8所示，最初，在框802中，计算设备能够确定特定车型。在一个示例中，如果由计算设备接收到的车辆信息是VIN，则计算设备能够对VIN进行解码来确定YMM、YMME或YMMES。在其它示例中，车辆信息能够显式地标识YMM、YMME或YMMES。

在框804中，计算设备能够基于特定类型的车辆的维修通知单和/或制造商标识出的推荐检修来确定特定车型的一个或多个未来车辆检修。维修通知单可以是代表车辆故障趋势的数据。例如，维修通知单可以指示特定车型的哪个零件需要在一段时间内进行维修，以及当每个零件进行维修时的平均里程或里程范围。

要确定未来车辆检修，计算设备能够标识出匹配特定车型并且在车辆的里程计读数的里程范围内执行的维修通知单。要确定里程范围，计算设备可以从里程中提取预定里数来确定最小值，并且将预定里数添加到里程中来确定最大值。如果里程计读数为例如56,123英里，则里程范围可以是41,123英里至71,123英里。因此，计算设备能够标识出报告里程在41,123英里和71,123英里之间的特定车型的维修通知单。可选地，计算设备可以标识里程对应于多个预定里程范围中的哪个。例如，如果预定范围是0至25,000英里，25,000英里至50,000英里，50,000英里至75,000英里，等等，以25,000英里递增，则计算设备可以确定里程范围是50,000至75,000英里。

在框806中，计算设备能够确定与一个或多个未来车辆检修有关的估计信息。估计信息可以包括维修时间和/或维修花费，并且能够以上文参考图5中的框506所描述的估计信息的确定类似的方式来确定。在框808中，标识出估计信息和未来车辆检修的数据还能够经由通信网络提供给客户端计算设备。

如上文简要描述的，当诊断车辆故障的根本原因时以及当确定维修的估计信息时，一个或多个客户端设备可以与车辆诊断记录进行交互。现转向图9，图9是用来确定潜在维修信息的示例方法900的框图。方法900的每个框能够由诸如图1的客户端设备102中的一个之类的计算设备来实施。

如图9所示，在框902中，方法900包括：通过计算设备来确定包括用于第一车型的第一车辆标识符的车辆信息。在一个实例中，计算设备可以是访问或接收指示车辆信息的车辆诊断记录的客户端设备。根据以上所述，车辆诊断记录可以对应于特定车辆。此外，车辆诊断记录可以包括第一车辆标识符。作为一个示例，第一车辆标识符可以是VIN，VIN继而标识第一车型。可选地，第一车辆标识符可以是第一车型的类属标识符。例如，第一车辆标识符可以是YMM、YMME或YMMES。其它类型的车辆标识符也是可能的，取决于车辆类型。

在一个实施例中，由检修技师在维修店中使用的客户端设备能够访问由服务器维护的车辆诊断记录来确定车辆信息。通过示例的方式，检修技师能够将车辆ID(例如，当车辆被带到维修店时分配给特定车辆的唯一标识)输入到客户端设备。使用车辆ID，客户端设备随后能够访问对应于车辆ID的车辆诊断记录。

在另一实施例中，客户端设备能够从另一设备接收车辆诊断记录。例如，不是访问由服务器存储并且维护的车辆诊断记录，客户端设备能够从另一客户端设备或者从服务器接收车辆诊断记录的副本。在该方案中，车辆诊断记录又可以包括作为由维修店分配给特定车辆的唯一标识的车辆ID。通过这种方式，如果客户端设备接收到多个车辆诊断记录，则检修技师能够利用对应的车辆ID来区分车辆诊断记录中的每一个。

在框904中，方法900包括：通过计算设备基于车辆信息来确定第一类维修通知单条目中的至少前两个维修通知单条目。第一类维修通知单条目中的至少前两个维修通知单条目与第一车型有关，并且从第一类维修通知单条目中的与车辆有关的多个维修通知单条目中确定。作为一个示例，计算设备可以通过应用编程接口(API)或网络服务来查询车辆维修数据库以确定第一类维修通知单条目中的至少前两个维修通知单条目。

如上所述，车辆维修数据库能够存储多个维修通知单，每个维修通知单均包括关于维修车辆和/或执行预防性维护的信息。通过示例的方式，维修通知单可以包括服务提供商标识符、服务标识符日期、指示客户寻求特定车辆的检修的客户指示器、指示特定车辆的车辆信息、指示客户所请求的抱怨或服务的服务请求、指示针对检修特定车辆所获得的零件的零件信息、以及对特定车辆实施的检修程序信息中的任意的组合。在一个实施例中，维修通知单能够存储在维修店的本地计算系统中，并且能够备份并且基于频率(例如，每小时、每天、每周等等)发送到车辆维修数据库。

在一个示例中，计算设备可以被配置为将车辆信息与车辆维修数据库的内容匹配从而标识与车辆信息有关的维修通知单。在一个实例中，车辆维修数据库的维修通知单可以被加标签或注释，以使得维修通知单能够被过滤或分类。例如，车辆维修数据库可以包括具有代表维修通知单的记录(例如，行)和字段(例如，列)的表格。表的每个记录可以对应于特定的维修通知单并且包括关于特定维修通知单的数据。通过示例的方式，特定的维修通知单能够由用于多个字段的字段值的行来表示。在该实现方式中，计算设备随后能够通过基于字段来进行过滤或分类从而标识具有期望字段值的多个维修通知单。车辆维修数据库的维修通知单同样可以以其它方式被加标签或者注释。因此，示例不意在限制。另外，车辆维修数据库的各个维修通知单可以包括维修通知单条目。如同维修通知单，维修通知单条目也可以被加标签或注释，使得维修通知单条目能够被过滤或分类。作为示例，特定维修通知单条目能够在车辆维修数据库中由多个字段的字段值的行来表示。

将接收到的车辆信息与车辆维修数据库的维修通知单匹配可以包括搜索或查询车辆维修数据库以将车辆标识符与车辆维修数据库的维修通知单的内容相关。在一个实例中，YMM、YMME或YMMES能够用于过滤车辆维修数据库的维修通知单。随后，计算设备能够标识特定类别的维修通知单条目的维修通知单条目。例如，如果类别是维修的组件，则计算设备能够标识出包括在与特定车型有关的维修通知单中的任何维修的组件。计算设备随后能够从所表示的维修组件中确定最上面的维修组件(即，最经常地出现在与特定车型有关的维修通知单中的维修组件)。例如，对于每个不同类型的维修组件，计算设备能够确定与该类型的维修组件的相对应的维修通知单的数量。

在一些实例中，对应于车辆的唯一零件的维修组件的每个实例可以被视为不同类型的维修组件。因此，如果与特定车型有关的维修通知单指示其中已经更换水泵的四个实例，则对应于水泵的维修通知单的数量可以是四个。基于对应于每个不同类型的维修通知单的相应数量的维修通知单，计算设备能够确定至少前两个维修组件。例如，计算设备能够将每个不同类型的维修组件从最多数量的对应维修通知单到最少数量的对应维修通知单进行排序，并且选择具有最对应的维修通知单的两种类型的维修组件。

在另一示例中，车辆维修数据库可以存储由车辆信息组织的预定的维修信息。要确定潜在维修信息，计算设备能够执行针对车辆信息的数据查找。例如，给定特定车型的车辆标识符，计算设备能够从车辆维修数据库中取回用于该特定车型的预定维修信息列表。通过示例的方式，预定的维修信息可以标识该特定车型的最上面的维修组件(例如，前十个维修组件，前五个维修组件，等等)。

在其它示例中，另外地或者可选地，计算设备能够确定与车型有关的其它类型的维修通知单条目。例如，使用车辆信息，计算设备能够确定与车型有关的至少前两个报告的DTC。通过示例的方式，给定对应于车型的多个维修通知单，计算设备能够标识在每个维修通知单中报告的任何DTC。计算设备随后能够从所标识的维修通知单中确定前面的报告的DTC。在另一实现方式中，车辆维修数据库可以存储由车辆信息组织并且包括对于每个车型最常报告的DTC的预定维修信息。在该方案中，给定车辆标识符，计算设备能够从车辆维修数据库中取回对于该车型前面的报告的DTC的列表。

作为另一示例，使用车辆信息，计算设备能够确定与车型有关的至少前两个报告的症状。通过示例的方式，给定对应于车型的多个维修通知单，计算设备能够标识在每个维修通知单中所报告的任何症状。计算设备随后能够从所标识的维修通知单中确定前面的报告的症状。在另一实现方式中，车辆维修数据库可以存储由车辆信息组织的并且包括每个车型的最前面的报告症状的预定维修信息。在该方案中，给定车辆标识符，计算设备可以从车辆维修数据库中取回对于车型的最前面报告症状的列表。

作为另一示例，使用车辆信息，计算设备能够确定与车型有关的任何技术检修布告(TSB)。通过示例的方式，车辆维修数据库或单独的数据库可以存储由对应于每个TSB的一个或多个车辆标识符组织的TSB。给定特定车辆标识符，计算设备随后能够查询车辆维修数据库或其它数据库以取回与车型有关的任何TSB。

在框906中，方法900包括：由计算设备提供并且用于显示的第一类维修通知单条目中的至少前两个维修通知单条目的图形表示。通过示例的方式，图形表示可以是任何类型的图表或曲线图。例如，图表或曲线图可以标识前面维修通知单条目中的每个出现的次数。可选地，图表或曲线图可以标识对应于每个特定维修通知单条目的与车型有关的全部维修通知单条目的百分比，或者可能对应于每个特定维修通知单条目的至少前两个维修通知单条目中的全部的百分比。例如，如果计算设备提供指示前五个维修组件的饼形图，则曲线图的每个饼的切块可以对应于特定维修组件，并且每个饼切块的大小可以与每个组件维修的相对次数成比例。换言之，如果计算设备标识前五个维修组件，并且前五个的最前面的维修组件对应于其次最频繁维修的组件两倍多的维修通知单，则对应于最前面的维修组件的饼切块可以是对应于其次最频繁维修的组件的饼切块的大小的两倍。

在一些示例中，第一类中的至少前两个维修通知单条目同样可以以替代的方式提供。例如，计算设备可以提供第一类中的至少前两个维修通知单条目的列表或者多个相应类别中的至少前两个维修通知单条目的多个列表。

在其它示例中，除了提供至少前两个维修组件的图形表示之外，或者不提供至少前两个维修组件的图形表示，计算设备能够提供与车型有关的至少前两个报告的DTC和/或症状的列表或图形表示。例如，计算设备能够提供与车型有关的3、4、5、10或更多的最前面的报告的DTC和/或症状的列表。在该类别内，DTC和/或症状能够按发生频率来进行分类。可选地，列表可以按字母分类。任选地，计算设备还能够提供与车型有关的任何TSB的列表。

在另一示例中，不提供至少前两个维修组件的图形表示，计算设备能够提供用于显示的至少前两个维修组件的类别并且能够提供用于显示的至少前两个报告的DTC和至少前两个报告的症状中的一者或两者的图形表示。

在进一步的示例中，方法900还可以包括确定并提供用于特定维修组件、特定DTC和/或特定症状的车辆使用简档。例如，响应于接收到特定维修组件、DTC或症状的选择，计算设备能够确定对应于该选择的车辆使用简档并且提供车辆使用简档以用于显示。

在一个示例中，用于特定维修组件、特定DTC和/或特定症状的车辆使用简档可以指示多个维修通知单在多个车辆使用间隔上的分布。特别地，多个维修通知单可以对应于特定车型，如车辆信息所标识的，以及特定维修组件、特定DTC或特定症状。例如，车辆使用简档可以是直方图或分布的类似类型的图形表示。

根据上述，要确定车辆使用简档，计算设备能够标识对应于特定车型以及特定维修组件、特定DTC或特定症状的多个特定通知单的车辆使用数据。例如，可以通过标识涉及到车辆维修数据库中的维修特定车型的水泵的全部维修通知单来确定“水泵移除并且更换”的车辆使用简档。然后，计算设备能够基于报告的里程计读数将标识的维修通知单分类到车辆使用间隔(例如，仓)中，并且提供维修通知单在多个车辆使用间隔上的分布的图形表示。

图10、11、12A、12B、12C、13A、13B、13C和14是计算设备的示例接口的特征的概念图示。特别地，图10-14是用于与车辆诊断记录交互的示例接口的概念图示。结合图10-14所描述的示例接口仅作为示例来提供，不意在限制。其它示例接口也是可能的。

图10是用于输入客户和车辆信息以及用于显示估计信息的示例接口1000的概念图示。在一个实例中，客户端设备，诸如由检修撰写人操作的客户端设备，能够提供接口1000。通过示例的方式，示例接口1000可以是用于输入客户信息或车辆信息以用于车辆诊断记录的第一窗或制表符。因此，检修撰写人或另外的用户(例如，检修技师)可以使用接口1000来输入客户信息或车辆信息。在一个示例中，当客户将车辆带到维修店时，检修撰写人可以输入或查找客户信息和车辆信息。例如，客户信息可以包括姓名、公司、地址、电话号码或电子邮件地址，并且车辆信息可以包括YMM和VIN。

在一个实例中，客户信息和车辆信息可以利用客户端设备的输入接口来手动输入。可选地，客户信息和车辆信息可以利用客户姓名从客户信息数据库中取回。作为又一示例，通过扫描位于车辆或车辆钥匙上或车辆或车辆钥匙内的物理标识符(例如，条形码或其它标识码)，能够取回客户信息和车辆信息。

图11-13C是用于显示和选择车辆的潜在维修信息的示例接口1100的概念图示。在一个实例中，客户端设备，诸如由检修撰写人操作的客户端设备，能够提供接口1100。通过示例的方式，示例接口1100可以是用于显示车辆诊断记录的潜在维修信息并且任选地选择车辆的一个或多个潜在车辆修理的第二窗或制表符。例如，在检修撰写人或检修技师已经输入客户信息和车辆信息之后，检修技师可以使用接口1100来实现车辆诊断。

如图11所示，在一个示例中，接口1100可以是提供车辆的潜在维修信息的模式故障旅行者。特别地，模式故障旅行者可以包括前面的维修组件的图形表示1102、前面的报告DTC的列表1104以及前面的报告症状的列表1106。

前面的维修组件的图形表示1102包括与特定车型有关的前五个维修组件的环形图。例如，图形表示标识制动钳、氧气传感器、防锁制动轮速传感器、点火线圈和水泵。在一个示例中，环形图的每个部分的相对大小可以指示与车型有关并且与由该部分表示的维修组件有关的维修通知单的相对数量。换言之，根据图11的示例，制动钳可以是前面的维修组件，而水泵可以是第五个最经常维修的组件。

前面的报告DTC的列表1104包括与特定车辆有关的前五个报告的DTC的列表。在一个示例中，列表1104可以基于发生频率来排序。因此，“P0100”可以是在与特定车型有关的全部维修通知单内被报告最多次数的DTC。

前面的报告症状的列表1106包括与特定车辆有关的前五个报告症状的列表。在一个示例中，列表1106可以基于发生频率来排序。因此，“听-嘎嘎声”可以是在与特定车辆有关的全部维修通知单内被报告最多次数的症状。

在一个实施例中，检修技师可以使用接口1100来实现对车辆诊断。例如，检修技师可以通过点击、悬停、或以其它方式选择特定组件来查看指示针对特定车型特定组件何时经常维修的车辆使用简档。如图12A所示，如果计算设备接收到指示制动钳组件的选择的数据，则计算设备可以提供用于制动钳的车辆使用简档1200A。通过示例的方式，车辆使用简档1200A包括具有对应于多个里程间隔的多个仓的直方图。在图12A所示的示例中，每个里程间隔代表了10,000英里的范围。例如，第一间隔是0-10,000英里，第二间隔是10,001-20,000英里，第三间隔是20,001-30,000英里，等等。给定技师正在诊断的特定车辆的里程，查看车辆使用简档1200A可以为检修技师提供制动钳很可能需要维修的估计。例如，如果特定车辆已超60,000英里，则根据车辆使用简档1200A，检修技师可能希望查验制动钳是否需要更换。

类似地，检修技师可以通过选择特定DTC来查看指示针对特定车型何时报告特定DTC的车辆使用简档。如图12B所示，如果计算设备接收到指示“P0100-质量空气流传感器”DTC的选择的数据，则计算设备可以提供特定DTC的车辆使用简档1200B。通过示例的方式，车辆使用简档1200B包括具有对应多个里程间隔的多个仓的直方图。查看车辆使用简档1200B可以为检修技师提供当在车辆使用时对于特定车型而言何时报告特定DTC的估计。

同样，检修技师可以通过选择特定症状来查看指示对于特定车型何时报告特定症状的车辆使用简档。如图12C所示，如果计算设备接收到指示“听-尖叫声”症状的选择的数据，则计算设备可以提供用于特定症状的车辆使用简档1200C。通过示例的方式，车辆使用简档1200C包括具有对应于多个里程间隔的多个仓的直方图。查看车辆使用简档1200C可以为检修技师提供在车辆使用时对于特定车型何时报告特定症状的估计。

另外，根据上述，检修技师可以使用接口1100来选择车辆的一个或多个潜在车辆修理。例如，如图13A所示，如果检修技师证实一个或多个制动钳需要更换(例如，通过视觉检查和测试车辆制动系统)，则检修技师可以选择接口1100上的制动钳旁边的复选框。响应于接收到制动钳的选择，计算设备能够提供与制动钳有关的一个或多个潜在车辆修理的列表1300A。检修技师随后可以从列表1300A中选择一个或多个车辆修理，并且计算设备能够将选定的车辆修理与车辆诊断记录相关联。例如，响应于选择“分动器”按钮1302，计算设备能够将选定的车辆修理与车辆诊断记录相关联。在另一示例中，列表1300A可以提供在覆盖模式故障旅行者(未示出)的部分的弹出窗内。

类似地，如图13B所示，如果检修技师证实对于特定车辆触发了特定DTC，则检修技师可以选择接口1100上特定DTC旁边的复选框。响应于接收到DTC的选择，计算设备能够提供与DTC有关的一个或多个潜在车辆修理的列表1300B。检修技师随后可以从列表1300B中选择一个或多个车辆修理，并且计算设备能够响应于“分动器”按钮1302的选择而将选定的车辆修理与车辆诊断记录相关联。在另一示例中，列表1300B可以提供在覆盖模式故障旅行者(未示出)的部分的弹出窗内。

同样，如图13C所示，如果检修技师证实车辆呈现特定症状，则检修技师可以选择接口1100上特定症状旁边的复选框。响应于接收到症状的选择，计算设备能够提供与该症状有关的一个或多个潜在车辆修理的列表1300C。然后，检修技师可以从列表1300B中选择一个或多个车辆修理，并且计算设备能够响应于“分动器”按钮1302的选择而将选定的车辆修理与车辆诊断记录相关联。在另一示例中，列表1300C可以提供在覆盖模式故障旅行者(未示出)的部分的弹出窗内。

进一步根据上述，服务器或其它计算设备能够确定与关联车辆诊断记录的至少一个潜在车辆修理有关的估计信息。例如，如上文结合图6所描述的，计算设备能够通过访问服务劳动时间标准的数据库来确定潜在车辆修理的维修时间。并且，计算设备能够通过访问特定维修店的用户账户来确定该特定维修店的店内人工工资率。此外，计算设备能够通过查询一个或多个EPC来确定与潜在车辆修理相关联的任何零件的零件花费。并且，要确定维修花费估计，计算设备能够将所确定的维修时间乘以所确定的店内人工工资率来计算劳动花费。劳动花费随后能够与零件花费组合而确定维修花费估计。

在维修花费估计或维修时间估计已经确定之后，计算设备能够将维修花费估计或维修时间估计与车辆诊断记录相关联。例如，计算设备可以更新服务器所维护的车辆诊断记录以包括维修花费估计和维修时间估计。

图14示出了包括与至少一个潜在车辆修理有关的估计信息1402的示例接口1400的概念图示。特别地，图14示出了已经更新而包括用于修理制动钳的估计信息的图10的示例接口1000的概念图示。如图14所示，通过示例的方式，估计信息包括维修时间、劳动花费、零件花费以及总维修花费估计。

图15示出了又一示例接口1500的概念图示。通过示例的方式，接口1500可以是用于显示与车辆诊断记录相关联的潜在维修信息以及任选地选择车辆的一个或多个潜在车辆修理的窗或制表符。例如，在检修撰写人或技师已经输入客户信息和车辆信息之后，检修技师可以使用接口1500来实现车辆诊断。

如图15所示，接口1500包括前面维修组件列表1502、前面维修DTC列表1504、前面维修症状列表1506以及前面查找列表1508。在一个实例中，前面查找列表1508可以包括对于特定车型用户(例如，检修技师)最经常搜索的组件列表。

另外，图15描绘了搜索框1510。在一些示例中，用户可以使用搜索框1510来搜索未出现在前面维修组件列表1502、前面维修DTC列表1504、前面维修症状列表1506以及前面查找列表1508中的特定症状、组件或DTC。在一些实例中，用户可以将文本输入到搜索框1510中，并且搜索的结果可以提供于显示窗1512中。例如，如果用户输入特定组件，则结果可以包括与特定组件有关的车辆使用简档。其它示例也是可能的。

注意，在图15的示例接口1500中，搜索框1510被提供于靠近接口1500的顶部。示例不意在限制。在其它配置中，搜索框1510同样可以被提供于接口1500的其它位置。

现在参考图16A和16B，图16A和16B是用于与车辆诊断记录交互的示例流程图。特别地，图16A和16B示出了第一客户端设备1602、服务器1604、第二客户端设备1606和车辆维修数据库1608之间的示例交互。为示例的目的，结合图16A和16B，假设第一客户端设备1602由检修撰写人来操作，第二客户端设备1606由检修技师操作。在其它示例中，第一客户端设备1602和第二客户端设备1606的一个或多个功能能够由单个客户端设备来执行。可选地，在一些实例中，第一客户端设备1602和第二客户端设备1606的一个或多个功能能够由一个或多个附加计算设备(未示出)来执行。

如图16A所示，在框1610中，第一客户端设备1602能够接收车辆信息。例如，第一客户端设备1602可以接收由检修撰写人输入或者从车辆扫描的车辆信息。随后在框1612中，第一客户端设备1602能够将车辆信息与由服务器1604维护的车辆诊断记录相关联。例如，第一客户端设备1602可以使用网络服务或应用编程接口来创建车辆诊断记录。可选地，第一客户端设备能够通过生成具有车辆信息(未示出)的车辆诊断记录来将车辆信息与车辆诊断记录相关联。

随后，在框1614中，第二客户端设备1606能够访问车辆诊断记录来确定检修技师正在诊断的特定车型的车辆信息。在确定车辆信息之后，在框1616中，第二客户端设备1606能够查询车辆维修数据库1608来确定与特定车型有关的维修信息。根据上述，第二客户端设备1606能够确定如下的一个或任意组合：与车型有关的至少前两个维修组件、与车型有关的至少前两个报告症状，以及与车型有关的至少前两个报告的DTC。并且，在框1618中，第二客户端设备1606能够提供指示维修信息的图形表示。例如，图形表示可以是指示维修信息的一部分的图形或图表。

如图16B所示，在框1620中，第二客户端设备1606能够接收潜在车辆修理的选择。在框1622中，第二客户端设备能够将车辆修理与车辆诊断记录相关联。此外，在框1624中，服务器1604能够查询车辆维修数据库1608来确定与车辆修理有关的估计信息。根据上述，估计信息可以包括维修花费估计和/或维修时间估计。在框1626中，服务器1604随后能够将所确定的估计信息与车辆诊断记录相关联。

随后，在框1628和1630中，第一客户端设备1602能够访问车辆诊断记录来确定估计信息，并且显示该估计信息。例如，检修撰写人能够访问车辆诊断记录从而为客户准备开价。因此，第一客户端设备1602和第二客户端设备1606能够在与客户交互并且诊断车辆故障原因时访问车辆诊断记录。

如上所述，本文所描述的计算设备可以是任意类型的计算设备。图17是示出了在根据本文所描述的至少一些实施例布置的计算系统中使用的示例计算设备1700的功能框图。能够实现计算设备1700以确定估计信息或维修信息，或者执行上文参考图1-16所描述的任何功能。在基本配置1702中，计算设备1700能够典型地包括一个或多个处理器1710以及系统存储器1720。存储器总线1730能够用于处理器1710与系统存储器1720之间的通信。取决于所需的配置，处理器1710可以是任意类型，包括但不限于微处理器(μP)、微控制器(μC)、数字信号处理器(DSP)或其任意组合。存储器控制器1715还能够与处理器1710一起使用，或者在一些实现方式中，存储器控制器1715能够是处理器1710的内部部件。

根据所需的配置，系统存储器1720可以是任意类型，包括但不限于易失性存储器(诸如RAM)、非易失性存储器(诸如ROM、闪速存储器等)或其任意组合。系统存储器1720可以包括一个或多个应用1722以及程序数据1724。根据本公开，应用1722可以包括被布置为接收车辆信息，并且将车辆信息提供给通信网络或者接收车辆信息并确定估计信息或维修信息的算法1723。程序数据1724可以包括涉及任意数量类型的数据的维修通知单数据1725。在一些示例性实施例中，应用1722可以被布置为在操作系统上操作程序数据1724。

计算设备1700可以具有附加的特征或功能以及附加的接口以便于基本配置1702与任何设备和接口之间的通信。例如，数据存储设备1740可以被提供，包括可移除存储设备1742、非可移除存储设备1744或者其组合。可移除存储设备和非可移除存储设备的示例包括诸如软盘驱动器和硬盘驱动器(HDD)的磁盘设备、诸如压缩盘(CD)驱动器或数字多功能盘(DVD)驱动器的光盘驱动器、固态驱动器(SSD)和磁带驱动器，仅列举了几个。计算机存储介质可以包括以用于存储诸如计算机可读指令、数据结构、程序模块或其它数据之类的信息的任何方法或技术实现的易失性和非易失性、非暂时性、以及可移除和非可移除的介质。

系统存储器1720和存储设备1740是计算机存储介质的示例。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪速存储器或其它存储器技术、CD-ROM、数字多功能盘(DVD)或其它光学存储设备、磁盒、磁带、磁盘存储设备或其它磁存储设备、或者能够用于存储所需信息并且可由计算设备1700访问的任何其它介质。任意这样的计算机存储介质可以是设备1700的部件。

计算设备1700还可以包括输出接口1750，其可以包括图形处理单元1752，其能够被配置为经由一个或多个A/V端口1754或通信接口1770与诸如显示设备1760或扬声器的各种外部设备通信。通信接口1770可以包括网络控制器1772，其能够被布置为利于经由一个或多个通信端口1774通过网络通信与一个或多个其他计算设备1780通信。通信连接是通信介质的一个示例。通信介质可以通过计算机可读指令、数据结构、程序模块或诸如载波或其它传输机制的调制数据信号中的其它数据来具体实施，并且可以包括任何信息输送介质。调制数据信号可以是使得其特性中的一个或多个以将信号中的信息进行编码的方式设定或改变的信号。通过举例而不是限制的方式，通信介质可以包括诸如有线网络或直接线连接的有线介质，以及诸如声波、射频(RF)、红外(IR)和其它无线介质的无线介质。

计算设备1700可以被实现为诸如蜂窝电话、个人数据助理(PDA)、个人媒体播放器设备、无线网页监视设备(wireless web-watch device)、个人头戴送受话器设备、专用设备或包括上述功能中的任一种的混合设备的小形状因数的便携式(或移动)电子设备的一部分。计算设备1700还可以被实现为包括膝上型计算机和非膝上型计算机配置两者的个人计算机，或者服务器。

在一些实施例中，公开的方法能够实现为以机器可读格式编码在非暂时性计算机可读存储介质或者其他非暂时性介质或制品上的计算机程序指令。图18是示出了根据本文提供的至少一些实施例布置的包括用于在计算设备上执行计算机过程的计算机程序的示例计算机程序产品1800的概念局部图的示意图。

在一个实施例中，示例计算机程序产品1800是利用信号承载介质1801来提供的。信号承载介质1801可以包括一个或多个编程指令1802，当由一个或多个处理器执行时，这些编程指令能够提供上文结合图1-16所描述的功能或功能的部分。在一些示例中，信号承载介质1801能够包括计算机可读介质1803，诸如但不限于硬盘驱动器、压缩盘(CD)、数字多功能盘(DVD)、数字带、存储器等。在一些实现方式中，信号承载介质1801可以包括计算机可记录介质1804，诸如但不限于存储器、读/写(R/W)CD、R/W DVD等。在一些实施方式中，信号承载介质1801可以包括通信介质1805，诸如但不限于数字和/或模拟通信介质(例如，光纤电缆、波导、有线通信链路、无线通信链路等)。因此，例如，信号承载介质1801能够通过通信介质1805的无线形式(例如，符合IEEE 802.11标准或其他传输协议的无线通信介质)来传送。

一条或多条编程指令1802可以为例如计算机可执行的和/或逻辑实现的指令。在一些示例中，诸如图17的计算设备1700的计算设备能够被配置为响应于由计算机可读介质1803、计算机可读介质1804和/或通信介质1805中的一个或多个传送到计算设备1700的编程指令1802而提供各种操作、功能或动作。

应当理解，本文所描述的布置仅为了示例目的。因此，本领域技术人员将意识到，能够替代地使用其他布置和其他元件(例如，机器、接口、功能、次序以及功能的群集等)，并且根据期望结果能够使得一些元件一起省略。进一步，所描述的许多元件是能够在任何适合的组合和位置中实现为离散的或分布的组件或者与其他组件相结合而实现的功能实体。

虽然本文已经公开了各个方面和实施例，但是其他方面和实施例将对于本领域技术人员而言是显而易见的。本文所公开的各个方面和实施例是为了示例说明的目的，并且不意在限制，真正的范围由随附的权利要求书以及这些权利要求赋予权利的等同方案的整个范围来指示。还应理解，本文所使用的术语仅是为了描述特定实施例的目的，不意在限制。

Claims (20)

1.一种用于车辆维修的方法，包括：

由计算设备确定车辆信息，所述车辆信息包括用于第一车型的第一车辆标识符；

由所述计算设备至少部分地基于所述车辆信息以及与之前对所述第一车型的各种车辆执行的维修相关的从多个维修店收集的并且存储在车辆维修数据库中的数据来确定第一类维修通知单条目中的至少前两个维修通知单条目，其中，所述第一类维修通知单条目包括与所述第一车型有关的多个维修通知单条目，所述多个维修通知单条目中的每一个维修通知单条目在列出所述维修通知单条目的所述车辆维修数据库中具有相应数量的相对应的维修通知单，并且其中，所述至少前两个维修通知单条目在所述第一类维修通知单条目中具有两个最对应的维修通知单；以及

由所述计算设备提供并且用于显示所述第一类维修通知单条目中的所述至少前两个维修通知单条目的图形表示，并且由所述计算设备提供并且用于显示所述至少前两个维修通知单条目中的至少一个维修通知单条目的车辆使用简档。

2.如权利要求1所述的方法，进一步包括：

由所述计算设备接收所述第一类维修通知单条目中的所述至少前两个维修通知单条目中的特定维修通知单条目的选择；以及

由所述计算设备提供并且用于显示与所述特定维修通知单条目相关联的一个或多个潜在车辆修理。

3.如权利要求2所述的方法，进一步包括：

由所述计算设备接收与所述特定维修通知单条目相关联的所述一个或多个潜在车辆修理中的至少一个潜在车辆修理的选择；以及

由所述计算设备将所述至少一个潜在车辆修理与由服务器存储的车辆诊断记录相关联。

4.如权利要求1所述的方法，其中，所述车辆使用简档指示与所述至少一个维修通知单条目相对应的维修通知单在多个车辆使用间隔上的分布。

5.如权利要求1所述的方法，其中，所述车辆使用简档包括直方图。

6.如权利要求1、2、3、4或5所述的方法，其中，确定所述第一类维修通知单条目中的所述至少前两个维修通知单条目包括查询所述车辆维修数据库，其中，所述车辆维修数据库包括多个维修通知单，并且其中，所述多个维修通知单中的各个维修通知单均包括维修通知单条目。

7.如权利要求1、2、3、4或5所述的方法，其中，所述第一类维修通知单条目包括从由如下项构成的组中选出的类别：维修的组件、报告的诊断故障码、以及报告的症状。

8.如权利要求1、2、3、4或5所述的方法，进一步包括：

至少部分地基于所述车辆信息以及存储在所述车辆维修数据库中的所述数据来确定第二类维修通知单条目中的至少前两个维修通知单条目，其中，所述第二类维修通知单条目中的所述至少前两个维修通知单条目与所述第一车型有关，并且是从所述第二类维修通知单条目中的与所述第一车型有关的多个维修通知单条目当中确定的；以及

提供所述第二类维修通知单条目中的所述至少前两个维修通知单条目用于显示。

9.如权利要求8所述的方法：

其中，所述第一类维修通知单条目包括从由如下项构成的组中选出的给定类别：维修的组件、报告的诊断故障码、以及报告的症状；以及

其中，所述第二类维修通知单条目包括从所述组中选出的不同于所述给定类别的另一类别。

10.如权利要求1、2、3、4或5所述的方法，其中，所述第一车辆标识符包括从由如下项构成的组选出的标识符：年份、品牌、型号；年份、品牌、型号、引擎；年份、品牌、型号、引擎、系统；以及车辆标识号。

11.如权利要求1、2、3、4或5所述的方法，其中，所述车辆信息进一步包括用于第一车辆的车辆使用数据。

12.如权利要求1、2、3、4或5所述的方法，其中，确定所述第一类维修通知单条目中的所述至少前两个维修通知单条目包括：

针对所述多个维修通知单条目的所述维修通知单条目中的每一个，确定与所述维修通知单条目对应的所述相应数量的维修通知单；以及

基于所述多个维修通知单条目中的所述维修通知单条目的相应数量的维修通知单，确定所述第一类维修通知单条目中的所述至少前两个维修通知单条目。

13.一种计算设备，包括：

至少一个处理器；以及

计算机可读介质，其被配置为存储指令，当由所述至少一个处理器执行时，所述指令使所述计算设备执行包括如下的功能：

确定车辆信息，所述车辆信息包括第一车型的第一车辆标识符，

至少部分地基于所述车辆信息以及与之前对所述第一车型的各种车辆执行的维修相关的从多个维修店收集的并且存储在车辆维修数据库中的数据来确定第一类维修通知单条目中的至少前两个维修通知单条目，其中，所述第一类维修通知单条目包括与所述第一车型有关的多个维修通知单条目，所述多个维修通知单条目中的每一个维修通知单条目在列出所述维修通知单条目的所述车辆维修数据库中具有相应数量的相对应的维修通知单，并且其中，所述至少前两个维修通知单条目在所述第一类维修通知单条目中具有两个最对应的维修通知单，以及

提供所述第一类维修通知单条目中的所述至少前两个维修通知单条目的图形表示以用于显示，并且显示所述至少前两个维修通知单条目中的至少一个维修通知单条目的车辆使用简档。

14.如权利要求13所述的计算设备，其中，所述功能进一步包括：

接收所述第一类维修通知单条目中的所述至少前两个维修通知单条目中的特定维修通知单条目的选择；以及

提供与所述特定维修通知单条目相关联的一个或多个潜在车辆修理以用于显示。

15.如权利要求13所述的计算设备，其中，所述车辆使用简档指示多个维修通知单在多个车辆使用间隔上的分布。

16.一种用于车辆维修的系统，包括：

第一客户端设备，其被配置为：

经由被提供在所述第一客户端设备上的第一接口来接收车辆信息，所述车辆信息包括第一车型的第一车辆标识符，以及

将所述车辆信息与对应于第一车辆的第一车辆诊断记录相关联；以及

第二客户端设备，其被配置为：

至少部分地基于与所述车辆诊断记录相关联的所述车辆信息以及与之前对所述第一车型的各种车辆执行的维修相关的从多个维修店收集的并且存储在车辆维修数据库中的数据来确定第一类维修通知单条目中的至少前两个维修通知单条目，其中，所述第一类维修通知单条目包括与所述第一车型有关的多个维修通知单条目，所述多个维修通知单条目中的每一个维修通知单条目在列出所述维修通知单条目的所述车辆维修数据库中具有相应数量的相对应的维修通知单，并且其中，所述至少前两个维修通知单条目在所述第一类维修通知单条目中具有两个最对应的维修通知单，以及

提供所述第一类维修通知单条目中的所述至少前两个维修通知单条目的图形表示以用于显示，并且显示所述至少前两个维修通知单条目中的至少一个维修通知单条目的车辆使用简档。

17.如权利要求16所述的系统，其中，所述第二客户端设备进一步被配置为：

经由被提供在所述第二客户端设备上的第二接口来接收所述第一类维修通知单条目中的所述至少前两个维修通知单条目中的特定维修通知单条目的选择；以及

提供与所述特定维修通知单条目相关联的一个或多个潜在车辆修理以用于显示。

18.如权利要求17所述的系统，其中，所述第二客户端设备进一步被配置为：

经由所述第二接口来接收与所述特定维修通知单条目相关联的所述一个或多个潜在车辆修理中的至少一个潜在车辆修理的选择；以及

将所述至少一个潜在车辆修理与所述车辆诊断记录相关联。

19.如权利要求16、17或18所述的系统，其中，将所述车辆信息与所述车辆诊断记录相关联包括：将所述车辆信息提供给服务器，以用于与所述车辆诊断记录相关联。

20.如权利要求16、17或18所述的系统，其中，将所述车辆信息与所述车辆诊断记录相关联包括生成具有所述车辆信息的车辆诊断记录，并且其中，所述第一客户端设备进一步被配置为将生成的车辆诊断记录提供给所述第二客户端设备。