Systems and apparatuses facilitating a do-it-yourself experience-based repair solution

Embodiments are disclosed for facilitating Do-It-Yourself (DIY) repairs. In the context of a method, an example embodiment includes receiving, by an experience-based repair service (EBRS) host system, vehicle diagnostic information identifying one or more vehicle problems. This example embodiment of the method further includes evaluating the vehicle diagnostic information, generating, based on the evaluation of the vehicle diagnostic information, required part types and required tools for addressing the one or more vehicle problems, and generating, based on the evaluation of the vehicle diagnostic information, recommended part types for addressing the one or more vehicle problems. Finally, this example embodiment of the method further includes causing presentation of an interface facilitating purchase of required parts from each of the generated required part types, the required tools, and recommended parts from each of the generated recommended part types. Corresponding apparatuses and computer program products are also provided.

TECHNOLOGICAL FIELD

Example embodiments of the present invention relate generally to vehicular repairs and, more particularly, to a system and apparatuses facilitating repairs by Do-It-Yourself (DIY) consumers.

BACKGROUND

Applicant has discovered problems with traditional methods by which retailers and DIY consumers interact. Many of these problems are overcome using example embodiments described in detail below, which rely upon previously unavailable technological improvements to address pain points and minimize administrative hassle.

BRIEF SUMMARY

As described herein, example embodiments provide an Experience-Based Repair Solution (EBRS) platform addressing the DIY consumer market segment and providing example systems and apparatuses facilitating a DIY EBRS solution.

In a first example embodiment, a method is provided for facilitating Do-It-Yourself (DIY) repairs. The method includes receiving, by an experience-based repair service (EBRS) host system, vehicle diagnostic information identifying one or more vehicle problems, and evaluating, by the EBRS host system, the vehicle diagnostic information. The method further includes generating, by the EBRS host system and based on the evaluation of the vehicle diagnostic information, required part types and required tools for addressing the one or more vehicle problems, generating, by the EBRS host system and based on the evaluation of the vehicle diagnostic information, recommended part types for addressing the one or more vehicle problems, and causing presentation of an interface facilitating purchase of required parts from each of the generated required part types, the required tools, and recommended parts from each of the generated recommended part types.

In some embodiments, the method includes generating complexity information relating to each of the one or more vehicle problems, wherein the complexity information identifies an estimated time period needed to complete repair of each of the one or more vehicle problems, and causing presentation of the generated complexity information. In some such embodiments, generating complexity information relating to a vehicle problem includes retrieving, by the EBRS host system, historical information regarding frequency of returns of parts and tools associated with the vehicle problem, and assigning a level of complexity to the vehicle problem based on the frequency of returns. Alternatively, generating complexity information relating to a vehicle problem may include calculating an estimated time to fix the vehicle problem. In one such embodiment, calculating the estimated time to fix the vehicle problem comprises retrieving, by the EBRS host system, historical information regarding time periods until subsequent activity by consumers having purchased parts relating to the vehicle problem, and averaging the time periods until the subsequent activity, wherein the estimated time to fix the vehicle problem is based on the averaging of the time periods until the subsequent activity. This historical information may include vehicle diagnostic information retrieved from vehicles that identifies when the vehicle problems are fixed. In another such embodiment, calculating the estimated time to fix the vehicle problem comprises causing dissemination of customer surveys corresponding to vehicle problems after each purchase, wherein the customer surveys request information regarding the estimated time to fix the vehicle problem, and receiving, by the EBRS host system, consumer responses to the customer surveys, wherein the estimated time to fix the vehicle problem is based on the received consumer responses.

In some embodiments, the method includes causing presentation of an interface facilitating selection from a plurality of quality tiers, and receiving, by the EBRS host system, selection of a quality tier from the plurality of quality tiers, wherein prioritization of the required parts from each of the generated required part types and the recommended parts from each of the generated recommended part types is based on the selected quality tier.

In some embodiments, the method further includes causing presentation of an interface facilitating selection from a plurality of comprehensiveness tiers, and receiving, by the EBRS host system, selection of a comprehensiveness tier from the plurality of comprehensiveness tiers, wherein the recommended part types are generated based on the selected comprehensiveness tier.

In some embodiments, the EBRS host system causes the presentation of the interface facilitating purchase of the required parts, the required tools, and the recommended parts in response to an application programming interface (API) call from a third party application.

In some embodiments, the method includes identifying orders of priority of the required parts and the recommended parts, wherein causing presentation of the interface facilitating purchase of the required parts, the required tools, and the recommended parts includes causing presentation of the required parts and the recommended parts in the corresponding orders of priority. In some such embodiments, the orders of priority of the required parts and the recommended parts are based on one or more of: price, inventory levels, vendor-negotiated deals, geography, or historical rates of part returns.

In some embodiments, the method includes receiving, by the EBRS host system, vehicle diagnostic information after making repairs recommended by the EBRS host system to address one or more vehicle problems. The method further includes determining, by the EBRS host system and based on the evaluation of the vehicle diagnostic information, whether any vehicle problems exist, and storing an indication of one or more effects of the repairs. In some such embodiments, the indication of one or more effects of the repairs is based on one or more of: vehicle problems existed before and after the repairs, records of part returns, or user input.

In some embodiments, the method includes transmitting, by the EBRS host system, a survey to gather input regarding vehicle problems from a user after determining, by the EBRS host system and based on the evaluation of the vehicle diagnostic information received after making repairs recommended by the EBRS host system, whether any vehicle problems exist. The method further includes receiving, by the EBRS host system, feedback from the user in response to transmission of the user survey, determining, by the EBRS host system and based on the evaluation of the user feedback, whether any vehicle problems exist, and storing, by the EBRS host system, an indication of one or more effects of the repairs.

In a second example embodiment, an apparatus is provided for facilitating Do-It-Yourself (DIY) repairs. The apparatus includes at least one processor and at least one memory storing computer-executable instructions, that, when executed by the at least one processor, cause the apparatus to receive vehicle diagnostic information identifying one or more vehicle problems, and evaluate the vehicle diagnostic information. The computer-executable instructions, when executed by the at least one processor, further cause the apparatus to generate, based on the evaluation of the vehicle diagnostic information, required part types and required tools for addressing the one or more vehicle problems, generate, based on the evaluation of the vehicle diagnostic information, recommended part types for addressing the one or more vehicle problems, and cause presentation of an interface facilitating purchase of required parts from each of the generated required part types, the required tools, and recommended parts from each of the generated recommended part types.

In some embodiments, the computer-executable instructions, when executed by the at least one processor, further cause the apparatus to generate complexity information relating to each of the one or more vehicle problems, wherein the complexity information identifies an estimated time period needed to complete repair of each of the one or more vehicle problems, and causing presentation of the generated complexity information. In some such embodiments, generating complexity information relating to a vehicle problem includes retrieving historical information regarding frequency of returns of parts and tools associated with the vehicle problem, and assigning a level of complexity to the vehicle problem based on the frequency of returns. Alternatively, generating complexity information relating to a vehicle problem may include calculating an estimated time to fix the vehicle problem. In one such embodiment, calculating the estimated time to fix the vehicle problem comprises retrieving historical information regarding time periods until subsequent activity by consumers having purchased parts relating to the vehicle problem, and averaging the time periods until the subsequent activity, wherein the estimated time to fix the vehicle problem is based on the averaging of the time periods until the subsequent activity. This historical information may include vehicle diagnostic information retrieved from vehicles that identifies when the vehicle problems are fixed. In another such embodiment, calculating the estimated time to fix the vehicle problem comprises causing dissemination of customer surveys corresponding to vehicle problems after each purchase, wherein the customer surveys request information regarding the estimated time to fix the vehicle problem, and receiving, by the EBRS host system, consumer responses to the customer surveys, wherein the estimated time to fix the vehicle problem is based on the received consumer responses.

In some embodiments, the computer-executable instructions, when executed by the at least one processor, further cause the apparatus to cause presentation of an interface facilitating selection from a plurality of quality tiers, and receive selection of a quality tier from the plurality of quality tiers, wherein prioritization of the required parts from each of the generated required part types and the recommended parts from each of the generated recommended part types is based on the selected quality tier.

In some embodiments, the computer-executable instructions, when executed by the at least one processor, further cause the apparatus to cause presentation of an interface facilitating selection from a plurality of comprehensiveness tiers, and receive selection of a comprehensiveness tier from the plurality of comprehensiveness tiers, wherein the recommended part types are generated based on the selected comprehensiveness tier.

In some embodiments, the apparatus causes the presentation of the interface facilitating purchase of the required parts, the required tools, and the recommended parts in response to an application programming interface (API) call from a third party application.

In some embodiments, the computer-executable instructions, when executed by the at least one processor, further cause the apparatus to identify orders of priority of the required parts and the recommended parts, wherein causing presentation of the interface facilitating purchase of the required parts, the required tools, and the recommended parts includes causing presentation of the required parts and the recommended parts in the corresponding orders of priority. In some such embodiments, the orders of priority of the required parts and the recommended parts are based on one or more of: price, inventory levels, vendor-negotiated deals, geography, or historical rates of part returns.

In some embodiments, the computer-executable instructions, when executed by the at least one processor, further cause the apparatus to receive vehicle diagnostic information after making repairs recommended by the apparatus to address one or more vehicle problems. The computer-executable instructions, when executed by the at least one processor, further cause the apparatus to determine, based on the evaluation of the vehicle diagnostic information, whether any vehicle problems exist, and store an indication of one or more effects of the repairs. In some such embodiments, the indication of one or more effects of the repairs is based on one or more of: vehicle problems existed before and after the repairs, records of part returns, or user input.

In some embodiments, the computer-executable instructions, when executed by the at least one processor, further cause the apparatus to transmit a survey to gather input regarding vehicle problems from a user after determining, based on the evaluation of the vehicle diagnostic information received after making repairs recommended by the apparatus, whether any vehicle problems exist. The computer-executable instructions, when executed by the at least one processor, may further cause the apparatus to receive feedback from the user in response to transmission of the user survey, determine, based on the evaluation of user feedback, whether any vehicle problems exist, and store an indication of one or more effects of the repairs.

