GB2413744A

GB2413744A - Limiting access to personal (e.g. location) information of a service user by a service provider

Info

Publication number: GB2413744A
Application number: GB0409585A
Authority: GB
Inventors: Anand Shamji Gajparia; Chan Yeob Yeun
Original assignee: Toshiba Research Europe Ltd
Current assignee: Toshiba Europe Ltd
Priority date: 2004-04-29
Filing date: 2004-04-29
Publication date: 2005-11-02
Anticipated expiration: 2024-04-29
Also published as: GB2413744B; GB0409585D0

Abstract

The present invention relates to the provision of personal information whilst maximising the security or privacy of this information; particularly but not exclusively location information (LI) for location based services (LBS). The present invention provides a system for providing location information (LI) about a subject device (11) to location based services (LBS) provider (15); the system comprising: a location gathering means (13) for determining said LI and constraints relating to the dissemination of said LI; a location information preference authority (16) which issues a public key; the location gathering means (13) arranged to issue a token (17) comprising said location information (LI) and said constraints (C) encrypted with said public key, and a subject device identifier without said encryption, to the LBS (15); the LBS (15) arranged to forward a request for LI including the token to the LIPA (16); the LIPA (16) arranged to receive said request, decrypt said LI and constraints, and determine whether said LI can be provided to said requesting LBS (15) based on said constraints; the LIPA (16) further arranged to forward the LI and not the constraints to said LBS (15).

Description

24 1 3744 M&C Folio: GBP89836 Document:999971

PERSONAL INFORMATION PRIVACY

Field of the Invention

The present invention relates to the provision of personal information whilst maximising the security or privacy of this information; and particularly but not exclusively to the provision of location information (LI) for location based services (LBS).

Background of the Invention

Location based services include the provision of maps and other navigation aids, identification of local restaurant or petrol station information and directions to these, as well as various location specific advertising. Further examples include tracking emergency calls where the emergency service provider wishes to obtain location information about the user in trouble, and the tracking of certain types of people such as those on parole, and the tracking of vehicles for tolling purposes.

To offer location based services, location based service providers (LBSP) need to have access to location information (LI) regarding the users or LI subjects which they wish to serve. Such information is gathered using a variety of mechanisms including the global positioning system (GPS) and enhanced observed time difference (EOTD) technologies, as well as LI provided by cellular and WLAN providers. EOTD calculates LI by observing time differences in transmissions between a user device and a base station.

However location information is considered personal and private and therefore there is a need to restrict this information for approved LBS providers only. Figure 1 illustrates a known type of system utilising a proxy device 3 which determines whether an LBS provider 5 requesting LI about a mobile device or end user 1 should get this or not. This may depend on a list of approved LBS providers and/or a black list of other non- approved LBS providers, approval of LBS providers associated with the mobile communications services provider, and manual approval by the user if an automatic setting or rule does not apply. An example of such a system is described in patent document US2003/0078053.

US2003/0078053 Location Privacy Proxy (LPP) describes how a proxy device may be used to ensure the privacy of LI. When a request to position a user is received from a location based service provider by the LPP, the LPP determines whether the location based service provider is permitted by the user to have this information. This decision is made if the user permits this manually or if the user has used this service previously or by checking rules which may be found in a user profile. If the location based service provider is permitted to have LI of the user the LPP provides authorisation to a location positioning service which may provide the LI. If the location based service provider is found to be untrusted, the LPP may create a pseudonym on behalf of the user. This pseudonym is then used to transmit information from the user to the location based service provider. However such pseudonyms are unsuitable for some applications such as billing. Also the way in which the proxy makes decisions depends on preset constraints which may be held on a server. This means that a user must have privacy rules which apply to all LI which passes through the LPP. If a user decides to alter the rules for particular LI, it must so for the rules for all the LI. If, then the user wishes to change the rules back to its previous state, it must change all the rules back.

Anand S. Gajparia, Chris J. Mitchell, and Chan Y. Yeun, "Using constraints to protect personal location information", In IEEE Semiannual Vehicular Technology Conference (VTC 2003 Fall), IEEE press, October 2003 discloses a method which relies on the use of constraints which allow a user to dictate the way in which LI is managed. Such constraints include time limits on the provision of the LI, lists of LBS providers entitled/not entitled to receive the users LI, and lists or authorised and unauthorized uses, for example navigation and advertising. This system relies on the use of digital signatures and auditing to track malicious entities that fail to adhere to the constraints and/or re-distribute the LI by changing the constraints.

