WO2006129225A2

WO2006129225A2 - Flexible domain policy distribution

Info

Publication number: WO2006129225A2
Application number: PCT/IB2006/051609
Authority: WO
Inventors: Robert P. Koster; Franciscus L. A. J. Kamperman
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2005-05-31
Filing date: 2006-05-19
Publication date: 2006-12-07
Also published as: WO2006129225A3

Abstract

The present invention relates to a method and a system of distributing domain policy enforcement to at least one target device (103, 104, 105, 106) in an authorized domain (101). A basic idea of the present invention is to distribute at least a part of an authorized domain policy in an authorized domain by distributing data representing at least part of the domain policy from one AD device to another, which another device is arranged to execute at least part of the domain policy. The domain policy governs AD management and may be divided in different parts, and devices typically enforce only a part of the complete domain policy. Further, a user authentication token may also enforce a part of the domain policy. Hence, the domain policy (or parts of it) may be distributed among other types of devices than AD devices, for example among user authentication tokens. The present invention is advantageous since it enables a rights issuer, which typically is a content provider, and an ADM, also known as domain manager (107) or domain issuer, to share the responsibilities of managing ADs and issuing rights, since a non- fixed domain policy is prescribed.

Description

Flexible domain policy distribution

The present invention relates to a method and a system of distributing domain policy enforcement to at least one target device in an authorized domain.

In prior art authorized domain (AD) systems, domain policy - i.e. rules governing the domain composition such as device domain membership - is typically fixed. Hence, in a digital rights management (DRM) environment supporting an AD concept, the domain policy is static and content items such as movies, digital books and audio files, which are brought into the AD, are accessible from a limited number of compliant devices. Hence, the domain policy may be that a maximum number N of compliant devices are allowed in the domain. Compliant devices are devices which are trusted and adhere to the general AD/DRM compliance rules. The term "compliant" also implies that a device is capable of enforcing certain policy aspects that are valid for a particular class of devices to which it belongs. As will be described in the following, a number of different types of devices exist, for example AD manager devices, AD devices, user authentication tokens, etc. A domain member, i.e. a domain device, is a device (typically an AD device) that is registered to the domain and is thereby - per definition - considered compliant.

Various proposals exist that implement the concept of authorized domains to some extent. In so-called device based ADs, the domain is formed by a specific set of devices and content. A domain manager, which can be one or more of the devices, a smart card or another device, controls which devices may join the domain. Only the specific set of devices of the domain is allowed to make use of the content of that domain, e.g. to open, copy, play or export it. Examples of such device-based ADs are given in international patent application WO 03/098931 (attorney docket PHNL020455) and international patent application WO 04/027588 (attorney docket PHNL030283) by the same applicant. A device based AD allows a set of devices bound to a domain to access content bound to that domain. This double binding assures that all the devices in the AD can access the content. Alternatively, the content may be directly bound to one device. Another type of AD is the so-called person based Authorized Domains, where the domain is based on persons instead of devices. An example of such a system is described in international patent application WO 04/038568 (attorney docket PHNL021063) by the same applicant, in which content is coupled to persons, which then are grouped into a domain. For instance, the content may be bound to a person and a number of persons, e.g. all the members of one family, grouped into an authorized domain, and the content will be accessible on every suitable compliant device. The latter involves the step of a user of such a domain to authenticate to the device. Because devices are still required to process (e.g. render) and store content and licenses, they need to be compliant to guarantee that the content cannot be illegally exported from this DRM system.

Hybrid AD is characterized in that it ties content to a group that may contain devices and persons. This group is typically limited to a household, such that content can be watched on any of the devices that belongs to the household (e.g. TV in living room, TV in bedroom, PC, etc.) and such that content can be watched by any of the users that belong to the household after they have authenticated themselves on any device (such as a television in a hotel room). Such authentication normally involves a user authentication device such as a smart card. Examples of hybrid AD systems can be found in international patent application serial number PCT/IB2004/051226 (attorney docket PHNL030926) and in European patent application serial number 04101256.8 (attorney docket PHNL040315). PED (Private Entertainment Domain) AD-DRM can be seen as a variant of hybrid AD with the main difference that the domain only contains a single user. Content is bound to the single user. The single user may have a set of permanent AD devices as domain devices. Content may be rendered permanently on the domain devices and may also be rendered temporarily on other devices after user authentication. The latter devices are called temporary domain devices, since the authentication session expires after a set time period. After expiration, no access to domain content is possible on the temporary domain devices. Preferably, user authentication is done using a user authentication device. A typical PED implementation combines an AD manager device with user authentication device.

