WO2002012912A2

WO2002012912A2 - Methods and apparatus for dynamically determining location using a simplified client device

Info

Publication number: WO2002012912A2
Application number: PCT/US2001/024845
Authority: WO
Inventors: Sherk Chung; Andrew Chou; Benjamin Van Roy
Original assignee: Enuvis, Inc.
Priority date: 2000-08-08
Filing date: 2001-08-07
Publication date: 2002-02-14
Also published as: WO2002012912A3; TW533320B; AU2001281180A1

Abstract

A location determination system ('LDS') determines the location of a thin-client device from a location server to significantly reduce the computational requirements on the client and to permit implementation of more accurate and efficient location calculations on the location server. The client device pre-processes a reference signal, such as a GPS signal, to generate reference data. The pre-processed reference data is transmitted from the client device to the location server via a communications link, such as a wireless link or a combination wireless and global communications network.

Description

METHODS AND APPARATUS FOR DYNAMICALLY DETERMINING LOCATION USING A THIN-CLIENT DEVICE

CROSS-REFERENCES TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Patent Application No. 60/223,873, filed August 8, 2000, entitled "Thin-Client Location Determination Utilizing RF Signals Over A Communications Link."

BACKGROUND OF THE INVENTION Field of the Invention:

The present invention is directed toward the field of location determination technology, and more particularly towards determining location from a thin-client device.

Art Background:

In general, location technology determines the location, position or coordinates (e.g., in either two or three dimensions) of a "device." As used herein, a device or client device refers to any remote device for which the location is desired. One application for location technology is determining the location of a mobile device, such as a cellular telephone. There are several applications or uses for determining the location of a mobile device. For example, if a cellular telephone user with an emergency dials "911", it is desirable to permit the 911 emergency response team to immediately identify the location of the cellular telephone user. Location technology for mobile devices also has applications for use with the Internet. For example, a mobile Internet user may desire to locate a particular good or service near the current location of the user. If the location of the mobile device is known, then the location may be used to direct the user to the nearest good or service in that area. The global positioning system ("GPS") is one available technology for identifying location. Using traditional GPS techniques, users may identify their positions, which include latitude, longitude and altitude, using GPS receivers. In traditional GPS, the GPS receiver acquires signals from four or more different satellites to obtain a three dimensional location. The GPS positioning system uses a constellation of satellites that orbit the earth. Only a certain number of satellites are "visible" to a GPS receiver at a particular time. Because the GPS receiver must acquire multiple signals to determine a location, most GPS receivers employ multiple channels. Each channel attempts to acquire a GPS signal. Once the receiver channel has acquired the GPS signal, additional processing occurs to track the GPS signal. Under traditional approaches, the

GPS receiver ascertains, for four or more GPS signals, its distance from the satellite by comparing its local time with the time in which the GPS signal was transmitted from the satellite, h addition, the GPS receivers compensate for clock errors and changes in frequency due to Doppler shift, as well as read satellite navigation messages. These distances, along with the known locations of the satellites, are used to determine the position of the GPS receiver.

Although current GPS receivers provide accurate information regarding location, those receivers comprise form factors that are large relative to the size of a mobile device. For example, even the smallest current implementations of GPS receivers consist of a few integrated circuit chips. These additional integrated circuit chips increase the total amount of integrated circuits used in cellular telephones to an unacceptable number. In addition, the cost to implement a GPS receiver on all mobile devices, such as cellular telephones or personal digital assistants ("PDAs"), is prohibitive, and GPS receivers consume significant power that unacceptably degrades the overall battery life of the mobile device. Furthermore, the time to fix on a location using tradition GPS techniques is significant. Therefore, it is desirable to provide solutions for mobile devices that permit these devices to accurately and cost effectively determine their position.

SUMMARY OF THE INVENTION In a dynamic thin-client location determination system, the quality and quantity of the reference data, generated at a thin-client device, changes "dynamically" at the request of the server. For this embodiment, the thin-client device transmits reference data to the server, and the server generates and transmits a "server response" to the client device. In one embodiment, the server response consists of a location and/or a "location calculation response code" ("LCRC"). The LCRC is an instruction to the client device, h one embodiment, the LCRC instructs the client to perform one or more of the following commands (but is not limited to only using these commands): 1) use the location contained in the response; 2) transmit more samples from the reference signal buffered at the client device, 3) acquire a new reference signal and transmit new reference data to the server for further calculation of a location; 4) perform additional pre-processing on the reference signal to calculate new reference data, or 5) inform the user of the client device that a location cannot be determined. In one embodiment, the client also downloads the software from the server to interpret LCRCs, and in another embodiment, the server may "push" software to the client device to interpret LCRCs.

In another embodiment, the location server employs multiple algorithms. For this embodiment, the location server uses one or more of the location calculation algorithms to calculate the client's location. The server receives a location calculation request, parses the request to obtain the reference data, and obtains aiding data. The server selects one or more algorithms, and calculates the location using those algorithms. If the algorithm was successful, then a response is generated. If the algorithm was not successful, then one or more new algorithms are applied, and new locations are calculated. If all the algorithms have been tried, then an error code is generated as the response. The response is sent to the client.

In another embodiment, the location server processes the reference data using multiple algorithms in parallel. The server receives a location calculation request, parses the request to obtain the reference data, obtains aiding data, and calculates multiple locations in parallel. The location server selects the best result, creates a response, and sends the response. In another embodiment, the server receives a location calculation request, parses the request to obtain the reference data, and obtains aiding data. Embedded in the request is also a command identifying a specific algorithm or a class of algorithms to use in the calculation of a location. The location server calculates a location using a specified algorithm or algorithms, creates a response, and sends the response. In other embodiments the server, rather than the client, makes the determination of which algorithm or algorithms to use to calculate a location. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a block diagram illustrating one embodiment for the thin- client location determination system. Figure 2 is a flow diagram illustrating one embodiment for determining client location in the LDS system.

Figure 3 is a flow diagram illustrating another embodiment for determining client location in the LDS system.

Figure 4 is a flow diagram illustrating one embodiment for using location tracking numbers in a LDS system.

Figure 5 is a block diagram illustrating one embodiment for the client device.

Figure 6A is a block diagram illustrating one embodiment for a client device that consists of separate units. Figure 6B is a block diagram illustrating another embodiment for a client device that consists of separate units.

Figure 7 is a block diagram illustrating one embodiment for modifying a mobile device to include the thin-client LDS.

Figure 8 is a block diagram illustrating one embodiment for communicating between the client device and the location server.

Figure 9 is a block diagram illustrating one embodiment for a carrier network, network communications, and server.

Figure 10 is a block diagram illustrating one embodiment for communicating between the client device and the location server over wireless networks. Figure 11A is a block diagram illustrating one embodiment for the location server.

Figure 1 IB illustrates another embodiment for the location server.

Figure 12 illustrates a block diagram of a location server for an LDS that utilizes location tracking numbers.

Figure 13 is a flow diagram illustrating high-level processes for the location server.

Figure 14A is a flow diagram illustrating one embodiment for generating location tracking numbers in conjunction with a request to calculate a client location.

Figure 14B is a flow diagram illustrating one embodiment for processing at the server requests with location tracking numbers.

Figure 15 is a flow diagram illustrating another embodiment for additional pre-processing in the client device. Figure 16 is a flow diagram illustrating one embodiment for downloading algorithms to the client device.

Figure 17 is a flow diagram illustrating one embodiment for implementing dynamic data transmission in a thin client location determination system. Figure 18 is a flow diagram illustrating one embodiment for dynamically determining location in a server.

Figure 19 is a block diagram illustrating one embodiment for a location server that dynamically determines location.

Figure 20A is a block diagram illustrating one embodiment for a location server that employs multiple algorithms. Figure 20B is a block diagram illustrating one embodiment for a location server that employs a single algorithm.

Figure 20C is a block diagram illustrating another embodiment for a location server that employs multiple algorithms. Figure 21 is a flow diagram illustrating one embodiment for use of multi-algorithms in the server.

Figure 22 is a flow diagram illustrating another embodiment for use of multi-algorithms in the server.

