ETSI TS V1.4.1 ( ) Technical Specification

ETSI TS 102 822-2

V1.4.1 (2007-11)

Broadcast and On-line Services: Search, select, and

rightful use of content on personal storage systems

("TV-Anytime");

Part 2: Phase 1 - System description

E u ro p e a n B ro a d c a s tin g U n io n U n io n E u ro p é e n n e d e R a d io -T é lé vis io n

Reference RTS/JTC-TVA-PH1-25-02

Keywords

broadcasting, content, system, TV, video

ETSI

650 Route des Lucioles

F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la

Sous-Préfecture de Grasse (06) N° 7803/88

Important notice

Individual copies of the present document can be downloaded from:

http://www.etsi.org

The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive

within ETSI Secretariat.

Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at

http://portal.etsi.org/tb/status/status.asp

If you find errors in the present document, please send your comment to one of the following services:

http://portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification

No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2007. © European Broadcasting Union 2007.

All rights reserved.

DECTTM, PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the benefit of its Members. TIPHONTM and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members.

Contents

Intellectual Property Rights ...6

Foreword...6

Introduction ...7

1 Scope ...8

2 References ...8

3 Definitions

and

abbreviations...9

3.1 Definitions ...9

3.2 Abbreviations ...11

4

TV-Anytime system architecture...12

4.1 Content referencing rationale ...14

4.2 Phase 1 Metadata rationale...15

4.3 Phase 2 Metadata rationale...15

4.3.1 New content types...15

4.3.2 Packaging...16

4.3.3 Targeting...16

4.3.4 Interstitial content ...17

4.3.5 Sharing...17

4.3.6 Remote programming ...17

4.3.7 Interchange data format ...17

4.3.8 Coupons ...18

5

TV-Anytime content referencing scenarios ...19

5.1 Content referencing key concepts...19

5.2 Content referencing and unique content identification...19

5.3 CRID issuing Authority and resolution providers ...20

5.3.1 Third party extension to static reference model ...20

5.4 CRID issuing and resolving scenarios...21

5.4.1 CRID originated by content creator, resolved by content creator...21

5.4.2 CRID originated by content creator, resolved by content service provider ...22

5.4.3 CRID originated by content creator, resolved by third party ...22

5.4.4 CRID originated by content service provider, resolved by content service provider...23

5.4.5 CRID originated by content service provider, resolved by third party ...23

5.4.6 CRID originated by third party, resolved by content service provider ...23

5.4.7 CRID originated by third party, CRID resolved by third party ...24

5.5 Example of coding an ISAN using a CRID...25

5.6 The relation between CRID and instance metadata...25

5.7 CRID lifecycle...26

5.8 Harmonization of TS 102 822-4 and TS 102 822-6 ...28

6 Metadata ...28

6.1 Introduction ...28

6.2 XML - a common representation format ...29

6.3 The TV-Anytime metadata high level documents ...29

6.3.1 Metadata structure...29

6.3.2 Phase 1 Metadata ...30

6.3.2.1 Content description metadata ...30

6.3.2.2 Instance description metadata ...31

6.3.2.3 Consumer metadata ...32

6.3.3 Phase 2 metadata...33

6.3.3.1 Schema overview ...33

6.3.3.2 Phase 2 as an extension to Phase 1 metadata tools...33

6.4 Documents related through the CRID ...34

6.4.1 Grouping ...34

6.6 Mandatory and optional elements ...35

6.7 Delivery of metadata over a unidirectional environment ...36

6.8 Notes on Schema Extension ...37

6.8.1 Polymorphism of existing type by inheritance with extension ...38

6.8.2 Polymorphism of existing type by inheritance with restriction ...38

7

Phase 1 cookbook examples and scenarios ...39

7.1 TV-Anytime dynamic processes ...39

7.2 Phase 1 example: Record every episode of this programme series in the broadcast case ...39

7.3 Phase 1 example: Record highlights from a football match via an EPG ...44

7.4 Phase 1 example: Select a particular showing of a programme from an EPG (in the broadcast case) ...47

7.5 Phase 1 example: Allow the user to select content from an on-demand content offer with associated pricing information, or seek lowest cost offer ...50

7.6 Phase 1 example: Notify the user of something interesting based on their profile...51

7.7 Phase 1 example: Personal Channel Service at my PDR...52

7.8 Phase 1 example: Programme made up of segments from multiple providers and maintain the latest news on my PDR...59

7.9 Phase 1 example: Usage scenarios for bi-directional metadata transport ...62

7.10 Phase 1 example: Profile 1 bi-directional multi-provider EPG ...65

7.11 Phase 1 example: Related material recording...65

7.12 Phase 1 example: User profiling cookbook scenario and work-through application...66

7.13 Phase 1 example: RMPI descriptive metadata...70

7.13.1 Introduction...70

7.13.2 Free-to-air content...70

7.13.3 Pay-per-view content ...71

7.13.4 Video-On-Demand Content ...73

8

RMPI cookbook examples and scenarios...74

8.1 Introduction ...74

8.2 RMP system dependencies ...74

8.3 RMP concepts ...74

8.3.1 Copy control versus playback control...74

8.3.2 Targeting content consumption and usage with RMPI ...74

8.3.3 "Export Rights" as distinct from "Play Right" ...75

8.3.4 RMP / non-RMP interoperability...75

8.4 Lifecycle of RMPI...75

8.5 Compliance...75

8.6 Scenarios ...75

8.6.1 Scenario 1: Free-To-Air broadcast with no redistribution/viewing control ...75

8.6.2 Scenario 2: Free-To-Air broadcast without authorized redistribution over the Internet ...77

8.6.3 Scenario 3: Free-To-Air broadcast with content consumption constrained to a geographical area ...78

8.6.4 Scenario 4: Free-To-Air content with viewing and redistribution controls ...80

8.6.5 Scenario 5: Free-To-Air broadcast without support for legacy receivers ...81

8.6.6 Scenario 6: Free-To-Air live streaming ...82

8.6.7 Scenario 7: Scrambled Free-To-Air...84

8.6.8 Scenario 8: Pay-TV subscription with limited number of simultaneous consumptions...85

8.6.9 Scenario 9: Push Content ...87

8.6.10 Scenario 10: Pay-Per-View Content, "buy to keep" ...89

8.6.11 Scenario 11: Import of copy protected analogue content...90

8.6.12 Scenario 12: Video on Demand ...91

9 Issues

per process ...93

9.1 General system issues...93

9.1.1 Set-up and service discovery ...93

9.1.2 Language Identification ...94

9.1.3 Transport and delivery of TV-Anytime data ...94

9.1.4 Updating resolution tables ...94

9.1.5 Updating metadata ...95

9.2 "Publish" process...95

