WO2000021010A1

WO2000021010A1 - Dispatch management system

Info

Publication number: WO2000021010A1
Application number: PCT/US1999/023176
Authority: WO
Inventors: Larry D. Bass
Original assignee: Dealers Transport, Ltd.
Priority date: 1998-10-05
Filing date: 1999-10-05
Publication date: 2000-04-13
Also published as: CA2345113A1; WO2000021010A9

Abstract

A dispatch management system maintains information on the status of vehicles. The system includes a host and at least one terminal coupled to the host for the entry of an order for the dispatch of a vehicle. A method for maintaining information on the status of vehicles includes providing a dispatch management system host and at least one terminal coupled to the host for the entry of an order for the dispatch of a vehicle.

Description

DISPATCH MANAGEMENT SYSTEM

Related Applications

This application is based upon U. S. Provisional Patent Application Serial Number 60/103,039 filed October 5, 1998. The filing date of U. S. S. N.

60/103,039 is hereby claimed. U. S. S. N. 60/103,039 is hereby incorporated herein by reference.

Field of the Invention The present invention relates generally to managing collection and delivery of vehicles, and particularly to collection of vehicles from multiple locations for disposition through a dispatching system.

Disclosure of the Invention In accordance with the present invention, a system and method of managing the collection and delivery of vehicles is provided that can include one or more of the following features: providing a dispatch management system using a computer and software for maintaining and updating information on the status of the vehicles identified for disposition through the system; providing for coupling terminals to the dispatch management system from remote locations, such as order entry terminals at remote customer locations coupled by a communication link such as the world wide web; recording time stamps for one or more transactions in the process, such as a time of initial identification of a vehicle for collection, a time at which a vehicle is ready for collection from a remote location, a time at which a dispatch request for a vehicle was made, a time of actual dispatch of a vehicle, at time of arrival of a vehicle at a destination location, etc.; providing one or more identifiers for a vehicle being processed through the system, such as a transaction number and/or a waybill number, etc; defining a dispatch status for a vehicle that is indicative of the status of the vehicle, such as "pending dispatch", "ready for dispatch", "dispatched", etc., as well as updating the dispatch status for a vehicle as it is processed through the system; defining one or more collection attributes of a vehicle indicative of whether the vehicle is ready for delivery from a remote location, such as "drivable", "tow", "body shop", "needs cleaning", "has keys", etc., as well as updating the collection attributes for a vehicle as appropriate; recording vehicle information for a vehicle being processed through the system, such as vehicle identification number, year, make, model, color, etc.; recording delivery information for a vehicle such as fuel, oil, source mileage, destination mileage, etc.; assigning one or more drivers for collection of one or more vehicles; confirming information from remote locations, such as fax confirmation that a vehicle is ready to be picked up from the remote location, and including verification information from previous transactions related to the vehicle; generating statistics based on collected information, e.g., average times and statistical variations that vehicles spend in a dispatch status such as pending dispatch, etc.; generating reports based on collected information, e.g., inventory reports for vehicles by location or regardless of location, reports based on individuals, vehicle attributes, locations, or status information, etc.; aggregating drivers for multiple deliveries from a remote location; automatically determining assignments of drivers based on driver information, such as familiarity with locations, dealerships, etc.; automatically generating documents such as waybills or bills of lading; using visual indicia to highlight status information based on a predetermined criterion, such as using red text for a pending dispatch status of a vehicle; generating alerts for status information based on a predetermined criterion, such as an alert for a vehicle that has a dispatch status value of pending dispatch for more than seventy-two hours; validating information required by the system, such as collection status, collection attributes, vehicle information, etc.; automatically time stamping information; automatically changing information based on a predetermined criterion, such as updating vehicle status from pending dispatch to ready for dispatch based on a change in a collection attribute; providing for searching for information based on a search criterion, e.g., on waybill number, date(s), remote locations, reference names, VINs, etc.; storing information identifying individuals that enter information; providing for security privileges for entering, changing, and accessing information within the system; generating a bar code that correlates to vehicle information, so that the bar code can be affixed, e.g., to a bill of lading and/or to a vehicle; scanning a bar code to obtain vehicle information; updating vehicle information based on scanning a bar code, e.g., automatically changing a vehicle status to delivered based on scanning a bar code when the vehicle arrives at a destination, or scanning a bar code and designating a change in vehicle status such as to ready for dispatch, etc.; and generating an invoice to a customer based on stored information, e.g., automatically invoicing within a twenty-four hour period.

