GB2514327A

GB2514327A - Multi-device transaction method for digital content

Info

Publication number: GB2514327A
Application number: GB1305512.4A
Authority: GB
Inventors: Daniel Shelton; Adrian Dawson; Bryan Jeffery Moles
Original assignee: Antix Labs Ltd
Current assignee: Antix Labs Ltd
Priority date: 2013-03-26
Filing date: 2013-03-26
Publication date: 2014-11-26
Also published as: GB201305512D0

Abstract

A user requests digital content 1-5 from a first device and submits credentials 9-11 to authorize payment to unlock the content on a second device 12-15. When the transaction is completed an authorisation is sent to a consumption device, which may be the first or second device or a third device, and is used to unlock the digital content. A system may hold transactions in progress and direct the user to a credential-submission interface on the second device e.g. via a URL, hyperlink or QR code 6-8, the user inputting a transaction ID or associated shorter code on accessing the URL using the second device in order to complete the transaction. The authorization may include an authenticable digital rights object enumerating the usage rights. The user may have an account specifying the relevant devices. The user may already have the content and wish to purchase usage rights 1A, or may wish to acquire the content and usage rights at the same time 1B.

Description

Multi-Device Transaction Mechanism for Digital Content

Background

Informally, a consumer might think of "buying a game" or "buying a song" for use on a consumer electronic device such as a mobile phone, television set-top box, or tablet. In actuality, the transaction would rarely result in the consumer owning the content itself, but rather he would acquire the right to use that content in a prescribed way as defined by the terms and conditions of the transaction with the content owner or reseller.

Typically, a digital rights management (DRM) framework enforces usage rights for content. The consumer would experience this as the content being locked in some way so that it can only be used in accordance with the rights purchased. The consumer might be allowed to consume the content only on one particular device or for a limited number of times, for example. In order to realize this enforcement, the technical implementation of the DRM framework requires that the rights themselves be enumerated and codified in some way, then provided as part of the content package (a bundled set of digital files with a well-defined packaging format), part of an application that plays the content (a "player"), or separately as a standalone "rights object".

This invention applies to scenarios in which consumers purchase usage rights for content, and also take delivery of both the content and the associated rights objects either together or separately.

Descr)ption of the Problem Consider a consumer seeking to purchase the rights to use some content on a particular internet-connected consumer electronic device. Although the device is internet-connected, it may be unsuitable for executing financial transactions to purchase such rights, either as deemed by the consumer or due to some technical limitations of the device.

To understand why a device may be deemed unsuitable, consider that any such device presents a user interface, typically comprising both hardware and software elements, with which the consumer interacts to initiate a purchase transaction. While the device user interface may be suitable for initiating the transaction, it may be deemed unsuitable for the financial part of the transaction for a variety of reasons including: * Lack of a browser or on-device software for inputting financial details on the device * Capabilities and limitations of the software UI, e.g. the browser or other on-device software * Capabilities and limitations of the physical device display or input devices (touchscreen, keypad, TV remote, etc.) * Clumsiness of the interface to enter particular kinds of data, i.e. digits or text.

* Perceived or actual security of the device and platform for inputting important financial or personal data necessary for the transaction Despite the reason for the device being deemed unsuitable or inconvenient for financial transactions, and/or in light of another device being more suitable or convenient, there remains a need in the art for a method and apparatus to enable the consumer to purchase the desired rights for content to be consumed on that device.

Dscusson of the lnventon The present invention is as set out in the claims.

Where a feature in the present application is discussed or defined in terms of a method, it is to be understood that the invention also extends to a corresponding apparatus. Likewise, where the discussion is in terms of apparatus, it is to be understood that the invention is considered also to extend to a corresponding method.

The invention further extends to a computer readable medium carrying instructions that, when executed by a computer, carry out a method according to the invention.

According to a further aspect of the present invention a transaction mechanism for digital content comprises a method or apparatus as follows: * A purchase or other transaction that utilizes two (or multiple) devices: o The device on which the content/service will be consumed and for which the appropriately formatted content must be selected or prepared o The device from which the financial transaction will be executed * An optional database that stores transactions in progress and a way to redirect a consumer to continue the transaction, e.g. via U RL and other credentials.

