Share it_

Document Sample
Share it_ Powered By Docstoc
					                               IST-2000-28703:

                               Share it!
                               DELIVERABLE #3


                           Description of example
                               applications

Version   Status               Date      Comments

0.1       Skeleton doc         16/1/02   Skeleton document provided as starting point. To be filled in before and
                                         discussed at the February WP4-meeting.

0.1b      Skeleton+ doc        13/2/02   Skeleton document with first classification of apps/services and some
0.1c      Refs corrected       14/2/02   implications for broadcasters.

0.2       Agreed outline       27/2/02   Agreed outline document indicating responsible part-contributors.
                                         Includes first text on apps & services and Share it! implications.

0.2b      Outline+             15/3/02   0.2 version document + additional text from NOB, Nokia, PRL

0.2c      Outline++            29/3/02   0.2b version + additional text from Elisa, FhG, KPN, UoL, Philips NL

0.2d      Outline++            17/5/02   0.2c version + chapter 5 authors assigned

0.3       D1 refs + mockups    14/6/02   Links to scenarios and requirements (D1) updated and first text on
                                         mock-ups added

0.4       D1 refs + mockups+   4/7/02    Some missing refs + more in-depth text on mock-ups added.
                                         Duplications from paragraph 5.1 & 5.2 removed.

0.4b      D1 refs + mockups    2/8/02    Some missing descriptions + more in-depth text on mock-ups added.
          updated version                Chapters renumbered.

0.4c      ‘80% version’        11/9/02   Mock-up descriptions updated (partly) + some missing text added



                                                   1
0.5       Draft final version      4/11/02    Revision of chapter 4, addition of text in chapter 1, removal of editor
                                              comments, numbering of figures and tables.

0.9       Draft final version II   13/11/02   Updating of chapter 4 with newly received contributions, text on
                                              scnenarios in new chapter (5), general editor work

1.0beta   Final version            23/11/02   Feedback from partners used, updated Scenario A part, actualised NOB
                                              iTV portal mock-up, proofread and ready to be signed off. Beta version
                                              only because it still is lacking a few pictures due to technical problems
                                              with Word...

1.0       Signed off version       31/11/02   Missing pictures inserted and signed off by all partners




                                              - Public -




                                                        2
Project Number:                                     IST-2000-28703
Project Title:                                      Share it!
Title of Deliverable:                               Description of example applications
Deliverable Type:                                   Public


CEC Deliverable Number                              3
Contractual Date of Delivery to the CEC:            November 30th 2002
Actual Date of Delivery to the CEC:
Work package Contributing to the Deliverable:       WP4
Nature of Deliverable:                              Report & Demonstration
Editor:                                             Frans de Jong, NOB, frans.dejong@nob.nl
Contributors:                                       Philips NL, Philips UK, NDS, BBC, NOB, Elisa,
                                                    KPN, FhG, UoL
External approval:




Abstract:

The Share it! ‘Description of example applications' deliverable (#3) covers a range of
applications and services enabled by the combination of broadcasting, local storage and
broadband interconnections.

This document forms a record of the process that the WP4-group went through in coming to
the types of applications and services to be prototyped in the Share it! project. It provides
example applications and scenarios based on the partner’s roles, backgrounds on benefits
and drawbacks. A range of concepts were mocked up to help think through core
functionalities, and to prioritise which applications and services to research more in depth and
to prototype in the remainder of the project.

Keywords: Applications, services, broadcast, broadband, local storage, mock-ups




                                                3
4
Table of Contents

ABOUT THIS DOCUMENT ...................................................................................................11

1     SHARE IT! IN PERSPECTIVE .......................................................................................12
    1.1     MYTV........................................................................................................................12

      1.1.1         INTRODUCTION .....................................................................................................................12

      1.1.2         MYTV RESULTS ....................................................................................................................12


    1.2     SHARE IT!..................................................................................................................12

      1.2.1         AIM ......................................................................................................................................12

      1.2.2         SCOPE .................................................................................................................................13

      1.2.3         CURRENT STATUS .................................................................................................................14

          1.2.3.1      PROCESS: TOWARDS MAIN SCENARIOS ............................................................................................ 14

          1.2.3.2      OUTLINE OF SYSTEM REQUIREMENTS / IMPACTS OF TECHNOLOGY CHOICES ...................................... 14

          1.2.3.3      TECHNOLOGY CHOICES ................................................................................................................... 15


2     APPLICATIONS & SERVICES.......................................................................................18
    2.1     RESIDENT APPLICATIONS & FUNCTIONALITY ................................................................18

      2.1.1         USER DATA COLLECTION .......................................................................................................18

      2.1.2         RECORDING, COPYING AND DISTRIBUTION OF CONTENT ...........................................................19

      2.1.3         EDITING CONTENT ................................................................................................................20

      2.1.4         TELECOM RELATED APPLICATIONS .........................................................................................20

      2.1.5         REMOTE CONTROL ................................................................................................................22

      2.1.6         RIGHTS MANAGEMENT & PROTECTION, SYSTEM SECURITY .......................................................23

      2.1.7         USER PROFILE MANAGEMENT ...............................................................................................24

    2.2     DOWNLOADABLE APPLICATIONS & SERVICES...............................................................25

      2.2.1         CONTRIBUTING AV TO THE BROADCASTER .............................................................................25

      2.2.2         CONTRIBUTING DATA TO THE BROADCASTER ..........................................................................25

      2.2.3         PROVIDING EXTRA AV-MATERIAL VIA BROADBAND ..................................................................26

      2.2.4         USE OF LOCAL STORAGE .......................................................................................................26

      2.2.5         SUPERDISTRIBUTION .............................................................................................................26

      2.2.6         COMMUNITY BUILDING ...........................................................................................................26

      2.2.7         BRAND STRENGTHENING .......................................................................................................27

    2.3     THIRD PARTY SERVICES ..............................................................................................27

      2.3.1         PORTALS PROVIDING NEW CONTENT .......................................................................................27

      2.3.2         GATHERING AND MODERATION SERVICES ...............................................................................29


                                                                             5
      2.3.3         TRUSTED THIRD PARTY ..........................................................................................................30

3     BUSINESS ASPECTS....................................................................................................31
    3.1     CE MANUFACTURER ..................................................................................................31

      3.1.1         BENEFITS .............................................................................................................................31

      3.1.2         DRAWBACKS/DANGERS .........................................................................................................31

      3.1.3         RELATED REQUIREMENTS ......................................................................................................32

    3.2     NETWORK PROVIDER ..................................................................................................32

      3.2.1         BENEFITS .............................................................................................................................32

      3.2.2         DRAWBACKS/DANGERS .........................................................................................................33

      3.2.3         RELATED REQUIREMENTS ......................................................................................................34

    3.3     BROADCASTER ..........................................................................................................34

      3.3.1         BENEFITS .............................................................................................................................34

      3.3.2         DRAWBACKS/DANGERS .........................................................................................................35

      3.3.3         RELATED REQUIREMENTS ......................................................................................................36

    3.4     THIRD PARTIES ..........................................................................................................36

      3.4.1         BENEFITS .............................................................................................................................36

      3.4.2         DRAWBACKS/DANGERS .........................................................................................................37

      3.4.3         RELATED REQUIREMENTS ......................................................................................................37

    3.5     THE END USER ...........................................................................................................38

      3.5.1         BENEFITS .............................................................................................................................38

      3.5.2         DRAWBACKS/DANGERS .........................................................................................................38

      3.5.3         RELATED REQUIREMENTS ......................................................................................................39

4     MOCK-UPS ....................................................................................................................40
    4.1     PARTNERS’ CONCEPTS & MOCK-UPS...........................................................................40

      4.1.1         SHARE IT! BOX USER INTERFACE (PHILIPS UK)......................................................................40

          4.1.1.1      DESCRIPTION .................................................................................................................................. 40

      4.1.2         NEWS EX10SION (BBC) .......................................................................................................41

          4.1.2.1      DESCRIPTION .................................................................................................................................. 41

          4.1.2.2      THE MOCK-UP ................................................................................................................................. 41

          4.1.2.3      RESEARCH AREAS/REQUIREMENTS .................................................................................................. 42

      4.1.3         GARDENERS' WORLD (BBC) ................................................................................................42

          4.1.3.1      DESCRIPTION .................................................................................................................................. 42

          4.1.3.2      THE MOCK-UP ................................................................................................................................. 43

          4.1.3.3      RESEARCH AREAS/REQUIREMENTS .................................................................................................. 43


                                                                               6
4.1.4        TV-ANYTIME COMPLIANT DATA SERVICE (BBC) .....................................................................43

  4.1.4.1       DESCRIPTION .................................................................................................................................. 43

  4.1.4.2       THE MOCK-UP ................................................................................................................................. 43

  4.1.4.3       RESEARCH AREAS/REQUIREMENTS .................................................................................................. 44

4.1.5        RIGHTS NEGOTIATOR (BBC).................................................................................................44

  4.1.5.1       DESCRIPTION .................................................................................................................................. 44

  4.1.5.2       RESEARCH AREAS/REQUIREMENTS .................................................................................................. 45

4.1.6        BROADCASTER’S ITV PORTAL (NOB)....................................................................................45

  4.1.6.1       DESCRIPTION .................................................................................................................................. 45

  4.1.6.2       THE MOCK-UP ................................................................................................................................. 46

  4.1.6.3       RESEARCH AREAS .......................................................................................................................... 47

4.1.7        SOCCER SHARING (NOB) .....................................................................................................47

  4.1.7.1       DESCRIPTION .................................................................................................................................. 47

  4.1.7.2       THE MOCK-UP ................................................................................................................................. 48

  4.1.7.3       RESEARCH AREAS .......................................................................................................................... 50

4.1.8        TV ANYTIME METADATA SERVER (NOB)................................................................................50

  4.1.8.1       DESCRIPTION .................................................................................................................................. 50

  4.1.8.2       THE MOCK-UP ................................................................................................................................. 50

4.1.9        AUDIENCE AND PROGRAMME RESEARCH (NOB) .....................................................................50

  4.1.9.1       DESCRIPTION .................................................................................................................................. 50

  4.1.9.2       THE MOCK-UP ................................................................................................................................. 51

  4.1.9.3       RESEARCH AREAS .......................................................................................................................... 52

4.1.10       HANDHELD DEVICE CONNECTIVITY (KPN, ELISA) ..................................................................52

  4.1.10.1          DESCRIPTION ............................................................................................................................. 52

  4.1.10.2          THE MOCK-UP............................................................................................................................. 52

  4.1.10.3          RESEARCH AREAS/REQUIREMENTS ............................................................................................. 53

4.1.11       NETWORK STORING (KPN, ELISA).......................................................................................53

  4.1.11.1          DESCRIPTION ............................................................................................................................. 53

  4.1.11.2          THE MOCK-UP............................................................................................................................. 54

4.1.12       BUNDLING OF CONTENT (FHG) ..............................................................................................57

  4.1.12.1          DESCRIPTION ............................................................................................................................. 57

  4.1.12.2          THE MOCK-UP............................................................................................................................. 57

  4.1.12.3          RESEARCH AREAS/REQUIREMENTS ............................................................................................. 60




                                                                        7
      4.1.13         ANNOTATION OF STREAMED CONTENT (FHG)..........................................................................61

          4.1.13.1          DESCRIPTION ............................................................................................................................. 61

          4.1.13.2          THE MOCK-UP............................................................................................................................. 62

          4.1.13.3          RESEARCH AREAS/REQUIREMENTS ............................................................................................. 64

      4.1.14         DISTRIBUTED NON REAL-TIME GAME (FHG) ............................................................................64

          4.1.14.1          DESCRIPTION ............................................................................................................................. 64

          4.1.14.2          THE MOCK-UP............................................................................................................................. 64

          4.1.14.3          RESEARCH AREAS/REQUIREMENTS ............................................................................................. 66

      4.1.15         CHAT SERVICE (UOL) ...........................................................................................................66

          4.1.15.1          DESCRIPTION ............................................................................................................................. 66

          4.1.15.2          THE MOCK-UP............................................................................................................................. 66

          4.1.15.3         RESEARCH AREAS/REQUIREMENTS .............................................................................................. 68

      4.1.16         THIRD-PARTY PEER-TO-PEER USER GROUP WITH MEMBERSHIP (UOL) ......................................68

          4.1.16.1          DESCRIPTION ............................................................................................................................. 68

          4.1.16.2          THE MOCK-UP............................................................................................................................. 68

          4.1.16.3          RESEARCH AREAS/REQUIREMENTS ............................................................................................. 69

      4.1.17         ENHANCED TV-ANYTIME DATA SERVER (UOL) .......................................................................69

          4.1.17.1          DESCRIPTION ............................................................................................................................. 69

          4.1.17.2          THE MOCK-UP............................................................................................................................. 69

          4.1.17.3          RESEARCH AREAS/REQUIREMENTS ............................................................................................. 69

      4.1.18         REMOTE CONTROL OF THE SET-TOP BOX ................................................................................69

          4.1.18.1          DESCRIPTION ............................................................................................................................. 69

          4.1.18.2          RESEARCH AREAS/REQUIREMENTS ............................................................................................. 69


5     MAIN SCENARIOS ........................................................................................................71
    5.1     PROTOTYPE SCENARIOS .............................................................................................71

    5.2     BASIC MODEL ............................................................................................................71

    5.3     CURRENT STATUS OF THE SCENARIOS (EARLY NOVEMBER 2002) ..................................72

    5.4     SCENARIO A: BASIC CONTENT SHARING FUNCTIONALITY ..............................................72

      5.4.1          OVERVIEW OF PROPOSED BASIC CONTENT SHARING FUNCTIONALITY ......................................72

      5.4.2          DEMONSTRATOR SYSTEM......................................................................................................72

      5.4.3          BASIC DEMO SYSTEM ...........................................................................................................73

      5.4.4          PROPOSED WALKTHROUGH ..................................................................................................73

      5.4.5          ADVANCED DEMO SYSTEM ....................................................................................................75



                                                                                8
      5.4.5.1       SHARE IT! RIGHTS BROKER............................................................................................................. 75

      5.4.5.2       SHARE IT! PEER EMULATOR ............................................................................................................ 75

      5.4.5.3       HOME GATEWAY ............................................................................................................................. 75

  5.4.6          POTENTIAL SCENARIO A FUNCTIONALITY ...............................................................................76

5.5     SCENARIO B: OPPORTUNITIES FOR SERVICE PROVIDERS ..............................................77

  5.5.1          B1: NETWORKED SERVICES ..................................................................................................77

  5.5.2          SYSTEM COMPONENTS..........................................................................................................78

  5.5.3          WALKTHROUGHS ..................................................................................................................79

      5.5.3.1       USER RECEIVES SUGGESTIONS ........................................................................................................ 79

      5.5.3.2       USER SEARCHES FOR PEER-HOSTED GROUP CONTENT ..................................................................... 79

      5.5.3.3       USER SEARCHES FOR NETWORK-HOSTED GROUP CONTENT .............................................................. 79

      5.5.3.4       USER SUBMITS CONTENT ................................................................................................................. 80

  5.5.4          REQUIREMENTS ....................................................................................................................80

  5.5.5          ISSUES .................................................................................................................................80

  5.5.6          OPPORTUNITIES FOR EACH PARTY..........................................................................................80

  5.5.7          ROLE OF EACH PARTY ...........................................................................................................81

  5.5.8          B2: AUDIENCE RESEARCH ....................................................................................................81

  5.5.9          SYSTEM COMPONENTS ..........................................................................................................82

  5.5.10         WALKTHROUGHS ..................................................................................................................83

      5.5.10.1          THE END-USER PERSPECTIVE ...................................................................................................... 83

      5.5.10.2          THE SYSTEM PERSPECTIVE.......................................................................................................... 84

      5.5.10.3          THE BROADCASTER PERSPECTIVE ............................................................................................... 84

  5.5.11         REQUIREMENTS ....................................................................................................................85

  5.5.12         ISSUES .................................................................................................................................85

  5.5.13         OPPORTUNITIES FOR EACH PARTY..........................................................................................86

  5.5.14         ROLE OF EACH PARTY ...........................................................................................................86

5.6     SCENARIO C: CREATING, EDITING AND PUBLISHING BY VIEWERS ...................................87

  5.6.1          OVERVIEW OF END USER SERVICES ........................................................................................87

  5.6.2          SYSTEM COMPONENTS..........................................................................................................87

  5.6.3          WALKTHROUGHS ..................................................................................................................88

      5.6.3.1       PICTURE WITH SHORT MESSAGE ...................................................................................................... 88

      5.6.3.2       COMPLEX CONTENT SHARED WITH OTHER USERS ............................................................................. 88

      5.6.3.3       MIXTURE OF HOME-GROWN AND THIRD-PARTY CONTENT .................................................................. 89

      5.6.3.4       INDEXING OF A STREAM ................................................................................................................... 89


                                                                           9
          5.6.3.5      PROVISION OF ADDITIONAL CONTENT RELATED TO AN INDEXED VIDEO ............................................... 89

          5.6.3.6      USE OF PRE-DEFINED ANNOTATIONS THAT ARE PROVIDED WITH THE BROADCAST PROGRAMME ......... 90

     5.6.4          REQUIREMENTS ....................................................................................................................90

     5.6.5          ISSUES .................................................................................................................................90

     5.6.6          OPPORTUNITIES FOR EACH PARTY..........................................................................................91

     5.6.7          ROLE OF EACH PARTY ...........................................................................................................91

6    BIBLIOGRAPHY ............................................................................................................92

A    ANNEX ...........................................................................................................................93
    A.1     ABBREVIATIONS AND TERMINOLOGY............................................................................93




                                                                           10
About this document
This document is the Share it! project’s third deliverable. The Share it! project currently is at
the beginning of its application and service implementation phase. This document is intended
to:

1.      Set the background of the Share it! project (what has been done in the previous
        project) and to discuss the current status of the underlying system design work. This
        chapter also explains how we came to the current scenarios. Chapter 1
2.      Introduce applications, services and functionality that take advantage of the Share it!
        concepts and platform. Chapter 2
3.      Discuss potential benefits and drawbacks for the different value-chain actors and to
        relate these to the requirements identified in deliverable 1. Chapter 3
4.      Specify the subset of applications/services selected for mock-up implementations and
        to describe their implementations. Chapter 4
5.      Provide a small number of main scenarios that will be implemented in the remainder
        of the project. Chapter 5




                                               11
1 Share it! in perspective
This chapter provides an overview of the position of the Share it! project in relation to its
predecessor project: myTV, and the status of the project at the time of writing. Our
perspective is focussed on applications & services.

1.1       myTV

1.1.1      Introduction
The European myTV project was the predecessor of the Share it! project. myTV focussed on
the interoperable use of local storage technology in set-top boxes. Many of the Share it!
partners also participated in myTV. The project ran from January 1999 up to January 2001.


1.1.2      myTV results
The myTV project developed and implemented multiple prototypes of set-top boxes and
related applications and services. Those were all based on DVB-MHP, IP and TV-Anytime
specifications. The project made use of broadcast for content-delivery and a small-bandwidth
return-channel for control & content referencing data. No network storage, IP-streaming or
direct box-to-box connections were used.

The resulting prototypes included:

      •    Resident navigators for Philips and Nokia set-top boxes
      •    A downloadable navigator, including virtual channel by BBC
      •    A Segmented Latest News application by NOB
      •    Metadata-servers for advanced EPG-information
      •    Remote control of the PVR via WAP and the Internet

Besides developing prototypes, the myTV team contributed to standardisation, in particular to
the TV-Anytime forum. A large part of the work on the Content Referencing specification [3]
was developed and tested in the myTV project and numerous contributions were made to
develop the metadata specifications [4].

The experience and techniques gained in the myTV project may be used as a starting point in
the Share it! project. For example content referencing may be extended to find content
residing on other set-top boxes. Nevertheless the Share it! project differs from myTV
significantly as it is more focussed on broadband interconnections between the boxes and
between boxes and service/content providers.


1.2       Share it!

1.2.1      Aim
Share it! is developing an end-to-end system that enables easy access to personal content
shared between local storage devices in peer-to-peer networks. An important goal is to
contribute to, and promote adherence to standards such as TV-Anytime and DVB. This will
enable interoperability between different content and service providers, and devices made by
different equipment manufacturers. In this way Share it! will contribute to creating the
conditions that allow innovative services that seamlessly combine broadband Internet,
broadcast, and stored content.




                                                12
1.2.2   Scope
The Share it! project enables publishing of a user's content to a limited audience, controlled
by the content creator and owner. This is achieved either by directly granting access rights to
another user, or by establishing a home-to-home connection to enable the transfer of the
content, or by transferring access management control of multiple homes to another trusted
party (e.g. another user or a third party server). In this way a "virtual" network of trusted
homes is established to allow the sharing of content. The concept of a virtual network of
homes can be extended to a network of users forming a community of interest. In all cases,
special attention has to be paid to the privacy and security of users’ data and content, and the
protection of the copyright of downloaded or broadcast materials.