According to one aspect of the invention, a dispatch management system maintains information on the status of vehicles. The system includes a host and at least one terminal coupled to the host for the entry of an order for the dispatch of a vehicle. According to another aspect of the invention, a method for maintaining information on the status of vehicles includes providing a dispatch management system host and at least one terminal coupled to the host for the entry of an order for the dispatch of a vehicle.

Illustratively, the at least one terminal includes at least one order entry terminal.

Further illustratively, the information includes a time stamp for indicating when a transaction is ordered by a customer. Additionally illustratively, the information includes the status of the order.

Illustratively, the information includes whether placement of the order by the customer is complete. Further illustratively, the information includes whether the vehicle can be driven.

Additionally illustratively, the information includes whether the vehicle must be towed.

Illustratively, the information includes whether a key for operating the vehicle is available.

Further illustratively, the apparatus and method include apparatus for, and the step of, generating machine-readable code and/or scanning machine-readable code for correlating vehicle information and/or updating vehicle information.

Additionally illustratively, the apparatus and method include apparatus for, and the step of, creating at least one of a waybill, a bill of lading, an invoice, and an identifier for the vehicle.

Illustratively, the at least one terminal is coupled to the host for the entry of an order by a customer.

Additionally illustratively, the information on the status of a vehicle includes at least one of: a transaction number; a waybill number; who authorized the order; who placed the order; the orderer's account number; the orderer's reference for the transaction; where the vehicle is located; where the vehicle is to be delivered; when the order was sent to dispatch; when a driver was dispatched to pick up the vehicle; the driver's identity; the vehicle's identity; information on the vehicle's fuel; information on the vehicle' s lubricant; vehicle odometer data at the point of origin; vehicle odometer data at the destination; when the vehicle was delivered to the destination; the identity of the recipient; and, the dispatch status of the vehicle.

Further illustratively, the vehicle's identity includes at least one of: a vehicle identification number; the year of the vehicle; the make of the vehicle; the model of the vehicle; and, the color of the vehicle.

Illustratively, the terminal for the entry of an order for the dispatch of the vehicle includes a terminal for updating the dispatch status of the vehicle. Additionally illustratively, the information on the status of the vehicle includes the assignment of a driver for collection of the vehicle.

Illustratively, the terminal for the entry of an order for the dispatch of the vehicle includes a terminal for at least one of generating order confirmation and transmitting order confirmation.

Further illustratively, at least one of the host and the terminal includes means for generating at least one of statistics and reports from information collected by the system.

Additionally illustratively, the host includes information from which a driver can be assigned.

Illustratively, the host includes a host for at least one of creating a visual indication based on a criterion and displaying a visual indication based on a criterion.

Further illustratively, the host includes a host for automatically changing information based on a criterion.

Additionally illustratively, the host includes a host for searching for information based on a criterion.

Illustratively, the host includes a host for identifying individuals who modify stored information. Further illustratively, the host includes a host for controlling access to the system for changing information stored in the system.

Brief Description of the Drawings

The invention may best be understood by referring to the following detailed description and accompanying drawings which illustrate the invention. In the drawings:

Fig. 1 illustrates a screen which is generated by a computer on which a dispatch management system according to an embodiment of the invention is run and displayed on a monitor associated with the computer; Fig. 2 illustrates another screen which is generated by a computer on which a dispatch management system according to an embodiment of the invention is run and displayed on a monitor associated with the computer; Fig. 3 illustrates a process flow for order entry according to an embodiment of the invention; and,

Fig. 4 illustrates a process flow for dispatch according to an embodiment of the invention.

Detailed Descriptions of Illustrative Embodiments

Referring now to the drawings, the system is described using the use case model. The illustrated system is able to run on Windows NT version 3.51 or 4.0 and Windows 95. The illustrated system is designed to be fault tolerant for continuous operation. It is capable of displaying all dialogs within twenty seconds of activation. As configured, for maximum performance it requires 32 MB of RAM and an Intel Pentium processor.