In a third example embodiment, a computer program product at least one non-transitory computer-readable storage medium is provided for facilitating Do-It-Yourself (DIY) repairs. The at least one non-transitory computer-readable storage medium stores computer-executable instructions that, when executed, cause an apparatus to receive vehicle diagnostic information identifying one or more vehicle problems, and evaluate the vehicle diagnostic information. The computer-executable instructions, when executed, further cause the apparatus to generate, based on the evaluation of the vehicle diagnostic information, required part types and required tools for addressing the one or more vehicle problems, generate, based on the evaluation of the vehicle diagnostic information, recommended part types for addressing the one or more vehicle problems, and cause presentation of an interface facilitating purchase of required parts from each of the generated required part types, the required tools, and recommended parts from each of the generated recommended part types.

In some embodiments, the computer-executable instructions, when executed, further cause the apparatus to generate complexity information relating to each of the one or more vehicle problems, wherein the complexity information identifies an estimated time period needed to complete repair of each of the one or more vehicle problems, and causing presentation of the generated complexity information. In some such embodiments, generating complexity information relating to a vehicle problem includes retrieving historical information regarding frequency of returns of parts and tools associated with the vehicle problem, and assigning a level of complexity to the vehicle problem based on the frequency of returns. Alternatively, generating complexity information relating to a vehicle problem may include calculating an estimated time to fix the vehicle problem. In one such embodiment, calculating the estimated time to fix the vehicle problem comprises retrieving historical information regarding time periods until subsequent activity by consumers having purchased parts relating to the vehicle problem, and averaging the time periods until the subsequent activity, wherein the estimated time to fix the vehicle problem is based on the averaging of the time periods until the subsequent activity. This historical information may include vehicle diagnostic information retrieved from vehicles that identifies when the vehicle problems are fixed. In another such embodiment, calculating the estimated time to fix the vehicle problem comprises causing dissemination of customer surveys corresponding to vehicle problems after each purchase, wherein the customer surveys request information regarding the estimated time to fix the vehicle problem, and receiving consumer responses to the customer surveys, wherein the estimated time to fix the vehicle problem is based on the received consumer responses.

In some embodiments, the computer-executable instructions, when executed, further cause the apparatus to cause presentation of an interface facilitating selection from a plurality of quality tiers, and receive selection of a quality tier from the plurality of quality tiers, wherein prioritization of the required parts from each of the generated required part types and the recommended parts from each of the generated recommended part types is based on the selected quality tier.

In some embodiments, the computer-executable instructions, when executed, further cause the apparatus to cause presentation of an interface facilitating selection from a plurality of comprehensiveness tiers, and receive selection of a comprehensiveness tier from the plurality of comprehensiveness tiers, wherein the recommended part types are generated based on the selected comprehensiveness tier.

In some embodiments, the computer-executable instructions, when executed, further cause the apparatus to cause the presentation of the interface facilitating purchase of the required parts, the required tools, and the recommended parts in response to an application programming interface (API) call from a third party application.

In some embodiments, the computer-executable instructions, when executed, further cause the apparatus to identify orders of priority of the required parts and the recommended parts, wherein causing presentation of the interface facilitating purchase of the required parts, the required tools, and the recommended parts includes causing presentation of the required parts and the recommended parts in the corresponding orders of priority. In some such embodiments, the orders of priority of the required parts and the recommended parts are based on one or more of: price, inventory levels, vendor-negotiated deals, geography, or historical rates of part returns.

In some embodiments, the computer-executable instructions, when executed, further cause the apparatus to receive vehicle diagnostic information after making repairs recommended by the apparatus to address one or more vehicle problems. The computer-executable instructions, when executed, further cause the apparatus to determine, based on the evaluation of the vehicle diagnostic information, whether any vehicle problems exist, and store an indication of one or more effects of the repairs. In some such embodiments, the indication of one or more effects of the repairs is based on one or more of: vehicle problems existed before and after the repairs, records of part returns, or user input.

In some embodiments, the computer-executable instructions, when executed, further cause the apparatus to transmit a survey to gather input regarding vehicle problems from a user after determining, based on the evaluation of the vehicle diagnostic information received after making repairs recommended by the apparatus, whether any vehicle problems exist. The computer-executable instructions, when executed, further cause the apparatus to receive feedback from the user in response to transmission of the user survey, determine, based on the evaluation of user feedback, whether any vehicle problems exist, and store an indication of one or more effects of the repairs.

In another example embodiment, a method is provided for facilitating Do-It-Yourself (DIY) repairs. The method includes receiving vehicle diagnostic information identifying one or more vehicle problems, transmitting the received vehicle diagnostic information to an EBRS host system, receiving, from the EBRS host system, required part types and required tools for addressing the one or more vehicle problems, receiving, from the EBRS host system, recommended part types for addressing the one or more vehicle problems, and causing presentation of an interface facilitating purchase of required parts from each of the generated required part types, the required tools, and recommended parts from each of the generated recommended part types.

In some embodiments, receiving vehicle diagnostic information identifying one or more vehicle problems includes one or more of: receiving, via communications circuitry, diagnostic trouble codes from an OBD-II scanner; receiving, via OBD-II scanning circuitry, diagnostic trouble codes from a vehicle; receiving, via input/output circuitry, user input; or receiving, from a memory, vehicle diagnostic information from a historical database.

In some embodiments, the method further includes receiving, from the EBRS host system, complexity information relating to each of the one or more vehicle problems, wherein the complexity information identifies an estimated time period needed to complete repair of each of the one or more vehicle problems, and causing presentation of the generated complexity information. In some such embodiments, the complexity information relating to a vehicle problem includes a level of complexity to the vehicle problem based on the frequency of returns. In other such embodiments, the complexity information relating to a vehicle problem includes an estimated time to fix the vehicle problem.

In some embodiments, the method further includes causing presentation of an interface facilitating selection from a plurality of quality tiers, receiving selection of a quality tier from the plurality of quality tiers, and transmitting the selected quality tier to the EBRS host system.

In some embodiments, the method further includes causing presentation of an interface facilitating selection from a plurality of comprehensiveness tiers, receiving selection of a comprehensiveness tier from the plurality of comprehensiveness tiers, and transmitting the selected comprehensiveness tier to the EBRS host system.

In some embodiments, the method includes receiving vehicle diagnostic information after making repairs recommended by the EBRS host system to address one or more vehicle problems, and transmitting the received vehicle diagnostic information to the EBRS host system.

In some embodiments, receiving vehicle diagnostic information after making repairs recommended by the EBRS host system to address one or more vehicle problems includes one or more of: receiving, via communications circuitry, diagnostic trouble codes from an OBD-II scanner; receiving, via OBD-II scanning circuitry, diagnostic trouble codes from a vehicle; receiving, via input/output circuitry, user input; or receiving, from a memory, vehicle diagnostic information from a historical database.

In some embodiments, the method includes receiving, from the EBRS host system, a survey to gather user input regarding vehicle problems, causing presentation of an interface facilitating collection of user feedback, and transmitting, to the EBRS host system, the user feedback in response to the received user survey.

In another example embodiment, an apparatus is provided for facilitating Do-It-Yourself (DIY) repairs. The apparatus includes at least one processor and at least one memory storing computer-executable instructions, that, when executed by the at least one processor, cause the apparatus to receive vehicle diagnostic information identifying one or more vehicle problems, transmit the received vehicle diagnostic information to an EBRS host system, receive, from the EBRS host system, required part types and required tools for addressing the one or more vehicle problems, receive, from the EBRS host system, recommended part types for addressing the one or more vehicle problems, and cause presentation of an interface facilitating purchase of required parts from each of the generated required part types, the required tools, and recommended parts from each of the generated recommended part types.

In some embodiments, receiving vehicle diagnostic information identifying one or more vehicle problems includes one or more of: receiving, via communications circuitry, diagnostic trouble codes from an OBD-II scanner; receiving, via OBD-II scanning circuitry, diagnostic trouble codes from a vehicle; receiving, via input/output circuitry, user input; or receiving, from a memory, vehicle diagnostic information from a historical database.

In some embodiments, the computer-executable instructions, when executed by the at least one processor, further cause the apparatus to receive, from the EBRS host system, complexity information relating to each of the one or more vehicle problems, wherein the complexity information identifies an estimated time period needed to complete repair of each of the one or more vehicle problems, and cause presentation of the generated complexity information. In some such embodiments, the complexity information relating to a vehicle problem includes a level of complexity to the vehicle problem based on the frequency of returns. In other such embodiments, the complexity information relating to a vehicle problem includes an estimated time to fix the vehicle problem.

In some embodiments, the computer-executable instructions, when executed by the at least one processor, further cause the apparatus to, cause presentation of an interface facilitating selection from a plurality of quality tiers, receive selection of a quality tier from the plurality of quality tiers, and transmit the selected quality tier to the EBRS host system.

In some embodiments, the computer-executable instructions, when executed by the at least one processor, further cause the apparatus to cause presentation of an interface facilitating selection from a plurality of comprehensiveness tiers, receive selection of a comprehensiveness tier from the plurality of comprehensiveness tiers, and transmit the selected comprehensiveness tier to the EBRS host system.

In some embodiments, the computer-executable instructions, when executed by the at least one processor, further cause the apparatus to receive vehicle diagnostic information after making repairs recommended by the EBRS host system to address one or more vehicle problems, and transmit the received vehicle diagnostic information to the EBRS host system.

In some embodiments, receiving vehicle diagnostic information after making repairs recommended by the EBRS host system to address one or more vehicle problems includes one or more of: receiving, via communications circuitry, diagnostic trouble codes from an OBD-II scanner; receiving, via OBD-II scanning circuitry, diagnostic trouble codes from a vehicle; receiving, via input/output circuitry, user input; or receiving, from a memory, vehicle diagnostic information from a historical database.

