A decentralized privacy-enabling TV personalization framework Olivier Potonniée Gemplus Research Labs 13705 La Ciotat Cédex FRANCE
[email protected]
Abstract While there has been many studies on personalization frameworks for iTV, few have raised the issue of personal information ubiquity and privacy. Our purpose is to address both of them, thanks to the use of a smart card based personal profile engine. We additionally propose an innovative solution to mix content based and collaborative filtering using a decentralized architecture. We illustrate the usage of our framework with an experimental movie recommender application, and give metrics that show the quality of the obtained recommendations.
Keywords Recommender systems, Personalization, Collaborative filtering, Personal profile, Smart cards
Introduction The last decade has seen the emergence of many propositions to personalize TV experience. These studies were motivated by the advent of digital television, where channels and programs proliferate. To help users to get what they like inside this hardly bounded information flow, personalization systems have provided means to customize Electronic Program Guides (EPG) and other applications to each user. This is achieved by building so-called personal profiles, which store information about the user, ranging from demographics to interests or habits. Early personalized TV applications were available on the Internet, due to the limitations of Set Top Box (STB) execution environment [Smyth & Cotter, 2000]. But new STBs’ capacities made possible the move of personal profiles and personalization framework to the TV infrastructure [Buczak et al., 2002]. However, most of these systems fail to address two important issues about the profile: ubiquity and privacy enforcement. − A ubiquitous profile is one that you carry with you everywhere, so that it can be enriched and used in any digital interaction you’re involved in. This ubiquity makes the personalization both more useful and more accurate. − Privacy is a major user concern. As people realize the amount of information that is
collected and used about them, they get suspicious about service providers and intermediaries. Users want to be sure the personal information collected by personalization systems is not used for anything else that personalizing services they requested to. They are hence reluctant to delegate the storage and processing of their personal profile. We propose the use of smart cards to store and control access to the profile. We will first introduce the benefit of such a device. Then we will present our framework, the way we implemented it, and metrics from our experimentation.
Smart card benefits Similar in size to plastic payment cards, smart cards have an embedded microprocessor to store and process sensitive data. In order to answer ubiquity and privacy requirements, we propose to host a Personal Profile Engine in a smart card. This provides several benefits: − The profile is available in multiple devices and contexts. The device only needs a low cost smart card reader to access the profile. No network connection is required. This ubiquity allows personalizing applications, as well as enriching the profile, during off-line sessions. It makes it possible, for instance, to personalize your TV’s EPG according to the DVDs you rented in your usual movie store, or news you usually access on a PC.
− Compared to network based solutions where the profile is stored on a remote server, the smart card avoids access failures and delays. Remote communication is always subject to failures (disconnection, unavailability, etc.) and delays (at connection time, or during network congestion). These situations cannot occur with a smart card. It furthermore avoids the cost of the remote communication which is usually charged to the user. − The user directly controls his profile availability: he has the choice to present it or not, and even to destroy it anytime. − Profiles protection is enhanced. The smart card’s tamper resistance (physical and logical) ensures its security, so that proper software can efficiently guarantee the fulfillment of user decided access policy. See further for more details about privacy issues.
Personalization techniques Content personalization is an increasingly important need in the TV domain [Stroud, 2001]. By content we mean any program that can be viewed, heard or used on TV (movies, shows, music, interactive program, etc.). Our framework implements a personalization service based on both individual and collaborative filtering. Filtering consists in processing differently content elements (e.g. highlight, or hide), that we call items, according to a predicted interest of the user regarding this item. Predicting interest is realized by computing a score for each item based on a history of collected interests that we call votes. A vote is a note assigned by a user to an item. Our framework does not handle the capture of the votes, it has to be done at the application level. It is hence transparent for our framework whether votes have been collected explicitly, by asking the user to give a note to an item, or implicitly, by inferring a note from a user behavior. We use two personalization techniques: CBF and CF.
Content-based filtering (CBF) CBF [Maes, 1994] realizes an individual filtering, as it only uses the target person’s profile (i.e. his votes history) to compute a score. CBF imposes to have metadata associated to items. Metadata describe item’s content. It can contain, for instance, the genre, cast, year of release, country of production of a movie, or the category of a news flash. CBF considers the user’s votes history to compute his personal profile. The profile summarizes votes for each metadata element the user has voted for. For
instance, the profile will contain an interest level for the metadata element “western” based on votes for items containing this metadata value. Computing a score for an item consists then in computing the mean of the profile’s interest levels regarding each item’s metadata element.
Collaborative filtering (CF) Whereas CBF uses only one profile to compute a score, CF [Breese et al., 1998] uses multiple profiles, which reflects the usage of different users. The idea is to infer missing information in one profile based on other profiles that have been detected to be similar. CF does not need item metadata: it only compares the sets of votes of different users, without knowing anything about the item content. For instance, CF will recommend a specific western to John if other users who liked many movies in common with John have appreciated that western. Unlike CBF, CF will recommend a western although John didn’t ever watch a western.
Mixed approach Both CBF and CF have weaknesses and strengths [Smyth & Cotter, 2000]. CBF suffer from what we call the blinkers defect: they only recommend items similar to previously liked ones, hence discouraging novelty. Furthermore, CBF gives recommendations of lower quality than CF does. On the other hand, CF will not recommend new items before users have expressed their opinion on them, which is not encouraged as these items are not recommended (this is usually called the latency problem). CF is also inappropriate for so called gray sheep users, who have unusual preferences. And last, CF suffers from a sparsity problem: when the number of item grows, there may not be sufficient feedback for each of them to permit any profile comparison Our framework allows to mix CBF and CF, which has proved to give better results than each of them individually [Claypool et al., 1999]. However, the solutions proposed so far (such as [Good et al., 1999], [Pazzani, 1999] or [Dai & Cohen, 2003]) are based on a single centralized server, where all profiles are accessible simultaneously. Our solution, based on decentralized personal profiles, brings additional flexibility, as explained below.
Framework overview Figure 1 presents our framework’s overall architecture. The operator’s broadcast service and modeling service may or not be collocated on the same server. The operator communicates to set top boxes via broadcasting, and the set
top box sends data to the modeling service using the so-called return path, possibly asynchronously. The smart card is plugged into the set top box, and the STB personalization service communicates with the profile engine using synchronous procedure calls.
Operator Broadcast Service
Appli
Perso. Server Modeling Service
Perso Service
STB
Profile Data
Profile Engine
Smart card
Figure 1 - Overall framework architecture
Personal Profile As previously mentioned, our content based filtering mechanism is based on a personal profile hosted on a smart card. The following figure describes the tree structure of our profile. It is of course formatted in a compact binary form inside the card. profile identity name email address ... demographics birth date gender occupation ... preferences topics interest levels ... recent recurrent program names ... unique program names ...
Figure 2 - Personal Profile structure This profile contains four sections: − Identity values are for applicative dialogs. They permit application to establish a personalized dialog with the user.
− Demographics are for CF recommendations. They are used to compute similarity between profiles. − Preferences contain interest levels for all possible metadata. The set of possible metadata element has thus to be defined a priori. Interest levels are a set of three statistical values: count is the number of votes for a topic (with a ceiling value), mean is the mean (between 1 and 5) of all votes involving this metadata element, and diff if the mean absolute difference from mean. Preferences are used for both CBF and CF recommendations. − Recent values are the names of recent programs watched (or used) by the user. These values are split into two categories: recurrent for periodic programs, and unique for programs that are supposed to be watched only once. A recently seen unique program should not be recommended anymore, while a recently seen periodic program should be recommended (it can be considered as being usually seen). Our prototype uses fixed-size recent lists of ten elements, with fifo policy. The profile can be initialized by asking the user to fill a form. This will provide identity, demographics, and a few interest levels to start with. Although it is not implemented in our framework yet, interests levels initialization could be enhanced thanks to stereotypes [Ardissono et al., 1999][Kurapati & Gutta, 2002]. The profile is dynamically updated by a profile engine within the smart card. This engine takes as input new votes (explicit or implicit) collected by the applications. It updates statistical values of preference topics corresponding to the voted item, and adds the item name to the appropriate recent list. Content Based scoring consists in submitting to the card two parameters: the item name and its metadata. The profile engine, within the smart card, retrieves the profile interest level of each item metadata element, and computes a weighted mean of them. The metadata associated to an item is the list M = { i1, i2, ... in } of metadata elements to which the item belongs. Considering mi, ci, di the statistical values (resp. the mean, count and mean absolute difference from mean) of a personal profile which are associated with the metadata i, the embedded profile engine computes a weight for each considered metadata element i using the
following formula:
Age > 50
c wi = i di Given N the subset of M for which ci > 0, the score S returned by the profile engine is then:
S=
1 .∑ wi .mi C i∈N
yes
no Age < 20
gender = M
yes
no
yes
2
3
3
Where C is the sum of all wi values. If the item name is listed in one of the two recent lists the engine reduces or raises the computed mean (depending whether it is in the recurrent or unique list). The item score is the resulting value, which is returned by the engine. It is worth noticing that the profile content has never to be extracted from the smart card during CBF operations: scoring and dynamic profile updates are computed within the card. It is hence impossible to copy a profile. This property guaranties users’ privacy.
Collaborative personalization There are many collaborative techniques, which can be grouped in two families [Breese et al., 1998]: − Memory-based techniques compute a score in a single operation, by processing the whole set of votes from all users. − Model-based techniques split the filtering process. A first step, called learning phase, computes a model for each item based on votes from all users. The second step, called matching phase, evaluates the model with the user profile. Memory based techniques are not appropriate for our decentralized iTV environment: we want to compute the score on the user side, where the only profile available is that of the current user. We therefore adopted the modelbased approach, where models are computed on a centralized server, broadcast to all STB, and matched within the smart card with the local user profile. Collaborative models are generally represented using rules or decision trees. Rules are a list of expressions such as “if user has such property, then raise the score by 0.2”. Decision trees are trees where non-terminal nodes hold a conditional expressions, and leaves hold a value. Each non-terminal node has two children, one if the condition is true, the other if it is false.
no occup = doctor
yes
no
4
3
Figure 3 - Sample decision tree We decided to use decision tree models, because they are widely used and recognized as both efficient and easy to analyze. In our case, the node expressions are conditions on user profiles, and a leaf value is the predicted score for users whose profile match all parent nodes conditions. Figure 3 illustrates such a tree. Our models are computed thanks to collected user votes. These votes are captured on the STB, and sent back to the modeling server. Digital TV networks often have no permanent return path from STBs to remote servers. However, the collected votes do not have to be sent synchronously: they can be buffered on the STB, and sent from time to time when a connection is available. The collected votes are anonymous: they only contain the item identifier, the user attributed note, and a user profile snapshot. The snapshot is a selected subset of the user profile, which contains his demographics (age, gender and occupation...), and his main preferences (those which have the higher interest levels). The recipient cannot detect (and does not need to know) that two snapshots relate to the same user. The figure below presents a sample collected vote content. Item: Toy Story Note : 4 User demographics: age: 35 gender: M occupation: Doctor Main preferences: Western Horror Drama
Figure 4 - Sample collected vote The anonymity of this information respects privacy concern. However, unlike what we claimed for CBF, part of the user profile is exposed outside the smart card. But the disclosure is limited, as it is only a subset of the profile. If further confidentiality is required, snapshots can be encrypted to avoid disclosure during their transmission to the modeling
server. The encryption can be performed in the smart card itself. Being encrypted ensures that no undesired application, especially on the STB, can see the content of the snapshot. There are many algorithms to build decision trees, and we have tested several of them, and adopted an implementation of CART [Breinman et al., 1984], which is both simple and efficient: it computes in a short time a model which reveals to be of good quality (see further for metrics). Our goal was not to invent new modeling algorithms, we hence did not investigate very deeply the possibility of getting higher quality models. Model (re)computing can be triggered by different event kinds: manually by an operator, at a specific frequency, when there is a given number of new votes, or each time the model is requested. When an item is to be proposed to users, its model is serialized and broadcast to all users’ STB. The STB transmits it to the smart card’s profile engine, which matches it with the user profile. This process returns the predicted score contained in the leaf corresponding to the user. Here again the profile does not need to be disclosed to the STB, it is matched with the model within the smart card.
Assembly Although each one can be used independently, our framework proposes to combine CBF and CF results. The scoring process for an item is then the following (see illustration on Figure 5): − The operator broadcasts the same item metadata (including item name) and model to all STBs. − The receiver application on the STB forwards it to the personalization service, which reformats and transmits those two sets of data to the smart card. − The smart card computes the content-based and collaborative scores separately. It returns a combined score which is the mean of both values. In some situations one the two scores cannot be computed: this happens for instance when the decision tree is empty, or when the profile does not contain any statistics about the metadata elements associated to an item. In such cases, only the available score is returned. STB Personalization Framework
STB application score()
metadata + model
score
Smart Card Profile Engine
metadata + model score
Figure 5 - Scoring process
The personalization framework sends user votes to both personal and collaborative modeling services (see Figure 6): − The note and item metadata are sent to the smart card profile engine, which updates the personal profile accordingly. − The smart card provides a profile snapshot of the user (this can be done in reply to the previous step) − The snapshot is sent together with the vote to the modeling server.
Collaborative Modeling Server
STB application vote()
STB Personalization Framework
note + metadata + item id
note + snapshot + item id
Smart Card Profile Engine
metadata + note
snapshot
Figure 6 - Vote processing
Personalized alternatives selection The smart card decision tree matching is also available as a standalone function, independent of the scoring mechanism. Indeed, collaborative models can be used to take personalized decisions of many kinds. In this case, the leaves do not contain a score but a decision id, transparent to the personalization framework, that applications can use to select between alternative behaviors or data. For instance, it allows to automatically select a skin for an application based on user demographics or preferences. We call this function personalized alternative selection.
Experimentation We experimented our framework with a movie recommendation application, using the MovieLens dataset [Grouplens]. This dataset contains 100,000 votes from 943 users regarding 1682 movies. Each user voted at least for 20 movies. A vote is an integer note between 1 (poor) and 5 (excellent). For each movie the database identifies the genres to which it belongs. This is the only content metadata we used. Our application consists in presenting a fixed list of 20 movies to all users (it can for instance be the list of movies available in one day). It also has a list of 5 advertisements, among which only one can be presented, in a dedicated banner. In normal (impersonal) mode, the application displays the movies in a random order, and the banner displays a randomly
1.38
Random CBF 0.79
0.78
CF
0.74 48.2%
MAE
64.3%
66.0%
69.9%
CBF+CF
ROC4
Figure 7 - Recommendation quality metrics
selected advertisement. When the user plugs his personal smart card in the STB, the system automatically switches to a personalized mode, where each movie is scored and the list is ordered with higher scores presented first. And the personalized alternative selection is used to select the advertisement to display in the banner. For the latter, a single decision tree is provided which defines the population targeted by each of the 5 advertisements.
random is our reference, it randomly gives a score between 1 and 5. Any personalization algorithm must at least be better than random. Our CBF and CF services presented above have been tested independently, and using the mixed approach we promote.
Recommendation quality
Fortunately, our CBF and CF services perform significantly better than the random algorithm, with much lower error and a reasonable pertinence (far more than 50%). And the combination of both (CBF+CF) enhances further the recommendation quality, demonstrating the pertinence of our approach.
We measured the quality of the resulting recommendations using a classical approach: we trained our system with 80% of the votes, and challenged it with the remaining 20%. We compared the computed score P (rounded to its closer integer value) with the actual note N given by the user. We used the following metrics: − The Mean Absolute Error (MAE) gives an indication of the accuracy of the prediction. If we consider the set V of test votes, and C its size, we have:
MAE =
1 .∑ Pv − N v C v∈V
− The Receiver Operating Characteristic (ROC) is a pertinence indicator [Herlocker et al., 1999]. Considering a threshold n above which notes can be considered good (we use n=4), ROCn measures the probability that a user receives a pertinent recommendation. That is the predicted score P and the actual note N are both higher or lower than n. We call U (for useful) the number of votes for which this property is verified. We compute our pertinence indicator using:
ROC 4 =
U C
Figure 7 presents the results we obtained. We challenged four recommendation algorithms:
The random algorithm gives a ROC4 pertinence close to 50%, which verifies the randomness property. It also gives a high MAE, showing poor accuracy.
As stated previously, our goal was not do develop a new algorithm, and we therefore do not put too much emphasize on the metrics values. We used well-known algorithms, and tried to adapt them to our original architecture. However, we felt necessary to demonstrate than our approach does not reduce personalization quality. Indeed, it gives results similar to other approaches with the same dataset [Herlocker et al., 1999][Sarwar et al., 2001]. This shows that the architecture we propose can lead to high quality personalization.
Smart card implementation Hosting the personal profile and the profile engine requires both storage and processing capabilities. Smart Cards implementing the Java CardTM standard meet such requirements. These cards have a small Java Virtual Machine able to execute multiple Java applications respecting Java Card restrictions [JavaCard]. We used the GemXpresso Pro R3, a Gemplus Java Card with 64 KB of EEPROM. In smart cards, applications are stored and executed in EEPROM. Our application occupies less than 5 KB, and the profile data has a similar size. We
have not tried to optimize the memory footprint, we can hence suspect that it can be reduced. Computing a full score for a movie using its metadata, model and name takes around 600 ms. This processing can be decomposed in elementary operations. 17%
41%
Other Recent (overhead) Names Search Content Based Scoring
17%
Decision Tree Matching
25%
Figure 8 - Distribution of the processing time for a score operation Figure 8 shows the mean distribution for 20,000 different scores. The “other” area is the overhead including the 9600 bps communication between the card and the offcard software. The average number of nodes per decision tree is 3.33, and the average number of metadata elements per movie is 1.72. The content based scoring time suggests that the mathematical operations used in the metadata computation could be optimized. Note that each of these sub-tasks (except the overhead!) is optional. It is thus possible to get faster recommendations if at least one of them is not used.
Privacy Enabling We mentioned our framework enhances privacy safety. It is worth explained why and how. Personalization systems require storage and processing of personal data. This raises a legitimate concern about the potential misuse of this data. Personalization providers usually address this concern by claiming privacy policies [Schafer et al., 2000]. However this approach has a major defect: it is exclusively based on trust. Users have no mean to check that the claimed policy is not violated. Once made available to the remote personalization system, it is impossible to make sure that the information is not duplicated and transmitted to a third party. Using the smart card to store personal data avoids delegating the storage (and processing) of this confidential information. This makes it possible to avoid disclosure of personal information to remote parties. However, using a smart card does not enforce privacy on its own: it still needs proper usage to ensure that the information it contains
is not copied out from the card. And this usage still needs to be expressed in a policy. But the important aspect of it is that the user holds the card. He hence has the possibility to check what information it discloses. This verification, of course, requires technical expertise, as it involves listening to communications between the card and the client software. But it can be done by independent parties, in a way similar to today’s spyware detection software. The smart card hence enables privacy policy checking. The above paragraph assumes that no confidential information is disclosed by the smart card, which is not absolutely true: a score can disclose a good hint about the profile content. For instance, a score request based on a single metadata element (e.g. “western” movie genre) gives information about a user preference. However this is not an exact copy of the profile content, as the latter contains statistical values, whereas the score is a single numerical value. Secondly the profile engine can impose a minimum set of input information to request a score (e.g. at least three metadata elements, and a decision tree of at least three hierarchical levels). The more input information is provided, the more difficult it is to recompose a degraded profile copy (again an exact copy is impossible). Last, aggressive personalization clients could be detected by recording each session requests history, and looking in it for known aggressive patterns. These techniques have no yet been experimented. Whatever information is disclosed, an important feature of the smart card is that it avoids identifying the user. In traditional personalization systems the user has to be identified in order to retrieve his profile between sessions. Thanks to the smart card, the personalization system doesn’t care about the user identity, as the profile is unambiguously provided. This makes smart card based personalization anonymous: personal information is presented without the ability to know who it relates to, except by physically looking at who is holding the card. If a card is unplugged and reinserted, there is no mean to know whether it belongs to the same person or not. We mentioned previously the possibility to include identity related information in the profile, such as name and e-mail addresses. When the profile contains such identifying information, it should include an identity protection mechanism. One solution we prototyped is the Chinese Wall policy [Brewer & Nash, 1989]: within one session, it is impossible to access both nominative and confidential information. The access to one
information category access the other one.
automatically
forbids
Conclusion The personalization framework we presented in this document addresses needs of growing importance: privacy and mobility. Privacy and mobility are provided by the smart card, which holds not only the personal profile data, but also the profile engine. The collocation of both of them in the secured smart card environment avoids the need to disclose the profile content to the terminal, hence preventing undesirable usage of this data. We explained why the smart card can be considered as a privacy enabler, providing the basic security features on which proper privacy enforcement mechanisms can be built. Some of them have been prototyped, some remain to be studied. Mobility is an obvious smart card feature. It permits not only to move the profile from one STB to another, but also to switch between different terminal kinds. This allows different application providers from different domains to share a common smart card based profile. For instance, if one could use his profile in a DVD renting machine, the latter would automatically propose him the movies that would best match his tastes. And the machine would enrich the profile based on his actual choice. Then the same profile, with the collected information, could be used in an STB to personalize an EPG. This is an important benefit for the user. Our framework furthermore provides separation of concerns, by isolating core personalization services in a consistent framework. This allows application to focus on their core business, and promotes reuse of both mechanisms and personalization knowledge. Although our limited experimentation (with a single application) could not measure the benefit of sharing the profile between multiple applications, it should raise the quality of the personalization significantly. We have shown that our innovative choices can be implemented in a efficient way, providing high quality recommendations. In order to increase our framework usability, it can be envisioned to embed the personal profile into a mobile communicating device, which would provide a wireless communication link to the profile. This communication could be available on the smart card itself, or on the device it is inserted in. This would facilitate the integration of our framework in environments where a physical smart card reader is not available. It would also make it possible to build
a multi-profile personalization service, where personalization dynamically takes into account the arrival and departure of personal profiles. This feature would be useful in many contexts, such as Family TV watching, musical ambience in public places, or advertisement selections in subways. This perspective opens the way to an interesting follow up for our study.
Acknowledgment This work has been conducted within the COMPiTV project [COMPiTV], which was sponsored by the French research program RNRT [RNRT].
References Ardissono, L., Console, L., Torre, I. Exploiting user models for personalizing news presentations, in Proceedings on Adaptive Systems and User Modeling on the WWW, 1999. Breese, J.S., Heckerman D., and Kadie, C. Empirical Analysis of Predictive Algorithm for Collaborative Filtering. Microsoft Technical Report MSR-TR-98-12, October 1998. Breiman, L., Friedman, J.H., Olshen, R.A., Stone, C.J. Classification and Regression Trees. Chapman & Hall, New York, 1984. Brewer, D., Nash, M.J. The Chinese wall security policy, in 1989 IEEE Symposium on Security and Privacy. IEEE Computer Society, pp. 206-214, May 1989 Buczak, A.L., Zimmerman, J., Kurapati, K. Personalization: Improving Ease-of-Use, Trust and Accuracy of a TV Show Recommender, in Proceedings of the AH’2002 Workshop on Personalization in Future TV, 2002. Claypool, M., Gokhale, A., Miranda, T., Murnikov, P., Netes D., and Sartin, M. Combining Content-Based and Collaborative Filters in an Online Newspaper, in Proceedings of ACM SIGIR Workshop on Recommender Systems, August 1999. COMPiTV, a component based framework for interactive TV services: http://www.gemplus.com/compitv Dai, W. Cohen, R. Dynamic Personalized TV Recommendation System, in Proceedings of 3rd Workshop on Personalization in Future TV, 2003. Good, N, Schafer, J.B., Konstan, J.A., Borchers, A., Sarwar, B., Herlocker J., Riedl, J. Combining Collaborative filtering with personal agents for better recommendations, in Proceedings of the Sixteenth Na-tional Conference on Artificial Intelligence, 1999.
GroupLens Research Project,100K MovieLens dataset: http://www.cs.umn.edu/Research/GroupLens /data/ Herlocker, J.L., Konstan, J.A., Borchers, A., Riedl, J. An algorithmic framework for performing collaborative filtering, in Proceedings of the 22nd annual international ACM SIGIR conference on Research and development in information retrieval, 1999. Java Card specifications and products: http://java.sun.com/products/javacard/
Filtering. Artificial Intelligence Review, pp. 393408. Dec. 1999. RNRT, Réseau National de Recherche en Télécommunications (National Network for Telecommunication Research): http://www.telecom.gouv.fr/rnrt Sarwar, B. M., Karypis, G., Konstan, J. A., Riedl, J. Item-based collaborative filtering recommendation algorithms, in Proc. of the 10th International World Wide Web Conference (WWW10), Hong Kong, May 2001
Kurapati, K., Gutta, S. TV Personalization through Stereotypes, Workshop on Personalization in Future TV, 2002.
Schafer, J.B., Konstan, J., and Riedl, J. Electronic Commerce Recommender Applications. Journal of Data Mining and Knowledge Discovery, vol. 5 nos. 1/2, pp. 115-152, 2000
Maes, P. Agents that Reduce Work and Information Overload, in Communications of the ACM, Vol. 37, No.7, July 1994.
Smyth, B., Cotter, P. A Personalized Television Listing Service, in Communications of the ACM, Vol.43, No.8. August 2000.
Pazzani, M. A Framework for Collaborative Filtering, Content-Based and Demographic
Stroud J. TV Personalization: a key component of interactive TV, a Carmel Group white paper, 2001.