In this description, the following terms are frequently used. "Actor" means any agency that interacts with the system. All actors are provided with security privileges appropriate for the duties performed within the dispatch management system by each actor. The actor represents a role played by a person or other system component. In order to act within the dispatch management system, an actor must have first logged onto the dispatch management system and navigated to the main control window of the dispatch management system. "Dispatch management system" means the software application itself. To start the dispatch management system, an actor must run the file DMSDTL.exe. A "dispatched screen" contains two tables, illustrated in Fig. 1 as grids. The upper table displays the orders sent to dispatch. The lower table displays orders that have been dispatched but are not yet completed. A "generate reports form" display is a display of all available reports to preview or to print. A "main control window" is a window that is opened after an actor runs the software and logs onto the dispatch management system. The main control window contains the menu bar and toolbar that permit users to initiate all major system activities. A "maintain accounts form" contains all related information for customer accounts. A "maintain users screen" contains all related information for the user system accounts, such as user name, password, security access rights, and so on. A "maintain DMS settings form" contains all options available for dispatch management system configuration and permits the system administrator to modify and save system parameters. An "order form" contains all related information for an order. An illustrative order form according to the invention is illustrated in Fig. 2. An "order search form" contains a grid view of the orders list with columns that display searchable fields. A "pre-condition" of a use case is the state in which the system must be prior to performance of a use case. A "post-condition" of a use case is the state in which the system will be immediately after performance of a use case. A "requisitioner" is an entity that places a pickup request. The requisitioner's name is captured in the "order by" field of an order form. An actor selects a requisitioner from the stored list that is maintained by the system administrator. A "special requirement" is a non-functional requirement that is specific to a use case but is not easily or naturally specified in the text of the use case's event flow. Examples of special requirements include performance, usability, reliability and supportability requirements. A "splash screen" is the screen that appears for a brief interval, illustratively three seconds, after an actor has launched the dispatch management system. A "supplementary requirement" is a non-functional requirement that is common to all use cases in a dispatch management system. Examples of supplementary requirements include performance, usability, reliability and supportability requirements. A "use case" is a sequence of actions that a dispatch management system performs that yields an observable result of value to a particular actor. The following actors may interact with the dispatch management system. A "dispatcher" receives orders from order entry personnel, reviews the orders, and has the ability to sort orders. A dispatcher may sort orders by, for example, date and time ordered, vehicle identification number or VIN, point of origin including address, destination, drivable or tow status, and date and time dispatched. The dispatcher is capable of making updates to order data. The dispatcher assigns a lead van driver. The dispatcher prints bills of lading in appropriate quantities, one for each vehicle, for lead van drivers. The dispatcher receives the valid order after the order entry person presses the save button or presses a shortcut key to save an order, or after the order entry person presses the "send to dispatch" button on the order form. "Order entry personnel" receive pickup requests from vehicle sources, such as vehicle factories, vehicle dealers, and the like. Order entry personnel enter order data. Order entry personnel verify with vehicle sources that vehicles are ready for pickup. Order entry personnel transmit confirmations, for example, by facsimile, to vehicle sources of their orders. Order entry personnel send orders to dispatch. Order entry personnel can initiate the basic flow and all alternative flows of the "manage orders" use case. A "lead van driver" accepts a quantity of bills of lading from a dispatcher and assembles an appropriate number of drivers. A "system administrator" maintains all configuration parameters of the dispatch management system and user accounts.

The use case model is described by the following descriptions. The "manage orders" use case is initiated by an order entry person to create a new order, review an existing order, modify an existing order, cancel an existing order, find an existing order, send confirmation of an order to a vehicle source, and send an order to dispatch. Actors can initiate the basic flow and all alternative flows of the "manage orders" use case. The "manage orders" use case starts when an order entry person opens an order form. The order form contains the status of the order. It indicates whether the call placing the order is completed. It indicates whether the vehicle is drivable, whether keys are available, and whether data on the vehicle has been ordered. The order form identifies the transaction number and the waybill number. It indicates who authorized the order, who placed the order, the orderer's account number and the orderer's reference name/number. The order form indicates the origin, that is, where the vehicle is, including a contact name, telephone number, and the name and address where the vehicle is to be picked up. The order form indicates the destination, that is, where the vehicle is to be delivered, including the name, address and telephone number. The order form also identifies the date and time the order was sent to dispatch, the date and time a driver was dispatched to pick up the vehicle, the driver's identity, typically by a driver number, the last eight characters of the VIN, and the year, model and color of the vehicle. A field is provided on the order form for comments. The order form indicates how much fuel is in the vehicle, whether it has sufficient lubricant, the odometer mileage at the point of origin, the odometer mileage at the destination, the date and time the vehicle was delivered at its destination, and the identity of the recipient. If no activity is selected by the order entry person, the order form displays the current saved order for review. When the order form is opened, it displays the first saved order, or a blank order if no orders have been saved. The order entry person can navigate to the first, last, next and previous orders using toolbar buttons and shortcut keys. The dispatch management system displays the available activities and permits the user to select: "add new" (to create a new order); "edit" (to modify an existing order); "find" (to locate an existing order); "cancel" (to cancel an existing order); "fax confirmation" (to facsimile transmit to a vehicle source confirmation of an order); and "send to dispatch" (to transmit an order to dispatch).

