HK1078713B - Method and client for digital rights management for streaming media - Google Patents

Description

Digital rights management method and client device for streaming media

Technical Field

The present invention relates generally to rights management (digital rights management) techniques for managing digital content provided via a network, and more particularly to methods, apparatuses, and systems for managing rights related to streaming media.

Background

The distribution of digital content or media implemented using modern digital communication techniques is growing, gradually replacing the more traditional methods of distribution. In particular, there is an increasing trend to download or stream digital content from a content provider via a network to a client or user who then renders the content, typically using a rendering device, according to certain user rights or usage rules specified in a license associated with the digital content. Since this form of content distribution has the advantages of being cheap, fast and easy to implement, applications for distributing all types of content including audio, video, images, electronic books and software, especially mobile phone specific content such as ringing signals and background images for mobile phone screens, can be found today.

However, accompanying this entirely new way of digital media content distribution comes the need to prevent unauthorized use and illegal copying of the digital assets of the content provider. Of course, copyright holders and creators of digital content have a strong economic interest in protecting their rights, thereby resulting in an increasing need for rights management (DRM). Generally, DRM is a technology for protecting assets of content providers in a digital content distribution system, which includes processes of protecting, monitoring, and limiting the use of digital content and payment. DRM systems therefore typically contain components for encryption, authentication, key management, usage rule management, and charging.

The most fundamental threats to DRM systems include eavesdropping, illegal copying, modification of usage rules, removal of DRM protection, and wide-ranging unauthorized use by redistributing unprotected content. Of these basic security issues, most are addressed by standard cryptographic techniques, including encryption, authentication, integrity protection, and key management. However, the security problem of DRM systems is essentially different from other general security problems in that even other terminal parts in the communication are not completely trusted. In fact, the end user may wish to attempt to extend his usage rights in a fraudulent manner, such as rendering the media content more than it pays or illegally copying the digital content to another rendering device. Therefore, some form of rule enforcement needs to be performed in the rendering device of the client. For this purpose, a DRM agent or module implemented as software and/or anti-tampering circuitry in the rendering device and some formal language expressing usage rules are typically used together with the basic cryptographic techniques described above. To see the general background on encryption, we can refer to [ HAC ].

While reliable transport protocols may be used to download all of the above media types to the user device, for real-time applications, and for other reasons, it is sometimes desirable to stream media, such as music or video, to the client in a digital stream. Streaming media means that data is transferred to a client in a continuous stream before all media data is received in an efficient way taking into account the data application. Examples of streaming being more feasible than downloading include live sporting events, concerts or other long-lasting media where, for example, due to real-time or storage requirements, the entire or parts of the media cannot be downloaded prior to rendering. Streaming is typically delivered by using unreliable transport mechanisms that may cause errors or loss of data parts (we do not consider "cumulative download" as streaming, which is described more below). The rationale for using unreliable transport mechanisms is because real-time needs are too high to retransmit lost media data and the risk of quality loss is sometimes acceptable and/or managed by error correction codes or other technical measures. Due to the inherent differences mentioned here and differences in delivery, downloading and streaming media require different measures to protect the content, which in turn requires special handling when managing rights. This difference is emphasized in wireless networks, such as mobile telephone networks, where interference and data loss are more frequent than in wired networks.

In particular, the present invention encompasses a solution common to DRM for downloading content and DRM for streaming media. This solution can be implemented with little impact on existing systems for downloading DRM protected content and managing rights.

State of the art

Described below are rights management techniques currently used for "content" used by clients. The content is typically referred to as digital data objects and may be downloaded using a reliable transport protocol, such as TCP, which is described more below. Examples of downloadable digital content include audio, video, images, electronic books, and software, particularly mobile phone specific content such as ring signals and background images for mobile phone screens. Associated with the content is a license that specifies client usage rules and rights associated with the acquired digital media.

DRM aims at managing the digital content itself and handling various issues such as who gets the content, how to deliver the content, how many times the content is used (rendered, saved, forwarded, copied, executed and/or modified), how many times the content can be used, how long the rights last, who gets paid, how much they get paid and how much it gets paid. Some or all of these issues may be specified in a license that may be delivered either with or separate from the digital content. To describe usage rules, a specialized language known as rights expression language has been developed. Of the most popular rights expression languages currently in use, two of them are the extensible rights markup language (XrML) and the Open Digital Rights Language (ODRL).

The most difficult part of DRM is to enforce the usage rules contained in the license that are specified for the digital content. As shown in the background, cryptographic techniques combined with tamper resistant devices are a common component in existing DRM solutions. Also, in such environments, for example, privacy algorithm and protocol dependent obfuscation (obfuscation) techniques are also used, where such techniques are mainly used in proprietary solutions, as this approach hinders security assessment and interoperability between different solutions.

For download-type DRM, the most common data structure is based on separating content and rights to use the content from each other while maintaining an association between the content and the rights to use the content. An example of DRM downloading is first described with reference to fig. 1, while some variations will be given later, mainly relating to the protection of content and rights.

