Content usage monitor

A trusted content usage monitor for monitoring content usage is provided. A unique identifier generation unit generates a unique identifier indicative of content being rendered and a packet generator generates a trusted packet comprising the unique identifier. The trusted packet is trust signed by the trusted content usage monitor, so that it can be trusted by its recipient. The trusted content usage monitor has at least one mode of operation in which content rendering cannot be decoupled from operation of the unique identifier generation unit, so that generated packets can be trusted as truly indicative of content usage.

TECHNICAL

The technology relates to content usage monitoring, and more particularly, to trusted content usage monitoring, wherein the results of that content monitoring process can be trusted to be authentic.

BACKGROUND

Widespread contemporary technologies such as personal computers and the internet mean that users may copy, share, and distribute digital content with ease. Whilst this situation can be of great advantage to end users, it also presents great challenges to those who are reliant on content distribution as a source of income, such as recording artists.

In order to address this problem, previously techniques such as Digital Rights Management (DRM) have been developed, which seek to limit an end user's ability to copy and share digital content. Such techniques have however proved to be unpopular, due to their intrusive nature, and in particular because of the limitations they impose on a given end user to copy content legitimately for personal use (for example making a backup copy of an audio CD). Conversely, once DRM protection on a copy of some digital content has been circumvented, that unprotected and unlicensed copy can be distributed at will by those who choose to do so, meaning that over time such unlicensed copies will tend to proliferate at the expense of the protected copies.

Another approach to digital content distribution is to allow end users to freely copy, share and distribute digital content, and to distribute royalty payments to the providers of that digital content in accordance with its usage. Whilst such a scheme is understandably popular with end users, a drawback is that it is open to abuse by those who seek to distort the royalty payment distribution. For example, by repeatedly downloading an item of digital content which is freely available on the internet, a single user may trick the server providing that digital content into registering much higher usage statistics than are fairly to be attributed to that digital content.