Descdpton of Drwhigs The invention may be carried into practice in a number of ways and some specific embodiments will now be described, by way of example, with reference to the accompanying drawings, in which: Figure 1 shows the preferred elements of an embodiment of the invention; Figure 2 shows the preferred process steps for the embodiment of Figure 1; Figure 3 shows the retrieval of purchasable items; Figure 4 shows the transmission of transaction information to the content store; FigureS shows the retrieval of pending transaction information; and Figure 6 shows delivery of rights objects.

The manifold advantages of this invention in its various forms include some or all of the following: Providing a convenient means for consumer to execute a purchase of content/service for use one device, even when that device is deemed unsuitable for executing the purchase transaction itself.

Neither the selection nor purchase devices is required to be among the devices on which the content is intended to be consumed.

* Providing security in that consumer financial details can be segregated to only one device while purchased content/services go to various devices.

* Circumventing problems associated with financial transactions through awkward UI input methods that were not designed for such activities, e.g. a TV remote control.

* Enabling consumer use cases such as a parent buying content for his children's devices without having to put financial details thereon.

HghLev& De rpton of the Preferred Etnbothments The preferred transaction may be thought of as comprising several parts: 1. The "selection part" wherein the consumer chooses the digital content for which he wishes to obtain the content on his device and purchase some corresponding consumption or usage rights. In some implementations, the consumer may have the opportunity to select more content, rights, or further refine his previously made selections in orderto uniquely define that which he wishes to purchase.

2. The "purchase or transaction part" wherein the consumer explicitly or implicitly submits purchase or other transaction credentials through a user interface; and 3. The "fulfilment part" wherein the digital content and/or "rights objects" are delivered and after which it is consumed.

Note that while "selection part" of the transaction must always occur first, either explicitly or implicitly, the "purchase part" and "fulfilment part" might occur in either order. Further, the three parts of the transaction need not necessarily occur back-to-back-to-back, but might be spread out over some time to accommodate practical issues such as billing cycles, trial periods, promotions, gift giving scenarios, etc. We describe in more detail below a variety of novel combinations of functional elements and operational sequences by which the selection and fulfilment parts of the transaction are executed on one device, while the financial part is executed on a different, more suitable device.

To clarify, consider a set of devices labelled "A", "B", "C", and so on. The following Table 1 shows the combinations which are already known (see column 2) along with combinations that comprise embodiments of the invention.

Table I

Embodiment Case of Selection Purchase Consumption Invention? Device Device Device Comments Traditional content purchase scenario. Known per I No A A A Se.

Example; Select and buy content on PC for 2 No A A A and B consumption on PC and mobile device. Known per Sc.

Example: Select and buy content on PC for A, B, C and 3 No A A consumption on PC and several mobile devices.

others Known per se.

B, C and Example: Select and buy content on PC for 4 No A A others, but consumption on one or more other specific devices NOT A excluding the PC. Known per Se.

Example; Select content on Tv/SIB, complete Yes A B A purchase transaction on mobile, consume content on that same Tv/Sm Example: Select content on Tv/SIB, complete 6 Yes A B B purchase transaction on mobile device, consume content on that same mobile device Example; Select content on Tv/SIB, complete purchase transaction on mobile device, consume 7 Yes A B AandB content on that specific Iv/STB and that specific mobile device Example: Select content on Tv/SIB, complete A, ftC and purchase transaction on mobile device, consume 8 Yes A B others content on those two specific devices and one or more other specifically enumerated devices Example: Select content on Tv/SIB, complete B, C and purchase transaction on mobile device, consume 9 Yes A B others, but content on that mobile as well as one or more other NOT A specifically enumerated devices excluding the Tv/STB Example: Select content on Tv/SIB, complete C and others, purchase transaction on mobile device, consume Yes A B but NEITHER content on one or more other specifically A NOR B enumerated devices excluding the Tv/STB and mobile used in selection and purchase respectively Assodaton of Devks Implicit in Table 1 is the need for the consumer to select both the content (or rather, the rights objects) to be purchased and the device or devices on which that content is intended to be consumed and for which licences in the form of rights objects must be generated and delivered.

