Extensible media rights

Abstract

A DRM System. A DRM system comprising a service provider, a CE device coupled to the service provider, and an XMR license disposed upon the CE device.

Description

DESCRIPTION OF THE DRAWINGS

The present description will be better understood from the following detailed description read in light of the accompanying drawings, wherein:

FIG. 1 is a block diagram of a typical digital rights management system utilizing an XMR DRM license.

FIG. 2 is a diagram showing an XMR DRM licenses.

FIG. 3 is a diagram showing a conventional ASF file.

FIG. 4 shows an XMR structure having a header object and an outer container object.

FIG. 5 shows the details of an XMR header object.

FIG. 6 shows the details of an XMR container object.

FIG. 7 is a block diagram showing an exemplary XMR DRM license.

FIG. 8 is a block diagram showing a computer processor capable of processing an XMR structure.

Like reference numerals are used to designate like parts in the accompanying drawings.

DETAILED DESCRIPTION

The detailed description provided below of extensible media rights in connection with the appended drawings is intended as a description of the present examples and is not intended to represent the only forms in which the present example may be constructed or utilized. The description sets forth the functions of the example and the sequence of steps for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.

Extensible media rights may include a way of constructing a license that is used to govern the use of digital media. Although the present examples of extensible media rights (“XMR”) are described and illustrated herein as being implemented in a license of a digital rights management (“DRM”) system, the DRM system described is provided as an example and not a limitation. As those skilled in the art will appreciate, the present examples are suitable for application in a variety of different types of data exchange systems such as clients and servers.

Conventional binary systems that may be used for representing digital rights tend to have limitations. CCI systems utilize two bits and are typically capable of only conveying four states.

Extensible Media Rights (“XMR”) typically provide a binary system that may be used to convey media usage rights and restrictions, such as in a license that may be found in a digital rights management (“DRM”) system. The framework established by XMR typically allows extensions to be introduced in a backwards-compatible fashion. XMR typically uses an object framework, nesting structure, and binary representation to convey media usage rights in the form of a license. The format of an XMR license may include some aspects of RIFF and ASF files, both of which may use nested objects or structures that may have systems for providing different types or lengths.

FIG. 1 is a block diagram of a typical digital rights management system utilizing an XMR DRM license. Although the present examples are described and illustrated as being implemented in a consumer electronics (“CE”) device system, the system described is provided as an example and not a limitation. CE devices may include pocket PCs, set top boxes, portable media centers, cell phones, music players, PCs, software constructed media players, high fidelity components, and the like. In fact PCs are a common device that may be provided with DRM enabling software to function as a CE device. PCs may be used as docking stations for a user to store content on, and then download some or all of it to another CE device, such as an MP3 player. These CE devices are typically configured to operate in a system that includes the internet, PCs and the like to facilitate license and media content transfer.

DRM system 100 typically provides a collection of processes for the secure distribution of multimedia content 110 from a service provider 107 coupled 106 to an insecure channel, such as the Internet 105. Digital media content for viewing or playback would typically include music files, picture files, video files, documents, and other protected content, in short anything that a service provider wishes to transmit securely over an unsecured channel.

In particular content may be anything that a provider desires to protect such as music, video, multimedia, pictures and the like. Content is typically regulated to prevent its unauthorized use by providing licenses. Content may be audio, video, textual, encrypted, unencrypted, compressed, uncompressed or otherwise manipulated. In a DRM system the content, (or equivalently media, media files, files, or the like) to be played, can typically be freely transferred. Transfer of encrypted content is typically over unsecured channels such as the internet. In a DRM system the playback of the content is controlled, or allowed, by a license that may be typically stored on a specific CE device. Those skilled in the art will realize that the term “play” as used herein may also be construed to mean consumed, or other equivalent terms that indicate that there are limits placed upon accessing the media file governed by the license. Digital media file 110 is typically encrypted by service provider 107 prior to transmission, and is typically decrypted into an unencrypted media file 109 at the CE device 101 or 103

A personal computer 103 may be used to couple 104 to the internet 105 as a CE device. The computer may also be used to transfer content and licenses from the service provider 107 to another more portable consumer electronics device 101 via the path 102 shown. The personal computer and the CE devices may operate utilizing any number of suitable operating systems known to those skilled in the art to implement the desired DRM processes being activated. The instructions for implementing the functions described in this application may exist as software, hardware (for example instructions burned into an ASIC), or a combination of both.

The PC may act as a main storage location and have a large number of licenses and media files stored on it. Protocols for transferring information to the PC 103, and to the CE device 101 over paths 102 and 104 may be achieved by conventional connections such as Ethernet, USB, infrared, Bluetooth, MTP and the like. These pathways may be useful for transmitting licenses and content.

A CE device 101 may be as previously noted a variety of devices equipped with a processor. As shown here 101 the CE device may be a portable personal electronics device such as a digital juke box, MP3 player, or the like.

