PERSONALIZATION AND USER PROFILE STANDARDIZATION

1
PERSONALIZATION AND USER PROFILE STANDARDIZATION
The Seventh IASTED International Conference on
Communication Systems and Networks CSN 2008 1-3
September 2008

• Tatiana Kovacikova
• ETSI (European Telecommunications Standards
  Institute), Sophia Antipolis, France
• STF 342

2
Agenda items and topics

• User profile concept and benefits
• Background work
• Personalization and user profile management (ETSI
  EG 202 325)
• Universal Communications Identifier (UCI) and
  profiles (ETSI EG 284 004)
• Ongoing STF 342 work
• ETSI ES 202 746 on User Profile Preferences and
  Information
• ETSI TS 102 747 on Architectural Framework
• Related STFs on user profiles

3
User profile - Concept and benefits
4
Problem
Services and content may not be delivered
appropriately to

• all users in various situations

• different devices with different software and
  hardware

• STF342 focus on
• users needs
• different situations different needs
• multimodal, multi-device environments
• services

To tailor users preferences to different
situations
5
Why User Profiles?

• This situation?
• or personal and efficient services?
• User profiles are about
• Personalization of services
• that reflect users unique lifestyles and
  situations

6
What is a User Profile?
User and context information used to
deliver appropriate services and content, in a
format tailor-made to users needs.

• User profiles contain data describing
• The users preferences including their
• characteristics
• preferences and needs depending on time,
  activity, role, location
• Settings, rules, context information related to
• User Profile Management system
• services
• terminals
• communications
• physical objects in users proximity

7
Permanent / Situation dependent profilesExample
Special need - listen to text

• A person driving a car might prefer listening to
  text.
• The situation dependent profile
• Car provides this service.

• A blind person or a child who cannot yet read
  might prefer listening to text.
• The permanent profile
• Listen to Text/Blind provides this service.

8
Wider use of preferences

• related profile fields for other devices or
  services can be populated by the same data.
• Define once - use in many terminals and services

9
Background work

• ETSI STF 265 ETSI Guide, EG 202 325 Human
  Factors (HF) User Profile Management
• defines the user profile concept and establishes
  a set of guidelines relevant to users and their
  need to manage their user profiles
• ETSI STF 302 ETSI Guide, EG 284 004
  Telecommunications and Internet converged
  Services and Protocols for Advanced Networking
  (TISPAN) Incorporating Universal Communications
  Identifier (UCI) support into the specification
  of Next Generation Networks (NGN)
• a single global identifier for the user
• for ALL communications such as fixed and mobile
  phone numbers, fax, email addresses
• to reflect a desire on behalf of users to manage
  the capabilities of their electronic
  communications

10
Overview of personalization and user profile
management (ETSI EG 202 325)
11
Outcome STF265 - An ETSI Guide (EG) 202 325

• that provide
• recommendations and guidance
• to solve the common issues of user profile
  management.
• Useful for
• standardization bodies
• manufacturers
• service providers
• developers (service and device)

12
Stakeholder roles

• Users
• Profile providers
• Service providers
• Device manufacturers

13
Stakeholder roles

• Users
• Independent adults
• the most straightforward category
• the greatest (?) freedom to manage their profiles
  
• Supervising users (ownership of responsibility)
• parent - child
• employer - employee
• caregiver care recipient
• teacher student relationships
• Users with impaired or underdeveloped functions
• First-time users

14
Stakeholder roles

• Profile providers
• entities, such as companies, that provide the
  profile and associated services
• Service providers Device manufacturers - they
  decide about
• in what way personalization can take place
• which parts of the service are candidates for
  personalization
• available settings (identifying which are
  standardized and which are service or device
  unique)
• produce templates that reflect these points
• For the guidelines, use the results of EG 202 325

15
Overview of Universal Communications Identifier
(UCI) and profiles (ETSI EG 284 004)

16
UCI the unique identifier

• A flexible means of identification in an
  increasingly communications intensive world
• It minimizes the need to for a user to have many
  different identifiers for a range of different
  communications services
• It has to provide the potential for verifying the
  true identity of the originator or recipient of a
  communication
• It has to remain unchanged when moving to a
  different service provider or service type
• It must be structured
• It would be beneficial if existing systems can
  process it without significant update
• A numeric element conforming to the E.164 scheme
  easily meets all of the above criteria

17
UCI additional data

• Additional data elements can be used to convey
  information such as
• whether the UCI label is authentic or not
• the preferred language for the information or
  communication session
• special user requirements e.g. textual
  information presentation for a deaf user

