WO1997024010A1

WO1997024010A1 - Personal location services using a personal communication service mobility management infrastructure

Info

Publication number: WO1997024010A1
Application number: PCT/US1996/003503
Authority: WO
Inventors: Ravi Kumar Jain; Narayanan Krishnakumar
Original assignee: Bell Communications Research, Inc.
Priority date: 1995-12-22
Filing date: 1996-03-14
Publication date: 1997-07-03
Also published as: AU5252896A; TW396705B

Abstract

A value added personal location service for wireless communications system customers uses existing information in the wireless communication infrastructure to identify the cell or registration area in which a mobile terminal is currently located. In one example of the invention, a query processor (110, 302) receives a dispatcher query. The query processor communicates with existing communications network components and databases (106, 108, 124, 132) to determine the location of the requested vehicle or person. Queries may be customized to suit a particular customer's unique needs, such as locating a particular terminal, all terminals in a particular area, all terminals associated with one or more particular attributes, or a combination of the above.

Description

PERSONAL LOCATION SERVICES USING A PERSONAL COMMUNICATION SERVICE MOBILITY MANAGEMENT INFRASTRUCTURE Field of the Invention The present invention relates to wireless communications services and, more particularly, to a method and apparatus for using a Personal Communications Services (PCS) or other wireless communications system mobility management: infrastructure to provide personal location services. Background of the Invention

To administer efficiently a mobile workforce or fleet, a dispatcher should know the location of the mobile personnel or vehicles. The way this is currently done is via telephone or radio communications. This s inefficient, because the dispatcher typically must directly contact each worker or vehicle operator in order to determine his or her location. It may be a time consuming task to contact each person. Moreover, often one or more persons may not be able to be contacted. For example, a repairman may be away from a service vehicle equipped with a radio, or a salesperson may be on a cellular phone call.

Another problem is that a location of a mobile workforce or fleet is dynamic. A repairman near the location of an incoming emergency repair at one time may not be close to the location several minutes later. If this person is not contacted until several minutes after the incoming service call (which is quite possible if each person is directly contacted) , valuable time may be lost backtracking towards the location of the service emergency, or the person currently closest to the emergency location may not be identified as being in the closest location.

To overcome this problem, it has been proposed to provide a dispatcher with a personal location service (PLS) that allows the dispatcher to quickly determine the location of personnel or vehicles in service and/or in a certain geographic location. Several technologies have been considered for implementing a PLS. Candidate technologies include Global Positioning System (GPS) , Differential Global Positioning System (DGPS) , FM radio triangulation, and cellular basestation triangulation. These technologies have in common at least four drawbacks:

1. installing these technologies incurs substantial costs in addition to technology to communicate with the personnel (e.g., a cellular telephone or a two- way radio) ;

2. these technologies do not make use of relevant location information already residing in personal communication service (PCS) or wireless communications infrastructures;

3. they do not use the advanced features of existing telephone network facilities; and

4. they do not allow value added queries tailored to the requirements of particular customers. As seen in Fig. 1, an illustrative PCS system 100, a switched telephone network 102, such as a public switched telephone network (PSTN) or an Integrated Signaling Digital Network (ISDN) , is connected to a wireless communication system 104. An illustrative switched communications network includes a network database 106, such as a Bellcore proprietary Advanced Intelligent Network Service Control Point (SCP) . The database 106 is connected to a network server or intelligent peripheral (IP) 110, such as a Bellcore Proprietary Intelligent Services Peripheral. A database called a Home Location Register (HLR) 108 is part of the telephone network. The HLR may be part of the network database 106, located in another network component, or distributed among several components. Fig. 1 shows the HLR 108 as a separate network component. The database 106 and server 110 preferably communicate using the TA 1129+ protocol, but any suitable communication protocol may be used.

The database 106 is also connected via link 112 to a Regional Signaling Transfer Point (RSTP) 114. The RSTP 114 is connected via a number of links 116 to several Local Signaling Transfer Points (LSTPs) 118. Each LSTP 118 is connected via a number of local links 120 to a number of switches such as Service Switching Points (SSP) 122. The SSP 122 connects to customer premises to provide for premises equipment, such as a wireline telephone 123. An SSP 122 may also be connected to one or more Mobile Switching Centers (MSC) or Radio Port Control Units (RPCU) 124, which are part of the wireless communications system 104. The MSC (or RPCU) 124 is connected to a number of Base Stations (BS) (or Radio Ports (RP) ) 126, which monitor a "cell" (or "coverage area") 128. The cells (or coverage areas) 128 of the BSs (or RPs) connected to a single MSC (or RPCU) 124 define a registration area (RA) 130. It is currently proposed that an RA 130 may be between 2,500 - 15,000 feet. One or more MSC or RPCU 124 are connected to a second database called the Visiting Location Register (VLR) 132. One VLR 132 may cover a number of RAs 130.