In alternative embodiments a consumer electronics device 101 may be coupled 104 to a service provider 107 without using the personal computer 103 as an intermediary. In this example the CE device 101 operates to download media and licenses directly from the internet.

A DRM capable device, such as a CE device 101, or a PC 103, typically includes a number of DRM components 114 utilized by a DRM system. The components 114 are typical, but not limiting, of DRM components. A similar set of components may be associated with the PC 103, but are omitted to simplify the figure. Typical DRM components may include one or more licenses 102. Also shown as part of a typical DRM system is a device certificate 111 that may uniquely identify the CE device 101 to the DRM system 100. Device certificates may provide cryptographical hand shake information that may facilitate the transfer of information, such as a master clock signal 110 from a trusted time authority 116.

In a typical application, DRM system 100 protects contents 110 by providing encrypted data files 109. Since files 109 are encrypted, the data itself is protected. Thus, the files 109 may be moved, archived, copied, or distributed without restriction. There is no need to hide files or make them inaccessible, or to put special protection in place when files are transmitted from system to system. However, copying a file and giving it to a friend will not enable that friend to use the file. In order to be able to use an encrypted file, users must obtain an XMR license 108. This license 108, that typically includes a grace period 115, is a way of exercising control over the encrypted file 110 and the unencrypted version 109 of the file. An XMR license 108 is typically granted to a single machine 101, and even if copied, it will not tend to function on other machines.

An example of a Digital Rights Management system that may be capable of utilizing Grace Periods is described in U.S. patent application Ser. No. 09/290,363, filed Apr. 12, 1999, U.S. patent application Ser. Nos. 10/185,527, 10/185,278, and 10/185,511, each filed on Jun. 28, 2002 which are hereby incorporated by reference in its entirety.

A typical licensing system is a digital rights management (“DRM”) system. As those skilled in the art will appreciate, the present example is suitable for application in a variety of different types of systems that operate under a license.

FIG. 2 is a diagram showing a plurality of typical XMR DRM licenses 202. XMR Licenses are typically exchanged as in a typical client server exchange. First a client initiates contact with a server and presents a certificate having a public key to the server. The server then sends an XMR license to the client. In this example the XMR license sent is an exemplary XMR license. In alternative embodiments any suitable method issuing a license may be utilized to cause an XMR license to be transmitted.

An XMR license typically accompanies a media file (not shown) that has been downloaded to the CE device 101, or to a PC 103. In the past licenses have been typically downloaded with the content, and not separately, although they may be downloaded together. The number of XMR licenses on the CE device 101 can be extremely large, such that a user typically can not keep track of the individual conditions applied to each media file by its associated license. A PC will typically contain even more XMR licenses. Occasionally, more than one XMR license will be associated with a media file.

XMR licenses typically regulate the use of content. Most current DRM solutions rely on unique identification of user devices, such as CE devices. In such systems each XMR license is typically bound to a unique consumer electronics device (or playback device), so the XMR license stored in one CE device typically can not be transferred or used by another device. The XMR licenses are typically stored separately from the content, typically in a dedicated storage area such as a secure store.

FIG. 3 Illustrates a conventional Advanced Streaming Format (“ASF”) data file structure and its use. A conventional ASF media file 300 may be stored on a computer 301, and may be played 305 by, a conventional media player application 303 or the like. Current ASF media files 300 typically are not used to provide licenses in DRM systems. Typically the ASF file is loaded by an application 303, and subsequently processed (or played) by the application 303, to produce an output such as the video output 309 and, sound output 307 shown here. ASF files 300 have been used convey a variety of information such as music, video and the like. Media players may include audio players, video players, editing programs, digital photo albums, and the like. The possible outputs 307, may include audio video and the like.

A typical ASF file may include a header object 302, a data object 304, and one or more index objects 308 310. In the ASF file structure space is provided for other top level objects 306. An ASF header object 302 typically includes a set of tables that may include information on the entire file, including the size of the file, if the file is packetized, how large the packets are, if there is audio stream, the number of streams present in the file, and the like. An ASF data object 104 may include the data or media content.

The ASF data object 304 that contains the digital media typically varies in length. The following paragraphs describe licenses that may incorporate the variable length structure of ASF files.

FIG. 4 shows an XMR structure having a header object 402 and an outer container object 412. Many different license features may be described in an XMR structure by coupling various base XMR objects together under a header 402. (One XMR base object is shown for simplicity.) The XMR objects may be assembled or coupled under a header in a variety of ways that may include nested structures inside the outer container structure. However, the XMR objects assembled under a header typically include a common structure like that of the XMR container object or template. For example, a number of license features may each be represented by XMR objects, by assembling them under a header to form an XMR license. In this arrangement each XMR object may have the structure of the XMR base object 401, and may be nested within the XMR container object.