The IETF geopriv workgroup describes an internet draft: Geopriv requirements; draft- ietf-geopriv-reqs-04.txt; also known as Network Working Group for Comments (RFC) 3693 and can be found at http:/twww.ietf.orplrfc/rfc3693.txt. This describes the requirements to ensure the security of LI. The requirements covered are, the security of the transmission of LI, the privacy rules for managing LI, reducing the accuracy of LI, how a location object may carry LI with privacy rules and how to limit a user from being linked back to their LI. Other documents from the geopriv workgroup discuss the actual structure of LI, and specific privacy rules for LI. Although IETF geopriv requirements document specifies the requirements for ensuring the privacy of LI, it does not specify an actual mechanism to ensure the privacy.

Summary of the Invention

In general terms in one aspect there is provided a personal information such as location information (LI) service in which LI is provided together with constraints in the form of an encrypted message or token. A location based service provider (LBSP) can then request that the LI be decrypted by an authorising authority or agent which decrypts the LI and constraints, and provides the LI to the LBS provider dependent on the constraints.

This can be used to prevent all or some of the constraints from being determined by the LBSP even if it is authorised to see the LI. An example of an allowable constraint is a time limit or expiry on the use of the LI. A further advantage is that,the LI is only directed to approved LBS providers. It also allows the constraints to be changed on a per token or message basis, as opposed to known systems where the "rules" have to be changed for all requests for LI. This allows the provision of one-off LI or the user to determine when he does not want LI issued, for example when leaving work for the weekend.

The term "token" is a general term intended to encompass a wide variety of means for transferring associated or linked data from one entity to another, and may include a message or packet(s) for example.

In particular in one aspect there is provided a personal information provision service according to claim 1.

In another aspect there is provided a system for providing personal information according to claim In another aspect there is provided a location information (LI) provision service for providing location information (LI) about a subject device to location based services (LBS); the service comprising: issuing a token comprising a subject device identifier, said location information and constraints relating to the dissemination of said LI, wherein the LI and constraints are encrypted with a public key from an authorising authority; receiving a request for LI from a LBS, the request including said token; decrypting said LI and constraints in order to determine whether said LI can be provided to said LBS according to said constraints; providing said LI to said LBS.

The LI is preferably determined by an LI gatherer which is logically separate from the authorising agent and is arranged to either interrogate or collect LI (and constraints) about a device and either store this in order to produce a token upon request or issue a token periodically or upon receipt of new LI and/or constraints. The LI and constraints are encrypted by the gatherer with a key unknown to an LBSP but known by or capable of being decrypted by the authorizing agent. Preferably the authorising agent issues a public key to the LI gatherer, and retains the corresponding private key of the pair to decrypt the tokens.

In another aspect there is provided a personal information gathering apparatus according to claim 14.

In another aspect there is provided a personal information gathering service according to claim 20.

In another aspect there is provided a personal information based service provider according to claim 16, and a corresponding service according to claim 22.

In another aspect there is provided a personal information authorising agent apparatus according to claim 18, and a corresponding service or method according to claim 24.

The user device, information gatherer, and authorising agent can be distributed in a variety of ways, for example all three logical entities could be implemented on the same equipment (the user device), or the gatherer and agent could be on the same apparatus but separate from the user device, or all three entities can be implemented on separate equipment.

In addition to location information, the personal information could also include medical or other sensitive personal information.

Brief Description of the Drawings

Embodiments will now be described with reference to the following drawings, by way of example only and without intending to be limiting, in which: Figure 1 shows a schematic of a known system for providing location information; Figure 2a shows a schematic of a system for providing location information according to an embodiment; Figure 2b shows a schematic of a token used by the system of figure 2a; Figure 3 shows a flow diagram of the processes for the location infromation gatherer of figure 2a; Figure 4 shows a flow diagram for the location based service provider of figure 2a; and Figure 5 shows a flow diagram of the processes for the authorising agent of figure 2a.

Detailed Description

Referring initially to figure 1, a known system for providing location information (LI) is shown, and comprises an end user device I such as a mobile phone which is the subject of the LI, the mobile service providers infrastructure 2, positioning functionality 3 which gathers LI associated with the mobile 1, a location privacy proxy (LPP) 4 which controls access to the LI, and a location based service provider (LBSP) 5 which requests LI from the proxy 4.