In Open Mobile Alliance (OMA) DRMv2, an AD system is limited to include a number of compliant devices. A domain policy typically at least consists of a maximum number of devices per domain. The maximal allowed number is definable by a rights issuer who manages both the domain and issues rights. DRM rights or licenses for content items typically indicate what type of access a user has to the content item. For example, in case the content item is an audio file, whether the user can play, copy or distribute the file, how many times the file can be played, if the file is valid for a predetermined time period etc. DRM rights are distributed from content providers to devices which are to render a content item with which the rights are associated. The huge number of different types of rights offers flexibility to content providers and allow them to implement their business models in the DRM systems in which the rights are employed.

The rights issuer decides in OMA DRMv2 which access possibilities are given to users (or in practice to the device operated by the user) of content items. However, if the rights issuer - i.e. the content provider - wishes to share or delegate the responsibility of managing the authorized domain and issuing rights (e.g. with the AD itself via an AD manager), it is preferred that the AD system does not prescribe a fixed domain policy. Today, the domain policy is however fixed, which is a problem that the present invention overcomes. It should be noted that the domain policy and domain composition (i.e. which devices are members of the domain) are not part of the actual DRM right/license in pure AD systems. One reason for this is that the domain policy and/or composition may change after issuing of a license for the concerned AD. Another reason is that the use of a consistent domain for all content items simplifies management at the user side. Further, domain policy may be determined and enforced by another party than the actual issuer of the DRM rights. As mentioned in the above, domain policy is typically hard-coded into a device or a server on which the domain policy is to be enforced. The present invention may further advantageously be applied when distributing DRM software updates (e.g. iTunes/Fairplay or Windows Media Player/WM DRM) and firmware updates (e.g. for an MP3 player). These software updates may be employed to update DRM software and hard-coded domain policies that are part of it. The main disadvantage of prior art approaches are that they are very coarse, since they only enable "all or nothing"-updates. The process of carrying out the updating of all devices of a user becomes rather cumbersome, since the user herself has to perform the update. Consequently, flexibility is limited. With the present invention, these disadvantages are overcome.

An object of the present invention is to overcome the above given problems in the prior art by means of enabling distribution of data representing domain policy from one authorized domain manager (ADM) device to another device to be registered, or which already is registered, in the authorized domain supervised by the ADM device. Further, it is an object of the present invention to enable distribution of data representing domain policy from one device not being an ADM device to another device not being an ADM device within the concerned authorized domain. Moreover, the domain policy data may be distributed among ADM devices. These objects are attained by a method of distributing domain policy enforcement in an authorized domain in accordance with claim 1, and a system for distributing domain policy enforcement in an authorized domain in accordance with claim 9. According to a first aspect of the present invention, there is provided a method of distributing domain policy enforcement in an authorized domain, which comprises the steps of sending data, which defines the domain policy, to at least one target device arranged to execute at least part of the domain policy, storing the domain policy data at the at least one target device and enforcing, at the at least one target device, at least part of the domain policy defined by the stored data.

According to a second aspect of the present invention, there is provided a system comprising a domain managing device and at least one target device to which the domain policy is distributed, which device is arranged to execute at least part of the domain policy. The managing device comprises means for sending data, which defines the domain policy, to said at least one target device and the target device comprises means for storing the domain policy data and means for enforcing the domain policy defined by the stored data. A basic idea of the present invention is to distribute at least a part of an authorized domain policy in an authorized domain by distributing data representing at least part of the domain policy from one AD device to another, which another device is arranged to execute at least part of the domain policy. Hence, the device to which a domain policy is distributed should be able to execute at least the part of the domain policy which is distributed. At the time of distribution of domain policy, the policy-receiving device may be blank, i.e. it is arranged with means to receive and execute the policy but it is not yet in possession of an actual policy to enforce. The domain policy may differ per domain and consequently, the domain policy may differ per content item if content items belong to different domains. Devices are not blank anymore upon reception of (parts of) a domain policy.

The domain policy governs AD management and may be divided in different parts, and devices typically enforce only a part of the complete domain policy. When enforcing domain policy, different types of devices generally enforce different parts of the complete policy, although each device very well may hold data corresponding to the complete domain policy data. An ADM typically controls admission/registration to the AD, wherein different policy parameters may have to be complied with for registration to take effect. For example, domain policy may prohibit that a maximum number of domain devices is exceeded. Another requirement that may have to be satisfied for registration to take effect is that the device to be registered in the AD is in proximity (e.g. within 3 meters) to an authentication token, for instance in the form of a smart card, held by a user. In another example, the domain policy may prescribe how many domains one single device is allowed to be a member of. In a further example, it prescribes the rate at which a device may enter and exit a domain. In yet a further example, different domain policies is enforced for different classes of devices; for instance, a first policy for ADM devices, a second policy for AD devices, a third policy for user authentication tokens, etc. Clearly, a person skilled in the art may envisage a number of parameters that must be complied with.

An AD device is typically a rendering or storing device. Different types of domain policies (i.e. domain policy parameters to be satisfied) that may be enforced by AD devices are e.g. "maximum number of user authentications per time unit", "maximum number of (de)registration operations", "maximum number of domain memberships for the AD device", "length of authentication sessions", "maximum number of license transfers per time unit", etc. Further, the user authentication token mentioned hereinabove may also enforce a part of the domain policy, for instance "allowed number of authentications per time unit". Hence, the domain policy (or parts of it) may be distributed among other types of devices than AD devices, for example among user authentication tokens.

The distribution of the domain policy may be undertaken along with distribution of other AD related items, which items may comprise physical articles as well as more abstract item such as data and information, e.g. domain membership tokens, domain keys, ADM devices etc.

The AD policy may also be employed by a rendering device, for example a portable CD player. The rendering device determines whether content items may be accessed, including enforcement of DRM rights/licenses (e.g. view a movies three times before a predetermined dater) and domain policy. For instance, the domain policy may be to allow rendering by all devices comprised in the domain and by any authorized AD user that has been authenticated the last thirty minutes. When the domain policy is to be distributed to a device, in the following also referred to as a target device, the distributor may verify whether the device is a compliant AD device that supports the required domain policy enforcement mechanisms. If this is case, data defining the domain policy is sent to the target device. Note that a target device may be any type of appropriate device to which policy data is distributed, for instance an AD device, an ADM device or an authentication token (e.g. in the form of a smart card).

This can either be done for a device which is already registered in the AD, or a device which is not yet registered in the AD. A typical example of the latter case may be that the AD manager is the distributor and further registers the device in the AD. Thereafter, the domain policy data is stored at the target device, which then enforces the domain policy defined by the stored data.

The present invention is advantageous since it enables a rights issuer, which typically is a content provider, and an ADM, also known as domain manager or domain issuer, to share the responsibilities of managing ADs and issuing rights, since a non- fixed domain policy is prescribed. By considering the different desires and requirements of the rights issuer and the ADM, and enabling combinations of these different desires and requirements, it is possible to support different business models based on different domain policies. This has the effect that it is possible to harmonize the different technical requirements that a rights issuer may have on the domain policy of a domain manager and vice versa, such that a flexible system as well as an easily adaptable flexible information exchange interface between the two parties may be provided.

The actual distribution of the domain policy may be effected in a number of different manners. In an embodiment of the present invention, a smart card may be arranged to be the authorized domain manager (ADM). Hence, the ADM smart card is pre-configured with a certain domain policy, and is typically bought by a user with that certain configuration. When an ADM is employed to register a target device, the domain policy is, as described in the above, transferred to the target device, typically being some type of rendering device, e.g. a DVD player. In yet another embodiment of the invention, the rendering device may in its turn transfer the domain policy to other compliant target devices. It is further possible that the domain policy is distributed over e.g. the Internet by a rights issuer, for instance in a system where AD management is primarily done at a (remotely located) server. When a target device receives domain information, e.g. a cryptographic domain key, from the server after registration, it may further receive the domain policy, which the target device is adapted to enforce.

Further, there are different options regarding the form in which the domain policy is distributed. In an embodiment of the present invention, the domain policy data comprises a string indicating domain rules, e.g. "MAX n DEVICES, USER AUTHENTICATION VALID FOR y MINUTES". In another embodiment, the domain policy data comprises executable software code such as e.g. Java, which implements AD management related functions for a certain domain policy.

In a further embodiment of the present invention the domain policy data is cryptographically signed, wherein a target device can verify correctness of a digital signature provided to the domain policy data, since there may be strong requirements that the authenticity of the domain policy can be trusted. This ensures that a target device enforces the correct and trusted domain policy for a content item, and it further allows for the fact that a content provider may trust a domain policy issuer and accept the particular domain policy, when the content provider sells a content item, and thus enters the content item in a certain domain. Possibly, further cryptographic features are employed. For instance, a hash value may be calculated for the domain policy data and distributed to the target device along with the actual data to provide the domain policy data with integrity.

Further features of, and advantages with, the present invention will become apparent when studying the appended claims and the following description. Those skilled in the art realize that different features of the present invention can be combined to create embodiments other than those described in the following.

Preferred embodiments of the present invention will be described in detail with reference made to the accompanying drawings, in which:

Fig. 1 shows an authorized domain in which the present invention is advantageously employed.

Fig. 1 shows a Private Entertainment Domain (PED) AD-DRM system 101. This type of system is characterized in that an individual 102, who has a number of devices 103, 104, 105 grouped in her domain may access (step 1) content items on all her domain devices without authentication and on any other device 106 after the individual has authenticated (step 2) herself to that particular device. The compliant devices 103, 104, 105 and 106 are also referred to herein as target devices. The individual typically has a smart card 107 that can be used as an authentication token. Possibly, the smart card also functions as an authorized domain manager (ADM) device. By means of the ADM smart card, the individual may register a number of devices to the domain. Content items in PED AD-DRM are typically bound to the individual. In general, in a PED AD implementation, the maximum number of devices allowed in the AD is hard-coded in the ADM smart card. Moreover, the authentication procedure carried out between the device and the ADM smart card (i.e. the authentication token) is hard-coded into the smart card, including the time period for which an authentication session is valid without the individual having to effect a re-authentication. The individual typically buys an ADM smart card 107 that supports a specific domain policy, e.g. "PED AD with X devices and authentication sessions of Y minutes". A user may also buy another ADM smart card with another domain policy.

When an individual employs her ADM smart card to register new compliant devices to her AD, the ADM first verifies whether the device may be registered in the AD pursuant to the domain policy with which her smart card has been pre-configured. If the domain policy allows the device to be registered in the AD, the smart card registers the device in the AD and may send a domain membership certificate to the device. Then, the ADM smart card transfers the domain policy to the compliant device, which stores the policy. As previously mentioned, the domain policy to be enforced in this case may be that the time period during which authentication is valid has not expired to allow access to domain content. As a matter of fact, in an embodiment of the invention, the domain policy defining this authentication time period may be transferred to the compliant device from the authentication token as a part of the actual authentication, under assumption that an authentication token contain relevant parts of the domain policy and is arranged to transfer those to other devices.

Note that both the ADM smart card 107 and each device 103, 104, 105, 106 typically comprises a microprocessor 108, 109, 110, 111 and 112, respectively, or some other device with computing capabilities, for example an application specific integrated circuit (ASIC) or a filed-programmable gate array (FPGA). The steps defined in the method of the present invention are typically performed by the respective microprocessor, each microprocessor executing appropriate software for performing these steps. Also note that a network, e.g. the Internet, may interconnect the devices 103, 104, 105 in the AD 101.

Whenever the individual 102 wishes to buy a content item, and bring it into the AD 101 with which she is associated, she informs (step 3) a content provider 113 about the domain policy that prevails in the concerned AD. This is an effect of a flexible domain policy; the content provider 113 must himself determine if the domain policy complies with the business model he wants to support. For instance, in ADs for which the domain policy defines a great number of possible users, a greater amount of money may have to be paid for a content item, as compared to an AD which allows a smaller number of users.

As a consequence, the device that is employed to buy the content item sends the domain policy (or a domain policy identifier on condition that the content provider is familiar with different types of predetermined domain policies). The content provider 113 is typically remotely located from the individual 102, which implies that a network, e.g. the Internet, is used to connect the content provider 113 and the individual 102 (or in practice the device used by the individual to enter the purchased content item into the AD).

When the individual 102 authenticates herself to a device by means of her smart card 107, the authentication is valid for a predetermined time period of e.g. 30 minutes. The smart card and the device can be brought into contact with each other in a number of different ways, e.g. via a wireless connection such as infrared light, Near Field Connectivity (NFC) or Bluetooth, or the device may be arranged with a card reader to extract necessary information from the smart card. In case the individual 102 performs an authentication (step 2) with a device 106 that is not part of the AD 101 , at least part of the domain policy is transferred from the ADM smart card 107 to the device 106, namely the validity period of authentication sessions.

When a content item is to be accessed on a device, the device determines whether the access is allowed for that particular content item. This is typically performed by evaluating the DRM right that is associated with the content item, which right specifies which type of access an individual has to the content item (e.g. play, copy, distribute, etc.). Further, in a PED AD, the ADM smart card verifies whether the device on which the content item is to be accessed is a member of the particular AD and/or that there is a valid authentication session established between the smart card and the device. As previously mentioned, the domain policy may be distributed in many forms. In an embodiment of the present invention, the domain policy data comprises a string indicating domain rules, e.g. "MAX n DEVICES, USER AUTHENTICATION VALID FOR y MINUTES". In another embodiment, the domain policy data comprises executable software code such as e.g. Java, which implements AD management related functions for a certain domain policy. Hence, for above mentioned functions such as devices registration, purchasing of content items, authentication, content item access etc., the executable Java code is invoked and handles the enforcement of the domain policy and forwarding of information.

Currently, a number of DRM systems with server-based authorized domains exist, e.g. Apple's Fairplay or OMA DRMv2. In Fairplay, a user has an account at a server and may authorize up to five personal computers that is allowed to render content items of the user. Further, the content items of the user may be stored and rendered on an unlimited number of iPODs. In OMA DRMv2, a rights issuer (i.e. a content provider) may register a number of devices to the AD associated with a user. The rights issuer can decide and enforce the domain policy himself. In both systems, ADM functionality, e.g. registering and authorizing compliant devices, resides at the server. Hence, with reference made to Fig. 1, the server 113 would be considered to be the authorized domain manager, instead of the smart card 107.

Currently, there is no flexibility in domain policy for the AD devices in these server-based systems. However, it is envisaged that both systems may be modified in such a way that it enables domain policy flexibility for the compliant devices. For instance, in Fairplay, the number of iPODs could be arranged to be dynamic. When a user opens a Fairplay account at a content provider, she may choose the number of iPODs to be allowed within her AD. Hence, the user has created a domain policy to be enforced. This domain policy is then sent to the devices to be included in the AD when they are authorized by the ADM, e.g. by means of a smart card of the user or via a service on a server on the Internet. Subsequently, the devices will enforce the domain policy set by the user. OMA DRMv2 may also be modified such that it complies with PED functionality. That is, OMA DRMv2 may be modified such that it not only supports device-based access, but also content-based access by authentication with a user token. The rights issuer can set the domain policy to be enforced. During registration, the ADM service running on the server sends a parameter defining the authentication session length to the compliant devices within the concerned AD, which devices subsequently enforce the policy. Alternatively, the parameter defining the authentication session length could be first transferred from the ADM service to the user authentication token when the user registers the token to the ADM service, and secondly be forwarded from the user authentication token to a device as part of an authentication. Further, the domain policy may be acquired by the authentication token in that the token is preconfigured with at least a part of the domain policy and that the authentication token is able to enforce the domain policy. Even though the invention has been described with reference to specific exemplifying embodiments thereof, many different alterations, modifications and the like will become apparent for those skilled in the art. The described embodiments are therefore not intended to limit the scope of the invention, as defined by the appended claims.