One such example of free digital content distribution is the free internet radio service Last.fm (http://www.last.fm/), which allows users to stream audio content as an internet radio or on-demand service. The frequency with which particular audio tracks are listened to by on-line listeners can be used to determine royalty payments to artists and record labels, yet services such as Last.fm are vulnerable to their statistics being distorted by unscrupulous users.

Accordingly, it would be desirable to provide an improved technique for monitoring content usage, which makes it difficult, if not impossible, to unfairly distort the results of that monitoring, and can therefore provide trusted usage information.

SUMMARY

Viewed from a first aspect, a trusted content usage monitor is provided for monitoring content usage comprising: an interface for receiving content; a content renderer; a unique identifier generation unit configured to generate a unique identifier indicative of said content; and a packet generator configured to generate a trusted packet comprising said unique identifier, said trusted packet being trust signed by said trusted content usage monitor, said trusted content usage monitor having at least one mode of operation in which operation of said content renderer cannot be decoupled from operation of said unique identifier generation unit.

Thus, a trusted content usage monitor is provided which receives content via an interface and then renders that content. The trusted content usage monitor has a unique identifier generation unit configured to generate a unique identifier indicative of that content and a packet generator configured to generate a trusted packet comprising the unique identifier. Hence, content usage can be monitored by later examination of the packets generated by the packet generator. This content usage monitoring can be trusted, because the trusted packet is trust signed by the trusted content usage monitor, i.e. the recipient of the packet can trust its content because of the manner in which the packet has been trust signed by the trusted content usage monitor. Furthermore, the recipient of the trusted packet can be confident that the packets generated by the trusted content usage monitor are a true indication of the content that has been rendered, because the trusted content usage monitor has at least one mode of operation in which operation of the content renderer cannot be decoupled from operation of the unique identifier generation unit. In other words, in this mode it is not possible for content to be rendered without the unique identifier generation unit generating a unique identifier indicative of that content. Equally, because the unique identifier generation unit and packet generator are comprised within the trusted content usage monitor, it is not possible for packets indicative of rendered content to be generated, without that content in fact having been rendered.

It should be noted that in the context of the present application, the extent to which the unique identifier is strictly (i.e. mathematically) unique is a choice for the system designer. Ideally the recipient of the trusted packets can be 100% sure of what content has been rendered on the basis of the unique identifier(s) received, but in practice it may prove acceptable for there to be a minor error rate, so long as this does not distort the usage statistics for the purposes they are being gathered.

In one embodiment this mode of operation is the only mode of operation in which the trusted content usage monitor can operate.

Whilst in principle the packet generator could generate the trusted packet as soon as the content renderer begins rendering content, in one embodiment said packet generator is configured to generate said trusted packet only if a predetermined minimum portion of said content has been rendered by said content renderer. In this way, the recipient of the trusted packet can know that a minimum portion of the content has been rendered by the content renderer, thus preventing the impression that the entirety of a piece of content has been rendered, when in fact only a small initial portion of that content has been rendered. As an example, if the content is an audio track, the packet generator can be configured to generate the trusted packet only if (for example) at least 15 seconds of the audio track has been played.

In a related arrangement, in one embodiment the packet generator is configured to generate said trusted packet only if said content has been rendered by said content renderer according to a predetermined manner. Given that the aim of the trusted content usage monitor is to provide content usage monitoring information which can be trusted as indicative of content that has been “truly” rendered, it is advantageous if the trusted packet is only generated if the content has been rendered according to a predetermined manner. It will be appreciated that this predetermined manner could take a variety of forms, but in one embodiment the predetermined manner is a normal rendering speed. In the example of an audio track, this allows the trusted packet only to be generated when the audio track has been played back at normal playing speed, and not merely fast forwarded from beginning to end.

In another approach, to generate trusted packets which the recipient can rely on and from which true content usage can be deduced, in one embodiment said packet generator is configured to generate said trusted packet including an indication of any abnormal rendering. In this arrangement, the packet generator can generate the trusted packet regardless of whether the rendering of that content has taken place normally, but is configured to include in the trusted packet an indication of any abnormal rendering, for example fast forwarding or skipping through an audio track.

It will be appreciated that the unique identifier could be provided in a variety of ways, but in one embodiment, the unique identifier is generated using a hash function. This hash function will be understood by those skilled in the art to be configurable in a number of ways, so long as it provides a unique identifier indicative of the content. In another embodiment the unique identifier is generated using a fingerprinting algorithm. In yet another embodiment the unique identifier comprises a sample of said content.

The trust signing of the trusted packet by the trusted content usage monitor could take place in a number of ways, but in one embodiment the trusted content usage monitor further comprises a signing unit configured to sign said trusted packet using a trusted signing key. Using a trusted signing key provides an advantageously simple yet secure manner of trust signing the trusted packet such that the packet's recipient can be assured of its authenticity.

As well as the unique identifier indicative of the content, the trusted packet may contain various other pieces of information which may be of use to the recipient of the trusted packet for the purposes of content usage monitoring. In one embodiment the trusted packet comprises an indicator associated with said trusted content usage monitor. This enables the recipient of the trusted packet to easily identify the trusted content usage monitor which has generated that trusted packet. In another embodiment said trusted packet comprises a security indicator indicative of a level of trust accorded said trusted content usage monitor. It may be the case that various kinds of trusted content usage monitor exist operating in different situations, which give rise to a different level of trust accorded to each trusted content usage monitor. For example, on the one hand the content usage monitor may be trusted to a high degree, in which case usage statistics derived from such a content usage monitor are taken at face value. On the other hand the content usage monitor may be less well trusted, in which case usage statistics derived from such a content usage monitor may be more closely scrutinised for signs of distortion. As an example of such scrutiny, a sudden spike in the usage of a particular piece of content reported from a less trusted content usage monitor may be ignored as an attempt at spoofing such a sudden increase in usage.

In another embodiment the trusted packet further comprises a time stamp. This not only provides the recipient of the trusted packet with information about when the content was rendered, but also may act as a further security provision in that multiple packets received with identical time stamps are likely to have been spoofed. Alternatively even closely spaced time stamps may be indicative of spoofing if the time stamps are too close to have allowed the indicated content to have been genuinely rendered. In another embodiment the trusted packet further comprises a statistically unique number. For example the content usage monitor may generate a 32-bit random number to append to each trusted packet that is generated, providing a further verification tool for the packet recipient to verify whether two packets from one source do indeed correspond to separate renderings of that content, or are merely a repeated packet.

In another embodiment, the trusted packet further comprises metadata associated with said content. For example such metadata could be ID3 tags in the case of MP3 content. Such metadata may be used to cross check against the identification resulting from the unique identifier produced by the unique identifier generation unit, or even to identify the content in the case that the unique identifier cannot be recognized by the recipient of the trusted packet.

In another embodiment the trusted packet further comprises an indication of configuration details of the trusted content usage monitor. This enables the recipient of the trusted packet to gather information regarding the trusted content usage monitor. In another embodiment the trusted packet further comprises an indication of configuration details of a system comprising said trusted content usage monitor. This enables the recipient of the trusted packet to gather information regarding a system, such as a mobile phone, or personal computer of which the trusted content usage monitor forms part.

An advantage of the technology in this application is that if the packet is trust signed and can therefore be trusted by its recipient, there is in principle no need for third parties to be prevented from reading the contents of the trusted packet, so long as those third parties are unable to fake these trusted packets. However, in one embodiment, the trusted content usage monitor further comprises an encryption unit configured to encrypt said trusted packet using an encryption key. This provides a further level of security for the system, preventing third parties from being able to read the contents of the trusted packets and for example preventing transmission of particular packets in order to distort the usage statistics.

Once the packets have been generated they may be handled in a number of different ways. In one embodiment the trusted content usage monitor is configured to transmit said trusted packet. For example, if the monitoring of content usage were being carried out in a mobile phone, that mobile phone could transmit the trusted packet via its normal communication channels to a remote server. In one embodiment the trusted content usage monitor is configured to store said trusted packet prior to transmission. This may be advantageous for a number of reasons, for example to transmit only when it is desirable to do so, e.g. so as not to conflict with other communication requirements, or to store multiple packets to transmit later in a burst. Transmitting packets in a burst may be useful to conserve battery life in a mobile device, for example simply due to the efficiency of a batch burst, or alternatively by waiting until the mobile device has a high bandwidth transmission channel available to it (e.g. in a WiFi connected location).

In another embodiment the trusted content usage monitor is configured to store said unique identifier prior to generating said trusted packet. This allows the trusted content usage monitor to separate the generation of the unique identifier from the generation of the trusted packet, for example so that multiple unique identifiers can be bundled into one trusted packet.

The interface over which the trusted content usage monitor receives the content may connect to a number of different types of source. In one embodiment the interface is configured to receive said content from a non-trusted source. This reduces the extent of the components which are required to be trusted effectively resulting in a more secure system. The source of the content does not need to be trusted, as long as the trusted content usage monitor itself is trusted.

It will be appreciated that the particular type of content, the usage of which is being monitored by the trusted content usage monitor, could take a variety of forms. In one embodiment said content renderer is an audio renderer and said content comprises audio data. In another embodiment said content renderer is a video renderer and said content comprises video data. In another embodiment said content renderer is a text renderer and said content comprises text data. In another embodiment said content renderer is a graphics renderer and said content comprises graphics data. In another embodiment said content renderer is an application execution device and said content comprises application data. Application data could take a variety of forms, in particular software that is arranged to be executed on a system incorporating the trusted usage monitor. Hence rendering content, when understood in the context of application data, could for example consist of executing that application on the system, or alternatively could only consist of installing that application on the system.

Whilst the unique identifier indicative of the content could be generated by continuous sampling of the content as it is rendered, in one embodiment said unique identifier generation unit is configured to generate said unique identifier indicative of said content by intermittently sampling said content during rendering by said content renderer. This intermittent sampling, in one embodiment, occurs at predetermined intervals during said rendering. In another embodiment the intermittent sampling occurs at randomized intervals during said rendering.

Viewed from a second aspect, a method of operating a trusted content usage monitor is provided to monitor content usage, comprising the steps of: receiving said content; generating a unique identifier indicative of said content; and generating a trusted packet comprising said unique identifier, said trusted packet being trust signed by said trusted content usage monitor, said trusted content usage monitor having at least one mode of operation in which rendering said content cannot be decoupled from generating said identifier.

Viewed from a third aspect, a trusted content usage monitor is provided for monitoring content usage comprising: interface means for receiving content; content rendering means for rendering content; unique identifier generation means for generating a unique identifier indicative of said content; and packet generator means for generating a trusted packet comprising said unique identifier, said trusted packet being trust signed by said trusted content usage monitor, said trusted content usage monitor having at least one mode of operation in which operation of said content rendering means cannot be decoupled from operation of said unique identifier generation means.

Viewed from a fourth aspect, a data processing system is provided comprising a trusted content usage monitor according to the first aspect. In such a system, the trusted content usage monitor may be viewed as a trusted component of that system, whilst other components may be non-trusted. Such components may be distinct items of hardware, or may be implemented in software running in either a trusted or a non-trusted environment. As such it is possible for some trusted components and some non-trusted components to be implemented by the same hardware, such as a processor core, if for example that processor core is arranged to execute both trusted and non-trusted software. In one embodiment the interface over which the trusted content usage monitor receives content is configured to receive that content from a non-trusted component of the system.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1schematically illustrates a system comprising a trusted content usage monitor of one embodiment in the form of a secure rendering device;

FIG. 2schematically illustrates a system comprising a trusted audio content usage monitor of one embodiment;

FIG. 3schematically illustrates in more detail the trusted audio content usage monitor ofFIG. 2in accordance with one embodiment;

FIG. 4illustrates a series of steps taken by a trusted audio content usage monitor such as that illustrated inFIG. 3in accordance with one embodiment;

FIG. 5schematically illustrates a system comprising a trusted audio content usage monitor of one embodiment;

FIG. 6schematically illustrates the division of a system into secure and non-secure domains; and

FIG. 7schematically illustrates a system which implements a trusted content usage monitor according to one embodiment.

DESCRIPTION OF EXAMPLE EMBODIMENTS

FIG. 1schematically illustrates a system comprising a trusted content usage monitor according to one embodiment. In the context of the present discussion, a content usage monitor is described as “trusted” if the content usage results that it produces can be relied upon as genuine, i.e. truly indicative of the content that has been used. This “trust” could be ensured in various ways, one example of this being the provision of secure components within a system to which non-secure components of the system have no access. Security is further discussed below.

The system100comprises a content store110into which content may be stored either by downloading it from a network or from a local source (such as from a CD, a DVD or a USB stick). Content is then retrieved and if necessary decoded by retriever/decoder120, which then passes the (decoded) content to secure rendering device130. Secure (i.e. trusted) rendering device130comprises a trusted content usage monitor for monitoring the content used (i.e. rendered) by secure rendering device130. Secure rendering device130then produces content output. The particular content and the corresponding nature of the secure rendering device could take a range of forms such as: audio content rendered by an audio device (e.g. music played back by audio hardware); video content rendered by an video device (e.g. video played back by video hardware); text content rendered by an text device (e.g. an e-book displayed on a screen); graphics content rendered by a graphics device (e.g. graphics reproduced on a screen); or application content rendered by an application rendering device (e.g. application software executed on a computer).

In parallel to rendering the content the trusted content usage monitor in secure rendering device130generates trusted packets which are signed as being authentic. These signed packets140are transmitted to logging server150which gathers usage statistics for the content being used. The security provisions enabling secure rendering device130to be deemed “secure” may be provided in a number of ways, but in the embodiments described herein the security is provided by the TrustZone technology provided by ARM Limited of Cambridge, United Kingdom as described for example in U.S. patent application Ser. No. 10/714,518, now U.S. Pat. No. 7,849,310 the contents of which are incorporated herein by reference. There are also various standards known to the skilled person for defining how trusted signing and encryption could be implemented, such as Public-Key Cryptography Standard (PKCS) #7 (see http://www.rsa.com/rsalabs/node.asp?id=2129), and how cryptographic data should be handled within a secure environment, such as PKCS #11 (see http://www.rsa.com/rsalabs/node.asp?id=2133). Equally the implementation of secured key and data transfers could be managed by well known protocols such as Transport Layer Security (TLS)—see RFC 5246:: “The Transport Layer Security (TLS) Protocol Version 1.2” (see http://tools.ietf.org/html/rfc5246).

Additionally it should be noted that the illustrated “devices” inFIG. 1may be embodied as dedicated hardware components, but may alternatively be embodied as software components running on a suitable system. In the following, as examples of these possibilities, the embodiments shown inFIGS. 2, 3 and 5are described as hardware devices, whilst the embodiments shown inFIGS. 6 and 7are described in terms of software. Equally, in any given embodiment a mix of hardware and software is of course also possible.

FIG. 2schematically illustrates a specific example of the system illustrated inFIG. 1, namely an audio rendering system200. The system200comprises memory210in which encoded audio220is stored. Encoded audio220is, in this embodiment, encoded in MP3 format. When the user of system200wishes to play an item of audio content, that item is passed from memory210to audio decoder230which converts the encoded audio into raw audio which in this embodiment is in Pulse-Width Modulation (PWM) format. This raw audio is then passed to secure audio device240which drives loudspeaker250, thus playing the required audio track. In parallel to driving loudspeaker250, the secure audio device240also generates and signs signed packet255which contains a unique identifier indicative of the audio track being played and transmits this signed packet255to logging server260.

FIG. 3schematically illustrates in more detail the secure audio device240shown inFIG. 2. The raw audio data is received by secure audio device240over interface300which passes the raw audio data to control unit310. Control unit310passes the raw audio data to audio renderer320which drives loudspeaker330to produce the audio output. Thus, audio renderer320is essentially an analogue-to-digital converter. In parallel, control unit310passes the raw audio data to fingerprint transform unit330. Fingerprint transform unit330analyses the stream of raw audio data and generates a unique identifier indicative of the content of the raw audio data. Although the fingerprint transform unit could in principle generate a true fingerprint (in the mathematical sense of the word, where a large data item is mapped to a much shorter bit string), such algorithms are sensitive to the encoding used for the content or any distortion, since any minor change at the bit level will result in a change to the fingerprint thus produced. Preferably instead the fingerprint is indicative of the perceptual characteristics of the audio content. The skilled person will be aware of various techniques for performing a fingerprint in this manner which exploit perceptual characteristics of the audio content such as tempo, spectral features and prominent tones. Contemporary audio fingerprinting algorithms are able to identify whole audio tracks from excerpts only a few seconds long. Example techniques are described in “A Robust Audio Fingerprint Extraction Algorithm”, J. Lebossé, L. Brun, J-L. Starck, J. C. Pailles, SPPRA2006, pp. 185-192, Innsbruck, Austria, February 2006 and “Boosted Binary Audio Fingerprint Based On Spectral Subband Moments”, Sungwoong Kim and Chang D. Yoo, ICASSP2007), Honolulu, Hawai'i, April 2007.