The first two bytes of the XMR base object may be used for flags 404, the next two bytes may describe the object type 406, and the next four bytes may represent the object length “I” 408 of the information that makes up the object data 410. An object data of length “I” 410 typically follows the bytes that describe the object length. In addition the object 410 may contain numerous sub objects, where the length of each sub object may be provided in its own header.

XMR objects may be stored in network byte order (big-endian) and 1-byte alignment may be assumed (in other words, no alignment), so alignment-related padding bytes need not be inserted. Storage of these binary objects is typically provided by one or more memory registers, or data buffers.

FIG. 5 shows the details of an XMR header object 500. In order to perform an efficient check that a particular data buffer contains a valid and complete XMR representation, it is typically required that every XMR representation begin with the header structure shown. The header 500 may include the header constant 502, the XMR version 504, and the rights ID 506. An XMR license typically contains a header structure followed by a “container” object that may contain nested XMR “data” objects within it. Such a container object may be called an XMR outer container object. In alternate examples the length of the accompanying data object may be included in the header object.

FIG. 6 shows the details of a base XMR container object 600. Details of the flags 602, object type 604, object length 608, and object data 610 are shown in the figure. The remainder of the XMR binary representation may be composed of logically nested “objects”, which may be self-descriptive tag/length/value tuples. XMR representations will typically contain multiple derived objects with certain portions of the logical ordering and nesting structure being structured as indicated in the example described below.

A flag may be used to distinguish between “data objects” that contain additional fields in a structure derived from a base XMR object representation (such as an XMR outer container object) and “container” objects that have only nested XMR objects as their contents and are otherwise identical in structure to the base XMR object. Flags may simplify parsing, validating, extending, and diagnosing XMR data dumps.

The flags are typically used for a must understand object that indicates that at least the present field must be understood in order to process or enforce the license. In order to simplify parsing, validating, extending, and diagnosing of XMR data dumps, XMR objects typically begin with a field for flags. The current extension provided in this example defines flags that may distinguish between container or leaf objects and between mandatory and optional objects.

The must understand flag (0x0001) is used as a signal to compliant XMR parsers that if they don't recognize this object's object type value, they should return an error code to the calling application, rather than silently ignoring the object. The XMR parser should also understand all of the values of the object. For instance, an XMR object might define a DWORD which has newly introduced values for subsequent releases. Such values should be understood, or an error should be returned to the application. In general, the must understand flag will not be set on objects that represent rights and will be set on objects that represent restrictions.

If a container object is marked that it need not be understood, then an XMR parser should not check contained objects for the must understand flag unless the parser understands the container. For instance, the copy policy container does not have the must understand flag set. If an XMR parser does not understand the concept of copying, it need not understand any contained restrictions on the copy.

The container object flag (0x0002) is used when the XMR object contains data consisting of zero or more “nested” XMR objects. This construct is used for logical grouping and scoping reasons, and is distinguished in order to support general purpose tools as well as to simplify the logical rights usage design.

Each XMR object of the plurality of objects may be assigned a unique object type 604, as indicated by the type field. The length field 608 typically specifies the length of the object and it's plurality of nested children. The object type values may be centrally managed by a service provider, and may be allocated out of a single 16-bit space. Object type values should be given as part of each XMR object description.

The object data 610 is of variable length. The object length 608 may be the length in bytes of the entire object including the header structure. For container objects, this length includes the size of all the enveloped child objects. The child objects may refer to data objects that may be nested in an enveloping container object.

A use for XMR is to represent DRM licenses. The binary rendition of the XMR license puts the license in a form that typically needs little processing, or translation to be used. Some conventional licenses have typically been represented using a script based description, such as a proprietary XML schema. A conventional license, having a script based description, is typically not a binary representation, has a relatively large size, and a high processing time. This may limit the performance of DRM systems, especially as the size of the license store grows larger. XMR typically provides a very compact binary representation of a license which may help provide a minimal processing time. A binary format also tends to eliminate the need for parsers or interpreters typically utilized in script based licenses.

FIG. 7 is a block diagram showing an exemplary XMR DRM license 700. In the example provided mandatory and optional objects may be provided for the present example. In alternative embodiments the importance of the objects may change depending upon the purpose of the embodiment. In particular the example illustrates an application of the previously described XMR license structure.

The XMR header 702 is followed by a single outermost XMR container object 704 which typically has a plurality of nested objects 706, 708, 710, 712, 714 within it. The outer container object 704 is typically used to supply a total length value for the remainder of the XMR license. Extensions to the base XMR framework provided by the outer XMR container 704 may be logically nested within this outermost XMR container. The outer XMR container object typically includes flags, object type, and object length information. The last object within the outer XMR container will typically be the signature object 716 which ensures the integrity of the represented license. The outer XMR container object may include a number of containers 706, 708, 710, 712, 714 nested within it. It is possible to extend this license configuration by adding additional objects. Such an extensible structure may add other objects that may include one or more additional licensing constraints such as: a grace period, a source ID, an explicit uncompressed digital output protection list, a revocation container, a license granter key, a user ID and the like. The extensible structure may be used to change or extend the capabilities of current licenses, or may be used supply new licenses that specify digital rights beyond those previously downloaded.

