WO2012136652A1

WO2012136652A1 - System of communicating user information for web services

Info

Publication number: WO2012136652A1
Application number: PCT/EP2012/056062
Authority: WO
Inventors: Antonio Manuel Amaya Calvo; Miguel Ochoa Fuentes; José Enrique LÓPEZ GARCÍA; Vanessa ALVAREZ COLINA
Original assignee: Telefonica, S.A.
Priority date: 2011-04-08
Filing date: 2012-04-03
Publication date: 2012-10-11
Also published as: AR085849A1; ES2395443B1; ES2395443A1

Abstract

A system (20) is provided for communication between an end user (21) and a third party service (23) through an Internet Service Provider (22) which handles user information including Personal Identifiable Information, PII, and comprises a PII Broker or PIIB Server (24) for informing the end user (21), request or of an owner user's information, whether the request is accepted or rejected and if accepted, sending links specifying an alias for being used by the third party service (23) in replacement of the PII. Additionally, the system (20) includes a Transparent Filter (25) and a Search Metaportal (26) in the Internet Service Provider (22) and/or an API (28) in the third party service (23) for delivering search requests to the PIIB Server (24). Optionally, a data translator (27) of the end user (21) and a Communications Proxy (29) for the third party service (23) can be included in the system (20).

Description

SYSTEM OF COMMUNICATING USER INFORMATION FOR WEB SERVICES

D E S C R I P T I O N TECHNICAL FIELD OF THE INVENTION

The present invention deals with the handling of personal and confidential information among end-users of a web service and, more particularly, relates to a system for communicating private user information used by the so called Web 2.0 services.

BACKGROUND OF THE INVENTION

Web services boom implies an increase of private and confidential information deposited by individuals and companies on the Internet Service

Providers (ISPs).

Web 2.0 services are based upon users providing the content of the services. In contrast to websites where users are limited to the active viewing of content that they created and controlled, a Web 2.0 site allows users to interact and collaborate with each other in a social media dialogue as consumers of user- generated content in a virtual community. The term Web 2.0 is associated with web applications that facilitate interactive systemic biases, interoperability, user-centered design and developing the World Wide Web. Examples of Web 2.0 services include social networking sites, such as Facebook, Twitter, Tuenti, Orkut, etc..

Certain user information used by these Web 2.0 services, called Personally

Identifiable Information (Pll) is used to uniquely identify, contact, or locate a single person or individual. Pll can include the user's real name, physical mail address, phone numbers and electronic mail address.

Social networks and other content sharing sites provide several methods for restricting access to that kind of personal information, giving users the ability to restrict access to their content. Each social network or Web 2.0 service provider has its own privacy policy that it enforces through its service. But enforcement does not extend past the boundary of the service provider and, even inside that boundary, most of the times the enforcement is not backed by technical means. Furthermore, some data of the Personally Identifiable Information is used by Web 2.0 services to allow users to search for other users. As an example, Facebook allows searching for Facebook users by name. That way, everybody that has an account on Facebook can search for all other Facebook users with a concrete name. Most users have a dual point of view to this functionality:

- On one hand, users most definitely want a subset of the total set of the service users to be able to search and find them. After all, this capability is what allows them to establish connections among other users and that is the main function of some web 2.0 services (social networks, for example).

- But on the other hand, users would like to allow only a subset of all the possible other users to be able to search and find them (and to make things worse, in current web 2.0 services the 'desired' subset of users that they wish to allow searches from, cannot be defined a priori by the own users). Currently, users can know who they want and who they do not want to be able to look them up only after they have been found up by someone. That is, after user B searches for, finds and contacts user A, user A is generally capable of cataloging user A on the 'desired' or 'undesired' contact lists, but by then it is too late: user B already knows user A Personally Identifiable Information.

Privacy enforcement solutions as they are implemented on current systems, when they are implemented, restrict access to PI I on each site by forcing users to authenticate themselves and checking if their identities are on the authorized users' list. But the 'authorized users' list' must be predefined for that to work. And search permissions, when implemented actually, are implemented on an all-or-nothing basis: A user can either allow everyone to search for him/her or deny everyone that ability, but there is no middle ground.

Figure 1 shows a typical scenario of a user uploading some Personally Identifiable Information to a Web 2.0 service, e.g., a Social Network in this case. A content owner (Bob) uploads some Personally Identifiable Information (1 ) to a social network site (10). When he uploads the information he also specifies who can see it, and more importantly, who can search for it. Unfortunately, and since it is quite improbable that even Bob knows the complete set of users he wants to be able to search for his information, the options are restricted to everyone and none. If he chooses 'everyone' then an allowed user (Alice), a person that he wants to be able to contact him can look up to him by a query (2) including Bob's personal information and can get some data from his Pll (3). But also an undesired user (Malice), a person that Bob does not want to be allowed to contact him, is able to look up him too by a similar query (2') and obtain without more difficulty Bob's Pll (3').