The “fingerprint” develops as the raw audio data is fed to the fingerprint transform unit330requiring a minimum amount of time for the fingerprint to have developed sufficient characteristics to uniquely identify the audio content. The control unit310is arranged in one embodiment to control fingerprint transform unit330to pass the results of its operation to packet generator340once a predetermined period of time has passed. Similarly the control unit310is configured to prevent packet generator340from generating a packet until a minimum proportion of the audio content is played back. In another embodiment the control unit310is configured to control fingerprint transform unit330to intermittently sample the audio content during playback. This intermittent sampling can be configured to occur at predetermined intervals during said playback or at randomized (quasi-random) intervals during playback.

Packet generator340is arranged to generate a packet comprising the unique identifier (fingerprint) provided by fingerprint transform unit330in order to pass this information to the outside world. Before being released to the outside world the packet is trust signed and encrypted, these stages being performed by signing and encryption unit350which is also controlled by control unit310. Finally the packet generator340passes the trust signed and encrypted packet to communication unit360which, in this embodiment, is outside the secure audio device240(but in other embodiments could comprise part of secure audio device240). Communication unit360then transmits the packet to logging server370. In the embodiment illustrated inFIG. 3, control unit310is arranged to ensure that audio renderer320can only be operated in parallel to operation of the fingerprint transform unit330and packet generator340, such that audio cannot be produced from loudspeaker330under control of secure audio device240without a corresponding fingerprint and packet being generated. Conversely a fingerprint and packet cannot be generated without operation of the audio renderer320. Logging server370is arranged to gather usage statistics, the usage statistics being gathered from many different trusted content monitors. The usage statistics are then later analysed in order to determine the relative usage frequency of the audio content.