A view of the Share it! system is given in Figure 1.1. It illustrates the main actors present in
the scenarios of use of the overall system.

The most basic scenarios of use of the Share it! system are the following:

    •   An end user grants access to a limited set of his own content to another user of the
        Share it! system, possibly in another home.
    •   Multiple users (homes) connect to each other, creating a virtual community of homes.
    •   Users form groups of users based on their interests.
    •   A user accesses content and networked services provided by broadcasters, service
        providers or third parties.
    •   An end user connects to the system remotely and can view and manipulate stored
        content.



                                          broadcast




                                        broadband
                                        interactive




   my home                                                                a friend’s home


                                           UMTS


Figure 1.1 The Share it! system.

In each of these scenarios the establishment of the connection is based on users’ access and
viewing rights to specific content, which may include (non-copyrighted) audio-visual data,
different sets of metadata and other user-provided data. The scenarios envisage peer-to-peer



                                              13
communication, where of course a central question is user authentication, access rights and
adequate control of the rights of content owners.

In realising the Share it! project

    •     Consumers will benefit from a rich audio-visual experience and may become content
          creators, either by putting audio-visual material up for sharing or by adding context to
          content.
    •     Service providers and broadcasters will benefit from the extended capabilities of a
          system using both on-line, broadcast and locally stored content, enabling them to
          deliver new services, involve their consumers in the actual service creation process
          and enabling their content to be spread using the broadband network.
    •     Network operators, content creators, equipment manufacturers and other players in
          the chain will benefit from the increased demand for their products and services
          generated by the enhanced system capabilities.

1.2.3     Current status
Within the Share it! project we have worked out a number mock-up applications (see
paragraph 4.1) that build on the functionality the system enables. In parallel we have
investigated the technological state-of-the-art and made a number of choices on protocols,
technologies, and designs. This section summarises the current state of the technical work. It
starts with an overview of the process used to come to the main scenarios to be implemented.
More detail on the applications/services chosen to be prototyped can be found in chapter 5.
1.2.3.1    Process: towards main scenarios
While the ‘playing field’ of the Share it! system is quite wide and the number of partners
relatively high, focussing on a limited set of scenarios to prototype is not easy. In WP4 we
chose to follow the following approach:

    1. Widening the view: all partners together think up many example scenarios covering
       a wide range of functionality (chapter 2).

    2. Focussing: each partner chooses a number of concepts to implement as a mock-up
       (chapter 4).

    3. Convergence: the mock-ups of the previous fase converge into a small number of
       main scenarios, each of which is implemented as a prototype (chapter 5).

Direct convergence from the broad range of example scenarios to the main scenarios was
perceived to be problematic, because of the huge range of possible concepts. By using an
intermediate ‘focussing phase’, the partners were forced to try out and experiment with those
concepts they thought to be the most valuable. This phase not only produced interesting
mock-ups, but also helped to inform and educate on the capabilities of the Share it! system.

The main scenarios were chosen under the assumption that at least this collection of
functionality will be demonstrated. Therefore the scenarios together should cover all core
Share it! system functionality. As the definition of ‘core’ depends on the perspective of each
partner (a broadcaster sees different functionality as interesting to a CE manufacturer) the
scenarios divide into different areas of interest and functionality. The reader is referred to
chapter 5 for a more detailed explanation of the scenarios.

1.2.3.2    Outline of system requirements / impacts of technology choices
The system requirements and how we derived them are documented in Deliverable 1 [1].
The consequence of the choices of box architecture is documented in Deliverable 2 [8]. The
whole system design and protocol choices are ongoing work within the project. The current
status is documented in a “living document” that will become Deliverable 5.



                                                14
A summary of the requirements may be arranged into several categories, as shown in table
1.1.

Discovery of devices,     - Devices and users can be identified uniquely, and can be found in the
groups and users in       network.
the p2p network           - Groups of users can be established. There are several sub-types of user
                          groups to support different models. Users can join and leave groups.
Find, select, access,     - Users can search for content using metadata queries. For the purposes
create and reference      of the project we use CRIDs (as defined by TV-Anytime) for referencing
content                   content.
                          - We use TV Anytime metadata where possible.
Transfer          and     - Content is transferred and streamed as MPEG-2 data over the DVB
streaming of content      channel or the IP channel.
                          - Practical limits on the deployment of broadband may limit the user to
                          transfers over IP rather than streaming.
Describe and control      - We are developing a model of content rights to allow a user to see what
rights                    rights he has, what rights are required for a piece of content, etc.
A secure environment      - Users can authenticate themselves, decide what they disclose to third
                          parties, and can control what content they share with whom.
                          - The system is protected by a firewall.

Table 1.1. Summary of Share it! requirements.

1.2.3.3   Technology choices
The basic technologies used in the project are being defined and will be reported on in
Deliverable 5. The following diagram and description highlights some of the key elements.

             In Home Network                           Broadband Network


                                                                    Network
                 DVB                                                Services
 Share-It!
 Box


                                      Gateway                    Broadband
                 DVB                                              Network
 Share-It!
 Box


                                                            Other Share It! Peers


              Metadata             Applications              Security
             Management                                        and
                                                              Rights
                                P2P         Content
                                            Transfer

                               Low Level Networking




Figure 1.2 Simplified Share it! system block model and network context.




                                                  15
Peer-to-peer
Share it! has chosen JXTA as the basic peer-to-peer technology to be used. JXTA is a
framework of a set of standards that support peer-to-peer applications. It provides a flexible
peer-to-peer platform that uses non-proprietary (XML-based) communication protocols and is
network and operating system agnostic. It provides mechanisms to deal with NAT (Network
Address Translation) and firewalls. It provides low-level primitives necessary to build secure
peer-to-peer applications. They act as the building blocks of our secure infrastructure, and
depending on the requirements for the application we can combine these primitives to arrive
at a meaningful secure framework.

Each user of the Share it! system is identified by a unique User ID. Each device has a single
unique peer ID - each device runs a single instance of a JXTA peer. There may be multiple
User IDs active on a device/peer (for example, members of a family), with each user sharing
content item(s) via one or more user groups to which they are members. A Share-it! User
Group is the means by which content can be published and organised to enable sharing.
Groups are flexible (i.e. any user can create a group) and are primarily intended to scope the
nature and range of shared content.

TV-Anytime CRIDs are used as references to content in Share-it! A number of potential
difficulties with the life-cycle of the CRID in a peer-to-peer network have been identified and
the project will explore these issues further.

Content transfer
Share it! will support transfer of content at its original bandwidth, or transcoded to lower
bandwidths. We support MPEG-2 video as the preferred video compression format. Based
on analysis of likely available bandwidths of broadband connections:

•   Streaming of native DV (Digital Video Camcorder) content is not possible in any scenario.
    DV will require transcoding to a lower bit-rate MPEG format.

•   In many cases the broadband network is asymmetrical limiting the upstream bandwidth
    from the home. In practice it may not be possible to stream from one home to another.
    Nevertheless we will support his functionality as it is possible in some cases and within
    the home.

•   Streaming from a VOD server or multicast server downstream to the box is possible in
    many cases.

•   Where streaming is not possible, the project will support file transfer as the practical
    alternative.

Metadata
The Share-it! project will use TV-Anytime metadata as far as possible.

Rights description, management and security
Work on rights management is less advanced. So far we have identified a number of usage
models and two technological approaches: the so-called “light touch model” where the rights
associated with content are distributed along with the content and the system must manage
the enforcement of the rights; and a model that uses a “rights broker” as an intermediary in
transactions.

Security issues are not yet finalised. JXTA is capable of working through properly configured
firewalls. The project is defining and experimenting with what has to be done to ensure
adequate security.

Applications
The Multimedia Home Platform (MHP) defines a generic interface between interactive digital
applications and the terminals on which those applications execute. This interface decouples
different provider's applications from the specific hardware and software details of different


                                              16
MHP terminal implementations. It enables digital content providers to address all types of
terminals ranging from low-end to high-end set top boxes, integrated digital TV sets and
multimedia PCs.

The core of the MHP is based around a platform known as DVB-J. This includes a virtual
machine as defined in the Java Virtual Machine specification from Sun Microsystems. A
number of software packages provide generic application program interfaces (APIs) to a wide
range of features of the platform. MHP applications access the platform only via these
specified APIs. MHP implementations are required to perform a mapping between these
specified APIs and the underlying resources and system software.

The Share it! project has adopted MHP as the application environment. We plan to use a
number of API extensions, such as those previously defined for the storage interface in the
myTV project, and some new ones that will be needed to allow applications a controlled
access to the peer-to-peer network.

Low-level networking
Over the broadband connection Share it! will use IP and the related family of protocols. We
have decided not to use IPsec to protect the connections because of issues with traversing
firewalls and NAT. Instead we will use TLS.

The broadcast interface will be DVB. The most widespread source of DVB signals is DVB
Satellite and this is what we prefer to use as inputs. DVB terrestrial and DVB MPEG-2 TS
inputs will also be provided.




                                             17
2 Applications & services
Although it is difficult to draw hard borders between types of applications/services, we divide
the applications and services being studied in Share it! in three main categories:

      1. Resident applications/resident box functionality
      2. Downloadable applications/services provided by broadcasters
      3. Services provided by third parties

The first category consists of all applications and functionality that basically ‘come with the
box’. All kinds of resident management functions, but also ‘standard’ functionality like the
ability to send content to other boxes is part of this category. The second category consists of
applications and services that are specific for broadcast content providers and typically are
strongly related to the content and branding of its provider. The last category consists of
applications/services that are provided by non-broadcasters, for example a ‘third party
programme review service’. The next paragraphs discuss applications and services for all
categories. It would be a waste of space to repeat detailed usage scenarios here, while they
can be found in [1] and [5]. This chapter therefore focuses on providing context and being
complementary to D1. Related usage scenarios are given in the tables at the end of each
section*. Applications/services chosen as mock-ups will be discussed in more detail.

* The text in these tables are short descriptions of the relevant part of the scenarios. The
paragraphs in the tables refer to [5].


2.1        Resident applications & functionality
The following paragraphs provide an overview of basic functionality that may be provided by
Share it! PDRs. This kind of functionality typically is always there, irrespective of the
service/content provider the user currently is using content from. Two notes are important
here:

      1.       The functionality may also be accessible for downloadable applications or remote
               services, typically by use of the common ‘Share it!’ API.
      2.       Although the functionality is resident, it’s effects may vary with the content it is
               used with. This typically applies to all ‘rights-sensitive’ functions, like copying of
               content for example (also see 3.1.6).


2.1.1       User data collection
Within the Share it! system, it is important to handle and collect user data for each user of the
system. User profiles can be divided from the action of collecting data as suggested by the
following definitions:

User profile: A collection of configuration data, e.g. preferences, application data, history,
security policy, etc., that is bound to a particular user account on a Share it! system.

User data collection: The action of collecting, storing, and reporting data about a user of a
Share it! system, either from automated statistical collection methods, e.g. viewing
preferences, time between channel changes, amount of content shared, etc., or from user
input, e.g. user preferences, user registration info, etc.

The two definitions are related in that at least some of the user data, e.g. user preferences,
would presumably be stored in the user profile. Furthermore, if the collection of data produced
some behaviour on the Share it! device, the rules for that behaviour should be correlated to
the particular user that produced the data, and thus should be stored in the particular user
profile. E.g. "User A likes funny adverts but flips the channel during serious ones, so use
personalised advertisements to only show funny ads to this user. User B, however, doesn't
flip the channel during ads at all, so provide the default set to that user."

                                                  18
This functionality gives numerous possibilities for the user to personalise his viewing, it also
provides possibilities for the content providers and other parties to monitor user behaviour.

Related usage scenarios
§ 2.2.20 Personal TV Channel
§ 2.4.22 Shared profile
§ 2.4.24 Adaptive user profile


2.1.2   Recording, copying and distribution of content
PDRs are extremely well placed to become popular content recording and copying machines.
The Share it! box can be seen as an even more attractive machine, because it also allows for
content to be easily shared with (distributed to) other boxes. Many concepts in the Share it!
project are based on the sharing functionality. Sharing here includes broadcasters sharing
content with box owners, as well as box owners sharing content among each other. For
content one can think of (file) copying, streaming, e-mailing, etc.

Typical material the box should be able to record consists of television content (AV), radio
content (audio only), non-AV data (e.g. teletext/ceefax), enhanced/interactive content (iTV).
The Share it! box should have a scheduler that resolves recording conflicts, problems with
space limitations, and schedule changes. In case of recording conflicts it should look for an
alternative scheduling of the programmes to be recorded in order to satisfy the requests made
by the owner. In case of space limitations it should either solve them or find an alternative for
(temporarily) storing the program by sharing resources with other PDRs or via an NDR where
the user has rented some personal space.

Typical content that can be shared includes both content provided by the broadcaster as well
as content made by the user. This content has to be published, and the owner and/or
publisher of the content can give access rights to specific users or groups of users.

Sharing of content typically relates to accessing or copying content from:

    •   a remote server to the box (e.g. broadcast or community cache server)
    •   a peripheral to the box (e.g. phone, camera, removable storage)
    •   a box to a peripheral (e.g. to removable storage for permanent keeping)
    •   a box to another box (e.g. sharing a home video with friends)

Related usage scenarios
§ 2.2.4   Subscribe, navigate and search groups
§ 2.2.5   Publish own content, create groups
§ 2.2.11 Sending a home video to named devices
§ 2.2.13 Record and send segments to another
§ 2.2.14 Distributing video to named devices
§ 2.2.19 Watch your content on somebody else’s TV
§ 2.2.21 Sharing content with a portable device
§ 2.2.22 Downloading content to personal devices
§ 2.2.25 Inserting media clips into conversations
§ 2.2.28 The easy home page builder
§ 2.2.34 Watch private channel anywhere
§ 2.2.35 Virtual-gathering for a ‘video night’
§ 2.2.37 Adaptive content
§ 2.2.39 Content compositor
§ 2.2.40 Automated downloading
§ 2.2.41 Queue order
§ 2.2.42 Smart delivery of content
§ 2.4.25 Auto content from “friends”-list


                                               19
2.1.3   Editing Content
The possibility of editing content may be very appealing for the user. This could give him the
possibility to add comments to videoclips, merge clips into larger parts, and also create new
personal content on the box.

However, since the box is equipped with limited processing power it would be reasonable to
assume that the editing functionality provided by resident applications is very limited. The
most basic functionality is to be able to download content from a PC (on which it may have
been created and/or edited) or a video camera. Also the file system on the box should make it
possible to publish a collection of clips to a user group. More advanced editing facilities, like
video editing and summaries will only be available on the box if it is capable. As an
alternative, such functionality could be provided as a PC-application.

Other (more basic) functionality that could be supported is the ability to define and edit
playlists of stored content and the ability to add metadata to stored content.

Related usage scenarios
§ 2.2.13 Record and send segments to another
§ 2.2.38 Programme indexing
§ 2.2.39 Content compositor


2.1.4   Telecom related applications
The Share it! box is well placed to become the ‘VCR of tomorrow’, which means it will
probably be located in a prominent place in the living room. Because of its communicating
capabilities and audio-visual interface, telecom and network applications may be part of the
system’s resident functionality. This may include:

    •   Chat services
    •   One to one Videophone
    •   Teleconferencing Videophone
    •   Advanced Videophone functions like ‘voice recognition and live subtitling’
    •   Distributed game playing

These kinds of scenarios have fascinated the human mind for a number of years and the
ideas keep popping up at various instances. Advances in telecommunications technology are
finally making the services accessible to the consumers (at least in theory). In the following
the above-mentioned ideas and related implementation-requirements will be described in
more detail. Most of the services discussed here belong to telecommunications operators’
core-competence areas and as such certainly affect how business is conducted. From the
competitive standpoint it would also be valuable to have as much of the basic services
standardised as possible. Even though a proprietary system can in a short term provide the
best terms, only head to head competition with open standards lowers the risk involved.

Chat
Popular Internet services include services like on-line chatting and virtual communities as well
as web boards. These services are used for pleasure and entertainment as well as for
education and business. The Share it! network capable set-top boxes enable these services
and they can easily be used from any device connected to the system. The chat can be peer-
to-peer or provided by a third party.




                                               20
Chatting can be made content dependent or as featured services in some portal or together
with some other service. The content related chats are related to programmes and available
only when the programme in question is being broadcast. The portal services include chats
just like many portals do today. The Share it! system also allows audio-visual content and
data to be included in the chats and shared between the users.

Subscription data monitoring
When using the Share it! system network interface it is crucial to be able to monitor the costs
the system usage’ results in. The box should be able to connect to the network provider to be
able to monitor his/her subscription and the fees related to it. This monitoring can also include
other monitoring like cell phone subscriptions, making new subscriptions (faster access) and
traffic monitoring. This might be even more crucial if the box functionality includes Voice over
IP (VoIP) and tele-/videoconferencing, which may be expected to be provided as ‘standard’
telecommunication services.

Note: The functionality so far has not included VoIP, only tele- and videoconferencing.

Videophone, teleconferencing and other telephony related applications
Telecom operators may offer basic videophone and teleconferencing services on the Share it!
System since the system has extensive communicating capabilities and an audiovisual
interface. It is possible to record audio and video messages on the box and to either share
them from the device or to send them directly to other people. Similarly it will be possible to
arrange teleconferencing sessions between the Share it! users to make virtual meetings
possible. These are basic telecom services, which could easily be implemented in the system.
Since the Share it! box is already connected to a network, the users can also start using VoIP
services from their devices.

Distributed game playing
The gaming business has been one of the biggest success stories of recent years. The
instant gratification brought by rapid point-and-shoot games, but also the slower paced
strategy games have proven to be strong formulas, especially in the younger consumer
segments. Inside the gaming business different hardware platforms have battled with content
much like the distribution chains in video content business. In this time of convergence these
two separated entertainment business areas are approaching each other. The likely outcome
of this development is that different concepts will melt together to form new forms of
enhanced content. As an example one could think of game-show concepts and formats from
the video side, into which interactive games can be easily incorporated. Of course more
adventurous ideas will surely be introduced once the development work starts to be done in
unison.

From the network operator perspective the ability to play truly interactive games is the most
important aspect. Games can be played against peers in distributed service manner for which
telecommunications operator can sell the infrastructure. Networked games like ‘Quake’ and
‘Unreal Tournament’ have found many friends and fans. To cater for these user needs the
system should have basic 3D API’s implemented, while those are required for application
development. To keep the gaming experience in the same spirit as the rest of the Share it!
system features such as sharing of games and sharing of different maps and levels should
also be implemented. If betting and transaction services can be offered, even more revenue
can be generated. Thus the Share it! system should be able to provide the required security
features for the service providers.

Related usage scenarios
§ 2.2.7   Live group chats
§ 2.2.18 Distributed game playing
§ 2.2.35 Virtual-gathering for a ‘video night’
§ 2.4.26 Multimedia messaging between users
§ 2.4.27 Game sharing experience
§ 2.4.28 Video answering machine




                                               21
2.1.5   Remote control
A remote control is virtually standard with all kinds of modern consumer equipment. Because
of its networking capabilities the Share it! device’s remote control may be extended to other
forms of remote control, including:

    •   a WAP enabled mobile phone
    •   a WEB browser on a Internet-enabled device (this typically would be a PC)
    •   another Share it! device.

Remote control of the Share it! device.
The user can have the ability to control his/her Share it! device remotely, via an Internet
connected PC with a web browser or a via a WAP phone (figure 2.1). When a user remotely
connects to his/her Share it! device he/she is provided with basic remote control of PDR like
functionality:

    •   browse an EPG
    •   mark content for recording
    •   browse recorded content (e.g. movies, music, pictures)
    •   delete content etc.

Other functionality that could be remotely available is more related to sharing content:

    •   create new user groups
    •   add/delete persons to a group
    •   publish content

                                                    Home network
 Web browser        WAP phone
                                                    ShareIt! - Box
                                                      HTTP server




                                                      Gateway
                               WAP

                          WAP
                          gateway    HTTP

                          HTTP

Figure 2.1 Remote control of the Share it! box: the gateway may or may not be part of the
           box.

Remote control from the Share it! device
The user has the ability to login from any Share it! device to his/her own Share it! device.
When logged in, the user can copy/view content from his/her device to the device where
logged in from. This enables the user to share content without publishing it.

Related usage scenarios
§ 2.2.23 Mobile phone browsing
§ 2.2.32 Remote access of the Share it! box
§ 2.2.33 Remote usage and control of PVR
§ 2.2.34 Watch private channel anywhere
§ 2.2.35 Virtual-gathering for a ‘video night’
§ 2.4.29 Home control center


                                               22