The HLR 108 contains a database maintained by a user's local telecommunications service provider at the user's home location and includes information about the user, called the user profile. The VLR 132 is maintained by a local telecommunications service provider at the location the mobile user and mobile terminal or subscriber unit 134 are visiting. The VLR 132 stores a subset of the HLR user information and records that the mobile terminal 134 is currently located in the RAs serviced by that VLR. The HLR 108 keeps a record of the VLR in which the mobile terminal is currently registered.

When the mobile terminal 134 travels to a new RA 130 (e.g., switches to MSC or RPCU 124) the terminal is registered in the new MSC 12 . The location of the new RA is stored in the VLR 132. If the mobile terminal 134 travels to an RA 130 covered by another VLR 132, the subset of the HLR data stored in the previous VLR is transferred to the new VLR. The location of the new VLR is stored in the HLR and the previous VLR location is deleted from the HLR 108.

It is an object of the present invention to provide a PLS using communication technology which the dispatcher may also use to communicate with the mobile employee. It is another object of the present invention to provide a PLS using location information which is already maintained in PCS and other wireless communications networks. It is yet another object of the present invention to provide a PLS using existing telephone network facilities.

It is a further object of the present invention to provide a PLS which may allow customers to define unique queries .

Summary of the Invention

These and other objects of the invention are provided by the present invention. The present invention is a value added personal location service for wireless communications system customers using existing information in the wireless communication infrastructure to identify the cell or registration area in which a mobile terminal is currently located.

A dispatcher having the present invention may locate (1) each vehicle or person in a fleet equipped with a PCS device, (2) each equipped fleet vehicle (or person) located in a particular geographic area, (3) equipped fleet vehicles (or persons) having certain attributes, or (4) a combination of attributes and geographical location. Once located, the dispatcher may be able to communicate with the located vehicles or persons via the wireless communications system.

In a preferred embodiment, a query processor -- which may include a database of relevant customer information receives a dispatcher query. The query processor communicates with existing communications network components and databases to determine the location of the requested vehicle or person. The invention is preferably implemented using information stored in a PCS network infrastructure and information which may optionally be stored in client-specific databases. Brief DβBcription of the Drawings

The present invention is described with reference to the following figures:

Fig. 1 is a diagram illustrating a prior art Personal Communication System; Fig. 2A is a diagram illustrating an architecture for a first embodiment of the present invention using a "bundled" service; Fig. 2B is a message flow for the architecture of Fig. 2A using DTMF, and routing directly to the network server;

Fig. 2C is a message flow for the architecture of Fig. 2A using DTMF, and routing to the network database; Fig. 2D is a message flow for the architecture of Fig. 2A using a computer telephony integration with modem dial up, and routing directly to the network server;

Fig. 2E is a message flow for the architecture of Fig. 2A using computer-telephony integration with e-mail; Fig. 3A is a diagram illustrating an architecture for a second embodiment of the present invention using an "open" service;

Fig. 3B is a message flow for the architecture of Fig. 3A using DTMF; Fig. 4A is a message flow for a first type of dispatcher query requesting locations within a registration area;

Fig. 4B is an alternative message flow for the first type of dispatcher query;

Fig. 4C is a message flow for the same query as Fig. 4A requesting locations within an area smaller than a registration area;

Fig. 5A1 and 5A2 are a message flow for a second type of dispatcher query;

Fig. 5B is a message flow diagram for the query of Fig. 5A requesting locations within an area smaller than a registration area;

Fig. 6A is a first message flow diagram for a third type of dispatcher query;

Fig. 6B is a second message flow diagram for the third type of dispatcher query; and

Fig. 7 is a message flow diagram for a fourth type of dispatcher query.

Detailed Description, of Preferred Embodimenta System Architecture It is assumed that a wireless communication system 104 connected to a switched public telephone network 102 is already in place, as seen in Fig. 1, and that a fleet of vehicles or persons are equipped with mobile terminals 134.

In an exemplary embodiment, a dispatcher communicates with the communication system, i.e., calls into (or from) a designated number from a wireline telephone 123, transmits an e-mail, or sends a data communication. The communication is advanced to a network server or intelligent peripheral 110, which determines how to handle the communication. The server 110 queries the network database 106 for instructions on handling the communication. A. A "Bundled" Service

Fig. 2A shows a first illustrative embodiment of an architecture 200 for the present invention. Fig. 2A shows a "bundled" service. A "bundled" service is a service where the network server 106 controls the incoming communication and queries. A dispatcher terminal 202, such as a telephone or computer, is connected to the switched telephone network 102 via wireline telephone, e-mail, or other data access 204. The VLR 132 connects to a portion of a wireless communication system 104. The network database 106 interacts with the dispatcher terminal 202 via the network server 110. This interaction may take place in several different ways. A first way is through interactive voice or dual tone multi-frequency (DTMF or TouchTone) . A second way is through computer-telephony interaction or computer-telephony integration (CTI) .

1. A Bundled Service Using Interactive Voice/DTMF