In some scenarios (see cases 1 and S in the table), the device selection is implicit in that the consumer is buying rights to consume content on the very same device used to select the content.

In other scenarios (2-4 and 6-10), the consumption is intended for one or more other devices beyond that used to select the content. Therefore, some other mechanism is necessary to associate the devices. This could be done either at the time of or in advance of the transaction. Further, it can be done directly (enumerating specific devices) or indirectly (by locking the licences to an user account that contains the list of devices). The account could be a mobile SIM card, a Facebook account, a cable/satellite TV subscription, a retail store membership, a credit card, etc. In one embodiment, there exists a user account in which the consumer registers or otherwise uniquely enumerates all his devices in advance of any content purchase transactions. This information is stored and used to facilitate ease of transactions. During the selection process, the consumer is able to choose one or more registered devices on which he intends the content to be consumed. Both Apple iTunes and Google Play implement similar ideas.

The important distinction and advantage of this invention is that neither the selection nor purchase devices is required to be among the devices on which the content is intended to be consumed. This invention is, in this regard, a superset of the iTunes and Google Play store models.

Descdption of Bask Eements of the M&ii Embodhnents Refer to Figure 1.

The functional elements are: 1. Consumption Device -Typically a consumer electronic device (e.g. a mobile device) for which a consumer seeks to obtain some digital content and the usage rights to consume that content thereon.

In this document, a "consumer electronic device" includes any typical electronic computing device with some means of input, display, memory, and processing elements. Such devices may also have one or more forms of wired or wireless connectivity to the Internet, web, or other devices. Common examples include: mobile phones, cordless phones, navigation devices, personal computers, tablet computing devices, TVs, set-top boxes (DVD, Blu-Ray, cable boxes, fiber-optic connected boxes, IPTV boxes), and the like.

The expression "consume" in relation to digital content means to use the content in some way, for example by executing computer code or by viewing or operating on data. The expression extends to storing the content and to forwarding the content for later storage or use. Finally, it extends to the use of any type of digital service.

2. Purchase Device -A device a consumer may use to execute a financial purchase or other transaction, e.g. with a network-connected store or payment proxy thereof. The actual transaction may take place on that device or elsewhere.

3. Content Store -A network-connected store from which a consumer may obtain digital content and purchase various rights to use that content.

4. Content Rights Server -This is a server that generates Rights Objects based on data provided by the Content Store and for which that Store indicates that financial part of the transaction was executed (even if the transaction was "free-of-charge").

5. Payment Server -This is a server with which the Content Store communicates and which executes the actual financial part of the purchase transaction. In practice, this might be the same server as the store, a different server operated by the same company as the Store, or a party who's payment processing services are contracted by the Store.

6. Pending Transaction Server -A server that stores information about request, purchase, and fulfilment of transactions related to digital content and/or services. Further, it supports APIs and messaging protocols necessary to interact with other servers and devices that make use of its services.

7. Pending Transaction Record -This is the set of data (possibly a database record in practice) that comprises al the items of data required to describe the state of the pending transaction, e.g. the content to be purchased, the price, and the like.

8. Pending Transaction ID -This is a unique ID (possibly a database key in practice) that uniquely identifies a pending transaction such that it can be retrieved and completed in a session separate from the initial one.

9. Pending Transaction Code -This is a string of characters or other data that identifies a specific Pending Transaction ID, and which a consumer may be required to input on the page served at the Pending Transaction URL The combination of the URL and the code are required to progress the pending transaction.

10. Pending Transaction URL or code -This is a URL or code to which the consumer is directed to complete a pending transaction. In practice, this could be implemented in many ways including: I) a traditional text URL, ii) a hyperlink in an email or text message or similar, or iii) a QR Code or other kind of visual barcode representation. In some cases the consumer may be required to enter the PendingTransaction Code manually, while in other cases it may be encoded implicitly into a hyperlink, QR code, or other representation.