2.1.6   Rights management & protection, system security
Of all functionality, rights management and enforcement is probably one of the most
important. The rights management enforcement part of the device is responsible for enabling
and enforcing the business models of the service providers. Although rights management
typically involves multiple players in the digital value chain, ultimately the CE device is the one
that has to enforce the protection. Virtually all scenarios that relate to the sharing of content
assume the presence of a Rights Management and Protection (RMP) solution in the box.
Without it, many content providers simply will not be willing to provide content to the boxes.

When considering RMP systems, two different RMP systems can be distinguished. RMP
systems responsible for implementing and enforcing the business models of the service
provider are Conditional Access systems. This category also includes RMP systems
protecting free-to-air broadcast although in this case a more standardised solution may be
required. Other RMP systems are responsible for enforcement of usage rules and copy
protection. Typical examples of such RMP systems are systems implemented on physical
media like DVDs. Such systems are called Copy Protection systems. Content typically flows
from Conditional Access systems to Copy Protection systems.

Related to Copy Protection systems, the concept of an authorised domain is used. The
authorised domain represents a secure environment in which content can reside. An
authorised domain can consist of one or more devices. Within the domain the content can be
accessed within the boundaries of the usage rules associated with the content. Copy
restrictions apply when the content leaves the authorised domain. In order to ensure the
protection of the content within the domain, the content will be probably be encrypted. This
would require that all devices handling the content provide decryption and in some cases
encryption functionality.

Regarding content operations the following set of RMP related activities are defined:

    •   Receiving content
    •   Accessing content
    •   Distributing content

Receiving content deals with the process of importing content into the authorised domain. In
this process, the rules related to the content in the domain are defined. Content can be
imported into the authorised domain when received in the home network or stored under
control of the original conditional access system. The import in the authorised domain takes
place when the user accesses the content.

Accessing content deals with all operations on the content while it resides in the authorised
domain. Examples of actions related to accessing content are storage, viewing, processing
(e.g. bitrate and content format changes), deleting and editing. Typically, each of these
actions involves the RMP system.

Content distribution deals with moving or copying content from one authorised domain to
another (within the same home and between homes). Depending on the rights associated
with the content this may involve a third party.

When receiving, accessing or distributing content, the RMP system may require processing of
content and/or communication with the user. The security aspects discussed above mostly
relate to the protection of content rights. Another security topic relates to system security. This
involves processes to ensure protection of user data (privacy) and the integrity of the system.
Within the Share it! project we will focus on the DRM aspects of security.

Related usage scenarios
§ 2.1.4   Broadcaster rights protection
§ 2.2.21 NDR Content management tool
§ 2.2.36 Identification
§ 2.2.44 Threat from hackers, viruses etc.

                                                23
2.1.7   User Profile Management
Since any given Share it! device may be used in a multi-user setting, e.g. a family or a group
of roommates, each device should have the ability to support multiple user profiles. User
profiles should include the following features:

•   Individual content preferences, e.g. the EPG displays news and football listings at the top
    of Mom and Dad's profile, but music and nature programs at the top of the teenage son's
    profile.
•   Content consumption rules, e.g. the kids' profile will not display content that is marked as
    "for mature audiences only", nor will it display listings for such content in the EPG. This
    should be true regardless of the content's location: broadcast, streamed over IP, or local.
•   Application preferences (for resident and downloadable applications), e.g. the EPG uses
    different skins for each user, key clicks are turned on for user A and off for user B.
•   History information, e.g. what content has been viewed, what applications have been
    used
•   Security policy, e.g. Mom & Dad can alter content permissions & content consumption
    rules, change passwords, add users, etc., but the kids cannot.
•   Key database, each user should have a separate store of keys associated with particular
    services that the user is registered with.
•   Community membership information, each user may belong to a separate set of Share it!
    communities, therefore queries for content will be run against different communities
    depending on which user is running the query

Moreover, the system should provide some easy facility for identifying which profile is in use
at a given time. Each system should start with a default user and profile already set up, so no
user configuration is required. Profiles should also be extensible, allowing the addition of
profile-specific features via additional services and applications. Possible additional profile-
specific features are:

•   Storage quotas, each user is only allowed to store a certain amount of content locally
•   Sharing/service limitations, e.g. Mom & Dad can share whatever they want, but the kids
    are only allowed to share up to 50 MB of audio files, no video, no streaming
•   Bandwidth dedication (Quality of Service - QOS), e.g. user A gets all the available
    bandwidth for downloading and receiving streams unless user B needs bandwidth, in
    which case A gets 25% and B gets 75%

Related usage scenarios
§ 2.2.20 Personal TV Channel
§ 2.2.29 Personal content guide & navigator
§ 2.4.15 Audience research
§ 2.4.23 Automated ratings system
§ 2.4.24 Adaptive user profile




                                              24
2.2       Downloadable applications & services
This paragraph focuses on applications and services provided by broadcasters. Broadcasters
play a special role because they mostly are the content providers, have built up a strong
brand and have access to a very efficient mechanism to provide all boxes with bandwidth-
demanding AV-material: broadcasting. The following applications can be used with a Share it!
box.


2.2.1      Contributing AV to the broadcaster
When the Share it! device has access to a broad return channel, that may be used to provide
audiovisual content to the broadcaster. Examples are:

      •    Participation in TV-programmes (e.g. using a webcam)
               o Live
               o Non live
      •    Uploading of home-made footage
               o real-time
               o non real-time

An important role of the broadcaster is to moderate the incoming content, creating an overall
style and quality programme and at the same time allowing individual Share it! users to reach
the maximum available public.

Related usage scenarios
§ 2.2.19 Uploading of images
§ 2.4.1   Contributing video to a live TV programme
§ 2.4.8   Moderated ‘talented musicians’ programme
§ 2.4.32 Game-show with in-home participants taking part in the show
§ 2.4.35 Home-made holiday-videos competing in a TV-contest
§ 2.4.36 Chat allowing related content to be uploaded to the broadcaster
§ 2.4.37 Contributing home-edited assignments in a game-show


2.2.2      Contributing data to the broadcaster
A simpler form of contributions may be in the form of contributing data to the broadcaster
using the return channel. Examples include:

      •    Voting
      •    Contributing viewing statistics (also see 2.1.1)
      •    Moderated chat (non-AV)
      •    Game-shows

Note that although gathering viewing statistics can be a basic functionality of the box,
broadcasters may decide they want to gather other data from the users in a more direct form,
for example programme appreciation ratings.

Related usage scenarios
§ 2.4.5   Charity donations provided over the return channel
§ 2.4.6   Voting of your pop idol
§ 2.4.12 ‘Pump or Dump’, about direct feedback on radio playlist
§ 2.4.14 Chat with the makers of ‘Walking With Beasts’
§ 2.4.15 Audience research
§ 2.4.32 Game-show with in-home participants taking part in the show
§ 2.4.33 Game-show with option to earn tokens by answering questions correctly
§ 2.4.34 Informative political referendum using @home voting via the Share it! device
§ 2.4.36 Chat with the royal family


                                                  25
2.2.3   Providing extra AV-material via broadband
Using the broadband connection to the Share it! box, broadcasters basically have another
means to reach their audience. This typically may be interesting to provide access to content
that is not likely to be of interest for the whole audience. Examples are:

    •   Providing extra programme material for interest groups (e.g. paid for service)
    •   Sending extra teasers/promos
    •   Allowing users to access part of the broadcasters’ vast AV-archives

Related usage scenarios
§ 2.4.2   Extra material provided for an educational service
§ 2.4.4   An ‘extra material’ news programme
§ 2.4.7   The ‘making of’ Eastenders live
§ 2.4.13 In-depth stories via broadband
§ 2.4.16 Video encyclopaedia
§ 2.4.17 Access to archive
§ 2.4.38 Personalised sports programme


2.2.4   Use of local storage
Combining the above delivery method with local storage, the broadcaster may choose to
enrich its programming by integrating/linking content already stored on the Share it! device.
Also the broadcaster may provide additional data, classifying the broadcast/broadband
content, which (depending on the user-profile) may lead to it being recorded.

    •   Making use of earlier/extra broadcast programmes
    •   Provision of classification data to allow personalisation of (parts of) content

Note that although profiling typically would be resident functionality, broadcasters may choose
to provide their own ‘programme classifications’ and/or profiling applications (also see
paragraph 3.1.1).

Related usage scenarios
§ 2.4.11 ‘Download-a-DJ’
§ 2.4.13 ‘Pick of the Week’
§ 2.4.14 Enhanced Interactive TV, using locally stored content
§ 2.4.32 Game-show with option to practice using recorded episodes


2.2.5   Superdistribution
Networked Share it! devices may be used to distribute broadcast programmes to other box
who chose not to record it. This is called ‘superdistribution’. Broadcasters may decide to
encourage this form of distribution as it may increase the number of times the content is
viewed*.

Related usage scenarios
§ 2.4.18 Rewards for passing content

* Note that security measures must be in place to prevent illegal superdistribution of content.

2.2.6   Community building
Programmes attract people with similar interests, thus providing an ideal starting point to build
communities around. Broadcasters may choose to build communities around the programmes
they broadcast, possibly rewarding the community members with ‘first off’ content.



                                               26
Other uses of ‘communities’ include competitive scenarios where you can compete with other
Share it! device owners.

Related usage scenarios
§ 2.4.10 Targeted programming
§ 2.4.32 Game-show with competition amongst Share it! box owners
§ 2.4.33 Game-show with option to exchange tokens amongst collectors
§ 2.4.35 People with the same holiday-interests setting up communities
§ 2.4.39 Sharing of home-recorded recipes


2.2.7      Brand strengthening
Other ways of strengthening the broadcasters’ brand may be:

      •    Reward schemes for loyal viewers
      •    Provision of ‘broadcaster recommendations’ (‘virtual channel’)
      •    Local/regional branding of ‘brandless’ content

Related usage scenarios
§ 2.4.7   Eastenders reward tickets
§ 2.4.9   Broadcaster recommendations
§ 2.4.19 See one episode, buy the series
§ 2.4.21 The ‘brandless’ music channel


2.3       Third party services
Convergence of DVB and Internet offers new opportunities for distribution of TV-like
audiovisual content and data about the content. In the case of a limited-bandwidth back
channel, Internet-like portals can gather metadata, content resolution and schedule
information from different broadcasters and make them available to consumers in an
interactive way, which enables searching for required information and personalisation of the
service. The benefit of such third party services is that data from different broadcasters is
collected at one place and that metadata can be further enhanced with additional information,
like reviews, descriptions, etc, from independent organisations. However, if broadband
connections are available to consumers’ homes, the third parties can also offer audiovisual
content, such as video on demand, in different qualities depending on available bandwidth of
the channel. The audiovisual content may include movies, pre-recorded TV programmes or
segments of the programmes, educational material, advertising, video clips, etc.


2.3.1      Portals providing new content
When Share it! boxes are widely adopted by consumers and broadband connections to the
consumers’ homes are available, Internet-like portals may appear, but with more focus on
easy to use, TV-like audiovisual content. In general, a third party portal is any Internet-like
portal with audiovisual content and data about TV programmes according to TV Anytime open
standards. Typically, independent Internet organisations will set up the TV-Anytime Internet
portals. However, broadcasters can also have their own Internet sites with ‘third party’
functionality to better serve their viewers. The third party portals can operate in classical client
– server networks or in peer-to-peer networks, where the third party can be a peer of one or
more interest user group. In this way, the third parties can make their services and content
available to the consumers according their interests and the consumers can easily find the
service, data or content they are interested in.




                                                 27
Businesses advertising goods/service to the consumer directly

Third parties may offer video advertising in the form of video clips on their Internet portals,
which can be further enhanced with additional textual data used by MHP applications. By
joining appropriate peer-to-peer groups, the third parties can advertise their services directly
to the interesting consumers, who can download the advertising content from the third party
portals. To make video advertising services attractive to consumers, special discounts can be
offered if the product is ordered through the Internet portal. Consumers who frequently pay for
goods and services bought through the third party portal or allow third parties to push video
advertisements on to their Share it! boxes can get additional discounts or some other
benefits.

Video advertising on third party portals is useful for consumers because they can ask (search)
for advertisements when they need them, while otherwise they are not hindered. On the other
hand, video advertisements on the Internet portal can be longer with more information than
the usual ones included in TV programmes. By implementing advertisements as MHP
applications, they can be interactive with possibilities to order and pay goods or services while
watching the advertisements in a very simple way.

Community service organisations

Community organisations or other Internet organisations operating on the behalf of the
community organisations can set up Internet portals exploring the possibilities of the Share it!
system for providing public services for local citizens. Such Internet portals will create and
manage user groups for the local population in a peer-to-peer network. Citizens will find all
kinds of useful information on such portals, prepared by legal community organisations as
well as information and audiovisual and textual content posted by citizens themselves. The
citizens will have the chance to ask questions or express their opinion about public matters,
so the Internet portal will be their notice board. In the case of any important matter, the
information or content could be pushed on their Share it! systems to remind them.

Educational organisations

Educational organisations can use the concept of the Share it! system to set up Internet
portals with educational audiovisual content and to create peer-to-peer user groups for their
students. The content on the portals will include core materials like video lectures as well as
extra educational material prepared from other sources, for example segments from
educational TV programmes or video clips prepared by lecturers or students themselves. By
joining the educational peer-to-peer group, the students can additionally have access to the
educational content on the Internet portal, communicate with lecturers and other students,
and exchange their own educational materials with them.

Independent media organisations

Independent media organisations will have the possibility to create and manage their own
peer-to-peer groups, where they can comment on actual political and economical events and
situations in an independent way. They can gather different opinions and comments about the
same issues that citizens talk about. Such portals can also select and make available video
content about actual events that weren’t shown by other less independent TV channels. The
concept of peer-to-peer groups will enable consumers to be actively involved in commenting
on actual events by posting their opinions on the portal or by making them available on their
Share it! systems. The media organisation managing the peer-to-peer group may collect
opinions from consumers about the issues and send the report to responsible politicians or
organisations.




                                               28
Related usage scenarios
§ 2.2.6   Special interest group
§ 2.2.11 Showing your home video to other named devices
§ 2.3.4   What’s on at the cinema?
§ 2.3.6   Video lectures and extra material
§ 2.3.8   Independent organisations providing footage & annotations
§ 2.3.9   Community noticeboard
§ 2.3.12 Internet Movie/CD database autoget and autoupdate
§ 2.3.14 Happycar
§ 2.4.4   An ‘extra material’ news programme


2.3.2   Gathering and moderation services
Third parties may decide not to publish new content themselves, but to review content
created by others. They may provide links to the original content and thus form attractive
‘starting places’ for consumers looking for specific content.

Third party broadcast programme review services

On Internet portals third parties can offer broadcast programme review services with reviews,
ratings and additional descriptions from different sources. Third parties can gather information
like descriptive metadata, location resolution and scheduling from different broadcasters in
one place and enhance the collected data with additional independent information.
Consumers could freely access data from the third party portals or they could subscribe to the
service. In the latter case, a better service with the personalisation possibilities is available.
The consumers can specify their profiles and the server would automatically select
appropriate information according to the profile. Such functionality has already been
implemented during the myTV project. However, the Share it! concept exploiting opportunities
of peer-to-peer networks will extend the functionality of the service. The third parties can
address more focused interest groups of consumers by joining (or creating) one or more peer-
to-peer user groups and by advertising their services inside these groups. On the other side,
the consumers can search for the required information inside the entire peer-to-peer group
and not only on the third party portals. In this way, the consumers can get the
recommendations and comments about TV programmes from other consumers and not only
from third parties.

Community ‘newsgroups’, linking (possibly moderated) consumer content

Many consumers will have their own content or video clips with their comments and
explanations created from freely available commercial content that they want to share with
other consumers. However, they will probably not have enough knowledge, time and
equipment to create their own portals. In that case, the third parties can create such Internet
portals where the consumers can post their content. The third parties will moderate
community ‘newsgroup’ organized as peer-to-peer user groups. Interesting content can be
further processed by the third party and put on its portal, while for less useful content only
links to the owner’s Share it! device can be available from the portal. In case that any content
made available by members of the peer-to-peer group were offensive or even illegal, the third
party could eliminate such member from the group and take legal action if required.




                                               29
Community chat services

Third parties can create peer-to-peer user groups and offer chat services to the group
members. In addition to the existing textual and video chat services available on computers,
the consumers can share audiovisual content and data (segmentation metadata) between
themselves. The chat service can be performed directly between the consumers without any
involvement of the third party or it could be moderated by the third party. In any case, some
information like a list of the participating consumers should always be available on-line on the
third party portal. The third party can additionally enhance the chat service by offering an
exchange server on its portal. The exchange server can be used for exchanging of
audiovisual content and other data between the consumers during the chat. In this way, the
chat service becomes collaborative. By using the same technology, the third party can offer
                                                           rd
online video games to the consumers. In that case, the 3 -party portal will act as a video and
game server in the peer-to-peer network.

Related usage scenarios
§ 2.2.6   Special interest group
§ 2.2.11 Showing your home video to other named devices
§ 2.3.1   Service discovery and subscription
§ 2.3.2   Publishing a hobbyist’s films
§ 2.3.3   Holiday promos
§ 2.3.5   Video newsgroups
§ 2.3.7   Ranting service
§ 2.3.10 Collation and distribution of programme segments
§ 2.3.11 Content aggregation
§ 2.4.22 Shared profile
§ 2.4.32 Game-show with option to set-up third party token exchange server


2.3.3   Trusted third party
For commercial transactions, a trusted third party may be the desired party to work with, as it
can be independent of the other parties involved in the transaction.

Third party payment services

Third parties can be divided into two main groups. One group consists of freely accessed
Internet portals, while the other group consists of Internet portals available only to members,
who should subscribe and pay the membership fee. Freely accessed third party portals are
available to all but they are insecure and they are not trusted. On the other hand, trusted third
parties are secure and only members can access them in secure way. If the consumers
should pay the trusted third parties for services and content from the Internet portals, the
communications between the third party servers and consumers’ Share it! devices should be
secure. Secure communications are important not only for transactions but also for transfer of
the content in order to protect the integrity and ownership of the content. The consumers can
securely download protected content from the trusted third party to their Share it! devices but
they cannot watch it until they pay the required fee to the third party using a secure back
channel.

Related usage scenarios
§ 2.1.3   Passing content rights
§ 2.3.1   Service discovery and subscription in the Share it! system
§ 2.3.15 The hobby channel




                                               30
3 Business aspects
3.1     CE manufacturer

3.1.1    Benefits

Promotion of horizontal markets
By utilising open standards for broadcast (such as those defined by DVB and TV-Anytime)
and for the transfer of content across a network a horizontal market is promoted. A horizontal
market allows a PVR to be used to obtain any free-to-air content or services without need for
business agreements between the CE manufacturer and the content provider. The result is
that CE manufacturers can compete directly with each other in terms of the feature sets and
price of their PVRs. This contrasts with the vertical market model, where the selling feature is
mainly the range of content offered by the service provider and there is little scope for adding
value to the feature set of the PVR. In other words, the horizontal market allows CE
manufacturers to sell their devices directly to the consumer rather than to the service
provider, with the potential for greater profit margins.

Enhanced feature sets
The Share it! project will provide a number of new ways to access content and services and
will enable interesting new applications. These services and applications have already been
described earlier in this document. From a CE manufacturer's point of view the novel
applications and features will directly add value for the user and enhance the product in the
market place.

Service opportunities
A Share it! device will make use of network services and many of these could be provided by
the CE manufacturer. For example, the manufacturer might offer a metadata service (as is
done by TiVo) or provide enhanced TV-Anytime services that make the product more
competitive. The network connection offers the opportunity to learn more about the user and
promote products from the same manufacturer.


3.1.2    Drawbacks/dangers

Increased complexity
The range of functionalities offered by Share it! means that the device will become more
complex and confusing for the end user, and this will demand the design of much better user
interfaces. The danger is that the added complexity will put off users from adopting the
technology.

Vulnerable to attacks
A network-connected device is vulnerable to attacks from hackers and malicious users. For
example, the user's privacy or a financial transaction might be compromised, or the PVR
could be made to crash. The CE manufacturer must prevent this since it is likely that the
consumer will hold the manufacturer responsible.

Illegal use of content
Although the Share it! project intends to prevent the possibility, there is a danger that a Share
it! device could be used for illegal purposes, such as pirating, infringing copyright or releasing
private information. The legal liability of the CE manufacturer in such cases is not yet clear.




                                               31
Cost of network access
The cost of accessing a broadband network from the home could be prohibitively expensive.
This will directly increase the cost of obtaining content via a network, possibly to such an
extent that it cannot realistically compete with content obtained via traditional broadcast.
Thus, the CE manufacturer might end up adding functionality not wanted by the user.


3.1.3     Related requirements
The promotion of horizontal markets concerns the adoption of open standards by the box
manufacturers and service providers. Open standards are an implicit part of the project and
are not expressed as requirements in [1]. The enhancement of the PVR's feature set is
related to many of the requirements in [1] (i.e. those in sections 5.1, 7.1, 10, 11 and 12).

