EP1696381A1 - Systeme und Verfahren zur Bestimmung des Fahrzeugschrottwertes - Google Patents

Systeme und Verfahren zur Bestimmung des Fahrzeugschrottwertes Download PDF

Info

Publication number
EP1696381A1
EP1696381A1 EP06110128A EP06110128A EP1696381A1 EP 1696381 A1 EP1696381 A1 EP 1696381A1 EP 06110128 A EP06110128 A EP 06110128A EP 06110128 A EP06110128 A EP 06110128A EP 1696381 A1 EP1696381 A1 EP 1696381A1
Authority
EP
European Patent Office
Prior art keywords
bid
vehicle
bids
communication network
virtual
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP06110128A
Other languages
English (en)
French (fr)
Inventor
David L. Bauer
Aaron J. Adair
Willis J. Johnson
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Copart Inc
Original Assignee
Copart 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 Copart Inc filed Critical Copart Inc
Publication of EP1696381A1 publication Critical patent/EP1696381A1/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/08—Auctions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/08—Insurance

Definitions

  • the insurance company decides whether to repair or "total" the vehicle. Typically, the insurance company will deem the vehicle “totaled” when the cost to repair the vehicle is greater than either the value of the vehicle prior to the accident or the value of the vehicle prior to the accident less the salvage value of the vehicle. In such a situation, the insurance company generally reimburses a policyholder the pre-damage value of the vehicle instead of paying for the vehicle to be repaired.
  • an insurance adjuster usually travels to the vehicle and performs an inspection. The insurance adjuster then sets the pre-damage value based on comparisons with sales of similar vehicles, taking into account factors such as vehicle condition and mileage.
  • the policyholder may either accept the reimbursement payment (i.e., the pre-damage value of the vehicle as determined by the insurance adjuster) and relinquish the vehicle or retain the vehicle.
  • the insurance company pays the policyholder the value of the pre-damaged vehicle less the salvage value of the damaged vehicle._The right of a policyholder to retain the vehicle is commonly referred to as owner retention.
  • owner retention a policyholder will decide to retain the vehicle because it is still drivable, or because the damage is not of concern to the policyholder (e.g., the damage is merely aesthetic).
  • Insurance companies have conventionally relied on a number of different techniques for estimating vehicle salvage value. Some of these techniques are based on actual salvage values for similar vehicles having similar damage. For instance, the average of actual salvage values of similar vehicles may be calculated and used as an estimated salvage value for a particular vehicle. Other conventional techniques simply calculate and use a predetermined percentage of the pre-damage value of a vehicle. Unfortunately, values generated by the above-described conventional techniques are usually too conservative and frequently inaccurate. That is, the values often fail to accurately represent actual fair market salvage values.
  • soliciting bids by telephone generally fails to produce a reliable record of how salvage values are determined.
  • a bidder may be induced by the insurance adjuster to offer an unreasonably high bid for the vehicle in order to decrease the liability of the insurance company. Consequently, policyholders may be unknowingly and undesirably affected by unfair practices that go unnoticed when an adequate record is not produced. The lack of an adequate record may also leave insurance companies vulnerable to legal action, including governmental audit and sanction.
  • Figure 1 is a block diagram illustrating an exemplary system for determining vehicle salvage value, according to principles described herein.
  • FIG. 2 is a block diagram of an exemplary bid module of Figure 1, according to principles described herein.
  • Figure 3 is an illustration of an exemplary graphical user interface configured to be presented during a preliminary bid stage, according to principles described herein.
  • Figure 4 is an illustration of an exemplary graphical user interface configured to be presented during a virtual bid stage, according to principles described herein.
  • FIG. 5 is a flowchart illustrating an exemplary process of determining vehicle salvage value, according to principles described herein.
  • Figure 6 is a flowchart illustrating an exemplary process of determining a disposition of a vehicle based on vehicle salvage value, according to principles described herein.
  • This specification describes systems and methods for determining a vehicle salvage value.
  • the systems and methods described herein can determine a vehicle salvage value based on one or more actual bids received for a vehicle over a data communication network. These bids each represent an amount a bidder is actually willing to pay for the vehicle if the owner decides not to retain the vehicle and may be binding on and result in a sale of the vehicle to the bidder.
  • data representative of the vehicle may be posted for access over the data communication network and used to solicit bids for the vehicle.
  • One or more bids may be received and used to set the salvage value of the vehicle.
  • the salvage value is set to the value of the highest bid received for the vehicle.
  • An insurance adjuster may then be notified of the determined salvage value.
  • the insurance adjuster may use the information to determine whether it is more economically practical to deem the vehicle "totaled” or to have the vehicle repaired. In the case that the vehicle is deemed “totaled," the insurance adjuster is able to present at least two options to the policyholder associated with the vehicle: (1) accept full reimbursement (i.e., the determined pre-damage value of the vehicle) and relinquish the vehicle or (2) retain the vehicle and accept the pre-damage value less the determined salvage value of the vehicle.
  • the present systems and methods may be configured to provide notification of determined salvage value to the policyholder and/or insurance agent, receive data representative of a decision of the policyholder or insurance agent, and determine a disposition of a vehicle based on the decision.
  • the present systems and methods may be configured to notify potential bidders of "on-approval" sale conditions and of the decisions of policyholders or insurance agents.
  • the systems and methods described herein are able to determine and set salvage values based on what bidders have indicated they are actually willing to pay for vehicles.
  • Use of a data communication network for soliciting bids allows numerous bidders to submit bids, which generally tends to raise bid quantities and values and reaches a more accurate determination of the actual value of the damaged vehicle.
  • detailed descriptions of the vehicles, including visual images and/or video can be provided to potential bidders over the data communication network so that the bidders can visually inspect the vehicles without having to incur travel costs and without the vehicles having to be transported. The ability to visually inspect the vehicles can increase bidder confidence and result in higher bids being placed.
  • the systems and methods described herein can maximize the fair market value of vehicles, thereby helping insurance companies make educated decisions concerning the disposition of vehicles, as well as saving insurance companies money in owner retention situations. As insurance companies compete for business, these savings may be passed on to policyholders in the form of decreased premiums and/or increased coverage.
  • the systems and methods described herein are also able to produce reliable records indicative of how salvage values are determined. Communications sent over the data communication network may be recorded and archived. Accordingly, insurance companies can use the records to verify the use of legitimate and fair practices for determining salvage values that comply with any applicable rules or laws. Other uses and benefits of the systems and methods described herein will become apparent upon consideration of the following examples.
  • Figure 1 illustrates an example of a system 100 for determining vehicle salvage value.
  • access devices 104-1 through 104-N may be communicatively coupled to valuation subsystem 110 by data communication network 120.
  • the data communication network 120 includes the Internet or World Wide Web.
  • Access devices 104 and valuation subsystem 110 may communicate over data communication network 120 using any known communication technologies, devices, media, and protocols supportive of remote communications, including, but not limited to, transmission media, communications devices, Transmission Control Protocol (“TCP"), Internet Protocol ("IP”), File Transfer Protocol (“FTP”), teinet, Hypertext Transfer Protocol (“HTTP”), socket connections, packet-switching technologies, circuit-switching technologies, wireless communication technologies (e.g., cellular telephone and wireless access technologies), and any other suitable communications technologies.
  • TCP Transmission Control Protocol
  • IP Internet Protocol
  • FTP File Transfer Protocol
  • HTTP Hypertext Transfer Protocol
  • valuation subsystem 110 may include input module 130, data store 140, bid module 150, valuation module 170, notification module 180, transaction module 182, and reward module 184 communicatively coupled as shown in the Figure.
  • the elements of valuation subsystem 110 may communicate using any suitable communication technologies, including any of the communication technologies previously listed.
  • Input module 130 may receive vehicle data 185, which can be stored in data store 140.
  • Bid module 150 may use the vehicle data 185 to put one or more vehicles up for bid over data communication network 120, as described in detail below.
  • Bidders may use access devices 104 to submit bids for the vehicles.
  • Bid module 150 may receive bids and generate a record of the bids and corresponding bid processes. The record may be referred to as bid record 188 and may be stored to data store 140.
  • bid module 150 may generate and provide bid results 190 to valuation module 170, which may be configured to use the bid results 190 to determine values associated with vehicles, including salvage values of vehicles.
  • Notification module 180 may be used to communicate determined values to users (e.g., insurance adjusters) of access devices 104 and to receive acceptance and/or rejection messages (e.g., messages representative of decisions to retain or relinquish vehicles) from the users. Notification module 180 may also notify bidders whether sales of vehicles have been approved or rejected. When sales are approved, transaction module 182 may perform operations helpful for completing the transactions. When owners retain vehicles and the high bid is consequently rejected for purposes of a sale, reward module 184 may still assign rewards to the highest bidder, as will be described in more detail below.
  • valuation subsystem 110 is implemented in one or more computers.
  • Valuation subsystem 110 may include any computer hardware and/or instructions (e.g., software programs), or combinations of software and hardware, configured to perform the processes described herein.
  • valuation subsystem 110 may be implemented on one physical computing device or may be implemented on more than one physical computing device.
  • valuation subsystem 110 may include any one of a number of computing devices known to those skilled in the art (e.g., one or more servers), and may employ any of a number of computer operating systems known to those skilled in the art, including, but by no means limited to, known versions and/or varieties of the Microsoft Windows® operating system, the Unix operating system, and the Linux operating system.
  • a processor e.g., a microprocessor
  • receives instructions e.g., from a memory, a computer-readable medium, etc.
  • executes those instructions thereby performing one or more processes, including one or more of the processes described herein.
  • Such instructions may be stored and transmitted using a variety of known computer-readable media.
  • a computer-readable medium includes any medium that participates in providing data (e.g., instructions) that may be read by a computer (e.g., by a processor of a computer). Such a medium may take many forms, including, but not limited to, non-volatile media, volatile media, and transmission media.
  • Non-volatile media may include, for example, optical or magnetic disks and other persistent memory.
  • Volatile media may include, for example, dynamic random access memory ("DRAM”), which typically constitutes a main memory.
  • Transmission media may include, for example, coaxial cables, copper wire and fiber optics, including the wires that comprise a system bus coupled to a processor of a computer.
  • Transmission media may include or convey acoustic waves, light waves, and electromagnetic emissions, such as those generated during radio frequency (“RF”) and infrared (“IR”) data communications.
  • RF radio frequency
  • IR infrared
  • Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASH-EEPROM, any other memory chip or cartridge, or any other medium from which a computer can read.
  • Each access device 104 may include any device or devices physically or remotely accessible to one or more users and that allows a user to provide input to and/or receive output from valuation subsystem 110.
  • access device 104 can include, but is not limited to, one or more desktop computers, laptop computers, tablet computers, personal computers, personal data/digital assistants, cellular telephones, satellite pagers, wireless internet devices, embedded computers, video phones, network interface cards, modems, optical network terminals, mainframe computers, mini-computers, programmable logic devices, vehicles, entertainment devices, gaming devices, music devices, wireless communication devices, wireline communication devices (e.g., Plain Old Telephone Service (“POTS”) telephones), analog telephone adapters ("ATAs"), devices operating softphones, devices operating Java Virtual Machines, Internet Protocol (“IP”) devices (e.g., IP-based phones), Session Initiation Protocol (“SIP”) devices (e.g., SIP phones), and any other devices capable of communicating with valuation subsystem 110 over data communication network 120.
  • Access device 104 can also include various peripheral
  • Access devices 104 may include instructions for generating and operating user interfaces. These instructions may be in any computer-readable format, including software, firmware, microcode, and the like. When executed by a processor (not shown) of a particular access device 104, the instructions may present one or more user interfaces to a user.
  • the user interfaces may be configured to present information to and receive input from users. For example, the user interface(s) described herein present information to users regarding a damaged vehicle and receive from users bids to purchase that vehicle.
  • the user interfaces may comprise one or more graphical user interfaces ("GUI") capable of displaying information and receiving input from users.
  • GUI graphical user interfaces
  • the user interfaces include one or more web browsers, such as Internet Explorer® offered by Microsoft Corporation of Redmond, Washington.
  • user interfaces are not limited to graphical interfaces or web form embodiments and may include many different types of user interfaces that enable users to utilize access devices 104 to communicate with valuation subsystem 110.
  • user interfaces may include one or more voice interfaces capable of receiving input from and providing output to a user.
  • valuation subsystem 110 may include technologies for processing voice and data signals, including voice recognition technologies and technologies for converting between voice and text (e.g., voice-to-text and/or text-to-voice converters).
  • Access devices 104 may include any combination or subset of the above-listed devices. Merely by way of example, one or more of the access devices 104 may include personal computers, while other access devices 104 may include other device types, such as cellular telephones. Regardless of the type or combination of devices, access devices 104 are able to communicate with valuation subsystem 110 over data communication network 120. Access devices 140 may be configured to utilize any suitable access technologies to access data communication network 120, including, but not limited to, known access networks, media, and protocols.
  • Data communication network 120 may include one or more networks suitable for carrying communications between access devices 104 and valuation subsystem 110.
  • data communication network 120 may include, but is not limited to, the Internet, World Wide Web and/or one or more intranets, local area networks, wide area networks, voice communication networks (e.g., the Public Switched Telephone Network ("PSTN”), Voice over Internet Protocol (“VoIP”), and wireless telephone networks), access networks, packet-switched networks, circuit-switched networks, and any other communications networks capable of carrying communications between access devices 104 and valuation subsystem 110.
  • Communication network 120 may include any devices, media, and technologies helpful for carrying communications between access devices 104 and valuation subsystem 110.
  • valuation subsystem 110 may include any device or combination of devices (e.g., servers) useful for communicating with access devices 104 over data communication network 120.
  • Valuation subsystem 110 may be configured to include and/or utilize any suitable access technologies, including, but not limited to, servers (e.g., web servers), security technologies, access levels, predefined access rules, firewalls, user lists, sign-on technologies, and any other technologies for controlling access to valuation subsystem 110.
  • valuation subsystem 110 is configured to restrict access to registered users.
  • Valuation subsystem 110 may include any known technologies for registering and validating users.
  • Valuation subsystem 110 may be configured to recognize different classes of users and to provide different predefined levels of access to the different user classes.
  • one class of users may include persons or entities desiring to have vehicles valued by valuation subsystem 110.
  • Such users may include agents of insurance companies (e.g., insurance adjusters).
  • Valuation subsystem 110 may provide specific functions to this class of users, including mechanisms by which the users can provide vehicle data 185, e.g., photographs of the damaged vehicle, and other input to valuation subsystem 110.
  • Another class of users may include persons or entities who/that submit or wish to potentially submit bids for damaged vehicles. This class of users, referred to herein as "bidders," may be granted access to functions for bidding on vehicles.
  • Yet another possible class of users may include policyholders associated with vehicles being valuated.
  • Valuation subsystem 110 may receive a variety of information from access devices 104.
  • valuation subsystem 110 may receive data representative of user registration and/or logon information, information associated with or descriptive of one or more vehicles, e.g., photographs of the damaged vehicle, bids placed by users of access devices 104, and decisions of insurance agents and/or policyholders.
  • Valuation subsystem 100 may also make a variety of information accessible to access devices 104.
  • valuation subsystem 110 may provide data representative of user registration and/or logon information, information associated with or descriptive of one or more vehicles, information associated with bids or bid processes, information associated with the outcome of bids (e.g., notifications of winning bids), and notifications of determined vehicle values. Exemplary elements and functions of valuation subsystem 110 will now be described in additional detail.
  • Input module 130 may be configured to provide and/or receive data to/from users who are approved to upload data representative of vehicle information. As mentioned previously, such users may include agents of insurance companies (e.g., insurance adjusters) and other pre-approved users. Insurance adjusters typically use some of the access devices 104 to provide vehicle data 185 to input module 130 through data communication network 120.
  • agents of insurance companies e.g., insurance adjusters
  • Insurance adjusters typically use some of the access devices 104 to provide vehicle data 185 to input module 130 through data communication network 120.
  • Vehicle data 185 may include, but is not limited to, text, audio, visual, and/or video descriptions or representations of vehicles, including descriptions of the conditions of vehicles, visual images of vehicles, vehicle maintenance records, vehicle histories, third-party valuations (e.g., Kelly Blue Book® values), vehicle mileage, vehicle color, vehicle features (e.g., leather seats, stereo make and model, engine specifications, navigation system, etc.), title information, estimated values of vehicles (e.g., pre-damage values of vehicles as determined by insurance adjusters), damage descriptions, vehicle locations, and any other information potentially useful for describing and/or valuating a vehicle.
  • third-party valuations e.g., Kelly Blue Book® values
  • vehicle mileage e.g., vehicle color
  • vehicle features e.g., leather seats, stereo make and model, engine specifications, navigation system, etc.
  • title information e.g., estimated values of vehicles (e.g., pre-damage values of vehicles as determined by insurance adjusters), damage descriptions, vehicle locations, and any other information potentially useful for
  • Insurance adjusters may obtain or generate information descriptive of vehicles during visual inspection of the vehicles. The insurance adjusters can then use access devices 104 to upload data representative of the information to input module 130. As described below, vehicle data 185 may be used to present vehicles for bid over data communication network 120 without the vehicles having to be transported or physically present at any specific location because the vehicle data 185 was previously obtained and provided to valuation subsystem 110.
  • Input module 130 may be configured to provide templates (e.g., Hypertext Mark-up Language (“HTML”) templates) to access devices 104, the templates being designed to accept input from users of access devices 104.
  • HTML Hypertext Mark-up Language
  • the templates may define user interfaces helpful for input of vehicle data 185.
  • Input module 130 may be configured to provide received data (e.g., vehicle data 185) to data store 140, which can store the data for subsequent access and use.
  • received data e.g., vehicle data 185
  • data store 140 which can store the data for subsequent access and use.
  • Data store 140 may include one or more data storage mediums, devices, or configurations and may employ any type, form, and combination of storage media known to those skilled in the art, including hard disk drives, read-only memory, caches, databases, optical media, and random access memory. Data store 140 may include any known technologies useful for storing, updating, modifying, accessing, retrieving, and deleting data.
  • Data store 140 may include any suitable type or form of electronic data representative of or associated with vehicles, user access privileges, bid records (described further below), and any other information that may be potentially useful for soliciting bids and/or valuating vehicles, including vehicle data 185, bid record 188, and bid results 190.
  • the data may be stored in extensible markup language (“XML”), or in any suitable form.
  • valuation subsystem 110 may be configured to store and/or retrieve data to/from external data sources. Any data potentially helpful for valuating vehicles, managing user access, and/or communicating with users may be retrieved from any suitable and accessible internal or external data source.
  • Bid module 150 may be configured to use vehicle data 185 to place one or more vehicles up for bid over data communication network 120.
  • bid module 150 may retrieve at least a subset of vehicle data 185 from data store 140 and make the retrieved data (or a copy of the retrieved data) available for access over data communication network 120.
  • bidders can utilize access devices 104 to consider and place bids on vehicles represented by vehicle data 185.
  • valuation subsystem 110 makes vehicle information widely accessible, which accessibility can in many instances increase the quantity and value of bids received for vehicles as compared to conventional techniques for estimating salvage values.
  • Receiving bids over data communication network 120 allows bids to be received and salvage values determined in an efficient, justifiable, cost-effective, and automated manner.
  • Soliciting bids over data communication network 120 also enables the presentation of helpful information associated with vehicles, which information can increase bid amounts and bidder confidence.
  • bid module 150 may provide any aspect of vehicle data 185 described above as part of a bid solicitation, including any combination of visual images, video, written description, and audio description of vehicles.
  • Bidders may be provided with access to a dynamic picture that may be rotated up to 360 degrees for viewing from different perspectives. By having access to helpful vehicle information such as visual images of vehicles, bidders can make educated and confident bids, which may in certain cases help increase the values of winning bids.
  • bidders may use access devices 104 to access and consider bid solicitations over data communication network 120.
  • bidders may use one or more domain names and/or IP addresses to access one or more sites (e.g., a websites) hosting bid processes or bid modules as described herein.
  • Bid module 150 may be configured to limit access to qualified bidders. For example, bid module 150 may request valid registration information from users before the users will be granted access. Accordingly, bid module 150 may maintain any registration information useful for controlling access to bid solicitations. Bid module 150 may be configured to receive registration information (e.g., user name, business name, contact information, payment information, password, etc.) associated with new users seeking registration. Once registration is completed, bid module 150 may provide the registered users with access to one or more bid processes supported by bid module 150. A separate bid process may be conducted by bid module 150 for each vehicle being valued or for a batch of one or more vehicles being valued.
  • registration information e.g., user name, business name, contact information, payment information, password, etc.
  • Bid module 150 may also be configured to control which registered bidders are allowed to bid on specific vehicles.
  • Bid module 150 may include predefined rules configured for use in identifying approved bidders. The predefined rules may determine who is allowed to bid on a particular vehicle. The rules may be defined in accordance with laws or governmental regulations such as license requirements for purchasing vehicles having specific types of titles (e.g., salvage titles).
  • Bid module 150 may also be configured to track and limit the number of bids accepted from or sales made to bidders, including the number of bids or sales within a predetermined length of time. The limits may be based on governmental regulations or business policies. Regulation of bids and sales can help prevent fraud, abusive practices, and potentially illegal activities.
  • bid module 150 is configured to provide a two-stage bidding process.
  • Figure 2 is a block diagram of the bid module 150 of Figure 1, according to a particular example. As shown in Figure 2, bid module 150 may include preliminary bid component 210 and virtual bid component 220, which may be configured to work together to provide a two-stage bid process, which will now be described in detail.
  • the first stage of an exemplary two-stage bid process may be referred to as a preliminary bid stage and may be provided by preliminary bid component 210.
  • the preliminary bid stage may be a static bid stage during which one or more bidders can consider and bid on any vehicle(s) in a batch.
  • preliminary bid component 210 may group one or more vehicles into a batch (i.e., a "sale list") and present the batch for consideration by one or more bidders.
  • a batch may include vehicles that are grouped based on geographic locations, sale dates, and/or other suitable criteria.
  • a batch may include vehicles having a common predetermined preliminary bid stage closing time and/or a common virtual bid start time. The vehicles in a batch may be concurrently made available for bidding during the preliminary bid stage.
  • the preliminary bid stage may be configured to last for a predefined duration of time (e.g., until a predetermined closing time). Accordingly, bidders are able to consider and bid on any of the one or more vehicles in the batch within the predefined duration of time. Typically, the duration of the preliminary bid stage is measured in days or weeks. Such durations provide ample time for bidders to consider and place preliminary bids on many different vehicles. Of course, any suitable duration of time may be used. The duration of time and/or scheduled close time of the preliminary bid stage may be determined and defined by an operator of valuation subsystem 110.
  • bid module 150 is configured to present, over data communication network 120, a list of the vehicles in a batch along with one or more mechanisms (e.g., hyperlinks) by which bidders can select specific vehicles for additional information and/or bidding.
  • a list of the vehicles in a batch may be presented in a particular user interface (e.g., a graphical user interface ("GUI")), and when a vehicle is selected, another user interface having additional information associated with the selected vehicle and/or with bidding may be presented.
  • GUI graphical user interface
  • Figure 3 illustrates an exemplary preliminary bid interface 300 that preliminary bid component 210 may present to a bidder during the preliminary bid stage.
  • Preliminary bid component 210 may be configured to present preliminary bid interface 300 in response to a bidder selecting to view additional information about a particular vehicle included in a batch of vehicles.
  • preliminary bid interface 300 may include information associated with a particular vehicle, including any or all information included in vehicle data 185.
  • preliminary bid interface 300 may include visual images of the vehicle 310, a written description of the vehicle 320, a bid entry window 330, and a submit bid icon 340.
  • Bid entry window 330 and submit bid icon 340 can be used by bidders to enter and submit preliminary bids.
  • preliminary bid interface 300 may include bid entry icons (such as bid matrix 450 described below in reference to Figure 4) for quick entry of specific bid amounts.
  • preliminary bid interface 300 may include a lot number, an indication of the scheduled begin time of the virtual bid stage (described further below) in which the vehicle will be included, a pick-up location identifier (e.g., the name of a vehicle yard near to the policyholder associated with a vehicle), a pre-damage vehicle value (shown as actual cash value ("ACV")), a repair cost, title information (e.g., salvage or clean title), loss type (e.g., property or collision damage), mileage, damage type description or code, and current high bid amount.
  • the current bid shown in Figure 3 represents the current high preliminary bid.
  • Preliminary bid interface 300 may also include any other potentially useful information.
  • preliminary bid interface 300 may include notices, instructions, or disclaimers associated with vehicle bidding, including instructions for placing bids (e.g., instructions associated with proxy bids, which are described below) and/or notices that the vehicle is not yet in a vehicle yard and/or that bids are subject to approval (e.g., sales are conditioned on the approval of the policyholder or insurance company associated with the vehicle).
  • bids e.g., instructions associated with proxy bids, which are described below
  • the information presented to bidders may encourage placement of high bids because bidders can ascertain the condition of vehicles and confidently submit educated bids.
  • visual images 310 are valuable for conveying the condition of vehicles while avoiding or minimizing travel and transportation costs.
  • Preliminary bid component 210 may be configured to support proxy bidding, which allows any bidder, referred to hereinafter as the first bidder, to enter a maximum bid value (i.e., a proxy bid) for a vehicle.
  • This maximum bid value may represent the maximum amount the first bidder is willing at that time to pay for the vehicle in question and may be significantly more than the current high bid for that vehicle.
  • Preliminary bid component 210 can then automatically place increasingly higher bids in pre-determined increments on behalf of the first bidder in response to bids placed by other bidders that outbid the first bidder. This may continue up to the maximum bid value authorized by the first bidder.
  • a bidder may submit a proxy bid in any suitable manner.
  • preliminary bid component 210 may provide a mechanism by which a bidder can identify a bid as being a proxy bid.
  • preliminary bid component 210 may be configured to automatically treat a bid amount in excess of a predefined bid increment as a proxy bid. To illustrate, if the current high bid for a vehicle is $500 by a first bidder, and the minimum bid increment is $50, a subsequent bid greater than $550 submitted by another bidder can be treated as a proxy bid if it is at least $100 more than the current high bid. If a second bidder provides a bid of $1000, preliminary bid component 210 may be configured to set the current high bid for the vehicle to $550 on behalf of the second bidder.
  • preliminary bid component 210 may be configured to automatically increase the bid of the second bidder to $650. This may continue until the second bidder remains the high bidder, or until the maximum bid submitted by the second bidder (i.e., $1000) is reached. The second bidder can still submit subsequent bids if desired. Thus, preliminary bid component 210 can incrementally and automatically increase the current bid for a vehicle on behalf of a bidder up to the maximum bid value specified by the bidder.
  • one or more user interfaces associated with the preliminary bid stage may include an indication of the predetermined time at which preliminary bid component 210 is scheduled to close the preliminary bid stage.
  • a countdown timer indicating the amount of time remaining until the scheduled close of the preliminary bid stage may also be presented.
  • the preliminary bid stage may be helpful to bidders trying to identify specific vehicles in which they are interested. Bidders may also use the preliminary bid stage to analyze, from bids received for vehicles, the level of interest in those vehicles and can then better estimate how high a bid the vehicle will eventually fetch in the virtual bid stage. In certain cases, bidders may be able to eliminate vehicles from consideration without having to spend time going to a live auction or participating in a corresponding virtual bid stage. Accordingly, the preliminary bid stage can be a valuable time-saving tool for many bidders.
  • the preliminary bid stage can also attract numerous potential bidders and thereby increase the level of interest in vehicles.
  • the amounts bid for vehicles will increase with an increase in the number of bids received.
  • the preliminary bid stage may serve to increase participation in the virtual bid stage, which can further help to increase bid amounts.
  • preliminary bid component 210 is configured to close the preliminary bid stage at the predetermined time set to mark the end of the preliminary bid stage. Once the preliminary bid stage is closed, preliminary bid component 210 no longer receives preliminary bids. However, preliminary bids are only preliminary, and winning bids and bidders are not determined until completion of a second bid stage referred to as a virtual bid stage, which may be provided by virtual bid component 220. In other words, regardless of what happens in the preliminary bid stage, bidding will proceed to the virtual bid stage, in which a winning bid will be determined. A winning bid can be a bid received during the virtual bid stage, the high preliminary bid received during the preliminary bid stage if no virtual bids are subsequently received, or a proxy bid carried over from the preliminary stage that is not surpassed during the virtual bid stage.
  • Virtual bid component 220 may be configured to open the second bid stage at a predefined time or in a predefined time interval after closure of the first bid stage.
  • the predefined time or time interval may be defined by an operator of valuation subsystem 110.
  • virtual bid component 220 is configured to open the virtual bid stage approximately one hour after closing of the preliminary bid stage.
  • any suitable time interval may be used between the first and second bid stages.
  • Bid module 150 may be configured to notify bidders of the start of a particular virtual bid stage. Notification may be provided at the start or in advance of the virtual bid stage. Bidders may request notification for specific virtual bid stages. For example, a bidder may submit a request over data communication network 120 to be notified of the initiation of a virtual bid stage in which a particular vehicle will be placed up for bid.
  • Bid module 150 may notify bidders in any suitable manner, including providing messages over data communication network 120.
  • a message is posted at a site (e.g., a website) configured to host a virtual bid stage or a preliminary bid stage associated with the virtual bid stage.
  • site e.g., a website
  • Other forms of notification may be used, including, but not limited to, e-mail messages, text messaging, instant messaging, voicemail messages, audible messages, recorded voice calls, pager messages, and any other suitable communication technology.
  • virtual bid component 210 may present one or more vehicles for consideration by one or more bidders.
  • Vehicles in a batch may be presented consecutively such that within a particular batch of vehicles bidding is open for one vehicle at a time.
  • bidders may submit virtual bids for the vehicle dynamically and in real time.
  • vehicles in a batch may be offered up for bid consecutively during the virtual bid stage with each of the vehicles remaining up for bid until a high bid has been determined for the vehicle.
  • the high bid may be determined when no subsequent higher bids are received within a predetermined time interval.
  • the highest bid for a vehicle may be used to set a salvage value of the vehicle.
  • the virtual bid stage may be configured to emulate certain aspects of a traditional live auction but in a virtual environment accessible over data communication network 120.
  • virtual bid component 220 may be configured to provide a virtual, real-time bidding environment that is designed to instill in bidders the same or similar feelings and reactions brought on by attending a traditional live auction. Consequently, the virtual bid stage may encourage bidders to bid and to continue bidding, even when bidders are located at different and remote geographic locations.
  • the virtual bid stage helps maximize the amounts of winning bids received for vehicles. Accordingly, system 100 can determine salvage values that are reflective of actual and fair market values. Insurance companies are able to use the salvage values having confidence that the values accurately reflect fair market values because the values were determined in an acceptable and documented manner and represent actual bids that bidders may be required to pay for the vehicle in question.
  • Starting bids in the virtual bid stage may be set based on preliminary bids received during the preliminary bid stage.
  • starting bids in the virtual bid stage are set equal to, or approximately equal to, the high preliminary bids received during the preliminary bid stage for corresponding vehicles.
  • a high bid in the preliminary bid stage may be carried over and used as the starting bid in the virtual bid stage.
  • starting bids in the virtual bid stage may be set to a predefined percentage or amount above or below the high preliminary bids received during the preliminary bid stage. For example, a starting bid in the virtual bid stage may be set to a value approximately ten percent (10%) above the high bid received during the preliminary bid stage for a particular vehicle.
  • virtual bid component 220 By setting starting bids based on preliminary bids received in the preliminary bid stage, virtual bid component 220 provides an efficient virtual bid process. For example, the time to determine a high bid in the virtual bid stage may be significantly reduced as compared to the time this would take in a traditional live auction because at least a portion of bidding has already taken place during the preliminary bid stage. Accordingly, virtual bid component 220 is able to efficiently determine the highest bid for a vehicle.
  • a default bid may be used as the starting bid in the virtual bid stage.
  • the default bid can be placed any time prior to the start of virtual bidding. In certain embodiments, for example, a default bid is placed approximately one day before the virtual bid stage is scheduled to begin. When the default bid is placed, it will become the starting bid in the virtual bid stage as long as no other preliminary bid is received after placement of the default bid. However, if a preliminary bid is received after placement of the default bid, the last preliminary bid received during the preliminary bid stage will be used as the starting bid.
  • the default bid may be placed on behalf of a particular party such as a junk buyer. Junk buyers may bid for the right to have their bids be used as default bids for vehicles not receiving any preliminary bids during the preliminary bid stage.
  • Virtual bid component 220 may be configured to provide one or more virtual bid interfaces to access devices 104 for consideration by bidders.
  • the user interfaces may include information associated the virtual bid process including vehicle information and real-time bid information.
  • Figure 4 illustrates an exemplary virtual bid interface 400 that virtual bid component 220 may present to a bidder during the virtual bid stage.
  • Virtual bid component 220 may be configured to present virtual bid interface 400 in response to a bidder selecting to participate in virtual bidding associated with a batch of one or more vehicles.
  • a bidder may select multiple virtual bid batches, and multiple virtual bid interfaces may be presented to the bidder simultaneously. For example, multiple virtual bid interfaces in the form of multiple graphic user interfaces may be displayed simultaneously at a particular access device 104, giving a bidder the ability to concurrently monitor multiple virtual bid batches.
  • virtual bid interface 400 may include information associated with a particular vehicle currently up for bid.
  • virtual bid interface 400 as shown in Figure 4 includes visual images 410 of the vehicle, a location identifier associated with a vehicle yard 415 (e.g., a yard at which a buyer can pick up the vehicle), an item number, a lot number, and a written description of the vehicle 420.
  • the written description 420 includes the vehicle make, model, year, color, vehicle identification number ("VIN”), and mileage, as well as a pre-damage value of the vehicle (denoted as "ACV” for actual cash value), repair cost, title information (e.g., certificate of destruction or salvage certificate), loss type (e.g., collision), and damage description (e.g., all over, front end, rear end, etc.).
  • VIN vehicle identification number
  • ACV a pre-damage value of the vehicle
  • repair cost e.g., certificate of destruction or salvage certificate
  • loss type e.g., collision
  • damage description e.g., all over, front end, rear end, etc.
  • virtual bid interface 400 may include other information associated with the vehicle (e.g., video footage of the vehicle), including any information potentially helpful for encouraging and/or helping bidders to submit bids for the vehicle.
  • Virtual bid interface 400 may also include information related to performance of virtual bid processes.
  • virtual bid interface 400 includes a bid section 430 having bid information therein.
  • Bid information can include any information descriptive of performance of virtual bid processes and events.
  • bid section 430 may include a bid log 440 configured to depict virtual bid events.
  • the bid log 440 may include text, audio, visual images, or any combination of messages and message types that are potentially useful for indicating bid events. The messages may be presented in real time and may help to inform and motivate bidders.
  • Virtual bid component 220 is configured to control the messages presented by bid log 440. Accordingly, virtual bid component 220 can function as a virtual, electronic auctioneer by providing, over data communication network 120, electronic messages descriptive of virtual bidding events. With respect to the text messages provided in the bid log 440 of Figure 4, the bid log 440 may begin virtual bidding for a vehicle by displaying a starting bid amount (e.g., $1,050 in Figure 4) and an indication that this amount is the starting bid. Upon posting of the starting bid, virtual bid component 220 then initiates a countdown. If a bid greater than the starting bid is not received within a predetermined time interval, the vehicle will be sold (subject to approval) to the bidder who submitted the starting bid.
  • a starting bid amount e.g., $1,050 in Figure 4
  • the new bid (e.g., $1,150 in Figure 4) is displayed as the current high bid, and the countdown timer is reset. Similar to a traditional live auction, the countdown timer gives bidders a time limit after each bid within which to submit a higher bid. As shown in Figure 4, this countdown may be visually and/or audibly displayed (e.g. Going, Five, Four, Three, Two, One, Sold) so that bidders are encouraged to enter additional bids before the countdown has elapsed.
  • virtual bid component 220 may also present additional information.
  • a general location identifier such as a city, state, province, or country may be displayed along with accepted bids. Other embodiments may omit this information or present different types of information. Display of a general location identifier together with each accepted bid may help bidders factor shipping costs into bidding strategies. For example, a bidder located in Florida who is bidding on a vehicle also located in Florida will be able to ascertain an apparent advantage over a bidder located in California who may have to pay higher fees to have the vehicle transported to California. Display of a location identifier together with each accepted bid may also inform bidders of the magnitude and mass appeal of system 100. Significantly, bidders from anywhere in the world can be brought together by the system 100 to bid for vehicles or other items being valued or sold.
  • Virtual bid component 220 may be configured to present a countdown sequence in bid log 440.
  • the countdown sequence may be designed to correspond with and illustrate progress of the countdown timer.
  • the countdown sequence may be any stream of messages configured to inform a bidder of the progress of the countdown timer. Accordingly, the countdown sequence can alert a bidder that a bid should be submitted quickly in order not to lose an item.
  • a countdown sequence is configured to include a sequentially timed display of the phrases "going...,” followed by “five...,” followed by “four...,” followed by “three...,” followed by “two...,” followed by “one...,” followed by “sold,” where the term “sold” indicates expiration of a predetermined time interval and that an item has been sold (subject to approval) to the highest bidder.
  • Subject to approval typically means subject to the decision of the insured vehicle owner to relinquish rather than retain the vehicle.
  • the presentation of the phrases listed above, or other suitable messages may be timed so as to encourage maximum bids.
  • the amount of time between the presentation of the phrases "one" and "sold” is greater than the amount of time between the presentation of the other phrases. This provides an extra measure of time to receive bids. The extra measure of time allows virtual bid component 220 to accept bids from hesitant bidders who may pause before finally submitting "last second" bids.
  • the countdown sequence may include audio and/or other types of messages.
  • the countdown sequence includes audio playback of the phrase "going once..., going twice..., ... sold," with each word being presented a predetermined time after the previous word.
  • Audio messages may be designed to help create a virtual bidding environment that emulates aspects of a live auction. This is especially useful to bidders who use a voice interface to participate in the bidding process. Regardless of the form(s) in which the countdown sequence is presented, the presentation should serve to encourage bidders to submit bids over data communication network 120.
  • an item may be deemed to be sold when no subsequent virtual bids are received within a predetermined time interval after the current bid was accepted (e.g., before the end of a countdown period).
  • a valid bid received at any time within the predetermined time interval will reset both the countdown timer and the countdown sequence.
  • a valid bid may comprise any bid greater than the current bid or any bid greater than the current bid by at least a predetermined increment.
  • the countdown timer and sequence may be repeatedly reset as long as bids are received within the countdown time interval. Accordingly, as long as bidders continue to submit bids within the predetermined time intervals, the virtual bid stage remains open and continues to solicit virtual bids. Thus, the virtual bid stage may continue for an indefinite time period, subject to the continual receipt of additional high bids.
  • the amount of time allotted between bids may remain constant throughout a virtual bid process or may change dynamically based on the virtual bids received. For example, the time interval may be reduced as bidding advances.
  • virtual bid component 220 may be configured to reduce the time interval allotted between virtual bids once a predetermined number of virtual bids have been received. Further time interval reductions may be executed at different predetermined stages (e.g., when other thresholds of predetermined numbers of virtual bids have been reached).
  • virtual bid component 220 may encourage bidders to submit higher bids early in the virtual bid process and/or to submit proxy bids to invoke and leverage time interval reductions. In certain cases, this may help shorten the overall time to determine the highest bid for a vehicle. It is desirable to minimize the time required to reach the ultimate high bid for each vehicle so that the process is as efficient for both buyers and sellers as possible.
  • submission of proxy bids may be supported in the virtual bid stage.
  • virtual bid component 220 may be configured to automatically place proxy bids on behalf of bidders during the virtual bid stage.
  • Virtual bid component 220 may be configured to receive proxy bids submitted during the virtual bid stage. For example, virtual bid component 220 may treat submitted bids greater than a predetermined bid increment as proxy bids. In exemplary embodiments, however, virtual bid component 220 may be configured to treat bids submitted during the virtual bid stage as normal bids without invoking proxy bidding features.
  • proxy bids are carried forward from the preliminary bid stage to the virtual bid stage.
  • any unused proxy bid authority remaining from the preliminary bid stage e.g., proxy bid authority associated with the highest bidder
  • proxy bids in both stages may help reduce bidding time and thereby increase overall returns.
  • bid section 430 may include a bid matrix 450 comprising one or more selectable mechanisms (e.g., icons or buttons) that provide bidders with readily selectable options for submitting bids.
  • a bid amount may be associated with each mechanism.
  • Virtual bid component 220 may be configured to recognize a bidder selection of any one of the mechanisms and respond by posting a bid equal to the bid amount associated with the selected mechanism. Consequently, bidders are able to quickly place bids in any of the amounts associated with the icons, without having to take the time to manually enter (e.g., type) bid amounts.
  • bid matrix 450 can reduce errors associated with entering bids and increase the ease, convenience, and speed of the virtual bid process.
  • the bid amounts in bid matrix 450 may be determined and set by virtual bid component 220 based on preliminary bidding, a starting bid in the virtual bid stage, or the current virtual bid amount.
  • the bid amounts in bid matrix 450 are a function of the starting virtual bid.
  • the bid amounts in bid matrix 450 are a function of the current virtual bid amount.
  • the bid amounts may be dynamically updated when a new current bid is accepted.
  • the differences between the bid amounts associated with the mechanisms may also be a function of a preliminary bid, a starting bid in the virtual bid stage, or the current virtual bid amount.
  • Bid matrices may be dynamically generated or predefined. A particular one of the predefined bid matrices may be selected and presented based on the current high virtual bid. Accordingly, virtual bid component 220 may maintain a library of bid matrices from which a particular bid matrix (e.g., bid matrix 450) may be retrieved and presented for consideration by a bidder.
  • a particular bid matrix e.g., bid matrix 450
  • bid log 440 may display a complete and dynamic history including an eventual display of the winning bid together with a location identifier associated with the winning bidder.
  • the winning bid i.e., the highest bid
  • the winning bid may be used by valuation subsystem 110 to determine and set a vehicle salvage value, as described below.
  • virtual bid component 220 moves to the next vehicle in the batch, if one exists, and repeats the above-described virtual bid process. In this manner, the virtual bid stage determines high bids for vehicles in a batch in a consecutive, dynamic, and real-time manner until a high bid is determined for each of the vehicles, and the virtual bid stage associated with the batch is closed.
  • the sales of vehicles to the highest bidders are subject to the approval of insurance adjusters.
  • an insurance adjuster is notified of the high bid received for a vehicle.
  • the insurance adjuster informs a policyholder of the value of the vehicle as determined by the high bid received for the vehicle.
  • the insurance adjuster gives the policyholder an option either to retain the vehicle and receive a payment for the pre-damage vehicle value less the high bid received for the damaged vehicle or to relinquish the vehicle and receive a payment for the pre-damage vehicle value.
  • the insurance adjuster may then accept or reject the high bid for the vehicle based on the decision of the policyholder to either retain or relinquish the vehicle.
  • bid module 150 may notify bidders that all sales are "on approval.” In certain embodiments, bid module 150 may be configured to notify bidders that when insurance adjusters refuse to accept high bids, the high bidders will earn a reward for being the highest bidders, as described below.
  • sales of vehicles to the highest bidders may be made subject to the approval of insurance agents or other individuals with authority to authorize the sale.
  • insurance agents may use determined vehicle values, including salvage values set by valuation module 170, to determine dispositions of vehicles.
  • insurance agents may use vehicle values determined by the bidding process being described here to decide whether to repair of total particular vehicles.
  • the sale of the vehicle to the highest bidder will be canceled.
  • the sale of the vehicle may still be subject to the approval of the corresponding policyholder who may elect to retain the vehicle.
  • Bid module 150 may be configured to generate bid record 188, which may be stored to data store 140.
  • Bid record 188 may include any data representative of one or more bid processes and events performed by bid module 150.
  • bid record 188 may include, but is not limited to, data representative of bids received for vehicles, high bids for vehicles, messages presented to bidders (e.g., countdown sequences), vehicle information, bidder information, timestamps, and information associated with access devices 104 that participate in bid processes (e.g., IP addresses).
  • Bid record 188 may include server logs and/or any other suitable data representative of interactions between bid module 150 and access devices 104.
  • Bid record 188 may be used as evidence of bids received for vehicles and the processes used to solicit and receive the bids. Accordingly, insurance companies can rely on bid record 188 to show compliance with governmental regulations or that fair processes were used to determine vehicle values. In certain embodiments, bid record 188 can be used to show that a bid at least approximately equal to a determined vehicle salvage value was received from a qualified and legitimate bidder. Thus, bid record 188 can be used to protect insurance companies from potential accusations related to the setting of vehicle values. Bid record 188 can also serve to protect policyholders by ensuring that a determination of vehicle value is based on a fair bid process that receives legitimate bids from qualified and interested bidders.
  • Bid module 150 may be configured to generate bid results 185, which may include data representative of bid processes preformed by bid module 105 and/or the outcomes of the bid processes.
  • bid results 190 include one or more high bids received for one or more vehicles (e.g., a batch of vehicles).
  • bid results 190 may include data representative of all bids received for one or more vehicles.
  • bid results 190 may be used by valuation module 170 to determine and set vehicle values based on the bid results 190.
  • bid module 150 may be configured to perform alternative bid processes, including any bid process suitable for soliciting and receiving bids for vehicles over data communication network 120.
  • alternative bid processes including any bid process suitable for soliciting and receiving bids for vehicles over data communication network 120.
  • either of the bid stages described above may be performed independently of the other bid stage.
  • the virtual bid stage may be performed and the preliminary bid stage omitted.
  • starting virtual bids may be set to predefined default amounts, as described above.
  • valuation module 170 may receive bid results 190, or at least a subset of bid results 190, from bid module 150. Valuation module 170 may be configured to set values for vehicles based on data included in bid results 190. In particular, valuation module 170 may set a salvage value for a vehicle based on one or more bids received for the vehicle, as represented in the bid results 190.
  • Valuation module 170 may be configured with predefined instructions (e.g., software) useful for setting a vehicle value based on the bid results 190.
  • the predefined instructions may be programmable to allow for modifications such that valuation module 170 may be tailored to particular implementations of system 100.
  • valuation module 170 is configured to set a salvage value at least approximately equal to the value of the highest bid received for the corresponding vehicle.
  • Other embodiments may set a vehicle value according to different predefined instructions.
  • valuation module 170 may be configured to set a vehicle value to a computed average of bids received for the corresponding vehicle or to a value that is a predetermined percentage or increment greater than or less than the highest bid received.
  • Valuation module 170 may be configured to use any other suitable logic for setting vehicle values based on bid results 190. By basing vehicle values on actual bids received for the vehicles, valuation module 170 sets vehicle values based on the fair market values of the vehicles.
  • valuation module 170 may provide the value to notification module 180.
  • Notification module 180 may be configured to provide vehicle values received from valuation module 170 to one more access devices 104 over data communication network 120.
  • notification module 180 may provide a vehicle value to one or more particular access devices 104, including a particular access device associated with a particular user who provided data representative of the vehicle corresponding with the vehicle value.
  • this user is an agent of an insurance company (e.g., an insurance adjuster) who is able to use the vehicle value to choose whether to repair or "total" the vehicle and/or to notify a policyholder of available options, including actual amounts that the insurance company will offer to pay the policyholder.
  • an insurance company e.g., an insurance adjuster
  • the insurance adjuster may notify the policyholder of the pre-damage cash value that will be paid to the policyholder should he or she choose to relinquish the vehicle, as well as the amount that will be paid to the policyholder should he or she choose to retain the vehicle (i.e., the pre-damage cash value less the salvage value set by valuation module 170).
  • the policyholder is then able to make an educated decision taking into account a fair market salvage value of the vehicle.
  • notification module 180 may be configured to provide a vehicle value to a particular access device 104 associated with a particular policyholder. For example, when an insurance adjuster submits vehicle data 185 for a vehicle, the insurance adjuster may also provide contact information for the policyholder associated with the vehicle. Notification module 180 may use the contact information to provide information (e.g., a determined salvage value) to the policyholder through data communication network 120. By directly notifying the policyholder, both the workload of an insurance adjuster and the time to receive a response (i.e., a decision) from the policyholder may be reduced.
  • information e.g., a determined salvage value
  • Notification module 180 may employ any suitable technologies to provide notifications and other information to users of access devices 104 through data communication network 120.
  • notification module 180 may communicate with one or more access devices 104 over data communication network 120 using one or more HTML messages (e.g., web pages), e-mail messages, instant messaging services, text messaging services, paging services, automated telephone messages, and any other suitable communication technologies.
  • HTML messages e.g., web pages
  • notification module 180 is configured to post notifications to one or more web pages accessible by a particular insurance adjuster.
  • notification module 180 may be configured to send an e-mail message including a vehicle value to a particular insurance adjuster.
  • Notification module 180 may also be configured to receive data representative of policyholder decisions over data communication network 120.
  • the decisions may be received directly from policyholders or indirectly from other parties such as insurance adjusters.
  • an insurance adjuster may communicate with and receive a decision from a particular policyholder using the data communication network 120.
  • the insurance adjuster may then use any particular access device 104 to provide data representative of the decision of the policyholder to notification module 180 over data communication network 120.
  • the insurance adjuster may use an HTML template to upload the data to notification module 180.
  • Notification module 180 may be configured to generate a default decision if a sale approval, i.e., a policyholder decision, is not received within a predetermined timeout interval.
  • notification module 180 is configured to reject a sale if a policyholder decision is not received within approximately seventy-two hours after notification of the salvage value has been sent.
  • a predetermined timeout default decision can benefit bidders by limiting the amount of time that they are kept waiting for policyholder decisions.
  • notification module 180 may notify the highest bidder of the decision.
  • notification module 180 may notify the highest bidder as to whether the policyholder has decided to relinquish or retain the corresponding vehicle. Accordingly, the highest bidder can learn whether the sale of the vehicle has been approved or rejected.
  • a notification to the highest bidder may include additional information such as information concerning steps for completing an approved transaction (e.g., transaction details and logistics) or information associated with a rejected transaction (information associated with highest bidder rewards).
  • Notification module 180 may be configured to use any of the communication technologies described above to provide notifications over data communication network 120 to access devices 104 associated with bidders.
  • Valuation subsystem 110 may take different actions based on the decision of a policyholder. For example, when a policyholder chooses to relinquish a vehicle, valuation subsystem 110 may be configured to perform operations designed to help complete the sale of the vehicle to the highest bidder. On the other hand, when a policyholder chooses to retain the vehicle, valuation subsystem 110 may perform operations designed to reward the highest bidder for placing the highest bid on the vehicle.
  • valuation subsystem 110 may take different actions based on the decision of a policyholder. For example, when a policyholder chooses to relinquish a vehicle, valuation subsystem 110 may be configured to perform operations designed to help complete the sale of the vehicle to the highest bidder. On the other hand, when a policyholder chooses to retain the vehicle, valuation subsystem 110 may perform operations designed to reward the highest bidder for placing the highest bid on the vehicle.
  • notification module 180 can alert transaction module 182 of the decision.
  • Transaction module 182 may then perform operations designed to help complete the sale of the vehicle to the highest bidder.
  • transaction module 182 may be configured to accept payment from the highest bidder or an agent of the highest bidder.
  • transaction module 182 may be configured to receive and process credit card information, or to process any acceptable payment method.
  • Transaction module 182 may be configured to perform functions helpful for processing vehicles titles. The processing of vehicle titles to complete a sale of vehicles will be understood by those skilled in the art. In certain embodiments, if title is not transferred within a predetermined time interval after approval of a sale, the highest bidder is given an opportunity to either continue with the transaction or cancel the sale. The highest bidder may also be given an opportunity to cancel a sale under other circumstances, including when items have been removed or replaced on a vehicle or when the vehicle has incurred additional damage since the winning bid was submitted.
  • Transaction module 182 may be further configured to perform functions associated with transportation and/or pickup of vehicles, including, for example, identifying transportation and/or pickup options based on the location of the vehicle and the location of the highest bidder. Transaction module 182 may provide the options to notification module 180, which may notify the highest bidder of the options, thereby allowing the highest bidder to select one of the options for transport or pick-up of the vehicle.
  • reward module 184 may be configured to assign a predefined reward to the highest bidder. Notification module 180 can alert reward module 184 of the decision of the policyholder to retain the vehicle. Reward module 184 can then assign the predefined reward to the highest bidder, and notification module 180 can notify the highest bidder that the reward has been given or credited to that bidder.
  • the predefined reward may be designed to motivate bidders to bid on vehicles.
  • bid module 150 may be configured to notify bidders that the highest bid, if rejected by a policyholder, will earn the high bidder a predefined reward. Accordingly, bidders may be more likely to vie to become the highest bidder because of the potential of receiving a reward simply for being the highest bidder. This may result in increased bid quantities and values.
  • Rewards may be provided to bidders in any suitable manner, including providing monetary payment, credit, gift cards, or any known form of reward.
  • Figure 5 illustrates an exemplary process for determining salvage value for a vehicle. While Figure 5 illustrates exemplary steps according to one embodiment, other embodiments may omit, add to, reorder and/or modify any of the steps shown in Figure 5.
  • step 510 vehicle data (e.g., vehicle data 185) is received.
  • Step 510 may be performed in any of the ways described above, including an agent of an insurance company using an access device (e.g., access device 104-1) to provide vehicle data to valuation subsystem 110 over a data communication network (e.g., data communication network 120).
  • an access device e.g., access device 104-1
  • a data communication network e.g., data communication network 120.
  • step 520 bids for a vehicle are solicited over a data communication network (e.g., data communication network 120).
  • Step 520 may be performed in any of the ways described above, including posting at least a subset of vehicle data (e.g., vehicle data 185) such that the data is accessible to one or more access devices (e.g., access devices 104) over a data communication network. Accordingly, bidders are able to use the access devices to consider posted vehicle data and to submit bids on the corresponding vehicle.
  • step 530 at least one bid for the vehicle is received.
  • Step 530 may be performed in any of the ways described above.
  • one or more bids for the vehicle are submitted by bidders and received over a data communication network (e.g., data communication network 120). If no bids are received over the data communication network for the vehicle, valuation subsystem 110 may place a predetermined default bid on behalf of another party (e.g., a junk buyer), as described above.
  • performance of step 530 includes using a two-stage bid process such as the two-stage bid process described above.
  • Other embodiments may use alternative bid processes to receive bids over data communication network 120.
  • a salvage value is set for the vehicle based on at least one received bid.
  • Step 540 may be performed in any of the ways described above, including setting a salvage value equal to, or at least approximately equal to, the high bid received for the vehicle.
  • a disposition of the vehicle is determined based on the salvage value of the vehicle as determined in step 540.
  • the determination may be based on a decision of an insurance agent regarding whether to repair or total a vehicle.
  • the disposition of the vehicle may be based on a decision of a policyholder to retain or relinquish the vehicle.
  • Step 550 may be performed in accordance with the exemplary process illustrated in Figure 6, which shows a process for determining a disposition of a vehicle based on vehicle salvage value. While Figure 6 illustrates exemplary steps according to one embodiment, other embodiments may omit, reorder, add to, and/or modify any of the steps shown in Figure 6.
  • step 610 it is determined whether the policyholder associated with the vehicle wants to retain the vehicle.
  • Step 610 may be performed in any of the ways described above, including notifying an insurance agent and/or policyholder of the salvage value and receiving data representative of a policyholder decision as to whether the policyholder wishes to retain or relinquish the vehicle.
  • a default decision may be entered automatically if a policyholder decision is not received within a predetermined timeout interval, as described above. The disposition of the vehicle may then be determined based on either the policyholder decision or the default decision.
  • Step 620 at which step the sale of the vehicle to the high bidder is approved.
  • Step 620 may be performed in any of the ways described above, including notifying the high bidder that the sale is approved and performing steps helpful for completing the transaction. For example, payment and delivery or pickup of the vehicle can be arranged.
  • the insurance company may be paid the high bid amount, or a portion of the high bid amount, for the vehicle.
  • step 630 the policyholder relinquishes the vehicle and receives the pre-damage value of the vehicle from the insurance company.
  • Step 640 at which step the sale of the vehicle to the high bidder is rejected.
  • Step 640 may be performed in any of the ways described above, including notifying the high bidder that the sale is rejected.
  • Step 650 the high bidder is rewarded.
  • Step 650 may be performed in any of the ways described above, including assigning a predetermined reward to the high bidder.
  • step 660 the policyholder retains the vehicle and receives the pre-damage value less the salvage value of the vehicle from the insurance company.
  • the insurance company typically benefits from the salvage value being determined based on one or more bids received over a data communication network because such a bid process generally helps to increase and document the quantity and value of bids for a vehicle. This results in savings for the insurance company. The savings may be passed on to policyholders, as discussed above.
  • salvage values for items or services other than vehicles may be determined based on one or more bids received for the items or services over a data communication network.
  • types of values other than salvage values may be determined based on one or more bids received over a data communication network. The determined values can then be used to determine dispositions of the associated items or services. It is intended that the scope of the invention be defined by the following claims.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • Economics (AREA)
  • General Physics & Mathematics (AREA)
  • Development Economics (AREA)
  • Theoretical Computer Science (AREA)
  • Technology Law (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
EP06110128A 2005-02-25 2006-02-17 Systeme und Verfahren zur Bestimmung des Fahrzeugschrottwertes Withdrawn EP1696381A1 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US65685205P 2005-02-25 2005-02-25

Publications (1)

Publication Number Publication Date
EP1696381A1 true EP1696381A1 (de) 2006-08-30

Family

ID=36178105

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06110128A Withdrawn EP1696381A1 (de) 2005-02-25 2006-02-17 Systeme und Verfahren zur Bestimmung des Fahrzeugschrottwertes

Country Status (7)

Country Link
US (1) US20060195384A1 (de)
EP (1) EP1696381A1 (de)
JP (1) JP2006244492A (de)
CN (1) CN1828663A (de)
AU (1) AU2006200707A1 (de)
CA (1) CA2536988A1 (de)
MX (1) MXPA06002043A (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IT201900000106A1 (it) * 2019-01-07 2020-07-07 Gba S R L Sistema per la determinazione del valore effettivo di un veicolo
US10733579B2 (en) 2013-01-30 2020-08-04 Row52, Llc Systems and methods for self-service recycling of automotive parts

Families Citing this family (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AUPQ056099A0 (en) * 1999-05-25 1999-06-17 Silverbrook Research Pty Ltd A method and apparatus (pprint01)
EP1990364A4 (de) * 2006-02-06 2009-11-04 Zeon Corp Formkörper aus vernetzbarem harz, formkörper aus vernetztem harz und laminat aus vernetztem harz und metall
EP2027135A4 (de) * 2006-04-24 2011-03-09 Andrew Altschuler System und verfahren zum mehrmaligen verkaufen eines produktes während der haltbarkeitsdauer dieses produkts
US8392297B2 (en) * 2007-01-22 2013-03-05 Rebuilders Automotive Supply Automotive core fulfillment system and method
WO2008091882A1 (en) * 2007-01-22 2008-07-31 Rebuilders Automotive Supply Co., Inc. Automotive core fulfillment system and method
US20070226072A1 (en) * 2007-03-01 2007-09-27 Paul Gross System and method for managing the sale of salvage items in connection with the management of an insurance claim
US7986914B1 (en) * 2007-06-01 2011-07-26 At&T Mobility Ii Llc Vehicle-based message control using cellular IP
US8341051B2 (en) * 2007-07-10 2012-12-25 Property Liquidators Llc System and method of auctioning a defaulted loan
US20100138242A1 (en) * 2008-07-14 2010-06-03 Cross Country Automotive Services Electronic Vehicle Repair Management (eVRM)
US9881284B2 (en) 2008-10-02 2018-01-30 ecoATM, Inc. Mini-kiosk for recycling electronic devices
US8200533B2 (en) * 2008-10-02 2012-06-12 ecoATM, Inc. Apparatus and method for recycling mobile phones
CA2926097C (en) 2008-10-02 2020-11-10 ecoATM, Inc. Secondary market and vending system for devices
US10853873B2 (en) 2008-10-02 2020-12-01 Ecoatm, Llc Kiosks for evaluating and purchasing used electronic devices and related technology
US7881965B2 (en) 2008-10-02 2011-02-01 ecoATM, Inc. Secondary market and vending system for devices
US11010841B2 (en) 2008-10-02 2021-05-18 Ecoatm, Llc Kiosk for recycling electronic devices
CA3210819A1 (en) 2011-04-06 2012-10-11 Ecoatm, Llc Method and kiosk for recycling electronic devices
US20140095336A1 (en) * 2012-07-25 2014-04-03 Newell Recycling, Llc. System and method for providing vehicle valuation management
US20140081673A1 (en) * 2012-09-18 2014-03-20 Insurance Auto Auctions, Inc. Title document rules engine method and apparatus
US20140156272A1 (en) * 2012-11-29 2014-06-05 Insurance Auto Auctions, Inc. Voice entry vin method and apparatus
US20140214488A1 (en) * 2013-01-30 2014-07-31 Row52, Llc Systems and methods for self-service recycling of automotive parts
US8788301B1 (en) * 2013-03-13 2014-07-22 Allstate Insurance Company Parts valuation and use
US9595019B1 (en) 2013-03-13 2017-03-14 Allstate Insurance Company Parts inventory management
US9858622B1 (en) 2013-03-15 2018-01-02 State Farm Mutual Automobile Insurance Company System and method for facilitating vehicle insurance services
US9508200B1 (en) 2013-03-15 2016-11-29 State Farm Mutual Automobile Insurance Company System and method for using a specialty vehicle data identifier to facilitate treatment of a vehicle damaged in a crash
US20140278572A1 (en) 2013-03-15 2014-09-18 State Farm Mutual Automobile Insurance Company System and method for routing a vehicle damaged in a crash
US9996885B1 (en) 2013-03-15 2018-06-12 State Farm Mutual Automobile Insurance Company System and method for facilitating vehicle insurance services
JP5954715B2 (ja) * 2013-04-24 2016-07-20 独立行政法人国立高等専門学校機構 栽培契約マッチングシステム、サーバ、方法およびプログラム
US9208526B1 (en) 2014-07-11 2015-12-08 State Farm Mutual Automobile Insurance Company Method and system for categorizing vehicle treatment facilities into treatment complexity levels
US10401411B2 (en) 2014-09-29 2019-09-03 Ecoatm, Llc Maintaining sets of cable components used for wired analysis, charging, or other interaction with portable electronic devices
EP4446968A2 (de) 2014-10-02 2024-10-16 ecoATM, LLC Drahtlos aktivierter kiosk zur wiederverwertung von verbrauchervorrichtungen
WO2016054435A1 (en) 2014-10-02 2016-04-07 ecoATM, Inc. Application for device evaluation and other processes associated with device recycling
US10445708B2 (en) 2014-10-03 2019-10-15 Ecoatm, Llc System for electrically testing mobile devices at a consumer-operated kiosk, and associated devices and methods
US10572946B2 (en) 2014-10-31 2020-02-25 Ecoatm, Llc Methods and systems for facilitating processes associated with insurance services and/or other services for electronic devices
US10417615B2 (en) 2014-10-31 2019-09-17 Ecoatm, Llc Systems and methods for recycling consumer electronic devices
CA3227945A1 (en) 2014-11-06 2016-05-12 Ecoatm, Llc Methods and systems for evaluating and recycling electronic devices
WO2016094789A1 (en) 2014-12-12 2016-06-16 ecoATM, Inc. Systems and methods for recycling consumer electronic devices
US10853882B1 (en) * 2016-02-26 2020-12-01 State Farm Mutual Automobile Insurance Company Method and system for analyzing liability after a vehicle crash using video taken from the scene of the crash
US10127647B2 (en) 2016-04-15 2018-11-13 Ecoatm, Llc Methods and systems for detecting cracks in electronic devices
US9885672B2 (en) 2016-06-08 2018-02-06 ecoATM, Inc. Methods and systems for detecting screen covers on electronic devices
US10269110B2 (en) 2016-06-28 2019-04-23 Ecoatm, Llc Methods and systems for detecting cracks in illuminated electronic device screens
US11037246B1 (en) 2017-04-05 2021-06-15 State Farm Mutual Automobile Insurance Company Systems and methods for total loss handling via blockchain
US11443381B2 (en) 2017-12-04 2022-09-13 Allstate Insurance Company Multicomputer processing of user data with centralized event control
CN109034899A (zh) * 2018-07-26 2018-12-18 北京京东尚科信息技术有限公司 估计物品残留价值的方法、装置及计算机可读存储介质
CN112912914A (zh) * 2018-09-06 2021-06-04 纳伊夫·阿尔胡米丹 竞价方法和系统
KR20210106493A (ko) 2018-12-19 2021-08-30 에코에이티엠, 엘엘씨 이동 전화기 및 다른 전자 디바이스의 판매 및/또는 구매를 위한 시스템 및 방법
EP3924918A1 (de) 2019-02-12 2021-12-22 ecoATM, LLC Kiosk zur bewertung und zum einkaufen von gebrauchten elektronischen geräten
KR20210125526A (ko) 2019-02-12 2021-10-18 에코에이티엠, 엘엘씨 전자 디바이스 키오스크를 위한 커넥터 캐리어
CN111738402A (zh) 2019-02-18 2020-10-02 埃科亚特姆公司 基于神经网络的电子设备物理状况评估及相关系统和方法
US20200387919A1 (en) * 2019-06-10 2020-12-10 International Business Machines Corporation Product evaluation based on dynamic metrics
US11922467B2 (en) 2020-08-17 2024-03-05 ecoATM, Inc. Evaluating an electronic device using optical character recognition
WO2022040668A1 (en) 2020-08-17 2022-02-24 Ecoatm, Llc Evaluating an electronic device using optical character recognition
CN115119018B (zh) * 2021-03-17 2023-12-01 腾讯科技（深圳）有限公司 视频处理方法、装置、计算机设备及存储介质
CN117928982B (zh) * 2024-03-21 2024-07-23 合肥松果智造智能科技有限公司 基于路况信息的共享车辆实验平台测试方法、运维方法和存储介质

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6415269B1 (en) * 1998-05-29 2002-07-02 Bidcatcher, L.P. Interactive remote auction bidding system
US6091998A (en) * 1998-09-30 2000-07-18 Rockwell Technologies, Llc Self organizing industrial control system using bidding process
US7818205B2 (en) * 2001-01-12 2010-10-19 Pickapin.Com Search engine providing an option to win the item sought
US20020161697A1 (en) * 2001-04-30 2002-10-31 Stephens Charles M. On-line procurement or RFP auction system
US20030158806A1 (en) * 2002-02-15 2003-08-21 Hanley James P. Automated ranked bid sales method and system
US8688528B2 (en) * 2004-12-30 2014-04-01 Ebay, Inc. Methods and systems to alert a user of a network-based marketplace event

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
No Search *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10733579B2 (en) 2013-01-30 2020-08-04 Row52, Llc Systems and methods for self-service recycling of automotive parts
US11461741B2 (en) 2013-01-30 2022-10-04 Row52, Llc Systems and methods for identifying automotive parts in a salvage yard
IT201900000106A1 (it) * 2019-01-07 2020-07-07 Gba S R L Sistema per la determinazione del valore effettivo di un veicolo

Also Published As

Publication number Publication date
US20060195384A1 (en) 2006-08-31
CN1828663A (zh) 2006-09-06
AU2006200707A1 (en) 2006-09-14
JP2006244492A (ja) 2006-09-14
CA2536988A1 (en) 2006-08-25
MXPA06002043A (es) 2006-09-29

Similar Documents

Publication Publication Date Title
EP1696381A1 (de) Systeme und Verfahren zur Bestimmung des Fahrzeugschrottwertes
US6868395B1 (en) Business transactions using the internet
US7908210B2 (en) Systems and method for managing dealer information
US20190050922A1 (en) Electronic bond and guaranty process and business method
US8140442B2 (en) Matching residential buyers and property owners to initiate a transaction for properties which are currently not listed for sale
US7958011B1 (en) Obtaining community association data in a direct, efficient manner
US8095422B2 (en) Systems and methods for vehicle information management
US20160307276A1 (en) System and method for insuring against unrecoverable litigation costs
US20030033241A1 (en) Methods and systems for automated loan origination, processing and approval
US20070282735A1 (en) Lien payoff systems and methods
US20070011083A1 (en) System and method of processing asset financing transactions
US20060015449A1 (en) Method for conducting a computerized auction
US20140129366A1 (en) Self-service real estate framework
US20080201259A1 (en) Method and Apparatus for Conveying the Right to Broker Real Property Transfers
US20100042508A1 (en) Method and Apparatus for Implementing a Peer to Peer Transaction System
JP7180904B2 (ja) オンラインオークションのための方法およびシステム
US20140258041A1 (en) System and methods for vehicle lifecycle management
US20210390600A1 (en) System and method for facilitating a consumer-driven marketplace for sellers
US20030055662A1 (en) System and method for auditing electronic auctions
US20070143201A1 (en) Systems and methods for selling vehicle repossession rights
US20090083080A1 (en) Method, apparatus and program product for facilitating transfer of group meeting contracts
US20080147532A1 (en) System and Methods for Transferring Tax Credits
EP4341886A1 (de) Verfahren und system für eine angebotsverwaltungsplattform zur ermöglichung von eigenschaftstransaktionen
CA2585585A1 (en) Systems and methods for managing dealer information
AU2013205621A1 (en) Method and system for selecting an agent

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK YU

17P Request for examination filed

Effective date: 20070228

AKX Designation fees paid

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

17Q First examination report despatched

Effective date: 20070424

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20090901