WO2005036854A1

WO2005036854A1 - Method, system and computer program for managing usage of digital contents.

Info

Publication number: WO2005036854A1
Application number: PCT/IT2003/000622
Authority: WO
Inventors: Massimo Balestri; Giovanni Cordara; Stefano Dal Lago; Barbara Silano
Original assignee: Telecom Italia S.P.A.
Priority date: 2003-10-14
Filing date: 2003-10-14
Publication date: 2005-04-21
Also published as: AU2003279547A1

Abstract

The usage of digital content (C) by means of at least a usage device (PC, HF, STB, LP, TM, P) is 5 controlled by information elements (UR) that are representative of usage licenses. At least a terminal (TM) is provided, such as a mobile telephone, inserted in at least a communications network and having a memory area (SIM/USIM) associated therewith. The aforesaid information elements are stored, at least in part, in the aforesaid memory area (SIM/USIM) associated with the terminal. At least one of the following steps is performed:- loading the aforesaid information elements (UR) into the aforesaid memory area (SIM/USIM) via the communications network, and - controlling the usage of the aforesaid content according to the aforesaid information elements (UR) stored in the memory area (SIM/USIM).

Description

METHOD , SYSTEM AND COMPUTER PROGRAM FOR MANAGING USAGE OF DIGITAL CONTENTS

Field of the Invention The present invention relates to the techniques for managing usage or fruition of digital contents, fruition being controlled by information elements (UR) that are representative of usage or fruition licenses. The invention thus falls within the field of the management of those which are usually called "digital rights" , in particular in view of the use and consumption of media or digital content. Description of the Prior Art Valuable digital content must be protected when it leaves its legitimate owner to be distributed to users. Distribution entails the transfer of protected digital content from a so-called service domain (essentially, from the facilities of content providers) to a user's domain or environment (i.e. a certain set of fruition devices that belong to a user) . Protection substantially consists of means to prevent usage of content without the legitimate owner's approval. In other words, these are means to impose and enforce rules for the usage of content (for instance: possibility of reproducing/copying/moving content, number of plays or copies allowed, allowed playtime) within a user's domain. Usually, these results are achieved through a series of steps, i.e.: - defining usage rules by means of a formal language (i.e. a rights expression language), incorporating this description in a digital container (usually called a license) , - providing the aforesaid container to one or more devices in the user's domain together with related content, and - opening the aforesaid container, interpreting the description and enforcing said rules on said device or devices. Systems to generate, distribute, interpret, verify and apply said usage rules are normally called digital rights management or DRM systems. Within a network context, the implementation of

DRM systems is usually based on a remote server (DRM server) for the generation and distribution of rights.