Some of the requirements should also help reduce the risks of the various dangers that a
Share it! system might pose to CE manufacturers. For example, the increased user
complexity must be countered by the design of a good user interface (requirement 5.1.8 in
[1]), easy configurability (requirement 5.1.3), and the careful use of personalisation (section
12). The vulnerability to attacks must be prevented by appropriate security measures (section
8.1). Finally, the illegal use of content will be prevented (or at least significantly reduced) by
the various rights management solutions for protecting content (section 9.2).


3.2     Network provider

3.2.1     Benefits

Providing a better service
A customer-oriented view is a good starting point for attempting to understand the creation of
competitive advantages in the network provisioning business. Network providers want to
create the largest possible amount of value to their customers, i.e. to provide the best
possible service. When taking full advantage of a Share it! system, consumers are bound to
require assistance in navigation and data storage. Thus directory services such as TVA-
metadata and JXTA rendezvous servers should be provided to improve accessibility. Wide
availability of Share it! client systems could also open up an attractive market for
personalisation and network storage services, which a network operator can handle.

It is important to remember that network operators cater also for the professional market. It
will be in service operators' interests to make their partners' content services as accessible as
if they would be transmitted through television broadcasts. Network operators are well
positioned for also offering billing and transaction services. Telecommunication companies
can operate between third party service providers and consumers by lowering risks on both
sides.

Drive up the need for broadband networks
To make more money network providers need to find practical new ways to encourage the
use of higher valued or wider bandwidth communication services. Video-sharing utilities and
systems like Share it! can boost bandwidth usage and demand. This is of course the most
obvious benefit for network providers. To be able to share multimedia content broadband
networks are needed. Availability of attractive content for end-users can drive up the number
of broadband customers.

Room for network based services
The Share it! system can contain network based services. There are several services that can
be implemented (including payable services). From these two areas can be distinguished:

      1. Content storage in the network, which allows possibilities to extend the storage
         capabilities of end-user PDRs or can be used to provide content that is only offered
         via these network servers. This in fact means that it adds a new content delivery
         medium, in addition to traditional broadcast. It can also function as a "cache" in the
         network for end-users to be able to use the storage space provided by the network


                                               32
       operator. When implementing this kind of network cache, anonymity must of course
       be granted.
    2. Search, find and other ‘database’ services, which help the end-user, or the PDR of
       the end-user, to find and retrieve the right content. Personalisation services and
       intelligent agents in the network or downloadable profiles (branding) can also be
       implemented.

Offering new quality of service classes
Even if the end-user has a broadband network like ADSL or VDSL the bandwidth is limited.
And especially in a sharing situation where two end-users share content the ‘weakest link’
(e.g. the ADSL uplink) defines the time taken to transfer the content. Therefore Quality of
Service (QoS) can be important. Some examples:

    1. Management of the access link (end-users home to the first node in the network) so
       that priorities can be set for different types of traffic (e.g. Sharing content v.s.
       downloading from an FTP site)

    2. Accurate prediction (and management) of the time it takes to retrieve a specific part
       of content from someone’s PDR.


3.2.2   Drawbacks/dangers

Unexpected, not yet modelled generation of traffic
Just as in the early stages of Internet, when the “pipelines” filled up unexpectedly with all
kinds of IP traffic, something similar may happen when broadband networks are going to be
used for the exchange of large amounts of multimedia content (especially if the content is
real-time by nature). We foresee the following potential threats when many people start
down/uploading content simultaneously:

    1. The amount of traffic may cause the network (access and/or core) to be blocked.

    2. Traffic concentration in the current architecture of access network, DSLAMs etc., may
       not allow more than a certain amount of simultaneous connections or Mbit/s.

Asymmetric nature of first stage broadband networks
The first broadband networks that are being deployed by operators typically use ADSL
technology in the access network. For ADSL the downstream capacity is larger than the
upstream capacity (e.g. 512 vs 64 kbit/s, or 1024 vs 256 kbit/s). For peer-to-peer exchange of
large amounts of content this is less suitable, since the upstream capacity determines the
speed a PDR can “send” content to another PDR.

This means that consumers may experience performance problems in their “multimedia
content exchange service” especially when transferring content to others. (This can be
partially solved, however, by using content caches in the network.)

Can the new quality of service factors be managed?
The introduction of peer-to-peer multimedia content exchange using consumer devices (such
as PDRs) may also call for new quality of service parameters, such as “expected delivery
time”. Consumers may not be interested in obtaining a certain piece of content (e.g. a movie)
if it takes too long to get it (e.g. if they can’t watch it tonight). For the network operator it will
be a challenge (not to say difficult) to make sure that such new QoS parameters become
controllable and predictable, so that they match the user’s idea of quality.

Interference with other broadband traffic
The broadband access channel will be shared between many multimedia devices, which exist
in a home. If these devices, e.g. powerful PCs, put large demand on the network capabilities
(e.g. long FTP up/download of software) this will leave less room for the PDR to up/download
content. It is not clear which traffic must be given priority and who should decide this.



                                                 33
IPR and other content related issues
If the exchanged content on the network is pirated or illegal it may hurt network providers’
image. Network operators have to at least take nominal action and issue guidelines of
misconduct for the network storage services.


3.2.3      Related requirements
Most important to the network provider are the requirements that have to do with the content
distribution in his network (see [1], chapter 7). Requirements on transmission (real-time?,
push?, pull?, multicast?) and storage (in the network?, if so where?) will strongly influence the
network architecture needed to transport and deliver content with an acceptable end-user
perceived QoS. Requirements on content formats (see [1], chapter 6) and transcoding are
also relevant here, since they influence network implementations e.g. with respect to
bandwidth.

The interface through which the Share it! box connects to the network (section 5.1.9) is
important: the choice made should be in line with the developments in the field of broadband
connections to the network (e.g. xDSL modems).

If non-authorised persons can access the Share it! box too easily, this will also damage the
image of the network operator, especially if he also operates as an ISP. Therefore the
security aspects of the connection to the Share it! box are important ([1], chapter 8). The
implementation of remote management ([1], section 5.1.6) plays a role, especially if the box
also acts as an access point to the home ([1], section 8.1.7).

The image of the operator may also be damaged if illegal exchange of content is possible too
easily through the operator’s network. A reasonable number of the rights management
requirements ([1], section 9.2) should therefore be fulfilled.


3.3       Broadcaster

3.3.1      Benefits

Reaching a larger audience
Broadcasters have as a primary goal to attract as many viewers as possible. This is true for
both commercial broadcasters and often also for public broadcasters. The former are solely
dependent on the amount of advertisement payments coming in (which directly depends on
the number of viewers), while the latter have an official obligation to serve the public with a
diverse and mostly informative collection of content and services. However, the need to do
this as efficiently as possible in practice also often translates into trying to address the largest
possible audience. This is particularly true when public broadcasters are partly paid by
commercials also*.

The Share it! type of box may lead to a situation where the broadcaster’s content is viewed
more than in a broadcast-only situation, because:

      •    it is largely viewing-time independent (time shifting)
      •    it offers various ways of retrieving content that has not been recorded during
           broadcast (superdistribution, broadband servers)
      •    it offers new ways to refer to upcoming/available content (e.g. programme-linked
           trailers, group-recordings, etc.)
      •    content can be made more attractive/’involving’, so that it keeps viewers attracted for
           longer periods of time**

* This indirectly is the case in The Netherlands for example.
** Examples include using competitive elements amongst people (“I like the show more if I
can compete with known relatives”) and offering more (contextual) information/material to
choose from.

                                                  34
Accurate viewing statistics
Current day viewing statistics gathering is done in small reference groups. If Share it! type
boxes become widespread, the gathering of viewing statistics can be done automatically and
much more accurately.

New services
The seamless integration of broadcast, stored and broadband content allows the broadcaster
to provide a much richer experience for the viewer. This allows the user to take advantage of
all the material they have available associated with a particular programme, e.g. archive
footage, textual information or still images such as maps. By allowing access to peer-to-peer
services, such as groups and direct communication, the broadcaster can also participate in,
and lead the development of, richer services surrounding their content. With the addition of
downloadable applications, the broadcaster can provide a desirable portal to their services.

Low threshold viewer feedback
For certain programmes (e.g. discussion programmes, voting) viewer feedback is an integral
part of the format. A PDR with a return-channel offers a low threshold means to communicate
back to the broadcaster, which could be used in creating the programme.


3.3.2   Drawbacks/dangers

Reaching a smaller audience
The Share it! box basically opens up the living room for more providers than in the broadcast-
only situation. This means the user may receive more content that can be watched than he
does today. Unless the user starts watching more tv, this most likely leads to a broadcaster’s
content being watched less then before... Which in turn may lead to less quality content being
produced, etc., etc.

Illegal use of content
A Share it! type of box offers nearly endless opportunities to rearrange and share content.
Unless a proper rights management and security enforcement system is in place, this may
easily lead to the infringement of content rights and possibly even forged content, which could
hurt the broadcasters’ image and status, and damage relationships with content owners.

Fragmented programme viewing
Almost any harddisk-based recorder offers the opportunity to skip parts of programmes (e.g.
commercials). From the user’s perspective this may be a good thing, but from (especially
commercial) broadcasters the perception is different. Two solutions are typically mentioned
for this problem:

        1.      Secure systems that prevent commercials from being skipped
        2.      Find alternatives for current-day commercials

The former ‘solution’ in practice frequently turns out to be non-existent (e.g. [2]) or poorly
implemented*. The second is ‘in development’ and it is much too early to see whether the
industry is succeeding in finding realistic alternatives. If those are not found, the situation
could result in an abundance of CA-systems being used for all ‘common’ channels, probably
resulting in higher priced TV-watching for the end-user...

As the Share it! project is concerned, the project has not decided in favour of any of the two
‘solutions’.

* Think of the DVD-region situation and/or the current debates on the CD-protection
mechanisms.

Yet another platform to author for
For broadcaster this may be seen as another platform for which they have to supply a portal
to their services and content, in addition to web pages, WAP interfaces, SMS services, i-
mode phones, etc. While storing content in platform independent description formats like XML

                                              35
might help, they also carry the risk of providing services on a ‘lowest common denominator’ of
all platforms and of not using the specific features of the Share it! platform, which made it
attractive to viewers in the first place.


3.3.3      Related requirements
Basically all requirements that have to do with content rights protection and functionality that
prevents illegal recording, copying, etc. of content, are of high relevance to broadcasters.
Paragraph 9.2 in [1] is the most important in this respect. Further there are some
requirements related to personalisation and audience research, these can be found in
paragraphs 12.5 and 12.6.


3.4       Third parties

3.4.1      Benefits
Although not immediately obvious, one of the main benefits of the Share it! system is that
third parties are not involved with the user at all. In established broadcasting scenarios, third
parties deal almost exclusively with the broadcaster or with even earlier parts of the delivery
chain. Advertisement is delivered to the broadcaster or provided at the point of content
production (banner advertising on sports events, product placement). Share it! allows third
parties to contact the end-user directly.

This not only opens new opportunities for advertisers, who are the classical ‘third parties’ in
conventional broadcasting, but also provides an environment for new services, which can be
provided by parties not currently associated with broadcasting.

Targeted advertising
Advertising can be targeted at specific users based on:

      •    Viewing patterns of the user (e.g. show tickets for people who watch musicals, offer
           DVDs for people who watch episodes of a series more than twice before deleting it
           from the STB)
      •    Known demographic of the user/household (e.g. show car adverts if family car is
           older than five years)
      •    Interaction with other users or in discussion groups (e.g. sell fishing lures to users
           who annotate fishing scenes in movies)

Close relation between advertising and sales
The time span between advertisement viewing and sales contact can be accurately measured
and can provide fast feedback on the efficiency of a particular advertising concept. This
allows third parties to fine tune ad campaigns to the viewers preferences.

Information can be replayed
Currently direct sales advertisements (unlike brand awareness advertisement) is inefficient
outside specific tele-shopping broadcasts, since viewers are unlikely to interrupt the watching
of a movie to call a provider of goods and order. With Share it! based advertisements the
viewer can mark advertisements that interest him and recall those ads after the movie is
finished and contact the advertiser at a time more convenient than during the watching of a
movie.

Localisation of services
Third party applications and content could be delivered to specific geographic locations. This
not only allows small local businesses to advertise only to likely customers in their area, it
also allows other organisations to provide information to specific regions (e.g. information
about the schedule of a bus for blood donors or a local election). In addition to providing
information to viewers, new services for local interaction between users can be offered, like
scheduling of local sports activities or community history projects.


                                                36
New services
Similar to various ‘support industries’ spawned by successful services such as Ebay, the
Share it! system allows third parties to provide new services to the customer, such as rights
brokerage and management, content collection, review and annotation, search engines,
external storage provision, newsgroup management, trusted payment services. Many of these
services can be financed by direct payments or on a commission basis and are not forced to
rely on advertising revenue.

More secure payment due to close link of STB and a geographical address
The close integration of the Share it! box into the household makes credit card fraud and
identity theft less likely than for similar sales offered in the classical Internet environment,
which is especially important for the sale of non-tangible goods like movies.

Large audience with similar interests
Even with ‘time-shift’ capabilities, most viewers will watch many shows when they are
broadcast. This allows third parties to reach a large audience with similar interests at a
specific point in time and can be used for events directly connected to the show. A company
might offer a live chat with the author of a movie directly after the movie has finished. There
could also be services based on group activities, which require a large audience ‘online’ at the
same time, for example a ‘where is the biggest football expert’ trivia contest between France
and Spain during a halftime break of a game between teams from both countries.


3.4.2   Drawbacks/dangers

Services may migrate to broadcasters
Services that have been traditionally the province of third parties may be provided directly by
the broadcaster. For example, once video rental does no longer require the use of physical
storage devices (VHS tape, DVD), video rental may be provided directly by the broadcaster
as an additional source of revenue.

Yet another platform to author for
For many third party providers this will be seen as another platform for which they have to
supply a portal to their services and content, in addition to web pages, WAP interfaces, SMS
services, or callcenters. While storing content in platform independent description formats like
MPEG-7 or XML might help, they also carry the risk of providing services on a ‘lowest
common denominator’ of all platforms and of not using the specific features of the Share it!
platform, which made it attractive to viewers in the first place.

Advertising revenue loss for broadcasters
Third parties may provide advertisement directly to viewer by other means than broadcasting
(e.g. using Internet based data transfer), thus bypassing the broadcaster and reducing the
broadcasters income from advertisements. Third parties might also provide piggyback
advertising, by providing interesting and easy to produce services to tie in with large events,
which draw a large viewership, without the need of paying the higher advertising rates during
such events. For example, a company could provide an overlay animation that shows the
position of cars during a formula 1 race, including an advertising banner. This would reach a
high number of viewers and ensure that the advertising banner stays an the screen and is
watched by a large audience for a long time without any need to place an ad at premium
prices with the broadcaster.


3.4.3   Related requirements
Similar to broadcasters third parties require content protection as described in section 9.2 in
[1]. Sections 9.2.2 User identification, 9.2.3 User status, 9.2.4 Rights management, 9.2.5
Tracking content use, 9.2.8 System information update, 9.2.9 Support for group rights, and
9.2.13 Rights Management Protection Information (RMPI) are all of particular interest to the
third party content provider.




                                              37
In order to provide targeted services the third party has to be able to push content to the box
(7.1.11), to profile the audience (12.6), and to manage user groups (10.2 and 10.4).

Third parties also require tools to provide applications and content in the appropriate formats,
as discussed in: 11.3 third-party creation, 11.5 Publishing (creation of CRIDs) and 11.6/7
Creating/augmenting metadata.


3.5     The end user

3.5.1    Benefits
There are several main benefits for the user when using the functionalities offered by the
Share it! system.

(Faster) access to a wider range of content
With the Share it! system the end user has access to a wider range of content, possibly
available faster than from broadcast channels. This allows him to select the pieces of content
that are of interest to him, and get a personalised selection of content to consume.

End user as content provider
The end user can become a content provider by providing or even selling on content they
have acquired, or from content they have created themselves (e.g. photo albums). Maybe
consumers will be prepared to pay for inclusion in a metadata service in order for their content
to be found in a large audience. Collaborative authoring is possible, where either end users
work together to produce finished content or consumers use services of professionals.

Creation of user communities
The Share it! functionality allows user communities to be formed. This can be of benefit for
the end user since it enables him to acquire, share and possibly even discuss content with
persons that have a similar interest. This also may allow the end-user to share his own
content within selected communities, such as the family or close friends.

Remote access to personal content
The Share it! system allows the end user to access and view content stored on his own box
away from home. For instance, he can access and load his holiday videos or some recorded
movie while visiting his friends.

Communication between users
The Share it! system also allows for communication between users via e-mail or chat. This
could be particularly advantageous if the users are enabled to discuss some common content
in the Share it! system.


3.5.2    Drawbacks/dangers

Consumer privacy
The technical possibilities of Share it! allow the content and service providers to log and
monitor user behaviour. The obtained information could be used in different ways, for
instance to select suitable commercials for the users. This is a possible threat to the user’s
privacy.

Security threats
Since the Share it! box is connected via broadband and since it is allowed to download new
software, there is a number of security threats to the box and the users’ content. One is the
possibility that viruses corrupt the operation of the box. Another is the possibility that
intruders, i.e. hackers, could access the user’s content.




                                              38
Charges for accessing content
The possibility of accessing content through the network gives new possibilities for charging
content consumption.

Complex system to use
The Share it! system offers a large amount of new functionality to the user. This faces the end
user with a complex system that can confuse him. Since some activities possible with the
system may imply charges or cause your content to be accessible among other users it is
extra important to prevent misuse of the system.


3.5.3   Related requirements
The related requirements from the end user’s perspective are described in [1], section 5.1
End User requirements of the Share it! box, section 7.1 End User requirements of content
distribution, section 8.1 End User requirements of security and section 9.1 End User
requirements of rights management.




                                              39
4 Mock-ups
Mock-ups of applications and services allow the Share it! partners to obtain a better
understanding of the functionality that the related application and/or service is intended to
provide. They also force developers to focus on the use-case which helps think through the
application’s/service’s design and the required functionality from underlying stacks, API’s, etc.
A mock-up is an ideal tool to discuss the intended functionality of new applications/services
with their potential users even prior to a usability test in order to allow for a user-centred
development process. Also, mock-ups help to relatively easily explain the project’s focus area
and status to individuals not directly involved in the Share it! project.

Therefore in Share it! we have created a diverse range of mock-ups as a starting point to
select applications and services to implement as prototypes. Most partners provided one or
concepts, developed them into mock-ups and received feedback from the other partners.
Some of those mock-ups may also be presented during the first audit, to help visualise the
ideas discussed here. The next paragraphs describe the concepts and mock-ups in detail.

An important part of mock-up design concerns the user-interface of graphical
applications/services. For this purpose a reference document was provided in Share it! The
interested reader is referred to [6] for more information.


4.1     Partners’ concepts & mock-ups
18 applications and services were thought through by the partners, most of these were
created as mock-ups. The following paragraphs describe these applications/services in more
detail.


4.1.1     Share it! Box user Interface (Philips UK)

4.1.1.1       Description
Philips’ major focus in the project is on the architecture, protocols and the platform. However,
a user interface to the Share it! box part of the platform which Philips designs will be provided.
The user interface will allow the user to interact with the platform and expose the main parts
of the functionality of the implementation, as defined in [1]:

          •     Configure the platform
          •     Device/user/peer discovery
          •     Search for content
          •     Acquire content
          •     View content
          •     Manage storage and other resources
          •     Interact with (join/leave etc) “groups” and other peers
          •     Acquire, start / stop interactive applications

The purpose of the user interface is to demonstrate the main resident functionality of the
system, rather than to explore the full possibilities of how users could interact with such a
platform. No mock-up was created for the box interface.




                                                   40
4.1.2     News Ex10sion (BBC)

4.1.2.1    Description
This application is essentially a mixture of stored broadcast content and on-demand
programming, with additional ‘rich media’ content such as text, graphics, audio commentary
and so on. On-demand content may consist of up-to-the-minute live reports, or previously
archived footage.

The application controls play-out of a news programme, during which a ‘more info’ option
appears. This allows the user to request further information (in the form of text, pictures,
audio and video snippets, etc) about the current story. This extra information may be sent in
advance from the broadcaster, or may be made available using the peer-to-peer aspects of
the Share it! system.

     •    A news programme stored on disk (MPEG-2).
     •    Using broadband link for streaming content of in depth audio discussion around the
          stories.
     •    Extra text, images and graphics displayed on screen.


4.1.2.2    The mock-up
A "News Ex10sion" application mock-up was created using Macromedia Director. This tool
provides a fast and efficient means of assessing the look and feel of an application, allowing
the playback of many media formats to be controlled via PC key events.

Whilst the mock-up is PC-based, the design is carried out to televisual standards (i.e. correct
16:9 aspect ratio, a limited colour palette, restrictions on minimum font size and maintaining
screen safe-areas). By viewing the mock-up on a television screen using a standards
converter, a good impression can be obtained as to how the application may look on the
intended type of display.