9.3 "Search and select" processes...96

9.4 "Locate" process...97

10

Phase 2 cookbook examples and scenarios ...98

10.1 Phase 2 example: New content types ...98

10.2 Phase 2 example: Packaging ...99

10.2.1 Program with an associated package ...99

10.2.2 Phase 2 example: Educational package ...101

10.2.3 Data broadcasting ...102

10.3 Phase 2 example: Targeting...104

10.3.1 User environment description ...104

10.3.2 Personalized service...105

10.4 Phase 2 example: Interstitials ...107

10.5 Phase 2 example: Sharing - metadata exchange ...111

10.5.1 Transfer profile to another device...111

10.5.2 Recommend content to a friend ...113

10.5.3 Web browsing to select content and metadata acquisition...114

10.6 Phase 2 example: Remote programming using a Networked Digital Recorder (NDR) ...115

10.6.1 NDR programming for future recording ...115

10.6.2 NDR programming for immediate recording...116

10.6.3 NDR programming for consumption by another device ...116

10.7 Phase 2 example: Coupons ...118

11

Issues per Phase 2 technology ...119

11.1 Sharing, content and metadata exchange...119

11.1.1 Content referencing and identification...119

11.1.2 Sharing Metadata ...120

11.1.3 Sharing metadata with content...120

11.2 Remote programming...120

Annex A (informative):

Example of usage history ...121

Annex B (normative):

Transport environment and requirements...123

B.1 Scope ...123

B.2

Requirements on the Uni-Directional Delivery System ...123

Intellectual Property Rights

IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in

respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web

