Patent Application
20050283388
1. Field of Invention
This invention relates generally to the verification of information and more particularly to a system and method of verifying automobile insurance policy coverage in real time. The system also provides means to prevent fraud and automatically maintain system integrity.
2. Background Information
Currently, the state of Texas and multiple other states require proof of financial responsibility (liability insurance) for every registered vehicle operated on public roadways. Typically, that proof of insurance is a paper card carried in the glove compartment of the vehicle. The deficiencies of the current paper card based proof coverage is that the card is easily counterfeited (duplicated and created falsely) and the coverage was effective for the issuance of the card but is not necessarily in effect after the card was received by the insured. Also a percentage of motorists carry a card illegally obtained (either bought from a counterfeiter or printed by oneself). Additionally, insurance policies are started and then when the proof of insurance card is received by the insured, the insurance is cancelled yet the card is carried by the individual and presented as verification of a current policy even though there is no current insurance in effect. There currently is no timely, economical, real time method to verify that the insurance coverage indicated by the paper card is valid. The end result is the carrying of a card that does not indicate a nonexistent or canceled policy. Also, drivers can be ticketed in the morning for not having insurance and can purchase and have an active policy that afternoon but not have a current card. Insurance companies have resisted combining insurance data into a single database for centralized verification which enforcement agencies can access for fear of client information being accessed by a competitor or other unauthorized entity.
Multiple methods of improving compliance among motorist with state mandated minimum liability insurance laws exist today. All of the existing methods have shortcomings.
One method involves all insurance companies sending a snapshot of their insured customer database (called the “book of business” by the industry) to the specific state utilizing a method called “database compare”. The state takes the data from all insurance companies and compares that data to the state's registered vehicle database. Any registered vehicle which does not have a matching insurance company database entry is considered uninsured. The state then takes appropriate or inappropriate action. The two significant shortcomings of this approach are that the snapshot database is old (“stale”) the moment it is created and the compare criteria is commonly in error.
Stale data refers to data in a database that is inaccurate because of a change in the data after the database is created which the database inaccurately reflects. Since states require a new database snapshot periodically (i.e. once per quarter), there is an opportunity for the vehicle owner to cancel the policy after the snapshot is created and thus is able to drive around uninsured. Conversely, a vehicle owner that purchases a policy the day following the creation of the database snapshot will be identified as uninsured while in fact is legally insured. The database snapshot does not accurately reflect the true insured status with the Insurance Company.
An additional shortcoming of the database compare method is the compare criteria are frequently in error. The most common error involves the Vehicle Identification Number (VIN) being utilized as the key for the database record lookup. Often, the VIN is entered improperly in one of the databases resulting in a failed compare and subsequent action by the state.
A second method involves all insurance companies sending policy status updates to a centralized database system. The centralized database is then queried to determine if a motor vehicle is insured. This method also suffers from the two previously mentioned shortcomings. Since each insurance company must send the status change of a vehicle owner to the common centralized database, there is ample opportunity to miss an update resulting in data in the centralized database not reflecting the true status of the vehicle owner thus stale data. And since the vehicle entry in the state registered vehicle database is created separately from the vehicle entry in the insurance company database which is created separately from the vehicle entry in the common centralized database, there are more opportunities to have mismatched database query information.
This system and method of instant Automotive Liability Insurance verification specifically overcomes the shortcomings of the database compare methods (either book of business compare method or common centralized database) and current paper card based vehicle insurance identification issued by insurance companies and carried by motorists across the nation. In one approach with this system, a new insurance card is issued to each vehicle. The new card includes bar-coded information, or magnetic encoded information, is a Radio Frequency Identification (RFID) transponder with stored information or other comparable data. This information includes the unique vehicle/policy identifier (PI—also referred to herein as the data query key) assigned by each insurance company (i.e. an assigned or random number or string, the Vehicle Identification Number (VIN) and/or license plate number and/or the insured's name or some combination of any of these items), an optional translation control code (TCC) and a home Identifier (HID). The optional translation control code and home identifier are collectively referred to as the Homing Tag. The translation control code, home identifier and unique vehicle/policy ID can be combined into a single one dimension encoding, single multidimensional encoding or may be one or more separate encoding with delimiters. The information may be encoded in a machine-readable encoding such as a standard barcode to minimize the impact to existing systems. One embodiment may have two barcodes, one may include the Insurance Company assigned vehicle policy identifier (PI) and the second barcode may include an identifier to uniquely identify a specific Insurance Company (Homing TAG).
The system and method is utilized when a barcode scanner is utilized to read the Homing Tag and PI, read the Homing Tag and License Plate number, read the License Plate number, or some other pre-defined letter/number sequence, or is initiated on a computer after a keyboard “Enter” key is pressed following a barcode scan or manual entry of the encoded information or is initiated by RF scan of the RFID transponder. A software routine extracts and applies the Homing tag data to a translation/routing table which returns the network (Internet) address or Web Service Signature which includes the network address of the specific insurance company to send the electronic information request. The software routine creates a message including a message type tag, requester ID and address, an optional security access code, home identifier, and the PI and sends it to the insurance company across the Internet. Software located at the insurance company (the other end of the internet link) receives the Internet message, decodes that it is an authorized insurance status request, performs a local database lookup for the insurance status, builds a response message with the appropriate information (owner or responsible party, license plate number, vehicle model and type, VIN, and insurance status for example: active, canceled, or non-existent) and sends the response message via the Internet back to the original requester using the received requester address. The software that originated the request receives the message and displays the information in a custom format.
The Program initiating and/or handling the data exchange (this invention) and the Program responding to the data exchange (at each insurance company or other remote database) are tightly or loosely coupled using any of currently available methods including proprietary socket based, Web Services, Remote Method Invocation, etc. and the Programs communicate using proprietary and/or standard message formatting such as binary, HTTP, XML, JMS, etc.
As part of this system and method for enforcement of mandated insurance, a mobile enforcement capability is provided allowing law enforcement agencies with Internet capable cellular phone or other wireless device (i.e. wireless Palm Pilot, laptop, etc.) utilizing stored program control and a built in camera or other barcode scanning means to perform the same functions as a computer with a barcode scanner. Software exists today to convert a still image of barcodes to a standard barcode scan output. In this case, the image capture of the camera initiates the information request and the result is displayed on the wireless device.
In the embodiment, the system and method for mobile enforcement includes an Application Programming Interface (API) which allows a third party software company (specifically, the company or state agency which created/supports the police cruiser based vehicle registration query system) to perform an insurance verification information request. This system and method optionally allows a Homing Tag be displayed on the license plate or other visible location on the vehicle. The homing tag would be a sticker with, for example, three characters (letters and numbers) applied to the license plate or to the vehicle in a visible location. The officer today enters the license plate number into the in-cruiser system. The officer will optionally take the additional step of entering the Homing Tag information. The in-cruiser system using it's stored program control will provide the License plate number to the API or will combine the License plate number and the Homing Tag information and provide it to the API. The API itself is a stored program control and will perform the information request and return the result to the fixed or hand held terminal in the cruiser where it is displayed or audibly presented to the officer. In an alternate embodiment, as shown in
The user subsystem (100) includes supplemental applications that are an extension specific to insurance verification. One such application works in concert with the vehicle registration database via the API to randomly query insurance companies against the vehicle registration database. The vehicle VIN, license plate number, or other unique identifier value obtained from vehicle record contained within the state vehicle registration database is utilized to obtain the routing key from the local translation table 6700. Over some predetermined time, based on the number of queries per hour the system will support, the entire vehicle registration database can be sequenced through and queries initiated for each vehicle entry in the registration database. A second supplemental program in the administration and control subsystem calculates the percentage of uninsured motorists based on the number of uninsured responses divided by the total number of queries or based upon the total number of registered vehicles.
The system and method should include the method described previously which includes a transaction across the internet initiated by a bar code scan, magnetic stripe scan, retina/fingerprint scan or RFID tag scan, and distributed routing tables or a centralized routing table to allow multiple companies to share the same communications infrastructure for what is effectively a distributed database system where the database is distributed among differing companies or state and federal agencies.
When insurance companies are comfortable providing information to a common database, the Homing Tag per vehicle can be eliminated in lieu of a database (local translation table 6700) containing the routing information so that the mobile enforcement capability is only required to enter the license plate number, VIN, or other unique vehicle identifier. The license plate number, VIN, or unique identifier is used as an index into the stated database to return either the Homing Tag or can contain the actual status of insurance. The following additional variations are included within the scope of this invention:
The following goes together to form a system and method to automate and assist the proper agencies, law enforcement, and other personnel in the immediate verification of information contained at one or more of many remote locations. This system preferably utilizes the Internet as a wide area network to connect corporations or individual users with disparate computer systems or otherwise non-connected competing companies or Federal, State, and Local Governmental agencies in a manner such that specific information can be retrieved without the use of a common collective database or singular routing hub. A singular routing hub is not excluded however it would limit the throughput of the system and provide a single point of surveillance thus is not the preferred embodiment. The system could also be implemented over a private Local Area Network, Wide Area Network, or Virtual Private Network as the communication system interconnectivity. The system is a closed system in that only authorized requests are processed (the requestor is authenticated). The system utilizes proprietary or public domain commands and responses and application specific user interfaces to interact with one of many existing information storage subsystems. In its initial implementation, the system will be used to verify, in real time, the current status of automobile liability insurance.
Referring to
Referring to
The barcode scanner will scan an insurance card containing the Homing Tag (HT) and Data Query Key (Vehicle Identification Number (VIN), license plate number, or other unique policy identification field) (collectively referred to as trigger data). The Homing Tag includes the combination of the optional translation control code (TCC) and the Homing ID (HID). The TCC identifies the translation method to be applied to the HID (don't translate or translate with specific table). The HID is either a direct routing address or is a key into a translation table including the routing address. The trigger data will be parsed by the trigger program (1200) and will be input to the User Control Program (UCP, 1300). The User Control Program will evaluate the TCC to determine if the HID is absolute or should be translated. If the TCC indicates to not translate (the HID is absolute), it is used as the network address directly for the data query. If the TCC indicates a non-absolute HID, the TCC indicates which translation table (1700) to utilize and the HID is translated into the network address. The network address contained in the translation table is either the Network Domain Name of the specific Data Server Subsystem, the Web Service signature of the Insurance company web service, or the absolute network address and port of the required form (i.e. nnn.nnn.nnn.nnn:port as specified by Internet Protocol) utilized to send the query or build the Web Service signature.
The User Control Program creates a network data query using the HID, the user subsystem identifier (UID), User Network Address, the Daycode (an optional security feature), the Translation Table ID, and the data key (unique vehicle or policy identifier—i.e. the VIN or license plate number or a unique insurance company assigned policy or vehicle identifier) and passes the query to the Network Interface Subsystem (NIS, 1400) for network transport. The NIS provides a standard UDP/IP and TCP/IP interface to the network using the HID based network address as the destination for the query. The destination is a Data Server Subsystem. A timer is started when the query is sent and allowing up to N queries where N is a variable to be initiated again if a response is not received within a preset time.
A local verification table is also optionally maintained on the system for self-insured individuals and for small insurance companies which do not maintain their own database. The table is maintained by the Control and Maintenance Subsystem (300). In the specific case of the local verification table, the HID indicates the local table is to be utilized and a verification of insurance is performed by a lookup into the local table using the VIN or license place number as the lookup key. The local table lookup simulates a Data Server Subsystem. The resultant insurance status contained within the local table is returned to the User Control program.
The User Control program receives network query responses from the Data Server Subsystem (DSS) that received the query. The timer associated with the query is cancelled. The insurance company assigned policy identifier is used as the data query key and the VIN, license plate of the vehicle, and/or common unique identifier (common to the DSS and the state vehicle registration record) is returned from the Insurance Company in the response. The returned VIN, license plate number and/or common unique identifier is then compared against the VIN, license plate number and/or common unique identifier contained within the vehicle registration database. If the value returned matches that stored in the vehicle registration database, the response is considered valid for that vehicle and the insurance status is displayed in a predetermined application specific format. A common identifier is included in both the vehicle registration database (which provides the common identifier to the User Control Program) and the insurance company database (the Data Server Subsystem) as a compare value to determine attempted fraud. If the comparison of the common identifier fails (either direct compare fails or a pattern match of less than 80 percent of the characters, for example), then the query was not valid for that vehicle. This fraud detection method is utilized to prevent a Query Key/Insurance Company combination for a valid insurance policy for one vehicle from being utilized for one or more vehicles for which the policy was not written. A difference exists in using the VIN, license place number or unique identifier as the query key (no fraud prevention) vs. using the VIN, license place number or unique identifier as a compare value (using something else as the query key and using the VIN, license plate number, or unique identifier compare as a fraud prevention method).
The User Subsystem receives periodically, for example at least once per day, a Daycode from the Control and Maintenance Subsystem (CMS) during the authentication process. The Daycode is the daily authorization code and improves the efficiency of the overall system by performing authorizations once per day. The Daycode is optionally included in each query to the DSS as an optional per transaction authentication method.
The User Control Program (UCP) contained within the User Subsystem provides local update capability of the Translation Table entries via interaction across the Network with the Control and Maintenance Subsystem (CMS). The Translation Tables entries are added, deleted, or changed. The entire table can be replaced by the CMS. The Translation Tables are used by the User Subsystems to locate and access the Data Server Subsystems.
Additionally, the UCP initiates a whole table update query if no table exists or the table becomes stale (contains old or otherwise incorrect routing entries). The UCP first tries to access the CMS. If a data query is made to a Data Server Subsystem and that specific Data Server Subsystem determines that the table is stale (via the table ID sent in the data query), the Data Server Subsystem will initiate a Translation Table update with the User Subsystem.
Referring to
An external computer system provides a data packet to the User API interface (6110). The data packet should include any formatted message containing the Data Key (Vehicle Identification Number (VIN) or license plate number, or unique insurance company assigned key such as the insured policy number) and optionally a Homing Tag (HT) (collectively referred to as trigger data). These are collectively known as an identifier of the vehicle or policy. The data packet will also optionally contain a unique user assigned packet ID to allow the sender to correlate the system response to their original request.
The Homing Tag includes of the combination of the optional translation control code (TCC) and the Homing ID (HID). The TCC identifies the translation method to be applied to the HID (don't translate, translate with specific table). The HID is either a direct routing address or is a key into a translation table.
The data packet is converted by the message adapter program (6100) to a standard format required by the user control program (6300). After conversion to the standard format by the adapter (6100), the data packet is presented to the trigger program (6200). The trigger program initiates the transaction and routing processing. The standard formatted trigger data will be parsed by the trigger program (6200) and is input to the User Control Program (UCP, 6300). The User Control Program evaluates the TCC to determine if the HID is absolute or should be translated. If the TCC indicates to not translate (the HID is absolute), it is used as the network address directly for the data query. If the TCC indicates a non-absolute HID, the TCC indicates which translation table (6700) or local insurance table (6700) to utilize and the HID is translated into the network address or extracts the local insurance status.
In the case of insurance verification where only a license plate number (TAG), VIN or unique identifier is entered, the TCC specifies the license plate number, VIN or unique identifier to be utilized as the key into the translation table (6700), specifically, the license plate TAG, VIN or unique identifier to HT translation table. The HT contained in the translation table is the homing tag of the specific insurance company or the local table identifier containing insurance status. With the HT, the user control program then performs a second translation of HID to insurance status or network address as stated previously of either the Network Domain Name and web service address of the specific Data Server Subsystem or the absolute network address of the required form (i.e. nnn.nnn.nnn.nnn:port and web service specification).
The User Control Program creates a network data query using the HID, the user subsystem identifier (UID), User Network Address, the Daycode, the Translation Table ID, and the data key (i.e. VIN or license plate number) and passes the query to the Network Interface Subsystem (NIS, 6400) for network transport. The NIS provides a standard UDP/IP and TCP/IP interface to the network using the HID based network address as the destination for the query. The destination is a Data Server Subsystem determined by the routing lookup (first by translation of the TAG, VIN or unique identifier to HT, then by translation of the HT to HID). A timer is started when the query is sent and allowing up to N queries (N is programmable) to be initiated again if a response is not received within a preset time.
The User Control Program (6300) collects counts of queries including initiations and responses to each data server subsystem and logs the counts into the Metrics Table (6310). Stored values are kept including a count of the number of queries to an endpoint, a count of the number of valid insurance responses from an endpoint, a count of the number of invalid insurance responses from an endpoint, the accumulated query time to an endpoint, and the largest and smallest time of query to an endpoint. The metrics table collects data using programmable intervals (i.e. 30 minutes), and writes the data to Persistent Storage (6320) for later extraction by the Control and Maintenance Subsystem (
The User Control program receives network query responses from the Data Server Subsystem that received the query. The timer associated with the query is cancelled. The data is passed back to the message adapter subsystem (6100) for conversion back to the User specific format and the User formatted response is transferred back to the User (6110).
The User Subsystem receives periodically, at least once per day, a Daycode from the Control and Maintenance Subsystem (CMS) during the authentication process. The Daycode is the daily authorization code and improves the efficiency of the overall system by performing authorization once per day. The Daycode is included in each query to the DSS as the per transaction authentication method.
The User Control Program contained within the User Subsystem provides local update capability of the Translation Table entries via interaction across the Network with the Control and Maintenance Subsystem. The Translation Tables entries are added, deleted, or changed. The entire table can be replaced by the CMS. The Translation Tables are used by the User Subsystems to locate and access the Data Server Subsystems.
Additionally, the UCP initiates a whole table update query if no table exists or the table becomes stale (contains old or otherwise incorrect entries). The UCP first tries to access the CMS. If a data query is made to a Data Server Subsystem and that specific Data Server Subsystem determines that the table is stale (via the table ID sent in the data query), the Data Server Subsystem will initiate a Translation Table update with the User Subsystem.
Referring to
The Data Server Subsystem (DSS) receives a query from a User Subsystem via the Network Interface (2600) to the Network Interface Subsystem (2100). The NIS provides a secure transaction capability such as SSL. The user query is parsed by the Receiver Control Program (RCP, 2200) and the received Daycode is verified against the daycode (2800) for validation of user access. If the Daycode is invalid, the UID, Network address, and time received are logged in the activity log (2300). In addition to, or in lieu of, the Daycode validation, the received UID is verified against the access list (2400). The Daycode is unique to the system, calculated at the start of the day, and is sent to each User Subsystem upon authentication once per day by the user to the CMS.
After validation of the source of the query, the Receiver Control Program creates a database query using the required database query language for the location (ODBC, SQL, etc.) and performs the query to the database or data file (2500).
A Graphical User Interface (GUI, 2700) is available to view the activity log, modify the access list, and update the Daycode manually.
Additionally, the received user's Translation Table ID is checked to determine if the translation table is stale. If the received table ID does not match the value contained in the translation table, the User Subsystem translation table is considered stale (old or containing expired data), the Data Server Subsystem, if enabled to do so, initiates a Translation Table update to that specific User or sends a Table update notification to the CMS so that the CMS can initiate the Table Update.
The response to the database query is constructed by the Receiver Control program into a response to the network address of the original requester. The response, addressed to the network address of the UID, contains optionally any combination of the VIN, license plate number, make, model, year of auto, query operation status, and expiration date of the insurance policy or an insurance valid flag of “current”, “expired”, or “cancelled”. If the database query results in a failure to find the information, the validity flag of “not found” is returned in the response query. The query operation status indicates the success of DSS database lookup. The response to the query is logged in the activity log.
If a Daycode was not received or was incorrect by the sender, the DSS will optionally validate the UID against the access list and after validation of the UID, the current Daycode is sent to the user for subsequent queries (faster validation).
The Data Server Subsystem contains local terminal access via a custom GUI for the purpose of local table viewing and updates. The GUI provides access to the access list, query log, Receiver ID, all tables, and the Daycode.
The Data Server and User Subsystems accept requests from the CMS for the query logs. The Query logs are transferred to the CMS and upon receipt acknowledge of the transfer, and are initialized to zero entries. The query log contains failed validations for security uses and optionally database results for system metrics capability. As an option, the Query log can be processed for metrics data locally if the insurance companies do not wish to have the non-failed queries collected external to their company.
The Data Server Subsystem accepts Access List updates from the CMS. The updates are individual entry updates or entire list updates. The update is accepted after the CMS identification is authenticated.
The Data Server Subsystem can initiate an update to the translation tables (1700, 6700) within the User Subsystem or Control and Maintenance Subsystem to update the route for a specified table entry. The DSS initiates a table update to the CMS by sending a message to the CMS containing the update type identifier (route or insured entry) and one or more of the following data: license plate number and/or VIN number, unique identifier or policy number, the time to policy expire value, IP address and port, web service signature and the insurance company HID. The message is sent utilizing the NIS capabilities. The CMS updates the specified table entry and sends a response message indicating success or failure of the table update back to the initiating DSS.
There are two translation tables of primary interest utilizing updates from the DSS to the CMS. The HID to route translation table, and the License Plate Number (TAG), VIN or unique identifier to HID translation table. All updates and acknowledgements are accomplished via the NIS using any of the prescribed methods (i.e. TCP/IP, UDP, proprietary messaging or web service, etc.). Each table update is acknowledged in that a response is sent from the User Subsystem or Control and Maintenance Subsystem to the specific insurance company DSS that the table update was accepted.
All updates to the translation table containing HID to route translation entries are immediate after receipt of the new route (i.e. network address or web service signature) from the insurance company matching the HID. Route update requests where the sender of the update does not match the HID of the table entry are rejected. The update contains the HID of the requestor and the new route.
Updates to the translation table containing TAG/VIN/Unique ID to HID translation entries are either immediate or buffered depending on the data contained in the update. The update includes the license plate number and/or VIN number, unique identifier or policy number, a time to policy expire value, the insurance company HID. A value of nonzero for a policy expire value constitutes notification of a policy update while value of zero for a policy expire value constitutes notification of a cancelled policy by that insurance company. If a translation table update is received but no existing table entry is located for update, a new table entry is created. Translation table entry creations and updates are immediately applied to the TAG/VIN/unique ID to HID translation table and propagated to the User Subsystems. Policy deletions (initiated by a translation table update with a policy expire value of zero) are buffered for a programmable amount of time.
TAG/VIN to HID translation table updates are buffered within the CMS using two watch tables in persistent storage 3300, one watch table for translation table entry creations (new entry watch table) and one watch table for translation table entry deletions (expired/deleted entry watch table). Each entry of each of the two watch tables contains a programmable aging value used to age records (the buffering). This buffering allows for an individual to move from one insurance company (canceling a policy) to another (creating a policy) without an entry being created on the expired policy list file which is reported to state agencies for further action.
When a policy cancellation is received from an insurance company (TAG/VIN/Unique ID to HID translation table entry update with policy expire value of zero), an entry is created in the expired entry watch table with an initial aging value of nonzero (some programmable value). Each night or other appropriate time, a program on the CMS scans the list of entries in the expired entry watch table and compares each entry against entries in the new route watch table. If a matching entry is found in the new route watch table (the TAG, VIN or Unique ID matches), the TAG/VIN/unique ID to HID table entry is updated by updating the HID value. Then the expired watch table entry and new entry watch table entries are deleted. If no matching entry is found in the new entry watch table, the aging value of the expired entry is decremented. When the aging value of the expired entry reaches zero, the entry is moved to the expired policy list file. The expired policy list file is periodically reported to the state.
When a policy update or creation is received from an insurance company (TAG/VIN/Unique ID to HID translation table entry update with policy expire value of nonzero), an entry is created in the new policy entry table with an initial aging value of non zero (some programmable value) and a normal update to an existing translation table entry or the creation of a translation table entry occurs immediately. At the end of the scheduled scan of all expired translation table entries, the aging value of all new policy table entries is decremented. When the aging value of a new entry reaches zero, the entry is removed from the new entry watch table with no further action required.
Referring to
The CMS provides User and Authentication methods for all DSS and User Subsystems. The CMS provides access list updates to the Data Server Subsystems and Daycode updates to all DSS and User Subsystems. The CMS also requests and receives the Query logs from the Data Server Subsystems. The CMS is also referred to as the Administrative Subsystem.
The CMS provides local update capability of the Receiver list entries. The Receiver list entries are added, deleted, or changed. The Receiver list is used to provide destinations to the CMS for propagating Access List updates. The receiver list is a superset of the Translation Table entries containing additional system security information. The Receiver List, as with all other tables maintained by the CMS, is maintained on the Storage Subsystem (3300). The CMS provides local update capability of the Translation Table entries utilizing a local Graphical User Interface or machine to machine transaction method (i.e. web service). The Translation Tables entries are added, deleted, or changed. The Translation Tables are used by the User Subsystems to locate and access the Data Server Subsystems or local table containing insurance status. As an option, after update of an individual table entry, the individual entry is propagated to all User Subsystems contained within the Receiver List, via the NIS. Optionally, the entire list is broadcast to all User Subsystems contained in the Receiver List.
The CMS provides local update capability of the access list entries. The access list entries are added, deleted, or changed. As an option, after update of an individual entry, the individual entry is propagated to all Data Server Subsystems contained within the Receiver List, via the network. Optionally, the entire list is broadcast to all Data Server Subsystems contained in the Receiver List.
The CMS periodically polls all User Subsystems and Data Server Subsystems for their Query logs. The Query logs are extracted and system metrics are created from the query data.
The CMS stores a user access list in the database (3300). A GUI is provided to add and delete users from the user access list. The login and password of the user subsystem are stored in the database. Users can also be marked as disallowed to explicitly deny access.
The CMS stores a DSS access list in the database (3300). A GUI is provided to add and delete DSS from the user access list. The login ID and password of the DSS are stored in the database.
The CMS contains a computer program that collects metrics from each User Subsystem and writes the data to persistent storage (3300). The computer program compares the metrics against pre-configured thresholds and provides a popup GUI (3500) to notify that the specific Data Subsystem is outside the pre-configured thresholds. Another GUI is provided to view the data in a user useful format.
Referring to
An example of a third party system that will utilize this API would be the police cruiser based vehicle registration query system. APIs are provided for user authentication, interaction with the administration services function, and data query access. The existing in cruiser software will be modified to optionally collect the routing key (Homing Tag) in addition to the already entered vehicle license plate number or VIN. The optional routing key (Homing Tag) and license plate number (TAG) or VIN would be delivered to the API by the existing state based system which serves the police cruisers today with the vehicle registration data, which would then perform the translation and routing lookup and subsequent query. The returned query result would then be delivered to the third party software (modified through the use of the APIs to accept the query and result) where it would then be presented to the officer/requestor.
The user subsystem API contains stored program control (6300) to perform several operations specified in the following paragraphs.
The user subsystem API contains stored program control (6300) to perform VIN verification, License plate verification, and optional correction between the State registered vehicle database and the insurance company containing the policy for the vehicle.
One could substitute the vehicle license plate or a unique identifier in lieu of the VIN for record matching as fraud detection or a combination of the data or any other common piece of comparable data that exists in both databases (the vehicle registration database initiating the query and the database of the insurance company being queried).
The user subsystem and control and maintenance subsystem contain stored program control (6300) to perform an expired policy check against the translation table entries. The translation table entries contain the vehicle license plate, VIN, unique identifier, Homing ID, routing address, and expiration date of the vehicle policy. The steps are shown in
The expired policy list file is extracted periodically by the Control and Maintenance Subsystem and is available for further action by the specific state required activity. The extraction produces a list of expired policies sorted by VIN or TAG.
The System and Method for Internet based Instant Information Verification System (IIVS) provides real time automobile liability insurance verification. All data requests preferably require an indirection by using a homing tag lookup into the translation table (XT) also referred to as a network address table (NAT). The homing tag should not be used for direct routing. The specific network addresses are considered a security issue and are a restricted element (guarded secret) of the system. If a homing tag could be utilized for direct request routing then someone could create a counterfeit card and have the request route to his or her counterfeit database, which would return a counterfeit valid response. The NAT in the user subsystem can only be updated and distributed by the administration function (CMS) thereby restricting update access to the routing capability. The distribution to end user segments is by secure connection after user validation.
Data requests received by the data servers are counted and measured against time resulting in queries per minute value. Data servers can maintain a local table of excluded users (access table with exclusion or “disallow” markings) attempting to perform more than N queries per minute. Any user, which performs more than N queries per minute, is added to the table or marked in the table as “disallowed” and a message is sent to the administration function with that User ID. The administration function will disallow system logins by that user. For each data request, the exclude table is optionally checked and if a user ID is present in that table, the user request is denied.
The system and method for instant automotive liability insurance verification allows a remote location to perform data requests to any specific insurance issuing insurance company. The data request results in a real time query into the insurance company maintained insurance database and returns a time stamped response indicating the current status of the vehicle insurance.
Referring to
The present invention provides the following system and method of fixed location insurance verification in
As an extension to the method of a single verification just presented (beginning [73]), the user subsystem will accept query initiations from the API (6110) and provides query responses to the system initiating queries (i.e. state vehicle registration database control program) using the API. This method allows interaction with a state vehicle registration database for the purpose of ascertaining if 100% of the vehicles in the vehicle registration database contain a corresponding insurance policy. This invention works in concert with an application running on the system containing the, or a copy of, vehicle registration database. The vehicle registration database application sequences through the entire vehicle registration database and initiates a query, via the API (6110), for each vehicle entry in the database. The sequence of steps is as follows in
The present invention provides the following system and method of mobile enforcement insurance verification as shown in
The present invention provides the additional following system and method of mobile enforcement insurance verification as shown in
The police officer can pull the vehicle over and issue a citation based on expired vehicle insurance and the vehicle is now subject to probable cause and all those opportunities afforded by that probable cause, that cause being the vehicle is being operated on a public road illegally because it does not have a valid insurance policy.
The system administration and maintenance function (Control/Maintenance System) generates a random number each day to be utilized as the security “day-code”. The system administration and maintenance function builds, updates, and distributes the network address table NAT (translation table) containing insurance company homing tag to insurance company DSS network address data entries to each user subsystem.
Each insurance company DSS database is accessible via stored program control at the insurance company location. The contents of the database including maintenance of the database are the responsibility of the appropriate insurance company. The system administration and maintenance function CMS pings each insurance company, contained in the HID to route translation table, every 30 minutes or other appropriate time period to verify it is on-line and to distribute the current security code (“day-code”). When each insurance company application receives the ping, it responds with a registration message containing its unique homing tag and network address. The response received from the insurance company is verified/updated in the NAT and a day-code message is sent to the insurance company application.
A new insurance company is brought on-line by the insurance company application sending a register message (authenticated message containing network address, homing ID, and unique authorization code) to the administration and maintenance function. The administration and maintenance function contains a user and a DSS authentication database for logins. The system administration and maintenance function validates the sender of the register message against the authentication database and acknowledges any validated (proper login/password sequence) unsolicited registration message with a message containing the day-code.
Users of the system must optionally log in once each day. The system maintenance function includes a user authentication database where users enter a user ID and password. After successful verification of the username and password the NAT (translation table) and day-code are downloaded to the user application. The user application may now be used to perform data requests to all insurance companies listed in the NAT. After the 24-hour period a new day-code is generated by the CMS and distributed to the insurance company applications. User applications, which utilize the stale day-code, must perform the login function again to receive the new day-code and NAT.
It is a method of this system to count data requests from each user over a period of time at the DSS (insurance company application) via a counter in the access list. Users which perform data requests at a rate greater than N (programmable value) per minute are denied system access at the insurance company application and a message is sent to the system maintenance function to log the ID of the user and disable the user login capability for M (Programmable value) minutes.
It is a part of the system and method for the User Subsystem to count successful and total data requests to each DSS (insurance company application) over a predetermined but programmable period of time at the DSS via counters in the access list. Additionally, for each successful query/response, the per-query time and total time of all successful queries is summed to determine the average and maximum query times. These counts and query times are stored in a log file by each user subsystem on a per DSS basis. The counts and time logs are transferred to the system maintenance function on a periodic basis. DSS endpoints which result in a query success rate below some predetermined but programmable threshold (i.e. 99% as determined by the user subsystem) result in an acknowledged message being sent to the system maintenance function to log the ID of the DSS and another acknowledged message being sent to the DSS so that automated problem identification methods can take place. DSS endpoints which are detected by the user subsystem as having a maximum or average query time response rate greater than some predetermined but programmable threshold (i.e. 4 seconds max and 2 seconds average) result in an acknowledged message being sent to the system maintenance function to log the ID of the DSS and another acknowledged message being sent to the DSS so that automated problem identification methods can take place between the control and maintenance subsystem and the specific DSS. The DSS is optionally disabled by the control and maintenance subsystem by updating the translation table to indicate “disabled” for that route. The translation entry is then propagated to all user subsystems whereby the user subsystem will no longer perform queries to that DSS and instead immediately return the status of “endpoint disabled” to the user subsystem or API along with insurance status of “undetermined”.
A new data server (DSS) or a data server that was temporarily disabled or otherwise not accepting data queries may enter the system by interaction with the administration function.
Periodically (preferably every 12 hours), the security day-code is updated.
An overview of the system and method for automotive liability insurance compliance system is shown in
There exists today, tools designed to decrease the amount of time required to implement a system with methods similar to those described in this patent application. Such tools provide a framework and building blocks with which to develop this system and methods, for example Web Services. There are also tools offered as individual building blocks by which to implement this system and methods, for example Java Beans and the various Java Enterprise components. It is understood by one skilled in the art that the system and methods described in this patent application are independent of the infrastructure upon or the environment within which the subsystems execute, thus the system and methods implemented via Web Services or some other developmental tool is not an improvement over what is described here but rather a different implementation of the same system and methods.
While the invention has been illustrated and described in detail in the drawings and foregoing description, the same is to be considered as illustrative and not restrictive in character, it being understood that only the preferred embodiment has been shown and described and that all changes and modifications that come within the spirit of the invention are desired to be protected.
| Number | Date | Country | |
|---|---|---|---|
| 60580215 | Jun 2004 | US |