11. Digital Content -Includes all types of non-physical content such as movies, games, music, wallpapers, ringtones, e-books, documents, themes/templates, computer programs, and the like for consumption on one or more consumption devices.

12. Rights Object -A well-defined digital package containing data that i) enumerates the "usage rights" to be conferred on some specified digital content or service, and ii) is authenticable through some means.

Typical examples of usage rights for content or services include but are not limited to the right to consume the content and/or access the service: i) on one or several devices, ii) once or a predefined number of times, iii) for a limited or unlimited cumulative or calendar time, iv) up until some content-specific criteria is met, e.g. reaching a specified level in a game or redeemingten digital coupons, etc. Typical methods for authenticating digital Rights Objects include but are not limited to cryptographic digital signatures, online identity verification, biometrics, etc., however only the optional presence of and not the details of such authentication is part of this invention and its claims.

tracton Between ard Among the Eements In the processing sequence shown in Table 2, the steps are labelled to correspond to certain use cases. In each case, the numbers indicate the step in the sequence and the letter suffix indicates the use case. Those steps with no letter suffix apply to all use cases.

Refer to Figure 2 for an illustration of the sequence of processing events enumerated in Table 2.

Table 2-Nocesd SeqLence for Varous Use Cases Transaction Step Entity Action Part IA Starting In this scenario, the consumer DOES already have content on the device for which Conditions he seeks to purchase usage rights.

using the consumption Device, the consumer navigates ul presented by the content or some associated software, and interacts to indicate his intent to Selection purchase usage rights for this content. Typically, he would click the "Buy" button Part or some equivalent action.

This action causes the ul of the device to present the consumer with a set of information describing the usage rights that are available to be purchased, and the corresponding descriptions and pricing information.

lB Starting In this scenario, the consumer does NOT already have content or the device. He Conditions seeks to both obtain the content and purchase the corresponding usage rights.

Using the UI of the Consumption Device, the consumer browses content available in the Content Store to the point where he is presented with a set of information describing the content and/or the usage rights that are available to be purchased, optionally including other information such as pricing.

2 Consumer Select desired item(s) (content and/or usage rights) and submit request to purchase.

Note that the selection(s) made at this point might not fully or uniquely describe the totality of item(s) to be purchased. The consumer may have another opportunity to further refine his selection(s) in a later part of the transaction.

3 Consumption Encode and send to Content Store information including: Device * Purchase Request Descriptor: When fully formed/filled, this uniquely identifies the content and/or usage rights selected by the consumer for purchase, i.e. the bits the consumer wishes to purchase. At this point, the Descriptor might be only partially formed/filled.

* Device Content Configuration Descriptor: Identifies specific information about the Consumption Device necessary to generate/retrieve and deliver the correct content and/or usage rights.

* Device Transaction Capability Descriptor: Information necessary to determine whether the Consumption Device is suitabe for executing the payment portion of the transaction 4 Content Store Using information provided, determine if the Consumption Device is suitable for completing the payment portion of the transaction. This might happen as a matter of factual analysis of the capabilities of the Consumption Device, by query of preconfigured user device or account settings, or by simply asking the consumer whether he wishes to execute the payment part of the transaction on the Consumption Device. He may simply wish to execute and finalize the transaction on a separate device because he wishes to also purchase content and/or usage rights for more than one device and have them all grouped into a single payment transaction.

If YES, then STOP. The consumer will complete the transaction on the Consumption Device.

If NO, then CONTINUE. The consumer will use a different device to complete the transaction.

Content Store Send information provided to the Pending Transaction Server 6 Pending * Note: in some embodiments, the Pending Transaction Server Transaction functionality could be implemented as part of the Content Store, Server however it is shown here as a separate entity.

* Construct a Pending Transaction Record from the information provided * Store this Pending Transaction Record in the Pending Transaction Database.

