WO1999045519A2

WO1999045519A2 - Fleet management system and method

Info

Publication number: WO1999045519A2
Application number: PCT/US1999/004931
Authority: WO
Inventors: Sanjiv Prabhakaran
Original assignee: Mobile Information System, Inc.
Priority date: 1998-03-06
Filing date: 1999-03-05
Publication date: 1999-09-10
Also published as: AU2898799A; WO1999045519A3

Abstract

According to the present invention, a technique for processing data is provided. The invention provides a fleet management system with a novel interface unit. The interface unit (116) that includes a processor (122). A positioning system (120) couples to a first antenna (126) and to the processor. A remote data terminal (118) electrically couples to the interface unit during at least a first time period. The remote data terminal is capable of data transfers with the interface unit during the first time period and with a user.

Description

FLEET MANAGEMENT SYSTEM AND METHOD

COPYRIGHT NOTICE A portion of the disclosure of this patent 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 the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all Copyright rights \\ hatsoever.

BACKGROUND OF THE INVENTION The present invention relates to an apparatus and system for data processing and, more specifically, data processing as it relates to transportation management. The present invention is illustrated by way of an example with regard to a system for fleet management using an apparatus and method capable of remotely transmitting and receiving information from a base station. But it will be recognized transmitting and receiving information from a base station. But it will be recognized that the invention has a wider range of applicability. Merely by way of example, the invention can be applied to other types of transportation, mapping, information management, and the like. As the world becomes more industrialized and populated, transportation requirements also increase rapidly. In particular, the number of vehicles such as automobiles, trucks, vans, and the like on typical city highways has increased to levels such that traffic jams are now a way of life for a typical driver using these highways as a means for travel. In fact, some of these highways are so constricted that anyone using them can experience significant delays often unexpectedly due to problems such as accidents, road construction, and others. These problems also exist on other transportation ways such as our city streets, airways, and waterways. Accordingly, it is often difficult to predict with any accuracy the location of a vehicle using these transportation ways. Cities and governments have attempted to resolve some of these problems by adding more transportation infrastructure in highly populated areas. This infrastructure often comes in the form of improved roads or highways, train systems, and the like. Unfortunately, roads, highways, and train systems are often difficult to build in highly populated areas and are generally extremely expensive and time consuming to build. In most cases, construction used to provide this additional infrastructure often causes even more traffic congestion and other problems.

