Location aware wireless data gateway

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to systems and methods for monitoring remote and mobile business assets, by location, usage, activity, assignment, and so forth, and enabling data communication or messaging between the asset owner or user and the asset. More particularly, the invention relates to improved techniques for such monitoring, through devices carried by the asset and designed to detect and report indicia of the aspect of the asset to be monitored, and to improvements in the communication path such as wireless data networks between the owner or user and the asset-appended device, including a location aware wireless gateway.

2. Brief Review of the Prior Art

Businesses that operate fleets of vehicles, have a mobile workforce, have remote fixed assets, or rent mobile equipment have the difficult task of managing these assets or employees efficiently. Getting data from these assets that indicates what they are doing and where and when they are doing it, into applications that managers are using to run their businesses is of critical importance.

Voice radios or mobile telephones have been used for many years for communication with vehicle drivers and service technicians, but voice does not work for equipment and voice does not integrate automatically or reliably to other electronic information systems. Several wireless data networks or transport mechanisms are now available. These include: GRID DATA™ (trademark of Grid Data, Inc. for its goods and services employed in or employing wireless data networks, and which are the subject of a co-pending U.S. patent application), ARDIS® (trademark of American Mobile), cellular digital packet data (CDPD), code division multiple access (CDMA) and time division multiple access (TDMA), personal communications system (PCS), Mobitex® (trademark of Ericsson), Aeris® Microburst™ (trademarks of Aeris.net), Orbcomm® (trademark of Orbcomm Global, L.P.), and others. Each of these networks has different coverage areas, capacity, pricing, and usage schemes so that not any one network is optimal for all applications. For all of these networks, however, overall capacity (bandwidth) is increasing quickly and pricing is falling. A wireless network gateway makes connections to multiple wireless networks. Customers have one connection point to the gateway that routes messages through the wireless network using the most appropriate and cost effective method for the customers' businesses.

The Global Positioning System (GPS) makes determining accurate location of vehicles relatively easy and inexpensive to accomplish. One drawback of GPS based position determination is that coarse/acquisition (C/A) code typically has errors on the order of 100 meters when selective availability (SA) is on and requires augmentation with differential corrections to remove errors in the signal to an error level of typically less than 5 meters. Some wireless networks designed for vehicle location and telemetry purposes, such as the GRID DATA™ network, provide differential corrections automatically. Other networks make it more difficult and expensive, but over time may be cost effective. In the near future, the FAA Wide Area Augmentation System will be operational; most commercial GPS receivers will be able to automatically receive this differential augmentation signal.

A second drawback of GPS is the lack of signal availability when the satellites are obscured by foliage or structures. This requires GPS to be augmented by other sensors, such as dead reckoning inputs from a vehicle speed sensor, or from triangulation techniques from wireless network signals. The latter solution is attractive because it can work as a hand held unit away from a vehicle.

The ubiquity of the Internet makes it possible to transfer data between the enterprise customers and their mobile assets operating on wireless networks through a central wireless network gateway. As available wireless bandwidth is increasing, so is Internet bandwidth to the enterprise. High bandwidth Internet makes it possible to serve sophisticated business applications and to distribute large volumes of data to individual users in the enterprise from the wireless gateway. Serving of applications eliminates the up front cost of purchasing software and removes the software support tasks from the customer, and it enables easier support and upgrading by the service provider. The Internet allows access to data and applications from almost anywhere at any time.

The convergence of these three technological advances: low cost and expanding wireless data bandwidth, low cost GPS based location sensors, and expanding Internet availability and bandwidth, reduce the device and recurring air time costs to use location based data to manage remote assets. In order to effectively use any kind of data, applications that the business uses must be able to incorporate it and process it with other business information in meaningful ways. Data without applications is useless; therefore, common business applications such as work order management, scheduling and dispatching, inventory tracking, vehicle maintenance, and text messaging all need a common interface to receive asset location data. A standard interface and set of business rules is required to allow the wide variety of business applications to treat location information in a common way.

SUMMARY OF THE INVENTION

The current invention solves this problem by deploying special location aware business logic to the mobile devices and network operations center. Applications and data are provided to customers over the Internet from the network operations center. Text messaging and mapping is provided as a core functionality. Standard protocol interfaces are provided to the core location business logic and database as well as the mapping and messaging to enable other business applications to use the wireless networks and location information. One example of location aware business logic is the ability to send a location of interest to a mobile device. The mobile device then can report when it has arrived or left the location. The ability to send location information and receive status is extended to any application, such as dispatching, to enable it to track work order status. Interfaces to mapping functions allow the application to view and define locations of interest.

