Scrutable Mobile Client-side Personalization

Published Online April 2015 in MECS

In this modern era of computing, mobile devices are used as a personal computing platform to store and share information. A user may have a variety of mobile services on a single device and can share his/her personal information to the service providers for mobile services personalization. Mobile personalized services are highly sensitive to the context and the requirements of the user. The context and the user model are the corner stones of mobile services personalization. Not every mobile service may require the same level of personalization. Different levels of personalization are needed in mobile services depending on types of service and user’s requirements [1]. Contextual personalization is the most complex level of personalization which requires both user context and user model. According to [2], the effectiveness of the mobile services depends on their ability to offer relevant context sensitive information while shielding the user from information overload. Depending on the current requirements of personalization of mobile services, we have defined it as “Personalization is a controlled process of adaptation of a service to achieve a particular goal by utilizing the user model and the context of use” [1].

There are two key issues regarding the personalization of mobile services; the business competition and the privacy of users. This can be a reason for the service providers to not to share the user model [3]. Privacy is an integrated part of personalization. Every person may have different priorities for privacy. Some people may not want to share much information as they don’t have trust or they are more curious about their personal information. Some people may want to share more personal information to gain more personalized experience.

This problem can be solved if a user keeps his/her user model and share according to his/her own requirements. The focus of this work is an attempt to build architecture to fulfill the following purposes:

• •    Scrutable client-side personalization with dynamic privacy control.

• •    Re-usability of the parts of the user model across different mobile services. This can help to reduce the “cold start” problem as existing user information can be re-used by the newly subscribed mobile service.

Scrutability describes the ability of users to understand and control what goes into their user model, what information from their model is available to different services, and how the model is managed and maintained [4]. Scrutability is a key to enabling reuse and sharing of user model[5]. There is a variety of methods to collect information about users (implicit or explicit). The collected information is used to create user models for personalization. The approach in this research is bit different in that a user should build his/her model and share according to the requirements. We think that a user should build his/her model instead of giving raw information to the systems to build a model for the user. A user can share his/her model with different services and his/her requirements of personalization. The users will remain in complete control of his/her model by applying constraints of his/her choices. The approach can have two significant benefits. First, the model will be more accurate and current that is a key to the personalization. Second, the model can be scrutinized by the user and can update as his/her interest or requirements changes. It is annoying and inconvenient to repeat the personalization process for the mobile users [6] and repetition can be reduced from the reusability of the user model.

Privacy is a big challenge for personalization. It is very difficult to achieve a balance between privacy and personalized user experience. A study [4] has discussed various approaches to reduce the privacy risks in personalization. The authors consider the client-side personalization and user control as separate approaches. In this work, we have combined both client-side personalization and user control as a single approach to provide privacy enhanced scrutable personalization.

We are following the same philosophy as [7] that a user is an owner of their user model. The user should have access to their user model and the processes that created it. The transparent personalization process is a key in this regard. In a study [8], authors suggested that users should know when personalization is happening and how they are perceived by the system. In this paper, we advocate a solution to share scrutable partial user model we called it persona here for client-side personalization while keeping the user’s privacy.

This paper is structured as follows: Section 2 gives an overview of personalization approaches and related work. Section 2 also describes the possible issues and advantages of the approaches as well. The user model is a key in personalization and is discussed in section 3. User control and privacy are the key issues in personalization and to address these we have proposed architecture in section 4. The main focus of the architecture is to share scrutable persona (a partial user model) to a service provider while keeping the user’s privacy. Section 4 describes major components of the architecture. Section 5 describes basic work flow of the overall approach. The proposed approach has some challenges and in section 6 we have discussed these challenges in brief. Section 7 describes some conclusions and further work.

• II.    Overview of Personalization Approaches and Related Work

There is a variety of approaches depending on how the user model is built and exploited to provide mobile services personalization. This section describes an overview of the approaches with a brief comparison. The approaches are discussed in detail in [9, 10].

The increasing capability of mobile devices is making it possible to create system architecture that can share personal context to other mobile devices. It is also evident that mobile devices are equipped with various sensors such as GPS, accelerometer, Bluetooth, microphone, camera, calendar, contact list that can capture personal context[11]. Use of mobile device in context sharing with other mobile devices or service providers is gaining importance in the research community of context-aware computing. The most common architecture for personal context sharing using mobile devices is the centralized server architecture [11].

