Method and apparatus for transmitting data subject to privacy restrictions

Abstract

A method for transferring data between a service provider and a user is described. The service provider possesses a privacy policy, which may be a predefined privacy policy or a set of privacy policies. The method includes the steps of introducing to a broker a usage policy for the constraints related to the data of the user, receiving a request for data associated with the user from the service provider to the broker, checking in the broker the request against the usage policy of the user, and deciding if the data can be released.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates to data storage and retrieval, and more specifically to granting permissions to operate on data on machines separate from an originating storage. In particular, the invention relates to data transfers between a service provider and a user or to peer-to-peer data transfer, where a user communicates with another user, wherein one of the users acts as a “service provider.”

2. Description of the Related Art

Users may be provided with various types of services via a communication system. The communication system can be seen as a facility that enables communication between two or more entities such as user equipment and/or networks entities or other nodes associated with the communication system. The communication may include, for example, communication of various kinds of data such as voice data, electronic mail (email), text messages, content data, multimedia and so on.

A party of a communication may require privacy or other security features. For example, personal information may be suppressed entirely or partly from another party of the communication. The party requiring the privacy may typically be a user or a consumer of a service provided by a service provider (SP). A service provider may be an entity that is connected to one or more communication systems, for example, the Internet or other data network. The service provider may also be implemented as a part of a communication system. The service provider may also be another user acting as a service provider. Other parties may include, but are not limited to, the intended destination of a message, such as the service provider, or an intermediary handling this message.

Service providers in the Internet may have privacy policies that are posted on their web sites and which provide some protection. All service providers do not have privacy policies. Even if a service provider has a privacy policy, it can change the policy after the user has released data to the service provider. The user has no easy way of comparing service providers' privacy policies. Furthermore, the user has no way to prove under which policy he has provided data to a service provider.

Privacy policies may be based on any appropriate protocol, such as the Platform for Privacy Preferences (P3P) protocol. P3P enables Web sites to express their privacy policies in a standardized format that can be downloaded and read by web browsers and other end-user software tools. These end-user software tools can display information about site's privacy policy to users and take actions based on a user's preferences. Such end-user software tools might provide positive feedback to users when the sites they visit have privacy policies matching their preferences, and provide warnings when a mismatch occurs. The end-user tools may also notify users when a site's privacy policy changes.

In the known solutions, it is hard to check and find a privacy policy matching since virtually every service provider has its own privacy policy. As every service provider has a different privacy policy, it is very difficult for the user to get an overview of different service provider's privacy policies and to compare them.

There is also a need for an improved system for testing the privacy policy matching or otherwise testing that the privacy levels are acceptable for the parties involved or for other such functions. Furthermore, certain applications may require a system enabling the use of different privacy policies with different service providers. It might also be advantageous in certain applications to be able to track later the policy under which the data of the user was released to a certain service provider at a certain moment. In certain embodiments, it might be advantageous to attach a reference to the agreed upon privacy policy to the data that is released.

SUMMARY OF THE INVENTION

According to an embodiment of the invention, there is provided a method for controlling transfer of data between a provider and a user in a communication system where the provider possesses a privacy policy. The method includes the steps of introducing to a broker a usage policy for the constraints related to the data of the user, receiving a request for data associated with the user from the service provider to the broker, checking in the broker the request against the usage policy of the user, and deciding if the data can be released.

In another embodiment, the usage policy for the constraints related to the data of the user is preferably defined by the user. The user may define a strictness level for his usage policy describing constraints related, for example, to the constraints related to the data of the user, such as purpose of use, retention and so on. The user may define the usage policy by means of a predefined set of policies. For this, standardized privacy policies or privacy contracts known by both the service provider and the user may be used. Thus the usage policy of the user is preferably defined by the same elements than the privacy policy of the service provider. The user may also define an acceptable usage policy in a general manner to be respected in relation to any service provider. Such a general acceptable usage policy may then be mapped to a predefined set of policies. A similar mapping mechanism may be carried out for the privacy policy of a service provider to find a common privacy policy. Alternatively, the user may define his usage policy in function of the service provider so that the data to be released may vary between each service provider or each type of service provider. In such a case, the data to be released may refer to an attribute, such as an address, or to a set of attributes, such as a name and an address. The broker may be configured to host the privacy policies and the usage policies. The broker may also carry out the mapping of the policies defined by the user and the service provider, when mapping is required. A negotiation mechanism may be used for the release of data. In certain embodiments, the privacy policies or usage policies may be attached to the released data.