Interactive voice or DTMF interaction allows a call processing record (CPR) 206, which may be part of a user profile stored in the network database 106, to instruct the network server 110 to play appropriate announcements to the dispatcher (i.e., prerecorded announcements if the communication is a telephone call) and collect responses from the dispatcher, using well known techniques. The responses may be provided using DTMF signals or voice activated responses (e.g., "If you want to locate vehicles currently located in Orange County, please say 'Yes' after the tone") . The announcements/responses may be used to authenticate the dispatcher (e.g., requiring an identification number) , or to obtain or narrow down the query. Call flows for this architecture are described in Figs. 2B and 2C. Fig. 2B provides an illustrative message flow 210 for a PLS using DTMF signal and routing the call directly to the network server 110. Signaling messages are represented with a single arrow, voice trunk messages are represented with a double arrow. A dispatcher initiates a telephone call to a predetermined dialed number (DN) (line 212) . The call is sent to a switch 122 and routed to a network server 110 according to the DN (line 214) . The call is held at the network server. The network server requests instructions from the network database 106 (line 216) . The network database may consult the CPR 206 and provides instructions to the network server 110 (line 218) . The network server, for example, may be instructed by the network database to send a voice message, such as an announcement, instructing the dispatcher to provide additional information to complete the query (line 220) . The dispatcher may provide the information using, for example, DTMF signals. The DTMF signals are received by the network server (line 222) . The network server takes these signals and requests further instructions from the network database (line 224) . Those signals essentially represent the dispatcher's query.

The network database 106 now acts as a query processor and receives and analyzes the dispatcher's query. Assume the query requests the location of a particular terminal. The query contains terminal identifiers with which the dispatcher is familiar (i.e. locate terminal 4) . The network database 106 consults the CPR 206 for a translation of the terminal ID into a terminal ID used by the communication system, called the PCS subscriber ID. Each mobile terminal 134 has a Mobile Identification Number (MIN) , which is stored in the terminal during manufacture and cannot be changed. Also associated with the mobile terminal 134 is a unique Electronic Serial Number (ESN) . Either of these identifiers, or a combination of them, may be used as the PCS subscriber ID used by the network. The CPR 206 is αsed by the network database to translate the dispatcher's terminal IDs into PCS subscriber IDs the network may use. The network database 106 sends to the HLR 108 a request for a location of the PCS user having that PCS subscriber ID (line 226) . The HLR obtains the location where the terminal is currently located (described in detail below) and sends it to the network database (line 228) . The database may convert the location identified by the network (such as a particular RA or cell) into a geographical region and converts the PCS subscriber ID back to the dispatcher's terminal ID. The network database sends to the network server instructions and the requested information (line 230) . The network server transmits messages providing the requested information to the dispatcher (i.e., a voice message "Terminal ID numbers 4 and 12 are located in Hudson County" ) .

Fig. 2C is an illustrative call flow 240 of a PLS using DTMF where the call is routed first to the network database. The dispatcher issues a telephone call to a predetermined dialed number (DN) (line 242) . The call is received at a switch 122, which holds the call. The switch then requests instructions from the network database 106 (line 244) . The network database may consult the CPR 206 and then may instruct the network server to reserve resources for processing the query (step 246) . The network server responds to the network database with a "success" message and phone number (step 248) . The "success" message indicates to the database that the server has reserved resources to handle the query, and the phone number is the number on which these resources are located. The network database sends to the switch an instruction to route the call to the network server using the phone number provided (line 250) . In response, the switch delivers the call to the network server at the telephone number provided (line 252) . The server holds the call. The network server then requests instructions from the network database (line 254) . The remainder of the call proceeds as shown in Fig. 2B.

2. A Bundled Service Using Computer-Telephony Interaction Computer-telephony Interaction (CTI) allows the network database 106 to interact with the customer's databases, which may reside in the network database 106, the dispatcher terminal 202, or other convenient location. This is implemented using known technology similar to known "800" number call routing, where the network database 106 queries the customer's database when an 800 number call is received to determine how to route the incoming call. Illustrative message flows for PLS using CTI are provided in Figs. 2D and 2E. Fig. 2D provides an illustrative message flow 255 of a PLS using CTI with a modem dial-up call and which routes the call directly to the network server 110. A dispatcher types a data message, which message is sent to a modem. The modem dials a predetermined dialed number (DN) and directs the call to a switch 122 (line 252) . The switch 122 routes the call to a network server 110 according to the DN (line 258) . The network server may have a modem connected to the server platform. The two modems set up a data connection (line 260) . The network server may send to the dispatcher terminal a query request such as "input terminal to be located" (line 262) . The dispatcher types a data message responding to the query, which message is sent to the network server 110 (line 264) . The network server 110 translates the dispatcher terminal ID into a PCS subscriber ID and requests instructions from the network database (step 266) .

