Method and system for identifying and displaying discrepancies in vehicle titles4989144Abstract A computer method for rapidly identifying and displaying discrepancies in vehicle titles comprises the steps of automatically identifying the discrepancies inherent in individual title transaction records and identifying contextual discrepancies which may be determined by comparison of title transaction records. Claims I claim: Description BACKGROUND OF THE INVENTION
TABLE I
______________________________________
dcl 1 new.sub.- vin.sub.- rec static,
2 vin.sub.- rec.sub.- union union,
3 vin.sub.- rec char (70),
3 vin.sub.- struc,
4 t2vin char(17), /* 01-17 (17) */
4 t2tranid char(3), /* 18-20 (03) */
4 t2date fixed dec(7),
/* 21-24 (04) */
4 t2titletype
char(1), /* 25-25 (01) */
4 t2odo union, /* 26-29 (04) */
5 t2odo.sub.- bin
fixed bin(31),
5 t2odo.sub.- dec
fixed dec(7),
4 t2zip fixed dec(5),
/* 30-32 (03) */
4 t2lien char(1), /* 33-33 (01) */
4 t2status union, /* 34-34 (01) */
5 t2status.sub.- chr
char(1),
5 t2status.sub.- bit8
bit(8),
5 t2status.sub.- bits,
6 t2stat.sub.- dup
bit(1),
6 t2stat.sub.- dupflag
bit(1),
6 t2stat.sub.- salvage
bit(1),
6 t2stat.sub.- salvageflag
bit(1),
6 t2stat.sub.- miles.sub.- unknown bit,
6 t2stat.sub.- miles.sub.- not.sub.- provided bit,
6 t2stat.sub.- new.sub.- owner
bit(1),
6 t2stat.sub.- not.sub.- used
bit(1),
4 t2titleno char(15), /* 35-49 (15) */
4 t2dealer char(5), /* 50-54 (05) */
4 T2.sub.- MISC UNION, /* 55-70 (16) */
5 T2MISC CHAR (16),
5 T2MISC.sub.- ANY,
6 T2MISC01 CHAR,
6 T2MISC02 CHAR,
6 T2MISC03 CHAR,
6 T2MISC04 CHAR,
6 T2MISC05 CHAR,
6 T2MISC06 CHAR,
6 T2MISC07 CHAR,
6 T2MISC08 CHAR,
6 T2MISC09 CHAR,
6 T2MISC10 CHAR,
6 T2MISC11 CHAR,
6 T2MISC12 CHAR,
6 T2MISC13 CHAR,
6 T2MISC14 CHAR,
6 T2MISC15 CHAR,
6 T2MISC16 CHAR,
5 T2MISC.sub.- INDIANA,
6 T2IN.sub.- PREV.sub.- STATE
CHAR (2),
6 T2IN.sub.- NEXT.sub.- STATE
CHAR (2),
6 T2IN.sub.- NEW.sub.- USED
CHAR,
6 T2IN.sub.- MAINT.sub.- DATE
FIXED DEC (7),
6 T2IN.sub.- ASSEMBLED
CHAR,
6 T2IN.sub.- COURT.sub.- ORDER
CHAR,
6 T2IN.sub.- OUT.sub.- OF.sub. - COUNTRY
CHAR,
6 T2IN.sub.- NOT.sub.- USED
CHAR (4),
5 T2MISC.sub.- KANSAS
6 T2KS.sub.- HWY.sub.- STATUS
CHAR (1),
6 T2KS.sub.- NOT.sub.- USED
CHAR (15),
5 T2misc.sub.- Arkansas,
6 T2AR.sub.- Bit.sub.- flags,
7 T2AR.sub.- New
bit (1),
/*True = new*/
7 T2AR.sub.- Instate
bit(1),
/*True = instate*/
7 T2AR.sub.- Fuel.sub.- code bit(3),
/* Coded with UNSPEC(code)
*/
not used */
Gasoline */
Diesel */
Propane/butane */
Electric */
7 T2AR.sub.- unused.sub.- bits bit(3),
6 T2AR.sub.- Vehicle.sub.- Type char(1),
/* Titled as: */
City owned */
County owned */
State owned */
Dealer */
Master dealer */
TaxiX' */
Regular (Other) */
6 T2AR.sub.- Surrendered.sub.- Title char (12),
______________________________________
The first field ("VIN") in the standard record is the vehicle identification number and thus is the key field upon which data is recalled from the master database. The next field ("transid") identifies the state or other source from which the transaction record was received and controls the variable portion of the record ("misc") at the end of the record. The next fields ("date", "titletype," "odo", "zip" and "lien" contain the date of the transaction, the type of title issued (duplicate, salvage, original etc.), the odometer reading, the zip code of the owner and the number of liens, respectively. The next field "status" is especially important in that it is created by the gather-in program and contains in one byte the information necessary to detect static errors. Bits of this byte are defined as set forth in the following Table II.
TABLE II
______________________________________
Bit Name Description
______________________________________
Dup Title was a "duplicate"
DupFlag Some unknown previous title was a
"duplicate"
Salvage This is a salvage title.
Salvage Flag Some unknown previous title was
salvage.
Miles Unknown Title was marked "TMU".
Miles Not Provided
Mileage was not provided.
______________________________________
The next two constant fields in the record ("titleno", "dealer") hold the number of the title issued and the dealer number of the selling dealer, if known. The variable field ("misc") is available for storing information unique to each different source. Each source has one or more different definitions of this field. In an embodiment of the invention that has been implemented, the entire record is 70 bytes long and the miscellaneous field is 16 bytes long. A key feature of the system and method being described herein is that data is analyzed by the gathering in program prior to its ever being called for, notwithstanding it may never be called for. The analysis is stored in the status byte. Salvage titles are issued at the time of a salvage event, such as a collision or fire which requires the vehicle to be either junked or rebuilt. In many states when insurance companies declare a vehicle to be a total loss, a salvage title is issued to the insurer upon settlement of the claim. It should be noted that the theft of an insured vehicle also results in the issuance of a salvage title upon settlement of the claim. A title record may indicate that at some unstated time in the past a salvage title was issued. In states which brand the titles of rebuilt vehicles, each subsequent issued title will carry some indication of the original salvage. If a vehicle's odometer breaks, or is disconnected, or the true and accurate mileage is no longer affirmable by the owner when the vehicle is sold, this information must be disclosed to the buyer. In the car trade, this vehicle is sold "true miles unknown" ("TMU"). If a state issues a title when the owner has not provided the mileage, this is a case of "miles not provided." Miles unknown is a positive affirmation that the mileage is unknown to the seller. Miles not provided is treated by the database solely as the absence of a mileage reading. Some states have a code in the title data which is set if the vehicle is sold either TMU or not provided. Some states did not collect odometer readings at one time on a required basis or did not supply the database with the odometer readings on some vehicles. These must be treated as miles not provided titles. When the auctioneer or other dealer makes sales, at their option, the following data is captured in a "auction pool" database: vehicle identification number, sale date, odometer reading, auctioneer identification. The data may be used along with the public records data to provide further information for discrepancy checking. This data is considered of somewhat lower veracity since it is not drawn from sworn public records. Therefore, it is generally only available for use by auctioneers that provide such data. When a report on a vehicle title history is required, the auctioneer or dealer submits from a remote terminal or modem an individual request or perhaps from a remote computer and modem a batch of requests. A typical report is produced in Table III.
TABLE III
______________________________________
Date: 10/11/88 Vehicle Records History Service
______________________________________
For: ACE, INCORPORATED
1306 Old Hwy 63 South
Columbia, MO
Vehicle ID No.: 1G6CD6984F4256241
Yr/Mfg: 1985 Cadillac
Model: Deville
Body: 4dr Sedan
______________________________________
NOTE the following potential problem(s) regarding this
records history:
*Odometer reading discrepancy.
No. Date Source Description
______________________________________
1 02/04/85 Missouri Title type issued- Regular
Odometer reading- 30
Mileage sworn/affirmed
Owner city- LAKE OZARK, MO
Purchase status- New instate
Title Number - UB521294
2 05/15/85 Kansas Title type issued- Regular
Odometer reading- 3,316
Owner city- SHAWNEE MISSION,
KS
3 11/04/86 Kansas Title type issued- Regular
Odometer reading- 31,439
Owner city- SHAWNEE MISSION,
KS
Title Number - 19311051
4 09/28/87 Missouri Title type issued- Regular
Odometer reading- 49,885
Mileage sworn/affirmed
Owner city- SEDALIA, MO
Purchase status- Used instate
First lien at time of title issue
Title Number - UC631306
5 08/19/88 Kansas Title type issued- Duplicate ***
Odometer reading- 31,439
Owner city- SHAWNEE MISSION,
KS
Title Number - A0529989
______________________________________
The requests for a report at the very least contain the vehicle identification number of the vehicles for which a report is required. The request might also contain the sale date, a discrepancy mask that sets the type of discrepancies the auctioneer or dealer desires to be alerted to, a caution control flag which determines if the report will reflect that the vehicle is identified in a special caution list, a pool control flag that determines if auction pool data will be considered and one or more records of the type in the master database which the requester desires to also be considered and displayed in the report. For example, the state title office might desire to check for discrepancies in the title transaction it is about to issue. The inserted record would be of the form that would be issued by the state and the information therein could be used for contextual discrepancy checking. FIGS. 2A, 2B and 2C are a flow diagram of a computer program for generating the report. Appendix A is portions of a source code listing for one implementation of this invention in the PL/1 language. The numbers in the parentheses on the flow diagram correspond to program lines of the source code. Referring to FIGS. 2A, 2B and 2C, the first step in generating a report is to collect all records in the master database with the same key, that is, the same vehicle identification number and to place them into a raw records array. Next, a check is made to determine if information from the auction pool is desired. If so, all records from the auction pool are added to the raw records array. Finally, a check is made to determine if external records have been supplied by the requester and if so, these are added to the raw records array. The combined raw records array is then sorted by date and checked for duplicate records. Duplicate records are discarded. The sorted raw records array is then processed into a print array. The print array is a formatted array of the same information contained in the raw records array. The process for forming the print array comprises checking the second field in the raw record ("transid") to decode the miscellaneous field at the end of each record. Next, the discrepancy check subroutine is called. This subroutine processes the raw record array to produce a 16 byte discrepancy flag ("discrep.sub.-- flag") that holds an analysis of all records in the records array, a "flag1.sub.-- array" of the "status" bytes of the record array, and a "flag2.sub.-- array" of the local discrepancy bits ("odo.sub.-- discrep", "dup.sub.-- discrep", "dup.sub.-- in60"), and a dealer array which is an array of the "dealer" field from the record array. The details of this subroutine are described hereinafter with reference to FIG. 3. The print header, print caution routine, print transaction routine and print footer routine are next called to produce the desired report. The print transaction step is a subroutine that is described hereinafter with reference to FIG. 4. The discrepancy check subroutine will now be described with reference to FIG. 3. The source code for one implementation of this subroutine is set forth in Appendix B. Upon entering the routine, the array status word is cleared. This is a 16 bit word that keeps track of the type of discrepancies that can be found in any record in the record array and of any contextual discrepancy found by comparing records in the array. The principal purpose of the array status word is to control the display of discrepancy messages when a title report is being transmitted, displayed or printed. One byte of the array status word is comprised of a byte created by a bit by bit logical OR of each status word in the record array. The other byte of the array status word has bits set whenever a contextual discrepancy is detected. Each record in the raw record array is accessed and placed into a data structure that enables access to individual fields. The status byte of the present record being handled is placed into the flag1.sub.-- array. One byte of the array status word is ORed with the present record status byte. Next, a check for duplicate titles issued within the last 60 days is made by comparing today's date with the date of any duplicate title transaction. Next, a check is made to see if a duplicate title has been issued in a new state. Finally, a check is made for odometer discrepancies by checking whether the odometer reading has been advanced between transactions. If any of the contextual discrepancies are found, the bits corresponding thereto are set in the array status word and in the corresponding byte in the flag2.sub.-- array. Finally, the dealer identification of the present record is transferred to the dealer array if all records have not been processed and the subroutine loops back. Referring now to FIG. 4, the print report subroutine is described. The source code for one implementation of this subroutine is set forth in Appendix C. The first step is a test for the bit set in the array status word. If bits corresponding to a particular discrepancy are set, a message is printed below the report header corresponding to that discrepancy. Possible messages comprise those set forth in the following Table IV.
TABLE IV
______________________________________
"duplicate title issued"
"salvage or junk title issued"
"title with unknown mileage"
"incomplete mileage history"
"odometer mileage discrepancy"
"duplicate title state and prior title state not
the same"
"duplicate title issued within the last two
months".
______________________________________
The foregoing is based upon information supplied by sources deemed to be
reliable but no responsibility is assumed by reason of errors,
inaccuracies or omissions.
##SPC1##
Having thus described my invention with the detail and particularity required by the Patent Laws, what is claimed and desired to be protected by Letters Patent is set forth in the following claims.
|
Same subclass Same class Consider this |
||||||||||