In certain embodiments of the invention the user may easily compare the privacy policies of service providers since they use the same set of policies. In certain applications, the user may attach an electronically signed, legally binding usage policy, i.e. a privacy policy defined by the user, to the data of the user when the data is released to the service provider.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will now be described in further detail, by way of example only, with reference to the following examples and accompanying drawings, in which:

FIG. 1 shows an example of an arrangement in which the invention may be implemented;

FIG. 2 a shows an example of a collection of attributes defining the strictness level 1, “Privacy Strict”, of the privacy policy or usage policy in accordance with one embodiment of the invention;

FIG. 2 b shows an example of a collection of attributes defining the strictness level 2, “Privacy Cautious”, of the privacy policy or usage policy in accordance with one embodiment of the invention;

FIG. 2 c shows an example of a collection of attributes defining the strictness level 3, “Privacy Neutral”, of the privacy policy or usage policy in accordance with one embodiment of the invention;

FIG. 2 d shows an example of a collection of attributes defining the strictness level 4, “Privacy Flexible”, of the privacy policy or usage policy in accordance with one embodiment of the invention;

FIG. 2 e shows an example of a collection of attributes defining the strictness level 5, “Privacy Casual”, of the privacy policy or usage policy in accordance with one embodiment of the invention;

FIG. 3 shows a binding profile describing access and policy of a personal profile of a user in accordance with one embodiment of the invention;

FIG. 4 shows a flow chart of the method of the invention;

FIGS. 5 a, 5 b and 5c show message sequence charts describing ways of handling attribute request and checking of privacy policies and usage policies in accordance with certain preferred embodiments of the invention; and

FIG. 6 shows a message sequence chart describing a way of handling attribute request and checking of privacy policies and usage policies in accordance with another embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS:

FIG. 1 shows an example of an arrangement including a data communication network 10, a plurality of service providers (SP) 12, 14 and 16, and a plurality of end-users 18, 20 and 22. In connection with the invention, the term “service provider” typically means a system for providing services, such as sales, information distribution or any other form of service provisioning that may occur via a communication network. Service provider may also be another end-user. The service provider may also act in certain circumstances as a “Web Services Consumer.” A set of service and identity providers having a business relationship may form a Circle of Trust (CoT).

The communication network 10 may be any appropriate data communication network. In one embodiment, the communication network is provided by the Internet. The terms “user”, “end-user” and “principal” refer to a subject, such as a person, a company, a system or a device, requiring a service provided by the service provider. It shall be appreciated that FIG. 1 is only an example showing three service providers and end-users and that the number of these entities may differ substantially from that which is shown.

FIG. 1 shows also a broker entity 24 configured for operation in accordance with the invention. The broker entity 24 is provided with appropriate devices for the provision of data storage and processing facilities 26 and 28, respectively. The operation of the exemplifying broker entity 24 will become clear from the description of the embodiments of FIGS. 2 to 6.

It is to be noted, that the term “broker” is used herein to describe any network entity or an entity associated with the user being capable to represent the user in the data transfer transaction. The broker may also be referred to as a Web Service Provider (WSP) capable of accomplishing the privacy control functions as described herein. The Web Services Provider provides services to the above-mentioned “Web Services Consumer.” The broker may be located in the network or in the user terminal, for example.

The service provider or the Circle of Trust 12, 14, 16 preferably has a predefined set of privacy policies. These privacy policies may include information such as intended usage, retention, sharing and so on. Preferably, the privacy policies are sequenced according to strictness. The strictness may be an arbitrary metric assigned to a collection of privacy attributes such that higher levels of strictness are assigned values that are higher than lower levels of strictness. It is also possible in certain applications, that the privacy policy of the service provider is undefined.

A user or a principal 18, 20, 22 may define or choose constraints related to his data. The user may, for example, define one or more policies that are acceptable for the release of a specific attribute or class of attributes and for each service or category of services. The user may define to whom and according to what policy data may be released. Usage policies may also describe restrictions related to the use of attribute data. The user may define how the data can be used, with whom the data can be shared, for how long the data can be retained and so on. The data can be any attribute or set of attributes associated with the user, such as name, address, other contact information, profession, payment information, sicknesses, hobbies, preferences or any other data relating to the user.

The user may alternatively choose a default policy that applies for all categories. According to the invention, the privacy policy of the user may also be termed as a “usage policy.” The usage policy may include similar information elements than the privacy policy of a service provider. In one embodiment, the user and the service provider use the same predefined set of policies including the same information elements and set of values.

For example, in an embodiment of the invention, the service provider 12, 14, 16 may ask for attributes related to a user 18, 20, 22. At the same time, the service provider preferably indicates its privacy policy. A broker 24 may then check the privacy policy of the service provider against the usage policy requirement defined by the user for the attributes in question. If the privacy policy of the service provider is equal or more restrictive than the usage policy defined by the user, the requested attribute data is released. If the privacy policy of the service provider is less restrictive than the usage policy, the user may be warned. The user may be asked if he wants to provide the requested data and continue the use of the service, or end the session.

An example of a possible set of different privacy or usage policies that reflect different degrees of strictness is given in FIGS. 2a-e by defining five strictness levels, which may be ranked in order: level 1—privacy strict (FIG. 2a), level 2—privacy cautious (FIG. 2b), level 3—privacy neutral (FIG. 2c), level 4—privacy flexible (FIG. 2d), and level 5—privacy casual (FIG. 2e).

Each privacy or usage policy may include for example following elements or attributes:

• • “Purpose” describing the purposes of data collection or uses of data;
  • “Recipient” describing the recipients of the collected data;
  • “Retention” indicating the retention policy that applies to the data;
  • “Non-identifiable” signifying that no data is collected or that all of the data referenced will be made anonymous upon collection;
  • “Access” indicating whether the service provider provides access to the collected data;
  • “Disputes” describing dispute resolution procedures that may be followed for disputes about a services' privacy practices; and
  • “Remedies” specifying the possible remedies in case a policy breach occurs.

Typically the elements (e.g. purpose, recipient and so on) defining the privacy policy or the usage policy have an acceptable preset value or a set of acceptable preset values. Values of the elements in the level 1 “privacy strict” policy are typically very restrictive, whereas the values of the level 5 “privacy casual” may be very permissive. The privacy or usage policies may be arranged into an ordered set. The policies may be ordered, for example, according to the strictness level or according to any other appropriate criteria.

As mentioned above, in one embodiment, the user and the service provider may use the same set of policies including the same elements and set of values. In other words, the privacy policy and the usage policy preferably refer to similar set of policies. In another embodiment, the set of policies is arranged in an order as explained above. The term “privacy policy” is used in this description to denote a privacy policy defined by the service provider and term “usage policy” is used to denote a privacy policy defined by the user. In this embodiment the comparison of policies may be carried out directly without any preceding mapping of policies.

FIG. 3 shows an example of a binding profile describing access and policy of personal profile of a user or a principal. The profile may be a database of fields that match an attribute or set of attributes 601 of the user to a service provider 603 and usage policy 604. The profile may be stored in the broker or may be accessible to the broker.

The arrangement of FIG. 1 is used here as an example of a system where the invention may be implemented. A user 18, 20, 22 may contact a service provider 12, 14, 16 and request a service. Below, an example is described with reference to a user 18 and a service provider 12. It should be noted, that this is not meant to limit by any means the number or nature of the user or the service provider.

In the arrangement of FIG. 1, a broker 24 may collect information relating to the user privacy, such as user consent, access rules and usage policy. The broker 24 represents the user 18 in the transaction for transferring data between the service provider 12 and the user 18. The service provider 12 may then send to the broker 24 a request for data associated with the user 18. The service provider 12 typically needs this data to proceed with the request of the user 18.

The above procedure is shown in a flow chart in FIG. 4. The usage policy of the user is introduced in the broker (step 1). The broker receives a request for data associated with the user from the service provider (step 2). The broker checks the request against the usage policy of the user (step 3). Following the checking, it is decided if the requested data can be released (step 4).