The positioning functionality or LI gatherer 3 may be part of the mobile infrastructure 2, the mobile device 1, or third party equipment (not shown), perhaps connected via the Internet for example. The LI gatherer 3 may utilise GPS input to determine the location of the mobile station 1, or information regarding which cell the mobile is currently active in a cellular network, or similarly which WLAN the mobile is in.

The location privacy proxy 4 may be part of the mobile infrastructure 2 or in third party equipment (not shown), and contains a list of rules relating to the dissemination of the LI. The proxy 4 receives requests from LBSP's 5 for LI about the mobile device 1. Such LI enables the provider's 5 to tailor their services to the mobile device 1 based on its location. Such services include navigation such as the provision of local maps, and advise on local services such as dining and fuel locations. The rules ensure that the LI is not freely available to anyone requesting it, and may include for example a list of authorised LBSP 5.

If a requesting LBSP 4 is approved by the proxy 4, then the proxy 4 instructs the LI gatherer 3 to forward the LI to the approved LBSP 4.

Referring now to figure 2a, a location information provision system according to an embodiment is shown. The system services a device 11 which is associated with a user's LI, for example a mobile phone, PDA, laptop computer. The device 11 may also be "fixed" in the sense that it is not readily mobile, for example a desktop computer.

The device it is supported by a communications infrastructure 12 such as a cellular phone network, a WLAN or an ISP.

A location information gatherer 13 determines LI associated with the device 11 and may utilise GPS input to determine the location of the device 13, or information regarding which cell the device is currently active in a cellular network, or similarly which WLAN the mobile is in, or even LI retained by an ISP. The LI gatherer 13 may be at any location, including in the User Device 11 itself. The LI gatherer 13 may obtain LI in response to a request by a Location Based Service provider (LBSP) 15 or an LI subject (11), or it may constantly collect LI for a large number of LI subjects.

The gatherer 13 is further arranged to issue tokens 17 which contain the LI and constraints (C) related to the LI, as well as a device identifier (Is) The token also preferably contains a token identifier (TokenID), a gatherer identifier IG, and a digital signature using the signing key (ESG) of the issuing LI gatherer 13 together with a certificate (Certc) which attests that the signing key ESG used for the signature part of the token belongs to the LI gatherer 13. A location information preference authority (LIPA) identifier IL is also included in some embodiments. The LIPA is described in detail below. The digital signature of the token is calculated over LI, C, IS, IL, IG, and TokenID, as well as the encrypted LI and constraints C. A schematic of such a token is shown in figure 2b.

The LI and the constraints C are encrypted by the gatherer 13, however the other token contents such as the device identifier is not. Thus whilst the token 17 can be received by location based service providers (LBSP) 15, the LI and constraints C cannot be read by them. The LBSP 15 can however read the device identifier Is in the token 17, as well as any other non-encrypted information including IL, TokenID, and IG for example. The gatherer 13 can be configured to issue tokens 17 to any LBSP 15 requesting these, or the tokens may be issued automatically to a list of LBSP's 15. Alternatively the tokens may be provided to a repository available to any LBSP 15.

The constraints C are restrictions of the availability of their associated LI, and may include for example time limits after which the LI is no longer available, lists of LBSP which may access the LI and others which may not, and lists of uses of the LI which are approved or not, for example navigation or advertising.

When LI is required, an LI token 17 is provided to the LBS provider 15 wishing to use the LI for service provision. This could occur in a variety of ways, for example by using third party LI token repositories, by sending the LI token 17 via the device 11, or by direct transfer from the LI gatherer 13 to the service provider 15.

The system also comprises a location information preference authority (LIPA) or authorising agent or authority 16 which is a trusted third party and provides an encryption key to the gatherer 13 which is used to encrypt the LI and constraint information C in the tokens 17 issued by the gatherer 13. The agent 16 may issue a single public key, for example for a given period, or may issue new public keys upon request by the gatherer 13, for example for each LI subject 11. The agent 16 retains the private key associated with the issued public key in order to decrypt the LI and constraint information in the tokens 17. However for all other parties receiving the tokens 17, the LI and constraints cannot be determined. The LIPA or agent 16 can ensure that the information held within the constraints C can remain private. In an alternative arrangement a symmetric key may be shared between the agent 16 and the gatherer 13.

Location based service providers (LBSP) 15 which receive the tokens 17 can read the device identifier Is (and some other contents of the token as described above) as this is not encrypted, and so determine whether they want LI about the corresponding device 11. If so, they forward a request for LI to the authorising agent or authority 16 including the token 17. The request will also include a certificate Certp from the LBSP, which is the digital certificate which attests that the public key in the certificate belongs to that particular LBSP. By providing its digital certificate, the LIPA 16 may use the public key found in this to verify the LBSP 15. As this key is used to encrypt the LI which is returned, only that LBSP may access the LI sent.

The constraints may include the use to which the LI will be put, and this may be determined based on previous knowledge by the LIPA 16, for example a predetermined list held by the LIPA 16 with LBSP's 15 and corresponding services which they are known to provide. Other methods may require the LBSP 15 to indicate to the LIPA 16 what use it will make of the LI in its request to the LIPA 16.

The authorising authority (LIPA) 16 receives the request including the token 17, and using its private key, decrypts the LI and constraints information C contained in the token 17. By interrogating the constraints C, the authority 16 can determine whether the requesting LBSP 15 is authorised to receive the LI. For example if the LBSP 15 is on a list of approved providers contained within the constraints, and an expiry time relating to the LI has not expired, then the agent 16 forwards the LI, but not the constraints, to the requesting LBSP 15. In some configurations some constraints such as when the LI expires may also be forwarded with the LI.

This allows constraints to be associated with a single LI, as opposed to "blanket" constraints or rules that are applied to all requests for LI. The advantage of having constraints specific to LI is that users may then have the freedom to change their constraints at different locations. For example, a user may allow them to be tracked at work however, once they leave work, they may want the option not to be tracked. Also, they may only want to provide LI to a LBSP once for a service and never again.

A further advantage ofthe arrangement is that it also prevents the requesting LBSP's 15 from obtaining constraints associated with the LI, which the device 11 user may wish to keep secret.

The token 17 preferably contains information which helps to identify both the LI subject Is and the LIPA IL, together with a unique token identifier TokenID. The LI token includes the certificate CertG of the LI gatherer guaranteeing the integrity of the LI token, and may also include the identity of the gatherer IG. The Certificate CertG also provides evidence to receiving entities regarding the identity of the LI gatherer IG. An LI gatherer may generate several tokens for the same LI, for example if an LI subject uses two or more LIPAs. There may be more than one authorization agent 16, and if this is the case then the token issued by the LI gatherer 13 will also include a non-encrypted agent identifier It in order that the LBSP 15 can request LI from the appropriate agent 16.

Figures 3, 4, and 5 show flow charts of the operation of respectively the LI gatherer 13, the LBSP 15, and the authorising agent 16. Referring first to figure 3, four processes A, B. C, and D are shown. Process A retrieves LI about the device 11, for example by monitoring GPS signals received at the device 11, gathering periodically location data from a cellular network or WLAN, or using EOTD technologies. This information is added to a database (DB) within the LI gatherer 13 and is associated with an identifier Is for the device 11.

As previously discussed, Location information (LI) is data which provides information regarding an LI subject's 11 location. LI may occur in many forms, and in general can be divided into two types, namely Inferred LI and Actual LI. Actual LI refers to a directly calculated geographical location. This type of data indicates, to some degree of accuracy, the physical location of an LI subject 11. Inferred LI is, by contrast, obtained by implication. For example, if a user device 11 is present on a network, this implies that they are likely to be within an certain vicinity, although no specific calculation of geographical LI has taken place.

The LI gatherer 13 is an entity which gathers or possesses LI about an LI subject 11. A GPS receiver is an example of an LI gatherer, as it obtains location data. An entity in a GSM network which keeps signalling data for a device 11 is also an example of an LI gatherer. Although a GSM network does not normally pass on this LI (except in certain special cases), it certainly possesses such information, and could, in an appropriate environment, be a valuable source of LI for commercial use. Other examples of methods used to generate LI can be found in Jeffrey Hightower and Gaetano Borriello, Location systems for ubiquitous computing, Computer, 34(8):57-66, August 2001.

Process B retrieves constraints C associated with the LI for a subject or device 11. This may be forwarded periodically by the device 11, and will include a device identifier Is.

This information is also added to the database DB and associated with the device identifier. Various methods will be known to those skilled in the art to define and collect these constraints C. Process C retrieves the public key EL from the authorising agent 16 and adds this to the database DB. In an alterative arrangement a symmetric key can be shared by the LI gatherer 13 and agent 16.