The call flow proceeds in the same manner as shown in Fig. 2B up to the point where the responses are to be provided to the dispatcher. The network database 106 sends to the network server 110 instructions and the requested information (line 268) . The network server sends a data message to the dispatcher terminal providing the requested information (line 270) . The dispatcher terminal terminates the call (line 272) . In response, the network server clears resources in the network server dedicated to serving that query (line 274) .

Fig. 2E provides an illustrative message flow (line 275) of a PLS using CTI with e-mail. The dispatcher composes an e- mail message requesting certain information. The e-mail is transmitted via an interface over a data network such as the Internet (step 276) . The message is received by a network interface which connects to the network server platform (line 278) . The network server 110 may receive and parse the e- mail. The network server 110 then sends the query and requests instructions from the network database 106 (line 280) .

The call flow proceeds as in Fig. 2B until the requested information is to be provided to the dispatcher. The network database 106 sends instructions and the requested information to the network server 110 (line 282) . The network server 110 composes and sends to the data network an e-mail containing the requested information (line 284) . The data network delivers the e-mail to the dispatcher (line 286) .

Note that for any of the call flows described herein, the query may be either composed contemporaneously, or be a predefined query. If the dispatcher requests a predefined query, only a query number, for example, may be provided. The network database may use the collected information to select a predefined query in the CPR 206, for example, "identify all vehicles currently located in Orange County" . Once the query is selected, the network database 106 queries the relevant HLRs 108 as described.

B. An "Open" Service Fig. 3A shows a second illustrative embodiment of an architecture 300 for the present invention as an "open" service. An "open" service is similar to the "bundled" service, except that the query processing is performed in a database outside of the switched telephone network 102, which database is contained in a Location Information Server (LIS) 302. The LIS 302 contains a customer specific profile for the PLS. The LIS 302 may, for example, contain predefined queries for the customers. When the network database 106 receives the communication from the dispatcher, the CPR 206 for the customer is retrieved, and the network database 106 contacts the LIS 302, indicating that the communication requests location information. The database 106 relinquishes control of the call. The LIS 302 may obtain additional information about the dispatcher's request using either the CTI or voice interactive/DTMF techniques described above. This may be done by directly sending commands to the network server 110 or by communicating the commands to the network database 106, which then forwards them to the network server 110. Fig. 3B provides an illustrative message flow 310 for a PLS having an LIS using DTMF. A dispatcher places a telephone call to a predetermined dialed number (DN) (line 312) . The message is received by a switch 122 which routes the call to the appropriate network server according to the DN (line 314) . The network server 110 holds the call and requests instructions from the network database 106 (line 316) . The network database 106 may consult the CPR 206 and then sends a message to the network server 110, instructing it to connect the call to the LIS 302, which may be reached at a particular phone number (line 318) .

The network server 110 sends a message to the LIS 302 by setting up the call and providing the DN for the number dialed by the dispatcher and the caller ID, which is the number from which the dispatcher's call originated (line 320) . The LIS 302 sends a voice message, such as an announcement asking the dispatcher to provide additional information (line 322) . The dispatcher may enter the information using, for example DTMF tones, to provide information and complete the query (line 324) . Assume the query requests the location of a particular terminal. The LIS 302 receives the digits and may convert the terminal ID (i.e., "terminal 21") into a PCS subscriber ID (i.e., the EIN, MIN, or a combination) . Alternatively, this may be done by the network database 106. The LIS 302 requests the network server 110 to locate the terminal having this ID (line 326) . The network server 110 sends to the network database 106 the ID and a location request (line 328) . The network server 110 requests the HLR 108 to obtain the terminal's location (line 330) . How this is done is described below. The response is sent back to the network database 106 (line 332) . The network database sends the ID and requested information to the network server 110 (line 334) . Once the database receives the requested information, the network server 110 instructs the network database 106 to clear the resources servicing this request (line 336) . At about the same time, the network server 110 sends the PCS subscriber ID and requested information to the LIS (step 338) . The LIS may convert the PCS subscriber ID into a terminal ID and the network location into a geographic region, and announces the requested information to the dispatcher (line 340) . The dispatcher terminates the call (line 342) . Terminal Location Information

A mobile terminal's 134 location within a registration area (called the RA ID) is available from the HLR 108 and VLR 132, where this information is maintained in order for the wireless communications system 104 to route communications to and from the wireless terminal 134. The RA ID may be obtained by querying the relevant HLRs and VLRs . The RA ID locates a terminal within the area of an RA, e.g., between 2,500 and 15,000 feet. This may be sufficient for many applications. It may also be possible to locate the cell or coverage area 128 in which the mobile terminal is located. This information (called the cell ID) is not maintained in the VLR 132 or HLR 108, but in the MSC or RPCU 124. The cell ID may locate the mobile terminal within an area of a cell. For a PCS cell, for example, the terminal may be located within 250 - 1000 feet. The cell ID may be obtained in several ways. One way is for the MSC 124 to provide the cell ID to the VLR 132. A second way is for the VLR 132 to query MSCs or RPCUs 124 in a particular geographic area for the cell ID of a particular mobile terminal or set of mobile terminals. Regarding the first way for the VLR to obtain the cell ID, the MSC or RPCU 124 may provide the cell ID to the VLR and/or telephone system switch (a person skilled in the art recognizes that other network components may be involved in this transaction. For example, in certain PCS systems, an access manager may receive cell ID information) every time a mobile terminal registers or deregisters in a BS or RP 126; originates or terminates a call (e.g., sends or receives a call) ,- or participates in a call handoff between BSs or RPs 126.