In some embodiments, computer-executable instructions, when executed by the at least one processor, further cause the apparatus to receive, from the EBRS host system, a survey to gather user input regarding vehicle problems, cause presentation of an interface facilitating collection of user feedback, and transmit, to the EBRS host system, the user feedback in response to the received user survey.

In another example embodiment, a computer program product comprising at least one non-transitory computer-readable storage medium is provided. The at least one non-transitory computer-readable storage medium stores computer-executable instructions that, when executed, cause an apparatus to receive vehicle diagnostic information identifying one or more vehicle problems, transmit the received vehicle diagnostic information to an EBRS host system, receive, from the EBRS host system, required part types and required tools for addressing the one or more vehicle problems, receive, from the EBRS host system, recommended part types for addressing the one or more vehicle problems, and cause presentation of an interface facilitating purchase of required parts from each of the generated required part types, the required tools, and recommended parts from each of the generated recommended part types.

In some embodiments, receiving vehicle diagnostic information identifying one or more vehicle problems includes one or more of: receiving, via communications circuitry, diagnostic trouble codes from an OBD-II scanner; receiving, via OBD-II scanning circuitry, diagnostic trouble codes from a vehicle; receiving, via input/output circuitry, user input; or receiving, from a memory, vehicle diagnostic information from a historical database.

In some embodiments, the computer-executable instructions, when executed, further cause the apparatus to receive, from the EBRS host system, complexity information relating to each of the one or more vehicle problems, wherein the complexity information identifies an estimated time period needed to complete repair of each of the one or more vehicle problems, and cause presentation of the generated complexity information. In some such embodiments, the complexity information relating to a vehicle problem includes a level of complexity to the vehicle problem based on the frequency of returns. In other such embodiments, the complexity information relating to a vehicle problem includes an estimated time to fix the vehicle problem.

In some embodiments, the computer-executable instructions, when executed, further cause the apparatus to cause presentation of an interface facilitating selection from a plurality of quality tiers, receive selection of a quality tier from the plurality of quality tiers, and transmit the selected quality tier to the EBRS host system.

In some embodiments, the computer-executable instructions, when executed, further cause the apparatus to cause presentation of an interface facilitating selection from a plurality of comprehensiveness tiers, receive selection of a comprehensiveness tier from the plurality of comprehensiveness tiers, and transmit the selected comprehensiveness tier to the EBRS host system.

In some embodiments, the computer-executable instructions, when executed, further cause the apparatus to receive vehicle diagnostic information after making repairs recommended by the EBRS host system to address one or more vehicle problems, and transmit the received vehicle diagnostic information to the EBRS host system.

In some embodiments, receiving vehicle diagnostic information after making repairs recommended by the EBRS host system to address one or more vehicle problems includes one or more of: receiving, via communications circuitry, diagnostic trouble codes from an OBD-II scanner; receiving, via OBD-II scanning circuitry, diagnostic trouble codes from a vehicle; receiving, via input/output circuitry, user input; or receiving, from a memory, vehicle diagnostic information from a historical database.

In some embodiments, the computer-executable instructions, when executed, further cause the apparatus to receive, from the EBRS host system, a survey to gather user input regarding vehicle problems, cause presentation of an interface facilitating collection of user feedback, and transmit, to the EBRS host system, the user feedback in response to the received user survey.

DETAILED DESCRIPTION

OVERVIEW

Embodiments disclosed herein illustrate an EBRS platform that serves heretofore unmet needs of the automotive consumer base. Retailers historically have always sold replacement vehicle parts. Others, such as mechanics, offer quotes for Do-It-For-Me (DIFM) repairs, but those quotes are often fixed beforehand or ballpark estimates that include the cost of labor. However, for those consumers who seek to manually repair their own vehicle, labor costs are irrelevant, and it would be useful to have additional guidance regarding what parts are needed, without the requirement to separately research an issue. It is often the case that DIY consumers are forced to learn what parts are needed by trial and error, thus resulting in a series of trips to the store for various part purchases, even though a well-informed consumer would only need one. Moreover, in many cases, certain tools or equipment are required to repair certain parts, and repair of certain parts may also necessitate the replacement or repair of other parts by virtue of their relative relationships within a vehicle. For instance, the repair of brake pads and brake rotors often go hand-in-hand. Similarly, a valve cover may need to be replaced when replacing or repairing its corresponding valve.

Accordingly, example embodiments of the EBRS platform disclosed herein are designed to provide DIY consumers with the information necessary to evaluate the costs and requirements of repairing damage to vehicles and to facilitate a DIY EBRS solution. To do this, example embodiments of the EBRS platform gather information about a target vehicle, such as information retrieved from a vehicle diagnostic system or vehicle telematics system, or information about the vehicle that is not retrieved from the vehicle itself but from a separate source such as a vehicle owner or a third party (collectively, this information about a target vehicle may be referred to herein as vehicle diagnostic information), generate necessary repair information based on the gathered vehicle diagnostic information, locate available parts and tools based on the repair information, and provide an interactive interface offering the opportunity to purchase the parts and tools needed to repair the target vehicle. This interactive interface may describe the problem, the necessary parts and tools to fix the problem, and the cost to purchase the parts and tools, and may further provide a consumer with the opportunity to buy the necessary parts. In some embodiments, this interface may present a health report include how-to instructions/videos, job difficulty or complexity, and estimated time for completion, an estimated DIY cost and possibly a Do-It-For-Me (DIFM) cost (adding in an estimated labor cost, which may be provided by one or more mechanics using a service estimate provided in advance or through a service request leveraging an Application Programming Interface (API) or similar process). This report may be provided to the customer located in a retail store (e.g., via a point-of-sale terminal the customer can view), or may be provided to the consumer's device, to a commercial device (e.g., a mechanic's device), or to a third party application with which the customer interacts.

In addition, a closed-loop feedback system that confirms the effectiveness of repairs recommended for DIY consumers to address one or more vehicle problems is very valuable for enhancing the service provided to the DIY consumers. Accordingly, example embodiments of the EBRS platform disclosed herein are also designed to collect feedback indicating one or more effects of the repairs recommended to DIY consumers. To do this, example embodiments of the EBRS platform gather vehicle diagnostic information about a target vehicle after making repairs recommended by the EBRS system to address one or more vehicle problems, determine whether any vehicle problems exist based on the gathered vehicle diagnostic information, and store an indication of one or more effects of the repairs. In some embodiments, an interactive interface may be provided to a user to collect user feedback regarding vehicle problems and effectiveness of the repairs for each problem, and additional indications of one or more effects of the repairs, based on the user feedback, may be stored. This interactive interface for user feedback may be provided to a customer located in a retail store, or may be provided to the consumer's device, to a commercial device, or to a third party application with which the customer interact.

While each of these operations are described here at a high level, example systems and apparatuses for implementing this concept are provided below along with more detailed descriptions of example operations performed by those systems and/or apparatuses to provide consumers with the ability to utilize the example EBRS platforms described herein.

System Architecture

Methods, apparatuses, and computer program products of the present invention may be embodied by any of a variety of devices. Example embodiments may include a plurality of networked devices, such as an EBRS host system, retailer devices, third party devices, and/or other network entities, configured to operate in tandem. Example embodiments may include any of a variety of mobile terminals, such as a portable digital assistant (PDA), mobile telephone, smartphone, laptop computer, tablet computer, vehicle on-board computer, or any combination of the aforementioned devices. Similarly, the example embodiments may additionally or alternatively include any of a variety of fixed terminals, such as desktop computers, mainframe devices, kiosks or the like.

FIG. 1Adiscloses an example computing system100, which may be referred to herein as the EBRS platform, and within which embodiments of the present invention may operate. As illustrated, an EBRS host system102may be connected to a network108(e.g., the Internet, or the like) that the EBRS host system102utilizes to communicate with a series of retailer devices110A through110N. Consumers, vendors, manufacturers, service providers, and the like may interact with the EBRS host system102via the network108using a series of third party devices112A through112N. The EBRS host system102may comprise a server104in communication with a database106, which may be referred to as an affinity database.

The server104may be embodied as a computer or computers as known in the art. The server104may provide for transmission of notification messages among various devices, including but not necessarily limited to the retailer devices110A-110N, the third party devices112A-112N, and the database106. For example, the server104may be operable to receive and process notification messages provided by one or more retailer devices110and to deliver notification messages to retailer devices110A-110N and/or third party devices112A-112N.

The database106may be stored on one or more data storage devices, such as a Network Attached Storage (NAS) device, or as a separate database server or servers. Moreover, while referred to in the singular throughout this disclosure for clarity, it should be understood that database106may in some example embodiments comprise a series of databases. As one example using a series of databases, each database in the series may store a discrete type of information from the other databases in the series. The database106includes information accessed and stored by the server104to facilitate the operations of the EBRS host system102. In this regard, database106may comprise a proprietary set of “fix information” that is updated based on expert curation, historical information, feedback information, and manufacturer updates. This fix information may correlate vehicle diagnostic information to a problem, and may further identify one or more parts that must be replaced to repair each problem. In this regard, the fix information may identify one or more tools needed to complete the repair, and may further provide repair information describing the steps for making the repair. In some embodiments, the retailer may offer a “loaner tool” program providing a consumer with access needed tools without the requirement to purchase those tools outright. In addition, for each problem, the fix information may also include an identification of recommended parts that should be considered when making the repair. To generate this fix information, the database106may store information regarding the various vendors providing parts and/or tools, where the parts and/or tools from each vendor can be purchased, and the cost of purchasing each of the identified parts and/or tools from the various locations. Where the database106comprises a series of databases, this vendor information may be stored in a separate database in the series from other information stored in the series of databases.

In some embodiments, the database106may utilize a number of security and privacy measures to reduce the possibility that consumer or merchant data is leaked to unauthorized parties. In this regard, some or all of the retailer devices110A-112N and third party devices112A-112N may utilize password protected authentication to access the EBRS host system102and the transmission of data may be encrypted when possible. In some embodiments, this authentication-related information may be stored in a system (not shown inFIG. 1A) that is remote from the EBRS host system102.

