Source: https://patents.google.com/patent/US8904191B2/en
Timestamp: 2020-02-28 19:32:58
Document Index: 271903632

Matched Legal Cases: ['Application No. 61', 'Application No. 200980155365', 'Application No. 200980155365', 'Application No. 200980155365', 'Application No. 200980155365', 'Application No. 200980155365', 'Application No. 200980155365', 'Application No. 200980155365', 'Application No. 2009339304', 'Application No. 2011', 'Application No. 200980155365', 'Application No. 200980155365', 'Application No. 200980155365']

US8904191B2 - Multiple content protection systems in a file - Google Patents
Multiple content protection systems in a file Download PDF
US8904191B2
US8904191B2 US12/485,949 US48594909A US8904191B2 US 8904191 B2 US8904191 B2 US 8904191B2 US 48594909 A US48594909 A US 48594909A US 8904191 B2 US8904191 B2 US 8904191B2
US12/485,949
US20100185854A1 (en
Quintin Swayne Burns
Robert Kilroy Hughes, JR.
John Carl Simmons
2009-01-21 Priority to US14609909P priority Critical
2009-06-17 Priority to US12/485,949 priority patent/US8904191B2/en
2009-07-23 Assigned to MICROSOFT CORPORATION reassignment MICROSOFT CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: HUGHES, ROBERT KILROY, JR., BURNS, QUINTIN SWAYNE, SIMMONS, JOHN CARL
2010-07-22 Publication of US20100185854A1 publication Critical patent/US20100185854A1/en
2012-08-01 Assigned to MICROSOFT CORPORATION reassignment MICROSOFT CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: FIERSTEIN, SCOTT J.
2014-12-02 Publication of US8904191B2 publication Critical patent/US8904191B2/en
230000004224 protection Effects 0 abstract claims description title 154
This application claims the benefit of U.S. Provisional Application No. 61/146,099, filed Jan. 21, 2009, the entirety of which is hereby incorporated by reference herein.
Existing digital rights management (DRM) systems protect media content and other files from unauthorized use. To protect the content, metadata specific to one of the DRM systems is stored in the file with the media content. Devices render the content by interpreting the metadata and decrypting the content for presentation to a user. However, content encrypted according to a first DRM system cannot be decrypted by a device supporting only a second DRM system. To enable decryption of the encrypted content by such a device, existing systems create multiple versions of the content each encrypted according to a different DRM system. Alternatively, the content may be decrypted by a device supporting the first DRM system and then re-encrypted by a device supporting the second DRM system. Still other existing systems include a service that provides a rights mapping between the first and second DRM systems.
Embodiments of the invention support multiple protection systems applied to a single container file. The file containing the content and one or more encryption expressions is received. The content is encrypted by the encryption expressions. A plurality of protection systems are applied to the content using the encryption expressions from the received file. Each of the protection systems protects the content using the same encryption expressions. The file with the content and the applied plurality of protection systems are transmitted to one or more computing devices for decryption. Each of the computing devices decrypts the content using at least one of the applied plurality of protection systems.
FIG. 1 is an exemplary block diagram illustrating a first computing device providing content to a second computing device over a network.
FIG. 2 is an exemplary block diagram illustrating the flow of content from a content provider through an encoding provider and a service provider to a consumer.
FIG. 3 is an exemplary flow chart illustrating the application of protection systems to content.
FIG. 4 is an exemplary flow chart illustrating the decoding of content for presentation on a computing device.
FIG. 5 is an exemplary block diagram illustrating an exemplary structure representing a fragmented file structure.
FIG. 6 is an exemplary block diagram illustrating an exemplary structure representing fragmented file organization.
FIG. 7 is an exemplary block diagram illustrating an exemplary structure for storing a track box.
FIG. 8 is an exemplary block diagram illustrating an exemplary structure for storing for storing a media information box.
FIG. 9 is an exemplary block diagram illustrating an exemplary structure for storing a protected sample entry box.
Referring to the figures, embodiments of the disclosure support, at least, multiple protection systems such as digital rights management (DRM) systems in a file 111 storing media content for presentation to a user. The file 111 stores a single copy of the media content or other content protected by the multiple protection systems. In part to enable such interoperability among the protection systems, the protection systems use or share an encryption algorithm or other encryption method common to the protection systems. Additionally, encryption expressions such as key information used by the protection systems are shared across the protection systems.
Aspects of the disclosure extend the International Organization for Standardization (ISO) base media file format to support the multiple DRM systems in a single container file such as file 111. In some embodiments, the container file includes a sample encryption box 114 and a plurality of protection system header boxes 116, each particular to one or more of the protection systems. The sample encryption box 114 stores or identifies the encryption method common to the protection systems. The protection system header boxes 116 each store data objects used to decrypt the content with the corresponding protection systems. For example, in some embodiments, the data objects in the protection system header boxes 116 are used to acquire other data objects (e.g., from a license server) to decrypt the content. The data objects represent opaque metadata to support the multiple protection systems in the single file, simultaneously.
While aspects of the invention are described with reference to the computing device being the mobile computing device such as a mobile telephone or a netbook or ultraportable, embodiments of the invention are operable with any computing device. For example, aspects of the invention are operable with devices such as digital cameras, digital video cameras, laptop computers, set top boxes, gaming consoles (including handheld gaming consoles), portable music players, personal digital assistants, information appliances, and personal communicators.
Referring again to FIG. 1, an exemplary block diagram illustrates a first computing device 102 providing content to a second computing device 104 over a network 106. In some embodiments, the first computing device 102 is a server, the second computing device 104 is a client device, and the network 106 is the Internet. The first computing device 102 includes at least a first memory area 110 and a processor 108. The first memory area 110 stores the file 111 corresponding to, for example, media content or a media presentation. The media content includes commercial or non-commercial media data such as video, audio, images, text, and/or graphics, or sequences thereof. The first computing device 102 transmits the file 111 with the media content to the second computing device 104 over the network 106.
The exemplary block diagram in FIG. 1 describes content delivery scenarios supported by embodiments of the disclosure including, but not limited to, second session or digital delivery of standard definition or portable media content from an optical disc to a computing device (e.g., portable device or personal computer), progressive download of multimedia content, adaptive streaming over Internet Protocol (IP) networks, or side loading of multimedia content onto portable devices.
The first computing device 102, or other server, represents any known or later-developed sources of media content or information associated therewith including, but not limited to, data storage servers, DRM servers, media content servers (e.g., for music or video downloading, on-demand, broadcasting, or advertising), peer servers, and the like. The first computing device 102 may comprise one or more such devices.
The network 106 represents any digital data transmission infrastructure or technology configured to support known or future-developed media protocol. Exemplary networks include, but are not limited to, the Internet, cellular networks, satellite networks, BLUETOOTH brand wireless networks, and the like.
The second computing device 104 is any computing device, or element of such a computing device, configured to receive data from the first computing device 102. The second computing device 104 may be configured to store and/or present the received data, or alternatively pass the received data to another device for storage and/or presentation.
The first computing device 102 and the second computing device 104 may include components such as transceivers, multiplexers, demultiplexers, encoders, decoders, encrypters, decrypters, and the like.
In some embodiments, the file 111 represents a container file that stores the content in a format supports multiple protection systems. The protection systems correspond to, for example, the DRM systems. In such embodiments, the file 111 includes encrypted content 112, the sample encryption box 114, and the plurality of protection system header boxes 116 such as protection system header box #1 through protection system header box #N. The sample encryption box 114 and the protection system header boxes 116 represent object-oriented building blocks defined by a type identifier and length. A container box contains and groups related boxes. For example, a media data box is a container box holding media content for a presentation, while a movie box is a container box whose sub-boxes define metadata for a presentation. While the sample encryption box 114 and protection system header boxes 116 are shown to be included in a particular box or container box such as illustrated in the figures, the boxes sets forth information that can be conveyed via the box included therewith, or another box therein. Further, the boxes may be considered sub-boxes of other boxes in the file 111.
Each of the plurality of protection system header boxes 116 are associated with one or more of the protection systems. Any quantity of the protection system header boxes 116 may be contained within the file 111. The boxes and protection system are identified by a DRM identifier or other protection system identifier. The sample encryption box 114 identifies a key used to encrypt the encrypted content 112. In some embodiments, the sample encryption box 114 stores a key, key identifier, and/or key mapping information describing a common or standard encryption method across the protection systems. The key may be different for each sample encryption box 114. For example, the standard encryption method includes the Advanced Encryption Standard (AES) with 128-bit key size in counter (CTR) mode. The initialization vector for the AES algorithm is also common to the protection systems. The sample encryption box 114 is shared by the protection system header boxes 116. Each of the protection system header boxes 116 includes metadata for decoding the encrypted content 112, or otherwise granting access to the content, in accordance with one or more of the protection systems.
In an example in which the file 111 corresponds to the ISO base media file format, the protection system header boxes 116 are at nesting level 1 while the sample encryption box 114 is at nesting level 2, in some embodiments.
The second computing device 104 has access to a second memory area 118. The second memory area 118, or one or more computer-readable media, stores computer-executable components for decoding and presenting the media content to a user of the second computing device 104. Exemplary components include an interface component 120, a detection component 122, a parse component 124, and a transform component 126. These components represent exemplary structure for implementing functionality associated with the second computing device 104, although other structures are contemplated for implementing the functionality described herein. Operation of the exemplary components illustrated in FIG. 1 is described below with reference to FIG. 4.
In general, the first memory area 110 is associated with the first computing device 102. For example, in FIG. 1, the first memory area 110 is within the first computing device 102. However, the first memory area 110 or any of the data stored thereon may be associated with any server or other computer, local or remote from the first computing device 102 (e.g., accessible via a network). Similarly, the second memory area 118 is associated with the second computing device 104. For example, in FIG. 1, the second memory area 118 is within the second computing device 104. However, the second memory area 118 or any of the data stored thereon may be associated with any server or other computer, local or remote from the second computing device 104 (e.g., accessible via a network)
The processor 108 includes any quantity of processing units, and is programmed to execute computer-executable instructions for implementing aspects of the disclosure. The instructions may be performed by the processor 108 or by multiple processors executing within the first computing device 102, or performed by a processor external to the first computing device 102 (e.g., by a cloud service). In some embodiments, the processor 108 is programmed to execute instructions such as those illustrated in the figures (e.g., FIG. 3 and FIG. 4).
Referring again to FIG. 2, an exemplary block diagram illustrates the flow of content from a content provider 202 through an encoding provider 204 and a service provider 206 to a consumer. The diagram of FIG. 2 represents an example of the diagram shown in FIG. 1 in which the service provider 206 corresponds to the first computing device 102 and a consumer device 208 corresponds to the second computing device 104.
The content provider 202 generates a file containing media content. For example, the content provider 202 is a movie studio that produces a video file corresponding to a movie. The generated video file may be in the format known as a mezzanine format, which may be specific to each content provider 202. The content provider 202 transmits the video file to the encoding provider 204. The encoding provider 204 prepares the video file for distribution to one or more of the service providers 206. In this example, the encoding partner performs processing to prepare the mezzanine content for encoding, including encryption in some embodiments, and then performs the encoding and encryption. The encoding and encryption occurs using an encryption key provided by the content provider 202 or generated by the encoding provider 204. The encoded content is ready for distribution, but lacks a protection system (e.g., DRM). The encoded content is sent to the service provider 206.
The service provider 206 receives the encoded content and adds a header (e.g., one of the protection system header boxes 116) for DRM A to the video file. The video file with the applied protection system may be sent to the consumer device 208 or other devices where it is capable of being decrypted only by DRM A. Alternatively or in addition, the service provider 206 may also add another header (e.g., another one of the protection system header boxes 116) for DRM B to the video file. At this point, the video file is capable of being decoded using DRM A or DRM B. The video file is transmitted to the consumer, where the consumer device 208 may parse, decrypt, and decode the video file using DRM A or DRM B.
In an example, the content is a movie, and the user attempts to play the movie on Device One which support DRM A. Playback software on Device One determines that the movie is encrypted. The playback software finds the protection specific header box corresponding to DRM A. The playback software uses the information contained in the protection specific header box to contact a license server and retrieve a license for the movie. The retrieved license may be stored within the protection specific header box for DRM A (e.g., in extra space therein). The movie is then decrypted using DRM A and presented to the user.
In a further example, the user then copies the movie to Device Two which supports DRM B. The playback software on Device Two determines that the movie is encrypted. The playback software finds the protection specific header box corresponding to DRM B. The playback software uses the information contained in the protection specific header box to contact a license server and retrieve a license for the movie. The retrieved license may be stored within the protection specific header box for DRM B (e.g., in extra space therein). The movie is then decrypted using DRM B and presented to the user.
Referring next to FIG. 3, an exemplary flow chart illustrates the application of protection systems to content. A computing device, such as the service provider 206 in FIG. 2, determines at 302 if a file has been received. The file includes media content and one or more encryption expressions. The media content is encrypted according to the encryption expressions. In some embodiments, the encryption expressions include, or include metadata describing, one or more encryption keys, key identifiers, and key mapping information. In other embodiments, the encryption expressions include data objects for obtaining one or more of the encryption keys, key identifiers, and key mapping information from another location (e.g., a web service). The encryption expressions may be stored in, for example, one or more of the protection system header boxes 116 and/or the sample encryption box 114 illustrated in FIG. 1.
After the file with the media content is received at 302, a plurality of protection systems is selected at 304. For example, the protection systems may be selected based on the intended recipients of the file, or represent a default selection of protection systems commonly used by consumer devices 208. At 306, the selected protection systems are applied to the content in the file using one or more of the encryption expressions to create DRM-protected content. For example, applying the protection systems includes adding or embedding metadata for the protection systems to the file. The metadata describes the protection systems and enables decryption of the content. In some embodiments, the metadata includes a rights object or license information (or a reference to the license information) related to the protection systems, along with a decryption key associated with the protection system.
The protection systems are applied to the content without creating additional copies of the content. As a result, a single container file (e.g., file 111) comprises the content and the plurality of selected, applied protection systems.
The DRM-protected content is transmitted to one or more computing devices at 308. The computing devices decrypt the content using at least one of the applied protection systems supported by the computing devices. Alternatively or in addition, the DRM-protection content is stored in a memory area for access by the computing devices.
In the example of FIG. 1, applying the protection systems includes defining one of the protection system header boxes 116 for each of the selected protection systems. The defined protection system header boxes 116 are included in the file. In this example, the sample encryption box 114 includes key information including key mapping information and a key identifier. The protection systems are applied to the content using the key information identified in the sample encryption box 114.
Referring next to FIG. 4, an exemplary flow chart illustrates the decoding of content for presentation on a computing device. A DRM-protected video file is received by the computing device at 402. A parser executing on the computing device examines metadata in the received file at 404 to determine that the file has a protection system applied thereto at 406. For example, the parser determines that the file has been protected by a stream type of encrypted video (e.g., “encv”) or encrypted audio (e.g., “enca”) if the file is in Moving Picture Experts Groups-4 (MP4) format. In such an example, the parser examines a scheme information box or scheme type box within a protection scheme information box to determine whether a track within the file is encrypted in accordance with aspects of the disclosure. The track corresponds to a collection of related samples in the file. In some embodiments, the parser finds in the scheme type box a four-character code and a version number identifying the protection scheme.
An application program executing on the computing device searches the protection system header boxes 116 in the received video file at 408 to find the protection system header box 116 that corresponds to a protection system supported by the computing device. The protection system header box 116 is used to ensure that any license(s) for decrypting the content is available on the computing device before playback begins. The key identifier is obtained from the sample encryption box 114. The application program obtains data from the protection system header box 116 corresponding to a supported protection system that enables the application program to obtain a license from a license server that corresponds to that key identifier at 410. The application then extracts an encrypted key from the license, and decrypts the key at 411. Decryption of the encrypted key (e.g., a private key, an individualized key, or other asymmetric key) may be performed using known public-private key systems, in some embodiments. The decrypted key is used to decrypt the track, and the decrypted content is presented to the user at 412.
In some embodiments, the operations illustrated in FIG. 4 are implemented using computer-executable components stored on one or more computer-readable media. For example, the components illustrated in FIG. 1 perform the operations. In such an example, the interface component 120 receives the file containing content and one or more encryption expressions. The content has been encrypted by at least one of the encryption expressions. The content further has a plurality of protection systems applied thereto, and the file includes metadata for each of the plurality of protection systems. The plurality of protection systems share access to the encryption expressions. Further, the content is encoded according to an encryption algorithm. The plurality of protection systems shares the encryption expressions and the encryption algorithm.
The detection component 122 examines a scheme information box in the file to determine whether the content is protected by a protection scheme in accordance with aspects of the disclosure. The detection component 122 determines which protection systems are supported by the computing device, and selects one of the supported protection systems. The parse component 124 obtains, from the metadata, license information for the protection system selected by the detection component 122. The transform component 126 decodes and decrypts the content based on the license information obtained by the parse component 124 and based on the encryption expressions. The interface component 120 presents the decoded content to a user.
Referring next to FIG. 5, FIG. 6, FIG. 7, FIG. 8, and FIG. 9, exemplary block diagrams illustrate an example application of embodiments of the disclosure to extend a media file format to support a plurality of protection systems in a single container file. The examples below refer to various known specifications including, but not limited to, ISO 14496-12, ISO 14496-14, ISO 14496-1, ISO 14496-10, ISO 14496-3, and ISO/IEC 639-3:2007, all of which are hereby incorporated by reference herein for all purposes. While the examples next described are directed to the ISO base media file format and/or MP4 formats, embodiments of the invention are applicable to other file formats.
For the purposes of the following examples, the file format may be referred to as a movie. The movie is logically divided into tracks. Each track represents a timed sequence of media (e.g., frames of video). Within each track, each timed unit or frame of data is called a sample (e.g., a frame of video or audio, a time-contiguous series of video frames, or a time-contiguous compresses section of audio). Samples are implicitly numbered in sequence. A frame of audio may decompress into a sequence of audio samples. Each track has one or more sample descriptions. Each sample in the track is tied to a description by reference. The description defines how the sample may be decoded (e.g. identifies the compression algorithm used).
In some embodiments, neither the physical structure of the file nor the layout of the physical media is tied to the time ordering of the media content. For example, frames of video need not be laid down in the file in time order, although the frames might be laid down in such a way.
The data within the file is encapsulated in boxes. The metadata, including metadata defining the placement and timing of the media content, is contained in the boxes. The media content (e.g., frames of video) is referred to by the metadata. The media content may be in the same file (e.g., contained in one or more boxes) or can be in other files. The metadata permits referring to other files by means of references such as hyperlinks (e.g., uniform resource locators).
In the examples below, embodiments of the invention use a class-based notation with inheritance. The classes are consistently represented as structures on the disk and on the wire as follows: the fields of a class appear in the disk structure in the same order the fields are specified, and the fields in a parent class appear before the fields for derived classes. Further, when a box contains other boxes as children, the child boxes appear after any explicitly specified fields and can appear in any order (e.g., sibling boxes can be re-ordered without breaking compliance to the specification).
Referring again to FIG. 5, an exemplary block diagram illustrates an exemplary structure representing a fragmented file structure in accordance with embodiments of the disclosure. The fragmented file structure includes two top-level boxes: a movie fragment box (“moof”) for metadata, and a media data (“mdat”) box for samples. In this example, the sample encryption box 114 shared by the protection systems is shown as a sub-box of the movie fragment box. The sample encryption box 114 includes sample-specific encryption data. In the example of FIG. 5, the sample encryption box 114 has a type universally unique identifier (UUID), and is part of a track fragment container box or a sample table container box.
An example syntax for the sample encryption box 114 is shown below.
aligned(8) class SampleEncryptionBox extends FullBox(‘uuid’, extended_type=1, version=0, flags=0) { unsigned int(8) AlgorithmID; GUID KID; unsigned int(32) sample_count; { unsigned int(64) SampleIdentifier; }[ sample_count ] }
The AlgorithmID is the identifier of the encryption algorithm (e.g., AES 128-bit in CTR mode) used to encrypt the track. KID is a key identifier that identifies the key for decrypting samples referred to by the sample encryption box 114. In this example, there is one AlgorithmID and one KID in the sample encryption box 114, meaning that there is one key per track. In other embodiments, there are multiple keys per track to, for example, allow for key rotation for broadcast content including sections of clear content within an encrypted track and to allow for insertion of content encrypted with different parameters (e.g., editing, advertisement insertion, etc).
Sample_count is the quantity of sample in this track or track fragment. SampleIdentifier is used to form an initialization vector for decrypting the sample. The AES CTR mode encryption used to encrypt the sample data uses the SampleIdentifier as the high 64 bits and a simple block counter (e.g., starting at zero from the beginning of the sample) as the low 64 bits of the 128 bit value encrypted with the AES cipher. In some embodiments, the SampleIdentifiers for a given key are unique for each sample, and the initial sample identifier is randomly generated. For each protected sample added to the file, the SampleIdentifier is incremented to provide entropy and ensure that the SampleIdentifiers are unique.
Referring again to FIG. 6, an exemplary block diagram illustrates an exemplary structure representing fragmented file organization. The movie fragment includes a particular segment of a particular sequence of media data. In this example, the disk format is fragmented MP4. The file type box in FIG. 6 identifies the file as being encoded according to embodiments of the disclosure to make the file type box fixed length. The plurality of DRM specific header boxes 602 such as DRM specific header box #1 through DRM specific header box #N (sub-boxes of the movie box) correspond to the plurality of protection system headers boxes illustrated in FIG. 1. The DRM specific header boxes 602 contain data including, but not limited to, a license server reference (e.g., uniform resource locator), a list of key identifiers used by the file, embedded licenses, and the like. The DRM specific header boxes 602 may also store or pre-load any quantity of embedded licenses (e.g., from the service provider 206 prior to the content being made available to the user).
In some embodiments, a plurality of DRM specific header boxes 602 exists for the same protection system. For example, a single file is shared by two different services both using the same protection system but each using different header parameters (e.g., different service identifiers, different license acquisition links, etc.).
An example syntax for the DRM specific header boxes 602 is shown below.
aligned(8) class DrmSpecificHeaderBox extends FullBox(‘uuid’, extended_type=1, version=0, flags=0) { GUID DRMID; unsigned int(32) DataSize; unsigned int(8) [DataSize] Data; }
DRMID specifies a UUID that uniquely identifies the protection system to which this header belongs. DataSize specifies the size in bytes of the data member. Data holds the data specific to the protection system.
Referring again to FIG. 7, an exemplary block diagram illustrates an exemplary structure for storing a track box. The track box acts as a container box storing boxes such as a media information box 702 as shown in FIG. 8.
Referring again to FIG. 8, an exemplary block diagram illustrates an exemplary structure for storing the media information box 702. The media information box 702 acts as a container box for storing boxes such as a sample description box (“stsd”). The sample description box stores boxes including a protected sample entry box 802, which stores the encrypted sample content. The sample entry box is shown again in FIG. 9.
Referring again to FIG. 9, an exemplary block diagram illustrates an exemplary structure for storing the protected sample entry box 802. The protected sample entry box 802 acts as a container box storing boxes such as a protection scheme information box. In contrast to the existing ISO base media file format, the protection scheme information box is stored in place of the sample entry in the sample description box to denote that the stream is encrypted. The protection scheme info box contains a scheme type box (‘schm’) so that the scheme is identifiable.
The file format described herein represents a minimum file format that includes support for late binding of alternate audio and video content. This enables computing devices supporting legacy or emerging coders/decoders (codecs) to late-bind those streams at playback without burdening devices without support of those codecs with the additional download cost.
Embodiments of the disclosure support both fragmented and nonfragmented container files. For example, for adaptive streaming, the fragmented file format is used, but for digital copy from an optical disc, the nonfragmented file format is used.
The embodiments illustrated and described herein as well as embodiments not specifically described herein but within the scope of aspects of the invention constitute exemplary means for supporting the plurality of protection systems within a single container file in accordance with the ISO Base Media File Format, and exemplary means for storing the metadata for the plurality of protection systems in a single container file as an extension to the ISO Base Media File Format.
receiving a file containing encrypted content and one or more encryption expressions, said encrypted content being encrypted by the one or more encryption expressions;
using the one or more encryption expressions to apply a plurality of protection systems to the encrypted content to create a DRM-protected file from the received file, each of the plurality of protection systems defining a corresponding protection system header box, each protection system header box containing license information that enables decryption of the encrypted content, each protection system header box being included in the received file; and
transmitting the DRM-protected file to one or more computing devices for decryption of the encrypted content, wherein the one or more computing devices search the protection system header boxes to find the protection system header box that corresponds to a protection system supported by the one or more computing devices, the decryption determining the license information contained in the found protection system header box that corresponds to the protection systems supported by the one or more computing devices, the determined license information enabling retrieval of a decryption key to decrypt the encrypted content.
2. The method of claim 1, wherein applying the plurality of protection systems to the encrypted content comprises adding metadata for each of the plurality of protection systems to the received file, said metadata defining one or more of the following: a decryption key, a rights object, and license information.
3. The method of claim 1, wherein receiving the file comprises receiving a file containing key mapping information, said encrypted content being encrypted using said key mapping information.
4. The method of claim 1, further comprising embedding the license information into the protection system header box.
5. The method of claim 1, further comprising embedding in the protection system header box a reference to the license information.
6. The method of claim 1, wherein applying the plurality of protection systems to the content comprises applying the plurality of protection systems to said encrypted content without creating another copy of the encrypted content.
7. The method of claim 1, wherein the file further contains a sample encryption box that identifies an encryption method common to the plurality of protection systems.
8. The method of claim 1, wherein the one or more computing devices obtain a license from a license server, the license enabling decryption of the encrypted content.
9. The method of claim 7, wherein the sample encryption box includes a key identifier that identifies an encryption key, the sample encryption box being shared across the protection system header boxes.
10. A system for extending a media file format to support multiple protection systems in a single container file, said system comprising:
a memory area for storing at least a file containing encrypted content; and
receive the file containing the encrypted content and one or more encryption expressions, said encrypted content being encrypted by the one or more encryption expressions;
use the one or more encryption expressions to apply a plurality of protection systems to the encrypted content to create a DRM-protected file from the received file, each of the plurality of protection systems defining a corresponding protection system header box, each protection system header box containing license information that enables decryption of the encrypted content, each protection system header box being included in the received file; and
transmit the DRM-protected file to one or more computing devices for decryption of the encrypted content, wherein the one or more computing devices search the protection system header boxes to find the protection system header box that corresponds to a protection system supported by the one or more computing devices, the decryption determining the license information contained in the found protection system header box that corresponds to the protection system supported by the one or more computing devices, the determined license information enabling retrieval of a decryption key to decrypt the encrypted content.
11. The system of claim 10, wherein applying the plurality of protection systems to the encrypted content comprises adding metadata for each of the plurality of protection systems to the received file, said metadata defining one or more of the following: a decryption key, a rights object, and license information.
12. The system of claim 10, wherein the received file contains key mapping information, said encrypted content being encrypted using said key mapping information.
13. The system of claim 10, wherein the processor is further programmed to embed the license information in the protection system header box.
14. The system of claim 10, wherein the processor is further programmed to embed in the protection system header box a reference to the license information.
15. The system of claim 10, wherein the file further contains a sample encryption box that identifies an encryption method common to the plurality of protection systems.
16. The system of claim 15, wherein the sample encryption box includes a key identifier that identifies an encryption key, the sample encryption box being shared across the protection system header boxes.
17. One or more computer devices storing computer-executable instructions that when executed by at least one processor causes the at least one processor to perform operations comprising:
transmitting the DRM-protected file to one or more other computing devices for decryption of the encrypted content, wherein the one or more other computing devices search the protection system header boxes to find the protection system header box that corresponds to a protection system supported by the one or more other computing devices, the decryption determining the license information contained in the found protection system header box that corresponds to the protection system supported by the one or more other computing devices, the determined license information enabling retrieval of a decryption key to decrypt the encrypted content.
18. The computer devices of claim 17, storing further computer-executable instructions that when executed by the at least one processor causes the at least one processor to further perform operations comprising:
embedding the license information into the protection system header boxes.
19. The computer devices of claim 17, wherein applying the plurality of protection systems to the content comprises applying the plurality of protection systems to said encrypted content without creating another copy of the encrypted content.
20. The computer devices of claim 17, wherein the one or more other computing devices obtain a license from a license server, the license enabling decryption of the encrypted content.
US12/485,949 2009-01-21 2009-06-17 Multiple content protection systems in a file Active 2030-11-24 US8904191B2 (en)
US14609909P true 2009-01-21 2009-01-21
US12/485,949 US8904191B2 (en) 2009-01-21 2009-06-17 Multiple content protection systems in a file
KR1020117016966A KR101623616B1 (en) 2009-01-21 2009-12-22 Multiple content protection systems in a file
PCT/US2009/069332 WO2010090689A1 (en) 2009-01-21 2009-12-22 Multiple content protection systems in a file
JP2011547943A JP5730786B2 (en) 2009-01-21 2009-12-22 Multiple content protection systems in one file
CA2747824A CA2747824C (en) 2009-01-21 2009-12-22 Multiple content protection systems in a file
CN200980155365.9A CN102292931B (en) 2009-01-21 2009-12-22 Method and device for multiple content protection systems in a file
MX2011007388A MX2011007388A (en) 2009-01-21 2009-12-22 Multiple content protection systems in a file.
EP09839834.0A EP2380307A4 (en) 2009-01-21 2009-12-22 Multiple content protection systems in a file
AU2009339304A AU2009339304B2 (en) 2009-01-21 2009-12-22 Multiple content protection systems in a file
IL213103A IL213103A (en) 2009-01-21 2011-05-24 Multiple content protection systems in a file
US14/555,498 US10229248B2 (en) 2009-01-21 2014-11-26 Multiple content protection systems in a file
US14/555,498 Continuation US10229248B2 (en) 2009-01-21 2014-11-26 Multiple content protection systems in a file
US20100185854A1 US20100185854A1 (en) 2010-07-22
US8904191B2 true US8904191B2 (en) 2014-12-02
ID=42337885
US12/485,949 Active 2030-11-24 US8904191B2 (en) 2009-01-21 2009-06-17 Multiple content protection systems in a file
US14/555,498 Active 2029-10-21 US10229248B2 (en) 2009-01-21 2014-11-26 Multiple content protection systems in a file
US (2) US8904191B2 (en)
EP (1) EP2380307A4 (en)
JP (1) JP5730786B2 (en)
KR (1) KR101623616B1 (en)
CN (1) CN102292931B (en)
AU (1) AU2009339304B2 (en)
CA (1) CA2747824C (en)
IL (1) IL213103A (en)
MX (1) MX2011007388A (en)
WO (1) WO2010090689A1 (en)
KR101830968B1 (en) 2010-08-24 2018-02-21 삼성전자주식회사 Device and method for enforcing an advertisement watching
DE102012022064A1 (en) * 2012-11-09 2014-05-15 Thomas Klimpel System and method for playing music and / or multimedia data
CN104463019B (en) * 2014-12-29 2017-07-25 北京致远互联软件股份有限公司 The encipher-decipher method of electronic document
KR101703489B1 (en) * 2015-07-22 2017-02-08 주식회사 디지캡 Broadcast scrambling system based on file
FR3052893B1 (en) * 2016-06-21 2018-07-13 Bouygues Telecom Method for restituting digital multimedia content
JP2005538453A (en) 2002-09-09 2005-12-15 ソニー エレクトロニクス インク Content distribution for multiple digital rights management
US20060075226A1 (en) 2004-09-29 2006-04-06 Nokia Corporation Data file including encrypted content
US20060242074A1 (en) * 2005-04-22 2006-10-26 Nokia Corporation Encrypting digital rights management protected content
US20060262074A1 (en) 2005-05-20 2006-11-23 Nec Corporation Bootstrap circuit, and shift register, scanning circuit, display device using the same
WO2007094588A1 (en) 2006-02-15 2007-08-23 Samsung Electronics Co., Ltd. Method and apparatus for importing content having plurality of parts
US20070203843A1 (en) * 2005-05-09 2007-08-30 Lauri Tarkkala System and method for efficient encryption and decryption of drm rights objects
US20080288788A1 (en) 2007-05-16 2008-11-20 Broadcom Corporation Digital Rights Management Metafile, Management Protocol and Applications Thereof
US20090080664A1 (en) 2007-09-21 2009-03-26 Samsung Electronics Co., Ltd. Method of storing broadcast contents in mobile broadcast service terminal
CN100460202C (en) * 2006-05-15 2009-02-11 高学文;嘉合实业(苏州)有限公司 PVDC polyolefin coextruded thermal-formed high-blocked composite packaging material
2009-06-17 US US12/485,949 patent/US8904191B2/en active Active
2009-12-22 JP JP2011547943A patent/JP5730786B2/en active Active
2009-12-22 EP EP09839834.0A patent/EP2380307A4/en active Pending
2009-12-22 CN CN200980155365.9A patent/CN102292931B/en active IP Right Grant
2009-12-22 WO PCT/US2009/069332 patent/WO2010090689A1/en active Application Filing
2009-12-22 CA CA2747824A patent/CA2747824C/en active Active
2009-12-22 MX MX2011007388A patent/MX2011007388A/en active IP Right Grant
2009-12-22 KR KR1020117016966A patent/KR101623616B1/en active IP Right Grant
2009-12-22 AU AU2009339304A patent/AU2009339304B2/en active Active
2011-05-24 IL IL213103A patent/IL213103A/en active IP Right Grant
2014-11-26 US US14/555,498 patent/US10229248B2/en active Active
JP2007220139A (en) 2006-02-15 2007-08-30 Samsung Electronics Co Ltd Method and device for importing content containing plurality of content portions
"China Fourth Office Action", Mailed Date: Jul. 3, 2013, Application No. 200980155365.9, Filed Date: Jul. 20, 2011, pp. 7.
"China Second Office Action", Mailed Date: Oct. 29, 2012, Application No. 200980155365.9, pp. 9.
"China Third Office Action", Mailed Date: Mar. 4, 2013, Application No. 200980155365.9, Filed Date: Jul. 20, 2011, pp. 6.
"Coral Consortium Introduction," Coral Consortium Corporation, 2005, pp. 25.
"DRM Content Format V2.0", Retrieved at <<http://xml.coverpages.org/OMADRM-DCFv202-20040420.doc>>, Apr. 20, 2004, pp. 1-32.
"DRM Content Format V2.0", Retrieved at >, Apr. 20, 2004, pp. 1-32.
"Fifth Office Action" for Chinese Patent Application No. 200980155365.9 with English summary, Mailed Date: Sep. 30, 2013, 7 pages.
"First Office Action" for Chinese Patent Application No. 200980155365.9 with English summary, Mailed Date: Apr. 27, 2012, 13 pages.
"Fourth Office Action" for Chinese Patent Application No. 200980155365.9 with English summary, Mailed Date: Jul. 3, 2013, 8 pages.
"International Search Report", Mailed Date: Jul. 22, 2010, Application No. PCT/US2009/069332, Filed Date: Dec. 22, 2009, pp. 8.
"Notice of Allowance for Chinese Patent Application No. 200980155365.9" with English summary, Mailed Date: Dec. 5, 2013, 7 pages.
"Office Action for Australian Patent Application No. 2009339304", Mailed Date: Mar. 3, 2014, 3 pages.
"Office Action for Japanese Patent Application No. 2011-547943" with English summary, Mailed Date: Dec. 26, 2013, 8 pages.
"Office Action from the Mexican National Phase", Aug. 14, 2013, Application No. MX/a/2011/007388, pp. 6.
"Second Office Action" for Chinese Patent Application No. 200980155365.9 with English summary, Mailed Date: Oct. 29, 2912, 13 pages.
"Third Office Action" for Chinese Patent Application No. 200980155365.9 with English summary, Mailed Date: Mar. 4, 2013, 7 pages.
First Office Action in U.S Patent Application No. 200980155365.9, Dated Apr. 27, 2012, pp. 13.
Ji, et al., "MPEG-4 IPMP Extension for Interoperable Protection of Multimedia Content", Retrieved at <<http://hindawi.com/GetPDF.aspx?doi=10.1155/S1110865704403096>>, EURASIP Journal on Applied Signal Processing, vol. 14, 2004, pp. 2201-2213.
Ji, et al., "MPEG-4 IPMP Extension for Interoperable Protection of Multimedia Content", Retrieved at >, EURASIP Journal on Applied Signal Processing, vol. 14, 2004, pp. 2201-2213.
Taban, et. al., "Towards a Secure and Interoperable DRM Architecture", Retrieved at <<http://delivery.acm.org/10.1145/1180000/1179524/p69-taban.pdf?key1=1179524&key2=9317639421&coll=GUIDE&dl=GUIDE&CFID=47490296&CFTOKEN=57432691>>, In Proceedings of the ACM Workshop on Digital Rights Management, Oct. 30, 2006, pp. 69-78.
Torres, et al., "Open DRM and the Future of Media", Retrieved at <<http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&isnumber=&arnumber=4545709>>, IEEE MultiMedia, vol. 15, No. 2, Apr.-Jun. 2008, pp. 28-36.
Torres, et al., "Open DRM and the Future of Media", Retrieved at >, IEEE MultiMedia, vol. 15, No. 2, Apr.-Jun. 2008, pp. 28-36.
Wang, Xing, "Standards and Legal Issues", Retrieved at <<http://www.contentguard.com/drmwhitepapers/DRM—standard—activities.pdf>>, Multimedia Security Technologies for Digital Rights Management, Apr. 28, 2006, pp. 1-24.
Wang, Xing, "Standards and Legal Issues", Retrieved at >, Multimedia Security Technologies for Digital Rights Management, Apr. 28, 2006, pp. 1-24.
CA2747824A1 (en) 2010-08-12
JP2012515976A (en) 2012-07-12
WO2010090689A1 (en) 2010-08-12
CA2747824C (en) 2017-01-31
US20170124295A9 (en) 2017-05-04
US20150193599A1 (en) 2015-07-09
CN102292931A (en) 2011-12-21
MX2011007388A (en) 2011-07-28
IL213103D0 (en) 2011-07-31
JP5730786B2 (en) 2015-06-10
KR101623616B1 (en) 2016-05-23
US20100185854A1 (en) 2010-07-22
AU2009339304B2 (en) 2014-08-07
EP2380307A4 (en) 2017-05-31
IL213103A (en) 2016-11-30
EP2380307A1 (en) 2011-10-26
CN102292931B (en) 2014-03-26
KR20110122669A (en) 2011-11-10
US10229248B2 (en) 2019-03-12
AU2009339304A1 (en) 2011-07-07
EP2316087B1 (en) 2019-08-14 Segmented media content rights management
KR20020089472A (en) 2002-11-29 Content distribution/ protecing method and apparatus
JP2005533416A (en) 2005-11-04 How to securely present encrypted digital content
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BURNS, QUINTIN SWAYNE;HUGHES, ROBERT KILROY, JR.;SIMMONS, JOHN CARL;SIGNING DATES FROM 20090601 TO 20090611;REEL/FRAME:022995/0492
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:FIERSTEIN, SCOTT J.;REEL/FRAME:028702/0538