In one alternative embodiment, the fingerprint transform unit330is arranged to perform a selection on the raw audio data it is passed from control unit310, and to pass this sample to the packet generator340. The identification of that sample is then performed by the recipient of the trusted packet.

In an alternative embodiment, the control unit could be arranged to allow, under certain specific circumstances, the audio renderer320to operate independently of the fingerprint transform unit330and packet generator340, such that audio can (under these specific circumstances) be produced from loudspeaker330without a corresponding fingerprint and packet being generated. This could for example allow the user to operate the system occasionally without packets indicative of content usage being generated. However, although a user may have valid privacy reasons for occasionally opting out of the trusted packet generation process, an inherent advantage of participating in the trusted packet generation process is that by doing so the user will be benefiting the content producers that they favour. As such there is a constant incentive for users who have such a possibility to opt out to choose to opt in.

In alternative embodiments the secure audio device240further comprises temporary storage unit380and/or temporary storage unit390. Temporary storage unit380is arranged to store (under the control of control unit310) fingerprints produced by fingerprint transform unit330before being passed to packet generator340. Similarly temporary storage unit390is arranged to store (under the control of control unit310) packets produced by packet generator340before being passed to communication unit360. Accordingly multiple fingerprints stored in temporary storage unit380can be bundled into one packet and/or multiple packets stored in temporary storage unit390can be transmitted together.

