WO2009132664A1

WO2009132664A1 - Method and system for providing recommendations to users

Info

Publication number: WO2009132664A1
Application number: PCT/EP2008/003467
Authority: WO
Inventors: Florian Winkler; Daniele Abbadessa; Robert De Groote; Martin Snijders; Joost Broekens
Original assignee: Nec Europe, Ltd.
Priority date: 2008-04-29
Filing date: 2008-04-29
Publication date: 2009-11-05

Abstract

A method for providing recommendations to users, wherein a user accesses a Service Provider under a pseudonym provided by an Identity Provider, wherein said Service Provider requests personalized recommendations for the user from a Recommender Service, and wherein said Service Provider, upon retrieval of said recommendations from said Recommender Service, provides said recommendations to the user is characterized in that the message exchange between said Service Provider and said Recommender Service is decoupled by adding an indirection in form of an additional component serving as Recommendation Broker. Furthermore, a corresponding system is described.

Description

METHOD AND SYSTEM FOR PROVIDING RECOMMENDATIONS

TO USERS

The present invention relates to a method for providing recommendations to users, wherein a user accesses a Service Provider under a pseudonym provided by an Identity Provider, wherein said Service Provider requests personalized recommendations for the user from a Recommender Service, and wherein said Service Provider, upon retrieval of said recommendations from said Recommender Service, provides said recommendations to the user.

Furthermore, the present invention relates to a system for providing recommendations to users, the system comprising at least one Service Provider that can be accessed by a user under a user's pseudonym provided by an Identity Provider, and at least one Recommender Service that upon request provides personalized recommendations for the user to said Service Provider.

A personalized service is a service that is tailored to an individual or group of individuals. Personalization typically involves maintaining user-specific information, such as user preferences. In order for a personalized service to be delivered to an individual, the service provider has to know for whom it is requested.

The type of personalized service addressed first and foremost by the present invention is content recommendation. Because of the ever-growing amount of content available both on the internet as well as through classical media such as broadcast television, individuals are faced with a very large number of choices on what content to consume. This may result in information overload and an increased difficulty to find relevant content as described for example in M. van Setten "Supporting People in Finding Information", PhD Thesis, University of Twente, 2005. Content recommendation addresses this problem by proposing personalized content to an individual based on his or her preferences.

A recommendation service is typically used by content (or other kinds of services) offering entities to enhance the quality of the offers to their customers. This means that three parties are involved: the (content) service provider, the recommender service, and the end-user. For the service provider to be able to request a recommendation for a specific user, it has to indicate that user's identity to the recommender service. As there can be many recommender services, service providers and users, it is necessary to have a standard and safe way of talking about users. This should take, for example, user privacy and the management of user data (e.g. bank account, social security number) into account. Such functionality is provided by an Identity Management (IdM) framework, such as Liberty Alliance (http://www.projectliberty.com).

Within an IdM framework, a user typically identifies itself with a pseudonym. This pseudonym is used to identify that unique user to any service provider. A service provider uses this pseudonym to retrieve properties relevant to the services it offers. These properties are retrieved from a central component that knows the mapping between pseudonyms and identities, the Identity Provider (IdP). The IdP also knows which services may access what properties. For example, a bank is allowed to retrieve a user's bank account, whereas a web-shop is allowed to retrieve a user's shipping address. The advantage of using a pseudonym is that it enables a user to remain anonymous to a self-controlled extent. Pseudonyms thus enable different service providers to communicate about the same user without knowing the user's actual identity.

Although the three parties involved in the above given example of content recommendation can now communicate about a user in an anonymous way, the recommender service is still able to know more about an individual than strictly needed.

In the context of the following example it is assumed that there is a recommender service R that already contains user preferences for a user U. It is irrelevant in what way R acquired these preferences. We assume that services request recommendations from the recommendation service R by including a pseudonym for user U and the content (or list of content items) for which a recommendation is requested. The recommendation service R returns a measure of interest (or list of measures) in the content for user U. Content in this perspective means anything for which a measure of interest can be returned such as a product, a list of products, a person, a service, etc. The content can also be empty, in which case it is assumed that the recommendation service sends back a list of measures of interest in content items generated by the recommendation service.

