Digital Media in Italia

Un'iniziativa per interrogarci on the ruolo dell’Italia
e per programmare il nostro futuro
 

 

2007/12/23


The Digital Media in Italia proposal

To give Italy a primary role in the exploitation of digital media

Executive Summary

Digital Media in Italia (dmin.it) is an interdisciplinary, open, non-profit group established in November 2005 with the purpose to define action areas that enable Italy to play a primary role in the exploitation of the global “digital media” phenomenon. By “digital media” dmin.it means any digitally-represented content that can be carried by digital networks and processed by digital devices, particularly if these are programmable.

dmin.it has defined objectives, work method and process to be followed to achieve the objectives  while keeping itself open to participation by anybody sharing the group’s goal. All documents have been published on the dmin.it web site with requests for comments by any interested party and possibility to submit contributions in response to calls for technologies, solutions and comments.

dmin.it observes that many advantages brought by digital media are just potential because digital technologies can alter in a substantial way the traditional roles and operational modalities of value chains to nullify the advantages.

For a series of reasons the innovation attempts made in the last 10 years by many operators have failed and today we are left with digital value chains that look very much like old analogue value chains where proprietary protection technologies have been added to control distribution. Even new and promising open distribution methods such as Creative Commons licences have a hard time to show their innovation potential.

The result is an “underground” market that is orders of magnitude bigger than the “apparent” market. The attempts made to increase the punitive pressure so far have not – and dmin.it expect it will not have any time soon – any measurable effect. This without counting the danger of interventions that may have very negative impacts on fundamental freedoms.

The dmin.it proposal contained in this document extends the preliminary proposal made in September 2006. This time the proposal provides the necessary technological, normative and governance tools required to realise the objective that dmin.it set to itself, namely “maximise the flow of digital media”, as the objective had already been reformulated in September 2006. More specifically the proposal identifies, specifies and defines the conditions for an effective use of three key technologies:

  1. Format for the controlled distribution of digital media (iDRM)

  2. Access to broadband digital networks (iNet)

  3. Pay and cash based on points (iPay)

dmin.it does not propose a standardisation of technologies that excludes other technologies. Indeed an action of this kind, even though its benefits have been historically assessed, does not correspond to current trends. dmin.it simply proposes that, next to technologies that operators freely elect to adopt to satisfy their needs, the interoperable technologies proposed by dmin.it by used.

Concerning the format, dmin.it observes that Digital Rights Management (DRM) technologies, both for the purpose of management and protection, are being used pervasively in the market for the controlled distribution of digital media and that there are international treaties, obligations coming from the European Union and national laws that regulate rights and duties stemming from the use of DRM. Therefore dmin.it assesses that any proposal aiming at substantially altering such a legislative context would be unrealistic.

  on the other hand it has been widely recognised that use of proprietary DRM technologies entails significant impediments to

  1. Contents providers (authors, composers, interprets and producers) who need millions of consumption devices deployed – an extremely hard undertaking – in order to be able to distribute their works;

  2. Consumers who have to stand significant costs in order to be equipped of all devices that are required to access all contents of their interest and find it difficult to move content between different devices;

  3. Service providers who typically find it difficult to hook up to value chains;

  4. Italian companies who find it difficult to operate in the national market that is fragmented and dominated by multinational behemoths.

Therefore dmin.it proposes that the law determines that operators who release content with proprietary DRM technologies must release the same content also using the “interoperabile DRM” (iDRM) technologies specified in this document, at conditions that are not discriminatory if compared with those used by the operator to release content with proprietary DRM technologies.

Concerning the access to broadband digital networks, dmin.it proposes that the law determines that a broadband digital network operator can offer access to his network based on freely determined technical characteristics, provided a network user (content provider, intermediary or end user) may request and obtain from that broadband digital network operator the raw “service-agnostic” access to “big Internet”, according to the specification of this document, with the technical characteristics the operator adopts for its offer and at conditions that are not discriminatory if compared with those used by the operator for his own offer.

Concerning the pay and cash, dmin.it proposes that anybody, within the terms of banking regulation, may offer “account” services that are not directly monetary (points, credits) for transactions connected to the use of digital media, according to the specification of this document. Transactions are effected between “accounts” that rely on payment instruments with guaranteed cashing, e.g. bank account, credit card, prepaid card, electronic purse etc. Synchronisation of an “account” with its payment means is not effected at each transaction but at fixed times or on demand.

This document contains

  1. Some examples of very innovative use cases enabled by the dmin.it proposal;

  2. The body of technical and juridical (where necessary) requirements employed for the definition if iDRM, iNet and iPay technologies;

  3. The technical specifications, the proposals of normative action and the governance rules necessary to operate the iDRM, iNet and iPay systems;

  4. Some experimental examples that dmin.it participants are implementing to verify the adequacy of adopted technologies and their ability to respond to the stated requirements.

Table of Contents

 

Executive Summary

  Table of Contents
3 Features and advantages of the proposal
3.1 Format technologies
3.2 Access technologies
3.3 Pay/cash technologies
4 Use cases
4.1 Introduction
4.2 Leonardo buys a song from Mimmo
4.3 Roberta watches a live TV programme
4.4 Antonella listens to ad-supported music
4.5 Luca listens to subscription music
4.6 Beppe compensates Pippo with an Alternative Compensation System
4.7 NewGarage sells music on the web
4.8 Marco distributes his videos on DTT
4.9 Distribution of governed content on P2P networks
4.10 Personal Video recording
4.11 Management of document life cycle
5 Requirements
5.1 Introduction
5.2 iDRM.requirements
5.3 iNet requirements
5.4 iPay requirements
5.4.1 iPay system requirements
6 iDRM specification
6.1 Introduction
6.2 Reference diagram
6.3  Scope of iDRM standardisation
6.4 Reference software
6.5 Links with a iNet and iPay
7 Legislation proposal to support iDRM
7.1 Introduction
7.2  Text of proposal
7.3 Relationships with other legislative proposals
8 Governance of iDRM system
8.1 Introduction
8.2 Objectives if iDRM Trust Model
8.3 Certificatione process
8.4 Run-time processo linked to content consumption
8.5 Legal/normative/contractual.scheme
8.6 iDRM system economics
9 iNet specification
9.1 Introduction
9.2 Reference diagram
9.3 User access
9.4 Interfaces and protocols between operators
9.5 Reference software
9.6 Links with iDRM and iPay
10 Legislation proposal to support iNet
10.1  Introduction
10.2 Text of proposal
10.3 Relationships with other legislative proposals
11 Governance of iNet system
11.1 Introduction
11.2 Objectives of iNet governance
11.3 Operation of iNet governance
12 iPay specification
12.1 Introduction
12.2 Reference diagram
12.3 Elements to be standardised
12.4 XML representation of data structures
12.5 Protocols
12.6 Reference software
12.7 Links with iDRM and iNet
13 Legislation proposal to support iPay
13.1 Introduction
13.2 Text of proposal
13.3 Relationships with other legislative proposals
14 Governance of iPay system
14.1 Objectives of iPay governance
14.2 Operation of iPay governance
15 Implementation examples of dmin.it proposal
15.1 Introduction
15.2 P2P iDRM
15.3 VHS 2.0
16 References
17 Glossary

1 Introduction

2 Development of proposal

3 Features and advantages of the proposal

In other ages it would have been natural to propose a set of technologies – format, access and pay/cash – to be applied uniformly on the national territory and exclude all other competing technologies. This is a formula that has contribuited to the success of other communication systems both analogue and digital. However, even if this approach met the consensus of affected value chain players, there would be today serious obstacles caused by national legislation, obligations coming from European Union deliberations and constraints of international treaties.

On the other hand dmin.it believes that making it possible for

is a potent factor enabling the attainment of dmin.it objectives.

Therefore dmin.it, instead of proposing an exclusive standardisation of format, access and pay/cash technologies, proposes to place next to the tools proposed by dimin.it those that operators freely decide to adopt for their needs. The value added brought by dmin.it tools lies in the assurance that users have that interoperability is possible with those who adopt the same tools.

The dmin.it proposal identifies an equilibrium point between the demand of operators to retain the freedom to select those technologies that best match the needs of their business and the demand of interoperability coming from the two end points of the value chains – authors, performers, interpreters and producers on one end and consumers on the other hand – and from intermediaries who decide to base their business on ’interoperability.

dmin.it believes that its proposal will create a potential homogeneous market of 60 million people capable of stimulating both the national cultural industry and innovation in the market of digital media thus helping the national industry to achieve a leading position.

3.1 Format technologies

For format technologies dmin.it proposes that an interoperable Digital Rights Management (iDRM) specification be adopted at the national level. It is important to note that, in spite of the improper use of the DRM acronym on the part of some as synonymous of Technical Protection Measure (TPM), the “M” means “Management”  not necessarily “Protection”. The well-known definition of DRM by the National Institute of Standards and Technologies (NIST) as “A system of Information Technology components and services that strive to distribute and control content and related rights with digital technologies” makes deliberate reference to the term “control” and not “enforcement”. This means that there are many technologies falling under the above-mentioned meaning of “DRM”. These include the release of simply identified content up to, if deemed necessary by some parties, to content released with protection technologies. With the acronym iDRM dmin.it intends to reserve to the national community this broad and not sectarian use of content management technologies .

dmin.it adopts the NIST definition of DRM (indeed this is found in the Glossary). The “i” prefixed to DRM means that dmin.it OLNY supports the interoperable, i.e. standard, version of DRM here proposed. dmin.it DOES NOT support (but is not and may not be against) the use of non-interoperable DRM.

Therefore dmin.it proposes that the law determines that service providers who release content using a proprietary DRM technology shall ALSO release the same content using the iDRM technology iDRM at conditions that are not discriminatory if compared with those employed to release content using the proprietary DRM technology. this is depicted in Figure 1

Figure 1 Distribution of content with proprietary and interoperable DRMs

Anybody may (but is not obliged to) realise (hardware and software) devices and services, request and obtain, if the implementation qualifies, a conformity certificate and offer them to third parties withe an “iDRM” mark so that no conflicts are created.

The iDRM specification is public, implemented in Open Source Software (licence MPL 1.1), does not prescribe specific business models, in line with the part above related to the meaning of “Management” in the iDRM acronym.

The iDRM specification is not comparable with the specifications of the current "black box" and monolithic DRM solutions that are found today in the market, because iDRM is a toolkit specification. This approach allows users to implement value chains corresponding to a large number of business models with improved levels of interoperability, using the same basic tools configured to suit their needs.

As an example use of the iDRM specification enables the following systems where content is distributed with:

  1. No other information but an identifier;
  2. A licence (e.g. Creative Commons) which expresses rights without any form of enforcement;
  3. An identifier and an “Event Report Request” to allow the collection of use information;
  4. An identifier and a licence that contains, in addition to the right expression, also a decryption key;
  5. Ecc.

As in most modern "converging" standards, the iDRM specification does not consider device implementation aspects. Therefore it is quite possible that manufacturers decide to make devices that can only handle content in use today, e.g.  MP3 or MP4, others that can handle only  iDRM content, still others that handle both iDRM and proprietary DRM content, and all other possible combinations.

For the same reason the iDRM specification does not consider security aspects that some operators may require for their own iDRM implementations.

A typical case could require that the device used to prepare content for iDRM distribution (Content Creation Device) be “secure” because in general it must be possible to associate the content that is distributed with its author. Naturally this should not imply that the author should not be able to preserve anonymity if so desired.