If "add new" is selected, either by clicking on the "new" button on the order form or on the toolbar, or by using a shortcut key, the dispatch management system disables all other action selection until the transaction is completed. The user is able to save or cancel an order. The dispatch management system generates a waybill number, or transactional sequence number, and date ordered. These fields are read only. The dispatch management system enters the name of the user who is logged on in the "authorized by" field of the order form, and enters the default destination's full address. The user can edit the default destination's address field. The user must then complete the "order by" field by selecting from the requisitioners list, the reference name, the account number, the origin fields including contact name, and search for the origin phone number in the account table. If the account exists in the account table, the dispatch management system fills in the name and address fields. Otherwise, the user must fill in the name and address fields, after which the dispatch management system adds a new origin account record when the order is saved on the dispatch management system. The user adds the last eight characters of the VIN, and the year, make and model of the vehicle. The user can edit or update the "is call required" field, the "status" field, the "drivable" field, the "keys" field and the color field. The user then chooses either to save the order or cancel it. The user presses the save button or presses a shortcut key to save. The system validates required fields, adds a time stamp, and saves the order information. The order appears on the dispatch screen. The "manage orders" use case begins again.

If one or more required fields are left blank, the dispatch management system informs the user that one or more required fields have been left blank. The user can then enter the necessary information and save the order or cancel the order. If the value of the "is call required" field is "yes" or the value of the "status" field is not "ready" or the value of the "drivable" field is null or the value of the "drivable" field is null or the value of the "keys" field is null, the order status is set to pending. The user is informed that the order has been saved as pending, and the system displays the order on the pending screen. If the user wishes to cancel an order, the user presses the cancel button or shortcut key. The system asks the user to confirm the cancel order instruction. If the user confirms, the order status is changed to "canceled." The "manage orders" use case begins again.

The user may modify an order by clicking either the modify button on the order form or on the toolbar, or by using a shortcut key. Only users with appropriate security can update the order fields. The dispatch management system inhibits editing of: the destination address fields; the reference name; the account number; the contact name; the phone number; the last eight characters of the VIN; the year, make and model; the "is call required" field; the "status" field; the "drivable" field; the "keys" field; and the "color" field. To update the order fields, the user places the cursor in the field to be updated using the tab key or mouse. The dispatch management system permits editing when a valid editing field is selected. After editing, the user presses the save button or a shortcut key.

The user may find an order by clicking either the find button on the order form or on the toolbar or by using a shortcut key. The order search form opens as a modal dialog window containing a grid view of the orders list with columns that displays searchable fields. The searchable fields are: waybill number; date ordered; origin name; reference name; account number; and last eight characters of the VIN. The user can change the sort order by pressing the tab key and selecting an active column. The user can navigate back and forward by pressing arrow up and arrow down keys or using the mouse. The user can do incremental searching on the active field by typing on alphanumeric keys. The user presses the "ok" button to select an order and return to the order form or the "cancel" button to cancel a search. The "manage orders" use case begins again.

The user can send facsimile confirmation by clicking the "send fax" button on the order form. The dispatch management system generates a text file that contains waybill number, date ordered, "authorized by," "ordered by," full address of origin, lead driver, full address of destination, reference name, account number, contact name, last eight characters of the VIN, year, make, model and color, and special instructions. This file is then printed to the facsimile printer. The facsimile printer can be a fax modem with a printer driver, or a printer assigned as the facsimile printer by the system administrator. The "manage orders" use case begins again. Order entry personnel can send an order to dispatch by clicking the "send to dispatch" button on the order form. The dispatch management system validates the required fields, changes the order status to "ready," adds a date and time stamp, and saves the order information. If the system detects the field "is call required" set to "yes," the order status is "not pending," the "drivable" field is empty, or the "keys" field is empty, it disables the "send to dispatch" button, and the "send order to dispatch" button is disabled. The system permits the "send order to dispatch" action if the order status is "pending," the field "is call required" is set to "no," the field "drivable" is set to "drive" or "tow," and the field "keys" is set to "has keys" or "no keys." The valid order appears on the dispatch screen. The "manage orders" use case begins again. Order entry personnel can cancel an order by clicking either the