Figure 4.1 Mock-up screen shots showing the segmentation menu and video extra view with
           paused main programme.

Currently the mock-up is implemented to provide a single route through the application rather
like an enhanced slide-show. This provides a sufficient idea of the functionality of the
application.




                                              41
4.1.2.3    Research areas/requirements
Media
• Load and display image (sourced from disk / broadband link / off-air)
•   Load and control playback of ‘lower quality’ video (sourced from disk / broadband link /
    off-air)
•   Load and control playback of audio (sourced from disk / broadband link / off-air)
•   Simultaneous additional video/audio (more than one JMF player?)
•   Time synced media assets (e.g. audio ‘clips’ synced to video). Off-disk & via broadband.
•   Downloading of content and media assets (including applications, graphics, video, text) to
    disk before use.
•   Multicast IP over broadcast channel?
•   Triggers in broadcast and off-disk streams for firing application events

Profile
• Get current user’s profile or preferences

TV-Anytime
• Control playback of video segments based on TVA data.
•   Get Segmentation metadata (is TVA parser on box, or in application?)

Security / Rights / etc
• Conditional Access API
•   MHP security model?

Remote Control
• Pause, Play, Rewind, Fast forward (or could use colour keys as for myTV?)

Other
• Request what services are available
•   Establish available connectivity (data rates over network, quality of service issues).


4.1.3     Gardeners' World (BBC)

4.1.3.1    Description
Here, upon invitation of the broadcaster, members of the peer network are able to submit
content about particular programme topics for review and classification by the broadcaster.

As part of an enhanced broadcast programme, reference is made to this peer-submitted
content (which may be inserted into the broadcast programme, made available from the
broadcaster’s servers or available from peer boxes).

Although applications of this type can be imagined for a variety of programme genres, as an
example, in the case of ‘Gardener’s World’ viewers may be invited to submit content giving
houseplant care advice and video sequences of their gardens, which are categorised by plant
type and landscaping style.




                                               42
4.1.3.2    The mock-up
As for the News application, Macromedia Director was used to implement a mock-up of the
Gardeners' World application. Screenshots from the mock-up are shown below.




Figure 4.2 Selecting content from disk to send to the BBC and reviewing other's contributions
           during the programme.

Please note that the "Gardeners' World" brand is used for illustration only, and it is possible
that any application whereby users can submit and view programme contributions will be
based around another similar BBC programme.

As with the BBC news example, the mock-up is limited at the time of writing to providing a
single route through the application.

4.1.3.3    Research areas/requirements
Media
• Source AV content from peer boxes / servers
•   Source metadata from peer boxes / servers
•   Send AV content to peer boxes / servers
•   Send metadata to peer boxes / server

Remote Control
• Alpha numeric keyboard for authoring metadata

4.1.4     TV-Anytime compliant data service (BBC)

4.1.4.1    Description
Following on from the success of the IP data servers implemented in the myTV project, the
BBC intend to supply detailed descriptions for radio and television programmes, according to
TV-Anytime specifications. This data will be made available using internet-type query
protocols, and possibly over air.

4.1.4.2    The mock-up
Data to describe television and radio programmes available from the BBC using TV-Anytime
compliant data is available from a prototype server, written in Java. Currently a query protocol
similar to that developed within the myTV project is used to request information, although this
protocol may need changing to allow access to the full richness of the TV-Anytime data.




                                              43
A fragment of data similar to that returned following a request for metadata on a single CRID
is shown below.