The invention enables business applications to become location aware, i.e., to use information about the location of assets, vehicles, and employees to enable the user of those applications to manage them more efficiently. The gateway system of the invention consists of wireless devices in vehicles, handheld units and other mobile assets of the business enterprise which is the customer of the system, connected to a wireless gateway through one of several wireless data networks, and the customers who manage those assets connect to the gateway through the Internet using browsers. Location data are used by applications utilized by the customer; the applications are served over the Internet. The core of the system is location aware business logic in the gateway that ties the assets (e.g., the customer's vehicles) and applications together through a common set of protocols and interfaces. The core business logic and the applications are implemented at the system and services supplier's web site.

The core business logic component manages customer login accounts and access to remote asset data. It also manages wireless device communications and access to the appropriate networks. All data communications between the customer at the enterprise and the vehicle devices or other remote users are routed through the core business logic, with the core providing the database and interfaces to applications. The mapping and messaging applications are more tightly coupled to the core business logic than other applications since location information and message routing are basic functions of the gateway. These functions are directly accessible from other applications and behave based on the business rules established in the core component.

The primary functions of the location aware business logic are to associate location information with other data generated by the mobile assets or traditional business applications and to enable the creation of new applications that were not possible before. For example, the gateway and the vehicles have a concept of job sites. These are locations where work is to be performed. Work order management and dispatching applications maintain work orders and schedules but are unable by themselves to keep track of where vehicles or personnel are actually located at any given time relative to work sites. When a work order is created, the gateway creates and stores a job site. When a vehicle is dispatched, the gateway sends the site information to the vehicle. When the vehicle arrives at the site, it automatically transmits data back to the gateway. The gateway then passes the event to the work order management application which can then automatically change the status of the work order.

Because of the importance of location information, the mapping application is a principal part of the user interface. Mapping functions can be initiated by other applications and functions of other applications can be initiated from the mapping interface. Since the map is intended for real-time business use, it must be both fast and interactive. To achieve these requirements, traditional web served mapping methods that involve simple image delivery are not adequate. The street level map data and map control application must reside on the user's local computer with location information provided through a second data channel directly from the application server instead of the web server. This unique implementation enables seamless location data updates and smooth interaction with the map and the vehicles depicted on it, and retains the advantages of internet delivery of code and map database updates. The data channel also provides for procedure calls to and from other applications and the core business logic.

Vehicles provide location data in the form of geodetic position, along with speed and heading, periodically and in response to the detection of certain events that are reported through the messaging application. All data is stored in the business component's database, and the mapping application displays these positions as they are received or displays historical location data when requested.. Periodic position reports are typically available at one minute intervals. While position data is not often required at this rate for monitoring of a vehicle in real time, it is required for detailed auditing of position history when the need arises. What is required in real time is location tied to event reports from vehicles. Examples of event reports are speeding exceptions, unauthorized stops, text messages initiated by field personnel, and automated status reporting such as arrival at a job site.

It is necessary that the navigational state information from each vehicle's wireless device (tracker) be provided to the gateway for the gateway to provide the location services. Efficient methods of providing frequent periodic location reports, guaranteeing delivery of those reports, and tagging events reported by the wireless devices with location information are important aspects of the invention.

One example of enhancement of business applications by Internet delivery of location information is in the package delivery business. Currently, many package delivery companies provide their clients the ability to track packages over the Internet by giving the inquiring client the history of when the package arrived and left certain sorting facilities. Once the package is on a truck, no one knows where it is until the driver enters the information concerning its having been delivered. With vehicle location data feeding the tracking and routing applications in the system of the present invention, the package delivery business operators and their clients are able to see the actual location of the package, the truck's route, and an estimated time of arrival.

The number of potential applications is endless. The critical factor in making these applications possible is removing the wireless and location integration problems from the business application developer and making the applications available over the Internet. The location aware wireless gateway does this by providing the application developers with a standard interface and a core set of business rules to follow in order to make use of location information. Serving these applications over the Internet allows them to interact with the other applications that use the same core business rules. This enables the application developers to focus on their areas of expertise and take advantage of other applications where prudent.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and still further objectives, aims, features, aspects and attendant advantages of the present invention will become apparent from a consideration of the following detailed description of the best mode presently contemplated for practicing the invention, with reference to certain preferred embodiments and methods, in conjunction with the accompanying drawings, in which:

FIG. 1 is a diagram of the overall gateway system of the invention, illustrating the data flow between the business enterprise user and remote assets through the Internet, location aware business component, and wireless networks;

FIG. 2 is a more detailed block diagram of software architecture and data flow in the gateway system of FIG. 1;

FIG. 3 illustrates the message routing and network server architecture of the wireless gateway portion of the overall system.; FIG. 3A shows the sequence of operations performed by a message router to resend unacknowledged messages, and FIG. 3B shows the sequence of operations performed by the router in assuming a message is undeliverable and reporting a failure to a customer server, in managing limited guaranteed delivery from the gateway to the tracker; and FIGS. 3C, 3D, and 3E, respectively, show the process flows for sending text, pre-defined, and user data messages to trackers;

FIG. 4 illustrates the Customer Interface Server software architecture and data flow;

FIG. 5 is an exemplary screen of the web browser mapping user interface;

FIG. 6 is a block diagram of the web based mapping application architecture;

FIG. 7 is a simplified perspective view of a fixed vehicle mounted wireless tracking device (tracker, a data computer);

FIG. 8 is a simplified perspective view of a vehicle mounted display terminal;

FIG. 9A is a simplified block diagram of a fixed mounted wireless tracking device as it interacts with the gateway, display, and vehicle mounted sensors; FIG. 9B is a simplified block diagram of a hybrid handheld/fixed mounted wireless device architecture; and FIG. 9C is a simplified block diagram of a location enabled purely handheld device in which all of the location aware software is located at or in the handheld device;

FIG. 10 illustrates the subsystems contained in the overall software system structure;

FIG. 11 is a functional diagram of the vehicle display function structure;

FIG. 12A is a functional diagram illustrating the sequence of operations performed for a Get Last Reported Information function; FIG. 12B is a diagram showing the detailed design of the Get Last Reported Information function sequence;

FIG. 13A is diagram illustrating the sequence of functional steps performed for changing asset display and symbol in the manage vehicle display use case; FIG. 13B is a diagram of the detailed design of the change asset display and symbol function sequence;

FIG. 14A is diagram illustrating the sequence of functional steps performed for locating a vehicle on the display; FIG. 14B is a diagram of the detailed design of the locate vehicle function sequence;

FIG. 15A is diagram illustrating the sequence of functional steps for performing a playback of vehicle location history; FIG. 15B is a diagram of the detailed design of the playback history function sequence;

FIG. 16A is diagram illustrating the sequence of functional steps for performing an update real-time location request; FIG. 16B is a diagram of the detailed design of the update real-time location function sequence;

FIG. 17 is a functional diagram of the messaging function structures;

FIG. 18A is diagram illustrating the sequence off functional steps for performing a send dispatcher initiated message; FIG. 18B shows the user interface for sending dispatcher initiated messages;

FIG. 19A is diagram illustrating the sequence of functional steps for performing a send messages function; FIG. 19B is a diagram of the detailed design of the send messages function sequence;

FIG. 20A shows the sequence of functional steps performed by View Message Folder function; FIGS. 20B, 20C and 20D show detailed design of View Message Folder inbox sequence, outbox sequence and lists sequence, respectively; and FIG. 20E shows the View Message Folder user interface display;

FIG. 21 is diagram illustrating the sequence of functional steps for performing an identify message function;

FIG. 22 is a functional diagram of the map navigation function structure;

FIG. 23A illustrates the process flow for the Search function; FIG. 23B shows the Search function interface with a highlighted address;

FIG. 24 illustrates a thumbnail map interface on the display;

FIG. 25 shows a typical job site on the map display;

FIG. 26 is a functional diagram of the dispatching function structure;

FIG. 27 is a functional diagram of the work site management function structure;

FIG. 28 is a functional diagram of the project and work order management function structure;

FIG. 29 shows the primary user map interface for the dispatching and work order management applications;

FIG. 30A shows the functional steps performed by the Work Order Management Application to dispatch a vehicle if a work order is selected for dispatch; FIG. 30B illustrates the user interface used to send the dispatch message;

FIG. 31A shows the functional steps performed by the Maintain Project Order and Work Order function; FIG. 31A illustrates the user interface for that function; FIG. 31C shows the work order state transition;

FIG. 32 shows the functional steps performed for Change Work Order State;

FIG. 33A shows the steps performed by the View Project/Work Order List function;

and FIG. 33B shows the steps performed by the Search Project/Work Order List function;

FIG. 34A shows the user interface for work site creation and the modification, removal, and location functions; FIG. 34 B shows the functional steps performed by the create work site function;

FIG. 35 shows the functional steps performed by the modify work site function;

FIG. 36 shows the functional steps performed by the remove work site function;

FIG. 37 shows the functional steps performed by the assign home site function;

FIG. 38 shows the functional steps performed by the find work site function;

FIG. 39 shows the functional steps performed by the select work site function;

FIG. 40 is a functional diagram of the customer asset management function structure;

FIG. 41 is a functional diagram of the client management function structure;

FIG. 42 is a functional diagram of the customized feature management function structure;

FIG. 43 is a functional diagram of the maintain code/lookup table function structure;

FIG. 44 is a functional diagram of the customer setup function structure;

FIG. 45 is a functional diagram of the system access function structure;

FIG. 46 is a functional diagram of the role management function structure;

FIG. 47A illustrates the user interface for the view resource list and maintain resource functions; and the functional steps performed for both of those functions are shown in FIG. 47B and continued in FIG. 47C;

FIG. 48A shows the user interface for the view vehicle list and maintain vehicle functions; and the functional steps performed by the view vehicle list and maintain vehicle functions are shown in FIG. 48B and continued in FIG. 48C;

FIG. 49A shows the maintain sensor user interface; FIG. 49B is the functional sequence of steps performed by the maintain sensor function; and FIG. 49C is the detailed design of the maintain sensor sequence;

FIG. 50A shows the view sensor list user interface; FIG. 50B shows the functional steps performed by the view sensor list function; and FIG. 50C shows the detailed design of the view sensor list function;

FIG. 51A shows the view client and maintain client user interface; and FIG. 51B shows the functional steps performed by the view client and maintain client functions;

FIG. 52A shows the functional steps performed by the manage map data display function; and FIG. 52B shows the detailed design of the manage map data display sequence;

FIG. 53A shows the functional steps performed by the manage map detail display function; and FIG. 53B shows the detailed design of the manage map detail display sequence;

FIG. 54A shows the functional steps performed by the manage map default area function; and FIG. 54B shows the detailed design of the manage map default area sequence;

FIG. 55 illustrates a typical vehicle symbol;

FIG. 56A shows the functional steps performed when a message is created by the maintain messages function; FIG. 56B shows the detailed design of the maintain messages sequence for message creation; FIG. 56C shows the functional steps performed when a message is changed/deleted by the maintain messages function; and FIG. 56D shows the detailed design of the maintain messages sequence for message change/deletion;

FIG. 57A shows the functional steps performed for the view message list function; and FIG. 57B shows the detailed design of the view message list sequence;

FIG. 58A shows the view job type list and maintain job types common user interface; and FIG. 58A shows the functional steps of the view job type list and maintain job types functions;

FIG. 59A shows the main user interface for gateway administration; FIG. 59B shows the user interface for creating a new customer; FIG. 59C shows the user interface for modifying a customer;

FIG. 60A shows the login user interface; FIG. 60B shows the functional steps performed by the login function; FIG. 60C shows the detailed design for the login sequence;

FIG. 61A shows the functional steps performed by the logout function; and FIGS. 61B and 61C show a detailed sequence of the logout function for the cases in which the user initiates the logout, and in which the connection is lost, respectively;

FIG. 62A shows the user change password interface; FIG. 62B shows the gateway administrator change password interface; FIG. 62C shows the change password functional steps for a user initiated change; and FIG. 62D shows the detailed design for the change password sequence;

FIG. 63 shows the user interface for changing or expiring a user account;

FIG. 64 illustrates an event selection screen of the user interface for reporting;

FIG. 65 illustrates a group creation screen of the user interface for reporting;

FIG. 66 illustrates an exemplary run time report;

FIG. 67 illustrates an exemplary fleet summary report of pour time and trip time;

FIG. 68 is a pie chart of the fleet summary report of FIG. 67;

FIG. 69 is an event report showing multiple types of events;

FIG. 70 is an engine on time report;

FIG. 71 is an engine on time trend report; and

FIG. 72 is a functional diagram of the reporting function structure.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The invention provides a wireless gateway that connects mobile and remote assets or employees to business enterprise users through multiple wireless networks and the Internet by using web served applications. The central core of the gateway is a location aware business component that sends and receives location based information to and from remote and mobile assets and applies business logic to the location data to enhance and automate business applications run by the enterprise user. This functionality considerably exceeds that of a traditional wireless gateway, which simply manages messages passed through multiple wireless networks but does nothing with the content of the messages. The business logic component provides a common interface and protocol for handling location information and allows applications that follow the protocol to interface with the gateway to take advantage of location information by using location data to trigger events or to tag events, messages, or other data.

A web site serves as a portal to provide business applications for companies with vehicle fleets, remote assets, or employees. In the main, the site provides a gateway to wireless networks that provide data from and communication capabilities with customers' vehicles. The communicated data is primarily associated with location information but provides other information regarding vehicle and operator activity as well. The customers' vehicles are outfitted with data computers that operate on a wireless network. Core functions of the system include location related reporting, messaging and system administration. Dispatching, vehicle maintenance tracking, accounting capabilities and industry tailored ERP (enterprise resource planning) applications can all be served through the web site.

Business applications are enabled to become location aware through use of the system's wireless gateway, and to utilize information about the location of their respective assets, vehicles, and employees for more efficient management of them. Available applications are tailored to each customer's and/or industry needs, and fees charged to customers may be based on applications served. Applications are preferably segregated into the following broad categories: location and messaging, reporting, dispatching, maintenance, ERP and accounting, business marketplaces, and other services. Reporting is included within all applications; while full-featured dispatching capabilities include order entry and invoicing functions.

I. Architecture

A. General

The overall gateway system 10 of the invention, illustrating the data flow between the business enterprise users 11 and remote assets 12 through the Internet 13, location aware business component 14, and wireless networks 15 is illustrated in FIG. 1. The system includes wireless devices in vehicles 17 and handheld units of individuals 18 connected to a wireless gateway 20 through one of several wireless data networks 15. Customers (i.e., the business enterprise users of gateway system 10) manage their mobile assets (which may include vehicles 17, employees 18 and packages (not shown), among other things) through connections to the gateway 20 through the Internet 13 using browsers. The customers employ applications making use of location data pertaining to their respective mobile assets, and those applications are served over the Internet.

As generally used in this specification, the term “customer” refers to a business that owns vehicles or remote assets that receives application and data services from the system(s) or in the method(s) of the invention; “users” are employees of the “customer” that use the applications and access data; “clients” are customers of “customers,” and clients may also be “customers.” This “client,⇄ however, is not to be confused with client applications in client/server software architectures.

The core of the system is the location aware business logic component 14 in gateway 20 that ties the vehicles 17 (and other mobile assets 12) and applications together through a common set of protocols and interfaces. The core business logic and the applications are implemented as the web site of the invention, griddata.com™. The location aware wireless gateway 20 is responsible for the management of all data required to provide customers with the ability to monitor and communicate with their vehicles. Data management includes providing customers access to their data in real-time, and access to meaningful reports required for more efficient utilization of their vehicles. Data management also enables the gateway provider to monitor/analyze network performance and to bill customers according to number of applications and usage.

The wireless devices (also referred to herein as “trackers”, and occasionally as “tracking computers”) in vehicles, handheld units and installed in or on a customer's other mobile assets all have hardware and software to enable them to determine the respective tracker's location (for example, using GPS). For the sake of convenience and simplicity, the terms “asset” and “vehicle” are sometimes used interchangeably throughout this specification and in the claims, but it will be understood that asset may refer to anything (including human resources) which is employed, owned, leased, delivered or otherwise of value to the customer's business and which is typically intended to undergo movement outside the customer's premises. The installed trackers report location data for their respective vehicles and other status information through the respective wireless network used in the system 10. The trackers also contain software to support location aware dispatching and to automatically report when the vehicle (such as ready-mix concrete truck) has arrived at and left a job site. These vehicle-mounted wireless devices can also run other types of business specific logic and report on sensor outputs.

Gateway 20 may utilize multiple types of wireless networks 15 (e.g., CDPD, Orbcomm®, etc.); however, the server software applications hide most of the details related to different networks. As a result, the customer/end-user is not bothered—such as by data formatting, error correction algorithms, and guaranteed delivery—with the details of the specific network being used. Users simply access location information from the core business logic of the gateway and other information from applications integrated with the gateway.

Applications are hosted on web servers 22 and application servers 23 located within a gateway network operations center or remotely hosted by another application service provider or on site at large customers' own facilities. Applications access location data through Customer Interface Servers 29 (FIG. 2) that implement the core location aware business logic and control access to the database and wireless gateway. Customer enterprise users run applications through a web browser. Business applications are integrated with and built on core gateway applications such as mapping, messaging, work site management, and administration functions for managing access to data.

B. Data Flow

System data flow is shown in FIG. 2, a more detailed block diagram of software architecture and data flow in the gateway system. Each data flow illustrated in FIG. 2 is referred to here as a data channel. Labels for data channels and subsystem elements identify the data content, formatting, and protocols for each major data flow between subsystems and subsystem elements. Only labeled data channels are shared by software outside the system. Thus, externally hosted software applications may only interact with the system via the extensible markup language (XML) protocol (data channel D).

As shown in FIG. 2, Data Channel A (at tracking subsystem 25) is used to route tracker messages, consisting of all of the wireless transmissions to and from the remote wireless devices (the trackers 17), via the wireless network 15 and the wireless network management 26 which include the wireless network servers 21. Of these messages, real time location data provide the highest volume of information flow. The data content, formatting, and update frequencies are dependent on the characteristics of the particular wireless network being used. A summary of the characteristics of Data Channel A is shown in Table 1 of Appendix B of this specification (all Tables subsequently referred to herein in bold text accompanied by a number will be understood to be in Appendix B—not to be confused with lookup tables that may be used in the system).

Data Channel B routes the tracker message data within the wireless gateway between the appropriate wireless network servers and the message queues 27 (spanning tracking subsystem 25 and server subsystem 28. Messages are routed to customers through the Customer Interface Server (CIS, sometimes referred to herein as Customer Server) 29 and logged in the database via server 30. A summary of the characteristics of Data Channel B is shown in Table 2.

Data Channel C is used for database queries, implementing Structured Query Language (SQL) requests to the database via server 30 to retrieve historical data provided by the trackers (e.g., vehicle position history). The CIS 29 also uses the database to manage customer business and administrative data such as work sites, user IDs and passwords, vehicle sensor configurations, etc. A summary of the characteristics of Data Channel C is shown in Table 3.

Data Channel D provides an XML interface for all real time tracker messages to be pushed to web based applications, such as mapping, and other integrated applications. This interface also supports a complete command response protocol to enable any application to take advantage of the wireless network interfaces and location aware business logic in the gateway. A summary of the characteristics of Data Channel D is shown in Table 4.

Data Channel E handles all web-like data requests and responses. Hypertext transfer protocol (HTTP) data is not encrypted, and HTTP secure (HTTPS) data is encrypted using standard protocols like Secure Socket Layer 3 (SSL3) when transmitted across the Internet 13. User configuration data is posted to the Server Subsystem 28 for storage in the system database 31 (e.g., FIGS. 3A, 4) via server 30. Most user interface components for web based applications use this data channel. A summary of the characteristics of Data Channel E is shown in Table 5.

Data Channel F carries command data between CIS 29 and web server 22. The CIS makes database queries on behalf of web servers and applications using the XML interface. This insulates the database from indiscriminant queries, and forces queries to conform to the business logic rules of the gateway. A summary of the characteristics of Data Channel F is shown in Table 6.

C. Wireless Gateway System Architecture

The wireless gateway 20 (FIG. 1) consists of wireless network servers and message routers 21 that connect vehicles or other mobile assets to the CIS 29 (FIG. 2). The network servers and routers maintain the message management logic for each network and route messages between the wireless networks 15 and the CIS 29. The architecture of the network server and message router 21 of the wireless gateway portion of the overall gateway system 10 is shown in block diagram form in FIG. 3.

Each block in FIG. 3 represents a software application. These applications are normally run on physically separate machines, and multiple instances of the applications are run to provide redundancy and fault recovery. Hardware running the applications use Microsoft operating systems and are clustered to provide redundancy. Load directors are used to distribute the computational load between multiple machines running the same application. The applications include Customer Servers (CIS's) 29, Customer Message Routers 36, Q (queue) Manager 37, Reliable Message Servers 38, and Tracker Message Routers 39. Applications are also present for managing each connected wireless network, in the form of CDPD (Cellular Digital Packet Data) Network Interface Servers 40 and Alternate Network Interface Servers 41. Other server applications include Network and Engineering Database (NED) Server, Alarm Server, and Tracker Configuration Server (these server applications not shown in FIG. 3).

The Q Manager 37 is at the center of the wireless network management portion of the gateway, with the responsibility for ensuring messages are reliably passed between all of the other applications that communicate with the wireless networks. The Q Manager is based on the Microsoft (trademark of Microsoft Corporation) Message Queue (MSMQ) product, which has the advantages of cost relative to other queue managers, and support for Microsoft clustering technology. Applications place messages for other applications into the appropriate queues and read messages from their queues for processing. An advantage of a queuing system is that if all queue operations are transactional, messages cannot be lost in the event of a system failure.

However, MSMQ does have two disadvantages that must be addressed to enable it to work in this type of system. First, it does not support transactional reads on remote queues; and second, its message throughput is too slow to support high volume message traffic from thousands of wireless users on multiple networks. Solutions to these problems are as follows.

With respect to the transactional queue read problem, the Q Manager application enables transactional reads by performing queue reads on behalf of each application. Each application that receives messages has a local input queue from which it can perform a transactional read. The Q Manager has an input queue to receive requests from applications for reads from remote queues (queues local to the Q Manager are shown surrounding the Q Manager 37 block in FIG. 3). The Q Manager processes these requests by performing a transactional write of the appropriate data to the local input queue of the requesting application.

As for the second problem, a solution is achieved through message bundling for queue throughput enhancement The throughput of the Q Manager using MSMQ is very slow, roughly seven transactional messages per second for message sizes between 50 and 2000 bytes on a state of the art PC. This is not adequate for wireless network traic that will generate hundreds of messages per second when tens of thousands of wireless devices are on line. The throughput problem is addressed by bundling small messages into larger, less frequent messages.

Two factors make bundling a good technique to increase message throughput. First, transactions add significant overhead to each message that is sent using MSMQ; and second, increasing MSMQ message size does not decrease MSMQ message throughput significantly (e.g., a 5 KB message takes approximately the same time to be delivered as a 50 B message). Typical wireless messages are short, usually 50-100 bytes. Throughput for messages of this size is roughly seven per second; however, if the size of the messages is increased until the throughput drops to just over 1 message/second, the message size is on the order of about 200 KB. If this large message is an aggregate of small messages, the equivalent throughput equates to approximately 4000 messages per second (assuming an average message size of 50 bytes). The above numbers apply to messages moving in a single direction (e.g., from the network servers to the customer servers). For these numbers, then, the total bidirectional maximum throughput would be approximately 8000 messages per second.

Message bundling is achieved by caching a number of messages over a period of time, then aggregating them into a single message, to achieve a message throughput improvement on the order of a factor of 600. This lends considerable scalability to the gateway's messaging backbone. The gateway uses a component object model (COM) object called MrBundle to cache messages over a fixed time interval and then bundle them into a single message. For the gateway, an interval of one second is used, which adds an average of 0.5 seconds to the message delivery time. Considering web connection and tracker update rates, half a second is virtually unnoticed by customers. An instance of MrBundle is used by each Customer Server, Customer Message Router, Network Interface Server, and Tracker Message Router. Messages are bundled up before being sent to the Q Manager, and are unbundled after being received from the Q Manager.

Customer Server or CIS 29, which will be described in more detail presently, is responsible for managing the flow of data between the wireless networks and customer software. This server authenticates customers, controls customer data access, pushes tracker packet data in real-time to customer applications, queues customer requests to the networks, and services customer database queries.

The Customer Message Router 36 determines which messages should be forwarded to one or more Customer Server 29 applications. The Customer Message Router makes routing/filtering decisions using a cached table (created by querying a User Support Database (USD) which is part of the CIS, and/or Network and Engineering Database) that associates tracker modules with an organization, and maps which Customer Servers are currently servicing a customer. While tracker messages represent the majority of messages routed by the Customer Message Router, the latter also routes system messages to the customer applications (e.g., broadcast messages from a Site Administrator).

The Reliable Message Router 38 periodically checks the Customer Support Database to see if any messages that have not been acknowledged should be resent. Messages that should be resent are generated by the Reliable Message Router for retransmission.

Network servers 40 and 41 communicate with trackers over each wireless network. The servers are designed to run in redundant pairs: two servers for transmitting data and two servers for receiving data. FIG. 3 shows CDPD network servers 40 and alternate network servers 41, the latter representing a group of servers for each network being serviced. The Base Packet Servers among network servers 40 and 41 are responsible for transmitting data to tracker modules and storing the raw data transmitted. The Tracker Packet Servers among network servers 40 and 41 are responsible for processing, storing, and forwarding data received from tracker modules.

A Tracker Configuration Server (not shown) is responsible for programming wireless devices “over the air.” Programming includes initial configuration of a device for a customer with parameters such as home sites, message lists, sensor configurations, as well as software updates. An Alarm Server (not shown) is responsible for processing alarm messages generated by all applications that generate alarms in the gateway. All server applications (including the Customer Server, Customer Message Router, Reliable Message Router, and Q Manager) generate alarm messages as required. Alarms generated by these applications are placed in a queue for Alarm Server processing. Alarms are monitored by site administrators using web based messaging and reporting tools similar to those used by customers.

Oracle (trademark of Oracle Corporation) 8 i Enterprise database servers are used within the gateway to support all of the server applications. The database used primarily for message routing and network servers is the Network and Engineering Database (NED). The USD portion of the Customer Servers is used to support customer connections and business logic.

Several web server applications are used to support the network servers and message routers 21. Web pages are used to support monitoring, reporting, coverage analysis, internal data entry, and customer data entry screens. Several reports provide assistance to engineering, network (and alarm) monitoring, wireless device testing and production, installation, and customer service. Initial activation of wireless devices, system configuration, and provisioning of services is done through data entry interfaces. Service provisioning is performed either manually by site administrators or customer service personnel, or automatically by customers through the Internet.

D. Wireless Message Protocols

The wireless gateway 20 supports numerous wireless networks 15. Each network has its performance limitations and pricing models that make it necessary to tailor data transfer in order to optimize wireless bandwidth usage for each network. For the location services provided by the gateway, the navigational state information from each wireless device must be provided to the gateway.

Efficient methods of providing frequent periodic location reports, guaranteeing delivery of those reports, and tagging events reported by the wireless devices with location information are important aspects of the invention.

The wireless protocol for CDPD (cellular digital packet data) is described below by way of example. CDPD operates as a data add-on to the analog cellular telephone system. It provides packet data using Internet Protocol (IP) to wireless devices. An aspect of CDPD is that the air time subscriber is billed for all overhead associated with data transmission. This makes it expensive for small packet transmission normally associated with telemetry applications, such as location reporting. The need for frequent location information, and concomitant cost reduction, is addressed by bundling frequent reports into large packets. Overhead is further reduced by using user datagram protocol (UDP) rather than transmission control protocol (TCP) and implementing a guaranteed delivery protocol that is more amenable to a wireless environment.

TCP is the standard transmission protocol used over IP networks (TCP/IP). This protocol sends large blocks of data by splitting them into small packets, transmitting the packets and then reassembling the packets in the correct order on the receiving end, guaranteeing delivery and order. It also provides for error detection with a checksum. TCP is a reliable mechanism for transmitting data over networks that have low rates of data loss and reasonably short response times. These advantages come at the expense of a significant amount of overhead added to the original data to be transmitted. TCP adds 20 bytes of overhead to each packet transmitted and includes additional overhead in the form of acknowledge packets. This protocol may break a message across several IP packets, and each IP packet has its own 20 bytes of overhead.

TCP is not an efficient protocol for wireless systems for the following reasons: (a) since most wireless networks charge by the byte or connection time, the overhead is expensive to send; (b) the protocol to guarantee delivery was not designed for the poor reliability of wireless connections so it can retry excessively (increasing cost) or take too long to deliver data; and (c) its protocol requires continuous communication while transferring data, which is usually not cost effective or reliable when-using circuit switched wireless systems because a dropped call to a cellular telephone, for example, requires the system to complete an additional call, and because data must be passed in both directions on a periodic basis, increasing data transmission cost.

For these reasons, wireless communication can be performed more efficiently using UDP over IP networks (UDP/IP) and software algorithms that are better suited to wireless interfaces to improve data delivery reliability. UDP has an 8 byte overhead compared to TCP's 20. The protocol itself does not guarantee delivery of data, but does not add the associated overhead of acknowledgments and connection maintenance. For example, a UDP packet is simply sent to its destination address—the sender does not know if it was received successfully. In contrast, the TCP protocol requires full bidirectional communication to send a packet, but delivery is guaranteed. UDP has a significant advantage for wireless interfaces because one way communication is often easier to establish than two way communication.

The wireless gateway servers 21 and trackers 12 of the present invention implement a limited guaranteed delivery protocol using UDP that is more appropriate for wireless interface than TCP. Limited guaranteed delivery ensures that the system will attempt to deliver messages of all kinds for a period of time. If the time period expires without successful delivery of the message, the user is notified of the failure. Each message successfully received is acknowledged back to the sender, and each message has a sequence number assigned to it to allow the order to be determined, if necessary. For wireless telemetry and messaging applications, messages are very short (typically less than a few hundred bytes), so breaking single messages into multiple packets is rarely required.

The Reliable Message Router (RMR) 38 (FIG. 3) manages the limited guaranteed delivery from the gateway 20 to the tracker 17. (The tracker 17 performs an identical function for messages sent to the gateway.) Each time a new message is sent by the Customer Server 29, the time that the message is sent is logged to the database 31 (FIG. 3A). When an acknowledgment of that message is received from a tracker, that is also logged to the database. FIG. 3A shows the sequence of operations performed by RMR 38 to resend unacknowledged messages. Periodically, every two minutes in the preferred embodiment, the RMR retrieves a list of trackers that require messages to be sent. The send time, number of retries attempted, and total time waiting to be acknowledged are updated. Those messages are then forwarded to Base Packet Server 40 a or alternate Server 41 a for retransmission.

It is assumed that most messages sent through the gateway are of little importance if not delivered promptly. Timers and retry counters are used to control when messages are undeliverable. An overriding retry count limit is set to 720 in the preferred embodiment. This allows for a retry every two minutes for 24 hours, before failure. This counter can be extended to a maximum of one week, for example, if required. A timer can be set by the user on most messages to indicate that delivery attempts for the message should stop before the overriding system limit. The user typically sets this timer at a few hours. If timers expire or the retry counts are exceeded, the RMR assumes the message is undeliverable and reports a failure to the Customer Server 29. This sequence is shown in FIG. 3B.

The primary use of bandwidth for a location-oriented service is the reporting of vehicle state information. Frequent periodic reports of vehicle location are important for reconstructing the path a vehicle drove—locations of events, such as speeding exceptions or vehicle equipment activation are important for the monitoring of safety or equipment usage. The trackers 17 minimize the bandwidth used by using a combination of packet bundling and data compression. Messages sent by the tracker can contain several packets of the same or different type. Putting multiple packets together minimizes the overhead used by the UDP packet headers.

Vehicle state information is compressed by sampling data at a short interval, such as one minute and bundling ten one-minute interval sample packets into a single message that is transmitted every ten minutes. The first packet is sent in its entirety; the subsequent packets are compressed by representing them as changes in location relative to the previous packet. This way, fewer bits of information are required to represent the location data. Furthermore, if an event occurs or message is received that must be acknowledged, any sampled vehicle state information is bundled with that message acknowledgment. To further reduce bandwidth, state information is not sampled at a high rate while the vehicle is stationary. A stationary vehicle tracker will sample and send a report at ten minute intervals. This behavior allows the user to receive data at the same real time rate, but save sending redundant samples.

Message and packet formats for the CDPD network, by way of example, are described in the following paragraphs. Base messages consist of packets sent from the gateway 20 to the trackers 17 (here, for example, identified with and located on vehicles) over the CDPD network. Tracker messages consist of packets sent from the trackers 17 to the gateway 20. Both the gateway and the trackers initiate the transmission of messages and send acknowledgments in response to receiving messages from the other. In the preferred embodiment, trackers cannot send messages directly to another tracker.

The base message data contain network control information, interval definitions, messaging/paging data, and user specific data. The format of the base message data packets broadcast to trackers is summarized in Table 7. The data packets are of fixed or variable length, depending on the type, and include user commands, messaging and tracker control commands. Data packet decoding occurs after error detection/correction and decryption. Each packet starts with a packet ID byte followed by the data in the packet.

Information flow is handled by message data that control network activity (network and tracker control packets), the message data being created by the Base Packet CDPD Server 40a in response to data received from trackers and from customer or system administrator command stations. Messaging and user data packets are created from commands by the users 11.

Each base message is encapsulated into a data packet wrapper (see Table 8) that is bound by control characters and has a cyclic redundancy check (CRC) to verify the packet data. This format allows the mobile computer comprising the tracker to distinguish between packets when plural packets are sent simultaneously. It also provides for minor error detection on the packets, using a simple 8 bit CRC to check that the data is good and that the correct number of bytes was sent.

Text message data packets are generated in response to messaging commands from user command stations. The maximum message length, for example, is 32739 characters. In addition, an optional 28 character response set may be appended. The text message packet format is summarized in Table 9, and is acknowledged by the tracker at the time the message is received, by use of a Message Response Acknowledge packet. Pre-defined message response sets are illustrated in Table 10.

A Pre-defined Message packet (Table 11) provides a shorter message format for “canned” user messages of the type that are frequently used by an individual customer. Since trackers know the text of these messages a priori, only a message ID and a 16 Bit CRC need be sent by the gateway. The message ID indicates its identity and, consequently, its substance, and the CRC is used as a check for the tracker to verify that the text matches the CRC of the known associated pre-defined message.

Pre-defined message CRC's are computed using the entire pre-defined message. As a result, a tracker may determine if the ID has been reassigned to a new message. Tracker modules that determine that a pre-defined ID has been associated with a new message (or do not know a specified pre-defined message) may request the entire pre-defined message using a “Pre-defined Message Request Packet.” Pre-defined Message Request packets are serviced by the CDPD servers 40a, 40b. When the Tracker Packet CDPD Server 40b receives such a packet, the Base Packet CDPD Server 40a provides the tracker with the pre-defined message in a Pre-defined Message Definition Packet.

A User Data message packet (defined in Table 12) supports generic, user specific data that are sent to trackers from user command stations 11. The format of the message is similar to the text message packet, having at most 32767 data bytes available for any customer purpose. This message can either be used by customer software or viewed via the web based reports.

The process flows for sending Text, Pre-defined, and User Data messages to trackers are shown in FIGS. 3C, 3D, and 3E, respectively. The basic flow for all three is similar, as follows. The user 11 initiates sending a message to the Customer Server 29. The Customer Server acknowledges receipt of the message to the user's web browser, stores the message in the database 31 and forwards it to the Base Packet CDPD server 40a. The Base Packet CDPD server 40a then sends the message to the destination tracker(s) 17 and stores the formatted data packet in the database. The tracker is later expected to acknowledge receipt of the message; otherwise the RMR 38 will act to resend the message as described previously.

The Pre-defined message sequence (FIG. 3D) is more complicated, because if the tracker 17 does not have a match with the message ID and the CRC, it must request the text of the message from the gateway in order to display the message to the mobile user. In this case, the Tracker Packet CDPD Server 40b receives a request for the definition of the message, obtains the definition from the database 31, and tells the Base Packet CDPD Server 40a to send the definition (Table 18) to the tracker.

A Set Intervals Definition packet (Table 13) informs the tracker of the length of all its intervals, including sampling rate, reporting rate, low power update rate and Built in Test (BIT) rate (discussed in more detail below). These values must be positive integers. If the tracker already has a repeating interval assigned, it will be reset to the one contained in the message.

Trackers receiving a main repeating interval assignment may use the assigned interval until they request to exit the network. The tracker may receive a sampling interval of ‘0’. In this case, the reporting interval will indicate when the tracker should ask for another interval packet. If that reporting interval is also ‘0’, the tracker will not ask to be in the network again, and although it will respond to requests for data, it will not send position reports.

When a Text or Pre-defined text message is sent to a tracker, a pre-defined or custom response set may be identified. This response set indicates the text labels that should be associated with the mobile data terminal (i.e., tracker) soft keys when the message is displayed. When a soft key is pressed to respond to a message, the soft key number is returned to the CDPD Server in a “Message Response Tracker Packet.” A Message Response Acknowledge base message (Table 14) is used to acknowledge that the Tracker Packet CDPD Server 40b has successfully received a response packet. The tracker module will not discard a message response until it has successfully received an acknowledgment for that response, and if it does not receive an acknowledgment within a set brief interval (e.g., 20 seconds) it will resend the response.

The gateway's SITE DISPATCH (a trademark of Grid Data, Inc., the assignee of this application) feature provides automatic notification when a tracker arrives at or leaves from a specified rectangular geographic area. (The SITE DISPATCH™ notification feature is described in more detail in later paragraphs.) When a vehicle or asset is dispatched to a particular location by the user, the gateway sends a mathematical description of the location, or site, to the tracker using the SITE DISPATCH message (Table 15). The message contains the latitude/longitude coordinates of the southwest and northeast corners of the site. It also contains a test description from the user. Upon receipt of this message, the tracker module will acknowledge the message using the Message Response and User Data packet. When the tracker enters or exits the site, it sends a Site Status message which indicates the site ID number and a code that indicates entry or exit. This provides an automated indication to dispatch applications about when an asset or technician is on a job site for management of the status of work orders. The Site Status message is discussed in more detail below.

A User Data Acknowledge message (Table 16) acknowledges a reliable user data message sent by a tracker. Tracker modules retain a copy of all reliable user data packets until they receive this acknowledgment message from the CDPD Server, and, as in the situation described above, if the acknowledgment is not received within 20 seconds, the tracker will re-send the reliable user data packet.

A Site Purge Message packet (Table 17) requests a tracker to remove one of its known sites. Trackers receiving this packet will acknowledge the message using a Message Response packet and will cease providing a Site Status message for the site associated with the specified “Site ID.”

The Pre-defined Message Definition packet (Table 18, also referenced above) provides tracker modules with a text message associated with a specified pre-defined message ID. Tracker modules receiving this message will store the pre-defined message definition and subsequently use it to display the appropriate message upon receipt of a pre-defined message packet.

A Site Status Acknowledge message (defined in Table 19) is used to acknowledge a site status message sent by a tracker 17. Tracker modules will retain a copy of all site status packets until they receive this acknowledgment message from the Base Packet CDPD Server 40a, and if the acknowledgment is not received within 20 seconds, the tracker will re-send the site status packet.

A Tracker State and Status Block Acknowledge message (Table 20) acknowledges state and status data sent by the tracker. Tracker modules will retain a copy of all state and status block packets until they receive this acknowledgment message from the Base Packet CDPD Server 40a—and if not received within 20 seconds, the tracker will re-send the packet.

Tracker messages are transmitted from the trackers to the gateway over the CDPD network. Tracker data consist of navigation state information, responses to network related commands from the gateway, messaging responses, and user specific data.

Trackers initiate sending data such as navigation state, messages from the driver, or data from sensors, among others and respond with acknowledgments to data transmitted from the gateway. The trackers 17 send the data directly to the Tracker Packet CDPD Server 40b with the UDP protocol. The messages are routed from the CDPD service provider through the Internet to the servers. The messages are logged, processed, and passed in real time to users. In general, each tracker has a periodic interval intended for transmission of navigation state data. Other messages are transmitted as required, usually immediately in response to an event like arriving at a site, acknowledging messages from the gateway, or a driver initiated message.

Exemplary available tracker update repeating interval rates are summarized in Table 21. Due to the expense of CDPD air time, update rates faster than at ten minute intervals are impractical. With the efficiencies realized in data formatting and protocol implementation, the invention is able to provide the effect of more frequent reporting by sampling data at more frequent intervals, such as one minute and transmitting ten one-minute samples every ten minutes. For update intervals longer than one hour, the system use a polling mode of obtaining location reporting instead of automatic periodic reporting.

Each tracker message is encapsulated into a message wrapper (Table 22) which commences with a control character and the length of the message. This is followed by one or more tracker packet(s) and by a CRC to verify the packet data. This format allows the server to distinguish between two or more packets sent at the same time. It also provides for minor error detection on the packets, using a simple 8-bit CRC to check that the data are not corrupt and that the right number of bytes was sent.

Tracker packets are made up of packet specific contents and bit packed blocks of data that are common to several different packets. These common data blocks are defined in this paragraph. The tracker state consists of time, position, speed, and direction, with state byte and bit definitions shown in Table 23. Since the tracker can be in any CDPD cell, it must have the entire latitude and longitude from the GPS. If the CDPD tracker samples its position at a higher update rate than it reports the data, the state and status blocks are placed into a bundle. The first block of that bundle is the regular Tracker State Data Block, but subsequent blocks are a condensed version of the block as defined in Table 24. A Network Status Code (4 out of an available 8 of which are defined in Table 25) is used by trackers to exit the CDPD network. Additional codes can be defined as needed, to automate tracking service changes. Text, pre-defined, user data, site purge, site dispatch, and other messages are acknowledged by trackers to indicate receipt of the respective messages. Text, pre-defined, and site dispatch messages have two responses: a return receipt to indicate the field service technician read the message and a key code to indicate the his answer to the message, if required. Acknowledgments and responses are sent in a Message Acknowledgment/Response Block which has the format shown in Table 26. Each packet has an ID number that requires 4 bits for a total of 16 different packet types. Each packet reserves the first 4 bits for a ID Block.

Packet types are identified by packet ID; for example, space is provided for 16 different packet types, summarized in Table 27. Unused or spare data bits and bytes in the packets are set to zero. The packets themselves consist of the bit-packed data blocks described above. The packets have sequence ID numbers and are acknowledged by the gateway. The sequence ID numbers allow the tracker to know which messages are awaiting acknowledgment. Unacknowledged packets are re-sent by the tracker at one minute intervals while it is registered in the CDPD network. The tracker does not try to send data when it is outside network coverage, and, instead, stores packets for later transmission.

A Net Entry Request packet (Table 28) is used by tracker modules to obtain access to the gateway and to receive a periodic reporting interval for location information, with each module requesting its main repeating interval slot and registering its IP address with the server. The tracker will not know the status of the server before requesting network entry, so it must wait for a response to ensure that it is in the network. If it does not receive an acknowledgment within 60 seconds after sending a network entry request, the tracker module will re-send the request. When a data packet is received from an unknown IP address prior to a net entry request, a Set Interval Definition Packet with intervals of zero is sent to that address by the gateway. The tracker identified by that address must then send a Net Entry Request Packet to become known. Once recognized by the gateway, trackers can send a variety of different packet types depending upon the tracker state.

A State and Status Packet (Table 29) is normally transmitted periodically by trackers, containing full resolution tracker position, velocity, heading, network status information, and five user data bytes. These packets usually contain one or more Condensed Tracker State Data Blocks for the location samples between updates. These packets are normally transmitted in real-time so that up-to-date data are available to the enterprise user. If the vehicle operates outside of network coverage, away from metropolitan areas, for example, the tracker will store location data and transmit using this packet when the vehicle reaches an area that is covered by CDPD.

The User Data Packets provide for data that is not defined by the interface herein to be provided to applications or users. The gateway simply stores and passes these data through to users. The user data (referred to as the User Data Block in the packet being defined in Table 30) consists of a minimum of 1 byte and may be as long as a full tracker transmit packet, all defined by the user. As noted earlier herein, an important function of the location aware business logic is tagging an event report or other data with location information as shown in Table 30. This packet contains location, distance, time, and current site, if applicable. For user data that does not require location information, a user data only packet is defined in Table 31.

A Message Response packet containing an acknowledgment/response (Table 32) is transmitted in response to receipt of any type of message from the gateway. Responses are transmitted when the driver reads a text message or site dispatch message. When the driver presses a response button to one of these messages, the code representing the key pressed is sent by the tracker.

A Site Dispatch Message from the customer/user indicates the area of a job site to the tracker module, which allows it to determine its arrival at and departure from the job site. The tracker sends a Site Status Packet (Table 33) indicating the tracker ID, site type, site ID, arrival/departure status, time of arrival/departure and the source of arrival/departure status. The site status packet is sent based on latitude and longitude if arrival/departure occurs (using the latitude and longitude values in the Site Dispatch message), and allows the user to manually indicate arrival/departure. The site source bit in the packet indicates how arrival/departure was determined.

A built-in test (BIT) packet (Table 34) is sent by the trackers to provide gateway administrators and engineers information to aid system testing and enable determining whether the tracker modules are functioning properly. Tracker modules provide the BIT packet at a rate specified in Table 13. All values supplied in a BIT Packet Data Block indicate values recorded since the last BIT packet was supplied to the Gateway. The tracker determines which BIT blocks should be included in a BIT Packet. The BIT Packet starts with a Packet ID and a count of the number of BIT Blocks contained in the message, followed by the respective Block ID and its data. The types of BIT data are defined in Table 35. The details of each BIT type are not shown; they include diagnostic information related to navigation reliability, network activity, input voltage, tracker temperature, and so forth.

When a tracker module receives a pre-defined message, it displays the known message associated with the specified message ID and 16-bit CRC. If the message associated with the specified message ID is unknown to the tracker, or the CRC of the known message fails to match the CRC in the pre-defined message packet, the tracker will request the message definition by sending a-Pre-defined Message Definition Request packet (Table 36; also see Tables 11 and 18).

E. Customer Interface Server (CIS)

Each CIS 29 provides a unified customer interface regardless of the location of the customer enterprise or wireless network being used. The CIS provides for redundancy and load distribution. As load increases on the customer subsystem additional resources can be added in the way of more web servers or more CIS's. A block diagram of the CIS software architecture and data flow is illustrated in FIG. 4.

The primary functions of CIS 29 are to receive all system and asset data, redirect information to customers attached to a customer interface, send messages to assets, interact with the database, and implement the business logic required by the system. The three major components in the CIS are the connectivity manager 54, the security service 55, and the CIS business logic 50. The connectivity manager communicates information between the intranet, which connects to the wireless gateway message routers, and connected customers via the customer interface 60.

The input queue 62 receives real-time data messages from the CMR (Customer Message Router) 36. The intranet 61 (Ethernet or other Local Area Network (LAN)) connects the hardware components of the gateway 20 (FIG. 1) together. The various applications communicate with each other through this interface. The system supports multiple applications and computers to run them, such as CIS's 29, Web Servers 22, and routers 36 and 38, among others. Customer Server applications communicate with the other applications and each other through the connectivity service 54 and the inbox/outbox 73. One example of communication is coherency messages used to keep users updated on changes made by other users. If one user creates a site while connected to one CIS, that CIS sends a broadcast message to the other CIS's so all appropriate users have access to the new site. The business logic 50 supports most of the business logic functions for the connectivity manager 54, and, along with supporting the CIS, provides a common place for database access and back-end support to the web servers.

Business logic components 50 are not commingled with web server 22 components. Business logic components provide the security context for the data and applications. Optimization of the security component(s) and their usage is paramount. Since a web interface does not maintain a continuous connection, all web based transactions validate security every time a message is posted. This can be very inefficient so the business logic components cache a security context where appropriate, rather than essentially requiring a login every time a new page is displayed.

Security for both web applications and the connectivity service is attained through the security service 55, which is responsible for creating and maintaining a security context for any connected customer.

Customers connect using TCP/IP to access the CIS. CIS 29 uses a pure XML interface (data channel D) 60 implemented as a bidirectional messaging interface that provides a data transfer channel for real-time data that must be pushed to the customers' browsers. The XML interface is the primary connection point for applications, such as dispatching, to connect to the database 31 and gateway 20 and take advantage of the core location aware business logic 50.

All business applications developed for customer support exist on a group of web servers. The customer web server 22 is primarily responsible for servicing web requests, executing active server pages (ASP) or middleware business logic and delivering content and applications to end users. The web server 22 does not have any direct connection to the database 31 for support of business applications; access to the database must go through the location aware business logic 50.

An Oracle 8i Enterprise database is used to support all of the gateway functions. External and integrated applications maintain their own databases and use the XML interface to access location related data from the gateway. Depending on the application, modification to the core database may be required to integrate a new function into the gateway.

The connectivity service 54 is a functional unit comprised of the objects necessary to take information off the web site intranet (e.g., Grid Data™ Intranet) 61, process this information and transmit relevant data to the appropriate connected customers. This service is responsible for four primary functions: (1) providing the mechanism for TCP/IP connection to the CIS for customers connecting over the Internet; (2) managing the removal of items from its input queue 62, from the intranet 61, and routing them to the appropriate connected customers; (3) having a message filter component 63 that allows connected customers to restrict the flow of their outbound data; and (4) providing the functionality necessary to parse messages (XML parser 64) and to create an object 65 that executes a command similar to a remote procedure call (RPC).

Message filter 63 is responsible for restricting the outgoing flow of tracker data to the XML socket connectivity manager for vehicles that are not required to be displayed or used by any of the web based applications. An individual user may not want to see or may not be allowed to see all vehicles owned by a customer. Data related to those vehicles are not transmitted; this is done both for security and to reduce required Internet bandwidth. The message filter component provides the following functions: (1) restricts the outgoing flow of tracker information after receiving a command to disable a tracker; (2) requires a call to the security component to verify dataset access to enable a tracker, and upon validating enablement of the tracker, allows messages to commence to the connected customer; and (3) receives notice of a tracker having been added or removed, by communication from automated processes.

The input queue 62 is the main point of delivery for system and tracker messages to the message filter component 63.

The security service 55 manages a secured access by customers using either the web interface or the XML interface, providing a mechanism for determining access privileges to the primary functions of the CIS and any data potentially available to a user.

User accounts are managed using the concepts of roles and datasets. Roles define classes of users; typical roles could be Dispatcher, Order Entry Clerk, Supervisor, and Administrator. The roles define a template for data and application access privileges. For example, an Order Entry clerk may be able to enter orders into a work order management application, but is not allowed to send dispatch messages, view fleet performance reports, or add users to the system. An administrator may have all of these privileges. With users belonging to certain classes, this mechanism allows simplification of the security system so that only a user's role needs to be checked for access to a certain part of the system. Datasets are partitions of the full set data logged into the database that are accessible only by certain customers or users. Data are normally partitioned by a time range and an owner. Datasets can be used to partition data between users; for example, a customer with two dispatchers may have each one responsible for a different group of vehicles. In this case, the dataset business logic will prevent access by the dispatchers to data from each other's vehicles. Roles provide a mechanism to define a type of user and the features available to it. Datasets are implemented to provide a means to restrict the visibility of vehicles a customer's user can see at any given time. The security service also provides support for the functions of: (1) user login and logoff; (2) encryption and decryption of credentials; (3) maintenance of cached security (roles and datasets); and (4) miscellaneous audit and statistical functions.

An important use for datasets is Client Administration Rights. Fleet owners will often lease vehicles or subcontract vehicles to their clients. Clients of customers who are themselves gateway customers need to be able to manage and dispatch those vehicles as if they were their own. These clients can be assigned administration rights to the vehicles by the owning customer through the datasets. To accomplish this, the owning customer, through an administration web page, selects the vehicles and time frame for which the client is allowed to access data for those vehicles. The client customer can then receive location data in real time and send messages to those vehicles during that time window. Outside of that window there is no real time access; however, events and other data logged during that time window are always available to the client.

A message sequence ID & site management component 67 is responsible for, management of the internal requirements for messaging and sites. Its primary responsibilities are: (1) creating message sequence ID's and de-referencing incoming message sequence ID's; (2) managing message response set ID's and dynamic response sets which includes the de-referencing of the response set used for a particular message; and (3) creating site ID's when a new work site is being created.

An alarm generation component 68 is used by the connectivity service 54 to provide information on connections, disconnections, and authentication failures.

Data related to customers that are required for customization and management of the customers' accounts are stored in the system database 31. Each user can customize the environment to his liking by configuring items like initial map views and types of real time data for which he would like audible notification. The system also tracks code and data versions to ensure that the user has the latest of both and can automatically download updates. A customer application support (and profiles) component 70 provides the functions of: (1) facilitating the storage and retrieval of user parameters and configuration information for customer applications; and (2) managing application version checks with the client that includes keeping track of map data updates.

A message logic & validation component 71 is responsible for the general maintenance and validation of all features of messaging for both the CIS 29 and the web servers 22. Messaging tasks initiated from a web server use this component for business logic implementation of all messaging related functions.

A dispatching logic & validation component 72 is responsible for dispatching and dispatch validation for all of the features implemented in the CIS and the web servers. Dispatching tasks initiated from the web server use this component for business logic implementation of all dispatching related functions.

An inbox component of inbox & outbox components 73 is responsible for listening to customer server 22 broadcast messages, and acts to maintain coherency between multiple customer servers. For example, when a site is created or purged, a customer server or other device sends a broadcast message, and the inbox listens for and routes the message to any connected customers it refers to. The outbox component is responsible for sending customer server 22 broadcast messages and customer message router (CMR) 27 broadcast messages, and acts to maintain coherency between multiple customer servers. For example, when a site is created or purged, the customer server sends a broadcast message indicating the operation that took place, and the broadcast message is sent by the outbox to identify to the CMR the trackers related to the customer server.

Customer administration component 53 is responsible for the general administration and validation of all features related to administration for both the CIS and the web servers. Administrative tasks initiated from the web server use the customer administration component to provide business logic. This component supports the functions of: (1) customer asset management; (2) client management; (3) customized feature management; and (4) maintaining Code/Lookup Tables.

Finally, a web support component 74 supports integration of web based applications, providing services for those applications for proper security, dataset, and function (role) access.

F. XML Data Channel Message Formats and Protocol

The XML (extensible Markup Language) data channel D 60 (FIG. 2) provides for all real time tracker messages to be pushed to web based applications, such as mapping, and other integrated applications. It also supports a complete command response protocol to enable any application to take advantage of the wireless network interfaces and location aware business logic 50 in the gateway 20. In an exemplary embodiment the protocol defined below uses the Microsoft XML parser shipped with Internet Explorer 5.0. The schema is intended to define and validate an XML payload that is passed between the CIS 29 and the client ActiveX control (“ActiveX” is Microsoft technology for an object oriented application architecture).

All messages are generally formatted identically in a standard message format. The message body contains the XML representation described under each message. All messages are sent and received in the format as shown in the examples below. Table 37 describes the items represented in any message.

MSG_LENGTH<MESSAGE_NAME REQID SOURCE NAMESPACE> MSG_BODY_TEXT</MESSAGE_NAME>

A typical message is similar to that shown below. All optional parameters are included for completeness, and the text of this message is as it would appear exactly, since XML data is very sensitive to inadvertent punctuation and spaces.

Assumptions are that:

- The RequestID parameter in all messages that include this parameter is automatically inserted if accessed through the CIS ActiveX control.
- Date/Time values are specified in GMT (Greenwich Mean Time) unless otherwise specified. Example: Saturday, Nov. 1, 1997 10:15:00 UTC
- Text fields that represent information, unless otherwise stated, are 64 characters in length maximum.

A CIS connection takes place as follows. The client application connects with a socket, and the CIS generates a login request which has an encryption key available to the client for encrypting messages. The encryption key is sent to the client application through a Login Response message, and the client application then returns a Login Result message that contains the result of the login attempt.

CIS connection related commands include a login request message with the format shown immediately below, containing a key value that is a base 64 encoded public key for use by the client in all requests requiring encryption. Table 38 illustrates the login field list for requests.

The connection related commands also include a login response message having the format shown immediately below that contains an encrypted version of the users credentials, including the customer name, user name, and password. This credential string is encrypted using the public key received from the login request. The encrypted credential string is then base 64 encoded for transmission to the server. Table 39 shows the message field definitions.

The login result message (format shown below) always returns a value. If it returns a failure, the client should expect that the socket will disconnect automatically. Table 40 gives message field definitions.

Logout is similar, with the logout request message format as follows.

The logout response message has the format shown below, with message field definitions given in Table 41.

The user is allowed to change his password at any time; the application use s the following message to accomplish this. A change password message contains an encrypted version of the users credentials, including the customer name, user name, and password. This credential string is encrypted using the public key received from the login request, and is then base 64 encoded for transmission to the server. The change password request message format is shown below, with message field definitions given in Table 42.

<ChangePasswordRequestID=“ ”xmlns=‘urn:schemas-griddata:ChangePassword> <OriginalCredentials></OriginalCredentials> <NewCredentials></NewCredentials></ChangePassword>

The change password response message is shown below, and field definitions are given in Table 43.

<ChangePasswordRequestID=“ ”xmlns=“urn:schemas-griddata:ChangePassword> <Status></Status></ChangePassword>

A failure message is returned if a message sent to the CIS fails for any reason such as being invalid, containing invalid formatting, containing invalid content, or causing a security infraction. The reason code provides a text description of why the message failed. Table 44 gives message field definitions.

Mapping application support includes use of a generic request and save function. When the mapping application needs to execute a request, it may use the GetMapParameters request function. This function has one element, the function type. All generic map functions return a standard response, which is the GetMapParameters response. This response contains one element, the status, which reflects the success or failure of the operation.

The GetMapParameters allows for a mapping application to receive persistent data stored in the gateway database. Table 45 contains the list of functions. The map parameter function request message format is:

Whenever map parameters are saved, a SaveMapParameters response message is received. If the result is not successful, the reason code is filled in with the cause for the failure. Table 46 shows message field definitions. The response message format is:

Map persistent data commands include county list response and save request messages, formatted as set forth below. This message enables the user to control the display with street level data for a particular county. This configuration will follow the user wherever he logs in. Table 47 contains message field definitions. The response message format is: