HK1189293A - Embedded licenses for content - Google Patents

Description

Embedded licenses for content

The present application is a divisional application entitled "embedded license for content" with an application date of 2010, 10/28, and an application number of 200980115756.8 (international application number of PCT/US 2009/039515).

Technical Field

The present application relates to licenses and, more particularly, to a method for embedded licenses for content.

Background

Increasingly, storage and playback of different types of audio and/or video content is performed digitally, with playback being performed using a variety of computers and other digital devices. In order to protect their content and to ensure that only those who have obtained rights to use the content can actually use the content, the content is frequently encrypted using a key. One problem with this encryption, however, is that the key is typically associated with a particular device. This may make it difficult for the user to play back the content on other devices that he or she owns, although he or she obtains rights to use the content.

Disclosure of Invention

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

In accordance with one or more aspects of an embedded license for content, a request to perform an action on the content is received. A license for the content is retrieved, the license having been previously embedded in the content. This license is a license for a domain that includes one or more devices, including the device that received the request. If the license indicates that the action on the content is permissible, the action is allowed to be performed on the content, and otherwise the action is prevented from being performed on the content.

The content to be sent to the second device is accessed in accordance with one or more aspects of the embedded license for the content. A check is made as to whether the content already has an embedded license for the domain of which the second device is a part. If the content already has an embedded license for the domain, the content is sent to the second device with the embedded license. If the content does not already have an embedded license for the domain, a license for the domain is embedded in the content and the content is sent to the second device with the embedded license.

In accordance with one or more aspects of an embedded license for content, a request for a license for accessing content is received from a device. The requested license is sent to the device, the requested license including one or more rules indicating where the device is to store the license.

Drawings

The same reference numbers will be used throughout the drawings to refer to the same or like features.

FIG. 1 illustrates an example system implementing embedded licenses for content in accordance with one or more embodiments.

FIG. 2 illustrates an example system with content embedded with a license portion in accordance with one or more embodiments.

FIG. 3 is a flow diagram illustrating an example process for using a license having an embedded license in accordance with one or more embodiments.

FIG. 4 is a flow diagram illustrating an example process for using a chain of licenses in accordance with one or more embodiments.

FIG. 5 is a flow diagram illustrating an example process for embedding a license at a source device in accordance with one or more embodiments.

FIG. 6 is a flow diagram illustrating an example process for using embedded license rules in accordance with one or more embodiments.

FIG. 7 illustrates an example computing device that can be configured to implement embedded licenses for content in accordance with one or more embodiments.

Detailed Description

Embedded licenses for content are discussed herein. Generally, licenses for content are embedded in the content, allowing the licenses to be easily sent to various devices along with the content. The content includes an embedded license portion in which one or more embedded licenses can be stored. Each embedded license may be a separate license or part of a chain of licenses. In addition, each embedded license may be associated with a particular device or domain of which one or more devices are a part. The license may be embedded by the device that receives the content, or alternatively by the device from which the content is received. Additionally, the license may include one or more rules regarding where the device stores the license.

FIG. 1 illustrates an example system 100 implementing embedded licenses for content in accordance with one or more embodiments. The system 100 includes a source device 102 and a target device 104. Content can be transferred from the source device 102 to the target device 104 in a variety of different ways. In one or more embodiments, content is transferred via a network, such as the Internet, a Local Area Network (LAN), a public telephone network, an intranet, other public and/or proprietary networks, combinations thereof, and so forth. In other embodiments, the content is transferred via a direct line or wireless connection, such as a Universal Serial Bus (USB) connection, IEEE1394 compliant connection, wireless USB connection, bluetooth connection, or the like. It will be appreciated that content may also be transferred using one or more transport devices, such as magnetic disks, optical disks, USB dongles, and the like.

Each of source device 102 and target device 104 may be a variety of different devices capable of playing, storing, or otherwise using content. Both source device 102 and target device 104 may be the same type of device or alternatively may be different types of devices. For example, each of the devices 102 and 104 may be a desktop computer, a server computer, a mobile station, an entertainment appliance, a set-top box communicatively coupled to a display device, a wireless telephone, a game console, an automotive computer, a kiosk, and so forth. Thus, each of the devices 102 and 104 may range from full resource devices with substantial memory and processor resources (e.g., personal computers, game consoles) to low-resource devices with limited memory and/or processing resources (e.g., traditional set-top boxes, hand-held game consoles).

Devices 102 and/or 104 may generally access and/or use content in different manners, such as performing one or more of playing the content, storing the content, transferring the content, and so forth. "content," as used herein, refers to a variety of different digital or electronic content, such as audio content (e.g., songs), audio/video content (e.g., television programs, movies, documentaries, cartoons, etc.), image content (e.g., digital pictures), textual content (e.g., electronic books), compiled or uncompiled computer programs or portions thereof, Java games, files compressed in a zip format or otherwise, email messages and attachments, and the like, as well as combinations thereof. As discussed in more detail below, whether a particular device 102 and/or 104 can access particular content is determined based at least in part on the embedded license for the particular content.

Source device 102 includes a content store 112 that contains content 114 and a license embedding module 116. In one or more embodiments, license embedding module 116 embeds licenses in content 114 prior to transfer to target device 104. In other embodiments, the license is embedded by the target device 104. This embedding of the license into the content is discussed in more detail below.

Target device 104 includes a consumption module 122, a license embedding module 124, and a content store 126. The content store 126 includes content 128. Each of the content 128 (e.g., each song, each movie, etc.) includes an embedded license portion 130. Consumption module 122 manages consumption of content 128 at target device 104. How particular content 128 is consumed may vary based on the particular request received from the user to use the content 128 and the type of content 128. For example, such consumption can include playing back the content 128, transferring the content 128 to another device, burning the content 128 to a CD (compact disc) or other optical disc, printing a hard copy of the content 128, sending the content 128 via email, and so forth. As discussed in detail below, in one or more embodiments, license embedding module 124 embeds licenses in embedded license portion 130 of content 128. Additionally, in one or more embodiments, target device 104 includes a license store 132 in which one or more licenses for content 128 are stored.

Reference is made herein to symmetric key cryptography, public key cryptography, and public/private key cryptography. While these key ciphers are well known to those skilled in the art, a brief overview of such ciphers is provided herein to assist the reader. In public key cryptography, an entity (e.g., a hardware or software component, device, domain, etc.) has a public/private key pair associated with it. The public key may be made publicly available, but the entity keeps the private key secret. Without the private key, it is computationally very difficult to decrypt data encrypted using the public key. Therefore, data can be encrypted by any entity using the public key and decrypted only by the entity with the corresponding private key. In addition, a digital signature of the data may be generated by using the data and a private key. Without the private key, it is computationally very difficult to create a signature that can be verified using the public key. Any entity having a public key can verify the digital signature using the public key by comparing a verification value obtained using the public key with the original data, and if the two are the same, determine that no one has tampered with or altered the digitally signed data.

In symmetric key cryptography, on the other hand, both entities know and keep secret the shared key. Any entity with a shared key is typically able to decrypt data encrypted using the shared key. Without a shared key, it is computationally very difficult to decrypt data encrypted using the shared key. So, if both entity a and entity B know the shared key, each can decrypt data encrypted by the other, but other entities cannot decrypt the data if they do not know the shared key.

Consumption module 122 enforces Digital Rights Management (DRM) for target device 104. Digital rights management refers to the protection of rights to the artist, publisher, and/or copyright owner of digital content. The DRM technology used by consumption module 122 limits the actions that can be taken on content 128 on target device 104. Various different accesses may be restricted, such as playing back content 128, burning content 128 to a CD or other optical disk, copying content 128 to another device, printing a hard copy of content 128, sending content 128 via email, and so forth.

Consumption module 122 uses DRM techniques to protect content 128 from improper use or action on target device 104. The constraints on the use of the content 128 are made known to the device 104, typically as part of a license, as discussed in more detail below. Alternatively, one or more constraints may be made known in other ways, such as preprogrammed into consumption module 122, giving individual notifications of such constraints (e.g., individual messages sent to device 104, or obtaining such constraints from a website, etc.), and so forth.

The content 128 is typically protected by encryption so that the content 128 can only be consumed in an understandable manner if the correct decryption key is known. Consumption module 122 uses various DRM techniques to determine when it is permissible to decrypt the content (according to constraints on the use of content 128). DRM technologies can be implemented in a variety of different ways. For example, DRM techniques may include verification that the operating system and/or other software executing on device 104 is trusted, verification that constraints specified by the owner of the rights to content 128 and/or the distributor of content 128 are satisfied, verification that the operating system and/or device 104 has the latest DRM updates required for one or more licenses, and so forth. Various DRM techniques are known to those skilled in the art, and one or more of these techniques may be used by consumption module 122.

One or more restrictions on the use of the particular content 128 are identified based on the one or more licenses associated with the particular content 128. The license for a particular piece of content 128 includes a policy identifying when decryption of the particular piece of content 128 is permitted and a cryptographic key for decrypting the particular piece of content 128. This cryptographic key is typically a shared key for symmetric key encryption, but may alternatively be a private key for public key encryption.

The policy identifies one or more actions that may be taken with respect to the corresponding content 128, one or more parties that may take the one or more actions, and/or one or more constraints or conditions to be satisfied in order to take the actions. Alternatively or additionally, the policy may identify one or more actions that cannot be taken with respect to the corresponding content 128 and/or one or more parties that cannot take one or more actions. Examples of actions that may be taken (or alternatively may not be taken) include playing back the corresponding content 128, burning the corresponding content 128 to a CD or other optical disc, copying the corresponding content 128 to another device, printing a hard copy of the content 128, sending the content 128 via email, and so forth. Examples of parties that may (or alternatively may not) take these actions include a particular target device 104, a particular user of the target device 104, and so forth. Examples of constraints or conditions to be satisfied include a particular consuming module 122 running on the target device 104, a particular operating system running on the target device 104, and so forth.

A variety of different licenses may be used. For example, a license may indicate that a particular target device 104 may play back a particular content 128, but may not burn the particular content 128 to a CD. As another example, another license may indicate that a particular target device 104 may play back a particular content 128, burn the particular content 128 to a CD, and transfer the particular content 128 to another device.

The license may be associated with a particular target device or a particular domain. When associated with a particular target device, the policy of the license indicates that actions can only be taken by the particular target device. Any attempt to use the license on a different target device will result in the requested action being denied. On the other hand, when associated with a particular domain, the policy of the license indicates that action can only be taken by any target device that is part (i.e., a member) of the domain. One or more individual target devices may register to become part of the domain, or alternatively a user may register to become part of the domain. Any attempt to use the license on a target device that is not part of the domain will result in the requested action being denied. For example, a user may own multiple target devices and register all of the devices as part of a single domain, and all of the devices may play back content with a license indicating that devices that are part of the domain may play back the content.

The content 128 is typically encrypted using a cryptographic key included in a license associated with the content 128. Consumption module 122 extracts this key from the license and uses it to decrypt the content only if the policy in the license indicates that consumption module 122 is permitted to use the content. The key in the license is bound to the particular target device 104 or domain, such as by encrypting the key in the license (or alternatively encrypting the entire license) using the public key of the particular target device 104 or domain. Thus, only the particular target device 104 or domain to which the key in the license is bound can extract and use the key to decrypt the content.

Each particular piece of content 128 in content store 126 has an embedded license portion 130 in which one or more embedded licenses can be stored. An embedded license refers to a license that is embedded in the content rather than in a separate file (e.g., on disk, in memory, or elsewhere). Embedding the license in content 128 allows the license for content 128 to be easily transferred to other devices. For example, a file containing the particular content 128 may also contain an embedded license for the particular content 128. Content 128, including any embedded licenses, can be transferred to other devices without any checks being made as to whether the embedded licenses allow the device receiving the content 128 to consume the content 128. Instead, the content 128 can be easily transferred to the receiving device and if the license indicates that the receiving device is allowed to consume the content, the receiving device will be allowed to consume the content.

Generally, licenses that are portable in nature are embedded in the content 128, while licenses that are not portable in nature are not embedded in the content. For intrinsically portable licenses, the license is typically associated with a domain or root license. The independent license bound to a particular target device 104 is typically not available on another device, and thus is typically not portable in nature and is typically not embedded in the content 128.

The licenses obtained by the target device 104 may be copied between license stores. These licenses can be embedded in embedded license portion 130 in content 128, so embedded license portion 130 can be viewed as a license store. A device license store 132 may also be included in the target device 104 and one or more other license stores (not shown) on other devices (not shown) coupled to the target device 104 may also store licenses. Licenses can be copied between these various license stores by consumption module 122, or alternatively by another module implementing DRM for target device 104.

FIG. 2 illustrates example content having an embedded license portion. In FIG. 2, content file 202 includes embedded license portion 204 and content data portion 206. The content file 202 may be, for example, any of the content 128 of fig. 1. Embedded license portion 204 may be located in any of a variety of different locations in content file 202. For example, embedded license portion 204 may be included in the header of content file 202 or otherwise near the beginning of content file 202. Alternatively, embedded license portion 204 may be included near the end of the content file, in the middle of content file 202, and so forth. Additionally, although portions 204 and 206 are each shown as a single portion, alternatively one or both of the portions may be separate. For example, embedded license portion 204 may be divided into a plurality of sub-portions distributed in content file 202, thereby mixing embedded license portion 204 and content data portion 206 in content file 202. In one or more embodiments, these sub-portions correspond to a single portion of content data 206. In other embodiments, these sub-portions correspond to different portions of content data portion 206. For example, content data portion 206 may be divided into multiple portions with sub-portions of embedded license portion 204 interspersed between the multiple portions. Continuing with the example, a first sub-portion of the embedded license portion 204 can correspond to a first portion of the plurality of portions (e.g., can include one or more licenses corresponding only to content data in the first portion), a second sub-portion of the embedded license portion 204 can correspond to a second portion of the plurality of portions (e.g., can include one or more licenses corresponding only to content data in the second portion), and so forth.

The content data section 206 includes content data of the content file 202, such as audio data of audio content, video and video data of movie content, and the like. As described above, a portion of the content data portion 206 is encrypted using a cryptographic key. Embedded license portion 204 includes one or more embedded licenses for content file 202. As discussed in more detail below, each of these licenses can be part of a chain of licenses or a separate license.

Embedded license portion 204 stores one or more embedded licenses, and the particular licenses stored in portion 204 can change over time. In one or more embodiments, embedded license portion 204 is a static portion having a fixed amount of space that does not change regardless of the number of embedded licenses stored thereon. For example, the embedded license portion 204 may be a fixed 10kB space, but alternatively, smaller or larger sizes may be used. This fixed space allows embedded licenses to be added and/or removed from portion 204 without affecting content data portion 206. For example, a newly embedded license may be added to content data portion 206 by simply overwriting a portion of already embedded license portion 204. By adding such an additional embedded license, the size of the content file 202 and the content data portion 206 remains unchanged.

In other embodiments, embedded license portion 204 is a variable amount of space. In such embodiments, the size of embedded license portion 204 may be increased to accommodate additional embedded licenses and/or decreased to accommodate fewer embedded licenses.

The following may occur: one or more new embedded licenses need to be added to embedded license portion 204, but there is not enough room for such new embedded licenses. In this case, one or more embedded licenses in portion 204 are deleted from portion 204 to accommodate the new license. In one or more embodiments, those embedded licenses deleted from portion 204 are added to the license store (e.g., license store 132 of FIG. 1) of the device performing the deletion or alternatively added to another license store. Alternatively, such licenses can be deleted from portion 204 and not stored in such license store or other location.

Licenses may be selected for deletion from portion 204 in a variety of different ways. In one or more embodiments, a three-step process is used to select one or more licenses from portion 204 for deletion. First, any licenses that expire are selected for deletion. Licenses typically have an associated duration or expiration date and, once expired, cannot be used to decrypt associated content. Thus, any such expired licenses are first selected for deletion.

Second, if there are no expired licenses in portion 204, or the expired licenses in license 204 are insufficient to make enough room for the license or licenses to be added, any licenses that cannot be used by the device that added the new license are deleted. The content may include embedded licenses that may be used by different devices and/or domains. If a license cannot be used by the device to decrypt the content, such license is selected for deletion. All such licenses that cannot be used by the device may be selected for deletion, or alternatively, only enough licenses to make sufficient space for the license or licenses to be added are selected for deletion. If there are more licenses in embedded license portion 204 that the device cannot use than the licenses that need to be deleted to make enough space for the license or licenses to be added, then certain ones of these licenses are selected for deletion. This selection can be made in different manners, such as based on the order in which the licenses appear in portion 204 and/or the order in which the licenses are accessed in portion 204, based on the age of the licenses (e.g., from oldest to newest) (the age of the licenses can be determined in different manners, such as the time the license is embedded in portion 204, the time the license is created, etc.), a random selection, and so forth.

Third, if the first two steps do not make enough room for one or more licenses to be added, then one or more remaining licenses in portion 204 are selected from oldest to newest. As described above, the age of the license may be determined in different manners.

Continuing the three-step process, a sufficient number of licenses are selected for deletion and deleted from embedded license portion 204 to make sufficient room for one or more new embedded licenses. The removal of the license from portion 204 can be accomplished in different ways, such as overwriting the license with a new license, overwriting the license with a particular bit pattern or other data, shortening the size of the used portion of embedded license portion 204, and so forth.

Each license embedded in license portion 204 may be a separate license or part of a chain of licenses. An independent license is a license that includes sufficient policies and cryptographic keys for a module implementing DRM to determine whether a requested action can be performed on the corresponding content.

On the other hand, a license that is part of a chain of licenses is used in conjunction with one or more additional licenses for a module implementing DRM to determine whether a requested action can be performed on the corresponding content. One or more of these additional licenses can be included in portion 204 or, alternatively, can be in a separate license store (e.g., store 132 of fig. 1). In one or more embodiments, the embedded license is a portion of the chain of licenses referred to as a leaf license, and identifies a root license that is stored in a license store (e.g., store 132 of FIG. 1) of the device and/or that is included in embedded license portion 130.

For example, in FIG. 1, a leaf license may be embedded in particular content 128, the leaf license identifying a root license included in license store 132. The leaf licenses can include various policies, including constraints that a root license identified for performing a particular action is to be present in license store 132 (and/or license portion 130). If the identified root license exists in license store 132, consumption module 122 may perform the particular action; otherwise, module 122 will not perform the action.

