Patent Abstract:
A system and methods to allow multiple stations in geographically dispersed locations to monitor and track vehicle repair record and service status information in a coordinated fashion. In a service area comprised of a number of geographically-bounded service regions, at least one regional communications terminal is provided in communication with a plurality of local communications terminals. Each local communications terminal and regional communications terminal communicates with a vehicle service status database. Vehicle service events are entered into a vehicle tracking system and maintained using the vehicle status database. Database files are exchanged between local communications terminals and regional communications terminals and with a central equipment manager in order to provide timely and accurate dissemination of service status. Vehicle service status, including an equipment availability prediction, is shared with marketing offices and retail locations to enable personnel at such locations to make informed decisions in allocating particular equipment to a customer based on the customer&#39;s needs.

Full Description:
RELATED APPLICATION DATA 
     This application is a continuation of U.S. patent application Ser. No. 09/939,164, filed on Aug. 24, 2001, now U.S. Pat. No. 6,477,452, which is a continuation of U.S. patent application Ser. No. 09/607,189, filed on Jun. 29, 2000, which has been issued as U.S. Pat. No. 6,308,120 on Oct. 23, 2001. 
    
    
     A portion of this disclosure contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or patent disclosure, as it appears in the Patent and Trademark Office files or records, but otherwise reserves all copyright rights whatsoever. 
     FIELD OF THE INVENTION 
     The present invention relates to a vehicle service status tracking system and method. 
     SUMMARY OF THE INVENTION 
     The present invention provides a system and methods to allow multiple stations in geographically dispersed locations to monitor and track vehicle repair record and service status information. In a service area comprised of a number of geographically-bounded service regions, at least one regional communications terminal is provided in communication with a plurality of local communications terminals. Each local communications terminal is typically located at a separate repair or service location having responsibility for servicing the vehicles temporally located within the region. 
     The present invention provides a system and methods for maintaining and disseminating vehicle service information within and among regions. Vehicle service events are entered into a vehicle tracking system and maintained using a vehicle status database. Database files are exchanged among regional communications terminals and with a central equipment manager in order to provide timely and accurate dissemination of service status. 
     A further aspect of the present invention is the sharing of vehicle service status with marketing offices and retail locations. This enables personnel at such locations to understand the repair history of a particular vehicle. 
     A still further aspect of the present invention is the ability to predict vehicle availability or time of return from service. The system and methods according to the present invention provide an availability prediction for operations personnel to allocate fleet vehicles while taking account of anticipated vehicle demand. 
     Other advantages and objectives of the present invention are apparent upon inspection of this specification and the drawings appended thereto. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 is a block diagram depicting the overall arrangement of a preferred embodiment of a vehicle tracking system according to the present invention; 
     FIG. 2 is a functional block diagram of a preferred embodiment of a vehicle tracking system according to the present invention; 
     FIG. 3 depicts the components of a preferred implementation of a local communications terminal and a regional communications terminal according to the present invention; 
     FIG. 4 depicts the contents of a vehicle status database according to a preferred embodiment of the present invention; 
     FIG. 5 depicts a preferred format for a control number for use with a vehicle tracking system according to the present invention; 
     FIG. 6 is an information flow diagram depicting the flow of vehicle repair and service status information throughout a preferred vehicle tracking system; 
     FIGS. 7A and 7B depict processing accomplished by a local communications terminal in a preferred embodiment of the present invention; 
     FIG. 8 depicts the processing accomplished by a regional communications terminal in a preferred embodiment of the present invention; 
     FIG. 9 depicts vehicle repair history processing performed by a local communications terminal and a regional communications terminal according to the present invention; 
     FIG. 10 is a preferred user interface by which a user enters equipment/location validation information at a local communications terminal according to the present invention; 
     FIG. 11 is a preferred user interface for a local communications terminal according to the present invention by which a user may enter portions of vehicle repair/service event information; 
     FIG. 12 is a preferred user interface for a local communications terminal according to the present invention by which a user may modify portions of vehicle repair/service event information; 
     FIG. 13 is a preferred user interface by which a local communications terminal according to the present invention displays a control number to a user; 
     FIG. 14A is a preferred user interface for a local communications terminal according to the present invention providing the capability for a user to edit location information and view location-related reports; 
     FIG. 14B is a preferred user interface for a local communications terminal according to the present invention providing the capability for a user to view a variety of repair shop oriented reports; 
     FIG. 14C is a preferred user interface for a local communications terminal according to the present invention providing the capability for a user to view a variety of traffic reports; 
     FIG. 14D is a preferred user interface for a local communications terminal according to the present invention providing the capability for a user to view a variety of special programs reports; 
     FIG. 15 is a preferred embodiment of an on-screen pop-up multiple breakdown advisory warning provided by a preferred embodiment of the present invention; 
     FIG. 16 is an example of a preferred campaign information warning report provided by a central equipment manager according to the present invention; 
     FIG. 17 is a preferred advisory warning generated by a local communications terminal and a regional communications terminal according to the present invention; 
     FIG. 18 is a preferred report generated by a local communications terminal according to the present invention showing a portion of the out-of-service vehicles whose service has not been completed within a projected repair time; 
     FIG. 19 is a preferred display of a calculated repair/service time provided by a local communications terminal according to the present invention; and 
     FIG. 20 is a preferred down equipment report generated by a local communications terminal and a regional communications terminal according to the present invention displaying information contained in a vehicle history file. 
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     The present invention provides a system and methods to allow multiple stations in geographically dispersed locations to monitor and track vehicle repair record and service status information regardless of vehicle location. 
     FIG. 1 illustrates the overall arrangement of a preferred embodiment of a vehicle tracking system  100  according to the present invention. Referring now to FIG. 1, vehicle tracking system  100  includes a central equipment manager  101 , regional communications terminals  102 , and local communications terminals  103 . Preferably, a single regional communications terminal  102  is allocated to support a given particularly-bounded geographical region. For example, FIG. 1 shows three regions (Regions A, B, and C) each having a regional communications terminal  102 . However, one or more additional regional communications terminals  102  may provide backup communications and processing for one or more regions. 
     Each regional communications terminal  102  is preferably located in a regional company office or other such location having responsibility for maintaining and servicing the vehicles within a particular geographical region or regions. Each local communications terminal  103  is preferably located in a repair and service station having responsibility for repairing broken-down or out-of-service vehicles, as well as for providing routine service and preventive maintenance, for vehicles temporally within that region. A local communications terminal  103  communicates with a regional communications terminal  102  within its local region; however, a given local communications terminal  103  may communicate with one or more regional communications terminals  102  within or outside of its local region. Regional communications terminal  102  is thus provided in shared communication with multiple local communications terminals  103 . 
     FIG. 2 further illustrates the logical relationships among these elements of vehicle tracking system  100 . Referring now to FIG. 2, each regional communications terminal  102  communicates with central equipment manager  101 . Central equipment manager  101  maintains at a single office location vehicle service status information for all regions, and periodically disseminates this information to all regional communications terminals  102  and local communications terminals  103 . 
     In a preferred embodiment, each regional communications terminal  102  communicates with central equipment manager  101  and multiple local communications terminals  103  using a frame relay network  104 . Frame relay is a packet-switched protocol used for connecting terminals to a Wide Area Network (WAN) supporting T-1 or T-3 data rates. Alternatively, frame relay network  104  comprises public switched or private telecommunications circuits such as telephone landlines, the Internet, or wireless transmission systems including, but not limited to, personal communications services, cellular data, satellite, or point-to-point microwave communications. Regional communications terminals  102  are interconnected via frame relay network  104 . 
     Referring again to FIG. 2, vehicle tracking system  100  includes a vehicle status database  200  operably coupled to each local communications terminal  103  and regional communications terminal  102 . A vehicle status database  200  is also operably coupled to central equipment manager  101 . In a preferred embodiment, central equipment manager  101  is a mainframe computer system, such as a DEC® VAX™ or IBM® Model 3070 system, having a frame relay gateway and an Internet interface. Alternatively, central equipment manager  101  is implemented according to a client-server architecture. Central equipment manager  101  preferably communicates with regional communications terminals  102  via frame relay network  104  and with local communications terminal  103  via Internet interface  108 . 
     Central equipment manager  101  transmits a multiple breakdown advisory  215  (see FIG. 6) to all local communications terminals  103  and all regional communications terminals  102 , preferably once per 24-hour period. Central equipment manager  101  transmits a multiple breakdown advisory  215  to local communications terminals  103  as a database file via File Transfer Protocol (FTP) using Internet interface  108 . Preferably, central equipment manager  101  transmits multiple breakdown advisory  215  to regional communications terminals  102  as a database file via frame relay network  108 . Users at repair/service locations having local communications terminal  103  are able to withhold rental of vehicles listed on multiple breakdown advisory  215  if, in the user&#39;s judgment, the vehicle&#39;s repair history indicates a high likelihood of break-down during an extended trip such as, for example, an inter-regional or cross-country trip. This allows an operator of vehicle tracking system  100  to achieve higher overall customer satisfaction and to save money on operating costs such as vehicle towing. 
     Preferably, multiple breakdown advisory  215  is also used to indicate additional conditions affecting the status of a given vehicle such as, but not limited to, a stolen or missing vehicle. For example, FIG. 17 illustrates a preferred advisory warning generated by local communications terminal  103  and regional communications terminal  102  in response to receiving a multiple break-down advisory  215  from central equipment manager  101  providing and indication of a stolen or missing vehicle. 
     Referring again to FIG. 2, a local communications terminal  103  typically provides vehicle service status file  205  to a single regional communications terminal  102 . However, as shown in FIG. 2, local communications terminal  103  may alternatively provide vehicle service status file  205  to multiple regional communications terminals  102  located in different regions. The latter situation may occur, for example, when local communications terminal  103  is located sufficiently physically proximate to two or more regional communications terminals  102  such that it is advantageous for that repair/service location to support vehicles within the control span of either or both regional offices. 
     Referring again to FIG. 2, local communications terminal  103  includes an interface for receiving an entity master list  280  (see FIG. 6) transmitted from central equipment manager  101 . Preferably, central equipment manager  101  transmits entity master list  280  using FTP via Internet interface  108 . The entity master list  280  is useful for identifying the current set of regional company offices, retail locations, and marketing offices. 
     Local communications terminal  103  includes an interface to an Automated Repair Management System (ARMS)  105  for receiving vehicle history file  210  transmitted from central equipment manager  101 . In a preferred embodiment, ARMS  105  is a frame relay network. Central equipment manager  101  preferably transmits vehicle history file  210  to local communications terminals  103  as a database file via File Transfer Protocol (FTP) using ARMS  105 . 
     Referring again to FIG. 2, local communications terminal  103  preferably includes interfaces to retail outlet  106  and marketing office  107  using frame relay network  104 . Local communications terminal  103  transmits vehicle service status file  205  to retail outlet  106  and marketing office  107  via frame relay network  104 . In a preferred embodiment, retail outlet  106  and marketing office  107  include an availability database  300  containing, without limitation, information concerning the availability status of vehicles in the fleet. Users at retail outlet  106  and marketing office  107  are able to allocate vehicle resources to customers, and to predict equipment availability to customers, using the vehicle repair and service status provided in vehicle service status file  205  and availability database  300 . 
     FIG. 3 shows a preferred implementation of local communications terminal  103  and regional communications terminal  102 . Local communications terminal  103  and regional communications terminal  102  include a personal computer based server  150  having standard peripherals including monitor, printer (not shown), keyboard and mouse (not shown), and having an interface to a frame relay network  104  and an Internet interface  108 , and having a vehicle status database  200 . In a preferred embodiment, server  150  is an Intel® Pentium™-based personal computer (PC) running Microsoft® Windows™ operating system software, including Windows NT™ version 4.0. Server  150  executes programmed instructions in accordance with a software application program in order to achieve the functionality described herein. In a preferred embodiment, server  150  application software is written in FoxPro™ version 2.6 for Microsoft® Windows™. In a preferred embodiment, vehicle tracking system  100  includes two independent application programs: one application program for execution at local communication terminal  103 , and a second application program for execution at regional communications terminal  102 . 
     Local communications terminal  103  and regional communications terminal  102  include a web browser and electronic mail capability to enable electronic communication using the Internet, including Hypertext Transport Protocol (HTTP), File Transfer Protocol (FTP), and Simple Mail Transfer Protocol (SMTP). In a preferred embodiment, local communications terminal  103  and regional communications terminal  102  use Microsoft® Internet Explorer™ and Outlook™ application software. 
     In a preferred embodiment, vehicle status database  200  is implemented using FoxPro™ version 2.6™ version 7.0. Server  150  interfaces with vehicle status database  200  using FoxPro™ queries and instructions. 
     FIG. 4 describes the contents of vehicle status database  200 . Referring now to FIG. 4, vehicle status database  200  includes one or more vehicle service status files  205 , a vehicle history file  210 , and multiple break-down advisory  215 . 
     FIG. 6 illustrates the flow of vehicle repair and service status information comprising vehicle status database  200  throughout vehicle tracking system  100 , as described herein. 
     Vehicle service status file  205  is comprised of one or more service event notifications  220 . A service event notification  220  is created or modified by a user, usually a service professional, at a local repair or service location by logging vehicle repair and service information using local communications terminal  103 . Referring again to FIG. 4, service event notification  220  may include, for example, a control number  225 , a vehicle identifier  230 , an equipment type indicator  235 , current status  240 , location identifier  245 , date-in-building indicator  250 , type-of-service-required indicator  255 , an availability prediction  260 , and remarks  265 . 
     In a preferred embodiment, local communications terminal  103  provides for generation of availability prediction  260  by calculating an average repair/service time for the particular location and providing this information to the user. To calculate the average repair/service time, local communications terminal  103  retrieves from vehicle status database  200  service event notifications  220  for repair/service activities accomplished at this service location during the past thirty days. Local communications terminal  103  then computes an average repair/service time by averaging the number of days from date-in-building  250  to closing of the service event notification  220  for each service event notification within the thirty day period. FIG. 19 illustrates a preferred display of the calculated repair/service time provided by local communications terminal  103 . Alternatively, a period of time of shorter or longer duration than thirty days is used in calculating the average repair/service time. Preferably, the average repair/service time is calculated daily. Local communications terminal  103  displays the calculated average repair/service time to the user. Local communications terminal  103  further includes an operator interface that allows the user to enter availability prediction  260  using a keyboard, the user having considered a variety of factors including the average repair/service time. 
     In a first alternative, local communications terminal  103  calculates availability prediction  260  based on, without limitation, the mean-time-to-repair (typically measured in hours) to complete a particular service job for a particular item of equipment. In this alternative embodiment, vehicle status database  200  further includes a set of mean-time-to-repair values indexed by equipment type  235  and type-of-service-required  255 . Mean-time-to-repair values are periodically updated in response to changes in the calculated average repair/service time described above. Local communications terminal  103  sets availability prediction  260  equal to the mean-time-to-repair value associated with the particular equipment type  235  and type-of-service-required  255 . Local communications terminal  103  may modify availability prediction  260  based upon user-provided factors such as, but not limited to, the service backlog at this location, staffing levels at this location, and parts availability. 
     In a second alternative embodiment, local communications terminal  103  automatically calculates availability prediction  260  by setting availability prediction  260  equal to the date occurring three business days following the date service event notification  220  is entered into vehicle service database  200 . Local communications terminal  103  further includes an operator interface that allows a user to modify availability prediction  260  by manually entering a different projected availability date using a keyboard. 
     Local communications terminal  103  stores availability prediction  260  with its associated service event notification  220  record using vehicle status database  200 . In a preferred embodiment, availability prediction  260  is included in the service event notification  220  record as shown in FIG.  4 . Alternatively, the service event notification  220  record includes a pointer to a memory location containing availability prediction  260 . 
     FIG. 5 shows a preferred control number  225  for use with vehicle tracking system  100 . Referring now to FIG. 5, control number  225  is formed by sequentially concatenating two numeric digits corresponding to the current month, two numeric digits corresponding to the current day of the month, and a three-digit sequential service number  275 . Service number  275  is preferably determined by local communications terminal  103  at the time the user enters a new service event notification  220 . A distinct control number  225  is provided for each service request for an individual vehicle. Control number  225  thus patently conveys to an observer an indication of: (1) the date that a particular service event notification  220  was created for the associated vehicle, and (2) the order in which that service event notification  220  was created with respect to other service event notifications  220  logged by that local communications terminal  103  on a particular date. 
     Referring again to FIG. 4, vehicle service status file  205  is comprised of the service event notifications  220  entered or modified at a local communications terminal  103  since the last time vehicle service status file  205  was uploaded to regional communications terminal  102 . In a preferred embodiment, vehicle service status file  205  is created by local communications terminal  103  immediately prior to uploading it to regional communications terminal  102 . Local communications terminal  103  creates vehicle service status file  205  by formulating a query requesting retrieval all of the service event notifications  220  entered or modified (e.g., service ticket closed at the completion of repair, service location changed) since the time of the most recent upload. The retrieved service event notification  220  records are then stored as vehicle service status file  205  using vehicle status database  200 . 
     Referring again to FIG. 6, vehicle service status file  205  is then uploaded to regional communications terminal  102  using frame relay network  104 . In a preferred embodiment, local communications terminal  103  automatically uploads vehicle status file  205  periodically at a frequency of once every 30 minutes. Alternatively, the frequency of upload can be decreased to minimize the number of transmissions or increased to approach real-time notification. Personnel at regional company offices use regional communications terminal  102  to determine equipment status and location in order to manage reservations. For example, if equipment is scheduled to be serviced in a particular region, personnel at other regions will not reserve that vehicle for an inter-regional trip. 
     Regional communications terminal  102  aggregates each of the vehicle status files  205  received from local communications terminals  103  into a vehicle service status report  285 . Regional communications terminal  102  then transmits vehicle service status report  285  to central equipment manager  101 . In a preferred embodiment, regional communications terminal  102  automatically uploads vehicle service status report  285  periodically at a frequency of once every 30 minutes. In a preferred embodiment, vehicle service status report  285  is uploaded from regional communications terminal  102  using frame relay network  104 . 
     Vehicle history file  210  comprises all of the service event notifications  220  associated with a particular vehicle identifier  230 , preferably including all service event notifications  220  occurring in the previous twelve-month period. 
     Vehicle history file  210  is received by local communications terminal  103  and regional communications terminal  102  from central equipment manager  101  and stored using vehicle status database  200 . FIG. 20 illustrates a preferred down equipment report generated by local communications terminal  103  and regional communications terminal  102  displaying information contained in vehicle history file  210  received from central equipment manager  101 . Vehicle history file  210  preferably includes multiple breakdown advisory  215 , a separate indication also provided by central equipment manager  101 . In a preferred embodiment, multiple breakdown advisory  215  is provided as a separate record of vehicle history file  210 . Users of vehicle tracking system  100  are able to detect root cause problems or other systemic problems based on the pattern of recurring repair/service actions for a particular vehicle provided by vehicle history file  210 . For example, a series of dead battery service events can be indicative of an underlying electrical problem. Local communications terminal  103  and regional communications terminal  102  provide a history search capability to allow a user to review service event notifications  220  for a particular vehicle occurring over a period of time which is preferably the previous twelve-month period. 
     FIGS. 7A and 7B describe the processing accomplished by local communications terminal  103  in a preferred method of managing a fleet of vehicles, and vehicle repair record and service status information, in vehicle tracking system  100  (see FIG. 1) having multiple geographically remote service locations, according to the present invention. 
     Referring now to FIG. 7A, a user of vehicle tracking system  100  uses local communications terminal  103  to enter and log vehicle repair and service information (block  301 ). FIG. 10 illustrates a preferred user interface for local communications terminal  103  by which a user enters equipment/location validation information. Specifically, upon a determination of a repair or service action being required for a particular vehicle, a user enters information specific to the repair/service event using local communications terminal  103 . Referring again to FIG. 4, such user-entered repair/service event information includes, but is not limited to, vehicle identifier  230 , equipment type  235 , current status  240 , type of service required  255 , location  245 , date_in_building  250 , and any specific explanatory remarks  265 . FIG. 11 depicts a preferred user interface for local communications terminal  103  by which a user may enter portions of vehicle repair/service event information. FIG. 12 depicts a preferred user interface for local communications terminal  103  by which a user may modify portions of vehicle repair/service event information. 
     In a typical application, local communications terminal  103  is located in a repair and service station having responsibility for repairing and servicing vehicles. Referring again to FIG. 7A, a user, such as a service professional, preferably enters the repair/service event information using an interactive data entry screen and keyboard/mouse provided by local communications terminal  103 . For example, repair/service event information may be manually entered from a written work order, or, alternatively, in conjunction with creation of a written work order. 
     Alternatively, local communications terminal  103  receives repair/service event information from an external source via Internet interface  108  (block  303 ). External sources include, but are not limited to, a mobile repair unit, a remote repair or service location, or other location not equipped with local communications terminal  103 . In this case, an external source transmits vehicle repair/service information to local communications terminal  103  using an electronic message such as, for example, an email message, over Internet interface  108 . 
     After entry or receipt of vehicle repair/service information, local communications terminal  103  generates control number  225  for a new service event notification  220  as described herein in reference to FIG. 5 (block  305 ). FIG. 13 illustrates a preferred user interface by which local communications terminal  103  displays the generated control number  225  to a user. Local communications terminal  103  also generates availability prediction  260  as described elsewhere herein (block  307 ). In a preferred embodiment, control number  225  is generated per block  305  prior to availability prediction  260  being generated per block  307 ; however, these two operations may be accomplished without regard to any particular sequence, or in parallel as well. After obtaining vehicle repair/service information in blocks  301  or  303 , generating control number  225  in block  305 , and generating availability prediction  260  in block  307 , local communications terminal  103  creates service event notification  220  using this information as shown in FIG. 4 (block  309 ). 
     After creating service event notification  220 , each such new service event notification  220  is stored in the local vehicle status database  200  operably coupled to the local communications terminal  103  that generated that service event notification  220  (block  311 ). FIGS. 14A through 14D illustrate a preferred user interface for local communications terminal  103  by which a user may request to receive a variety of service event reports generated by local communications terminal  103  using the vehicle repair/service information contained in vehicle repair database  200 . 
     Referring now to FIG. 14A, local communications terminal  103  provides the capability for a user to edit location information and view location-related reports. 
     Referring now to FIG. 14B, local communications terminal  103  provides the capability for a user to view a variety of repair shop oriented reports, including reports indicating various aspects of equipment disposition and availability at this location, including equipment for which the scheduled repair date has been exceeded. FIG. 18 illustrates a preferred report generated by local communications terminal  103  showing a portion of the out-of-service vehicles whose service has not been completed within a projected repair time. 
     Referring now to FIG. 14C, local communications terminal  103  provides the capability for a user to view a variety of traffic reports. 
     Referring now to FIG. 14D, local communications terminal  103  provides the capability for a user to view a variety of special programs reports, including campaign information (received from, for example, a particular vehicle manufacturer), equipment history search, control number search, and shop transfers. 
     Referring now to FIG. 7B, service event notification  220  processing as described with respect to FIG. 7A continues as required at local communications terminals  103  (reference blocks  313 ,  315 , and  317 ). However, new service event notifications  220  are periodically uploaded to regional communications terminal  102  (block  331 ), marketing offices  107  (block  333 ), and retail outlets  106  (block  335 ). Local communications terminal  103  maintains a series of software-implemented upload timers used to determine when the current set of new service event notifications  220  are collected and uploaded to each of these destination nodes. In a preferred embodiment, a first timer, TIMER_1, is used to determine when local communications terminal  103  uploads the current set of new service event notifications  220  to regional communications terminal  102  (block  313 ). Another timer, TIMER_2, is used to determine when local communications terminal  103  uploads the current set of new service event notifications  220  to marketing office  107  (block  315 ). A third timer, TIMER_3, is used to determine when local communications terminal  103  uploads the current set of new service event notifications  220  to retail outlets  106  (block  317 ). 
     In a preferred embodiment, local communications terminal  103  employs three separate upload timers each having independent expiration times but each being set to a value of approximately 30 minutes. The timer values are each independently modifiable by the user. In a first alternative embodiment, a single timer may be used to effect periodic uploading of the current set of new service event notifications  220  to regional communications terminal  102 , marketing offices  107 , and retail outlets  106 . In a second alternative embodiment, service event notification  220  upload is accomplished aperiodically in response to the occurrence of one or a combination of external events, or upon receiving an upload request from the destination node. 
     Referring again to FIG. 7B, upon the expiration of upload TIMER — 1 (block  313 ), local communications terminal  103  retrieves from its local vehicle status database  200  the set of service event notifications  220  entered since the time of the last upload action associated with TIMER — 1 (block  319 ). In a preferred embodiment, this is accomplished by formulating a database query to retrieve service event notifications  220  having entry dates later in time than the most recently accomplished upload action associated with TIMER — 1. This database query is then transmitted to vehicle status database  200 . Vehicle status database  200  responds by providing to local communications terminal  103  the set of service event notifications  220 , if any, meeting the query criteria. 
     Local communications terminal  103  gathers the set of service event notifications  220  from block  319  into a vehicle service status file  205  (block  325 ) as described in FIG.  4 . In block  331 , local communications terminal  103  then uploads vehicle service status file  205  to regional communications terminal  102  via Frame relay network  104 . Similarly, upon the expiration of upload TIMER — 2 (block  315 ), local communications terminal  103  retrieves from its local vehicle status database  200  the set of service event notifications  220  entered since the time of the last upload action associated with TIMER — 2 (block  321 ). Local communications terminal  103  gathers the set of service event notifications  220  from block  321  into a vehicle service status file  205  (block  327 ). In block  333 , local communications terminal  103  then uploads vehicle service status file  205  to marketing office  107  via frame relay network  104 . 
     Further, upon the expiration of upload TIMER — 3 (block  317 ), local communications terminal  103  retrieves from its local vehicle status database  200  the set of service event notifications  220  entered since the time of the last upload action associated with TIMER — 3 (block  323 ). Local communications terminal  103  gathers the set of service event notifications  220  from block  323  into a vehicle service status file  205  (block  329 ). In block  335 , local communications terminal  103  then uploads vehicle service status file  205  to retail outlet  106  via frame relay network  104 . 
     Referring now to FIG. 8, regional communications terminal  102  receives vehicle service status file  205  from one or more local communications terminals  103  via frame relay network  104  (block  351 ). Upon receiving vehicle service status file  205 , regional communications terminal  102  stores vehicle service status file  205  using its local vehicle status database  200  (block  353 ). 
     Regional communications terminal  102  maintains a software-implemented upload timer to determine when the current set of new vehicle service status files  205  are to be collected and uploaded to central equipment manager  101  (block  355 ). In a preferred embodiment, regional communications terminal  102  upload timer is set to a value of approximately 30 minutes. The timer value may be modified as required by the user. Alternatively, vehicle service status file upload is accomplished aperiodically in response to the occurrence of one or a combination of external events, or upon receiving a request for upload from central equipment manager  101 . 
     Upon the expiration of the upload timer (block  355 ), regional communications terminal  102  retrieves from its local vehicle status database  200  the set of vehicle service status files  205  entered since the time of the last upload action (block  357 ). In a preferred embodiment, this is accomplished by formulating a database query to retrieve vehicle service status files  205  having receipt dates later in time than the most recently accomplished upload action. This database query is then transmitted to vehicle status database  200 . Vehicle status database  200  responds by providing to regional communications terminal  102  the set of vehicle service status files  205 , if any, meeting the query criteria. 
     Regional communications terminal  102  collects the set of vehicle service status files  205  from block  357  into a vehicle service status report  285  (block  359 ). In a preferred embodiment, vehicle service status report  285  is a single file formed by sequentially appending the contents (i.e., service event notification  220  records) of each vehicle service status file  205  in a sequence from oldest to newest (with respect to time of receipt). In block  361 , regional communications terminal  102  then uploads vehicle service status report  285  to central equipment manager  101  via frame relay network  104 . 
     In a preferred embodiment, local communications terminal  103  and regional communications terminal  102  receive vehicle history file  210 , entity master  280 , and multiple breakdown advisory  215  from central equipment manager  101  once per 24-hour period. 
     Referring now to FIG. 9, central equipment manager  101  periodically transmits vehicle history file  210  to local communications terminals  103  and regional communications terminals  102  using electronic network  105 . Electronic network  105  may be referred to as an Automated Repair Management System (ARMS). Local communications terminal  103  and regional communications terminal  102  receive vehicle history file  210  (block  371 ) and store the received vehicle history file  210  using vehicle status database  200  (block  377 ). 
     Local communications terminal  103  and regional communications terminal  102  receive additional information from central equipment manager  101  via electronic network  105 . For example, FIG. 16 provides an example campaign information warning report received from central equipment manager  101 . 
     Referring again to FIG. 9, central equipment manager  101  periodically transmits entity master  280  list to local communications terminals  103  using Internet interface  108  and to regional communications terminals  102  using frame relay network  104 . Upon receiving entity master  280  list (block  373 ), local communications terminal  103  and regional communications terminal  102  store the received entity master  280  list using vehicle status database  200  (block  379 ). 
     Central equipment manager  101  also transmits multiple break-down advisory  215  to all local communications terminals  102  and all regional communications terminals  103 . Upon receiving a multiple breakdown advisory (block  375 ), local communications terminal  103  and regional communications terminal  102  provide a multiple breakdown advisory warning (block  387 ) to alert the user to consider this information in assessing the suitability of the vehicle for a particular rental itinerary. In a preferred embodiment, local communications terminal  103  and regional communications terminal  102  provide the advisory warning in the form of an on-screen pop-up warning box on the display device of processor  150 . FIG. 15 illustrates a preferred embodiment of an on-screen pop-up multiple breakdown advisory warning. 
     In addition, regional communications terminal  102  reviews service event notifications  220  received from local communications terminals  103  in vehicle service status files  205  for actual service completion times (block  381 ). 
     In a preferred embodiment, regional communications terminal  102  determines if the repair/service action has not occurred by the time specified by availability prediction  260 . Specifically, if the repair/service action is not accomplished within 24 hours of the projected completion date specified by availability prediction  260  (block  383 ), then regional communications terminal  102  provides a service time advisory warning (block  389 ). The time in excess of the availability prediction  260  that triggers the advisory warning is user-programmable from as little as two hours to as long as four weeks. In a preferred embodiment, regional communications terminal  102  provides the service time advisory warning in the form of an on-screen pop-up warning text box on the display device of processor  150 . The user may thereafter take corrective action such as, for example, telephoning the service location to determine the cause of the service delay. 
     In a preferred embodiment, local communications terminal  103  reviews service event notifications  220  for vehicles whose number of repair/service actions exceed a pre-defined threshold (block  385 ). If the repair threshold has been exceeded, then regional communications terminal provides multiple breakdown advisory  215  as described above for block  387 . In a preferred embodiment, the pre-defined threshold for multiple breakdown advisory is two service event notifications  220  within the last sixty-day period. If the threshold is exceeded, multiple breakdown advisory  215  provides the user the option of retrieving and displaying or printing the service event notifications  220  associated with the vehicle. 
     Thus, a system and methods for managing a fleet of vehicles has been shown that allows multiple geographically dispersed locations to monitor and track vehicle service status, including generating a prediction of vehicle availability. 
     While the above description contains many specific details of the preferred embodiments of the present invention, these should not be construed as limitations on the scope of the invention, but rather are presented in the way of exemplification. Other variations are possible. Accordingly, the scope of the present invention should be determined not by the embodiments illustrated above, but by the appended claims and their legal equivalents.

Technology Classification (CPC): 6