In the example of fig. 1, the portion containing the downloadable content is referred to as a "content object" or "content container" 1. The part containing the usage rights is denoted "rights object" 2. Other synonyms for a rights object are "ticket" or "license". The content object then contains the actual digital content 3 and the metadata 4. The content is typically stored in a protected form, such as the encrypted and integrity protected form shown by bold line rectangle 5. The rights object contains usage rights 6, content cryptographic keys 7 and metadata 8, typically expressed in a rights expression language. By using the content key it is possible to check whether the protected content is reliable and the extracted plaintext digital content. The metadata in the content object may include the content object identity, information about the actual content, the name and location of the rights holder, relevant information for rendering the content such as the relevant application or content type, a reference to a location where the relevant rights object can be accessed/purchased, e.g. a Uniform Resource Locator (URL) to a web server hosted by the content provider/distributor (host). The metadata of the rights object typically contains a reference to the content object to which it applies, such as a content object identity or an encrypted content (cryptographic) hash. Typically, a given rights object is uniquely associated with a particular content object. Whereas a given content object may sometimes have several rights objects associated therewith; this occurs because different uses of the same content are allowed without having to change the content object. For security reasons, the same content may be encrypted with different encryption keys and may be stored in different content objects, so that disclosing a particular secure content key does not reveal the plaintext content to the owner of the content object in question for this particular content, but only to those owners having the particular content object encrypted with this key.

A variation of the above example is that the entire content object is protected as a whole, not just the content. Another variation is to use an encryption key to encrypt the content key in the rights object and to save the thus encrypted content key in the rights object instead of the clear content key. Yet another variation/addition is that the rights object contains a "validation tag" in addition to the above. By including this tag, the right to use and/or the content key and/or the metadata, either as plaintext or encrypted, can be integrity protected. Since a rogue user may change the licensing rights to his liking, regardless of the rights owner or paying a premium, at least the rights are very important for integrity protection. For the security of the DRM scheme, the secure management of the rights objects and, where applicable, the cryptographic keys necessary for accessing the content keys, verifying the integrity of the rights, etc. is of utmost importance, but this is not discussed further herein.

Referring to fig. 2-4, an example of content download and the manner in which DRM operates is described in connection with a user who purchases the right to use certain digital content. This example also demonstrates how the DRM mechanism works to force the rights to be preserved to ensure that the content is not used by others or by other devices than the device licensed in the rights object. Examples are also given where two or more users share a media experience together.

In the example shown in fig. 2, the system for DRM of downloadable contents includes a distribution server 9, a rights server 10, a client 11 and a DRM broker (broker) 12. The distribution server stores and forwards the content object and the rights object. The rights object is purchased by the user and forwarded to the client. The rights server holds rights objects corresponding to the content object for use in purchasing rights relating to the previously acquired content object. The client is a device that reproduces the content. There is also a DRM agent 13 in the client that enforces the usage rules. The DRM broker is a network entity that interconnects different rights servers that may be in different networks (not shown) and provides a single point of contact for the client.

Referring to fig. 3, a user operating a client machine requests content that can be downloaded to the client machine by browsing web pages on a distribution server. The user decides on a certain content with certain associated rights and provides the information needed for payment. The user then sends a request 14 for the desired content to the distribution server. The content object and the rights object, which are protected by a suitable password corresponding to this particular client and/or user, are delivered to the client as indicated by arrows 15 and 16, wherein the delivery is preferably made using a reliable transport mechanism. The necessary cryptographic information is collected inside the DRM agent in the client in order to use the content in the content object in accordance with the usage rights in the rights object. In a practical implementation, the trusted application is necessary for secure rendering of the content. The DRM agent parses the rights in the rights object, decrypts the content (or requests decryption of the content from another trusted part, such as a local cryptographic module in the client) and forwards it to the appropriate trusted application for rendering or using the content according to the specified rights. The application depends on the type of content, for example, music or video rendering is forwarded to a media player application, image display is forwarded to a picture viewer application, and so on.

An alternative procedure is contemplated which allows a user to download content objects without or with special rights objects to a client, by means of which the user can use a limited version of the complete content. This version may be a small portion of multimedia content such as a 10 second audio clip excerpt of a piece of music, a low resolution version of an image, etc. The concept of limited use that allows free or reduced cost is known as "preview", but it has nothing to do with viewing or displaying the content. By means of this mechanism, for example, the full rights relating to the content are not revealed, since the content in the content object is cryptographically protected and the content key needed to use the full content is in the (normal price) rights object. After previewing, the user may decide whether he wishes to purchase the content shown, then contact the rights server, whose URL can be obtained from the content object or via the DRM broker, and then purchase and download the rights object needed in the DRM agent to be able to use the whole content.

Separating the content used in the preview from the usage rights, this operation is equally applicable to another ideal content distribution example outlined below: and (4) super distribution. Referring to fig. 4, a situation is envisaged where one user wishes to share a usage experience with another user. There is no security risk in sending the content object directly between the two clients via a local connection such as bluetooth, infrared, cable, or other network, since the content object itself is protected and no special security measures need to be performed in the transmission.