Claims

CLAIMS:

1. A method of distributing domain policy enforcement in an authorized domain (101), said method comprising the steps of: sending data, which defines the domain policy, to at least one target device (103, 104, 105) arranged to execute at least part of the domain policy; storing the domain policy data at said at least one target device; and enforcing, at said at least one target device, at least part of the domain policy defined by the stored data.

2. The method according to claim 1, further comprising the step of: verifying that the at least one target device (103, 104, 105) is a compliant authorized domain device.

3. The method according to claim 1 or 2, further comprising the step of: registering said at least one target device (103, 104, 105) in the authorized domain (101).

4. The method according to any one of claims 1-3, further comprising the step of: forwarding the domain policy data from said at least one target device (103,

104, 105) to further target devices within the authorized domain (101).

5. The method according to any one of the preceding claims, wherein an authorized domain manager (107) is preconfigured with the domain policy and is arranged to send the domain policy data to said at least one target device (103, 104, 105).

6. The method according to any one of the preceding claims, wherein an authentication device (107) is stored with the domain policy and is arranged to send the domain policy data to said at least one target device (103, 104, 105).

7. The method according to any one of the preceding claims, wherein the domain policy data comprises executable software code.

8. The method in accordance with any one of the preceding claims, further comprising the step of: informing a content provider (113), from which a content item is acquired, which particular domain policy is employed in the authorized domain (101) in which the content item is entered.

9. A system for enabling distribution of domain policy enforcement in an authorized domain (101), said system comprising; a domain managing device (107); and at least one target device (103, 104, 105) to which the domain policy is distributed, which device is arranged to execute at least part of the domain policy; said managing device comprising: means (108) for sending data, which defines the domain policy, to said at least one target device; and said target device comprising: means (109, 110, 111) for storing the domain policy data; and means (109, 110, 111) for enforcing the domain policy defined by the stored data.

10. The system according to claim 9, further comprising: means (108) for verifying that said at least one target device (103, 104, 105) is a compliant authorized domain device.

11. The system according to claim 9 or 10, wherein the domain managing device (107) further comprises: means (108) for registering said at least one target device (103, 104, 105) in the authorized domain (101).

12. The system according to any one of claims 9-11, wherein the domain managing device (107) is further arranged to be preconfigured with the domain policy.

13. The system according to any one of claims 9-12, wherein the domain managing device comprises a smart card (107).

14. The system according to any one of claims 9-13, wherein said at least one target device (103, 104, 105) is arranged to forward the domain policy data to further target devices within the authorized domain (101).

15. The system according to any one of claims 9-14, wherein the domain policy data comprises executable software code.

16. The system in accordance with any one of claims 9-15, wherein an authentication device is used for authenticating an individual (102) at a target device (103, 104, 105, 106), said authentication device being arranged to acquire and enforce at least part of the domain policy.

17. The system in accordance with any one of claims 9-16, wherein an authentication device is used for authenticating an individual (102) at a target device (103, 104, 105, 106), said authentication device being arranged forward at least part of the domain policy.

18. The system in accordance with any one of claims 9-17, wherein any device (107, 103, 104, 105) comprised in the system further comprises: means (108, 109, 110, 111) for informing a content provider (113), from which a content item is acquired, which particular domain policy is employed in the authorized domain (101) in which the content item is entered.

19. The system in accordance with any one of claims 9-18, wherein said at least one target device (103, 104, 105) is a rendering or storage device.

20. A computer program product comprising computer-executable components for causing a device (107, 103, 104, 105, 106) to perform the steps recited in any one of claims 1-8 when the computer-executable components are run on a processing unit (108, 109, 110, 111, 112) included in the device.