EP2646969A2 - System and method for obtaining competitive pricing for vehicle services - Google Patents
System and method for obtaining competitive pricing for vehicle servicesInfo
- Publication number
- EP2646969A2 EP2646969A2 EP11845242.4A EP11845242A EP2646969A2 EP 2646969 A2 EP2646969 A2 EP 2646969A2 EP 11845242 A EP11845242 A EP 11845242A EP 2646969 A2 EP2646969 A2 EP 2646969A2
- Authority
- EP
- European Patent Office
- Prior art keywords
- vehicle
- vendor
- service
- data
- pricing
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Ceased
Links
- 238000000034 method Methods 0.000 title claims description 101
- 230000002860 competitive effect Effects 0.000 title claims description 8
- 238000012544 monitoring process Methods 0.000 claims abstract description 235
- 230000002441 reversible effect Effects 0.000 claims abstract description 79
- 230000004044 response Effects 0.000 claims abstract description 24
- 230000006870 function Effects 0.000 claims description 70
- 238000003745 diagnosis Methods 0.000 claims description 46
- 230000015654 memory Effects 0.000 claims description 39
- 238000004891 communication Methods 0.000 claims description 32
- 238000004458 analytical method Methods 0.000 claims description 13
- 230000001413 cellular effect Effects 0.000 claims description 10
- 230000008439 repair process Effects 0.000 abstract description 223
- 238000007689 inspection Methods 0.000 abstract description 13
- 230000005540 biological transmission Effects 0.000 description 80
- 238000013480 data collection Methods 0.000 description 22
- 230000000670 limiting effect Effects 0.000 description 21
- 238000010586 diagram Methods 0.000 description 16
- 238000012545 processing Methods 0.000 description 11
- 239000000446 fuel Substances 0.000 description 8
- 238000012423 maintenance Methods 0.000 description 8
- 239000003921 oil Substances 0.000 description 8
- 238000013459 approach Methods 0.000 description 7
- 230000005055 memory storage Effects 0.000 description 7
- QVGXLLKOCUKJST-UHFFFAOYSA-N atomic oxygen Chemical compound [O] QVGXLLKOCUKJST-UHFFFAOYSA-N 0.000 description 6
- 229910052760 oxygen Inorganic materials 0.000 description 6
- 239000001301 oxygen Substances 0.000 description 6
- 238000012552 review Methods 0.000 description 6
- 230000008859 change Effects 0.000 description 5
- 238000001514 detection method Methods 0.000 description 5
- 230000003993 interaction Effects 0.000 description 5
- 238000012986 modification Methods 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 238000001816 cooling Methods 0.000 description 4
- 230000002547 anomalous effect Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 3
- 239000002826 coolant Substances 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 230000002159 abnormal effect Effects 0.000 description 2
- 230000009471 action Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000012774 diagnostic algorithm Methods 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 238000002347 injection Methods 0.000 description 2
- 239000007924 injection Substances 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 230000006403 short-term memory Effects 0.000 description 2
- 238000012384 transportation and delivery Methods 0.000 description 2
- 238000013024 troubleshooting Methods 0.000 description 2
- 230000000007 visual effect Effects 0.000 description 2
- 230000004913 activation Effects 0.000 description 1
- 238000007405 data analysis Methods 0.000 description 1
- 238000013481 data capture Methods 0.000 description 1
- 238000013479 data entry Methods 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000002950 deficient Effects 0.000 description 1
- 230000009365 direct transmission Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000001747 exhibiting effect Effects 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 239000010705 motor oil Substances 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000010422 painting Methods 0.000 description 1
- 230000036961 partial effect Effects 0.000 description 1
- 230000008447 perception Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000002265 prevention Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000035807 sensation Effects 0.000 description 1
- 238000011179 visual inspection Methods 0.000 description 1
- 230000016776 visual perception Effects 0.000 description 1
- 238000012800 visualization Methods 0.000 description 1
- 230000001755 vocal effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/20—Administration of product repair or maintenance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/01—Customer relationship services
- G06Q30/015—Providing customer assistance, e.g. assisting a customer within a business location or via helpdesk
- G06Q30/016—After-sales
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/08—Auctions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
- G06Q50/40—Business processes related to the transportation industry
Definitions
- Vehicle owners including individual consumers and fleet operators, have many choices for acquiring services for their vehicles.
- Such services can include, but are not limited to, routine maintenance, diagnosis and repair of fault conditions, and replacement of consumable items, such as engine oil, coolant, brakes and tires. Selecting an appropriate vendor is often a time consuming endeavor.
- Much of the data collected by the data collection components is used to control the operation of the vehicle.
- data collected by oxygen sensors is used to control the amount of fuel introduced into the engine, to avoid providing an overly rich fuel mixture that would result in decreased fuel efficiency and increased emissions.
- Operational data encompasses data that is used to control the operation of the vehicle, such as the data from oxygen sensors, as noted above.
- operational data is not stored, but rather generated, contemporaneously used as necessary to control various vehicular systems (such as a fuel injection system, a cooling system, and/or a braking system), and then discarded.
- Exemplary operational data include, but is not limited to, engine coolant temperature, engine speed, oxygen levels, throttle position, brake temperature, vehicle speed, brake position, and gearbox parameters. Much of this data is collected very frequently. Indeed, some types of operational data are collected multiple times per second. The sheer quantity of operational data being generated makes storing or archiving all of the operational data problematical.
- the service shop that is selected to repair a vehicle or further diagnose problems observed by an operator is selected either based on past knowledge of the service shop vendor, or by referral from someone who has experience with the service shop, or by randomly selecting a service vendor from a list such as provided in telephone listings or on the Internet. While an operator or owner of a vehicle may call to inquire about repair estimates, the decision to use a specific repair service vendor is often based on incomplete data, and may not represent the best choice from the available repair service vendors near a desired location for the repair or maintenance service.
- the vehicle operator or owner would benefit from being provided with a more complete list of the suitable and cost effective repair facilities available near a vehicle's location to perform the required servicing. It would also be desirable to provide the operator of the vehicle with the cost charged by each such repair/service vendor for performing the required repair or maintenance. Further, it would be desirable to obtain the lowest costs at which each such vendor is willing to perform the repair task. It would also be desirable to provide vehicle operators with well defined service needs (new tires, oils changes, etc.) with similar information on suitable vendors.
- the concepts disclosed herein encompass determining the service needs of a particular vehicle, contacting a plurality of suitable vendors to obtain pricing data for the service, and providing the operator of the vehicle with the pricing data obtained from the vendors.
- one or more of the following types of additional information for each vendor will be provided along with the pricing data, to enable the consumer (the owner or operator of the vehicle) to make an informed selection: a rating of the vendor, a relative distance between the consumer (or known vehicle location) and the vendor, and a time period defining when the vendor will be able to accommodate the service.
- a pricing service provider hosts a reverse auction for the benefit of the consumer.
- the pricing service provider hosts a webpage upon which results of the service requests from the plurality of vendors are displayed.
- the consumer will know exactly what services are required. For example, a particular consumer may need new tires for their vehicle, or may need their oil changed.
- the consumer conveys a service request that specifically defines the required service to the pricing service provider, who in turn conveys the specific, well defined service request to the plurality of vendors, to obtain pricing data for the consumer.
- the consumer may understand there is a problem with the vehicle, but may not know exactly what service is required.
- the concepts disclosed herein encompass embodiments in which the pricing service provider acquires vehicle performance data from the specific vehicle, and that vehicle performance data is used to determine the specific service that is required.
- the diagnosis of the vehicle performance data can be performed by a third party, by the pricing service provider, or by each vendor providing a price quote, as well as combinations and permutations thereof.
- the vehicle performance data is acquired by the consumer and conveyed to the pricing service provider along with a request for service.
- Low cost diagnostic units capable of extracting fault code data and other vehicle performance data from vehicles are increasingly available.
- individual consumers use such equipment to transfer vehicle performance data to their smart phones, and such data is then conveyed to the pricing service provider.
- Vehicle manufactures are also increasingly collecting and storing vehicle performance data from vehicles they manufacture and sell. Manufactures such as General Motors, Ford, and Hyundai each have varying abilities to collect vehicle performance data.
- the concepts disclosed herein encompass conveying vehicle performance data collected by such third parties to a pricing service provider to be used for the purpose of acquiring pricing information for the required service.
- There also exist vendors who install after market data collection components in vehicles such data collection components can be integrated into or logically coupled with position tracking components), and the concepts disclosed herein encompass conveying vehicle performance data collected by such monitoring service vendors to the pricing service provider to be used for the purpose of acquiring pricing information for the required service.
- the pricing service provider also collects and archives vehicle performance data collected from the vehicle on a regular basis (thus, the monitoring service and the pricing service provider are the same entity).
- the concepts disclosed herein also encompass embodiments where the consumer does not yet know that their vehicle requires service, but a third party who collects and monitors vehicle performance data collected from the consumer's vehicle on a regular basis detects a problem with the vehicle (a current fault condition or a developing fault condition) by analyzing the vehicle performance data collected from the consumer's vehicle. The third party then contacts the pricing service provider (noting that in some embodiments the monitoring party and the pricing service provider are the same entity) for obtaining pricing data for the required service. As discussed above, the pricing service provider collects pricing data from a plurality of vendors, and then conveys that pricing data either directly to the vehicle operator, or to the third party monitoring service, who in turn contacts the vehicle operator.
- data is collected from a vehicle and used to diagnose any mechanical or electrical problems with the vehicle, quotes for the required repair are acquired from a plurality of vendors, and the pricing data is provided to the operator of the vehicle.
- the repair costs are determined in a reverse auction, where vendors compete for the opportunity to repair the diagnosed problem by making bids for the costs that will be incurred if they provide the required service; however, it will be understood that non-binding repair quotes can alternatively be solicited from repair vendors who are interested in repairing the vehicle.
- a reverse auction is a type of auction in which the roles of buyers and sellers are reversed.
- reverse auction In an ordinary auction (also known as a forward auction), buyers compete to obtain a good or service, and the price typically increases over time. In a reverse auction, sellers compete to obtain business, and prices typically decrease over time. It should be understood that the reverse auction embodiment is not limited to embodiments where vehicle performance data is used to diagnose the service needed, but that the reverse auction technique can also be applied to embodiments where the consumer knows what service is required (i.e., new tires, an oil change, or the repair of a previously diagnosed condition).
- the bids are requested in a reverse auction style format, where the vehicle repair providers bid on the job, which tends to reduce the costs bid by successive bidders.
- the pricing service vendor then makes the diagnosis and the reverse auction bid results available to the vehicle operator, the monitoring service vendor, or both.
- the vehicle monitoring service and the pricing service provider are the same entity, although it should be recognized that the concepts disclosed herein also specifically encompass embodiments in which the vehicle monitoring service and the pricing service provider are different entities.
- “operator” and “vehicle operator” are intended to encompass the party actually operating a vehicle, as well as the owner of the vehicle, and/or the person or persons responsible for ensuring that vehicles are maintained.
- a fleet of vehicles may be owned by a person, a company, or a corporate entity, and each of these entities is encompassed by the term vehicle owner and/or vehicle operator.
- the owner may employ one or more other persons to be responsible for ensuring that the vehicles are repaired or maintained using a vehicle repair vendor selected by that person or by the owner, and such one or more other persons are also encompassed by the terms operator and/or vehicle operator.
- the term consumer is used refer to the party requesting the pricing data from the pricing service provider, who can be the vehicle operator and/or the monitoring service.
- the pricing service provider charges vehicle operators a subscription fee (the pricing service may be bundled with additional services, including but not limiting to the monitoring service discussed above).
- the pricing service provider charges the service facility that wins the reverse auction (or whose non-binding or binding quote is selected) and provides the repair service a fee. It should also be understood that a third party may be tasked with carrying out the reverse auction on behalf the vehicle owner, and/or the monitoring service.
- the fee to the repair facility may be a flat fee or a percentage of the repair costs.
- the diagnosis data and the reverse auction data are available to vehicle operators and providers of vehicle repair services over the Internet.
- the pricing service provider hosts a website that is accessible to vehicle operators and (in some embodiments) providers of vehicle repair services.
- the pricing service provider prequalifies providers of vehicle repair services, to ensure that each provider participating in the reverse auction is qualified to perform the requested repair.
- the vehicle monitoring service vendor and/or pricing service provider prequalifies vehicle operators, to ensure that vehicle operator is able to pay for the requested repair/service.
- the requested repair must be scheduled through the vehicle monitoring service vendor and/or pricing service provider, to prevent providers of vehicle repair services and vehicle operators, introduced through the vehicle monitoring service vendor or pricing service provider, from making side agreements for the requested repair that deny the vehicle monitoring service vendor/pricing service provider a fee earned for facilitating the transaction between the service vendor and the vehicle operator.
- the vehicle monitoring service pays the repair vendor, and bills the vehicle operator.
- the vehicle monitoring service may also pay the pricing service provider to conduct the reverse auctions.
- the pricing service provider pays the repair vendor, and bills the vehicle operator or the vehicle monitoring service.
- the location of the vehicle varies over time, and the pricing service provider prequalifies providers of vehicle repair services according to the current location of the operator's vehicle (i.e., providers of vehicle repair services who are located beyond a predefined distance are not allowed to bid in the reverse auction).
- the pricing service provider will have access to that information when the pricing service provider and the monitoring service are the same entity. Where the pricing service provider and the monitoring service are not the same entity, the pricing service provider can obtain the vehicle location from the monitoring service, and/or the vehicle operator.
- vehicle operators can define, or redefine, the predefined distance.
- vehicle operators can define a desired location for the repair (for example, a vehicle may be en route to a specific destination, and the vehicle operator can define that destination so that repair costs from vendors at the destination can bid on the repair).
- the current location of the vehicle may be determined by a GPS receiver disposed on the vehicle and will then enable the current location of the vehicle to be the basis for determining the desired location for the repair to be carried out.
- the current location will be appropriately the desired location for the repair.
- other types of vehicle faults and conditions that are diagnosed will be for less critical repairs that can be deferred until the vehicle is at a different location in its route, or has returned to its home base.
- the vehicle monitoring service will be aware of the current location and can have access to the route information of each vehicle it is monitoring, so it will be able to determine the desired location based on that information and the type and criticality of the repair to be performed.
- the operator of the vehicle can communicate with the vehicle monitoring service or pricing service provider to advise of the vehicle's planned route or to make changes in a predefined route.
- the vehicle monitoring service vendor collects data from enrolled vehicles in real-time. In some embodiments, the vehicle monitoring service vendor collects fault code data from enrolled vehicles, and uses the fault code data to monitor the vehicle, and determine if a repair is required. In a particularly preferred embodiment, the vehicle monitoring service vendor collects fault code data and non-fault code based performance from enrolled vehicles in real-time, and uses the fault code data and the performance data to monitor the vehicle, and determine if a repair is required. In at least one embodiment, the amount of performance data collected increases when a fault code is detected. In some exemplary embodiments, the vehicle may alert the operator of a problem requiring repair with a warning on the instrument panel in the vehicle.
- the operator can then transmit a request for automatically obtaining quotes to complete the repair from interested service vendors to the monitoring service, which can respond (or use a third party) to obtain the quotes or conduct a reverse auction to determine the costs for each interested service vendor to complete the desired repair.
- the operator can select a desired service vendor to complete the repair from among the quotes submitted by the service vendors interested in doing the repair work, or from the bids provided by the service vendors participating in the reverse auction.
- the information about the vehicle provided to the repair vendors is sufficiently detailed such that repair vendors can feel confident of the services required, so that such repair vendors will be able to more aggressively compete for business (i.e., the repair vendors will feel more confident in offering their lowest possible price for the repair, without being concerned that the diagnosis is too vague to enable their best price to be offered).
- the data provided to the repair vendors will be from a recognized diagnostic software application known to repair vendors, who have come to trust the results provided by such an application.
- Such diagnostic software applications use many types of data (including but not limited to fault code data, vehicle sensor data, the vehicle identification number (VIN), the firmware version of the vehicle computer, details about the specific transmission with which the vehicle is equipped, and details about the specific engine with which the vehicle is equipped) to arrive at a detailed diagnosis.
- the monitoring service will input the required data in a diagnostic package of their own choosing, while in other embodiments the monitoring service will forward the raw data to the repair vendors who will input the required data in a diagnostic package of the repair vendor's choosing.
- Using a well-known or trusted diagnostic software application will likely encourage repair vendors to provide better pricing. Vendors such as Navistar, Detroit Diesel, and Snap-on Tools offer such diagnostic software applications.
- the vehicle is configured to transmit data to the remote server at various intervals, and at each interval, the vehicle will transmit data including position data and vehicle performance data to the remote server (however, the concepts disclosed herein also encompass embodiments where performance data is transmitted without position data).
- the quantity of performance data to be transmitted can be varied. The more performance data that is conveyed from the vehicle to the remote server operated by the monitoring service, the more likely the remote server will be able to accurately identify mechanical faults. However, as the volume of performance data transmitted from the vehicle to the remote server increases, the required computing resources increases, and transmission related costs can increase.
- a relatively small amount of performance data is transmitted to the remote server at each transmission interval.
- the type of data transmitted at each interval can be varied (for example, injector data is included in a first transmission, oxygen sensor data is included in a second transmission, brake sensor data is included in a third transmission, and so on until many different types of performance data are conveyed to the remote server over time).
- the remote server is configured to request specific types of performance data (i.e., data from specific sensors) to aid in identifying a particular mechanical fault.
- the vehicle transmits data to the remote server each time the vehicle changes heading. In at least one embodiment, the vehicle transmits data to the remote server at predefined time intervals. In at least one embodiment, the vehicle transmits data to the remote server each time a fault code is generated in the vehicle. In at least one embodiment, the vehicle transmits data to the remote server each time a vehicle sensor acquires a reading that varies from a predetermined threshold, even if no fault code is generated. In at least one embodiment, the vehicle transmits position data to the remote server each time performance data or fault code data is conveyed to the remote server.
- the performance data and fault code data are conveyed to the remote server immediately upon being generated by the vehicle's system and without being logged based on priority, although it is contemplated that other approaches might be used, such as time schedules or type of fault code being used to determine when the data are transmitted.
- the concepts disclosed herein also encompasses machine instructions stored on a non-transitory memory medium, which when executed by a processor implement one or more of the methods disclosed herein, and systems for implementing the disclosed methods.
- the basic elements include a computing device remote from the vehicle that implements the functions of monitoring the performance data from the vehicle to identify a fault, automatically contacting vendors to acquire repair costs (either through a reverse auction or simple price request), and automatically contacting the vehicle operator (either the driver or a fleet manager) to inform the operator of the fault and the repair costs/repair options.
- computing device encompasses computing environments including multiple processors and memory storage devices, where certain functions are implemented on different ones of the multiple processors.
- computing device not only encompasses single desktop and laptop computers, but also networked computers, including servers and clients, in private networks or as part of the Internet.
- the data being processed can be stored by one element in such a network, retrieved for review by another element in the network, and analyzed by yet another element in the network.
- a vehicle operator can access the reverse auction network (i.e., the pricing service provider discussed above) using a hand held portable computing device, such as a smart phone.
- the smart phone embodiment specifically is intended to encompass individual consumers seeking to obtain repair services for their personal vehicles (although fleet operators may also choose to utilize such an embodiment).
- the smart phone embodiment specifically includes the ability to have the vehicle operator use the smart phone to convey information regarding the requested service to the pricing service provider (or in some embodiments, to a vehicle monitoring service, if no consumer/vendor relationship exists between the consumer and the pricing service provider, but such a relationship exists between the consumer and the vehicle monitoring service).
- the consumer uses their smart phone to access a reverse auction network hosted by the pricing service provider. This embodiment enables the services of the pricing service provider to be accessible to vehicle owners whose vehicles are not equipped to send vehicle data to a vehicle monitoring service.
- the smart phone embodiment also encompasses vehicles that are equipped to send vehicle performance data to a vehicle monitoring service, generally as discussed above. Due to the limitations of the displays and processing power available to smart phones relative to desktop and laptop computers, the vehicle monitoring service and/or pricing service provider can provide pricing data and service vendor information to the consumer in a format suitable for display on smaller screens.
- the smart phone embodiment specifically encompasses embodiments in which the consumer specifically defines the desired service (and no vehicle performance data is included in the pricing request), as well as embodiments where the smart phone user includes vehicle performance data they extract from their vehicle.
- FIGURE 1A is a high level functional block diagram illustrating the various inputs that can be received by a pricing service provider, who in response to an input will send a pricing request to a plurality of service vendors;
- FIGURE 1C is a high level flow chart showing the overall method steps implemented in accord with one aspect of the concepts disclosed herein, where a consumer suspects that a specific vehicle needs servicing, but does not understand what specific service is required, and that consumer wants a pricing service provider to obtain pricing data for the vehicle service;
- FIGURE ID is a high level flow chart showing the overall method steps implemented in accord with one aspect of the concepts disclosed herein, where a consumer enrolled in a monitoring service (the monitoring service collecting and storing vehicle performance data for the consumer's vehicle) suspects that a specific vehicle needs servicing, but does not understand what specific service is required, and that consumer wants a pricing service provider to obtain pricing data for the vehicle service;
- FIGURE IE is a high level flow chart showing the overall method steps implemented in accord with one aspect of the concepts disclosed herein, where a monitoring service collecting and storing vehicle performance data for a client's vehicle is the consumer from the standpoint of the pricing service provider, and the monitoring service suspects that their client's vehicle needs servicing based on the vehicle performance data they monitor;
- FIGURE IF is a high level logic diagram showing exemplary overall method steps implemented in accord with the concepts disclosed herein to remotely monitor a vehicle using data collected during normal vehicle operations, to use the collected data to diagnose an abnormal vehicle parameter in real-time, and to provide reverse auction results for the diagnosed repair to the vehicle operator;
- FIGURE 2 is a functional block diagram of an exemplary computing device that can be employed to implement some of the method steps disclosed herein;
- FIGURE 4 is an exemplary functional block diagram showing the basic functional components used to implement the method steps of FIGURE IF;
- FIGURE 5 is an exemplary screen shot of a webpage accessed by a vehicle operator to review the results of the reverse auction for a specific vehicle;
- FIGURE 6 is a high level logic diagram showing exemplary overall method steps implemented in accord with the concepts disclosed herein to host a reverse auction for a diagnosed repair to a vehicle;
- FIGURE 7 is another exemplary functional block diagram showing the basic functional components used to implement the method steps of FIGURE IF, where the performance data includes buffered operation data and fault codes;
- FIGURE 8 is a functional block diagram showing a pricing service provider, a consumer, and a plurality of service vendors interacting over the Internet;
- FIGURE 9 schematically illustrates an exemplary kit, designed to facilitate an interaction between a smart phone user and a pricing service provider.
- the concepts disclosed herein encompass several different embodiments for providing consumers with pricing information for servicing a vehicle.
- the concepts disclosed herein encompass embodiments in which a consumer (who can be a private individual, a fleet operator, and/or a monitoring service) contacts a pricing service provider and requests pricing information for a vehicle service, as well as embodiments in which the pricing service provider monitors vehicle performance data to determine that vehicle servicing is required (which in some cases may occur before the consumer recognizes that service is required).
- the pricing service provider determines that service is required (either based on a request for service from a consumer, or an analysis of vehicle performance data, or a combination thereof)
- the pricing service provider contacts a plurality of vendors to acquire pricing data for performing the requested service.
- the pricing service provider hosts a reverse auction, in which interested service vendors compete with one another for the service job.
- the pricing service provider hosts a webpage upon which results of the service requests from the plurality of vendors are displayed.
- FIGURE 1A is a high level functional block diagram illustrating the various inputs that can be received by a pricing service provider 202, who in response to an input will send a pricing request to a plurality of service vendors 212a-212c (noting that the three service vendors shown in the Figure are simply exemplary, and that price requests may actually be sent to more or fewer service vendors).
- a first type of input that can be received by pricing service provider 202 is a defined service request 206.
- the term defined service request is intended to encompass those service requests where there is no need to diagnose the vehicle to determine what type of service is required.
- Such an input will be received when a consumer (which could be an operator 200 or a monitoring service 204) determines that a specific type of service is required, and wants pricing service provider 202 to obtain pricing data for that service. For example, a car owner may realize that their vehicle requires new tires, and request pricing service provider 202 to obtain pricing data for the specific type of tires required from a plurality of service vendors.
- the defined service request is not limited to tires, but can include any type of vehicle service where the scope of the required service is well characterized at the time of the request.
- Exemplary, but not limiting defined service requests includes brake replacement (replacement of pads only, or the replacement of pads and resurfacing of rotors), oil changes, tire replacement, cooling system maintenance, scheduled maintenance services, repair of diagnosed vehicle faults, towing services, body repair, painting, and windshield replacement/repair. It should be recognized that essentially any vehicle maintenance, service or repair that can be defined is encompassed.
- the defined service request can originate from a vehicle operator (such as an individual car owner or a fleet operator) or from a third party monitoring service, which regularly acquires vehicle performance data, and monitors the vehicle performance data to identify any vehicle service needs.
- Vehicle manufactures are increasingly collecting and storing vehicle performance data from vehicles they manufacture and sell. Manufactures such as General Motors, Ford, and Hyundai each have varying abilities to collect vehicle performance data.
- Applicant is developing data collection components to be installed in fleet vehicles (such data collection components are often integrated into position tracking components), to be used by vendors to offer monitoring services to alert vehicle owners to service issues that can be proactively addressed before failures take vehicles out of service or result in more costly repairs.
- Such a monitoring service can analyze the vehicle performance data, and contact the pricing service provider when the need for vehicle service is identified.
- the pricing service provider will then provide the monitoring service with the price quotes, and the monitoring service can provide those pricing quotes to their clients (the vehicle operator).
- the pricing service provider and monitoring service are the same entity.
- vehicle performance data 208 A second type of input that can be received by pricing service provider 202 is vehicle performance data 208.
- vehicle performance data is intended to encompass all types of data collected from a vehicle that can be used to diagnose a vehicle fault or to identify an anomalous condition that should be addressed.
- Vehicle performance data specifically includes operational data and fault code data.
- Vehicle performance data can be collected on an ongoing basis by a vehicle monitoring service. Vehicle performance data can also be collected when the operator of the vehicle suspects that some type of vehicle service is required, but the specific service required cannot be defined by the vehicle operator.
- the vehicle performance data is conveyed to the pricing service provider, and the pricing service provider can analyze the vehicle performance data to determine what service is needed.
- the pricing service provider can also convey the vehicle performance data to the service vendors, so each vendor can analyze the vehicle performance data to determine what service is needed. Note that as shown in FIGURE 1A, pricing service provider 202 can receive vehicle performance data 208 from operator 200, from monitoring service 204, or from vehicle 210.
- the pricing service provider receives the vehicle performance data from operator 200
- the operator will suspect that some service is needed, but will not be certain what specific service is required (i.e., a diagnosis is required).
- the vehicle performance data is acquired by the operator/consumer and conveyed to the pricing service provider along with a request for service.
- Low cost diagnostic units capable of extracting fault code data and other vehicle performance data from vehicles are increasingly available.
- individual consumers use such equipment to transfer vehicle performance data to their smart phones, and such data is then conveyed to the pricing service provider.
- the monitoring service may suspect that some service is needed, but will not be certain what specific service is required (i.e., a diagnosis is required).
- vehicle performance data acquired and stored by the monitoring service is conveyed to the pricing service provider along with a request for service.
- the monitoring service will have access to diagnostic tools that can be used to analyze the vehicle performance data, such that a defined service request can be conveyed to the pricing service vendor.
- Some monitoring services may employ relatively simply diagnostic algorithms to identify potential problems, and outsource detailed diagnostic functions to either the pricing service provider or service vendors.
- the pricing service provider receives the vehicle performance data from the vehicle, the pricing service provider is also functioning as a monitoring service.
- the pricing service provider generates a webpage 214 to communicate with one or more of the service vendors, the operator, and the monitoring service.
- the webpage hosts a reverse auction in which service vendors compete for the service business.
- FIGURE 5 illustrates an exemplary webpage. Note that while not specifically shown in FIGURE 1A, in various embodiments the webpage can be used to facilitate communications between one or more of the service vendors, the operator, the 3 rd party monitoring service, and the pricing service provider.
- FIGURE IB is a high level functional block diagram providing greater detail about the various inputs that can be received by a pricing service provider 202.
- a block 216a corresponds to an input received from a consumer (such as a fleet operator or the owner of a private vehicle) who has a well defined service request, such as the replacement of tires, or the repair of a previously diagnosed condition (noting that such services are intended to be exemplary, and not limiting).
- a block 216b corresponds to an input received from a consumer (such as a fleet operator or the owner of a private vehicle) who recognizes that some type of service should be performed, but cannot specifically define the scope of the service.
- a block 216c corresponds to an input received from a consumer (such as a fleet operator or the owner of a private vehicle) who recognizes that some type of service should be performed, but cannot specifically define the scope of the service, and who employs a monitoring service to collect and store vehicle performance data. That consumer will send a poorly defined service request to pricing service provider 202, along with a request that the vehicle performance data needed be acquired from the monitoring service.
- a consumer such as a fleet operator or the owner of a private vehicle
- the consumer sends a request to the monitoring service to forward the vehicle performance data to the pricing service provider, while in other embodiments the consumer sends a poorly defined service request to the pricing service provider, and the pricing service provider obtains the vehicle performance data from the monitoring service.
- a block 216d corresponds to an input received from a monitoring service that has used vehicle performance data to diagnose a specific vehicle service.
- the monitoring service sends a well-defined service request to the pricing service provider to obtain pricing quotes for the service.
- a block 216e corresponds to an input received from a monitoring service that has used a basic diagnostic algorithm to determine that some poorly defined vehicle service should be performed.
- the monitoring service sends a poorly defined service request to pricing service provider 202, along with vehicle performance data that the pricing service provider or service vendors can use to more specifically diagnose the required service before providing price quotes.
- FIGURE 1C is a high level flow chart showing the overall method steps implemented in accord with one aspect of the concepts disclosed herein, where a consumer suspects that a specific vehicle needs servicing, but does not understand what specific service is required, and that consumer wants a pricing service provider to obtain pricing data for the vehicle service.
- the consumer extracts vehicle performance data from the vehicle and sends the vehicle performance data along with a service request to a pricing service provider (this corresponds to the input of block 216b of FIGURE IB).
- Many relatively low cost diagnostic tools are available to consumers to extract vehicle performance data (including but not limited to fault codes) from their vehicles.
- the consumer simply sends the numerical fault codes to the pricing service provider along with a service request.
- a service request will include basic information about the vehicle, including but not limited to the vehicle's make, model, mileage, equipment, and vehicle identification number (such information is often used in diagnosing a particular fault code), along with any information about how a suspected problem condition is manifesting itself in the vehicle (excess fuel consumption, hard starting, reduction in power, etc.)
- the consumer will acquire an electronic data file from the vehicle, and that data file is sent to the pricing service provider along with the service request.
- the consumer employs a dongle (i.e., a hardware connector) that couples a smart phone to a data port in the vehicle (such as an onboard diagnostics (OBD) port), such that the electronic data is imported from the vehicle into the smart phone.
- a dongle i.e., a hardware connector
- OBD onboard diagnostics
- the electronic data file extracted from the vehicle is then conveyed to the pricing service provider along with the service request.
- the pricing service provider conveys the service request to a plurality of service vendors to obtain pricing data. It should be understood that block 222 encompasses embodiments where the pricing service provider diagnoses the vehicle performance data and sends a defined service request to the service vendors, embodiments where the pricing service provider diagnoses the vehicle performance data and sends a defined service request and the vehicle performance data to the service vendors, and embodiments where the pricing service provider does not diagnose the vehicle performance data, but sends a poorly defined service request and the vehicle performance data to the service vendors.
- the service vendors provide pricing data for performing the required service.
- block 224 encompasses reverse auction embodiments, as well as embodiments where each service vendor simply quotes their price.
- a decision block 226 the consumer selects (or not) a service vendor. If no service vendor is selected, the method terminates. If a service vendor is selected, then the pricing service provider facilitates the transaction between the consumer and the selected service vendor in a block 228. While such facilitation is not required, the pricing service provider will likely have a vested interest in facilitating the transaction. While it is possible that the pricing service provider will provide the pricing service for free (perhaps in order to drive traffic to a website, where the pricing service provider earns advertising revenue), in at least some embodiments the pricing service provider will earn a transaction fee (most likely from the winning service vendor).
- the pricing service provider is involved in the transaction between the selected service vendor and the consumer.
- the pricing service provider handles the payment between the consumer and the service vendor, enabling the pricing service provider to retain part of the fee.
- the pricing service provider handles the scheduling between the consumer and the service vendor, enabling the pricing service provider to bill the service vendor (and/or consumer) for the pricing service provided.
- the pricing service provider withholds some service vendor identification details from the consumer, to prevent the consumer from bypassing the pricing service provider, and preventing the pricing service provider from earning a fee.
- the pricing service provider can withhold one or more of the following types of information about the service vendors until the pricing service provider is paid a fee: the name of the service vendor, the address of the service vendor, and the telephone number of the service vendor.
- FIGURE ID is a high level flow chart showing the overall method steps implemented in accord with one aspect of the concepts disclosed herein, where a consumer enrolled in a monitoring service (the monitoring service collecting and storing vehicle performance data for the consumer's vehicle) suspects that a specific vehicle needs servicing, but does not understand what specific service is required, and that consumer wants a pricing service provider to obtain pricing data for the vehicle service.
- the consumer sends a service request to a pricing service provider (this corresponds to the input of block 216c of FIGURE IB).
- a pricing service provider this corresponds to the input of block 216c of FIGURE IB.
- vehicle performance data is obtained from the monitoring service.
- block 220a encompasses embodiments where the pricing service provider requests the vehicle performance data from monitoring service (so that a diagnosis of the required service can be made) as well as embodiments where the consumer requests the vehicle performance data from monitoring service (so that a diagnosis of the required service can be made).
- the steps of blocks 222, 224, 226, and 228 remain consistent with the description of those blocks provided above in connection with FIGURE 1C.
- FIGURE IE is a high level flow chart showing the overall method steps implemented in accord with one aspect of the concepts disclosed herein, where a monitoring service collecting and storing vehicle performance data for a client's vehicle is the consumer from the standpoint of the pricing service provider, and the monitoring service suspects that their client's vehicle needs servicing based on the vehicle performance data they monitor.
- the monitoring service detects that a specific vehicle requires servicing.
- the monitoring service sends a service request to the pricing service provider.
- blocks 221 and 223 encompasses embodiments where the monitoring service has conclusively diagnosed what service is required (i.e., the monitoring service has performed a high level diagnostic, consistent with block 216d of FIGURE IB), as well as embodiments where the monitoring service has not conclusively diagnosed what service is required (i.e., the monitoring service has performed only a cursory diagnostic, consistent with block 216e of FIGURE IB). If the monitoring service has performed a detailed diagnosis, then no vehicle performance data need be sent to the pricing service provider with the service requests.
- the monitoring service may send the pricing service provider the vehicle performance data from which the diagnosis was made, and unless confidentiality issues preclude sharing that information with the pricing service provider, in at least some embodiments the vehicle performance data will be included even when the monitoring service believes they have correctly diagnosed the service required. If the monitoring service has performed only a cursory diagnosis, then the vehicle performance data needs to be sent to the pricing service provider with the service request, so the detailed diagnosis can be performed by the pricing service provider or the service vendors, generally as discussed above.
- the steps of blocks 222, 224, 226, and 228 remain consistent with the description of those blocks provided above in connection with FIGURE 1C.
- the pricing service provider may be interacting with the monitoring service (who then interacts with their client, the vehicle operator), and/or with the vehicle operator (the client of the monitoring service).
- FIGURE IF is a high level flow chart showing the overall method steps implemented in accord with one aspect of the concepts disclosed herein, to convey performance data from a vehicle to a remote monitoring service that uses the performance data to diagnose any mechanical problems with the vehicle.
- the monitoring service collects quotes for the required repair, and provides the operator of the vehicle with information describing the identified mechanical fault and the repair costs from a plurality of vendors.
- the repair costs have been determined in a reverse auction, where vendors compete and bid for the opportunity to repair the diagnosed mechanical problem. The vendors may also simply submit non- binding or binding quotes to repair the mechanical problem.
- the monitoring service and the pricing service provider are the same entity.
- the vehicle includes a position sensing component as well, and position data and performance data are generated by the vehicle, and also transmitted to the remote monitoring service.
- a portable data entry device might be used to collect and transmit data concerning the status of components on the vehicle.
- One such exemplary portable data collection device disclosed in the patents referenced above includes a sensor that detects a token disposed at each location on a vehicle included on a list of components to be inspected, when the portable data collection device is positioned proximate to the token, thereby ensuring that the person doing the inspection actually was physically present next to each of the components that are being inspected. The person can enter data relating to the condition or status of each component into the portable data collection device for subsequent transmission to the remote monitoring service.
- an operator can submit data electronically to the remote monitoring service that is indicative of the condition noted by the operator. For example, the operator may notice that a light on the vehicle is not working and needs to be replaced while walking around the vehicle, or while driving the vehicle, may notice that the engine is running rough or may detect an unusual noise in the valves.
- the vehicle may provide a warning to the operator that a problem has been detected, so that the operator can then transmit a request for automatically soliciting quotes or bids from interested service vendors, to repair the problem. For example, while driving the vehicle, a display panel in the vehicle may indicate some abnormal condition to the operator, who can then electronically transmit that information to the remote monitoring service.
- Such observations or requests can be submitted by telephone or through a data link connection to the remote monitoring service.
- the data submitted to the remote monitoring service need not be limited to that automatically produced and transmitted by the vehicle system without input by the operator.
- a portable data collection device can also be used in embodiments where no monitoring service is used, and data from the handheld portable data collection device is conveyed to the pricing service provider, to provide the pricing service provider with details about the vehicle service to be priced.
- a processor at the remote monitoring service location is used to analyze the performance data to determine if a mechanical fault has been detected. This analysis is ongoing, as performance data from the vehicle is conveyed to the remote monitoring service in ongoing data transmissions.
- the processor at the monitoring service i.e., the remote location
- defects or the need for repair or maintenance of the vehicle can also be determined by visual inspection or other perception, e.g., by the operator of the vehicle while operating the vehicle, and the data provided by these visual and other types of observations can be included with the vehicle location (from GPS) as well as data generated by the vehicle computer(s) for purposes of determining that a mechanical fault or problem requires attention and possible repair, either by the vehicle or by the remote monitoring service.
- the monitoring service and the pricing service provider are separate entities, upon identifying a fault (either a fault that has actually occurred or a fault that the data analysis predicts will occur), the monitoring service can convey a service request to the pricing service provider, generally as discussed above. It should also be understood that in some embodiments encompassed by the concepts disclosed herein, the diagnostic analysis of vehicle performance data can also be implemented by the pricing service provider, and/or service vendors.
- the monitoring service contacts a plurality of providers of vehicle repair services and requests bids (or non-binding or binding quotes) for the required repair. It should be noted that this task may be carried out by a different entity than the one monitoring the conditions in the vehicles.
- the bids are requested in a reverse auction style format, where the vehicle repair providers bid on the job.
- the vendor makes the diagnosis and the reverse auction bid results available to the vehicle operator, as indicated in a block 20.
- the monitoring service schedules the repair.
- the logic then returns to a block 12, where additional performance data is received from the vehicle, and monitoring of the performance data for additional mechanical faults continues.
- performance data is intended to encompass data collected at the vehicle that can be used by a computing device to identify a mechanical fault. Such data can include fault code data, data from dedicated sensors added to the vehicle to aid in diagnosing a mechanical fault, and operational data.
- operational data encompasses data that is used to control the operation of the vehicle. In the prior art, operational data is not stored, but rather generated, contemporaneously, used as necessary to control various vehicular systems (such as a fuel injection system, a cooling system, or a braking system), and then discarded. Exemplary operational data include, but is not limited to, engine coolant temperature, engine speed, oxygen levels, throttle position, brake temperature, vehicle speed, brake position, and gearbox parameters.
- a data buffer is added to the vehicle to temporarily store operational data, such that when a fault code is generated at the vehicle, the fault code data and at least some of the buffered operational data are conveyed to the remote monitoring service.
- the fault code data and at least some of the buffered operational data are conveyed to the remote monitoring service.
- injector data can be included in a first transmission
- oxygen sensor data can be included in a second transmission
- brake sensor data can be included in a third transmission
- the quantity of performance data conveyed during each different data transmission can be selected to match a desired bandwidth. Where data transmission costs are relatively higher, relatively less performance data can be sent during each different data transmission. Where data transmission costs are relatively lower, relatively more performance data can be sent during each different data transmission.
- more than one type of performance data can be conveyed in the same transmission (i.e., injector data plus brake data, or some other combination).
- the amount of data transmitted during each transmission will be relatively small, e.g., less than a kilobyte (or in some embodiments, multiple kilobytes, but less than hundreds of kilobytes, though it should be understood that such data volumes are exemplary, and not limiting).
- the monitoring service can build a database of vehicle performance data over time and still receive a very manageable volume of data during each data transmission.
- the monitoring function is ongoing over an extended period, sufficient data can be acquired to enable the monitoring service to detect changes in the performance data indicative of a developing or worsening mechanical fault. If trying to perform a diagnosis at just one point in time (i.e., in response to just a single transmission of vehicle performance data), it might be necessary to include as much data as possible in that one transmission. In embodiments where the monitoring service collects performance data from a vehicle over an extended period of time, transmission of smaller data sets is acceptable. Where different types of performance data are transmitted to the remote monitoring service at different times, in at least one embodiment, one or more types of operational data are pulled from a data bus (i.e., operational data currently being generated by the vehicle are acquired) in the vehicle at the time of the data transmission to the remote monitoring service.
- a data bus i.e., operational data currently being generated by the vehicle are acquired
- the operator provided input can be sent when the operator desires, or alternatively, can be included with the next transmission of the data automatically provided by the vehicle system.
- the selection of the data provided by an automated system can be based on a predefined schedule, or can be manually selected if the operator wants to expedite input of a specific type of data, or wants to prioritize the type of data transmitted most often.
- the schedule can be repeated in the same sequence (i.e., data types A, B, and C are sent in sequence A-B-C, repeatedly), or the sequence can be varied (i.e., data types A, B, and C are sent in sequence A-B-C initially, and then in a different order in a subsequent sequence of transmissions).
- the selection of data for a specific transmission can be performed at random, and over an extended period of time performance data from all different categories are likely to be received by the remote monitoring service.
- the time period between subsequent data transmissions is based on a predetermined time interval (for example, a new data transmission can be executed at hourly intervals (or be executed based on a larger or a smaller fixed time period)).
- the time period between subsequent data transmissions is based on a randomly determined time interval (for example, the time period between subsequently data transmissions can be randomly varied). Such random variations can be controlled as desired.
- the intervals between subsequent data transmissions can be randomly varied.
- the time period between subsequent data transmissions is based on a predetermined event.
- a different data transmission is executed whenever a particular event occurs. Exemplary events include, but are not limited to, powering up the vehicle, powering off the vehicle, the generation of a fault code in the vehicle, a measured vehicle parameter exceeds or falls below a predetermined value (i.e., engine temperature exceeds a predetermined value, oil pressure exceeds a predetermined value, oil pressure drops below a predetermined value, etc.).
- the vehicle is equipped with a position sensing system that is configured to convey position data to a remote computer device according to either a predefined schedule (i.e., every five minutes, such a time interval being exemplary and not limiting) or when a predefined event occurs (i.e., the vehicle heading changes by a certain extent, such an event being exemplary and not limiting).
- a predefined schedule i.e., every five minutes, such a time interval being exemplary and not limiting
- a predefined event i.e., the vehicle heading changes by a certain extent, such an event being exemplary and not limiting.
- each time position data is transmitted from the vehicle to a remote computing device, performance data is included in the same transmission (in such an embodiment, the monitoring service tracks vehicle performance data and position data for the operator of the vehicle).
- the vehicle position data can be used by the vehicle monitoring service
- the vehicle monitoring service monitors vehicles over a relatively large geographical range (i.e., regionally or nationally), and will have prescreened or otherwise qualified many different service vendors.
- the pool of vendors can be narrowed based on the location of the vehicle as indicated by the current vehicle position data, or by data provided by the vehicle operator about an intended destination of the vehicle - as appropriate for the type and importance of the repair required.
- the service vendors automatically contacted to solicit quotes or bids can also be limited to those specializing in the specific type of repair required.
- the vehicle monitoring service can use the vehicle's current location as the basis for selecting from which service vendors repair quotes (or reverse auction bids) should be solicited (i.e., providers of vehicle repair services who are located beyond a predefined distance are not allowed to bid in the reverse auction, or are not contacted by the monitoring service (or the third party) for a repair quote).
- service vendors repair quotes or reverse auction bids
- vehicle operators can define, or redefine, the predefined distance about a desired location from which to solicit bids for the repair job.
- enabling the consumer to define a preferred geographical location for service vendors is a functionality that can be implemented into each of the embodiments encompassed in FIGURES 1A and IB (which illustrate different inputs that can be received by the pricing service provider).
- the vehicle monitoring service can contact the vehicle operator before obtaining repair costs from service vendors (or before requesting the pricing service provider to obtain price quotes, in embodiments where the pricing service provider and the monitoring service are different entities), to enable the vehicle operator to define the appropriate repair location.
- vehicle operators can affirmatively provide the monitoring service (or the pricing service provider) with the vehicle's scheduled route, such that the monitoring service (or the pricing service provider) can solicit service vendors based on the scheduled route.
- the scheduled route may indicate that a first stop must be made in Seattle, WA by a specific time and date, a second stop must be made to Portland, OR by a specific time and date, and no additional stop is currently scheduled.
- the monitoring service (or the pricing service provider) can determine if there is time to perform the repair in Seattle (or some location between Seattle and Portland) before the stop in Portland is scheduled. If there is sufficient time between the scheduled deliveries, the monitoring service (or the pricing service provider) can solicit repair quotes from vendors in the Seattle area, or service vendors along the Seattle to Portland corridor. If there is not sufficient time between the scheduled deliveries, the monitoring service can solicit repair quotes from vendors in the Portland area only. Once the bids (in a reverse auction) or quotes have been obtained from the service vendors, the operator can make a selection of the service vendor to carry out the repair work.
- the selected service vendor may not be the lowest bid or quote to do the work, since the operator may include other factors besides the cost bid or quote in making this selection.
- the second lowest quote may be from a service vendor having a business located closer to the location where the repair is desired (or the current location - if repair is required immediately).
- the selected vendor may be chosen by the operator based on the reputation of the vendor or based on the indicated time delay before the repair work can be started by the vendor.
- the analysis of the performance data will be carried out by a remote computing device (i.e., remote from the vehicles enrolled in the monitoring service) operated by the monitoring service vendor, unless the nature of the required repair has already been determined by the operator input data or by the computing system on the vehicle.
- the remote computing device performing the monitoring function in at least one embodiment comprises a computing system controlled by the operator of the vehicle (i.e., the monitoring service is operated by the vehicle owner, who may operate of a fleet of vehicles), while in other exemplary embodiments, the computing system performing the monitoring function is controlled by an independent party or vendor who manages the monitoring/diagnostic service for the operators of the enrolled vehicles (in some embodiments, the vehicle monitoring service bills the vehicle operators a subscription fee).
- the remote computing device can be operating in a networked environment and can comprise multiple computing devices that may be disposed at disparate geographical locations or at a single location.
- the monitoring service provides sufficient data to the repair vendors that such data can be input into a diagnostic software application known to the repair vendor, so the repair vendor can confirm the diagnosis, or derive their own diagnosis independent of the monitoring service.
- FIGURE 2 schematically illustrates an exemplary computing system 250 suitable for use in implementing the method of FIGURE IF (i.e., for executing at least blocks 14-20 of FIGURE IF, noting that such a computing device can also be employed to implement the functions of the methods of FIGURES 1C-1E). Similar components might be used in a data terminal within a vehicle to enable the operator to input information related to the status of the vehicle or components on the vehicle, so that the information can be transmitted to the remote monitoring vendor.
- Exemplary computing system 250 includes a processing unit 254 that is functionally coupled to an input device 252 and to an output device 262, e.g., a display (which can be used to output a result to a user, although such a result can also be stored).
- Processing unit 254 comprises, for example, a central processing unit (CPU) 258 that executes machine instructions for carrying out an analysis of performance data (and in some embodiments, of position data) collected from enrolled vehicles, to identify mechanical faults in the enrolled vehicles.
- the machine instructions implement functions generally consistent with those described above with respect to blocks 14-20 of FIGURE IF.
- CPUs suitable for this purpose are available, for example, from Intel Corporation, AMD Corporation, Motorola Corporation, and other sources, as will be well known to those of ordinary skill in this art.
- processing unit 254 Also included in processing unit 254 are a random access memory
- RAM 256 and non-volatile memory 260 which can include read only memory (ROM) and may include some form of memory storage, such as a hard drive, optical disk (and drive), etc. These memory devices are bi-directionally coupled to CPU 258. Such storage devices are well known in the art. Machine instructions and data are temporarily loaded into RAM 256 from non-volatile memory 260. Also stored in the non-volatile memory are operating system software and ancillary software. While not separately shown, it will be understood that a generally conventional power supply will be included to provide electrical power at voltage and current levels appropriate to energize computing system 250.
- Input device 252 can be any device or mechanism that facilitates user input into the operating environment, including, but not limited to, one or more of a mouse or other pointing device, a keyboard, a microphone, a modem, or other input device.
- the input device will be used to initially configure computing system 250, to achieve the desired processing (i.e., to monitor vehicle performance data over time to detect a mechanical fault).
- Configuration of computing system 250 to achieve the desired processing includes the steps of loading appropriate processing software into non-volatile memory 260, and launching the processing application (e.g., loading the processing software into RAM 256 for execution by the CPU) so that the processing application is ready for use.
- Output device 262 generally includes any device that produces output information, but will most typically comprise a monitor or computer display designed for human visual perception of output. Use of a conventional computer keyboard for input device 252 and a computer display for output device 262 should be considered as exemplary, rather than as limiting on the scope of this system.
- Data link 264 is configured to enable vehicle performance data (and position data when desired) collected in connection with operation of enrolled vehicles to be input into computing system 250 for analysis to identify a mechanical fault with the vehicle.
- USB universal serial bus
- FireWire ports FireWire ports
- infrared data ports wireless data communication
- Wi-Fi and BluetoothTM network connections via Ethernet ports
- vehicle performance data from the enrolled vehicles will be communicated wirelessly, either directly to the remote computing system that analyzes the data to diagnose the anomaly, or to some storage location or other computing system that is linked to computing system 250.
- remote computing device are intended to encompass a single computer as well as networked computers, including servers and clients, in private networks or as part of the Internet.
- the vehicle data received by the monitoring service from the vehicle can be stored by one element in such a network, retrieved for review by another element in the network, and analyzed by yet another element in the network.
- a vendor is responsible for diagnosing the vehicle data, and clients of the vendor are able to access and review such data, as well as any resulting diagnoses. While implementation of the method noted above has been discussed in terms of execution of machine instructions by a processor (i.e., the computing device implementing machine instructions to implement the specific functions noted above), the method could also be implemented using a custom circuit (such as an application specific integrated circuit or ASIC).
- ASIC application specific integrated circuit
- FIGURE 3 is a functional block diagram of exemplary components used in vehicles 28 that are enrolled in the vehicle diagnostic service, to implement some of the method steps shown in FIGURE IF.
- An exemplary vehicle monitoring service is based on adding an optional data buffer 36 (or other short-term memory storage) and a bi-directional data link 34 to each enrolled vehicle (in an exemplary, but not limiting embodiment, the data buffer and data link are combined into a single component).
- the short term memory storage is not required for embodiments where the performance data transmitted from the enrolled vehicle does not include operational data that must be briefly stored.
- the data link is a combination radio frequency (RF) transmitter and receiver, although separate transmitters and receivers could be used.
- RF radio frequency
- a data terminal can also be included in the vehicle to facilitate operator entry of information and operator transmission of information that is presented to the operator on a display within the vehicle.
- the data collected on the portable data collection device during an inspection can also be uploaded through such a data terminal, or independently by direct transmission to the remote monitoring service. While RF data transmission represents an exemplary embodiment, other types of data transmission could be employed.
- the vehicle does not already include performance data/operational data collecting components 30, such components are added. As discussed above, most vehicles manufactured today include such operational data collecting components already, as many of today's vehicles are designed to use such continuously generated operational data to control operation of the vehicle in real-time, and such vehicles generally include data collecting components, data buses, and controllers that use the operational data to control the operation of the vehicle.
- the vehicle includes at least one processor 32 that performs the function of managing the transmission of performance data from the vehicle to the remote monitoring service, according to one or more of the transmission paradigms discussed herein.
- the processor also implements the function of temporarily storing operational data from components 30 in data buffer 36 or other temporary storage, detecting an anomalous condition (or predefined condition) in the vehicle, and in response to detecting such an anomaly, using bi-directional data link 34 to convey real-time anomaly data and the buffered operational data from the enrolled vehicle to a remote computing device 40 (which is used to determine or diagnose a cause for the detected anomaly).
- those processor functions can be implemented by a single processor, or distributed across multiple processors.
- an output 38 is also included, to provide mechanical fault/diagnostic related information to the driver in a form that can be easily understood by the driver.
- Output 38 can be implemented using one or more lights (for example, a red light can be used to indicate that a problem has been detected which requires the operator to stop the vehicle, or to modify vehicle operations, such as by slowing down to reduce a load being placed on the vehicle until a repair can be made), using a speaker providing an audible output, and using a display providing a visual output.
- output 38 can be combined into a single component with the data buffer and the data link, so only a single additional component is added to the vehicle (recognizing that most vehicles already include the additional required components, such as the operational data collecting components and the processor).
- remote computing device 40 (operated by the monitoring service) is logically coupled via a network 42 (such as the Internet) to a computing device 44 accessible to a vehicle repair service vendor (noting only one such vendor is shown in the Figure; however, the monitoring service (or a third party) will be exchanging data with a plurality of different service vendors, each likely having access to a different computing device 44), and a computing device 46 accessible to a vehicle operator (noting that in at least some embodiments, the monitoring service performs the monitoring function for a plurality of different vehicle operators).
- a network 42 such as the Internet
- vehicle repair service vendor noting only one such vendor is shown in the Figure; however, the monitoring service (or a third party) will be exchanging data with a plurality of different service vendors, each likely having access to a different computing device 44
- a computing device 46 accessible to a vehicle operator (noting that in at least some embodiments, the monitoring service performs the monitoring function for a plurality of different vehicle operators).
- Network 42 facilitates communication between computing devices 40, 44, and 46, enabling the monitoring service (and a third party who may be employed to solicit the bids from the service vendors) to efficiently communicate with service vendors and vehicle operators.
- the data terminal for manual input can alternatively, or additionally, be located in the vehicle.
- the concepts disclosed herein are in at least some embodiments intended to be used by fleet owners operating multiple vehicles, and the performance data conveyed to the remote location for diagnosis will include an ID component that enables each enrolled vehicle to be uniquely identified.
- the concepts disclosed herein are also applicable to individual consumers, who desire to employ the pricing service provider discussed herein to obtain pricing (in some embodiments, via a reverse auction) from a plurality of service vendors who can service the consumer's vehicle.
- FIGURE 4 is a functional block diagram of various elements that can be employed to implement the method steps of FIGURE IF.
- the elements includes a plurality of enrolled vehicles 48a-48c (noting that the concepts disclosed herein can be applied to a different number of vehicles), a plurality of repair (or service) vendors 52a- 52c (noting that the concepts disclosed herein can be applied to a different number of service vendors), a plurality of vehicle operators 56a-56c (noting that the concepts disclosed herein can be applied to a different number of vehicle operators), and a remote monitoring service 50.
- Each vehicle includes the components discussed above in connection with FIGURE 3, enabling the vehicle to convey performance data from the vehicle to remote monitoring service 50, which monitors the performance data from each vehicle 48a-48c over time to identify any mechanical fault in the vehicle.
- remote monitoring service 50 contacts repair vendors 52a- 52c to obtain repair costs to fix the mechanical fault that was detected by monitoring the vehicle performance data (or identified by the vehicle operator via an inspection of the vehicle, or via an in-vehicle identification of a fault).
- monitoring service 50 generates a webpage (as indicated by webpages 54a-54c) for each vehicle in which a mechanical fault is detected, and that webpage is made available to the corresponding vehicle operator.
- FIGURE 4 should not be interpreted that there must be a 1 :1 correspondence between the number of enrolled vehicles and the number of vehicle operators (or a 1 :1 correspondence between the number of enrolled vehicles and the number of repair vendors).
- monitoring service 50 is implemented using a remote computing device, and that the term remote computing device is intended to encompass networked computers, including servers and clients, in private networks or as part of the Internet.
- the monitoring of the vehicle performance data by monitoring service 50 can be performed by multiple different computing devices, such that performance data is stored by one element in such a network, retrieved for review by another element in the network, and analyzed by yet another element in the network.
- vehicle operators can establish standards that the monitoring service uses to select repair vendors for providing pricing data. For example, a first vehicle operator may only want price quotes from service vendors having a specific level of insurance, or who exceed a specific size, or who are part of a chain of service centers. A second vehicle operator may only want price quotes from service vendors whom they have pre-qualified. A third vehicle operator may place no restrictions on the repair vendors the monitoring service approaches for pricing data.
- the diagnostic/monitoring function performed by the monitoring service involves comparing the performance data from the vehicle with historical data linked to a specific fault condition.
- vehicle parameters extending beyond the collected performance data, which is broadly referred to herein as "contextual data.”
- vehicle parameters include, but are not limited to, the VIN #, the firmware data used on the vehicle data system, the year, make and model of the vehicle, the engine employed in the vehicle, the transmission employed in the vehicle, and additional equipment employed on or added to the vehicle to customize the vehicle to the operator's needs.
- This additional data can help increase the accuracy of the diagnostic aspect of the monitoring service and better determine the parts required and the cost to repair the vehicle, because the historical data records may indicate that a particular set of performance data from one make and model of a vehicle having a specific equipment configuration was associated with a first mechanical fault, while a similar set of performance data from a differently equipped vehicle (either a different make and model, or a similar make and model with different equipment) was associated with a different mechanical fault. Analyzing the performance data in light of the make, model, and specific equipment configuration of a vehicle, as well as any available vehicle inspection data for the vehicle, can thus improve the accuracy of a diagnosis of a mechanical fault.
- diagnostic function can also or alternatively be carried out by any of the repair vendors solicited to quote or bid on the repair job, and the above-noted performance data and contextual data can be supplied to each such vendor to enable them to be more confident that they are bidding or quoting on the actual repair job that needs to be completed.
- FIGURE 4 has been illustrated and discussed in terms of a single entity implementing the functions of monitoring vehicle performance data (see block 204 of FIGURE 1A) and acquiring pricing data from a plurality of service vendors (see block 202a of FIGURE 1 A), it should be recognized that FIGURE 4 is also relevant to embodiments where reference numeral 50 refers to a pricing service provider (which does not also perform a monitoring function), receiving inputs related to vehicle operators 56a-56c.
- FIGURE IB schematically illustrates different types of inputs that can be received by a pricing service provider.
- the monitoring service contacts repair vendors to get pricing data for the required repair (or contacts a pricing service provider who in turn contacts the service vendors, in embodiments where the monitoring service and the pricing service provider are separate entities).
- the monitoring service/pricing service provider arranges a reverse auction, where selected repair vendors competitively provide their best price in a reverse auction format (i.e., the repair vendors bid against each other, and are able to see each other's bids, which encourages the repair vendors to lower their prices on successive bids to compete against one another for the repair job).
- FIGURE 5 is an exemplary screen shot of a webpage accessed by a vehicle operator to review the results of a reverse auction for a specific vehicle.
- a webpage 100 includes a first portion 102 that enables a vehicle operator having a plurality of vehicles to select a specific vehicle. It should be understood that webpage 100 can be unique to only one vehicle, such that portion 102 is not required.
- Webpage 100 also includes a results section 104, where details of the detected mechanical fault and results from the reverse auction are displayed. It should be understood that the details of the detected mechanical fault and results from the reverse auction can be displayed on different portions of the webpage, or on different webpages and/or different websites, instead of together.
- Webpage 100 also includes a map section 106, where the locations of the repair vendors relative to the vehicle location (at the current time or at the time that the vehicle will be available to be repaired) can be viewed. If desired, map section 106 can be omitted, or can be displayed on a separate webpage.
- results section 104 includes results from three different repair vendors. It should be recognized that the specific number of repair vendors displayed here can, and likely will vary, based on the number of repair vendors that respond to the solicitation from the monitoring service (or the third party who is responsible for soliciting bids). If desired, the webpage can limit the results to the best pricing received (or a range of prices), or all of the results can be made available to the vehicle operator.
- While the monitoring service will endeavor to provide a plurality of repair options to the vehicle operator, based on the vehicle operator's restrictions on repair vendors, or the location of the vehicle (i.e., a remote area where few repair vendors are located), in some circumstances there may be only one repair option available, and in extreme circumstances - none.
- exemplary (but not limiting) information displayed herein includes details on the identified mechanical fault (in this example, the mechanical fault is a defective fuel injector), an estimated amount of time required for the repair (most vendors use standardized tables/databases to determine the time required for repairs, or such information can be obtained by using a diagnostic application employed by the monitoring service or the individual repair vendor), the pricing data for each repair vendor (as illustrated, such pricing data is broken out by labor and parts, although it should be understood that the pricing data can simply be provided as a total price), the name and address of each repair vendor, the availability of the repair vendor (Vendor 1, Brett's Truck Repair, has a 1 day wait for the repair, while Vendor 2, Bill's Diesel Service, can perform the repair immediately), a distance between the vehicle and the repair vendor, and a performance rating (wrench icons 108a- 108c) for each repair vendor (where a greater number of wrench icons or other type of graphic device indicates a better performance rating, recognizing that while only full icons
- Radio buttons 1 lOa-c can be used by the vehicle operator to select the repair vendor who should perform the repair work.
- the performance ratings are based on work performed by the vendor in connection with a previous repair brokered by the monitoring service, while in at least one embodiment the rankings are based on (or include) performance ratings obtained from a search (performed by the monitoring service) of public comments posted on the Internet about particular vendors.
- webpage 100 it should be understood that the design of webpage 100 is intended to be exemplary, and different webpage designs can be employed, and further, that the data on webpage 100 can be provided to the vehicle operator on more than one webpage. If desired, access to webpage 100 can be restricted only to the monitoring service and vehicle operator. However, providing repair vendors access to webpage 100 will enable the repair vendors to see competing bids, encouraging repair vendors to reduce their bids during the reverse auction to provide the best price to the vehicle operator. It should also be understood that a different webpage could be generated for use during the reverse auction, such that webpage 100 need not be accessible by the repair vendors.
- the service vendors in results section 104 are identified by name, address, and telephone number. It should be recognized that the concepts disclosed herein also encompass embodiments in which one or more of the service vendor's name, address, and telephone number (or other information that can be used to uniquely identify the service vendor) is withheld from the consumer, in order to make it difficult for the consumer to arrange for service directly with the service vendor, and bypass the pricing service provider. Such an embodiment will be important to pricing service providers who charge either the consumer or the service vendor a fee for facilitating the transaction. Once the fee earned by the pricing service provider has been paid, then the service vendor's identification information will be provided.
- FIGURE 6 is a high level logic diagram showing exemplary overall method steps implemented in accord with the concepts disclosed herein to host a reverse auction for a diagnosed repair to a vehicle. This process is implemented after the monitoring service (or the vehicle system or vehicle operator) identifies a mechanical fault in a vehicle (i.e., FIGURE 6 corresponds to block 18 in FIGURE IF). Note a reverse auction can also be implemented when a pricing service provider receives one or more of the inputs identified in FIGURE IB, such as a consumer determining that their vehicle needs new tires.
- the monitoring service (when the pricing service provider and monitoring service are the same entity) or the pricing service provider (i.e., the remote computing device operated by the monitoring service or by the pricing service provider) selects a plurality of service vendors from which pricing data will be solicited. The selection process can be based on a number of factors, including but not limited to the location of the service vendor, and restrictions on service vendors defined by the consumer, generally as discussed above.
- the monitoring service (when the pricing service provider and monitoring service are the same entity) or the pricing service provider (i.e., the remote computing device operated by the monitoring service or by the pricing service provider) defines parameters of the reverse auction.
- Those parameters will include the identity of the mechanical fault that needs to be repaired (or a well defined service request, or a poorly defined service request and vehicle performance data that can be used to diagnose the required service, generally as discussed above with respect to the inputs of FIGURE IB) the desired service, and the time period of the reverse auction. Where the repair is not time critical, a relatively longer reverse auction may enable the vehicle operator to receive better pricing. However, in some cases, time will be of the essence, and the timeline of the reverse auction will be relatively short, so the repair can be effected promptly.
- the parameters may include data enabling individual service vendors to perform their own diagnosis based on data provided by the monitoring service.
- the monitoring service (when the pricing service provider and monitoring service are the same entity) or the pricing service provider (i.e., the remote computing device operated by the monitoring service or by the pricing service provider) sends the parameters of the reverse auction to the selected vendors.
- this step is implemented using email, but other approaches might instead be used, such as an RSS message or a social/professional network transmission.
- the monitoring service (when the pricing service provider and monitoring service are the same entity) or the pricing service provider (i.e., the remote computing device operated by the monitoring service or by the pricing service provider) hosts the reverse auction for the defined time period.
- service vendors can visit a website operated by the monitoring service and place their bid on the required repair.
- service vendors are allowed to reduce their bid amount during the auction, in response to bids placed by other service vendors.
- service vendors in addition to providing pricing data, service vendors will include in their bid a commitment of when the repair work can be started (and/or completed), which will enable the vehicle operator to select a service vendor with a slightly higher price who can complete a repair immediately, over the lowest priced vendor who cannot perform the repair immediately.
- the diagnosis data and the reverse auction results are conveyed to the vehicle owner, for example, by at least one of text message, email, and an automated telephone call (i.e., a robocall).
- the vehicle operator or consumer can be contacted when the reverse auction begins, and can be allowed access to the website where the reverse auction is being hosted, so the vehicle operator can monitor the progress of the reverse auction.
- the monitoring service or pricing service provider will use a well-known or trusted diagnostic software application to perform the diagnosis, or to verify a diagnosis.
- a well-known or trusted diagnostic software application will likely encourage repair vendors to provide better pricing. Vendors such as Navistar, Detroit Diesel, and Snap-on Tools offer such diagnostic software applications.
- the monitoring service when the pricing service provider and monitoring service are the same entity or the pricing service provider, will, in lieu of or in addition to performing a diagnosis, send vehicle data to the repair vendors, so the repair vendors can perform their own diagnosis using a diagnostic software application of their own choosing.
- the monitoring service when the pricing service provider and monitoring service are the same entity or the pricing service provider will determine that requesting pricing from service vendors is warranted based on at least one of the following: the generation of a fault code in the vehicle, the activation of a warning light in the vehicle, the detection by the monitoring service of an anomaly in vehicle data conveyed from the vehicle to the monitoring service, and the diagnosis of a fault by the monitoring service using vehicle data conveyed from the vehicle to the monitoring service.
- operational data represents one type of performance data that can be conveyed to the remote monitoring service.
- a majority of vehicles manufactured today already include components to collect operational data during operation of the vehicle. Such data is used during operation of the vehicle, to provide feedback to control many vehicle systems, including but not limited to engine fuel supply components, vehicle braking components, vehicle cooling components, and vehicle transmission components. Conventionally, such data is generated, used by the vehicle immediately, and discarded.
- each time a data transmission from the vehicle to the remote monitoring service occurs at least a portion of the operational data currently generated by the vehicle is included in the data transmission (the amount of operational data available at any given time is likely too large to be transmitted in total, so some portion of the readily available operational data is selected, and the rest discarded as usual).
- enrolled vehicles can optionally include a data buffer or memory storage in which operational data is temporarily stored. Further modifications include configuring a processor in the vehicle to convey detected vehicle anomalies (such as fault codes) and to define an anomaly both as the generation of a fault code, and when a measurable vehicle parameter (engine temperature, oil pressure, oil temperature, etc.) exceeds or falls below a predefined value.
- a vehicle processor can be configured to send a data transmission to the remote monitoring service whenever an anomaly is detected.
- Such a data transmission can include an identification of the anomaly (i.e., the fault code that was generated or the parameter that exceeded or fell below the predefined value).
- the operational data and fault code data are conveyed in real-time to the monitoring service, so that a diagnosis of a vehicle problem causing the generation of the fault code can occur while the vehicle is operating. Rapid diagnosis of problems can lead to the prevention of damage to the vehicle that might otherwise be caused by continuing to operate the vehicle after a malfunction is detected, where the diagnosis indicates that continued operation of the vehicle would result in such damage. In such circumstances, the driver of the vehicle can be contacted by telephone or other electronic messaging service or data link to ensure that continued operation of the vehicle does not occur. If the diagnosed problem is relatively minor, the operator of the vehicle can be contacted with less urgency, to arrange for a repair when convenient.
- the results of the vehicle diagnosis are forwarded to the vehicle operator, results from the reverse auction for the required repair are generated, service for the vehicle is scheduled, and parts required for the service are ordered, all while the vehicle continues to operate.
- operational data is archived whenever a specific user defined operating parameter condition is detected, i.e., an operating parameter above or below a predefined limit.
- this approach enables a user to define a custom fault code library (it is recognized that prior art fault codes are tied to specific operating parameters; however, prior art fault codes are predefined at the vehicle manufacturer level, and are not user modifiable or user defined).
- Such user defined fault codes can include any user defined single operational parameter level, or a combination of user defined operational parameter levels, that are different from the fault codes defined at the vehicle manufacturer level.
- systems implementing the concepts disclosed herein are configured so that user defined fault codes can be defined and implemented while the vehicle is operating.
- user defined fault codes are generated at a remote computing device attempting to acquire additional information to be used to diagnose a vehicle, where the user defined fault code is uniquely defined based on archived operational data conveyed to the remote computing device while the vehicle is operating.
- the operational data that is temporarily stored on the vehicle can include operational data that is automatically broadcast by the vehicle while the vehicle is operating.
- the temporarily stored operational data includes operational data that must be specifically requested.
- the temporarily stored operational data includes both operational data that is automatically broadcast by the vehicle while the vehicle is operating and operational data that must be specifically requested.
- operational data that must be requested is operational data that can be generated upon request (such as throttle position data), but is not data that is required during normal vehicle operation.
- FIGURE 7 is another functional block diagram showing the components of a vehicle diagnostic system in accord with the concepts disclosed herein, wherein the performance data includes temporarily stored operational data, and the data link and data buffer are combined into a single component to be added to a vehicle to enable the vehicle to participate in the diagnostic/monitoring program.
- a system 62 includes a vehicle 64 and a remote computing device 72 for performing diagnostic analysis on data supplied by the vehicle over a wireless network 70. The data can be input by an operator or can be collected using the portable data collection device as described above.
- Vehicle 64 can also include a plurality of components for collecting operational data, including a brake control unit 66a, an engine control unit 66b, and a transmission control unit 66c, each of which transmit operational data along a data bus 67. While only a single data bus is shown, it should be understood that multiple data buses could be employed. Further, a vehicle controller/processor, such as is shown in FIGURE 3, is not illustrated in FIGURE 7, but one or more such elements can be coupled to the data bus to receive and use operational data generated by the vehicle. Vehicle 64 also includes an add-on diagnostic unit 68, which combines a data temporary storage, a data link, and a processor.
- Diagnostic unit 68 conveys diagnostic logs 76 from vehicle 64 to remote computer 72 via wireless network 70, generally as discussed above. Diagnostic logs 76 include an identified anomaly (such as a fault code) and data temporarily stored in the memory storage of diagnostic unit 68. Remote computer 72 analyzes the diagnostic logs to determine a cause of the anomaly. Remote computer 72 conveys data 74 (which includes one or more of configuration data and diagnostic data) to diagnostic device 68 via the wireless network. The configuration data is used to modify the functions implemented by the processor in diagnostic unit 68.
- Modifications include, but are not limited to, changing the amount of operational data to be temporarily stored in the data memory storage, changing an amount of operational data collected before an anomaly is conveyed to the remote computing device, changing an amount of operational data collected after an anomaly is conveyed to the remote computing device, changing a type of operational data conveyed to the remote computing device (this enables the remote computing device to request specific types of operational data after a diagnostic log has been received, to facilitate diagnosing the anomaly), and changing a definition of what constitutes an anomaly.
- the diagnostic data includes data conveyed to the operator of the vehicle, informing the operator of any actions that the operator needs to take in response to the diagnosis.
- Such diagnostic data can include instructions to cease vehicle operation as soon as possible to avoid unsafe or damaging conditions, instructions to proceed to a designated repair facility selected by the operator as a result of the reverse auction, and/or instructions to proceed with a scheduled route, and to wait to repair the vehicle at a point along the route or after the route is complete.
- diagnostic device 68 is implemented by using a hardware device permanently or temporarily installed onboard medium and heavy duty (Class 5-8) vehicles, energized by onboard vehicle electrical power systems, and connected to the in-vehicle diagnostic data communications network, which is capable of collecting diagnostic data from the vehicle data communications network and sending it to a remote server.
- the specific information to be acquired from the vehicle communications data link is remotely configurable.
- the specific data messages that trigger a data collection event are also remotely configurable.
- Data transmission from the vehicle includes a wireless interface between the vehicle and the remote server, such as via a cellular modem or other wireless data transmission network. Data received at the remote server may then be forwarded to any defined set of consumers for the diagnostic information to be remotely analyzed and acted upon.
- the components of system 62 include the hardware device used to implement diagnostic device 68, hardware programming (firmware), the wireless network, and the remote computing device (such as a computer server/data center).
- System 62 operates by using the remote computing device to transmit programming/configuration data to the in-vehicle device (i.e., diagnostic device 68) via the wireless network.
- the diagnostic data device stores operational data that is included with all diagnostic log events (i.e., with each fault code or detected anomaly).
- the diagnostic log conveyed to the remote computing device from the vehicle includes data such as a diagnostic log file revision, a diagnostic log file type, a device ID, a configured time interval defining the extent of the temporarily stored operational data, and the number of parameters to be stored in the diagnostic log files.
- the diagnostic data device in the vehicle performs the functions of: storing a list of diagnostic parameters to be monitored and recorded from the vehicle data link at regular periodic intervals (or as otherwise defined); storing a list of event parameters to trigger diagnostic data capture; and storing a time interval for diagnostic parameter recording.
- the diagnostic data device is connected to an in-vehicle data link (e.g., a J 1939 bus) and vehicle power connections.
- diagnostic data device is continuously monitoring for specific data messages configured to trigger the collection of diagnostic log files. Once diagnostic log files are recorded, they are transmitted via the wireless network to the remote computing device. Diagnostic log files are moved from the data center server within minutes to a destination server where the data may be analyzed and/or distributed for further action.
- the diagnostic log sent to the remote computing device includes one minute worth of operational data collected both before and after an anomalous event.
- the diagnostic device in the vehicle can be remotely configured to redefine the parameters used to generate a diagnostic log.
- the diagnostic log generated by the diagnostic device includes two primary components; at least some of the operational data temporarily stored in the data memory storage, and data defining the anomaly (in some embodiments, fault codes are used to define the anomaly).
- the diagnostic device can be remotely reconfigured to change an amount of buffered operational data acquired before the anomaly that is included in the diagnostic log.
- the diagnostic device can be remotely reconfigured to change an amount of temporarily stored operational data acquired after the anomaly that is included in the diagnostic log.
- the diagnostic device can be remotely reconfigured to change the type of operational data that is included in the diagnostic log (in terms of FIGURE 7, the diagnostic device can be remotely reconfigured to selectively determine whether data from brake control unit 66a, data from engine control unit 66b, and/or data from transmission control unit 66c should be included in the diagnostic log, noting that such operational data generating components are exemplary, and not limiting).
- the diagnostic device can also be remotely reconfigured to define what constitutes an anomaly that triggers sending a diagnostic log to the remote computing device for diagnosis. As discussed above, fault codes defined by the vehicle manufacturer can be considered to be anomalies that will trigger conveying a diagnostic log to the remote location.
- the concepts disclosed herein encompass enabling the diagnostic device to be remotely reconfigured to define a single parameter or a set of parameters (different than the parameters used by manufacturers to define fault codes) that will trigger the conveyance of diagnostic log to the remote location.
- the diagnostic device can be remotely reconfigured to generate and convey a diagnostic log to the remote location in response to detecting any specified parameter or set parameters in regard to the value(s) of the parameters exceeding or falling below predefined level(s).
- FIGURE 8 is a functional block diagram showing a pricing service provider 73, a consumer 71, and a plurality of service vendors 75a-75c interacting over the Internet.
- FIGURE 8 is related to FIGURE 7, but FIGURE 7 is directed to a specific embodiment where the pricing service provider and a vehicle monitoring service are the same entity, whereas, FIGURE 8 is more generalized, and encompasses each of the inputs illustrated in FIGURE IB.
- consumer 71 uses a wireless network 70 (such as the Internet) to communicate a service request (either a well defined service request without vehicle performance data, or a less well defined service request with vehicle performance data enabling a service diagnosis to be made by pricing service provider 73 and/or service vendors 75a-75c) to pricing service provider 73, who in turn requests pricing for the requested vehicle service from a plurality of service vendors 75a- 75c (noting the number of service vendors in FIGURE 8 is exemplary, and not limiting).
- the pricing service provider communicates the pricing data to the consumer, generally as discussed above.
- FIGURE 9 schematically illustrates an exemplary kit 230, designed to facilitate an interaction between a smart phone user and a pricing service provider.
- Kit 230 includes a hardware interface 234 than enables the smart phone user to extract vehicle performance data from the vehicle into their smart phone as an electronic data file.
- the vehicle performance data can be used by the pricing service provider, and/or service vendors to identify the service needs of the smart phone user's vehicle.
- the hardware interface will include a first data port configured to interface with the vehicle, and a second data port configured to interface with the smart phone.
- OBD-I and OBD-II hardware ports are well known in the vehicle industry. The use of a well adopted vehicle data port to extract the vehicle performance data into the smart phone means that the first data port on the hardware interface will be compatible with many vehicles. It should also be understood that various adapters can be provided with kit 230, to accommodate less widely used vehicle data ports. Further, hardware interface 234 can be provided with multiple first data ports, each having a form factor designed to interface with a different style vehicular data port (i.e., hardware interface 234 could be provided with both an ODB-I style connector and an OBD-II style connector, or some other connector commonly found in commercial vehicles and heavy trucks).
- the second data port of hardware interface 234 may be customized to interface with specific models of smart phones, such that different phones will require a different kit (another option would be to include a plurality of different adaptors with the kit, enabling the same second data port to interface with smart phones having data ports exhibiting different form factors).
- Optional elements to include in kit 230 are software 232 (to be added to the smart phone to facilitate interaction with the pricing service provider), a hardware interface 236 (for exporting vehicle performance data from the smart phone to a desktop or laptop computer, so the consumer can use the Internet to communicate with the pricing service provider, even if their smart phone is not web enabled), and instructions 238 (including but not limited to instructions for using hardware interface 234, instructions for interacting with the pricing service provider, instructions for extracting vehicle performance date from a vehicle, instructions for using software 232, and instructions for formulating a service request to be sent to the pricing service provider).
- software 232 to be added to the smart phone to facilitate interaction with the pricing service provider
- a hardware interface 236 for exporting vehicle performance data from the smart phone to a desktop or laptop computer, so the consumer can use the Internet to communicate with the pricing service provider, even if their smart phone is not web enabled
- instructions 238 including but not limited to instructions for using hardware interface 234, instructions for interacting with the pricing service provider, instructions for extracting vehicle performance date from a vehicle
- Software 232 can be used to improve the user experience for the smart phone user, as smart phones do not have the graphics processing power (and certainly not the screen size) as desktop computers. For example, in at least one embodiment, software 232 can help improve the visualization of websites intended to be viewed on larger screens.
- the smart phone user can employ their smart phone not only to convey the service request and vehicle performance data to the pricing service provider, but also to perform any of the following functions: receiving pricing quotes from the pricing service provider, scheduling a service from a specific vendor, and paying the pricing service provider and/or the selected service vendor. Such payments can be implemented based on verbal communication, or by using a web enabled smart phone to convey an electronic payment.
- a first system for receiving a vehicle service request for a specific vehicle and providing pricing data from one or more vendors able to provide service for the vehicle including: (a) a memory in which a plurality of machine instructions are stored; (b) a data link for receiving the vehicle service request; and (c) a processor coupled to the memory and to the data link.
- said processor executes the machine instructions to carry out a plurality of functions, including: (i) in response to receiving the vehicle service request, conveying vehicle information to a plurality of vendors, to enable each vendor interested in responding to the vehicle service request to provide a price quote for their services; and (ii) in response to receiving a price quote from a vendor, conveying the price quote to at least one entity selected from a group of entities consisting of: (A) an operator of the vehicle; and (B) a third party able to convey the price quote to the operator of the vehicle.
- the machine instructions cause the processor to convey the price quote using at least one communication technique selected from a group of communication techniques consisting of: (a) communicating the price quote via email; (b) communicating the price quote via a text message on a cellular phone; (c) communicating the price quote via a voicemail message; (d) generating a webpage upon which vendor information can be viewed, the vendor information including information about the vendor and the vendor's price quote; and (e) updating a previously generated webpage to add vendor information for an additional vendor.
- the webpage displays a reverse auction and each vendor can access the webpage and adjust their price quote based on price quotes offered by other vendors, in order to stimulate competitive price quotes.
- the vehicle service request comprises electronic vehicle performance data collected from the vehicle
- the machine instructions cause the processor to implement at least one of the following functions: (a) the function of conveying the electronic vehicle performance data to each vendor, so each vendor can independently diagnose what service is required based on the electronic vehicle performance data; and (b) the function of using the processor to analyze the electronic vehicle performance data to diagnose what service is required, where the analysis is implemented before the vehicle information is conveyed to the plurality of vendors, such that the service diagnosis is included in the vehicle information conveyed to each vendor.
- a first non-transitory memory medium having machine instructions stored thereon for receiving a vehicle service request for a specific vehicle and providing pricing data from one or more vendors able to provide service for the vehicle, the machine instructions, when implemented by a processor, carrying out the functions of: (a) in response to receiving the vehicle service request, conveying vehicle information to a plurality of vendors, to enable each vendor interested in responding to the vehicle service request to provide a price quote for their services; and (b) in response to receiving a price quote from a vendor, conveying the price quote to at least one entity selected from a group of entities consisting of: (i) an operator of the vehicle; and (ii) a third party able to convey the price quote to the operator of the vehicle.
- the above identified first non-transitory memory medium wherein the machine instructions, when implemented by the processor, implement the function of conveying the price quote using at least one communication technique selected from a group of communication techniques consisting of: (a) communicating the price quote via email; (b) communicating the price quote via a text message on a cellular phone; (c) communicating the price quote via a voicemail message; (d) generating a webpage accessible by at least one of the vehicle operator and the third party upon which vendor information can be viewed, the vendor information including information about the vendor and the vendor's price quote; and (e) updating a previously generated webpage to add vendor information for an additional vendor.
- a group of communication techniques consisting of: (a) communicating the price quote via email; (b) communicating the price quote via a text message on a cellular phone; (c) communicating the price quote via a voicemail message; (d) generating a webpage accessible by at least one of the vehicle operator and the third party upon which vendor information can be viewed, the vendor information including information about the vendor and the vendor
- the above identified first non-transitory memory medium wherein the machine instructions, when implemented by the processor, further carry out the function of communicating at least one type of additional information selected from a group of additional information consisting of: (a) an indication of how quickly each vendor can provide service for the vehicle, based on data provided by each vendor; and (b) a distance between the vehicle and each vendor, based on vehicle location data included in the vehicle service request.
- a group of additional information consisting of: (a) an indication of how quickly each vendor can provide service for the vehicle, based on data provided by each vendor; and (b) a distance between the vehicle and each vendor, based on vehicle location data included in the vehicle service request.
- the above identified first non-transitory memory medium wherein the machine instructions cause the processor to implement at least one of the following functions: (a) the function of conveying the electronic vehicle performance data to each vendor, so each vendor can independently diagnose what service is required based on the electronic vehicle performance data; and (b) the function of using the processor to analyze the electronic vehicle performance data to diagnose what service is required, where the analysis is implemented before the vehicle information is conveyed to the plurality of vendors, such that the service diagnosis is included in the vehicle information conveyed to each vendor.
- a first method having the function of providing pricing data to a consumer of vehicle services, the first method including the steps of: (a) receiving a vehicle service request for servicing a specific vehicle at a computing device remote from the vehicle; (b) using the remote computing device to convey vehicle information to a plurality of vendors, to enable each vendor interested in responding to the vehicle service request to provide a price quote for their services; and (c) in response to receiving a price quote from a vendor, using the remote computing device to convey the price quote to at least one entity selected from a group of entities consisting of: (i) an operator of the vehicle; and (ii) a third party able to convey the price quote to the operator of the vehicle.
- step of using the remote computing device to convey vehicle information to a plurality of vendors comprises the step of hosting a reverse auction for servicing the vehicle based on the vehicle service request, wherein any vendor interested in servicing the vehicle enters a bid in the reverse auction.
- the above identified first method wherein the step of using the remote computing device to convey the price quote is implemented in a manner that withholds vendor identification information, such that the vehicle operator and vendor cannot complete a transaction without interacting with a party implementing the method.
- the step of using the remote computing device to convey the vehicle information to the plurality of vendors comprises the step of conveying electronic vehicle performance data from the vehicle, so each vendor can independently diagnose what service is required based on the electronic vehicle performance data.
- the step of using the remote computing device to convey the price quote is implemented using at least one communication technique selected from a group of communication techniques consisting of: (a) communicating the price quote via email; (b) communicating the price quote via a text message on a cellular phone; (c) communicating the price quote via a voicemail message; (d) generating a webpage upon which vendor information can be viewed, the vendor information including information about the vendor and the vendor's price quote; and (e) updating a previously generated webpage to add vendor information for an additional vendor.
- the step of generating the webpage comprises generating a webpage that displays a reverse auction and each vendor can access the webpage and adjust their price quote based on price quotes offered by other vendors, in order to stimulate competitive price quotes.
- the above identified first method further comprising the step of using the remote computing device to convey at least one type of additional information along with the price quote, the at least one type of additional information being selected from a group of additional information consisting of: (a) an indication of how quickly each vendor can provide service for the vehicle, based on data provided by each vendor; and (b) a distance between the vehicle and each vendor, based on vehicle location data included in the vehicle service request.
- the step of using electronic vehicle performance data from the vehicle to diagnose what service is required based on the electronic vehicle performance data comprises the step of comparing the electronic vehicle performance data to a plurality of data records, each data record corresponding to a different mechanical fault.
- the step of receiving a vehicle service request for servicing a specific vehicle comprises the step of receiving the vehicle service request at a pricing service provider, and further comprising the step of conveying the vehicle service request to the pricing service provider, where the party conveying the vehicle service request to the pricing service provider comprises at least one party selected from a group of parties consisting of: (a) an owner of the vehicle; (b) an operator of the vehicle; (c) a fleet operator; (d) a private individual consumer; and (e) a third party monitoring service that monitors data acquired form the vehicle to determine service needs of the vehicle.
- a second system for automatically receiving information about a mechanical fault on a vehicle and providing an operator of the vehicle with pricing data for one or more vendors willing to repair the mechanical fault including: (a) a memory in which a plurality of machine instructions are stored; (b) a data link for automatically receiving information about the mechanical fault from the vehicle; and (c) a processor coupled to the memory and to the data link, said processor executing the machine instructions to carry out a plurality of functions, including: (i) receiving the information about the mechanical fault from the vehicle; (ii) based upon the mechanical fault, conveying data defining the mechanical fault to a plurality of vendors able to repair the mechanical fault, to enable each vendor interested in repairing the vehicle to provide pricing quotes for the vendor to repair the mechanical fault; and (iii) conveying to the operator of the vehicle information about the mechanical fault and the pricing data from any vendors interested in repairing the vehicle.
- the machine instructions cause the processor to generate a webpage that the operator of the vehicle can access to determine the pricing data for the repair provided by any vendor interested in repairing the vehicle.
- the webpage that was generated provides the following information to the operator of the vehicle: (a) an indication of how quickly each vendor can start the repair, based on data provided by each vendor; (b) a cost for completing the repair charged by each vendor; and (c) a distance between a vehicle location where the vehicle will be located when it is to be repaired and a location of each vendor, wherein the vehicle location is based either on a current vehicle location provided by a position sensing component at the vehicle, or a future vehicle location where the vehicle will be when the repair is desired.
- the webpage that is generated provides a rating of each vendor.
- the rating is displayed on the webpage as at least one graphic icon adjacent to an identification of the vendor, where a relatively greater number of graphic icons indicates a relatively better rating for the vendor, wherein at least one such graphic icon comprises a wrench.
- the machine instructions cause the processor to inform the operator of the vehicle of at least one of the following: (a) an indication of how quickly each vendor can start the repair, based on data provided by each vendor; (b) a rating of each vendor; and (c) a distance between a vehicle location where the vehicle will be located when it is to be repaired and a location of each vendor, wherein the vehicle location is based either on a current vehicle location provided by a position sensing component at the vehicle, or a future vehicle location where the vehicle will be when the repair is desired.
- the above identified second system wherein the information received from the vehicle indicates the mechanical fault that requires repair.
- the information received from the vehicle is either manually input by the operator of the vehicle or is provided by a portable data collection device used to conduct an inspection of the vehicle.
- a second non-transitory memory medium having machine instructions stored thereon for automatically receiving information about a mechanical fault on a vehicle and providing an operator of the vehicle with pricing data for one or more vendors willing to repair the mechanical fault, the machine instructions, when implemented by a processor, carrying out the functions of: (a) receiving the information about the mechanical fault from the vehicle; (b) based upon the mechanical fault, conveying data defining the mechanical fault to a plurality of vendors able to repair the mechanical fault, to enable each vendor interested in repairing the vehicle to provide pricing quotes for the vendor to repair the mechanical fault; and (c) conveying to the operator of the vehicle information about the mechanical fault and the pricing data for the repair.
- the machine instructions when implemented by the processor, further carry out the function of generating a webpage that the operator of the vehicle can access to determine the pricing data for the repair provided by any vendor interested in repairing the vehicle.
- the machine instructions when implemented by the processor, further carry out the function of provide a rating of each vendor, wherein the rating is displayed on the webpage as at least one graphic icon adjacent to an identification of the vendor, where a relatively greater number of graphic icons indicates a relatively better rating for the vendor.
- (c) conveying to the operator of the vehicle information defining a distance between a vehicle location where the vehicle will be located when it is to be repaired and a location of each vendor, wherein the vehicle location is based either on a current vehicle location provided by a position sensing component at the vehicle, or on a future vehicle location where the vehicle will be when the repair is desired.
- a second method having the function of responding to detection of a mechanical fault on a vehicle and providing the operator of the vehicle with pricing data from vendors interested in repairing the mechanical fault, the second method including the steps of: (a) automatically collecting vehicle data from the vehicle, the vehicle data including location data corresponding to a location of the vehicle and performance data provided either by at least one sensor in the vehicle, or by the operator of the vehicle, or by a portable data collection device used during an inspection of the vehicle; (b) wirelessly transmitting the vehicle data to a remote site; (c) based upon the vehicle data received by the remote site, determining if there is a mechanical fault with the vehicle; (d) if there is a mechanical fault with the vehicle, automatically transmitting information about the mechanical fault to a plurality of vendors who might be interested in repairing the mechanical fault, enabling any vendor interested in repairing the mechanical fault to provide pricing data for repairing the mechanical fault; and (e) conveying information to the operator of the vehicle identifying the mechanical fault and providing the pricing data obtained from each vendor interested
- the above identified second method wherein the step of wirelessly transmitting the vehicle data to the remote site comprises the step of wirelessly transmitting the vehicle data to a vehicle monitoring service in real-time.
- the above identified second method further comprising the step of, at the remote site, comparing the vehicle data to a plurality of data records, each data record corresponding to a different mechanical fault.
- step of automatically transmitting the information about the mechanical fault comprises the steps of:
- the above identified second method wherein the step of enabling any vendors interested in repairing the mechanical fault to provide the pricing data comprises the step of hosting a reverse auction for such vendors to bid on repairing the mechanical fault.
- the step of generating the webpage comprises the step of generating a webpage that provides the following information to the operator of the vehicle: (a) an indication of how quickly each vendor can start the repair, based on data provided by each vendor interested in repairing the mechanical fault; (b) a cost of the repair indicated by each vendor; and (c) a distance between a vehicle location where the vehicle will be located when it is to be repaired and a location of each vendor, wherein the vehicle location is based either on a current vehicle location provided by a position sensing component at the vehicle, or on a future vehicle location where the vehicle will be when the repair is desired.
- the step of generating the webpage comprises the step of generating a webpage configured to provide a rating of each vendor.
- the rating is displayed on the webpage as at least one graphic icon adjacent to an identification of a vendor, where a relatively greater number of graphic icons indicates a relatively better rating.
- the step of conveying information to the operator of the vehicle about the mechanical fault and the pricing data for the repair comprises the step of informing the operator of the vehicle of at least one of the following: (a) how quickly each vendor can start the repair, based on data provided by each vendor; (b) a rating of each vendor; and (c) a distance between a vehicle location where the vehicle will be located when it is to be repaired and a location of each vendor, wherein the vehicle location is based either on a current vehicle location provided by a position sensing component at the vehicle, or on a future vehicle location where the vehicle will be when the repair is desired.
- step of conveying information to the operator of the vehicle about the mechanical fault and the pricing data for the repair comprises the step of using at least one of the following types of communication: (a) a webpage; (b) a text message; (c) an email; and (d) an automated telephone call.
- a first geographical position system for use in a vehicle, the geographical position system comprising: (a) a housing; (b) a position sensing component for collecting geographical position data from the vehicle during vehicle operation, the geographical position data being time indexed; (c) at least one data port for receiving vehicle performance data for the vehicle; (d) a data link for wirelessly conveying the vehicle performance data and position data from the vehicle to a remote location to indicate any mechanical fault on the vehicle requiring repair; and (e) a processor that executes machine instructions to implement the following functions: (i) using the data link to convey a first type of vehicle performance data to the remote location during a first data transmission; and (ii) using the data link to convey a second type of vehicle performance data to the remote location during a second data transmission, the first data transmission and the second data transmission being executed at different times, a time period between the subsequent data transmissions being a function of at least one of a predetermined time interval and the detection of a predetermined condition.
- the above identified first geographical position system wherein the processor includes vehicle position data in each data transmission.
- the processor determines if the vehicle has collected any additional types of vehicle performance data not included in the first data transmission and the second data transmission, and if so, transmits a third type of vehicle performance data in a third data transmission.
- the above identified first geographical position system wherein the processor transmits vehicle performance data that includes information input either by the operator of the vehicle, or from a portable data collection device used during an inspection of the vehicle.
- the above identified first geographical position system wherein the processor is configured to receive instructions from the remote location defining a type of vehicle performance data to be conveyed to the remote location, such that the requested type of vehicle performance data is conveyed to the remote location in a subsequent data transmission.
- the above identified first geographical position system wherein the vehicle processor is configured to initiate a new data transmission in response to determining a change in the vehicle's heading.
- a third method having the function of obtaining servicing for a specific vehicle, the third method including the steps of: (a) importing vehicle performance data from the vehicle into a smart phone; and (b) using the smart phone to convey a service request including the vehicle performance data to a pricing service provider, who obtains pricing data from a plurality of vendors.
- the above identified third method further comprising at least one step selected from a group of steps consisting of: (a) using the smart phone to receive a communication from the pricing service provider, the communication including at least a price quote from at least one vendor for servicing the vehicle; (b) using the smart phone to convey a scheduling request to the pricing service provider for a specific price quote identified in the communication received from the pricing service provider; and (c) using the smart phone to convey a payment to at least one party selected from a group of parties consisting of the pricing service provider and a vendor who submitted a specific price quote identified in the communication received from the pricing service provider.
- a first kit for enabling a consumer to obtain pricing data for servicing a specific vehicle comprising: (a) a hardware interface for extracting vehicle performance data from the vehicle into a smart phone; and (b) instructions for implementing at least one of the functions selected from a group of functions consisting of: (i) the function of using the hardware interface for extracting vehicle performance data from the vehicle into a smart phone; (ii) the function of conveying the extracted vehicle performance data and a pricing request to a pricing service provider; and (iii) the function of acquiring a software application for the smart phone to facilitate interactions between the consumer and the pricing service provider.
- a third system for detecting a mechanical fault with a vehicle and providing the operator of the vehicle with pricing data from vendors who can repair the mechanical fault comprising: (a) a vehicle comprising: (i) at least one sensor for generating vehicle operational data; (ii) a position tracking component for generating vehicle position data; and (iii) a data link for wirelessly conveying operational data and position data from the vehicle to a remote location during operation of the vehicle; and (b) a computing device at the remote location, the computing device being configured to implement the following functions: (i) monitor the vehicle operational data to identify a mechanical fault with the vehicle; (ii) after identifying the mechanical fault, conveying data defining the mechanical fault to a plurality of vendors able to repair the mechanical fault, so that such vendors can provide pricing data for repairing the mechanical fault, the plurality of vendors having been selected based on their location relative to the vehicle's current location as defined by the position data received from the vehicle, the data defining the mechanical fault enabling the plurality of vendors to participate
- a fourth system for detecting a mechanical fault with a vehicle and providing the operator of the vehicle with pricing data from vendors who are interested in repairing the mechanical fault comprising: (a) a vehicle that includes: (i) a plurality of sensors configured to generate different types of vehicle performance data; (ii) a data link for wirelessly conveying vehicle performance data from the vehicle to a remote location for analysis during operation of the vehicle; and (iii) a processor configured to implement the following functions: (1) using the data link to convey a first type of vehicle performance data to the remote location during a first data transmission; and (2) using the data link to convey a second type of vehicle performance data to the remote location during a second data transmission, the first data transmission and the second data transmission being executed at different times, a time period between the first data transmission and the second data transmission being a function of at least one of a predetermined time interval and the detection of a predetermined condition; and (b) a computing device at the remote location, the computing device being configured to implement the following functions: (i) a plurality of sensors
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Economics (AREA)
- Marketing (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Strategic Management (AREA)
- Finance (AREA)
- Human Resources & Organizations (AREA)
- Accounting & Taxation (AREA)
- Tourism & Hospitality (AREA)
- Entrepreneurship & Innovation (AREA)
- Development Economics (AREA)
- Quality & Reliability (AREA)
- Operations Research (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Primary Health Care (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Vehicle Cleaning, Maintenance, Repair, Refitting, And Outriggers (AREA)
Abstract
Description
Claims
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/956,961 US20120136802A1 (en) | 2010-11-30 | 2010-11-30 | System and method for vehicle maintenance including remote diagnosis and reverse auction for identified repairs |
US13/157,184 US10600096B2 (en) | 2010-11-30 | 2011-06-09 | System and method for obtaining competitive pricing for vehicle services |
US13/157,203 US20120136743A1 (en) | 2010-11-30 | 2011-06-09 | System and method for obtaining competitive pricing for vehicle services |
PCT/US2011/062480 WO2012075055A2 (en) | 2010-11-30 | 2011-11-29 | System and method for obtaining competitive pricing for vehicle services |
Publications (2)
Publication Number | Publication Date |
---|---|
EP2646969A2 true EP2646969A2 (en) | 2013-10-09 |
EP2646969A4 EP2646969A4 (en) | 2014-06-11 |
Family
ID=46172513
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP11845242.4A Ceased EP2646969A4 (en) | 2010-11-30 | 2011-11-29 | System and method for obtaining competitive pricing for vehicle services |
Country Status (2)
Country | Link |
---|---|
EP (1) | EP2646969A4 (en) |
WO (1) | WO2012075055A2 (en) |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
AU2012313346A1 (en) * | 2011-09-20 | 2013-05-23 | Jivi Pty Ltd | Automated system and method for job estimating, scheduling and administration |
US20130338873A1 (en) * | 2012-06-15 | 2013-12-19 | Harman International Industries, Inc. | Vehicle service auction systems and methods |
US9336244B2 (en) * | 2013-08-09 | 2016-05-10 | Snap-On Incorporated | Methods and systems for generating baselines regarding vehicle service request data |
WO2016179494A1 (en) * | 2015-05-07 | 2016-11-10 | Chalumeau Consulting Services, Llc | Merchant-traveler messaging systems and methods |
US20180082312A1 (en) * | 2016-09-21 | 2018-03-22 | Ford Global Technologies, Llc | Feedback for Vehicle Dealership or Service Providers |
JP2021163313A (en) * | 2020-04-01 | 2021-10-11 | 株式会社デンソー | Evaluation information confirmation system and server |
US11615660B2 (en) | 2020-11-17 | 2023-03-28 | Caterpillar Inc. | Identifying a failed turbocharger of a plurality of turbochargers |
US20240273476A1 (en) * | 2023-02-09 | 2024-08-15 | Blackberry Limited | Vehicle servicing |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050288830A1 (en) * | 2004-06-24 | 2005-12-29 | General Motors Corporation | Method and system for remote telltale reset |
US20060089767A1 (en) * | 2004-10-25 | 2006-04-27 | Sowa Michael A | Vehicles fault diagnostic systems and methods |
WO2007033311A2 (en) * | 2005-09-14 | 2007-03-22 | Wobb R W | Reverse auctioning system for automobile repair services |
JP2007102336A (en) * | 2005-09-30 | 2007-04-19 | Car Bid Japan:Kk | System and method for automobile repair auction |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6636790B1 (en) * | 2000-07-25 | 2003-10-21 | Reynolds And Reynolds Holdings, Inc. | Wireless diagnostic system and method for monitoring vehicles |
US8068951B2 (en) * | 2005-06-24 | 2011-11-29 | Chen Ieon C | Vehicle diagnostic system |
US20080040129A1 (en) * | 2006-08-08 | 2008-02-14 | Capital One Financial Corporation | Systems and methods for providing a vehicle service management service |
US8131417B2 (en) * | 2007-08-29 | 2012-03-06 | Driverside, Inc | Automotive diagnostic and estimate system and method |
US9014910B2 (en) * | 2007-12-07 | 2015-04-21 | General Motors Llc | Method and system for providing vehicle data to third party authorized recipients |
US20100257104A1 (en) * | 2008-08-14 | 2010-10-07 | Reza Bundy | Method and apparatus for repair procedure |
KR20100023434A (en) * | 2008-08-22 | 2010-03-04 | 엘지전자 주식회사 | Telematics device and method for providing car error service thereof |
-
2011
- 2011-11-29 EP EP11845242.4A patent/EP2646969A4/en not_active Ceased
- 2011-11-29 WO PCT/US2011/062480 patent/WO2012075055A2/en active Application Filing
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050288830A1 (en) * | 2004-06-24 | 2005-12-29 | General Motors Corporation | Method and system for remote telltale reset |
US20060089767A1 (en) * | 2004-10-25 | 2006-04-27 | Sowa Michael A | Vehicles fault diagnostic systems and methods |
WO2007033311A2 (en) * | 2005-09-14 | 2007-03-22 | Wobb R W | Reverse auctioning system for automobile repair services |
JP2007102336A (en) * | 2005-09-30 | 2007-04-19 | Car Bid Japan:Kk | System and method for automobile repair auction |
Non-Patent Citations (1)
Title |
---|
See also references of WO2012075055A2 * |
Also Published As
Publication number | Publication date |
---|---|
WO2012075055A2 (en) | 2012-06-07 |
WO2012075055A3 (en) | 2012-10-04 |
EP2646969A4 (en) | 2014-06-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US12125083B2 (en) | System and method for obtaining competitive pricing for vehicle services | |
US20170076344A1 (en) | System and method to prevent vehicle failures on public roadways | |
US12125082B2 (en) | System and method for obtaining competitive pricing for vehicle services | |
US20160071338A1 (en) | Diagnostic unit and method | |
US11810030B2 (en) | Roadside assistance service provider assignment system | |
US20190279444A1 (en) | Graphical user interface for efficiently viewing vehicle telematics data to improve efficiency of fleet operations | |
WO2012075055A2 (en) | System and method for obtaining competitive pricing for vehicle services | |
US9297721B2 (en) | Auto ID and fingerprint system and method thereof | |
US20140129080A1 (en) | System and method for recording driving patterns and suggesting purchasable vehicles | |
US20130246135A1 (en) | System, device and method of remote vehicle diagnostics based service for vehicle owners | |
US20060052921A1 (en) | On-demand system for supplemental diagnostic and service resource planning for mobile systems | |
US11132629B2 (en) | Crowdsourced roadside assistance service provider assignment system | |
US20150170439A1 (en) | Automotive fleet management system having an automated vehicle maintenance and repair referral | |
EP2674907A1 (en) | Vehicle service auction system and method | |
US20160110934A1 (en) | Automated Vehicle Health & Maintenance Predictor | |
US20240095686A1 (en) | Autonomous car repair | |
CA3113075C (en) | Crowdsourced roadside assistance service provider assignment system | |
US11954724B2 (en) | System and related methodology of using vehicle data in connection with the sale of a vehicle | |
WO2020036533A1 (en) | System and method for facilitating vehicle after-sales and maintenance services | |
WO2014091361A1 (en) | Vehicle evaluation and lead generation |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20130628 |
|
AK | Designated contracting states |
Kind code of ref document: A2 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
DAX | Request for extension of the european patent (deleted) | ||
A4 | Supplementary search report drawn up and despatched |
Effective date: 20140509 |
|
RIC1 | Information provided on ipc code assigned before grant |
Ipc: G06Q 10/00 20120101AFI20140502BHEP Ipc: G06Q 50/30 20120101ALI20140502BHEP Ipc: G06Q 30/00 20120101ALI20140502BHEP Ipc: G06Q 30/08 20120101ALI20140502BHEP |
|
17Q | First examination report despatched |
Effective date: 20180604 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R003 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED |
|
18R | Application refused |
Effective date: 20200112 |