User B experiences an interesting content and forwards the content object to client a, which forwarding is indicated by arrow 17. The received content object may contain a preview to make it easy for the receiving user to determine whether the content is interesting. The content object contains a reference to the associated rights server or DRM broker which directs the user to the correct rights server. Client a connects to the rights server, negotiates rights and accepts payment, and requests a rights object as indicated by arrow 18. The requested rights object will be downloaded to client a and the previously obtained content object can now be used on client a, as indicated by arrow 19. This concept of end-to-end content distribution is referred to as "superdistribution," which is considered a very important mechanism for business-based content. Desirable and priced content is likely to expand rapidly among the user population and provide significant revenue to content providers/distributors.

Described next are delivery mechanisms for downloading and streaming. These mechanisms are very important for understanding the content in view of the complex factors arising from the process of managing rights to media delivered using the respective mechanisms.

For download-type DRM in IP networks, both content objects and rights objects are delivered to the client using a reliable transfer protocol such as hypertext transfer protocol (HTTP) or File Transfer Protocol (FTP). These protocols are standard web protocols used by most web servers and web browsers. HTTP and FTP operate on top of the Transmission Control Protocol (TCP), which handles all data transfers. To optimize non-real-time applications such as file transfers, telnet, etc., TCP aims to maximize the data transfer rate while ensuring overall stability and high throughput of the entire network. For this purpose an algorithm called slow start is used, where TCP first sends data at a low data rate and then gradually increases the rate until the destination reports a packet loss. TCP then assumes that it has reached the bandwidth limit or that network congestion has occurred and returns to sending data at a low data rate, then gradually increases the rate, thereby repeating this process. TCP achieves reliable data transmission by retransmitting lost packets. However, it cannot be guaranteed that all retransmitted packets arrive at the client within a certain time, for example, and can be played in one media stream.

Turning now to streaming technology. HTTP and FTP (or other protocols based on TCP) are suitable for reliable data transfer, but do not perform well for streaming media, mainly because TCP implements reliable transfer without regard to timing requirements, and TCP changes the data transfer rate of the client-server connection according to bandwidth availability rather than media needs. The most common example of a standard for real-time data transmission is the real-time transport protocol RTP, which is a packet format for multimedia data streams in IP networks. Most proprietary protocols for transmitting real-time data are similar to RTP. In particular, RTP is a protocol framework that accommodates additional functionality. Additional information such as payload format (e.g. media coding) is needed to fully specify the protocol. This information constitutes a so-called "profile" for RTP. In streaming applications, RTP preferably runs on top of the User Datagram Protocol (UDP), which improves the streaming experience compared to TCP. Unlike TCP, UDP is a fast and compact protocol that does not have any retransmission or data rate management functions, making it suitable for transmitting real-time audio and video data, such as those that can tolerate packet loss. Because the above-mentioned slow-start mechanism is implicit in the TCP protocol, UDP traffic will get a more efficient bandwidth sharing than TCP traffic in a network.

For completeness, the concept of "progressive download" should be discussed herein. Progressive downloading means reliable downloading of media, where TCP is typically used, and rendering is started before the end of the download. Since TCP is used as well in this case, the same restrictions apply to real-time media streaming as discussed above for downloading.

For controlling the presentation of the transmitted multimedia stream, a control protocol such as the real time streaming protocol RTSP is used. RTSP can be used to establish a media streaming session and can also be used to start, pause, terminate and move ("fast forward" and "rewind") in the media stream. The protocol can thus be seen as a remote control between the client and the server streaming the multimedia.

In order to synchronize the streaming server with the client, the media client (which is a software part of the client) needs to have startup parameters in order to correctly interpret the RTP data. These initiation parameters may be described by the Session Description Protocol (SDP), which is a description protocol for multimedia sessions, which includes, among others: session name, session active time, media comprising the session, information (address, port, format, etc.) on which these media are received, bandwidth used, media type, codec (algorithms for compression and decompression), media key, and additional attributes relating to the specific media in the multimedia stream or the entire session.

The following is an example of an SDP description.

v＝0

o＝mobilemusic 288973739593 2887475859 IN IP4126.16.64.4

s＝Thesong

e＝mobilemusic@themusiccompany.com

m＝audio 0 RTP/AVP 0

a＝control:rtsp://224.2.17.12/media/thesong.amr

These parameters have the following meanings:

'v' -protocol version

'o' -owner/creator and an identifier

's' -session name

'e' -email address

The'm-field is used to enumerate the streams and contains information about the payload type, RTP protocol subset, and proposed ports. RTP/AVP indicates that the payload is RTP over UDP. The 'a-control' field indicates an attribute, and the 'a-control' indicates a URL pointing to a multimedia stream, which in this example is an audio stream. Based on the information in the SDP description, the media client sends an RTSP SETUP command to determine the transport settings (IP address, port number and other parameters), and after confirmation, the streaming server sends an RTSP PLAY command to initiate the media streaming. More details about this can be found in [ RTSP ] and [ SDP ].

A special case of the above example is the use of RTSP link URLs:

rtsp://224.2.17.12/media/thehit.amr

in order to initiate media streaming.

This URL uniquely defines a streaming media and by using this data in the RSTPDESCRIBE message a streaming session is initiated which results in the same stream as in the previous example. However, before the rtsp setup and PLAY commands are issued by the client, transport and protocol information must be negotiated between the server and the client. Thus, an additional round trip of messages is made between the client and the server before the rendering (DESCRIBE message and reply) begins. As a result, if only RTSP URLs are used to initiate a streaming session, an additional delay is incurred, and thus this example is not as efficient as the first case.

Another alternative to describing streaming sessions is to use Synchronized Multimedia Integration Language (SMIL), which is a media description language that describes multimedia sessions. The SMDL can be viewed as a hypertext markup language (HTML) that specifies web content and its geometry, but adds it to a time-based structure for multimedia presentation, thereby enabling different streams to be specified and different times to be used to create different streams (or render other media objects). Using SMIL also requires additional message round trips and is therefore also very inefficient. However, SMIL is capable of rendering other types of multimedia sessions than described by a single SDP description, such as image-like time discrete objects.

Turning now to protection of streaming media, data encryption is often necessary to maintain confidentiality of data over a network. In principle, encrypted data can be transmitted using any protocol, but when the protocol is unreliable, packet loss can result in an inability to decrypt the data or a significant quality degradation, which can be much greater than the corresponding unencrypted data packet loss. With the encryption algorithm, a lost packet may generate an error in the decryption process; this error may propagate to other received packets and thus be unable to decrypt them. This is in contrast to encrypted data transfer when reliable laundry is used, where all data is guaranteed to be transferred. A specific streaming encryption protocol is thus designed for wireless networks, one example of which is the secure real-time transport protocol SRTP, which is a protocol subset of RTP. SRTP provides confidentiality, message authentication, and playback protection for RTP/RTCP traffic. It is designed to eliminate error propagation caused by errors in the encrypted data, to be tolerant of RTP packet loss or reordering, and to allow fast forward and back-off operations in the encrypted stream. Hence, SRTP transmitted over UDP is a secure but unreliable protocol.

An example of an SDP description is a streaming audio/video session encrypted by SRTP:

i＝The lord of the rings behind the scene

e＝mobile_films@themusiccomany.com

a＝recvonly

m＝audio 0 RTP/SAVP 0

a＝control:rtsp://224.2.17.12/media/lothringen.amr

k＝base64:i064Ygf+IJtfF|8wSGbDaR＝＝

m＝video 0 RTP/SAVP 0

a＝control:rtsp://224.2.17.12/media/lothringen.rtp

k＝base64:Ah2pBY/HoqS+OglbdG6TMg＝＝

the main difference from the previous example is the SRTP protocol subset, which is represented by RTP/SAVP in the "m ═ field. Likewise, separate encryption keys for the audio and video streams are included in the base64 encoding of the "k ═ field.

Problem(s)

The download techniques described above cannot be used directly in conjunction with streaming techniques. For streaming, content is separated from the ticket.

The problem to be solved is therefore how to modify the downloading technique and its secure rights management in order to take into account (a) the transmission of streaming multimedia and (b) the secure rights management of the transmitted multimedia, thereby taking into account the following practical facts:

streaming is a process that means rendering the media is carried out as it is received, streaming does not allow storing the received media after it has been rendered at download.

Existing network components and mechanisms for downloading should be reused for streaming as much as possible, thereby allowing them to be used for both downloading and streaming.

Streaming media uses unreliable transport protocols such as the User Datagram Protocol (UDP). A small number of bit errors or lost packets can be handled without significantly affecting the quality of the media, and if this can be controlled or verified, such bit errors or lost packets are acceptable, so that the user does not have to pay for the media that is too disturbing.

However, as previously mentioned, in DRM systems some data cannot be delivered in an unreliable way, e.g. using rules and encrypted media keys, for which any changes are unacceptable, since this would violate the specified rules or render it impossible to decrypt the content.

To cryptographically protect streaming media, a cryptographic key must be agreed upon between the streaming server and the client in a secure manner.

If a secure streaming protocol is being used, the cryptographic key must be validated before streaming starts, but the download-type DRM protocol typically does not know the order of arrival of the rights object and the content object.

It is desirable to be able to "rewind" and "fast forward" the streaming media.

In some applications, such as real-time applications, it is not possible to access all content simultaneously (e.g., web-play). This does not affect the processing performed for the media.

There is no solution in prior art DRM systems that is common to both DRM for downloading media and DRM for streaming data. In fact, cryptographic protection of streaming media transmitted over an interfered channel is very difficult even without managing rights (one exception is [ SRTP ]). In particular, an existing system providing DRM for content download is assumed, however, no solution is currently available to transparently introduce DRM for streaming into this system. There are other important constraints that should work transparently for downloading and streaming, including mechanisms for superdistribution, content preview and rights purchase.

The present invention provides a solution to the above-mentioned problems.

Disclosure of Invention

It is an object of the present invention to provide a solution for handling DRM with streaming media.

It is another object of the present invention to provide a process for DRM with streaming media by using existing protocols and protection mechanisms for media download type DRM.

It is another object of the present invention to provide a process for DRM with streaming media, wherein super distribution of streaming media is taken into account.

It is another object of the present invention to provide an apparatus and method for managing rights related to streaming media.

It is another object of the present invention to provide a system and method for delivering and managing entitlements related to streaming media.

These and other objects are achieved in connection with the invention as defined in the claims.

A distinguishing feature of the present invention is the use of DRM mechanisms that include a content object and an associated rights object, where the content object contains not content but a start-up description of an upcoming streaming session in which digital media is streamed to a client. This feature allows for preview and superdistribution. Optionally, the session initiation description includes an encryption key for protecting the streaming media from unauthorized use.

In the following, the expression "content" sometimes denotes any data at the location of the content in the content object in the prior art download-type DRM solutions.

The present invention is described below. For ease of understanding, an existing specific rights management system for downloading is assumed herein, in which content objects and rights objects described in the state of the art DRM solution are used for downloading. Rights relating to streaming media are managed by means of the following scheme:

the actual digital content is not placed in the object content, but a start-up description of the streaming media is placed in the same location in the recording. For example, the start-up description may contain an SDP description, in particular an RTSP URL to a particular streaming media, SMIL file, etc.

Optionally, the start-up description may contain cryptographic information that protects the streaming media from unauthorized use.

In addition to this, the DRM solution for downloading is reused without changes. Thus, for example, the rights object contains usage rules and a cryptographic key that encrypts "content". As in the download paradigm, the DRM agent parses the usage rules, decrypts the "content" and passes the plaintext "content" to the appropriate trusted application, which renders the content. For streaming media, the "content" is a streaming media start-up description.

By virtue of the trust model between participants in a particular content distribution scheme, the need is met by protecting the download-type DRM system-enabled streaming initiation description, and the actual streaming media is not protected here. Examples of certain conditions are given below, wherein if one or all of these conditions are observed, these conditions may be considered sufficient enough so that protection of the actual streaming media may be ignored.

Whether the streaming start-up description is not leaked to an unauthorized party, so that streaming is allowed only for an authorized party.

If it is difficult to eavesdrop on the streaming media, thereby preventing or limiting unauthorized use.

If it is difficult to preserve the streaming media, unauthorized use is prevented or limited.

However, in general, protection of only the streaming start-up description is not sufficient, especially if only some or none of the above conditions are observed, and additional protection of the streaming is necessary. Cryptographic protection of streaming media can be applied at any layer of the Open Systems Interconnection (OSI) model. An example of this will be described below, where protection is applied at the transport layer.

A clear improvement to the security of streaming media is to cryptographically protect the media during the transmission between the streaming server managed by the content provider/distributor and the trusted streaming application in the client. As previously described, this may be accomplished by using a secure and robust streaming protocol, such as SRTP, especially for wireless networks. In this case, it is of course important that the cryptographic key or keys used to protect the streaming media between the streaming server and the client are kept secret together with the trusted party. This key may be cryptographic information contained in (or managed by) a streaming media start-up description, which may be an SDP description with optional attributes specifying the media key, as described in the previous example, and optionally specified by the present invention. In particular, such a start-up description only contains one or several RTSP URLs and one or more encryption key attributes containing one or more encryption keys. Alternatively, in the streaming media start-up description, the cryptographic key may be delivered together with any start-up description of the plaintext streaming session, e.g. an SDP description without key attributes bound to the cryptographic key, in particular one or several RTSP URLs and one or more separate encryption keys. An alternative embodiment of the streaming media initiation description is an SMS file bound to one or more cryptographic keys.

Additional security mechanisms may also be considered to protect the streaming media startup description or the streaming media itself.

Incorporating the advantages achieved by the invention

In general, the present invention is applicable to rights management (DRM) of streaming media. The present invention provides a universal solution for DRM for media download and DRM for streaming media. With the present invention, a compatible system that handles streaming media can be enabled with only a small amount of changes to the existing DRM for the download system. Because of this and these changes seamlessly conform to the concept of DRM for downloading, all features of the DRM download system can be extended to streaming media, including rights management, superdistribution, previewing, rights object purchases involving specific content, and the like. For example, superdistribution typically operates by forwarding content objects end-to-end. The receiving end may then initiate his/her own streaming session in conjunction with the purchased rights object.

It is necessary here to give descriptive text relating to the concept of streaming previews. Such previewing may be implemented in several ways. One of the methods is to actually provide a content object with a limited multimedia sample of the complete or related content actually downloaded to the user. Another approach is to provide a key that the client can use to create a temporary or otherwise restricted/constrained stream that is, alternatively, of lower resolution/quality than the full version.

The present invention also provides an option to enable cryptographic protection of media streams and solves the key management problem of how to establish a public key on the streaming server and the streaming client. Since the scheme is compatible with the use of secure and robust streaming protocols like SRTP, the invention is well suited for managing rights in wired and wireless networks with interference causing transmission errors.

As previously mentioned, there are many differences between streaming and downloading of media content. However, the user experience of the same media rendered by either method need not have significant differences, say videos of concerts: the concert downloaded to the client has the advantage that it does not show any indication of occasional variation, whereas the video streamed to the client may be live and direct broadcast concerts.

According to the present invention, the same rights management scheme can be used for downloading and streaming media independent of media transfer. This rights management scheme will work for superdistribution, rights purchasing, which are considered important business conditions. If superdistribution works only for downloading, the introduction of streaming services will likely result in an inability to determine the ability to distribute/purchase content, which would compromise the traffic conditions for superdistribution of downloaded content.

Since the same rights management scheme is used for downloading and streaming the media, there is no need to perform a parallel solution for downloading and streaming. This may also ensure a uniform user experience.

Brief Description of Drawings

The invention, together with further objects and advantages thereof, may best be understood by reference to the following description taken in conjunction with the accompanying drawings in which:

figure 1 illustrates a data structure of a rights management (DRM) system using a downloading method in the related art,

figure 2 illustrates a node included in a DRM of the prior art,

figure 3 is a diagram illustrating the steps of a prior art method for accessing content from a content distributor in a DRM system using download technology,

figure 4 is a diagram illustrating the steps of a prior art method (superdistribution) for accessing content from another client in a DRM system using download technology,

figure 5 schematically depicts the underlying DRM mechanism for streaming media according to the present invention,

figure 6 is a diagram illustrating the method steps for the transmission of streaming media and DRM according to the present invention,

figure 7 is a schematic block diagram illustrating a node and a device for providing DRM of streaming media according to the present invention,

FIGS. 8A-D illustrate various methods of including an activation description in a content object, in accordance with the present invention, and

fig. 9A-F illustrate various ways of including a start-up description with a cryptographic media key in a content object in accordance with the present invention.

Description of the preferred embodiments

Fig. 5 illustrates a data structure and a client view of an example of DRM used for streaming media in accordance with the present invention. Now it is assumed that the client receives a content object 20 and a rights object 2, wherein said object relates to a certain digital multimedia content transmitted from the streaming server to the client in the form of data packets 22 during a streaming session. How this occurs will be described further below.

The content object contains metadata and an activation description 23 in the form of an SDP description of the type described above containing a media key 24. The boot description is protected in the form of a key, as indicated by the bold rectangle 25.

As in the case of download-type DRM, the rights object associated with the content object contains metadata, usage rights, and a content key.

The client uses the content key provided in the rights object to decrypt the protected start-up description, which contains the media key provided in the content object. And the client uses the clear media key to decrypt the protected multimedia stream 22. The decrypted media stream is accessed by an application and rendered to a media player that is not shown.

A streaming media session must be established before the multimedia stream is delivered to the client. For this purpose, a connection is established between the client and the streaming server. Before starting the media stream, a variety of multimedia-related information, such as its name, type, location, encoding, etc., is exchanged between the streaming server and the client over this connection. And the start-up description is also used for these purposes.

Fig. 6 illustrates the method steps for providing DRM for streaming data in accordance with the present invention. The client sends a request for multimedia to the distribution server, as indicated by arrow 26. The expiry of the rights relating to the requested multimedia is then negotiated and determined. The next step is that the distribution server sends the content object with the protected start-up description to the client, as indicated by arrow 27. The rights object containing the usage rights and the content key is then sent to the client as indicated by arrow 28. By using the content key, the client decrypts the session initiation description and, in addition, starts establishing a streaming session with the streaming server by using the information given therein. This operation is indicated by double-headed arrow 29. Other parameters used in the streaming session are also exchanged over this connection. In a final step the streaming session starts and streaming of a stream of protected multimedia packets to the client is started as indicated by arrow 30.

The packets are transmitted over the streaming protocol indicated in the start-up description, in this case the SRTP protocol. A reliable protocol such as HTTP or WAP may be used to transfer the rights object and the content object. Furthermore, the reliable protocol may also be used for RTSP control signaling.

The client can verify the receipt of the packet by sending an acknowledgement or authentication to the streaming server. This mechanism is part of the SRTP/SRTCP protocol [ SRTP ].

Fig. 7 is a block diagram illustrating a node and an apparatus for providing DRM of streaming media according to the present invention. Among them is a content server 31 containing multimedia, a streaming server 32 providing multimedia streams, an encryption key generator 33 providing content keys and media keys, a media key database 34 storing media keys, a content object generator 35, a rights object generator 36, a distribution server 37, and a rights server 38.

The content object generator extracts the above-mentioned start-up parameters for use in the start-up description of the streaming session starting from the content server, as indicated by arrow 39. The media key 24 is retrieved from the key generator. The boot description is cryptographically protected by using a content key generated by a key generator. This content key may also be used for a rights object generator, see below. Metadata is also extracted and included in the content object. The generated content object is then stored on the distribution server and a copy thereof is passed to the client according to arrow 28 of fig. 6.

The rights object generator generates a rights object associated with the content object and contains therein the same content key as the key used to protect the content object. And the rights object containing an identity is stored in the distribution server and the rights server. A copy of which is passed to the client according to arrow 28 of fig. 6.

Double-headed arrow 40 depicts the passing of media and content keys to the content object generator and rights object generator.

In addition, the media key inserted into the content object is stored in a media key database along with the rights object identity associated with the generated content object. This is depicted by arrow 41 in fig. 7.

The situation up to now is as follows: the client receives the content object and the rights object as described earlier (arrows 27 and 28 of fig. 6). The media key 24 and the associated rights object identity are stored in a media key database.

Next, at arrow 29 in fig. 7 (corresponding to arrow 29 in fig. 6), the streaming server receives a session setup message from the client. This message contains the information described earlier and subsequent signaling between the client and the server reveals the identity of the rights object associated with the content object. The streaming server sends a media key request to the media key database as indicated by arrow 42 and provides the rights object identity received at arrow 29. In response to this request the media key database is searched for the indicated rights object identity and the corresponding media key is returned to the streaming server, as indicated by arrow 43. The streaming server now uses this media key to cryptographically protect the media stream that was initially delivered to the client, as indicated by arrow 30 (corresponding to arrow 30 in fig. 6). Both the streaming server and the client now use the same media key for encryption and decryption, respectively.

Many modifications of the above examples are possible. Instead of using the same media key for encryption on the streaming server and decryption on the client, the streaming server may use a public media key while delivering a private media key to the client in the content object.

Another modification is to cryptographically protect the media key in the content object, rather than providing the key in clear as described.

The media stream and/or the content object may also be protected by encryption and/or integrity protection, and the rights object and/or the content object may also be delivered to unprotected clients.

The order in which the content and the rights object are delivered to the client may be reversed, that is, step 28 may precede step 27 in fig. 6. They may also be delivered to the client via a separate communication channel, for example in the form of SMS messages and using the WAP protocol, respectively, in a mobile communication network.

The start-up description may be provided by the content server instead of the content object generator.

In fig. 8, different embodiments of content objects are shown at 8A-8D. One common feature for all of the embodiments of fig. 8 is that no cryptographic information is included in the boot description. In fig. 8A basic version is shown, containing the usual metadata and start-up description files, this time without the media key. In fig. 8B, the startup description is implemented as an SDP description without key attribute settings. In fig. 8C, the start-up description is implemented as an SMIL file without a key. Fig. 8D is a specific example of fig. 8B, where the SDP description is an RTSP URL addressed to the streaming media.

In fig. 9, 9A to 9F show other different embodiments of the content object. One of the common features for all embodiments is that cryptographic information is included in the boot description. In fig. 9A basic version is shown, which contains the usual metadata and a start-up description file containing the media key. In fig. 9B, the start-up description is implemented as an SDP description containing the set key attributes. In fig. 9C, the startup description is implemented as an SDP description without key attribute settings; while the media key is contained separately in the start-up description. In fig. 9D, the start-up description is described as an SMIL file and a media key. Fig. 9E is a specific example of fig. 9B, where the SDP description is an RTSP URL addressed to the streaming media with media key attribute settings. Similarly, fig. 9F is a specific example of fig. 9C, where the SDP description is an RTSP URL addressed to the streaming media. The media key is provided independently of the RTSP URL in the start-up description.

It should be understood that the media key shown in fig. 9 may include several other keys, such as other media keys and/or other keys for providing other types of security. One reason for using several media keys is to associate each key with a portion of the complete media stream, thereby enhancing security. The idea behind this reason is that an eavesdropper should not be able to decrypt the entire media stream using a single key.

The above embodiments are given by way of example only and it should be understood that the invention is not limited thereto. Further modifications, variations and improvements which maintain the basic principles disclosed and claimed herein are within the spirit and scope of the invention.

Reference to the literature

[ HAC ] A.J.Menezes, P.C.van Oorschot and S.C.Vanstone, "Handbook of Applied Cryptography", CRC Press.

Jacobson, s.l.casser, r.frederick and h.schulzone, "RTP: a Transport Protocol for Real-time application ohs ", RFC 1889, IETF, November 2001.

[RTSP]H.Schulzrinne、A.Rao、R.Lanphier，“Real TimeStreaming Protocol(RTSP)”，RFC 2326，IETF，April 1998。

[SDP]M.Handley、V.Jacobsson，，“SDP：SessionDescription Protocol”，RFC 2327，IEFT，April 1998。

[ SRTP ] M.Baugher, R.Blom, E.Carrara, D.McGrew, M.Naslund, K.Norrman and D.Oran, "The Secure Real Time transport protocol", draft-IETF-avt-SRTP-05.txt, IETF, June 2002.

Claims (28)

1. A client device (11) for rendering digital content, the digital content being processed in accordance with a digital rights management, DRM, technique for downloading, the client device (11) comprising:

-means for downloading a content object (20) of a first type, the content object (20) of the first type comprising downloaded content as content;

-means for downloading a rights object (2) comprising usage rules (6) defining rights to use the associated content object (20); and

-means for rendering the content in the content object (20) of the first type according to usage rules of the associated received rights object (2);

it is characterized in that

The means for downloading content objects are further arranged to download content objects of a second class comprising session initiation descriptions (23) for streaming sessions as content, and wherein

The means for rendering content are further adapted to establish a streaming session during which the streaming media is streamed according to the information in the session initiation description (23) received in the content object (20) of the second class and according to the usage rules (6) of the associated received rights object (2).

2. A client device according to claim 1, characterized in that said session initiation description (23) comprises a session description protocol, SDP, description, a uniform resource locator, URL, pointing to said streaming media, or a synchronized multimedia integration language, SMIL, file.

3. A client device according to claim 1 or 2, characterized in that the rights object (2) contains first cryptographic data (7) relating to cryptographic protection of the session initiation description included in the content object (20) of the second type.

4. A client device according to claim 3, characterized in that the session initiation description (23) in the content object (20) of the second type comprises second cryptographic data (24) for cryptographically protecting said streaming media (22).

5. A client device according to claim 4, characterized in that the second cryptographic data comprises at least one cryptographic key (24).

6. A client device according to claim 4, characterized in that said second cryptographic data comprises a number of cryptographic keys (24) for protecting the streaming media.

7. A client device according to claim 1, characterized in that said means for downloading the content object (20) of the first or second type and the rights object (2) are adapted to use the hypertext transfer protocol HTTP and/or the wireless application protocol WAP and/or the short message service SMS.

8. A method for rendering digital content, the digital content being processed in accordance with DRM techniques for downloaded digital rights management, the method comprising the steps of:

downloading a content object (20) comprising content;

downloading a rights object (2) comprising usage rules (6) defining rights to use the content object (20); and

presenting the downloaded content according to the usage rules (6);

the method is further characterized in that

The content objects (20) are of a first type or of a second type, wherein the content of the content objects of the first type is download content and the content of the content objects of the second type is a session initiation description for a streaming session and

the step of presenting the downloaded content comprises establishing a streaming session, during which the streaming media is streamed according to the information in the session initiation description and according to the usage rules (6) associated with the received rights object (2), if the downloaded content object is of the second type.

9. A method according to claim 8, characterized in that said session initiation description (23) comprises a session description protocol, SDP, description, a uniform resource locator, URL, pointing to said streaming media, or a synchronized multimedia integration language, SMIL, file.

10. A method according to claim 8 or 9, characterized in that the rights object (2) contains first cryptographic data (7) relating to cryptographic protection of the session start description included in the content object (20) of the second type.

11. A method according to claim 10, characterized in that the first cryptographic data is cryptographically secured.

12. A method according to claim 10, characterized in that the streaming media (22) is cryptographically protected with second cryptographic data (24) in the session start description (23) in the content object of the second type.

13. A method according to claim 12, characterized in that a security protocol is used to protect said streaming media.

14. A method according to claim 13, characterized in that a secure real-time transport protocol SRTP is used as the security protocol.

15. A method according to claim 8, characterized in that part of the streaming media is provided to a content object of the second type, and that the content object of the second type is transmitted in order to prepare for a user who has no rights or limited rights to the streaming media.

16. Method according to claim 8, characterized in that the content object (20) and/or the rights object (2) of the first or second class are protected by encryption and/or integrity protection.

17. A method according to claim 11, wherein the client device, upon receiving the rights object and the content object of the second type, enforces rights to the content object and the streaming media based on information included in the rights object, characterized by:

the client device accesses the session initiation description (23) comprised in the content object of the second type by using the first cryptographic data (7) and initiates the transfer of the streaming media by establishing (29) a connection between the client device and the streaming server (32).

18. A method according to claim 13, wherein the streaming server cryptographically protects the streaming media (22) with second cryptographic data (24), characterized in that said step of presenting comprises the client device:

accessing second cryptographic data (24) comprised in the content object of the second class,

accessing the streaming medium (22) using the accessed second cryptographic data (24), and

the accessed streaming media is presented according to the usage rules.

19. A method according to claim 12, characterized in that said session initiation description is in the form of a session description protocol, SDP, description and that the second cryptographic data (24) is included in the session description protocol, SDP, description.

20. A method according to claim 12, characterized in that said session initiation description is in the form of a session description protocol, SDP, description and the second cryptographic data (24) is provided separately from the session description protocol, SDP, description.

21. A method according to claim 12, characterized in that said session initiation description is in the form of a synchronized multimedia integration language, SMIL, file and that the second cryptographic data (24) is included in the synchronized multimedia integration language, SMIL, file.

22. A method according to claim 12, characterized in that said session initiation description is in the form of a synchronized multimedia integration language, SMIL, file and that the second cryptographic data (24) is provided separately from the synchronized multimedia integration language, SMIL, file.

23. A method according to claim 12, characterized in that the streaming media is protected by a number of second cryptographic data items (24).

24. A method according to claim 12, characterized by including in the session start-up description (23) information about the management of the second cryptographic data (24), said information allowing to cryptographically protect the streaming media and/or to verify the data integrity of the streaming media (22) with a new cryptographic key derived from said first-mentioned second cryptographic data (24).

25. A method according to claim 9, characterized in that the uniform resource locator URL of the distribution server (9) is included in the metadata part (8) of the content object.

26. A method according to claim 12, characterized in that the cryptographic information is obtained using the second cryptographic data (24) for integrity protection and/or for verification of the reception of the streaming media.

27. A method according to claim 8, characterized in that the content object (20) and the rights object (2) are transferred to the client device (11) using the hypertext transfer protocol HTTP and/or the wireless application protocol WAP and/or the short message service SMS.

28. A method according to claim 8, characterized in that the rights object (2) and/or the content object (20) are downloaded to an unprotected client device.