Moreover, the database106may store accounts for retailers and third parties that enable retailers and third parties to log into and utilize the EBRS platform provided by the EBRS host system102via retailer devices110A-110N and third party devices112A-112N, respectively. The database106may store account information provided by the various account holders, but may store information harvested about each account holder as well, such as information gathered from clickstream data, purchasing histories, return histories, account activity, retailer inventory levels, and the like. Where the database106comprises a series of databases, this account-related information may be stored in a separate database in the series from other information stored in the series of databases.

For instance, for a retailer having a location in Cleveland, Ohio, the database106may store a set of information regarding the retailer, including its specific location, sales activity, and historical snapshots of inventory information harvested from the retailer over time. Moreover, when purchases are made via the EBRS platform, the database106may store customer demographic data for each retailer that provides insight into the types of consumers who may visit the retailer.

As another example, for a consumer that has an account with the EBRS platform, the database106may store contextual information that may be useful for improving that consumer's experience interacting with the EBRS platform. For instance, this contextual information may identify the physical location of the consumer when that consumer accesses the EBRS platform (e.g., whether the consumer is at a retail location or a consumer device, whether the consumer accesses the platform from varied geographical locations, or the like). Or regarding the consumer's activity interacting with the EBRS platform, the database106may store a purchase history, return history, activity frequency, indication of effects of past repairs, user feedback, or the like that is harvested from the consumer's interaction with the EBRS platform.

More broadly, the database106may also store other historical information that need not be directly tied to any individual or any specific device, but which can still be utilized for predictive analysis. This historical information may include cross-consumer and/or cross-retailer purchase information, vehicle diagnostic information, an indication of effects of repairs for one or more vehicle problems of a vehicle, and/or clickstream information. Similarly, the historical information may aggregate regional, national, and/or global information regarding part returns, reviews, consumer surveys, an indication of effects of past repairs, or the like that may be gathered from third party interactions with the EBRS platform.

The retailer devices110A-110N may be embodied by any computing devices known in the art. Although referred to herein as “retailer devices,” it should be understood that these devices110A-110N may in some embodiments be employed in a broader context than merely with regard to retail stores. For instance, while described in connection with retail stores, the term “retailer device” carries intuitive meaning. However, when the technology platform is utilized in alternative contexts (e.g., by an e-commerce provider that does not have a brick and mortar retail location), devices110A-110N may be operated by employees or independent contractors associated with an organization that is not traditionally referred to as a “retailer.” Despite the fact that the technology platform can be utilized by those that may not traditionally be designated as retailers, the terms “retailer” and “retailer device” are used herein for the sake of simplicity.

The retailer devices110A-110N may transmit messages to the server104in various forms and via various methods. For example, the retailer devices110A-110N may include kiosks, desktop computers, laptop computers, smartphones, netbooks, tablet computers, wearable devices, or the like. The information may be provided through various sources associated with each of these respective devices.

In some embodiments, a retailer device110may execute an “app” to interact with the EBRS host system102, other retailer devices, and/or third party devices112A-112N. Such apps are typically designed to execute on mobile devices, such as tablets or smartphones. For example, an app may be provided that executes on mobile device operating systems such as Apple Inc.'s iOS®, Google Inc.'s Android®, or Microsoft Inc.'s Windows®. These platforms typically provide frameworks that allow apps to communicate with one another and with particular hardware and software components of mobile devices. For example, the mobile operating systems named above provide frameworks for interacting with location services circuitry, wired and wireless network interfaces, user contacts, and other applications in a manner that allows for improved interactions between apps while also preserving the privacy and security of individual users. Communication with hardware and software modules executing outside of the app is typically provided via APIs provided by the mobile device operating system.

In embodiments in which a retailer device110is not a mobile device but comprises a desktop computer, laptop computer, or the like, the retailer device110may execute a more traditional software application facilitating the functionality described above, such as a web browser. As an example, a computer monitor may be mounted to the retailer's parts counter in a rotatable or movable fashion so that the retailer can show the web browser to a customer or mechanic on the other side of the counter. As yet another example, in some embodiments (e.g., when the retailer device110comprises a kiosk located with a retail facility), a retailer device110may include special-purpose hardware or firmware designed to interface with the EBRS host system102or third party device112in a purpose-built device having a primary purpose of communicating with the EBRS host system102.

The third party devices112A-112N may be any computing devices known in the art and operated by a third party. These devices are referred to herein as “third party devices” for the sake of inclusiveness, because one goal of several example embodiments is the engagement of a wide variety of entities. Accordingly, although a primary user of a third party device112may be a consumer, example embodiments described herein also contemplate use of third party devices112by business partners, suppliers, insurance companies, or other interested parties.

Each of the third party devices112A-112N may include a computing device accessing a web site designed to provide merchant access (e.g., a smartphone, PDA, or desktop computer configured to access a web page via a browser using a set of merchant account credentials). Each of the third party devices112A-112N may interact with the EBRS host system102and retailer devices110A-110N. In this regard, the third party devices112A-112N may provide information to the EBRS host system102and/or the retailer devices112A-112N in various forms and via various methods. Similarly, the third party devices112A-112N may receive transmissions from the EBRS host system102and/or one or more retailer devices110A-110N.

Like the retailer devices110A-110N, the third party devices112A-112N may be embodied by any computing devices known in the art. The third party devices112A-112N may transmit messages to the server104in various forms and via various methods. For example, the third party devices112A-112N may include desktop computers, laptop computers, smartphones, netbooks, tablet computers, wearable devices, or the like. Similarly to the retailer environment, a computer monitor may be mounted to a third party's desk or counter in a rotatable or movable fashion so that the third party can show the web browser to a customer or mechanic on the other side of the counter or desk. The information may be provided through various sources on these devices.

Like the retailer devices110A-110N, a third party device112may execute an “app” to interact with the EBRS host system102, retailer devices110A-110N, and/or with other third party devices112A-112N. Additionally or alternatively, the third party devices112A-112N may interact with the EBRS host system102or retailer device110A-110N via a web browser. As yet another example, the third party devices112A-112N may include various special-purpose hardware or firmware designed to interface with the EBRS host system102or an retailer device110(e.g., where a third party devices112is a purpose-built device offered for the primary purpose of communicating with the EBRS host system102or retailer device110).

FIG. 1Bdiscloses a diagram150illustrating one example sequence in which various elements of the system interact. As shown, the EBRS platform may be leveraged for performing DIY repairs on a vehicle152. An On-Board Diagnostics (OBD)-II scanner154may be used to interrogate the vehicle152to harvest vehicle diagnostic codes (e.g., diagnostic trouble codes such as p-codes or the like), which can then be relayed to a retailer device110or third party device112. It should be understood that OBD-II is an expanded set of standards and practices developed by the Society of Automotive Engineers (SAE) and compliance is mandatory throughout the US. In Europe and other countries such as Japan and Australia, similar standards have proliferated, and it will be understood that referencing scanner154as an “OBD-II scanner” is for ease of description, and that the scanner may in some embodiments be capable of interacting with vehicles operating under the relevant standards in other countries, or any other, standards for retrieving on-board diagnostic information from a vehicle. In some embodiments, a retailer device110or third party device112may itself incorporate an OBD-II scanner, thus removing the need for a separate OBD-II scanner to interrogate the vehicle152(hence the separate dotted line between the vehicle152and the box representing the retailer/third party device110/112). It will be understood that OBD-II scanning is not a necessary element of all example embodiments, and the EBRS platform may in some circumstances be leveraged using only manually-entered data or data retrieved via a telematics system incorporated into the vehicle152. Accordingly, as indicated by the dashed lines associated with the vehicle152and OBD-II scanner154, the EBRS platform may in some instances may gather data directly from the vehicle154(thus not requiring OBD-II scanner154), or in other embodiments may not even need to involve the vehicle152, in which case data is gathered using only a retailer device110and the EBRS host system102or a third party device112and the EBRS host system102.

Example Implementing Apparatuses

Having provided a high level description of the various devices employed by the example embodiments contemplated herein and an example illustration of how those devices may interact with each other, a low-level description of the various components comprising each of these devices will now be provided.

Turning first toFIG. 2, the server104included within the EBRS host system102may be embodied by one or more computing systems, such as apparatus200shown inFIG. 2. As illustrated inFIG. 2, the apparatus200includes a processor202, a memory204, input/output circuitry206, communications circuitry208, and may further include diagnostic circuitry210and fix finder circuitry212. The apparatus200may be configured to execute the operations described above in connection withFIGS. 1A-1Band below in connection withFIGS. 5A-11. Although these components202-212are described with some functional descriptors, it should be understood that the particular implementations necessarily include the use of particular hardware. It should also be understood that certain of these components202-212may include similar or common hardware. For example, two sets of circuitry may both leverage use of the same processor, network interface, storage medium, or the like to perform their associated functions, such that duplicate hardware is not required for each set of circuitry (although embodiments using duplicated hardware may also be used). The use of the term “circuitry” as used herein with respect to components of the apparatus therefore includes particular hardware configured to perform the functions associated with the particular circuitry described herein.

Of course, while the term “circuitry” should be understood broadly to include hardware, in some embodiments, circuitry may also include software for configuring the hardware. For example, in some embodiments, “circuitry” may include processing circuitry, storage media, network interfaces, input/output devices, and the like. In some embodiments, other elements of the apparatus200may provide or supplement the functionality of particular circuitry. For example, the processor202may provide processing functionality, the memory204may provide storage functionality, input/output circuitry206may provide user interface functionality, communications circuitry208may provide network interface functionality, and the like.

In some embodiments, the processor202(and/or co-processor or any other processing circuitry assisting or otherwise associated with the processor) may be in communication with the memory204via a bus for passing information among components of the apparatus. The processor202may be embodied in a number of different ways and may, for example, include one or more processing devices configured to perform independently. Additionally or alternatively, the processor may include one or more processors configured in tandem via a bus to enable independent execution of instructions, pipelining, and/or multithreading. The use of the term “processing circuitry” may be understood to include a single core processor, a multi-core processor, multiple processors internal to the apparatus, and/or remote or “cloud” processors.

