An increasing number of devices (PC, CE, and mobile) contain some form of digital interconnectivity technology. For the (near) nature digital interconnect ivity technology will get more and more a ubiquitous character. We can safely assume that many devices in the home will get an Internet connection and also that mobile devices will be able to routinely access the Internet to communicate to servers or to communicate in a peer-to-peer (P2P) manner to other devices.

Digital interconnectivity and storage technologies enable the transfer and copying of data. As this also holds for commercial content, which typically comprises things like music, songs, movies, TV programs, pictures, games, books and the likes, but which also may include data related to interactive services, Digital Rights Management (DRM) systems are being increasingly employed to protect and enforce the rights of content owners.

An illustrative embodiment of a DRM system is illustrated in Fig. 1. To prevent unauthorized access to content, the content is encrypted and embedded in a so-called Content Container for which many standards exist, e.g. ISMACrypt or MPEG-2 Transport Stream as defined by DVB for conditional access. See

• ISMA, Internet Streaming Media Alliance implementation specification version 1, 28-8-2001.

• ISMA, ISMA 1.0 Encryption and Authentication, Version 1.0 Unapproved Draft, 2003. http://www.isma.tv • Digital Video Broadcasting (DVB); Support for use of scrambling and Conditional

Access (CA) within digital broadcast systems, ETR 289, ETSI, 1996. DVB.

• MPEG, Information Technology - Generic coding of moving pictures and associated audio information: Systems, ISO/IEC 13919-1: 1996(E), MPEG, 15-4-1996.

To decrypt the content a device will require the Content Key. Additionally there is Rights Expression, which specifies which identity may use the content and also how the content may be used. The identity specified in the Content Item could cither represent a device, a person or a group of devices and/or persons. Devices should comply with certain (security and other) requirements before they are entitled to access protected content. Such devices are commonly referred to as "compliant devices".

The combination of the Content Container, the Content Key and the Rights Expression is in this document referred to as the Content Item (denoted 'C in subsequent figures).

Consumers want to enjoy content without hassle and with as few limitations as possible. They want to network their devices to enable all types of different applications and easily access any type of content. They also want to be able to share/transfer content in their home environment without limitations.

The concept of Authorized Domains (ADs) tries to find a solution to both serve the interests of the content owners (that want protection of their intellectual property) and the content consumers (that want unrestricted use of the content). The basic principle is to have a controlled network environment in which content can be used relatively freely as long as it does not cross the border of the authorized domain. Typically, authorized domains are centered around the home environment, also referred to as home networks.

Of course, other contexts are also possible. A user could for example take a portable device for audio and/or video with a limited amount of content with him on a trip, and use it in his hotel room to access or download additional content stored on his personal audio and/or video system at home. Even though the portable device is outside the home network, it is a part of the user's authorized domain. In this way, an Authorized Domain (AD) is a system that allows access to content by devices in the domain, but not by any others.

For a more extensive introduction to the use of an Authorized Domain, etc., see S.A.F.A. van den Heuvel, W. Jonker, F.L.A.J. Kamperman, PJ. Lenoir, Secure Content Management in Authorised Domains, Philips Research, The Netherlands, IBC 2002 conference publication, pages 467-474, held at 12-16 September 2002. 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.

One type of AD, sometimes referred to as a device based AD is illustrated in Fig. 2. It 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. This structure is often established by implementing the bindings through a shared secret key. This key is chosen by a domain manager and distributed to all the devices in the domain. When content is bound to the domain, the license is cryptographically linked to the domain by means of encryption with the shared key.

Alternatively the content may be directly bound to one device, as illustrated in Fig. 3. As can be seen the devices remain bound to the AD.

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.

In Fig. 4 is shown a configuration with the content bound to a person and a number of persons, e.g. all the members of one family, grouped into an authorized domain. We now assume that the content will be accessible on every suitable compliant device and therefore they are missing in the figure because for the purpose of this model all compliant devices are equal. We note that, 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. A so-called Hybrid Authorized Domain-based DRM system ties content to a group that may contain devices and persons. This group is typically limited to a household, such that:

1. content can be watched on any of the devices that belongs to the household

(e.g. TV in Living, TV in Bedroom, PC) 2. 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/TB2004/051226 (attorney docket PHNL030926) and in European patent application serial number 04101256.8 (attorney docket PHNL040315).

Content protection systems, especially those set up as some form of Authorized Domain, normally involve protected communication between devices based on some secret, only known to devices that were tested and certified to have secure implementations. Knowledge of the secret is tested using an authentication protocol. The best

solutions for these protocols are those that employ public key cryptography, which use a pair of two different keys. The secret to be tested is then the secret key of the pair, while the public key can be used to verify the results of the test. To ensure the correctness of the public key and to check whether the key-pair is a legitimate pair of a certified device, the public key is accompanied by a certificate, which is digitally signed by a Certification Authority (CA), the organization that manages the distribution of public/private key-pairs for all devices. Everybody knows the CA's public key and can use it to verify the CA's signature on the certificate. In a simple implementation the public key of the CA is hard-coded into the implementation of the device. To enable this process each hardware device or software application (referred to collectively as devices hereafter) holds a number of secret keys, sometimes also known as private keys. These keys and the control flow using these keys should be well protected, for knowledge of these keys or manipulation of the control flow would allow hackers to circumvent the content protection systems. In typical security scenarios, there are several different devices involved, which might not all be implemented with equal levels of tamper proofing. Such a system should therefore be resistant to the hacking of individual devices, which might enable illegal storing, copying and/or redistribution of digital content. However, it is likely that during the lifetime of a product type that makes use of the system, some or even many devices will get hacked in some way.

An important technique to increase the resistance is the so-called revocation of these hacked devices. This requires all devices to read a so-called Certificate Revocation List (CRL), a list allowing identification of revoked devices. Compliant devices are forced in some manner to possess an up-to-date CRL, and they should never pass content to devices that are listed as revoked in the CRL. The CA generates and distributes new CRLs whenever necessary.

Revocation can be indicated in several different manners. Two different techniques are so-called black lists (a list of revoked devices) and white lists (a list of un- revoked devices). Devices are identified on the blacklist or the white list by a unique identifier, such as a serial number. A device may have a unique identifier installed in the factory. This globally unique identifier can then be listed in the CRL. Alternatively an authorized domain manager device may assign unique identifiers to devices as they join the authorized domain.

These identifiers can be used in a CRL to be used in the authorized domain (sometimes called a "local CRL") instead of globally unique identifiers.

A typical problem with blacklist-based approaches is that each device has to store the blacklist or has to have communication means to check or retrieve the blacklist. In CE devices this is often not a viable solution and therefore the whitelist approach is preferred. Now each device gets an authorization certificate in which is declared that the device is still compliant. The latter is small enough such that a device can store it. However, a device now has to renew its authorization certificate every now and then from the authority that issues those. The latter is difficult for devices that do not directly contact such authorities, for example because they have limited connectivity or because they operate most of the time without a connection to an authority.

In one aspect, the invention provides an authorized domain system comprising a plurality of devices including at least one retrieval device, in which the retrieval device is configured to retrieve revocation status information for two or more devices comprised in the domain and to distribute the retrieved revocation status information to one or more devices with which the retrieval device is in contact.

In this manner, it is realized that not all devices need a connection to an authority that provides the revocation status information. Such status information may be provided using the blacklist or whitelist approach discussed above. Preferably it comprises a range of non-revoked devices.

The retrieval device may retrieve revocation status information for some or all of the devices comprised in the domain. Optionally the retrieval device is configured to retrieve revocation status information for one or more devices in the domain that it has learned are a member of the domain. For instance, these one or more devices may have previously requested the retrieval device to retrieve content, or the retrieval device has recently communicated with these one or more devices. The domain may comprise devices that expect different types of revocation status information, for example because they are configured to use different content protection mechanisms. It is likely that a device that requests content from the retrieval device (which is in a particular format) is also able to handle revocation status information provided by this same retrieval device.

In an embodiment a first device comprised in the domain that has received the retrieved revocation status information is configured to distribute the retrieved revocation status information to a second device comprised in the domain, for example as part of setting up a secure authenticated channel with said one or more devices. This provides a mechanism for distributing the revocation status information amongst the devices in the domain. It is now not necessary for the retrieval device (or another central device or management device) to distribute the status information directly to that second device.

The revocation status information may be bundled with an updated version of a list of device identifiers that is to be distributed to the devices in the domain. Such bundling can be effected in many ways e.g. by including the revocation status information in a data structure containing this updated version of the list, or by transmitting it in the same session as the one used to transmit this updated version of the list.

The revocation status information may comprise a plurality of certificates, each identifying one or more devices that have not been revoked. A device then normally sends, as part of the authentication procedure, only the certificate that identifies this device itself. The device receiving this certificate may compare a version number associated with this certificate against a version number of a certificate it received and stored earlier. If this certificate is newer than the stored certificate, the receiving device may request the sending device to send some or all of the certificates in possession of the sending device. A receiving device may request to send all certificates that are newer than the stored certificate. A receiving device may also request only that certificate which is newer than the stored certificate and which identifies the receiving device. This option is especially advantageous for receiving devices with limited storage capacity, although it does limit the speed at which the revocation status certificates are distributed throughout the domain. Instead of a version number, a creation date can be used. Preferably the retrieval device is configured to retrieve the revocation status information in conjunction with a purchase transaction. For example, the revocation status information can be retrieved from a server facilitating the purchase transaction, or from a different server of course. By combining the purchase transaction and the act of retrieval of the revocation status information, it is achieved that this information is not needlessly retrieved.

These and other aspects of the invention will be apparent from and elucidated with reference to the illustrative embodiments shown in the drawings, in which: Fig. 1 schematically shows an illustrative embodiment of a DRM system;

Fig. 2 schematically shows an authorized domain structure with devices bound to a domain and content bound to that domain;

Fig. 3 schematically shows an authorized domain structure with content bound to devices and devices bound to that domain; Fig. 4 schematically shows an authorized domain structure with content bound to a person and persons bound to a domain;

Fig. 5 schematically shows a system comprising devices interconnected via a network;

Fig. 6 schematically shows an embodiment of an AD system; Fig. 7 schematically shows this embodiment in more detail; and

Fig. 8 schematically shows major building blocks for this embodiment. Throughout the figures, same reference numerals indicate similar or corresponding features. Some of the features indicated in the drawings are typically implemented in software, and as such represent software entities, such as software modules or objects.

Fig. 5 schematically shows a system 100 comprising devices 101-105 interconnected via a network 110. A typical digital home network includes a number of devices, e.g. a radio receiver, a tuner/decoder, a CD player, a pair of speakers, a television, a VCR, a digital recorder, a mobile phone, a tape deck, a personal computer, a personal digital assistant, a portable display unit, and so on. These devices are usually interconnected to allow one device, e.g. the television, to control another, e.g. the VCR. One device, such as e.g. the tuner/decoder or a set top box (STB), is usually the central device, providing central control over the others.

The system 100 may be an in-home network that operates as an Authorized Domain. In this kind of content protection systems (like SmartRight from Thomson, or DTCP from DTLA) a set of devices can authenticate each other through a bi-directional connection. Based on this authentication, the devices will trust each other and this will enable

them to exchange protected content. In the licenses accompanying the content, it is described which rights the user has and what operations he/she is allowed to perform on the content. Some particular architectures of authorized domains have been outlined in international patent application WO 03/098931 (attorney docket PHNL020455), European patent application serial number 03100772.7 (attorney docket PHNL030283), European patent application serial number 03102281.7 (attorney docket PHNL030926), European patent application serial number 04100997.8 (attorney docket PHNL040288) and F. Kamperman and W. Jonker, P. Lenoir, and B. vd Heuvel, Secure content management in authorized domains, Proc. IBC2002, pages 467-475, Sept. 2002. Authorized domains need to address issues such as authorized domain identification, device check-in, device check-out, rights check-in, rights check-out, content check-in, content check-out, as well as domain management.

Content, which typically comprises things like music, songs, movies, TV programs, pictures, games, books and the likes, but which also may include interactive services, is received through a residential gateway or set top box 101. Content could also enter the home via other sources, such as storage media like discs or using portable devices. The source could be a connection to a broadband cable network, an Internet connection, a satellite downlink and so on. The content can then be transferred over the network 110 to a sink for rendering. A sink can be, for instance, the television display 102, the portable display device 103, the mobile phone 104 and/or the audio playback device 105.

The exact way in which a content item is rendered depends on the type of device and the type of content. For instance, in a radio receiver, rendering comprises generating audio signals and feeding them to loudspeakers. For a television receiver, rendering generally comprises generating audio and video signals and feeding those to a display screen and loudspeakers. For other types of content a similar appropriate action must be taken. Rendering may also include operations such as decrypting or descrambling a received signal, synchronizing audio and video signals and so on.

The set top box 101, or any other device in the system 100, may comprise a storage medium Sl such as a suitably large hard disk, allowing the recording and later playback of received content. The storage medium Sl could be a Personal Digital Recorder (PDR) of some kind, for example a DVD+RW recorder, to which the set top box 101 is connected. Content can also enter the system 100 stored on a carrier 120 such as a Compact Disc (CD) or Digital Versatile Disc (DVD).

The portable display device 103 and the mobile phone 104 are connected wirelessly to the network 110 using a base station 111, for example using Bluetooth or IEEE 802.1 Ib. The other devices are connected using a conventional wired connection. To allow the devices 101-105 to interact, several interoperability standards are available, which allow different devices to exchange messages and information and to control each other. One well- known standard is the Home Audio/Video Interoperability (HAVi) standard, version 1.0 of which was published in January 2000, and which is available on the Internet at the address http://www.havi.org/. Other well-known standards are the domestic digital bus (D2B) standard, a communications protocol described in IEC 1030 and Universal Plug and Play (http://www.upnp.org).

It is often important to ensure that the devices 101-105 in the home network do not make unauthorized copies of the content. To do this, a security framework, typically referred to as a Digital Rights Management (DRM) system is necessary. One way of protecting content in the form of digital data is to ensure that content will only be transferred between devices 101-105 if

• the receiving device has been authenticated as being a compliant device, and

• the user of the content has the right to transfer (move and/or copy) that content to another device.

If transfer of content is allowed, this will typically be performed in an encrypted way to make sure that the content cannot be captured illegally in a useful format from the transport channel, such as a bus between a CD-ROM drive and a personal computer (host).

Technology to perform device authentication and encrypted content transfer is available and is called a secure authenticated channel (SAC). In many cases, a SAC is set up using an Authentication and Key Agreement (AKA) protocol that is based on public key cryptography. Standards such as International Standard ISO/IEC 11770-3 and ISO/IEC 9796- 2, and public key algorithms such as RSA and hash algorithms like SHA-I are often used.

At manufacturing time compliant devices receive an identity certificate that is used in the AKA to exchange the public keys of the devices. In a preferred embodiment, the compliant devices receive a second certificate called AuthorizationCertificate (AC), which declares that that device still belongs to the compliant set of devices. This way a white list- based solution is realized. A black list-based solution is also possible of course. Both certificates are verified for validity during SAC AKA.

The contents of the AC preferably consists of intervals of (still compliant) device identities and the total authorization list consists of one or more of such ACs. A device only needs to

store and exchange that AC, which contains the interval in which its device identity falls. This is well suited for embedded CE devices, as these devices have often strict and fixed storage requirements. See international patent application WO 03/107588 (attorney docket PHNL020543). European patent application serial number 04101104.0 (attorney docket PHNL040332) provides an improvement comprising generating a run-length encoded representation of an authorization status of a number of devices and storing the representation in the GC.

The authorization certificates are updated on a regular basis and new certificates are identified by means of a serial number, creation date or similar mechanism. This mechanism has as a drawback the chance that devices can be locked out of compliant communications, while in fact they are still compliant devices but with outdated authorization information. This drawback can be largely mitigated by employing efficient distribution strategies for the authorization lists.

In one embodiment of an AD system, which we will call Personal Entertainment Domain (PED) in the remainder of this document, one single person is member/owner of the domain. This embodiment is illustrated in Fig. 6. The content is bound to that person and a number of devices are bound to his domain. The content can be accessed on devices that belong to the PED. However, to facilitate location independence, content can still be accessed on all other compliant devices if a suitable user authentication has taken place.

An improvement is to allow devices to be part of multiple PEDs. As the number of devices in a PED is limited and content is kept bound to the person in the domain, we can still make sure that persons, who make use of the same devices, can share content

Fig. 7 shows how the domain/grouping functionality of PED AD-DRM can be organized. In PED AD-DRM content is bound to users by binding the license to a particular user, normally the one that buys rights to the content.

The main aspect of user management in PED AD-DRM is that a user gets a UserID certificate and corresponding public/private key pair. The user does not get personal access to the corresponding private key. This prevents that a user can give away his private key and enable someone else to impersonate him. Therefore the user's private key must be securely stored on a tamper resistant UserID device, which also serves as a token proving the user's presence. The UserID device must be easy to handle, robust, provide secure computing means and must be hard to clone. Examples of such devices are smart cards and mobile phones with a SIM.

Devices in PED AD-DRM get a DevicelD certificate. Domain management in PED AD-DRM is reflected by the relation between a UserID and a number of DevicelDs. The relation has the form of a DomainDevices (DD) certificate. This DD certificate contains a reference to the user of the domain, references to a number of devices and a version number When a device receives a valid certificate with a higher version number than its current DD certificate, it replaces the old DD with the new DD if it is still listed itself, otherwise it removes its DD completely and takes the other steps to deregister itself locally as described for local device reset.

Solutions without a DD certificate can be considered, e.g. each device "remembers" that it is associated with a particular user, or each device gets its own certificate instead of one DD that lists all members, or each device is simply given a domain key that grants access the content of the user. The advantage of storing the DomainDevices information in a certificate is that it leaves a trace of who issued it, while both "remembering" and having access to a key do not leave a trail. The advantage of putting all domain members in one certificate is that it allows for a simple (viral) signalling mechanism what devices are in the domain, which can be effectively used to inform deregistered devices and be used in the process of revocation information distribution.

Another use of the DD certificate is that devices can use it to report domain information to the user, e.g. show the devices in his domain. A disadvantage of using DD certificates is that they are generally bigger in size, but this size limitation is so marginal compared with the other information in this system (e.g. content) that it is considered to be of little importance.

The functionality of an AD-DRM system as indicated above is distributed over a set of functional components that form the major building blocks for the AD-DRM system. An embodiment is illustrated in Fig. 8. In this embodiment, the ADMCore, ADMTerminal, ADClient and UserID components together are responsible for the following AD and DRM functions of AD-DRM: domain management, content management, compliance management, rights management (license evaluation), user management (user authentication), device management and user interfacing. Note that components may be combined on a device. In other embodiments, different components may be used or their functionality can be distributed in another way over different components.

Fig. 8 also shows the interaction between the different components including the typical communication means between the components. The communication means arc not exhaustive, but rather indicate some classes, such as:

• being combined on the same device, e.g. local inter-process communication,

• being connected through a network, e.g. an IP network

• being connected with a strong limitation on the distance, e.g. using Near Field Communication technology such as is available from Philips Semiconductors, see the Internet address www.semiconductors.philips.com/markets/identification/produc ts/nfc/

The third class is considered as a special category, because (secure) distance limited communication means can be used both for user convenience and for security.

The ADMCore component has the responsibility for domain management, e.g. registering and deregistering of devices to the domain. It controls the domain composition by acting according to the domain policy. ADMCore furthermore acts as a security module for domain secrets and controls distribution of those secrets, which means that domain secret are concentrated in ADMCore and that other components only get access to those credentials on a need to have basis. Preferably this also implies that ADMCore must operate in a secure and robust environment.

The ADMTerminal component provides the interface for the ADMCore to end-users, for example a user interface to perform domain management actions, and to the rest of the AD-DRM system components (arrows 1 and 2). For example, ADMTerminal may provide proxy functions to ADMCore that enable remote components to communicate with ADMCore. ADMTerminal does not need a robust implementation and does not need to be located on a compliant device, because ADMTerminal does not perform any security sensitive AD-DRM operations itself, but only interfaces with the components.

The ADClient component is responsible for both AD and DRM functions, such as rights management (e.g. verifying that rights can be accessed by the right components, rights evaluation) and content management (processing content , e.g. decryption). ADClient also realizes some of the user management, device management and domain management functions, but the main responsibility of those functions lies at other components and ADClient only acts as a client to such functions. ADClient typically runs on devices that access the content, e.g. for rendering, and supports typical DRM functionality such as license exchange (arrow 3) and license evaluation and participates in typical AD functionality such as (de)registering to domains (arrow 2 and 4) . ADClient requires a robust implementation, because it has access to secrets associated with content and domains.

The UserID component is important for the person-based access of content on compliant devices that do not belong to the PED. Therefore UserID manages some user

credentials and uses those for authentication with ADClients (arrow 5). UserID ensures that the user credentials are protected and thereby UserID also requires a robust implementation. The distribution of components over devices depends on the characteristics of the AD-DRM system and a lot on the expected user interaction. PED AD-DRM has some characteristics that make it efficient to combine certain components on the same device. One of these choices would be to combine the UserID and ADMCore components on a smart card, because each user has exactly one domain. This smart card is then the physical representation for both the user and the domain, which makes it conceptually quite straightforward for the end-user. Implementing both on a smart card furthermore has the advantage that it provides a natural environment for secure and robust implementations, which is what both UserID and ADMCore require.

Ideally ADClient resides on a device together with ADMTerminal, which makes it straightforward to perform AD management operation since the ADMCore smartcard can be held at the device after which ADMTerminal uses the user interface of the device to facilitate (de)registration of the device in cooperation with ADClient. Alternatives are also possible, e.g. advanced portable devices that combine the ADMCore and ADMTerminal components and possibly even UserID.

The ADMCore component needs authorization information for some of its • operations. However, it may have no direct contact with the services that provide the authorization information. The same roughly applies to some devices running ADClients, e.g. typical consumption-only portable devices, that normally only contact another ADClient to obtain their content. Fortunately also devices exist with ADClients that regularly communicate with services in the network, e.g. to buy new content and receive new licenses, and these devices can obtain updated authorization information as part of that transaction. When buying new content a service provider can provide new authorization information for the device it is delivering to and we extend this mechanism by also obtaining authorization information for the identities of all other domain members listed in the DD certificate, preferably also for the identity of ADMCore and also for the uscr(s) of the domain. Due to the viral nature of the DD certificate distribution, we achieve that eventually deregistered and revoked devices cannot render any domain content anymore, with the exception when a deregistered device does not have any contact its former domain members anymore. In this case the isolated device can keep on rendering content based on the information it already possesses.

In some embodiments of DRM systems, the DRM system does not explicitly provide a list of device identifiers of the devices in the system or domain. An example of such a system is given in international patent application WO 04/027588 (attorney docket PHNL030283). In such embodiments the determination of which devices to retrieve the revocation status information for of course has to be made in another way. Even if there is a list of device identifiers, the determination of which devices to retrieve the revocation status information can be made without using this list of device identifiers.

The domain manager may supply the retrieval device with the necessary device identifiers. The devices in question may supply a request for retrieval of relevant revocation status information to the retrieval device, or to the domain manager. The domain manager then informs the retrieval device that revocation status information should be retrieved for these devices. This can be done in many ways. For example the domain manager may send a message or request to the retrieval device. This can be done periodically or whenever a predetermined number of requests have been received or according to another criterion. The retrieval device may contact the domain manager to find out if other devices have made any requests for revocation status information. This can be done periodically or whenever the retrieval device is about to engage in a purchase or download transaction or according to another criterion.

The devices may also send such a request for revocation status information to other devices in the system, which then pass the request on to yet other devices. Such a "viral" distribution of requests ensures that the requests will eventually reach the retrieval device. Such an embodiment is advantageous e.g. when there is no domain manager, or when the domain manager is not available to the other devices at all times.

The above mechanisms for making requests and supplying these requests to the retrieval device can also be used to supply responses, i.e. revocation status information, from the retrieval device back to devices in the system. For instance, the retrieval device may supply the retrieved revocation status information to the domain manager, or signal the domain manager that it has retrieved this information. It may also signal this to other devices, for example by using a designated bit in another message to "flag" that updated revocation status information is available. The other devices can then retrieve the revocation status information when needed.

The "viral" distribution mechanism is especially suitable.

A device may "subscribe" to revocation status information, i.e. indicate to the retrieval device or domain manager that updated revocation status information should be retrieved and transmitted to this device on a regular basis.

Note that different manufacturers or DRM systems may have different revocation mechanisms and/or different formats or structures for revocation status information. The retrieval device should be prepared to handle this. If the retrieval device can only handle one particular type of revocation status information, it should reject or ignore any requests for revocation status information of a different type. If multiple types or formats of revocation status information are retrieved, they may need to be distributed among the devices in the domain separately, or at least labeled as being of different type. This depends on the AD system in question.

Another embodiment is an extension to the system described in European patent application serial number 04100997.8 (attorney docket PHNL040288). In this system revocation is done in a two-step approach. First global revocation information is retrieved by a content management device. This is forwarded to the AD manager device which creates local revocation information from it. The system does not specify the exact format of the revocation information. A blacklist approach is possible, but this may be inefficient since these can be large and processing on AD manager can be hard because it may have limited storage and processing capabilities. If the system is extended with distribution of the global identifiers of all domain member devices and AD manager device then each content management device could obtain a much smaller set of revocation information based on the domain members. In addition the use of a whitelist approach is now preferred. New authorization information can be sent to the AD manager that turns it into local revocation information, which it can do much simpler now because less storage and processing is required.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims.

The revocation status information for example may also apply to (certificates or tokens for) persons or other entities in the system, not just to devices. It may also apply to a certain function in the system, i.e. the ability to write content to storage media can be revoked. It may also apply to an entity outside the system whose revocation status needs to be known to the entities in the system.

International patent application WO 01/42886 (attorney docket PHA 23871) discloses an efficient way of combining a contact list and a revocation list. Contact lists can be combined with the revocation or authentication lists as discussed above.

To allow (prospective) owners of devices to determine the revocation or authorization status of their equipment, the method according to international patent application WO 03/019438 (attorney docket PHNLO 10605) can be used.

European patent application serial number 04100215.5 (attorney docket PHNL040086) describes a method of and source device for authorizing access to content by a sink device in accordance with usage rights, the content being stored on a storage medium controlled by the source device. The revocation or authorization status of the sink device is verified using the most recently issued revocation or authorization information that is available if the usage rights need to be modified as part of the authorization of access to the content, and using revocation or authorization information associated with the content stored on the storage medium, preferably the information stored on the storage medium, otherwise. The latest version of the revocation or authorization information as used in that patent _' application can be obtained in accordance with the present invention.

In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising" does not exclude the presence of elements or steps other than those listed in a claim. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer.

In the device claim enumerating several means, several of these means can be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.