Based upon this state of the transportation infrastructure in most industrialized countries, it is often difficult for a company involved in the courier or delivery business to accurately track its vehicles and deliveries. The problems mentioned above severely limit the predictability for a fleet manager to track vehicles in its fleet for the pick-up and delivery of information, packages, and people. Moreover, it is desirable but difficult to keep the fleet manager up-to-date about the status of members of the fleet and to update the fleet members with information from the manager. Industry also has attempted to resolve some of these problems. For instance, some companies are now providing their couriers with cellular phones and radios so that a dispatcher can communicate with them. Other companies retrofit their vehicles with navigational systems such as LORAN or a global positioning system (GPS) to determine vehicle location. Still, other companies are using maps and GPS to track vehicle location by dispatchers at a central office terminal. One such company is Mobile Information Systems, Inc. ("Mobile

Information Systems"), assignee of the present application, which pioneered a technique for implementing easy-to-read maps for tracking vehicle location on a display or workstation at the central office terminal or any other terminal. In particular, Mobile Information Systems implemented one of the first techniques for using a raster-type map and vector data for referencing vehicle location. The raster-type map used on a display had features that were easy-to-read for a dispatcher or user. These features were generally geographical in nature and were easier to reference than the maps predominantly made using stick-type representations of geographical features. The techniques used by Mobile Information Systems have partly overcome some of the daily problems faced by a fleet manager or the like. It would, however, be desirable to develop other techniques for integrating further aspects of fleet management.

Based upon the above, it would be desirable to develop a device for improving a user's ability to create and receive data to help with the predictability, efficiency, and accuracy of task management such as fleet management or tracking any object that can be transported into our roadways, highways, waterways, airways, and the like.

SUMMARY OF THE INVENTION

According to the present invention, a technique for processing data is provided. In an exemplary embodiment, the invention provides a technique for fleet management in a flexible way to process data at a remote location such that a user may conveniently enter and transfer data and also have ready access to powerful data processing. The present technique can be used in a variety of applications such as transportation and the like. In a specific embodiment, the present invention provides a system for fleet management having an improved interface unit at a user location. The system also has, among many features, a graphical interface user apparatus having a display and user interface such as a keyboard. The fleet management system further has an information center, which provides vehicle position data and the like. This vehicle position data are received and transmitted to a fleet of vehicles (e.g. , couriers) through the mobile information center. In a preferred embodiment, the vehicle position data are received and transmitted from a novel interface unit (e.g., hand-held unit, mobile data terminal, personal information manager, commonly known as PLM or the like). The interface unit includes, among a variety of features, a processor, e.g., microprocessor, digital signal processor, microcomputer. A positioning system (e.g., GPS) couples to a first antenna and to the processor. A remote data terminal electrically couples to the interface unit during at least a first time period. The remote data terminal is capable of data transfers with the interface unit during the first time period and with a user in the vehicle. This system allows a user to take the remote data terminal on errands away from the interface unit, and transfer data to and from the interface unit. The information center is operably coupled to the interface unit.

In a modification to the above embodiment, the remote data terminal is adapted to be hand-held. This allows the user to carry the remote data terminal on errands. Thus, the user can enter data conveniently in real-time when the user receives data. This, for example, allows the user to avoid writing the data onto paper only to be entered electronically later.

In still another embodiment for fleet management, the present invention provides a method of data processing including receiving user data in a control unit, receiving positioning data from a first antenna of the control unit, and transmitting the user data and the positioning data, using a second antenna of the control unit, to a base station. This embodiment provides a method by which user data may be combined with positioning data thereby providing an indication of not only the substance but also the origin of the user data.

In yet an alternative embodiment directed to fleet management, the present invention provides a microprocessor based system using a novel set of instructions or computer codes. The computer codes form a computer program (e.g., software) to carry out the functionality and methods described herein. The functionality and methods are described throughout the present specification and more particularly below.

This invention provides myriad advantages. For example, quick access could be gained to valuable information such as the user's current location, speed, direction, destination, schedule, estimated time to destination, and required time to destination in some embodiments. The present invention can also store and transmit precise tracking information regarding the user's past, present, and future positions and locations at noteworthy times such as when the user reaches certain destinations including pickup and delivery points in other embodiments. When used in conjunction with scheduling techniques, the present invention can, for example, improve user efficiency b reducing the time and cost of travel between destinations while providing improved tracking of the user, packages, or the like. The present invention can provide accurate location and tracking information automatically, without requiring the user to enter this information which may require additional time or introduce human error. Also, the present invention may provide these and other advantages in a convenient and portable package. At least one, of not all, of these advantages are integrated into an easy to use fleet management system for controlling and/or tracking a fleet of movable items, e.g., vehicles, planes, trucks, people, boats, golf carts, trains. Of course, the present invention provides other advantages. Hence, the description provided here is only exemplary and not an exhaustive list.

Some of the novel features of the invention are set forth in the appended claims. The invention, however, as well as other features and advantages thereof, will be best understood by reference to the detailed description which follows, when read in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a simplified diagram of a display according to the present invention;

Figs. 2-5 are simplified diagrams of fleet management systems according to embodiments of the present invention; and Figs. 6-15 are simplified diagrams of one or more data processing systems according to embodiments of the present invention.

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS

The following descriptions use several acronyms and abbreviations. For the reader's convenience, the following is a list of some acronyms and abbreviations that may be used in this present specification:

API Application Program Interface

AVL Automatic Vehicle Location

CAD Computer Aided Dispatching

GPS Global Positioning System

IPC Inter-Process Communication

MCU Mobile Control Unit

MDS Mobile Data Suite

MDT Mobile Data Terminal

MIC Mobile Information Center

MIC-RUN MIC Database Runtime Process

CMIC Centralized Mobile Information Center

MPM Main Process Manager

MID Mobile Interchange Data

MTS Mobile Tracking Station

TCP/IP Transport Communication Protocol/Internet Protocol

T/R Transmitter/Receiver

TWM Two-Way Messaging

SCB System Controller Board

DisDlav Technioue S

Fig. 1 illustrates an integrated raster map display according to an embodiment of the present invention. This diagram is merely an illustration and should not limit the scope of the claims herein. The raster map 510 includes natural features such as marshlands 512, creeks 514, and the like. The raster map 510 also includes manmade features such as the Auto Assembly Plant 516, Agnews Hospital 518, and others. The raster map is, for example, a digitally scanned road map, a digitally scanned automobile road map, a raster image in digital form, a preexisting digital map without intelligent information, a digital map in TIFF format, a digitized video image, a digitized satellite image, or the like. Of course, the raster map can also generally be almost any type of digital map with substantially clear features without intelligent street information or the like.

Icons 520 show the position of the vehicles identified in the vector information table 528. But it will be recognized that the icons can also represent any mobile entities such as automobiles, vans, trucks, ambulances, animals, people, boats, ships, motorcycles, bicycles, tractors, moving equipment, trains, courier services, container ships, shipping containers, airplanes, public utility vehicles, telephone company vehicles, taxi cabs, buses, milk delivery vehicles, golf carts, beverage delivery vehicles, fire trucks and vehicles, hazardous waste transportation vehicles, chemical transportation vehicles, long haul trucks, local haul trucks, emergency vehicles, and the like. The icons can represent any mobile or potentially mobile entity or the like.

The vector information table 528 indicates selected geographic and cartographic information retrieved from, for example, the vector database. The vector information table 528 provides intelligent street information such as block number, address information, nearest cross-section of major streets, and the like with reference to the vehicle position. The vector table can also provide information about vehicle speed, vehicle heading, an activity status, a time status, and the like.

The display shown in Fig. 1 can be divided into at least two regions or segments such as a raster display segment 530, a vector information display segment 532, and others. The raster display segment 530 includes a first and second axis 534, 536 representing the latitudinal and longitudinal position of the vehicle position, respectively. Alternatively, the raster display segment may be in cylindrical or polar coordinates, and may not be limited to two dimensions. A digitized map of the region through which the vehicle travels is displayed in the first segment of the display 530, adjacent to the first and second axis 534, 536. As noted above, each vehicle is represented as an icon. The icons may be color coded relative to a status chart and the like. Of course, the shape and color of each icon depend upon the particular application.

Furthermore, the display segments can be in the form of one or more "windows" that are commonly used in graphical user interfaces. The window can have either vector or graphical information, or a combination of vector and graphical information. The windows can be disposed along an edge of the display or in the center of the display. Furthermore, the windows can be moved from any location on the display for easier reading and referencing. In still a further embodiment, the present display can include addition features such as those discussed in U.S. Serial

Application Nos. and (Attorney Docket Nos. 15517-1-4-1 and 15517-

1-4-2, respectively), filed on date of this application and assigned to the present assignee, which are hereby incorporated by reference.

Block Diagrams of Fleet Tracking System

Fig. 2 illustrates a block diagram of the fleet tracking system 600 for automatic vehicle location according to the present invention. Each vehicle 610a-610n includes a navigational tracking device hereafter called a fleet mobile data suite (MDS) 611a-611n. The fleet MDS 611 includes a microprocessor-controlled circuit 700 coupled to a GPS navigational sensor 702. a mobile radio modem 704, and a specialized mobile radio (SMR) 706 operational in the 800-900 Mhz frequency range, as illustrated by Fig. 3. The fleet MDS 611 continuously compiles latitude and longitude position data from the GPS sensor. Latitude and longitude position data is periodically transmitted to the data acquisition system 612.

The mobile position block 616 processes vehicle location information typically on a UNIX based computer. Other computer such as Windows NT, DOS, MacOs, etc. based computer, for example, are also contemplated for alternative embodiments of the present invention. The mobile position block 616 includes a data acquisition system 612, a mobile position database 614, a UNIX process

DBFUPDATE 618, a disk database 622, and a UNIX process DBREQSRV 624. The data acquisition system 612 includes a personal computer coupled to both a base data link controller, and a specialized mobile radio (SMR) operational in the 800-900 Mhz frequency range, but is not limited to this radio. Cellular telephones, wireless "totem pole" communication, pagers, and other wireless communication techniques can also be used. The data acquisition system 612 receives latitude and longitude position data from the fleet MDS 611 , attaches a vehicle identifier to the navigational position data, and transmits the data block 613 (e.g., vehicle identification, latitude, longitude) to the mobile position database 614. Vehicle position is defined in terms of a latitude and longitude value during a predetermined time period. The UNIX process DBFUPDATE 618 scans the mobile position database 614, preferably every 5 seconds, for any new information from the fleet MDS. The new data 620 is permanently stored in the disk database 622 for subsequent retrieval of historical information. Another UNIX process DBREQSRV 624 processes requests by the user from the mobile tracking station 626 for navigational position information. The mobile tracking station 626 can be a high resolution color UNIX workstation. User requests 628 are originated by mobile information data process 630, a UNIX process running on the mobile tracking station 626.

The mobile information data process 630 receives latitude and longitude position data for a ϋarticular vehicle. The mobile information data process 630 accesses the vector database 631 using the vector utilities 632. The vector utilities 632 match the latitude and longitude position information 634 to the latitude and longitude of street segment information 636 from the vector database 631. In addition, the vector utilities 632 match the latitude and longitude position information 634 to the latitude and longitude information of the cross-section of major streets 636 in the cross-section vector database 638. The cross-section vector database 638 can be a subsection of the vector database 631.

The nearest matching street segment, its street name and block number range, and the nearest cross-section of major streets, and its street name 640 are transmitted to the mobile information data process 630. The mobile information data process 630 attaches the street text information to the mobile position information and sends this data packet 642 to the fleet process 644.

The fleet process 644, a UNIX based process or the like, is the user interface display process. The fleet process 644 receives mobile position information and street text information from the mobile information data process 630. In addition, the fleet process 644 accesses the raster database 645 through the raster map utilities 646.

The raster map utilities 646 match the latitude and longitude mobile position 648 from the fleet MDS 611 to the various digitized raster maps data 650 in the raster map database 645. By specifying the zoom level option, using as an example, the Xll/Motif graphical user interface on the mobile tracking station 626, the digitized raster map is displayed in one display window segment 530 and the corresponding street text information on another display window segment 532. A user locatable mark 520 represents the fleet MDS position for a particular vehicle. The icon 520 is positioned at the corresponding latitude and longitude location on the raster map display 530.

Historical data requests may be made by specifying a particular time period and a particular fleet MDS 611. The data request is sent by the fleet process 644 to the mobile information data process 630. The mobile information data (MID) process 630 in turn sends a request 628 to the DBRQSRV 624 process. The DBRQSRV 624 process accesses the disk database 622 and retrieves reports for the specific time period and fleet MDS 611. For every historical report sent back to the MID process 630, the above described process flow for accessing and displaying the raster map, vector street information, and displaying the user locatable mark representing the position of the navigational system is followed.

The vehicle display system includes at least three databases (a mobile position database 614, a raster database 645 and a vector database 631). The database information is interrelated by common latitude and longitude position data. A mobile tracking station 626 displays the position, raster and vector information in a format easily understood by the dispatcher or fleet manager. The first database, the mobile position database 614, is a positional information database for storing vehicle position information received from the navigation systems . Navigational data transmitted from systems such as LORAN and GPS (Global Positioning System) is stored into data records indicating the latitude and longitude of a particular vehicle during a predetermined time interval. The DAQ process 612 is used to format position data received from the navigational system into the mobile position database 614. The vehicle identification is used as locator field to access the database for a particular vehicle. Vehicle position data is stored related to the vehicle identifier. The second database, the raster database 645, is generated by digitally scanning a standard road map or paper map. The raster database 645 contains a digitized version of the visual features of the land for a specified region. Digitized raster information is stored in the raster database 645 in data records. Each data record corresponds to a digitized region having a particular latitude and longitude value. The latitude and longitude values are used as a locator field for accessing the raster database 645.

Data from both the raster database 645 and the mobile position database 614 are used in displaying the raster map and icon 520 in the first segment 530 of the display shown in Fig. 5. The fleet process 644 in combination with the raster map utilities 646, MID process 630, and vector map utilities 632 contains routines to access the mobile position database 614 and the raster map database 612. Both the mobile position database 614 and the raster map database 645 include a latitude and longitude field identifier. The raster map utility 646 in combination with the fleet process 644 and MID 630 matches the longitude and latitude values from the mobile position database 614 and the raster map database 645 and displays an icon 520 (representative of a particular vehicle) moving along the raster map as it changes its latitude and longitude position. The icon 520 moves according to the navigational data extracted from the mobile position database 614 for a particular vehicle. The icon 520 is also displayed in the first display segment 530. Since the latitude and longitudinal position of the icon 520 corresponds to a street location, the icon 520 moves along a particular street on the raster map display 530. However, because the raster map is merely a digitized representation of the street, no interrelationship between different street locations or landmarks exists and intelligent street information is not displayed. A third database, the vector database 631, is needed to provide intelligent street information. Vector address data and street information is publicly available from the US Census Bureau. The US Census provides GBF/DIME (Geographic Base Files/Dual Independent Map Encoding) files which are a common source of address data for dispatching applications. These files contain information describing the street network and other features. Each field record contains the segment name, address range and ZIP code. Node numbers for intersections are referenced to the vehicle latitude and longitude coordinate position.

A third database the vector database 631, contains vector information provided from GBF/DIME files. Vector information is displayed in the second display segment 532. The vector information displayed in segment 532 is typically displayed as text and relates intelligent street information corresponding to the latitude and longitude of a particular vehicle. Display segment 532 of Fig. 5 represents the vector text information.

The MID process 630 contains routines to access the mobile position database 614. Both the mobile position database 614 and the vector map database include a latitude and longitude field identifier. The vector utility 632 in combination with the MID process 630 contains routines to extract block number, street name, cross-section of major streets and other address related information and to match the longitude and latitude values from the mobile position database 614 to the vector map database 632. The mobile tracking station 626 displays the vehicle position on a raster map and corresponding address information simultaneously .

The steps for display of the integrated system include defining a coordinate system having a first axis representing the latitude of the vehicle position and a second axis representing the longitude of the vehicle position. Digitized information representative of a raster map is extracted from the raster database 645 and displayed adjacent to the first and second axes to form a raster map of a first predefined area. Mobile position data from the GPS navigation system corresponding to vehicle latitude and longitude position during a predetermined time interval is extracted from the mobile position database 614. A user locatable mark 520 in the first display segment 530 corresponding to the latitude and longitude of the vehicle position is displayed. Intelligent street information is extracted from a third database, the vector database 631. Vector text information is displayed in a second segment 532 of the display. The vector text information corresponds to the latitude and longitude of the user locatable mark 520.

Fig. 4 illustrates a simplified block diagram 800 of an integrated raster map display and information display according to an alternative embodiment of the present invention. The block diagram is merely a simplified illustration and should not limit the scope of the claims as defined herein. The block diagram provides functions for accessing mobile information center (MIC) databases and servers to handle sub-systems such as an automatic vehicle location (AVL) system, a two-way messaging (TWM) system, a computer aided dispatch (CAD) system, and others. The simplified block diagram includes fleet mobile units 610, a mobile information center (MIC) 802, a mobile tracking system-mobile information center link (MTS- MIC LINK) 804, a mobile tracking system 806, among other features.

The mobile tracking system 806 includes system elements such as a mobile tracking station 626. a fleet process 644, a computer aided dispatch system 811, a mobile information data menu (MIDMENU) 821, a mobile information data main process (MIDMAIN) 823, and other elements. The mobile tracking system provides functions similar to the previous embodiment, but also has the computer aided dispatch system 811 and other elements. Selected system elements from the previous embodiment such as the mobile information data process 630, raster utility library 646, raster database 645, vector database 631, vector utility library 632 are combined within the MIDMENU & MIDMAIN 821, 823 process (hereinafter collectively "MIDMAIN"). A UNIX process such as the DBREQSRV 624 processes requests by a user from the mobile tracking station 626 for navigational position information. The mobile tracking station 626 can be any suitable high resolution color UNIX workstation or the like. User requests 628 originate at the MIDMAIN 821, 823 process which is a UNIX process running on the mobile tracking station 626.

The MIDMAIN 821, 823 process receives latitude and longitude position data for a selected mobile unit MDS-1 to MDS-n via line represented as 629. The MIDMAIN 821. 823 process accesses the vector database (or memory) 631 using the vector utilities. The vector utilities match the latitude and longitude position information to the latitude and longitude of street segment information from the vector database. The vector utilities also match the latitude and longitude position information to the latitude and longitude information of the cross-section of major streets in the cross-section vector database. The cross-section vector database is a subsection of the vector database, all within the MIDMAIN 821, 823 process or the like.

The MIDMAIN 821, 823 process via vector utility library retrieves the nearest matching street segment, its street name and block number range, and the nearest cross-section of major streets, and its street name and other information. The MIDMAIN 821, 823 process via mobile information data process attaches the street text information to the mobile position information and defines such information as a data packet or the like. The MIDMAIN 821, 823 process sends the data packet over a line represented as 642 to the fleet process 644. The fleet process 644 is a user interface display process. The fleet process can be any suitable user interface display process such as a UNIX process or the like. The fleet process 644 receives mobile position information and street text information from the MIDMAIN 821, 823 process. The fleet process 644 accesses via line represented as 642 the raster database (or memory) through the raster map utilities, all in the MIDMAIN 821. 823.

The raster map utilities match the latitude and longitude mobile position from the fleet mobile units to the various digitized raster maps data in the raster map database. By specifying the zoom level option, using for example the X22/Motif graphical user interface on the mobile tracking station 626, the digitized raster map is displayed in one display window segment 530 and the corresponding street text information on another display window segment 532. A user locatable mark 520 (or icon) represents the fleet mobile units position for a particular vehicle. The icon 520 is positioned at the corresponding latitude and longitude location on the raster map display 530.

The display system includes at least three databases or memory locations and the like (a mobile position database 614, a raster database 645, and a vector database 631). The database information is interrelated by common latitude and longitude position data. The mobile tracking station 626 displays the position, raster and vector information in a format easily understood by the dispatcher or fleet manager. For example, the raster information includes a graphical representation of the raster map and icons graphically depict locations of the fleet mobile units on such raster map. Vector information is superimposed onto the raster map to provide intelligence. Other functions of the vehicle display system are similar to the previous embodiment.

In the fleet mobile units, each vehicle 610a-610n includes a navigational tracking device, hereinafter called a fleet mobile data suite (MDS-1 to MDS-n) 611a-611n. Each fleet MDS 611a-611n includes elements such as a microprocessor-controlled circuit coupled to a GPS navigational sensor and the like, a mobile radio modem, and a specialized mobile radio (SMR) operational in, for example, the 800-900 Mhz frequency range. But it would be recognized that the specialized mobile radio may be any type of wireless commumcation means such as cellular telephone, frequency modulated (FM) carrier means, cellular digital packet data means (CDPD), satellite communication, wide area wireless communication network (WAN) such a product called Ricochet™ sold by Metricom of Los Gatos, California, and others. The mobile radio modem can also be a data modem, PCMCIA card modem, or the like for transporting data signals, voice signals, video signals, and the like. The fleet MDS 611a-611n compiles latitude and longitude position data from GPS sensors in a continuous manner and the like. Latitude and longitude position data are periodically transmitted at for example 5 minute increments or less to the mobile information center 802 block. The automatic vehicle location system provides for vehicle tracking by way of selected elements from the fleet mobile units, the mobile information center, and other elements. The automatic vehicle system includes elements such as a UNIX DBFUPDATE server 618, a UNIX DBREQSRV server 624, a data acquisition and messaging interchange module (MIP or messaging interchange module) 801, a data acquisition and messaging interchange module and receive module (MIP_RCV) 808, a monitoring process (MONDBF) 813, and others. Also shown are a shared memory 815, a mobile information center (MIC) disk buffer 807, and other elements. Of course other types of servers and elements may be used depending upon the particular application.

In the automatic vehicle location system, the UNIX DBFUPDATE server 618 momtors the shared memory 815 via line represented as 827 for any new reports or updated reports. The UNIX DBFUPDATE server 618 transfers the reports from the shared memory 815 to the mobile information center disk buffer 807 in a periodic manner via line represented as 825. The reports include information such as a time, a vehicle location, a driver name, a vehicle number, a vehicle speed, a vehicle status, and others. The UNIX DBFUPDATE server 618 uses memory and file locking protocols to access data from the shared memory 614. The UNIX DBFUPDATE server 618 process runs continuously, transferring reports in data form from the shared memory 815 to the mobile information center disk buffer 807. The shared memorv 815 can be a dynamic random access memory which can store up to about 50 or less reports per vehicle. Accordingly, it is important that the data in shared memory 815 be transferred to the mobile information center disk buffer 807 before the shared memory fills up with data. For example, vehicles reporting every minute fill up the shared memory 815 in about 50 minutes or less, and the new data coming into the shared memory can be overwritten. Of course, as dynamic random access memory capacity increases, more reports can be stored in the shared memory 815.

The UNIX DBRQSRV 624 server processes requests from login to logoff from the automatic vehicle location subsystem, and in particular a workstation. The workstation can be any suitable workstation of sufficient memory and processing means to handle data as described herein. The UNIX DBRQSRV 624 server also forks out a copy of its process upon connection on a socket. The fork out process verifies login information and processes requests from each workstation. The UNIX DBRQSRV 624 server also provides for a different (or second) commumcation channel w ith the use of a computer aided dispatch (CAD-type) messages as will be described in more detail below. Other functions of the UNIX DBRQSRV were described in the previous embodiment.

An interface between fleet mobile units 610 and mobile information center disk buffer 807 is provided by the messaging interchange process (MIP) 801. In particular, vehicle position reports from the mobile units 610 are transferred to the snared memory 614 via line represented as 829. The UNIX DBFUPDATE server transfers the vehicle position reports into the mobile information center disk buffer 807 via line represented as 827. As previously noted, the vehicle position reports include at least latitude and longitude information at a selected time and the like.

The MIP.RCV process 808 assistants (or is an assistant) the messaging interchange process 801. In particular, the MIP.RCV process 808 receives data from the messaging interchange process 801 and processes the data to determine a forwarding path. For example, some data are sent back to the messaging interchange module 801 for forwarding to the fleet mobile unit(s) 610, and other data go into the shared memory 815 and/or the two way messaging disk buffer 805, among other elements. Of course, the MIP.RCV may also forward data to other elements of the mobile information center, mobile tracking station, and the like.

The automatic vehicle location system also includes the monitoring process such as the MONDBF 813 and the like. The MONDBF 813 is often dormant but periodically wakes up and checks the DBFUPDATE process 618 via line represented as 831. If the DBFUPDATE process 618 is not nning, the MONDBF 813 outputs a warning message to an output device such as a screen or a printer, typically in standard UNIX shell script language or the like. The warning message alerts a user and appropriate action such as maintenance of the system or the like occurs. Of course, other forms of monitoring processes and/or systems may also be used depending upon the particular application. The two-way messaging system provides for two-way messaging between the fleet mobile units 610 and, for example, a dispatcher or the like. The two-way messaging system is a "dumb" messaging system for communicating voice, data, video, and the like information between the fleet mobile umts and the dispatcher and the like. The two-way messaging system includes elements such as a mobile information center two-way messaging module (MIC.TWM) 803, a UNIX server 809, a CANPEND process 817, a CLRTWMDB process 819, and others.

A message such as a two-way message and the like from one of the fleet mobile units goes to the MIC_TWM process from the message interchange module 801 via line represented as 833. A message from a dispatcher goes to the fleet mobile units through the MIC.TWM module (or process) 803 through the messaging interchange module 801 via lines represented as 841 and 833. The MIC TWM module provides an interface between the dispatcher and the fleet mobile units 610 for two-way messaging. The MIC.TWM module also has write access to a two- way messaging (TWM) database 805 and other memory devices via line represented as 835. The MIC_.TWM module has read access to the two-way messaging database 805 and other memory devices via line represented as 835. The MIC.TWM module also records in-coming (fleet mobile units to mobile information center) and outgoing (mobile information center to fleet mobile units) messages in the two-way messaging disk buffer or the like. The MIC.TWM module creates queues for communication between the messaging interchange 801 module, the UNIX DBTWMSRV server 809, and any other two-way messaging module, and is often started first in the two-way messaging system.

The CANPEND module 817 cancels pending messages via line represented as 839. Pending messages may be defined as messages sent to vehicles that are turned "off" or messages that need "acknowledgment" which are queued up as "pending" until they are delivered or acknowledged. The CANPEND module 817 reduces the likelihood of messages being piled up or the like. The CANPEND module 817 is preferably activated periodically to automatically cancel pending messages and the like. The cancelled messages are stored in the TWM disk buffer 805, and can be viewed via a HISTORY.DATA option, but the status is preferably displayed as "cancelled" in a selected display device.

The CLRTWMDB module (or process) 819 clears the two-way messaging disk buffer of incomplete message transactions in the event that the messaging interchange process 810 or the MIP.RCV 808 process is restarted. The CLRTWMDB module 819 clears status prompts such as message sent or message fail and other types of status prompts from the two-way messaging disk buffer, and leaves the messages as pending. The CLRTWMDB process 819 is often executed before the messaging interchange module process, but can also be executed at other times.

The computer aided (CAD) dispatch process provides dispatching for the fleet mobile units from the dispatch office. The computer aided dispatch process includes servers 809 such as a MICDSP server, a UNIX SF.DSPSRV server, a SFDSP server, and others. The computer aided dispatch also includes a system 811 (or module). The system or module can be any suitable computer aided dispatch software and hardware combination or the like.

The MICDSP server defines an interface to the CAD process 811 and other system elements such as the mobile tracking station 626, the fleet mobile units 610, and the like. The MICDSP server translates data coming from the CAD system 811 via line represented as 843 and formats the data into the mobile information center system specifications or the like. The MICDSP server passes data to the SF DSPSRV process, a UNIX socket level interface process or the like.

The SF.DSPSRV server provides an interface between the MICDSP server and the SFDSP server. The SF_.DSPSRV server deciphers different types of CAD messages and routes them to either the SFDSP or DBREQSRV servers.

Messages from the fleet mobile units are sent to SFDSP server, while display and driver status type of messages are sent to the MTS station via the DBRQSRV process.

The SFDSP module provides a connection to the two-way messaging disk buffer for a store-n-forward mechanism. The SFDSP provides socket connection to the DBTWMSRV process and sends CAD messages via the two-way messaging disk buffer to the fleet mobile units. Statuses are returned to the CAD system by the fleet mobile data units via the SFDSP process. The SFDSP process also reads the SUPERUSR account information of the fleet mobile units at start-up time via a login packet transaction.

The present fleet management system can also be any of those described in U.S. Serial No. 08/706,211 (15517-000111), commonly assigned, and also incorporated by reference. Additionally, the present fleet management system can also be a variety of others. Furthermore, the various functions of a fleet management system can be implemented in hardware or software or a combination of hardware and software. Accordingly, the descriptions above can be further combined in the form of software, as well as combined in hardware. These descriptions should not be limited with respect to the claims defined herein.

MDS Hardware Description

In a preferred embodiment, Fig. 5 shows a simplified overall system 110 in an information management system, such as a fleet management system, according to an embodiment of the present invention. This diagram is merely an illustration and should not limit the scope of the claims herein. One of ordinary skill in the art would recognize other variations, alternatives, and modifications. System 110 includes a mobile information center (MIC), or base station, 112 that interacts with a mobile data suite (MDS) 114. The MIC may include a system, such as a software system, to manage several MDS users to efficiently control fleet use. As merely an example, U.S. Serial No.08/706,211, commonly assigned, describes a MIC according to the present invention. This application is incorporated by reference herein for all purposes. Of course, other types of systems which have similar functionality as the MIC described herein can also be used.

As shown, the MDS is an integrated module including a mobile control unit (MCU) 116 and a mobile data terminal (MDT) 118. In an embodiment, the MDS is an on-board module, adapted to fit conveniently in a fleet vehicle such as a car, van, or truck. Preferably, the MDS is easily portable, fitting in a carrying case no bigger than approximately 18 " x 12 " x 10 " and weighing approximately 10 pounds or less. This portability allows a user to remove the MDS from the vehicle for safe storage or for convenient maintenance away from the confines of the vehicle. In an embodiment, the MDT may act as an interface between the MCU and the user for receiving and displaying information.

Preferably, the MCU includes a global positioning system (GPS) 120, a microprocessor unit 122 (e.g., a microprocessor board, a microcomputer, a micro-controller, a programmable controller), and a transmitter/receiver (T/R) unit 124. The GPS allows monitoring of positioning-related information, e.g., latitude and longitude. Positioning data enters the GPS via a GPS antenna 126. The GPS antenna may be mounted on the exterior of the vehicle, but is not limited to this location. This may improve reception of the antenna while reducing space consumed by the system inside the vehicle. A magnetic base may be used to mount the antenna that will allow a user to quickly and easily remove the antenna for storage, to improve reception, or for other purposes. From the positioning data, the GPS can determine the current or past location of the MCU based on information received from global positioning satellites. The GPS, the microprocessor unit, or the MDT (including MDT software) either alone or in combination, may use the information received by the GPS to determine information related to system management such as the vehicle's speed and heading. Alternatively, equipment at the MIC or elsewhere in the MCU, such as in the microprocessor unit, may determine this system management information. In an embodiment, the GPS is a Trimble OEM GPS receiver card made by Trimble Navigation, although other GPS systems can be used.

Any form of positioning system capable of determining the location of the MCU could replace the GPS. For example, a system using information from local position detectors instead of global positioning satellites could be used. The GPS is generally not required and may be omitted from the MCU.

In particular, not using a GPS may reduce the size, weight, complexity, initial cost, and maintenance expense of the MCU. Eliminating the GPS may be desirable for applications when system size and weight are at a premium such as for a bicycle messenger. In an embodiment, the MCU T/R receives data from, and transfers data to, the MIC via an MCU T/R antenna 128a. The MIC receives data from, and transmits data to, the MCU via a MIC antenna 128b (the data transfer represented by a double-ended arrow). Data from the microprocessor or GPS may be sent to the MIC or data from the MIC may be received and transferred to the GPS or microprocessor as needed by the MCU T/R. The MCU T/R may process received data as necessary to be in a form compatible with its destination. The MCU T/R is preferably a radio T/R, such as a radio frequency radio modem, due to cost and maintenance advantages. For example, the MCU T/R may be a RAM compatible Mobitek Modem made by Mobitek. Other forms of T/R units, however, may be used depending upon the application. The MCU T/R antenna, similar to the GPS antenna, may have a magnetic base, or be otherwise adapted, to assist mounting the antenna on the exterior of the fleet vehicle.

To reduce interference, the GPS antenna and the MCU T/R antenna may be mounted at least about 12 inches apart.

In an embodiment, the microprocessor unit may act as an interface unit in the MDS. For example, the microprocessor may provide an interface between the MCU T/R and the MDT, the MCU T/R and the GPS, or the GPS and the MDT. Included in the microprocessor unit are a memory 130 and a microprocessor 132. The memory may, for example, store messages for the user of the MDS. These messages may come from, for example, the MIC, the GPS, or the user. Messages may be categorized into groups for convenience such as received but not yet read, received and previously read, and sent. The microprocessor can access desired portions of the memory for data insertion or retrieval. The microprocessor may also process data from the memory, the MIC, the GPS, or the MDT before transferring the data to the memory, the MIC, the GPS, or the MDT. Examples of such processing may include determining speed and heading information based upon positioning data. In an embodiment of the present invention, the MDS architecture includes the MDT, MCU, GPS, microprocessor unit, and MCU T/R. The microprocessor unit may act as the central controller of the MDS, directing information flow between the components and storing information as necessary. The GPS receives information through its antenna and the microprocessor unit may store this data and/or direct it to the MCU T/R for transmission to the MIC or to the MDT for user viewing. Information from the MDT may also pass to the MCU T/R and/or be stored in memory under the direction of the microprocessor unit. The MCU T/R may then transmit the data to the MIC. The MCU T/R may also receive information from the MIC which the microprocessor unit may then direct into memory and/or to the MDT.

A power cable 134 may connect the MCU to an external power supply. The external power supply may be the same power supply used by the vehicle. For example, the power cable may have a connector (not shown) that fits into a cigarette lighter socket of the vehicle. The MCU would then use the electrical energy from the vehicle such as a 12-volt battery. Using an external power supply could help reduce the size, weight, and cost of the MDS. Alternatively, the MCU may have an internal power supply 136 in addition to, or in lieu of, the external power supply. Having an internal power supply would allow the MDS to operate independently of an external power supply. The user could, for example, use the MDS in places which would be inaccessible if the MCU was dependent upon a vehicle power supply. Also, having an internal power supply would allow the user to use the MDS as needed in case of a failure of the vehicle's power supply. For example, the user could relay information to the MIC if the user is in an accident that causes the battery to stop functioning, or during a malfunction which prevents energy from reaching the power cable.

The MDS may also include a printer 140. Having a printer would, for example, allow the user to make a hard copy of data received from the MIC, transmitted to the MIC, or entered into the MDT even if not transmitted to the MIC. The printer may also be utilized to provide a hard copy of other information such as the configuration of the MDS, GPS, MDT, or the MCU.

Fig. 6 illustrates an exemplary front view diagram of an MDT 200 according to an embodiment of the present invention. This diagram is merely an illustration and should not limit the scope of the claims herein. One of ordinary skill in the art would recognize other variations, alternatives, and modifications. Data from the GPS and MIC may be illustrated on a display 202 of the MDT. The display permits the user to visually inspect the displayed data and act accordingly. The display can be any suitable output device such as a liquid crystal display or an active matrix liquid crystal display, as well as other types of displays, e.g., laser, diodes. The display should have a sufficient region for providing information (e.g., text, numbers) in an easy to read manner to a user. Additionally, the display can work under limited or low power conditions in some embodiments. The display also can be employed as an input device such as a touch sensitive screen used in, for example, a product called PalmPilot™ made by 3Com™ Corporation of California. Preferably, the display is also resistant to extreme environmental temperature ranges (e.g., freezing) and is shock resistant. Furthermore, the display is sealed or isolated from moisture and particulates such as "dust" or contamination. These and other features will become more apparent throughout the present specification and more particularly below. Additionally, although the above display is configured in the MDT, the invention also has other applications. For example, the display can be detached from the MDT. The display can be loosely coupled to the MDT. Alternatively, the display can be integrated into another device such as a watch, a helmet, glasses, clipboard, and the like.

In an embodiment, information from the MIC such as changes in delivery or pick-up schedules, lunch break approvals, emergencies, traffic conditions, vehicle location, and personal messages may be displayed. Also, if the MDT is a pager, the user can receive business, personal, and other messages such as reminders, phone numbers, and emergencies. In an embodiment, the received data may include general information that may be broadcast to many users simultaneously, such as sports scores or other news. The display can also be coupled to another output device such as a beeper, a pager, electric shocker, or a vibrator to alert the user in a specific or selected situation such as an emergency.

In an embodiment, the MDT may also receive data from the user. In such an embodiment, the MDT may have a data entry portion 204. As shown in Fig. 6, the data entry area may be a keypad. Other types of data entry tools may be utilized including a flat-panel keypad, a recorder that receives and stores sounds such as speech, a voice recognition unit which could recognize speech and convert the speech into data indicative of the speech such as text data, a touch-sensitive display, a display area allowing the user to write or draw characters or symbols such as a signature (e.g., pen computing), a bar-code reader, or a scanner (e.g., an optical character recognition device). If the data entry area is one of the last two examples, the data entry portion may coincide with the display 202. Alternatively, if the data entry portion receives data through writing or drawing on a display, the MDT or MCU may include circuitry to recognize hand-writings or signatures. This ability, for example, could assist the user in determining whether the person signing for a package has the authority to do so. As shown in Fig. 6, the MDT may include a housing 206 adapted to fit in the user's hand, for example. Such a hand-held design permits the user to hold the MDT with one hand and enter data with the other hand. Alternatively, if the data entry portion receives audio input, the user may conveniently hold the MDT with one hand, enter data, and still have one hand free. Such an arrangement also permits a user with physical handicap to use the MDT more conveniently. The housing is preferably made of a suitable material to withstand environmental variations such as temperature and weather. Accordingly, it is desirable to have a housing that is resistant to moisture and particulate contamination. This feature can be achieved by way of seals such as o-type rings and rubber gaskets, which seal one member of the housing with another member of the housing.

Furthermore, the housing can be sufficiently rigid to withstand mechanical shock, although other embodiments may require a flexible or "soft" housing for ergonomic purposes. In these embodiments, the housing can have a coating made of a soft or flexible synthetic material, which tends to be easier to handle with "hot" and "sweaty" palms, for example. Preferably, the housing is also made of an isolating or shielding material which can electrically isolate the internal electronics from external transmission lines that can lead to "noise" or multi-path influences. The housing is also chemically resistant and inert to isolate the internal components from chemical influences. Although some desirable features have been described, numerous other features can be implemented into the present housing design.

Additionally, the MDT is detachable from the MCU in some embodiments. A detachable design allows the user to use the MDT away from the MCU. Thus, the user may not need to carry the whole MCU in order to use the system. Furthermore, an internal MDT power supply 208 would permit the user to use the MDT away from the MCU. The MDT power supply may also be mounted externally, for example, on a belt clip. Such a configuration may provide a lighter MDT which may be carried by hand for a longer period to distance. The MDT is generally less than 5 pounds, less than 2.5 pounds, or less than 1 pound to merely ounces in preferred embodiments.

If detachable, the MDT can be able to transfer data to, and receive data from, the MCU when connected to the MCU. In this embodiment, the user enters data while away from the MCU and later connects the MDT to the MCU. Once connected, the MDT and MCU can transfer data to each other. This configuration obviates driving or even having an antenna, and associated circuitry, in the MDT for receiving and transferring data while detached from the MCU. Alternatively, the MDT may receive, transmit, or transmit and receive data while detached from the MCU. In such an embodiment, the MDT may have an MDT antenna 210 and associated circuitry, which is shown in reference to Fig. 2 A. The MDT antenna may be internal, as shown, or external. The MDT can transfer data back and forth with the MCU, MDS, and MIC via the MDT antenna. To reduce the circuitry needed and/or power consumed, the MDT may be restricted to receiving data only (such as if the MDT is a pager), or transmitting data only. Depending upon the frequency chosen for remote data transfer between the MDT and MCU, the MCU may require an additional MCU/MDT antenna 138.

Given the various embodiments described above, the MDT may take several forms. In an embodiment, the MDT can be similar to a portable data terminal (PDT) 3100 made by Symbol Technologies, Inc. Alternatively, the MDT may be an electronic personal organizer such as the PalmPilot™. The MDT may also include, or simply be, a printer.

Fig. 6 A is a simplified block diagram of the MDT shown above. The simplified diagram includes, among other elements, a GPS 251, a transmitter/receiver unit 253, a microprocessor unit 254, a power supply 263, a printer driver 261, a display driver 259, which are coupled to each other by way of a common bus(es) 257. The GPS determines positioning information, which can be displayed by way of the display through the display driver or which can be sent to the MIC through the transmitter/receiver unit. Additional output of information can be directed to an optional printer by way of the printer driver. The power supply provides energy in the form of electrical voltage and current to elements of the MDT. Preferably, the power supply is a rechargeable battery such as "NiCad" or the like. Alternatively, low voltage applications can be driven by a solar power supply unit, which can also be used to recharge the battery in some embodiments. Antenna 210 is coupled to the transmitter/ receiver. In an embodiment, the antenna is capable of communicating through radio frequency radio signals. The location and type of the antenna, however, is merely exemplary and one of ordinary skill in the art would recognize other variations, alternatives, and modifications. For example the antenna may be internal or external to the device, or may utilize other types of signals to communicate, such as infra red. Overall functionality of the MDT is often overseen using the microprocessor based unit in the present embodiment.

Fig. 7 shows an example of a simplified method 300 according to an embodiment of the present invention using a system such as that shown in Figs. 1 and 2. This method is exemplary only and does not limit the claims to this embodiment. The order in which the steps appear in the figure are largely arbitrary and may appear in many orders different from the specific order shown in Fig. 7.

The method starts at step 302 and proceeds to step 304, when user data is entered into the MDT. This data entry may take any of numerous forms depending on the particular MDT used. For example, the user may enter data by pressing keys on a keypad, touching portions of a touch screen, scanning a document, or reading a bar code.

At step 306, the user data is transferred from the MDT to the MCU. Again, this data transfer may take any of numerous forms. For example, the data transfer may be accomplished via the MDT antenna, or by coupling the MDT and MCU using a cable, or by positioning the MDT into a cradle in the MCU having MCU contacts adapted to couple to corresponding MDT contacts.

At steps 308 and 310, the MDS receives positioning data via the GPS antenna and MIC data via the T/R antenna. As described above, the positioning data could also come from local position detectors or other positioning systems. The GPS and T/R antennas may be specifically designed or selected to reduce the power needed to provide adequate data transfer between the MCU and the positioning system or the MIC.

In step 312, the MCU processes MCU data (including, for example, the user data, positioning data, and MIC data) as needed. Such processing may include manipulating the user data, positioning data, and MIC data and converting them into formats compatible with the MIC or the MDT. For example, the positioning data may require manipulation in order to display this information on the MDT. Also, this step may include the processing needed to determine information such as vehicle speed and heading. In step 314, the MCU data is transferred to the MIC. All, selected part, or none of the information available for transfer may be transferred. This data transfer may typically involve sending the data via the T/R antenna to a corresponding antenna at the MIC.

In step 316, the MCU transfers data to the MDT. All, selected part, or none of the information available for transfer may be transferred. This data transfer may occur in the same manner as described above with respect to transferring data from the MDT to the MCU. The MCU may be configured to transfer data when a communication link between the MCU and the MDT exists, or periodically. For example, the MCU may accumulate data for transfer to the MDT for a predetermined time period, then transfer some part of the accumulated data at the end of the time period. Alternatively, the MCU may transfer data to the MDT in real-time, as soon as data is ready for transfer.

In step 318, the MCU data is displayed on the MDT display. The displayed data may include the MCU data transferred from the MCU, the user data entered into the MDT, and/or predetermined data not entered by the user or received from the MCU. An example of the predetermined data would be prompts provided to the user to request data input, text or symbols displayed near the user data, or MCU data that may provide an indication of the significance, or meaning, of the displayed user or MCU data. Finally, the process terminates at step 320. While the above method has been described using a specific order, many combinations and permutations of the order presented are possible. The steps may appear in almost any order within a few logical guidelines. These guidelines may merely ask that data exists before an attempt to transfer or process it. For example, step 306 of transferring user data from the MDT to the MCU may follow step 304 at a later time. Likewise, step 312 of processing MCU data may follow any combination of the steps that provide data to the MCU, such as steps 306 through 310. Similarly, steps 314 and 316 of transferring MCU data to the MIC and the MDT may follow any combination of the steps that provide data to the MCU. And, step 318 of displaying MCU data on the MDT display may follow the step of transferring MCU data to the MDT at a later time. Additions and omissions to the steps of Fig. 7 are also acceptable. For example, the MCU need not receive MIC data from the MIC. As a further example, the MCU may not even have GPS (or other positioning system) capabilities and, hence, the method need not include receiving positioning data. Other deletions are also possible. Moreover, the method may include more steps or sub-steps including transferring data to a RAM network that may provide coverage nationwide, globally, and beyond.

Software Description

In an embodiment, the present invention includes software to control the user interface and data processing operations. The software may partly or completely reside in the MCU or MIC, but preferably resides in the MDT. Thus, while the software is sometimes referred to below as the MDT software, this label refers to an, but not the only, possible embodiment of the present invention. In some embodiments, the MDT may encased in a product manufactured by Symbol commonly known as a Symbol terminal, such as Series 3100, that has its own software. The software described below may be an addition, a modification, or a replacement of the software supplied with the Symbol terminal. The software of the present invention may control receipt, processing, and transmission of data between the MCU, MDT, MIC, user, etc.

Moreover, the software described below, in accordance with an embodiment of the present invention, may support several configurations of the MCU. Moreover, one configuration does not necessarily include more or less hardware than another configuration. For example, an external modem configuration may support a Symbol Series 3100 terminal, an external RAM-compatible Mobitek Modem (sometimes referred to as a Mobidem), and a Motorola 505sd modem. This configuration may, for example, not support GPS functionality.

Similarly, a black box configuration may support a Symbol Series 3100 terminal and a black box including a RAM-compatible Mobitek Modem module, and a Trimble OEM GPS receiver card. This configuration, for example, could support, among others, modem communications and GPS information receipt, processing, and transmission.

The software preferably runs on the MDT, interfaces with the external Mobitek modem or a black box including the GPS and the MCU T/R. Also, the MDT software preferably includes a traffic manager and a report scheduler.

Preferably, the MDT software is organized in a modular fashion. This arrangement may provide compartmentalized functionality to assist with creation and modification of the software code and debugging of problems. For example, an engine module may communicate with the GPS. This module could prepare data for transmission to the GPS and process data received from the GPS. The data transmitted and received may or may not pass through or be stored in the microprocessor unit. In some embodiments, the engine module supports Magnavox 4200 and engine receivers used in the GPS. In an embodiment, a hardware initialization module may provide initialization and hardware interface functions for the MDS. In this respect, the MDT may initialize the entire MDS by transmitting initialization parameters to the MCU to initialize the MCU T/R, the GPS, and the microprocessor unit. After initialization, this module can provide interface functions among the various MDS components. In a preferred embodiment, this module may also provide support for an event timer facility of the MDS. The event timer facility could, for example, allow users to have a number of timers based on the Symbol terminal system timer.

In another embodiment, an MDT module may provide MDT-specific functions. For example, the MDT module may support data entry forms (e.g., a package delivery form or a hospital admittance form) that are larger than the physical size of the screen by allowing scrolling of the forms. In addition, a number of routines could support automatic list building by selecting and inserting an identification number in appropriate form field. The MDT module may provide a recall of information that is the same from job to job, such as customer-related information, by having the user provide the identification number. This would save the user time and effort in entering such information. For example, the customer's address, phone number, billing, and special instruction information may be recalled based upon entry of the customer's name or other identification tools such as the identification number.

Other features may include using a Menus module to support scrolling menus, time and distance position reporting, data compression, and blinking overlaid indicators for canceled, re-transmitted, and changed jobs. The user may select items in each menu by scrolling or entering an associated number. To exit from any menu, the user may press a clear key, etc. Some examples of the menu operations and options are discussed in more detail below.

In a preferred embodiment, an MDT utility module may provide utilities for an MDT interface. The MDT interface may include a display screen upon which data may be displayed prompting the user for information or providing the user with information. To assist the user with the MDT interface, the MDT utility module may provide processes for, among other things, creating menus, positioning a cursor in the menus, and checking for input from the user. Fig. 8 shows a sample startup activation screen. This screen displays general information and, for example, prompts the user to press the acknowledge key to activate the system. In an embodiment, a timer requires the user to press the enter key within a predetermined time (e.g., five seconds) or the MDT would shut down, requiring reactivation by the user before use. Alternatively, the startup screen may ask for the user to enter a security code. This will, for example, only provide authorized personnel access to the MDT. Other methods of startup activation may include finger-print recognition, retina recognition, etc.

Fig. 9 shows a sample warning screen displayed by the MDT at least for safety purposes. This or other warning screens may be displayed for different purposes. For example, the screen may display contact information in case the MDT is lost by the rightful owner. Fig. 10 shows a welcome screen that the MDT may display. Information regarding matters including company name, version of the software, copyright, patent, trademark, or other intellectual property protection may be displayed on this screen. This screen may also display contact information in case the MDT is lost by the rightful owner.

Fig. 11 shows an primary menu 7000 of the MDT with an upper portion 7020 including status indicators, and the current date and time, and a lower portion 7040 providing information about user selectable functions and the corresponding keys. The MDT status indicators shown in Fig. 11 provide information about the current operating status of the MDT. A NEW indicator 7060 flashes when new messages are received. An indicator 7070 displays the number of new messages. A LINK indicator 7080 informs the user as to whether the network link is UP or DOWN. In an embodiment, the MDS communicates with the MIC only if the link is UP. A BATT indicator (not shown) may replace the LINK indicator when the MDT is disconnected from the MCU. The BATT indicator may provide general energy status of a battery in the MDT by, for example, indicating that the battery is either GOOD, LOW, or DEAD. Any of the MDT indicators may flash to indicate an abnormal status. A number 7090 next to a pending indicator 7100 displays the number of messages currently awaiting transmission. A number 7110 next to a saved indicator 7120 displays how many messages have been saved. A GPS indicator 7140 provides information as to the age of GPS data and current GPS navigation capabilities. An "UNK" status may designate an unknown GPS status. Similarly, "N/A" may indicate that GPS information is unavailable or "OLD" may indicate that the most recent GPS data is older than 10 seconds. "NV2" may indicate that only 2-D navigation is available (i.e., only 3 satellites are visible) while "NV3" may indicate that 3-D navigation is available (i.e., more than 4 satellites are visible).

A signal-strength indicator 7160 may indicate the signal strength of the modem. The signal-strength indicator may display up to six bars (e.g., right-facing arrowheads in Fig. 1 1). Three or more bars may indicate very strong communication signal, providing a very good coverage area. The lower portion of the primary menu displays several options available to the user by pressing various keys. For example, pressing the FI key may display a help description. Pressing the PREV or NEXT keys may then step through various help pages. To return to the primary menu, the user can press the MENU key. Pressing F2 from the primary menu may allow the user to view sent messages. In an embodiment, the MDT retains the four most recently sent messages. Pressing F2 from the primary menu may cause the MDT to display a list of sent messages with corresponding current statuses such as delivered or pending and the time each was sent. Using the PREV/up-arrow and NEXT/down-arrow keys may step through these messages. An extended beep sounds may warn the user when no further scrolling is possible.

In an embodiment, to view saved messages the user may press F3 from the menu 7000. The MDT then displays the latest saved message which could be scrollable as discussed above. Moreover, the user may delete sent and saved messages by navigating through the appropriate screens. Before deleting any messages, the MDT may confirm the deletion action.

Pressing F4 from the menu 7000 may provide access to new messages. For example, if the NEW indicator in the primary menu is blinking, the MDT may have one or more new messages. Pressing F4 may cause the MDT to display the new messages, for example, with the newest message displayed first. Once the user reaches the new messages, the user may scroll through the various new messages.

Figs. 12A and 12B illustrate a simplified FORMS MENU 8000. As shown, various options may be displayed on the FORMS MENU. This menu may also be scrollable to ensure all related information are displayed in the same menu. For example, Figs. 12A and 12B may be 2 of may available screens within the same menu 8000. An area 8050 may show an order of the present screen amongst the available screens within the same menu 8000. The user may select a desired form by either highlighting the form's title using an up-arrow or a down-arrow key and pressing an enter key. Alternatively, numbers associated with each item may be entered. Preferably, each form displayed in the FORMS MENU may be designed to ensure the user spends less time in preparing reoccurring information. For example, O 99/45519

34 form 810 may enable the user to enter orders by utilizing previously saved information in order to minimize data entry time and possible errors. Once a form is filled, the user may send the currently-selected form to, for example, the MIC.

Figs. 13 A and 13B illustrates an exemplary STATUS MENU 9000. Again, the user may select a desired form by using the up-arrow and down-arrow keys and the enter key, or by entering the appropriate code. The selected status screen is then displayed. If a different status is desired, the user may repeat the process, or may use the PREV and NEXT keys to cycle ttirough the various status codes. Once the desired status is displayed, the user may send the status to, for example, the MIC. The user may also exit the status menu.

In an embodiment, the MDT keypad performs several generic operations according to the keys pressed. Table 1 lists some generic operations according to key stroke or combination of strokes that initiate corresponding functions.

TABLE 1

9/45519

35

Fig_. 14 shows a secondary menu of the MDT indicating various options for the user_. In an embodiment, pressing a next key from the primary menu causes the MDT to display this screen. In the embodiment of Fig. 14, once at the secondary menu, the user may press any key (except FI - F4) to go back to the primary menu.

Moreover, pressing FI from the secondary menu may provide the user with time, speed, and direction information. This may be accomplished by displaying GPS information, if available_. A time-speed-direction screen may show the current time, the speed of the vehicle, and the direction it is heading such as north, east, etc. It also may display how long the system has been turned on. In this embodiment, pressing any key returns the user to the secondary menu.

To turn OFF the MDT the user can select the F2 key from the secondary menu If connected to the MCU, shutting down the MDT may also shut down the MCU a ter the MCU sends a message to the MIC (which could take as long as five minutes or more if communication coverage is poor). It may take a few seconds to a minute before the MDT actually powers down.

Fig. 15 is an exemplary illustration of a shutdown screen according to an embodiment of the present invention. This screen may inform the user that the user will not receive messages while the MDT is shut down and prompts the user to proceed with shut down (ACK) or cancel the shut down request (CLR). Once the system has been shut down, the user may unplug the appropriate cables and remove the system from the vehicle for safe storage. The MDT may retain all data in the memory.

Returning to Fig. 14, pressing the F3 key may permit the user to enter a field-service screen. Access to this screen, however, may require a password and, preferably, only field service personnel have access to valid passwords or security codes.

In the embodiment of Fig. 14, the user may also view the MDT system application version number by pressing F4. From the system version screen, pressing any key may return the user to the secondary menu. The MDS may be configured to save the last 40 job ID's (tag or identification numbers) to make it easier to enter them into an outgoing form rather than re-entering them using the alpha/numeric keys or other means such as a voice recognition, character recognition, etc. When the cursor is placed in the job ID field, the user may press the up-arrow or down-arrow keys to scroll through the list of the latest JOB IDs. Once the desired job ID is displayed in this field, the user can proceed to the next field using the ENTER key. Some IDs may be displayed in reverse order indicating that a "pickup form" was sent to the host.

Jobs in the MDT may be canceled by the dispatcher, retransmitted, or changed. In each of these instances, the MDT may display these conditions in a unique way. If a job is canceled, the MDT displays the job to be canceled with a big flashing "X" overlaying the job. The MDT automatically removes the job once the user acknowledges the message. If the job is retransmitted as is, the MDT displays the job with a big flashing "R." Finally, if the job is retransmitted with some changes in it, the MDT may detect that the job has changed and display the job with a big flashing "C." The MDT may display these screens from either the primary or secondary menus. The retransmitted and changed jobs may replace the previous copies of the job. At any given time, the MDT may have only one copy of a job.

The MDT may also display various error messages to assist the user.

Examples of error messages may include: invalid form number; invalid status; invalid queued message; could not translate incoming message; error saving data ... press any key to continue; error retrieving data ... press any key to continue; error setting default lat/long; RCV queue full ... incoming message was lost ... please delete SAVED/SENT messages or process NEW messages; out of memory ... incoming message was lost... please delete SAVED/SENT messages or process NEW messages; out of memory ... message was not sent ... please delete SAVED/SENT messages or process NEW messages; delete a message from the save queue before saving this message; etc.

Furthermore, the MDT may display various warning messages to assist the user. Examples of warning messages may include: Communications Out-Of-Range

... Press ACK to continue; GPS not available; Mobidem information not available; Running low on memory ... Please delete SAVED/SENT messages or Process NEW messages; Terminal cable out... Connect cable and press ACK to send shutdown message; etc.

In an embodiment, the MDT may be restarted by a warm boot. For example, if the MDT application appears to be frozen (e.g., text on the display does not change even after trying to go to a different menu) for any reason and nothing revives it, then the user may want to warm boot the MDT. To warm boot the MDT, the user may press the PWR key for about 30 seconds to shut off the MDT. Then the user may press the 4 and 5 keys simultaneously followed by pressing the PWR key twice. turn off in 15 seconds of no activitv.

Trouble Shooting Guide

Table 2 indicates various possible trouble conditions and possible solutions to recover from them according to an embodiment of the present invention. TABLE 2

Although the above description has been described in terms of hardware and software, the present invention is not limited to the specific hardware and software described. For example, the functionality described herein can be further combined in terms of hardware or further combined in terms of software. The hardware can also be separated or combined with other software. The software can also be separated from the hardware. Furthermore, the functionality can all be stored in the form of electronic data on an integrated circuit, for example. The integrated circuit can include, among others, DRAM, SRAM, FRAM, and Flash Memory Cells, as well as other integrated circuit devices in the form of "chips" or "cards. " Accordingly, the present specification should not be construed as limiting the scope of the language of the claims herein. Additionally, although embodiments of the present invention are fully described above, various modifications, alternate constructions, and equivalents will be obvious to those with skill in the art. Thus, the scope of the present invention is limited solely by the appended claims and their full scope of equivalents.

Claims

WHAT IS CLAIMED IS:

1. A fleet management system comprising: a computer aided dispatch system for tracking a plurality of mobile units; an interface unit operably coupled to said computer aided dispatch system, said interface unit including a processor and a positioning system coupled to a first antenna and to the processor; and a remote data terminal, electrically coupled to the interface unit during at least a first time period, capable of data transfers with the interface unit during the first time period and with a user.

2. The system of claim 1 wherein the processor is coupled to a second antenna and the remote data terminal includes a third antenna, and wherein the remote data terminal and the interface unit are capable of data transfer during the first time period using the second and third antennas.

3. The system of claim 1 wherein the interface unit and the remote data terminal are adapted to physically couple during the first time period.

4. The system of claim 1 further comprising a system power supply wherein the processing system is capable of operation independent of an external power supply.

5. The system of claim 1 wherein the interface unit is adapted to removably couple to an external power supply.

6. The system of claim 1 wherein the interface unit is electrically coupled to an external power supply of a vehicle.

7. The system of claims 1 wherein the remote data terminal includes a data terminal power supply.

8. The system of claims 1 wherein the remote data terminal includes a keypad.

9. The system of claims 2 wherein the first and second antennas are coupled to the interface unit with first and second cables and coupled to first and second magnetic bases respectively such that the first and second antennas may be removably mounted on a metallic surface.

10. The system of claim 1 wherein the positioning system is a global positioning system.

11. The system of claim 1 wherein the remote data terminal is adapted to be hand-held.

12. In a fleet management system, a method of processing data comprising steps of: receiving user data from a user interface of a control unit; receiving positioning data from a positioning system of the control unit; and transmitting the user data and positioning data, using a second antenna of the control unit, to a base station.

13. The method of claim 12 wherein the step of receiving user data comprises: entering the user data into a remote data entry terminal; and transferring the user data to the control unit.

14. The method of claim 13 wherein the entering step comprises actuating keys on a keypad.

15 The method of claim 13 wherein the entering step comprises scanning a bar code

16 The method of claim 13 wherein the entering step comprises scanning data

17 The method of claim 12 wherein the transmitting step comprises transmitting data to a RAM network

18 In a fleet management system, a method of processing data comprising steps of removably coupling a remote data terminal to a control unit that includes an antenna, receiving positioning data in the control unit from the antenna; transferring at least a portion of the received positioning data to the remote data terminal; and displaying data indicative of at least a portion of the positioning data on a display of the remote data terminal

19 In a fleet management system, a computer program product for use with a base station, a positioning system and a user interface, the computer program product comprising a computer-readable memory comprising: code that processes user data entered into the user interface; code that processes positioning data from the positioning system; and code that directs transmission of the processed user data and processed positioning data to the base station

20 The computer program product of claim 19 further comprising code that directs the user interface to prompt the user to enter the user data.

21. The computer program product of claim 19 further comprising code that directs the user interface to display the positioning data on a display screen of the user interface.

22. The computer program product of claim 19 wherein the code that processes the positioning data calculates a speed of the positioning system.

23. The computer program product of claim 19 wherein the code that processes the positioning data calculates a heading of the positioning system.

24. A fleet management system, said system comprising: a mobile data terminal unit comprising: a processor for processing user data; a display for displaying output data; a data entry tool for entering input data; a power source for operating the mobile data terminal unit; a mobile control unit removably coupled to the mobile data terminal and configured to transmit data between the mobile control unit and a base unit; and a computer-readable memory including: code that processes the input data; code that processes the output data; and code that directs transmission of the user data to a destination selected from a group consisting of the mobile control unit, the base unit and a mobile data suite.