Abstract:
A distributed vehicle valuation system provides actual wholesale, retail, purchase, and reconditioning prices of used automobiles based on actual transactional data retrieved from a plurality of dealership management systems. The distributed vehicle valuation system leverages a client-server, multi-tier software solution for collecting, mapping, and processing data from various dealership management systems in order to attain the necessary data. The data mining software resides on the dealership computer systems to mine such data from the dealership management systems and uploads the data to the central server. The data mining software is configured to mine and transmit data without any human intervention or interaction at the dealership. Such data includes actual wholesale sold amounts, actual retail sold amounts, actual purchase amounts and actual reconditioning amounts, as well as additional relevant information, such as stock date, sold date, gross profit, geographical data, etc.

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
       [0001]    This application is a continuation-in-part and claims the priority benefit of U.S. Non-Provisional patent application Ser. No. 11/380,001, filed Apr. 24, 2006, which is hereby incorporated herein by reference. 
     
    
     FIELD OF THE INVENTION 
       [0002]    This invention relates generally to valuation of used vehicles, and, more particularly, to a system and method of providing valuation data for used-vehicles based upon actual dealership information. 
       BACKGROUND 
       [0003]    In the used vehicle sales industry, Hearst Business Media Corporation&#39;s Black Book® guide, Kelley Blue Book Co., Inc.&#39;s Blue Book® guide and the National Automobile Dealers Association&#39;s NADA® guide are primary sources of vehicle valuation and appraisal information for dealers. The Black Book® guide places a vehicle for a particular model year in one of four classes depending on its condition and then provides a wholesale price based on the prices dealers pay for cars at auctions that are not open to consumers. Like the Black Book® guide, the Kelley Blue Book guide classifies vehicles based on their condition and provides wholesale prices that generally correspond to those in the Black Book guide and are based upon auction and new and used-car dealership data. The values from NADA® guide are based upon information gathered from new and used-car dealers, auto shows, trade periodicals, vehicle classifieds, magazines, newspapers, advisory boards, associations, and car clubs. Unlike Black Book® guide and Kelley Blue Book® guide prices, however, NADA prices do not vary with the vehicle&#39;s condition. The NADA® guide assumes that all vehicles are in excellent condition. Consequently, the prices in the NADA® guide are typically higher than prices in the Black Book® guide or Kelley Blue Book® guide. In each case, editors adjust accumulated sales data by mathematical factors and their own experience to provide their prices. Thus, the published prices are not actual sales data or even averages of actual sales data. Instead, they represent the publisher&#39;s own estimate for dealerships nationwide based primarily upon selected auctions, experience and subjective judgment. 
         [0004]    As a result of scheduling of auctions and the analysis required for each vendor&#39;s publication, each publication is updated and published periodically with a considerable lag between actual auctions and corresponding adjustment of published prices. By way of example, the Black Book® guide, which is published the most frequently (i.e., weekly), accounts for results from dealer-only auctions from about a week or two prior to publication. The NADA® guide is published monthly and Blue Book® is published bimonthly (i.e., 6 times per year), resulting in a more substantial delay between analysis and publication. While the publishers (and third parties) also offer computerized versions, the values are based upon information from the published guides. 
         [0005]    Another shortcoming of conventional valuation guides is that they focus primarily on auction data that accounts for a small percentage of used cars purchased by dealerships. The guides generally overlook trade-ins, dealer-to-dealer sales and consumer-to dealer transactions, which constitute the majority of used car acquisitions by dealers. 
         [0006]    Conventional valuation guides also do not provide different prices for different regions. Dealers in the northwest may use one guide more widely while dealers in the southeast may use another guide more widely, because they are known to concentrate on auctions in their respective areas. However, none of the guides offers valuations for specified geographic regions (e.g., state, city, zip) based upon transactions within the specified region. 
         [0007]    Conventional guides also fail to provide information useful for a dealership to fully evaluate the potential return on a used vehicle. For example, while conventional guides may supply retail price estimates, they do not provide a value of parts and labor typically required to restore a vehicle to a condition for resale. Likewise, conventional guides do not reveal how long a vehicle typically remains on a lot (nationwide or in a given geographic area) before it is resold. Furthermore, conventional guides do not provide market trend data that indicates what vehicles are selling well in a geographic area. 
         [0008]    Additionally, while dealers regularly purchase vehicles at auctions to stock their lots, conventional guides are impractical to use effectively at such venues. During an auction, a dealer may have scant time to formulate a competitive bid. Using a printed guide, a dealer must refer to an index, locate a vehicle, then refer to the vehicle&#39;s page in the guide and determine a wholesale price, then adjust the price based upon mileage tables, and then add to the price to account for options. This conventional process is tedious and conducive to error. Even manual entry of vehicle make, model, year, options and condition into a portable computer is conducive to error and time consuming. 
         [0009]    The assignee of the present application previously has developed a vehicle valuation system (sold under the name BookItOut) that supplies accurate wholesale, retail, purchase, and reconditioning values of used automobiles. In particular the BookItOut system provides vehicle values based upon the actual transaction data that is gathered from subscribing new and used car dealerships. Actual data is used to formulate accurate values, rather than manipulated valuation estimates as provided by other guides. The BookItOut system value includes: purchase data, wholesale data, reconditioning data, days in inventory and sold pricing data; all of which is determined from actual transactions of dealerships. 
       SUMMARY OF THE INVENTION 
       [0010]    In a preferred form, the present invention relates to a system and method of gathering used vehicle data. For example, a software application is installed on dealership computer systems that access data pertaining to the actual purchase price, reconditioning amount, sold price, stock date, and sold date. The software applications mine the relevant data (from a multitude of platforms and formats), standardizes it, and transmits it to a central server optionally in real-time. The actual transaction data preferably is gathered from subscribing industry participants, such as auto dealers, finance companies, insurance companies, banks, auctions, and warranty companies. 
         [0011]    Preferably, the mined data is not altered in any way that would compromise its accuracy—no algorithm is applied to the values, as the mined data represents the actual transaction amounts. The validation process checks the VIN, transaction amounts, etc to ensure, in an automated manner, that false (corrupted, duplicate garbage, etc.) data is not impacting the entire data set. The mined data that fails a step of the validation process is rejected and omitted from being inserted into the central server. 
         [0012]    Optionally, gathered data is made available for the subscribers&#39; viewing via a website. This allows viewing of the data that was mined, but does not allow the subscriber to modify or delete it. 
         [0013]    Optionally, other information can be mined from the subscribers&#39; computer systems as well, such as gross profit, options on the vehicle, vehicle condition, etc. 
         [0014]    Actual transactions (actual records of purchases and sales) of dealerships provide the most accurate representation of a vehicle&#39;s value when compared to other valuation methods. Prior art guides obtain their values solely from auctions, which account for only a fraction of dealership wholesale sales and are not 100% of total dealership sales and purchases. The values used by the present invention are constantly updated as the data mining software monitors the sales and purchase activities of the subscribers (typically, dealerships). 
         [0015]    In one form, the present invention relates to a system for determining an average actual cost of a specified used vehicle for purchase or sale, using actual purchase transaction data obtained from a plurality of dealer management systems. The system is adapted for electronically publishing the average actual cost and includes a computer server housing a database comprising of all actual used vehicle cost data. The actual used vehicle cost data includes vehicle cost data obtained from actual purchases, reconditioning, and sold transactions of subscribing dealerships. A plurality of client software modules are housed on client computer systems operated by subscribing automobile dealers, the client computer systems having dealer management systems. The data mining software is configured to retrieve data from the dealer management systems and to periodically forward the data to the central server. The data on the central server includes actual used vehicle cost data obtained directly from the plurality of dealer management systems. The central server is programmed to determine an actual average vehicle cost for a specified used vehicle, and the central server is operable for electronically communicating the determined average vehicle cost for the specified used vehicle to one or more of the subscribing automobile dealers. Preferably, the database includes vehicle condition data, purchase data, sales data, reconditioning data, days in inventory, and geographical data. In another aspect of an exemplary implementation of the invention, a method is provided for determining the value of a specified used vehicle according to its related actual transaction data from dealerships without requiring any data reporting action on the part of the dealerships. This is accomplished by placing data mining software on the dealership computer systems. The software is configured to monitor and mine the purchase, reconditioning, and sales information on the dealerships&#39; computer systems. This software is operable to monitor and mine the information, across a wide array of dealer management systems (is configured to be able to read the data files of various dealer management systems). The software “crawls” through the data in the background, without requiring intervention or interaction by the dealership personnel. The software uploads the data daily to a central server, again without requiring any action by the car dealers. This uploading of data can be done every minute, every so many minutes, once per hour, once per day, etc. Alternatively, this uploading of data can be effected only when there is new data to upload (“real-time”). Thus, the data mining software can be configured to compare the last version of the data mined with the current state of the data and to upload data only if there is new data to send. In another embodiment, the data mining software can be configured to upload mined data after every purchase or sale transaction is entered in the dealer management system. Alternatively, an update request can be sent to the data mining software on the client device, triggering the data mining software to mine and upload the data. These requests can be timed to occur periodically or on an ad hoc basis. However, the preferred implementation of the present system and method is to configure the data mining software to periodically and automatically mine the data from the dealer management systems and upload that mined data automatically at specified intervals (rather frequently). 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0016]    The foregoing and other aspects, objects, features and advantages of the invention will become better understood with reference to the following description, appended claims, and accompanying drawings, where: 
           [0017]      FIG. 1  is a high-level block diagram of an exemplary networked computer system according to principles of the invention; 
           [0018]      FIG. 2  is a high-level block diagram of components of an exemplary networked computer system configured for submission of dealer transaction data to a server according to principles of the invention; 
           [0019]      FIG. 3  is a high-level block diagram of components of an exemplary networked computer system configured for communication of valuation data from a server to computing devices including hand held computers according to principles of the invention; 
           [0020]      FIG. 4  is a high-level flowchart of an exemplary process of submitting dealer transaction data to a server according to principles of the invention; 
           [0021]      FIG. 5  is another high-level flowchart of an exemplary process of submitting dealer transaction data to a server according to principles of the invention; 
           [0022]      FIG. 6  is a high-level flowchart of an exemplary process of requesting valuation data for a used vehicle according to principles of the invention; 
           [0023]      FIG. 7  is another high-level flowchart of an exemplary process of requesting valuation data for a used vehicle according to principles of the invention; 
           [0024]      FIG. 8  conceptually illustrates a portion of a user interface for requesting valuation data for a used vehicle according to principles of the invention; 
           [0025]      FIG. 9  conceptually illustrates a portion of a user interface for displaying valuation data for a used vehicle according to principles of the invention; 
           [0026]      FIG. 10  conceptually illustrates a portion of a user interface for displaying valuation data for a used vehicle on a handheld computer according to principles of the invention; 
           [0027]      FIG. 11  conceptually illustrates another portion of user interface for displaying valuation data for a used vehicle on a handheld computer according to principles of the invention; 
           [0028]      FIG. 12  conceptually illustrates another portion of a user interface for displaying valuation data for a used vehicle on a handheld computer according to principles of the invention; and 
           [0029]      FIG. 13  conceptually illustrates a portion of a user interface for requesting valuation data for a used vehicle from a handheld computer according to principles of the invention; 
           [0030]      FIG. 14  conceptually illustrates another portion of a user interface for requesting valuation data for a used vehicle from a handheld computer according to principles of the invention; 
           [0031]      FIG. 15  conceptually illustrates another portion of a user interface for requesting valuation data for a used vehicle from a handheld computer according to principles of the invention; and 
           [0032]      FIG. 16  conceptually illustrates another portion of a user interface for requesting valuation data for a used vehicle from a handheld computer according to principles of the invention. 
           [0033]      FIG. 17  is a high-level block diagram of an exemplary networked computer system according to another form of the present invention. 
           [0034]      FIG. 18  is a high-level flowchart of an exemplary process according to principles of the invention. 
       
    
    
       [0035]    Those skilled in the art will appreciate that the invention is not limited to the exemplary embodiments depicted in the figures, or the components, steps, interrelationships, configurations, or order of steps shown in the figures. 
       DETAILED DESCRIPTION 
       [0036]    The invention is directed to an interactive used vehicle valuation system and method, and in particular a system and method adapted for providing vehicle valuation data based upon actual transaction data from car dealership DMS systems. In particular, the invention permits data to be mined from subscribers&#39; DMS systems and uploaded to a central server more or less automatically, with minimal or no action required of the dealer-subscriber. The invention will first be described in connection with a basic implementation of a vehicle valuation system, followed by a description of the data mining aspect of the present invention. 
         [0037]    The valuation data includes wholesale pricing data, repair data, days in inventory and retail pricing data, all of which is determined from actual transaction data and all of which is associated with geographical regions. The system is adapted to receive transaction data, either automatically from a dealer management system or upon dealer submission, via online communication. The received data populates a database, which is used for determining valuation data for a user-specified vehicle and geographic area. The system is adapted to receive and process valuation requests from client computers, which may include remote computing devices such as personal computers, laptop computers and handheld computers. Valuation requests may be generated from manual and/or scanned entries. In response to valuation requests, the system returns corresponding vehicle valuation data to the requesting client computers. 
         [0038]    With reference to the drawings, wherein like numerals represent like features.  FIG. 1  provides a high-level block diagram of an exemplary networked computer system according to principles of the invention. A database server  135  hosts a database management system for managing a transaction database  140 , including steps of writing and reading data to and from the database  140 . The database  140  is communicatively coupled to the database server  135 , and may reside on the database server  135  or on a separate computer and/or one or more separate database storage devices. A web application server  130 , which is communicatively coupled to the database server  135 , hosts information, documents, scripts and software needed to provide user interfaces and enable performance of methodologies in accordance with an exemplary embodiment of the invention. By way of example and not limitation, the web application server  130  may include web page information, documents and scripts (e.g., HTML and XML code), applets and application software, which enable users to submit valuation requests and display valuation data in response to valuation requests from users. 
         [0039]    A plurality of users (e.g., used auto dealerships, finance companies, insurance companies, banks, auctions, and warranty companies) may access the web application server  130  using compatible computing devices  105 - 125  with network connectivity. By way of example, such devices  105 - 125  may include personal computers, laptop computers, handheld computers a/k/a personal digital assistants, kiosks, mobile phones or any compatibly equipped electronic computing devices. User computing systems may include an operating system and a browser or similar application software configured to properly process and display information, documents, software, applications, applets and scripts provided by the web application server  130 . Although five user computing devices  105 - 125  are shown for illustrative purposes, any number of user computers may be used in accordance with the invention. 
         [0040]    The invention is not limited to any particular network connectivity or communication protocol. Various forms of communication networks may be used by the user computers  105 - 125  to access the web application server. By way of example and not limitation, a proprietary Wide Area Network (WAN) or a public WAN, such as the Internet  100 , may be used. These networks typically employ various protocols such as the HyperText Transfer Protocol (HTTP), File Transfer Protocol (FTP), Extensible. Markup Language (XML), and Transfer Control Protocol/Internet Protocol (TCP/IP) to facilitate communication of information between communicatively coupled computers. 
         [0041]    A system according to the present invention may also utilize wireless networks, including those utilizing Global System for Mobile (GSM), Code Division Multiple Access (COMA) or Time Division Multiple Access technology, and the Wireless Application Protocol (W AP). Furthermore, a system according to the invention may utilize any, all, and any combination of such communications networks, as well as communications networks hereafter developed. 
         [0042]    The computing devices described herein (e.g., personal computers, handheld computers [e.g., PDAs] and servers) may be comprised of commercially available computers, hardware and operating systems. The aforementioned computing devices are intended to represent a broad category of computer systems capable of functioning in accordance with the present invention. Of course, the computing devices may include various components, peripherals and software applications provided they are compatible and capable of performing functions in accordance with the present invention. The computing devices also include information, documents, data and files needed to provide functionality and enable performance of methodologies in accordance with an exemplary embodiment of the invention. 
         [0043]    A firewall may be located between FTP server  215  and the database server  135 , as well as between the web server  130  and database server  135 , to protect against corruption, loss, or misuse of data. The firewall limits access by the FTP server  215  and web server  130  and prevents corruption of POS data. Thus, the FTP server  215  and web server  130  may be configured to update and receive data only to the extent necessary. The firewalls may be comprised of any hardware and/or software suitably configured to provide limited or restricted access to the database server  135 . The firewalls may be integrated within the database server  135  or another system component, or may reside as a standalone component. 
         [0044]    Functions and process steps described herein may be performed using programmed computer devices and related hardware, peripherals, equipment and networks. When programmed, the computing devices are configured to perform functions and carry out steps in accordance with principles of the invention. Such programming may comprise operating systems, software applications, software modules, scripts, files, data, digital signal processors (DSP), application-specific integrated circuit (ASIC), discrete gate logic, or other hardware, firmware, or any conventional programmable software, collectively referred to herein as a module. 
         [0045]    Referring now to  FIG. 2 , a high-level block diagram of architecture components of an exemplary networked computer system configured for submission of dealer transaction data to a server according to principles of the invention is conceptually shown. The FTP server  215 , running FTP server software, listens on the network for connection requests from other computers. FTP or File Transfer Protocol is a commonly used protocol for exchanging files over any network that supports the TCPIIP protocol (such as the Internet or an intranet). The same computer may be configured to function as the web application server and FTP server, or separate computers may be utilized for these servers. In an exemplary implementation, the user&#39;s computer  115  running FTP client software, initiates a connection to the FTP server  215 . Before file transfer begins, the end user&#39;s computer  115  and server  215  may negotiate a port of the data connection. Once connected, the user&#39;s computer  115  can upload files to the server  215  and download files from the server. 
         [0046]    Transaction data files from industry participants, such as from used auto dealerships, finance companies, insurance companies, banks, auctions, and/or warranty companies, are uploaded to the FTP server periodically. The files may be uploaded automatically, or upon user command. The transaction data files may include data corresponding to vehicles sold by the user  205 , as well as data corresponding to vehicles purchased by the user  210 . The transaction data files may be comprised of one integrated file or a plurality of separate files or other data structures. In addition to purchase and/or sales data, the transaction data preferably is date stamped and includes vehicle identifiers such as vehicle identification number (VIN), year, make, model, trim (i.e., series and body style), mileage, options, and condition data; as well as one or more location identifiers such as a region, state, city and zip code data, for each purchase and sales transaction reported to the server. Purchase transaction data also preferably includes purchase price and stock date, while sales transaction data preferably includes reconditioning (i.e., reconditioning/repair) costs, sales price and a sales identifier to distinguish wholesale and retail sales. Upon validation of uploaded files, the FTP server directly or indirectly communicates the files and/or transaction data to the database server  135  for updating the database  140 . 
         [0047]    The FTP client software may be a module integrated with a dealership management system or a separate application. Illustratively, an add-on or plug-in module may be provided to interface with a dealership management system. The module or application may be configured to periodically copy transaction data from the dealership into a transaction file and send the transaction file to the FTP server  215 . The copying and transmission may be programmed to occur at user-selected times and frequencies, or upon user command. 
         [0048]    Important aspects of an exemplary implementation of the invention are the use of actual transaction data and association of the data with geographical identifiers. Instead of relying upon conventional guidebook data or a manipulated variation thereof, a system according to principles of the invention facilitates gathering actual transaction data and enables computing valuations based thereon. Because actual transaction data is used, a more detailed and precise valuation is achieved. The valuation may include actual wholesale prices, actual reconditioning data, actual days in inventory and actual retail prices, all of which may be associated with geographical regions. Illustratively, using the system, a user may readily determine the current average wholesale price for a particular vehicle within a specified geographic region, state, city, or zip code. The user may also assess whether a vehicle is in demand in the dealer&#39;s territory as evidenced by days in inventory, how much work and parts are typically required to recondition/repair such a vehicle for resale, and the average retail price for such a vehicle. 
         [0049]    Referring now to  FIG. 3 , a high-level block diagram of components of an exemplary networked computer system configured for communication of valuation data from a server to handheld computing devices according to principles of the invention is conceptually shown. The system is adapted to receive and process valuation requests from client computers  105 - 120 , such as handheld computers  105 ,  120 . Valuation requests may be generated from manual and/or scanned entries. A request may include vehicle identifiers such as vehicle year, make, model, trim (Le., series and body style), mileage., options, and condition, as well as one or more location identifiers such as a region, state, city or zip code of the country. For example, a user may request valuation data for a 1996 Volvo 960, 4-Door Sedan, in good condition, with 100,000 miles, in Jacksonville, Fla. Valuation requests are received by the web application server  130 , where they are processed into queries for the database server  135 . In response to valuation requests and corresponding queries, the database server  135  searches the transaction database  140  for a matching record and returns the resulting wholesale, retail, purchase, and reconditioning values to a user either via a web application or mobile PDA application. The returned values are averages of actual transaction data in the database  140 . 
         [0050]    Referring now to  FIG. 4 , a high-level flowchart of an exemplary process of submitting dealer transaction data for purchased vehicles to a server according to principles of the Invention is provided. In step  400 , purchase transaction data is exported from a dealer inventory management system used to inventory used vehicle purchases. Upon export, a compatibly formatted (e.g., comma delimited text) file containing vehicle purchase information is produced. Illustratively, an exemplary file may include the following fields of data:
   Vehicle Year   Vehicle Make   Vehicle Model   Vehicle Color   Vehicle Engine Type   Vehicle Model Type   Vehicle Identification Number (VIN)   Vehicle Mileage   Vehicle Purchase Price   Vehicle Stock Date   Vehicle Purchase Zip Code   Vehicle Purchase City   Vehicle Reconditioning or Repair Costs   
 
         [0064]    Next, the properly formatted file is imported into the transaction database  406 . Importing entails validating the data as in step  403 . Data that fails validation is rejected and not inserted into the database, in accordance with step  404 . A failure report may be provided to the user explaining that the data was rejected and providing a reason in step  407 . Data that passes validation is accepted and inserted into the database, in accordance with step  405 . A success report may be sent to the user indicating that the data was accepted, as in step  407 . 
         [0065]    A multi-stage validation is preferred. One stage of validation entails checking the validity of the vehicle information using the supplied VIN. A conventional VIN is comprised of seventeen (17) characters that do not include the letters 1,0 or Q. The first three characters uniquely identify the manufacturer of the vehicle. The 4th through 9 1h  positions in the VIN identify the vehicle type, and may include information on the platform used, the model, and the body style. Position 9 is a check digit. The 10 th  through 17th positions identify the individual vehicle in question, including the year as well as information on options installed or engine and transmission choices. Specifically, position 10 encodes the model year of the vehicle and position 11 encodes the factory of manufacture of the vehicle. If the VIN is invalid or does not match the entered vehicle characteristics, the data fails validation. Thus, this aspect of validation helps ensure a high level of integrity of data within the transaction database  406 . 
         [0066]    Another stage of validation entails comparing used vehicle purchase information with similar purchases in the transaction database that antedate the purchase being validated. A variance greater than a determined amount suggests the data is of questionable validity or the product of an atypical transaction. In such cases, the imported data may be rejected as in step  404 . This aspect of validation also helps ensure a high level of data integrity within the transaction database  406 . 
         [0067]    Referring now to  FIG. 5 , a high-level flowchart of an exemplary process of submitting dealer transaction data for sold vehicles to a server according to principles of the invention is provided. In step  500 , purchase transaction data is exported from a dealer inventory management system used to inventory used vehicle purchases. Upon export, a compatibly formatted (e.g., comma delimited text) the containing vehicle purchase information is produced. Illustratively, an exemplary file may include the following fields of data:
   Vehicle Year   Vehicle Make   Vehicle Model   Vehicle Color   Vehicle Engine Type   Vehicle Model Type   Vehicle Identification Number (VIN)   Vehicle Mileage   Vehicle Purchase Price   Vehicle Stock Date   Vehicle Purchase Zip Code   Vehicle Purchase City   Vehicle Reconditioning or Repair Costs   Vehicle Sold Date   Vehicle Sale Price   Vehicle Sale Type (Wholesale or Retail)   
 
         [0084]    Next, the properly formatted file is imported into the transaction database  506 . Importing entails validating the data as in step  503 . Data that fails validation is rejected and not inserted into the database, in accordance with step  504 . A failure report may be provided to the user explaining that the data was rejected and providing a reason in step  507 . Data that passes validation is accepted and inserted into the database, in accordance with step  505 . A success report may be sent to the user indicating that the data was accepted, as in step  507 . 
         [0085]    As with importing purchase data, a multi-stage validation is preferred for importing sold vehicle data. One stage of validation entails checking the validity of the vehicle information using the supplied VIN. A conventional VIN is comprised of seventeen (17) characters that do not include the letters 1,0 or Q. The first three characters uniquely identify the manufacturer of the vehicle. The 4th through 9 th  positions in the VIN identify the vehicle type, and may include information on the platform used, the model, and the body style. Position 9 is a check digit. The 10 th  through 17th positions identify the individual vehicle in question, including the year as well as information on options installed or engine and transmission choices. Specifically, position 10 encodes the model year of the vehicle and position 11 encodes the factory of manufacture of the vehicle. If the VIN is invalid or does not match the entered vehicle 10 characteristics, the data fails validation. Thus, this aspect of validation helps ensure a high level of integrity of data within the transaction database  506 . 
         [0086]    Advantageously, in one embodiment of the invention, a compatible handheld computing device includes a user interface for interacting with a user and/or a barcode or other-type scanner for logging and identifying a vehicle. The user interface may be optionally arranged with a manual data entry device (e.g., a keyboard, keypad, pointing device and/or touch sensitive screen), a display and rich graphical-user-interface (GUI) environment to provide display of vehicle data and other information, user-friendly access to features, and streamlined data entry. As a vehicle identification number provides information about the vehicle make, model, year and other features, the exemplary system may be configured to allow a user to enter a vehicle identification number in lieu of entering such parameters (i.e., make, model, year) separately. 
         [0087]    Additionally, the vehicle identification number may be entered manually or by scanning a barcode corresponding to the vehicle identification number using a barcode scanner device coupled to the handheld computing device. Modem vehicles typically include a scannable barcode representation of the vehicle identification number at one or more locations on the vehicle. Thus, the compatible handheld computing device may include a barcode scanning module, such as an infrared or laser barcode scanner, configured to facilitate quick and accurate entry of Vehicle Identification Numbers (VINs) from vehicles equipped with bar coded VINs. 
         [0088]    Another stage of validation entails comparing used vehicle purchase information with similar purchases in the transaction database that antedate the purchase being validated. A variance greater than a determined amount suggests the data is of questionable validity or the product of an atypical transaction. In such cases, the imported data may be rejected as in step  504 . This aspect of validation also helps ensure a high level of data integrity within the transaction database  506 . 
         [0089]    A high-level flowchart of an exemplary process of requesting valuation data for a used vehicle from a web application according to principles of the invention is provided in  FIG. 6 . First, a user logs into a web application as in step  600 . Next, the application validates the user&#39;s credentials, as in step  601 . If a user&#39;s credentials are rejected, the user is notified, as in step  602 . However, if a user&#39;s credentials are accepted, the application loads application data and user specific settings, as in step  603 , and displays a search page (as shown in  FIG. 8 ), as in step  604 . On the search page, the user selects or inputs the following:
   A vehicle year ( 800  in  FIG. 8 ), as in step  605 .   A vehicle make ( 801  in  FIG. 8 ), as in step  606 .   A vehicle model ( 802  in  FIG. 8 ), as in step  607 .   A vehicle trim (i.e., series and body style) ( 803  in  FIG. 8 ), as in step  608 .   Vehicle mileage ( 805  in  FIG. 8 ), as in step  610 .   A vehicle color, as in step  611 ,   A vehicle condition, as in step  612 .   
 
         [0097]    Next, in step  613 , vehicle options are loaded from a database based upon the vehicle specified by the user in steps  605 ,  606 ,  607 ,  608 ,  609 ,  610 ,  611 , and  612 . The user selects vehicle options ( 813  in  FIG. 8 ) in step  614 . The user also selects or inputs geographical information to search for a selected vehicle. Illustratively, the user selects a zip code ( 807  in  FIG. 8 ), as in step  615 ; a state ( 808  in  FIG. 8 ), as in step  616 ; a city ( 809  in  FIG. 8 ), as in step  617 ; a region ( 810  in  FIG. 8 ), as in step  618 . Subsequently, date parameters are entered. The user selects a begin search date for the selected vehicle ( 811  in  FIG. 8 ), as in step  619 . The user also selects an end search date for the selected vehicle ( 812  in  FIG. 8 ), as in step  620 . Transaction data in the database within the specified date range is utilized. To proceed, a BookItOut button  815  is selected. 
         [0098]    Next the database is searched, as in step  621 . If no results are found based upon the user input, a no results page is displayed, as in step  624 . If results are available, the vehicle according to the user selections and pricing information for the vehicle within the date range are found, as in step  622 , in the transaction database for the following geographical regions:
   National used vehicle pricing ( FIG. 9 )   Regional used vehicle pricing ( FIG. 9 )   State used vehicle pricing ( FIG. 9 )   Zip Code used vehicle pricing ( FIG. 9 )   City used vehicle pricing ( FIG. 9 )   
 
         [0104]    The results are then displayed to the user (as shown in  FIG. 9 ) in accordance with step  623 . The following information is returned to the user for the vehicle and geographic selections:
   Purchase Results ( 900  in  FIG. 9 )   
 
         [0106]    Average Purchase Price ( 920  in  FIG. 9 ) 
         [0107]    Average Repair/Reconditioning Amount ( 921  in  FIG. 9 ) 
         [0108]    Average Adjustment based upon mileage, condition, and options supplied by the user ( 922  in  FIG. 9 ) 
         [0109]    Average Total Cost ( 923  in  FIG. 9 ) which is the (Purchase Price+Reconditioning Costs in FIG.  9 )+Adjustments
   Retail Sales Results ( 901  in  FIG. 9 )   
 
         [0111]    Average Sale Price ( 930  in  FIG. 9 ) 
         [0112]    Average Purchase Price ( 931  in  FIG. 9 ) 
         [0113]    Average Repair/Reconditioning Amount ( 932  in  FIG. 9 ) 
         [0114]    Average Gross Amount ( 933  in  FIG. 9 ) which is Sale Price+Trade-In Value−Purchase Price−Reconditioning Costs 
         [0115]    Average Adjustment based upon mileage, condition, and options supplied by the user ( 934  in  FIG. 9 ) 
         [0116]    Average Days in Inventory ( 935  in FIG.  9 )—which is the difference between Stock Date and Sold Date
   Wholesale Sales Results ( 902  in  FIG. 9 )   
 
         [0118]    Average Sale Price ( 940  in  FIG. 9 ) 
         [0119]    Average Purchase Price ( 941  in  FIG. 9 ) 
         [0120]    Average Repair/Reconditioning Amount ( 942  in  FIG. 9 ) 
         [0121]    Average Gross Amount ( 943  in  FIG. 9 ) which is Sale Price+Trade-In Value−Purchase Price−Reconditioning Costs 
         [0122]    Average Adjustment based upon mileage, condition, and options supplied by the user ( 944  in  FIG. 9 ) 
         [0123]    Average Days in Inventory ( 945  in FIG.  9 )—which is the difference between Stock Date and Sold Date 
         [0124]    Referring now to  FIG. 7 , a high-level flowchart of an exemplary process of requesting valuation data for a used vehicle from a handheld computer according to principles of the invention is shown. First, a user logs into a mobile application as in step  20   700 . Next, the application validates the user&#39;s credentials, as in step  701 . If a user&#39;s credentials are rejected, the user is notified and the application is exited, as in step  702 . However, if a user&#39;s credentials are accepted, the application loads application data and User-specific settings, as in step  703 , and displays a search page (as shown in  FIG. 16 ), as in step  704 . On the search page, the user selects or inputs the following:
   A vehicle year ( 1610  in  FIG. 16 ), as in step  705 .   A vehicle make ( 1611  in  FIG. 16 ), as in step  706 .   A vehicle model ( 1612  in  FIG. 16 ), as in step  707 .   A vehicle trim (i.e., series and body style) ( 1613  in  FIG. 16 ), as in step  708 ,   Vehicle mileage ( 1615  in  FIG. 16 ), as in step  710 .   
 
         [0130]    Next, in step  711 , a user may select a BookItOut button to proceed. In step  712 , vehicle options are loaded from a database based upon the vehicle specified by the user in  10  steps  705 , 706 , 707 , 708 , 709 , 710 . The user selects vehicle options ( 1510  in  FIG. 15 ) and selects a BookItOut button  1511  to proceed, in step  713 . 
         [0131]    After selecting options, the user selects a button to proceed to the next form, as in step  714 , where the user will select or input geographical information to search for a selected vehicle. Illustratively, the user selects a stare ( 1410  in  FIG. 14 ), as in step  715 ; a city ( 1411  in  FIG. 14 ), as in step  716 ; a zip code ( 1412  in  FIG. 14 ), as in step  717 . 
         [0132]    After specifying location (i.e., geographical) information, the user specifies the vehicle condition ( 1413  in  FIG. 14 ), as in step  718 . Selecting a BookItOut button ( 1414  in  FIG. 14 ) allows the user to proceed. 
         [0133]    Next the database is searched, as in step  719 . If results are available, the vehicle according to the user selections and pricing information for the vehicle are found, as in step  719 , in the transaction database for the following geographical regions:
   State used vehicle pricing ( FIG. 10 )   Zip Code used vehicle pricing ( FIG. 10 )   City used vehicle pricing ( FIG. 10 )   
 
         [0137]    The results are then made available for display to the user (as shown in  FIG. 13 ) in accordance with step  720 , which allows the user to select from available displays, such as a state  1310 , zip code  1311  or city  1312  display. In accordance with step  721 , the following information is returned to the user for the vehicle and state  1310  selection:
   Purchase Results ( 1010  in  FIG. 10 )   
 
         [0139]    Average Purchase Price ( 1020  in  FIG. 10 ) 
         [0140]    Average Repair/Reconditioning Amount ( 1021  in  FIG. 10 ) 
         [0141]    Average Adjustment based upon mileage, condition, and options supplied by the user ( 1022  in  FIG. 10 ) 
         [0142]    Average Total Cost ( 1023  in  FIG. 10 ) which is the (Purchase Price+Reconditioning Costs)+Adjustments
   Retail Sales Results ( 1011  in  FIG. 10 )   
 
         [0144]    Average Sale Price ( 1030  in  FIG. 10 ) 
         [0145]    Average Purchase Price ( 1031  in  FIG. 10 ) 
         [0146]    Average Repair/Reconditioning Amount ( 1032  in  FIG. 10 ) 
         [0147]    Average Gross Amount ( 1033  in  FIG. 10 ) which is Sale Price+Trade-In Value−Purchase Price−Reconditioning Costs 
         [0148]    Average Adjustment based upon mileage, condition, and options supplied by the user ( 1034  in  FIG. 10 ) 
         [0149]    Average Days in Inventory ( 1035  in FIG.  10 )—which is the difference between Stock Date and Sold Date
   Wholesale Sales Results ( 1012  in  FIG. 10 )   
 
         [0151]    Average Sale Price ( 1040  in  FIG. 10 ) 
         [0152]    Average Purchase Price ( 1041  in  FIG. 10 ) 
         [0153]    Average Repair/Reconditioning Amount ( 1042  in  FIG. 10 ) 
         [0154]    Average Gross Amount ( 1043  in  FIG. 10 ) which is Sale Price+Trade-In Value−Purchase Price−Reconditioning Costs 
         [0155]    Average Adjustment based upon mileage, condition, and options supplied by the user ( 1044  in  FIG. 10 ) 
         [0156]    Average Days in Inventory ( 1045  in FIG.  10 )—which is the difference between Stock Date and Sold Date. 
         [0157]    In accordance with step  722 , the following information is returned to the user for the vehicle and zip code  1311  selection: 
         [0158]    Purchase Results ( 1110  in  FIG. 11 ) 
         [0159]    Average Purchase Price ( 1120  in  FIG. 11 ) 
         [0160]    Average Repair/Reconditioning Amount ( 1121  in  FIG. 11 ) 
         [0161]    Average Adjustment based upon mileage, condition, and options supplied by the user ( 1122  in  FIG. 11 ) 
         [0162]    Average Total Cost ( 1123  in  FIG. 11 ) which is the (Purchase Price+Reconditioning Costs)+Adjustments
   Retail Sales Results ( 1111  in  FIG. 11 )   
 
         [0164]    Average Sale Price ( 1130  in  FIG. 11 ) 
         [0165]    Average Purchase Price ( 1131  in  FIG. 11 ) 
         [0166]    Average Repair/Reconditioning Amount ( 1132  in  FIG. 11 ) 
         [0167]    Average Gross Amount ( 1133  in  FIG. 11 ) which is Sale Price Purchase Price−Reconditioning Costs 
         [0168]    Average Adjustment based upon mileage, condition, and options supplied by the user ( 1134  in  FIG. 11 ) 
         [0169]    Average Days in Inventory ( 1135  in FIG.  11 )−which is the difference between Stock Date and Sold Date 
         [0170]    Wholesale Sales Results ( 1112  in  FIG. 11 ) 
         [0171]    Average Sale Price ( 1140  in  FIG. 11 ) 
         [0172]    Average Purchase Price ( 1141  in  FIG. 11 ) 
         [0173]    Average Repair/Reconditioning Amount ( 1142  in  FIG. 11 ) Average Gross Amount ( 1143  in  FIG. 11 ) which is Sale Price+Trade-In Value−Purchase Price−Reconditioning Costs 
         [0174]    Average Adjustment based upon mileage, condition, and options supplied by the user ( 1144  in  FIG. 11 ) 
         [0175]    Average Days in Inventory ( 1145  in FIG.  11 )—which is the difference between Stock Date and Sold Date 
         [0176]    In accordance with step  721 , the following information is returned to the user for the vehicle and city  1312  selection:
   Purchase Results ( 1210  in  FIG. 12 )   
 
         [0178]    Average Purchase Price ( 1220  in  FIG. 12 ) 
         [0179]    Average Repair/Reconditioning Amount ( 1221  in  FIG. 12 ) 
         [0180]    Average Adjustment based upon mileage, condition, and options supplied by the user ( 1222  in  FIG. 12 ) 
         [0181]    Average Total Cost ( 1223  in  FIG. 12 ) which is the (Purchase Price+Reconditioning Costs)+Adjustments
   Retail Sales Results ( 1211  in  FIG. 12 )   
 
         [0183]    Average Sale Price ( 1230  in  FIG. 12 ) 
         [0184]    Average Purchase Price ( 1231  in  FIG. 12 ) 
         [0185]    Average Repair/Reconditioning Amount ( 1232  in  FIG. 12 ) 
         [0186]    Average Gross Amount ( 1233  in  FIG. 12 ) which is Sale Price+Trade-In Value−Purchase Price−Reconditioning Costs 
         [0187]    Average Adjustment based upon mileage, condition, and options supplied by the user ( 1234  in  FIG. 12 ) 
         [0188]    Average Days in Inventory ( 1235  in FIG.  12 )—which is the difference between Stock Date and Sold Date
   Wholesale Sales Results ( 1212  in  FIG. 12 )   
 
         [0190]    Average Sale Price ( 1240  in  FIG. 12 ) 
         [0191]    Average Purchase Price ( 1241  in  FIG. 12 ) 
         [0192]    Average Repair/Reconditioning Amount ( 1242  in  FIG. 12 ) 
         [0193]    Average Gross Amount ( 1243  in  FIG. 12 ) which is Sale Price+Trade-In Value−Purchase Price−Reconditioning Costs 
         [0194]    Average Adjustment based upon mileage, condition, and options supplied by the user ( 1244  in  FIG. 12 ) 
         [0195]    Average Days in Inventory ( 1245  in FIG.  12 )—which is the difference between Stock Date and Sold Date 
         [0196]    Then, a results page is displayed using the above data and in accordance with user input and selections, as in step  724 . 
         [0197]    As depicted in  FIG. 17 , the present invention relates to a distributed system  1700  and method for garnering and reporting used vehicle sales prices. For example, a software application is installed on and/or accesses data at/on computer systems  1710  of subscribers to a central sales system (server)  1720 . The software application mines the relevant data (from a multitude of platforms and formats), standardizes it, and transmits it to one or more central servers, optionally in real-time. Preferably, the data is processed at least twice for the benefit of the subscribers. Initially, preferably the raw data so aggregated is validated through a series of stored procedures prior to being combined with the existing vehicle valuation data. The database stores actual, raw data and an average price or value is determined by the database on an ad hoc basis (on the fly). 
         [0198]    The data mining software at the subscriber&#39;s client devices  1710  is implemented as a Windows service that has a configuration XML file. The configuration XML file contains a chronology schedule (when to run) and a dictionary of customer IDs and ODBC data sources. These ODBC data sources enable the data mining software to support multiple customers on the same machine (“1”=“DSN=db 1 ”, “2”=“DSN= 2 ”. etc.). The dictionary is in the configuration XML file, and it has key value pairs where the keys are the customer IDs and the values are connection strings. 
         [0199]    The data mining software has a responsibility to run on a schedule, fetch the customer configuration, run queries from the customer&#39;s configuration, and upload the data. The data mining software does not “know” what data it is operating on and instead this logic is held at the server level, rather than at the client level. The data mining software can be configured to operate on schedule, as stated above, for each customer in the config file. In one manner of operation, the data mining software performs at least the following for each customer: 
         [0200]    1. Contacts customer service and gets the configuration (customer, policy, queries) 
         [0201]    2. Validates the customer (checks ID, makes sure the customer is active). 
         [0202]    3. Runs each query against configured ODBC data sources and creates a temp data file for each query. 
         [0203]    4. Creates a snapshot in the form of an XML file containing all config information, job messages, and combined data from data files. 
         [0204]    5. Compresses the snapshot XML file and calculates a checksum in preparation for communicating the snapshot. 
         [0205]    6. Uploads the snapshot via Archive Service. The data mining software then starts all over again and performs the above steps for the next customer (subscriber). 
         [0206]    As shown in  FIG. 17 , at the server level  1720  a web portal  1721  is provided. The web portal  1721  is implemented using the latest ASP.net MVC architecture (Model View Controller). It is the responsibility of the web portal  1721  to manage customers, policies, and queries and to allow the archive/snapshot data to be monitored. The web portal  1721  ensures that each customer has a “policy” which defines queries and the type of DMS that the customer has. Multiple customers can use the same policy (rule set). A single policy or rule set has one or more queries which define SQL statements that the client or subscriber can run in order to collect data. The web portal  1721  has the ability to remotely change data that the client should collect without changing the client information itself. Web portal  1721  also has ability to practice pro actively monitor which customers have not uploaded data recently and to view error messages during job runs. This web portal  1721  is implemented as an elastic, fluid layout optimized for 1024×768 display. It features ID and integrated authentication with a Windows domain. It features “friendly” URLs which can be bookmarked. The web portal  1721  has a client-side (AJAX) and a server-side, which together perform validation. The web portal  1721  is SEQ-friendly (allows search engine optimization). The web portal  1721  allows SignOn Redirect (if requesting a secure page, a user will return to it after logging in). The web portal also is secured via SSL. 
         [0207]    The system can be configured to compel the data mining software to send only periodical data or to send “all” data. Moreover, the system can be configured to utilize secure Web services. All data preferably is transmitted securely by HTTPS. The system can be configured to store, utilize, and display logos and graphics. The system also can be configured to allow customers to have optional attributes or to add customer address information so that an optional Mapper feature can fill in missing details. This has the advantage of allowing additional information that most DMS systems don&#39;t capture for inventory. 
         [0208]    The mined data is not altered in anyway that would compromise its accuracy—no algorithm is applied to the values, as the mined data represents the actual transaction amounts. The validation process checks the VIN, transaction amounts, etc to ensure, in an automated manner, that false (corrupted, duplicate or garbage) data is not impacting the entire data set. The mined data that fails a step of the validation process is rejected and omitted from being inserted into the central server. 
         [0209]    The present invention provides vehicle values based on actual used car transactions gathered from a plurality of dealership&#39;s DMS systems. Optionally, other information can be mined, such as options on the vehicle, vehicle condition, etc. This data can be collected over a wide area, but organized to reflect local dealership activities so relevant and accurate valuation information can be constructed for a particular zip code, city, area, state, region, etc. The system advantageously uses actual transactions from its member subscribers, rather than far-flung values obtained from auctions. Actual transactions (actual records of purchases and sales) of dealerships provide the most accurate representation of a vehicle&#39;s value when compared to other valuation methods. The collected values stored on the server are constantly updated as the data mining software monitors the sales and purchase activities of the dealership-subscribers. This process is fully automated without the need for an operator to initiate or authorize each access to the dealership DMS system. 
         [0210]    As depicted in  FIG. 18 , when a new subscriber, such as a car dealership, takes a subscription, the first thing done is that the data mining software is loaded on the dealership computer system at step  1810 . The data mining software works in the background, completely unseen by the dealership&#39;s computer operators. The data mining software operates to monitor the data stored in the dealer management system (DMS) as they purchase, recondition and sell the vehicles, as depicted at step  1830 . This software runs continuously, as depicted in step  1820 . It will be appreciated by those skilled in the art that this is not a single data input, but occurs constantly, continuously, and more or less perpetually without human intervention. The data mining software mines the DMS, extracting purchase, sales and reconditioning data, as well as various related information, such as gross profit, stock date, sold date, vehicle options, etc. This occurs at step  1840 . At step  1850 , the data mining software forwards the mined data from the dealer subscriber&#39;s computer to the central server. The central server then verifies the data at step  1860 . The purpose of the verification step is to avoid corrupting the database maintained by the central server and to ensure that only good, reliable data is added to the database. As mentioned elsewhere, the verification step should be carried out in such a way so as to avoid modifying or otherwise changing the purchase, reconditioning and sales data that has been mined. In this regard, it is the actual, unaltered purchase, reconditioning and sales data that would be used to populate the database on the server. The verified data is added to the database and assembled and organized therein at step  1870 . The database can then be sorted, queried, reported from, etc. Indeed, the data contained in the database can be published, as depicted in step  1880 . This can take the form of pre-established reports that are distributed to the subscribers. For example, a standard report which covers all regions can be distributed. Moreover, more tailored reports can be generated automatically, such as reports for specific geographic regions, cities, makes of cars, etc. Also, individualized reports can be automatically generated and distributed to individual subscribers. In addition, the database can be queried on an ad hoc basis for particular results. 
         [0211]    When the data mining software is installed on the dealerships&#39; systems, it should be noted that the application can be installed on virtually any type of computer system. 
         [0212]    While an exemplary embodiment of the invention has been described, it should be apparent that modifications and variations thereto are possible, all of which fall within the true spirit and scope of the invention. With respect to the above description then, it is to be realized that the optimum relationships for the components of the invention and steps of the process, including variations in form, function and manner of operation, are deemed readily apparent and obvious to one skilled in the art, and all equivalent relationships to those illustrated in the drawings and described in the specification are intended to be encompassed by the present invention. The above description and drawings are illustrative of an exemplary embodiment and illustrative of the principles of the invention. As numerous modifications and changes will readily occur to those skilled in the art. It is not desired to limit the invention to the exact construction and operation shown and described, and accordingly, all suitable modifications and equivalents are intended to fall within the scope of the invention as claimed,