<?xml version="1.0" encoding="ISO-8859-1"?>
<TVAMain xmlns="http://www.tv-anytime.org/2002/06/metadata"
xmlns:mpeg7="urn:mpeg:mpeg7:schema:2001" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.tv-anytime.org/2001/08/metadata I:\tv-
anytime\schema\tva_metadata_v12.xsd">
     <ProgramDescription>
         <ProgramInformationTable>
             <ProgramInformation programId="crid://bbc.co.uk/276819538" version="1">
                 <BasicDescription>
                    <Title><![CDATA[City Hospital]]></Title>
                    <Synopsis><![CDATA[Matthew Kelly and the team share the trials and triumphs of the
                    staff and patients of one of Britain's busiest city hospital complexes, Guy's and St
                    Thomas'.]]></Synopsis>
                    <Genre href="urn:mpeg:TVAnytime_v0.3IntentionCS:1.3">
                         <Name><![CDATA[INTENTION:EDUCATION]]></Name>
                    </Genre>
                    <Genre href="urn:mpeg:TVAnytime_v0.3FormatCS:2.1.4">
                         <Name><![CDATA[FORMAT:STRUCTURED:Documentary]]></Name>
                    </Genre>
                    <Genre href="urn:mpeg:TVAnytime_v0.3ContentCS:3.1">
                         <Name><![CDATA[Content:NON-FICTION]]></Name>
                    </Genre>
                    <Genre href="urn:mpeg:TVAnytime_v0.3ContentCS:3.3.16">
                         <Name><![CDATA[Content:LEISURE/HOBBY:Personal health]]></Name>
                    </Genre>
                 </BasicDescription>
                 <AVAttributes>
                    <AudioAttributes>
                         <NumOfChannels>2</NumOfChannels>
                    </AudioAttributes>
                    <VideoAttributes>
                         <AspectRatio>16:9</AspectRatio>
                    </VideoAttributes>
                 </AVAttributes>
                 <MemberOf crid="crid://bbc.co.uk/Alert_HealthFitness"/>
                 <MemberOf crid="crid://bbc.co.uk/CityHospital_Series"/>
             </ProgramInformation>
         </ProgramInformationTable>
     </ProgramDescription>
</TVAMain>



Further development of this mock-up may involve migrating towards a query protocol agreed
within the Share it! project (which itself may be based in part upon that under current
discussion within TV-Anytime). It is also intended to make this service available to project
partners.

4.1.4.3    Research areas/requirements
Server

     •    Query protocol for data server access based on TV-Anytime


4.1.5     Rights Negotiator (BBC)

4.1.5.1    Description
The rights negotiator consists of a rights server communicating with an application offering a
user interface for viewing and negotiating rights for content. It may also be used for ‘resolving’
rights associated with particular content that has been passed around on the network.




                                                    44
Visualising rights in a simple and easy-to-understand way is important for usability of a Share
it! system, so an attempt to present visual metaphors of different ‘rights states’ (free-to-view
forever, payment required, passing to others prohibited, four views allowed, etc) will be made.

The rights negotiator application is intended to demonstrate the process by which the user
may acquire information about the rights associated with particular content. However at the
current time, work to define the Share it! rights system is still in progress, and the mock-up is
incomplete.

The rights negotiator could consist of two parts:

- Firstly, a 'server' (likely to be an extension of the data server described in 4.1.4) exists. Part
of the mocking-up process would involve investigating the structure and fields required to
accurately described the rights associated with each piece of content.

- Secondly, a 'client' exists, which may be implemented as a web page, Java applet, MHP
xLet, or another application type. This client allows the viewer to visualise rights associated
with content in an easy to understand way.

Clients may include one or a number of the following:

        •   MHP xLet
        •   Web page
        •   PC-based Java application
        •   Java applet
        •   WML cards (for mobile phone)

This mock-up is concerned with investigating the semantics of the queries, and the types of
rights conditions that exist and must be expressed to the user.

In addition, a selection of graphical screens showing how the client may look on a number of
devices may be produced. These graphically focussed mock-ups may also be used to
investigate any suitable visual metaphors that may be employed to represent the different
rights states that a piece of content can be in.

4.1.5.2      Research areas/requirements
Server
        •   Protocol for rights server access (is this ‘application specific’, or ‘project generic’?)

        •   Rights model (it is possible that the model used in this mock-up will be different to
            the final model adopted).


4.1.6       Broadcaster’s iTV portal (NOB)

4.1.6.1      Description
A broadcaster provided application that allows the viewer to be provided with broadcaster
originated:

    •       News
    •       Programme backgrounds
    •       Programme recommendations




                                                   45
And to share the above with their friends & relatives, e.g.:

    •     Chat about programmes
    •     Send recommendations to others

This application intends to show how a broadcaster can make use of general Share it!
functionality to provide an entry point into the 'world of content' it is offering their viewers. The
Share it! functionality basically is an add on to more common day portals, but may allow the
faster spread & more use of the broadcaster's content. Also it may help to promote the brand
of the broadcaster to the largest possible audience.

Possible extensions
The functionality of the iTV portal may optionally be extended with viewer polls, content rating
and reviewing, downloading of content via broadband, the uploading of user generated
content to the broadcaster, etc. This functionality can all be based on p2p technology.

4.1.6.2    The mock-up
In this mock-up the focus is on integration of p2p functionality in iTV portals. The iTV portal
mockup shows typical functionality that will be available on a broadcaster’s iTV portal. NOB
would like to give special attention to the implications for the Dutch broadcasting situation,
where multiple broadcasters share one physical broadcast channel. Provisions will have to be
made to insure that resources like the access to the carousel and the user attention can be
shared equally amongst broadcasters.

With the mock-up a number of possibilities and features of p2p networking can be shown. For
example with the chat application the process of user (or peer) discovery can be shown. The
chat can also serve as a mechanism for users to share references to content, next to the
standard content and service discovery methods already defined in TV-Anytime. The portal
can be seen as a collection of applications that are not synchronised to the broadcast of a
television program.

At the time of writing a fully functional version of the application had been implemented on two
MHP set-top boxes and an operational moderation server was created. This task has been
completed in close cooperation with the NOS and the European CIATV (Concepts
Development for Interactive Television Concepts) project, in which (amonst others) NOB and
BBC participate. The implemented functionality includes: a user-selectable tickertape (figure
4.3) with editing tool, a messenger application which allows you to send text messages to
other boxes/SMS-phones and to receive messages from other phones/boxes and poll-
functionality which allows you to share your opinion on broadcaster-originated statements
with others and to view the global results (percentages).




Figure 4.3       iTV Portal with main screen, ticker and messenger interface shown.



                                                 46
The poll-functionality also includes an ‘archive’ with previous statements and results (figure
4.4). The ticker and poll can be influenced by the broadcaster using it’s server-side
moderation tools, in our set-up the messaging is not influenced/controlled by the broadcaster.
The current implementation forms an ideal starting point to investigate more complex features
like sharing programme recommendations and to investigate how to present the functionality
to the user (user interface).




Figure 4.4 iTV Portal with poll and poll archive shown.

4.1.6.3    Research areas
Issues to be researched for this mock-up are:

•   Chatting over P2P networking protocol (JXTA?) [7], 3.4.10.3
            o How to find friends that are currently watching?
•   Permanent list of friends [7], 3.4.10.3, 3.4.11.2
          o Centralised resident list accesible by downloadable apps?
•   Transfering programme recommendations over P2P networking
                                                   protocol [7], 3.4.10.3
            o CRIDs over JXTA?
•   Sending & receiving SMS [7], 3.4.10.3
           o NOB already has access to an SMS gateway and would be interested in
               coupling it to the Share it! infrastructure.
•   Uploading of personal content to the broadcaster [7], 3.4.9.1, 3.4.10.3
           o This is a possible extension and currently not a priority.


4.1.7     Soccer Sharing (NOB)

4.1.7.1    Description
A broadcaster provided application that focuses on the exchange of content & metadata in
various ways.

This application is focussed on a specific type of popular content that already today triggers a
lot of community-feelings amongst viewers: soccer. The application is provided with the
broadcast soccer-match and allows viewers to:

    •     Exchange opinions about the current match
    •     Create and share references to highlights with friends
    •     Send/receive the highlighted content to/from friends, using the broadband connection


                                                47
Possible extensions
   • Create peer groups to form supporter or special interest groups
    •     Vote on referee decisions
    •     View alternate camera angles in low resolution quality


4.1.7.2    The mock-up
The soccer sharing mock-up focuses on sharing experiences around soccer matches.
Viewers are able to share their opinions and highlights of the match with other box-owners.
This mock-up intends to show the use of content sharing among users over p2p networks.

Functionality
The mock-up functionality demonstrates how a viewer can choose from a limited set of
opinions on the match (expressed in short textual format). The idea is that the viewer would
not really like to type in free text, as he typically is watching the match with e.g. a drink in one
hand and the remote in the other. Figure 4.3 shows an example where the user has just
shared an opinion with his friends and currently is receiving their opinions.




               Figure 4.5      Soccer sharing mock-up showing ‘opinion sharing’.



Figure 4.6 shows how the same viewer can share highlights with another box owner. The set
of highlights the viewer can choose from is predefined by the broadcaster (using
segmentation metadata), to prevent the viewer having to go through relative complex
‘indexing’ process and to allow the broadcaster to have control over the way the match is
promoted to others. The demo shows the full process, including the option to view the content
by the receiving party. Also both ‘viewers’ can decide to start sharing. The mock-up is fully
functional to a large extent (only the highlights selected are predetermined).




                                                48
                               Figure 4.6 Highlights sharing.

Limitations
• The current ‘opinion sharing’ mock-up has a single ‘predefined path’, that is: you can only
   choose to give one predefined opinion on the match.

•   The way to choose other box-owners to share with and the way to find them is not shown
    or touched upon by the mock-up in the ‘opinion sharing’ case.

•   For the highlight-sharing case the segment chosen is part of a predefined path.

•   For the highlight-sharing case the mechanism to choose other box-owners is visualised
    using a list of ‘e-mail addresses’ and corresponding names. The use of the e-mail
    address is for visualisation purposes only.

Evaluation
NOB decided to start from the ‘minimal functionality’ side, because it is our belief that an
overkill of functionality will not ‘fly’, as it is easily too complicated for a viewer to use
(especially while watching the TV-programme at the same time). Therefore we used
predefined sets in both the opinion and highlights sharing case. The drawback of course is
limitation of freedom of choice. Our preliminary evaluation on this mock-up concludes:

•   Level of complexness in ‘opinion sharing’ mode is ok (argument: most people being
    introduced to the application understood the functionality and how to use the mock-up
    very quickly).




                                             49
•   Level of complexness in ‘highlights sharing’ mode may be too high. Although the
    intermediate steps are clear in themselves, the interface looks relatively cluttered.
    Another way to choose whom to share with may ease the perception of the complexity.
    The number of ‘button presses’ seems difficult to lower much more.

•   Use of ‘free text’ input (using T9 or a separate keyboard) should be experimented with.

•   Inclusion of NDR functionality (= a larger range of highlights to choose from) may be
    interesting.

4.1.7.3    Research areas
Issues to be researched when one decides to implement this mock-up include:

•   Transferring of content references and index markers [7], 3.4.2.3, 3.4.10.3
            o This may be realised by transferring CRIDs and segmentation metadata
•   Indexing [7], 3.4.2.3
            o Viewers can create indexes on programmes.
•   Transcoding [7], 3.4.10.3
           o Creation of browse quality content and accompanying CRID if necessary

•   How to find user groups and how to indicate with whom to share?

•   How far to go with providing the viewer ultimate freedom in entering opinions (‘free text’)
    and choosing segments (TC in/TC out). What is best point on trade-off between
    complexity and freedom?


4.1.8     TV Anytime metadata server (NOB)

4.1.8.1    Description
The myTV originating metadata server will be extended for Share it! use. For the mock-up
phase the current server is enough, as it already provides a good insight in how such a
system would work. For a real Share it! service details regarding the metadata syntax (e.g.
more TVA-compliant) and more support for service discovery probably are needed.
4.1.8.2    The mock-up
The myTV server was extended with ‘groups of programmes’ functionality and made available
to all interested partners. It is providing myTV metadata continuously and also functions as
the data-source for the experiments with the audience research mock-up (see the next
paragraph).


4.1.9     Audience and programme research (NOB)

4.1.9.1    Description
As mentioned in paragraph 3.3.1 the ability to gather accurate viewing statistics is one of the
positive promises the Share it! system has to offer to broadcasters. Effectively evaluating the
influence of (possibly illegal) use of content and the effects of superdistribution require
accurate viewing statistics. Up till now this is being done using limited groups of viewers
which have been specially selected. Only recently experiments with the use of advanced set-
top boxes for this purpose have been started, but not yet in an open standards-based way.




                                              50
NOB has set out to investigate the possible use of audience research data, by interfacing to
the box content-use logs. This may be in the form of a usage data gathering service, showing
'normal day operation' and in the form of a specific 'questionnaire application' that is sent to
obtain more detailed information about the public's likes & dislikes. Emphasis is on a
standardised way to interface to the box and on the back-end and return data processing to
discover what will be desired & feasible in a practical system.

The possibilities to use content referencing information for this probably form a key part of the
work. The functionality may include:

    •     Providing an (anonymous) overview of programmes watched in the last week
    •     Providing an (anonymous) overview of mostly watched *parts* of programmes
    •     Providing detailed information on programme ratings via a 'questionnaire app.'

4.1.9.2    The mock-up
The current mock-up is based on PHP-scripts that mimic viewer behaviour in various ways.
The scripts can be accessed by the partners via an Internet browser. The partners can query
NOB’s metadata server, in order to generate simulated user-behaviour. This provides some
idea of what the audience research functionality could look like.




Figure 4.7        Engineering interfaces to simulate statistics using NOB’s TV-Anytime
                  metadata service.

Since the logging of viewer statistics should be transparent to the user most of the time, the
demonstration value from a user perspective is not so high. Focus in this mock-up is mainly
on the backend interface of a viewer statistics system. The use of the broadband return
channel for the transfer of viewer statistics is obvious but poses a number problems.

In the field of viewer statistics there are two opposite forces. The viewers usually want a high
degree of anonymity, where as the broadcaster usually wants to know exactly what the viewer
is watching. For a free to air broadcaster it seems reasonable to demand basic overall
statistics, like viewer rating and the number of viewers. As users will also transfer (i.e.
republish) broadcast content amongst each other, it would be reasonable to extend the
statistics to the tracking of the content. This should of course be done without harming the
(sense of) privacy of the viewer.

In the mock-up a balance in both the interests of the viewer and the broadcaster is sought.
This is done by displaying different classes of statistics. The mock-up will aid in the process of
forming an opinion on what should be allowed in audience research and help develop open
standards that allow content providers to access usage logs on the Share it! system in a safe
and standardised way.




                                               51
4.1.9.3   Research areas
Issues to be researched for this mock-up are:

•   What is logged exactly by the box [7], 3.4.11.2
            o For example: boolean indicating if programme was watched, duration of
                watching, date at which it was watched, etc.
•   Anonimity [7], 3.4.7.2,
           o If and how the anonymity of the viewer can be guaranteed
•   Access to user profile [7], 3.4.7.2
           o Who should get access to which part of the user profile
•   Digital rights management [7], 3.4.8
              o Tracking the usage of shared content


4.1.10 Handheld device connectivity (KPN, ELISA)

4.1.10.1 Description
This concept is centred around personal mobile devices that can be used in the process of
sharing content. There is a strong link between the application on the mobile device and the
local storage or network storage in the sense that the mobile device acts as the interface to
the user, providing the possibility to initiate exchange of content; send content to a friend,
retrieve content etc. The actual transfer of content will (in almost all cases) not take place
between those mobile devices but between the actual places where content can be stored. Of
course it is possible to access your own content and view it on your personal mobile device.

This mock-up illustrates how the user's Share it! box can be controlled 'from a distance', i.e.
by a mobile device such as a PDA or an i-mode phone. The focus of the mock-up is on the
user interface and interaction showing the following functionality accessed from a mobile
device:

•   access of own content: browsing/searching through content residing on own Share it!
    box and playing content on mobile device.
•   transfer of content from other user's pvr (pull): browsing/searching on mobile device
    through content residing on other user's Share it! box, and ordering own Share it! box to
    pull selected content from other user's Share-it box.
•   transfer of content to other user's pvr (push): browsing/searching on mobile device
    through content residing own Share it! box and ordering it to pull selected content to other
    user's Share it! box.
•   programming Share it! box: browsing/searching the EPG on mobile device. Ordering
    the Share it! box to record selected programmes.

4.1.10.2 The mock-up
Figure 4.8 shows a visualisation of the mock-up.




                                                52
                                   PVR - Erik              A handheld device provides
                                      Latest news          access to your personal video
                                      Home video           recorder at home. You can
                                                           browse through your content,
                                      Keeping up
                                      appearances          send content to friends, search
                                                           for content and watch content
                                   watch   send   search   on your mobile device.




                                   PVR - Erik              Friends can send you links to
                                                           content that is stored at their
                                                           own PVR, or at any other
                                    New video link         place they can link to. When
                                     from Ronald.
                                                           you receive a link, you can
                                                           ‘order’ your PVR to fetch and
                                                           store it for you.
                                     Fetch to my PVR




                                                           You can watch content that is
                                                           stored on your PVR. In this
                                                           case the latest news, but of
                                                           course also Personal Content
                                                           can be watched.

                                   Latest news




            Figure 4.8      Illustration of use of a handheld device within Share it!

4.1.10.3 Research areas/requirements
•   Secure link between mobile device and Share it! box.
•   Authorization/authentication of mobile device.
•   Streaming to mobile device.
•   Player for mobile device.
•   Receiving and processing commands by Share it! box through webserver.
•   Pushing/pulling content between Share-it boxes.
•   Network: GPRS, UMTS, WLAN.


4.1.11 Network storing (KPN, ELISA)

4.1.11.1 Description
Another application/service that is of interest is the usage of active network components.
Users and content providers will be able to store content on network storage and share it from
this location. The logic of how the network storage functions is a key issue, centering on how
the content is shared to user groups or made publicly available. Another logical feature is the
possibility to change the network on which the content is shared, for instance if a certain
amount of streams (users) is exceeded the content can be tranferred and streamed trough
the terrestrial network instead. This feature is of interest to broadcasters, popular content can
then be re-transmitted if necessary. Also billing and pricing of this service is an interesting
issue. The NDR is also an important factor in stabilising network and bandwidth usage.




                                                     53
                                                      NDR                           STBs

                           A/V material
       STB




                                    Downloaded
                                                               STB
                                    A/V material



                                                                                     Downloaded
                                                                                     A/V material
      An end user has stored his content on the NDR and since several users
      have selected to view his content the NDR has chosen to broadcast it as one
      single uni-cast stream instead of N different videostreams




                               Figure 4.9           Illustration of use of NDRs.

4.1.11.2 The mock-up
The mock-up demonstrates a telco provided application that allows users and content
providers to store content on network storage and share it from this location. The network
element primarily provides download acceleration, which is an important factor in stabilizing
network and bandwidth usage. A secondary function of the network storage device is to
function as a recorder for users with limited recording capacity (i.e. the local disk is full).
Content stored on the network can be retrieved from the device later when more capacity is
available locally. Network storage client functionality can be divided into three parts: recording
live, recording show chosen from guide and viewing content.




        Figure 4.10           Screenshots of the NDR’s client-side interface.

A user can record live or future shows found from the EPG. Files are saved on their default
storage device, which is normally the local hard disk. However, if the user is running out of
local hard drive space, alternatives are suggested. The system notifies the user and proposes
using network storage or cleaning up the hard disk. the user has the option of defining which
files to delete first or to buy space from the network device.



                                                          54
Searching and viewing video files is part of the resident functionality of the box. Thus the
navigator interface is not demonstrated in detail in this network storage mock-up. The user is
presented the opportunity to choose the content source, one of which is the network storage.
The network storage selection defaults to users own storage space on the network storage.
Files on the network (both NDR and p2p) can be browsed and their rights changed.

The mock-up will be created using xml-documents and can be viewed on a modern browser
(IE6). XML was chosen to ensure the smoothest possible transition to application
development phase. Tools such as Director and PowerPoint were considered, but not chosen
in order to cut down on costs and development time. It is acknowledged that much of the
functionality of an NDR can not be shown in a mock-up. Diagrams, flow charts and other
models have been used to illustrate the more abstract features of the system.

Several key issues have to be solved to produce the actual demonstration. One major
obstacle is to make a decision on application of digital rights management to the files shared
on the network. Consensus must be found on whether the content should be shared freely or
force some kind of DRM solution. Rights could be assigned to user groups or have all content
publicly available. Also an intermediate solution, with some of the files encrypted, is possible.
Naturally also privacy issues have to be considered. If all content is publicly available and
searchable users’ identity has to be kept hidden.

Another aspect of the system design challenge is to figure out how exactly multichannel
transfer of content should implemented. This is an important area of study, because it can be
used to minimize network load and NDR system requirements. It would also ensure the most
straightforward path towards commercial products. The retrieval of remote media files may
not for example be implemented as real-time streaming, but rather as a background download
process or ip-datacast.

Limitations
The client mock-up naturally has some limitations. Some of the functions are not implemented
at all and an error message is presented instead (e.g. buying more ndr-space). Other
functions have been implemented partially but no real interaction is possible (browsing files
on the NDR). Also the background video clip is currently a looped piece, but video streams
can be used for more important occasions.

Server controls are an important part of the system, but no functional mock-up was created.
The principles are illustrated with text and flowcharts. Most of the features should be
automatic and therefore not visible. A large part of the functionality consists of different alarm
and event logging visualisations. To able to tune the system operator needs to know how
much resources (disk space, bandwidth) is left. The server automatically provides file version
management and network optimisation. In addition the operator should be able to change the
rules for deleting old files and make changes to configuration manually in emergency cases.

Possible extensions
A possible extension and logical additional feature for the network storage service would have
been the possibility to change the network on which the shared content is distributed. For
instance if a certain amount of unicast streams (users) is exceeded the content can be
streamed trough a terrestrial broadcast network or multicast streams instead of IP-networks.
This feature would be of interest to broadcasters and telcos alike. The multichannel delivery
scenario is however not implemented in the mock-up.




                                               55
                      Figure 4.11      NDR’s serverside user interface.

Research areas/requirements

•   Remote folder management (move items/folders, delete items/folders, rights
    management)
    o record show (by CRID, time + channel) to a default or chosen folder
    o remove show from storage (file management)
    o transfer of remote access rights to another user/group
•   Starting streaming/downloading to local hard disk (ip, port, type)
•   Responding to queries (select, browse)
•   Uploading/sending a file to a broadcaster/friend/NDR (push)
    o allow push setting, folder name and size
•   Hard drive space status control and alarm function
•   NDR service provider information and search protocol
    o Proxy IP:port setup (NDR service provider selection)
•   Ability to choose a network (datacast, IP unicast, IP multicast)
•   XML-browser
•   Metadata specification
    o content that allows caching
•   Digital rights management
•   Different DRM systems and security
•   Existing metadata specifications for DRM
•   Network load optimization and balancing
              o Proxy caching is used to reduce required network bandwidth, latency and
                  load, but also server load (applies also to individual share-it! boxes). Video
                  files are generally large and thus the positive effects will be maximized.
              o Caching protocols (ICP, CDP, CARP, WCCP) and their applicability to video
                  content
              o Broadcasting/multicasting content from NDR/PVR
              o Comparison of local content, NDR content and public content for achieving
                  best result in searching for content
              o Authentication of users
              o Sharing cache configuration files with other NDRs to anticipate demand
              o Sharing cache configuration files with the user data management system
                  (see NoB mockup)




                                              56
•   NDR control unit functionality
           o System needs to count which video files have been accessed the most
               during the last week (chosen timeframe)
           o Cache only certain mime- and tva- content types (size, type)
           o Cache only non-changing items. News, sports etc Should not be cached.
           o Advertise that the wanted file will be available through multicast/broadcast.
               User terminal should ask (predefined settings?) the user whether to pause
               downloading and concentrate on other files.
           o Has to be able to distinguish rights to distribute files, before uploading
•   NDR functionality
           o Basically NDR should function just like any other Share-it! box, but it is
               controlled remotely by an outside agent (file and resource management)
           o Use of error correction in multicast/broadcast transmissions
           o Underlying network or chosen business group based identification
           o Be able to capture programming on several channels at once or be able
               advertise it is free for control
           o Fallback to decentralized peer-to-peer file sharing in an event of proxy server
               collapse

4.1.12 Bundling of content (FhG)

4.1.12.1 Description
The purpose of this application is the combination of various content items into a bundle. This
allows the user to collect all the content relating to a topic of his choosing and provide a
navigation interface similar to a DVD menu. The bundle description is then combined with the
content referenced in the bundle (at least that content for which the user has the property
rights) and can be shared with other users. Content for which the rights are not owned by the
user who produces the bundle are only referenced in the bundle. When the recipient of the
bundle tries to view it, the property rights are checked and the user can either acquire the
missing content or watch the presentation without it. The main challenge of the mock-up is to
provide a user interface which is easy enough to be handled by a TV remote control, but also
to provide enough functionality to attract the end user.

4.1.12.2 The mock-up
To describe the application, a specific scenario is used for demonstration purposes. A user
has watched a TV show about the “Arctic and Antarctic” and is reminded of some of his own
vacations to the North. He creates a bundle that combines the movie he has seen (in a full
length version, but also with access to specific chapters) with his own vacation snapshots and
videos. He then makes this bundle available for other Share it! users.




                     Figure 4.12      Starting the Content Bundle Editor

He begins by starting the content bundle editor and selecting the ‘New bundle’ option. The
program now generates a minimum bundle, consisting of a default background, a textual
header and one empty menu item.



                                              57
The user first replaces the default background and header by his own images. Following that,
the user starts to edit the menu items. He includes four menu items. The first is a ‘Read me’
item, to explain why he made this bundle. The next item will allow the viewing of the complete
movie about the polar regions. Since he likes to be able to go directly to specific chapters and
assumes that would be convenient for other users as well, the next menu item will be for
chapter access. While the previous two menu items will lead directly to the associated
content, there will be a submenu for chapter selection. The fourth, and for him the most
important menu item will lead to his own content, which consists of various holiday snapshots
and video clips, which he made on a trip to Iceland the previous year. The resulting main
menu is shown in figure 4.13.




                       Figure 4.13      Final appearance of main menu

The next step is the adding of content to the menu items by using the ‘Add content’ function.
Content can be text, images or movies. The user can also add submenus in order to group
his content. After adding some content, the user decides that he is ready to publish the
bundle. He navigates until the background image is selected and presses the red key to
access the main edit menu. From here he saves the bundle and then uses the ‘Test bundle’
function to see how the bundle will later appear to the viewer of the bundle. Essentially it is
the same appearance as the current appearance, but the viewer will not be able to access the
edit menus or navigate to the background or the header image.

Before the actual publishing, he uses the ‘Describe bundle’ function from the main edit menu
to add a short description of the bundle. Now it is time to use the ‘Publish bundle’ function.

The publishing process consists of three steps:

    1. selecting the recipients

    2. defining their rights

    3. sending notification messages (optional)

After selecting ‘Publish bundle’, the publish screen appears and an address book window
pops up to allow selection of the recipients of the bundle. (Figure 4.14). He selects his family
and Timothy as the receivers of this bundle.




                                              58
                           Figure 4.14      Selecting bundle recipients

While he does not want Timothy to be able to modify the bundle (and thus does not change
his default tights of ‘read-only’), he wants the members of his family to be able to edit the
bundle and its content. He presses the key for ‘Modify rights’ to bring up the ‘Rights
management’ window and change the rights for his family to ‘allow bundle and content edit’.

He also wants to inform Timothy about the bundle, so he brings up the ‘Message’ window with
the ‘Edit messages’ function and writes a short message. Since he intends to tell his family
during breakfast about the bundle and that they should add to it, he decides not to send a
message to his family. After selecting the recipients, modifying their usage rights for the
bundle and writing the message, he is now ready to publish the bundle.

The bundle receiver
Timothy Dudley is watching TV. Since he has instant messaging turned on, a message
appears on his screen, notifying him about the availability of the content bundle (figure 4.15).




                         Figure 4.15       Bundle availability notification

Timothy wants to have additional information before getting the bundle, so he decides to
watch the bundle description first. He finally decides to get the bundle.

The application now starts the bundle retrieval. Some of the content (the holiday snapshots
and videos) have been made by the person who built the bundle, so he is free to distribute it.
Part of the content is however from a television programme. He had recorded it on his PVR
and it was still available in his local storage, which allowed him to include it in the bundle, but
he did not have the distribution rights to the content. While he is free to watch it as long as it
remains in his local storage, he can not distribute it freely as part of a bundle.

At the start of the content retrieval the application checks the distribution rights. In this case it
notices that the BBC has the rights for the original television programme and that the content
is available from the BBC video server and can be downloaded for a price of 0.55 Euro.



                                                 59
Timothy decides to pay for the content and download the complete bundle. After some time
the content download has finished and a short message pops up to notify the viewer of this.
Timothy presses OK and starts the bundle viewer, which presents the main menu of the
bundle on the screen and allows the viewer to navigate through the bundle, but does not (due
to the rights as set by the bundle provider) allow him to change it in any way.

Since Timothy had chosen to pay for the content not owned by the bundle provider, he sees
the bundle and the content the same way as the builder of the bundle had seen it. If he had
decided to watch only the free parts of the bundle, all content not freely available would have
been replaced by dummy content (Figure 4.16)




                  Figure 4.16      Menu with and without purchased content

4.1.12.3 Research areas/requirements
Use of resident functions of platform
Currently only a user interface mock-up for the address book, rights management and
messaging functions has been implemented. For the final application, these interfaces either
have to be connected to the associated services on the Share it! platform or the
corresponding platform-resident applications have to be started directly (to be discussed).

In the mock-up there is only the provision to purchase all or none of the content at the
beginning of the bundle retrieval. In the actual application there should be the option to
purchase only part of the content (for example, only the still frames for the menu items or only
content from a specific owner) and also the option to purchase content from within the bundle
viewer application. At the moment, however, the rights purchasing mechanism is not
sufficiently well defined to justify the implementation of a more detailed interface in the mock-
up.

Application features
A number of application features that would be desirable in the final application have not been
implemented in the mock-up for various reasons. The main features that need to be added for
the final application are:




                                               60
    •   Inclusion of other content types
        Currently only text, images and video are allowed as content items. At least
        annotated streamed content from the application described in the next chapter and
        audio should be added.

    •   Menu items as text/graphics combination
        Currently the content bundle editor only allows either text or image based menu
        items. It is often desirable to have a graphic with an explanatory text as the menu
        item.
        An example for this is the sledge dogs submenu. The association ‘running dogs’ with
        ‘movies’ and ‘resting dogs’ with ‘still images’ may be obvious to the builder of the
        bundle, but an additional text overlay would be helpful for the consumer. The final
        version of the application will allow a mixture of texts and graphics for menu items

    •   Text editing
        At the moment, text can only be loaded from text files that are available on the local
        storage device and have been created by some other application. Texts should be
        editable directly in the content bundle application.

    •   Text content presentation
        The presentation of pages with text content are rudimentary. Better formatting control
        of the text (paragraphs, size, font, emphasis) needs to be added.

    •   ‘Missing link’ checker
        When the user ‘locks’ the bundle, it would be helpful if the application provides a
        feedback on whether there are any menu items that are not associated with either
        submenus or content pages.

    •   Various convenience functions
        This covers a number of minor items that should be implemented in the final
        application. For instance, a preferences menu to set default looks, a help page,
        loading of submenus, safety queries when creating or loading new bundles over
        edited menus, faster loading on large content directories, automatic creation of still
        frame representations of icons, content presentation timers for automated slide
        shows, start/stop/…/rewind control for streamed content, etc.


4.1.13 Annotation of streamed content (FhG)

4.1.13.1 Description
This application will run directly on the Share it! box and will enable the user to include
markers and make annotations to a movie that he has in his local storage and intends to
share with other users. It can be used for many different purposes and is as such rather a tool
than a concrete application. Application scenarios include

    • simple indexing of a movie to provide easy access to the main sections of interest, e.g.
        goals in a soccer game, the best jokes in a comedy, or favourite hits in a music
        show.
    • a more detailed description of the purpose of each index by means of annotations
         utilising additional text, audio or image content.
    • individual subtitling of a movie.

The recipient of such an annotated video may watch it either in its original sequence with
corresponding annotations automatically presented or he may skip from marker to marker.
Markers do not only represent an index into the video but also a duration. Annotations are
properties of a marker and can be pictures, recorded audio or preformatted text. While
watching the movie the user can insert a marker by pressing just one button of his remote
control. The movie is then paused and the user can edit the properties of the marker or he
can resume the movie and edit later.


                                               61
The mock-up uses the Java Media Framework for display and control of the video content.
The user interface utilises HAVi UI and is designed for use with a remote control. Only the
colour and cursor keys are used for navigation purposes. When the user has finished editing
markers and annotations are automatically saved in an XML file, which can then be
distributed utilizing the same mechanism as in the mock-up for bundling content described in
the previous section.

The mock-up is provided in two parts: an editor that allows the user to add and edit markers
and annotations, and a player that allows the recipient to watch the annotated content and
navigate through the markers.

4.1.13.2 The mock-up
Upon being started the editor checks whether the selected video already contains markers.
The user can then add new markers and annotations or edit the existing ones.

On the top of the screen a time bar indicates where markers have been set, it also allows the
user to jump to every marker and edit them at any time. The time bar can be made
visible/hidden at any time by pressing the yellow button on the remote control. At the bottom
of the screen the current key assignments for the colour keys are shown.

A new marker can be set by pressing the green button. It will be automatically be represented
in the time bar with a default duration (Figure 4.17). At this point the video can either be
continued (arrow up) or the new marker can be edited. Editing is initiated by the OK button
and the selected marker is highlighted in white.




                    Figure 4.17     User interface with timeline at the top.

When the marker is selected the user can either add an annotation or change start and end of
the marker. This period is used by the player to identify the part of the video to be shown or
specifies for how long an annotation should be presented. The marker can also be moved
with the left and right arrow keys. The end of the duration is indicated by the inverted marker
symbol and also by the yellow bar. To change the duration the red colour key must be
pressed, then the duration can be changed with the left and right arrow keys.

With the green colour key the user can add an annotation to the currently selected marker.
When he does that he must first choose what kind of annotation he would like to make.
Picture (red), audio (green) and text (yellow) annotations are possible.

For a picture annotation the user can choose from his locally stored images. They are
presented as thumbnails (Figure 4.18). After choosing the image, the user can choose where
on the screen the picture shall appear.




                                              62
                    Figure 4.18      Thumbnail gallery and annotation tool

If he has chosen to insert an audio annotation the user can use the colour keys to record
audio, play it to control his recording and if necessary overwrite it. For a text annotation the
user can choose among predefined texts, which are stored locally in a plain text file. When
the user is done with editing he can continue playback and add more markers. At the end of
the video, the video is stopped and the time bar will be automatically shown to allow further
editing. At all times a help screen is available through the blue colour key, which explains the
context sensitive key assignments for all keys (figure 4.19).




                                  Figure 4.19        Help screen

In player mode, the user can only watch the annotated content and navigate through the
markers with the red and green colour keys or watch only the marked scenes by pressing the
yellow colour key (figure 4.20). Whenever the video reaches a marker during playback the
corresponding annotation is presented for the period specified by the marker duration.




               Figure 4.20     Overlay of video with picture and text annotation




                                                63
4.1.13.3 Research areas/requirements
Problems that have appeared during implementation are concerned with overlays to the
video. With JMF a heavyweight component is provided that does not allow lightweight
components like HAVi UI objects to be rendered on top of the video. JMF can also provide a
lightweight player, but because of performance reasons this is no usable option. This mock-
up uses AWT Windows to do the overlays. Because of this problem there is sometimes more
space of the video picture covered than necessary.

Additional features to be implemented for the application are user-defined text annotations
and the possibility to mark areas on the screen, e.g. with a red circle.


4.1.14 Distributed non real-time game (FhG)

4.1.14.1 Description
The distributed game picks up the old tradition of board games as an important means to
share your time with the family or a group of friends. This scenario is transferred into a
distributed environment which is enabled by Share it! boxes. This kind of gaming does not
intend to compete with today’s PC games, but to enable board games in a TV-oriented
environment.

Provision of these kinds of games could become a business of its own, i.e. the players pay-
per-play or the game could be provided as bonus material.

The game itself and its rules are of minor importance to Share it! Any turn-based board game
which fulfils the following requirements would be suitable:

    •   The rules of the game should be easy to learn but interesting enough that people
        would like to play it several times;
    •   The board and other material like tokens, playing cards etc. should be visually
        attractive;
    •   To foster communication between group members there should be interactions
        among the players, not only between individual players and the board;
    •   Each turn should represent a significant step in the game (not just moving the token
        one board element further);
    •   The game should support a significant number of players.

For the purposes of Share it! we cannot use a game which exists as real board game due to
copyright issues. FhG FOKUS therefore invented a game – share the game! – the rules of
which are certainly inspired by a number of existing games, but using it for public
demonstrations should not be of any problem. All of the visual material has been produced by
FhG FOKUS. The board itself is composed from a number of individual elements. This allows
creating new boards easily and keeps the game interesting with only minor effort by the
service provider.

4.1.14.2 The mock-up
The game is server-driven. Before people can start playing, one has to set-up a game (e.g.
select a board) and specify the group of people who shall participate. Each member of this
user group will get an invitation message with the application attached to it. The application
including the visual material like board, tokens, etc. will be downloaded once and stored
locally on the box. Each player will submit his turn completely independently of the other
players to the server. When all turns have arrived, the server will calculate the results of the
individual moves. Together with a notification message these results are sent to all
participating Share it! boxes. The message that the game is ready for the next turn will be
presented as an overlay to the current TV programme. The player can decide whether he
wants to switch immediately to the gaming application (blue colour key on remote control) or
postpone this till later (ok button on remote control).


                                              64
                             Figure 4.21        Notification message

If the user decides to play immediately, the corresponding application is started from the local
storage. The player has to authenticate himself. Afterwards the board is shown and the player
can watch the results of the previous turn and submit his next turn.

Since the user interface is implemented with HAVi UI all functions of the game can be
operated by means of the TV’s remote control. The main functions are mapped to the colour
keys. Appropriate hints are given at any time on the screen with regard to the current function
of the individual colour keys. Arrow keys and the ok button are used for more complex
navigation and selection.




                         Figure 4.22       The board with initial options

Most likely the player will first have a look at the results of the previous turn. The movements
of the tokens are represented by means of animations and sound effects and corresponding
messages at the top of the board. The animations can be paused at any time.




                                  Figure 4.23         Help screen

The cards that have been selected for the next turn will be submitted to the server. A
notification message including the information of who has not submitted his turn yet is passed
back to the box.

                                                 65
The mock-up implementation concentrates on the client, i.e. that part of the application that
will run on the Share it! box. For the purposes of the mock-up the server itself as well as the
communication between the Share it! box and the server are only simulated, i.e. only one
fixed turn is available for demonstration purposes.

4.1.14.3 Research areas/requirements
The mock-up uses a fixed move for presentation purposes. For a real application a server
with the following features would have to be set up:

    •   Set-up and management of user groups
            o Relationship between users and boxes to be clarified
    •   Set-up of new games
    •   Download application/content to the box
    •   Messaging
    •   Client/Server protocol implementation
Additional features for the applications which have not been implemented in the mock-up
could be:
    •   The possibility of voice annotations to pass messages to other players
    •   Personalisation (e.g. different sets of tokens)



4.1.15 Chat service (UoL)

4.1.15.1 Description
The chat service is optional and if it was implemented it would be a part of the P2P software
of the set-top box (STB). It will be available to different P2P users groups. Its purpose is not to
replace computer chat but to provide STB users with simple and basic functionality, which will
enable them to exchange their opinions about the topic they are interested in or to ask for
some content. The features of the service will include:

    •   Public chat with all users in the P2P group

    •   Private chat between two users

    •   Termination of the current chat and start a new one with another user

4.1.15.2 The mock-up
The mock-up was created by using Macromedia Flash MX. The intention of the mock-up is to
show the functionality of the chat service and navigation through the application. From the
mock-up testing more detailed API requirements will be found out and probably some
modifications and improvements of the service will be made. Because a graphic user
interface (GUI) for the Share it! system is not designed yet, the myTV GUI has been used for
the mock-up to show how the chat service is integrated into the system.




                                                66
                   Figure 4.24      Opening screen of the resident navigator

The user starts in the resident navigator (figure 4.24). By selecting a “P2P groups” option he
gets a list of available P2P groups with their short description. For each group a longer
description is available by selecting “Group Info”.

After joining one of the groups, the user can see a list of online users for that group and a list
of available services. In our case only a chat service is implemented in the mock-up. One way
to start the chat is that the user starts the chat service and then selects one user or the entire
group for chatting. The other way is that he selects one user or the entire group and then
starts the service (chat in our case).




           Figure 4.23      List of available P2P groups with their short description.

When the chat service starts, a new window shown in figure 4.24 is opened. On the right side
is a list of available users in the group. First are listed the specially marked users who want to
chat with the current user. If he accepts the chat with a new user, the current chat is
terminated and a new one is established because only one chat window can be opened at the
same time. After the termination of existing chat, the user on the other side will be informed
about the reason for termination.

During the chat, the user can switch between the full screen chat window and TV screen.




                                               67
               Figure 4.24 List of users and services in a P2P group and chat window.

4.1.15.3 Research areas/requirements

•   Resident navigator as a peer in P2P networks.
•   Discovery of relevant P2P groups by the resident navigator.
•   Displaying available P2P groups and their descriptions in the resident navigator.
•   Displaying available services and online users in a group after joining the group in the
    resident navigator.
•   Switching between different displays (chat window, TV screen).

4.1.16 Third-party peer-to-peer user group with membership (UoL)

4.1.16.1 Description
A third-party will create secure P2P groups with membership. A user who wants to join one
such P2P group should obtain his own authentication key from the third party. The user needs
to authenticate himself each time he wants to connect to the group. The management of
authentication will be centralised on a third-party server.

This service will provide features of the chat service and probably some additional features
such as:

      •   Personalisation of the information and content on the third-part server for each
          member
      •   Secure upload of the members’ content on the third-part server
      •   Secure sharing of the members’ content stored on the third-party server
      •   Using the third-party server as temporary storage for recording TV programmes
          that the group member can later download on his STB.

The intention of the service is more than provision of new functionality, it includes the study
and demonstration of secure and centralised management of user membership, and secure
distribution of content in P2P networks.

4.1.16.2 The mock-up
The intention of the mock-up is to simulate the functionality of the service and to show the
critical parts, which will require extensive research. The functional diagram of the secure P2P
user group with the centralised membership by the third party is shown in figure 4.25.

From the user point of view, the main difference between the secure and ordinary P2P user
group is the request of the user ID when he wants to join the group. However, there are more
important differences like establishing a secure communication between the user’s set-top
box (one peer) and the third-party server (another peer), authentication of the user on the
centralised third-party server, exchanging of credentials and other secure information that are
hidden to the user.


                                              68
Because the focus of this service is research and implementation of a secure P2P user group
with centralised membership, only a few services from Figure 4.25 will be implemented to
demonstrate required functionality.

4.1.16.3 Research areas/requirements
    •   Secure communications in P2P networks.
    •   Centralised authentication of users.
    •   P2P user groups with distributed and centralised (membership, user authentication)
        services.


4.1.17 Enhanced TV-Anytime data server (UoL)

4.1.17.1 Description
TV-Anytime data of broadcast programmes from different broadcasters (provided by BBC and
NOB) will be downloaded to the third-party server and enhanced with additional information
like reviews, rating and additional description for the data will be made available over Internet.
Like in the myTV project, the TV-Anytime data will be available on a server-client basis.
Additionally to that, users can access and search data in a P2P network as the members of
the P2P user groups created by the third party. P2P functionality will be wider than the server-
client concept. The users can comment on TV programmes or use comments and remarks
from other group members to search for programmes they are interested in.

4.1.17.2 The mock-up
An enhanced IP data server based on server-client concept was implemented as a third-party
server in the myTV project. Because almost the same functionally will be extended to peer-to-
peer networks, no special mock-ups are required.

4.1.17.3 Research areas/requirements
•   Extension of the existing database to include users’ comments and remarks about TV
    programmes.
•   Extension of the IP data server from the server-client concept to the peer-to-peer
    concept.
•   Development of software on the server to enable the peer-to-peer functionality.
•   Specification of a new peer-to-peer protocol for communication between the IP data
    server and user’s set-top box or computer.


4.1.18 Remote control of the set-top box

4.1.18.1 Description
Because no new functionality regarding the myTV project will be implemented, the mock-up is
not needed.

4.1.18.2 Research areas/requirements
The functionality from the myTV project may be implemented again in the Share it! project.
Research will be focused on the required modifications in implementation caused by the
different platform used in the Share it!.




                                               69
       Navigator
                                                                                 Setting user
                                                                                   profile

                                    User         Available services
     Join to group1

                                                      Personalization
  username                                                                            Ueser
                                     All
   password                         user1
                                                         Browse                      3rd Party
                                    user2
   submit     cancel                  .
                                      .               Upload content                  Group
                                      .               to the 3rd party
                                                                                      Select
                                                       Chat service




      User
                                            Search query _________________
       All
      user1
      user2                                   Movies       Title   User
        .                                     Sports
        .                                     Music
        .                                        .
                                                 .
                                                 .
 Chat with user1

                                                            download        get
                                                rec
                                                             content      metadata




                                                 record to STB

                                            record to 3rd party server


Figure 4.25         Concept of a secure P2P user group with the centralized membership on the
                   third party.




                                                 70
5 Main scenarios
5.1   Prototype scenarios
After the development of the mock-ups described in the previous chapter, the WP4-team
combined and filtered all of those into three main scenario-categories illustrating the most
important features and opportunities enabled by the Share it! system. This chapter gives a
snap-shot of our thinking. The demonstration scenarios, the architecture to support them, and
the implementation plan will be finalised during the first quater of 2003.

(Some partners may choose to mock-up some other ideas in addition, if time and resources
are available.)
5.2   Basic model

                                                                    DV
                             Service provider                                       Applicati
                                                                                    on
                                                                         Share-it! STB
                                                                             SHARE-IT!

                                        Intern
                                        et
       DVB service                                       DVB service
                       Applicati                                       Applicati
                       on                                              on
             Share-it! STB                                  Share-it! STB



Figure 5.1        Basic model providing the scene for all applications & services

The Share it! project is developing a complex system with a number of distinct aspects.
Figure 5.1 shows a basic model of the Share it! environment. The basic model is vital to
provide a simple conceptual understanding of what the system can do. We have used this
model to help develop the three scenarios of how users interact with the system. The three
scenarios are given in table 5.1.

A: Basic content         Allows users to access all the content in the world, to which they have
sharing                  rights in a relaxed, “leanback” way.
functionality            This represents basic file-sharing functionality – with the challenges
                         of making this easy to use within the TV paradigm, and making rights
                         management easy-to-use.
B: Opportunities         Allows creation of broadcaster controlled group around a programme
for service              or series.
providers                Leads users to the content that is available (may e.g. include creating
                         demand for for distributing back catalogue).
                         Helps to gather information about how content is used.
C: Creating, editing     Allow users to publish their own content, to annotate existing content,
and publishing by        and to share it with family and friends in a secure way
viewers

Table 5.1         The three scenarios to be prototyped




                                                 71
5.3     Current status of the scenarios (early November 2002)
For scenario A the box functionalities are being worked out, while at the same time partners
are focussing on how to tackle the rights issues and how to create user groups.

For scenario B we are working on a broadcast programme that also uses broadband content
by deploying NDRs (roughly spoken the NewsX10sion concept combined with NDR
functionality). Current discussions are about the exact NDR functionality required. The other
part of scenario B is being worked on in the form of the audience research service, which
currently is focussing on the required box API’s and the metadata format & security to allow
implementation of such a service.

Finally for scenario C a range of functionalities has been sketched. Current discussion is
amongst others on the hardware support needed for this scenario.

The next paragraphs describe each of the scenarios in more detail.


5.4     Scenario A: Basic content sharing functionality

5.4.1     Overview of proposed Basic Content Sharing Functionality
Scenario A functionality includes:

•     A set of Share-it! peers connected (ad hoc P2P) over the public Internet

•     Running the agreed set of Share-it! protocols over the Internet

•     Running the agreed middleware (MHP+extensions)

•     Connected to a DVB-S broadcast signal and a source of consumer-generated content
      (e.g. camcorder, digital camera)

•     With a user interface that enables and visualises the functionality of the system and how
      it interacts with the rights management solution.

An exhaustive list of box and system functions that this scenario covers is very large – far
more than be demonstrated effectively in a limited time (see paragraph 5.4.6 for a more
comprehensive list). To support our key message for Scenario A - “All the world’s content in
your home”, we need to focus on the core Share it! functionality of DVB PVRs sharing rights
managed content in a peer-to-peer network, through the use of scripted walkthroughs.


5.4.2     Demonstrator System
Two demo systems are described below; a basic and an advanced system. The basic system
allows us demonstrate core functionality with a minimum of equipment. The advanced system
enables us to show extra functionality in addition to the core set.




                                                72
5.4.3   Basic Demo System



        DVB Service 1                                      DVB Service 2




    Home A                                              Home C

                               Internet
        DVB Service 1




    Home B



Figure 5.2 Basic Demo System

Figure 5.2 above shows the basic demo system needed to show core Share-It! functionality
i.e. a simple peer-to-peer network, consisting of 3 peers. At least one of peers should have a
different rights profile to the other peers, to support demonstration of DRM.


5.4.4   Proposed Walkthrough
•   Watching TV (live or PVR)
•   Example search: Search world group (light touch) for particular content e.g. ‘EastEnders’;
    system returns content options, plus relevant user groups (e.g. BBC managed group,
    unmoderated fan group etc.) User can then join user groups and / or acquire content of
    interest (see note about DRM/RMP below). An example of how searches could be
    implemented in the resident navigator is shown in figure 5.3.




                            Figure 5.3 Example search interface.




                                             73
•   DRM aspects can be highlighted by having two boxes with different rights profiles
    showing a different (light touch) view of the world (i.e. perform the same query, get
    different results).
•   Browse a user group, use user group specific services etc.

If time during the demonstration, or the interest of the target permits, the following aspects
can also be shown:
    •   Publishing / Sharing of existing PVR content to a relevant user group (unmoderated,
        or private). An example of how publishing could be implemented in the resident
        navigator is shown in figure 5.4.




                       Figure 5.4       Example of a publishing interface.

    •   Sending a recommendation to a friend


Note: This demo only supports ‘light touch’ DRM; this could still support use of a baseline
RMP system as a way to show interoperability. For more details of the light and heavy touch
approaches to DRM adopted within Share-It!, please see paragraph 1.2.3.3.

Note: We will need to build up a rich set of user groups, ideally with examples of each of the
different types of user groups we have defined. It is too early to define what this set will be, as
it will depend to some extent on the content we are able to use in the demo. Once this is
done, a detailed demo script can be finalised.




                                                74
5.4.5     Advanced Demo System



          DVB Service 1                                     DVB Service 2




    Home A                                               Home C

                                 Internet
          DVB Service 1
                                                          Rights
                                                          Broker


                                                          Peer
    Home B
                                                         Emulator


Figure 5.5 Advanced Demo System

Figure 5.5 above shows the advanced demo system – this includes some optional
components to support additional functionality, which may be of interest to some demo
targets, if time permits demonstration. These components can be independently added to the
basic demo system. Each component and the associated additional walkthrough is listed
below:

5.4.5.1     Share it! Rights Broker
This is necessary if we wish to demonstrate heavy touch DRM in action. Additional
walkthrough step:

    •     Example search: Search world group (heavy touch) for particular content e.g. ‘Attack
          of the Clones’; system returns content options, plus relevant user groups (e.g. Star
          Wars unmoderated fan group etc.). The user can then follow the heavy touch rights /
          content acquisition process to acquire the content of interest.

5.4.5.2     Share it! Peer Emulator
A very limited network of peers is unlikely to support the proposed “All the world’s content in
your home” message we want to convey. As such, we might want to consider a way of
emulating a larger set of peers for demo purposes. We might consider doing this with a
‘backstage’ PC running 1 or more JXTA Share-It clients, each providing adverts for published
content so searching yields a richer result. Content for these adverts is not provided, so
demos will need to be tightly scripted to use real content!

Note that this doesn’t add to the walkthroughs per se, it just gives a richer experience when
searching etc.

5.4.5.3     Home Gateway
One or more gateways supporting NAT (network address translation) - for a convincing story,
1 per home. This would allow us to effectively differentiate between inter and intra home
content sharing (note that having two NAT devices between two peers may be problematic



                                              75
without a rendezvous peer in the network?). The degree to which we show NAT working in
the Share-It! network is for discussion. Additional walkthrough step:

      •    When browsing local content, all available content on boxes in the home is shown -
           i.e. it appears as a larger ‘virtual’ distributed PVR.

5.4.6      Potential Scenario A functionality
A full list of the kind of functions that could potentially be shown in Scenario A is listed below:

Configure and manage the device

•     Add a new device – it becomes visible to other devices

•     Leave user groups (joining is covered below as part of searching).

Search and acquire content
• Browse an EPG (i.e. broadcast schedule), the local disc, or a specific user group to find
   content of interest

•     Directly search for specific content:

    • Broadcast schedule

    • World group (note that when searching the ‘World Group’, search results may include
       relevant user groups, as well as content)

    • Specific User Group(s)

      NB When searching groups, the search can be light touch or heavy touch i.e. can include
      only content that you have the rights for, or content that you might be able to acquire the
      rights for.

•     Once search results have been presented to the user they may elect to:

    • Acquire the content (this may include a rights acquisition step for ‘heavy touch’ content) –
       this may be `real time’ or non-real time’ depending on bandwidths available.

    • Join a user group of interest

Use other user group specific services (e.g. chat, recommendation)
• Publish content as shareable (home originated content is covered in scenario C)

•     Send or receive a recommendation to a friend

Consume content
• Full functional playback of local / recently acquired content

•     Watch live TV




                                                 76
5.5       Scenario B: Opportunities for service providers
Scenario B consists of two different subscenarios: B1 and B2. Both address services provided
by service providers such as broadcasters and telco’s.


5.5.1      B1: Networked services
As presented in John Morris’s document [9], Scenario B1 functionality includes:

      •    A Service provider provides a network service to some or all peers.

      •    The service provider has a server with a greater capability (resources) than a
           consumer box.

      •    The server communicates to the peers with the agreed Share it! protocols

The services presented in this document utilise the features offered by the Share it! system to
provide the user with an enhanced viewing experience. Using the skills of the service provider
(which in this case includes the broadcaster and the telco), a richer set of functionality is
presented to the user.

The scenario presented here is built around the following key components:

•     An open, visible, managed (by the broadcaster) user group tied to a programme strand
      (see group type 3 in [10]).

•     A service provider ‘look and feel’ portal to the user group offering links to additional
      related content that exists within the peer-to-peer network (on peer boxes, network
      storage, etc) and the ability to search and publish to the user group.

•     A networked storage device, hosting content promoted in the group, third party related
      content, broadcaster material, etc

A suitable programme might be something like “Holiday: You call the shots”, a BBC
programme where individuals are able to comment on particular holiday destinations.




                                                77
5.5.2   System Components



                                                                        Network   6
                                                                        Storage
                        TVA          5
                        Data
                       server




   4


                                                      2


                                         STB
                                 3                            STB
         1                                                          7
                                               STB
                                                      7




                                                      STB




Figure 5.6 System components

System components include:

        1. Share it! network

        2. Open, visible, managed user group (programme themed), with broadcaster
           provided portal.

        3. Share it! box

        4. Broadcast programmes

        5. TVA format data service provides metadata & content resolution for broadcast
           programmes over IP

        6. Network Storage

                           i. large capacity disk

                        ii. hosts content for third parties

                       iii. hosts popular network content

                       iv. copy content to peers (both non-real and real-time transfer)

        7. Other peer boxes within the group offering home-produced and recorded off-air
           content

                                                 78
5.5.3     Walkthroughs
When it comes to a demonstration system, it is useful to have an idea of particular
walkthroughs, or ‘scripts’ that make clear the functionality being shown.

There are two possible ways into the following walkthroughs:

    (1) When watching the programme around which the user group is based (e.g. “Holiday:
        Venice”), the user presses the ‘red’ button to enter the user-group world and access
        related content.

    (2) Using the resident-in-box search mechanisms (e.g. for “Venice”), the user is
        presented with the name of the managed user group, and when selected, the box
        launches the broadcaster provided portal.

5.5.3.1       User receives suggestions
User watches a programme and is offered broadcaster suggestions for related content
available on the Share it! network. Whilst watching a TV programme, the user group portal
offers related content that’s available in the Share it! network. Related content might include:

          •     recently broadcast programmes available from peers (presumably only presented
                if it exists within the peer-to-peer network and is available (in a rightful way) to the
                box. (e.g. a history programme about Italy, local weather forecast for that region)

          •     network stored material (e.g. an up-to-the-minute weather report for the region)

          •     home produced content available in the network that has been reviewed and
                catalogued by the broadcaster (e.g. ‘good’ examples of amateur video)

5.5.3.2       User searches for peer-hosted group content
User searches for and views peer-hosted moderated group content via service provider portal

In response to a user search, results are returned offering content hosted on other peers
belonging in the managed group. It’s presented to the user via the user group portal. Related
results might include:

          •     home produced content available in the network (e.g. favourite tourist sites, a
                family’s recent holiday video)

          •     broadcast material that’s been recorded by a peer and published to the group.

5.5.3.3       User searches for network-hosted group content
User searches for and views moderated group content hosted on network storage via service
provider portal.

In response to a user search, results are returned offering content hosted by a network
storage device. In the case where results are presented for pay-for content, a rights
resolution / payment process may have to be performed. Results might include:

          •     Network hosted third party or broadcaster produced content (e.g. a ‘Learn Italian’
                programme which is hosted by the Telco for a third party).

          •     Network stored home-produced content that has been cached by the service
                provider (e.g. one of the most popular pieces of content in the group).




                                                    79
5.5.3.4       User submits content
User submits content to the moderated user group, via service provider portal. User posts
content to user group via a user interface provided to the box. Content might include:

          •     home produced video (e.g. some footage of a favourite restaurant in Venice)


5.5.4     Requirements
          •     Service provider user group portal (this may be MHP xLet and API to Share it!
                functionality) including:

                    o   Customisable ‘look and feel’

                    o   Access to other ‘network services’ and/or data, e.g. recommendation
                        service

                    o   API to group functionality (subscribe to group, search for content within
                        group, submit content advertisement to group, view group content)

          •     Live streaming from network storage to peer box.


5.5.5     Issues
          •     Authentication / certification of user groups

          •     Live streaming from network storage to peer boxes

          •     Provision of user group portal (code driven vs. data driven)

          •     What does moderated user group actually mean? –

                    o   Only one peer (the moderator) can post advertisements for content

                    o   One peer (the moderator) posts advertisements on behalf of others after
                        editorial decisions

                    o   All peers can post advertisements, and the moderator can remove
                        inappropriate ones

                    o   Content cannot be changed after broadcaster promotion


5.5.6     Opportunities for each party
For the broadcaster

•   Increased access to content by the viewers, including archive and extra material

•   Increased connectivity between different media types

•   New forms of interactive content, supported by the widespread use of high quality AV
    material

For the network operator (Telco)

•   High quality content complements broadband access services

•   Leverage position as a distribution channel for audio-visual content


                                                   80
•   Hosting of content

•   Increase access to content

•   Certification of content

For the viewer:

•   More engaging/richer experience

•   Simplicity of access (seamless) to media from multiple sources, including broadcaster
    streams, other peers and third parties

•   A way to contribute content to a user group, and perhaps earn some kind of ‘credit’ or
    ‘reward’.

•   Education & information


5.5.7   Role of each party
For the broadcaster

•   Managing user group

•   Authoring MHP application as user group portal, tied to group and content

•   Pushing content to group

The network operator

•   Network storage of broadcaster content

•   Network storage (hosting) of third party content

•   Pushing content to group through a group portal

The concepts of mobile remote control and automated caching of content are possible
extensions to these features.


5.5.8   B2: Audience research
The Audience Research service demonstrates the positive possibilities for broadcasters that
are offered by the Share it! system. Chapter 3.3 looked at some of the potential
consequences for broadcasters of a Share it! network. The system's capability to help gain a
more in depth understanding of viewing behaviour and the use of shared content may have a
strong value to broadcasters. Also for the viewer new broadcast models can be set up to
specifically reach the target audience. Furthermore the addition of the always-on-line
connectivity of the return channel is demonstrated through the use of simple instant
messaging functionality.




                                              81
    5.5.9   System components


                      TV
RC




                                                                                   1


                     STB                                     STB                   acquired audience
                                all audience research                              research data
                           2        data (per peer)



                                                            STB
3
                                                                                   broadcaster
                               open, managed user group                            certificates (P3P)
metadata
 server
                                                                                    non-profit trusted third party


                  DVB-MHP

                  Object                                       request “own”

                                                            set of audience data
     broadcaster1 with certificate (P3P)
     broadcaster2 with certificate (P3P)

                   play-out    4



                 broadcaster             broadcaster           broadcaster



    Figure 5.7      System overview

    To show this functionality, the following elements are defined:

        1. Server (P3P, statistics) hosted at a broadcaster or non-profit third party that is
           interested in the audience behaviour/network usage information as related to specific
           content. The server attractively shows the gained information by displaying different
           graphs, etc.

        2. Multiple Share it! devices (with locally stored content as well as connected to a DVB
           system)

        3. TVA metadata server for resolving CRIDs and schedules (as used for statistics)

        4. DVB system play-out for broadcasting content/carousel, mimicking the normal
           operation of a broadcaster.



                                                      82
Also shown in the picture are multiple Xlets belonging to multiple owners (broadcasters) that
gather the information they are interested in and are allowed to gather.

To make this scenario understandable for demonstration purposes, the Xlet shows the P3P
certificate to the Share it! users and asks the user to rate the programme he or she is
watching at that particular moment. All of this information will be bundled and presented at the
server side, where it is showed instantly.


5.5.10 Walkthroughs
Many of the technicalities are difficult to show because it is rather technical or simply not
visible. However, even if this functionality cannot be shown directly on the set-top box, it can
still be shown indirectly through an interface to the back end server that collects the audience
research data and using an demonstration Xlet showing the use of P3P profiles. In this way
we are able to demonstrate functionality that is essential to the broadcaster/network provider
as well as for the viewer.

Two main elements of the demonstration are:

    1. Normal feedback about the current programme a Share it! user is watching from a
       specific broadcaster.

    2. Passive feedback (i.e. bulk data acquisition) to gain all the viewing behaviours of all
       users on the Share it! device to assist audience research.

We can demonstrate the Share it! functionality from three different perspectives, i.e. from the
perspective of the viewer, from the perspective of a broadcaster and from the perspective
from within the the Share it! system.

The actual demonstration will be done in the following way: for the demonstration we will be
playing out a DVB service with three channels running in it: channel A, channel B and channel
C. Channel A can be any channel, and has no real function in the demo other than to serve
as a starting point. Channel A has no P3P security policy attached to it nor an Xlet is
associated with it. Channel B runs a programme (e.g. NOS News) with an IM Xlet attached to
it, Channel C runs another program with an IM Xlet attached to it.

5.5.10.1 The end-user perspective
First we demonstrate the perspective of the viewer. We will be doing this on two set-top
boxes, in order to emphasize the sharing functionality. When the demonstration starts box 1 is
tuned to channel A and box 2 is tuned to channel C.

We start the demo on box 1:

We tune to channel B. As channel B’s programme/CRID has a P3P policy attached to it, the
resident functionality of the box will present the viewer with the P3P certificate. The user is
encouraged (default is accept, other choices are reject or accept always) to accept the policy
in order to participate in audience research. After the policy is accepted or rejected the
channel is displayed and the broadcaster hosted IM Xlet is started (broadcaster look and
feel). From the Xlet on box 1 the viewer on box 2 is contacted with an invitation to watch
some specific content (e.g.: “Dario >>>> Hey Jarl, this is the best goal ever!”). The user on
box 2 is selected from the resident address book.




                                              83
Meanwhile on box 2:

Box 2 is tuned to channel C (see above). Box 2 also has a broadcaster hosted IM Xlet
running. Hey that’s a coincidence a message is coming in! It’s a message of Dario suggesting
we (Jarl) watch this great goal. We decide to watch the goal … the CRID is resolved and
because the P3P policy of the clip differs from the P3P policy of the current service (Channel
C), a P3P certificate dialog pops up to present Jarl with the policy for consuming the content.
After accepting the policy Jarl watches the clip.

For recording content where a specific – not accepted before – P3P policy is attached to, the
above method can result in not recording the content. Therefore when scheduling content, the
content owner for the content to be recorded should be resolved. When it is clear that the
content to be recorded has a policy that has not been granted before, the user should be
informed and accept it on beforehand.

5.5.10.2 The system perspective
After the demonstration of the user perspective the inside system perspective is shown. The
system perspective can be shown at a server side; it gives us a more detailed insight as to
what information is transferred per box. For this we manually import and display the audience
research data from both settopboxes. In this way we can actually demonstrate what is the
difference between accepting and not accepting a certain policy. This can be compared to
port sniffer functionality as this is used in current computer networks.

If a user rejects certain P3P policies one cannot see any information being transferred. In our
example however we do see on box 1 (because the user accepted the P3P policy of channel
B) that the user views a specific CRID. Because the user on box 1 sends an invitation to box
2, the CRID of this content is monitored as well.

We would be interested in box 2 (because we know the user accepted the policy for channel
C), once the user gets the message from box 1 to view ‘the best goal ever’ the CRID
assigned to this is monitored as well and can thus be seen at the server side.

5.5.10.3 The broadcaster perspective
This perspective is implemented on the server side as well, but does not give us a look ‘under
the bonnet’. This perspective shows us the possible information a broadcaster/content owner
can see when audience research data is gathered. As mentioned before, different levels
apply as to whether the user of this perspective is a broadcaster or a non-profit third party. On
the server side all sorts of statistics relevant to the broadcaster can be shown, e.g. how many
times certain content was played back, at what time the content was consumed, how many
times was it shared (equals efficiency of super distribution), etc.

As a nice demo feature we should be able to see after a day of demonstrating at what time a
demo was given, how many times the demo was given (which should be equal to the number
of times the content of box 1 was shared with box 2), etc. The statistics are presented in an
attractive way with nice charts and are updated instantly to reflect current ongoing
demonstrations (this is very important for the demo’s credibility).




                                               84
5.5.11 Requirements
The information that is of interest for this demo and should therefore be logged is:

- Recording

- Viewing

Both points can be described more elaborately:

Recording
Recording is not limited to recording a live broadcast. It also covers the acquisition of content
shared by other Share it! users. The last issue can be viewed at two sides:

    1. the side of the user that shares the content

    2. the side of the user that acquires the content

By monitoring both sides of the sharing process third party service providers (KPN, Elisa, etc.)
can gain a view on where bottlenecks exist, which allows them to take appropriate measures
by adding capacity (like NDRs) to specific parts of the service delivery network. Even tracing
content is possible in this way, using session keys can even reveal the path the content took
as well [12]. This however might give rise to issues concerning privacy, since the exact path
of the content can be traced (and thus also the individual user consuming the content).

Viewing
Viewing does not only mean viewing of live broadcasts. It also means viewing of a recorded
broadcast.

By acquiring both the recording as well as the viewing behaviour related to the content, the
broadcaster can keep track of which programmes are watched when. Programmes that are
only recorded without being played back later may also be of interest for the broadcasters.

The acquisition of these events is gathered at the box side by some resident functionality that
is running when the Share it! device is powered on. The level of detail and amount of events
returned by the device depends on the rights of the broadcaster that requests the events. A
superuser non-profit third party can obtain all events, while a broadcaster can only obtain the
events that correspond to their own broadcast content.

How all of the above events are actually stored is not interesting from a broadcaster’s point of
view. The only thing the broadcaster’s Xlet is using for retrieving their specific events is an
API. This is discussed in much more detail in [13] and the corresponding references.

API-requirements
API that allows downloaded Xlets to gain access to the viewing behaviour in respect to their
content.


5.5.12 Issues
To avoid security issues, the P3P protocol may be a solution. Different certificates (even
those that do not gain access to user behaviour at all) could then to be sent to Share it!
devices to show that not everyone is allowed to gain access to this information.




                                               85
5.5.13 Opportunities for each party
For the service provider/broadcaster

- Targeting specific user groups and more in-depth statistics as related to the content
broadcast.

- Conditional access based on security policy (this will allow for new broadcast models).

- Broadcasters can still have control over what is happening to their content, even if it is
travelling trough the p2p network.

- Tool to monitor the effects of p2p content sharing (superdistribution).

For the network operator

- Capability to monitor network traffic to optimise infrastructure capacity/organisation.

For the viewer

- A way to give feedback to the broadcaster/service provider about the content broadcast.

- Better programme offerings due to a more detailed knowledge of target audience.

- Assurance of privacy-protection due to the use of P3P policies.


5.5.14 Role of each party
The service provider/broadcaster

- Managing and presenting the user information gathered on the server side.

- Encouraging the user to give feedback about the current programme they are watching.

The network operator

- Encryption/decryption of data

- Hosting shared content (NDR)

The viewer:

- Participate and help broadcasters by providing feedback for content he or she watches.




                                                86
5.6     Scenario C: Creating, editing and publishing by viewers

5.6.1    Overview of end user services
The scenarios presented in this section utilise downloadable applications (MHP Xlets) and the
features offered by the Share it! system to provide the end users with an enhanced content
sharing experience. They can share their own home-grown content with other users and
enhance third party content.

The key components which differentiate these scenarios from those in the other categories
are:

         1. Home-grown content

         2. Local end-user application to import, bundle, annotate and publish content


5.6.2    System Components




                                      5
                                               Broadcast



               TV




                                           Family & friends

        1      STB / PVR

                                MHP Xlet   2
                                                                             STB
        3
             Camera
                           RC                         4       STB




Figure 5.8          System components overview

System components include:

         8. Share it! box including PVR functionality

         9. Downloaded or resident application (MHP Xlet) to bundle and/or annotate content

         10. Digital camera to import home-grown content

         11. Other peer boxes to share the content with

         12. Broadcaster




                                                 87
5.6.3     Walkthroughs
This category of scenarios which all involve the end user as content provider can be split into
two sub-categories:

          1. Creation, bundling and sharing of users own content

          2. Annotation of existing content, either created by the user or from other sources

For each of the sub-categories a number of different scenarios can be envisaged. The
following walkthroughs describe a short selection that is most suitable for demonstration
purposes.

          1a. A single picture taken with a digital camera is sent to another Share it! user
              together with a short introductory message

          1b. More complexly structured personal content is shared with other Share it! users

          1c. Mixture of own content and content owned by other parties

          2a. Indexing of a pre-recorded stream in order to provide easy access to the sections
              which might be of special interest for the recipients

          2b. Annotation of a pre-recorded stream with additional content

          2c. Annotation by means of predefined text annotation provided by a service
              provider/third party

5.6.3.1    Picture with short message
A single picture taken with a digital camera is sent to another Share it! user together with a
short introductory message. This scenario is based on the bundling mock-up with regard to
the address book and publishing.

    •     The user has taken a picture which he would like to share with other family members.
          He connects the camera to his share it! Box.

    •     Automatically an Xlet pops up which allows the download of pictures from the camera
          into the box. The user can select from the list of available pictures the ones he wants
          to share.

    •     By means of the resident address book he can select the recipients.

    •     The resident publishing component allows him to specify the text for the content
          announcement.

    •     The content announcement is sent to all recipients and will pop up on their TV. Finally
          the recipients can retrieve and view the corresponding content.

5.6.3.2    Complex content shared with other users
Content with a more complex structure (e.g. a bundle with a whole slide show) is sent to other
Share it! users. This scenario is based on the content bundling mock-up (paragraph 4.1.12).

    •     The user has a number of pictures and videos from his last holiday that he wants to
          share with his friends. He has already stored all the material on the Share it! box.

    •     By means of an Xlet (downloaded or resident) he creates a content bundle which
          refers to the individual content items and structures them in a certain way.


                                                 88
    •     The steps for publishing the bundle including the content announcement and retrieval
          of content are the same as above.

    •     The recipient of the bundle can finally browse through the content along the pre-
          defined structure.

5.6.3.3    Mixture of home-grown and third-party content
Publishing of bundle assembled from a mixture of home-grown and third party content. This
scenario is based on the content bundling mock-up (paragraph 4.1.12).

This differs from the previous scenario only with regard to the source of the content. The tools
and steps described above will also cater for bundling and publishing any kind of content, e.g.
everything related to your favourite artist for all other fans. Instead of selecting individual
recipients from the address book, he might choose a user group. For demonstration purposes
it will be too time-consuming to show the generation of a complex bundle from scratch,
therefore an existing one will be extended.

5.6.3.4    Indexing of a stream
Indexing of a stream in order to provide easy access to the sections which might be of special
interest for the recipients. This scenario refers to the annotation mock-up (paragraph 4.1.13)

    •     The user has recorded a soccer game. He knows that his best friend would also be
          interested in watching it but neither has the time to watch it live nor to watch the full
          game later on. Therefore he uses the annotation tool (resident or downloaded) to
          mark the most interesting scenes such as the goals.

    •     Afterwards he publishes the recorded video together with the index markers as
          described above (selection of recipient from address book, content announcement
          which explains the semantics of the index information)

    •     The recipient can retrieve the video and the index information from the originators
          box. He can still watch the full video if he likes to, but can also use the index
          information to skip to the most interesting scenes.

Depending on the available content, the index information could also point to the best jokes in
a comedy, favourite songs in a show, or highlights from my last holidays.

In addition to indexing videos from the broadcast the user will also be able to index home-
grown content from the camcorder. However, for demonstration purposes pre-stored videos
will be used.

5.6.3.5    Provision of additional content related to an indexed video
In the previous scenario the only explanation for the purpose of the index information is given
in the content announcement. The originator might also choose to provide some additional
content related to an index. This could be text or audio annotations as well as additional
audio/visual information, e.g. extending a travel programme by providing the originators own
material of the same place. Subtitling would be a special case of this scenario. The annotation
tool utilised in the scenario above also allows the user to add locally stored content to an
index and publish it together with the video and the index information as described above.
While the video is played at the recipient’s side the additional content will automatically pop
up when the corresponding index is reached. The duration for which this content is visible is
an attribute of the index. This scenario also refers to the annotation mock-up (paragraph
4.1.13)




                                                 89
5.6.3.6       Use of pre-defined annotations that are provided with the broadcast
              programme
One example is the annotation of a soccer game by means of pre-defined text annotations as
demonstrated by the NOB mock-up (paragraph 4.1.7). The idea here is to provide a
community-based service that has an extremely low threshold for participation. By pre-
defining the annotations with the broadcast, the end-user can express his opinion with a
single key-press.

Basically this service can be seen as a combination of current-day polls (asking a viewer to
express his opinion on a certain topic) and chat-functionality. The difference however is that in
our scenario the broadcaster injects annotations in a user-group to facilitate easy
expressiveness. Also the annotations may be branded, styling the messages to create a
connection between the broadcaster and the user-groups.


5.6.4     Requirements
•   Access to other devices to import content, like a digital camera for pictures

•   Ability to publish home-grown content including rights management

•   Ability to send content announcements

•   Address Book with support for individuals and groups

•   Notification if the user receives a content announcement

•   Download content from other Share it! boxes

•   Download applications from a service provider and other Share it! boxes (e.g. bundle
    viewer)

•   Creation of bundles of content of different media types including layout information

•   Distribution of such bundles, either together with player application or as a “standardised”
    Share it! format which each box can play.

•   Indexing of recorded videos

          o     Ability to create and store index information.

          o     Ability to provide additional information (text, image, video annotations)

          o     Create an event/notification to an application when a stream reaches an index
                (needed for viewer application)

•   Publishing of indexed videos

•   Handling of multimedia content stored locally on the box with an Xlet
    (save, play, stop, pause, resize played video, copy, move …)


5.6.5     Issues
          •     None foreseen yet.




                                                   90
5.6.6   Opportunities for each party
For the service provider

•   Increased access to content by the viewers

For the viewer

•   More engaging/richer experience in communication with family and friends


5.6.7   Role of each party
The end user

•   Provide home-grown content

•   Annotate content

•   Bundle various types of content from different sources

•   Publish content

The service provider

•   Provide content to all users

The network operator

Encryption and billing services




                                             91
Bibliography
[1]    WP1, deliverable 1, Share it! System Usages Scenarios & End User/Service/Content
       Provider Requirements System Requirements, Share it!, 31 May 2002.

[2]    http://www.sonicblue.com/video/replaytv/default.asp
       (formerly http://www.replaytv.com)

[3]    TV-Anytime Specification SP004 v1.1, ,the TV-Anytime Forum, http://www.tv-
       anytime.org

[4]    TV-Anytime Specification SP003 v1.1, ,the TV-Anytime Forum, http://www.tv-
       anytime.org

[5]    WP1, Share it! System Usage Scenarios, internal Share it! project document, “Share-
       it-uol-25feb02-WP1 Usage scenarios-1.0-bm.doc”, Share it! project internal web
       page, alternatively contact bostjan.marusic@fe.uni-lj.si

[6]    WP4, UI Style Guide, FhG & UoL, Share it! project internal web page

[7]    First draft for D2 section on API’s (paragraph 3.4), D2-APIs-FhG.doc, 21-6-2002
       (provided on reflector).

[8]    WP2, deliverable 2, Box architecture and interoperability test, Share it!, 30 August
       2002.

[9]    ‘Share it! demonstration plan’, John Morris (Philips), 18 September 2002

[10]   ‘An information model to progress the role of user groups and rights management in
       Share it! v1.1’, Colin Davies and James Walker (NDS), 23rd September 2002

[11]   ‘The Networked Service in Share-it! discussion document v.4’, Eric Boertjes (KPN),
       31st October 2002

[12]   Technology for Share It Rights Processes as sent to the Share it! reflector on 1st
       November by Alex Ashley of Philips.

[13]   Audience research plans – fresh thoughts and improvements as sent to the Share it!
       reflector on 2nd October by Dario Buma of NOB.




                                             92
A       Annex
A.1     Abbreviations and terminology

Name / Acronym                  Description

ADSL                            Asymmetric Digital Subscriber Line

API                             Application Programming Interface

CARP                            Cache Array Routing Protocol

CDP                             Cache Digest Protocol

DSLAM                           Digital Subscriber Line Access Multiplexer

NAT                             Network Address Translation

NDR                             Network Digital Recorder

FTP                             File Transfer Protocol

ICP                             Internet Cache Protocol

PC                              Personal Computer

PDR                             Personal Digital Recorder

PVR                             Personal Video Recorder

QoS                             Quality of Service

TC                              Timecode

User data collection            See paragraph 3.1.1

UI                              User Interface

User profile                    See paragraph 3.1.1

VDSL                            Very high bitrate Digital Subscriber Line

WCCP                            Web Cache Coordination Protocol

Table A.1       Terminology used in this document.




                                            93

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:21
posted:9/8/2011
language:English
pages:93