Dividing the license into a leaf license and a root license may have several benefits. For example, a user of a target device 104 in a subscription-based environment may pay a monthly fee to access content 128. All of the content 128 may include leaf licenses identifying a particular root license to be present for playback of the content. The root license in storage 132 is updated to remain valid as the user pays his or her monthly fee, and expires if the user does not pay his or her monthly fee. Thus, each month only the root license is updated after a monthly fee is paid and the embedded licenses in the plurality of content 128 do not have to be updated.

It should be noted that a chain of licenses can include two or more licenses. For example, the chain of licenses can be two licenses, such as the leaf license and the root license described above. Additionally, the chain of licenses can include three or more licenses, such as one or more additional licenses included in the chain of licenses in addition to the leaf license and the root license. For example, a leaf license may identify an intermediate license, which in turn may identify a root license. Such intermediate licenses can be included in embedded license portion 130, or alternatively in a separate license store (e.g., store 132 of FIG. 1). Each intermediate license can include various policies including constraints that one or more identified licenses (e.g., one or more intermediate licenses, one or more root licenses, etc.) are to be present in embedded license portion 130 (and/or another license store) in order to perform a particular action.

In one or more embodiments using a chain of licenses, the cryptographic keys used to decrypt particular content 128 may be stored in different locations. For example, the cryptographic key may be included in the embedded leaf license (but may only be used if the identified root license and any other intermediate licenses in the chain of licenses are present). Continuing with the example, the identified root license includes a root key that is encrypted using a public key of the particular device or domain. The device decrypts the root key using the private key of the device or the domain, and then uses the root key to decrypt the cryptographic key embedded in the leaf license. As another example, the cryptographic key may be included in the root license instead of the embedded leaf license. As yet another example, the embedded leaf license may include one portion of the cryptographic key while the root license includes another portion of the cryptographic key.

Content data portion 206 may be encrypted in a variety of different ways, with different DRM systems using different encryption techniques. In one or more embodiments, content data portion 206 is encrypted using a symmetric key cipher. The shared key used to encrypt content data portion 206 is included in one or more licenses associated with content file 202, such as an embedded license stored in portion 204 and/or a root license stored in a license store (e.g., store 132 of FIG. 1). The shared key is encrypted using a public key of a particular device or a particular domain. The particular device or any device in the domain may in turn use its private key to decrypt the shared key and then use the shared key to decrypt the content data portion 206. Thus, only those devices with the appropriate private key can decrypt content data portion 206. Further, whether a DRM system (e.g., implemented by consumption module 122 of FIG. 1) will use its private key to decrypt the shared key depends on the policy in the license or licenses for the content.

Alternatively, the content data portion 206 may be encrypted in other ways. For example, the content data portion 206 may be encrypted with a public key of a particular device or a particular domain. Thus, the particular device or any device in the particular domain may use its private key to decrypt content data portion 206. Whether a DRM system (e.g., implemented by consumption module 122 of fig. 1) will use its private key to decrypt content data portion 206 depends on the policy in the one or more licenses for the content.

FIG. 3 is a flow diagram illustrating an example process 300 for using content with embedded licenses. Process 300 is performed by a device, such as target device 104 of FIG. 1, and may be implemented in software, firmware, hardware, or a combination thereof. Process 300 is typically performed by one or more modules responsible for implementing DRM in a device, such as consumption module 122 of FIG. 1. Process 300 is an example process for using content with embedded licenses; additional discussions of using content with embedded licenses are included herein with reference to different figures.

Initially, a request for an action to be performed on content is received (act 302). As described above, such actions may be playing back content, transferring content to another device, burning content to a CD, printing a hard copy of the content, sending the content via email, and so forth. One or more licenses embedded in the content for which the action is to be performed are then accessed (act 304), and a check is made as to whether one or more of the embedded licenses permits the requested action (act 306). The embedded license permits the requested action if the policy included in the embedded license indicates that the requested action can be performed.

If at least one of the embedded licenses in the content permits the requested action to be performed on the content, the requested action is permitted (act 308). Otherwise, a check is made as to whether a license permitting the requested action is available (act 310). The license granting the requested action may be obtained in a variety of different ways. For example, another device, such as a server, from which the content is received may be accessed to obtain the license, a service, such as a content subscription service, may be accessed to obtain the license, and so on. Acquiring the license may require registering the device with the domain or additional input from the user, such as approval to purchase the license, a credit card or other purchase information, an identification of another license store in which the license may be found, and so forth.

If a license permitting the requested action is available, such license is obtained (act 312) and saved (act 314). As discussed in more detail below, saving the license may include embedding the license in the content and/or maintaining the license in a separate license store. The action requested in act 302 is also performed (act 308).

Returning to act 310, if a license permitting the requested action cannot be obtained, the requested action is not performed (act 316).