In another embodiment, the request includes the following elements: an identifier of the user; at least one descriptor of the data sought by the service provider and an indicator of the privacy policy or privacy assurance in effect at the service provider for which the service provider makes an assurance that it will be applied to any data returned by the broker. Such a privacy assurance may have been pre-selected by the service provider from a range of privacy polices or privacy assurances.

The broker may make a check of the privacy policies or usage policies stored within itself or its domain or a place in the networks specified by a Uniform Resource Locator (URL) address. The broker may compare the indicator of the privacy policy of the service provider to the usage policy associated with data of the user that meets the description of the descriptor. The usage policy may have been previously associated with the data by earlier actions of the user. Such a check, or determining step, may be a comparison of a criterion such as policy strictness or a privacy attribute of a privacy policy of the service provider carried in the request.

The criterion is met for example if the privacy policy indicated in the request equals the usage policy of the user. In case the criterion is met, the broker may send at least one datum to the service provider. The at least one datum sent to the service provider is the counterpart to the descriptor included in the request. Such a response by the broker may satisfy the basic query for data that fits or otherwise is looked up based on the descriptor and the identifier of the user.

Failure of the request occurs when the broker makes a determination that a privacy assurance of the service provider is below a criteria previously established by the user associated with the data fitting the attributes of the request. In other words, failure of the request occurs when the privacy policy of the request does not equal or is less strict than the usage policy of the user stored in the broker. A response may include indication of an acceptable usage policy.

Alternatively, the broker may transmit a response bearing an error indicator or invoke an interaction service to check if the user wants to change his policy preference. It is thus indicated in the response that a privacy assurance is below or not equal to a criteria previously established by the user associated with the data fitting the attributes of the request.

In another embodiment, a service provider makes a request to the broker. The request may include an identifier of a user or a principal and at least one descriptor of the data sought by the service provider. The broker may make a check of the privacy policies or the usage policy of the user stored within itself or its domain or a place in the networks specified by a URL address, the check being associated with the at least one descriptor. The broker may then send a response including at least one datum corresponding to the query for data that is looked up based on the at least one descriptor. Additionally, the response typically includes the at least one usage policy that had been previously set by the user for that at least one datum.

The service provider may evaluate the usage policy according to the criteria in effect that moment at the privacy policies of the service provider. Such an evaluation may result in the service provider transmitting an error message. In addition to an error flag, such an error message may include an assurance that the data is being deleted or otherwise discarded.

The broker may transmit an error acknowledgement which may include messages, such as “error received” and “acknowledge receive discard data indication.” Any other messages may also be included in the response depending on the situation. Configuration of these different messages is not limited to the examples given in this text.

The broker may also attach an electronically signed usage policy to the data of the user when the data is released to the service provider. The user may sign electronically his usage policy in any appropriate way.

FIGS. 5 a, 5 b and 5c show signaling flows for some embodiments in accordance with the invention for attribute or data request and checking of privacy policies and usage policies. The privacy policy including for example intended usage set by the service provider 12 may be defined in the request 901, 911, 921. The usage policy required by the user is given in the response 902, 912, 922. In a successful case the privacy policy of the request 901, 911, 921 and the usage policy of the response 902, 912, 922 must match. This means that the usage policy of the user must define values for the attributes comprised in the request 901, 911, 921. In a successful case, the value defined by the user must be the same or less restrictive than the value required by the service provider.

In the example of FIG. 5a, the service provider 12 may request for example the name and the address of the user with PrivacyPolicy_—2 (privacy cautious). The user setting for the usage policy is, in this example, UsagePolicy_—2. The broker 24 then discloses the user name and address using UsagePolicy_—2.

In the example of FIG. 5b, the service provider 12 may request for example the name and the address of the user with PrivacyPolicy_—5 (privacy casual). The user setting for the usage policy is UsagePolicy_—2 (privacy cautious). The broker 24 may disclose name and address using only UsagePolicy_—2. The broker 24 may also indicate in the response that there was a mismatch between the privacy policy and the usage policy. Alternatively, the broker 24 may simply indicate that the required level of the privacy policy is not acceptable, as shown in the example of FIG. 5c.