Process D provides tokens to requesting location based service providers (LBSP) 15.

The LI gatherer 13 receives a request from an LSBP 15 to provide LI regarding a particular device 11. The device 11 will be identified by a predetermined identifier Is known within the system (13, 15, 16). The gatherer 13 then determines from its database DB whether it contains such information, and if not responds appropriately to the requesting LBSP 15. If the gatherer does have LI about the requested device 11, it obtains the LI and associated constraints for that device 11 from the database DB. This information is then encrypted using the public key from the authorising agent 16, and a token 17 is generated comprising the encrypted information (EL(LI+C)) as well as the device identifier Is. The token preferably also includes a token identifier (TokenID) or number as well as a digital certificate CertG from the LI gatherer 13 to verify the source ofthe token. The token 17 is then forwarded to the requesting LBSP 15.

A preferred token is divided into four parts: an encrypted part, a plaintext part, a digital signature, and a (optional) public key certificate of the LI gatherer. The encrypted section consists of LI and the constraints, C. These are encrypted using the public key EL of the agent 16. This ensures that entities other than the LIPA or agent 16 cannot see this information. The plaintext part consists of IL, IS, TokenID and IG. The identifier IL identifies the LIPA 16 whose public key EL has been used to encrypt the LI and the constraints. This enables any entity wishing to gain access to the contents of an LI token to determine which LIPA it can be requested from. This identifier could take a variety of forms, for example a URL or an IP address. The identifier Is allows any entity to identify the LI Subject to which the LI in the token relates. This identifier may be a pseudonym. The TokenID is an identifier which, in conjunction with IG, enables an LI token to be uniquely identified. The identifier IG allows any entity to determine which entity or LI gatherer 13 generated the LI token. This also enables entities to decide which public key to use to verify the digital signature. This identifier may also be a pseudonym. The digital signature is computed over both the encrypted and plaintext parts of the LI token. This provides assurance that the LI Token has not been tampered with, and authenticates the entity 13 which created the LI. The certificate CertG may be optionally included in the LI token. This makes it easier for LIPAs 16 which communicate with many LI subjects 11 to obtain the necessary public keys.

The encrypted part of the LI token could alternatively be encrypted using a symmetric encryption scheme with a shared secret key. The major advantage of such an approach would be that a symmetric encryption algorithm is typically much less computationally intensive that an asymmetric scheme. The main disadvantage is the key management overhead, since such an approach would require each LI gatherer 13 to share a secret key with every LIPA 16 with which it does business'. A variety of different mechanisms exist to provide the necessary key management functions such as that described in Alfred J. Menezes, Paul C. van Oorschot, and Scott A. Vanstone.

Handbook of applied cryptography. CRC Press Series on Discrete Mathematics and Its Applications. CRC Press, Boca Raton, Florida, 1997.

Figure 4 shows the method associated with a LBSP 15 which issues a request to the LI gatherer 13 for a token for a particular device 1 1 by including a digital certificate Certp in the request. The gatherer then proceeds with process D in figure 3, and if it has LI about the specified device 11, issues a token which is received by the LBSP 15. The token includes the encrypted LI and constraints information, preferably also a digital signature and a token number or identifier. The LBSP 15 then generates an LI request which includes the token or information taken from the token 17. The request also includes the digital certificate Certp of the requesting LBSP 15, such that the LIPA may use the public key found in this to verify the LBSP. As this key is used to encrypt the LI which is returned, only that LBSP may access the LI sent. Depending on system configuration the request may also include information on the intended use of the LI, for example a use identifier identifying navigation or advertising for example. The request may also include a public key issued by the LBSP 15 to be used to encrypt the LI it is requesting, as well as the token identifier. The LBSP 15 then receives either a "declined" message (including the token identifier) indicating that the LBSP 15 is not authorised to receive the requested LI, or the LI is itself (together with the token identifier TokenID andlor device identifier Is) received. The constraints C regarding the LI contained within the token are however not received in either case; except where a time limit or expiry date for use of the LI is included.

Figure 5 shows two processes E and F associated with the authorising agent 16. Process E relates to providing a public key to the LI gatherer 13 to be used in encrypting the LI and constraints in a token 17. A public key request is received from the gatherer 13 and a public-private key pair is generated by the agent 16. The private key is retained by the agent 16, and the public key is issued to the gatherer 13. Alternatively a public-private key pair may be generated and periodically forwarded automatically.