"cancel" button on the order form or on the toolbar, or using a shortcut key. The user is asked to confirm the cancellation of the order. If the "cancel" command is confirmed, the order is marked as canceled. The dispatch management system permits cancellation of the order if its status is "pending," "ready," or "dispatched." Orders with "canceled" or "completed" status cannot be canceled. The "manage orders" use case begins again. The user presses the "save" button or presses a shortcut key to save an order.

An illustrative process flow for order entry is illustrated in Fig. 3. Pickup requests are received from various factories and other entities and might include activities such as facsimile receipts for orders, computer generated orders, courier service-delivered orders, and so on. Information entered in the order form is derived from these pickup request documents. The availability of one or more vehicles is verified with the vehicle's (s') source, for example, an automobile dealership, by telephone contact with the source. Specific information is elicited during such telephone contact, for example, is the vehicle ready, is it drivable, must it be towed, are keys available, and so on, as well as the identity of the person who is providing the information concerning vehicle readiness. Should the vehicle not be ready for pickup, the order form includes fields for the entry of the reasons why, and the request is characterized as "pending," and cannot be dispatched until resolution of all of the readiness criteria. The dispatch management system premits a facsimile confirmation to be provided to the source of the order. This confirmation is intended to reduce wasted effort dispatching personnel to pick up vehicles which cannot be picked up. The facsimile confirmation includes specific language relating to the readiness of the vehicle and confirms the telephone conversation between dispatch management system personnel and the contact who ordered the pickup. This facsimile confirmation is believed best achieved using a fax modem in order to make it as effortless as possible. Orders are sent to dispatch by order entry personnel after completion of the required fields of the order and confirmation between dispatch management system personnel and the contact who ordered the pickup that the vehicle is ready for pickup. The paperless order is sent to dispatch by clicking on a designated command. The command to dispatch is date and time stamped. The "dispatch" use case is initiated by a dispatcher to assign lead drivers, review orders and enter delivery times for completed orders. This use case is initiated by the dispatcher opening the dispatch form illustrated in Fig. 1. A dispatcher can initiate the basic flow and all alternative flows of the "dispatch orders" use case. As previously noted, the dispatch form contains two table grids. The upper grid displays the orders that have not been dispatched. Order status is "ready" or

"pending." The grid contains columns assigned to: transaction number; address of origin; whether the vehicle is drivable; the time ordered; the destination address; the make; the model; comments; the identity of the lead driver; the time dispatched; and the status. Orders that have "pending" status and having less than seventy-two hours since the transaction was initiated are displayed with grey background. Pending orders having seventy-two or more hours since the transaction was initiated are highlighted. Orders having "ready" status are displayed with white background. The lower grid displays orders that have been dispatched but have not yet been delivered. These orders have "dispatched" status. This grid contains the same columns as the upper grid, and includes a "time delivered" field. These orders are displayed with white background. The dispatcher places the cursor in the "lead driver" field to enter a driver number. The dispatcher can then select the next record using the mouse or an arrow key, and enter a driver number again. If the current order has "ready" status, the dispatch management system enters the "time dispatched" field with the current date and time and updates the "status" field value to "dispatched." The dispatcher clicks on the "save" button. The system commits the changes to the "order" table and refreshes the order form. The orders that have been dispatched are displayed in the lower grid. New orders that have been entered since the last transaction appear in the upper grid. The "dispatch orders" use case begins again.

The dispatcher can change the sort order of the "not dispatched" orders by selecting one of the following options: origin name; destination name; or, time ordered. The dispatch management system refreshes the data in the grid and changes the sort order of the order records by the selected field. The "dispatch orders" use case begins again. The dispatcher can change the sort order of the "not yet delivered" orders by selecting one of the following options: origin name; destination name; time ordered.; time dispatched; or, lead driver. The dispatch management system refreshes the data in the grid and changes the sort order of the order records by the selected field. The "dispatch orders" use case begins again. The dispatcher can enter the delivery date and time by selecting the order to be edited in the lower grid and entering the date and time when the vehicle was delivered. The dispatch management system updates the status field to "completed." The dispatcher can double click on the "delivery time" field to fill in the current date and time. The dispatcher then clicks on the "save" button. The dispatch management system then commits the changes to the "order" table and refreshes the form. Orders that have been delivered are not displayed. Orders that have been dispatched since the last transaction appear in the lower grid. The "dispatch orders" use case begins again. To close the dispatch form, the dispatcher clicks on the "close" button on the form or uses a shortcut key. The dispatcher is asked to save changes. If the dispatcher selects "save," the dispatch management system commits changes to the database before closing the form. Otherwise, the changes are not saved. The "dispatch orders" use case ends. The dispatcher may assign drivers to orders with pending status. The dispatch management system discards unsaved changes and sets the unsaved driver status to zero. The dispatcher may revoke a driver assignment on an order that has been dispatched but has not yet been committed by changing the driver number to zero. The system resets the order status to "ready" and the time dispatched to null.

The "dispatch order" form can be closed by the dispatcher clicking on the "close" button or using a shortcut key. The dispatcher is asked to save changes to the dispatch order form. If the dispatcher selects the "save" option, the system will save the updates before closing the form. Otherwise, changes will not be saved. An illustrative process flow for dispatch is illustrated in Fig. 4. A dispatcher received orders from order entry personnel. The order appears on the dispatcher's screen. The dispatcher reviews the dispatch screen on an ongoing basis, typically sorting orders by various methods, such as ordering entity, location, date of order, and so on. Dispatch information may be created for consignment orders. Information such as "call for residential pickup" may also be added. The dispatcher assigns lead van drivers to pick up vehicles based on different criteria, such as van size, familiarity with a particular location or dealership, and so on. The dispatcher will add this information to the dispatch screen. The dispatcher will print bills of lading in appropriate quantities, one for each vehicle, for the lead van drivers. The bills of lading typically will be provided with bar code decals for use in later identification and tracking of vehicles. The lead van drivers travel to the vehicle points of origin, locate the vehicles to be transported, apply the appropriate bar code decals to these vehicles, note particular information on the vehicles themselves, for example, on the driver's side windshields of the vehicles, inspect the vehicles, leave copies of the appropriate bills of lading inside the vehicles, and assign drivers to transport the vehicles. The drivers then transport the vehicles to the auction gate for check-in. A remote bar code scanner located at the check-in station scans the code bars on the decal previously applied by the lead driver, the vehicle is entered into the auction's data base, and the entry is time and date stamped. The driver returns a copy of the bill of lading for the vehicle he or she has transported to the billing clerk along with any ancillary charges such as fuel, oil, change in tow/drive status, and so on. The clerk reviews the bills of lading and applies appropriate charges to approved accounts. The billing clerk then prepares invoices. These typically will be prepared within twenty-four hours of delivery, and will include particular information, such as a summary of the vehicles picked up, delivered, vehicle identification numbers, and so on. The dispatch management system permits the customer to determine online the status of an order. This ability results in significant time savings and permits customer personnel who otherwise would have to expend considerable effort tracking orders to engage in more productive activities, such as tracking soon-to-expire leases and so on. In addition, the Internet version of the dispatch management system permits the customer to print reports on the current status of the customer's business. With a user i.d. and password, the customer can determine the status and disposition of vehicles in the customer's inventory essentially in real time. For example, at an automobile auction, dispatchers can monitor many orders which can be sorted by, for example, zip code, city or state. This permits dispatchers to work logistically much more efficiently than prior art manual systems would permit. As well, the Internet activity permits multiple auctions to reside within the same database through a server, thereby achieving the logistical efficiency of a single location. In another words, a team of dispatchers, for example, can study the dispatch management screens and watch multiple auctions for logistical efficiencies, so that resources such as people and trucks retrieving automobiles being auctioned can be utilized with minimum waste. Dispatchers will be afforded many more opportunities to put together efficient runs to transfer automobiles. As well, from a dispatching operations standpoint, the user can create databases of how vehicles move through the process and how buyers and sellers handle these vehicles. In other words, from a management standpoint, a user can watch various auctions to determine how long it takes, for example, for a particular auction to retrieve vehicles as compared to other auctions, and correlate this data with, for example, auctions' locations. The user can then factor in other elements that may affect an auction's efficiency. This provides the user with a management tool that helps the user to know where to focus efforts to improve auction efficiency. The dispatch management system also permits users to create their own reporting through the dispatch management system's reporting features. This permits users to respond and be proactive with their customers from a management standpoint. It permits users to compare the success of various auctions whose success they wish to evaluate, for example, according to a number of different criteria by which the dispatch management system is capable of sorting. The dispatch management system also contemplates a scanning operation having multiple options. A vehicle can complete its cycle in the dispatch management system software, by manually clearing the vehicle if user personnel have first-hand knowledge that the vehicle is there, or a vehicle can complete its cycle by scanning. Scanning can be in the form of hand scanners stationed at various entry and exit points to and from an auction, or stationary scanners, to read bar codes applied to the cars. For example, a vehicle could trigger a bar code scanner to begin interrogating the vehicle for a bar code when the vehicle drives over, for example, an entry and exit coil or metal detector. In another example, a vehicle could interrupt a beam of an infra-red system to trigger a bar code scanner to begin interrogating the vehicle for a bar code. Once a bar code is read, a computer running the dispatch management system would conduct a query whether the code is a valid code for that destination. This happens very quickly. If the code is a valid code, the driver would enter an identity, for example, by using a machine readable identification card, for example, a proximity card, or by entering a thumb print or the like. This would credit the driver for moving that car.