In an example embodiment, the processor202may be configured to execute instructions stored in the memory204or otherwise accessible to the processor. Alternatively or additionally, the processor may be configured to execute hard-coded functionality. As such, whether configured by hardware or software methods, or by a combination of hardware with software, the processor may represent an entity (e.g., physically embodied in circuitry) capable of performing operations according to an embodiment of the present invention while configured accordingly. Alternatively, as another example, when the processor is embodied as an executor of software instructions, the instructions may specifically configure the processor to perform the algorithms and/or operations described herein when the instructions are executed.

In some embodiments, the memory204may be non-transitory and may include, for example, one or more volatile and/or non-volatile memories. In other words, for example, the memory may be an electronic storage device (e.g., a computer readable storage medium). The memory204may be configured to store information, data, content, applications, instructions, or the like, for enabling the apparatus to carry out various functions in accordance with example embodiments contemplated herein.

The communications circuitry208may be any means such as a device or circuitry embodied in either hardware or a combination of hardware and software that is configured to receive and/or transmit data from/to a network and/or any other device, circuitry, or module in communication with the apparatus200. In this regard, the communications circuitry208may include, for example, a network interface for enabling communications with a wired or wireless communication network. For example, the communications circuitry208may include one or more network interface cards, antennae, buses, switches, routers, modems, and supporting hardware and/or software, or any other device suitable for enabling communications via a network. Additionally or alternatively, the communication interface may include the circuitry for interacting with the antenna(s) to cause transmission of signals via the antenna(s) or to handle receipt of signals received via the antenna(s). These signals may be transmitted by the apparatus200using any of a number of wireless personal area network (PAN) technologies, such as Bluetooth® v1.0 through v3.0, Bluetooth Low Energy (BLE), infrared wireless (e.g., IrDA), ultra-wideband (UWB), induction wireless transmission, or the like. In addition, it should be understood that these signals may be transmitted using Wi-Fi, Near Field Communications (NFC), Worldwide Interoperability for Microwave Access (WiMAX) or other proximity-based communications protocols.

In addition, the apparatus200may also comprise diagnostic circuitry210, which includes hardware components designed to receive vehicle diagnosis information and identify required parts to replace and, in some embodiments, additional recommended parts to replace. Diagnostic circuitry210may utilize processor202, memory204, input/output circuitry206, or any other hardware component included in the apparatus200to diagnose part failures. Diagnostic circuitry210may further utilize communications circuitry208to transmit the identified part information.

Diagnostic circuitry210may utilize processing circuitry, such as the processor202, to facilitate performance of the above operations, and may utilize memory204to store the generated part information prior to (or, conceivably, after) transmission to a retailer device110, third party device112, or to the EBRS host system102. It should be appreciated that, in some embodiments, diagnostic circuitry210may include a separate processor, specially configured field programmable gate array (FPGA), or application specific interface circuit (ASIC) to perform the above-described functions. Diagnostic circuitry210is therefore implemented using hardware components of the apparatus configured by either hardware or software for implementing these planned functions.

In addition, the apparatus200may also comprise fix finder circuitry212, which includes hardware components designed to receive a series of part types and generate fix information based on the received part types. This fix information may include one or more parts falling within each part type and the respective purchase price and retailer availability for each of the one or more parts. Fix finder circuitry212may utilize processor202, memory204, input/output circuitry206, or any other hardware component included in the apparatus200to diagnose part failures. Diagnostic circuitry210may further utilize communications circuitry208to transmit the verified fix to a retailer device110or third party device112.

Fix finder circuitry212may utilize processing circuitry, such as the processor202, to facilitate performance of the above operations, and may utilize memory204to store the generated fix information prior to (or, conceivably, after) transmission to a retailer device110or third party device112. It should be appreciated that, in some embodiments, fix finder circuitry212may include a separate processor, specially configured field programmable gate array (FPGA), or application specific interface circuit (ASIC) to perform the above-described functions. Fix finder circuitry212is therefore implemented using hardware components of the apparatus configured by either hardware or software for implementing these planned functions.

Turning next toFIG. 3, an example hardware configuration of retailer devices110A-110N is provided. These devices may be embodied by one or more computing systems, such as apparatus300shown inFIG. 3. As illustrated inFIG. 3, the apparatus300includes a processor302, a memory304, input/output circuitry306, communications circuitry308, and in various embodiments may further include OBD-II scanning circuitry310.

As it relates to operations described in the present invention, the functioning of the processor302, the memory304, the input/output circuitry306, and the communications circuitry308may be similar to the similarly named components described above with respect toFIG. 2, and for the sake of brevity, duplicative description of the mechanics of those components is omitted. It will be understood, however, that communications circuitry308may further be configured to facilitate communication with a vehicle telematics system of a vehicle, thereby facilitating the retrieval of vehicle diagnostic information from the vehicle. These device elements of apparatus300, operating together, provide the apparatus300with the functionality necessary for the retailer devices110A-110N to communicate with the EBRS host system102, one or more other retailer devices110A-110N, one or more third parties operating one or more third party devices112A-112N, and in some embodiments, one or more vehicles.

In some embodiments, the apparatus300may also comprise OBD-II scanning circuitry310, which includes hardware components designed to interface with a vehicle's OBD-II port and retrieve vehicle diagnostic codes therefrom. OBD-II scanning circuitry310may utilize input/output circuitry306or any other hardware component included in the apparatus300to perform these functions. OBD-II scanning circuitry310may utilize processing circuitry, such as the processor302, to facilitate performance of the above operations, and may utilize memory304to store the retrieved vehicle diagnostic codes prior to (or, conceivably, after) transmission to another device (e.g., the EBRS host system102). It should be appreciated that, in some embodiments, OBD-II scanning circuitry310may include a separate processor, specially configured field programmable gate array (FPGA), or application specific interface circuit (ASIC) to perform the above-described functions. OBD-II scanning circuitry310is therefore implemented using hardware components of the apparatus that are configured by either hardware or software. As noted previously during description of OBD-II scanner154, Europe and other countries such as Japan and Australia utilize standards other than the OBD-II standard, and it will be understood that the OBD-II scanning circuitry310may comprise hardware and software components that facilitate interaction with vehicles operating under these or other standards for retrieving on-board diagnostic information from a vehicle.

Finally, third party devices112A-112N may be embodied by one or more computing systems, such as apparatus400shown inFIG. 4. As illustrated inFIG. 4, the apparatus400may include a processor402, a memory404, input/output circuitry406, communications circuitry408, and OBD-II scanning circuitry410. As it relates to operations described in the present invention, the functioning of these elements may be similar to the similarly named components described above with respect toFIGS. 2 and/or 3above, and for the sake of brevity, additional description of the mechanics of these components is omitted. Nevertheless, these device elements, operating together, provide the apparatus400with the functionality necessary to facilitate the communication of data (e.g., vehicle diagnostic information, user commands, information from other devices, or the like) between a third party utilizing the third party device(s)112A-112N and any other devices connected via the EBRS platform.

It should be appreciated, with respect to certain embodiments of the apparatuses described inFIGS. 2-4, computer program instructions and/or other type of code may be loaded onto a computer, processor or other programmable apparatus's circuitry to produce a machine, such that the computer, processor other programmable circuitry that execute the code on the machine create the means for implementing various functions described herein.

Having described specific components of an example server device (e.g., apparatus200) that may embody the EBRS host system102, an example retailer device110(e.g., apparatus300), and an example third party device112(e.g., apparatus400), example embodiments of the present invention are described below in connection with a series of demonstrative graphical user interfaces and flowcharts that describe some example operations performed variously by the EBRS host system102, retailer devices110A-110N and third party devices112A-112N.

User Interfaces

Turning now toFIGS. 5A-5C, 6A-6C, 7, and 8A-8H, some user interfaces will now be described that illustrate various displays provided by a retailer device110to a retailer representative or a consumer, or by a third party device112to a consumer, as contemplated in some example embodiments. It should be understood that while some of the following interfaces are designed for display on a desktop monitor, other interfaces are intended to be implemented in a mobile environment on a mobile device (e.g., a smartphone, tablet, or the like). Moreover, although it may appear most natural for the EBRS host system102to design and generate the various interfaces that are displayed by the retailer device110(or third party device112) described in this section, it will be understood that this is not the only implementation contemplated. Indeed, it may be the case that a third party app developer (who may, for instance, have a significant following) develops a mobile app that is particularly useful. The EBRS platform can then be leveraged via an API designed to enable ease of implementation via a variety of different apps. In this fashion, the EBRS platform may be leveraged by mobile apps having a significantly larger user base.

Turning first toFIGS. 5A-5C, a series of example user interfaces are described for navigating from a main landing page associated with the EBRS platform to select a health report for a vehicle. These example user interfaces may be provided by a host system to a retailer device110or a third party device112for display to a consumer.

InFIG. 5A, an example interface is provided that may be considered a landing page for an e-commerce platform. While it will be understood that the landing page may present the basis for a wide range of interactions with an EBRS host system102, example embodiments contemplated herein may utilize the “trouble codes” hyperlink502. As shown inFIG. 5B, in response to selection of the hyperlink502, the user is presented with a separate interface superimposed on the interface shown inFIG. 5A. This new interface illustrates a historical presentation of recent OBD-II scans of vehicles. The scans may have been performed by the device being used by the user (e.g., retailer device110or third party device112), a peripheral OBD-II scanning device, or additionally or alternatively, the list of recent scans may list scans associated with the consumer's account stored by the EBRS host system102and displayed only if the consumer has logged into the account previously. From this interface, the consumer may select one of the recent scans (in this case, hyperlink504is selected, prompts the generation of another interface, one example of which is shown inFIG. 5C. Specifically, this interface shown inFIG. 5Cpresents the VIN number associated with the vehicle selected fromFIG. 5B, and provides a field for entrance of the vehicle's mileage. Once entered, the consumer may select the “View Report” icon to be provided with a health report, as described in greater detail in connection withFIGS. 6A-6C.