It should be noted that the embedded licenses in acts 304 and 306 or the licenses obtained in act 310-. Additionally, these licenses can be licenses that permit a particular device implementing process 300 to perform a requested action, or licenses that permit a particular device implementing process 300 to perform a requested action when the particular device is a member of a particular domain.

Process 300 is discussed with reference to checking whether a license granting the requested action is available at act 310, in the event that the embedded license does not grant the requested action in act 306. Alternatively, one or more additional license stores may be accessed prior to performing the check of act 310. For example, license store 132 of FIG. 1 may be accessed to see if the licenses in store 132 permit the requested action, and if so, the requested action may be performed at action 308. As another example, another license store (not shown) may be accessed to see if the license in the license store permits the requested action, and if so, the requested action may be performed at act 308.

FIG. 4 is a flow diagram illustrating an example process 400 for using a chain of licenses. Process 400 is performed by a device, such as target device 104 of FIG. 1, and may be implemented in software, firmware, hardware, or a combination thereof. Process 400 is typically performed by one or more modules responsible for implementing DRM in a device, such as consumption module 122 of FIG. 1. In one or more embodiments, acts 401 and 410 implement acts 304 and 306 of FIG. 3. Process 400 is an example process for using a chain of licenses; additional discussion of using chains of licenses is included herein with reference to different figures.

Initially, a request for an action to be performed on content is received (act 402), similar to act 302 of FIG. 3 described above. A leaf license embedded in the content for which the action is to be performed is then retrieved (act 404), and a root license for the leaf license is identified (act 406). In one or more embodiments, this root license is identified by a leaf license. This identification may be explicit, such as an alphanumeric identifier of the root license included in the leaf license, or implicit, such as a naming convention for the license that allows the correspondence between the leaf license and the root license to be maintained.

The root license for the leaf license is retrieved (act 408). The root license may be retrieved from a local license store, such as license store 132 of FIG. 1, or from another location, such as a license store on another device, an embedded license portion of the content for which the action is to be performed, and so forth. Such a license store may be identified by a leaf license or may be known to the module implementing process 400.

A check is then made as to whether the leaf license and the root license permit the requested action (act 410). If the leaf license and the root license permit the requested action to be performed, then the requested action is performed (act 412). Otherwise, the requested action is not performed (act 414).

Process 400 is described with reference to a leaf license and a root license. It will be appreciated that one or more additional licenses can also be included in the chain of licenses that includes the leaf license and the root license. Each of these additional licenses can be identified as part of act 406, following the chain of licenses from the leaf license to the root license. The check in act 410 is then a check as to whether all licenses in the chain of licenses permit the requested action, where the requested action is performed if all licenses in the chain of licenses permit, and otherwise the requested action is not performed.

Returning to fig. 1, the license may be embedded in the content by source device 102, target device 104, and/or another device. As described above, the license embedded in the content by device 102, device 104, and/or another device may be a stand-alone license and/or part of a chain of licenses. Additionally, the license embedded in the content by device 102, device 104, and/or another device may be a license for device 102 and/or a license for a domain of which device 102 is a part.

In embodiments in which source device 102 embeds licenses in content, source device 102 includes a license embedding module 116 that embeds licenses in content prior to transferring the content to destination device 104. In one or more embodiments, license embedding module 116 embeds leaf licenses in content 114. Module 116 may pre-embed the leaf license in content 114 such that content 114 is already embedded with the leaf license when the transfer of content 114 to target device 104 is requested, and/or embed the leaf license in content 114 in response to a request for content 114. As described above, the leaf licenses identify the root license so that the same leaf license can be embedded in content 114 for different devices in multiple different domains. Although the leaf licenses are all the same, the requested action on the content is not performed on the device, as described above, unless the appropriate root license is also available to the device.

In embodiments where target device 104 embeds licenses in content, target device 104 includes a license embedding module 124 that embeds licenses in received content. License embedding module 124 may be implemented as part of consuming module 122 or may be a separate module operating in conjunction with and/or independent of consuming module 122. For example, consumption module 122 can communicate a request to license embedding module 124 to embed a license in particular content 128. As another example, license embedding module 124 may operate independently, searching content store 126 for content 128, and embedding a license from license store 132 into content 128 when content 128 without an embedded license is found.

Upon receipt of the content, the license is obtained from license store 132 or otherwise obtained as needed (e.g., similar to the discussion above with respect to process 300 of FIG. 3). License embedding module 124 writes this license to the embedded license portion (e.g., embedded license portion 204 of fig. 2) of the file that includes the content, overwriting any licenses selected for deletion if space is needed for storing this license. In one or more embodiments, the license is embedded in the content as it is obtained, but the license may alternatively be embedded at other times.

In embodiments where another device other than source device 102 or target device 104 embeds licenses in content, the other device includes a license embedding module similar to license embedding module 116. The license is embedded in the content, which may then be transferred to source device 102 or otherwise made available to source device 102. The license may thus be pre-embedded in content 114 such that the content has embedded a leaf license before requesting that the content be transferred to target device 104, and source device 102 does not have to embed a leaf license.

FIG. 5 is a flow diagram illustrating an example process 500 for embedding a license at a source device. Process 500 is performed by a device, such as source device 102 of fig. 1, and may be implemented in software, firmware, hardware, or a combination thereof. Process 500 is typically performed by modules of the active device, such as license embedding module 116 of FIG. 1. Process 500 is an example process for embedding a license at a source device, and additional discussion of embedding a license at a source device is included herein with reference to different figures.

Initially, content to be sent to a target device is accessed (act 502). In one or more embodiments, this content is accessed in response to a request for the content from a target device. Alternatively, such content may be accessed in response to other input, such as a request from a user of a device implementing process 500, a request from another component or device, and so forth.

A check is then made as to whether the content already has an embedded license for the target device (act 504). As described above, this embedded license for the target device may be a standalone license and/or part of a chain of licenses, and may be a license for the target device and/or a license for the domain of which the target device is a part. If the embedded license for the target device has been embedded in the content, the content with the embedded license is sent to the target device (act 506).

If, however, such an embedded license does not already exist in the content, then a license for the target device is embedded in the content (act 508). As described above, this embedded license for the target device may be a standalone license and/or part of a chain of licenses, and may be a license for the target device and/or a license for the domain of which the target device is a part. Whether such a license is embedded in the content may also optionally depend on other criteria, such as whether the target device is permitted to receive the content (e.g., an appropriate fee has been paid), and so forth. Once the license is embedded, the content with the embedded license is sent to the target device (act 506).

Returning to fig. 1, as described above, the following may occur: the target device 104 obtains a license from the license source device. This license source device may be source device 102 or another device (not shown). Such a license may have been embedded in content 128 or may be received separately. Upon receipt of such a license, it may be stored in its corresponding content 128 by being embedded in its corresponding content 128, stored in license store 132, stored in a different license store (not shown), or the like.

In one or more embodiments, the received license includes one or more embedded license rules for the target device that indicate where the target device 104 is to store the license. Consuming module 122 or another module on target device 104 accesses the one or more rules and stores the license based on the one or more rules. The one or more rules may indicate that the license is to be stored (embedded) in one or more of the content 128 to which the license corresponds, in the license store 132, in another license store on another device (not shown), and so forth. In one or more embodiments, the one or more rules are merely suggestions as to where to store the license. Alternatively, the storage in the license may indicate that consumption module 122 or another module implementing DRM at target device 104 is to follow these rules to access the content.

These rules may be included in a variety of different licenses, including an independent license, a portion of a chain of licenses (e.g., a leaf license or a root license), a license for the target device, a license for a domain of which the target device is a part, and so forth. When one or more rules are included in a license, the rules remain with the license whenever the license is stored or copied to another device. Alternatively, once the license is stored based on the one or more rules, the one or more rules may be deleted from the license.

Table I describes examples of one or more rules that may be included in a license. It will be appreciated that these are merely examples, and that in some embodiments none of these rules may be used, and in other embodiments different and/or additional rules may be used.

TABLE I

It should be noted that in some cases, storing the license in the one or more locations identified by the rule has already occurred. For example, assume that the target device receives content having an embedded license that includes copy rules. In this example, the target device may store the license in its license store when it is received, but the target device does not have to store the license in the content because the license is already embedded in the content.

FIG. 6 is a flow diagram illustrating an example process 600 for using embedded license rules. Process 600 may be implemented in software, firmware, hardware, or a combination thereof. The acts of process 600 shown on the left side of fig. 6 are performed by a target device, such as target device 104 of fig. 1. The acts of process 600 shown on the right side of fig. 6 are performed by a license source device, such as source device 102 of fig. 1. Process 600 is an example process for using license rules; additional discussion of usage license rules is included herein with reference to different figures.

Initially, the target device generates a request for a license for accessing content (act 602). The license source device receives this request (act 604) and determines whether to grant the requested license (act 606). As described above, this determination in act 606 can be made in a variety of different manners, such as based on whether an appropriate fee has been paid, whether the target device from which the request was received is part of a domain permitted to receive the license, and so forth. If the target device is not permitted to have the requested license, the request is denied (act 608). This rejection may optionally include returning an indication to the target device that the request has been rejected.

However, if the target device is permitted to possess the requested license, a license having one or more rules regarding where to store the license is generated (act 610) and sent to the requesting target device (act 612). The target device receives the license with the one or more rules and stores the license based at least in part on the one or more rules in the received license (act 616). As noted above, any of a variety of different rules may be included in the license.