A global policy container 706 is the first container nested in the outer XMR container 703. This object typically contains any data objects 707, 718 related to global policy, that is, policy not specific to playback or any other media usage scenario. This object may also include fields for flags, object types, and object lengths.

A minimum environment restriction object 707 may specify restrictions that may indicate several minimum requirements for security, and for the age of a revocation list (through versioning). In this example the minimum environment restriction object 707 can only be a child of a “Global Policy Container” XMR object. XMR encoding of this minimum environment restriction object 707 may include fields for flags, object type, object length, minimum security level, minimum app revocation list version, and minimum device revocation list version. The minimum security level typically specifies the lowest security level that the device must adhere to before it can access the content. The value from the license is compared with the security level from the device certificate. The value from the device certificate should be greater than or equal to the value from the license or the license must not be used to access the content.

In addition to the minimum environment restriction object 707 the global policy container 706 may include one or more additional child objects 718. In particular the child objects 718 of the global policy container 706 may include one or more of the following objects: minimum environment restriction, serial number restriction (Optional), rights settings (Optional), priority object (Optional), expiration restriction (Optional), issue date (Optional), expiration after first use restriction (Optional), expiration after first store restriction (Optional), and metering restriction (Optional).

The serial number restriction (Optional) restricts the content usage to one specific digital media receiver (“DMR”). This restriction is typically made only when multiple devices share the same device certificate. This restriction can typically only be a child of a “Global Policy Container” XMR object. This restriction may include fields for flags (set to must understand), object types, object length, and serial number. Serial number is a byte array containing the serial number of the DMR.

The rights settings (Optional), defines various rights settings that are global to the license. Various Boolean rights may be represented by this single object. This object can typically only be a child of a “Global Policy Container” XMR object. Object may contain fields for flags, object type, object length, and rights. Rights may have various states including: cannot persist, allow backup and restore collaborative play, and base license. The cannot persist bit indicates the license and content cannot be persisted; they should be used then discarded. The allow backup and restore bit indicates that a license may be backed up or restored to the same, or another device using a DRM backup and restore feature. The collaborative play right enables the single scenario that allows sharing of WMDRM protected content. The base license field may be used to derive keys for accessing other licenses.

The priority object (Optional), assigns the license a priority. This object need only be specified if there are two or more licenses issued for the same Key ID. This object can typically only be a child of a “global policy container” object. The XMR encoding of this object may include fields for flags, object type, object length, and priority. The priority field assigns a priority to the License. For licenses with the same key ID (“KID”), the license with the higher priority takes precedence.

The expiration restriction (Optional), describes any time limitations of the license. Fields may include flags, object type, object length, begin date and end date. The begin date typically controls the beginning of the validity period for the license. In this example the special value 0 indicates that the license may be valid from the beginning of time. The end date typically controls the end of validity period for the license. In the present example the special value 0xFFFFFFFF may indicate that the license is valid until the end of time, or its equivalent.

The issue date (Optional), object indicates when the license was issued. This object can typically only be a child of a “Global Policy Container” object. Object fields may include flags, object type, object length, and issue date.

The expiration after first use restriction (Optional), specifies the number of seconds the content may be played after first playback. The value of this restriction is that it allows the end user to choose when to begin playback, after which point they will have a specific number of seconds in which to play back the content. An alternative example replaces the first use restriction field with, an absolute expiration end date. This restriction can typically only be a child of a “Global Policy Container” object. Fields for this object may include flags, object type, object length, and expire after first use.

The expiration after first store restriction (Optional), This restriction specifies the time the content may be played after the license is first stored. This restriction allows a content provider to allow content to be used for a relative period of time regardless of the current time or time zone. The existence of this restriction in a license defines the license to be stateful. If a license containing this restriction is copied to another device or backed up, the state associated with this restriction is not copied. Instead, the copied license is assigned an absolute expiration end date. Fields for this object may include flags, object type, object length, and expire after first store. This restriction can typically only be a child of a “Global Policy Container” object.

The metering restriction (Optional) defines the information clients may be required to collect and where to remit that information to. This field may include flags, object type, object length, and metering ID. The metering ID may be the GUID of the metering requirements. This restriction can typically only be a child of a “Global Policy Container” object. Additional objects as described below may also be added, in addition to those shown above.

The Key material container object is used to contain any data objects related to key material and content encryption. This object can only be a child of an “Outer Container” XMR object. Typical fields include Flags, object type, and object length.

The RSA device key object defines the RSA public key of the device the license is bound to. This object can hold an RSA key. Emerald devices should have a 1024-bit or 2048-bit RSA key with an exponent of 65537. This object can typically only be a child of a “Key Material Container” XMR object. Fields for this object may include flags, object type, object Length, exponent, modulus Length, and modulus. Exponent specifies the exponent of the RSA key modulus length Specifies the length of the RSA key in bytes. For 2048-bit RSA, this value should be 256. Modulus is the modulus of the RSA key in network byte (big-endian) order.

Grace period (optional) indicates the number of seconds during which protected content can be played on a device after its clock becomes unset. The default value is zero seconds. This object can typically only be a child of a “Global Policy Container” object. Fields for this object may include flags, object type, object length and grace period.

Source ID (optional) identifies the source of the content. It could be used to make policy decisions based on the source. This object can typically only be a child of a “Global Policy Container” object. Fields for this object may include flags, object type, object length, and source ID. The source ID is typically an Identifier for the source of the content.

Explicit uncompressed digital audio output protection list (optional) is typically a container for Uncompressed Digital Audio Output Configuration objects. This container has a list of explicitly included Uncompressed Digital Audio output protection technologies that may be enumerated separately due to licensing restrictions. The application must employ all of the listed technologies that apply to the referenced output when outputting content to analog outputs. This is in addition to any other restrictions that may be on the output. Each listed output protection technology represents an addition requirement beyond the Uncompressed Digital Audio Output Protection level. The listed technologies only apply to digital outputs. Content sent to analog outputs is not affected by the list. This container can typically only be a child of a “Playback Right Container” XMR object. Fields typically include flags, object type, and object length.

Uncompressed Digital Audio Output Configuration Restriction (optional) typically requires the use of a certain uncompressed audio output protection scheme and provides relevant configuration data to be used by the scheme. This object typically can only be a child of an “Explicit Uncompressed Digital Audio Output Protection Container” XMR object. Fields typically include flags, object type, object length, audio output protection ID, and binary configuration data. The object length field typically Includes the 8-byte header, the 16-byte GUID, and the variable-length binary configuration data. The binary configuration data may include the configuration data for this output configuration. The size of the variable-length array is implied by the object length field of the object. The Binary Configuration Data is a variable length binary data field whose type is dependent on the value of the Audio Output Protection ID field. For the currently defined Audio Output Protection IDs, the Binary Configuration Data consists of a variable length unsigned integer in network byte order. The integer may be from 0 to 4 bytes long depending on the magnitude of the integer. The value and interpretation of the integer is defined below for each of the Audio Protection IDs. For the Downsample Required ID, the uncompressed digital audio must be downsample to a maximum value specified by the Binary Configuration Data. The Binary Configuration Data is a single integer containing an ordinal defining the downsample requirements. Currently, the only value 1 is defined. A value of 1 requires 48 KHz max sample rate, 16 bit max sample size. This Downsample Required ID applies to uncompressed digital audio outputs.

The revocation container object (optional) typically contains any data objects related to revoking or deleting XMR licenses. This object can typically only be a child of an “outer container” XMR object. Fields for this object may include flags, object type and object length.

The license granter key object typically specifies RSA public key of the entity that issued the license. When this license is revoked or deleted, the caller must prove possession of the corresponding RSA private key. This object can typically hold an RSA key. This object can typically only be a child of a “Revocation” XMR object. Fields for this object may include flags, object type, object length, exponent, modulus length, and modulus. Exponent typically specifies the exponent of the RSA key. Modulus length typically specifies the length of the RSA key in bytes. For 1024-bit RSA, this value should be 128. The modulus field is typically the modulus of the RSA key in network byte (big-endian) order.

The user ID object (optional) typically specifies a User ID to be associated with the license. The user ID is defined by the entity that issues the license. When this license is revoked or deleted, the caller may specify that only licenses with a particular User ID are to be deleted. The User ID is considered to be a binary blob. As such, if the User ID is a text string, any comparison with the blob is case sensitive. This object can only be a child of a “Revocation” XMR object. Fields for this object may include flags, object types, object length, and user ID.

The outer XMR container object 704 may also include on or more additional containers 708, 710, 712, 714 that may each include one or more additional child objects 720, 722, 724, 726, 728, 730, 732, 734. It is also specifically contemplated that additional child objects not listed here may be added, due to the extensible characteristics of this structure.

The second additional container 708 may be a playback right container. The playback right grants the ability to play the content. This object also contains any data objects related to media playback policy. This object typically includes fields for flags, object type and object length. This container can typically only be a child of an “outer container” XMR object.

The plurality of one through n child objects 720, 722 of the second additional container 708 may include any or all of the following: play count restriction (optional), output protection level restriction, explicit analog video output protection container object (optional), analog video output configuration restriction object (optional).

The play count restriction (optional), restriction specifies the number of times the content can be played. Play is defined as the first packet being decrypted. The existence of this restriction in a license defines the license to be stateful. If a license containing this restriction is copied to another device, the state associated with this restriction is usually not copied. Instead, another play count number of plays are allowed by the license copy.

If a license containing this restriction is backed up, the play count restriction in the backed up license is set to the net number of plays left instead of the original play count. This algorithm attempts to protect the content provider by accounting for the plays already consumed. However, it is impossible to account for any copies made between the time when the license was backed up and when the license was restored. Objects may include fields for flags, object type, object length and play count. This restriction can typically only be a child of a “Playback Right Container” object.

The output protection level restriction, restriction indicates several minimum requirements for content output protection, based on the type of content being output and the format of that content.

Output protection levels are specified by a number defining a minimum level of content protection required for a particular type and format of content. Larger numbers may imply that stronger content protection is required. Specific values may be defined for each type and format of content. Licenses should be issued with those specific defined values. Fields that may be included in this object include flags, object type, object length, digital compressed video output protection level, digital uncompressed video output protection level, analog video output protection level, digital compressed audio output protection level, and digital uncompressed audio output protection level.

The values defined for each type and format are mapped by this document to particular output technologies. That list of technologies may be expanded from time to time without notice. An application may map any technologies it supports to the levels defined by this document.

Licenses should be interpreted to allow for values that are not yet defined. For instance, if an output protection level defines a value of 200 for XXX content protection and 400 for ZZZ content protection, then an application that implements both XXX and ZZZ should interpret licenses at levels 201 through 400 inclusive as requiring ZZZ content protection. If a subsequent WMDRM specification defines level 300 for YYY content protection, a license issued for level 300 will be properly interpreted by the application.

Output protection levels may be defined for a type of output regardless of the original input format. For instance, if an application has an input of digital compressed video and doesn't support the required content protection for the digital compressed video, the application may uncompress the digital video and output that content based on the digital uncompressed video output protection level. This object can typically only be a child of a “playback right container” XMR object. The concept of output protection levels are further described in U.S. patent Ser. No. ______ (Attorney docket number 308256.01) ______ filed Apr. 14, 2005, the contents of which are hereby incorporated by reference.

The explicit analog video output protection container object (optional), is a container for analog video output configuration objects. This container typically has a list of explicitly included analog video output protection technologies that have to be enumerated separately due to licensing restrictions.

The application program must typically employ one of the listed technologies when outputting content to analog outputs. This is in addition to any other restrictions on the output. Each listed output protection technology represents an addition requirement beyond the analog video output protection level. The listed technologies only apply to analog outputs. Content sent to digital outputs is not affected by the list. Fields for this object may include flags, object type, and object length. This container can typically only be a child of a “Playback Right Container” XMR object

The analog video output configuration restriction object (optional) explicitly requires the use of a certain analog video output protection scheme and provides relevant configuration data to be used by the scheme. This object can typically only be a child of an “Explicit Audio Video Output Protection Container” XMR object

A third additional container 710 may be the optional copy right container. Copy right grants the ability to make a copy of this license on another CE device. This object is also a container that may contain any data objects related to media copy policy. Fields may include flags, object type and object length. This container can typically only be a child of an “outer container” XMR object. Child objects 1−n 724, 724 of the copy right container 710 may include any or all of the following: copy count restriction (optional), and copy protection level restriction (Optional).

The copy count restriction (optional), restriction allows an absolute number of copies to be made of the digital media. When a copy of this license is made to another device, state is maintained about the number of copies made. If the copy count restriction is not specified in a license, the license may be copied freely. The existence of this object in a license defines the license to be stateful. If a license containing this restriction is copied to another device, the state associated with this restriction is not copied. Instead, the copied license should have the copy policy container and all the child objects stripped from the license. The copied license can only be used to play the content. If a license containing this restriction is backed up, the copy count restriction in the backed up license is set to the net number of copies left instead of the original copy count. This process attempts to protect the content provider by accounting for the copies already made. However, it is impossible to account for any copies made between the time when the license was backed up and when the license was restored. Fields for this object may include flags, object type, object length and copy count. Copy count specifies the typically absolute number of copies that can be made. This restriction can typically only be a child of a “Copy Right Container” XMR object.

The copy protection level restriction (optional), defines the minimum level of protection for a destination copy. If a content protection system that meets the minimum level is not available then the copy isn't allowed. Fields for this object may include flags, object type, object length, and a minimum copy protection level. The minimum copy protection may start out with a suitable default value. This object can only be a child of a “Copy Right Container” XMR object.

A fourth additional container 712 may be the optional allow playlist burn right container. The allow playlist burn right grants the right to burn the content to a CD as part of a playlist. This object is also used to contain any data objects related to playlist burn policy. CD burning is typically not considered to be a copy. If no restrictions are set, an unlimited number of playlist burns are permitted. This object may include fields for flags, object type, and object length. This object can typically only be a child of an “outer container” XMR object. Child objects of the allow playlist burn right container 712 may include the playlist burn restriction as a child object 728.

The playlist burn restriction (optional) specifies limits on the right to burn playlists. The maxplaylistburncount field specifies the number of times that content can be copied to a CD as part of a particular playlist. The playlistburntrackcount field specifies the number of times that content can be copied to a CD as part of any playlist. The existence of this restriction in a license defines the license to be stateful. If a license containing this restriction is copied to another device, the state associated with this restriction is not copied. Instead, the entire CD burn policy container is not copied to the destination device. As such, the destination device may not burn CDs. If a license containing this restriction is backed up, the maxPlaylistburncount restriction is backed up intact. That is, a restored copy of the license is allowed to create copies of any particular play list. Due to the nature of this restriction, any other design would have to backup all of the play lists this license was used in. If a license containing this restriction is backed up, the playlistburntrackcount restriction in the backed up license is set to the net number of burns left instead of the original burn count. This process attempts to protect the content provider by accounting for the burns already consumed. However, it is impossible to account for any burns made between the time when the license was backed up and when the license was restored. Fields for this object may include flags, object type, object length, maxplaylistburncount, and playlistburntrackcount. Playlistburntrackcount right specifies the number of times the consumer is allowed to copy this particular media file within any playlist to a CD This object can only be a child of an “Allow Playlist Burn Right container” XMR object.

A fifth additional container may be the key material container object 714. The previously presented CD burn right grants the right to burn the content to a CD. This object 714 is also used to contain any data objects related to media CD burn policy. CD burning is not considered to be a copy. This right may be superseded by the allow playlist burn right, which should be used by content providers. Fields for this object may include flags, object type, and object length. Provision for this right is an example of backwards compatibility. This object can typically only be a child of an “outer container” XMR object. Child objects 1−n 732-734 may include: the content key object (optional), the RSA device key object (optional), and the uplink KID object (optional).

The content key object (optional) is used to contain any data objects related to key material and content encryption. Fields for the object may include flags, object type and object length. This object can typically only be a child of an “Outer Container” XMR object. This object is described further below.

The RSA device key object (optional), described more fully below, holds an encrypted version of the content key, and information about the crypto ciphers necessary to decrypt the key and then the content itself. DRM protected content typically contains a key ID identifying the key used to encrypt the content. That key ID is matched with the key ID in the Content key object to identify the license or licenses that contain the content key for the content. Fields for this object may include flags, object type, object length, key ID, symmetric cipher type, key encryption cipher type, encrypted key length, and encrypted key data. Key ID identifies the content key. Encrypted key length specifies the size of the encrypted key data. The encrypted key data buffers (the key data) encrypted using the specified Key Encryption Cipher type. The Symmetric Cipher Type defines how to interpret the decrypted buffer. This object can typically only be a child of a “Key Material Container” XMR object. In this application the key data is actually a combination of the content key and the integrity key typically used to sign the license. This combination of keys ties the signature to the creator of the license. This combination of keys also tends to eliminate any need for a PK based signature that might be present.

The uplink KID object (optional) specifies the key ID of the uplink license in chain of chained licenses. The uplink license contains the key used to encrypt the encrypted key in the content key object, and a chained checksum. The uplink KID object is present when this license is chained to another license instead of being granted to a device. The content key object indicates that the license is chained to another license by specifying a key encryption cipher type of “chained license”. In that case, the uplink KID object points to an uplink license. Fields may include flags, object type, object length, and uplink KID object including a chained checksum. Uplink KID specifies the Key ID of the license containing the content key used to encrypt the encrypted key. The chained checksum is typically a hash of the key from the uplink license That uplink license itself contains a content key.

As may be seen above extensibility may be provided in the XMR DRM license. XMR typically allows extensions to be introduced by defining new objects. Older XMR parsers typically ignore any objects that they do not know how to parse (unless the object is marked with a must understand flag), and may continue to parse any data following the unknown object. New objects may be introduced by nesting.

The outer XMR container 704 constructed in accordance with the base XMR object which includes the remainder of the XMR binary representation following the header which may be composed of logically nested “objects” 706, 708,710, 712, 714 which are simply self-descriptive tag/length/value tuples. All XMR representations may contain multiple derived objects with certain portions of the logical ordering and nesting structure being mandatory in this example. The designations of mandatory and optional used in this particular example are not intended to imply that other alternative examples must be limited by the same optional and mandatory designations.

FIG. 8 is a block diagram showing a computer processor capable of processing an XMR license structure. Exemplary computing environment 800 is only one example of a computing system and is not intended to limit the examples described in this application to this particular computing environment.

The computing environment 800 can be implemented with numerous other general purpose or special purpose computing system configurations. Examples of well known computing systems, may include, but are not limited to, personal computers, hand-held or laptop devices, microprocessor-based systems, multiprocessor systems, set top boxes, programmable consumer electronics, gaming consoles, consumer electronics, cellular telephones, PDAs, and the like.

The computer 800 includes a general-purpose computing system in the form of a computing device 801. The components of computing device 801 can include one or more processors (including CPUs, GPUs, microprocessors and the like) 807, a system memory 809, and a system bus 808 that couples the various system components. Processor 807 processes various computer executable instructions to control the operation of computing device 801 and to communicate with other electronic and computing devices (not shown). The system bus 808 represents any number of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures.

The system memory 809 includes computer-readable media in the form of volatile memory, such as random access memory (RAM), and/or non-volatile memory, such as read only memory (ROM). A basic input/output system (BIOS) is stored in ROM. RAM typically contains data and/or program modules that are immediately accessible to and/or presently operated on by one or more of the processors 807.

Mass storage devices 804 may be coupled to the computing device 801 or incorporated into the computing device by coupling to the buss. Such mass storage devices 804 may include a magnetic disk drive which reads from and writes to a removable, non volatile magnetic disk (e.g., a “floppy disk”) 805, or an optical disk drive that reads from and/or writes to a removable, non-volatile optical disk such as a CD ROM or the like 806. Computer readable media 805, 806 typically embody computer readable instructions, data structures, program modules and the like supplied on floppy disks, CDs, portable memory sticks and the like.

Any number of program modules can be stored on the hard disk 810. For example a number of XMR licenses 700. Mass storage device 804, ROM and/or RAM 809, including by way of example, an operating system, one or more application programs, other program modules, and program data. Each of such operating system, application programs, other program modules and program data (or some combination thereof) may include an embodiment of the systems and methods described herein.

A display device 802 can be connected to the system bus 808 via an interface, such as a video adapter 811. A user can interface with computing device 802 via any number of different input devices 803 such as a keyboard, pointing device, joystick, game pad, serial port, and/or the like. These and other input devices are connected to the processors 807 via input/output interfaces 812 that are coupled to the system bus 808, but may be connected by other interface and bus structures, such as a parallel port, game port, and/or a universal serial bus (USB).

Computing device 800 can operate in a networked environment using connections to one or more remote computers through one or more local area networks (LANs), wide area networks (WANs) and the like. The computing device 801 is connected to a network 814 via a network adapter 813 or alternatively by a modem, DSL, ISDN interface or the like.

Those skilled in the art will realize that storage devices utilized to store program instructions can be distributed across a network. For example a remote computer may store an example of the process described as software. A local or terminal computer may access the remote computer and download a part or all of the software to run the program. Alternatively the local computer may download pieces of the software as needed, or distributively process by executing some software instructions at the local terminal and some at the remote computer (or computer network). Those skilled in the art will also realize that by utilizing conventional techniques known to those skilled in the art that all, or a portion of the software instructions may be carried out by a dedicated circuit, such as a DSP, programmable logic array, or the like.

Claims

1. A DRM system comprising:

a service provider;

a CE device coupled to the service provider; and

an XMR license disposed upon the CE device.

2. The DRM system of claim 1, in which the XMR license is sent from a service provider to the DRM device via an internet connection.

3. The DRM system of claim 1, in which the XMR license is binary.

4. The DRM system of claim 1, in which the XMR license is extensible.

5. The DRM system of claim 1, in which the XMR license includes a must understand field.

6. The DRM system of claim 5, in which the XMR license includes a plurality of objects with each object of the plurality of objects includes the must understand field.

7. The DRM system of claim 6, in which the must understand field present in each object of the plurality of objects is configured to cause an XMR parser to ignore an object of the plurality of objects that the XMR parser does not understand.

8. The DRM system of claim 1, in which the XMR license includes a content key object formed by combining a content key and an integrity key.

9. An XMR license comprising:

an XMR header object; and

an XMR container object.

10. The XMR license of claim 9, in which the XMR container object comprises a plurality of child objects each having a header including a must understand field.

11. The XMR license of claim 9, in which the XMR container object is extensible to allow the addition of additional objects to the XMR license.

12. The XMR license of claim 9, in which the XMR container object includes a nested structure for the addition of additional objects.

13. An XMR license comprising:

an XMR header object; and

an XMR container object including a global policy container and a plurality of additional container objects.

14. The XMR license of claim 13, additionally comprising an XMR signature object.

15. The XMR license of claim 13 in which the XMR key material container object includes a content key object.

16. The XMR license of claim 13 in which one of the plurality of container objects comprises a plurality of child objects.

17. The XMR license of claim 13 in which the XMR container object provides extensibility.

18. The XMR license of claim 13 in which the XMR license is binary.

19. The XMR license of claim 13 in which one of the plurality of container objects comprises a must understand field.

20. The XMR license of claim 13 in which the global policy container includes a minimum environment restriction object.