Turning next toFIG. 6A, an example health report is provided. The health report may act as a landing page having selectable hyperlinks directing the consumer to more-detailed pages describing specific information including how-to instructions/videos, job difficulty or complexity information, granular estimates of the time for completion, and part breakdowns and associated costs. As shown inFIG. 6A, the health report may be generated by the EBRS host system102and presented to a user operating either a retailer device110or a third party device112. The health report illustrates vehicle demographic information, followed by diagnostic trouble code (DTC) information, followed by a set of information602describing the problem corresponding to the DTC information, providing engine light status information (e.g., inFIG. 6A, the health report indicates that the check engine light (CEL) is on), and providing scheduled maintenance information based on the received DTC information, VIN, and mileage information received via one or more of the interfaces displayed inFIGS. 5A-5C.

FIG. 6Billustrates some additional example fields that may be included in the health report. Specifically, in addition to overview information, the health report may provide fix information604, which is generated for presentation by the EBRS host system102. In some embodiments, the EBRS platform can provide tiered levels of service that offer a pre-selected package of parts for each repair based on the relative quality and/or cost and/or comprehensiveness of the corresponding fix. For instance, a platinum tier offering may pre-select the highest quality parts and include both the parts and tools required to replace required parts, as well as the parts and tools required to repair all recommended parts. In contrast, a silver tier offering pay pre-select the lowest acceptable quality of parts and may not include the parts and tools that are required only for replacement of recommended parts. The gold tier offering may provide mixture of quality and comprehensiveness in-between the platinum and bronze tiers. Accordingly, by selecting the settings icon606, the user may be provided with another interface such as that shown inFIG. 6C, which presents quality selection menu614and comprehensiveness selection menu622. In the example of quality selection menu614, the user may preselect one of three different quality “tiers” to enable quicker identification of parts for purchase. As shown inFIG. 6C, the platinum quality tier (chosen by selection of radio button616) would correspond to a request for the highest quality part from among any given part type required or recommended for a repair. The gold quality tier (chosen by selection of radio button618) would correspond to a mid-range quality selection preference, and the silver quality tier (chosen by selection of radio button620) would correspond to a preference for the lowest acceptable quality level (e.g., to keep expenses down).

Comprehensiveness menu622may enable a similar type of selection. The EBRS platform may be used to present both required parts for repair as well as a listing of recommended parts for repair. Comprehensiveness menu622allows a user to select which of those recommended parts should be presented by default for purchase. Selection of radio button624defaults the system to place all recommended parts into a user's shopping cart. Selection of radio button624defaults the system to place all recommended parts into a user's shopping cart. Selection of radio button626defaults the system to place only highly-recommended parts into a user's shopping cart (e.g., those parts recommended with a level of urgency greater than some predefined threshold). Selection of radio button628defaults the system to place no recommended parts into a user's shopping cart. Finally, selection of radio button630enables utilization of a drop-down menu enabling the customization of the comprehensiveness selection plan. In this regard, various possible selections within the drop-down menu may enable more granular comprehensiveness selections based upon the type of part recommended, the cost of the part, or the like.

It will be understood that, in some embodiments, only one of menus614and622may be presented, and while the precise manner by which the menus gather input may vary (e.g., rather than radio buttons, a slider may be used to indicate quality or comprehensiveness settings), the underlying goal is to predefine preferences that will be applied in the generation of a health report for the user and/or in presentation of fix information to the user for purchase.

Returning toFIG. 6B, the fix information604may further include several sub-categories of information. For instance, the fix information604may include job complexity information608, DIY cost information610, and DIFM cost information612, all of which may be generated by the EBRS host system102based on information harvested and stored in database106.

The job complexity information may identify an average time to complete the DIY job. This timing information may be predefined based on expert opinions harvested and stored in advance in database106. Alternatively, this timing information may be gathered from consumer survey responses or from clickstream data illustrating the timing of subsequent activity by users after reviewing the DIY job (e.g., after purchasing parts for a first job, a consumer who searches for a separate job 5 hours later may be estimated to have taken under 5 hours to complete the first job). Similarly, the job complexity information608may identify the percentage of consumers who return the parts (roughly illustrating the relative number of consumers who are unable to complete the job). This information may thus be gathered based on statistical analysis of consumer purchasing patterns.

The DIY cost information610may be based on the quality and comprehensiveness tiers identified by the user's settings. For instance, a platinum quality tier DIY cost will assume that the user intends to purchase the highest-quality version of each necessary part type or tool, whereas the silver quality tier DIY cost will be based on a lowest-acceptable quality version of each identified part type or tool. Similarly, depending on the comprehensiveness level selected by the user, the DIY cost may vary because a different percentage of recommended parts may be rolled into the DIY cost for the repair. In some embodiments, the absence of quality and comprehensiveness settings by a consumer may result in the EBRS host system102predefining a default quality tier selection and/or default comprehensiveness selection, or may leave the DIY cost information blank until the user has advanced to the purchasing interface shown inFIG. 7and selected the various parts/tools that the user will purchase.

The DIFM cost information612may also be based on the quality and comprehensiveness tiers in the same way as the DIY cost information610. However, DIFM cost information612also takes into account labor costs. These labor costs may be calculated by the EBRS host system102in several ways. First, the labor costs may be harvested from a third party platform having repair estimates, from a third party platform that crowd-sources repair estimation, or from historical data illustrating past labor costs for a particular repair. Finally, the labor costs may be estimated based on the job complexity information above and the prevailing hourly rate for labor. For instance, given an hourly rate of $100, a five hour complexity estimation might suggest a labor cost estimate of $500 if a mechanic were to perform the repair. In this fashion, DIFM estimates can be based on hard numbers (replacement part purchase price) rather than on arbitrary decision-making.

Turning next toFIG. 7, an example user interface is shown that presents fix information to the consumer. As shown inFIG. 7, the interface may be split into three primary sections: required part information, which contains items702A-702N, recommended part information, which is shown in items704and706, and a “shopping cart,” as shown in item708. Turning first to the required part information, the interface shown inFIG. 7presents a series of possible parts for selection, here labeled702A,702B,702C, and702N to illustrate that there may be any number of possible parts for selection. Each part may correspond to a part type identified as required in the fix information, and there may be many different parts available corresponding to each part type. Once the user selects any given part, all other parts corresponding to the same part type may be grayed-out or removed from the interface (to prevent the user from purchasing duplicative parts).

It should be noted that various elements of the interactive interface may be flexible and organized for presentation in a number of ways based on a variety of factors. For instance, the ordering of the parts may be designed to present the highest priority parts first, followed by parts having lower priority and so forth. To determine which of the presented parts has the highest priority, the EBRS host system102may be designed to evaluate a variety of factors. For instance, the parts may be organized alphabetically or they may be organized by price. Similarly, the parts may be organized according to their inventory levels in various retail locations (e.g., if a consumer is viewing this interface from a retailer device in a store, the parts that are prioritized may be those parts that are available in the store hosting the consumer). Alternatively, however, the prioritization of parts here may be in accordance with vendor-negotiated deals. For instance, if a first vendor negotiates a prioritization deal with the operator of the EBRS host system102, the presentation of parts may prioritize parts provided by the first vendor over parts provided by other suppliers.

Similarly, vendor relationships may dictate the prioritization of some parts falling within a part type above others. Specifically, vendors may negotiate prioritization deals that emphasize certain products over others, even when both are provided by the same vendors (e.g., a vendor negotiates a prioritization deal that prioritizes a new version of a product over an old version of the product). Finally, the prioritization may be crowd-sourced, such that the parts that are prioritized are those that consumers have most frequently selected for purchase, and this frequency determination may in some embodiments take into account the recency of consumer selections (a first part selected 100 times may be prioritized over a second part selected 50 times, although if 75 selections of the first part had occurred over one year ago while all 50 selections of the second part occurred within the last twelve months, the second part may be prioritized over the first part). Similarly, geography may also be taken into account. For instance, although a first tire may be selected far more frequently in Rochester, N.Y., a second tire may be selected more frequently in Miami, Fla., and the geographic element may be important in determining the relative merits of the two parts.

Finally, the prioritization of parts may also be informed by historical rates of part returns (e.g., a part that is frequently returned may be ranked lower than a part that is very rarely returned). In arriving at these determinations, the underlying frequency determination may be based on the purchase histories stored by the EBRS host system102, although it may alternatively be based on clickstream data retrieved during each user's navigation through the interface shown inFIG. 7. For instance, if consumers consistently choose a first part from one vendor over a second part from another vendor (when both fall within the same part type), then the first part may be prioritized or otherwise presented more prominently).

The series of parts shown in item704and part types shown in item706are those products that are not required, but which are recommended for purchase. For instance, if a required part were an oil filter, a recommended replacement part may be an air filter. The list of recommended parts may be prioritized in similar ways as the list of required parts. One difference, however, is that the most highly recommended part type is assigned to item704, and the various parts within that part type can then be prioritized in a similar way as the list of required parts. In contrast, the remaining recommended part types are shown in list form in item706, although the list in item706is not broken down into individual parts available for purchase until the part type is selected by the consumer (at which point the selected part type switches places with the part type shown by item704and constituent parts within the selected part type are shown).

Finally, in item708, a shopping cart may be displayed, along with total cost information and a running total cost.

Turning now toFIGS. 8A-8H, mobile implementations of the EBRS platform are described. As shown inFIG. 8A, when the Check Engine Light (CEL) of a vehicle is detected, that fact may trigger an icon notification802to appear on the icon for a mobile app provided by the EBRS host system102to a retailer device110or third party device112. Upon selection thereafter,FIG. 8Billustrates a landing page for the mobile app, which illustrates a similar icon notification over the “Repair Help” icon806within the mobile app itself. Upon selection of the “Repair Help” icon806or the “Repair Help” menu icon804, the user will be shown an interface such as that provided inFIG. 8F, described below. In another implementation, however, a third party mobile app may be modified to add “fix finder” functionality. In this regard, as shown inFIG. 8C, an icon for the third party mobile app icon may include a trigger notification of this check engine light. Upon selection of the third party app, the third party app may provide its traditional functionality (as shown inFIG. 8D), but will also present a menu option to select a “Fix Finder,” as provided by the EBRS host system102(as shown inFIG. 8E).