Consider two content services, A and B, which both directly invoke R for user U, identified by pseudonyms P(A) and P(B), i.e. both A and B request a recommendation from R based on the pseudonyms of U. In order for R to recommend something about U, R needs to resolve both P(A) and P(B). As both P(A) and P(B) refer to the same user U, they both map to the same set of preferences Prefs(U) at the recommender service. Prefs(U) was gathered by R before.

The recommender service R can now do the following. First, R can link the user U to both services A and B. This means R can gather service-specific usage statistics for user U. Strictly, the information about U's service usage that can in this way be gathered by R is not needed by R to fulfill its recommendation service, because R only needs content information sent by services A and B to generate a measure of interest to be returned to the recommendation request by A or B. Second, R is able to link the different pseudonyms P(A) and P(B) of user U to each other via Prefs(U). This means R can effectively build up a set of pseudonyms used by U which might allow it to deduce additional information about the user. As the user is unaware of the fact that this information can be gathered by R, this can be considered a violation of the user's privacy.

Existing IdM models such as Liberty Alliance (http://www.projectliberty.com), WS- Federation and WS-Trust (http://www.ibm.com/developerworks/library/ specification/ws-fed/) allow identity information to be shared across organizational boundaries using some form of pseudonyms. However, both models do not address the problems mentioned above.

It is therefore an object of the present invention to improve and further develop a method and a system of the initially described type for providing recommendations to users in such a way that, by employing mechanisms that are readily to implement, information about a user is protected as much as possible so that privacy concerns are widely avoided.

In accordance with the invention the aforementioned object is accomplished by a method comprising the features of claim 1. According to this claim, such a method is characterized in that the message exchange between said Service Provider and said Recommender Service is decoupled by adding an indirection in form of an additional component serving as Recommendation Broker.

Furthermore, the aforementioned object is accomplished by a system comprising the features of independent claim 18. According to this claim, such a system is characterised in that it comprises an indirection in form of an additional component serving as Recommendation Broker that decouples the message exchange between said Service Provider and said Recommender Service.

According to the invention it has first been recognised that existing personalized anonymous recommendation services reveal dispensable information about a user which is not necessarily required for providing personalized recommendations and that such dispensable information may harm a user's privacy. According to the invention an additional component is introduced which will function as a Recommendation Broker. The Recommendation Broker is a component that relays requests for recommendations of Service Providers to available Recommender Services. The Recommendation Broker serves as a kind of back to back user agent that decouples Service Providers and Recommender Services and thus allows for information hiding in such a way that neither of the involved parties has the possibility to harm a user's privacy. By introducing the Recommendation Broker in such a way users will receive anonymous recommendations from services that neither know the identity of a requesting user nor are capable to trace the usage pattern of a user in any way. Furthermore, it is ensured that neither of the parties involved in the recommendation process has any information that could harm the end-user's privacy. In particular, a recommender service is not able to correlate pseudonyms, link a user identity to services or infer service-specific usage not needed for recommendation. The main advantages of the present invention are that there is no need to trust the Recommender Service or the Recommendation Broker. Furthermore, the Recommendation Broker may provide a single point of access which facilitates finding recommendation service for interested third parties. Recommendations can be used in a secure and privacy-protecting way. Moreover, by the introduction of a Recommendation Broker it is possible to deploy a Recommender Service in such a way that only Recommendation Brokers would be able to call the Recommender Service (e.g. by placing the Recommender Service behind a firewall). This is attractive from a data safety point of view.

According to a preferred embodiment said Identity Provider, said Service Provider and said Recommendation Broker constitute a Circle of Trust, for instance as defined by Liberty Alliance and SAML 2.0. Among other things, this would allow the user to benefit from true Single Sign On technology and anonymous service usage.

According to a specific embodiment it is provided that the Service Provider sends a recommendation request message containing the request for recommendations to the Recommendation Broker. In addition to the request for recommendations, the recommendation request message may contain the user's pseudonym. The pseudonym's format allows the Recommendation Broker to derive which IdP to contact. The user's pseudonyms are managed by the Identity Provider and it is accepted that the Identity Provider is able to link pseudonyms to subsets of the user's identity information. For easy identification of the Recommender Service, it may be provided that the recommendation request message additionally contains the Recommender Service URI (Uniform Resource Identifier).

According to a preferred embodiment the Recommendation Broker exchanges the user's pseudonym contained in the recommendation request message with a Recommendation Profile Identifier (RPID) of the user. As regards the RPIDs it may be provided that the Identity Provider performs the mapping of user's pseudonyms and user's RPIDs. Advantageously, such mapping is performed individually for each Recommender Service. As regards an easy provision of the RPID by the Identity Provider, it may be provided that the Recommendation Broker requests the RPID from the Identity Provider, wherein the user's pseudonym and the Recommender Service URI are specified within the respective request message. Based on the received information the Identity Provider is enabled to forward the correct RPID to the Recommendation Broker. To further ensure user's privacy it proves to be advantageous that the Identity Provider forwards the RPID to the Recommendation Broker in an encrypted form. Specifically, the Identity Provider may use the public key of the respective Recommender Service for encryption of the RPID. By this means it is assured that the Recommendation Broker cannot see the RPID, which would allow it to link RPIDs to pseudonyms, and thus the Recommendation Broker would be able to link pseudonyms together.

According to a further advantageous embodiment, it may be provided that the recommendation request message sent from the Service Provider to the Recommendation Broker contains the request for recommendations in an encrypted form. The encryption may be performed by the Service Provider. Specifically, the Service Provider may compose the request for recommendations by including a secret key, wherein said secret key may be derived from the public key of the Recommender Service. The inclusion of such a secret key allows the Recommender Service and the Service Provider to set up a secure communication channel without the intermediary Recommendation Broker being able to retrieve any information from the communication.

Furthermore, it may be provided that the Service Provider employs the public key of the Recommender Service for encrypting the request for recommendations. This encryption is to ensure that the Recommendation Broker cannot read the message intended for the Recommender Service.

As regards an efficient provision of the public key of the Recommender Service to the Service Provider, it may be provided that the Service Provider, after a user accesses the Service Providers, demands the public key from the Recommender Service. Such a demand of the public key of the Recommender Service may include sending a message containing the Recommender Service URI from the Service Provider to the Recommendation Broker and forwarding said message from the Recommendation Broker to the Identity Provider. Based on the received Recommender Service URI, the Identity Provider is enabled to look up the respective public key and to forward the public key certificate of the Recommender Service via the Recommendation Broker to the Service Provider. Alternatively, the public key of the Recommender Service may not be retrieved from the Identity Provider itself but from a separate, independent Key Authority that issues these keys and provides them to the requesting parties. Verification of keys can be done by certificate chains as it is common for PKI (Public Key Infrastructure) encryption standards.

The Recommendation Broker, after having received the encrypted RPID from the Identity Provider, may forward a message to the Recommender Service, the message containing the encrypted RPID of the user and the encrypted request for recommendations. Upon receipt of that message sent from the Recommendation Broker, the Recommender Service may decrypt the request for recommendations, may extract the secret key included by the Service Provider, calculate the recommendations, encrypt the calculated recommendations using the secret key, and sending the encrypted recommendations back to the Recommendation Broker. Again, the encryption is to make sure that the Recommendation Broker cannot read the recommendation. The Recommendation Broker may forward the encrypted recommendations to the Service Provider that may decrypt the recommendations and forward them to the user.

There are several ways how to design and further develop the teaching of the present invention in an advantageous way. To this end, it is to be referred to the patent claim subordinate to patent claims 1 and 18 on the one hand, and to the following explanation of a preferred example of an embodiment of the invention illustrated by the drawing on the other hand. In connection with the explanation of the preferred example of an embodiment of the invention by the aid of the drawing, generally preferred embodiments and further developments of the teaching will be explained. In the drawings Fig. 1 illustrates schematically the involved parties of an anonymous recommendation system according to an embodiment of the present invention,

Fig. 2 depicts a sequence diagram illustrating a method for providing recommendations to users according to an embodiment of the invention and

Fig. 3 depicts a sequence diagram illustrating a method for providing recommendations to users according to another embodiment of the present invention with a separate key authority.

Fig. 1 schematically depicts the involved parties of an anonymous recommendation system according to an embodiment of the present invention. The involved parties are a user, an Identity Provider, a Service Provider, a Recommender Service, and a Recommendation Broker. Service Provider, Recommender Service and Recommendation Broker may reside in domains that are not trusted by the user. On the other hand, the Identity Provider will reside in a trusted domain.

More specifically, the user trusts its Identity Provider in such a way that it accepts that the IdP is able to link pseudonyms to subsets of the user's identity information. At the same time the user does not trust the Service Provider to do that, on the contrary, it wants to ensure that the Service Provider is in no way able to trace the user's behavior related to the use of other services or find out about a user's identity. The same holds for the relationship between the user and the Recommender Service. The Recommender Service is neither trusted by the user, i.e. it should not have any possibility to link its Recommendation Profiles to a particular user's identity.

Service Provider, Recommendation Broker and Identity Provider are in a circle of trust as defined by Liberty Alliance and SAML 2.0, which among other things allows the user to benefit from true Single Sign On technology and anonymous service usage.

It is to be noted that the recommendation system may comprise more than one Recommender Service. In fact, the most likely and applicable case of the present invention will be that there are many Recommender Services existing that can be contacted by different Service Providers through a Recommendation Broker. In particular, a collocation of Service Providers and Recommender Services is possible. In this context it is to be noted that it is possible for a Service Provider (e.g. Amazon) to provide both the content services and recommendation services. Thus, the Recommender Service could have all content information that the Service Providers has and be used only by this Service Provider. Additionally, the Service Provider deploying the Recommender Service could have business agreements with other Service Providers to offer them explicit access to its Recommender Service.

A collocation of Recommendation Broker and the IdP is also possible. Under the assumption that the IdP is a trusted domain, this trust can be expanded to include the Recommendation Broker. In other words, the Recommendation Broker and the IdP could be one domain. In particular, the Recommendation Broker could be a special service of Identity Providers.

Fig. 2 depicts a sequence diagram which allows services to provide recommendations based on user pseudonyms - i.e. without knowing the user's identity - and without Recommendation Services being able to link their recommendation profile information to either different pseudonyms of the same user or the user's actual identity. Thus, neither Service Providers nor Recommender Services can in any way harm a user's privacy.

After authentication with the IdP (steps 1.0 and 1.1) and download of his pseudonyms (steps 1.2 and 1.3), the user accesses Service A. It accesses the Service Provider in an anonymous way, i.e. without revealing its identity, using the valid pseudonym pseudol (step 2.0). Service A₁ which wants to provide the user with a recommendation, could now send a request to the Recommender Service directly, asking for a recommendation for the user behind pseυdoi. However, this would imply, that either Service A or the Recommender Service would have to resolve the pseudonym pseudol to a unique identifier that can be linked to a recommendation profile which is the basis for the computation of a recommendation for the user. That would allow either Service A or the Recommender Service to associate pseudonyms of the same user and thus potentially harm the user's privacy.

According to the invention the message exchange between Service A and the Recommender Service is decoupled by adding a step of indirection in the form of a Recommendation Broker. The function of this entity is that of a back to back user agent, that receives requests for recommendations from the Service Provider, exchanges the user pseudonym in the request with a Recommendation Profile ID (RPID) and forwards the message to the Recommender Service.

However, adding this entity as a dedicated back to back user agent introduces a possible privacy risk since the Recommendation Broker potentially is able to read the messages from Service A to the Recommender Service and thus harm the user's privacy. For that reason, recommendation requests from Service A to the Recommender Service are encrypted using the public key of the Recommender Service by Service A. In the embodiment illustrated in Fig. 2 that public key is fetched from the Identity Provider, which keeps a registry of Recommender Service URIs and public keys. Alternatively, the key could also be fetched from the Recommender Service directly or any other key authority. To avoid man-in-the- middle attacks with fake public keys certificates could then be used that prove the validity of the key.

After receiving the user's request, Service A retrieves the public key of the Recommender Service it wants to ask for a recommendation from the IdP. For that it contacts the Recommendation Broker, sending the URI of the Recommender Service it wants to contact (step 2.1). The Recommendation Broker forwards that request to the IdP (step 2.2) which resolves the URI of the Recommender Service to its public key. The IdP then responds with that key (step 2.3) which is forwarded by the Recommendation Broker back to Service A (step 2.4). In the next step, Service A generates a secret encryption key (step 2.5) which it will send to the Recommender Service for that to encrypt any conversation intended for Service A.

Service A composes the recommendation request including the secret key it generated (step 2.6) and encrypts the request with the public key of the Recommender Service (step 2.7). It then contacts the Recommendation Broker passing the encrypted recommendation request, the URI of the Recommender Service that should serve this request and the pseudonym of the user, for which a recommendation should be computed (step 2.8).

The Recommendation Broker now requests a Recommendation Profile ID (RPID) from the IdP which is linked to the pseudonym (step 2.9). That ID is used to identify the recommendation profile the Recommender Service uses to compute a recommendation for the user.

The IdP looks up the RPID from the identity records of the user given by the pseudonym, encrypts it with the public key of the Recommender Service and pads the result with random bytes (step 2.11). Encryption and padding is to make sure that the Recommendation Broker is not capable of linking the pseudonyms of the same user by associating them to the same RPID. For every request to resolve a pseudonym to an RPID, the encrypted and padded RPID returned by the IdP looks like a totally random string to the Recommendation Broker.

Having received the encrypted and padded RPID (step 2.12), the Recommendation Broker sends the encrypted request for recommendation from Service A together with the RPID to the Recommender Service (step 2.13). The Recommender Service decrypts the request from Service A and the RPID from the Recommendation Broker (step 2.14). Then, it extracts the secret encryption key of Service A (step 2.15). Using the RPID, it can identify the user's recommendation profile, and computes the recommendation (step 2.16). It is to be noted that this computation is done without ever knowing the user nor any of his pseudonyms or service account information. The Recommender Service creates a response which contains the recommendation and encrypts it using the secret key of Service A (step 2.17), then it sends the encrypted response back to the Recommendation Broker (step 2.18). The Recommendation Broker sends the response back to Service A without being able to read any details of the (encrypted) recommendation (step 2.19). Finally, Service A decrypts the response containing the recommendation (step 2.20) and presents the user with the result (step 2.21).

To summarize, a new component, the Recommendation Broker, is introduced which is a functional entity that is decoupling the communication between content services and recommendation services. The described communication protocol enables content services to provide personalized recommendations to end users without allowing any of the parties involved in the recommendation process to harm end users' privacy. The decoupling is done by a back to back user agent, which takes care of exchanging identity-relevant user data (pseudonyms) with recommendation profile IDs without exposing any of that information to either the content service or recommendation service. Extensive usage of public key infrastructure encryption techniques furthermore makes sure that additionally it is impossible for the Recommendation Broker itself to deduce any information about the end-user that could be used to violate his privacy.

Consequently, the Recommender Service can provide personalized recommendations but is unable to relate service usage to user identities. No single component can relate the used pseudonyms used by the Service Provider to a user identity. Thus, it is possible to perform user specific recommendations in a world where no other component than the IDP knows about the actual identities of the user involved.

Fig. 3 depicts an alternative flow according to which the IdP does not have to be the authority that public encryption keys are requested from. In contrast to the IdP as a trusted domain functioning also as key authority that issues and provides the public keys for the Recommender Service, a separate, independent key authority that issues these keys and provides them to the requesting parties is used. A verification of keys can be done by certificate chains, as it is common for PKI encryption standards. Alternatively, a collocation of IdP and key authority.

In principle, the Recommender Service could also be the party that that provides its public keys for encryption to Recommendation Broker and IdP. To check the validity of the keys and to avoid man-in-the-middle-attacks, again, certificate chains can be used.

Instead of requesting the public key of the Recommender Service from the IdP, the Recommendation Broker requests it from a key authority (steps 2.2 and 2.3). The same holds for the IdP before it encrypts the RPID (steps 2.10 and 2.11). In other respects the communication is the same as described in connection with Fig. 2.

Many modifications and other embodiments of the invention set forth herein will come to mind the one skilled in the art to which the invention pertains having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

C l a i m s

1. Method for providing recommendations to users, wherein a user accesses a Service Provider under a pseudonym provided by an Identity Provider, wherein said Service Provider requests personalized recommendations for the user from a Recommender Service, and wherein said Service Provider, upon retrieval of said recommendations from said Recommender Service, provides said recommendations to the user, c h a r a c t e r i z e d i n that the message exchange between said Service Provider and said Recommender Service is decoupled by adding an indirection in form of an additional component serving as Recommendation Broker.

2. Method according to claim 1 , wherein said Identity Provider, said Service Provider, and said Recommendation Broker constitute a Circle of Trust.

3. Method according to claim 1 or 2, wherein said Service Provider sends a recommendation request message containing the request for recommendations to said Recommendation Broker.

4. Method according to claim 3, wherein said recommendation request message contains the user's pseudonym.

5. Method according to claim 3 or 4, wherein said recommendation request message contains the Recommender Service URI.

6. Method according to any of claims 3 to 5, wherein said Recommendation Broker exchanges the user's pseudonym contained in the recommendation request message with a Recommendation Profile Identifier (RPID) of the user.

7. Method according to any of claims 1 to 6, wherein the mapping of users' pseudonyms and users' RPIDs is performed by said Identity Provider.

8. Method according to claim 7, wherein said Recommendation Broker requests said RPID from said Identity Provider, wherein the user's pseudonym and the Recommender Service URI are specified within the respective request message.

9. Method according to claim 7 or 8, wherein said Identity Provider encrypts the RPID for the user using the public key of said Recommender Service and sends the thus encrypted RPID to said Recommendation Broker.

10. Method according to any of claims 3 to 9, wherein the recommendation request message sent from said Service Provider to said Recommendation Broker contains the request for recommendations in an encrypted form, the encryption being performed by said Service Provider.

11. Method according to any of claims 1 to 10, wherein said Service Provider composes the request for recommendations by including a secret key, wherein said secret key is derived from the public key of said Recommender Service.

12. Method according to any of claims 1 to 11 , wherein said Service Provider employs the public key of said Recommender Service for encrypting the request for recommendations.

13. Method according to any of claims 1 to 12, wherein said Service Provider, after the user accesses said Service Provider, demands the public key of said Recommender Service.

14. Method according to claim 13, wherein demanding the public key of said Recommender Service includes sending a message containing the Recommender Service URI from said Service Provider to said Recommendation Broker and forwarding said message from said Recommendation Broker to said Identity Provider.

15. Method according to claim 13, wherein demanding the public key of said Recommender Service includes sending a message containing the Recommender Service URI from said Service Provider to said Recommendation Broker and forwarding said message from said Recommendation Broker to a Key Authority.

16. Method according to any of claims 9 to 15, wherein said Recommendation Broker forwards a message containing the encrypted RPID of the user and the encrypted request for recommendations to said Recommender Service.

17. Method according to claim 16, wherein said Recommender Service, upon receipt of the message from said Recommendation Broker, performs the following steps: decrypting the request for recommendations, extracting the secret key included by the Service Provider, calculating the recommendations, encrypting the calculated recommendations using the secret key, and sending the encrypted recommendations back to said Recommendation Broker.

18. System for providing recommendations to users, in particular for performing a method according to any of claims 1 to 17, the system comprising at least one Service Provider that can be accessed by a user under a user's pseudonym provided by an Identity Provider, and at least one Recommender Service that upon request provides personalized recommendations for the user to said Service Provider, c h a r a c t e r i z e d i n that the system further comprises an indirection in form of an additional component serving as Recommendation Broker that decouples the message exchange between said Service Provider and said Recommender Service.

19. System according to claim 18, wherein said Identity Provider, said Service Provider, and said Recommendation Broker constitute a circle of trust.

20. System according to claim 18 or 19, wherein said Recommendation Broker is configured to receive recommendation request messages from said Service Provider.

21. System according to any of claims 18 to 20, wherein said Recommendation Broker is configured, upon receipt of a recommendation request message containing a user's pseudonym and a Recommender Service URI, to request a corresponding RPID for that user and for that Recommender Service from said Identity Provider.

22. System according to claim 21 , wherein said Recommendation Broker is configured, upon receipt of the RPID from said Identity Provider, to send a message to said Recommender Service containing the RPID and the encrypted request for recommendations.

23. System according to any of claims 18 to 22, wherein of said Recommendation Broker and said Identity Provider are collocated in such a way that the Recommendation Broker and the Identity Provider are one domain.