Making reference to the distribution modalities indicated above one can say that in general the consumption device could be any for case 1., while it is desirable that the CC licence terms be displayed before use in case 2., even though that content could be consumed with any device. On the other hand the consumption device must be certified in case 3. not because the device handles protected content, but because it must be guaranteed that , e.g. in an Alternative Compensation System that “Event Reports” (see Glossary) issue`d by the device are authentic, so as to avoid distorted distribution of compensation caused by faulty statistics. It also likely that the consumption device in case 4. needs to be certified as, e.g. a pay TV set top box today, because the device handles protected content Indeed the operator may wish to mandate that his content be only consumed with devices of a certain security level.

The iDRM specification may not and does not deal with the issue of which security technology, if required, should be employed. Indeed in the market there are different modalities to obtain different security levels for different applications, e.g.

  1. Some software implementations can be considered secure because they are proprietary. An example of this approach could be an iTunes client for PC;
  2. Some software implementations that are based on hardware functionalities of the device that preserve secret information. Examples of this approach could be pay TV set top boxes, iPod players and multimediali cell phones;
  3. Some software implementations that are based on the Trusted Platform Module (TPM) defined by the Trusted Computing Group and currently installed on laptops.
  4. Some hardware/firmware implementations;
  5. Other types of implementations that may emerge as a consequence of market or regulation needs such, e.g. privacy,protection of minors etc.

Some of these aspects could be handled by the governance of the iDRM ecosystem. dmin.it proposes that governance be left in the hands of representatives of all affected parties.

3.2 Access technologies

dmin.it proposes that for access to digital broadband networks

  1. Digital broadband network operators may offer bundled and/or unbundled access to their networks with technical characteristic of their choice;
  2. A network user (content provider, intermediary or end user) may request and obtain from a digital broadband network operators the raw “service-agnostic” access to “big Internet” according to the iNet specification of this document within the technical characteristics already part of the operator's offer at conditions that are non discriminatory if compared with the other offers by the operator;
  3. Digital broadband network operators guarantee network service interoperability by agreeing on and providing specific levels of quality of service (QoS) at peering points so as to provide network users appropriate levels of QoS.

Figure 2 depicts the dmin.it proposal for access to digital broadband networks.

Figure 2 – Open access to digital broadband network

3.3 Pay/cash technologies

dmin.it proposes for pay/cash of content that

  1. Anybody, within the terms of banking regulation, may offer “account” services that are not directly monetary (points, credits) for transactions connected to the use of digital media, according to the specification of this document;
  2. Transactions are effected between “accounts” that rely on payment instruments with guaranteed cashing, e.g. bank account, credit card, prepaid card, electronic purse etc.;
  3. Synchronisation of an “account” with its payment means is not effected at each transaction but at fixed times or on demand.

Figure 3 depicts the proposal.

Figure 3 System to record and convert points for digital media

4      Use cases

4.1          Introduction

4.2          Leonardo buys a song from Mimmo

4.3          Roberta watches a live TV programme

4.4          Antonella listens to ad-supported music

4.5          Luca listens to subscription music

4.6          Beppe compensates Pippo with an Alternative Compensation System

4.7          NewGarage sells music on the web

4.8          Marco distributes his videos on DTT.

4.9          Distribution of governed content on P2P networks

4.10        Personal Video recording

4.11        Management of document life cycle

5      Requirements

5.1          Introduction

5.2          iDRM.requirements

5.3          iNet requirements

5.4 iPay requirements

5.4.1 iPay system requirements

In this subsection  on the iPay system requirements are collected. In the following reference to the terminology below will be made:

  1. Account: a ledger of Points owned by a User
  2. Point: the iPay accounting unit
  3. Shared Services: a central entity providing services to VASPs
  4. Subscriber: a User holding an Account with a VASP
  5. User: every player operating in the iPay system
  6. VASP: Virtual Account Service Provider

It is convenient to observe that some of the requirements below have been introduced to facilitate the design of the systems. However, there is room to remove of alter some of them.

  1. iPay operates in parallel with and does not replace other pay/cash systems
  2. In the iPay system Virtual Account Service Provider (VASP) operate. VASPs may cumulate the VASP function with other functions.
  3. Users (of "Consumer" or "Business" type) of dmin.it value chains may establish
    1. One or more than one Account
    2. With one or more than one VASP
    3. With of without the possibility to convert Points to real money
    4. Possibly with pre-assigned limits to the negative value of Points in the Account
    5. To be used by the Account holder to settle his payment, if the other party agrees
  4. Accounts are
    1. Based on Points, the only accounting unit that is valid in iPay and accepted by all VASPs
    2. Dependent on a single payment system in real money (two-way relationship)
    3. Synchronised with guaranteed payment systems in real money at fixed times or on demand by Account holders
    4. Hierarchical, i.e. they may contain Sub-Accounts
    5. Not charged by/accredited with interest on Points deposited in the Account
    6. Managed by Users by means of applications with standard interfaces (e.g. to get Account status or to force a synchronisation in advance of the fixed time)
  5. Points have the following characteristics
    1. They can be converted to real money at fixed times or ondemand by the Account holder
    2. They represent a very small monetary value (e.g. 0,001 €) to enable, e.g. impulse buying/selling
    3. They have a ration with real money that is
      1. Expressed by any number
      2. Determined at time t0 by iPay Governance
      3. Fixed after that or is variable (TBD)
  6. There is a data collection point called Shared Services that
    1. Is the single such point in the iPay system
    2. Collects information from VASPs on defaults by Account holders
    3. Supplies on request information on Account holders
      1. A VASP
      2. A User only to get information about himself
    4. Is updates as soon as a default is detected (failed synchronisation)
  7. The iPay Governance may establish forms of VASP supervision in order to avoid that these “create money” in fraudulent manner. Two possible ways are
    1. Inspections of VASP "accounting books"
    2. Communication to Shared Servces of all transactions where payload is omitted save transazione number and amount
  8. The amount of a default is shared
    1. Among all those who were paid in Points after the last successful synchronisation
    2. In proportion to the amount of their credit
  9. The iPay system applies VAT at each transaction (because rates for different transactions may be different)
  10. VASPs supply to their Account holders
    1. the information required to pay VAT according to the law
    2. Additional services, e.g. billing
  11. A VASP can mask part of the payload that is moves to another User
  12. The iPay system is supported by a participation fee (e.g. assessed at each transaction) for
    1. Shared Services
    2. Other services required (e.g. iPay Governance)
  13. Each iPay User has a unique identifier issued by Shared Services based on User's fiscal code and other parametres
  14. Each Account has a unique identifier
    1. Within the VASP
    2. Within the iPay system through association with VASP ID.

6      iDRM specification

6.1          Introduction

6.2         Reference diagram

6.3         Scope of iPay standardisation

6.4          Reference software

6.5          Links with a iNet and iPay

7     Legislation proposal to support iDRM

7.1          Introduction

7.2         Text of proposal

7.3         Relationships with other legislative proposals

8      Governance of iDRM system

8.1         Introduction

8.2         Objectives of iDRM Trust Model

8.3         Certification process

8.4         Run-time proces linked to content consumption

8.5         Legal/normative/contractual scheme

8.6         iDRM system economics

9      iNet  specification

9.1         Introduction

9.2         Reference diagram

9.3         User access

9.4         Interfaces and protocols between operators

9.5         Reference software

9.6         Links with iDRM and iPay

10        Legislation proposal to support iNet

10.1       Introduction

10.2       Text of proposal

10.3       Relationships with other legislative proposals

11        Governance of iNet system

11.1        Introduction

11.2        Objectives of iNet governance

11.3        Operation of iNet governance

12 iPay specification

12.1 Introduction

This chapter contains the technical specification of the point recording and conversion for digital media adopted by Digital Media in Italia (dmin.it).

12.2 Reference diagram

Reference is made to Figure 3 – System to record and convert points for digital media.

12.3 Elements to be standardised

In this section the elements requiring standardisation are given.

12.3.1 Players

The dmin.it iPay system has 4 types of player:

  1. Subscriber

  2. Virtual Account Service Provider (VASP)

  3. Shared Services

  4. Traditional paymnet circuits

12.3.2 Communications

The Players communicate between themselves. For each of these communications the following must be defined:

  1. The protocol

  2. The format of data exchanged

12.4 XML representation of data structures

In this section the messagges exchanged between the following three system players are reported: Subscriber (SU), who can be further classified as Buyers (BU) or seller s (SE), VASPs (VA) and the Shared Services (SS). A high-level description of the information contained in each message is also given. Each message must be signed by the sender, and the signature must be included in the element dsig:Signature in each message. Le complete XML representations of the payloads are give in a .zip file.

Note: Some names may need to be changed to align them to the correct English words.

12.4.1 Account Creation (createAccount)

When a new user decides to open a Virtual Account, the following messages are exchanged between the various Players:

12.4.1.1       Subscriber – VASP

CreateSubscriberAccount_SU-VA (optional) may be sent by a Subscriber to a VASP to request creation of a new Virtual Account. 

<element name="CreateSubscriberAccount_SU-VA" type="pay:CreateSubscriberAccount_SU-VAType"/>

<complexType name="CreateSubscriberAccount_SU-VAType">

            <complexContent>

                        <extension base="pay:PaymentProtocolType">

                                    <sequence>

                                                <element name="UserInfo" type="pay:UserInfoType"/>

                                                <element name="SupportingAccount" type="pay:PhysicalAccountType"/>

                                                <element name="AccountOptions" type="pay:OtherType" minOccurs="0"/>

                                                <element ref="dsig:Signature"/>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

Figure 10 – CreateSubscriberAccount_SU-VA

 This message contains personal information of the requester, information on the real circuit on which he intends to link his virtual account, and possible other optional information related to the type of account of which he requests creation.

12.4.1.2       VASP – SS

CreateSubscriberAccount_VA-SS is sent by a VASP to Shared Services to request an dentifier for the user who requests the creation of a Virtual Account.

<element name="CreateSubscriberAccount_VA-SS" type="pay:CreateSubscriberAccount_VA-SSType"/>

<complexType name="CreateSubscriberAccount_VA-SSType">

            <complexContent>

                        <extension base="pay:PaymentProtocolType">

                                    <sequence>

                                                <element name="UserInfo" type="pay:UserInfoType"/>

                                                <element ref="dsig:Signature"/>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

Figure 11 – CreateSubscriberAccount_VA-SS

This message contains personal information of the requester.

12.4.1.3       SS – VASP

CreateSubscriberAccount_SS-VA is sent by Shared Services to a VASP in response to a CreateSubscriberAccount_VA-SS  message. 

<element name="CreateSubscriberAccount_SS-VA" type="pay:CreateSubscriberAccount_SS-VAType"/>

<complexType name="CreateSubscriberAccount_SS-VAType">

            <complexContent>

                        <extension base="pay:PaymentProtocolType">

                                    <sequence>

                                                <choice>

                                                            <element ref="pay:User"/>

                                                            <element name="Fault" type="pay:FaultType"/>

                                                </choice>

                                                <element ref="dsig:Signature"/>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

Figure 12 – CreateSubscriberAccount_SS-VA

 This message contains the requester's identifier, that is generated when the user is not yet registered with Shared Services.

12.4.1.4       VASP – Subscriber

CreateSubscriberAccount_VA-SU is sent by a VASP in risponse to a CreateSubscriberAccount_SU-VA message after having received the CreateSubscriberAccount_SS-VA message in risponse from Shared Services. 

<element name="CreateSubscriberAccount_VA-SU" type="pay:CreateSubscriberAccount_VA-SUType"/>

<complexType name="CreateSubscriberAccount_VA-SUType">

            <complexContent>

                        <extension base="pay:PaymentProtocolType">

                                    <sequence>

                                                <choice>

                                                            <element name="AccountCreated" type="pay:AccountCreatedType"/>

                                                            <element name="Fault" type="pay:FaultType"/>

                                                </choice>

                                                <element ref="dsig:Signature"/>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

<complexType name="AccountCreatedType">

            <complexContent>

                        <extension base="pay:PaymentBaseType">

                                    <sequence>

                                                <element ref="pay:User"/>

                                                <element name="VirtualAccountInfo" type="pay:AccountType"/>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

Figure 13 – CreateSubscriberAccount_VA-SU

This message contains the requester's identifier and the information related to the new Virtual Account, se this has been successfully created, or an error code.

12.4.2        Purchase Order

When a user decides to buy a content item from another user, the following message is sent by the buyer to the seller:

12.4.2.1       Subscriber (BU) – Subscriber (SE)

PurchaseOrder is sent by un Subscriber buyer to a Subscriber seller

<element name="PurchaseOrder" type="pay:PurchaseOrderType"/>

<complexType name="PurchaseOrderType">

            <complexContent>

                        <extension base="pay:PaymentProtocolType">

                                    <sequence>

                                                <element name="ContentID" type="anyURI"/>

                                                <element name="LicenseCategory" type="pay:LicenseCategoryType" minOccurs="0"/>

                                                <element name="Buyer" type="pay:UserType"/>

                                                <element name="BuyerVASP" type="pay:VASPType"/>

                                                <element name="Beneficiary" type="dsig:KeyInfoType"/>

                                                <element ref="dsig:Signature"/>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

Figure 14 – PurchaseOrder

This message contains the identifier of the content item that the buyer intends to buy, the desired licence type, personal information, his own VASP, and who is the il beneficiary to whom the licence is granted (possibly different from the user issuing the order).

12.4.3 Cash Disposition

When a seller receives a purchase order, the following messages are exchanged between the various users:

12.4.3.1       Subscriber (SE)– VASP

CashOrder_SE-VA is sent by a Subscriber seller to his VASP. 

<element name="CashOrder_SE-VA" type="pay:CashOrder_SE-VAType"/>

<complexType name="CashOrder_SE-VAType">

            <complexContent>

                        <extension base="pay:PaymentProtocolType">

                                    <sequence>

                                                <element name="OrderNumber" type="string"/>

                                                <element name="LicenseInfo" type="pay:LicenseInfoType"/>

                                                <element name="Buyer" type="pay:UserType"/>

                                                <element name="BuyerVASP" type="pay:VASPType"/>

                                                <element name="seller " type="pay:UserType"/>

                                                <element name="seller Account" type="pay:AccountType"/>

                                                <element name="Amount" type="long"/>

                                                <element name="VAT" type="pay:VATType"/>

                                                <element ref="dsig:Signature"/>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

Figure 15 –  CashOrder_SE-VA

This message contains an identifier of the order, information on how the licence for the content item can be obtained , the information on the buyer and on himself, information on the Virtual Account on which the payment will be credited, the amount and the VAT on the transaction.

12.4.3.2       VASP – VASP

CashOrder_VA-VA is sent by the seller's VASP to the buyer's VASP.

<element name="CashOrder_VA-VA" type="pay:CashOrder_VA-VAType"/>

<complexType name="CashOrder_VA-VAType">

            <complexContent>

                        <extension base="pay:PaymentProtocolType">

                                    <sequence>

                                                <element name="OrderNumber" type="string"/>

                                                <element name="LicenseInfo" type="pay:LicenseInfoType"/>

                                                <element name="Buyer" type="pay:UserType"/>

                                                <element name="BuyerVASP" type="pay:VASPType"/>

                                                <element name="seller " type="pay:UserType"/>

                                                <element name="seller Account" type="pay:AccountType"/>

                                                <element name="Amount" type="long"/>

                                                <element name="VAT" type="pay:VATType"/>

                                                <element ref="dsig:Signature"/>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

Figure 16 – CashOrder_VA-VA

This message contains an identifier of the order, information on how the licenza for the content item can be obtained, the information on the buyer and on himself, information on the Virtual Account on which the payment will be credited, the amount and the VAT on the transaction.

12.4.3.3       VASP – Subscriber (BU)

CashOrder_VA-BU is sent by the buyer's VASP to the buyer. 

<element name="CashOrder_VA-BU" type="pay:CashOrder_VA-BUType"/>

<complexType name="CashOrder_VA-BUType">

            <complexContent>

                        <extension base="pay:PaymentProtocolType">

                                    <sequence>

                                                <element name="OrderNumber" type="string"/>

                                                <element name="LicenseInfo" type="pay:LicenseInfoType"/>

                                                <element name="seller " type="pay:UserType"/>

                                                <element name="seller VASP" type="pay:VASPType"/>

                                                <element name="seller Account" type="pay:AccountType"/>

                                                <element name="Amount" type="long"/>

                                                <element name="VAT" type="pay:VATType"/>

                                                <element ref="dsig:Signature"/>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

Figure 17 – CashOrder_VA-BU

This message contains an identifier of the order, information on how the licence for the content item can be obtained,information on the seller, information on the Virtual Account on which the payment will be credited, the amount and the VAT on the transaction.

12.4.4 Payment Disposition

When a seller receives a Cash Disposition, the following messages are exchanged between the various users:

12.4.4.1       Subscriber (BU) – VASP

PaymentOrder_BU-VA is sent by seller to his VASP. 

<element name="PaymentOrder_BU-VA" type="pay:PaymentOrder_BU-VAType"/>

<complexType name="PaymentOrder_BU-VAType">

            <complexContent>

                        <extension base="pay:PaymentProtocolType">

                                    <sequence>

                                                <choice>

                                                            <element name="Confirmation" type="pay:PaymentConfirmationType"/>

                                                            <element name="Negation" type="pay:FaultType"/>

                                                            <element ref="dsig:Signature"/>

                                                </choice>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

<complexType name="PaymentConfirmationType">

            <complexContent>

                        <extension base="pay:PaymentBaseType">

                                    <sequence>

                                                <element name="OrderNumber" type="string"/>

                                                <element name="LicenseInfo" type="pay:LicenseInfoType"/>

                                                <element name="Buyer" type="pay:UserType"/>

                                                <element name="BuyerAccount" type="pay:AccountType"/>

                                                <element name="Amount" type="long"/>

                                                <element name="seller " type="pay:UserType"/>

                                                <element name="seller Account" type="pay:AccountType"/>

                                                <element name="seller VASP" type="pay:VASPType"/>

                                                <element name="VAT" type="pay:VATType"/>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

Figure 18 – PaymentOrder_BU-VA

This message can contain either a Payment Disposition, or the refusal of the Cash Disposition. In the former case, the message contains the same identifier contained in the Cash Disposition, information on how the licence for the content item can be obtained, information on the buyer, information on the Virtual Account from which payment will be effected, the amount, the beneficiary of the payment and the information on the Virtual Account on which the anount will be credited, and the VAT on the transaction.

12.4.4.2       VASP – VASP

PaymentOrder_VA-VA is sent by the buyer's VASP to the seller's VASP. 

<element name="PaymentOrder_VA-VA" type="pay:PaymentOrder_VA-VAType"/>

<complexType name="PaymentOrder_BU-VAType">

            <complexContent>

                        <extension base="pay:PaymentProtocolType">

                                    <sequence>

                                                <choice>

                                                            <element name="Confirmation" type="pay:PaymentConfirmationType"/>

                                                            <element name="Negation" type="pay:FaultType"/>

                                                            <element ref="dsig:Signature"/>

                                                </choice>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

<complexType name="PaymentConfirmationType">

            <complexContent>

                        <extension base="pay:PaymentBaseType">

                                    <sequence>

                                                <element name="OrderNumber" type="string"/>

                                                <element name="LicenseInfo" type="pay:LicenseInfoType"/>

                                                <element name="Buyer" type="pay:UserType"/>

                                                <element name="BuyerAccount" type="pay:AccountType"/>

                                                <element name="Amount" type="long"/>

                                                <element name="seller " type="pay:UserType"/>

                                                <element name="seller Account" type="pay:AccountType"/>

                                                <element name="seller VASP" type="pay:VASPType"/>

                                                <element name="VAT" type="pay:VATType"/>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

Figure 19 – PaymentOrder_VA-VA

This message can contain either Payment Disposition, or a refusal to proceed to payment. In the former case, the message contains the same identifier contained in the Cash Disposition, information on how the licence for the content item can be obtained, information on buyer, information on the Virtual Account from which the payment will be effected, the amount, the beneficiary of the payment and the information on the Virtual Account on which the amount will be credited, and the VAT on the transaction. As a result of this message correctly sent, the issuing VASP will deduct the specified amount from the buyer's Virtual Account, while the receiving VASP will add the same amount to the seller's Virtual Account.

12.4.4.3       VASP – Subscriber (SE)

PaymentOrder_VA-SE is sent by the seller's VASP to the seller. 

<element name="PaymentOrder_VA-SE" type="pay:PaymentOrder_VA-SEType"/>

<complexType name="PaymentOrder_VA-SEType">

            <complexContent>

                        <extension base="pay:PaymentProtocolType">

                                    <sequence>

                                                <choice>

                                                            <element name="Confirmation" type="pay:PaymentExecutedType"/>

                                                            <element name="Fault" type="pay:FaultType"/>

                                                            <element ref="dsig:Signature"/>

                                                </choice>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

<complexType name="PaymentExecutedType">

            <complexContent>

                        <extension base="pay:PaymentBaseType">

                                    <sequence>

                                                <element name="OrderNumber" type="string"/>

                                                <element name="LicenseInfo" type="pay:LicenseInfoType"/>

                                                <element name="Buyer" type="pay:UserType"/>

                                                <element name="BuyerAccount" type="pay:AccountType"/>

                                                <element name="Amount" type="long"/>

                                                <element name="VAT" type="pay:VATType"/>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

Figure 20: PaymentOrder_VA-SE

This message can contain either a Payment Confirmation, or a Payment Refusal. In the former case, the message contains the same identifier contained in the Cash Disposition, information on the licence, information on buyer, information on the Virtual Account from which payment has been effected, the amount, and the VAT on the transaction.

12.4.5 Loading defaulting user data

When a VASP is not in a position to effect a synchronszation between the Virtual Account and the real circuit of one of his Subscribers, the following message is sent by the VASP to Shared Services.

12.4.5.1       VASP – SS

StoreSubscriberData_VA-SS is sent by a defaulted Subscriber's VASP to Shared Services. 

<element name="StoreSubscriberData_VA-SS" type="pay:StoreSubscriberData_VA-SSType"/>

<complexType name="StoreSubscriberData_VA-SSType">

            <complexContent>

                        <extension base="pay:PaymentProtocolType">

                                    <sequence>

                                                <element name="DefaultReportID" type="string"/>

                                                <element name="DefaultedUser" type="pay:UserType"/>

                                                <element name="DefaultRecord" type="pay:RecordType"/>

                                                <element ref="dsig:Signature"/>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

<complexType name="RecordType">

            <complexContent>

                        <extension base="pay:PaymentBaseType">

                                    <sequence>

                                                <element name="DefaultTime" type="time"/>

                                                <element name="DefaultAmount" type="long"/>

                                                <element name="ReportingVASP" type="pay:VASPType"/>

                                                <element name="AffectedOrderNumber" type="string" maxOccurs="unbounded"/>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

Figure 21 – PaymentOrder_VA-SC

This message contains an identifier of this report, the defaulted user identifier, the date and time of the failed synchronisation, the amount of the user default, its own identifier, and the list of transaction identifiers affected by the failed  dalla synchronisation.

12.4.6 User Data Consultation

The following messages are employed to request Shared Services the list of defaults of a user in a given time period, and to contain the response. Only a VASP can do this.

12.4.6.1       VASP – SS

RetrieveSubscriberData_VA-SS is sent by a defaulted Subscriber's VASP to Shared Services to request the list of defaults of a user in given time perios. 

<element name="RetrieveSubscriberData_VA-SS" type="pay:RetrieveSubscriberDataRequestType"/>

<complexType name="RetrieveSubscriberDataRequestType">

            <complexContent>

                        <extension base="pay:PaymentProtocolType">

                                    <sequence>

                                                <element ref="pay:User"/>

                                                <element name="StartTime" type="time"/>

                                                <element name="EndTime" type="time"/>

                                                <element ref="dsig:Signature"/>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

Figure 22: RetrieveSubscriberData_VA-SS

 This message contains the identifier of the user of which the VASP wishes to know possible defaults, and the identification of the relevant period.

12.4.6.2       Subscriber – SS

RetrieveSubscriberData_SS-SU is sent by a Subscriber to request Shared Services the list of defaults incurred by him in a given period of time. 

<element name="RetrieveSubscriberData_SS-SU" type="pay:RetrieveSubscriberDataRequestType"/>

Figure 23 – RetrieveSubscriberData_SS-SU

 This message, as the preceding one, contains the identifier of the user whi wishes to know possible defaults and the identification of the relevant period.

12.4.6.3       SS – VASP

RetrieveSubscriberData_SS-VA is sent by Shared Services in response to a RetrieveSubscriberData_VA-SS message.

<element name="RetrieveSubscriberData_SS-VA" type="pay:RetrieveSubscriberDataResponseType"/>

<complexType name="RetrieveSubscriberDataResponseType">

            <complexContent>

                        <extension base="pay:PaymentProtocolType">

                                    <sequence>

                                                <element ref="pay:User"/>

                                                <element name="Record" type="pay:RecordType" minOccurs="0" maxOccurs="unbounded"/>

                                                <element ref="dsig:Signature"/>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

Figure 24: RetrieveSubscriberData_SS-VA

 This message contains the identifier of the user of which VASP wishes to know possible defaults, and for each default the date and time in which synchronisation failes, the amount of the user default, the identifier the VASP who reported the default, and the list of identifiers of transactions affected by the failed synchronisation.

12.4.6.4       VASP – Subscriber

RetrieveSubscriberData_VA-SU is sent by the VASP of a defaulted user to the defaulted user after a failed synchronisation. 

<element name="RetrieveSubscriberData_VA-SU" type="pay:RetrieveSubscriberDataResponseType"/>

Figure 25 – RetrieveSubscriberData_VA-SU

This message contains the identifier of the relevant user, the date amd time of the failed synchronisation, the amount of the user default, the identifier of the VASP who reported the default, and the list of identifiers of delle transactions affected by the failed synchronisation.

12.4.6.5       SS – User

RetrieveSubscriberData_VA-SU is sent by Shared Services to a user in response to a RetrieveSubscriberData_SS-SU message.

<element name="RetrieveSubscriberData_SS-SU" type="pay:RetrieveSubscriberDataResponseType"/>          

Figure 26 – RetrieveSubscriberData_SS-SU

This message contains the identifier of the relevant user, the date and time of the failed synchronisation, the amount of the user default, the identifier of the VASP who reported the default, and the list of identifiers of transactions affected by the failed synchronisation.

12.4.7 Default redistribution

The following messages are employed when it is necessary to redistribute among the creditors of a defaulted user an amount in virtual currency drawn from the Subscriber's real circuit, although this is not sufficient to cover the debit entirely.

12.4.7.1       VASP – Subscriber

RetrieveSubscriberData_VA-BU is sent by the  VASP of a buyer to the buyer to communicate a failed synchronisation. 

<element name="DefaultRedistribution_VA-BU" type="pay:DefaultRedistribution_VA-BUType"/>

<complexType name="DefaultRedistribution_VA-BUType">

            <complexContent>

                        <extension base="pay:PaymentProtocolType">

                                    <sequence>

                                                <element name="DefaultReportID" type="string"/>

                                                <element name="Account" type="pay:AccountType"/>

                                                <element name="AmountDefaulted" type="long"/>

                                                <element name="DateOfDefault" type="time"/>

                                                <element ref="dsig:Signature"/>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

Figure 27: RetrieveSubscriberData_VA-BU

 This message contains the identifier of this reporo, information on the real account from which it was not possibile to draw the required amount, the amount overdraft and the date of the failed synchronisation.

12.4.7.2       VASP – SS

RetrieveSubscriberData_VA-SS is sent by the VASP of a defaulted user to Shared Services. 

<element name="DefaultRedistribution_VA-SS" type="pay:DefaultRedistribution_VA-SSType"/>

<complexType name="DefaultRedistribution_VA-SSType">

            <complexContent>

                        <extension base="pay:PaymentProtocolType">

                                    <sequence>

                                                <element name="DefaultReportID" type="string"/>

                                                <element name="DefaultedUser" type="pay:UserType"/>

                                                <element name="RemoveVASPCredit" type="pay:RemoveVASPCreditType" maxOccurs="unbounded"/>

                                                <element ref="dsig:Signature"/>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

<complexType name="RemoveVASPCreditType">

            <complexContent>

                        <extension base="pay:PaymentBaseType">

                                    <sequence>

                                                <element name="AffectedVASP" type="pay:VASPType"/>

                                                <element name="Amount" type="long"/>

                                                <element name="AffectedOrderNumber" type="string" maxOccurs="unbounded"/>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

Figure 28: RetrieveSubscriberData_VA-SS

This message contains the identifier of this report, information on the defaulted user, the identifiers of the VASPs affected by the redistribution, the amount to be deducted from each VASP and the identifier of the Payment Order that is overdraft.

12.4.7.3       SS – VASP (SE)

DefaultRedistribution_SS-VA is sent by Shared Services to the VASPs of those users from whose Virtual Accounts and amount will be deducted because of a failed synchronisation. 

<element name="DefaultRedistribution_SS-VA" type="pay:DefaultRedistribution_SS-VAType"/>

<complexType name="DefaultRedistribution_SS-VAType">

            <complexContent>

                        <extension base="pay:PaymentProtocolType">

                                    <sequence>

                                                <element name="DefaultReportID" type="string"/>

                                                <element name="DefaultedUser" type="pay:UserType"/>

                                                <element name="RemoveUserCredit" type="pay:RemoveUserCreditType" maxOccurs="unbounded"/>

                                                <element ref="dsig:Signature"/>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

<complexType name="RemoveUserCreditType">

            <complexContent>

                        <extension base="pay:PaymentBaseType">

                                    <sequence>

                                                <element name="AffectedUser" type="pay:UserType"/>

                                                <element name="Amount" type="long"/>

                                                <element name="AffectedOrderNumber" type="string" maxOccurs="unbounded"/>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

Figure 29 – RetrieveSubscriberData_VA-SS

 This message contains lthe dentifier of this report, information on the defaulted User, identifiers of the Users affected by the redistribution, the amount to be deductedfrom each VASP and the identifier of the Payment Order overdraft.

12.4.7.4       VASP (SE) – Subscriber (SE)

DefaultRedistribution_VA-SE is sent by the VASPs of Users who have received payments from the defaulted User to their relevant Users. 

<element name="DefaultRedistribution_VA-SE" type="pay:DefaultRedistribution_VA-SEType"/>

<complexType name="DefaultRedistribution_VA-SEType">

            <complexContent>

                        <extension base="pay:PaymentProtocolType">

                                    <sequence>

                                                <element name="DefaultReportID" type="string"/>

                                                <element name="DefaultedUser" type="pay:UserType"/>

                                                <element name="RemoveCredit" type="pay:RemoveSubscriberCreditType" maxOccurs="unbounded"/>

                                                <element ref="dsig:Signature"/>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

<complexType name="RemoveSubscriberCreditType">

            <complexContent>

                        <extension base="pay:PaymentBaseType">

                                    <sequence>

                                                <element name="Account" type="pay:AccountType"/>

                                                <element name="Amount" type="long"/>

                                                <element name="AffectedOrderNumber" type="string" maxOccurs="unbounded"/>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

Figure 30 – RetrieveSubscriberData_VA-SE

 This message contains the identifier of this report, information on the defaulted User, the identifiers of the accounts affected by the redistribution, the amount to be deducted from each Subscriber and the identifier of the Payment Order overdraft.

12.5 Protocols

WSDL  protocols can be easily derived from the XML representation of messages. They will included after the Open Source reference implementation will be completed.

12.6 Reference software

Under development

12.7 Links with iDRM and iNet

As it is clear from the use cases iPay and iDRM interact in the following points

  1. Seller issues a Cash Disposition containing the identifier of the content item (and possibly of the licence) in the transaction payload

  2. Seller issues a licence (that may be temporary or definitive) in exchange of a payment and makes it available to the buyer

  3. Seller does not reconfirms the temporary licence if synchronisation fails.

It is to be noted that licence nenotiation protocols could be employed with conditions against the monetary (point) value. In this case other interaction points will be developed.

13        Legislation proposal to support iPay

13.1        Introduction

13.2        Text of proposal

13.3        Relationships with other legislative proposals

14        Governance of iPay system

14.1        Objectives of iPay governance

14.2        Operation of iPay governance

15        Implementation examples of dmin.it proposal

15.1        Introduction

15.2        P2P iDRM

15.2        VHS 2.0

16 References

[1]

Dmin.it

Proposte di azione per dare all'Italia una posizione leader nei digital media, 2006/09/13 http://www.dmin.it/proposta/index.htm

[2]

Dmin.it

Specifiche funzionali, azioni normative e governance per la realizzazione della proposta dmin.it, 2007/03/15 http://www.dmin.it/proposta/proposta-operativa.htm

[3]

Dmin.it

Richiesta di piattaforme di Digital Rights Management (DRM) e pagamento elettronico http://www.dmin.it/proposta/richiesta-piattaforma-DRM-pagamenti.doc

[4]

Dmin.it

Richiesta di tecnologie e soluzioni per la realizzazione delle proposte dmin.it http://www.dmin.it/proposta/richiesta-tecnologie-soluzioni.doc

[5]

Dmin.it

Richiesta di commenti sugli interventi normativi necessari per la realizzazione delle proposte dmin.it http://www.dmin.it/proposta/richiesta-commenti-normativi.doc

[6]

Dmin.it

Richiesta di commenti sui sistemi di governance necessari per la realizzazione delle proposte dmin.it http://www.dmin.it/proposta/richiesta-commenti-governance.doc

[7]

DMP

DMP Technical Specification: Interoperable DRM Platform, Version 3.0 http://www.dmpf.org/open/dmp1003.zip

[8]

DMP

DMP Technical Specification: Use Cases and Value Chains, Version 3.0 http://www.dmpf.org/open/dmp1004.zip

[9]

DMP

Chillout – The IDP Reference Software http://chillout.dmpf.org/

[10]

Dmin.it

Wiki di dmin.action http://wiki.dmin.it/

[11]

ISO/IEC

ISO/IEC 23000-5, Media Streaming Aplication Format

17 Glossary

Term

Definition

4G

Fourth-generation mobile telephones (the 1st being TACS, the 2nd GSM and the 3rd UMTS)

ACS

Alternative Compensation Systems

Address space

All possible addresses with which the devices interconnected to a network can be identified. The address space can be private if the addressing is valid within a single organisation, or public if addresses must be universally univocal. As far as the Internet is concerned, a single authority (IANA) administers the governance of addresses.

Alternative Compensation System

Method of retribution of holders of rights other than direct economic retribution

B2B

Business to Business

B2C

Business to Consumer

Broadband

Bandwidth sufficient for transmitting audiovisual information of adequate level for entertainment applications

Best effort

Attribute of a network which makes a ‘sincere’ effort (similar to the legal concept of “best effort” contract) to deliver all data packages in transit under normal traffic conditions; when the network is overloaded, some data packages could get lost, delayed or delivered out of order.

BEUC

Bureau Européen des Consommateurs.

Bidirectional

Attribute of a network in which data can travel in both directions

CC

Creative Commons

CDN

Content Delivery Network

Content Protection 

see TPM

Digital content

See Digital media

Decoder

See Set Top Box

Digital media

Form of creation, distribution and use of content made possible by the fact that the content itself is expressed by means of bits which can be processed by programmable devices and can be transmitted by various types of protocols on digital networks

Digital Rights Management (DRM)

A system of computer-based components and services which aim at distributing and controlling content and the relative rights with digital techniques

DTT

Digital Terrestrial Television

DVB-H

Digital Video Broadcast Handheld

Event The result of any action performed by a User (e.g. play, copy, enlarge etc.)
Event Report The information generated by a Device as a result of an Event
Event Report Request The request that a User (e.g. a Creator or a Distributor) places in a Content Item that requests a Device to issue an Event Report

HSDPA

High-Speed Downlink Packet Access

IANA

Internet Assigned Numbers Authority

iDRM

Interoperable DRM

Interoperable

Adjective typically associated with:

  • A content, to specify the possibility of using that content on a device

  • A device, to specify the possibility of using a content on that particular device

  • A network, to specify the capacity of transferring data to another network with certain characteristics

IP

Internet Protocol

IPTV

Internet Protocol Television
The supply of television services, for example broadcast television and pay-per-view, Video-on-demand (VOD), interactive TV and the associated applications, realised on a broadband IP bidirectional network connected to a dedicated set-top box.

NGN

Next Generation Network

Open

An adjective typically associated with a technical solution that is public, completely specified, can be practiced from a party other than the one that specified it, possibly through the payment of royalties due to the intellectual property included in the specification. Examples: ISO/IEC/ITU/ETSI Standards etc.

OSS

Open Source Software

Peering

Operation with which different access or, generally, Internet connectivity operators connect their own networks. It represents the procedure thanks to which the different operators recognize each other’s equal status (literally: ‘relationship among equals’)

P2P

Peer-to-Peer

Platform

IN the distribution of contents: set of hardware and software devices thanks to which contents can be sent, received or used

Pay-per-view (PPV)

Pay service which allows a user to use single content upon payment

Quality of Service (QoS)

Characteristic by which a network can transmit data with predetermined characteristics

Rights Holder

Natural or legal person possessing the copyrights or the relative rights over a content

SET

Secure Electronic Transactions

Simulcast

The transmission of the same content with different characteristics (for example resolution) or on two different transmission systems

STB

Set Top Box

TPM

Technical Protection Measure
Any technology (encoding, watermarking etc.) aimed at preventing or discouraging the use of content to people without authorisation

UMTS

Universal Mobile Telecommunication System

Value chain

A group of intermediaries uniting in order to realise a business model and connected one to the other and with authors and end users. Intermediaries subsequently carry out added value functions to which transactions correspond

Venture Capital

A financial company which makes investments, especially towards fast-growing companies which however require a high level of capital

Walled garden

A set of content and services offered exclusively to a closed set of users

Work for hire

Intellectual work which should originate rights for those who are engaged in it but which instead reduces to simple salaried work


 

Released with Creative Commons licence Attribution - Non commercial 2.5
23 December 2007