As required by law on most countries, current Web 2.0 sites have Privacy Policies implemented and enforced by each service provider, which means that any user that has his/her information distributed on several providers, with access restrictions to their private data (including multimedia data), needs to keep tabs of the different Privacy Policies, usually written on vague terms.

There are some systems, such as the ones described in EP1017205B1 and US2002/017463A1 , which allow the user to control the distribution of his/her personal identifiable information, by generating some kind of fake information or alias to supply to the service providers. EP1017205B1 discloses a method for generating on-the-fly anonymous identities for a user and to propagate those identities to web sites requesting information using the Open Profiling Standard protocol. US2002/017463A1 describes a method and apparatus to generate and maintain anonymous identities (aliases) for a user, and these aliases can be used on third party services (TPS) allowing the TPS operators to contact the user through said anonymous identities.

Generally, on Privacy Policies of the existing systems, the current implementations have the following unsavory characteristics:

- They are ad-hoc solutions. Each Web 2.0 service implements its own privacy policy, with its own enforcement and rules.

- Often they are incomplete solutions. They restrict access to content when its accessed the way the site developer envisioned it, but they allow direct access to content when the normal site navigation is bypassed (by accessing a URL directly instead of navigating to it, for example).

- They do not control copy and redistribution of private data. There is no technical measure in place preventing any user to copy and redistribute another user's private data.

- If some content has been uploaded to several sites, there is no easy way to delete the content from all the sites, other than going to each of the sites and deleting it. - Furthermore, and independently of the Privacy Policy, all or part of the users' PI I must be public if users want to allow other users to find them. When Personally Identifiable Information is used to look up users on Web 2.0 services, every data of said PI I have a characteristic: either being public (and then everyone can look the user up) or being unsearchable (and then none can look this user up).

SUMMARY OF THE INVENTION

The present invention serves to solve the aforesaid problem by providing a unique, centralized, point in which privacy policy can be specified, tailored to the users' need, and where the user has total control over the access by other users to his/her Personally Identifiable Information (Pll). This invention also allows users to create alternative sets of Pll (aliases) but without loosing control of who can access the real Personally Identifiable Information, or any of the aliases, so that end- services (e.g., Web 2.0 services such as Social Networks) can be unable to link aliases to real Personally Identifiable Information. Users can generate the aliases to allow a third party to contact them through said aliases but these alternative sets of Pll cannot be linked to their real Personally Identifiable Information.

The invention refers to a system providing a method for communicating user information, with which third party web services handle, in a protected way so that the user can search on said third parties using his/her real Pll but without granting access to said real Pll to any third party service. The method can be implemented by specific software and hardware residing on a trusted server, to give users the ability to restrict who can access the content, where and when it can be accessed, and to eliminate Personally Identifiable Information from the network. The server uses specific hardware to store long term encryption keys for encrypting the content and store the encrypted files and performs all the necessary cryptographic operations on the files in order to assure the privacy of all the users' information.

In the context of the invention, the following definitions are used:

Personally Identifiable Information (Pll) data: Any information that can identify a given person, such as his name, his national identification number, his telephone number, mail address, etc.

Pll Owner: The person to whom the Pll belongs. Third Party Service (TPS): Any service on which the PI I Owner wants to execute any operation, such as opening an account, which requires Pll data to be given.

Alias (or aliases): A set of 'false' Pll data that a Pll Owner can supply to a TPS instead of the real Pll data.

Pll access request: A request placed by a TPS, on behalf of a user of the TPS, to access the real Pll data behind an alias. A Pll access request includes the data being requested, the TPS requesting it, and the user that desires access to the data (requestor).

Requestor: The user which desires to access the data and that initiates a Pll access request.

End-user: Any user accessing the system (of an Internet Service provider or the system of a Third Party Service provider) where alias data is stored. Both Pll Owners and Requestors are included in this group.