This may be done with little or no technical alterations to the existing communications systems. For example, the European cellular telephone system, called the Global System for Mobil Communication or GSM system, locates the MSC and the VLR in the same physical piece of equipment. In North American systems, it is contemplated that in the near future the U.S. Federal Communications Commissions will require the cell ID to be provided to the telephone network switch to provide for cellular 911 service. Some cellular service providers already provide this service by replacing the Automatic Number Identification (ANI) field in the message from the MSC to the switch with the cell ID. This may be done for all communications in the present invention because the MSCs ANI is not particularly useful for wireless communications calls.

This approach may add significant traffic and processing burdens on the network infrastructure. Thus, it may be preferable for the cell IDs to be provided to the VLR/switch only for the users subscribing to the PLS. This may entail storing in the MSC or RPCU the PCS subscriber ID for each PLS subscriber.

Regarding the second way for the VLR to obtain the cell ID, the VLR 132 may query the MSCs or RPCUs 124 located in a particular geographic area for one or more particular mobile terminal. Query Processing

Once the dispatcher's query has been formulated, the query must be processed tc obtain the requested information. The query may be processed in the network database 106 or in the LIS 302, depending on the architecture, as described above. The general message flow depends on the architecture used, as described with reference to Figs. 2A-2C, 3A, and 3B.

Several types of queries are possible. Four possible query types are described to illustrate the invention. These queries are:

1. Locate a particular terminal;

2. Locate all terminals in a particular geographical area; 3. Locate all terminals having a particular attribute; and 4. Locate all terminals in a particular zone and having a particular attribute.

1. Query Onet Locate a Particular Terminal One query type requests the location of specific mobile terminals: "Locate terminals 4 and 12." Figs. 4A, 4B, and 4C are exemplary message flows for this query, where the terminal is to be located within an area of an RA (Figs. 4A, 4B) and within an area smaller than an RA (Fig. 4C) . In Fig. 4A, the dispatcher sends a communication to the query processor (line 402) , which may be a computer; the query processor may be located in the network database 106 or LIS 302, or otherwise distributed in the network 102. The query contains the terminal identifiers with which the dispatcher is familiar (i.e., terminals 4 and 12) . The network database 106 may consult the CPR 206 for a translation of the IDs into PCS subscriber IDs used by the communication system. The query processor queries the HLR 108 (either directly, if the query processor is the network database 106, or indirectly via the network database if the query processor is the LIS 302) where the information regarding the fleet is located to obtain the address of the VLR 132 where the terminals are currently located (line 404) . (Information about a fleet may be located in a number of HLRs, perhaps HLRs of different service providers. If so, a person skilled in the art readily recognizes that techniques exist for finding the appropriate HLRs, such as Global Title Translation) . If only the RA ID is requested and the VLR 132 has only one RA, the RA ID is sent to the query processor (line 410) . The processing is complete, and the query result is sent to the dispatcher. Otherwise, the VLR 132 is queried to determine the RA in which the terminal is currently registered (line 408) . The VLR sends the RA ID to the query processor (line 410) . If only the RA ID is requested, the processing is complete, and the query result is sent to the dispatcher (line 412) .

Fig. 4B is an alternative message flow 420 for obtaining an RA ID as shown in Fig. 4A. A dispatcher may issue a query for the location of a particular terminal (step 422) . The query is received by the network database 106, which may consult the CPR to convert the terminal ID into a PCS subscriber ID. The network database 106 issues to the HLR 108 an RA ID request (step 424) . The HLR 108 obtains the VLR ID and forwards to the VLR 132 the RA ID request (line 426) . The VLR responds to the HLR with the ID (step 428) . The HLR forwards the RA ID to the network database (step 430) . The query processor provides the dispatcher with the RA ID (step 432) .

Fig. 4C is an exemplary message flow 450 where the cell ID is required. The message flow is the same as in Fig. 4A or 4B (the illustrated message flow is the same as Fig. 4A) until the query processor requests the RA ID from the VLR (line 458) . The VLR obtains the cell ID for the terminal according to one of the methods described above. That is, either (1) the VLR is aware of the cell ID because the MSC or RPCU has already provided it to the VLR; or (2) the VLR queries MSCs located in a particular geographical area to determine the terminal's location. Assuming the second method is used, the VLR 132 requests the cell ID from the MSC or RPCU 124 (line 460) . The MSC provides the VLR with the cell ID (line 462) . The VLR forwards the RA and cell IDs to the query processor