Figure 23 illustrates a location determination server that receives information from a variety of sources .

DETAILED DESCRIPTION

Overview of the System Architecture: The thin-client location determination system determines a location of a client from a "reference signal." In general, a reference signal, as used herein, connotes any type of signal, or a combination of signals, from which location information may be derived. In one embodiment, the reference signal consists of a Global Positioning System ("GPS") signal that the location server utilizes to identify a location of the client. Embodiments for processing GPS signals to obtain a client location are described more fully below. In other embodiments, the reference signal comprises an "air interface signal." As used herein, air interface signals connote any type of signals used to transmit information over a wireless medium, including, but not limited to, CDMA signals, GSM signals, TDMA signals, CDPD signals, W-CDMA signals, CDMA-2000 signals, PHS signals, iDEN signals, EDGE signals, GPRS signals, analog cellular radio signals, or specialized mobile radio ("SMR") signals. As used herein, TDMA signals include both GSM signals and IS-136 signals. In other embodiments, the reference signal is transmitted from a beacon transmitter, or the reference signal includes a LORAN signal. h one embodiment, to derive a location from air interface signals, the thin-client location determination system, using known locations of the base stations, calculates a time difference between signals transmitted to the client device from different base stations. For this embodiment, the client device receives the air interface signals, performs one or more types of pre-processing

(discussed below), and transmits, as reference data, the air reference signals to the location server. The location server calculates the location based on the time difference between signals transmitted to the client device from different base stations. In another embodiment, the thin-client location determination system may obtain an approximate client location from base station signal strength. For this embodiment, the client device receives the air interface signals, performs one or more types of pre-processing (discussed below), and transmits, as reference data, the signal strengths of the air interface signals to the location server. The location server calculates the location based on the signal strength contained as reference data. In a further embodiment, the thin-client location determination system calculates a time difference between signals transmitted to the client device from different client devices with known locations.

Figure 1 is a block diagram illustrating one embodiment for the thin- client location determination system. For this embodiment, the thin-client location determination system ("LDS") consists of the client device 105 and a location server 140. The client device 105 may consist of any type of a mobile device, including portable devices, such as cellular telephones. The location server, as used herein, refers to any computational resource, such as one or more computers or servers. For example, the location server may comprise an HTTP server operating in conjunction with an application server. As shown in Figure 1, the client device 105 is coupled to the location server via a communications link 130. The communications link 130 may consist of any type of communications. In one embodiment, the communications link 130 consists of a wireless communications system, such as a wireless telephone network, used in conjunction with a network, such as a private network or the Internet.

The client device 105 contains a reference signal pre-processor block 110, a protocol encoder 115, and a communications module 120. In general, the reference signal pre-processor block 110 receives electromagnetic signals (e.g., RF signals), and pre-processes the reference signal to generate a digitized reference signal. The digitized reference signal is referred to herein as part of the "reference data." Various embodiments to pre-process reference signals are described more fully below.

The protocol encoder 115 formats the reference data, in compliance with a required channel or link protocol, to generate a client message for transmission. In one embodiment, if the client device utilizes a bearer protocol, such as the General Packet Radio Services ("GPRS"), Circuit Switched Data ("CSD"), Short Message Service ("SMS"), Fast Associated Channel ("FACCH"), Slow Associated Channel ("SACCH"), Enhanced Data GSM Evolution ("EDGE"), or high data rate ("HDR"), the protocol encoder 115 formats the reference data, in accordance with the bearer protocol, to generate a client message. At a minimum, the reference data includes samples of the reference signal. In other embodiments, the reference data includes additional data appended to samples of the reference signal. In one of these embodiments, the reference data may include a client device time stamp that indicates the local time the reference signal was received at the client. In other embodiments, the reference data may indicate the signal strength of the reference signal, and/or may specify the present value of the mobile transmitter timing advanced setting, and/or an identification for the client device. In other embodiments, the reference data is compressed prior to transmission to the server. For these embodiments using compression, the client device may employ, by way of example, Huffman encoding, LZW, run length coding, or other compression algorithms.

The communications module 120 receives, as input, the reference data (formatted in accordance with a protocol or reference data alone), and generates, as an output, a communications signal suitable for transmission on typically bidirectional communications link 130. In one embodiment, if communications link 130 comprises a wireless communication link, then communications module 120 generates a signal for the wireless communications transmission (e.g., a CDMA, TDMA, or other signal).

The location server 140 receives the client message from the communications link 130. To this end, the location server 140 includes a communications module 150. In general, the communications module 150 provides an interface to the communications link 130. The communications module 150 passes the client message, including the reference data, to location processor 160. In one embodiment, the location processor 160 determines the location of the client device from the reference data. In other embodiments, location processing 160 generates a message to acquire more data at the client device before determining the client's location. The location server 140 transmits to the client the server message, which may include client location or a request for more data, or transmits the client location to a third party, h one embodiment, the location server 140 transmits the client location or server message to the client device 105 via the communications link 130. The location server 140 may transmit the client location to a third party, such as another server or another client device, via the communications link 130, using a location tracking number. For example, location server 140 may transmit the client location to another server via the Internet or a private network.

Figure 2 is a flow diagram illustrating one embodiment for determining client location in the LDS system. For this embodiment, the client device initiates a process to calculate the client's location at the location server. For example, a mobile subscriber dials the North American emergency response telephone number 911. Doing this initiates a process that inter alia starts the present process shown in Figure 2. The client device receives and pre-processes the reference RF signal to generate reference data (block 200, Figure 2). In one embodiment, the client device receives a GPS signal and samples the GPS signal to create a digitized GPS signal or GPS data. The client device transmits the reference data to location server (block 210, Figure 2). The location server receives the reference data, calculates a location for the client device, and sends the location to the client (blocks 220, 230 and 240, Figure 2). In turn, the client device receives the location from the server (block 250, Figure 2). Figure 3 is a flow diagram illustrating another embodiment for determining client location in the LDS system. For this embodiment, the location server initiates a process to determine the client's location. The location server transmits to the client device a request for reference data (block 300, Figure 3). The client device receives the server request for reference data, and initiates a process to acquire an RF signal (block 320, Figure 3). For example, if the reference signal comprises a GPS signal, then the client device initiates a process to receive a band of GPS signals. The client device receives and processes the reference signal (e.g., GPS signal) to generate the reference data (block 330, Figure 3). The client device then transmits the reference data to location server (block 340, Figure 3). The location server receives the reference data from the client device, and calculates the client's location from the reference data (blocks 350 and 360, Figure 3).

Figure 4 is a flow diagram illustrating one embodiment for using location tracking numbers in an LDS system. For this embodiment, a location tracking number, unique to a client's location, is generated to provide an identification for retrieval of the client's location. The LTN may include the client's identification as well as a time stamp. The use of LTNs provide several benefits. For example, the LTN provides anonymity to the user of the client device, and provides the ability to store and retrieve historic locations of the client device. The location tracking number has applications for use with third parties. Specifically, a third party may use the location tracking number to generate a request to a server to identify the location of the client device. For this embodiment, the process is initiated at the client device as the client receives and processes the RF reference signal (e.g., GPS signal) to generate the reference data (block 400, Figure 4). The client transmits the reference data to the location server (block 405, Figure 4). The location server receives the reference data from the client device and calculates the client's location (blocks 410 and 415, Figure 4). In addition, the location server creates a location tracking number corresponding to the current client's location, and stores the client location (block 420, Figure 4). The location server transmits the location tracking number to the client (block 430, Figure 4). The client device receives the location tracking number from the server, and forwards the location tracking number to a third party (blocks 440 and 450, Figure 4). In one embodiment, the third party is a content provider, such as a directory of goods and services. The third party receives the location tracking number from the client device, and in turn, generates a request to the server that includes the client's location tracking number (blocks 455 and 460, Figure 4).

The location server receives the location tracking number from the third party, and obtains the client's location using the location tracking number

(blocks 465 and 470, Figure 4). In one embodiment, the location server utilizes a database to store client locations, and retrieves client locations based on location tracking numbers. In response to the third party's request for the client's location, location server transmits the location data to the third party (block 475, Figure 4). The third party receives the server response with the client location (block 480, Figure 4). With the client's location data, the third party may execute any number of applications. For example, the third party may provide, in response to a request from client, a list of restaurants in the general area of the client's location. Thin-Client Device Embodiments:

Figure 5 is a block diagram illustrating one embodiment for the client device. For this embodiment, a client device 500 includes, in addition to the protocol encoder/communications module 560 and reference signal pre- processor 510. The reference signal pre-processor 510 contains an RF antenna

520, a RF module 530, and an analog to digital ("A/D") converter 540. For this embodiment, reference signal pre-processor 510 receives an RF signal on the RF antenna 520. The RF antenna 520 and associated circuitry receives one or more RF signals at various carrier frequencies. For example, if the reference signal is a GPS signal, then the RF antenna receives the GPS signal at the LI and or L2 GPS carrier frequencies. Similarly, for other reference signals, the RF antenna 520 receives those signals at the appropriate carrier frequency. The RF module 530 receives the RF signal from the RF antenna 520, and demodulates the reference signal. The output of the RF module 530, the reference signal, is input to the

A/D converter 540. The A/D converter 540 pre-processes the reference signal by sampling and digitizing the reference signal to generate the reference data. For this embodiment, the A D converter samples at the Nyquist rate or a modified Nyquist rate to accommodate the accuracy dictated by the digital precision of the samples. However, any sampling rate that produces adequate precision may be used. Also, the A/D converter 540 may directly sample the waveform from RF module 530, or may sample in phase and quadrature phase ("I/Q") channels of the waveform. The reference data from the A/D converter 540 is input to a protocol encoder / communications module 560 for encoding and transmission of the reference data on the communications link 130 (Figure

1).

In one embodiment, the RF module 530 outputs the reference signal, as an RF signal, to the A/D converter 550. The A/D converter 530, in turn, samples the RF reference signal and produces a digital code value to represent the sample. In a second embodiment, instead of sampling the reference signal at an RF frequency, the reference signal processor 510 down converts the RF reference signal to an intermediate frequency ("IF") reference signal. For this embodiment, the down conversion may occur as a single or a double conversion. The A/D converter 530 receives the IF reference signal, samples the IF reference signal, and produces a digital code value to represent the sample. In a third embodiment, the RF module 530 down converts the RF reference signal to a baseband reference signal. In one embodiment, the RF module 530 performs a double conversion. In other embodiments, the RF module 530 performs a single conversion to directly convert the RF reference signal to the baseband reference signal. The baseband reference signal is input to the A/D converter 550. The A/D converter 570 samples the baseband reference signal, at a sampling rate that accommodates the bandwidth of the reference signal, to generate the reference data. Figure 6A is a block diagram illustrating one embodiment for a client device that consists of separate units. For this embodiment, the client device includes a reference signal receiver 620 and a wireless device 600. The reference signal receiver 620 communicates to the wireless device 600 via a communications link 610. The wireless device 600 may comprise any type of device that employs wireless communications, such as a wireless telephone and/or a personal digital assistant ("PDA"). The wireless device 600 communicates to the location server (130, Figure 2) via the communications link 130 (e.g., wireless communications link). The reference signal receiver 620 includes the reference signal pre-processor 510. In one embodiment, the reference signal receiver 620 comprises a GPS receiver. The communication link 610, which couples the reference signal pre-processor 510 with the wireless device 600, may be any type of communications link, including a wireless communications link (e.g., RF or infrared), as well as a wire link that employs either serial or parallel data transfer. Figure 6B is a block diagram illustrating another embodiment for client device that consists of separate units. For this embodiment, in addition to a separate reference signal receiver and a wireless communications module, the client device further includes a separate mobile device 630. In general, the mobile device 630 includes hardware and software to implement various mobile device applications. For example, the mobile device 630 may consist of a PDA.

The communications module 660 {e.g., cellular telephone) includes the communication module 120 to communicate to the location server over the communications link 130. As shown in Figure 6B, the reference signal receiver 620 (e.g., GPS receiver) communicates with the mobile device 630 via communication link 640, and the communications module 660 communicates with the mobile device 630 over communications link 650. The communication links 640 and 650 may be any type of communication link, including a wireless link (e.g., RF or infrared), as well as a wire link that employs either serial or parallel data transfer. In one embodiment, the reference signal receiver 620 may communicate to wireless device 600 via a wireless local area network (e.g., 802. l ib standard).

Figure 7 is a block diagram illustrating one embodiment for modifying a mobile device to include the thin-client LDS. For this embodiment, a mobile device 700 includes, to receive data/information, an RF antenna 710, an RF module 720 and an A D converter 740. For example, the RF module 720 may be used to receive and process air interface signals that carry data and/or voice. Also, the mobile device 700 includes digital signal processor ("DSP"), labeled 760 on Figure 7, to process the air interface signals. In one embodiment, to implement thin-client LDS functionality, the circuits of a mobile device are modified to receive analog reference signals at different carrier frequencies and to process reference signals with different bandwidths. For example, if the reference signal is a GPS signal, then the receiver circuits (i.e., tuner) of the mobile device is modified to receive the GPS signal at a carrier frequency of 1.57542 GHz. In addition, the RF module 720 is modified to convert the

1.57542 GHz GPS signal to the intermediate frequency ("IF") used by the mobile device. The circuit modifications also include the ability to process signals with different bandwidths. The bandwidth of the signals processed in the mobile device may be greater or less than the bandwidth of the reference signal. For the GPS reference signal example, if the mobile device is configured to process CDMA signals, which have a bandwidth of 1.2 MHz, then the mobile device circuits are modified to process a 2 MHz band signal. To accommodate signals with different bandwidths, the bandpass filtering of RF module 720 is modified to filter the reference signal at frequencies outside the bandwidth of the reference signal. The thin-client processor 750 receives the reference data and the time stamp, indicating the time of capture at the client device, and generates an encoded message. The encoded message may be generated in the thin-client processor 750 or the DSP 760. The mobile device 700 further includes circuits to transmit data/information, including voice. Specifically, the mobile device 700 contains a digital to analog ("D/A") converter 770, a modulator 780 and an RF transmitter 790. In addition, the DSP 760 may format the data for transmission using a wireless protocol (e.g., WAP). For this embodiment, thin-client processor 750 formats reference data and outputs a message format suitable for the air interface protocol, hi turn, DSP 760 encodes the message in accordance with an air interface protocol, and transmits the message using the wireless transmitter circuits (e.g., D/A converter 770, modulator 780 and RF transmitter 790). The reference data is transmitted using the air interface protocol and communications network.

Communications Between The Thin-Client Device And The Location Server:

Figure 8 is a block diagram illustrating one embodiment for communicating between the client device and the location server. For this embodiment, the client 800 communicates with a location server 820 using a carrier network infrastructure 830. Specifically, the client device 800 utilizes a wireless communications network for two-way communications between the client device 800 and the carrier network infrastructure 820. To this end, the client device 800 includes, in part, a wireless communications module 840 and a wireless protocol encoder 835. The wireless protocol encoder 835 typically formats the reference data into packets, in accordance with General Packet Radio Services ("GPRS"), Circuit Switched Data ("CSD"), Short Message Service ("SMS"), or other suitable formats. The wireless communications module 840 then generates an air interface signal using a wireless communications technology.

For the embodiment of Figure 8, the carrier network infrastructure 830 communicates with the location server 820 over a network 850, such as a carrier network, a private data network, or the Internet. Figure 9 is a block diagram illustrating one embodiment for a carrier network, network communications, and server that support a variety of signal paths. As shown in Figure 9, a base station antenna 900 receives an air interface signal for input to a base station subsystem 905 ("BSS"). The BSS 905 processes the air interface signal, including demodulating the signal, to extract the reference data. If the air interface signal carries voice information, then the air interface signal is directed to the mobile service switching center ("MSC") 910. Alternatively, if the air interface signal carries data information, then the air interface signal is directed to the GPRS node 925. However, in some cases, data may be transmitted over a voice channel, and voice may be transmitted over a data channel. An MSC 910 connects the BSS 905 into a public telephone network 915. As shown in Figure 9, the reference data from the client device is routed to a GPRS node 925 or a

SMS center 930 by the BSS 905 or the MSC 910. The GPRS node, also referred to as SGSN, acts as an interface between the BSS and a packet network. The SMS center 930 connects an SMS network into the carrier network infrastructure. A server 945 receives the reference data through packet based network 940. The server 945 includes one or more software daemons (e.g., UDP daemon 950, TCP daemon 960, HTTP daemon 970, and SMTP daemon 980) that process network packets in accordance with their respective protocols. In turn, the daemons forward the reference data, extracted from the network packets, to location determination processing 990 for calculation of the client device location. In one embodiment, the location determination processing 990 communicates with the network protocol services through remote procedure calls ("RPCs"). The packet based network 940 receives the reference data in accordance with any type of network communications protocol. As shown in Figure 9, the packet based network 940 forwards the reference data utilizing TCP/IP or UDP/IP. In addition, the air interface data protocols (e.g., GPRS, SMS, CSD, etc.) may be encoded in accordance with an applications protocol, such as the Wireless Applications Protocol ("WAP"). To this end, reference data encoded in WAP messages are input to the WAP gateway 935, which in turn, translates the WAP messages into HTTP requests and responses to communicate with the server 945. The network infrastructure shown in Figure 9 is bi-directional, in that the server 945 communicates with the client device through the same infrastructure.

Figure 10 is a block diagram illustrating one embodiment for communicating between the client device and the location server over wireless networks. Similar to the embodiment of Figure 8, a client device 1000 includes wireless communications module 1010 to support transmissions between a client device 1000 and a carrier network infrastructure 1020. The carrier network infrastructure 1020 includes carrier network equipment to support wireless communications, over a predefined area through the use of cells or base stations, to the location server 1030. For this embodiment, the location server 1030 includes a wireless communications module 1040 to support two-way communications over the wireless communications link.

Embodiments of the Location Server:

Figure 11A is a block diagram illustrating one embodiment for the location server. The location server 1200 includes network communication module 1210 to provide two-way communications with the communications link 1220. The location calculation processor 1230 calculates the client's location, or alternatively, generates a request to the client device to obtain more data. As described more fully below, in one embodiment the location calculation processing works in conjunction with aiding data. To this end, server 1200 includes an interface to external systems 1240 to obtain such data.

In one embodiment, the location server uses "aiding data." The aiding data may be obtained from a variety of sources. For example, aiding data may be obtained from the Internet, such as the website www.ngs.noaa.gov/CORS/cors-data.htmk which provides specific GPS data. Alternatively, aiding data may also be obtained from a base station that independently acquires the data, or from other sources. One type of aiding data includes ephemeris information. Based on ephemeris information, the server computes satellite locations, satellite coverage, and Doppler shifts. In addition, satellite clock corrections are also obtained and used in location computations. Figure 11B illustrates another embodiment for the location server. For this embodiment, the server 1200 includes a database 1250. In one embodiment, the database 1250 is used to store location tracking numbers.

Figure 12 illustrates a block diagram of a location server for an LDS that utilizes location tracking numbers (LTN). In one embodiment a location server

1300 includes a network protocol server (e.g., HTTP or web server) 1310 that supports HTTP requests and generates HTTP responses. For this embodiment, the location server 1300 includes an application server 1320 that communicates with the HTTP server 1310 via RPCs. The application server 1320 implements the location determination processor 1330, aiding data interface 1340, as well as a database interface 1345. The database interface 1345 supports queries and responses, using a query language, such as the standard query language ("SQL"), to database 1350. To support location tracking numbers, location server 1300 includes a mechanism, referred to as LTN Creator/Storer 1360, to generate location tracking numbers for assigning LTNs to client device locations as well as to store the LTNs in memory and/or in a database 1350. In addition, LTN lookup 1370 accesses the memory and/or database 1350 to retrieve client device locations in response to requests that contain LTNs.

Figure 13 is a flow diagram illustrating high-level processes for the location server. The location server receives location calculation requests

(block 1400, Figure 13). In response to the calculation requests, the location server parses the requests to obtain the reference data (block 1410, Figure 13). The server then obtains aiding data, and calculates the location of the client device (blocks 1420 and 1430, Figure 13). A response to the location request is generated, and is transmitted to either the client device, a third party server (blocks 1440 and 1450, Figure 13), or a third party client device.

Figure 14A is a flow diagram illustrating one embodiment for generating location tracking numbers in conjunction with a request to calculate a client location. The location server receives a request to calculate a client location, and in response, parses the requests to obtain the reference data (blocks 1500 and 1510, Figure 14A). With the reference data, the location server obtains aiding data and calculates a location for the client device (blocks 1520 and 1530, Figure 14A). The location server creates a location tracking number, and stores, in memory and/or database 1250, the client's location with reference to the LTN (block 1540, Figure 14A). The location server creates a response that includes the location tracking number (block 1550, Figure 14A). The response, with the LTN, is transmitted to the client (block 1560, Figure 14A).

Figure 1 B is a flow diagram illustrating one embodiment for processing at the server requests with location tracking numbers. The location server receives a request to look up a client location using the LTN (block 1565, Figure 14B). In response to the request, the location server parses the request and obtains the LTN (block 1570 Figure 14B). The server retrieves the client location identified by the LTN (block 1575, Figure 14B). With the client location, the location server creates a response and transmits the response to the client device for a third party server or third-party client device (blocks 1580 and 1585, Figure 14B).

Reference Signal Pre-Processing: For purposes of nomenclature, pre-processing on the client device may include, but is not limited to, one or more of the following types of preprocessing: 1) pre-processing the reference signal to generate reference data ("reference signal pre-processing"); 2) pre-processing to quantize the reference data ("quantization pre-processing"); 3) pre-processing the GPS reference data to generate correlation results ("correlation pre-processing"), and pre-processing to compress the reference data ("compression pre-processing"). Although preprocessing on the client device is described as reference signal pre-processing, quantization pre-processing, correlation pre-processing, and compression pre- processing, additional pre-processing may be performed on the client to enhance location calculation on the server without deviating from the spirit or scope of the invention.

Figure 15 is a flow diagram illustrating one embodiment for quantization pre-processing in the client device. The server transmits a request to the client for reference data (block 1600, Figure 15). h response, the client receives a reference signal, and digitizes the reference signal (block 1610, Figure 15). In addition, the client device performs additional digital signal pre-processing on the digitized reference signal to generate reference data (block 1620, Figure 15). In one embodiment, the client device uses embedded software to perform the digital signal pre-processing, and in another embedment the client device uses downloaded application software to perform the pre-processing. The client device transmits the pre-processed reference data to the server (block 1630, Figure 15). The server receives the pre-processed reference data for the client device, and calculates the location of the client device using the reference data (blocks 1640 and 1650, Figure 15). In one embodiment where the reference signal is a GPS signal, the client device performs correlation pre-processing. As is well known, in order to acquire a GPS signal, the GPS receiver generates a code (i.e., either P code or C/A code) synchronous with a time reference maintained at the GPS receiver. The GPS signal, transmitted from the satellite, also includes a code (i.e., either P code or C/A code) synchronous with the same time reference maintained at the satellite. The satellite clock time may differ from GPS time due to clock drift. For this embodiment, the client device generates a code (i.e., either P code or C/A code) synchronous with a time reference. After receiving the GPS signal, the client device performs a correlation function, with the GPS signal and the code generated at the receiver as inputs, to synchronize the two signals. Any GPS correlation function may be used. The client device generates, as an output of the correlation function (i.e., correlation pre-processing), the correlation results. In one embodiment, the client device computes ambiguity values as the correlation results. The generation of ambiguity values is described more fully below. For this embodiment, the client device transmits, as reference data, the correlation results as reference data in lieu of the pre-processed reference signal. The client device may also perform quantization pre-processing on the correlation results. In general, the correlation results permit the location server to determine the phase or time difference between the GPS signal and the code generated at the client device. This phase or time difference is used at the location server to calculate the distance between the client device and the respective satellite. In one embodiment, the location server identifies a peak in the correlation results to correlate the GPS signal and the code generated at the client device. Downloading Software to The Client Device:

Figure 16 is a flow diagram illustrating one embodiment for downloading and modifying algorithms to the client device. The server transmits a request for reference data to the client device (block 1700, Figure

16). The client device receives the request for reference data from the server (block 1710, Figure 16). In one embodiment, the request includes an identification to specify the pre-processing software for the client's use in preprocessing the reference data. In response to the request, the client device acquires, as a radio frequency signal, the reference signal (block 1720, Figure 16). If the client device has the necessary pre-processing software available, then the client device pre-processes the reference signal to generate the reference data (blocks 1725 and 1730, Figure 16).

If the client device does not possess the appropriate pre-processing software, then the client device sends a request for the pre-processing software to the server (blocks 1725 and 1735, Figure 16). The server receives the request for the client pre-processing software, and sends the appropriate pre-processing software to the client device (blocks 1740 and 1745, Figure 16). The client device receives the pre-processing software and loads the pre-processing software for use in the client device, and performs the pre-processing on the reference signal (blocks 1750 and 1730, Figure 16). After pre-processing the reference signal with the appropriate software, the client device then transmits the reference data to the server, and the server receives the reference data and calculates the location of the client device (blocks 1755, 1760 and 1765, Figure 16). Dynamic Data Transmission for Thin-Client LDS:

In another embodiment for a thin client location determination system, the quality and quantity of the reference data, generated at the client device, changes "dynamically," in some embodiments at the request of the server. For this embodiment, after the client device transmits reference data to the server, the server generates and transmits to the client device a "server response." h one embodiment, the server response consists of a location and/or a "location calculation response code" ("LCRC"). The LCRC is an instruction to the client device. In one embodiment, the LCRC instructs the client to perform one or more of the following commands (but is not limited to only using ^"these commands): 1) use the location contained in the response; 2) transmit more samples from the reference signal buffered at the client device, 3) acquire a new reference signal and transmit new reference data to the server for further calculation of a location; 4) perform additional pre-processing on the reference signal to calculate new reference data, or 5) inform the user of the client device that a location cannot be determined. The LCRC may contain additional client instructions without deviating from the spirit or scope of the invention. In one embodiment, the client also downloads the software from the server to interpret LCRCs, and in another embodiment the server may "push" software to the client device to interpret LCRCs..

The server may request the client to alter the parameters for acquisition of a reference signal and/or pre-processing of the reference signal to generate the reference data, h one embodiment, one parameter for dynamic transmission of data specifies the length of the reference signal (i.e., the number of samples of the reference signal). In one embodiment, the client device acquires 1 millisecond of a GPS signal. The length parameter in an LCRC may request the client to acquire more of the reference signal. A second parameter for dynamic transmission of data specifies the bit precision or quantization used to digitize the reference signal. For example, if the initial reference data uses 2 bit precision, the LCRC may instruct the client to increase the bit precision. A third parameter for dynamic transmission of data specifies the sampling rate to generate the reference data from the reference signal. In other embodiments, additional parameters specify conditions for compression of reference data, including the number of bits in a block.

Figure 17 is a flow diagram illustrating one embodiment for implementing dynamic data transmission in a thin client location determination system. The client device receives the reference signal, and samples the reference signal to generate a first set of reference data (block 1800, Figure 17). The client device then transmits the first set of reference data to the server

(block 1810, Figure 17). The server receives the first set of reference data, processes the reference data, and creates a response message that includes the location and/or a location calculation response code ("LCRC") (blocks 1820 and 1830, Figure 17). The server transmits the response message to the client (block 1840, Figure 17). The client device receives the response message, and determines the appropriate action based on the LCRC.

Table 1 illustrates one embodiment for a client request and server response for a thin client location determination system with dynamic transmission of data . TABLE 1

In another embodiment, the server response includes a location tracking number ("LTN"). As shown in Table 1, in this embodiment the server response is an extended Mark-up Language ("XML") document with specific tags for the location, the LCRC, the LTN, and other relevant information. The contents of the LCRC XML sub-tree consist of a variable length alphanumeric code with a variable length alphanumeric parameter list. The variable length alphanumeric parameter list consists of zero or more parameters. The XML response document shown in Table 1 contains tags for both the location as well as for the LCRC. In addition, other items, including the location tracking numbers, are included. Although the server response is disclosed as an XML document, the server response may comprise any format and may contain different tags or fields without deviating from the spirit or scope of the invention. Table 2 illustrates one embodiment for LCRC codes, including interpretations and the client's appropriate course of action, as well as the parameters.

TABLE 2

For this embodiment, the "OK" LCRC code indicates the location calculation was successfully completed, and directs the client device to use the location data or the LTN embedded in the response. The RESEND LCRC code indicates to the client device that more reference data is required to complete the location calculation. In one embodiment, the RESEND code includes two parameters: a length ("LEN") parameter and a quantization ("QUANT") parameter. If the client device receives the RESEND LCRC code, then the client device acquires the specified LEN of the reference signal (i.e., length of the reference signal measured in milliseconds), and digitizes the reference signal in accordance with the quantization value (i.e., QUANT indicates the number of bits of precision). If the client device receives an ERROR LCRC, indicating that an error occurred in the server while calculating the client location, the client device displays an error message to the client user. If the LCRC code is a FAIL code, then the server failed to calculate the client location after a threshold number of attempts (e.g., three), and the location calculation is stopped and an error message is displayed.

In one embodiment, if after the first client request the server is not able to calculate the location, then the server transmits a response to the client with a RESEND LCRC code. The client device resends a request to calculate a location that also includes the number of RESEND requests previously transmitted (i.e., the <ITER> tag of the XML request). In one embodiment, if after a predetermined number (e.g., three) RESEND attempts the server is still unable to determine a location, then the server returns the FAIL response code to instruct the client to cease transmitting requests and to display an error message to the user. The predetermined threshold value is set to prevent the client device from draining the battery by sending repeated requests when the client device is physically out of range for an acceptable reference signal.

As shown in Figure 17, the client device receives a server response (block 1850). For the LCRC code and parameters, the client determines the appropriate action. If the LCRC code designates RESEND, then the client device acquires the appropriate reference signal based on the LEN parameter, and digitizes the reference signal with the amount of precision set forth in the QUANT parameter (blocks 1860 and 1870, Figure 17). Alternatively, if the LCRC indicates an ERROR or a FAIL, then the client device displays an error message to the user (blocks 1860 and 1880, Figure 17). This process is repeated until a response is received with an LCRC that instructs the client to use the location contained in the response or until a response is received with an LCRC that instructs the client to stop requesting the location. Figure 18 is a flow diagram illustrating one embodiment for dynamically determining location in a server. The location server receives a location calculation request from a client device (block 1900, Figure 18). In response to the request, the server parses the request to obtain the reference data (block 1910, Figure 18). To calculate the client's location, the server obtains aiding data (block 1920, Figure 18). Using the aiding data and the client's reference data, the server attempts to calculate the client's location (block 1930, Figure 18). The server creates the LCRC (block 1940, Figure 18). If the server was successful in calculating the client's location, the location is included in the response, and the LCRC code is set accordingly (e.g., "OK"). If the server was not successful in calculating the client's location, the server generates an appropriate LCRC code (e.g., either RESEND, ERROR or FAIL). The server formulates the response, and sends the response to the client (blocks 1950 and 1960, Figure 18). Figure 19 is a block diagram illustrating one embodiment for a location server that dynamically determines location. For this embodiment, location server 2000 includes an HTTP server, for processing requests and responses, and an application server. As shown in Figure 19, the application server includes location calculation algorithms 2020, an LCRC creator 2030, aiding data interface 2040, and a database interface 2050. The LCRC creator 2030 formulates responses as described above. The database, which processes SQL queries, provides information used to calculate the client's location.

Multi-Algorithm Server Embodiments: Figure 20A is a block diagram illustrating one embodiment for a location server that employs a location calculation algorithm that consists of two steps, as shown in Figure 20A. Specifically, for this embodiment, the location calculation algorithm comprises the steps of 1) signal acquisition 2010, and 2) location calculation 2020. The signal acquisition step determines pseudoranges from reference data. In the second step, location calculation 2020, the client's location is determined from the pseudoranges calculated in the signal acquisition 2010 step.

Figure 20B is a block diagram illustrating one embodiment for a location server that employs a location calculation algorithm that performs the location calculation in a single step. Specifically, location calculation algorithm 2030 performs the entire location calculation without the intermediate step of determining pseudoranges.

Figure 20C is a block diagram illustrating another embodiment for a location server that employs multiple algorithms. As shown in Figure 20C, the location server includes location algorithm #1 (2040), location algorithm #2

(2050), and location algorithm #n (2060). The location server uses one or more of the location calculation algorithms to calculate the client's location, h addition, the location server includes algorithm usage logic 2070. Embodiments for algorithm usage logic are described in Figures 21 and 22. The use of multiple location calculation algorithms in the location server permits optimization of the location calculation for different conditions and applications. In one embodiment, one or more location calculation algorithms are optimized for speed, sensitivity to signal strength, correction for multi-path errors, and client's environment (e.g., indoor or outdoor). Also, one or more location calculation algorithms are optimized for accuracy. Specifically, one or more location algorithms may take a "risky" approach where they produce results that are either very accurate or very inaccurate. Other algorithms may take a "risk-averse" approach where they produce results which are not very accurate, but that are also never extremely inaccurate. In another embodiment, one or more location calculation algorithms are configured to use different external data sources or to use no data sources at all. One or more location calculation algorithms are also configured to use different information in the reference data. In another embodiment, one or more location calculation algorithms are optimized based on the velocity of the client device. Figure 21 is a flow diagram illustrating one embodiment for use of multi-algorithms in the server. The server receives a location calculation request, parses the request to obtain the reference data, and obtains aiding data (blocks 2110, 2120, and 2130, Figure 21). The server selects an algorithm, and calculates the location using that algorithm (blocks 2140, 2150 and 2160). If the algorithm was successful, then a response is generated (blocks 2170 and

2180, Figure 21). If the algorithm was not successful, then a new algorithm is applied, and blocks 2150, 2160 and 2170 are repeated (block 2140, Figure 21). If all the algorithms have been tried, then an error code is generated as the response (blocks 2140, 2190 and 2180, Figure 21). The response is sent to the client, (block 2195, Figure 21).

Figure 22 is a flow diagram illustrating another embodiment for use of multi-algorithms in the server. The server receives a location calculation request, parses the request to obtain the reference data, and obtains aiding data (blocks 2210, 2220, and 2230, Figure 22). The location server processes the reference data using multiple algorithms in parallel (block 2240, Figure 22). The location server selects the best result, creates a response, and sends the response (blocks 2250, 2260 and 2270, Figure 22).

In another embodiment, the server receives a location calculation request, parses the request to obtain the reference data, and obtains aiding data. Embedded in the request is also a command identifying a specific algorithm or a class of algorithms (i.e., "least expensive") to use in the calculation of a location. The location server calculates a location using a specified algorithm or algorithms, creates a response, and sends the response. In other embodiments the server, rather than the client, makes the determination of which algorithm or algorithms to use to calculate a location.

Location Determination Processing:

An approximate client location £ may also be used to aid in the acquisition of GPS signals. (This approximate location here is represented in terms of a three-dimensional vector corresponding to a point in an. earth- centered earth-fixed coordinate system.) In one embodiment, the approximate

location £ is based on the location of the cell tower that provides the wireless

communications to the client device. In another embodiment £ may be determined by measuring signal strength between the base station and client device, using time-difference of arrival (TDOA), angle of arrival (AOA), and/or sector of arrival (SOA) methods at the base stations.

For purposes of the explanation below, location determination processing may be separated into several phases: 1) computation of approximate satellite locations; 2) identification of overhead satellites; 3) computation of code phases; 4) computation of pseudoranges; and 5) triangulation of pseudoranges to determine location.

For purposes of clarity, we denote the sampled signal by a process s , ..., S_K- These samples are taken at GPS times t_}, ...,tκ- The corresponding handset clock times are denoted by ,..., 7_K . Hence, represent the handset clock time

recorded when the first sample of the GPS signal is received at the client device. Note that, though 7_{ may differ from t (even if only by a few microseconds),

the samples are taken at uniform intervals t. — — _ . The reduction of "clock

Doppler" may be achieved by various protocols between the receiver and the network so that Δ = - 7_k__x = t_k - t_k__λ .

Computation of Approximate Satellite Locations:

As is known to one skilled in the art, one known method for computing satellite location from GPS signals uses ephemeris information (which is contained in the aiding data). In particular, given a GPS time t, it is

straightforward to compute the location y e SR³ of the z^'th satellite at time t, in

an earth-centered earth-fixed coordinate system. (This is a three-dimensional vector.)

For each zth satellite, the location server computes a location y' that

approximates the satellite's location at the time at which the signal sample received at GPS time t_j was transmitted, hi doing this, the server first

computes an approximate time at which the signal was transmitted. This is

given by t₍ — t_x -

(c denotes the speed of light.) The resulting approximate location of each i^th satellite may be represented by y' = y..

Identification of Overhead Satellites:

The next step is to identify the collection of satellites that are overhead. As is known to one skilled in the art, using an approximate location y' of a

satellite and an approximate location £ of the handset, the satellite is considered "overhead" of the client device if:

(Note that the "prime" denotes matrix transposition.) Computation of Code Phases: One known method for computing code phases is described below, however, as is known to one skilled in the art, a variety of other methods may be used to compute code phases. Using the sampled signal, the location calculation correlates C/A codes in order to determine code phases. The GPS time of each ^th sample is denoted by tj. and the sample signal is denoted by s*. The contribution of any particular satellite to the k^th sample may be expressed as:

2Pd(t_k - τ)x(t_k - τ) cos(2π((f_JF + f_D)t_k + θ))

= ΪPd(t_k - (t_k - _T)(_e W z,⁾fc⁺*⁾ _{+ e}- _F⁺/I>⁾'_⁺*⁾ )/ ₂ '

where, x(t) is a bandpass filtered version of the associated C/A code x(t) ,

P is the signal power d(t) is the navigation bit stream τ is the time elapsed from the transmission of the first sample to the receipt of the first sample, f_/F is the intermediate frequency, fo is the Doppler shift (i.e., a sum of the satellite Doppler and the clock Doppler); and θ is carrier phase. The carrier phase typically depends both on atmospheric effects and on the phase of the mixer used to downshift frequency in the client device. Note that this expression, an approximation, ignores the effects on the Doppler shift on the navigation message and the C/A code, as well as the change in signal travel time during the course of transmission and reception.

The location server estimates the code phase, φ , and Doppler shift, Ϊ_D,

associated with each satellite. This involves a search over candidates (φ,f_D) .

The search is exhaustive and entails computation of an "ambiguity value"

A(φ,f_D) for each candidate. The pair (φ,f_D) with maximum ambiguity value

is chosen.

In one technique to compute ambiguity values, multiplication with a complex-valued reference signal generates an altered signal and is performed as follows:

where, W_/. represents the contribution of noise and other satellites. In one embodiment, this signal is low pass filtered to obtain:

s{° = ΪPd(t_k - τ)x(t_k - φWtfD-toh+Vπ^r-toh⁺e⁾ + _e-w z>X'*-^<>⁾ 'w . .

Next, the signal is correlated with x(t_k -t_x -φ) , generating a value

However, rather than computing this sum explicitly for each φ and f_D , R(;f_D)

is viewed as a correlation. In one embodiment, the coπelation theorem and fast Fourier transforms ("FFT") are used to improve computation time. Finally, computing a squared magnitude yields:

This process is designed to "strip away" the navigation bit and the carrier phase, thus alleviating the need to estimate these parameter values. Assuming,

K

' _e ,--2^π,{⁽f^J _I ^l _F ^F+⁺f^j _D ^D){t'_k ^k--t^hO^,_W_kx(t_k - t_j -φ) « 0

K k=\ the expression becomes:

(., - t - φ (t_!c -

and therefore, the ambiguity values do not depend on the navigation bit or the carrier phase, assuming that the navigation bit is constant for the duration of the sampling. hi one embodiment, an ambiguity threshold ratio is used to detect useful code phases, and satellites without useful code phases may be disregarded. For a given satellite, its maximum ambiguity must exceed the average ambiguity by a constant ratio in order for that pseudorange estimate to be considered valid. In other embodiments, a variety of threshold tests can be used, such as ratio between highest ambiguity peak and next highest ambiguity peak. Computation of Pseudoranges:

Given an approximate location, £ , and a clock time, t_x , recorded by the

device at signal reception (i.e., at the time of sampling s(), a pseudorange, p. , is

generated for each zth satellite. To do this, an assumption that the handset clock time is commensurate with GPS time is made to simplify the process.

For each .th satellite, the pseudorange calculation may be broken into several steps.

1. Determining the contribution of satellite code phase φ_t and

satellite clock ercorε,. :

P_t = (Φ, +ε,)c

2. Calculating an integral number of PRN code segments. The length of each code segment is approximately 300km. Since the approximate location provides enough accuracy, the integral number of code segments may be determined as follows:

where /ris the length (in space) of a code segment.

3. Calculating satellite transmission phase v_i . Since the GPS

clocks are all synchronized (after applying the clock correction), this part of the distance is constant for all satellites. In one embodiment, this quantity is set to zero and solved for in triangulation.

4. Computing differential coπection d_r Differential coπections can be obtained from a variety of sources, including third-party vendors, publicly available data via the Internet (e.g. www.ngs.noaa.gov/CORS/cors-data.html), readings of an independent GPS receiver and other sources. The sum of these quantities form the pseudorange.

P, = P, + m,l, +cv, + d_t

Triangulation of Pseudoranges to Determine Location:

Given approximate satellite locations, y^l,...,y^N , together with

pseudoranges, a known triangulation technique can be used to compute user location. To reduce notation, the subscripts are eliminated from the approximate locations used in this section, with an understanding that all locations are associated with 7_X .

Note that

where γ is an eπor term common to all satellites (which may include an

unknown satellite phase contribution). To estimate the location £ and the error term γ , we solve

jj& ^,r

- -^y'W-r -f-yi-r ^,

for some positive definite weight matrix W. In one embodiment, the algorithm of Bancroft, Stephen (1985), An Algebraic Solution of the GPS Equations", IEEE Transactions on Aerospace and Electronic Systems, Vol. AES- -21, No. 7 is applied, as set forth below. Define an Nx4 matrix

-y - A

M =

and a N-dimensional vector r with components

rt = y''y'

Denote the pseudo-inverse of M, with respect to weight-matrix W, by

MX (M'WM)-^lM'W. Let i be the N-dimensional vector with every component equal to 1, and let

u =■ M and v = .

Finally, let

a_x - u + u + u 4 >

= 2(z.₁v₁ + u₂v₂ + v₃u₃ - v u₄ - 1),

Solving the quadratic equation

a_xλ + a₂λ + a₃ - 0 ,

that yields two roots,

Each root coπesponds to a vector of coordinates and time:

and the one closest to the Earth's surface is selected.

As used above, we employ a diagonal weight matrix W with diagonal

entries W_u = A, (θ_l , f ) . This is motivated by a maximum likelihood

argument, as set forth below.

A simplifying assumption is made that the pseudorange eπors are distributed according to independent Gaussian distributions. The relevant statistics are therefore the variances. An observation is made that the variance

of the pseudorange error for p_t is roughly σ² l(TP_t) , where σ² is the noise

power spectral density, T is the duration in time of the received signal, and Pi is

the power of the zth signal. Since A_l(θ_l,f^⁾) estimates P_., σ² /(TA_l(θ,,f ⁾)) is

an estimate of the pseudorange variance. The relationship between pseudorange estimates and location can therefore be modeled by

Where w_{ is an independent Gaussian random variable with variance

For a clearer conceptual presentation, a vector, q, is defined as

Then, let a function g: SR⁴ → di^N he defined by

The pseudoranges then satisfy p=g(q)+w. where w is a Gaussian random variable with diagonal covariance matrix Σ

whose diagonal entries are given by ∑_a = σ² /(TA^Θ^f^)). A maximum

likelihood estimator for q, given p, therefore minimizes

This quantity is proportional to

(p - g(q))'W(p -g(q)) . Hence, the choice for the weight matrix is determined.

Even though some embodiments of the invention were described above by reference to one particular location-determination process, one of ordinary skill will realize that other embodiments may use other location-determination processes. These other processes can perform their analysis based on the same set of parameters as the location-determination process described above, or based on different sets of parameters.

For instance, some location-determination processes use the information illustrated in Figure 23 to perform a Bayesians statistical analysis, which identifies the most likely location within a region that contains the client device that receives the GPS signal. In Figure 23, a location-determination server 2300 receives information from (1) a base station, (2) a client device through the base station, (3) a reference GPS receiver, and (4) one or more databases. From the client device, the server might receive the device's clock

Doppler, and the time that the device generated the first sample in the digital GPS reference data. From the base station, the server can receive the base station's tower-identification. The server also might receive an arrival-time delay that specifies the signal-transit delay between the client device and the base station. In addition, the server might receive an arrival angle and/or arrival sector, which respectively specify the angle of the incoming signal to the base station and the sector for the incoming signal. In some embodiments, the location-determination server naπows the approximate region containing the client device by using the signal-transit delay, arrival angle, and/or arrival sector.

The server might also receive from the GPS reference receiver the following information about the GPS satellites: Doppler values, ephemeris data, navigation bits, and/or differential-coπection values. In some embodiments, the location determination server can use this information to determine the satellite location and atmospheric delays, and/or to enhance computations involved in the location determination. The server might also receive information from the GPS reference receiver through the Internet or some other communication medium. As shown in Figure 23, the location-determination server can also retrieve some information from one or more databases. This information includes the base-station tower's coverage, topographic maps of the approximate region about the base-station tower, and three-dimensional maps of structures in this region.

General Considerations:

The processes and modules described herein may be implemented in hardware, software, or a combination of hardware and software. If implemented in software, the software comprises computer readable instructions for execution on a general purpose computer (e.g., server) or for execution on a microcontroller (e.g., client device).

Although the present invention has been described in terms of specific exemplary embodiments, it will be appreciated that various modifications and alterations might be made by those skilled in the art without departing from the spirit and scope of the invention.

Claims

CLAIMS What is claimed is:

1. A method for determining a location of a client device, said method comprising the steps of: receiving a reference signal at a client device; pre-processing said reference signal to generate reference data; transmitting said reference data from said client device to a server; generating, at said server, a server response comprising an instruction for the client device related to location determination of said client device; and transmitting said server response to said client device.

2. The method as set forth in claim 1, further comprising the steps of: parsing said server response at said client device; generating, at said client device, new reference data in accordance with said server response if said server response includes an instruction requesting new reference data and transmitting said new reference data from said client device to said server.

3. The method as set forth in claim 1, wherein the step of generating a server response comprises the step of inserting a location in said server response, and generating an instruction that instructs said client to use said location.

4. The method as set forth in claim 1, wherein the step of generating a server response comprises the step of generating an instruction that requests transmission of new reference data from said client device to said server.

5. The method as set forth in claim 1, wherein: the step of pre-processing said reference signal to generate reference data comprises the steps of : generating samples of said reference signal; storing said samples at said client device; generating reference data with a portion of said samples; the step of generating an instruction that requests transmission of new reference data from said client device to said server comprises the step of generating an instruction that requests the client device to transmit, as reference data, additional samples from the set of stored samples.

6. The method as set forth in claim 4, wherein the step of generating an instruction that requests transmission of new reference data from said client device to said server comprises the step of generating an instruction that requests reference data based on a new reference signal acquired at said client device.

7. The method as set forth in claim 4, wherein: the step of transmitting said reference data from said client device to a server comprises the step of transmitting said reference data comprising a first reference signal length; and the step of generating an instruction that requests transmission of new reference data from said client device to said server comprises the step of generating an instruction that requests reference data based on a second reference signal length, said second reference signal length being greater than said first reference signal length.

8. The method as set forth in claim 40, wherein the step of generating an instruction that requests transmission of new reference data from said client device to said server comprises the step of generating an instruction that requests said client device to perform additional pre-processing on the reference signal to calculate new reference data.

9. The method as set forth in claim 1, wherein: the step of pre-processing said reference signal to generate reference data comprises the step of generating samples of said reference signal based on a first bit precision; and the step of generating an instruction that requests transmission of new reference data from said client device to said server comprises the step of generating an instruction that requests the client device to transmit reference data comprising a second bit precision different than said first bit precision.

10. The method as set forth in claim 1 , wherein: the step of pre-processing said reference signal to generate reference data comprises the step of generating, at a first sampling rate, samples of said reference signal to generate reference data; and the step of generating an instruction that requests transmission of new reference data from said client device to said server comprises the step of generating an instruction that requests the client device to transmit reference data comprising samples generated from a second sampling rate, said second sampling rate being different than said first sampling rate.

11. The method as set forth in claim 1 , wherein: the step of pre-processing said reference signal to generate reference data comprises the steps of generating samples of said reference signal and compressing, in accordance with a first set of parameters, said samples to generate reference data; and the step of generating an instruction that requests transmission of new reference data from said client device to said server comprises the step of generating an instruction that requests the client device to compress said samples in accordance with a second set of parameters.

12. The method as set forth in claim 1, wherein the step of generating a server response comprises the step of generating an instruction to inform said client device that a location can not be determined.

13. The method as set forth in claim 1, further comprising the step of downloading software from said server to said client device to process said server response.

14. A method for determining a location of a client device, said method comprising the steps of: storing a plurality of algorithms at a server; receiving a request from a requestor to determine a location of a client device; receiving reference data from said client device; selecting at least one of said algorithms to determine said location for said client device; and calculating said location at said server using said at least one of said algorithms.

15. The method as set forth in claim 14, further comprising the steps of: determining whether said location calculation was successful; and selecting a second algorithm from said plurality of algorithms to determine said location for said client device if said location calculation was unsuccessful.

16. The method as set forth in claim 15, further comprising the steps of: storing more than two algorithms at a server; and repeating the step of selecting additional algorithms from said algorithms stored to determine said location for said client device until said location calculation is successful.

17. The method as set forth in claim 14, wherein: the step of selecting at least one of said algorithms to determine said location for said client device comprises the step of selecting a plurality of algorithms to determine said location; and the step of calculating said location at said server comprises the steps of: calculating a plurality of locations in parallel; and selecting one of said locations calculated.

18. The method as set forth in claim 14, wherein: the step of receiving reference data comprises the step of receiving, from said client device, a message comprising information regarding use of at least one of said algorithms; and the step of selecting at least one of said algorithms to determine said location for said client device comprises the step of selecting said at least one of said algorithms specified in said client request.

19. The method as set forth in claim 18, wherein said information regarding use of at least one of said algorithms comprises information that identifies one of said algorithms.

20. The method as set forth in claim 18, wherein said information regarding use of at least one of said algorithms comprises information that identifies a class of said algorithms.

21. The method as set forth in claim 14, wherein the step of calculating said location at said server comprises the step of using aiding data to calculate said location.

22. The method as set forth in claim 14, wherein the step of receiving a request to determine the location of a client device comprises the step of receiving, from said requestor, a request comprising information regarding the nature of the location determination request; and the step of selecting at least one of said algorithms to determine said location for said client device comprises the step of selecting at least one of said algorithms at said server based on said information regarding said nature of the location determination request.

23. A client device comprising: a reference signal pre-processor for receiving a reference signal and for pre-processing said reference signal to generate reference data; communications module, coupled to said reference signal pre-processor, for transmitting said reference data from said client device to a server, and for receiving, from said server, a server response comprising an instruction for said client device related to location determination of said client device.

24. The client device as set forth in claim 23, wherein: said reference signal pre-processor further for parsing said server response and for generating new reference data in accordance with said server response if said server response contains an instruction requesting new reference data; and said communications module further for transmitting said new reference data from said client device to said server.

25. The client device as set forth in claim 23, wherein said communications module further for receiving in said server response a location determination and an instruction that instructs said client to use said location determination.

26. The client device as set forth in claim 23, wherein said communications module further for receiving in said server response an instruction that requests transmission of new reference data from said client device to said server.

27. The client device as set forth in claim 26, wherein: said reference signal pre-processor further for generating samples of said reference signal to generate reference data; and said communications module further for receiving an instruction from said server that requests the client device to transmit, as reference data, additional samples from the reference signal.

28. The client device as set forth in claim 26, wherein said communications module further for receiving an instruction that requests reference data based on a new reference signal acquired at said client device.

29. The client device as set forth in claim 26, wherein said communications module further for transmitting to said server said reference data comprising a first reference signal length, and for receiving an instruction that requests reference data based on a second reference signal length, said second reference signal length being greater than said first reference signal length.

30. The client device as set forth in claim 26, wherein said communications module further for receiving an instruction that requests said client device to perform additional pre-processing on the reference signal to calculate new reference data.

31. The client device as set forth in claim 23, wherein: said reference signal pre-processor further for generating samples of said reference signal based on a first bit precision; and said communications module further for receiving an instruction that requests the client device to transmit reference data comprising a second bit precision greater than said first bit precision.

32. The client device as set forth in claim 23, wherein: said reference signal pre-processor further for generating, at a first sampling rate, samples of said reference signal to generate reference data; and said communications module further for receiving an instruction that requests the client device to transmit reference data comprising samples generated from a second sampling rate, said second sampling rate being different than said first sampling rate.

33. The client device as set forth in claim 23 , wherein: said reference signal pre-processor further for generating samples of said reference signal and compressing, in accordance with a first set of parameters, said samples to generate reference data; and said communications module further for receiving an instruction that requests the client device to compress said samples in accordance with a second set of parameters.

34. The client device as set forth in claim 23, wherein said communications module further for receiving an instruction to inform said client device that a location can not be determined.

35. A server comprising: network communication module for receiving, from a client device, reference data and a request to determine a location of said client device; and location calculation processor, coupled to said network communication module, for accessing a plurality of algorithms at said server, for selecting at least one of said algorithms to determine said location for said client device, and for calculating said location at said server using said at least one of said algorithms.

36. The server as set forth in claim 35, wherein said location calculation processor further for determining whether said location calculation was successful, and for selecting a second algorithm from said plurality of algorithms to determine said location for said client device if said location calculation was unsuccessful.

37. The server as set forth in claim 35, wherein said location calculation processor further for accessing more than two algorithms, and for selecting additional algorithms from said algorithms accessed to determine said location for said client device until said location calculation is successful.

38. The server as set forth in claim 35, wherein said location calculation processor further for selecting a plurality of algorithms to determine said location, for calculating a plurality of locations in parallel, and for selecting one of said locations calculated.

39. The server as set forth in claim 35, wherein: said network communication module further for receiving, from said client device, a message comprising information regarding use of at least one of said algorithms; and said location calculation processor for selecting said at least one of said algorithms specified in said client request.

40. The server as set forth in claim 39, wherein said information regarding use of at least one of said algorithms comprises information that identifies one of said algorithms.

41. The server as set forth in claim 39, wherein said information regarding use of at least one of said algorithms comprises information that identifies a class of said algorithms.

42. The server as set forth in claim 35, further comprising an interface to external systems for obtaining aiding data to calculate said location.

43. The server as set forth in claim 35 , wherein: said network communication module further for receiving a request to determine a location of said client device; and location calculation processor further for selecting at least one of said algorithms at said server based on information provided by said request to determine a location of said client device.