Thus, it can be seen that the embedded license for content discussed herein can be used in a variety of different ways. By embedding the license, the content and the corresponding license can be easily transferred between the various devices, while the DRM is still adapted to allow only those devices authorized by the license or licenses corresponding to the particular content to access the particular content. Furthermore, by embedding a license, additional access to other devices may be avoided. For example, a number of songs (or other content) may be copied to a portable device such as a cellular telephone and played back based on a license embedded in the songs, thereby freeing the cellular telephone from having to incur access time and charges for accessing a server to obtain a license for playing back the number of songs.

FIG. 7 illustrates an example computing device 700 that can be configured to implement embedded licenses for content in accordance with one or more embodiments. The computing device 700 may be, for example, the target device 104 or the source device 102 of fig. 1.

Computing device 700 includes one or more processors or processing units 702, one or more computer-readable media 704 which can include one or more memory and/or storage components 706, one or more input/output (I/O) devices 708, and a bus 710 that allows the various components and devices to communicate with one another. The computer-readable media 704 and/or the I/O device 708 can be included as part of the computing device 700 or alternatively can be coupled to the computing device 700. Bus 710 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processor or local bus using a variety of different bus architectures, and so forth. Bus 710 can include wired and/or wireless buses.

Memory/storage component 706 represents one or more computer storage media. Component 706 can include volatile media (such as Random Access Memory (RAM)) and/or nonvolatile media (such as Read Only Memory (ROM), flash memory, optical disks, magnetic disks, and so forth). Component 706 can include fixed media (e.g., RAM, ROM, a fixed hard drive, etc.) as well as removable media (e.g., a flash memory drive, a removable hard drive, an optical disk, and so forth).

The techniques discussed herein may be implemented in software with instructions being executed by processing unit 702. It is to be appreciated that different instructions can be stored in different components of computing device 700, such as in processing unit 702, in various cache memories of processing unit 702, in other cache memories of device 700 (not shown), on other computer readable media, and so forth. Additionally, it is to be appreciated that the location where instructions are stored in computing device 700 can change over time.

One or more input/output devices 708 allow a user to enter commands and information to computing device 700, and also allow information to be presented to the user and/or other components or devices. Examples of input devices include a keyboard, a cursor control device (e.g., a mouse), a microphone, a scanner, and so forth. Examples of output devices include a display device (e.g., a monitor or projector), speakers, a printer, a network card, and so forth.

Various techniques may be described herein in the general context of software or program modules. Generally, software includes routines, programs, objects, components, data structures, and so forth that perform particular tasks or implement particular abstract data types. An implementation of these modules and techniques may be stored on or transmitted across some form of computer readable media. Computer-readable media can be any available media or media that can be accessed by a computer. By way of example, and not limitation, computer-readable media may comprise "computer storage media" and "communication media".

"computer storage media" include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by a computer.

"communication media" typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism. Communication media also includes any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above are also included within the scope of computer readable media.

In general, any of the functions or techniques described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or a combination of these implementations. The terms "module," "functionality," and "logic" as used herein generally represent software, firmware, hardware, or a combination thereof. In the case of a software implementation, the module, functionality, or logic represents program code that performs specified tasks when executed on a processor (e.g., CPU or CPUs). The program code can be stored in one or more computer readable memory devices, further description of which may be found with reference to FIG. 7. The various features of the techniques for embedded licenses for content described herein are platform-independent, meaning that the techniques may be implemented on a variety of commercial computing platforms having a variety of processors.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims (7)

1. A method for embedded licenses for content, comprising:

receiving a request for a license for accessing content from a device (604); and

sending (612) the requested license to the device, the requested license including one or more rules indicating where the license is to be stored by the device, the one or more rules including a move rule indicating that the license is to be stored in a license store of the device and subsequently embedded in the content when the content becomes available.

2. The method of claim 1, wherein the one or more rules include an ignore rule indicating that the license is not to be embedded in the content but can be stored in a license store of the device.

3. The method of claim 1, wherein the one or more rules include a copy rule that indicates that the license is to be embedded in the content and is also stored in a license store of the device.

4. The method of claim 1, wherein the one or more rules include a license unrecoverable rule indicating to the device that the device is not allowed to recover the license if the device loses the license.

5. The method of claim 1, wherein the license includes a policy identifying one or more actions that can be taken on the content, and a cryptographic key to be used by the device to decrypt the content.

6. The method of claim 1, further comprising the device receiving the requested license and storing the requested license based at least in part on the one or more rules.

7. The method of claim 1, wherein the requested license is usable by a plurality of different types of devices from one or more different domains to access the content.