* Assign a unique Pending Transaction Record Identifier to the Pending Transaction Record.

* Associate this specific Pending Transaction Record with a Pending Transaction URL and a unique Pending Transaction Code.

* Send the Pending Transaction URL and Pending Transaction Code to the Content Store 7 Content Store * Send the Pending Transaction URL and Pending Transaction Code to the Consumption Device.

S Consumption * Display the Pending Transaction URL and Pending Transaction Code Device along with a message instructing the consumer to navigate to that URL on another device, the Purchase Device, which is suitable for completing the purchase. Such a device would typically have richer, more interactive UI capabilities such as would be found on a PC tablet Payment Part or smartphone.

* NOTE: in an alternate embodiment, the Content Store could use its own stored account information about the consumer, such as an email address or mobile phone number, to send the Pending Transaction URL and associated Pending Transaction Code to the consumer by electronic means, thereby freeing him from the need to manually input that information. In this case, the Pending Transaction Code could be provided as a parameter of the Pending Transaction URL.

* NOTE; in another alternate embodiment, the Content Store could generate a visual representation of the Pending Transaction URL and/or the Pending Transaction Code such that it can be automatically entered on the Purchase Device using some software installed on that device.

An example of such an approach would be to use OR codes and appropriate QR code reading application on the purchase device. In such an embodiment, the Pending Transaction Code would typically be encoded into the visual representation, thereby freeing the user from the need to manually input that information.

* NOTE: in another alternative embodiment, the Purchase Device could communicate with the Consumption Device to transfer the Pending Transaction URL and Pending Transaction Code so that little or no user interaction is required to continue the purchase process on the Purchase Device. An example of such an approach would be to use a short-range networking technology such as Bluetooth, Wi-Fi or NFC to transfer this information.

9 Consunier * On a Purchase Device, navigate to the Pending Transaction LJRL using or User the browser or another application that can navigate to, display, and allow the consumer to interact with the page(s) served by that URL.

* If not already provided as part of the Pending Transaction URL, the user would be required to manually input the Pending Transaction Code.

Follow the on screen instructions to complete the purchase transaction.

As part of these on-screen instructions, the consumer may be presented with the opportunity or requirement to make additional selections to fully or further define the item(s) (content and/or usage rights) to be purchased. Generally, upon completion of this step the Purchase Request Descriptor (that was fully or partially populated instep 2) must be fully formed/filled and uniquely define one or more pieces of content and the corresponding usage rights to be purchased.

The Purchase Request Descriptor might be populated with some data that not only comes directly from consumer input, but rather from a database that already contains information about the consumers devices, preferences, etc. For example, he might at this point choose to buy the usage rights for all of his devices that are associated with an online account, say, cr for a device of a friend.

Purchase Send the payment information to the Content Store. This rriav be explicit, such as Device credit card information, or implicit, such as charging to the consumers mobile prepaid or post-paid account.

11 Content Store * Complete the payment transaction with the Payment Server.

* After successful completion of the payment transaction, send the corresponding Pending Transaction Record (or a subset thereof) to the Content Rights Server.

* NOTE: In an alternate embodiment, the Content Store could provide Pending Transaction Record Identifier to the Content Rights Server to that the latter could retrieve the Pending Transaction Record (or a subset thereof) directly from the Pending Transaction Database.

12 Content Rights * Using the information provided by the Content Store, generate one or Server more appropriate Rights Object(s) to encapsulate the purchased usage rights tied to the specific content and the selected rights usage constraints.

* Deliver the Rights Object the to Content Store (2) 13A Content Store * Deliver the purchased Rights Object to the Consumption Device.

* Note: this delivery maybe realized through either push mechanisms or pull mechanisms between the Content Store and the Consumption Device.

14A Consuniption Apply the delivered Rights Object either invisibly or interactively as appropriate Fulfilment Device for the UI implementation on the Consumption Device. Part

13B Content Store * Deliver the purchased Content and Rights Object to the Consumption Device.

Note: this delivery may be realized through either push mechanisms or pull mechanisms between the Content Store and the Consumption Device.

Consuniption Install the content and apply the delivered Rights Object either invisibly or interactively as appropriate for the UI implementation on the Consumption Device Device.

Consunier Consume the content in accordance with the usage right purchased and conferred hy the Rights Ohject and enforced hv the on-device Rights Management Client.

Further Details of One Preferred Embodment In this embodiment, the Consumption Device is an internet-connected television or set-top box, and the Payment Device is a Smartphone, tablet or personal computer. In this embodiment, all cDmmunication between devices and servers and between different servers is performed using the HTTP 1.1 protocol, as describe in RFC 2616 The user chooses the specific purchasable item being purchased on the Consumption Device.

1. The user activates a user-interface element on the Consumption Device indicating that he wishes to purchase certain usage rights.

In one sub-embodiment, this user-interface element may be within the software application whose functionality is being extended by the purchase. In another sub-embodiment, the user interface element may be within a separate software application, such as a web-browser or other content-discovery software.

2. A user-interface is presented to the user at this point (either in the same software application or in a different one) allowing them to select from the available purchasable items (each item corresponding to a specific set of content, and usage-rights for that content); pricing information is displayed within this user-interface.

Typically, the set of available purchasable items is determined by retrieving information from the Content Store. See Figure 3 for details of the interaction between the Consumption Device and the Content Store at this point.

3. The user selects the specific purchasable item that he wishes to purchase.

4. The software on the Consumption Device transmits information to the Content Store, as shown in Figure 4. This includes the Purchase Request Descriptor (which describes the content and usage-rights selected for purchase by the user), the Device Content Configuration Descriptor (which contains information about the device necessary for producing the correct content and/or usage rights), and the Device Transaction Capability Descriptor (which contains sufficient information to allow the Content Store to determine whether the Consumption Device is suitable for executing the payment portion of the transaction).

5. A number of sub-embodiments could be envisaged for the contents of the Device Transaction Capability Descriptor, including: * A description of the software and hardware capabilities of the device, allowing the Content Store to determine whether the Consumption Device is capable of executing the payment portion of the transaction.

* A device model identifier, allowing the Content Store to determine simply by looking in a database whether the Consumption Device is capable of executing the payment portion of the transaction.

* A pre-configured value selected when the software developed for the Consumption Device, based on manual analysis of the capabilities of the device, which explicitly tells the Content Store whether the device is capable of executing the payment portion of the transaction * A value selected by the user of the Consumption Device indicating his preference for whether the Consumption Device should be used for the payment portion of the transaction or not.

In the embodiment being described here, a device model identifier is used as the Device Transaction Capability Descriptor.

6. The Content Store determines (in this embodiment) that the Consumption Device is not suitable for use during the payment portion of the transaction, and so it sends the information provided by the Consumption Device to the Pending Transaction Server.

The Pending Transaction server creates a Pending Transaction Record in its database, and returns a Pending Transaction URL and a Pending Transaction Code that uniquely identifies this specific transaction from the set of currently pending transactions. See Figure 4 for details of this interaction.

7. The Content Store responds with data (see Figure 4 for details) indicating what the available purchase methods are for the Consumption Device. In this embodiment, the data is in the form of an HTML page giving the user one or more choices of how they can purchase the content.

In this embodiment, the Consumption Device is not suitable for being used for the payment portion of the transaction, so the only option is to complete the purchase using a separate device. In other embodiments, this could be one of a number of different options, including the ability to complete the purchase on the Consumption Device.

The Pending Transaction Code returned by the Pending Transaction Server is included in the data returned by the Content Store, and is displayed to the user along with instructions about how to use it.

In this preferred embodiment and the Best Mode of implementation, the Pending Transaction URL and Pending Transaction Code are made available to the user in a number of different ways simultaneously: * Text telling the user to go to a particular URL and enter the code * A QR-code which the user can scan with their Smartphone or other device to go directly to the Pending Transaction URL with the Pending Transaction Code embedded within it * An email sent to the email address for the user account to which the Consumption Device is registered (if any), containing a link directly to the Pending Transaction URL with the Pending Transaction Code embedded within it.