Once the “Repair Help” or “Fix Finder” icons are selected, the user may be presented with an interface such as that shown inFIG. 8F. This interface may present drop-down lists for each of a series of part types needed to address the CEL. Parts to complete the job associated with the CEL can be displayed upon selection of each part type (as shown in in items812ofFIG. 8F and 816inFIG. 8G). Moreover, selection of the “Job Info” icon shown inFIGS. 8F and 8Gmay prompt display of an interface corresponding to the health report described previously in connection withFIGS. 6A and 6B. Finally, as shown inFIG. 8H, a shopping cart associated with part selections can presented, enabling the user to order the set of parts from the mobile terminal. In some embodiments, this feature enables users to buy parts for shipment to the user's location or for pickup in store, without having to leave the mobile app.

Having provided an overview of various graphical interfaces that may be utilized by the EBRS platform, specific operations performed by various parties contemplated herein are disclosed below.

Operations Performed by the EBRS Host System

FIGS. 9 and 10illustrate a series of flowcharts that contain operations performed by an EBRS host system102for facilitating a DIY EBRS solution. The operations illustrated inFIGS. 9 and 10may, for example, be performed by, with the assistance of, and/or under the control of an apparatus200embodying an EBRS host system102or a server104that is a part of the EBRS host system102, and more particularly through the use of one or more of processor202, memory204, input/output circuitry206, communications circuitry208, diagnostic circuitry210, and fix finder circuitry212.

Turning first toFIG. 9, a series of operations are illustrated using which the EBRS host system102may generate and present recommendations based on vehicle diagnostic information. In operation902the apparatus200includes means, such as input/output circuitry206, communications circuitry208, or the like, for receiving, by an experience-based repair service (EBRS) host system, vehicle diagnostic information identifying one or more vehicle problems.

In operation904the apparatus200includes means, such as processor202, memory204, diagnostic circuitry210, or the like, for evaluating, by the EBRS host system, the vehicle diagnostic information. Based on the received vehicle diagnostic information, the diagnostic circuitry210is configured to identify the underlying problem (e.g., low fluid level, broken tail light, loss of power steering, etc.). In many embodiments, identification of the problem is performed primarily by using OBD-II diagnostic codes to identify faulty part types. In some embodiments, the vehicle diagnostic information does not merely comprise OBD-II diagnostic codes, but further includes additional vehicle information that can be used separately or in conjunction with vehicle diagnostic codes to identify the underlying issue. For instance, this vehicle diagnostic information may include vehicle telematics information retrieved from a vehicle telematics system, symptoms provided by the customer, and/or historical information regarding repairs of similar vehicles that the diagnostic circuitry210may use to independently confirm the faulty part types. Similarly, the diagnostic circuitry210may perform root cause analysis of the failure of the faulty part types identified by the diagnostic codes, and may utilize historical information from database106, in additional to location information, and/or seasonal information that may be independently derivable.

In operation906the apparatus200includes means, such as processor202, fix finder circuitry212, or the like, for generating, by the EBRS host system and based on the evaluation of the vehicle diagnostic information, required part types and required tools for addressing the one or more vehicle problems. As noted previously, the generation of required part types and required tools may utilize a memory202(e.g., storing database106of the EBRS host system102) that provides curated fix information that identifies the required parts and tools.

In operation908the apparatus200includes means, such as processor202, fix finder circuitry212, or the like, for generating, by the EBRS host system and based on the evaluation of the vehicle diagnostic information, recommended part types for addressing the one or more vehicle problems. As noted previously, the generation of recommended part types may utilize a memory202(e.g., storing database106of the EBRS host system102) that provides curated fix information that can be referenced to identify not only the required parts and tools, but additional parts that may be useful to replace assuming that the required parts are being replaced. For instance, if access to one part also provides easy access to another part that is not broken, it still may be worth replacing both parts at that time.

In operation910the apparatus200includes means, such as input/output circuitry206, communications circuitry208, or the like, for causing presentation of an interface facilitating purchase of required parts from each of the generated required part types, the required tools, and recommended parts from each of the generated recommended part types. In some embodiments, the retailer may offer a “loaner tool” program providing a consumer with access needed tools without the requirement to purchase those tools outright. In such embodiments, the interface facilitating purchase of the required parts may offer the options to purchase or to rent any relevant loaner tool. Moreover, in some embodiments, the interface may also present an offer of a bulk discount if the consumer purchase all required parts as well as all recommended parts. In some embodiments, the apparatus200may further include means, such as processor202, fix finder circuitry212, or the like, for generating complexity information relating to each of the one or more vehicle problems, wherein the complexity information identifies an estimated time period needed to complete repair of each of the one or more vehicle problems. In such embodiments, the interface facilitating purchase may further include the generated complexity information. It should be understood that generating complexity information may be done in a number of ways.

In some example embodiments, generating complexity information relating to a vehicle problem includes retrieving, by the EBRS host system, historical information regarding frequency of returns of parts and tools associated with the vehicle problem, and assigning a level of complexity to the vehicle problem based on the frequency of returns.

In other embodiments, generating the complexity information includes calculating an estimated time to fix the vehicle problem. This estimated time to fix the vehicle problem, in turn, may be performed by the apparatus200by retrieving historical information regarding time periods until subsequent activity by consumers having purchased parts relating to the vehicle problem, and averaging the time periods until the subsequent activity, wherein the estimated time to fix the vehicle problem is based on the averaging of the time periods until the subsequent activity. This historical information may in some embodiments include vehicle diagnostic information retrieved from vehicles that identifies when the vehicle problems are fixed. Alternatively, calculating the estimated time to fix the vehicle problem may include causing dissemination of customer surveys corresponding to vehicle problems after each purchase, wherein the customer surveys request information regarding the estimated time to fix the vehicle problem, and receiving, by the EBRS host system, consumer responses to the customer surveys, wherein the estimated time to fix the vehicle problem is based on the received consumer responses.

Another aspect of the interface facilitating purchase of required parts, the required tools, and recommended parts is that the presentation can be tailored to the particular desires of a given consumer. As one example, the apparatus200may further includes means, such as input/output circuitry206, communications circuitry208, or the like, for causing presentation of an interface facilitating selection from a plurality of quality tiers, and receiving selection of a quality tier from the plurality of quality tiers. Prioritization of the required parts from each of the generated required part types and the recommended parts from each of the generated recommended part types may then be based on the selected quality tier. As another example, the apparatus200may further includes means, such as input/output circuitry206, communications circuitry208, or the like, for causing presentation of an interface facilitating selection from a plurality of comprehensiveness tiers, and receiving, by the EBRS host system, selection of a comprehensiveness tier from the plurality of comprehensiveness tiers. The recommended part types can then be generated based on the selected comprehensiveness tier.

It should be understood that the EBRS platform can be implemented by software operated by the EBRS host system102, or can be implemented via an API from third party applications. In such embodiments, the apparatus200may cause the presentation of the interface facilitating purchase of the required parts, the required tools, and the recommended parts in response to receiving an API call from a third party application.

Another element of the interface facilitating purchase of required parts, the required tools, and recommended parts is that the presentation of individual parts falling within any given part type can be tailored in a number of ways. For instance, the apparatus200may further includes means, such as processor202, fix finder circuitry212, or the like, for identifying orders of priority of the required parts and the recommended parts, wherein causing presentation of the interface facilitating purchase of the required parts, the required tools, and the recommended parts includes causing presentation of the required parts and the recommended parts in the corresponding orders of priority. In such embodiments, the order of priority of the required parts and the recommended parts are based on one or more of: price, inventory levels, vendor-negotiated deals, geography, or historical rates of part returns, as described previously.

Turning next toFIG. 10, a series of operations are illustrated using which the EBRS host system102may determine the effectiveness of suggested repairs. In operation1002, the apparatus200includes means, such as input/output circuitry206, communications circuitry208, or the like, for receiving, by the EBRS host system, vehicle diagnostic information after making repairs recommended by the EBRS host system to address one or more vehicle problems.

In operation1004, the apparatus200includes means, such as processor202, memory204, diagnostic circuitry210, or the like, for determining, by the EBRS host system and based on the vehicle diagnostic information, whether any vehicle problems exist and/or what problems exist. This operation may in some embodiments be similar to operation904, described previously. For instance, the diagnostic circuitry210may be configured to determine, based on the received vehicle diagnostic information, whether any vehicle problems exist, and identify, if any problem is detected, the underlying problem (e.g., low fluid level, broken tail light, loss of power steering, etc.). In many embodiments, identification of the problem is performed primarily by using OBD-II diagnostic codes to identify faulty part types. In some embodiments, however, the vehicle diagnostic information supplements the OBD-II diagnostic codes with additional vehicle diagnostic information that can be used to separately identify the underlying issue or to refine the identification of the underlying issue. For instance, the vehicle diagnostic information may include information retrieved from a vehicle telematics system, symptoms provided by the customer, and/or historical information regarding repairs of similar vehicles that the diagnostic circuitry210may use to independently confirm the faulty part types. Similarly, the diagnostic circuitry210may perform root cause analysis of the failure of the faulty part types identified by the diagnostic codes, and may utilize historical information from database106, in additional to location information, and/or seasonal information that may be independently derivable. From operation1004, the procedure may advance to optional operations1006,1008, and1010in embodiments utilizing a survey, or may instead advance directly to operation1012for processing of the vehicle problems that have been identified in operation1004alone.

To perform optional operation1006, the apparatus200may include means, such as input/output circuitry206, communications circuitry208, or the like, for transmitting, by the EBRS host system, a survey to gather input regarding vehicle problems from a user. The survey may provide a separate path for discovery of problems and/or more granular detail regarding solutions to the problems previously identified by the EBRS system. The survey may be presented as an interface allowing the user providing various feedback information. In some embodiments, the survey may ask the user if all previously identified problems have been addressed by the repairs recommended by the EBRS host system, and/or allow the user to identify new problems that may have been caused by making the repairs. Moreover, in some embodiments, the survey may provide an interface for the user to provide a granular indication regarding each problem that was supposed to be fixed, as well as each new problem that may have been caused by making the repairs. In this regard, the survey may request that the user indicate, in an instance in which a problem has been fixed, whether the problem was fixed by the repair recommended by the EBRS host system, how the problem was fixed if it was not fixed by the repair recommended by the EBRS host system, or if the problem has not been fixed at all.