FIG. 4schematically illustrates a series of steps taken when secure audio device240is operating in a system such as that illustrated inFIG. 2. At step400it is determined if the user has initiated audio playback. Until the user initiates audio playback the flow loops on itself through step400. When the user initiates audio playback the flow proceeds to step410where the selected audio is decoded and passed as raw audio to the secure audio device. The flow then splits into two parallel streams, the rendering of the audio taking place in step420and the fingerprint transform being performed in step430. The parallel nature of these operations is illustrated by the dashed line connecting steps420and430. At step440it is determined if audio playback has stopped. If it has not, the flow returns to step420(and in parallel to step430) and the rendering of audio and fingerprint transform continues. In parallel to step440(indicated by the dashed line between steps440and450), at step450it is checked whether there has been sufficient play length to allow packet generation to occur. If there has thus far been insufficient audio playback to allow packet generation then the flow returns to step430(and in parallel step420) and the fingerprint transformation process and audio rendering continue.

As soon as sufficient play length has occurred for packet generation to take place, then at step450the flow proceeds to step460, where the fingerprint is passed to the packet generator340. At step470the packet generator340and signing and encryption unit350generate the signed and encrypted packet which at step480is then transmitted to the logging server. The packet generation process thus ends at step485. Note that this then decouples the audio playback loop (steps420and440) from the fingerprinting loop (steps430and450), i.e. audio playback then continues until it is stopped, without further fingerprinting (or packet generation) occurring.