Pll Custodian: A system in charge of guarding Pll data on behalf of the Pll owner. Indeed, the present invention deals with a method implementing a Pll custodian (in an Internet Service provider's system) as described below.

In accordance with an aspect of the invention, there is provided a system for communicating user information, which includes Pll data, applicable on web services, which comprises a Personally Identifiable Information Broker Server, PUB Server, which comprises means for uploading Pll data from an owner user and storing said data using encryption means. The PUB Server is a web server of the Internet Service Provider (ISP) and further comprises:

- An information hub for informing a Requestor whether the requested access to Pll is accepted or rejected by the Pll owner. The information hub comprises means for sending, if the access request is accepted, at least one link to the Requestor, each link specifying an alias for being used by the third party service (TPS) in replacement of the Pll data.

- A search hub for searching the Pll owner on behalf of the Requestor which comprises means for deferring the search until the owner accepts the Requestor's access request and returning one single link to indicate that the Requestor is asking for said Pll owner's permission. In case that the permission is finally granted, the search hub sends at least one link to indicate the TPS to execute the search either by the specified alias or by the PI I data.

Additionally, the system can further comprise the following components: - A Transparent Filter, which is a web server of the ISP configured for intercepting content requests from a certain TPS on behalf of a Requestor and routing the intercepted content requests to the PUB Server. The Transparent Filter further comprises indicating means configured for:

if the intercepted content request is a search answer request, indicating the PUB Server to execute a search on behalf of the Requestor by

PI I data;

if the intercepted content request is a data page request, indicating the PUB Server to execute a search on behalf of the Requestor by the Pll owner's alias specified for the TPS;

- if the intercepted content request is a register page request, indicating the end user, in this case, playing the owner's role, a web page of the PUB Server to specify an alias for the TPS.

A Search Metaportal, which is a search portal of the ISP to which the Requestor can access (even if the Requestor is external to said ISP) specifying a set of TPSs (one or more) to execute searches on behalf of said Requestor. The

Search Metaportal is configured for building a result page containing results from the search executed on behalf of the Requestor by at least one TPS of the specified set and results from the search executed by the PUB Server using the Pll data.

An Application Program Interface (API), integrated in a TPS, through which an end user of the TPS accesses (even if the user is external to the ISP) to act as a

Requestor, requesting search for a Pll owner of said TPS. The API comprises means for communicating with the PUB Server to execute a search by the Pll data and returning results from the search directly to the Requestor.

A Communications Proxy server of the ISP configured for forwarding communications, e.g., telephone calls, short message service (SMS), emails, etc., from a TPS) to a contact address of an owner user. The contact address is contained in the owner's Pll data and obtained by the Communications Proxy from the PUB server using the owner's alias specified by the TPS. An optional data translator installed in a terminal equipment of the end user, configured for detecting data page requests from a TPS and, if a search request by the end user for an owner user is detected, indicating the PUB Server to execute a search by the owner's alias specified for the TPS and, if the request is accepted by the Pll owner, replacing the alias with the Pll data.

The main advantages of the invention can be listed here:

End-users have total control over their Personally Identifiable Information (Pll) and who can search for their Pll, providing effective restriction means to determine who others can access Pll, where they can access it and even when Pll can be accessed by them.

Search functionality is provided that is independent of web 2.0 providers' interpretation of privacy. Moreover, users have a centralized place on which they can manage their own privacy policy for all their information. Allow third party services to contact users by their real Personally Identifiable Information, even when they do not know the alias or fake identity that a user has on a given system. In addition, users can establish alternate sets of Personally Identifiable Information, not linkable to them by third parties.

Furthermore, the invention allows users to discontinue when they want the network presence of any private content they no longer deem appropriate to be public, even to a restricted set of the public.

DESCRIPTION OF THE DRAWINGS

To complete the description that is being made and with the object of assisting in a better understanding of the characteristics of the invention, in accordance with a preferred example of practical embodiment thereof, accompanying said description as an integral part thereof, is a set of drawings wherein, by way of illustration and not restrictively, the following has been represented: Figure 1 . - It shows a schematic representation of communicating personal user information in a possible scenario of a web 2.0. service as known in the prior art.

Figure 2. - It shows a block diagram of a system for communicating personal user information between an end-user and a third party service, according to a preferred embodiment of the invention.

Figure 3. - It shows a message flow relating the blocks of the system depicted in Figure 2, according to a possible embodiment of the transparent filter block of the invention.

Figure 4. - It shows a message flow relating the blocks of the system depicted in Figure 2, according to a possible embodiment of the search metaportal block of the invention.

Figure 5. - It shows a message flow relating the blocks of the system depicted in Figure 2, according to a possible embodiment of the data translator block of the invention.

Figure 6. - It shows a message flow relating the blocks of the system depicted in Figure 2, according to a possible embodiment of the search application program interface block of the invention.

Figure 7. - It shows a message flow relating the blocks of the system depicted in Figure 2, according to a possible embodiment of the communication proxy block of the invention.