server (http://webapp.etsi.org/IPR/home.asp).

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document.

Foreword

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European Broadcasting Union (EBU), Comité Européen de Normalisation ELECtrotechnique (CENELEC) and the European Telecommunications Standards Institute (ETSI).

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body by including in the Memorandum of Understanding also CENELEC, which is responsible for the standardization of radio and television receivers. The EBU is a professional association of broadcasting organizations whose work includes the co-ordination of its members' activities in the technical, legal, programme-making and programme-exchange domains. The EBU has active members in about 60 countries in the European broadcasting area; its headquarters is in Geneva.

European Broadcasting Union

CH-1218 GRAND SACONNEX (Geneva) Switzerland

Tel: +41 22 717 21 11 Fax: +41 22 717 24 81

The present document is part 2 of a multi-part deliverable covering Broadcast and On-line Services: Search, select and rightful use of content on personal storage systems ("TV-Anytime"), as identified below:

Part 1: "Phase 1 - Benchmark Features";

Part 2: "Phase 1 - System description";

Part 3: "Metadata";

Part 4: "Phase 1 - Content referencing";

Part 5: "Phase 1 - Rights Management and Protection (RMP)"; Part 6: "Delivery of metadata over a bi-directional network"; Part 7: "Phase 1 - Bi-directional metadata delivery protection"; Part 8: "Phase 2 - Interchange Data Format";

Introduction

"TV-Anytime" (TVA) is a synchronized set of specifications established by the TV-Anytime Forum. TVA features enable

the search, selection, acquisition and rightful use of content on local and/or remote personal storage systems from both broadcast and online services.

TS 102 822-1 [1] and the present document set the context and system architecture in which the standards for Metadata, Content referencing, Bi-directional metadata and Metadata protection are to be implemented in the TV-Anytime

environment. TS 102 822-1 [1] provides benchmark business models against which the TV-Anytime system architecture is evaluated to ensure that the specification enable key business applications. The present document presents the

TV-Anytime system architecture. These two documents are placed ahead of the others for their obvious introductory

value. Note that these first two documents are largely informative, while the remainder of the series is normative. The features are supported and enabled by the specifications for Metadata (TS 102 822-3 sub-parts 1 [2], 2 [3], 3 [4] and 4 [5]), Content Referencing (TS 102 822-4 [6]), Rights Management (TS 102 822-5 sub-parts 1 [7] and 2 [8]), Bi-directional Metadata Delivery (TS 102 822-6 sub-parts 1 [9], 2 [10] and 3 [11]) and Protection (TS 102 822-7 [12]), Interchange Data Format (TS 102 822-8 [13]) and Remote Programming (TS 102 822-9 [14]). This list of Features is to be used as guidance to manufacturers, service providers and content providers regarding the implementation of the Phase 1 and Phase 2 TV-Anytime specifications.

The present document is mainly informative and has therefore not the intention to mandate certain system

implementation solutions. Preferred solutions, from a technology stand point, will be indicated to allow implementers to build more efficient systems.

Only annex B to this document is normative and contains requirements for delivery systems being designed by users of the TV-Anytime specification for their specific operational environment.

1 Scope

The present document shows the system behaviour of a TV-Anytime broadcast system with an interaction channel used for consumer response. The present document contains examples of how to use the TV-Anytime specifications both from static and dynamic viewpoints, i.e. it will highlight the parties involved in the processes and show the interaction between them.

The present document is a cookbook or white paper to the TS 102 822-3 sub-parts 1 [2], 2 [3], 3 [4] and 4 [5], TS 102 822-4 [6], TS 102 822-5 sub parts 1 [7] and 2 [8], TS 102 822-6 sub-parts 1 [9], 2 [10], and 3 [11], TS 102 822-7 [12], TS 102 822-8 [13] and TS 102 822-9 [14].

The present document is mainly informative and has therefore not the intention to mandate certain system

implementation solutions. Preferred solutions, from a technology stand point, will be indicated to allow implementers to build more efficient systems.

Annex B to this document is normative and contains requirements for delivery systems being designed by users of the

TV-Anytime specification for their specific operational environment.

2 References

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

• References are either specific (identified by date of publication and/or edition number or version number) or non-specific.

• For a specific reference, subsequent revisions do not apply.

• For a non-specific reference, the latest version applies.

Referenced documents which are not found to be publicly available in the expected location might be found at

http://docbox.etsi.org/Reference.

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee their long term validity.

[1] ETSI TS 102 822-1: "Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems ("TV-Anytime"); Part 1: Benchmark Features".

[2] ETSI TS 102 822-3-1: "Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems ("TV-Anytime"); Part 3: Metadata; Sub-part 1: Phase 1 - Metadata schemas".

[3] ETSI TS 102 822-3-2: "Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems ("TV-Anytime"); Part 3: Metadata; Sub-part 2: System aspects in a uni-directional environment".

[4] ETSI TS 102 822-3-3: "Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems ("TV-Anytime"); Part 3: Metadata; Sub-part 3: Phase 2 - Extended Metadata Schema".

[5] ETSI TS 102 822-3-4: "Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems ("TV-Anytime"); Part 3: Metadata; Sub-part 4: Phase 2 - Interstitial metadata".

[6] ETSI TS 102 822-4: "Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems ("TV-Anytime Phase1"); Part 4: Phase 1 - Content referencing". [7] ETSI TS 102 822-5-1: "Broadcast and On-line Services: Search, select, and rightful use of content

on personal storage systems ("TV-Anytime"); Part 5: Rights Management and Protection (RMP) Sub-part 1: Information for Broadcast Applications".

[8] ETSI TS 102 822-5-2: "Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems ("TV-Anytime"); Part 5: Rights Management and Protection (RMP) Sub-part 2: RMPI binding".

[9] ETSI TS 102 822-6-1: "Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems ("TV-Anytime"); Part 6: Delivery of metadata over a bi-directional network; Sub-part 1: Service and transport".

[10] ETSI TS 102 822-6-2: "Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems ("TV-Anytime"); Part 6: Delivery of metadata over a bi-directional network; Sub-part 2: Phase 1 - Service discovery".

[11] ETSI TS 102 822-6-3: "Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems ("TV-Anytime"); Part 6: Delivery of metadata over a bi-directional network; Sub-part 3: Phase 2 - Exchange of Personal Profile".

[12] ETSI TS 102 822-7: "Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems ("TV-Anytime Phase 1"); Part 7: Bi-directional metadata delivery protection".

[13] ETSI TS 102 822-8: "Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems ("TV-Anytime"); Part 8: Phase 2 - Interchange Data Format". [14] ETSI TS 102 822-9: "Broadcast and On-line Services: Search, select, and rightful use of content

on personal storage systems ("TV-Anytime"); Part 9: Phase 2 - Remote Programming". [15] ISO/IEC 15938-1 (2002): "Information technology - Multimedia content description

interface - Part 1: Systems".

[16] ISO 8601: "Data elements and interchange formats - Information interchange - Representation of dates and times".

[17] IETF RFC 1591: "Domain Name System Structure and Delegation".

[18] ISO 15706: "Information and documentation - International Standard Audiovisual Number (ISAN)".

[19] IETF RFC 4078: "The TV-Anytime Content Reference Identifier (CRID)". NOTE: Available at: http://www.ietf.org/rfc/rfc4078.txt.

[20] ETSI TS 102 323: "Digital Video Broadcasting (DVB); Carriage and signalling of TV-Anytime information in DVB transport streams".

[21] IETF RFC 3066: "Tags for the Identification of Languages". NOTE: Obsoletes IETF RFC 1766.

[22] ISO 639: "Codes for the representation of names of languages".

3 Definitions

and

abbreviations

3.1 Definitions

For the purposes of the present document, the following terms and definitions apply:

acquisition: retrieval of content

advertising: content that is intended to promote or drive sales for products or services

application: specific set of functions running on the PDR. Some applications use metadata, either automatically or

attractor: metadata element that is accessible by the consumer in order to aid in the content selection process, thus

attracting the consumer

NOTE: Examples include the title and name of an actor in a television programme.

avail: term used in the United States to describe an individual interstitial item within for example a commercial break

also commonly known as a "Spot"

NOTE: In the UK an avail is used to refer to an interstitial break.

banner ad: traditionally used to describe images used as advertising on the world wide web

NOTE: An advertisement comprising a graphic (static or animating) and possible associated audio that is placed in association with editorial content.

bi-directional: system that allows a two-way flow of content and/or information

capture: storing the acquired content (to local storage)

consumer profile: data that represents the interests and preferences of the consumer

content: anything the viewer would like to consume (e.g. movies, games, TV programmes, radio programmes etc.)

content creator: producers of the content

content item: entity that can be acquired as a single unit e.g. AV file, Audio stream

content package: collection of Content Items, which may be consumed as a whole or individually

content provider: entity that acts as the agent for and is the prime exploiter of the content

content reference: pointer to a specific content item

control flow: system related data e.g. consumer queries, transactional information, device capabilities, profile

information etc.

data carousel: method for transmitting data over a broadcast channel in which data is cyclically transmitted

descriptor: metadata element, such as an attractor or other information about content such as the key frame index of a

piece of video

enhanced TV: television that includes additional information and/or applications related to content, but does not use a

return path

flash: popular authoring software ubiquitous on the Web used to create vector graphics-based animation programs with

full-screen navigation interfaces, graphic illustrations, and simple interactivity in an antialiased, resizable file format

free to air: broadcast content that is free at the point of consumption

NOTE: Free-to-air content can be delivered encrypted or in the clear.

functional unit: basic logical element, implementing a defined function of a TV-Anytime system

location resolution: process of establishing the address (location and time) of a specific content instance from its CRID interactive TV: television that includes additional information and/or applications related to content and which takes

advantage of a return path

interstitial: additional content that may be inserted within, at the start, or at the end of the primary content item

NOTE: This additional content includes for example advertising spots, station idents, promos and graphics.

interstitial break: terms used in the United Kingdom to design a group of interstitials shown together

metadata: generally, data about content, such as the title, genre, summary of a television programme consumer

metadata schema: identifier associated with a set of XML schemas that globally identifies those schemas so that they

can be referenced externally

NOTE: A globally unique namespace ensures that the names of types defined by schemas in that namespace do not conflict with types of the same name defined elsewhere.

metadata system: set of rules describing the syntax and semantics of metadata

non-skipable: content that is protected in a way that prevents the consumer from avoiding it by using the remote

control

pay per view: content for which the consumer had had to pay a one off fee

pod: set of Avails or Spots that form a commercial break

programme: editorially coherent piece of content

NOTE: Typically, a programme is acquired by the PDR as a whole.

programme group: one or more programmes that are grouped together

NOTE: TV Anytime defines several types of programme groups such as "series" and "programme compilation".

return path: part of the bi-directional distribution system from the consumer to service provider

segmentation: labelling of content that allows it to be broken down into separate discreet elements

speedbumps: advertising elements ( audio, video or graphics) that are superimposed on screen when a consumer selects

trick mode on a PDR

spot: individual content item within an Interstitial break (Pod)

NOTE: Also commonly referred to as an Avail. TV and Radio industry description for a unit of advertising.

skipable: content that can be missed by the consumer by using the remote control on a device

subscription TV: broadcast content that the consumer has paid for through a recurring subscription

telescope ad: long form advertising spot that is linked to from a shorter spot

transcode: technical conversion of content from one standard to another

NOTE: For example converting standard definition broadcast signal to a lower bandwidth web capable standard such as Real Media or Windows Media 10.

3.2 Abbreviations

For the purposes of the present document, the following abbreviations apply:

AAF Advanced Authoring Format

ACAP Advanced Common Application Platform

AES Audio Engineering Society

ARIB Association of Radio Industries and Businesses ATSC Advanced Television Systems Committee AV Audio-Visual

AVI Audio-Visual Interface

CA Conditional Access

CGMS Copy Generation Management System CRID Content Reference IDentifier

NOTE: An identifier for content that is independent of its location specified by TS 102 822-4 [6]. CSP Content Service Provider

DNS Domain Name System

DS Description Scheme DVB Digital Video Broadcasting EPG Electronic Programme Guide

NOTE: A means of presenting available content to the consumer, allowing selection of desired content. FTA Free-To-Air

HD High Definition

HKPDR Hong Kong Personal Digital Recorder HTTP HyperText Transfer Protocol

IMI Instance Metadata Identifier

IP Internet Protocol

IPR Intellectual Property Rights

ISAN International Standard Audiovisual Number ISO International Organization for Standardization MPEG TS MPEG Transport Stream

MPEG Motion Picture Expert Group

MXF Metadata eXchange Format

NDR Network Digital Recorder

NPT Normal Play Time

PDA Personal Digital Assistant

PDC Programme Delivery Control

PDR Personal Digital Recorder

PES Packetized Elementary Stream PPV Pay-Per-View

RAR Resolving Authority Record

RMP Rights Management and Protection

RMPI Rights Management and Protection Information RMPI-M Rights Management and Protection Information Micro

RMPI-MB Rights Management and Protection Information Micro Broadcast

RSS Really Simple Syndication

SD Standard Definition (video)

SM local Storage Management

SMPTE Society of Motion Picture and Television Engineers

SN Search and Navigation

SOAP Simple Object Access Protocol TVA TV-Anytime

TVA-RMP TV-Anytime Rights Management and Protection UDDI Universal Description Discovery and Integration

UI User Interaction

UKCP United Kingdom Content Provider

VoD Video on Demand

WAN Wide Area Networks

4

TV-Anytime system architecture

A simple TV-Anytime broadcast system can be viewed as containing three major elements: a service provider delivering the TV-Anytime service, a transport provider that carries the service and a piece of equipment in the home that stores the content and plays it back at the consumer's request. The present document examines the mechanisms behind this simple model and gives a comprehensive functional reference model. This model adapted for the pure broadcast situation is depicted in figure 1. In this figure, a clustering of functions is indicated that is especially relevant in the broadcast case: it shows the "PDR" (Personal Digital Recorder).

Consumer

Metadata

Location resolution Content

Access

User Interaction Location

Resolution Search and

navigation

Content Service Provision Content

Creation

Content Presentation

Local Storage management i3 i4

i6 i1

Figure 1: Broadcast model without rights management protection

Each of the boxes in the model is a function of the TV-Anytime system, and can be implemented in several different ways by several different service providers. Different physical implementations of the system will have different ordering of functionality in different physical devices (possibly in different locations). The present document gives a detailed description of possible system configurations. The arrows in the figure indicate information flows between functions, a complete description of these flows can also be found in the present document.

The broadcast model with a narrowband bi-directional channel supports the feature set listed in TS 102 822-1 [1]. It is a pure broadcast model as far as content and associated data is concerned. In this broadcast model only three system functions are external to the PDR: content creation, content service provision and access. The bi-directional green link between user and service provider can be used to get usage history data or preference data from a consenting user. A movie studio or entertainment company could fulfil the role of content creator. A broadcaster would typically handle the repackaging, addition of metadata and broadcasting of the content: the content service provision function. A cable or satellite operator typically provides the access. The remaining functions reside in the PDR. The PDR can be considered as a real device at the consumer's premises that allows him to store and view content. In figure 1 the PDR is the grey area encompassing functions search and navigation, location resolution, user interaction, content presentation and local storage management.

This system will allow the user to search, select, locate and acquire content that he likes. The search and selection, e.g. by an EPG, will be on the basis of broadcast metadata that advertises the available content. One or more parties can put this metadata in the broadcast: the broadcaster, the content creator or a third party. The third party is not modelled in figure 1. An extension of this model showing third party operation will be discussed in clause 5.3.1.

The search and navigation will result after user or automatic selection in a Content Reference ID (CRID). The

resolution function in the PDR, using the previously obtained content reference ID, results in a physical location of the content (e.g. a particular channel and time). Location resolution data must have been broadcast to allow the PDR to actually perform this translation from reference ID to in this example physical channel and time. The interfaces on the PDR will be subject to the appropriate rights management and protection policies that will be defined in a later version of the TV-Anytime specification series.

The "full interactive model" features are also described in TS 102 822-1 [1]. In this situation (see figure 2), the

TV-Anytime consumer has a bi-directional link to other system functions like content service provision or search and

navigation. In this case the following system functions could be external to the PDR: search and navigation, location resolution, content provision, content creation and access. Access will typically be provided by a telecommunications operator, there may however also be a broadcast operator providing a broadcast access function. Content creation can be done by entertainment companies as in the previous example, web designers or other interactive content designers (or even consumers!). Content service provision can be done by several parties e.g. webcasters, broadcasters, portal providers etc. The search and navigation function could be provided by a "web-EPG company" or TV-portal company. Location resolution could be done by a similar party. This is a new role or party that arises from this scenario. The PDR contains Storage, Content Presentation and User Interaction functions in one device.

The rights management and Protection part visualized in the figure is covered in TS 102 822-5 sub-parts 1 [7] and 2 [8], and TS 102 822-7 [12].

Access

User

Interaction

Location

Resolution

Search and

Navigation

Content Service

Provision

Content

Creation

Metadata

Control

Content

Content

Presentation

Local Storage

Management

Rights Management and

Protection

Consumer

PDR

Figure 2: Full interactive model

4.1

Content referencing rationale

The purpose of content referencing (TS 102 822-4 [6]) is to allow acquisition of a specific instance of a specific item of content. For example, if a consumer sees an announcement on TV saying "there will be a new series on "Foxes in the cold" around Christmas", he may want to instruct his Personal Digital Recorder (PDR) to record the whole series. However the actual time and channel of airing of the episodes might be unknown to the PDR. In fact, the broadcaster may not know yet either. Still the viewer will want to make sure at this point that he does not miss the opportunity to acquire the content.

The ability to refer to content (in this example a series of programmes) independent of its location will provide this capability desired by the consumer. Whether that location is on a particular broadcast channel on some date and time, or on a file server connected to Internet, or wherever.

In this example, the PDR system would be provided with a reference for the series. In due time, the information required to link this reference to the individual episodes will be supplied to the PDR. Subsequently a specific date and time for each episode would be provided, so that the PDR would be able to acquire all of them.

This example demonstrates the purpose of content referencing - to provide the ability to refer to content independent of its location, and the ability to subsequently resolve such a reference into one or more locations where the content can be obtained.

4.2

Phase 1 Metadata rationale

Users or user-agents want to choose programmes to watch or record. To make that choice they need information like what is the title of this programme, what is it about, who are the actors, is it sci-fi? On the other hand, programme makers want to attract users to their content, by providing similar information. That is where metadata comes in: it is descriptive data about the content the user wants to consume. TV-Anytime content-related metadata (TS 102 822-3 sub-parts 1 [2] and 2 [3]) is based on that assumption and is therefore largely "attractor" metadata, its goal being to provide choice to the user and means to service providers to advertise their content and services.

Clause 5 describes content referencing and the actors involved. Clause 6 describes the available metadata tools and their uses. Example walkthroughs and specific comments describing the dynamic system behaviour in the different processes of a TV-Anytime service lifecycle are described in clauses 7 and 8, respectively.

In complement to descriptive metadata, the purpose of RMPI metadata (TS 102 822-5-1 [7]) is to allow the customer to know about the rights associated with content before purchase. The RMPI metadata does not contain the actual rights bound to the content but is supposed to be an exact transcription of these rights.

Table 1: Phase 1 enabled feature set by TS 102 822-4 [6] and TS 102 822-3-1 [2]

Model 1 - Broadcast Model Support

Use of EPG to find and capture broadcast content. Full

Search and selection of on-demand content with associated pricing information. Full

Capture and playback of audio, video and data (AVD). Full

Cross linking of A/V content to related content. Part

(see note 1)

Support of consumer preferences. Full

Content can be updated/replaced by newer in-coming versions. Part (see note 2)

Support for a variety of broadcast content types. Part

(see note 3)

Support for all broadcast delivery mechanisms. Full

Multi-user preference support. Full

Model 2 - Consumer Response Model. Support

Updated listing/capture data can be delivered to "broadcast" analogue personal recorders. (via return path or other mechanism).

Full Updated listings/capture data can be delivered to "broadcast" PDRs. Full

Verification of usage of content on PDR. Part

(see note 4)

Ability to collect usage data. Full

NOTE 1: Various types of content can be cross-linked using MediaLocator (see TS 102 822-3-1 [2]).The programme metadata does not contain a CRID for cross-linking to other programmes.

NOTE 2: Entire programmes can be overwritten, but segments of programmes cannot be overwritten. NOTE 3: See TS 102 822-3-1 [2] for a list of supported content types.

NOTE 4: Access to usage data is not specified by the current tools.

4.3

Phase 2 Metadata rationale

4.3.1 New

content

types

TV-Anytime Phase 2 supports new content types other than linear audio/video such as games, web pages, music files,

graphics, data and many other applications. These new content types are treated on their own as non A/V programs and/or as components of a package (see the next clause).

4.3.2 Packaging

TV-Anytime Phase 2 defines a technology called packaging (TS 102 822-3-3 [4]) that enables the combination of

different types of content items such as games, applications and interstitial content with audio, video, still images and text, to create a new user experience.

A package consists of a collection of content items that are intended to be consumed together in some combination to provide various consumer experiences.

For example, one could have an audio-visual French language course with an accompanying word game to better learn the French language.

Package description metadata also provides a mechanism to express the options for consumption depending on usage environment (device) and user preference (user). This is further detailed in clause 4.3.3 on targeting.

Additionally, package description metadata describes synchronization (temporal) and spatial information between content items to allow content to be consumed as the content creator intended. Owing to synchronization information, multi-stream experience (e.g. multi-camera sports, or alternate audio and video documentaries) can be provided with content packaging.

Figure 3 describes how the Phase 2 packaging technology fits in with the existing TV-Anytime Phase 1 technologies.

Figure 3: Packaging and Phase 1 technologies

4.3.3 Targeting

In brief, targeting (TS 102 822-3-3 [4]) can be defined as automatically matching and delivering relevant content to profiled consumers. There are two types of targeting, which are push targeting and pull targeting. In push targeting, broadcasters transmit content with associated metadata to be used in targeted substitution based on user profile, preference, usage history, environment and other variables. In pull targeting, an intelligent agent in the PDR uses user preferences and other attributes to selectively play and record content.

In both cases, the user profiles, preferences, usage history, and environment descriptions should be available either in the PDR or at a server.

4.3.4 Interstitial

content

TV-Anytime Phase 2 TS 102 822-3-4 [5] now targets more advanced concepts such as the ability to perform interstitial

replacement at playback time based on a number of criteria. The criteria to be used for the control of what content should replace what, may be explicitly declared using the schemas defined within TS 102 822-3-4 [5].

The interstitial content specification does not attempt to define all the possible ways in which a broadcaster may wish to control their system, but provides a generic framework into which a broadcaster can define their own platform specific rules, which are used for interstitial replacement control.

4.3.5 Sharing

Once content or metadata is acquired it is natural to want to share it in a rightful manner. Users want to tell others about interesting content they have found, configure other devices so that they are personalized for them, and perhaps even transfer the content to other devices or other users. TV-Anytime Phase 2 specifications include some specific extensions to support sharing of metadata.

The TV-Anytime specifications explicitly support the exchange of user profiles (TS 102 822-6-3 [11]) and the transfer of content-related metadata (TS 102 822-8 [13]). The specifications do not cover all use cases regarding sharing of content as there are many different ways of implementing this. Indeed, there are several issues of substance that only actual implementations can provide detail on how the specifications will be used.

4.3.6 Remote

programming

The purpose of remote programming (TS 102 822-9 [14]) is to allow the consumer to programme a recording of content from another device.

For example, if the consumer is interested in two programmes which overlap in time and his PDR does not have the resources available to cope with this situation, the remote programming specification will allow him to make use of an NDR (Network Digital Recorder) to record one of the programmes and make it available later.

The same solution will be useful when the consumer is out of home and has no possibility to access their home PDR from outside.

4.3.7

Interchange data format

As illustrated in figure 4, the purpose of the Interchange Data Format specification (TS 102 822-8 [13]) is to allow the transfer of TV-Anytime metadata to a TV-Anytime compliant device from another device located in the non-TV-Anytime world.

Non TV

-

Anytime

world

TS 102 822-8

encapsulation

decapsulation

Publish Search Select Locate Acquire View Finish

TV-Anytime

data

Figure 4: Interchange Data Format

For example, if a consumer can browse an Electronic Programme Guide (EPG) available from a web site and select specific content for acquisition, then it would be convenient to obtain part of or all metadata associated with the selected content in a format which can be easily integrated with the TV-Anytime metadata already available in the PDR.

Additionally, the Interchange Data Format also allows to express an action to be done by the PDR on the transferred metadata.

For example, if a consumer selects content from an EPG using its PC in the office, a PDA or a mobile phone, he might be interested to send information associated to the content to his PDR at home with an action he wants the PDR to perform upon reception:

- "record" selected content and metadata; - record metadata only and "remind" me later; - "recommend" the associated content to a friend.

4.3.8 Coupons

A coupon is a way to provide value in an electronic form, which can be used to complement / replace money, upon purchase of content. Coupons revitalize proven promotional techniques and deliver a competitive advantage to service providers who use them.

TV-Anytime coupon metadata (TS 102 822-3-3 [4]) provides the way to signal the existence of coupon, to explain the

coupon (value, method, subject of discount, textual-explanation, etc.), and to signal the method to retrieve the coupon. The actual realization of a coupon is left to regional / industrial standards or to service providers.

Coupon metadata support most of existing coupon techniques like discount, two for the price of one, buy three get one free, etc. In addition, coupon metadata can express coupons intended to be used upon purchase of non-TV Anytime content.

5

TV-Anytime content referencing scenarios

The present clause introduces key concepts of content referencing, an extension of the static reference model introduced in clause 4 to model third party operation and possible scenarios of issuing and resolving references to items of content.

5.1

Content referencing key concepts

The key concept in content referencing (TS 102 822-4 [6]) is the separation of the reference to a content item - the CRID - from the information needed to actually retrieve the content item - the locator. The separation provided by the CRID enables a one-to-many mapping between content references and the locations of the deliverables. From a system perspective, content referencing and resolution lies between search and selection and actually acquiring the content. From the content referencing perspective, search and selection yields a CRID, which is resolved into either a number of CRIDs or a number of locators (the number may be one). A full discussion of content referencing is beyond the scope of the present document; rather it is the intention here to show how content referencing fits into the overall system. In the examples below, the syntax of a CRID and the syntax of a locator are employed. The syntax of a CRID is:

CRID://<authority>/<data> Where <authority> takes the form:

<DNS name>

<DNS name>is a registered Internet domain name or a delegated sub-domain within such a domain. The <DNS name>

is case insensitive and must be a fully qualified name according to the rules given by RFC 1591 [17]. CRID has been registered on the Official IANA Registry of URI Schemes available at

www.iana.org/assignments/uri-schemes. The CRID is described in RFC 4078 [19]. Some example authority names are:

www.broadcaster.com ISP.net

www.commerce.com

The syntax of the locator is:

<transport mechanism>:<transport system specific>

The content referencing mechanism employs two key tables. The first is the RAR table that maps the authority that issued the CRID to the resolution Service Provider. The second table is the actual resolution table, which maps a CRID to another CRID or to a location. The resolution table may also contain information to link a locator to metadata describing that instance. Refer to TS 102 822-4 [6] TV-Anytime for a more detailed explanation of the concepts and tables involved.

5.2

Content referencing and unique content identification

A content reference is the token that is used by the PDR to acquire a piece of content once the user (or an agent working on their behalf) has selected it. The content reference is the "way pointer" from selection to acquisition.

A content identifier is an identifier that is created at the point just after the content is created with the idea that this identifier will always stay with the content. It allows metadata from multiple sources to all refer to the origination of the content. Whilst very useful, a content identifier is not designed for aiding acquisition of the content as it would require the (possibly globally centralized) body that created the content identifier to know about every instance of the content, and to be informed every time any of these locations change.

As there are already technologies being designed to fulfil the requirements of a content identifier, the TV-Anytime forum have chosen to design a content referencing token as this is an area that requires a global open standard.

The TV-Anytime specification uses the CRID as its token to represent the location of content. The CRID can be converted into either more CRIDs, or actual locations, by the process of location resolution depicted in figure 5.

CRID

Location resolution

Location(s) / CRID(s)

Figure 5: The location resolution process

The idea of a CRID being able to refer to other CRIDs is so that a CRID can represent a grouping of content (which is something that a content identifier cannot do). The group CRID can be used for representing any arbitrary group, an example of which is an entire series. A group CRID for an entire series would allow the PDR to acquire an entire series of programmes by just selecting one CRID to acquire.

One feature of the group CRID is that it means that many CRIDs may resolve to the same piece of content (as the content may be a member of many groups) which means that there might not be one unique CRID per content item. The TV-Anytime defined CRID contains information about how to carry out the location resolution process. All CRIDs contain two parts, the first part is called an authority (which is the body that created this CRID) and the second part is data that has been created by the authority. A piece of information called the resolution authority record provides the mapping of resolution authority to the place where location resolution can take place.

An important feature of the TV-Anytime defined CRID is that it does not require a globally centralized body to assign CRIDs, as this was felt was impractical in that it may not scale well (e.g. in an Internet equipped PDR). From talking with various broadcasters it was also discovered that an advantage of a non-global registration system is that it allows material already in a broadcaster's catalogue to be broadcast without needing to register a globally unique identifier. Another advantage of a de-centralized system is that the user can choose an authority which is closest to their personal tastes. For example one authority can choose that two programmes are the same, but another authority can specify that they are different. E.g. one is a widescreen presentation and the other is a pan and scan presentation of the same film, and the user can pick the authority that matches their personal views (e.g. they might consider widescreen and pan and scan versions identical).

5.3

CRID issuing Authority and resolution providers

The originator of a CRID is the party that actually creates the CRID and assigns it to reference an item of content: the Authority. The resolution provider is the party that provides the facility to resolve the CRID into a physical location in space and time. Three main actors can originate and resolve content reference identifiers: content creators, content service providers, and third parties. Third parties are not shown in figure 1, but can be modelled in quite easily. The next clause will describe the amended model, after that the possible combinations of actors are discussed.

5.3.1

Third party extension to static reference model

Figure 6 shows possible actors in the issuing and resolving of CRIDs. Two of those actors are already in the broadcast reference model shown in figure 1, i.e the content creator and the content service provider. Third party operation is not explicitly modelled in figure 1. However, the model can be easily extended to cater for third party provisioning, both for CRID and resolution data, as well as metadata.

This extension is illustrated in figure 6. Only the existing interfaces are modelled in this figure. There may be a need for interfaces between the different functions in the content service provision function e.g. to enable the export of

Location

Resolution

provision

Metadata

provision

Content

Provision

i3

i4

Metadata

Location resolution

Content

i6

i1

CSP

Figure 6: Extension to static reference model

The content service provisioning function in the overall model of figure 1 is split up in a number of different functions: a location resolution provision function, a metadata provision function, and a content provision function. For example in a service broadcast by broadcast XYZ, where XYZ is provisioning the repackaged content, there could be metadata from a third party with more extensive descriptions of XYZ content. This metadata could also be linked to CRIDs describing a different clustering of content: e.g. all episodes of a series with a certain actress in them. That same party could provide accompanying location resolution data for those CRIDs as well.

5.4

CRID issuing and resolving scenarios

In the most straightforward scenario, the originator of a CRID is also the resolution authority for that CRID. However, this relationship does not always hold. There are a number of scenarios where the CRID originator does not resolve the CRID itself. Table 2 depicts all possible CRID originators to CRID resolution authority scenarios. Table 2 shows cases that are likely or unlikely to occur in a pure broadcast case. Unlikely in no way implies an impossible scenario.

Table 2: Originator of a CRID versus resolution of a CRID

Content creator

resolves CRID

Content service provider resolves CRID

Third Party resolves CRID Content creator originates

CRID

Likely Likely Likely

Content service provider originates CRID

Unlikely Likely Likely

Third Party originates CRID Unlikely Unlikely Likely

Clauses 5.4.1 to 5.4.7 describe some of the possible scenarios in more detail.

5.4.1

CRID originated by content creator, resolved by content creator

In this simple scenario, the content creator creates the content and creates a CRID to reference that piece of content. The content creator also provides the resolving information to find that particular piece of content.

In the broadcast case, suppose the content creator is not the broadcaster, and the content in question is a drama entitled "Most Moving Drama Ever". The authority syntax might then be:

content.com

The CRID itself might take the form:

The string "drama/MostMovingDramaEver" is meaningful to the authority, i.e the authority will be able to resolve this CRID when it is asked to do so. The content creator, having created the drama programme and having assigned it a CRID, needs to be able to broadcast the location resolution information to the PDR. This means it needs to have access to the broadcast channel and schedule information of the relevant broadcaster(s) involved. In the pure broadcast scenario, because there is no return channel, the location resolution takes place in the PDR itself. Finally, the content is broadcast and can be recorded on the local storage device and consumed later, or can be viewed at the time of

broadcast.

When the broadcaster is also the content creator the scenario is simpler and described in clause 5.4.4.

5.4.2

CRID originated by content creator, resolved by content service

provider

In this scenario, the content creator creates the content with an associated CRID. The content service provider is the resolution service provider.

Supposing the content creator is a motion picture studio, and the content in question is an action movie entitled "Best Action Movie Ever". The content service provider is a broadcaster. In this case the content service provider is acting as a proxy for the content creator. The content creator creates a CRID. It might look like this:

CRID://moviestudio.com/movies/BestActionMovieEver

The broadcaster, having purchased the movie from the studio for airing and having also acquired the CRID, broadcasts the location resolution information to the PDR. This information is contained in the "Resolution Tables" that map the CRID to the location. Also broadcast to the PDR are the Resolution Authority Records, one of which effectively includes a redirect, a record where the authority name and resolution service provider are different. In this example there is a RAR where the authority name is "moviestudio.com" and the resolution provider is "broadcaster.com". In a uni-directional network, the location resolution takes place in the PDR. The consumer selects "Best Action Movie Ever" during some navigation or search process. The location resolution engine, having looked up the appropriate RAR, resolves the CRID whose authority is "moviestudio.com" by using the resolution service provider "broadcaster.com". The resolution service provided by "broadcaster.com" resolves the CRID to the actual location, the time and channel of the broadcast in the context of the service provider.

Finally, the movie is broadcast and can be recorded on the local storage device and consumed later, or can be viewed at the time of broadcast.

5.4.3

CRID originated by content creator, resolved by third party

In this scenario, the content creator creates the content and associated CRID. A third party resolves the CRID. Supposing the content creator is a documentary production company, and the content in question is a documentary entitled "Incredible Documentary". Several broadcasters will carry this documentary over a period of time. In terms of location resolution the third party is acting as a proxy for the content creator. The production company creates a CRID. It might look like this:

CRID://documaker.com/IncredibleDocumentary

The third party might be an EPG service. The advantage of the third party in this case is that it can look across all service providers in the multiplex to resolve a CRID. The third party inserts the location resolution tables into the broadcast stream. Also inserted into the broadcast stream are the RARs, one of which contains the authority name "documaker.com" and the resolution service provider "res-service.ecg.com".

In a uni-directional network, the location resolution takes place in the PDR. The consumer selects "Incredible

Documentary" during some navigation or search process. The location resolution engine searches the table of RARs and finds the one whose authority name matches the authority name in the CRID, in this example "documaker.com". The engine then uses the URL contained in the record to find the actual location resolution tables. In this way the CRID is resolved to a locator e.g.:

transport:channel5~0800

Finally, the content is broadcast and can be recorded on the local storage device and consumed later, or can be viewed at the time of broadcast.

5.4.4

CRID originated by content service provider, resolved by content

service provider

In this scenario, the content service provider acquires content and assigns its own CRID to reference that content. The content service provider is also the resolution service provider.

The content service provider could be a broadcaster, and the content in question is the movie "Best Action Movie Ever" from a motion picture studio. The motion picture studio, the content creator, may very well have its own CRID

referencing the movie, but the content service provider decides not to use this. The broadcasters CRID might look like this:

CRID://broadcaster.com/movies/BestActionMovieEver

The broadcaster inserts the location resolution tables into the broadcast stream. Also inserted into the broadcast stream are the RARs, one of which contains the authority name "broadcaster.com" and the resolution service provider "broadcaster.com".

In a uni-directional network, the location resolution takes place in the PDR. The consumer selects "Best Action Movie Ever" during some navigation or search process. The location resolution engine searches the table of RARs and finds the one whose authority name matches the authority name in the CRID, in this example "broadcaster.com". The engine then uses the URL contained in the record to find the actual location resolution tables. In this way the CRID is resolved to a locator, e.g.:

transport:channel9~2130

Finally, the content is broadcast and can be recorded on the local storage device and consumed later, or can be viewed at the time of broadcast.

5.4.5

CRID originated by content service provider, resolved by third party

In this scenario, the content service provider creates a CRID associated to content, but a third party is delegated to resolve the CRID. The content service provider could be a broadcaster. Suppose the content in question is the movie "Best Comedy Movie Ever". The motion picture studio, the content creator of the movie, may very well have its own CRID referencing the movie, but the content service provider decides not to use this. The broadcaster creates a CRID that might look like:

CRID://broadcaster.com/movies/BestComedyMovieEver

The third party might be a trusted agent such as an EPG service provider. Either the broadcaster or the third party may create the location resolution tables as well as the RARs, one of which contains the name of the authority,

"broadcaster.com", along with the name of the resolution service provider, "res-service.ecg.com". The RARs can be inserted into the broadcast. Thus, in terms of location resolution the third party is acting as a proxy for the content service provider, broadcaster.com. In a uni-directional network, the location resolution takes place in the PDR, while in a bi-directional network, the location resolution may take place on the server side. The consumer selects, as a result of some navigation or search process, "Best Comedy Movie Ever". The CRID resolution engine searches the table of RARs and finds the entry whose authority name matches the authority name in the CRID, "broadcaster.com" in this example, which is resolved in turn to give "res-service.ecg.com". The engine then uses this resolved information to find the actual location resolution tables, which are provided by "res-service.ecg.com". In this way, the CRID is resolved and the locator for the CRID is obtained. The content can now be captured.

5.4.6

CRID originated by third party, resolved by content service provider

In this scenario, a third party service creates e.g. a group CRID that references other CRIDs that in turn reference actual content. The third party could be an aggregator of some description. The content service provider agrees to be the resolution service provider for this third party because the third party service is particularly valuable.

Suppose the third party provides a CRID referencing all episodes of the "Star Journey" science fiction series. The CRID might look like this:

The broadcaster provides a Resolution Authority Record (RAR) containing the authority name "StarJourneyAggregator.com" and the resolution provider "broadcaster.com".

The consumer, using some search and navigation process comes across the "All Episodes of Star Journey" item. The PDR looks up authority it finds in the CRID for this item. It finds that the resolution service provider is

"broadcaster.com" and uses the URL to find the resolution tables. It resolves the CRID into a list of other CRIDs:

CRID://broadcaster.com/StarJourneyEpisode1

CRID://broadcaster.com/StarJourneyEpisode2

CRID://broadcaster.com/StarJourneyEpisode3

In this example, the broadcaster issued the returned CRIDs, however the third party could also have its own CRIDs for these episodes that a broadcaster knows how to resolve.

The various episodes are presented to the viewer for selection. The viewer selects "Star Journey Episode 2" and again the engine looks up the authority name in the RAR table. It finds that authority name "broadcaster.com" maps to resolution provider "broadcaster.com", and subsequently resolves the CRID to a list of alternate locations e.g.:

transport:channel9~2130

transport:channel5~0915

The most appropriate location is chosen depending on such factors as how soon the viewer wishes to watch the programme, recording conflicts if the programme is to be saved to local storage, the cost of one location versus the other etc.

Finally, the content is broadcast and can be recorded on the local storage device and consumed later, or can be viewed at the time of broadcast.

5.4.7

CRID originated by third party, CRID resolved by third party

In this scenario, a third party service creates e.g. a group CRID and references other CRIDs that in turn reference actual content. The third party is an aggregator of some description. The same or another third party is also the resolution service provider.

Suppose the third party provides a CRID referencing all nature documentaries on all channels within a multiplex. The CRID might look like this:

CRID://Aggregator.com/AllNatureDocumentaries

The third party provides a Resolution Authority Record (RAR) containing the authority name "Aggregator.com" and the resolution provider "Aggregator.com". This is broadcast to the PDR along with the resolution tables, tables that the third party collates from schedule metadata it collects from all the content creators in the multiplex.

The consumer comes across the "All Nature Documentaries" item in their EPG. The PDR looks up the authority it finds in the CRID for this item. It finds that the resolution service provider is "Aggregator.com" and uses the URL to find the resolution tables. It resolves the CRID into a list of other CRIDs:

CRID://Aggregator.com/FoxesInTheWild

CRID:// Aggregator.com/OceansOfTheWorld

CRID:// Aggregator.com/TheMapleTree

The various programmes are presented to the viewer for selection. The viewer selects "Oceans of the World" and again the engine looks up the authority name in the RAR table. It finds that authority name "Aggregator.com" maps to resolution provider "Aggregator.com", and subsequently resolves the CRID to a list of alternate locations e.g.:

transport:channel2~1730

The most appropriate location is chosen depending on such factors as how soon the viewer wishes to watch the programme, recording conflicts if the programme is to be saved to local storage, the cost of one location versus the other.

Finally, the content is broadcast and can be recorded on the local storage device and consumed later, or can be viewed at the time of broadcast.

5.5

Example of coding an ISAN using a CRID

The ISO and SMPTE/ATSC have been actively working on the creation of an International Standard Audiovisual Number (ISAN). The goal of the ISAN is to uniquely identify completed audio-visual works, episodes of a work, versions of a work, and related parts of versions of a work (such as audio and subtitling tracks). In contrast with a CRID, the ISAN remains the same regardless of the provider of that content and would further allow comparisons between ISANs to determine that two pieces of content differ only by being a different version of the same root work or are different episodes of the same series.

The TV-Anytime Forum recognizes that some metadata and content providers have expressed interest in using the ISAN to identify the programmes they provide or reference in metadata. As such, the following CRID format is proposed to enable a CRID to be built using a known ISAN.

An example CRID incorporating an ISAN will look like: CRID://<authority>/isan<ISAN according to ISO 15706 [18]>In this example the <authority> portion is as specified in TS 102 822-4 [6] and the <data> portion of the CRID is

an ISAN, prefixed with the fixed string "isan". In this case the normal use and semantics of the CRID are preserved. Namely, to convert this CRID into one or more location records the PDR contacts a location resolution service serving the Resolution Authority named in the <authority> portion of the CRID and passes the <data> portion, which in this case is an ISAN. However, because the data portion is clearly identified as an ISAN it also enables the PDR to make comparisons between CRIDs to determine if the referenced content is identical, different by version, or different by episode.

It is important to note that there is a significant difference between a CRID that is issued by a resolution authority and one that is constructed by the user interaction functionality in the PDR. There is an intention that a CRID that is issued will always be resolved by the relevant authority, whereas resolution of a constructed CRID is entirely speculative: one cannot rely on getting the location of the requested content.

Any unique ID for content can be used in a similar way as the ISAN in the above examples.

5.6

The relation between CRID and instance metadata

Instance description metadata is used to describe meaningful differences between specific instances of the same content i.e. instances of content that share the same CRID. For example, two instances of the same film where the instance description metadata indicates that one is in the original 16:9 aspect ratio and the other is in 4:3. Instance description metadata is linked to a particular event-related instance of content. For the full specification of instance description metadata see TS 102 822-3-1 [2] and TS 102 822-3-2 [3]. For a discussion of instance description metadata in the System context, see clause 6.3.2.

The TV-Anytime CRID is used to select and acquire an item of content independent of any particular location (time or place). In some cases however, the consumer may wish to acquire a location dependent version of a piece of content e.g. the 16:9 version of the film. To enable this functionality, the content referencing specification - TS 102 822-4 [6] - details an optional identifier called an Instance Metadata Identifier. This identifier is only guaranteed to be unique within the scope of the CRID to which it has been assigned. So it is permissible to assign the same identifier value to different CRIDs.

The PDR can use the Instance Metadata Identifier to track changes in the scheduling of a specific instance of a piece of content. The following example illustrates the problem and the solution.

Suppose a PDR resolves a CRID:

crid://broadcaster.com/GreatMovie

to two locators: