TELECOMMUNICATIONS SYSTEMS
Technical Field
The invention relates to a telecommunication system having a plurality of mobile terminals. The invention also relates to a mobile telecommunications system, comprising a plurality of mobile telephone networks and a plurality of mobile terminals, each mobile terminal being registered with one of the networks ("home network") and being able to roam to another of the networks ("visited network").
Summary of the Invention
A telecommunication system embodying the invention, and to be described in more detail below by way of example only, enables access to or by a user of the system to be controlled and the privacy of the user within the system to be protected. The system may be a mobile telecommunications or telephone system, particularly a system comprising networks operated by different network operators and between which a user may roam.
According to the invention, the system as first set forth above is characterised by including authenticating means responsive to a request ("location request") coming from a third party outside the system and relating to the location of a specified one of the mobile teπninals for authenticating the allowability of the location request against a plurality of pretermined criteria, and location determining means responsive to receipt of the location request after authentication by the authentication means ("authenticated location request") for initiating determination of the location of the specified mobile terminal, the authentication means and the location determining means being functionally separate within the system.
According to another aspect of the invention, the system as second set forth above is characterised by a respective authentication means in each network responsive to a request ("location request") coming from a third party outside the system and relating to
the location of a specified one of the mobile terminals registered with that network for authenticating that location request according to predetermined criteria, and location determining means in each network responsive to receipt of an authenticated location request for at least initiating determination of the location of the specified mobile terminal, in which a location request in respect of a specified one of the mobile terminals roaming in a visited network ("visiting mobile terminal") is sent to the authentication means of the home network of the visiting mobile terminal for authentication there in accordance with the predetermined criteria, and the location determining means in the visited network is responsive to the authenticated location request.
According to a further aspect of the invention, the system as second set forth above is characterised by a respective authentication means in each network responsive to an authentication request coming from a third party outside the system and relating to a specified one of the mobile terminals registered with that network for authenticating that request according to predetermined criteria, in which an authentication request received by the authentication means of one of the networks with which the mobile terminal is not registered is passed to the authentication means of the network with which the mobile terminal is registered for authentication in accordance with the predetermined criteria, and including means associated with each authentication means for registering the identity or identities of the other authentication means in the system, and in which each authentication means is only responsive to an authentication request received from another authentication means if that other authentication means is registered with it.
Brief Description of the Drawings
A mobile telecommunications or telephone system embodying the invention, will now be described, by way of example only, with reference to the accompanying diagrammatic drawings, in which:
Figure 1 is a schematic diagram of one of the systems; and
Figure 2 is a schematic diagram of another of the systems.
Modes of Carrying Out the Invention
The system to be described with reference to Figure 1 comprises a mobile telephone system enabling services to be provided to or in respect of a user in the system in dependence on the physical location of the user. The term "user" normally involves an individual in physical possession of a mobile terminal (a mobile telephone handset) but includes a mobile terminal apparatus mounted in a moving vehicle. Examples of the types of service which could be provided to such a user are as follows:-
(a) services specifically requested by the user, such as information advising the user of the nearest restaurant, or the nearest restaurant of a particular type, to their present location, the nearest retail outlet of a particular type or belonging to a particular chain of retail outlets, or the nearest cinema showing a particular film;
(b) services again requested specifically by a user but involving other users in the system, such as the provision of information to the user advising whether one or more pre-identified friends is nearby ("friend-finding service" in which the user has identified a group of "friends", the locations of which the user may request by means of this service);
(c) services not actively requested by a user but permitted by them, such as where the user is on the "friends" list of, and their location is being requested by, another user; or where a user has asked to be provided with commercial or marketing information according to their location - such as the provision of discounts on merchandise of a particular type which is available at a retail outlet close to their current location;
(d) vehicle fleet management, where the operator of a fleet of vehicles each of which carries a mobile terminal may use the system to find a physical location of each vehicle.
These services will normally be provided by an application service provider (ASP) which may communicate with the mobile telephone system and with the user via the Internet.
In most cases, the user will have registered with a particular ASP for provision of the particular service. For example, a user may have registered with a particular ASP in order to be provided with information informing them of the nearest restaurant of a particular type. In such a case, the user may activate the service by a specific request to the ASP.
Instead, for example, the ASP could automatically provide the information to the user each time the user was in the region of a particular restaurant or of a restaurant of a particular type or within a particular group. Similarly, in the case of a friend-finding service the user would register with an ASP providing such a service and would provide the ASP with a list of their particular friends, and could then at any time make an active request for the location of the friends on the list. In another example, the user would have registered with a particular ASP, asking to be provided with information on discount offers provided by particular types of retail outlet.
In the case of a fleet management service, the ASP might be operated directly by the fleet operator who would be able to initiate requests for the location of the vehicles in the fleet.
In order to perform these services, the ASP requires information concerning the physical location of the relevant user or users. This information is known to and can thus be provided to the ASP by the network operator. However, two important factors, at least, must be taken into account. First, the provision of location information relating to a user involves privacy considerations - the user's location should not be divulged in an uncontrolled manner; and, secondly, the user's location is valuable information and the network operator may wish to levy a charge for its provision.
In a manner now to be described, the network incorporates a location enabling server (LES) which controls the provision of user location infonnation.
Figure 1 shows in diagrammatic form a mobile telephone network 10 in which mobile users MT are located, of which one is shown (MTl). The network is assumed to be of the GSM or 3G type having a home location register HLR, base station controllers (BSCs), of which one is shown by way of example, which are associated with respective cells of the network and transmit information to and receive information from MTs in that cell. The BSCs, are arranged in groups each controlled by a respective MSC, the current location of each MTs being stored in the HLR.
As shown in Figure 1, an application service provider ASP1 can be accessed from the network 10 via the internet through a suitable gateway G/Wl (e.g. a WAP gateway) provided by the network 10. For example, ASP1 could provide a friends-finding service to which the MTl user has subscribed. If MTl wishes to initiate this service, MTl will access ASP 1 through gateway G/Wl . In order to provide the service to the MS 1 user, ASP1 will need to be provided with the physical location of MTl. Network 10 includes a location server LSI which, when activated, accesses the HLR and obtains the necessary information. In a manner now to be described, however, the provision of the location information is controlled by a location enabling server LES1.
In order to be able to request location information of a particular MT, the ASP must clearly be able to identify the MT to the network 10. Such identification could be provided using the telephone number (MSISDN or IMSI) of the MT. However, the network operator 10 may wish to restrict divulgation of the MSISDN to the ASP (because the ASP could use the MSISDN to obtain direct access to the MS). Therefore, if MTl in this example accesses ASP1 via gateway G/Wl, the gateway will convert the user's MSISDN into a "session ID" (SID), which may be an encrypted form of the MSISDN.
It will be the SID which will be therefore received by the ASP 1. In this case, the user may be required to log in in a suitable way with ASPl which will thus be able to identify the user - that is, at least sufficiently to identify the user to establish that the user is a subscriber to the friends finding service (in this example).
In other cases, though, the user may access ASPl using the MSISDN. For example, if MTl accesses ASPl using a different gateway such as gateway G/W2 which is not a gateway maintained by the operator of network 10, then G/W2 will access ASPl using the MSISDN of MTl.
Therefore, depending on the circumstances, ASPl now transmits a request for the location of MTl to network 10. This request is transmitted to LES1.
The location request may identify the user by means of the SID (normally if the initial enquiry has been received via G/Wl) or in terms of the user's MSISDN (normally if the initial request has been received by another gateway such as G/W2). In either case, LES1 will be able to identify the user; if the initial request received by ASPl is based on the SID, the user's MSISDN will be known to LES1 because this information will be available within network 10.
LES1 now subjects the location request to an analysis and checking process to determine whether to authenticate the request.
A location request in principle has a number of key attributes which are used in the processes carried out in LES1, as follows :-
(a) Active/passive: in relation to a particular user, the location request is considered to be "active" when it has been initiated by the action of that user - such as when the user requests information on the nearest restaurant or when the user
requests the location of the "friends" on their list in a friend-finder service; and is considered to be "passive" when, in relation to that user, the request has been initiated other than by that user - such as by a third party, for example the user is on the "friends" list of the third party who has initiated a friend-finder service, or the request has been initiated as part of a fleet management service.
(b) Anonymity: the request may be "open" in that it is based on the user's MSISDN (or IMSI) or may be "private" if it is based on a SID.
(c) Service: the request will be in respect of a particular service provided by a particular ASP and for each such service it may be specified whether for a particular user the request is permitted to be active or passive (or both), and open or private (or both).
First, LESl refers to a table (Table 1, Figure 1) which lists ASPs, which are authorised to make location requests and to receive location information, and the services which they operate. Entries in Table 1 are controlled by the operator of network 10 and subject to commercial agreement between the network operator and each ASP. These agreements will include provisions and safeguards relating to user privacy and confidentiality and also limitations on the use which the ASP may make of the location information. Table 1 not only includes entries in respect of each ASP but may have different entries for different services which may be provided by the ASP, and the entries will identify users for which the ASP may request location information.
Table 1 thus carries out an initial level of "filtering" on the location request received from ASPl . Thus LESl responds to the location request from ASPl by checking in Table 1 that ASPl is an authorised ASP and, then, checking that the service in respect of which the location request is made by ASPl is also authorised by means of an entry in Table 1. The entries in Table 1 may indicate whether the service is used in active or passive mode.
The second level of filtering is a more detailed privacy check which is carried out on the basis of entries in a privacy table, Table 2. In principle, Table 2 has privacy entries (to be explained in more detail below) for each service entry in Table 1.
In response to the location request, LESl now checks the appropriate entries in Table 2. Thus, for example, there could be four different sub-sets of entries as follows for each service or ASP for a particular user:
Table 2
For each of the four possible combinations of "private", "open", "passive" and "active", there can be merely an entry indicating for that particular user whether the location request is to be "accepted" or "declined". The entries will in principle be individually settable by the user. For example, a user could decline all location requests which are passive - or, in another example, accept passive requests only when they are "private". It is also possible, however, for a user to set up a "list" for each of the four possible subsets of requests, in which the user sets more detailed conditions which must be satisfied before a particular type of location request is accepted. Thus, for each of the four possible sub-sets in Table 2, there is a "list'V'no list" flag. If this is set to the "list" setting, then LESl must inspect the detailed privacy conditions set in the list before deciding whether or not to authenticate the location request.
In this way, therefore, the LESl establishes whether, in relation to a particular location
request for the location of a particular user in respect of a particular service, the request is to be authenticated and accepted.
Authentication of the location request in relation to a particular user by LESl may also be subject to further checks. For example, the user may be able to apply different privacy conditions at different times of day or week. For example, in a fleet management service in which the location of vehicles is identified by the location of the respective MT's carried by the users (drivers) of the individual vehicles, a particular user could ensure that location requests were only accepted during working hours.
If, in relation to a particular location request, LESl determines, after carrying out all the necessary checks as outlined above, that the request is authenticated and is to be accepted, it instructs the location server LSI accordingly. LSI then obtains the location information from the network and transmits this information back to ASPl, which can then initiate or provide the requested service.
The operation of LSI may, however, be subject to overall control by entries, in relation to each of the users, in the HLR. Thus, a particular user could advise the network that no location requests at all were to be accepted (e.g. permanently, or temporarily). Any such settings in the HLR would also be checked by LSI before acceding to the location request.
From the foregoing, it will be apparent that the location enabling server LESl and the location server LSI are functionally separate. In this way, therefore, the location enabling servers can be produced as separate standardised entities and then used within networks having different types of location servers to which the location enabling servers would be inter-connected using appropriate interfaces.
As so far described, it has been assumed that the user (MTl) is located in their home network and that the ASP (ASPl) is registered with that network.
Figure 2 shows the network 10 of Figure in simplified form, which is assumed to be the "home" network of user MTl. As shown in Figure 2, MTl is roaming into a visited network 10A. It will initially be assumed that user MTl wishes to use a service provided by ASPl (which will be assumed to be an ASP registered with network 10, the home network).
MTl may access ASPl through the Internet gateway H/G/W of the home network 10 or may set up such access through a different gateway such as gateway V/G/W of the visited network 10A. If access is via gateway H/GW, the location request received by ASPl will be based on a SID which will be generated by the gateway. In general, if access is via some other gateway, such as gateway V/GW, the request will be based on the MSISDN. In either case, though, ASPl will know from the SID or MSISDN that the requesting user MTl is registered with network 10, and will therefore generate a location request, for the location of user MTl, which will be passed to the location enabling server H/LES of the home network 10. In H/LES, the privacy checks described above with reference to Figure 1 are carried out. However, Table 2 will contain an additional set of entries. Thus, the set of entries in Table 2 described above with reference to Figure 1 relates to the case where the ASP (ASPl) is registered with the home network and the user (MTl) is located within the home network. In the case now being described with reference to Figure 2, Table 2 would include an additional set of entries relating to the case shown in Figure 2 - where ASPl is registered with the home network 10 and the user MTl is roaming. Therefore, the user could set up particular privacy settings applicable to the case numbering described with reference to Figure 2. For example, in the case described with reference to Figure 1, where the user is located in the home network, the user might (for example) be willing to accept "passive" location requests - but would decline such request when roaming. Thus, Table 2 shown above could be replaced by Table 2 A as follows:
TABLE 2A
If H/LES determines, after carrying out all the necessary checks, that the location request can be accepted, the request is passed to the location server LS in the home network. This request will identify the user by their MSISDN. If the location request as issued by ASPl is in terms of a SID, this will be converted into the MSISDN by the H/LES.
The location server H/LS will be advised by the network (by the HLR) that the identified user is roaming in a different network, and the response will identify the visitor location register of the network where the user is roaming - this will, of course, be V/VLR in network 10A. The response issued to H/LS may also include the address of the cell where MTl is currently located H/LS will pass this information to H/LES.
When H/LS interrogates the HLR in network 10, any user privacy settings held as part of the user's profile in the HLR will also be checked. For example, the settings may indicate that the user has decided to refuse all location requests at that time or has decided to refuse location requests of a type including the current location request. If this is the case, H LS will advise H/LES and H/LES will terminate the location request and inform ASPl accordingly.
Assuming, however, that it is still determined that the location request can be actioned, the H/LES will now pass the location request to the LES (V/LES) in the visited network 10A - that H/LES will be able to identify V/LES as the LES which is to be addressed because the latter' s identity can be derived from the address of the VLR which will be
advised to H/LES by H/LS.
The location request passed to V LES will include the MSISDN of MTl and the VLR address in network 10A and, where available, the identity of the relevant cell.
V/LES in the visited network will not, normally, contain any privacy information relating to user MTl. However each LES in the system will store the identities of other LESs which have been pre-approved for location requests. For example, the identities (IP addresses) of "approved" LESs may be stored as part of Table 1 for LES 1, corresponding to Table 1 shown in Figure 1. Therefore, in the present example, V/LES merely has to check that H/LES is included in this list. Because H/LES is on the "approved" list held by V/LES, V/LES can assume that the necessary privacy checks have been carried out. Therefore, V/LES now passes the location request to the location service V/LS in the visited network 10 A, this request being based on the MSISDN of MTl and will also include the appropriate address in the VLR. The VLR will carry out its own privacy check - to check whether MTl has indicated that no location requests are to be accepted (or that this particular type of location request is not to be accepted). If no such privacy block has been made, the location details are obtained by V/LS and passed back to V/LES and then to H/LES in network 10, via the internet. H/LES associates the response with the original request and the information is then returned to ASPl .
The foregoing description with reference to Figure 2 has assumed that the location request is an "active" request - that is, it originated from action by MTl . It will now be assumed that a "passive" location request is made in respect of user MTl. This location request may originate in a number of ways - for example, it may originate from another MT which wishes to initiate a friend-finding service in respect of its list of friends which includes MTl. ASPl will thus issue a location request in respect of MTl, which will normally be based on a SID for MTl. This request will be sent to the LES in the home network 10 via gateway H/GW. The form of the SID will ensure that the location request
is directed to network 10. In gateway H/G/W, the SID will be converted into MTl's MSISDN and passed to H/LES The privacy settings for MTl will be checked in H LES in the manner already described. If these settings are such that the location request is prohibited, an appropriate response will be returned to ASPl. If the location request is accepted, however, it will be passed to H/LS. In response to this request, the HLR will advise that MTl is roaming in network 10A and will provide the VLR address of MTl . This information is passed back to the H/LES by H/LS. H/LES now passes on the location request to V/LES in the visited network 10A. In the manner already described, the location of MTl is then obtained from the VLR by the VLS (assuming that the privacy settings for MTl in the VLR are not blocking the request), and the location of MTl is then passed back to ASPl via V/LES and H LES.
It will now be assumed that the location request, for the location of the roaming user MTl, comes from a different ASP, ASP2 (see Figure 2), where ASP2 is registered with network 10A and not with network 10.
It will initially be assumed that the location request is an active request generated by MTl in respect of a service provided by ASP2. This request will be passed to ASP2 via gateway V/G/W in the visited network or perhaps by gateway H/G/W in the home network. The request may be passed to ASP2 on the basis of a SID which will be generated by the gateway.
After carrying out its own check in respect of the location request, ASP2 passes the location request to the visited V/LES - because ASP2 is registered with network 10 A. V/LES will check its Table 1 to ensure that ASP2 is properly registered with network 10 A. If the request is based on a SID generated by V/G/W, then V/LES will be able to translate the SID into the MSISDN of user MTl. If the SID is generated by encryption of the user's MSISDN by means of an algorithm known to both H/G/W and V/G/W, then V/LES will be able to translate the SID into the MSISDN of user MTl if the SID has been
generated by V/G/W or if it has been generated by H/G/W. If the user accesses ASP2 via H/G/W and H/G/W is not able to generate a SID using an algorithm known to V/LES or in some other way known to V/LES, then H/G/W will not convert the user's MSISDN into a SID. In each case, therefore, V/LES will know the MSISDN of MTl . V/LES will be aware, from the MSISDN, that MTl is registered with network 10, and will now pass the location request to H/LES in the home network 10. The request will be passed to H LES with additional information, including information identifying ASP2. From its Table 1, H/LES will be able to check the authenticity of V/LES in the visited network 10A. H/LES, the privacy settings in respect of user MTl will be checked in the manner already described. If the settings are such that the location request is to be rejected, an appropriate response will be sent back to V/LES in the visited network 10 A and thence to ASP2.
If the location request is to be accepted, it will be passed by H LES to H/LS in the home network 10. As before, the HLR will confirm that MTl is roaming in network 10A and will provide the relevant address in the VLR in the visited network 10 A. This information will be passed back to H/LES by H LS.
On receipt of the location request and the associated information from H/LES, V/LES passes the request to V/LS in the visited network which accesses the appropriate address in the VLR. Again, any privacy settings set in the VLR by MTl are checked. If these do not prohibit the location request, the location details of MTl are obtained by V/LS and passed back to V/LES. These location details are then passed by V/LES to H/LES in the home network 10. H LES in the home network now sends the location request back to V/LES in the visited network where it is associated with the original request. The location details are now passed back to ASP2. At this stage, the MSISDN may be translated back to the original SID.
It will now be assumed that a "passive" location request is made in respect of user MTl by ASP2. ASP2 will thus issue a location request in respect of MTl, which will normally be based on a SID for MTl . This request will be sent to V LES in the visited network 10 because ASP2 is registered with network 10A. V LES will first check that ASP2 is in fact registered with it. It will then decide from the form of the SID that MTl is registered with the home network 10 and will pass the request to H/LES. Gateway H/G/W will convert the SID into MTl's MSISDN. The privacy settings for MTl will be checked in H/LES in the manner already described. If these settings are such that the location request is prohibited, an appropriate response will be returned to ASP2 via V/LES. If the location request is accepted, however, it will be passed to H/LS. In response to this request, the HLR will advise that MTl is roaming in network 10A and will provide the VLR address of MTl . This information is passed back to the H/LES. H/LES now returns the location request to V/LES in the visited network 10A together with the associated information identifying the relevant VLR address. In the manner already described, the location of MTl is then obtained from the VLR by V/LS (assuming that the privacy settings for MTl in the VLR are not blocking the request), and the location of MTl is then passed back to V/LES. V/LES now passes this information to H/LES which returns it to V/LES so that it can be associated with the original request and V/LES then passes the authenticated request to ASP2.
As before, on each occasion when information is transmitted from one LES to the other, the receiving LES merely has to confirm that the transmitting LES is already registered with it. It can then trust the received information.
The system shown in Figure 2 may also be used for carrying out authentication requests not related to the location of the user MTl but instead relating to some non-location based characteristic. For example, ASPl or ASP2 may request information relating to the credit rating of user MTl. The request will initially be passed by ASPl to H/LES or by ASP2 to V/LES. In the latter case, V/LES will identify MTl as being registered with the home
network and will pass the request to H LES. In either case, therefore, H LES will subject the request to the privacy checks described above with reference to Figure 1 and, for example, Table 2 A, using privacy settings applicable to the user in respect of which the authentication request is made and to the other criteria already described.
Again, on each occasion when information is transmitted from one LES to the other, the receiving LES merely has to confirm that the transmitting LES is already registered with it. It can then trust the received information.
In this description of the extension of the system of Figure 2 to handle non-location based requests, it has been assumed that the location enabling servers (LESs) would also be handling location based requests in the manner explained earlier. However, if the system is only handling non-location based requests, the designation "location enabling servers" is not of course appropriate.