WO2002033624A1 - Graphical user interface for a warranty claim system - Google Patents

Graphical user interface for a warranty claim system Download PDF

Info

Publication number
WO2002033624A1
WO2002033624A1 PCT/US2001/032148 US0132148W WO0233624A1 WO 2002033624 A1 WO2002033624 A1 WO 2002033624A1 US 0132148 W US0132148 W US 0132148W WO 0233624 A1 WO0233624 A1 WO 0233624A1
Authority
WO
WIPO (PCT)
Prior art keywords
interface
data
field
search
information
Prior art date
Application number
PCT/US2001/032148
Other languages
French (fr)
Inventor
Peter B. Atwater
Alonna Marie Whitney
Derek James Bowers
Sankar Venkatesh
Paul Andrew Leary, Iii
John Gordon Minor
Original Assignee
Ge Financial Assurance Holdings, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ge Financial Assurance Holdings, Inc. filed Critical Ge Financial Assurance Holdings, Inc.
Priority to AU2002211749A priority Critical patent/AU2002211749A1/en
Publication of WO2002033624A1 publication Critical patent/WO2002033624A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/02Marketing; Price estimation or determination; Fundraising
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02Banking, e.g. interest calculation or account maintenance

Definitions

  • a mail-in claim may be converted to a normal claim once the further documentation is received.
  • a normal claim is one in which normal claim processing procedures may be initiated.
  • the I/M field 317 may default to an inquiry setting.
  • the Override field 318 of GUI 300 may be used to enable authorization of a claim when standard claim processing procedures and the related action conditions have not been satisfied.
  • the Override field 318 provides an identity field 318a for entering an identity, such as initials or an ID number, of the claims adjuster or user authorizing the override of the standard claim processing procedures.
  • a Password field 318b provides security by requiring a password or other validation of the identity of the claims adjuster overriding the standard claim processing procedures.
  • an override action may also require that the user make an entry in the Notes interface 340 (see Figure 6) to record and explain a reason for the override.
  • the Total Related Claims field 319 of GUI 300 provides a total of all of the related claims on the contract or the vehicle covered under the contract.
  • the Total Related Claims field 319 includes two data fields, one data field for input of the total related claims pending and one data field for input of the total related claims actually paid.
  • an amount paid for all of the total related claims may be evaluated against a value cap which may provide an action condition for recommending a further investigation and requiring an override and/or a note of explanation prior to authorization of the current claim.
  • the Claims Information field 305, the Contract Information field 306, and the Vehicle Information field 307 of the Parts interface 320 are populated automatically based upon the information provided through the Claim Summary interface 310.
  • the Parts interface 320 may be accessed in a second user session after the initial establishment of the claim and an approval of an estimate for the costs of a repair (first session) and the after repair has actually been completed by the repair facility.
  • the Code field 323c may include a drop down menu with a plurality of options describing whether the particular jurisdiction taxes parts, labor, or both. Selection of the Canadian Tax jurisdiction allows the user to enter a tax rate appropriate to the locality of the repair in a GST field 323d, a PST field 323e, and an HST field 323f. Tax information for any number of jurisdictions (both national and local) could be provided for when it is desired to process warranty claims from a wide-ranging number of localities.
  • tax information may be automatically retrieved from a data source in the Information System 120 or 220.
  • the tax information may be part of the repair facility record saved in the Repair Facility data source 124, for example.
  • a separate tax information data source based upon a locality may be accessed using a zip code of the location of the repair facility.
  • a Quantity column 324c shows a quantity required of the specified parts for the repair.
  • a Labor Hours column 324d shows a number of labor hours spent installing a specified part.
  • a Labor Amount column 324e shows a cost for the labor hours spent for installing a specified part. The labor amount cost may be calculated by multiplying the number of labor hours in the Labor Hours Column 324d by a labor rate per hour.
  • a Paid column 324f shows an amount paid toward the cost of the part if the claim has already been authorized and paid.
  • a Description column 324g shows a name or other written description of the specified part.
  • a Component column 324h shows a code used for the component required for the repair.
  • the Subtotals field 325 of the Parts interface 320 may include a number of fields each containing a subtotal of a cost for a part and associated labor for a repair.
  • the Subtotals field 325 includes a Parts subtotal field 325a, a Labor subtotal field 325b, and a Tax subtotal field 325c.
  • the Parts subtotal field 325a shows a total cost amount for the parts entered in Component table 324.
  • the Labor subtotal field 325b shows a total amount for the labor costs associated with the parts entered in the Component table 324.
  • a status entry may be automatically generated by virtue of an action taken through another interface (e.g., a claim denied from Claim Summary interface 310) or another application system (e.g., a check sent by the user of a separate billing system).
  • a status entry may be automatically created based upon an action condition and the user may be directed to the Status interface 330 to review or complete the status entry.
  • the Claims Information field 305, the Contract Information field 306, and the Vehicle Information field 307 shown in Figure 5 are automatically populated based upon the information provided through the Claim Summary interface 310.
  • the Status interface 330 may include a Status History table 331, a Status Selection field 332, a Status Explanation field 333, and an Override field 334.
  • the Status History table 331 shows a complete history of status changes to a specified claim.
  • the Status History table 331 allows the user to get, at a glance, a summary of a plurality of events that have taken place with regard to the specified claim during the course of processing the claim.
  • the Status History table 331 may include a User column 331a, a Date column 331b, an Action column 331c, and an Explanation column 33 Id.
  • the User column 331a identifies the user who made a particular status change.
  • the Date column 331b identifies a date and/or a time the status change was made.
  • the Action column 331c identifies what status action was performed or occurred.
  • Status actions may, for example, include opening a claim, closing a claim, reopening a claim, sending an inspector, denying a claim, authorizing a claim, receiving a document or correspondence with respect to a claim, sending a document or correspondence concerning a claim, receiving an inspection report, and changing parts or labor and other similar actions.
  • the Explanation column 33 Id includes the explanation or description of the action that was taken or performed or the event that occurred. In one embodiment, selection of a particular status action (e.g., by clicking or hovering) may provide the user with additional information about the status action.
  • the Status Selection field 332 is used for identifying a new status action.
  • Status Selection field 332 is a drop down menu containing a list of status actions. Each status action may be identified by a status action code.
  • the Status Selection field 332 may be automatically populated in response to a status action performed through another interface.
  • the Status Explanation field 333 allows a user to input text for an explanation or description of the action taken. Or, Status Explanation field 333 may be automatically populated with a partial explanation or an explanation format based upon a selected status.
  • the ID field 342 allows a user to select a note identifier for the note to be entered.
  • the note identifiers may include, for example, a denial, an inspection, an authorization, and a payment. Note identifier choices may be provided in a drop down menu. Alternatively, selection of an inspection identifier for a note automatically forwards a notification requesting an inspection to the appropriate system when the note is saved.
  • the Notes History table 343 provides a summary of all past changes to a claim record saved to the system 100 or 200. In one embodiment, the Notes History table 343 includes a User column 343a, a Date/Time column 343b, a Type column 343c, a Note column 343d and an ID column 343e.
  • the Search Results field 352 is in a format of a table with a plurality of entries for each contract and/or claim retrieved by the search.
  • the Search Results field 352 may include a number of columns for one or more descriptive characteristics for each entry.
  • the Search Results field 352 may include, for example, a contract number, a claim number, a VIN, a customer name, a year, a make, a model, and a contract and/or claim status.
  • a particular entry in the Search Results field 352 may be selected by clicking on it and pressing an OK button or by double clicking on it. Selection of an entry in the Search Results field 352 may open a Claim Summary interface 310 for a selected claim or a new Claim Summary interface 310 for a selected contract.
  • Figure 9 is an illustrative Repair Facility interface 370.
  • the Repair Facility interface 370 allows a user to access information related to a repair facility of interest.
  • the Repair Facility interface 370 combines the functions of searching for a record for a repair facility of interest and displaying fields and information regarding a selected repair facility of interest beyond the information displayed in other interfaces.
  • the Repair Facility interface 370 may be accessed from the Claim Summary interface 310 in order to search for a particular repair facility during the process of creating a new claim record.
  • the Repair Facility interface 370 may be accessed from the Claim Summary interface 310 for a claim which already contains repair facility information, in order to display additional repair facility information beyond that which is displayed through the Claim Summary interface 310.
  • the Repair Facility interface 370 may include a Search Criteria field 371, a Repair Facility Information field 372, a Results table 373, and a plurality of Function buttons 374.
  • the Search Criteria field 371 may include a plurality of different search criteria including, for example, an issuing dealer, a zip code, a telephone number, and a repair facility name. The issuing dealer field may be checked if the repair is performed at the dealer that issued the service contract.
  • the Repair Facility Information field 372 may include a plurality of informational categories about a particular repair facility including, for example, a repair facility name, an address, a telephone number, a facsimile number, a vendor number, a labor rate, and a special investigation field.
  • the special investigation field may include an identifier for any special handling instructions, such as a mandatory investigation, for claims through the specified repair facility.
  • Figure 10 is a flowchart illustrating the steps conducted in the claim administration process utilizing GUI 300 in accordance with an embodime it of the invention. The process illustrated in Figure 10 may be performed utilizing the systems 100 or 200 described with regard to Figures 1-9 above.
  • a new claim is submitted to the warranty service contract provider and a new claim record is initiated by the warranty service contract provider.
  • the new claim may be initiated in response to a telephone call or other correspondence from a repair facility, a customer, or another entity.
  • a claims adjuster or other user of system 100 or 200 may access the claim system 100 or 200 through a user terminal 110 or 210 in communication with system 100 or 200, respectively, which includes one or more Claim data sources 122.
  • the new claim record may be established through a Claim Summary interface 310, with or without the supplemental interfaces, in accordance with the process described with reference to Figure 11 below.
  • the new claim record for the claim, once created, may be saved within one or more Claim data sources 122 as described above.
  • a plurality of repair details relating to the new claim are entered into the new claim record.
  • the repair details may be provided by a repair facility once the repairs are estimated.
  • the repair details may be entered through a Claims Summary interface 310 in accordance with the process described with reference to Figure 12 below. Evaluation of the repair details and/or other claim data may identify the new claim as a claim requiring inspection under standard claim protocols.
  • the inspection may be initiated in step 1011 by entering an appropriate note through an inspection interface (step 1030).
  • one or more appropriate status actions may be entered to reflect initiation and completion of an inspection process before the user may authorize or deny the claim (step 1040).
  • a requirement for initiation and/or completion of an inspection prior to granting authorization of a claim may be overridden by an authorized user. If after step 1010 the claim did not require an inspection, then the user should enter information concerning the status action in step 1020 through use of the Status interface 330 and also enter an explanatory note in step 1030 through use of the Notes interface 340.
  • the user may continue the process in step 1040 where the claim is authorized or denied.
  • Authorization or denial may be achieved by selection of an appropriate function button available in one or more interfaces.
  • the authorization and/or denial may be automatically determined by the system 100 or 200 based upon the information entered by the user into one or more of the interfaces at step 1050.
  • a note providing an explanation of the authorization or denial may be input by the user.
  • step 1107 additional repair facility information relevant to the particular claim may be entered by the user.
  • additional repair facility information may include the date of the claim, the mileage for the vehicle on the date of the claim, a contact person at the specified repair facility, an order number, and other similar information.
  • step 1108 a record for a customer complaint may be entered.
  • one or more major components requiring repair are identified and may be selected from a drop down menu.
  • the major components may be identified by major component codes.
  • one or more related claims may be reviewed.
  • a table including a plurality of summaries of claims related to the identified contract may be provided for review.
  • a total of the related claims may also be provided for review.
  • the related claims may be automatically evaluated against one or more conditions and any suspect pattern of claims is identified.
  • any modification made to the vehicle subject to the claim is identified.
  • a default value may be provided. The default value may be "yes" if the vehicle was identified as modified in any previous claim. If a modification was unauthorized (or not in accordance with a manufacturer's specifications for the vehicle), such information may be used to initiate alternate handling procedures, inspection criteria, or eligibility for authorization for the claim.
  • FIG 12 is a flowchart illustrating the steps performed during a process of recording claim repair details after a repair is completed in order to evaluate a final authorization and payment of a claim.
  • This process may be carried out utilizing the systems 100 or 200 described above with regard to Figures 1-9 and specifically with regard to the Parts interface 320 shown in Figure 4.
  • a Parts interface 320 is accessed by the user.
  • the Parts interface 320 is a sub-interface of a Claim interface for an existing claim.
  • the Parts interface 320 may have been previously populated with basic claim, contract, and vehicle information.
  • step 1210 the repair facility information is verified.
  • a labor rate field and a corporate discount field may be provided with default entries from a prior repair facility record for the same repair facility.
  • a plurality of component details are entered by the user into the Parts interface 320 to provide an itemized description of the repair associated with the claim.
  • Such component details may be provided by the repair facility.
  • the component details may include required parts and labor for the repair.
  • the component details may also include towing and car rental.
  • Specific components required for the repair may be chosen from a list of components based upon the major components previously identified as requiring repair. A cost, a quantity, and a labor rate may also be entered for each specified component.
  • step 1240 a total and any subtotals for the required repair are verified.
  • the total and subtotals for the required parts, labor, and taxes may be automatically calculated from the component details provided as described above.
  • a deductible amount as specified in the customer's warranty service contract may be retrieved from the contract data source 121.
  • the deductible amount may be reduced or deleted if appropriate.
  • a total amount authorized for the claim and a total amount paid may also be calculated.

Abstract

A system for warranty service claim data access, retrieval and entry is provided. The system includes a data source (120) including claim data (12) for a plurality of warranty service claims (128), a graphical user interface (GUI) for accessing and retrieving data contained in, and for entry of data into, the data source, and at least one logic module. The logic module is responsive to data entered through the claim interface and/or data retrieved from the data source. The logic module evaluates action conditions and directs the claim interface based upon predefined claim processing protocols.

Description

GRAPHICAL USER INTERFACE FOR A WARRANTY CLAIM SYSTEM
BACKGROUND OF THE INVENTION
For many expensive consumer products such as an automobile, a household appliance or an electronic product, such as a television or a computer, it is often desirable to purchase a maintenance service contract to help defray the costs of repairs and maintenance services relating to the consumer product beyond the expiration of a manufacturer's standard warranty term or period. These service contracts are sometimes referred to as "extended warranties."
These service contracts or extended warranties are similar to insurance contracts. A consumer will typically purchase "coverage" against certain types of occurrences. For example, under a typical automotive service contract or extended warranty, the consumer's contract provides coverage for mechanical breakdowns or repairs that may be required to an engine, a fuel system, an electrical system, a cooling system, a transmission, and an electronic system of a vehicle after the expiration of the manufacturer's warranty. The consumer must pay periodic premiums to the automotive service contract provider in order to maintain the service contract in effect. If the consumer experiences a problem with the vehicle covered by the service contract, the consumer can take the vehicle to a repair shop and have the repair shop diagnose the problem. The repair shop may then contact the "Claims Department" of the automotive service contract provider to determine whether the problem with the vehicle falls within the scope of coverage under the service contract. If so, the repair shop can obtain authorization from the automotive service contract provider to perform the repair and can submit the invoice for the costs of the performed repair as a "claim" to the service contract provider for payment by the service contract provider. The service contract provider typically pays for the costs of the repair performed by the repair shop minus an amount equal to a "deductible" from a covered claim under the service contract, which "deductible" the consumer is responsible for paying.
The administration and processing of a claim submitted to the service contract provider under such a service contract or extended warranty is very data-intensive. It may require that the service contract provider gather and analyze information from a number of sources in order to decide whether to authorize or pre-authorize the claim, deny the claim, adjust the claim or conduct a further investigation of the claim. Typically, the service contract provider will require one of its "claims adjusters" to document each step taken when processing such a claim and provide an explanation for an action taken at each step. Additionally, many service contract providers have one or more defined protocols for making a determination as to whether to authorize or deny a claim. The claims adjuster may also need to interact with and/or obtain information from one or more outside entities, such as the repair shop, a dealer or retailer that sold the consumer product and the consumer.
The advent of the computer and information databases has altered the manner in which claims under a service contract are administered and processed. A service contract provider may now maintain a large volume of information in one or more databases for later retrieval and use during the claim process. At the very least, these databases may include basic information relating to the consumers having service contracts with the service contract provider, the consumer products covered under the service contracts, and the claims history of the consumers. These databases may be integrated with a payment system, contract maintenance system, and other information systems. These databases and information systems represent a significant step forward in the efficiency and standardization of the claim administration process.
However, many of the databases and information systems utilized by service contract providers have typically lacked an intuitive, user-friendly interface incorporating business logic to support the claim protocols, procedures, rules and policies. The lack of a proper interface decreases productivity, reduces the application of standardized protocols, and reduces the quality and consistency of the data used in the claim process.
SUMMARY OF THE INVENTION It is therefore desirable to overcome the foregoing drawbacks associated with typical systems and processes used by service contract providers.
There is a particular need for a service contract claim system which utilizes a user- friendly graphical user interface having embedded business logic for claim-related data entry, access and retrieval. In an exemplary embodiment of the invention, a system for warranty service claim data access, retrieval and entry is provided. The system comprises at least one data source including claim data for a plurality of warranty service claims; a claim interface for accessing and retrieving data contained in, and for entry of data by a user into, the at least one data source, the claim interface including a plurality of task oriented interfaces; and at least one logic module responsive to data entered through the claim interface for automatically evaluating a plurality of action conditions and directing the claim interface based upon a plurality of predefined claim processing protocols.
In another exemplary embodiment of the invention, a graphical user interface (GUI) for facilitating warranty service claim processing is provided. The GUI includes a claim summary interface, a parts interface, a status interface, and a notes interface. The claim summary interface provides a summary of information regarding a claim. The parts interface provides a detailed description of repairs made. The status interface provides a summary record of each action taken during processing of the claim. The notes interface provides one or more supplemental descriptions of each action taken with regard to the claim.
A further exemplary embodiment of the invention provides a claim administration process using a graphical user interface for at least one data source. The process comprises the steps of providing at least one user interface and at least one function button. The at least one user interface includes a plurality of fields corresponding to a plurality of data elements in the at least one data source. The function button corresponds to a claim-related task. Selection of the function button initiates a predefined claim protocol utilizing data from the at least one data source. A user may retrieve data from the at least one data source and enter data into the data source via the at least one user interface over a course of processing a claim.
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is a schematic diagram of a warranty claim system in accordance with an embodiment of the invention.
Figure 2 is a schematic diagram of an alternate embodiment of the warranty claim system.
Figure 3 is an exemplary claim summary interface for the warranty claim system in accordance with an embodiment of the invention. Figure 4 is an exemplary parts interface for the warranty claim system in accordance with an embodiment of the invention.
Figure 5 is an exemplary status interface for the warranty claim system in accordance with an embodiment of the invention. Figure 6 is an exemplary notes interface for the warranty claim system in accordance with an embodiment of the invention.
Figure 7 is an exemplary search interface for the warranty claim system in accordance with an embodiment of the invention.
Figure 8 is an exemplary dealer search interface for the warranty claim system in accordance with an embodiment of the invention.
Figure 9 is an exemplary repair facility search interface for the warranty claim system in accordance with an embodiment of the invention.
Figure 10 is a flow chart illustrating the steps in a claim administration process using a graphical user interface in accordance with an embodiment of the invention. Figure 11 is a flow chart illustrating the steps in a process of establishing a new claim through use of a graphical user interface in accordance with an embodiment of the invention.
Figure 12 is a flow chart illustrating the steps in a process of entering claim repair details through use of a graphical user interface in accordance with an embodiment of the invention.
DETAILED DESCRIPTION OF THE INVENTION
Reference will now be made in detail to the present preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings in which like reference characters refer to corresponding elements. With reference to the drawing figures generally, and particularly to Figure 1, a system 100 for warranty service claim data access, retrieval and entry is shown. The system 100 may be used in connection with administration of "extended warranty" or service contracts, such as automotive warranty service contracts marketed and sold to consumers to defray costs associated with maintenance of a vehicle. Although the system 100 will be described below as an automotive warranty service contract system, it should be appreciated by a person of ordinary skill that the system 100 may be used in connection with administration of service contracts or "extended warranties" for other consumer products such as a home appliance or an electronic product, such as a television or a computer. As shown in Figure 1, system 100 comprises a plurality of user terminals 110 connected to an Information System 120 via a Data Gateway 130. The user terminals 110 each include one or more input/output devices for enabling a user, such as a claims adjuster of a warranty service contract provider, to access and retrieve data included in the Information System 120. The user terminals 110 each present the user with an interface, such as a graphical user interface, to facilitate the user's use of the Information System 120.
The user terminals 110 may include terminals 111, 112, and 113. The user terminals 110 may be computer terminals or other workstations, each including a display and at least one input/output device. The user terminals 110 may be comprised of, or may include, for instance, a personal computer running a Microsoft Windows™ 95 or 98, a Millennium™, a Windows™ NT™, a Windows™CE™, a Palm OS™, a Unix, a Linux, a Solaris ™, an OS/2 ™, a BeOS ™, or a MacOS ™ operating system program or other similar operating system program or platform. The user terminals 110 may each further include a microprocessor such as an Intel x86-based device, a Motorola 68K or PowerPC™ device, a MIPS device, a Hewlett-Packard Precision™ device, or a Digital Equipment Corp. Alpha™ RISC processor, a microcontroller or another general or special purpose device operating under programmed control. Additionally, the user terminals 110 may each include an electronic memory such as a random access memory (RAM) or an electronically programmable read only memory (EPROM), a hard drive, a CDROM or a rewritable CDROM, or other magnetic or optical memory media, as will be appreciated by persons skilled in the art. The user terminals 110 may also each include or communicate with any number of input/output, communication, or other peripheral devices, such as a keyboard, a mouse, a microphone, a touch screen, a joystick, a touch pad, a monitor, a pair of speakers, a modem, a network card, a printer, a plotter, a scanner, and/or a digital camera.
The Information System 120 may be comprised of, or may include, or interface with, one or more data sources and associated information used by the warranty service contract provider, such as, a Contract data source 121, a Claim data source 122, a
Vehicle data source 123, a Repair Facility data source 124, a Component data source 125, a Dealer data source 126, a Manufacturer's Recall data source 127 and a Parts Warranty data source 128. The data stored in each of the foregoing data sources may be formatted in a database architecture utilizing a standard database application such as, for example, an Oracle™ relational database sold commercially by Oracle Corporation. Other database applications, such as those marketed by Informix™, Database 2 (DB2), and/or Sybase are also suitable, or other data storage or query formats, platforms or resources may be used including, for example, an On Line Analytical Processing (OLAP) format, a Standard Query Language (SQL) format, a storage area network (SAN) format, and/or a Microsoft Access™ format.
The Contract data source 121 may include a plurality of data elements such as a contract number, a dealer identification number (e.g., a reference for an entry for a dealer in the Dealer data source 126), a consumer name, a vehicle identification number (VIN) (e.g., a reference for an entry for a vehicle in the Vehicle data source 123), a warranty type (i.e., for a new or used vehicle), and key terms of the service contract (e.g., mileage limit, term limit, deductible, etc.). The Claim data source 122 may include a plurality of data elements such as a contract information element (e.g., a reference for an entry for the contract number in the Contract data source 121), a repair facility information element (e.g., a reference to an entry for a specific repair facility in the Repair Facility data source 124), a loss date information element, a loss mileage information element, a customer complaint information element, a major components information element, an estimate information element, a claim total information element, a repair details information element, a status and a status history information element, a notes and a notes history information element, an inspection provider information element, a components to be inspected information element, a date inspection requested information element, a date inspection performed information element, an inspection results information element and other claim-related information.
The Vehicle data source 123 may include a plurality of data elements such as a vehicle identification number (VIN) element, a year data element, a make data element (i.e., a manufacturer of the vehicle such as Ford, GM, Toyota), a model data element (i.e., Thunderbird, Tercel, Mustang), a purchase date data element, a purchase price data element, a purchase location data element, and a purchase mileage data element. The Repair Facility data source 124 may include a plurality of data elements such as a repair facility name data element, a vendor number data element, a contact person data element, an address data element, a telephone number data element, a facsimile number data element, a repair facility contract data element, a special investigation information data element, and a labor rate data element.
The Component data source 125 may include a plurality of data elements such as a component name data element, a component description data element, a major component class data element, an average cost data element, and an average labor hours data element. The Dealer data source 126 may include a plurality of data elements such as a dealer name data element, a vendor number data element, a dealer address data element, a dealer status data element, a type data element, and an agent number data element. The Manufacturer's Recall data source 127 may include a plurality of data elements such as a vehicle make data element, a vehicle model data element, a vehicle year data element, a vehicle identification number (VIN) data element, a component name data element and a recall description data element.
The Parts Warranty data source 128 may include a plurality of data elements such as a component name data element, a component code data element, a warranty duration (term) data element, a warranty miles data element and a warranty provider data element. In one embodiment, the Information System 120 includes, or is a part of, an enterprise-wide information system for supporting all aspects of warranty service contracts including marketing, sales, customer service, adjustment, investigation, claim payment, and administration.
The Data Gateway 130 is a middle-layer system for handling data transfer between one of the user terminals 110 and the Information System 120. For example, the Data Gateway 130 may include Oracle Gateway™ software. Data transfer among one of the user terminals 110, the Data Gateway 130, and the Information System 120 may be accomplished through any suitable communications link, such as, for example, the Internet, an intranet, a Personal Area Network (PAN), a Local Area Network (LAN), a Wide Area Network (WAN), a Metropolitan Area Network (MAN), a storage area network (SAN), a frame relay connection, an Advanced Intelligent Network (AIN) connection, a synchronous optical network (SONET) connection, a digital Tl, T3, El or E3 line, a Digital Data Service (DDS) connection, a Digital Subscriber Line (DSL) connection, an Ethernet connection, an Integrated Services Digital Network (ISDN) line, a dial-up port such as a V.90, a V.34 or a V.34bis analog modem connection, a cable modem, an Asynchronous Transfer Mode (ATM) connection, a Fiber Distributed Data Interface (FDDI), or a Copper Distributed Data Interface (CDDI) connection.
Additionally, the communications link may be comprised of, include or interface to, any one or more of a Wireless Application Protocol (WAP.) link, a General Packet Radio Service (GPRS) link, a Global System for Mobile (GSM) communication link, a Code Division Multiple Access (CDMA) or a Time Division Multiple Access (TDMA) link such as a cellular phone channel, a Global Positioning System (GPS) link, a cellular digital packet data (CDPD) link, a Research in Motion (RIM) limited duplex paging type device, a Bluetooth radio link, or an IEEE 802.11 -based radio frequency link. Moreover, the communications link may be comprised of, include or interface to, any one or more of an RS-232 serial connection, an IEEE- 1394 Firewire connection, a Fiber Channel connection, an infrared (IrDA) port, a Small Computer Systems Interface (SCSI) connection, a Universal Serial Bus (USB) connection or another suitable wired or wireless, digital or analog interface or connection such as would be known by a person of ordinary skill.
In the embodiment shown in Figure 1, a software application and logic for providing the graphical user interface is primarily located in each of the user terminals 110. The Information System 120 acts primarily as a remote data source and a data repository, and the Data Gateway 130 acts primarily as a switch for directing one or more data queries and inputs to the Information System 120.
An alternate embodiment of a system 200 of the invention is shown in Figure 2. The system 200 comprises a plurality of user terminals 210, which may be thin client terminals, and a substantial portion of the application logic for providing the graphical user interface application resides within an Interface Server 240. The user terminals 210 may be substantially as described above with respect to the user terminals 110 in Figure 1. The user terminals 210 may each include a Web browser, such as an Internet Explorer™ browser or a Netscape Navigator™ browser, or another thin client application to access the graphical user interface application residing in the Interface Server 240. The Interface Server 240 may be or include, for instance, a workstation running a Microsoft Windows™ NT™ or 2000, a Unix, a Linux, a Xenix, an IBM ALX™, a Hewlett-Packard UX™, a Novell Netware™, a Sun Microsystems Solaris™, an OS/2™, a BeOS™, a Macintosh, an Apache, an OpenStep™ operating system or another similar operating system or platform. An Information System 220 and a Data Gateway 230 may be comprised substantially as described above with regard to the Information System 120 and the Data Gateway 130 in Figure 1.
Figure 3 illustrates an exemplary GUI 300 for a user terminal of warranty service claim system in accordance with an embodiment of the invention. The GUI 300 may include a plurality of sub-interfaces, a plurality of function buttons, a plurality of menus, a plurality of fields, and a plurality of other features for displaying and inputting data and initiating interface application logic. In the embodiment shown in Figure 3, the GUI 300 is part of a warranty service claim system running on a Microsoft Windows™ operating system platform. An alternative configuration may include a Windows™-based GUI application running on a MacOS, a Unix, or a Linux operating system, or another similar operating system platform. The GUI application and interface logic may also be rendered via a thin client application, such as a Web browser.
In the embodiment illustrated in Figure 3, the GUI 300 uses a Windows™-based interface incorporating many of the plurality of standard features of a Windows™-based application interface. For example, the GUI 300 may incorporate a title bar 301 with a minimize button 301a, a maximize button 301b, and a close button 301c. The GUI 300 may also include a menu bar 302 having a plurality of menu options including a File menu 302a, an Edit menu 302b, a View menu 302c, a Window menu 302d, and a Help menu 302e. The File menu 302a includes an application connectivity control function and a print function. The Edit menu 302b includes a cut function, a paste function, and a selection function for manipulating text within the GUI 300 and across other applications. The View menu 302c includes access to three different search interfaces and the Internet. The three search interfaces include a general search interface for a contract and claim search interface, a dealer search interface, and a repair facility search interface. The Window menu 302d includes a plurality of window manipulation options. The Help menu 302e provides application help and information about the warranty service claim system. A minimize button 302f, a maximize button 302g, and a close button 302h may also be included on file menu 302a for providing window manipulation for manipulating one or more interfaces at one time. The GUI 300 may further include one or more tool bars, such as a tool bar 303 including a plurality of shortcut icons, such as a general search tool icon 303a, a dealer search tool icon 303b, a repair facility search tool icon 303c, and an Internet access tool icon 303d. The shortcut icons duplicate the plurality of functions contained in the View menu 302c in the menu bar 302. The GUI 300 may also incorporate a standard window navigation bar 304 including a start menu 304a and a number of buttons 304b corresponding to the interfaces of other applications or application components simultaneously running or "open" on the user terminal 110 or 210. In addition to the general Windows-driven application features described above, the GUI 300 includes a plurality of standard application interface features and a plurality of task specific application interface features. The plurality of standard application interface features include the features described above, as well as a Claim Information field 305, a Contract Information field 306, a Vehicle Information field 307, and a functions button 308.
The Claim Information field 305 includes a field for displaying a claim tracking number assigned to a particular claim. The claim tracking number may not be assigned until the first time the claim information is saved or otherwise submitted to the Information System 120 or 220 or other database. A Claim status (e.g., "O" for open, "C" for closed, "D" for denied, "A" for authorized, etc.) may also appear in the Claim Information field 305. In one embodiment, when a user selects the Claim Information field 305 (e.g., by hovering or clicking), an additional interface (e.g., a Claims Information pop-up window) may open with additional claim information, such as a customer name and one or more of a plurality of actions, such as an "established by" action which displays a user ID of a claims adjuster who established the claim, an
"authorized by" action which displays a user ID of the claims adjuster who authorized the claim for payment, or a "denied by" action which displays a user ID of the claims adjuster who denied the claim. The Claims Information pop-up window may further include an authorization amount which displays a dollar amount of the claim minus a deductible, and other summary information. The fields in both the Claim Information field 305 and the Claims Information pop-up window may be automatically populated based upon past data saved to the claim data source 122. The Contract Information field 306 may include a Contract Number field 306a, a Customer Name field 306b, and a Status of Contract field 306c. In one embodiment, additional contract information may be displayed in an additional interface (e.g., a Contract Information pop-up window) when the Contract Information field 306 is selected (e.g., by hovering or clicking). The additional contract information displayed in the Contract Information pop-up window might include a customer address, a product warranted (e.g., automobile, motor home, etc.), an effective date for the contract, an effective odometer reading displaying the vehicle odometer reading at the time of sale of the service contract, a service contract term and a mileage amount covered under the service contract, a coverage plan (for a new or a pre-owned vehicle), a deductible amount, an options field for displaying any coverage options purchased by the customer under the service contract, a written date for displaying the date on which the service contract was written, an expiration date for the service contract, an expiration odometer reading if the service contract term is based upon mileage, an issuing dealer that sold the service contract to the customer, and any other information of interest for the service contract. The Contract Information field 306 and any additional contract information fields in the Contract Information pop-up window may be automatically populated based upon past data stored in the contract data source 122. In one embodiment, some or all of the contract information fields will be available for display only and will not be editable by the user through the GUI 300. An alternate interface may be provided for maintenance of the data stored in the contract data source 122.
The Vehicle Information field 307 in the GUI 300 of Figure 3 provides basic information about the vehicle covered under the service contract. The Vehicle Information field 307 may include a vehicle identification number (VIN) field 307a, a Year field 307b which displays a year of manufacture of the vehicle covered under the service contract, a Make field 307c for displaying a manufacturer of the vehicle (i.e., Ford, Honda, Toyota, etc.), a Model field 307d for displaying a model of the vehicle ( i.e., Thunderbird, Accord, Celica, etc.) and a Purchase Price field 307e for displaying a purchase price of the vehicle. The Vehicle Information field 307 may be automatically populated with data retrieved from the Vehicle data source 123 based upon entry by the user of the VIN for the vehicle covered under the contract. In one embodiment, some or all of the Vehicle Information fields will be available for display only and will not be editable by the user through the GUI 300. An alternate interface may be provided for maintenance of the data stored in the vehicle data source 123.
A plurality of function buttons 308 provide commonly-used functions for claim processing. The function buttons 308 may include a Search button 308a, a New Claim button 308b, an Authorize button 308c, a Denial button 308d, a Save button 308e, and a Close button 308f.
The Search button 308a may initiate a general search interface for contracts and claims, similar to the general icon search tool 303 a or the search option available under the View menu 302c. The New Claim button 308b initiates an interface for establishing a record relating to a new claim. Li one embodiment, if a contract number has already been retrieved from a prior search or otherwise identified, the Contract Information field 306 and the Vehicle Information field 307 of the new claim interface will be automatically populated with data for the contract number previously retrieved and the associated vehicle covered under that contract.
The Authorize button 308c initiates a procedure for authorizing a claim. Selecting the Authorize button 308c may initiate an authorize status action and automatically direct the user to a Status Interface 330 (see Figure 5) with appropriate authorization data within appropriate status fields. In one embodiment, the Authorize button 308c may not be enabled until data has been entered in all mandatory fields in the GUI 300 and all conditions defined in a claim protocol are met. For example, the Authorize button 308c may not be enabled until a major component field and a parts field have been completed and any necessary investigations or authorization overrides outside of a plurality of standard authorization parameters have been entered for a claim. The Denial button 308d initiates a procedure for denying a claim. Selecting the
Denial button 308d may initiate a denial status action and automatically direct the user to a Status interface 330 (see Figure 5) with appropriate denial data within appropriate status fields. In one embodiment, where the user initiates a denial protocol even though the data associated with the claim meets an authorization criteria, the user may be directed to a Notes interface 340 (see Figure 6) in order to provide an explanation for the denial. In an alternate embodiment, the user is always directed to the Notes interface 340 when a denial is made. The Save button 308e saves data input by the user in the various fields in the GUI 300 to the Claim data source 122. The Close button 308f closes the window for the GUI 300 for the current claim. The Close button 308f may also prompt the user to save any unsaved data and may remind the user of any fields necessary to the claim processing procedures which have not been completed.
The remainder of the GUI 300 is variable according to the task-oriented sub- interface being accessed. The sub-interfaces are navigated using a number of interface tabs 309. The interface tabs 309 include an EPOL tab 309a corresponding to a Claim Summary interface 310 (described below), a Parts Repaired tab 309b corresponding to a Parts interface 320 (described below with regard to Figure 4), a Status Action tab 309c corresponding to a Status interface 330 (described below with regard to Figure 5), and a Notes tab 309d corresponding to a Notes interface 340 (described below with regard to Figure 6).
The Claim Summary interface 310 includes plurality of fields for establishing basic information surrounding a new claim. The Claim Summary interface 310 provides a starting point for recording information about a new claim as provided by a repair facility. Once a particular service contract and vehicle covered under the service contract are identified, the Claim Summary interface 310 provides a plurality of information fields for input of data required prior to authorizing payment of the new claim. The Claim Summary interface 310 includes a Repair Facility Information field 311 , a Customer Complaint field 312, a Major Component field 313, a Related Claims field 314, an Additional Questions field 315, an Estimate field 316, an Inquiry/Mail-In Claim (1/M) field 317, an Override field 318, and a Total Related Claims field 319. The fields in the Claim Summary interface 310 may be automatically populated based upon data entered in a previous session for a claim. Even with respect to a new claim, some fields in the
Claim Summary interface 310 may be provided with default values based upon common responses of customers or may be populated by data retrieved from a data source based upon the contract (le., the contract data source 121), the vehicle covered under the contract (i.e., the vehicle data source 123) a specific repair facility (i.e., the repair facility data source 124), or some other source of previously-collected data.
The Repair Facility Information field 311 of GUI 300 includes information about a repair facility handling a claimed repair, as well as claim information generally reported by the repair facility. In many cases, it will be the repair facility that initiates the claim with the service contract provider. The Repair Facility Information field 311 may include a number of fields, such as a Loss Date field 31 la, a Loss Mileage field 31 lb, a Repair Facility Contact field 31 lc, a Repair Facility invoice number (RO#) field 31 Id, a repair facility (RF) Name field 31 le, a facsimile number (Fax #) field 31 If, and a telephone number (Phone #) field 311g. In one embodiment, the Claim Summary interface 310 may compare data entered in the Loss Date field 311a and/or data entered in the Loss Mileage field 311b to the coverage period/mileage defined by the contract in order to determine whether the claim is covered under the contract, i.e., the "validity" of the claim. In the event that either the date entered in the Loss Date field 31 la is outside of the coverage period or the mileage input in the Loss Mileage field 311b falls outside of the covered mileage under the contract, the user may be notified that the claim is outside the terms of the contract. In such case, an authorize function (or button) will be disabled. In one embodiment, selection by the user of the Repair Facility Information field 311 (such as by clicking, hovering, or tabbing over from one or more fields) may initiate an additional Repair Facility Information pop-up window. The additional Repair Facility Information pop-up window may include a repair facility address field, a vendor number field, a special investigation flag field, a labor rate field, and other similar informational fields. In one embodiment, the additional Repair Facility Information pop-up window may be combined with a Repair Facility Search interface 370 (see Figure 9).
The Customer Complaint field 312 provides a field for entering a description of a customer's complaint, a cause of the complaint, and a cure for the complaint. The Customer Complaint field 312 may be an editable text box which provides a large amount of space for recording a customer's comments, concerns, and action items. The Major Component fields 313 of GUI 300 provides one or more fields for recording a major vehicle component (e.g., an engine, a transmission, brakes, a heating/cooling system, etc.) for which a repair claim is made. In one embodiment, the Major Component field 313 includes a plurality of fields for a claim in which a number of major systems or vehicle components are involved in the repair, for example component fields 313a-j. In another embodiment, the Major Component field 313 includes a plurality of drop down menus containing a list of major component names or codes for quick selection by the user. The list of major component names or codes may provide an exhaustive classification scheme for all of the components of the warranted vehicle. The list of major component names or codes may be linked to the type of vehicle warranted for providing a shorter and/or a better-organized drop down menu. The list of major component names or codes may be saved in a data source accessible in Information System 120 or 220 for system 100 or 200, respectively.
The Related Claims field 314 of GUI 300 provides a list of all claims, past or pending, associated with a particular contract or a vehicle. The Related Claims field 314 may include a plurality of fields organized in a table format including a Claim Number column 314a, a Status column 314b, a Date column 314c, a Miles column 314d, an Authorization (Auth/Paid) column 314e, an Amount column 314f, a Reported Date column 314g, and a Repair Facility column 314h. The Related Claims field 314 may be populated by initiating a search of the claim data source 122 based upon the contract number or VIN for the vehicle the subject of a current claim. In one embodiment, any related claim shown in the Related Claims field 314 may be selected to access additional information about the claim. Additional information may be displayed via a pop-up window or selection of the related claim may open an additional claim interface window providing access to a complete interface for the selected claim. In one embodiment, application logic evaluates the list of related claims and evaluates the current claim against a plurality of action conditions based upon a plurality of claim handling procedures for identifying a suspect pattern of claims. For example, a large number of claims submitted under a particular service contract over a short period of time, a large number of claims for the same major vehicle component, a large number of claims submitted through a single repair facility, or similar circumstances may be used to identify a suspect pattern of claims. The GUI 300 may notify the user of the suspect pattern of claims and require the user to input an explanatory note for a referral of the current claim to an investigation unit (e.g., a Special Investigation Unit (SIU)) prior to enabling authorization of the current claim.
The Additional Questions field 315 provides a plurality of additional questions that may impact the service contract coverage for the vehicle. For example, a Personal Use field 315a is used for recording whether a vehicle is for personal or commercial use. A Modified field 315b may provide a field for recording whether the vehicle has been modified in such a way that it may alter or void the warranty coverage. In one embodiment, each of the fields may be provided with a default entry based upon the most common response to the question given by the customers of the service contract provider.
The Estimate field 316 of GUI 300 allows a user to input a repair facility's estimate of a cost for a repair under a claim prior to actually completing the repair and incurring the cost. The Estimate field 316 is used for providing a pre-approval or a pre- authorization for a repair where such a pre-approval is required by the contract, the repair facility, or the customer. In one embodiment, the data in the Estimate field 316 may not be altered by the user once the claim has been authorized or denied. In one embodiment, an entry in the Estimate field 316 may be required as a pre-condition to enabling an authorize function absent entry of data for an actual parts cost and an actual labor cost for the repair.
The Ϊ/M field 317 of GUI 300 allows the user to note whether the current claim is a normal claim, an inquiry claim, or a mail-in claim. An inquiry claim does not initiate a full claims processing procedure and may be provided solely for informational purposes to the customer or the repair facility. An inquiry claim may still be retained within the claim data source 122 of the system 100 for a predefined period of time and may be converted to a normal claim should the inquiry claim be submitted as a normal claim at a later date. A mail-in claim establishes claim information and allows a user to provide information regarding the claim to the customer or the repair facility. However, a mail-in claim may not initiate claim processing procedures until further documentation for initiating the claim are received. A mail-in claim may be converted to a normal claim once the further documentation is received. A normal claim is one in which normal claim processing procedures may be initiated. In one embodiment, the I/M field 317 may default to an inquiry setting. The Override field 318 of GUI 300 may be used to enable authorization of a claim when standard claim processing procedures and the related action conditions have not been satisfied. The Override field 318 provides an identity field 318a for entering an identity, such as initials or an ID number, of the claims adjuster or user authorizing the override of the standard claim processing procedures. A Password field 318b provides security by requiring a password or other validation of the identity of the claims adjuster overriding the standard claim processing procedures. In one embodiment, an override action may also require that the user make an entry in the Notes interface 340 (see Figure 6) to record and explain a reason for the override.
The Total Related Claims field 319 of GUI 300 provides a total of all of the related claims on the contract or the vehicle covered under the contract. In one embodiment, the Total Related Claims field 319 includes two data fields, one data field for input of the total related claims pending and one data field for input of the total related claims actually paid. In one embodiment, an amount paid for all of the total related claims may be evaluated against a value cap which may provide an action condition for recommending a further investigation and requiring an override and/or a note of explanation prior to authorization of the current claim.
Figure 4 illustrates an exemplary Parts interface 320 for the warranty service claim system 100 or 200 in accordance with an embodiment of the invention. The Parts interface 320 is displayed when the Parts Repaired tab 309b of GUI 300 is selected by the user. The Parts interface 320 allows entry of data and review of a listing of a plurality of parts and labor required to complete the repair covered by the claim. The Parts interface 320 includes a plurality of algorithms for calculating an actual claim amount due to be paid to a repair facility or a customer. The Parts interface 320 may be accessed after the initial claim information is entered through the Claim Summary interface 310. The Claims Information field 305, the Contract Information field 306, and the Vehicle Information field 307 of the Parts interface 320 are populated automatically based upon the information provided through the Claim Summary interface 310. In many cases, the Parts interface 320 may be accessed in a second user session after the initial establishment of the claim and an approval of an estimate for the costs of a repair (first session) and the after repair has actually been completed by the repair facility. The Parts interface 320 may include a Labor Rate field 321, a Corporate Discount field 322, a plurality of Tax Information fields 323, a Component table 324, a plurality of Subtotal fields 325, an Inspection Required field 326, a Deductible field 327, a Total Paid Amount field 328, and a Total Authorized Amount field 329.
The Labor Rate field 321 of the Parts interface 320 provides a labor rate for a repair facility making a warranted repair. The labor rate is used in calculating the actual amount to be paid to the repair facility performing the repair. In one embodiment, a default labor rate is provided in Labor Rate field 321 based upon identification of the repair facility. The labor rate may be retrieved from the repair facility data source 124 based upon a search for records relating to the particular repair facility performing the repair. In one embodiment, the user may alter the labor rate for the specific claim, but may only adjust it downward. In another embodiment, the labor rate may be adjusted upward through the use of an override authorization.
The Corporate Discount field 322 of the Parts interface 320 allows the user to record a discount applied to the cost of the parts and/or labor provided by the repair facility. The Corporate Discount field 322 may allow entry of data expressed as a percentage discount, or alternatively, the Corporate Discount field 322 may be comprised of a drop down menu of various discount rates, one of which may be selected by the user by clicking on it. In another embodiment, the Corporate Discount field 322 may be automatically populated by a value retrieved from the repair facility data source 124 based upon the identity of the repair facility and/or the contract.
The Tax Information field 323 of the Parts interface 320 calculates an appropriate amount of taxes for the cost of the repairs relating to the claim based upon the location of the repair facility performing those repairs and/or other information provided by the user. In one embodiment, the Tax Information field 323 provides for a selection or an identification of a tax jurisdiction for determination of a tax rate for taxing the cost of the repairs. For example, the Tax Information field 323 shown in Figure 4 includes a jurisdiction radio button 323a for choosing between a U.S. Tax jurisdiction and a
Canadian Tax jurisdiction. Selection of the U.S. Tax jurisdiction allows the user to then enter a state/local tax rate in a Rate field 323b and a tax code in a Code field 323c. The Code field 323c may include a drop down menu with a plurality of options describing whether the particular jurisdiction taxes parts, labor, or both. Selection of the Canadian Tax jurisdiction allows the user to enter a tax rate appropriate to the locality of the repair in a GST field 323d, a PST field 323e, and an HST field 323f. Tax information for any number of jurisdictions (both national and local) could be provided for when it is desired to process warranty claims from a wide-ranging number of localities. In one embodiment, tax information may be automatically retrieved from a data source in the Information System 120 or 220. The tax information may be part of the repair facility record saved in the Repair Facility data source 124, for example. Alternatively, a separate tax information data source based upon a locality may be accessed using a zip code of the location of the repair facility.
The Component table 324 of the Parts interface 320 is used to provide an itemized summary of all of the parts used in the claimed repair. In one embodiment, each line in the Component table 324 includes an entry for a single part and the associated labor required to install the single part. Alternatively, the part and the labor may each have separate data entry lines. A Component column 324a may contain a code for each part required for the repair. In one embodiment, the Component column 324a includes a drop down list of all of the parts within the major component category or categories specified through Claim summary interface 310. In another embodiment, the parts list is retrieved from a Parts data source in the Information System 120 or 220. An Amount column 324b shows a cost for a specified part. A Quantity column 324c shows a quantity required of the specified parts for the repair. A Labor Hours column 324d shows a number of labor hours spent installing a specified part. A Labor Amount column 324e shows a cost for the labor hours spent for installing a specified part. The labor amount cost may be calculated by multiplying the number of labor hours in the Labor Hours Column 324d by a labor rate per hour. A Paid column 324f shows an amount paid toward the cost of the part if the claim has already been authorized and paid. A Description column 324g shows a name or other written description of the specified part. A Component column 324h shows a code used for the component required for the repair. A Subtotal column 324i shows a subtotal amount for a single row of the Component table 324. In one embodiment, the calculated costs of parts and labor for the claimed repair may be compared to a national average cost for a similar repair or another similar measure of comparison. The user may be notified of suspicious deviations from those national averages. In one embodiment, a rental charge and a towing charge may also be included as components in the Component table 324.
The Subtotals field 325 of the Parts interface 320 may include a number of fields each containing a subtotal of a cost for a part and associated labor for a repair. In one embodiment, the Subtotals field 325 includes a Parts subtotal field 325a, a Labor subtotal field 325b, and a Tax subtotal field 325c. The Parts subtotal field 325a shows a total cost amount for the parts entered in Component table 324. The Labor subtotal field 325b shows a total amount for the labor costs associated with the parts entered in the Component table 324. The Tax subtotal field 325c shows the total tax amount for the repairs based upon the above parts and labor subtotals, and the tax rate or rates determined in the Tax Information field 323. In one embodiment, a subtotal field for a rental charge and a subtotal field for a towing charge may also be included (not shown). The Inspection Required field 326 of the Parts interface 320 provides notice to the user that one or more inspection criteria are met by the claim. In one embodiment, the Inspection Required field 326 includes a yes/no field for showing the inspection requirement based upon one or more pre-defined inspection conditions. Some example inspection conditions for determining whether an inspection is required may include a claim where the total cost for repairs exceeds a pre-determined cap, a claim where a loss ratio is in excess of a particular cap, a claim involving a commercial use of a vehicle covered for personal use only, a claim where the vehicle mileage falls within the first or last 1000 miles covered by the service contract, a loss date within the first or the last month of the service contact, a large jump in mileage for the vehicle, and other similar circumstances. Inspection requirements may be evaluated using data provided through any portion of the GUI 300 and/or other data. A plurality of inspection conditions may be automatically evaluated and/or reevaluated in order to populate the Inspection Required field 326. In one embodiment, if an inspection is required, an override action, an explanatory note, or some other procedure may be required in order to enable authorization of the claim without performing such an inspection. A verification that a required inspection has been performed may be provided through input of an appropriate status entry.
The Deductible field 327 of the Parts interface 320 shows a deductible amount to be charged to the customer for the claimed repair, if applicable. In one embodiment, the Deductible field 327 is automatically populated with a deductible amount based upon the contract terms specified from a contract record retrieved from the contract data source 121.
The Total Paid Amount field 328 shows a value for any money that has been paid out on a claim to-date. In one embodiment, the Total Paid Amount field 328 is populated from a data source accessible through an alternate interface, such as an accounting interface or a billing interface. The Total Paid Amount field 328 can be set so that it may not be modifiable by the user of GUI 300. The Total Authorized Amount field 329 shows a total claim amount less the deductible amount and any discount given. The Total Authorized Amount field 329 may be the aggregate of the amounts shown in the sub-total fields 325, minus the amount shown in the Deductible field 327. Figure 5 shows a Status interface 330. In one embodiment, the Status interface
330 is accessed by selecting the Status Action tab 309c (shown in Figure 3). The Status interface 330 is used for entry and review of one or more status changes that have been made to a claim, such as a denial of a claim or a receipt of a facsimile. The Status interface 330 may be periodically accessed throughout the course of processing of the claim in order to record a plurality of events and changes in the status of the claim. In some cases, the user may initiate the Status interface 330 in order to record an event, such as a receipt of a phone call or a letter. In some cases, a status entry may be automatically generated by virtue of an action taken through another interface (e.g., a claim denied from Claim Summary interface 310) or another application system (e.g., a check sent by the user of a separate billing system). In some cases, a status entry may be automatically created based upon an action condition and the user may be directed to the Status interface 330 to review or complete the status entry. The Claims Information field 305, the Contract Information field 306, and the Vehicle Information field 307 shown in Figure 5 are automatically populated based upon the information provided through the Claim Summary interface 310. The Status interface 330 may include a Status History table 331, a Status Selection field 332, a Status Explanation field 333, and an Override field 334.
The Status History table 331 shows a complete history of status changes to a specified claim. The Status History table 331 allows the user to get, at a glance, a summary of a plurality of events that have taken place with regard to the specified claim during the course of processing the claim. The Status History table 331 may include a User column 331a, a Date column 331b, an Action column 331c, and an Explanation column 33 Id. The User column 331a identifies the user who made a particular status change. The Date column 331b identifies a date and/or a time the status change was made. The Action column 331c identifies what status action was performed or occurred. Status actions may, for example, include opening a claim, closing a claim, reopening a claim, sending an inspector, denying a claim, authorizing a claim, receiving a document or correspondence with respect to a claim, sending a document or correspondence concerning a claim, receiving an inspection report, and changing parts or labor and other similar actions. The Explanation column 33 Id includes the explanation or description of the action that was taken or performed or the event that occurred. In one embodiment, selection of a particular status action (e.g., by clicking or hovering) may provide the user with additional information about the status action.
The Status Selection field 332 is used for identifying a new status action. In one embodiment, Status Selection field 332 is a drop down menu containing a list of status actions. Each status action may be identified by a status action code. The Status Selection field 332 may be automatically populated in response to a status action performed through another interface.
The Status Explanation field 333 allows a user to input text for an explanation or description of the action taken. Or, Status Explanation field 333 may be automatically populated with a partial explanation or an explanation format based upon a selected status.
The Override field 334 allows initiation of a status action which may be otherwise prohibited by claim processing procedures or protocol embodied in interface logic. In some cases, the Override field 334 may be automatically populated based upon override data provided through another interface, such as the Claim Summary interface 310. In one embodiment, the Override field 334 may include an identifier field for identifying the user authorizing the override condition and a password field for providing an override security and identity verification.
Figure 6 illustrates a Notes interface 340. In one embodiment, the Notes interface 340 is accessed by selecting the Notes tab 309d. The Notes interface 340 displays a history of changes saved to the system. A new notes entry may be created every time the Save button 308e is pressed. A user may initiate a new note or, alternatively, a new note may be automatically initiated and a user may manually complete the new note. User tools may be provided for searching for or filtering displayed notes. The Claims Information field 305, the Contract Information field 306, and the Vehicle Information field 307 shown in Figure 6 are automatically populated based upon the information provided through the Claim Summary interface 310. The Notes interface 340 may include a Type field 341, an ID field 342, a Notes History table 343, and a New Note field 344.
The Type field 341 allows the user to select the type of note to be entered. Note types may include, for example, a contract note, a dealer note, a vehicle note, and a repair facility note. In one embodiment, the note type choices are provided in a drop down menu.
The ID field 342 allows a user to select a note identifier for the note to be entered. The note identifiers may include, for example, a denial, an inspection, an authorization, and a payment. Note identifier choices may be provided in a drop down menu. Alternatively, selection of an inspection identifier for a note automatically forwards a notification requesting an inspection to the appropriate system when the note is saved. The Notes History table 343 provides a summary of all past changes to a claim record saved to the system 100 or 200. In one embodiment, the Notes History table 343 includes a User column 343a, a Date/Time column 343b, a Type column 343c, a Note column 343d and an ID column 343e. The User column 343a displays an identifier for the user that saved the changes or authored the note. The Date/Time column 343b displays the date and/or time at which the note was generated. The type column 343c displays the type of the note. The Note column 343d displays a text description of the note. The ID column 343e displays the identifier for the note. In one embodiment, the note entries displayed within the Notes History table 343 may be searched for a specific entry in any of the columns, or the note entries displayed within the Notes History table 343 may be filtered and/or grouped according to type, ID, date, or another characteristic. Note entries within the Notes History table 343 may be selected to provide additional data regarding the note. The additional data may include an archival record of some or all of the claim data at the time that the note was created.
The New Note field 344 allows a user to manually enter a new note. In one embodiment, the New Note field 344 also allows a user to add an annotation to an existing note. Alternatively, the New Note field 344 may be an open text field.
Figure 7 is an exemplary Search interface 350. In one embodiment, the Search interface 350 is initiated by selecting "Search" using a button, a menu, or a similar selector. The Search interface 350 allows a user to search for and locate a particular contract and/or claim. The Search interface 350 may include a plurality of search fields 351 which may be used alone, or in combination, to locate a particular contract or claim. The Search interface 350 may include as search fields a VIN, a customer name (first, last, middle initial), a contract number, a claim number, or other similar fields. The search fields 351 may accept partial values for searching. The Search interface 350 may also include a Search Results field 352. In one embodiment, the Search Results field 352 is in a format of a table with a plurality of entries for each contract and/or claim retrieved by the search. The Search Results field 352 may include a number of columns for one or more descriptive characteristics for each entry. The Search Results field 352 may include, for example, a contract number, a claim number, a VIN, a customer name, a year, a make, a model, and a contract and/or claim status. A particular entry in the Search Results field 352 may be selected by clicking on it and pressing an OK button or by double clicking on it. Selection of an entry in the Search Results field 352 may open a Claim Summary interface 310 for a selected claim or a new Claim Summary interface 310 for a selected contract. The Search interface 350 may include a number of Search Action buttons 353. The Search Action buttons 353 may include a Retrieve button 353a, a Claim Search button 353b, a Clear button 353c, and a Contract Not on File (CNOF) button 353d. Selection of the Retrieve button 353a retrieves additional search results based upon information provided in the Search fields 351. Selection of the Claim Search button 353b initiates a claim search based upon information provided in the Search fields 351. Selection of the Clear button 353c clears any entries in the Search fields 351. Selection of the CNOF button 353d initiates a procedure for starting a new claim for a contract not already within the contract data source 121 and may activate a new Claim Summary interface 310 with editable contract and vehicle information fields.
Figure 8 illustrates an exemplary Dealer Search interface 360. The Dealer Search interface 360 allows a user to access a search engine for locating a particular dealer based upon one or more characteristics. The Dealer Search interface 360 may be accessed from a Contract Information pop-up window or a Claim Summary interface 310 with editable contract information in order to populate dealer-related information within a new contract record. The Dealer Search interface 360 includes a Search Criteria field 361, a Results table 362, and a plurality of Function buttons 363. The Search Criteria field 361 allows a user to specify one or more field values or dealer characteristics for which to conduct a search. The Search Criteria field 361 may include, for example, a dealer name, a dealer zip code, and a dealer number, etc. The Results table 362 displays information about each dealer matching the specified search criteria. The Results table 362 may display a variety of dealer field entries or characteristics. For example, the Results table 362 may include a dealer number, a dealer name, and a dealer address. In one embodiment, the Results table 362 will display a plurality of retrieved dealer records, arranged in descending order from the retrieved dealer record which most closely matches the specified search criteria to more remote matches. The Function buttons 363 allow a user to initiate a search and select a particular search result. The Function buttons 363 may include a search button for initiating a search, a clear button for clearing the search criteria, an OK button for selecting a particular dealer, and a cancel button for exiting the Dealer Search interface 360 without selecting a dealer. The selection of a dealer entry in the search results in the Results table 362 automatically populates the dealer related fields of the interface from which the Dealer Search interface 360 was selected.
Figure 9 is an illustrative Repair Facility interface 370. The Repair Facility interface 370 allows a user to access information related to a repair facility of interest. The Repair Facility interface 370 combines the functions of searching for a record for a repair facility of interest and displaying fields and information regarding a selected repair facility of interest beyond the information displayed in other interfaces. For example, the Repair Facility interface 370 may be accessed from the Claim Summary interface 310 in order to search for a particular repair facility during the process of creating a new claim record. Alternatively, the Repair Facility interface 370 may be accessed from the Claim Summary interface 310 for a claim which already contains repair facility information, in order to display additional repair facility information beyond that which is displayed through the Claim Summary interface 310. Repair Facility interface 370 may include a Search Criteria field 371, a Repair Facility Information field 372, a Results table 373, and a plurality of Function buttons 374. The Search Criteria field 371 may include a plurality of different search criteria including, for example, an issuing dealer, a zip code, a telephone number, and a repair facility name. The issuing dealer field may be checked if the repair is performed at the dealer that issued the service contract. The Repair Facility Information field 372 may include a plurality of informational categories about a particular repair facility including, for example, a repair facility name, an address, a telephone number, a facsimile number, a vendor number, a labor rate, and a special investigation field. The special investigation field may include an identifier for any special handling instructions, such as a mandatory investigation, for claims through the specified repair facility.
The Results table 373 may include a plurality of information about repair facilities meeting the search criteria, for example, a vendor number, a repair facility name, and an address. A user may select one of the entries in the Results table 373 by clicking on the entry line for the desired entry, tabbing through the entries, or by another similar method. The selection may also be combined with use of one or more of the Function buttons 374 to initiate one or more further actions. The Function buttons 374 may include, for example, a Search button, a Clear button, an OK button, and a Cancel button. Selection by the user of the OK button and/or selection of an entry in the Results table 373 results in the population of repair facility information about a specific repair facility within the interface from which the Repair Facility interface 370 was accessed.
Figure 10 is a flowchart illustrating the steps conducted in the claim administration process utilizing GUI 300 in accordance with an embodime it of the invention. The process illustrated in Figure 10 may be performed utilizing the systems 100 or 200 described with regard to Figures 1-9 above.
In step 1001, a new claim is submitted to the warranty service contract provider and a new claim record is initiated by the warranty service contract provider. The new claim may be initiated in response to a telephone call or other correspondence from a repair facility, a customer, or another entity. A claims adjuster or other user of system 100 or 200 may access the claim system 100 or 200 through a user terminal 110 or 210 in communication with system 100 or 200, respectively, which includes one or more Claim data sources 122. The new claim record may be established through a Claim Summary interface 310, with or without the supplemental interfaces, in accordance with the process described with reference to Figure 11 below. The new claim record for the claim, once created, may be saved within one or more Claim data sources 122 as described above.
In step 1010, a plurality of repair details relating to the new claim are entered into the new claim record. The repair details may be provided by a repair facility once the repairs are estimated. The repair details may be entered through a Claims Summary interface 310 in accordance with the process described with reference to Figure 12 below. Evaluation of the repair details and/or other claim data may identify the new claim as a claim requiring inspection under standard claim protocols.
If the standard claim protocols require or recommend an inspection of the new claim, the inspection may be initiated in step 1011 by entering an appropriate note through an inspection interface (step 1030). In step 1012, one or more appropriate status actions may be entered to reflect initiation and completion of an inspection process before the user may authorize or deny the claim (step 1040). In one embodiment, a requirement for initiation and/or completion of an inspection prior to granting authorization of a claim may be overridden by an authorized user. If after step 1010 the claim did not require an inspection, then the user should enter information concerning the status action in step 1020 through use of the Status interface 330 and also enter an explanatory note in step 1030 through use of the Notes interface 340.
The user may continue the process in step 1040 where the claim is authorized or denied. Authorization or denial may be achieved by selection of an appropriate function button available in one or more interfaces. In one embodiment, the authorization and/or denial may be automatically determined by the system 100 or 200 based upon the information entered by the user into one or more of the interfaces at step 1050. Following authorization or denial of the claim, in step 1060, a note providing an explanation of the authorization or denial may be input by the user.
Figure 11 is a flowchart illustrating the steps conducted during the process of initiating or setting up a new claim record in accordance with an embodiment of the invention. A new claim may be initiated through one or more interfaces in a manner as described above with regard to Figures 1-9. The process of Figure 11 may be used to create a new claim record, initiate various claim procedures, and evaluate a claim for pre- authorization of a repair, if pre-authorization is necessary.
In step 1101, a warranty service claim system, such as system 100 or 200, is accessed by a user via GUI 300. The user may be required to provide a user identification and a security verification prior to gaining access to system 100 or 200. The user identification may also be automatically recorded in one or more entries in a claim record to provide user accountability for actions taken with respect to a specific claim. In step 1102, a new claim interface may be initiated and, for example, a status of such claim should be verified as open. In one embodiment, a claim number for the new claim is not assigned until the first time the new claim is saved in the data source.
In step 1103, a contract record for the new claim is identified and selected for retrieval. In one embodiment, a search of a contract data source 121 is initiated, for example, by inputting one or more search criteria such as a customer name, a contract number, a VIN, or another identifier associated with the contract associated with the new claim. A specific contract may be selected from a list of contracts returned from the search. Once the identified contract is retrieved from the contract data source 121, the contract and vehicle information associated with the retrieved contract may be automatically populated within the new claim interface. The Contract Information pop-up window may be accessed by the user, if necessary, to verify additional contract information beyond the contract information available through the new claim interface. If there is no contract record within the contract data source 121 for the new claim, in step 1104, an interface with editable contract information is accessed and contract information and/or vehicle information is entered by the user. Alternatively, a search of the vehicle data source 123 may be conducted and a vehicle record may be retrieved to populate the vehicle information required for the fields in the contract interface. The claim status for the claim should indicate that the claim is awaiting contract verification. Alternatively, a contract verification procedure may be automatically initiated. An appropriate status action and note may also be automatically initiated in response to a new contract entry.
In step 1105, the vehicle information is verified. This step may include verifying the year, make, model, VIN, and purchase price of the vehicle subject to the claim. In step 1106, a repair facility associated with the claim is identified and selected via the Repair Facility interface 370. The Repair Facility interface 370 may include a search interface enabling the user to conduct a search for the identified repair facility by inputting the repair facility name, telephone number, zip code, or other information.
In step 1107, additional repair facility information relevant to the particular claim may be entered by the user. Such additional repair facility information may include the date of the claim, the mileage for the vehicle on the date of the claim, a contact person at the specified repair facility, an order number, and other similar information. In step 1108, a record for a customer complaint may be entered.
In step 1109, one or more major components requiring repair are identified and may be selected from a drop down menu. The major components may be identified by major component codes.
In step 1110, one or more related claims may be reviewed. A table including a plurality of summaries of claims related to the identified contract may be provided for review. A total of the related claims may also be provided for review. Or, the related claims may be automatically evaluated against one or more conditions and any suspect pattern of claims is identified.
In step 1111, the user inputs information concerning whether the vehicle associated with the claim is used for personal or commercial use. Or, a default value may be provided which may be derived from previous personal or commercial use entries in related claims. Depending upon the type of use for the vehicle, alternate handling procedures or inspection criteria for the claim may be initiated.
In step 1112, any modification made to the vehicle subject to the claim is identified. In one embodiment, a default value may be provided. The default value may be "yes" if the vehicle was identified as modified in any previous claim. If a modification was unauthorized (or not in accordance with a manufacturer's specifications for the vehicle), such information may be used to initiate alternate handling procedures, inspection criteria, or eligibility for authorization for the claim.
In step 1113, an estimated cost of repair is entered into the claim record. The estimated cost of repair is provided by the repair facility. The estimated cost of repair may also be added to the cost of related claims for identifying a cap on an amount of an authorized claim or a pattern of suspicious claims by the customer or the repair facility.
Figure 12 is a flowchart illustrating the steps performed during a process of recording claim repair details after a repair is completed in order to evaluate a final authorization and payment of a claim. This process may be carried out utilizing the systems 100 or 200 described above with regard to Figures 1-9 and specifically with regard to the Parts interface 320 shown in Figure 4. In step 1201, a Parts interface 320 is accessed by the user. The Parts interface 320 is a sub-interface of a Claim interface for an existing claim. The Parts interface 320 may have been previously populated with basic claim, contract, and vehicle information.
In step 1210, the repair facility information is verified. A labor rate field and a corporate discount field may be provided with default entries from a prior repair facility record for the same repair facility.
In step 1220, tax information is entered in the appropriate field in Parts interface 320. For example, a tax jurisdiction is selected. Tax rate information for the chosen tax jurisdiction may be manually entered or may be automatically retrieved from a tax rate data source. Alternatively, upon input of the repair facility zip code or other geographic identifier, the tax jurisdiction may be automatically entered. Or, the tax information may be automatically retrieved from the repair facility record.
In step 1230, a plurality of component details are entered by the user into the Parts interface 320 to provide an itemized description of the repair associated with the claim. Such component details may be provided by the repair facility. The component details may include required parts and labor for the repair. Moreover, the component details may also include towing and car rental. Specific components required for the repair may be chosen from a list of components based upon the major components previously identified as requiring repair. A cost, a quantity, and a labor rate may also be entered for each specified component.
In step 1240, a total and any subtotals for the required repair are verified. The total and subtotals for the required parts, labor, and taxes may be automatically calculated from the component details provided as described above. Then, a deductible amount as specified in the customer's warranty service contract may be retrieved from the contract data source 121. The deductible amount may be reduced or deleted if appropriate. A total amount authorized for the claim and a total amount paid may also be calculated.
In step 1250, one or more inspection procedures with respect to the claim may be initiated if the information input by the user triggers such inspection procedures. A number of conditions for recommending or requiring an inspection are automatically evaluated. For example, if the customer has previously submitted a high number of claims, an inspection of the current claim may be required. If an inspection is required, an inspection flag will indicate the need for an inspection to the user. The inspection procedures may be automatically initiated, or, alternatively, a note may be generated which initiates a request for inspection through an appropriate inspection system. A status action may also be generated to show that an inspection has been requested. The claim authorization mechanism may be disabled until a status action indicating that the inspection is complete is input, or the user overrides the inspection and provides an explanatory note for such an override.
As described above, the system and process of the present invention enables an efficient, user-friendly means for a warranty service contract provider to process claims of its customers under the service contracts. It will be apparent to those skilled in the art that various modifications and variations can be made in the systems and processes of the present invention without departing from the scope or spirit of the invention. Thus, it is intended that the present invention cover the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.

Claims

WHAT IS CLAIMED IS:
1. A system for warranty service claim data access, retrieval and entry comprising: at least one data source including claim data for a plurality of warranty service claims; a claim interface for accessing and retrieving data contained in, and for entry of data by a user into, said at least one data source, said claim interface including a plurality of task oriented interfaces; and at least one logic module responsive to data entered through said claim interface for automatically evaluating a plurality of action conditions and directing said claim interface based upon a plurality of predefined claim processing protocols.
2. The system of claim 1, wherein said claim interface includes at least one search interface for accessing and retrieving desired data within said at least one data source based upon a partial description of theodesired data, and wherein the accegsing and retrieving of the desired data automatically populates at least one field in said claim interface.
3. The system of claim 2, wherein said at least one search interface includes a claim search interface, a contract search interface, and a repair facility search interface.
4. The system of claim 1 , wherein the plurality of action conditions include an identification of a predefined number of related claims and wherein, if the predefined number of related claims are identified, said claim interface is directed to prompt the user to initiate an investigation into the related claims.
5. The system of claim 1 wherein the plurality of action conditions include a calculation of a claim amount in excess of a predetermined amount, and wherein, if the claim amount calculated is in excess of the predetermined amount, said claim interface is directed to require additional authorization to authorize payment of the claim.
6. The system of claim 1 wherein the plurality of action conditions include a plurality of inspection criteria and said claim interface is directed to access an interface for initiating an inspection.
7. The system of claim 1 wherein said claim interface includes a denial selector for initiating a claim denial protocol.
8. The system of claim 1 wherein said claim interface includes an authorization selector for initiating a claim authorization protocol.
9. The system of claim 8, wherein the authorization selector is not enabled until each of a plurality of conditions for authorizing a claim is satisfied.
10. The system of claim 1, wherein said at least one data source includes notes data including a record of each change made in the claim data over the course of processing of a claim.
11. A graphical user interface (GUI) for facilitating warranty service claim processing comprising: a claim summary interface for providing a summary of information regarding a claim; a parts interface for providing a detailed description of repairs made; a status interface for providing a summary record of each action taken during processing of the claim; and a notes interface for providing one or more supplemental descriptions of each action taken with regard to the claim.
12. The GUI of claim 11, wherein said claim summary interface includes a claim tracking information field, a contract information field, a repair facility information field, a customer complaint information field, a basic claim information field, and a related claim information field.
13. The GUI of claim 11, wherein said parts interface includes a labor rate information field, a tax information field, and a field including a list of parts, a list of labor rates, and a list of costs.
14. The GUI of claim 11, wherein said status interface includes a status history summary field and at least one field for a new status entry.
15. The GUI of claim 11, wherein said notes interface includes a notes history summary field and at least one field for a plurality of new notes.
16. The GUI of claim 15, wherein said notes interface includes a plurality of filters for selectively viewing one of more portions of the notes history summary field.
17. The GUI of claim 11, further comprising a claim search interface for initiating a search to locate a desired claim record.
18. The GUI of claim 11 , further comprising a contract search interface for initiating a search to locate a desired contract record.
19. The GUI of claim 11, further comprising a dealer search interface for initiating a search to locate a desired dealer record.
20. The GUI of claim 11 , further comprising a repair facility search interface for initiating a search to locate a desired repair facility record.
21. The GUI of claim 11 , further comprising a supplemental information interface for providing supplemental information related to information displayed in another interface.
22. A claim administration process using a graphical user interface for at least one data source comprising the steps of: providing at least one user interface including a plurality of fields corresponding to a plurality of elements in at least one data source; providing at least one function button corresponding to a claim-related task wherein selection of at least one function button initiates a predefined claim protocol utilizing data from the at least one data source; and whereby a user may .retrieve data from the at least one data source and enter data into the at least one data source via the at least one user interface over a course of processing a claim.
23. " The process of claim 22, wherein the step of providing at least one user interface includes providing a claim summary interface, a parts interface, a status interface, and a summary interface.
24. The method of claim 22, wherein the step of providing at least one user interface includes providing a plurality of search interfaces for locating data within the at least one data source.
25. The method of claim 22, wherein the step of providing at least one function button includes providing a denial button for initiating a claim denial protocol.
26. The method of claim 22, wherein the step of providing at least one function button includes providing an authorize button for initiating a claim authorization protocol.
27. The method of claim 22, further comprising the step of validating the data entered by the user against a predefined claim procedure.
28. The method of claim 22, further comprising the step of performing an automated action in response to data entered meeting a predefined action condition.
PCT/US2001/032148 2000-10-19 2001-10-17 Graphical user interface for a warranty claim system WO2002033624A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2002211749A AU2002211749A1 (en) 2000-10-19 2001-10-17 Graphical user interface for a warranty claim system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US69114400A 2000-10-19 2000-10-19
US09/691,144 2000-10-19

Publications (1)

Publication Number Publication Date
WO2002033624A1 true WO2002033624A1 (en) 2002-04-25

Family

ID=24775329

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/032148 WO2002033624A1 (en) 2000-10-19 2001-10-17 Graphical user interface for a warranty claim system

Country Status (2)

Country Link
AU (1) AU2002211749A1 (en)
WO (1) WO2002033624A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060111924A1 (en) * 2004-11-24 2006-05-25 Franz Hollich Method and system for warranty claim processing
US8140852B2 (en) * 2008-06-16 2012-03-20 International Business Machines Corporation Authenticating serialized commodities

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5191522A (en) * 1990-01-18 1993-03-02 Itt Corporation Integrated group insurance information processing and reporting system based upon an enterprise-wide data structure
US5950169A (en) * 1993-05-19 1999-09-07 Ccc Information Services, Inc. System and method for managing insurance claim processing
US6182048B1 (en) * 1998-11-23 2001-01-30 General Electric Company System and method for automated risk-based pricing of a vehicle warranty insurance policy
US6338093B1 (en) * 1996-03-28 2002-01-08 Dirienzo Andrew L. Attachment integrated claims system and operating method therefor

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5191522A (en) * 1990-01-18 1993-03-02 Itt Corporation Integrated group insurance information processing and reporting system based upon an enterprise-wide data structure
US5950169A (en) * 1993-05-19 1999-09-07 Ccc Information Services, Inc. System and method for managing insurance claim processing
US6338093B1 (en) * 1996-03-28 2002-01-08 Dirienzo Andrew L. Attachment integrated claims system and operating method therefor
US6182048B1 (en) * 1998-11-23 2001-01-30 General Electric Company System and method for automated risk-based pricing of a vehicle warranty insurance policy

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060111924A1 (en) * 2004-11-24 2006-05-25 Franz Hollich Method and system for warranty claim processing
US8140852B2 (en) * 2008-06-16 2012-03-20 International Business Machines Corporation Authenticating serialized commodities

Also Published As

Publication number Publication date
AU2002211749A1 (en) 2002-04-29

Similar Documents

Publication Publication Date Title
US11151645B2 (en) Generating customer-specific vehicle proposals for potential vehicle customers
US6941305B2 (en) Customer management system for automobile sales industry
US7778841B1 (en) System and method for generating information relating to histories for a plurality of vehicles
US8595079B1 (en) System and method for determining vehicle price values
US8600823B1 (en) System and method for determining vehicle price adjustment values
US20020077944A1 (en) System and method for disposing of assets
US20140052478A1 (en) Method and System for Marketing Vehicles for Sale or Lease to Replace Totaled Vehicles
US20030154094A1 (en) Interactive warranty product comparison system and method
EP1168224A1 (en) Sales method, systems and apparatus
US11062275B2 (en) Auto repair quote platform
US20160110804A1 (en) Generating customer-specific vehicle proposals for potential vehicle customers
US7395275B1 (en) System and method for disposing of assets
US20070136190A1 (en) Electronic service procurement and invoicing system
EP1242906A2 (en) System and method for virtual rental fleet, modeling a simulated fleet of assets and disposing of assets
US6850894B2 (en) Electronic shopping system
WO2002033624A1 (en) Graphical user interface for a warranty claim system
US20020091540A1 (en) Method and system for emergency assistance management
US20200380574A1 (en) Automobile Purchase Method
WO2000062219A1 (en) Comparative quoting system
WO2001090846A2 (en) System and method of providing uniform rates for warranties
WO2001020516A9 (en) Tracking system for customer electronic purchase requests and purchases

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PH PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP