1. Field of the Invention
The invention generally relates to systems methods for customizing an automobile inspection based partly on the automobile make, model, etc., the particular vehicle's inspection and repair history, and/or attributes of the particular vehicle's current driver and/or previous drivers.
2. Description of the Related Art
Automobiles have many components and systems that function alone, or in coordination, to allow proper operation of the vehicle. Examples of such systems and components may include, but are not limited to, brake systems, emissions systems, transmission systems, belts, hoses, fluid levels, tires, etc. In order to ensure that proper operation of the vehicle is maintained, vehicle inspections and repairs are typically recommended by the vehicle manufacturer at selected intervals in order to check the operation of the vehicle's many components and systems.
In order to assist in the inspection and repair process, vehicle inspection forms, lists, or checklists are often utilized. An inspection list provides an inventory of components to check during a vehicle inspection. In one example, such a list may be generated by a vehicle manufacturer. In another example, inspection lists may be generated by individual automobile repair facilities. In this manner, a technician or mechanic can be advised of a variety of systems and/or components to inspect and/or repair.
Unfortunately, these inspection checklists function as “one-size-fits-all” and are used for multiple makes, models, years, etc. of vehicles, each with different drivers and repair histories. Thus, these generic inspection checklists can potentially waste the vehicle owner's time and money, since they may result in inspection of systems that are without problems, while missing unlisted systems that may need repair. Additionally, certain vehicles may have unique repair needs that are not included on generic inspection checklists. Accordingly, there is a need for systems and methods that improve the vehicle inspection process so that the components that are most likely to need service or repair are examined thoroughly, while other components may be more quickly examined or not examined at all.
In one embodiment, a computerized method of generating a customized inspection checklist for a particular vehicle comprises determining one or more of a year, make, and model, of a particular vehicle presented at an inspection facility for inspection, locating inspection data for a plurality of similar vehicles each having one or more of a year, make, and model the same as the determined year, make, and model of the particular vehicle, wherein the inspection data comprises a plurality of inspection tasks and corresponding inspection results for the similar vehicles, locating one or more inspection tasks of the inspection data for which a predetermined proportion of the inspection results associated with the similar vehicles indicate that one or more repairs or further inspection should be performed on the respective similar vehicles, and generating a customized inspection checklist including the located inspection tasks.
In another embodiment, a method of determining inspection tasks for inclusion in an inspection checklist for a particular vehicle comprises accessing a data structure comprising indications of a plurality of inspection tasks and associations between respective inspection tasks and respective combinations of one or more of a year, make, and a model of a vehicle, and selecting a first plurality of inspection tasks that are associated with a particular vehicle in the data structure.
In another embodiment, a system for generating an inspection form for use by an automotive technician comprises a computing device configured to receive attributes associated with a particular vehicle, a server in data communication with the computing device, the server storing information regarding repairs that have previously been made to vehicles similar to the particular vehicle, wherein the server provides an indication of those repairs that have been made on similar vehicles at least a threshold number of times and the computing device generates the inspection form comprising inspection recommendations that correspond with the repairs indicated by the server.
Embodiments of the invention will now be described with reference to the accompanying Figures, wherein like numerals refer to like elements throughout. The terminology used in the description presented herein is not intended to be interpreted in any limited or restrictive manner, simply because it is being utilized in conjunction with a detailed description of certain specific embodiments of the invention. Furthermore, embodiments of the invention may include several novel features, no single one of which is solely responsible for its desirable attributes or which is essential to practicing the inventions herein described.
In one embodiment, the repair facility 180 comprises a data store that stores data associated with inspection, repairs, and/or repair results, for example, that are performed/observed at the repair facility 180. In one embodiment, the repair facility 180 comprises an automobile repair shop, such as that of a dealership, fleet maintenance depot, or independent mechanic. In another embodiment, the repair facility 180 may comprise the home or workshop of a consumer who performs at least one maintenance operation on a vehicle. In a further embodiment, the repair facility 180 may comprise the location of an individual who desires additional information on vehicle maintenance but does not intend to perform the maintenance themselves.
Advantageously, the smart inspection module analyzes the data received from one or more data sources 170 and generates customized inspection checklists for respective inspection vehicles based at least partly upon the received/accessed data. The terms “vehicle” and “automobile,” as used herein, may comprise any vehicle, automobile, airplane, tractor, boat, or other motorized device, as well as other types of devices that may require inspections and/or repairs, such as electronic devices, including computers and computerized devices, for example. Thus, any reference herein to an automobile or vehicle should be construed to cover any other apparatus or device.
In one embodiment, the smart inspection module 100 identifies inspection tasks that are customized for respective inspection vehicles based on data received from the one or more data sources 170 regarding vehicles similar to the inspection vehicle. In one embodiment, the data received from one or more data sources 170 comprises one or more of symptom reports, recommended inspections and/or repairs, repairs (that were actually performed on respective vehicles), effectiveness of repairs performed, consumer repair inquiry data, warranty information, replacement part sales/use data, and/or any other data that may be useful in determining components of like-kind vehicles that may benefit from inspections and/or repairs. The data received from the data sources 170 may then be used by the smart inspection module to identify trends associated with particular makes, models, mileages, etc., of particular vehicles, such that when the repair facility 180 requests inspection tasks for a particular inspection vehicle, the smart inspection model 100 can provide inspection tasks that are relevant to the particular inspection vehicle.
In one embodiment, the smart inspection module 100 generates a smart inspection checklist (also referred to herein as a “smart inspection report”, or simply a “smart inspection”) comprising one or more inspection tasks that are recommended for the particular inspection vehicle indicated by the automobile repair facility 180, for example. This smart inspection checklist is in contrast to that employed in conventional inspections that include inspection tasks that are generic to large classes of vehicles. As a result, the smart inspection checklist provides pertinent information on topics including, but not limited to, warrantees, recalls, customer surveys, independent reviews, and the experiences of large numbers of mechanics and technicians in an organized and timely manner. Thus, more time and energy can be spent at the repair facility 180 determining and implementing a proper course of action based on the recommendations and additional considerations provided by the smart inspection module 100, rather than gathering such information from scratch or relying on guesswork. This targeted approach, in turn, raises the likelihood of a successful inspection and/or repair outcome at the repair facility 180, saving the customer time and money. These and other advantages of embodiments of the smart inspection module 100 are discussed in detail below.
In the embodiment of
In addition to transferring relevant recommendation and repair data via the network 160, certain data sources 170 may transmit data to the smart inspection module 100 via other means, such as on a moveable media, such as DVD, CD-ROM, flash memory, thumb drive, etc., that may be delivered to an administrator of the smart inspection module 100. In other embodiments, the smart inspection module 100 is in communication with fewer or more devices than are illustrated in
In operation, the smart inspection module 100 receives data from the one or more data sources 170 via the network 160 and/or from the repair facility 180. From the received data, the smart inspection module 100 trends the repair recommendation and/or repair data indicated in the data received from the data sources 170, and the smart inspection module 100 provides the trending data to one or more repair facilities 180 in a customized, smart inspection report. In general, trending comprises analyzing historical data for similar vehicles in order to identify possible likely symptoms/repairs of another vehicle (such as an inspection vehicle at the repair facility 180). A trend may be associated with any group of vehicle attributes and may indicate any likely symptoms, likely repair needs, and/or informational items regarding vehicles having the common group of attributes. For example, the repair facility 180 may receive an inspection request from an owner of a 2005 Nissan Maxima. A technician at the repair facility may obtain various information, also referred to as attributes, associated with the Nissan Maxima (the “inspection vehicle”), such as the make, model, year, sub-model, engine specifications, accessory package, mileage, inspection history, and/or repair history, as well as any other relevant attributes of the inspection vehicle. Additionally, the technician may obtain various information associated with one or more drivers of the inspection vehicle, such as profession, driving severity, geographical region and climate of use, as well as any other relevant attributes of the driver(s) of the vehicle. After obtaining one or more vehicle attributes and possibly driver attributes, the technician transmits the obtained attributes to the smart inspection module 100 and, in return, the smart inspection module 100 provides one or more recommended inspection tasks for inclusion on a smart inspection checklist for the particular 2005 Nissan Maxima, wherein the inspection tasks are selected based on at least trended repair and/or recommendation data that has been generated by the smart inspection module 100 based on information received from one or more data sources 170. Further description of the process of generating trended repair and/or recommendation data and use of the trended data in generating smart inspection reports for specific vehicles is provided below.
In the embodiment of
In general, the word module, as used herein, refers to logic embodied in hardware or firmware, or to a collection of software instructions, possibly having entry and exit points, written in a programming language, such as C or C++. A software module may be compiled and linked into an executable program, installed in a dynamic link library, or may be written in an interpreted programming language such as BASIC, Perl, or Python. It will be appreciated that software modules may be callable from other modules or from themselves, and/or may be invoked in response to detected events or interrupts. Software instructions may be embedded in firmware, such as an EPROM. The modules described herein are preferably implemented as software modules, but may be represented in hardware or firmware. Moreover, although in some embodiments a module may be separately compiled, in other embodiments a module may represent a subset of instructions of a separately compiled program, and may not have an interface available to other logical program units.
In one embodiment, the smart inspection module 100 comprises a server based system. In other embodiments, the smart inspection module 100 may comprise any other computing device, such as a computing device or server that is IBM, Macintosh, or Linux/Unix compatible. In another embodiment, the smart inspection module 100 comprises a desktop personal computer (PC), a laptop computer, a cellular phone, personal digital assistant (PDA), a kiosk, or an audio player, for example.
In the embodiment of
The smart inspection module 100 is generally controlled and coordinated by operating system software, such as server based software. In other embodiments, the smart inspection module 100 comprises modules that execute one or more other operating systems, such as Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP, Windows Vista, Linux, SunOS, Solaris, PalmOS, Blackberry OS, or other desktop or server operating systems. In Macintosh systems, the operating system may be any available operating system, such as MAC OS X. In other embodiments, the smart inspection module 100 may be controlled by a proprietary operating system. Conventional operating systems control and schedule computer processes for execution, perform memory management, provide file system, networking, and I/O services, and provide a user interface, such as a graphical user interface (“GUI”), among other things.
The exemplary smart inspection module 100 includes one or more commonly available input/output (I/O) devices and interfaces (not shown), such as a keyboard, mouse, touchpad, speaker, and printer. In one embodiment, the I/O devices and interfaces include one or more display device, such as a monitor, that allows the visual presentation of data to a user. More particularly, a display device provides for the presentation of GUIs, application software data, and multimedia presentations, for example. The smart inspection module 100 may also include one or more multimedia devices, such as speakers, video cards, graphics accelerators, and microphones, for example.
In the exemplary embodiment of
In certain embodiments, the smart inspection checklist may include fewer inspection tasks than are on a standard automobile inspection. For example, the trending data that is generated by the smart inspection module 100 may not include certain standard inspection tasks based on a trend that indicates the particular inspection tasks are not likely to need repair on the particular inspection vehicle. In this embodiment, the technician is provided with additional time to focus on the more relevant inspection tasks, rather than inspecting items for which there is a low probability that a repair is needed.
Beginning in block 210 (
In one embodiment, the data sources 170, including the repair facility 180 in one embodiment, upload data to the smart inspection module 100 as the data is entered into their respective databases. In another embodiment, the smart inspection module 100 periodically requests data from certain data sources 170 and/or certain data sources 170 automatically upload data to the smart inspection module 100 on a periodic basis.
Continuing to block 220, the trending module 120 of the smart inspection module 100 analyzes the vehicle data from the data sources 170 and trends the data so that trends associated with similar vehicles are identified and usable in the inspection of the particular inspection vehicle. The term “similar vehicle,” as used herein, comprises vehicles having a group of attributes in common with the inspection vehicles, wherein the attributes are selected from the group comprising vehicle make, model, sub-model, engine specifications, accessory packages, purchase year, manufacture year, inspection/repair history, driving severity, mileage range, and any other attribute that vehicles may have in common. Thus, an inspection vehicle may be associated with multiple groups of similar vehicles, each potentially indicating different trends. For example, similar vehicles of a 2005 Nissan Maxima SE may include a first group of similar vehicles that are newer than 2002, a second group of similar vehicles that are Nissan Maxima SE's, and a third group of similar vehicles that are 2005 Nissan Maxima SE's. In one embodiment, each of the groups of similar vehicles may comprise one or more trends that are useful in determining inspection tasks for the current inspection vehicle. In one embodiment, the most probative trends are associated with the similar vehicles having the most attributes in common with the inspection vehicle.
Trends, in general, indicate some characteristic of multiple similar vehicles that suggest a particular action (or non-action) on other similar vehicles. For example, a trend for a particular inspection vehicle may indicate that (i) mechanics inspecting similar vehicles recommended a particular repair for a large percentage of the similar vehicles, (ii) mechanics inspecting similar vehicles performed a particular repair for a large percentage of the similar vehicles, (iii) a particular repair performed on similar vehicles successfully resolved certain symptoms, (iv) parts purchased for repair of similar vehicles suggest that a particular repair is commonly performed on similar vehicles, and/or (v) inspections of similar vehicles indicate a particular component/system may require repair. Additionally, trends for the inspection vehicle may be determined based more than one of the above-noted exemplary trends, such as repair data and part purchase data for the similar vehicles, and trends may be based on any other data associated with similar vehicles. For example, trends may be generated based on data received from one or more of the data sources 170 associated with similar vehicles having accessories that have been installed on the vehicle post-purchase, such as running boards, ski racks, towing packages, and/or windshield tint, for example.
In certain embodiments, trends for an inspection vehicle may indicate that fewer inspection tasks are prudent for the vehicle. For example, if multiple data sources 170 provided data to the smart inspection module 100 indicating that 2002 and newer models of all Lexus vehicles very rarely require replacement of spark plug prior to reaching 150,000 miles, the trending data for that particular model and year range of vehicles may include a recommendation that examination of spark plugs is not included on a corresponding smart inspection checklist.
With reference to
As discussed above, the data 172A-172E may be communicated to the smart inspection module 100 in various formats and may be transmitted and/or accessed at various times and frequencies. Additionally, the content of the data 172A-172E may vary from what is indicated in
Table 1, below, illustrates a small portion of an exemplary data structure indicating trending data for certain Ford vehicles. As illustrated in table 1, certain inspection tasks are associated with a particular make and model of vehicle, while others are associated with additional vehicle attributes. As is also illustrated in the rank column of
Moving to block 230, the smart inspection module 100 locates smart inspection tasks that are relevant to specific vehicles that are presented for inspection at respective repair facilities, for example. In one embodiment, for example, upon receiving a request for inspection of a particular vehicle, the inspection facility 180 transmits data including vehicle attributes and/or driver attributes to the inspection module 100. In one embodiment, certain attributes of the inspection vehicle may be gathered by cursory examination of the vehicle. Make, model, engine specifications, mileage, and year of a vehicle are generally recognizable features of a vehicle upon quick examination. Further, poor condition of a vehicle for its age may indicate demanding driving habits and/or use of the vehicle, while good condition of a vehicle for its age may indicate the opposite. Similarly, a cursory view of the vehicle may reveal many accessories which have been installed in the vehicle. In another example, certain attributes of the inspection vehicle may be gathered using a DTC code or vehicle identification number (VIN), in combination with records maintained by least one public or private vehicle organization, such those operated by as CarFax™, state governments, and national governments. Such records may be in electronic form, such as a database or in paper form. In a further example, the attributes of the inspection vehicle may be gathered by speaking with the vehicle owner, operator, or manager. Additionally, attributes of the inspection vehicle and/or driver of the vehicle may have previously been stored by a repair facility 180, such as during a previous inspection of the inspection vehicle. Any of the above methods may be employed in any combination to gather vehicle and/or driver attributes.
In response to receiving the vehicle and/or driver attributes, the smart inspection module 100 reviews the trending information stored in the trended data store 140 in order to identify inspection tasks associated with similar vehicles that may be included on a smart inspection checklist for the inspection vehicle. In one embodiment, the smart inspection module 100 provides the recommended inspection tasks to the requesting repair facility 180 and allows the repair facility 180 to generate a corresponding smart inspection checklists, possibly including additional inspection tasks and/or removing certain inspection tasks recommended by the smart inspection module 100. In another embodiment, the smart inspection module 100 generates a smart inspection checklists including the recommended inspection tasks identified by the smart inspection module 100. In one embodiment, the smart inspection may include a first set of inspection items associated with repairs that are likely to be necessary on the particular make and model of car, as well as another set of recommendations that are specific to at least one other attribute of the inspection vehicle, such as mileage range, driver attributes, repair history, etc. The smart inspection may also include inspection task recommendations that are particular to any other one or more attributes associated with the inspection vehicle. In one embodiment, inspection tasks are provided to the repair facility 180 in two or more groups, such as high priority and low priority groups of inspection tasks.
Beginning in block 410, vehicle and/or driver attributes associated with the inspection vehicle are received at the inspection module 100, or at another computing device that is configured to access the trending database 140. In one embodiment, the trending database 140 may be stored at additional locations, such as local to the automobile inspection facility 180. In one embodiment, the vehicle attributes comprise a make, model, engine specifications, year, and mileage of the automobile. In further embodiments, the vehicle attributes include at least a portion of the vehicle's repair and maintenance history. Depending on the embodiment, driver attributes may include one or more of an age, driving experience, profession, geographic location of driving and percentage of highway and city driving time as a function of total driving time. In other embodiments, the vehicle and/or driver attributes include fewer or additional attributes.
Moving to block 420, trended data for the particular inspection vehicle is accessed in the database 140. In one embodiment, the trended data indicates the likelihood that certain inspection tasks will result in a “Caution” or “Fail” response by the inspection facility, based on the proportion of “Caution” and “Fail” responses received for the similar vehicles when inspected by technician at one or more of various repair facilities (and/or by technicians at the repair facility that is requesting the smart inspection checklist). For example, if 250 out of 280 inspections of Chevy Vega's resulted in a “Fail” response to the “check oil pressure” task, the inspection module 100 may select the “check oil pressure” task as a high priority task for other Chevy Vega's for which inspection is requested. In other embodiments, other data from other data sources is also utilized in determining high priority tasks for respective inspection vehicles.
Next, in block 430, data regarding previous inspections, repairs, and/or repair recommendations on the inspection vehicle is optionally retrieved and analyzed in order to refine the inspection tasks provided based on the trending data. In one embodiment, block 430 is not performed, e.g., the high priority tasks determined based on trending data associated with the inspection vehicle are used in the smart inspection checklist. In embodiments where block 430 is performed, the smart inspection checklist may be even more specific to the particular needs of the inspection vehicle. For example, the previous repair/recommendation data may indicate that the specific automobile had valve gaskets replaced in the previous year. Accordingly, the smart inspection checklist generated by the smart inspection module 100 may indicate that the valve gaskets should be checked for leaks or other problems in view of the recent replacement of the valve gaskets. In another example, the previous repair/recommendation data may indicate that a major tune up service was performed in advance of a standard maintenance schedule. Accordingly, the smart inspection checklist generated by the smart inspection module 100 may indicate that such a tune up service should not be included at the standard interval. In one embodiment, the data associated with the vehicles serviced by the particular inspection facility 180 is stored local to the inspection facility 180 or at an off-site storage facility. In another embodiment, the historical repair data for a particular vehicle may be transmitted to the smart inspection module 100, may be used in generating the trending data stored in data store 140, and/or accessed by the smart inspection module in the generation of certain smart inspection checklist.
Moving to block 440, trending data associated with the driver profile in which one or more drivers of the inspection vehicle match is optionally accessed in order to locate relevant inspection tasks for inclusion or removal from the smart inspection checklist. For example, a first driver profile may match drivers that are female and above the age of 45. For these drivers, the trending data may indicate that brake pads should be checked at each inspection, regardless of the type of vehicle that is presented for inspection. In one embodiment, driver attributes and vehicle attributes may be considered by the trending module 120 in order to determine trends that for a particular inspection vehicle.
In block 450, a smart inspection checklist is generated and/or recommended inspection tasks for a particular inspection vehicle are compiled in a data structure that may be used by the inspection facility 180 in order for them to generate an inspection checklist. The smart inspection checklist may be transmitted in any format, such as in a PDF, CSV, TXT, JPG, or XML file, for example, or any other format that is readable by the automobile inspection facility 180. Upon receiving the smart inspection checklist and/or inspection tasks, the automobile inspection facility 180 may perform an inspection based on the inspection tasks listed in the smart inspection. In an advantageous embodiment, the smart inspection checklist includes items of particular interest for the specific inspection vehicle, based on at least the trended repair and/or repair recommendation data generated by the trending module 120 of the smart inspection module 100.
In one embodiment, the smart inspection module 100 orders the inspections tasks for a particular inspection vehicle according to a logical order of inspection that will be performed by the technician. For example, inspection tasks for a particular vehicle system may be grouped. Likewise, inspection tasks that require a particular vehicle configure, e.g., hood open, raised on stands, etc., may be grouped to minimize repetitive labor by the technician.
In one embodiment, technician reports of
In one embodiment certain of the tasks indicate a quantity of other similar vehicles for which the particular inspection task received a “fail” response from the respective inspection technician. Thus, a technician report may indicate that 200 out of 600 (or 33.3%) vehicles of the same make and model as the inspection vehicle resulted in a “fail” response to the “check the attachment of the muffler” inspection task. The technician report may further, or alternatively, indicate that 102 out of 150 (or 68%) vehicles of the same make, model, and year as the inspection vehicle resulted in a “fail” response to the same “check the attachment of the muffler” inspection task. Thus, statistics for various groups of vehicle and/or driver attributes may be provided on the technician report, allowing the technician to make better decisions for prioritizing completion of inspection tasks.
In one embodiment, any of the smart inspection reports may sub-divide inspection tasks according to likelihood of success of a recommended repair. The technician or service manager may employ data regarding the likelihood of success of an inspection or repair as a further tool in their advocacy.
Advantageously, with this information, the service manager may be a strong advocate for necessary inspections and repairs. At the same time, however, the service manager may be knowledgeable about optional inspections and repairs. The service manager may be further informed about the relative likelihood of success of a repair associated with a recommended inspection task. Taken together, this information allows the service manager to be focused on the customer's needs and preferences, maximizing the likelihood of positive results and return business.
One embodiment of a customer report is illustrated in
The foregoing description details certain embodiments of the invention. It will be appreciated, however, that no matter how detailed the foregoing appears in text, the invention can be practiced in many ways. As is also stated above, it should be noted that the use of particular terminology when describing certain features or aspects of the invention should not be taken to imply that the terminology is being re-defined herein to be restricted to including any specific characteristics of the features or aspects of the invention with which that terminology is associated. The scope of the invention should therefore be construed in accordance with the appended claims and any equivalents thereof.
This application claims the benefit of priority under 35 U.S.C. §119(e) of U.S. Provisional Application No. 60/886,845 filed on Jan. 26, 2007, entitled “Smart Inspections,” which is hereby incorporated by reference in its entirety.
Number | Date | Country | |
---|---|---|---|
60886845 | Jan 2007 | US |