In process F an LI request is received from a LBSP 15 and includes LI and constraints which have been encrypted by the agents public key. The request also includes a device identifier and a LBSP identifier. The request preferably also includes a token identifier.

The LI and constraints information is then decrypted using the agent's retained private key. The constraints are then interrogated to determine whether the requesting LBSP 15 is authorised to receive the LI. For example the constraints may contain a list of authorised LBSP identifiers, and if the requesting LBSP identifier matches one of these, then it is authorised and receives the LI together with either or both of the device identifier andlor the token identifier in order to indicate which device the forwarded LI relates to. If the request includes the public key of the LBSP 15, then the LI may be encrypted with this prior to being sent to the LBSP 15. However if the requesting LBSP is not authorised, a "declined" message is generated and forwarded indicating that the LBSP 15 is not authorised to receive the LI, no other information need be sent.

The Ll may also be provided with certain restraints, such as information about the length of time a location based service provider may store LI. The agent 16 also preferably keeps a record of the token identifier and which LBSP 15 requested the LI.

The message from the LIPA 16 to the LBSP service entity 15 preferably contains two parts: an encrypted part which contains LI, Expiry and the TokenID, and the signature of the agent 16. The encrypted part is encrypted with the public key of the service entity requesting the LI.This ensures that only the service entity 15 can read this information, preventing malicious parties intercepting data while in transit. Expiry is preferably a time-stamp extracted from the constraints and specifies when the LI expires i.e. when the LI should be deleted. This is the only information from the constraints which needs to be sent to the service entity 16. The TokenID allows the LI subject to relate the LI received from the LIPA to the LI token from which it has been taken. The digital signature allows the receiving entity to check whether the message has been tampered with during transit. If the requesting entity is not permitted to have access to the LI in the token then a PermissionDenied message is sent to the requesting entity 15.

Thus the embodiment cryptographically binds the LI to constraints. This allows freedom for a user to change constraints on a per LI token basis, upon creation of LI.

Of course there may additionally be pre-set rules for general LI. This feature enables the user to have more control over the privacy settings of LI. This enables a greater degree of privacy without divulging extra personal information. By enabling the LIPA 16 to make decisions based on constraints, untrusted entities do not gain access to the information found in constraints or LI. Also, when this information is transmitted, it is done so in an encrypted form. This prevents potential eavesdroppers from accessing this information.

Billing for the various services provided by the system is an important issue. There are various ways the LIPA or agent 16 may generate income for the provision of its service.

For example the LIPA 16 may charge for each request for LI which it receives from a LBSP 15, or each successful request for LI, i.e. when LI is sent to a LBS provider 15 by a LIPA 16. Also, billing may be per LI token or per individual request. The entities which may be billed for the LIPA service are the LI subject 11 and the LBS provider 15. Billing the LI subject 11 may result in a scenario where LBSP's 15 could request LI from the LIPA 16, which will charge the LI subject 1 [whether or not the LBS provider gives any service to the subject 11, so that billing the LBSP 15 is preferred, since the LBS provider 15 can recover the cost of obtaining the LI.

The LI gatherer 13 (unless it is the LI subject 11 him/herself) will also typically require a means of obtaining payment for providing LI tokens 17. However, the LI gatherer may have no obvious party to charge except for the LI subject. Another possibility might be for the LIPA entities 16 to pass on a percentage of charges they make to LBS providers 15 to the LI gatherers 13.

Whilst the embodiment has been described with respect to location information, the mechanism of encrypting token content using an authorising agent may also be applied to the protection of other sensitive personal information. For example this may facilitate controlling how medical information is divulged.

Claims

CLAIMS: 1. A personal information provision service for providing personal