18
UCI - the full picture

• A UCI with the following structure meets all of
  the previous requirements

19
UCI architecture

• Each UCI user has a Personal User Agent (PUA)
  that
• has access to a list of the users contacts
• has access to all of the users information and
  communication preferences
• contains rules that control how a user wishes
  their communications to be managed
• can negotiate with other PUAs to try to achieve a
  mutually acceptable outcome
• UCI needs Service Agent (SA) functionality to
  ensure that PUAs have a standardized interface to
  all applications, services and networks
• The SA functionality could require little or no
  changes to some existing APIs and gateways
• In other cases, SA functionality could require
  some form of specialised middleware

20
Mapping UCI to NGN

• Early UCI work described requirements and defined
  a conceptual architecture
• ETSI STF 302 - examined how NGN functional
  entities, protocols and services (e.g. SIP,
  Presence and ENUM) can deliver the capabilities
  required by UCI
• For the details, use the results of EG 284 004

21
Ongoing STF 342 work ETSI ES 202 746 on User
Profile Preferences and Information

• It defines a set of user profile preference and
  information settings for deployment in ICT
  services and devices for use by ICT users and
  suppliers
• It specifies
• objects including settings, values, operations
  and a lexicon of end user terms
• a rule definition language for defining
  functionality such as automatic modification of
  profiles.
• Profile solutions within the scope of the ES
• those provided for the primary benefit of the
  end-user
• those which the end-user has rights to manage the
  profile contents.

22
Profile content

• Information
• data about or related to the user (e.g. name,
  address, location)
• Preferences
• choices made by the user about a given parameter
  that will define or modify the system behavior
• more complex preferences can be expressed in the
  form of rules
• in some situations a preference is instead called
  a need (e.g. a blind user sets the modality to
  sound)
• Rules
• statements that can be automatically interpreted
  in order to define or modify the system behavior.

23
Profile content classification (1)

• Generic information
• permanent or semi-permanent information such
  as name
• address
• date of birth
• phone numbers
• e-mail address.
• Generic preferences
• contain data that is applicable to a range of
  situations, services and devices, such as
• text size
• language
• contrast and colors
• sound volume.

24
Profile content classification (2)

• Service and device related information and
  preferences
• preferences that are only relevant for a
  particular type or subtype of service or device
• Examples
• medical data (related to eHealth systems)
• insurance information (related to a range of
  applications such as medical and vehicle related
  services)
• preferred modes of communication, e.g. SMS rather
  than e-mail
• what should happen with communications services
  when the user is busy
• the frequency with which new email message
  delivery is checked
• how to show presence information.

25
Profile content classification (3)

• Rules
• statements that can be automatically interpreted
  in order to define or modify the system behavior
  to meet the users requirements
• they may
• express complex preferences
• activate or de-activate situation dependant
  profile specifications
• Context information
• any relevant information that can affect the
  behavior of the system information such as
• the status of the services to which the user is
  subscribed
• the status of the users devices
• the location of the user
• other presence information
• network conditions.
• this information will be mainly used in rules

26
Profile hierarchy Ex.

• Personal default (base profile specification)
• the profile data that will be active when no
  context dependent situation applies
• Situation dependent profile specifications
• the values of data in the user profile are
  amended according to the values specified in the
  related situation dependent profile specification

27
Creation of the active profile Ex.
Active Profile default profile specification
any applicable situation dependent profile
specification
28
Where are the profiles?

29
Profile tools

• Tools that support users when they need to
• create a profile specification (manually or with
  a template provided by the tool)
• add to, change or delete information / rules and
  preferences in their profile specifications
• check what information is in their profile
  specifications
• know when other entities access their profile
  specifications
• understand how their profile specifications
  affect the service or capabilities that they
  experience

30
Profile tools

• Different versions such as
• from any terminal (e.g. PC, PDA, mobile phone,
  fix phone)
• on different operating systems
• as a web application or installed on the
  terminal
• using any browser (e.g. Explorer, Netscape, WAP
  browser)
• using a graphical user interface, voice command
  interface or a human being)
• using preferred language
• private profile administrator
• corporate profile administrator.
• Goal
• Users should have a maximum of choices concerning
  the use of profile tool.

31
Templates

• Templates that contain typical rules and settings
  will be of particular benefit in the initial
  configuration of profiles
• information is already filled in as suggestions
  or default starting points
• the user can choose to accept it or otherwise
  select available alternatives
• Suit different types of user or situation
• first time user
• companies
• clubs
• roles private, professional, etc
• accessibility children, visual impairment etc