The most important issue in personalization is to create accurate and comprehensive user model. The process of personalization starts from collecting information about a user, creating user model and adapting the services according to the available context and user model. The process of collecting user information can be implicit or explicit. In implicit method, systems can observe and record user behavior; afterwards system can analyzes it to create a user model. This method involved different machine learning techniques to build a personal model. This method requires trust of users on service providers by giving enhanced privacy protection. In explicit method, user is given questionnaires to give personal opinions. However, personalization is not a static process rather it is dynamic and iterative process [12].

Research on personalization has focused primarily on automated discovery of user profile and preference data

• [ 13]. In this way, users can easily lose control on how and to what extent the information is shared with service providers. A clear separation of concerns between the client and the server can help to understand better opportunities in personalization. mPersona [6] is a system which provides personalized services using a portal technique. In such approaches, users may lose control over how much of their data is shared and with whom. In another study [14], authors proposed ad delivery framework where personalization is done by both server and mobile device. In this framework, authors suggested that it is vital to use context information extracted from user’s interactions and mobile device’s sensors to deliver more targeted and personalized ads.

Fig. 1 and 2 give an overview of the concerns and activities in both client and server-side personalization. In client-side personalization approach, mobile devices are considered as a user modeling platform. User control is valuable in a client-side personalization approach. Scrutability provides the basis for user control over personalization [15]. In a study of privacy enhanced profiling [16], the authors described how to put the user in control of their personal information. They described the user control as:

• •    Make user profile data sharable and available to other applications.

• •    Access to the profile information should governed by the user’s controlled privacy policy.

• •    The data model of the profile should be extendable and open.

Personalized ad services are another area where privacy is a major concern and a study [14] has described an approach to deliver privacy-aware personalized ads on mobile devices.

User data can be stored and managed locally. Since the data is collected and processed at the user’s device rather than the server side, user may perceive more control over their data and perceive less privacy risks [4]. The required data for personalization can be selectively provided to different service providers through a scrutable process. PersonisJ [17] has significant contribution in client-side user modeling. This way of storing and managing the user data at the source also avoids consistency problems of the user model [18]. An interesting case study [19] advocates client-side personalization which delivers personalized insurance rates. In some other studies [20, 21], authors argued that client-side personalization can reduce privacy problems and user may inclined to disclose more information if personalization is done locally.

The user is willing to share personal information in order to get a better user experience, but s/he wants to remain in control of what information is used, by whom and for what purpose [13]. It is obvious that a user may not want to share all his/her personal information to a service provider at a certain time. On the other side, authors[22] are also suggesting that users should be able to tailor their contents and can have the sense of control. However, the authors are considering personalization as a system driven and customization as a user driven approach. According to [4, 20] this approach has some challenges: First, existing personalization algorithm needs to redesign to fit the client-side model; second, there is a need to protect confidential business rules or methods. Therefore, trusted computing platform have to develop to achieve the purpose. This research work fits in this context as well.

Main Activities

• •    Receive Contents

  

  Main Activities

  • build user model • learn user behavior

  • manage privacy

  Personalized contents

  Service Provider

  User

  
  

Possible Issues

• •    Less accurate user model

• •    Privacy concerns

• •    No user control

• •    Less accurate behavioral model

• •    Less transparent personalization process

Fig. 1. Server-side personalization

Main Activities

• •    Build user model

• •    Define Rules for behavioral model

• •    Dynamic Privacy

• •    Scrutability

  

  Main Activities

  Understand user persona

  Understand user behavior

  Deliever accurate

  contents

  Possible improvements

  • More accurate and dynamic user model

  • Less privacy concerns

  • More user control and involvement

  • Accurate behavioral model

  • Transparent personalization process

  • Effective personalization with dynamic privacy control

  
  

Fig 2. Client-side personalization: selected approach

In our approach, we have proposed an architecture (in section 4) that can accommodate both adaptive and adaptable approach to achieve effective client-side personalization. We are giving users control over their personal data by providing scrutability and dynamic privacy control which is an adaptable part of the architecture. However, users will receive personalized contents and recommendations depending on the user model they shared and that reflect the adaptive behavior of the system.