FIG. 6 shows a situation, when the request 931 does not define the privacy policy level and thus indicates no intended usage. The usage policy is given in the response 932. In this embodiment, the service provider 12 must respect these directives. It is possible, however, that the service provider is not able to respect the level of the usage policy required by the user 18. In that case, the service provider may send to the broker 24 another request 933 including an indication that the required usage policy may not be respected. The broker 24 may, in its response 934, indicate a requirement for further action. Further action, for example, may be to discard the data.

In the embodiments shown in FIGS. 5a-c and 6, the privacy policies and usage policies are as defined above. The service provider 12 sets or chooses among a well known set of policies the privacy policy and the user or principal 18 sets or chooses the usage policy as mentioned above. In accordance to the invention, the usage policy is stored in a broker 24. The broker 24 can decide to disclose attributes only when the usage policy is equal or less strict to the privacy policy the service provider indicated in the request. In case the usage policy is less strict, the broker 24 may disclose attributes using the usage policy equal to the privacy policy given in the request of the service provider. The broker 24 should not change the usage policy defined by the user to attribute association without asking for user consent.

In one embodiment, either the Circle of Trust (CoT) or Liberty has a web site where the five above defined policies are available online. Alternatively the policies can be located at an entity that provides a well known set of policies for a number of CoTs. The message may carry for example an indication, such as “CoTPrivacyUsagePolicyURL” or “LibertyV2.0PrivacyUsagePolicyURL”.

Advantageously, several service providers or sets of service providers may use the same set of policies.

Although the invention has been described in the context of particular embodiments, various alternative embodiments are possible. For example, even if the communication network described in the examples above is mainly the Internet, the invention may be carried out in any other communication network. Examples of other networks may include, but are not limited to, other packet switched networks such as the third generation wireless network technologies like Wideband Code Division Multiple Access (WCDMA), CDMA2000, Universal Mobile Telecommunication System (UMTS) and Enhanced Data rates for GSM Evolution (EDGE). Networks may also include cellular networks such as the public switched telephone network.

In certain embodiments, it is also possible that the user carries out the function of the service provider and the service provider is functioning in place of the user. The terms service provider and user thus describe the function of the entity in question.

Thus, while the invention has been particularly shown and described with respect to specific embodiments thereof, it will be understood by those skilled in the art that changes in form and configuration may be made therein without departing from the scope and spirit of the invention.

Claims

1. A method for controlling transfer of data between a service provider and a user in a communication system where the service provider possesses a privacy policy, the method comprising the steps of: introducing to a broker a usage policy for constraints related to data of a user; receiving a request for data associated with the user from a service provider to the broker; checking, in the broker, the request against a usage policy of the user, and deciding if the data can be released.

2. A method according to claim 1, further comprising the step of using the user to define the usage policy for the constraints related to the data.

3. A method according to claim 1, further comprising the step of providing a predefined set of privacy policies and usage policies.

4. A method according to claim 3, wherein the providing step comprises providing the privacy policies and the usage policies comprising similar information elements.

5. A method according to claim 3, wherein the providing step comprises providing at least one of the privacy policies and at least one of the usage policies which specify a strictness level describing the constraints related to the data.

6. A method according to claim 3, further comprising the step of using the user to choose the usage policies for the constraints related to the data.

7. A method according to claim 5, further comprising the step of releasing user data if the at least one of the privacy policies of the service provider matches with the specified strictness level of the at least one of the usage policies of the user.

8. A method according to claim 5, further comprising the step of indicating, by the broker, the strictness level of the at least one of the usage policies of the user to the service provider if the at least one of the privacy policies of the service provider does not match with the specified strictness level of the at least one of the usage policies of the user.

9. A method according to claim 5, further comprising the step of allowing the user to reduce a usage policy requirement if the at least one of the privacy policies of the service provider does not match with the specified strictness level of the at least one of the usage policies of the user.

10. A method according to claim 1, further comprising the step of attaching an electronically signed usage policy to the data when the data is released.

11. A data transfer system comprising: a service provider possessing a privacy policy; and a broker hosting a usage policy for constraints related to data of a user, configured for checking a request from the service provider against the usage policy of the user and for deciding if data associated with the user can be released in response to the request.

12. A data transfer system comprising: introducing means for introducing to a broker a usage policy for constraints related to data of a user; receiving means for receiving a request for data associated with the user from a service provider to the broker; checking means for checking, in the broker, the request against a usage policy of the user, and deciding means for deciding if the data can be released.