Figure 8. - It shows a network scenario according to a possible application of the system depicted in Figure 2, where the end-users are external to the Internet Service Provider and a third party service integrates an API for providing the end- users with access to a Pll broker service. Figure 9. - It shows a network scenario according to another possible application of the system depicted in Figure 2, where the end-users are external to the Internet Service Provider and access to its PI I broker server through a search portal of the Internet Service Provider.

Figure 10. - It shows a network scenario according to a possible application of the system depicted in Figure 2, where the end-users are internal to the Internet Service Provider. DETAILED DESCRIPTION OF THE INVENTION

As shown in Figure 2, a preferred embodiment of the invention relates to a system (20) of communication between an end user (21 ) and a third party service (23) through an ISP or Internet Service Provider (22) which handles user information including Personal Identifiable Information or Pll. The architecture of the system (20) comprises the following modules or functional blocks:

A Personally Identifiable Information Broker Server or PUB Server (24), which can be implemented as a web server of the Internet Service Provider (22) network.

A Transparent Filter (25) always placed in the Internet Service Provider (22) network.

A Search Metaportal (26) always placed in the Internet Service Provider (22) network.

An optional data translator (27), installed on the browsers of the end user's (21 ) device.

An Application Program Interface or API (28) which can be integrated in web 2.0 services such as the third party service (23).

A Communications Proxy (29) to allow the third party service (23) to send messages to the end user (21 ) without knowing the real contact information of said end user (21 ).

Figure 3 shows the PUB Server (24) and Transparent Filter (25) functional blocks of the Internet Service Provider (22) architecture, involved in the message flow among the main modules of the system (20). The end user (21 ) playing a role of Pll Requestor sends from an end user's device a Pll access request (30) that prompts the third party service (23) to send a Pll access answer (31 ). The Transparent Filter (25) is an IP network service that transparently routes the Pll access requests (30) onto predefined third party service (23) and intercepts the Pll access answers (31 ) from said third party service (23) resending them through the

PUB Server (24) in order to take part in performing the search of the requested Pll data to access.

The PUB Server (24) can be implemented as a web service providing the following services:

Data Storage and Protection: This PUB Server (24) stores the Pll data using state-of-the-art symmetric encryption, e.g. Advanced Encryption Standard. The encryption keys can be different for each user's data and protected by a hardware-stored master key.

- Pll Owner Interface: The PUB Server (24) provides the Pll Owner with access to the following services:

Authentication: A Pll Owner has to authenticate himself/herself previously on the PUB Server (24) so that said Pll Owner can access his/her data. Different methods of authentication can be provided, e.g., public key based/password based/physical token based, and an Owner's Interface lets the Pll Owner chose the level of protection required for his/her data.

Creation of an account and upload of Pll data.

Generation of aliases as alternative sets of real Pll data.

Specification of links between aliases and TPS. A link means that the end user (21 ) can use that alias on a specific set of services provided by the web system of the third party service (23). For example, a concrete alias can be used on Facebook, while another alias can be used on Twitter and a third one might be used for Tuenti and Google.

Accept or reject Pll access requests (30).

Information hub: The PUB server (24) informs the Pll Requestors when their data access requests (30) have been approved, sending them links to the correct information through the own communication means of the third party service (23).

Search hub. The PUB server (24) allows the third party service (23) to execute searches on behalf of Pll Requestors and provides two kinds of search requests (32): either searches by real Pll data either searches by alias or fake Pll data. Thus the PUB server (24) defers the searches until the Pll Owner has accepted them and then the search answer (33) returns just links to allow the Pll Requestor to indicate that the Requestor wants to ask permission of the Pll owner. That way, the Pll owner can decide who can search for him/her, and who cannot, when a search is executed.

Note that the PUB server (24) supports several sub-scenarios for the creation of aliases. A Pll Owner can create one or more aliases either manually, by accessing the PUB Server, or automatically while accessing a third party service (23) through the Transparent Filter (25).

If the Pll Owner accesses a supported register portal of the third party service (23) through the Transparent Filter (25), then the following process ensues to create an alias automatically:

o The Transparent Filter (25) detects the register page of the third party service (23).

o The Transparent Filter (25) redirects the Pll Owner to a page of the PUB Server (24) in which the Owner is asked whether he/she wants to define a new alias for said third party service (23) or use a previously defined alias. Should the Pll Owner answer 'yes', a new alias is created, or a previously created one is selected, and the corresponding alias Pll data forwarded to the third party service (23) automatically, without any further intervention from the owner/user. If the third party service (23) is unknown or unsupported or the Pll Owner access without Transparent Proxy (25), then the process to create an alias is carried out as follows:

o The Pll Owner accesses the PUB server (24) and chooses the option to create a new alias. o The PUB server (24) asks which data the alias should include, such as name, surname, telephone number, etcetera, create an adequate set of fake data for the new alias and allow the Pll Owner to copy the sat of fake data.

o The Pll Owner can then access the register page of the third party service (23) and fulfil the register page with the fake data provided by the PUB server (24). If the third party service (23) is unsupported by the system (20), the automatic search by real name and the automatic data translation do not apply but communications proxying works correctly.

Transparent Filter (25) shown in Figure 3 allows the Pll access request (30) to go unfettered, i.e., the outgoing communications from the end user (21 ) to the Transparent Filter (25) passes transparently; while the incoming communications to the end user (21 ) are intercepted by the Transparent Filter (25) in order to deliver a search modified answer (34), which depends upon the content of the intercepted communication. The Transparent Filter (25) can be implemented by an application level proxy, for instance, HTTP/HTTPS proxy, which is content aware, and runs different processes according to the following scenario cases:

1 . If the content intercepted is a search answer (33), the Transparent

Filter (25) executes a query on the PUB server (24) using the search terms as real Pll data. The query sent to the PUB server (24) includes the -requestor- end user's identity on the third party service (23). The PUB server (24) executes the query and return two kind of results:

i.1 ) A set of results linking to alias profiles of Pll Owners that have approved previously the requestor access to the data.

i.2) A result that includes a link to allow the Pll Requestor to request access to the profiles that have still not access granted. Note that this result is a single link for all the possible identities, without giving any information of how many identities have been found.

2. If the content intercepted is a data page that includes Pll data for a given profile on the third party service (23), the Transparent Filter (25) executes a query on the PUB server (24) searching by alias information, instead of searching by real data as in the abovementioned case 1 . The query includes the end user information as 'requestor'. The query can find one or zero results. In case a result is found, the PUB server (24) checks whether the Pll Owner has previously granted the requestor access to the real Pll data. If said access has been granted, then the information is returned to the Transparent Filter (25) which replaces it and returns the modified page to the user. Otherwise, in the case that no access to the real Pll data has been granted, or if the query returns no result, then the page is returned unmodified, within the search modified answer (34), to the end user.

3. If the content intercepted is a register page, i.e., the page used by the third party service (23) to register new users, then the Transparent Filter (25) redirects the Pll Owner to a page on the Pll server (24) where the Pll Owner is asked whether he/she wants to create a new alias for that third party service (23) or use a previously created one. In case the Pll Owner answers 'yes' the profile is created, and all the required data is forwarded to the third party service (23) without any further Pll Owner intervention.

The Transparent Filter (25) can work in two modes of operation:

- Transparent mode, where the service is provided by the network without any end user's intervention. This mode is available only to customers of the Internet Service Provider (22) providing the described PUB broker service through the Pll server (24).

- Manual mode, where the service is configured as a proxy by the end user. This mode is available to all users with any network location, regardless of being outside the network of the Internet Service Provider (22) or if the user is connected to said ISP network.

For end users (21 ) that are not customers of the Internet Service Provider (22) providing the service and do not want to manually configure the Transparent filter (25), a Search Metaportal (26) is provided in the system (20). Figure 4 shows the Search Metaportal (26) of the Internet Service Provider

(22) performing the following processes:

1 ) Execution of a first query (42) on the PUB server (24) by real Pll data. The query data includes the Requestor's identity on each of the third party service (23). The PUB server (24) returns two kinds of results from the query process:

1.1 ) A set of results linking to alias profiles of Pll owners that have approved previously the requestor access to the data.

1.2) A result that includes a link, a single link for all the possible identities, in order to allow the Requestor to request access to the profiles whose access is still unapproved by the Owners to said Requestor. No information is given on how many identities have been found.

2) Execution of a second query (44) on the third party service (23) by using the allowed alias profiles of the Pll owners or the previously defined single link if the Requestor is still not allowed to access said alias profiles.

3) Construction of a result page (46) which comprises the results returned by the aforementioned two queries: the results (45) from the third party service (23) and the query results (43) returned from the PUB server (24).

The Search Metaportal (26) is a search portal for all the third party service (23) defined in the system (20). A Requestor end user (21 ) sending an Pll access request (41 ) to the search Metaportal of the Internet Service Provider (22) provides some real Pll data which the Requestor desires to search for, e.g., a surname, and specifies a set of third party services (23) from the ones defined in the system (20), where said end user (21 ) wants to execute the query.