• III.    Personas and Stereotypes- A Brief Review

The existence of a user model is a key to personalization. The compilation of a user model and using that model effectively is crucial for personalization. A user model may consist of a fixed part, containing a set of domain-independent user’s attributes, and a configurable part, containing the user’s preferences for domain-dependent product properties. Dynamic user profiling is an essential part of personalization due to the heterogeneous needs. Therefore, there is a need to consider the user profile in terms of the user’s primary goal and needs. The data that can be used for constructing user profile can be distinguished as data model, classified as demographic and transactional data and profile model, classified as factual data and behavioral data [23].

A complete user model may not be required to personalize a mobile service at a certain time. Further, it is suggested that elements defined within a user profile that suits to a specific situation, but relate to many different services should only need to be defined once [24]. However, a part of a user model can serve the purpose. Similarly, some services may not need all contextual elements to personalize a mobile service. Thus, we require a partial user model and the related context to personalize a mobile service which we call persona per service . User’s interests, needs and context are dynamic. Therefore, it may require constructing a persona dynamically or reusing an existing persona with slight modifications whenever required. In this research, we consider persona as a dynamic entity which contains required elements of a user model and the user’s context to personalize a mobile service. Similarly, a study [25] also suggests that same persona should not be used in distinct services. It also states that personas are useful to convey information about users’ context, goals, background and expected behavior.

Reusability of user models across different services is also of high importance. According to [7], if users model are to be reusable, they are no longer the property of one service or program. The only thing is to find out which elements of the user model are required or relevant to a service in the current user’s goal and context. Different users may have different goals at a time or; the same user may have different goals at different times. It can be useful to consider the user’s goal as a part of a persona at the time of sharing with the service provider. Fig. 3 gives an overview of the persona-information. A user can have subscribed services and have some goals. The goals can be a long term or can be changed anytime. The context part represents contextual elements required by a service and a user is willing to reveal. It is very important to understand which contextual attributes are required for a particular service. Sometimes, different services may require different type of contextual elements. For example, looking for nearby shopping center, location is the crucial context but when a user is in the shopping center it is not further required for that shopping session. Creating and maintaining user profile is critical for personalization. Full profile may not require in personalizing a particular service, a part of user profile may be sufficient. In a way, it is not required to utilize full context and profile to personalize a mobile service. It may require investigating further which contextual elements and which part of the profile is required to personalize a mobile service. However, the focus of personalization should be to improve the user experience while protecting privacy. The partial user model represents only those elements which are relevant to the service. In addition, the rules can represent the behavior and privacy preferences of a user for service personalization.

Fig 3. Overview of a user’s model

Persona is a combination of personal user model and user context to personalize a mobile service. It can contain the user’s information (user model), the context and behavioral model (history, recommendations) required by a particular service. Every service may require different user information and context to personalize. Therefore, the persona per service can be an ideal choice for designing personalized mobile services. There can be one persona per service or one persona against multiple services. User can have full control over his/her persona which is stored on their personal device. One can make any element of their persona private or public. For example, a user may want to utilize a service, but do not want to reveal his location but still want to receive personalized experience of the service.

In this work, a template based persona will be defined which can reuse existing data on the user’s device. A stereotyped approach will be used to build the template as an initial persona. Section 3.1 gives a brief overview of stereotype based profiling.

• A. An overview of stereotypes

Using a stereotype approach is quite common in user modeling to create group models as well as for creating initial individual user models[26]. According to [27], stereotypes are simply collections of personal characteristics of system users and this approach is a common in user modeling. The use of stereotypes when combined with the ability to record explicit statements by the user about him/herself and to make direct inferences about a user from his/her behavior, may provide a powerful mechanism for creating systems that can react differently to different users[27]. Stereotypes can provide a better initial user model [15, 26, 28]. However, using stereotype has an issue of accuracy as well [26].

In this work, we are proposing that a service should come with a stereotype as an initial persona to start an immediate personalization process. As the process of personalization starts, user can adapt the stereotype to his/her requirements for the service. Further, a user can add more knowledge to extend the stereotype based persona. Default profiles can also play a significant role in personalized mobile services. According to [29], if a user can be assumed to be of a certain type, i.e. fitting into a certain profile pattern, only a minimal list of attribute overrides have to be transmitted for service execution.

The persona template should be part of the service. The template can describe what features this service is providing to personalize and which information is required about the user and his context. While subscribing to a service, service should present this persona either as wizard configuration or manual configuration. The persona should be stored on the user’s personal device and the interface of the service should be presented based on the preferences given by the user. The interface should provide easy controllable features to control the access of user’s information to keep the user in control with ease. This can be achieved by keeping the structure of user’s persona to a level similar to the structure of user interface model. The persona should have a place for recommendation made by the service which the user can accept or reject in real-time or can go through later to improve his/her persona. After accepting recommendations, these recommendations will become the part of the user’s persona and should be reflected in interface as well. A study [30] argued that user can control the learning process because 1) users can decide whether to accept or reject the systems suggestions, and 2) users can directly access and modify their preference ( either privacy or others) anytime. The study applied the evaluation in location sharing applications and yields promising results.

• IV.    Proposed Architecture

In general, there is a tradeoff between privacy and personalization. It is essential to put the user in control to achieve the personalization of a required level. The more information a user reveals, a more personalized experience can be achieved. It is a difficult task to achieve the desired level of personalization and privacy at the same time. To address this challenge, there is a need to develop an architecture that can address privacy and personalization together. Moreover, the architecture is needed to put the user in control of his/her personal information and scrutability. The purpose here is to provide an architecture that can meet the above mentioned objectives in a flexible and scalable way. Moreover, the architecture will support the end users to

• •    Check, what information is in the persona.

• •    Modify the information in the persona.

• •    Scrutinize, when other services access or attempt to modify their persona.

• •    Understand how their persona affects the service personalization and their experience.

Fig. 4 shows the basic architecture for a client-side personalization to convey the essence of privacy, scrutability and personalization together. The proposed architecture consists of four basic layers with different roles to provide scrutable persona to personalize a mobile service. A brief description of the four layers along with high level components is as follows:

Fig 4. Proposed architecture

• A.    Data Gathering Layer

The data gathering layer has the primary role to collect and store the data. The main purpose of the layer is to prepare a knowledge base which will be utilized by the upper layers to deliver user persona for a mobile service. This layer consists of three main components context aggregator, personal database and persona collector elements . Sensors side collects the raw context using the hardware sensors or software sensors. The context aggregator module collects data from various sensors and store in the personal database to be processed by the management layer.

UserPersona: It represents the transactional data of the user for a service. It also keeps track of the different versions of personas used for a service. Sometimes, it may require using the recent version of a persona instead of constructing and configuring the new one. Each version of a persona will correspond to a certain level of personalization so that a user can quickly switch to a desired persona and the level of personalization.

User Agent: It is responsible for communication with the scrutiny layer to provide for access the persona of subscribed services. It works closely with other components to manage the persona for different services and retrieval whenever it is needed for a service. This component will also be responsible for logging the usage history of the service as well. Any updates to the user’s persona made by this component must be authorized by the user.

• B.    Management Layer

The management layer works on top of data gathering layer. The purpose of this layer is to provide different modules for managing different aspects of user’s persona. It consists of four key components context manager, privacy manager, rule manager and persona manager. Each component has an important role in managing and delivering scrutable user persona with dynamic privacy control to personalize mobile services. Different modules of this layer infer data from the user’s knowledgebase. The components coordinate with each other to provide context, privacy, user’s interest and associated rules to make a dynamic persona.

Privacy Manager: It is clear that some profiling information has to be classified as personal to the users. Sometimes, users do not want to share some of his/her information; or sometimes they are first willing to share after being requested specifically. Four privacy levels are adapted from [31] to put a user in control of revealing her/his data. The flags are Always (A) - to give a data element without asking the user, Check(C) - check user profile and priority rules and Ask(R) - ask the user before delivering the data. We are adding one more flag Never (N) - with this flag the data will never be shared with any service or application. The idea here is to provide privacy information readable by both users and system.

Profile Manager:Profile manager plays a key role in providing the user data required for a service to personalize. It keeps track of factual data about the users and provides privilege to add or remove preferences and interests of a user for a service. This module is helpful to access the preferences of a user for a service to personalize.

Context Manager: Context information can be acquired from various physical and logical sensors. Context acquisition and interpretation process is handled at data gathering layer. The acquired data is stored in a personal database in a format that can be utilized by the context manager at the management layer.

Rule Manager: This component is the incharge of provisioning the rules required to describe the user’s behavior. The main purpose of this module is to provide personal rules for service persona to be delivered and, to allow users to access and modify rules through an intuitive user interface. According to [28], rules are a common method of representing knowledge. This study also makes a comparison of using personal filtering rules, and using stereotypic rules. A user’s persona may consist of a set of rules that can express the user’s preferences. Rules based persona can help to make decisions about revealing the user information to a service while keeping the privacy. The rule manager will help to define rules describing the individual’s behavior. It may also define behavioral rules that can guide the personalization process. The behavioral rules defined by the user will be more accurate and reliable, and there will be no need to validate those rules separately [12]. This study also suggests that validation and separation of good rules or bad rules is a challenging task. This challenge can be minimized by giving the control to the user through an intuitive user interface for defining rules. The study also suggested that the use of rules in profiles can provide an intuitive, declarative and modular way to describe user behavior.

In our approach, after defining a rule by the user, the rule manager will deliver it to the scrutiny layer to put it to the user’s persona. An example of a rule to describe the behavior of a user to receive news can be: “I want to receive news about latest films on weekends only ”. The user should be able to define basic rules by making easy selections.

• C.    Scrutiny Layer

This layer provides scrutability of a user’s persona to be delivered to personalize a mobile service. The core of scrutability is that people should be able to scrutinize their user model and aware of personalization process. Scrutability although a desired feature but has significant challenges to achieve. Authors in a study[4] also suggested that the desirability of scrutability from a privacy point of view, its implementation and control is currently a challenging task due to the user’s lack of understanding of these notions and of effective and efficient user interfaces to support them. To address this challenge, we added this dedicated layer to handle scrutability with the support of adaptive interfaces at application layer. The layer consists of three different modules filtering engine, sPersona and PersonaController in order to coordinate the scrutability process of the persona. The descriptions of major components are as follows:

PersonaController: This component is responsible for interaction with the user through an adaptive user interface. It controls the delivery of persona from the lower layers to a service provider. It acts as a gateway with the help of a user between the system and the service provider. User can also communicate with the lower layers of the architecture to scrutinize the persona for personalized services. Depending on the rules defined in the persona, the service provider may get access to more or less user persona and context information, which enables them to do their part of the personalization or service adaptation. If the mandatory information cannot be accessed, the service provider may refuse to offer the service.

sPersona Module: This module is the backbone of the scrutiny layer. It prepares the user persona depending on the information received from the coordination layers and components. It also takes the real-time user feedback via persona controller component to scrutinize the persona and prepare it for delivery.

Filtering Engine: It is in-charge of asking the decisions and enforcing it. It asks from the respective managers at the management layer for certain decisions to include an element to the persona or not. The filtering engine will receive the constructed persona with certain rules and will update the sPersona module accordingly.

• D.    Application Layer

The application layer represents the adaptive user interface required to access the personalized service and presents personalization contents. This layer provides an intuitive user interface to work with the user persona. It plays on top of scrutiny layer to access and update the elements of persona to be shared with different services.

Fig. 5. Basic workflow techniques. Once the profile is initiated, the user may continuously make updates to the persona to make it more precise and reflect new preferences or change of preferences.

Initialization (startup persona and initial adaptation)

• •    Subscribed or install a service

• •    Get a stereotyped persona template and run wizard

• •    The user agent will understand the stereotyped profile and provide user data required for the initial profile. An intuitive GUI can present a series of forms through which users can fill in blanks and mark check-boxes in order to express their preferences.

• •    The user agent will store that initial adapted profile we called it initial persona to the database with service id.

Learning and adaptation process

• •    The user can review his/her persona to adapt according to the preferences.

• •    Context manager can help to review which context elements are being shared.