The interpretation, verification and enforcement of said rights are instead usually the tasks of a specialised entity (a so-called DRM user agent) installed on any user device hosting protected content. In the prior art, several types of DRM systems are known and normally utilised. For instance, with reference to personal computers, one could mention the product known as Microsoft DRM for Windows Media. Other examples are represented by the so-called digital TV set top boxes (in this case the DRM function, in a simplified version thereof called conditional access, is usually implemented using a smart card, for instance in the case of satellite broadcasting) . Other examples can be made with reference to mobile telephones (see for instance the so-called DRM specifications issued by the organisation named Open Mobile Alliance) . For a general description of such techniques, reference can advantageously be made to the book by B. Rosenblatt et al . : "Digital Rights Management : Business and Technology" M & T Books, New York, 2002. Application scenarios for DRM systems and concepts underpinning them are constantly evolving, for instance to take into account the increasingly widespread habit to purchase on line rights to reproduce music in digital format . In this context, traditional implementations of DRM systems allow a user to browse an on-line music catalogue and download songs of interest . Music content, in the form of digital files, is thus provided to a user device, such as a personal computer. Each provided song or music track is protected by cryptographic means, so that the song or track can be played and listened to only by applying a particular decryption key. Music tracks can be acquired and freely circulated by users, since they are unusable unless the specific decryption keys are available. The keys in question may be included in license files supplied by a music provider, together with usage rules for each track. A user can thus purchase a license on line, clearing the related payment in some way, and download a license file onto her personal computer. To prevent the user from transferring to other users a license file without authorisation, the file in question can be cryptographically bound to a user-unique identifier. This result can be achieved for instance by means of a public key cryptographic infrastructure (PK ) : a private cryptographic key is delivered to a user and the corresponding public key is managed by the service provider. The keys are such that data encrypted with one key can only be decrypted with the other key (and vice versa) . For instance, a license file can be encrypted with a user public key so that only a particular user is able to decrypt it using the private key stored, for instance, on her personal computer. Of course, the problem is then shifted to preventing duplication and circulation of users' private keys, which in fact represent the cornerstone of the entire DRM system. A private key can be hidden by the service provided in the software or hardware layers of the user's personal computer. For instance, it can be derived from some machine identifier that can be accessed only by certain authorised programs running at the operating system (OS) level. Alternatively, the private key can be supplied on a so-called intelligent physical token, such as a smart card, which must be connected to the user's personal computer every time she wants to listen to a certain protected song. In either case, a software program of the service provider (DRM user agent) is used, for example, on the user's personal computer in order to: - identify an encrypted license corresponding to a specific protected track or song, have it decoded by the personal computer operating system or by the user's smart card, - extract a key for decoding the track or song and usage rules from the aforesaid license, and - decrypt the protected track or song and enforce usage rules (for example, allow the user to listen to the song or track only twice) . However, this way of operating is inherently quite rigid. Suppose that a user of a system as described above wishes to move some protected songs or music tracks from her personal computer to a hi-fi system or to a set top box, copy other songs or tracks onto a car CD player or to a portable player and leave the rest in the personal computer. In general, this is possible because tracks or songs can be freely copied and moved within the user's domain; however, a specific license is required to play each of them correctly. In principle, one could imagine that - on all aforementioned devices - a DRM user agent is available that can apply the aforesaid sequence of operations to the songs or tracks of interest. In this case, though, the user should ensure that the DRM user agent running on each specific device can access the specific license needed to play a given track or song. Usually, however, licenses cannot just be copied and moved from one device to another, for example because they are cryptographically bound to a portion of the device where the user's private key is stored. If, for example, such device is the user's personal computer, licenses can be decrypted and used only on that personal computer. Theoretically, if one equips each user device with a different private key, the licenses need to be decrypted with the source device key and then again encrypted with the destination device key before moving them from one device to another. Then the reverse sequence of operations needs to be performed when the user decides to bring the songs or tracks back onto the original device. Apart from any other remark, although the user is able to freely move and copy her songs on any device within her domain, the need remains to keep track of where each license is located at all times, in order to transfer it from one device to another as needed. This is clearly unfeasible as the number of tracks or songs increases, and it imposes considerable limitations to the user's freedom of playing the same song or track on all of her devices. Examples of such embodiments are represented by so-called digital TV set top boxes used for receiving non free-to-air transmissions, in which a private key belonging to the user is usually placed in a portable device, such as a smart card. With reference to such a solution, licenses encrypted with such a private key could be used on multiple user devices, copying a license from one device to another and inserting the smart card in the target device, after copying and transferring the license, to obtain thereby the decryption of the license thus moved. An additional example consists of securely storing data representing a user within a DRM system (for instance a user private key) in a portable device that is not a smart card but, for example, a mobile telephone, a palmtop computer or any embedded device. This type of solution is disclosed, for example, in document WO-A-03/005174 , which describes a method and a portable apparatus for using multimedia content and enabling the user to control usage of such content based on a set of attributes pertaining to her personal identity. Control can be applied to a certain number of content consumption terminals such as for instance portable video and audio players . In this known solution, a portable device is essentially used to store information that allows to use licenses, but licenses themselves always remain on the various content consumption devices and they must be managed separately by the user. In particular, the user has to ensure that licenses are in fact where she needs them on each occasion. For instance, she needs to remember to copy the necessary licenses to the car player if she wants to listen to certain songs or tracks while driving. It will be appreciated that the problem cannot be solved simply by broadcasting licenses to all devices within the user's domain. This is because licenses with a status (i.e. licences containing usage rules that change as content is used - for instance because they set the maximum number of plays allowed for a certain song or track) cannot simply be copied from one device to another. They must be deleted from the source device after they have been transferred to a destination device. In any case, appropriate synchronisation of status information must be obtained, which is challenging and not very practical. For instance, when making multiple copies of a license that allows for a limited number of plays, the original allowed-number-of-plays must be distributed amongst the various copies, otherwise it is necessary to update all copies with the residual allowed-number- of-plays as a given song or track is played in one or more devices where the copies of the license reside. In any case, an underlying problem is that the user must always deal with two entities, i.e. content and licenses, checking that content and licenses are always in mutual agreement . It can be easily understood that this task is rather challenging, potentially confusing and in any case inconvenient for an average user who obviously does not want to have to deal with issues of this nature. Nor are the problems in question solved by solutions like those disclosed in WO-A-03/003173 or WO- A-02/052843. These prior documents describe systems that would allow a portable device to control the consumption of certain content by other devices belonging to the user. In such cases, too, digital rights, or equivalent information, must be stored on each content consumption device. This is because the portable device serving as the verification device is substantially only a means for authenticating the legitimate user and unlocking use of the digital rights in question. Object and Summary of the Present Invention The object of the present invention is to provide a solution that is able to overcome the intrinsic drawbacks of the prior art solutions described above. According to the present invention, said object is achieved thanks to a method having the characteristics specifically set out in the claims that follow. The invention further relates to the corresponding system as well as to a corresponding computer product that can be loaded into the memory of at least an electronic computer, comprising portions of software code to implement the method according to the invention when the product is run on a computer: within this context, said term should be deemed wholly equivalent to the mention of a computer-readable means comprising instructions for controlling a computer system to implement a method according to the invention. Reference to "at least an electronic computer" is of course intended to highlight the possibility of realising the solution of the invention in a decentralised context. Briefly, the solution described herein is based on the possibility of storing licenses in a terminal, such as a portable device (typically a mobile telephone) , thereby turning such a terminal into a centre for the centralised management of the aforesaid licenses, all placed in a single device that, in the case of a mobile telephone, is a commodity normally available to anybody, carried along by most people as they move around. The user can thereby bring with her her "digital rights" together with her digital identity, being able to browse, select, delete or add license items at any time with no need to physically connect the portable device to the consumption devices where content is actually stored. It will be particularly appreciated that a mobile terminal such as a mobile telephone can also be used as an actual remote control to enable the use of protected content stored in the aforesaid consumption devices. This can occur by exploiting the nature of the terminal as a terminal of a mobile network which can also be a Bluetooth network or simply a LAN network in which the various user devices represent the respective terminals, or by exploiting (in substantial analogy with more traditional remote controls) the infrared interface already available on some portable telephones . A terminal such as a mobile telephone is also capable of performing an important role for the acquisition of individual licenses, thanks to the ability to set up data connections to a license server, exploiting mobile terminals security and authentication features within a mobile telephone network in order to carry out the transactions related to the purchase of a given license. Moreover, the display normally associated to a mobile telephone for the visualisation of SMS or MMS messages can be used to present a user with a legible, complete, legally correct text of a license agreement, obtaining her approval expressed by applying a positive command - according to procedures which can be documented in the future - on the telephone terminal . A preferred embodiment of the invention therefore provides the implementation of a method for managing usage or fruition of media content by means of at least an usage or fruition device, fruition being controlled by information elements which are representative of usage or fruition licenses. The method further comprises the steps of: - providing at least a terminal inserted in at least a communication network, the terminal having associated therewith a memory area, such as at least a part of the SIM/USIM card of a mobile telephone, - storing the aforesaid information elements in said memory area associated with the terminal, as well as at least one (and preferably both) of the operations of: - loading the aforesaid information elements in the memory area through the communication network, and - controlling the fruition of the aforesaid media content according to the information elements stored in the aforesaid memory area. In a particularly preferred embodiment of the invention: the user stores her information elements (digital rights), i.e. her licenses, on the SIM/USIM card of her mobile telephone exploiting centralised license management by a program running on the aforesaid SIM/USIM (which therefore performs an active role, not one of mere storage) , while allowing programs running on other devices to communicate with the program or with the programs running on the SIM/USIM to request authorisations to use certain protected content , and - the aforesaid programs running on the SIM/USIM can grant said authorisations according to the digital rights available to the user, with no need to physically move the aforesaid digital rights away from to the SIM/USIM card. Although heretofore it has been a common practice to let protected content and associated rights physically reside on the same physical device, to allow for checking and enforcement of usage rules, the solution described herein is based on the remark that it is actually far more convenient for a user to have all of her rights (i.e. her licenses) stored in a single storage device, in order be able to apply them to content located on other devices within the user's domain. It is thereby possible to achieve a centralised management of a user's digital rights, while avoiding the problems linked to the transfer and duplication of the aforesaid rights, and at the same time allowing use of content on different devices. The aforesaid centralised license management scheme has various advantages . A given license is available at any time on the SIM/USIM card and the user need not transfer it manually to the various devices where she intends to consume content . There is only one instance of any state full license, physically located in the SIM/USIM. Therefore, the corresponding status is always consistently updated, regardless of the number of content consumption devices. The user can easily obtain a report regarding all of her digital rights and the related states at any given moment in time. This can be achieved by simply querying the SIM/USIM card. The user need not worry about licenses or keys, she may even be unaware of the very existence of licenses. All she needs to know is that, as a result of certain payments, the SIM/USIM card in her mobile telephone can be configured to trigger, for example, digital music consumption on various home devices or, for instance, in an automobile, or by means of a portable device. Such a centralised license management scheme, implemented on a SIM/USIM card, has also various inherent advantages, related to the fact that a mobile telephone is a widespread personal device, typically carried along by the user wherever she goes . Additionally, it is already equipped with various communications interfaces, it has information storage capabilities on board and sports tools for searching through stored information (for instance an electronic date book or address book, tools for sending or receiving SMS or MMS messages) . It also features, especially as regards the