* If the Consumption Device and the Purchase Device support it, the Pending Transaction URL and Pending Transaction Code can be transferred from the Consumption Device to the Purchase Device using a short-range networking technology such as Bluetooth, Wi-Fi or N FC.

By accessing such a QR-code or email on the Purchase Device or by transferring the information using a networking technology, the requirement to manually enter the Pending Transaction URL and Pending Transaction Code are removed, so these mechanisms are preferred. However, showing the user textual instructions is a necessary fallback mechanism to make the invention as widely applicable as possible.

8. The user uses one of the mechanisms described above to access the Pending Transaction URL and Pending Transaction Code in a suitable software application on the Purchase Device. In this preferred embodiment, a web-browser is used.

9. The information stored in the Pending Transaction Record is transferred to the Payment Server and the user is directed to the Payment Server, where he is presented with the purchasable item that he selected earlier, along with the information from the Device Content Configuration Descriptor containing information about the Consumption Device. See FigureS.

10. The user enters their payment information using whatever payment provider is appropriate. In this embodiment, the payment provider is PayPal. The payment transaction involves redirecting the user's web browser to PayPal's website where the user enters their username and password, and approves the transaction. Once this is complete, the user is redirected back to the Payment Server and the Payment Server is notified that the transaction has completed successfully. See FigureS.

Many other payment providers could be envisaged in other embodiments, including payment via the user's Smartphone pre-paid or post-paid account, etc. 11. The Content Store is notified that the purchase transaction is complete, and it sends information from the Purchase Request Descriptor and the Device Content Configuration Descriptor to the Rights Server, which generates one or more Rights Objects encapsulating the content and usage-rights selected by the user earlier. The resulting Rights Objects are delivered to the Content Store. See Figure 6 for details.

Typically these usage-rights lock the resulting Rights Object to a small set of devices. They may also restrict the validity period of the usage rights, etc. In this embodiment, a single Rights Object is generated which allows usage of the content only on the Consumption Device.

12. The Content Store delivers the Rights Objects to the Consumption Device. In this preferred embodiment, the web browser on the Consumption Device uses Javascript to poll for the transaction completing, using the Pending Transaction Code, and automatically downloads the resulting Rights Objects once they become available. See Figure 6 for details.

13. The Consumption Device applies the delivered Rights Objects either invisibly or interactively as appropriate for the user-interface implementation on the Consumption Device.

Claims

CLAIMS1. A transaction mechanism for digital content comprising: (a) on a first device, selecting digital content to which user access is required; (b) on a second device, submitting credentials to authorise a financial transaction to unlock user access to the content; (c) after completion of the transaction, supplying a use authorisation to a consumption device; and (d) on the consumption device, unlocking the content with the use authorisation, and consuming the content.
2. A transaction mechanism as claimed in claim 1 in which the consumption device is the first device.
3. A transaction mechanism as claimed in claim 1 in which the consumption device is the second device.
4. A transaction mechanism as claimed in claim 1 in which the consumption device is a third device.
5. A transaction mechanism as claimed in any one of claims ito 4 including providing a pending transaction system which stores transactions in progress, and which directs the user, after selecting the content on the first device, to a credential-submission interface on the second device.
6. A transaction mechanism as claimed in any one of the preceding claims in which after completion of the transaction the content is downloaded from content store to the consumption device.
7. A transaction mechanism as claimed in any one of the preceding claims in which the use authorisation comprises an authenticable digital rights object.
8. A transaction mechanism as claimed in any one of the preceding claims in which selecting of the digital content is carried out via a user account, the account including details of the second device or a plurality of second devices from which the user chooses either explicitly or by default.
9. A transaction mechanism as claimed in claim Sin which the user account includes details of a third device or a plurality of third devices from which the user chooses either explicitly or by default.
10. A computer-readable medium or a plurality of media storing instructions which, when executed on a computer, enable a user to carry out a transaction mechanism method as claimed in claim 1.