Finally, if at step440audio playback is stopped, then the flow proceeds to step490where the process ends. It should be understood that steps460,470and480effectively follow immediately from the determination at step450that sufficient play length has occurred for packet generation to take place. Hence the stopping of audio playback at step440will only prevent packet generation from occurring if it occurs earlier than a positive determination at step450.

FIG. 5schematically illustrates another example of the system illustrated inFIG. 1, as an alternative to that illustrated inFIG. 2. This audio rendering system200is similar to the system200illustrated inFIG. 2, with memory210, encoded audio220, loudspeaker250, signed packet255and logging server260being identical. However in the embodiment illustrated inFIG. 5, decoder232is also a secure device such that together secure decoder232and secure audio device240can be considered to form a “secure domain”236of the system. Furthermore, system202illustrates three alternative arrangements for the point within the secure domain of the system at which the fingerprinting and packet generation can take place.

Alternative A is the same as is illustrated inFIG. 2, the fingerprinting process being applied to the raw audio received by audio device240.

In alternative B the fingerprinting process is integrated into the decoding process performed by secure decoder232. For example, in this audio example, the fingerprinting can be arranged to operate on frequency samples prior to the inverse Modified Discrete Cosine Transform (iMDCT) in the decode process. In an equivalent video based example, where the decoder is a graphics driver, this fingerprinting could take place with respect to triangle lists (e.g. in an OpenGL-ES 3D graphics driver).