32
Automatic activation of profiles

• Users could define activation rules according to
  their activities and make use of different means
  such as events from
• time schedules
• accessories
• external applications
• physical sensors/transmitters
• location based services

33
Example - Profiles with automatic activation
34
Information sharing and privacy

• As users become more aware of privacy issues,
  there is
• an increasing need for user acceptance of
  personalized services
• a demand for solutions allowing them to be in
  control of their profile data.
• If profile data is made available to the wrong
  people, then users will lose confidence.
• Too restricted access to profile data should be
  avoided,
• as it may reduce the usability and the number of
  available services

35
Information sharing and privacy

• Sharing of profile data - Privacy levels
• public anyone can read or write to these profile
  fields without authentication or privacy concerns
• read only only the user can write. This is the
  lowest user basic authentication security
• read list the lowest level, the user can write,
  others on the access list can read after basic
  authentication
• vendor profile data maintained by, and kept
  absolutely secure to, a single vendor. This may
  or may not be known to the user
• by permission data that can be read by others,
  but only after getting specific permission from
  the user each time they are read
• private data only the user can read or write

36
Ongoing STF 342 work ETSI TS 102 747 on
Architectural Framework

• It defines an architectural framework supporting
  the personalization and user profile management
  concepts described in EG 202 325 Human Factors
  (HF) User Profile Management
• It addresses issues related to networks, end-user
  terminals and SmartCards (e.g. embedded in an
  end-user device or a stand alone card)
• Capabilities provided by the architecture are
• data editing (e.g. creation, templates, update).
• data storage
• synchronization
• backup
• access control respecting user preferences and
  legal policies.

37
ArchitectureNetwork and terminal issues

• Step 1
• Gap analysis
• UPM requirements
• UCI/TISPAN architecture
• other related architecture input, such as OMA,
  IST, SPICE OWL ontologies
• Step 2
• How to solve the identified gaps

38
Profile Agent
Any profile needs functionality associated with
it - this we class as its Profile Agent (for
the agents guidelines - see EG 202 325)
Storage Agent
Processing Agent
Activation Agent
Viewing/Editing Agent
39
Architecture to support user profile management

• Previous ETSI work on user profile management (EG
  202 325) defined a large set of guidelines
• It is necessary to identify what architectural
  solutions are required to deliver these
  guidelines
• The solution for supporting UCI in IMS based NGNs
  will be examined as a potentially practical
  solution
• Examination of possible architectural options
  requires
• A thorough analysis of the guidelines in EG 202
  325
• A coherent and clear way of representing the
  concepts behind those guidelines
• Examining the approach behind user profile
  solutions documented in other standards
• Looking for gaps between architectural options
  and the set of requirements

39
40
Concept capture

• The guidelines from the previous ETSI user
  profile management work were analysed and the key
  concepts were identified and documented as tags
  assigned to branches of a mindmap

40
41
Concept classification

• The concepts identified in the analysis of the
  guidelines have been initially classified
  according to whether they are object classes,
  attributes, actions, etc.

41
42
Domain knowledge modelling

• The classified concepts are being modelled as an
  ontology. The first phase of modelling was to
  develop an ontology derived exclusively from the
  analysis of previous ETSI work
• The current approach is to augment / modify the
  ontology developed by the European Community's
  Sixth Framework Programme (FP6) SPICE (Service
  Platform for Innovative Communication
  Environment) project
• As related standards work and the output of other
  projects are analysed, this ontology will be
  further developed and maintained throughout the
  lifetime of the STF
• Work on evolving both the architectural
  requirements and the user profile object model
  will be able to use the ontology as a coherent
  and integrated source of domain knowledge

42
43
User profiles for other STFs

• STF 287 - User-oriented handling of
  multicultural issues in broadband and narrowband
  multimedia communications
• STF 324 - PIAP Public Internet Access Points
• STF 352 - eHealth User Profiles
• STF 353 - ICT in Cars

44
Information and communication

• Web http//portal.etsi.org/stfs/STF_HomePages/STF
  342/STF342.asp
• Email Francoise.Petersen_at_etsi.org (STF leader)
• stf342_at_etsi.org
• Do you want to
• 1. receive the newsletters from our STF (about
  once a month, or when relevant)?
• 2. discuss personalization and user profiles with
  a wider group? If so welcome to use our mail list
  HF_User_Profile_Management_at_list.etsi.org
• Subscribe at http//list.etsi.org/HF_USER_PROFILE
  _MANAGEMENT.html

45
Thank you!Questions?