information about a subject to personal service providers; the service comprising: issuing a subject identifier together with said personal information and constraints relating to the dissemination of said personal information, wherein the personal information and constraints are encrypted with an encryption key; receiving a request for personal information from a said personal information service provider, the request including said encrypted PI and C; decrypting said personal information and constraints in order to determine whether said personal information can be provided to said personal information service provider according to said constraints; and if so forwarding said personal information to said service provider.
2. A service according to claim 1 wherein said personal information is location information.
3. A service according to claim 1 or 2 wherein said encryption key is a public key issued by an authorising agent, and wherein the receiving, decrypting, determining and forwarding is performed by said agent.
4. A service according to any one preceding claim wherein said forwarding further comprises forwarding a subset of the constraints to said service provider.
5. A service according to claim 4 wherein said subset of constraints includes a time limits or expiry deadline on the use of the personal information.
6. A service according to any one preceding claim wherein said subject identifier and said encrypted personal information and constraints is issued in the form of a token.
7. A service according to claim 6 wherein said token further comprises a token identifier, an issuer identifier, and a receiver identifier.
8. A system for providing personal information about a subject device to personal information based service providers; the system comprising: an information gathering means for determining said personal information and constraints relating to the dissemination of said personal information; the gathering means arranged to issue a token comprising said location information and said constraints encrypted with an encryption public key, and a subject device identifier without said encryption; the service provider arranged to forward a request for personal information including the token to an authorising agent; the agent arranged to receive said request, decrypt said personal information and constraints, and determine whether said information can be provided to said requesting service provider based on said constraints; the agent further arranged to forward the personal information to the service provider.
9. A system according to claim 8 wherein said personal information is location information.
10. A system according to claim 8 or 9 wherein said encryption key is a public key issued by said authorising agent.
11. A system according to any one of claims 8 to 10 wherein said agent further comprises means for forwarding a subset of the constraints to said service provider.
12. A system according to claim 11 wherein said subset of constraints includes a time limits or expiry deadline on the use of the personal information.
13. A system according to any one of claims 8 to 12 wherein said token further comprises a token identifier, an information gathering means identifier, and an agent identifier.
14. A personal information gathering apparatus comprising: means for determining personal information about a subject and constraints relating to how that information can be disseminated; means for generating a token containing the personal information, the constraints, and a subject identifier identifying the subject, wherein the personal information and the constraints are encrypted with an encryption key; means for forwarding said token to a third party.
15. An apparatus according to claim 14 further comprising means to receive said encryption key in the form of a public key issued by an authorising agent.
16. A personal information based services provider apparatus comprising: means for receiving a token containing a subject identifier identifying the subject of personal information, personal information about the subject and constraints relating to how that information can be disseminated, the personal information and the constraints being encrypted; means for requesting the personal information from an authorising agent by forwarding the subject identifier and the encrypted personal information and constraints to the authorising agent; means for receiving the personal information from the authorising agent.
17. An apparatus according to claim 16 wherein the request includes said token.
18. An authorising agent for authorising the use of personal information about a subject; the agent comprising: means for receiving a request for personal information from a personal information based service provider, the request comprising a subject identifier identifying the subject of personal information, personal information about the subject and constraints relating to how that information can be disseminated; the personal information and the constraints being encrypted with an encryption key; means for decrypting the personal information and constraints; means for determining whether the personal information based service provider is permitted to use the personal information based on the constraints; means for forwarding the personal information to the personal information based service provider.
19. An agent according to claim 18 wherein the encryption key is a public key issued by the agent.
20. A personal information gathering service comprising: determining personal information about a subject and constraints relating to how that information can be disseminated; generating a token containing the personal information, the constraints, and a subject identifier identifying the subject, wherein the personal information and the constraints are encrypted with an encryption key; forwarding said token to a third party.
21. A service according to claim 20 further comprising receiving said encryption key in the form of a public key issued by an authorising agent.
22. A personal information based service comprising: receiving a token containing a subject identifier identifying the subject of personal information, personal information about the subject and constraints relating to how that information can be disseminated, the personal information and the constraints being encrypted; requesting the personal information from an authorising agent by forwarding the subject identifier and the encrypted personal information and constraints to the authorizing agent; receiving the personal information from the authorising agent.
23. A service according to claim 22 wherein the request includes said token.
24. A method of authorising the use of personal information about a subject; the method comprising: receiving a request for personal information from a personal information based service provider, the request comprising a subject identifier identifying the subject of personal information, personal information about the subject and constraints relating to how that information can be disseminated; the personal information and the constraints being encrypted with an encryption key; decrypting the personal information and constraints; determining whether the personal information based service provider is permitted to use the personal information based on the constraints; forwarding the personal information to the personal information based service provider.
25. A method according to claim 24 further comprising issuing a public key as the encryption key.
26. A computer program comprising processor code which is arranged in use to carry out the method of any one of claims 1 to 7 and 20 to 25.