• •    Rule manager can help to review basic rules for a particular service.

• •    Privacy manager can help to review and adjust privacy flags.

• •    Profile manager can help to review and adjust factual and transaction data.

• •    The learning process is a continuous process and will     receive     recommendations.     These

recommendations can help in learning and adaptation of a persona.

Sharing and Scrutability of Persona

• •    Users need to share persona to get personalized contents and recommendation.

• •    The Persona controller of the scrutability layer will get the persona from the user agent.

• •    If the user wants to scrutinize it, the persona controller will deliver it to sPersona element which is the main component responsible for scrutability.

• •    sPersona will ask the filtering engine to verify that the persona elements are according to the current user’s preferences.

• •    Filtering engine will ask corresponding managers to include or exclude certain elements to the user’s persona.

• •    After filtering and confirmation from the filtering engine and sPersona, the persona controller will deliver the scrutinized persona to the service provider.

• E.    Basic workflow

The service deliver a stereotyped persona as described above with some default attributes as an initial persona. After that, the user can adapt stereotyped persona through an easy to use interface to receive personalized contents or recommendations. The stereotyped profile can be adapted by the user through learning and filtering

• V.    Discussions

The personalization process should be transparent and non-obtrusive through an intuitive GUI. In addition, the user should be involved and given control of the personalization process. It is a challenging task to provide new users with the personalized services due to lack of knowledge about their history. The specification and implementation of a full-fledged architecture to achieve the objectives is a long-term goal. However, the implementation of the architecture will focus the following issues:

Degree of Complexity: Since the user will be incharge of the whole personalization process, the complexity of handling all aspects of the persona and the service can be difficult to manage. To tackle this challenge, a stereotyped persona can give users a quick start. On the other hand, service providers can make recommendations which the user can accept or add to their persona. User interface will play a key role here as well.

Control and convenience: Users may lose the interest if the provision of personalization will be cumbersome and complex. Therefore, it is indispensable to provide intuitive user interface to perform the required tasks to achieve the required level of personalization.

Performance: The need of good performance is clear in the case of mobile services. It is will be crucial to measure the performance of the system on a variety of devices. The performance of the system will have a significant role for further advancements of this approach.

Intuitive user interface: The user interface is a key in this personalization approach. It is required to have an adaptive interface to improve the usability and performance of the system. The scrutability of the user model may require frequent user interaction which can be made easy through adaptive interfaces.

Adaptive and adaptable : There is a need to distinguish the adaptive and adaptable parts of the complex process of personalization. Some parts of this architecture require more user interaction, and some tasks will be handled by the system. The data gathering layer and management layer may require remarkably less user interaction and can be considered as the system’s task. However, the scrutiny layer will involve the user more as compared to the lower layers. In a way, the whole approach is blending the personalization and the customization together to achieve more effective personalization.

Generality and extensibility : The architecture presented is quite general and can provide personalization to a variety of mobile services of different domains. In a way, it may provide a layer of scrutability personalization conceptually to any architecture for providing personalized mobile services.

• VI.    Conclusions and Further Work

Mobile client-side personalization approach allows a single system to develop and maintain a life-long user model that can be applied to a variety of mobile services. The objective of this paper is to introduce a client-side personalization architecture that incorporates privacy and scrutability of a user model as an integrated part of the personalization process. It has been attempted to combine both adaptive and adaptability within one architecture. Moreover, this study also underpinned the significance of client-side personalization and the user control over his/her personal data. It has finally discussed certain issues that can be crucial to handle to make this approach successful. We have concluded that the mobile services should provide

• •    Different levels of user’s privacy regarding the context and user’s data.

• •    Flexibility to  tailor to different levels of

personalization.

• •    List minimum data required to personalize a mobile service.

• •    An intuitive GUI to handle dynamic privacy and scrutability of a user model.

• •    Combine both adaptive and adaptable approach to get more precise and accurate personalization of mobile services.

The next step is to develop and evaluate a prototype which will demonstrate the approach. The contribution illustrated in this paper is a first step in this direction. The focus of the prototype will be to hide the complexity from the user. The adaptive interface will be a key to reduce the complexity. We will evaluate the system with a variety of mobile information services after developing a prototype.