For end users (21 ) that are not customers of the Internet Service Provider (22) providing the service and do not want to manually configure the Transparent filter (25), a data translator (27) implemented at the end user's (21 ) device can be provided. The data translator (27) can be a web browser plugin and implements the content rewriting part of the process for the Transparent filter (25) described before.

Figure 5 shows interaction of the data translator (27) of the end user (21 ) with the PUB server (24) of the Internet Service Provider (22) and the defined third party services (23). The data translator (27) carries out the following steps: - Detecting content pages (51 ) for the supported third party service (23) which uses the aliases data.

- For each content page that includes PI I data, executing a query (52) on the PUB server (24) searching by alias information, instead of searching by real Pll data. The query includes the end user information as 'requestor'. The query can find one or zero results. In case a result is found, the PUB server (24) checks whether the Pll Owner has previously granted the requestor access to the real Pll data.

- If access has been granted, the Data Translator (27) receives information (53) to replace the content page that includes Pll data and returns the modified page to the end user (21 ).

- If access has not been granted or in the case that the query returns no result, then the Data Translator (27) returns the content page unmodified to the end user (21 ).

The Data Translator (27) in the end user's (21 ) device is completely optional for the system (20) to work. A Requestor that does not use Data Translator (27) in the device just sees the aliases data, instead of the real data, of the supported third party service (23) even if said Requestor is approved to access the real Pll data.

Since some of the real Pll data is contact personal information, such as telephone numbers or mail addresses, a communications proxy (29) can be included in the system (20) to allow the defined third party service (23) to contact the Pll Owner even without providing the real contact information. The communications proxy (29), shown in Figure 6, is provided by the Internet Service Provider (22) just to forward the communications from the fake contact address to a real one. The third party service (23) sends to the Internet Service Provider (22) a communication request (61 ) comprising aliases data, i.e., the fake contact address. The communications proxy (29) sends a request (72) for real contact data to the PUB server (24) corresponding to the aliases data provided by the third party service (23). The PUB server (24) returns contact personal information (73) from the real Pll data which is mapped to the given aliases and the communications proxy (29) forwards the communication (74) using said real data. The communications proxy (29) is modular so that additional communications forwarding processes can be defined as they are introduced in the system (20). Some preferred implementations are: telephone Call forwarding, telephone SMS forwarding and electronic Mail forwarding.

In order to cover all the possible integration scenarios, the system (20) can include also a search API (28) which the third party service (23) can choose to integrate in their services, allowing the end user (21 ) the use of the PUB Server (24) from the own services provided by said third party service (23). This API (28) allows any end user (21 ) external to the Internet Service Provider (22) implementing the proposed solution to search for other users without using the Search Metaportal (26) of the Internet service provider (22).

Figure 7 shows the processes followed for user search using the API (28) integrated in the third party service (23). When an end user (21 ) which is a Requestor user of the third party service (23) wants to search for other users, the Requestor accesses the third party service (23) inputting the search terms by means of an access request (71 ) to a search result generator (70) provided by the third party service (23). Thus the third party service (23) can execute the search locally but first the search terms (72) are forwarded to the PUB Server (24) through the search API (28) in order to order a search request (73) to the PUB Server (24) for search by real Pll data. The query data sent to the Pll Server (24) includes the

Requestor's identity. The PUB server (24) executes the query but the results are not to be returned to the third party service (23); instead, the search results are sent directly to the Requestor, the end user (21 ). There are two kinds of results returned by the PUB server (24) once the query is performed in the domain of the Internet service provider (22):

- A set of results linking to alias profiles of Pll owners that have approved previously the requestor access to the data.

- A result that includes a link to allow the Requestor, end user (21 ), to request access to the profiles not approved to said end user (21 ). Note that it is a single link for all the possible identities, without giving any information of how many identities have been found.

The third party service (23) can consult (73) the PUB server (24) through the API (28). If the third party service (23) is privacy aware and Personally Identifiable Information aware, the third party service (23) can mark which profiles are protected. The PUB server (24) informs (64) the third party service (23) on how many -if any- protected profiles meet the query criteria, when an end user (21 ) of the third party service (23) executes a query with real Pll data. Then the third party service (23) can insert a message (65) with a search reference returned by the PUB server (24) on the return content page (66), which is sent to the end user (21 ) for informing the Requestor end user (21 ) that there are protected data and providing a link to ask for access to the protected data. The link gives access directly to the PUB server (24), that is, for example, if the Requestor gets into said link, a message including the requestor's identity is sent to all the Pll Owner(s) asking for their permission to share their real Pll data. For every user that grants the permission request, the PUB Server (24) sends a message to the Requestor end user (21 ), including a link to access the protected profile, through the messaging means of the third party service (23). Figures 8, 9 and 10 show three different possible scenarios for using the system (20), respectively:

Figure 8 shows the above described scenario with end users (21 ) external to

Internet Service Provider (22) when the third party service (23), which is a Web 2.0 service such a Social Network, integrates the API (28);

Figure 9 shows with end users (21 ) external to the Internet Service Provider

(22) when no API is integrated in the Web 2.0 service and the access to the Pll

Broker Server (24) is through a Search Metaportal (26); and

Figure 10 shows when end users (21 ) are internal to the Internet Service

Provider (22) implementing the Pll Broker Server (24).

An embodiment of the process for executing a search using the search metaportal (26) shown in Figure 9 can be summarized as follows:

An end user (21 ), the Requestor, accesses the search metaportal (26) and provides the query data, i.e., real Pll data to look for, and the identifier of the Social Network, i.e., the third party service (23), in which to search. The search metaportal

(26) returns translated search data including protected data and a notification like There are additional users which have protected data that fits your search criteria. Do you wish to ask them for permission to access their data? Note: your identity will be forwarded to the users to ask for their permission'. If the requestor wishes to ask for permission of the Pll Owner(s), the -Requestor— end user (21 ) presses the link and triggers the sending of a message to all the Pll Owner(s) asking for their permission to share their real Pll data. The triggered message includes the end user's (21 ) identity. On the other hand, for every Owner user that grants the request, the PUB Server (24) sends a message to the end user (21 ) using the messaging system of the social network. The message includes a link to access the protected profile.

For executing a search of internal users of the Internet Service Provider (22) the search process uses transparent filter (25) as shown in Figure 10. The -

Requestor- end user (21 ) accesses the search portal of a Social Network and executes a query. For the query, the end user (21 ) provides real Pll data, for which said end user (21 ) is looking in the query, to the third party service (23) which executed the query and returns the results found. At this step, the Transparent Filter (25) detects a search answer page and intercepts it to complement the data with the protected data. The returned data includes protected data and a notification like There are additional users which have protected data that fits your search criteria. Do you wish to ask them for permission to access their data? Note: your identity will be forwarded to the users to ask for their permission'. If the Requestor end user (21 ) wishes to ask for permission of the Pll Owner(s), he can press said link and a message, comprising the requestor's identity, is sent to all the Pll Owner(s) asking for their permission to share their real Pll data. For every user that grants the request, the PUB Server (24) sends a message to the end user (21 ) which includes a link to access the protected profile by using the messaging system of the social network.

There are three data scenarios for accessing to a protected profile, i.e., to access data from a profile controlled by the third party service (23) which has alias Pll data.

a) Through the transparent filter (25)

A requestor user that accesses a protected profile through the transparent filter (25) can see the real Pll data if that right has been granted by the Pll Owner. The transparent filter (25) replaces the alias Pll data with the real Pll data.

b) Through the data translator (27) A requestor user that accesses a protected profile through the data translator (27) can see the real data if that right has been granted by the Pll Owner. The data translator at the requestor's device is in charge of replacing the alias Pll data with the real Pll data.

c) Through the API (28)

If the third party service (23) is implementing the Search API (28), then the TPS can use it to substitute the fictitious data with the real data. The real data is not sent the to the third party service (23) in any case, the API (28) sends the real data directly to the -Requestor— end user (21 ).

There are several sub-scenarios for the creation of an alias to substitute the real Pll data: A Pll Owner can create an alias manually by accessing the PUB Server (24) or the alias can be created automatically while accessing the third party service (23) through the Transparent Filter (25).

The Pll Owner can create an account on the PUB Server (24) by the following steps: The Pll Owner selects an identification mechanism, such as user and password, or electronic identity card, in the PUB Server (24) to which the Pll Owner accesses and, using said identification mechanism, introduces the real Pll data in the system.

Note that in this text, the term "comprises" and its derivations (such as "comprising", etc.) should not be understood in an excluding sense, that is, these terms should not be interpreted as excluding the possibility that what is described and defined may include further elements, steps, etc.

Claims

C L A I M S

1 . - A system (20) for communicating user information, which includes Personal Identifiable Information for web services, between an end user (21 ) and at least a third party service (23) through an Internet service provider (22), the system

(20) comprising:

- a Personally Identifiable Information Broker Server, PUB Server (24), which comprises means for uploading Personal Identifiable Information from an owner user and storing said Personal Identifiable Information using encryption means;

characterized in that the PUB Server (24) is a web server of the Internet

Service Provider (22) and further comprises:

- an information hub for informing an end user (21 ), which requests access from the PUB Server (24) to Personal Identifiable Information of an owner user, whether said access request is accepted or rejected by the owner user and the information hub comprises means for sending at least one link to the end user (21 ), if the access request is accepted, each link specifying an alias for being used by the third party service (23) in replacement of the Personal Identifiable Information;

- a search hub for searching an owner user on behalf of the end user (21 ) which comprises means for deferring the search until the owner user accepts the access request to the Personal Identifiable Information and returning one single link to indicate that the end user (21 ) asks for the owner user's permission and, if permission is granted, at least one link to indicate the third party service (23) to execute the search either by the specified alias or by the Personal Identifiable Information.

2. - The system (20) according to claim 1 , wherein the information hub of the PUB Server (24) uses communication means of the third party service (23) for sending the at least one link to the end user (21 ), if the access request is accepted.

3. - The system (20) according to any preceding claim, further comprising a

Transparent Filter (25), which is a web server of the Internet Service Provider (22) and configured for intercepting content requests, selected from search answer requests, data page requests and register page requests, from a certain third party service (23) on behalf of an end user (21 ) and routing the intercepted content requests to the PUB Server (24).

4. - The system (20) according to claim 3, wherein the Transparent Filter (25) is provided by the Internet Service Provider (22) automatically without intervention from the end user (21 ) of said Internet Service Provider (22)..

5. - The system (20) according to claim 3, wherein the Transparent Filter (25) is configured as a proxy by any end user (21 ) within the Internet Service Provider (22) or outside said Internet Service Provider (22).

6. - The system (20) according to any of claims 3-5, wherein the Transparent Filter further comprises indicating means configured for:

- if the intercepted content request is a search answer request, indicating the PUB Server (24) to execute a search on behalf of the end user (21 ), which searches for an owner user, by the Personal Identifiable Information of the owner user;

- if the intercepted content request is a data page request, indicating the PUB Server (24) to execute a search on behalf of the end user (21 ), which searches for an owner user, by the alias of the owner user specified for the third party service (23);

- if the intercepted content request is a register page request, indicating the end user (21 ) a web page of the PUB Server (24) to specify as owner user an alias for the third party service (23).

7. - The system (20) according to any preceding claim, further comprising a Search Metaportal (26), which is a search portal of the Internet Service Provider (22) to which an end user (21 ) requesting search for an owner user accesses from outside said Internet Service Provider (22) specifying a set of at least one third party service (23) to execute searches, and the Search Metaportal (26) is configured for building a result page containing results from the search executed on behalf of the end user (21 ) by at least one third party service (23) of the specified set and results from the search executed using the Personal Identifiable Information of the owner user by the PUB Server (24).

8. -The system (20) according to any preceding claim, further comprising an API (28) integrated in a third party service (23) which is Application Program Interface through which an end user (21 ) of the third party service (23) accesses (22) from outside the Internet Service Provider to request search for an owner user of said third party service (23), and the API (28) comprises means for communicating with the PUB Server (24) to execute a search by the Personal Identifiable Information of the owner user and returning results from the search directly to the end user (21 ).

9. - The system (20) according to any preceding claim, further comprising a data translator (27) installed in a terminal equipment of the end user (21 ) configured for detecting data page requests from a third party service (23) and, if a search request by the end user (21 ) for an owner user is detected, indicating the PUB Server (24) to execute a search by the alias of the owner user specified for the third party service (23) and, if the request is accepted by the owner user, replacing the alias with the Personal Identifiable Information of the owner user.

10. - The system (20) according to claim 9, wherein the data translator (27) is a web browser plugin.

1 1 . - The system (20) according to any preceding claim, further comprising a Communications Proxy (29) which is a proxy server of the Internet Service Provider (22) configured for forwarding communications from a third party service (23) to a contact address of an owner user, the contact address being contained in the Personal Identifiable Information of the owner user and obtained by the

Communications Proxy (29) from the PUB server (24) using the alias of the owner user specified by the third party service (23).

12. - The system (20) according to claim 1 1 , wherein Communications Proxy (29) is configured for forwarding communications selected from a telephone call, SMS, and electronic mail from the third party service (23).

13. - The system (20) according to any preceding claim, wherein the PUB server (24) further comprises means for creating, for at least a third party service (23), aliases of an owner user which accesses to the PUB server (24).

14. - The system (20) according to any preceding claim, wherein the search hub of the PUB server (24) is configured for returning links indicating the alias specified for a certain third party service (23) of every owner user which accepts access request by the end user (21 ).

15. - The system (20) according to any preceding claim, wherein the third party service (23) is a Web 2.0 service.