SIM/USIM card, a certain level of robustness to tampering and cryptographic supports, thus providing an adequate level of security for digital rights stored therein. With reference to the on-line music distribution example mentioned above, it can be seen that user procedures are considerably simplified with respect to usual ones and to the possibilities set out in the introductory part of the present description. Brief Description of the Accompanying Drawings The invention will be described, purely by way of a non limiting example, with reference to the accompanying drawings, in which: - Figure 1 is a conceptual diagram of a system exploiting the solution described herein, - Figure 2 is a functional block diagram of the solution described herein, and - Figure 3 is a flow chart representing a possible sequence of operations of the solution described herein. Detailed Description of an Embodiment of the Invention The block diagram of Figure 1 is a conceptual diagram of a DRM system allowing a user to copy songs or music tracks from a personal computer PC to other devices, such as an hi-fi system HF, an MP3 portable reader LP, a set top box STB associated with a television set TV, an electronic games console or play- station PS. We also assume that the user has a mobile terminal (mobile telephone) , equipped with a SIM/USIM card and separate or at least different from the above devices. The user is thus able to connect through her mobile telephone TM with a service centre SC in order to acquire some usage rights (digital rights) , labelled UR, allowing her to play certain songs or music tracks corresponding to content C that may physically reside on any, and virtually on all the various aforementioned devices PC, HF, STB, LP, PS. The user can download "digital rights" UR from the service centre SC onto her card SIM/USIM through the mobile telephone network (of any known kind, but preferably of the kind configured for data transmission, such as WAP, GPRS, UMTS) upon payment typically made through the mobile telephone network according to ordinary payment procedures . It will be appreciated that, once the digital rights or licenses UR are acquired from the service centre SC, they physically reside on the user's SIM/USIM card, from which they can be used to unlock content C (wherever content C is within the user's domain) , with no need to move the rights UR out of the SIM/USIM card. In particular, if the user wants to play a song or a track on a specific device, for instance hi-fi system HF, she can send an appropriate command, for instance by means of a connection of any known kind - wired or infrared - or even exploiting the characteristics of a network (for instance a Bluetooth network) of which the terminal TM is part. Physical connections from external devices towards the SIM/USIM card go through the mobile terminal TM which houses the SIM/USIM card in question. However, end-to-end communications at the logical level can be achieved directly between each device and the SIM/USIM card itself, as shown schematically in Figure 1. The mobile terminal TM serves solely as a physical routing device. If a wireless connection is available, in order to give the SIM/USIM card control over a certain device, it is sufficient to place the mobile terminal TM in proximity of the device in question and have commands issued as described in detail hereafter. To allow the HF system to play a certain track or song, the DRM user agent residing together with content C on system HF simply requests from the SIM/USIM card hosted by mobile terminal TM permission to play said song or track. If a related license is available in the

SIM/USIM card, and usage rules contained therein allow playing the track or song, then the track decryption key is extracted from the license and transmitted to the DRM user agent on system HF. The agent in question then decrypts and plays the song or track. It will be appreciated that the physical channel whereon the decryption key travels can be made secure, in particular when the connection is a wireless one, to prevent unauthorised access to sensitive data. This result can for instance be achieved using the cryptographic capabilities already available on the SIM/USIM card and ensuring that corresponding tools are available in the content consumption device (for instance system HF) . Figure 2 shows the logical structure of the physical system illustrated in Figure 1. As seen above, the system allows the user to purchase and play, for instance, music tracks or songs according to typical e-commerce procedures. Functionally, the system can be divided into two major blocks, i.e.: - a service domain 1, which represents a set of functions or facilities located at the service centre SC, and - a user domain 2 , which groups the various user devices seen above, wherever they are located (within the user's home environment, or even outside, for instance in a car, or on a portable reader) . In the embodiment illustrated herein, which is merely an example, service domain 1 essentially comprises a content server 3 that delivers protected content and a DRM server 4 which hosts licenses relating to the aforesaid content. User domain 2 in turn comprises: - a consumer electronics device 5, for instance a hi-fi system, a set top box, a car player or a portable player, - a fixed or mobile computing platform 6, such as a personal computer or portable digital assistant, and - a mobile telephone 7 with the related SIM/USIM card, designated as 8. Essentially, the system shown in Figure 2, comprises three types of different functions. Firstly, functions are provided for storing licenses, for instance by organising them in a database. Secondly, DRM agent functions are provided, which essentially comprise managing licenses (license interpretation and updating, for instance) , granting authorisations to access certain protected content in accordance with usage rules carried by licenses, and providing data embedded within licenses, for instance content decryption keys. Thirdly, DRM client functions are provided that are typical of content fruition devices. These include, for instance, managing protected content stored locally on various devices, requesting permissions to use the aforesaid protected content, receiving content decryption keys and decrypting protected content, and lastly actually using said protected content and reporting about protected content consumption. In the specific system shown in Figure 2, a DRM client function 9 is implemented on an electronic device 5, whilst another DRM client function 10 is implemented on a computer (PC/PDA) 6 and yet a third DRM client function 11 is implemented on a mobile telephone 7. In a SIM/USIM card 8 a DRM agent function, labelled 12, and a license storage function, labelled 13, are available. It will thus be appreciated that, in the embodiment described herein (which is an example) , card 8 does not perform merely a "passive" storage role, but also an "active" role, because of the DRM agent function implemented by means of software loaded on SIM/USIM card 8 (see also in this regard steps 108 to 111, 119 to 123 and 127 - 128 better described below with reference to Figure 3) . All described functions can be implemented - according to well-known techniques - in the form of software modules, for example as programs natively running or downloaded onto the various devices with ordinary techniques (for instance HTTP downloading or by means of WAP techniques) . Alternatively, these functions can be directly embedded within hardware modules present in the devices in question (in particular, this embedding action can be performed by a mobile telephony operator while configuring its own SIM/USIM cards) . Hereafter, it will be supposed for the sake of simplicity that all these functions are provided by the same service provider that operates and owns service domain 1. In greater detail, the software supply step can be organised as follows. When the user subscribes to the on-line music downloading service, she is informed by the provider that : - use of the service requires that all devices through which downloaded music is to be played must be compliant with certain requirements (for instance they must run a given software) , while consuming protected content, the user mobile telephone will have to be switched on and, for instance, placed in the proximity of the device where protected music is to be played, - upon charging, the mobile telephone will be automatically configured to allow protected music playing on that device. For example, with reference to the diagram of Figure 2, in order to play the music downloaded on computer 6 and device 5, the user must first complete the following operations: - check SIM/USIM card 8 to ascertain that it is compliant with service requirements (for instance, that it has enough memory capacity to hold data 13 that represent the necessary licenses) , - verify that DRM client module 9 is available on device 5 (hereinafter it will be assumed that such module is already present on device 5) , - install a similar DRM client, labelled 10, on computer 6 (which is initially supposed not to be equipped with the related software packages, which therefore need to be downloaded from the service centre) , and - approve the installation of a DRM client 11 and a DRM agent 12 (which are also software packages) on mobile telephone 7 and on SIM/USIM card 8. With reference to the flow chart of Figure 3, once a usage session has been started in a step 100, in a step 101 user U browses (for instance using the terminal) an on-line music catalogue published by the content server, for example in the form of a corresponding Website available on the Internet . After selecting a track or song A from the catalogue, in a step 102 user U downloads the related file A from server 3 onto terminal 6 for instance according to HTTP downloading procedures. It is assumed that the file corresponding to track or song A was previously encrypted by the service provider using standard encryption techniques, for instance the well known AES algorithm (Advanced Encryption Standard) . After switching on her mobile telephone 7, user U in a step 103 starts DRM client 11 from the application menu of mobile telephone 7 and enables, in a step 104, for example communications with a Bluetooth standard, using the related menu on mobile telephone 7 and also places mobile telephone 7 in proximity of terminal 6. User U then activates DRM client 10 by starting the corresponding application on terminal 6 and asks, in a step 105, client 10 to open song A file in order to play it. DRM client 10 recognises that this file is encrypted, for instance by examining an appropriate file header. Then, DRM client 10 checks the local connections on terminal 6 (such as infrared connections, Bluetooth, USB and serial ports) and finds out, for instance, that DRM client 11 is currently connected to terminal 6 through a Bluetooth link of mobile telephone 7. In a step 106, DRM client 10 establishes a secure and authenticated communications channel with DRM client 11. This can be accomplished by using a well known procedure (for example, opening a so-called SSL socket) , so that each subsequent exchange of information between DRM client 10 and DRM client 11 takes place on such secure channel. In a step 107, client 10 asks client 11 for permission to play track or song A, providing for example client 11 with a unique track identifier, extracted from track A file header. In a step 108, DRM client 11 routes the request to DRM agent 12. Communications between DRM client 11 and DRM agent 12 can be implemented using any application protocol . For instance, if DRM client 11 has access to the corresponding Application Programming Interface (API) on mobile telephone 7, it can send to SIM/USIM card 8 protocol data units (PDU) formatted according to the ISO/IEC 7816 specification, which regulates in general low level communications with smart cards . Alternatively, it can write specific application messages into a file in the SIM/USIM card, for example by using the provisions of the ETSI 11.11 specification for basic interactions between mobile telephone and SIM card. In a step 109, DRM agent 12 checks whether a license is available for song A in license memory 13. If, in a step 110, DRM agent 12 finds no license, in a step 111 it asks the DRM client to download one from DRM server 4. DRM client 11 establishes (through the mobile communication network) a secure and authenticated communications channel with DRM server 4 using a standard procedure (for example opening a so-called SSL socket over a GPRS connection, or communicating via SMS) . This takes place in a step 112, in which DRM server 4 is asked to provide a license for track or song A by means of a specific application protocol (for instance HTTP) . After the license is requested in a step 113, in a step 114 DRM server 4 informs DRM client 11 that the requested license can be purchased by user U at a certain price. In a step 115, DRM client 11 informs user U of the license price, requesting approval of the charging, for instance by showing a dialogue box on the mobile telephone display. The display can also show any other constraints associated to the license, such as the number of times the track may be played, or playtime limitations. It may also show user U any alternative license options with the relevant prices. It is assumed herein that, in a step 116, user U accepts to be charged for a specific license, for example she purchases a license to play song or track A twice. In a step 117 DRM client 11 authorises DRM server

4 to bill user U for the purchase. Billing can be implemented within service domain 1, for example by subtracting a corresponding amount from a prepaid credit of user U, or by charging a corresponding amount to user U's telephone bill if the service provider is a mobile telephone operator or has an agreement with a mobile telephone operator. In a step 118 DRM client 11 downloads the license for song or track A from DRM server 4. The downloaded license is transferred in a step 119 to DRM agent 12 which stores it in memory area 13. This takes place in a step 120, whilst in steps 121 and 122 DRM agent 12 extracts the decryption key for track or song A file and usage rules from track or song A license and subsequently checks whether the request to play track or song A is compatible with the aforesaid usage rules (for instance, it checks that the allowed-number-of-plays in the license is equal to or greater than 1) . In the example illustrated herein, it is assumed that user U has purchased a license to play the song or track twice, so this comparison yields a positive result. In a step 123, DRM agent 12 passes the decryption key for track or song A file to DRM client 11 that, in turn, in a step 124, transfers it to DRM client 10, simultaneously granting permission to play track A. In a step 125, DRM client 10 uses the received decryption key to decrypt track or song A file and play it. In a step 126, DRM client 10 notifies DRM agent 12 (as usual, via DRM client 11) that track or song A has been played once. The aforesaid notifications are represented by steps 126 and 127. Lastly, in a step 128, DRM agent 12 correspondingly updates track or song A license, for example by decrementing the allowed-number-of-plays within said license. It will be appreciated that steps 100 to 128 shown in the diagram of Figure 3 are understood to refer to the various elements identified by numbers 3, 4, 6, 7, 8, 10, 11, 12, 13 and to user U as indicated in the topmost row of the diagram. At a subsequent time, user U can for instance copy track or song A file from terminal 6 to system 5. This can take place, for instance, via a LAN connection or simply by transferring a physical storage device such as a memory card or a disk. Supposing for example that device or system 5 is a car player, we assume that user U inserts a memory card holding track A into the car player and places mobile telephone 7 in the car, for instance in dock-in station featuring a serial link with the car player. User U then turns mobile telephone 7 on and starts DRM client 11 once again. User U then starts (with the same procedures seen above) DRM client 9 on device or system 5 and requests it to play track A. DRM client 9 realises that DRM client 11 is currently connected to system 5 via mobile telephone 7 serial link. At this point, DRM client 9 asks DRM client 11 for permission to play track A. DRM client 11 routes the request to DRM agent 12 as seen above, which causes memory 13 to be checked to ascertain whether a license is available for song or track A. With reference to the example seen above based on the diagram of Figure 3, it is assumed that DRM agent 12 is able to check the availability of this license and hence to extract the decryption key for track A file and track A usage rules . It then checks that the request to play track A is compatible with the aforesaid usage rules (for example, that the allowed- number-of-plays in the license is still equal to or greater than 1) . With reference to the above example, considering user U has purchased a license to play track A twice, the result of the comparison is once again positive. At this point DRM agent 12 passes the decryption key for track A file to DRM client 11, which in turn transmits it to DRM client 9, granting it permission to play music track A. DRM client 9 uses the received decryption key to decrypt track A file and plays it . DRM client 9 notifies DRM agent 12, via DRM client 11, that track A has been played once. DRM agent 12 correspondingly updates track A license, for instance decrementing the allowed-number-of-plays within the license itself. In this specific case, since track A license originally allowed for two plays, the allowed-number- of-plays is now zero. Consequently, any subsequent attempt to play music track A either on terminal 6 or on device or system 5 will result in DRM agent 12 denying permission and requesting DRM client 11 to download a new license from DRM server 4 as described above . The above example shows that the solution described herein allows to centralise the storage and management of digital rights of a user U within the SIM/USIM card of her mobile telephone, achieving considerable advantages in terms of service flexibility and simplicity and allowing for controlled and consistent access to protected content located on a plurality of user devices. All this while providing handy administrative management of content usage rules and decryption keys . User U needs not worry about transfer and duplication of licenses among the various devices she intends to use, or obtain and carry with her any additional devices representing her digital identity in the specific service context (for example, a specific smart card) . The desired result is achieved through the SIM/USIM card available in her mobile' telephone in a very intuitive and simple manner. It is evident that the work flow described above is representative only of one interaction pattern amongst the many possible within a DRM system. The principle described herein is wholly broad and general and in particular it is independent of the specific license format or media coding scheme and of any specific formal language which may be used to support interactions between DRM server, DRM client and DRM agent . The privileged functional entity that responds to requests and grants authorisations for using protected content based on usage rules, without in itself disclosing or distributing valuable digital rights, can be implemented according to physical configurations that may differ from the one shown in Figures 1 and 2. For example, a user's mobile telephone can itself become a protected content consumption device according to the solution described herein, besides keeping enabling other devices. According to other possible embodiments of the invention, the license storage function can be implemented in part in the SIM/USIM card of the mobile telephone, and in part in an additional memory area, located in the user's domain or at the service provider premises, where licenses requested by a DRM agent function can be found. This solution is particularly advantageous when the number and nature of licenses is not incompatible with a SIM/USIM card memory constraints . As a variation, according to an additional embodiment of the invention the license storage function can be wholly implemented in a memory area located in the telephone itself. The same solution can be used to provide a recovery service for lost, damaged, or simply replaced SIM/USIM cards, allowing for example to download again from a back-up memory area all licenses acquired by and available to user at a certain date. Although the invention has heretofore been described with reference to authentication functions performed by a SIM/USIM that can be separated from the telephone, it also applies if the authentication functions, instead of being performed by means of a SIM/USIM are carried out by devices that are integrated with the telephone itself. Therefore, it is evident that, without altering the principle of the invention, the construction details and the embodiments may depart widely from what is described and illustrated herein, without thereby falling out of the scope of the present invention, as it is defined by the accompanying claims. In particular, it will be appreciated that most of the advantages identified above are maintained even if the terminal TM is not a mobile terminal but, for example, a terminal located in a fixed position in a house, being for instance associated to a content consumption system or device.

Claims

CLAIMS 1. A method for managing usage of digital content (C) by means of at least one usage device (PC, HF, STB,

LP, TM, PS) , the usage being controlled by information elements (UR) that are representative of usage licenses, characterised in that it comprises the steps of: - providing at least one terminal (TM) , different from said usage device, inserted in at least one communications network, the terminal (TM) having associated a memory area (SIM/USIM) , - storing (120) said information elements in said memory area (SIM/USIM) associated to said terminal (TM) , and at least one of the steps of: - loading (118) said information elements in said memory area (SIM/USIM) via said at least one communications network, and controlling (124) the usage of said digital content according to said information elements (UR) stored in said memory area (SIM/USIM) .

2. A method as claimed in claim 1, characterised in that said at least one terminal (TM) is a terminal of a mobile communications network.

3. A method as claimed in claim 2, characterised in that said mobile terminal (TM) is provided with a SIM/USIM card and in that said memory area is located, at least in part, in said SIM/USIM card.

4. A method as claimed in claim 3, characterised in that it comprises the step of locating in said

SIM/USIM card at least one function (DRM) for managing said information elements (UR) .

5. A method as claimed in claim 1, characterised in that it comprises the step of configuring said terminal (TM) as a device for the usage of said digital content (C) .

6. A method as claimed in claim 1, characterised in that it comprises the step of notifying (126, 127) from said at least one usage device, the usage of a given piece of media content (C) and the step of correspondingly updating (128) said information elements (UR) .

7. A method as claimed in claim 1, characterised in that it comprises the step of locating said digital content (C) in said at least one usage device (PC, HF, STB, LP, TM, PS) .

8. A method as claimed in claim 1, characterised in that it comprises the step of transferring, at least in part, said digital content (C) amongst different usage devices (PC, HF, STB, LP, TM, PS) .

9. A method as claimed in claim 1, characterised in that it comprises the step of performing, in a generically remote position relative to said terminal (TM) , at least a partial storage of the information elements (UR) representative of the licenses held by a given user.

10. A method as claimed in claim 1, characterised in that it comprises the steps of: - encrypting said digital content (C) by means of a key, and - enabling, according to said information content (121), the extraction of the cryptographic key (122) related to a giyen piece of media content (C) .

11. A method as claimed in claim 1, characterised in that it comprises the step of billing a user (116, 117) for the release of a given license via said at least a communications network.

12. A method as claimed in claim 1, characterised in that it comprises the step of enabling said at least a usage device (PC, HF, STB, LP, TM,PS) to deliver a given piece of media content (C) by placing said terminal (TM) in proximity of said at least a usage device .

13. A system for managing the usage of digital content (C) by means of at least one usage device (PC, HF, STB, LP, TM, P) , the usage being controlled by information elements (UR) that are representative of usage licenses, characterised in that it comprises at least one terminal (TM) , different from said usage device, inserted in at least one communications network, the terminal (TM) having associated a memory area (SIM/USIM) in which said information elements

(120) are stored.

14. A system as claimed in claim 13, characterised in that said terminal (TM) is configured to perform at least one of the steps of: - loading (118) said information elements in said memory area (SIM/USIM) by means of at least one communications network, and - controlling the usage of said digital content according to said information elements (UR) stored in said memory area (SIM/USIM) .

15. A system as claimed in claim 13, characterised in that said at least one terminal (TM) is a terminal of a mobile communications network.

16. A system as claimed in claim 15, characterised in that said mobile terminal (TM) is provided with a SIM/USIM card and in that said memory area is located, at least in part, in said SIM/USIM card.

17. A system as claimed in claim 16, characterised in that it comprises, located in said SIM/USIM card, at least one function (DRM) for managing said information elements (UR) .

18. A system as claimed in claim 13, characterised in that said terminal (TM) is configured as a device for the usage of said digital content (C) .

19. A system as claimed in claim 13, characterised in that said terminal (TM) is configured to receive, from said at least one usage device, the notification (126, 127) of the usage of a given piece of media content (C) and correspondingly to update (128) said information elements (UR) .

20. A system as claimed in claim 13, characterised in that said digital content (C) is located in said at least one usage device (PC, HF, STB, LP, TM, PS) .

21. A system as claimed in claim 13, characterised in that said digital content (C) is distributed, at least in part, amongst different usage devices (PC, HF, STB, LP, TM, PS) .

22. A system as claimed in claim 13, characterised in that it comprises, in a generically remote position relative to said terminal (TM) , at least one partial storage of the information elements (UR) representative of the licenses held by a given user.

23. A system as claimed in claim 13, characterised in that said digital content (C) is encrypted by means of a key and said terminal (TM) is configured to enable, according to said information content (121) the extraction of the cryptographic key (122) related to a given piece of media content (C) .

24. A system as claimed in claim 13, characterised in that said terminal (TM) is configured to bill a user (116, 117) for the release of a given license via said at least one communications network.

25. A system as claimed in claim 13, characterised in that said terminal (TM) is configured to enable said at least one usage device (PC, HF, STB, LP, TM,PS) to deliver a given piece of media content (C) being positioned in proximity of said at least one usage device .

26. Communications network comprising at least one system for managing usage of digital content (C) as claimed in claims 13 to 25.

27. Communications network as claimed in claim 26, characterised in that it comprises at least one memory area able to store, at least in part, said information elements (UR) .

28. A computer product able to be loaded into the memory of at least one electronic computer and comprising portions of software code to implement the method as claimed in any of the claims 1 through 12.