Once the vehicle and driver have been cleared, a light at the arm gate would change from red to green and a computer located in close proximity would send a signal to the arm gate. The arm gate would open and permit the vehicle to pass through, after which the arm gate would close again. The bar code also permits an entry/exit station i.d. to be transmitted so that a vehicle, once it is logged in to an auction, could pass through other stations having their own unique i.d.'s or bar code reading functions, such as hand scanners, at, for example, a body shop or a reconditioning shop. Amounts allocated to specific cost/price functions could then be fed to a central computer and posted as charges to a particular car. This feature can also be used for locating vehicles within a facility. For example, an auction can restrict lanes so that vehicles pass through the restricted lanes in facility parking areas and pass scanners of the general types previously described at various locations in the parking areas, providing indications of where the vehicles are within the facility. An illustrative system thus permits a user to: view and edit shipment data; maintain a consignor database; keep records; provide instant access to records; virtually eliminate handwritten orders; provide immediate knowledge of the locations of vehicles; whether personnel have been dispatched to retrieve vehicles, and the status of those dispatched orders; obtain complete order entry, for example, account number, reference, orderer's name, and so on; obtain alerts concerning pending pickups and incomplete orders; have instant access to proof of delivery; virtually immediate confirmation of orders; print statistical reports; save labor in taking orders; and, provide checks on vehicle log-in, maintenance and inventory processes.

Illustrative hardware shares an existing network with OS NT 3.51 or higher. It can use a separate server and share existing lines. It uses code 39 bar code scanning equipment. It can use remote hard wired or RF scan guns. It has a 33.6 K or faster modem, an SVGA monitor with 600 x 800 resolution, and a backup tape drive of 2 GB or higher capacity. An illustrative server has 64 MB RAM, 50 MB disk space and a 4.3 GB hard drive. Illustrative clients have 16 or 32 MB RAM, 50 MB disk space and 2.1 GB hard drives.

Claims

What is claimed is:

1. A dispatch management system for maintaining information on the status of vehicles, the system including a host, and at least one terminal coupled to the host for the entry of an order for the dispatch of a vehicle.

2. The apparatus of claim 1 wherein the at least one terminal includes at least one order entry terminal.

3. The apparatus of claim 1 wherein the information includes a time stamp for indicating when a transaction is ordered by a customer.

4. The apparatus of claim 1 wherein the information includes the status of the order.

5. The apparatus of claim 1 wherein the information includes whether placement of the order by the customer is complete.

6. The apparatus of claim 1 wherein the information includes whether the vehicle can be driven.

7. The apparatus of claim 1 wherein the information includes whether the vehicle must be towed.

8. The apparatus of claim 1 wherein the information includes whether a key for operating the vehicle is available.

9. The apparatus of claim 1 including apparatus for at least one of generating machine-readable code and scanning machine-readable code for at least one of correlating vehicle information and updating vehicle information.

10. The apparatus of claim 1 including apparatus for creating at least one of a waybill, a bill of lading, an invoice, and an identifier for the vehicle.

11. The apparatus of claim 1 wherein the at least one terminal is coupled to the host for the entry of an order by a customer.

12. The apparatus of claim 1 wherein the information on the status of a vehicle includes at least one of: a transaction number; a waybill number; who authorized the order; who placed the order; the orderer's account number; the orderer's reference for the transaction; where the vehicle is located; where the vehicle is to be delivered; when the order was sent to dispatch; when a driver was dispatched to pick up the vehicle; the driver's identity; the vehicle's identity; information on the vehicle's fuel; information on the vehicle's lubricant; vehicle odometer data at the point of origin; vehicle odometer data at the destination; when the vehicle was delivered to the destination; the identity of the recipient; and, the dispatch status of the vehicle.

13. The apparatus of claim 12 wherein the vehicle's identity includes at least one of: a vehicle identification number; the year of the vehicle; the make of the vehicle; the model of the vehicle; and, the color of the vehicle.

14. The apparatus of claim 12 wherein the terminal for the entry of an order for the dispatch of the vehicle includes a terminal for updating the dispatch status of the vehicle.

15. The apparatus of claim 1 wherein the information on the status of the vehicle includes the assignment of a driver for collection of the vehicle.

16. The apparatus of claim 1 wherein the terminal for the entry of an order for the dispatch of the vehicle includes a terminal for at least one of generating order confirmation and transmitting order confirmation.

17. The apparatus of claim 1 wherein at least one of the host and the terminal includes means for generating at least one of statistics and reports from information collected by the system.

18. The apparatus of claim 1 wherein the host includes information from which a driver can be assigned.

19. The apparatus of claim 1 wherein the host includes a host for at least one of creating a visual indication based on a criterion and displaying a visual indication based on a criterion.

20. The apparatus of claim 1 wherein the host includes a host for automatically changing information based on a criterion.

21. The apparatus of claim 1 wherein the host includes a host for searching for information based on a criterion.

22. The apparatus of claim 1 wherein the host includes a host for identifying individuals who modify stored information.

23. The apparatus of claim 1 wherein the host includes a host for controlling access to the system for changing information stored in the system.

24. A method for maintaining information on the status of vehicles, the method including providing a dispatch management system host, and at least one terminal coupled to the host for the entry of an order for the dispatch of a vehicle.

25. The method of claim 24 wherein providing at least one terminal includes providing at least one order entry terminal.

26. The method of claim 24 wherein maintaining the information includes placing a time stamp on a transaction when the transaction is ordered by a customer.

27. The method of claim 24 wherein maintaining the information includes maintaining the status of the order.

28. The method of claim 24 wherein maintaining the information includes determining whether placement of the order by a customer is complete.

29. The method of claim 24 wherein maintaining the information includes maintaining information concerning whether the vehicle can be driven.

30. The method of claim 24 wherein maintaining the information includes maintaining information concerning whether the vehicle must be towed.

31. The method of claim 24 wherein maintaining the information includes maintaining information concerning whether a key for operating the vehicle is available.

32. The method of claim 24 including at least one of generating machine-readable code and scanning machine-readable code for at least one of correlating vehicle information and updating vehicle information.

33. The method of claim 24 including creating at least one of a waybill, a bill of lading, an invoice, and an identifier for the vehicle.

34. The method of claim 24 wherein providing the at least one terminal coupled to the host includes providing at least one terminal coupled to the host for the entry of an order by a customer.

35. The method of claim 24 wherein maintaining information on the status of a vehicle includes maintaining at least one of: a transaction number; a waybill number; who authorized the order; who placed the order; the orderer's account number; the orderer's reference for the transaction; where the vehicle is located; where the vehicle is to be delivered; when the order was sent to dispatch; when a driver was dispatched to pick up the vehicle; the driver's identity; the vehicle's identity; information on the vehicle's fuel; information on the vehicle's lubricant; vehicle odometer data at the point of origin; vehicle odometer data at the destination; when the vehicle was delivered to the destination; the identity of the recipient; and, the dispatch status of the vehicle.

36. The method of claim 35 wherein providing the vehicle's identity includes providing at least one of: a vehicle identification number; the year of the vehicle; the make of the vehicle; the model of the vehicle; and, the color of the vehicle.

37. The method of claim 35 wherein providing the terminal for the entry of an order for the dispatch of the vehicle includes providing a terminal for updating the dispatch status of the vehicle.

38. The method of claim 24 wherein providing the information on the status of the vehicle includes providing the assignment of a driver for collection of the vehicle.

39. The method of claim 24 wherein providing the terminal for the entry of an order for the dispatch of the vehicle includes providing a terminal for at least one of generating order confirmation and transmitting order confirmation.

40. The method of claim 24 wherein providing at least one of the host and the terminal includes generating at least one of statistics and reports from information collected by the system.

41. The method of claim 24 wherein providing the host includes providing information from which a driver can be assigned.

42. The method of claim 24 wherein providing the host includes providing a host for at least one of creating a visual indication based on a criterion and displaying a visual indication based on a criterion.

43. The method of claim 24 wherein providing the host includes providing a host for automatically changing information based on a criterion.

44. The method of claim 24 wherein providing the host includes providing a host for searching for information based on a criterion.

45. The method of claim 24 wherein providing the host includes providing a host for identifying individuals who modify stored information.

46. The method of claim 24 wherein providing the host includes providing a host for controlling access to the system for changing information stored in the system.