To perform optional operation1008, which may be performed in response to the transmission of a survey in optional operation1006, the apparatus200includes means, such as input/output circuitry206, communications circuitry208, or the like, for receiving, by the EBRS host system, feedback from the user in response to transmission of the user survey.

From operation1008, the procedure may advance to optional operation1010, in which the apparatus200includes means, such as processor202, memory204, diagnostic circuitry210, or the like, for determining, by the EBRS host system and based on the user feedback, whether any vehicle problems exist and/or what problems exist. Accordingly, in addition to identifying problems based on the vehicle diagnostic information described in operation1004, the procedure illustrated inFIG. 10may optionally also utilize the feedback from the user via the steps described in operations1006,1008, and1010. It should be understood that operations1006,1008, and1010may be performed even if operations1002and1004are performed, and in such embodiments, a survey will provide the sole mechanism for evaluating the effects of the repairs, a second interrogation of a vehicle OBD-II port need not be performed.

Finally, from either of operations1004or1010above, the procedure may advance to operation1012, in which the apparatus200includes means, such as processor202, memory204, diagnostic circuitry210, or the like, for storing, by the EBRS host system, an indication of one or more effects of the repairs. To facilitate performance of this storage operation, the apparatus200may include means, such as processor202, memory204, diagnostic circuitry210, or the like, for generating an indication of the one or more effects of the repairs based on the determinations of whether vehicle problems exist provided from either or both of operations1004and1010. Generating the one or more effects of the vehicle repair may include comparing the set of problems identified previously by the EBRS host system to the set of vehicle problems identified after completion of the repair. Moreover, the one or more effects of the vehicle repair may further utilize the more granular information contained in the feedback from the user in operation1008to pinpoint which previously identified vehicle problems were addressed by repairs recommended by the EBRS host system, and if multiple problems were fully addressed, which vehicle problem was address by which repair. The effects of the repairs may further provide an indication of whether the repairs appear to have introduced any new problems. By storing the effects of the repairs, future repair recommendations can be modified to maximize the effectiveness of the repair suggestions provided by the EBRS host system.

Operations Performed by a Retailer Device or a Third Party Device

Turning now toFIGS. 11 and 12, flowcharts are illustrated that contains a series of operations performed by a retailer device110or by a third party device112. In embodiments where the operations illustrated inFIGS. 11 and 12are performed by a retailer device110, the operations may, for example, be performed by, with the assistance of, and/or under the control of apparatus300embodying a third party device110, and more particularly through the use of one or more of processor302, memory304, input/output circuitry306, communications circuitry308, or OBD-II scanning circuitry310. It will be understood that the operations illustrated inFIGS. 11 and 12can also be performed by a third party device112, in which case the operations may, for example, be performed by, with the assistance of, and/or under the control of corresponding features of the apparatus400.

Turning toFIG. 11, a series of operations are illustrated using which a retailer device110or third party device112may retrieve repair recommendations and facilitate purchase of corresponding parts. In operation1102, the apparatus300includes means, such as memory304, input/output circuitry306, communications circuitry308, OBD-II scanning circuitry310, or the like, for receiving vehicle diagnostic information identifying one or more vehicle problems. In some embodiments, this operation may include receiving, via communications circuitry, diagnostic trouble codes from an external OBD-II scanner. In some embodiments, this external OBD-II scanner may comprise a loaner device provided by the retailer that a consumer or retailer agent can use to interrogate the consumer's vehicle. In other embodiments, this may include receiving the diagnostic trouble codes directly from a vehicle via OBD-II scanning circuitry310. Finally, this operation may include receiving user input (e.g., via input/output circuitry306) or receiving the vehicle diagnostic information from a historical database stored by memory304(or retrieved, via communications circuitry308, from an external memory such as database106.)

In operation1104, the apparatus300includes means, such as communications circuitry308or the like, for transmitting the received vehicle diagnostic information to an EBRS host system.

In operation1106, the apparatus300includes means, such as communications circuitry308or the like, for receiving, from the EBRS host system, required part types and required tools for addressing the one or more vehicle problems.

In operation1108, the apparatus300includes means, such as communications circuitry308or the like, for receiving, from the EBRS host system, recommended part types for addressing the one or more vehicle problems.

In operation1110the apparatus300includes means, such as processor302, communications circuitry308, or the like, for causing presentation of an interface facilitating purchase of required parts from each of the generated required part types, the required tools, and recommended parts from each of the generated recommended part types. It should be understood that the operation1110may further include means, such as communications circuitry308, or the like, for receiving, from the EBRS host system, complexity information relating to each of the one or more vehicle problems, wherein the complexity information identifies an estimated time period needed to complete repair of each of the one or more vehicle problems; and means, such as processor302, communications circuitry308, or the like, for causing presentation of the generated complexity information. In such embodiments, the complexity information relating to a vehicle problem may include a level of complexity to the vehicle problem based on the frequency of returns. Additionally or alternatively, the complexity information relating to a vehicle problem includes an estimated time to fix the vehicle problem. This estimated time to fix the vehicle problem, in turn, may be calculated by the apparatus300by retrieving historical information regarding time periods until subsequent activity by consumers having purchased parts relating to the vehicle problem, and averaging the time periods until the subsequent activity, wherein the estimated time to fix the vehicle problem is based on the averaging of the time periods until the subsequent activity. This historical information may include vehicle diagnostic information retrieved from vehicles that identifies when the vehicle problems are fixed. Alternatively, calculating the estimated time to fix the vehicle problem may include causing dissemination of customer surveys corresponding to vehicle problems after each purchase, wherein the customer surveys request information regarding the estimated time to fix the vehicle problem, and receiving, by the EBRS host system, consumer responses to the customer surveys, wherein the estimated time to fix the vehicle problem is based on the received consumer responses.

In some embodiments, operation1110may further include means, such as input/output circuitry306, communications circuitry308, or the like, for causing presentation of an interface facilitating selection from a plurality of quality tiers, receiving selection of a quality tier from the plurality of quality tiers, and transmitting the selected quality tier to the EBRS host system. Similarly, in some embodiments, operation1110may further include means, such as input/output circuitry306, communications circuitry308, or the like, for causing presentation of an interface facilitating selection from a plurality of comprehensiveness tiers, receiving selection of a comprehensiveness tier from the plurality of comprehensiveness tiers, and transmitting the selected comprehensiveness tier to the EBRS host system.

Turning toFIG. 12, a series of operations are illustrated using which a retailer device110or third party device112may facilitate the determination of the effectiveness of suggested repairs. In operation1202, the apparatus300includes means, such as memory304, input/output circuitry306, communications circuitry308, OBD-II scanning circuitry310, or the like, for receiving vehicle diagnostic information after making repairs recommended by an EBRS host system to address one or more vehicle problems. In some embodiments, this operation may include receiving, via communications circuitry, diagnostic trouble codes from an external OBD-II scanner. In some embodiments, this external OBD-II scanner may comprise a loaner device provided by the retailer that a consumer or retailer agent can use to interrogate the consumer's vehicle. In other embodiments, this may include receiving the diagnostic trouble codes directly from a vehicle via OBD-II scanning circuitry310. Finally, this operation may include receiving user input (e.g., via input/output circuitry306) or receiving the vehicle diagnostic information from a historical database stored by memory304(or retrieved, via communications circuitry308, from an external memory such as database106).

In operation1204, the apparatus300includes means, such as communications circuitry308or the like, for transmitting the received vehicle diagnostic information to an EBRS host system.

In optional operation1206, the apparatus300may include means, such as communications circuitry308or the like, for receiving, from the EBRS host system, a survey to gather user input regarding vehicle problems.

In response to operation1206, the procedure may advance to optional operation1208, in which the apparatus300includes means, such as processor302, communications circuitry308, or the like, for causing presentation of an interface facilitating collection of user feedback regarding vehicle problems. The user feedback to be collected may include information such as if all vehicle problems are addressed by the repairs recommended by the EBRS host system, if new problems may have been caused by making the repairs, if each problem has been fixed by the repair recommended by the EBRS host system, and/or how the problem is fixed if it is not fixed by the repair recommended by the EBRS host system.

In operation1210, the apparatus300includes means, such as input/output circuitry306, communications circuitry308, or the like, for transmitting the user feedback to the EBRS host system. It should be understood that operations1206,1208, and1210are designated as optional because some embodiments of the procedure described inFIG. 12may not involve a survey and may instead rely purely on updated vehicle diagnostic information that may be gathered in accordance with operation1202above. However, it should be understood that operations1206,1208, and1210may be performed even if operations1202and1204are not, and in such embodiments, a survey will provide the sole mechanism facilitating the determination of the effects of the repairs, and a second interrogation of is not performed.

As described above, example embodiments disclosed herein provide an EBRS platform for facilitating Do-It-Yourself (DIY) repairs. The EBRS platform provides consumers with the information necessary to evaluate the costs and requirements of repairing damage to vehicles and to facilitate a DIY EBRS solution. Moreover, example embodiments enable consumers to evaluate the complexity of the repair and evaluate the merits of making additional recommended repairs at the same time. Furthermore, by facilitating the purchase of the necessary and recommended parts and tools, the EBRS platform enables one-stop shopping without the hassle of multiple rounds of purchasing based on the discovery, during repair, of newly required parts or tools. Finally, by collecting the closed-loop feedback information, the EBRS platform can continually update the vehicle problems and appropriate repairs, which enables continual improvement the service and recommendations provided to consumers in the future.

In some embodiments, some of the operations above may be modified or further amplified. Furthermore, in some embodiments, additional optional operations may be included. Modifications, amplifications, or additions to the operations above may be performed in any order and in any combination.