In alternative C the fingerprinting process takes place at the input (shown as input unit234) to the secure domain236on the incoming encoded audio (e.g. MP3 stream) being transferred from memory210.

The security required in a system implementing the technology described here could be provided in a number of different ways. However, in one embodiment it is provided by employing the TrustZone technology provided by ARM Limited of Cambridge, United Kingdom. According to the TrustZone technology, components of a system are defined as being in the “secure” domain (i.e. trusted) or the “non-secure” domain (i.e. non-trusted). It is also possible for components to be “secure aware”, meaning that they have the ability to operate in either domain and to act appropriately for that domain. One example of such a secure aware device is the processor hardware, which is schematically illustrated inFIG. 6.FIG. 6schematically illustrates a software view of the processor hardware500, spanning the secure domain and the non-secure domain. In the non-secure domain the processor hardware has a non-secure operating system510, under which various applications520are run. Similarly in the secure domain the processor hardware has a secure operating system530, under which various applications540are run.

Hence, when such a system is implementing the technology described in this application, trusted components such as the secure audio device240illustrated inFIG. 2are thus implemented in the right hand side of this figure in the secure domain. For example the control unit310, the fingerprint transform unit330, the packet generator340, the signing and encryption unit350and at least the driver software for the audio renderer320will be implemented as secure applications540running under control of the secure OS530. Conversely non-trusted components such as the decoder230are implemented in the left hand side of this figure in the non-secure domain as non-secure application520running under control of the non-secure OS510.

FIG. 7schematically illustrates in more detail a system comprising a trusted content usage monitor according to one embodiment of the present invention. The system is composed of some components that are secure (i.e. trusted) (labelled with vertical hatching), some components that are non-secure (i.e. non-trusted) (labelled with horizontal hatching) and some components that are secure aware, meaning that they have be ability to operate in either a secure or a non-secure mode (labelled with diagonal hatching).

The system generally comprises a system-on-chip (SOC)600, external SDRAM605(accessed via memory controller607) and external FLASH610(accessed via flash controller612). On-chip there is a processor comprising a TrustZone technology enabled core617and an L1 cache618. Processor core617communicates with the remainder of the system via bus620. Connected to the bus is LCD controller627, which provides display control for communicating information to the user. Some general purpose components which are part of the non-secure (non-trusted) domain are connected to the bus620via a general bridge625, such as a keyboard, watchdog unit, clock and timers (generally indicated as630). Other components, which form part of the secure (trusted) domain are connected to the bus620via security bridges635. These security bridges635in effect render the secure parts of the system invisible to non-secure parts of the system. One security bridge635provides access to boot ROM640which stores trusted boot code for the system. Another security bridge635provides access to unique ID storage unit645, key storage unit650and master key storage unit655. Another security bridge635provides access to crypto hardware660, random number generator unit665and audio hardware670. Another security bridge635provides access (via memory controller607) to the secure part of SDRAM605in which the trusted OS is stored. A non-trusted OS is also stored in the non-secure part of SDRAM605.

In operation, when a user wishes to play an audio track he starts any audio player available in the non-trusted OS (i.e. in non-secure memory in SDRAM605). The audio player offers a selection of encoded tracks stored in the flash file system610in the non-trusted OS (e.g. via a display interface controlled via LCD controller627). In this example the tracks are encoded in MP3 format. The user selects a track for playback, e.g. by means of input via keyboard630(corresponding to step400inFIG. 4).

The non-trusted audio player (typically with support of non-trusted CODECS in the non-trusted OS) decodes segments of the track into a raw audio format such as pulse-width modulation (corresponding to step410inFIG. 4). The player then (via non-trusted audio drivers in the non-trusted OS) places all or parts of that track into an audio buffer in non-secure memory in SDRAM605. The player then (via non-trusted audio drivers in the non-trusted OS) messages a trusted track ID application in the trusted OS in SDRAM605that a first segment is ready for playback. Note that in this system non-trusted audio drivers have no direct capability to render audio. They can only do so by communicating with the trusted track ID application.

The trusted track ID application initialises the trusted track ID generator and points it at the first segment for fingerprinting. The trusted track ID application initialises the trusted audio driver and points it at the first segment for playback. Simultaneously the trusted track ID application instigates two actions:

A. Firstly, if the trusted track ID generator has not completed a reference segment, the trusted track ID generator uses the presented raw audio to continue building its unique track identifier (i.e. a fingerprint) (corresponding to step430inFIG. 4). It may use the cryptographic hash generators typically built into the cryptographic hardware660(e.g. SHA1, MD5 etc) to perform this step, or it may make use of dedicated algorithms for processing audio media.

B. Secondly, the trusted audio hardware/driver combination proceeds with playback (corresponding to step420inFIG. 4) taking control commands from the non-trusted player via the non-trusted audio drivers. The trusted audio driver is the only thing that can access the audio hardware670. Any commands (routed via the trusted track ID application) from the non-trusted audio player which cause playback to be unintelligible are acted upon, but also noted for later reference as exceptions to intelligible playback (e.g. mute, fast forward, rewind). When the trusted audio driver is ready for the next segment it informs the trusted track ID application.

Unless interrupted (corresponding to step490inFIG. 4), the trusted track ID application requests further data from the non-trusted audio driver and if there is further data then the process continues repeating actions A and B above.

Once a sufficient reference segment of the raw audio has been used to generate a trusted track ID (corresponding to step450inFIG. 4), and all other relevant data has been gathered, then the trusted track ID application instigates the trusted track ID packet finalisation procedure (corresponding to step460inFIG. 4), according to which a data packet is created containing:the trusted track ID (i.e. the audio fingerprint);notes on the number and nature of exceptions to intelligible playback;device specific information retrieved from the secure store (a file system enabled by the secure world's internal use of keys and device unique identities along with the cryptographic hardware, providing cryptographically sealed or signed security of data that is stored in the general file system);a device unique identifier derived directly or indirectly from secure device identification;user specific information retrieved from the secure store;a statistically unique value generated by the trusted random number generator665, used to prevent replay attacks (the repeated sending of an intercepted packet); anda secure timestamp (if available—although the generation of trusted clocks is complicated and so the system may rely purely on the statistically unique value).

The crypto hardware660signs the packet against a key (stored in key storage650) that the packet receiver (i.e. the logging server) trusts (corresponding to step470inFIG. 4). Note that the key itself does not need to be exposed to risk as it is referenced by an identifier even inside the secure environment and the signing calculations are carried out inside the cryptographic hardware. The trusted track ID application passes the data packet to the non-trusted OS. The non-trusted OS uses its non-trusted communications methods to transmit the packet to the server (corresponding to step480inFIG. 4). Because the packet has been protected by security measures while inside the secure environment it is now safe from attacks and the receiving logging server may itself trust the packet of data received. Other variants of this exist depending on what data and playback information is needed to be noted.

Thus a trusted content usage monitor is provided which generates packets from which the content usage can be derived. The content used is indicated by means of a unique identifier generated within the trusted content usage monitor. The recipient of the packets can be confident of their authenticity, because the packets are trust signed by the trusted content usage monitor in a fashion that is trusted by the recipient. Furthermore, the recipient of the trusted packet can be confident that the packets generated by the trusted content usage monitor are a true indication of the content that has been used, because the trusted content usage monitor has at least one mode of operation in which operation of the content renderer cannot be decoupled from operation of the unique identifier generation unit. In other words, in this mode it is not possible for content to be rendered without the unique identifier generation unit generating a unique identifier indicative of that content. Conversely it is not possible for a unique identifier (and hence a packet incorporating such a unique identifier) to be generated without that content having been rendered.

Although particular embodiments have been described herein, it will be apparent that the claims are not limited thereto, and that many modifications and additions may be made within the scope of the claims.