(line 464) . The processing is complete, and the query processor sends the result to the dispatcher terminal (line

466) . 2. Query 2 : Locate Terminals in a Particular Area _

A second query type requests the identification of all fleet vehicles or persons in a geographic area: "Locate terminals in Zone 4" or "Locate terminals in Hudson County". Fig. 5A is an exemplary message flow 500 for this query, where the zone is no smaller than an RA. The query processor receives and analyzes the query, which includes one or more zone IDs with which the dispatcher is familiar (e.g., zone 4) (line 502) . The network database 106 may consult the CPR 206 for a translation of the zone IDs into zone IDs used by the communication system (step 504) . That is, the network database determines which RAs or cells correspond to the requested geographic region (i.e., zone 4 or Hudson County) . This translation may be stored in the user profile. Alternatively, the translation process may be performed by LIS 302.

The query is further processed by consulting several database tables stored in the query processor and VLR 132. Two such tables, for example, are:

Customer_Terminals (Customer, Terminal ID, . . . ) VLR_Terminals (Subscriber ID, RA ID, Cell ID, . . . ) where Customer_Terminals is a table containing a list of customers and each of the customers' terminal IDs; and VLR_Terminals is a table in each VLR containing a list of each RA served by that VLR and the PCS subscriber ID of each mobile terminal located in each served RA (and, if the system architecture is so structured, the cell ID in which each terminal is located) . Because Customer_rermina2s is typically stored in the network database 106 and VLR Terminals is typically stored in the VLR 132, the database operations could be implemented by a message set between the network database or query processor and the HLR, as shown.

The terminal IDs for the dispatcher's terminals are obtained from the Customer _^Terminals table (step 506) . These terminal IDs are converted into PCS subscriber IDs (step 508) . The query processor then sends to the HLR (1) a list of RA IDs falling in the requested zone; and (2) all PCS subscriber IDs for this dispatcher (step 510) . The HLR may consult tables to convert the PCS subscriber IDs to VLR IDs (step 512) , i.e., the HLR determines which VLRs serve each of the customer's terminals. Assume that the requested terminals are located in two VLRs, VLR 1 and VLR 3. The HLR sends to VLR 1 (D a list of RA IDs for this zone; and (2) all PCS subscriber IDs located in VLR 1 (line 514) . We refer to these lists as tables RA.ID and SUB . ID, respectively. VLR 1, for example, receives Tables RA.ID and SUB . ID. The VLR has a table of terminals registered in it called VLR_Terminals . The VLR finds the ID of any terminal (1) which is in the table SUB . ID; and (2) which is located in an RA which is in table RA.ID. This may be done by a database PROJECT and JOIN operation: PROJECT (subscriber ID, ((RA.ID JOIN VLR_ Terminals) JOIN SUB . ID) ) (step 516) . Alternatively, this may be done by transferring the appropriate information to the HLR or query processor.

The list of PCS subscriber IDs located in a requested RA is sent to the HLR 108 (line 518) . The same process is performed for VLR 3, which also sends a list of subscribers IDs located in its registration area (line 520) . The HLR 108 combines the list of subscriber IDs and sends it to the query processor (line 522) . Alternatively, the HLR may send back the two lists separately and these are combined by the query processor. The query processor converts the subscriber ID into dispatcher terminal IDs (step 524) . The converted IDs are sent to the dispatcher terminal 202 (line 526) .

Fig. 5B is an exemplary message flow 550 where the registered zone is smaller than an RA and one or more cell IDs are required. The message flow is same as in Fig. 5A (line 552-556) until the VLR_ Terminal request reaches the VLR 132. The VLR then requests the cell ID frcm the MSC 124 (line 558) .

The MSC 124 obtains the requested cell ID and sends it to the

VLR 134 (line 560) . The VLR obtains the cell ID in one of the methods described above (line 560) . The cell ID is added to the VLR Ter inal, and the VLR sends the table to the HLR (line

562) which sends the table to the query processor (line 564) .

The query result is sent to the dispatcher terminal line 202

(line 566) .

3. Query Three: Locate Terminal Associated with a Particular Attribute

A third query type specifies attributes of the vehicle or person associated with the mobile terminal: "Locate terminals in vehicles having more than 1 ton capacity". Fig. 6A is an exemplary message flow 600 for this query. The dispatcher sends to the query processor a query requesting information relating to an attribute (i.e., vehicles having > 1 ton capacity) (line 602) . The network database may consult the CPR 206 for terminal IDs for all vehicles in the fleet meeting the parameter. This information may be stored in the user profile or the LIS 302. This may be done using a database SELECT operation as follows. Suppose the CPR contains a table called Customer _Terminals (Customer, Terminal. ID, Capacity) which identifies the customers, the terminals belonging to each customer, and the capacity of the vehicle in which the terminal is installed. The relevant terminals for the dispatcher "Joe Smith" could be found by: SELECT (customer=Joe Smith and capacity > 1 ton, Customer _Terminal ) . The relevant terminal IDs are thus obtained, and converted to PCS subscriber IDs.

For each terminal ID, the query processor queries the HLR where the information regarding the fleet is located to obtain the address of the VLR where the terminal is currently located

(line 604) . The VLR ID is obtained and returned to the query processor (line 606) . Each such VLR is queried to determine in which RA the terminal (s) is (are) currently registered

(line 608) . If the requested area is smaller than an RA, the

VLR obtains the cell ID using one of the methods described above. For example, the VLR may query the appropriate MSC(s) or RPCU(s) (line 610) . The cell ID is sent to the VLR (line 612) , and the VLR sends the cell ID and RA ID to the query processor (line 614) . The query result is sent to the dispatcher terminal (line 616) .

Fig. 6B illustrates an alternative method 650 for processing this third query. The dispatcher sends to the query processor a query requesting information relating to an attribute (i.e., vehicles having > 1 ton capacity) (line 652) . The network database may consult the CPR 206 for terminal IDs for all vehicles in the fleet meeting the parameter as described above. The query processor sends to the HLR an Info_Terminal request (line 654) containing the PCS subscriber IDs, meeting the requested attribute. The HLR forwards the Info_Terminal request to the relevant VLRs (line 656) . If the requested area is smaller than an RA, each such VLR obtains the cell IDs using one of the methods described above. For example, the VLR may query the appropriate MSC(s) or RPCU(s)

(line 658) . The cell ID is obtained and returned to the VLR and included in the Info Terminal (line 660) . The Info- _Terminal table is sent to the HLR (line 662) , and then to the query processor (line 664) . The response is forwarded to the dispatcher (line 666) .-

4. Query Four: Locate a Terminal in a Particular Area and Associated With A

Particular Attribute

A fourth query type specifies a number of criteria: "Locate terminals in vehicles having more than one ton capacity and located in Zone 4". Fig. 7 is an exemplary message flow 700 for this query. The dispatcher sends to the query processor a query requesting information relating to a particular area and a particular attribute (i.e., vehicles in zone 4 and having > 1 ton capacity) (line 702) . The network database may consult the CPR 206 for a translation of the zone IDs into zone IDs used by the communication system. The network database may also consults the CPR or customer profile database, to determine information regarding vehicle capacity as previously described. The RA IDs for the requested zone and the PCS subscriber IDs associated with the attribute are sent to the HLR (line 704) . The subsequent processing proceeds as shown in Fig. 5A. The combined list of PCS subscriber IDs is sent to the query processor (line 706) . The query result is sent to the dispatcher (line 708) . Return of Results

For the results of the query to be reported meaningfully to the user, certain parameters, such as PCS subscriber IDs or VLR IDs, may need to be translated into identifiers or geographic locations the user understands. Thus, a look-up table or database may be used to translate a PCS subscriber ID

(i.e., a MIN) into a terminal identifier the customer understands (i.e., terminal 4) . The translated information may be delivered to the dispatcher or dispatcher terminal in a number of ways, including facsimile, e-mail, radio mail, pager, or converted into synthesized speech and delivered to a voice mailbox, wireline phone, or mobile phone. A communication between the dispatcher and one or more of the located terminals may be initiated. If a number of terminals are located, the calls may be connected sequentially.

Conclusion

A low-cost system for providing a PLS is described. The invention has the following advantages which differentiate it from other known technologies:

1. The PLS according to a preferred embodiment of the present invention uses existing hardware and requires no additional user equipment, thus reducing the incremental costs and, ultimately, the cost to the customer.

2. The location may be obtained within a registration area (2,500-15,000 feet) or within a cell (250-1,000 feet) , which is sufficient for applications such as taxicab or messenger location. Other known technology attempts to locate a user to within 10- 200 feet, which may be more precise than needed, except in a certain limited applications, such as enhanced 911 service.

3. The system uses and adds value to information already available within certain components of wireless communications networks, such as information already contained in the HLR and VLR databases and the RPCU or MSC.

4. It uses the switched telephone networks allowing, among other advantages, the service to be accessed from any telephone and also allowing customer information to be stored in central, highly reliable network databases.

5. It permits customer specific queries based on a customer's criteria. 6. Once a terminal is located, a wireless communication may also be automatically initiated, if desired. A person skilled in the art understands that the invention may be used with any wireless communication system that maintains user location information. For example, although a PCS system was disclosed, it is understood that PACS, cellular, or other wireless communication system may also be used. The above described embodiments of the invention are intended to be illustrative only. Numerous alternative embodiments may be devised by those skilled in the art without departing from the spirit and scope of the following claims .

APPENDIX A

Appendix of Acronyms

ANI Automatic Number Identification

BS Base Station

CPR Call Processing Record

CTI Computer-telephony interaction or Computer-telephony integration

DGPS Differential Global Positioning System

DN Dialed Number

DTMF Dual Tone Multiple Frequency

ESN Electronic Serial Number

GPS Global Positioning System

GSM Global System for Mobile Communication

HLR Home Location Register

ISDN Integrated Signaling Digital Networks

IP Intelligent Peripheral

LIS Location Information Server

LSTP Local Signaling Transfer Point

MIN Mobile Identification Number

MSC Mobile Switching Center

PCS Personal Communication Services

PLS Personal Location Services

PSTN Public Switched Telephone Network

RA Registration Area

RP Radio Port

RPCU Radio Port Control Unit

RSTP Regional Signaling Transfer Point

SCP Service Control Point

SSP Service Switching Point

VLR Visiting Location Register

A-l

Claims

We claim :

1. An apparatus for providing personal location services for a communications system customer, the communications system maintaining mobile terminal location information, the apparatus comprising: a. a network database connected to a query processor, the database configured to maintain customer information; and b. a query processor configured to: (1) receive a query from the customer;

(2) communicate with the communications system and to obtain mobile terminal location information in response to the query; and

(3) provide the obtained terminal location information to the customer.

2. The apparatus of claim 1, wherein the network database maintains information regarding attributes associated with mobile terminals of the customer.

3. The apparatus of claim 1, wherein the network database includes a call processing record.

4. The apparatus of claim 1, wherein the network database includes at least one predefined query.

5. The apparatus of claim 1, wherein the query processor is configured to receive the query in the form of dual tone multiple frequency signals.

6. The apparatus of claim 1, wherein the query processor is configured to receive the query in the form of interactive voice communications .

7. The apparatus of claim 1, wherein the query processor is configured to receive the query in the form of a data message.

8. The apparatus of claim l, wherein the query processor is configured to receive the query in the form of an e-mail message.

9. The apparatus of claim 1, wherein the query processor resides in at least one of a server and a database for the communications system.

10. The apparatus of claim 1, wherein the query processor is a location information server residing outside of the communications system.

11. A method for providing personal location services for a communications system customer, the communications system maintaining mobile terminal location information, comprising the steps of : a. receiving from a customer a terminal location query; b. obtaining terminal location information from the communications system; and c. reporting the terminal location information to the customer.

12. The method of claim 11, wherein after the step of receiving the query, converting a terminal identifier into a communications system user identifier.

13. The method of claim 11, wherein before the step of reporting the terminal location information, converting the terminal location information into at least one of geographical information and terminal identifier.

14. The method of claim 11, wherein the step of obtaining terminal location information comprises obtaining a registration area identification from a visiting location register.

15. The method of claim 11, wherein the step of obtaining terminal location information comprises obtaining a cell identification from one of a mobile switching center and a radio port control unit.

16. The method of claim 11, wherein the query requests identification of all of a user' s terminals in a particular area, the method further comprising the steps of: a. before the step of obtaining terminal location information: i. determining each registration area (RA) corresponding to the particular area; and ii . determining subscriber identifiers for each of the user's terminals; and b. the step of obtaining terminal location information includes the steps of : i. determining which visiting location register is currently serving each of the user's terminals; ii. determining which RA each of the user's terminals is located in; and iii. comparing the determined terminal identifiers, the determined RAs in which each user terminal is located, and the RAs corresponding to the particular area.

17. The method of claim 11, wherein the query requests identification of all terminals associated with a particular attribute, the method further comprising: a. before the step of obtaining terminal location information determining terminal identifiers for each of the customer's terminal associated with the attribute; and b. the step of obtaining terminal location information comprises: i. determining which visiting location register is currently serving each of the user's terminals associated with that attribute; ii. determining which RA each of the user's terminals is located in; and iii. comparing the determined terminal identifiers with the user terminals located in each registration area.

18. The method of claim 11, wherein the query requests identification of all terminals associated with a particular attribute, the method further comprising: a. before the step of obtaining terminal location information, determining terminal identifiers for each of the customer's terminals associated with the attribute; and b. the step of obtaining terminal location information further comprises consulting a Info_Terminal database; and c. comparing the determined terminal identifiers and

Info_Terminals database entries to determine if any of the customer' s terminals associated with the attribute are located in RAs covered by that VLR.

19. A method for identifying to a visiting location register (VLR) a cell in which a mobile terminal is located, comprising the steps of: a. one of a radio control port unit and a mobile switching center providing the VLR with a cell identification for the terminal each time the mobile terminal is involved in a transaction; and b. the VLR storing the cell identification provided.

20. The method of claim 19, wherein the step of providing the cell identification further comprises replacing an Automatic Number Identification field with the cell identification in a message to the VLR.

21. A method for identifying to a visiting location register (VLR) a cell in which a mobile terminal is located, comprising the step of querying each mobile switching center located in a geographic area if the mobile terminal is located therein.