HK1113608A - Centralized management of digital rights licensing - Google Patents

Description

Centralized management of digital rights licenses

Cross Reference to Related Applications

This application claims priority from U.S. provisional patent application No. 60/607,045 filed on 3.9.2004. It relates to PCT/US2004/002356 filed on 28/1/2004, U.S. patent application No. 10/726,284 filed on 2/12/2003, and U.S. provisional patent application No. 60/444,581 filed on 3/2/2003, all of which are incorporated herein by reference.

Technical Field

The present invention relates to digital rights management, and more particularly to facilitating authorized licensing and distribution of digital media.

Background

The music industry is centered on a tremendous chaos. For decades, music companies have controlled the physical distribution of the content that it creates. Consumers have historically been given the first time a tool that allows them to take control over the distribution of such content. The rapidly evolving and widely adopted technology has led to this now consumer driven destructive change. Countless legal and illegal solutions have proven to be poor attempts to answer and solve the innate challenges of content distribution in the digital world. While the problem of digital content distribution may be associated to a great extent with the music industry, other industries, such as the movie industry, suffer from the same challenges.

No solution to date has satisfied both content creators/owners and consumers. The only digital distribution scheme that is widely adopted can be found in various peer-to-peer networks. However, this solution allows millions of consumers to download music and other forms of copyrighted content without paying for the content they download. The content owner has no ability to levy a fee to be paid to it. This situation causes a disruptive loss of revenue.

Many content authoring entities, such as music companies, recognize that digital distribution will be in the future by signing up for digital subscription services and the like. This is the most efficient and economical means of distribution. To date, the music industry has not fully captured the potential of such distribution tools. Digital distribution is also becoming popular in other industries and for numerous types of content. In the context of other types of content, problems similar to those faced by the music industry have occurred or may occur.

Current digital distribution models in the music industry, for example, limit consumers to manual purchase patterns, which tend to limit competition, have limited song choices, and are limited in other options available. Moreover, these models generally limit how consumers use the content they pay for, and some models may not protect against infringement in the underlying work.

SUMMARY

In one general aspect, license rights in digital media are managed by storing digital media license records associated with multiple user identities. The license record for each user identity may be accessed from the remote device using the first authentication credentials corresponding to that user identity. A digital media license is provided for purchase using the second authentication credential. The particular second authentication credential is associated with the first authentication credential corresponding to the particular user identity. A record of digital media licenses purchased using a particular second authentication credential is stored in association with a particular user identity based on an association of the particular second authentication credential with a first authentication credential corresponding to the particular user identity.

Implementations may include one or more of the following features. The first authentication credentials and the second authentication credentials for each user identity each include a username and a challenge response. The digital media license record includes parameters of the license and/or a digital media file identifier. A plurality of device identifiers associated with a particular user identity are stored, and licenses for digital media identified by license records for the particular user identity allow the digital media to be used on devices having one of the device identifiers. The license record includes data identifying digital media found on a device associated with the user identity. The first authentication credential is associated with a central server and the second authentication credential is associated with a retailer server. The central server stores rules defining revenue allocations among a plurality of entities for purchasing digital media. If the purchase of the digital media license using the second user identity is made in response to a reference to the second user identity by the first user identity, a debit is assigned to an account associated with the first user identity in response to such purchase.

In another general aspect, digital media license records associated with a plurality of user identities are stored. Data is received identifying a first purchase of a first digital media license from a first retailer entity. The data includes information sufficient to identify a particular user identity associated with the first purchase. A record of the first purchase associated with the particular user identity is stored in the digital media license record. Data is received identifying a second purchase of a second digital media license from a second retailer entity. The data includes information sufficient to identify a particular user identity associated with the second purchase. A record of the second purchase is stored in the digital media license record in association with the particular user identity.

Implementations may include one or more of the following features. The first purchase and the second purchase are each made using the particular user identity. The record of the first purchase includes an association of the digital media license for the first digital media with a particular user identity, and the record of the second purchase includes an association of the digital media license for the second digital media with the particular user identity. The first purchase and the second purchase are made in response to an introduction made using a particular user identity. The record of the first purchase and the record of the second purchase include a debit against an account associated with the particular user identity. The rebate may be used to make a purchase of a digital media license via the first retailer entity and/or the second retailer entity. Each of the first retailer entity and the second retailer entity is provided access to the record. Revenue from the purchase is allocated among the first retailer entity, the owner of the digital media, an entity associated with the central server. The first retailer entity and the second retailer entity each have a separate digital media catalog for purchase.

In yet another general aspect, one or more retailer servers may be used to provide digital media licenses for purchase using retailer-specific authentication credentials associated with a particular user identity. The central server stores digital media license records associated with a plurality of user identities. The license record for a particular user identity may be accessed from a remote device using primary authentication credentials associated with the particular user identity. The license record for a particular user identity may be automatically updated to include a record of digital media licenses purchased using the retailer-specific authentication credentials associated with that particular user identity.

Implementations may include one or more of the following features. The central server stores rules defining revenue allocations among at least an operator of each retailer server and an operator of the central server. Each retailer server may be used to retrieve information from a digital media license record associated with a particular user identity. The central server stores data identifying deductions earned by a particular user identity for purchases made using other user identities, and the purchases are associated with referrals made using the particular user identity. Each retailer server may be used to support the transfer of licensed digital media files using a particular user identity.

In another general aspect, each of a plurality of retailer servers can be used to provide digital media licenses for purchase, and each retailer server includes a separate digital media catalog. The central server may be used to store digital media license records associated with a plurality of user identities, and the license records for a particular user identity include a record of digital media licenses purchased via a first one of the retailer servers and digital media licenses purchased via a second one of the retailer servers.

Implementations may include one or more of the following features. The central server supports a security mechanism for limiting the use of digital media files without a digital media license. The central server provides access to the digital media license record from the retailer server. The central server stores rules for revenue allocation among at least an operator of the central server and an operator of a retailer server via which revenue-generating purchases were made. The central server stores data defining revenue assigned to each of an operator of the central server and an operator of the retailer server.

Brief Description of Drawings

FIG. 1 is a block diagram of a representative system for managing and distributing digital rights.

FIG. 2A is a signaling and flow diagram of a process for purchasing and storing media file licenses.

FIG. 2B is a signaling and flow diagram for purchasing and storing media file licenses from different retailer servers.

Fig. 2C is a signal transmission and flow diagram of a process for earning and storing referral deductions.

FIG. 3 is an example of a user interface that may be used to purchase media file licenses.

FIG. 4 is a flow chart of a process for managing digital rights to a file loaded on a user device, such as a computer.

FIG. 5 is a flow chart of a process for installing software on a user device that controls access to protected files ("solution software").

FIG. 6 is a flow chart of a process for packaging content that does not have any digital packaging at the time of arrival on a user device that includes solution software.

Fig. 7 is a signaling and flow diagram of a process for generating a unique customer identifier for a user and/or a user device-specific key.

FIG. 8 is a signaling and flow diagram of a process for accessing a media file in the event that the user already has a license for the media file.

FIG. 9 is a signaling and flow diagram of a process for accessing a media file in the event that the user does not have a license for the media file.

FIG. 10 is a signaling and flow diagram of a process for copying or moving a media file from a user device to a second device.

FIG. 11 shows a flow diagram of an illustrative process for performing delivery distribution.

FIG. 12 is a flow chart of a process for packaging media files.

Like reference symbols in the various drawings indicate like elements.

Detailed Description

The systems and techniques described here relate to a computer-implemented system for distribution and rights management of digital media files. The system and techniques represent an end-to-end process that supports virtually any type of proprietary digital document, including music and other recordings, movies and other videos, books and other written works, and other documents such as those related to the financial, legal, medical, gaming, and software industries. Although the following description focuses primarily on the use of the technique in connection with music files, the technique is equally applicable to other types of digital files. Similarly, although the techniques are described in the context of media files, the techniques may also be used in connection with multimedia files and other types of data files. The systems and techniques ensure that content owners will be compensated for the distribution and use of their works and provide a multi-level share in the revenue generated by the sale and/or licensing of digital media.

Digital media licenses and electronic copies of digital media are distributed by a retailer network using a license and distribution management infrastructure provided by a central licensing server. Each retailer has its own independent digital media library or catalog from which the user can select a digital media license to purchase. The digital records relating to the digital media licenses are stored in a central database associated with the central licensing server. These data records, for example, identify which digital media files each user is permitted to access and use. A user may purchase a license for a media file from one or more retailers and may have a centrally managed database that identifies all of the licensed media files.

Typically, each retailer has an independent authentication process using each user's retailer-specific username and password. In addition, each user has a separate username and password for accessing the user's data record maintained by the central licensing server. By associating each retailer-specific username with the username of the central license server, digital media licenses purchased by the retailer can be recorded in the central license database. In some implementations, such an association may be required, for example, to implement a security mechanism that allows users to access or use digital media files for which they have purchased licenses. Each retailer may be provided with proxy access to the digital media license database, for example, to allow the retailer to display the user's own media file license library to the user.

Digital media is typically distributed to users' computers or other devices in a "packaged" form. The media rights owner has the ability to package the file with information about ownership and payment. This information is given a unique file ID and stored in a central database. The document ID is stored and transmitted with the package. Unpackaged songs or other forms of digital media may also be identified. Once the file is captured and identified, information such as the owner and payment requirements may be retrieved (e.g., by matching the identified file to its unique file ID stored in the central database). Software on a computer or other device is used to control access to the packaged file by determining whether a user has a license for the digital media contained in the packaged file.

A user ID is created for each user. The user ID may be the same as the user's username, or may be a separately created identifier. The user ID is stored with the device-specific information in a secure area on the computer, such as in the BIOS of the computer. The user ID may be stored in an encrypted or unencrypted format. This information may represent a user identification key that may allow access to a local database of licenses and associated licenses held by the user. By referencing the local license database, the software stored on the computer can determine whether the user is authorized to use a particular file and, if so, open a wrapper for that file. Because users typically have multiple devices and to protect against accidental loss of license data, information about the user's licenses is stored centrally to ensure that the user has access to all licensed media on more than one device, and to provide redundant license storage.

A user may be an individual or a group of related individuals such as a family, a family member, an individual accessing a shared private device, or a business entity. Further, when information is described as being stored in a database, the information may be stored in multiple databases.

The files may be forwarded to other users and exchanged among the users. However, if the file requires a license and the new user does not purchase the media file, the new user does not gain access to the file. To encourage distribution of the files, users are given an incentive to introduce or electronically transmit the media files or links to the media files to others who they find likely to be interested in the media files (i.e., potentially receiving a portion of the revenue generated by the new purchaser). Recipients are given an incentive to purchase a media file (i.e., have access to the file) and further introduce the media file so that they may share in revenue. The number of distribution levels in which revenue is allowed to be divided may be unlimited. However, in general the number of distribution levels in which revenue sharing is allowed will be limited. The payment progression for a particular media file may optionally be established by the content owner and/or subsequent distributor of the media file. The maximum number of payment levels and the rate of such payments may be established when creating a unique file ID for a media file and a payment rate. If the new user does not grant the media file, he/she will not gain access to the file, although he/she may be able to pass the file to other users for purchase.

Information about the deductions each user has earned via introductions to other users is stored in a central licence database. These rebates may be applied to purchases to any of the various retailers. In addition, the central licensing server maintains rules regarding the distribution of revenue generated via the sale of digital media licenses. Revenue is typically divided among the owner of the digital media (e.g., the record company that owns the rights to the song), the retailer making the sale, the operator of the central licensing server, and in some cases one or more referring users.

Whenever a sales transaction occurs for a particular media file, information of the retailer and/or user in the distribution channel is extracted from the media file to determine who is eligible to share revenue. All transactions can be tracked centrally for payment and analysis. The central licensing server may be used to track payments made to retailers, distributors (which may include users introducing media files), and users delivering files that arrive without packaging. The latter case may occur, for example, when a user shares a song that originates from a standard audio CD or DVD.

A license for a file may be identified across multiple devices of a user. The methods and techniques described herein provide processes for selling, distributing, and managing licenses for use of digital media.

FIG. 1 is a block diagram of a representative system 100 for managing and distributing digital rights. User device 105 includes a processor 110 that executes instructions stored in memory 115 and/or other storage media (not shown) connected to user device 105. The user device includes a BIOS (basic input/output system) 120 or some other non-volatile memory that stores basic information about the user device 105. The user device 105 includes one or more I/O ports 125 that allow files and other data to be moved and/or copied onto or from the user device 105 (as indicated at 130). For the purpose of identifying protected (e.g., copyrighted) music, video, software, and or other files, the processor 110 monitors files and other data passing through the I/O port 125 according to instructions stored in the memory 115.

The memory 115 includes a local database 135 that stores license information for files licensed for use on the user device 105. Access to the local database 135 or information contained in the local database 135 typically requires that some installed software decrypt and use one or more keys stored in the BIOS 120. Such keys are unique to the user and/or user device 105, and the process for accessing the local database 135 is designed so that the keys and/or license information stored in the local database 135 are valid only for the particular user device 105. For example, if a user attempts to make an unauthorized copy of the key and/or license information on another device, access to files licensed on the user device will be denied on the other device unless a new unique key is generated for the other device and the license information is stored thereon. License information on a particular device may be updated in the future to update usage rights or remove access rights to one or more files. One example of the ability to need to perform such an update is to revoke permissions from the old computer.

User device 105 communicates with central server 140 via network 145, which network 145 may include one or more of a wireless network, a LAN, a WAN, the internet, a telephone network, and any other network for communicating data. Communications between the user device 105 and the central server 140 may be performed using a secure channel such as Secure Sockets Layer (SSL) and/or may be encrypted using an encryption such as PGP. The central server 140 provides services that support the digital rights management system 100, such as generating keys at least partially using information transmitted from the user device 105 via a secure connection and validating the keys and license information periodically or when attempting to license new media. In addition, the central server 104 provides access to a central license database 150 that stores and identifies licenses held by individual users and stores key validation information. The storage of license information in the central license database 150 allows for redundancy (e.g., to prevent corruption in the volatile storage area of the user device), allows for the re-creation of a licensed data environment on another device, allows for the transfer of licenses between user devices, allows a user to remotely access license information using a device that does not have a volatile storage area (e.g., some type of cell phone), and allows for the streaming of licensed digital files.

The central license database 150 may also store information identifying media files discovered on the user device 105 by software installed on the device 105 (e.g., files that already exist in the device memory before the software that discovered the files was installed on the device). In some implementations, such files may be assumed to be licensed, at least to the device 105 on which they are located. However, restrictions may be placed on its use, such as by requiring a license to be purchased before allowing the file to be transferred or copied to other devices.

For certain types of user equipment 105, such as certain cell phones, certain functions may be performed by components that are remote from the user equipment. Some handsets, for example, may not have storage capability to store files and license information locally, or may not want to do so, depending on the application. In such a case, digital files (such as, but not limited to, music or video) may be streamed to the user device via the wireless connection. The local database 135 may be located in the wireless network and the process of determining whether the user device has a license to access a particular file may also be performed on a server in the wireless network.

The user device 105 is also able to communicate with one or more retailer servers 155(1) -155(n) that each provide the ability to download media files from their respective media file libraries 160(1) -160(n) of the retailer server 155 and the ability to purchase licenses to use those media files. The media file library 160 of each retailer server 155 is independent of the media file libraries of the other retailer servers 155. Thus, each media file library 160 may have a different set of media files, although in some cases there may be a substantial degree of overlap, if not complete, of the media files contained in the different media file libraries 160. This may occur, for example, when two different retailers are authorized by a particular record company to sell the same song file.

Each retailer server 155 may be implemented as a web server accessible using an internet address. The user may thus access the retailer server 155 via the user device 105 by directing the browser application on the user device 105 to the internet address associated with the retailer server 155. The user device 105 may then communicate with the retailer server 155 to request and retrieve a web page listing media files available for purchase; displaying licensing terms, conditions and pricing; providing a search capability; allowing the user to log in; and so on.

To purchase a license to use a digital media file and download the file, each retailer server 155 typically requires the user to log in via a conventional authentication process. The authentication process may authenticate the user using, for example, a username and password, some other challenge response, and/or other authentication credentials. Further, at least initially, the user may be required to further log into the central server 140 using a separate authentication process used by the central server 140. By logging onto the central server 140 at the same time as logging onto the retailer server 155, the retailer-specific authentication credentials can be associated with the authentication credentials of the central server 140, allowing licenses purchased via the retailer server 155 (i.e., using the retailer-specific authentication credentials) to be identified and stored according to the user identity (i.e., the user's central server authentication credentials) in the central license database 150 associated with the central server 140. This association of the retailer-specific authentication credentials with the central server authentication credentials may be performed for a plurality of different retailer servers 155 such that purchases made by users from different retailer servers 155 are each identified and stored in the central license database 150. A record of purchased licenses may also be stored in the local database 135.

The central server authentication credentials may also be different from the key stored in the BIOS 135. In particular, keys may be used by software installed on the user device 105 for the purpose of ensuring that media files have been licensed before access is allowed, while authentication credentials may be used for the purpose of allowing the user to access and display a list of licensed media files, license terms, introduction deductions, and other information stored in the central license database 150.

In general, the central server 150 is responsible for license management and protection against unauthorized access and use of digital media files, while the retailer server 155 is responsible for allowing users to purchase media file licenses and download media files. However, in some cases, the central server 140 may also provide retail services. For example, the central server 140 may not provide the ability to download media files, but may allow users to purchase licenses to access and use digital media files obtained via other channels (e.g., unlicensed files obtained via a peer-to-peer network and/or via the I/O port 125). Similarly, retailer server 155 may provide certain license management functions. For example, the retailer server 155 may access and/or retrieve particular user license data from the central license database 150 and may allow the user to view and/or process the license data. However, in general, any changes made via the retailer server 155 relating to licensed media are copied to the central license database 150, which is responsible for maintaining the primary license record data. Changes to user accounts associated with the retailer servers 155 or to user accounts associated with the central server 140 can be maintained locally by the individual servers and not duplicated or accessed by other servers. Thus, the user may be provided with account management functionality by logging onto the central server 140 or retailer server 155 using the corresponding authentication credentials.

In addition to storing license record data such as file IDs and license range parameters (e.g., number of copies/devices allowed, license terms, etc.), the central server 140 and/or the central license database 150 may store information about the introduction made by each user. For example, a user may recommend to a friend or other user a particular media file that the user purchases from the retailer server 155 (or that the user is only found on a web page supported by the retailer server 155). The recommendation may be sent via email, instant messaging, or some other form, and may include information identifying the referring user. For example, when a user is authenticated using a particular retailer server 155(1), the web pages supported by that retailer server 155(1) (in addition to the user interface elements that allow the user to purchase the media files) may include user interface elements (e.g., buttons, check boxes, or data entry fields) that allow the user to introduce one or more selected media files to another user. As a result, another user may receive an email with a link to a web page supported by the particular retailer server 155(1) that allows the other user to purchase the media file. By introducing the media files in this manner, the introducing user may be assigned a rebate that may be used in future media file license purchases. The rebate is typically stored in the central license database 150, associated with the identifier of the referring user, and available for purchase to any retailer server 155. However, in some cases, the rebate may be stored by the retailer server 155 and/or may be used only in connection with purchases made by the retailer server 155(1) to which the rebate-causing purchase was made.

Once a particular user is authenticated by the retailer server 155, the retailer server 155 can retrieve from the central server 140 a deduction earned by the particular user from the introduction, assuming that the particular user has previously associated the user's retailer authentication credentials with the user's central server authentication credentials. Whether the purchase was made as a result of the introduction may be tracked by the retailer server 155 or central server 140 using data contained in the introduction link, by routing the introduced user via a particular internet address, or by correlating the introduction information stored in the retailer server 155 and/or central server 140 with subsequent purchases.

Information identifying which media files have been introduced by each user may also be stored at the central server 140. The user may log onto the central server 140 by authenticating the credentials with its central server in order to access and view such information. The retailer server 155 may access this information or may store the information separately, at least for media files originating from the respective retailer server 155.

To make a purchase to the retailer server 155, the media file provided by the retailer server 155 may be selected by the user and added to the online shopping cart. The user may add or remove various items, purchase a license for the selected media file, and save the contents of the shopping cart. Further, once a user purchases one or more media file licenses, the user can download the licensed media files at the same time as the purchase or at a later time (e.g., when the user has access to a faster connection or wants to download to a different device).

For the case where the user copies the media file to a different device, the central server 140 also stores information in the central license database 150 identifying which devices the user has registered. This information allows the central server 140 to determine whether the user has reached the maximum number of devices on which media files may be copied as defined by the license rules for each particular media file. In addition, this information may be used to limit the downloading of media files to devices registered or associated with a particular user. Information about which devices are associated with each user may be retrieved by the retailer server 155 from the central server 140.

The central server 140 also supports a set of rules regarding the assignment or distribution resulting from the sale of media file licenses. In the case of music files, the rules generally define the percentage or amount to be assigned to the record company, the operator of the central server 140, and one or more referring users. For example, for a sale of 99 cents ($0.99), a record company may be assigned 50 cents ($0.50), a central server 140 operator may be assigned 7 cents ($0.07), a first referring user may be assigned 10 cents ($0.10), and a second referring user (i.e., a user to whom the first referring user refers to a file, which in turn refers to a third user) may be assigned 3 cents ($ 0.03). The operator of the retailer server 155 making the sale may also be assigned a fixed amount (e.g., $0.29) or a balance (i.e., allowing the retailer to set a price that produces the desired profit margin). Alternatively, another entity may be assigned a balance. For example, if the retailer has a fixed assignment or if there is no introducer requiring an assignment, the balance may be assigned to the operator of the central server 140.

FIG. 2A is a signaling and flow diagram of a process 200 for purchasing and storing media file licenses. The user retrieves a web page from the first retailer server 204 using the first user device 202 (step 220). The web page may provide a listing of media files that may be purchased with first retailer server 204 or may provide search capabilities for searching for media files that may be purchased. Using the list or as a result of conducting a search, the user identifies and selects one or more media files that the user would like to purchase (step 222). For example, a user may add a media file to an online shopping cart. The user may then initiate a purchase of the selected media file (step 224). To complete the purchase, the user is requested to log into the first retailer server 204 (step 226). Assuming the user has not previously registered with the first retailer server 204, the user registers with the first retailer server 204 to establish a first retailer server login credential (step 228).

First retailer server 204 also requests the user to log into central server 206 (step 230). In this example, assume that the user has not previously registered with the central server 206. Thus, the user establishes a central server login credential (step 232), which may be performed via the first retailer server 204 or by redirecting the user to the central server 206 to obtain user registration information (step 234). Subsequently, the login to the central server 206 may be accomplished by obtaining the user's central server authentication credentials only at the first retailer server 204 or by redirecting the user to a web page associated with the central server 206. The first retailer authentication credential is associated with the central server authentication credential (step 236). This association may be performed at the first retailer server 204 or at the central server 206. For example, the first retailer server 204 may store the user's central server authentication credentials in a local user profile associated with the user's first retailer server authentication credentials. Alternatively, the central server 206 may store the user's first retailer server authentication credential in association with the user's central server authentication credential. Thereafter, the purchase via the first retailer server 204 may be attributed to the user identity at the central server 206 by sending at least a portion of the user's first retailer server authentication credentials (e.g., a user name) and data identifying the purchased media file to the central server 206.

First retailer server 204 requests payment information, such as a credit card (step 238). In response, the user submits payment (step 240) and the purchased media file license is delivered to the central server 206 and the first user device 202 (step 242), where the user's license data is stored in the central license database 208 (step 244) and in a local database of the first user device 202 (step 246).

FIG. 2B is a signaling and flow diagram of a process 214 for purchasing and storing media file licenses from different retailer servers. As in steps 220 and 222, the web page of the second retailer server 210 is retrieved (step 250) and the user selects one or more media files to purchase (step 252). The user initiates a purchase of the selected media file (step 254). To complete the purchase, the user is requested to log into the second retailer server 210 (step 256). In this case, assume that the user has previously registered with the second retailer server 210, so the user provides the second retailer server authentication credentials (step 258). It is also assumed that the user has previously associated a second retailer server authentication credential with the user's identity at the central server 206. Thus, the central server that identifies the user authenticates the credentials (step 260). The second retailer server 210 requests payment information (step 262). In response, the user submits payment (step 264), and the purchased media file license is delivered to the central server 206 and the first user device 202 (step 266), with the user's corresponding license data being stored in the central license database 208 (step 268) and in the local database of the first user device 202 (step 270). As a result, permission data corresponding to media file licenses purchased from two different retailer servers 204 and 206, each having its own independent authentication process, is stored in association with the same user identity at the central server 206.

Fig. 2C is a signal transmission and flow diagram of a process 272 for earning and storing referral deductions. The user on the first user device 202 sends a presentation of one or more media files to the user on the second user device 212 (step 274). For purposes of this example, assume that the presented media file is presented by the user of the first device 202 from two different retailer servers 204 and 210. The introduction may be made as part of a single message or other communication, or as part of different communications. The user on the second user device 212 performs a login and purchase of some of the introduced media file licenses from the first retailer server 204 (step 276), and the corresponding license data is passed to the central server 206 and the second user device 212 (step 278). The license data is stored in the central server license database 208 in an account associated with the purchasing user (step 280). The central server 206 also allocates revenue from the purchase (step 282), including identifying the referral made by the user of the first device 202 and allocating a debit to the account of the referring user. The assigned withholds are stored in the central license database 208 in association with the introductory user account (step 284).

The user on the second user device 212 also performs a login and purchase of additional introductory media file licenses from the second retailer server 214 (step 286), and the corresponding license data is passed to the central server 206 and the second user device 212 (step 288). The license data is stored in the central server license database 208 in an account associated with the purchasing user (step 290). The central server 206 also allocates revenue from the purchase (step 292), including identifying the referral made by the user of the first device 202 and allocating a debit to the account of the referring user. The assigned withhold is stored in the central license database 208 in association with the introductory user account (step 294). Thus, the referrer user may accumulate credits in a single account based on referrals to different retailer servers 204 and 210. Further, the withhold is generally available for subsequent purchases made to the first or second retailer server 204 or 210 or to some other retailer server in communication with the central server 206.

FIG. 3 is an example of a user interface 300 that may be used to purchase media file licenses. The user interface 300 includes a list of music files that satisfy certain search criteria. The user interface 300 includes a user interface component 305 for selecting music files, a user interface component 310 for initiating purchase of the selected music files, and a user interface component 315 for introducing the selected music files to one or more other users. For example, by selecting the user interface component 315 for introducing selected music files, another user interface may be displayed that allows the user to identify the user (e.g., email address) to whom each music file is to be introduced.

The central server described above may be used as part of a system designed to prevent unauthorized access to digital media files. For example, the central server may be used in conjunction with software on the user's device to authorize access to and use of media files for which the user has a valid license.

Fig. 4 is a flow diagram of a process 400 for managing digital rights for files loaded on a user device, such as a computer. The user device includes a software interface with an I/O port for the device to monitor all file I/O, much like a firewall, which scans all inbound and outbound communications for the computer and checks for all files moved into or out of the system. Files may be loaded onto the device using any type of I/O port, including a floppy disk drive, an internet or LAN connection, a dial-up connection, a CD-ROM or DVD drive, a USB port, an infrared data port, a bluetooth or other wireless connection, or any other mechanism and/or protocol for transferring data to or from a user device.

When the file is loaded onto the user device, the file is detected (step 405). The detected file is further examined using file identification software to attempt to identify the file (step 410). For example, the file identification software may determine whether the received file represents a known song or movie (e.g., in MP3, Windows media, or some other format). Such file identification may be performed by software implementing the techniques described in U.S. patent application publication No. 20030028796, issued 2002 by Roberts et al at 31/7/2002, U.S. patent application publication No. 20030046283, issued 2002 by Roberts et al at 29/10/2002, and/or U.S. patent application publication No. 20030086341, issued 2002 by Wells et al at 22/7/2002, which applications are assigned to Gracenote limited and which applications are incorporated herein by reference. This technique extracts a digital fingerprint from a digital file and compares the extracted fingerprint to a database of known works. More specifically, such techniques may use algorithms to detect the type of media file and the likelihood that the media file is of interest (e.g., representing a potentially protected work). In general, these algorithms examine the internal properties of a file, rather than merely identifying the file type based on the file extension. Media files that are determined to be not of interest may be allowed to pass through without further analysis of the file.

If a media file is found to be likely to be of interest, additional algorithms are used to identify that particular media file (e.g., a particular song, movie, photo, written work, etc.). Fingerprint data that allows a particular media file to be identified may be stored at a central server and accessed using an internet connection. Some files may be related file types but may not be identified (e.g., if the media file represents a sound recording generated by a user or if access to a central database of digital fingerprints is not available). Access to such a file may be allowed without limitation, but the file may be marked as unidentified (e.g., by storing an indication to access the unidentified file on the user device), which allows for faster processing in the future and allows the solution software to potentially identify the media file at a later time if the media file is later categorized or identified (e.g., when an internet connection to a central digital fingerprint database becomes available). If the file is later identified or categorized and restricted, the stored indication of access to the unidentified file may be used to require a purchase of a license in order to continue use of the file or to impose a license fee for use of the file. In some implementations, data for a limited number of media files (e.g., 2000 most popular song files) may be stored locally on the computer for ready access. The locally stored fingerprint data may be updated periodically from the central server (e.g., when the popularity of song files changes).

The file identification techniques described above allow for accurate identification of files even if someone attempts to disguise the file (e.g., by changing the file name, extension, or other attributes) and whether the file is received in compressed or uncompressed form (e.g., using standard operations for reading compressed information). Such techniques provide very low error rates below 2% (below 1% false negatives and below 1% false positives).

Other file identification techniques, such as watermarking and fingerprinting techniques known in the art of digital rights management, may also be used. In some cases, it may not be necessary to use complex file identification techniques to identify files. Rather, files may be identified based on file name or using file ID attributes, which may be included in or with the file, and which may be designed to be tamper-resistant. For example, if a media file is packaged, file identification software may be used to detect the package and read the file ID information embedded in the package. Thus, a file may be identified using implicit characteristics of the file (e.g., a fingerprint or watermark) or using explicit file characteristics (e.g., a file identifier stored in a file header).

Once the file is identified, a determination is made as to whether the file is licensed on the user device and/or used by a particular user (step 415). This determination may be performed by reference to one or more license databases, which may be stored locally (e.g., on the user device) and/or remotely (e.g., at a central server). To ensure that the license information in the license database is valid, one or more special keys may be used to access the information, unlock the license database, and/or confirm the license on the user, the user device, and/or the user device itself, or may be communicated through communication with a central server, as will be discussed in more detail below. If the file is licensed, the user may be allowed access to the file (step 420), which may involve, for example, opening a file wrapper, playing a song or movie contained in the file, storing or using the file on the user device, or streaming the file to the user device via a wireless or wired connection. The license may specify which type of access or use to the file is allowed.

If the file is not licensed, a license may be provided to the user for purchase (step 425). For example, the user may be directed to a website where purchases may be made, or a pop-up window may appear on the display screen for the user device to ask the user whether the user wants to purchase a license for the file or accept certain license terms and/or the user may be directed to a website where purchases may be made. Alternatively, the user may have a service that allows pre-purchasing a certain number of rebates applicable to license purchases. As another alternative, the amount of unlicensed media used in a particular time period may be monitored locally by solution software or other software, which information may then be used to calculate a usage fee or usage rate. License terms such as terms, usage and distribution limitations, and payment options may also be displayed as part of the offer to purchase the license. It is then determined whether the user accepts the license (step 430) (by receiving an indication that the user clicked the accept button or the decline button in the pop-up window). If the user does not accept the license, access to the file may be denied (step 435). If the user accepts the license, including following any payment terms, the user is allowed access to the file, and license information indicating that the file has been licensed, as well as any other necessary information, is stored in the license database (step 440).

FIG. 5 is a flow diagram of a process 500 for installing software on a user device that controls access to protected files ("solution software"). The solution software may perform a number of different functions, including gathering information for generating keys, communicating with a central server, monitoring the file I/O system, storing and retrieving license information from a local database, identifying files (e.g., using Gracenote or other techniques), wrapping and unwrapping files, and facilitating purchase of licenses. The solution software can be installed on the user device in a number of different ways. The traditional download and software installation process is one way to install solution software. When the packaged file is received by the user device, an installation process may be initiated. Other potential installation processes may involve using songs wrapped by the solution software as seeds for the current peer-to-peer network, sending the solution software or a link to a server storing the solution software, sending using instant messaging or email, and other alternatives. The process 500 shown in FIG. 5 illustrates an installation initiated as a result of receiving a wrapped file.

Initially, a data file is created (step 505). If the data file is a song, for example, the creation of the data file may include the artist recording the song and the artist, record company, and distributor working together to create a song ready for distribution. Alternatively, an independent artist may produce and distribute songs by himself for distribution. Songs may then be "track-grabbed," which involves taking songs from a digital or analog source, such as a CD or DVD, and encoding the songs into an MP3 file, a Windows Media file, a Real Player file, or other Media format for playback on a computer or music/Media Player device.

A digital wrapper may then be applied to the media file (step 510). Digital packaging may be applied, adjusted, or enhanced to the media file by the content owner (e.g., record company, distributor, or independent artist) or by others in the distribution chain. The digital wrapper may include attributes such as title, author/artist, and volume/album, as well as business rules that specify ownership, usage rights, royalty costs, and transfer bonus levels (i.e., commissions to be paid to individuals along the distribution chain). This combined information is given a "unique file ID" (UFID) and this information can be stored in a central database (see fig. 2). The UFID is included in the package during any and all transfers and is used as a mechanism to identify the media file and trigger specific functions such as copyright owner payment events, file usage database updates, and micro-pay dispatch to deliver activity to the consumer. The solution software may include a process for verifying the integrity of a file and its UFID to prevent UFID and packaging tampering. For example, the file identification techniques discussed above for files that do not include a unique embedded ID may be used to "identify" the file by generating a derivative ID. The derived ID can then be checked against the corresponding stored ID to ensure that the file and its unique embedded identifier have not been tampered with.

In addition to information about the media file, the packaging prevents unauthorized access to the media file. In other words, the wrapper prevents access to the media file unless the user purchases a license. In essence, the wrapper places the file in an encrypted form that requires a key to be able to access the underlying media file. Conventional digital wrappers commonly used to protect software applications when they are electronically distributed may be used as wrappers for media files. For example, the packaging may be of the same type as e-commerce packaging provided by Digital River, which has been used to distribute Software such as Norton advertisements by Symantec and Privilege systems by Aladdin Software. Once the user has purchased a license for himself or for the device, the key is used to open the package for the media file. The key may be received from a central server.

Typically, all communications between the user device and the central server are conducted using two levels of encryption. First, the transmission is encrypted via SSL/TLS (secure sockets layer/transport layer security, also referred to as secure HTTP). Second, the transmitted key is protected via a public-private key pair and a symmetric key. A user device specific certificate may be issued to the user device at installation time to ensure that the computer is trusted for communications by the central server. The certificate indicates that the sender is indeed the device it purports to be. The central server then sends its public key to the sending computer. The sending computer encrypts the information it wishes to send using a symmetric key, which is then encrypted using the public key of the central server. The central server uses its private key to decode the symmetric key and then uses the symmetric key to decode the received information. Examples of symmetric key algorithms include DES (digital encryption system), 3DES (triple DES), and simple cipher transcription algorithms. One popular example of a key pair encryption algorithm is PGP (good privacy). The method may be used in reverse to send information from a central server to a user device.

In general, each media file may have a corresponding unique key, or a specific key that may be shared between two or more media files. To improve security, the dedicated encryption method used is unique for each file. Thus, multiple encryption techniques may be used, and the wrapper may include an encryption technique identifier that informs the solution software which decryption technique to use to open the file wrapper. The wrapper may also include an executable component that is run whenever a user attempts to open the wrapped file. In particular, the executable component determines whether there is a valid installation of solution software on the user device.

Note that the license database local to the device may be encrypted. Such encryption typically uses a symmetric key algorithm as described above. To improve security, a security layer (also as described above) may be added and the encryption scheme may be changed at any time in communication with the central server. The techniques generate a symmetric key using a combination of data and an encrypted seed value. Elements of these encryption seeds include local user and/or device specific information, including information bound to device hardware and non-volatile memory. This enhances the ability of the system to perform local machine specific encryption. In this way, encryption and identification keys generated for one system cannot be used on another system.

The wrapped file is typically encrypted using the symmetric key described above. The encrypted content is stored within an executable wrapper. Thus, the keys may be used for a variety of different security functions, including securing (i.e., locking) and unlocking the wrapped file, locking and unlocking the local database, securing communications between the user device and the central server and/or the central database, authenticating the user device to the central server, and authenticating the central server to the user device.

The user device may then receive the wrapped file via physical or electronic media distribution techniques (step 515). For example, a user may be on their computer from a peer-to-peer platform such as Morpheus, KaZaA, Napster, Grokster, etc.; in an email received from another person; file access and download procedures (FTP or HTTP) from a website, telephone or satellite network, whether or not the website is a legitimate distributor of digital content; in a person-to-person file sent via instant messaging or other direct connection methods; or receive the packaged file via other media such as a network connection, CD-ROM or CDR, DVD-R, Zip disk, or the like.

When the user attempts to open or access the wrapped media file (e.g., by double-clicking on the file), the executable component of the digital wrapper determines whether a valid installation of solution software already exists on the user's device (step 520). During installation of the solution software, the central server creates a unique key that includes a "unique customer ID" (UCID) associated with the user and/or device key. The unique key is generated by combining a plurality of data types according to a predetermined algorithm, which may include device specific information, data collected from user input, data generated by solution software or a central server, and local database access and location information. At least some of this data or at least some parts of the data are typically sent from the user device to the central server, and the central server uses the received data to generate the unique key. The central server then encrypts the information and sends the information back to the user device where it is stored in a secure, non-volatile area on the user device, such as the BIOS. In particular, the unique key and others allow the central server to identify the consumer, allowing the user to use the licensed data file and receive a reward for "promoting" (delivering) the file to other consumers. The presence of the unique key and the executable solution software and supporting files on the user device thereby indicates that a valid installation of the solution software is present on the user device. On the other hand, if the unique key exists but the user has removed all or part of the software and supporting files, it is necessary to reinstall the solution software.

Thus, when a user attempts to access a wrapped media file, the solution software checks the BIOS for a valid unique key by memory reading the BIOS data table, which may be written to the SMBIOS (also known as DMI) standard (as defined in "system management BIOS reference specification version 2.3 (section 2.1 — table specification)"), where the unique key is written when the solution software is installed. If the unique key is not found, the wrapped executable component determines that the solution software has not been installed. If the unique key is found in the BIOS, the unique key is read and verified using a central database to ensure that the found unique key is valid. The central database decrypts the unique key and computes and verifies a checksum. As an alternative to using a checksum, other authentication methods may be used, such as including an additional key or handshake token in the exchange between the client device and the central server. In some cases or implementations, verification of the validity of the unique key may be performed by the solution software on the user device. If the unique key does not match the checksum, the wrapped executable component determines that valid solution software has not been installed. If the unique key does match the checksum, a valid installation is determined to exist. In some implementations, such as where the local system has limited processing resources (e.g., a cell phone), the process of checking for a valid installation may be performed at the central server.

Further, if the unique key indicates that a valid installation exists, the solution software located on the user device may be validated against unique identification information for the solution software included in the unique key stored in the BIOS. For example, the unique key stored in the BIOS may include a checksum version of the solution software, which may or may not be stored in encrypted form as compared to the checksum and version of the solution software located on the user device. If the information does match, the wrapped executable component determines that valid solution software is not currently installed. Otherwise, a valid installation is identified.

Although not shown in fig. 5, there may be instances where the wrapped file is already licensed (i.e., the license to access the file is already stored in a local or central license database) or where an unwrapped file is already present on the user device (e.g., the file is tracked from the CD onto the user device before the solution software is installed on the user device). In the latter case, it may be assumed that the user is granted a license to access the file. To determine whether a file is already present on a user's device, it is generally necessary to scan a storage device connected to the user's device to discover what files are present on the user's device. The handling of files that are already licensed or already present on the user device will be discussed further below.

If the packaged executable component determines that valid solution software is not currently installed, then an offer to install the solution software is presented on the user device (step 530). The offer may be presented, for example, in a pop-up window. A determination is then made as to whether the user accepts the offer to install the solution software (step 535) (e.g., by receiving an indication that the user clicked an accept button or a decline button in a pop-up window). If the user does not accept the offer, the solution software will not be installed and access to the wrapped media file is denied (step 540). If the user accepts the offer, the solution software is installed from a central server that stores the solution software code or from code included in the wrapper (step 545).

Once the solution software is installed at step 545 or if the wrapped executable component determines that a valid installation of the solution software already exists at step 520 (and assumes that the wrapped media file has not been licensed by the user and/or on the user device), an offer to purchase or license the wrapped media file is presented on the user device (step 525). Alternatively, the user may be directed to a website that may complete the purchase or license of the file. It is then determined whether the user accepts the purchase or license offer (step 550). If not, access to the packaged media file is denied (step 540).

In some implementations, installation of the solution software will not occur until after the offer to purchase or license the packaged media file is presented at step 525, or even after the user accepts the purchase or license offer at step 550. Thus, an offer to purchase or license the packaged media file (step 525) may be presented on the user device regardless of whether a valid installation of the solution software was found on the user device at step 520, and before a copy of the solution software was installed at step 545. In such a case, the solution software may be installed at step 550 at about the same time or after the determination of whether the user accepts the purchase or license proposal without separate proposal and acceptance of the solution software. Thus, step 545 may be performed substantially simultaneously with step 550 or after step 550, and steps 530 and 535 may be omitted. As another alternative, steps 530 and 535 may be performed at some other point during process 550.

If the user accepts the purchase or license offer, payment information is obtained from the user and sent to the central server (step 555). The central server may include a micropayment system that tracks the sales of media file licenses and all parties that will pay for each particular sale, as will be described further below. If the purchase is the first purchase of a media file by the user, billing information including payment method and related information and address and phone contact information is entered. Otherwise, the user may have the option of logging in and using a previous payment method or entering a new payment method.

The payment method is processed. If the payment fails, the user may enter a different payment method and try again. If the user chooses not to try again or if any proposed payment method is not confirmed, the transaction is cancelled and access to the media file is denied. Assuming, however, that the payment was successful, the media file is unpacked (step 560) and the license information may be stored in the local database and/or the central database, as appropriate.

Once the solution software is installed on the user device, the solution software may check all media on the user device (step 565) to determine if any of the media files represent protected content. Such checking may be performed by scanning the contents of the memory of the user device and using file identification techniques to identify known media files. The identified media files may then be packaged to allow the user to market and sell his/her own catalog library, as will be described further below. In particular implementations, the media file may or may not be wrapped after identification until the user attempts to send the file via the I/O system of the user device. Further, the user may be required to purchase a license for any identified content for which the user does not already own the license. However, in some implementations, it may not be desirable to require a license to be purchased for files that are already resident on the user device when the solution software is installed, as it may not be possible to determine whether the user has legitimate possession of these files (e.g., whether the user has previously paid for the files before the solution software was installed on the user device). However, files already present on a user's device may be packaged when transferred to another device and/or another user.

FIG. 6 is a flow diagram of a process 600 for packaging content that does not have any digital packaging at the time of arrival on a user device that includes solution software. Initially, a media file is created (step 605), as described above in connection with FIG. 5. The media file is then received onto a user device that includes solution software via physical or electronic media distribution techniques (step 610). The solution software monitors the file I/O system to identify the receipt of the media file. Using file identification techniques, the solution software attempts to identify the media file by, for example, extracting a digital fingerprint from the media file and comparing the fingerprint to fingerprints of known media files (step 615). A determination is made as to whether a media file is identified (step 620). If not, then it may be assumed that the media is not protected by copyright or the like and access to the media file may be allowed (step 625).

If the file is identified, a determination is made as to whether the media file has been licensed on the user device and/or used by a particular user (step 630). Typically, when a file is identified, the file identification technique will identify the existing UFID associated with the media file. To determine whether a media file is licensed for use on a user device, the solution software may determine whether the UFID is stored in a local database containing UFIDs for licensed media files. In some cases, the user may have a license for the media file, but the license information may not be stored on the user device. For example, a user may have purchased a license using a different device. Given that the business rules of a media file do not limit the use of the media file to a particular device (i.e., the device that originally licensed the media file) or prevent the use of the media file on the current user device, access to the media file may be allowed. Thus, if the UFID is not found in the local database, the central database may be checked to determine if the user has a license for the media file.

If it is determined that the media file is permitted, access to the media file may be allowed (step 625). In some cases, it may be determined that a valid license exists and access to the media file may be allowed, even if the file is not contained in the user's license database. For example, if the file is being loaded onto the user device from a Compact Disc (CD), the solution software may be able to identify whether the CD was factory produced, and if so, may be programmed to assume that the attempt to copy the file is legitimate or permissible. Thus, the solution software may allow files to be copied from the original CD and may store license information for files copied from the original CD (see step 640 of FIG. 6). However, the solution software may also be programmed to prevent further copying of files received from the CD. In particular, the solution software may wrap files copied from a CD at any time when the files are identified or when it is detected that the files are being transferred via the I/O system of the user device.

If the media file is not licensed, the user may be given the opportunity to purchase a license to use the media file (step 635). If the user chooses not to purchase a license, access to the media file may be denied (step 640). If the user decides to purchase the license, payment information is obtained from the user and sent to the central server (step 645). Assuming the payment is successful, the license information for the media file may be stored in the local database and/or the central database, as appropriate (step 650). The media file may also be packaged for future distribution (step 655), which ensures that the media file is licensed and that an appropriate fee distribution is made before others can access the media file. As described above, the media file may be packaged immediately. Alternatively, the media file may be maintained in an unpackaged form on the user device and only packaged when the user attempts to send the media file via the I/O system of the user device.

Fig. 7 is a signaling and flow diagram of a process 700 for generating a UCID for a user and/or a user device-specific key. Typically, each user will have a single UCID, and each user device will have its own private device key. The UCID may be used to identify the user for purposes of accessing the user's license information stored at the central server, to track the source of the file for purposes of identifying consideration (i.e., when the user adds his/her UCID to the file package and distributes the file to other purchasers), and to identify certain user devices as belonging to a particular user. The private device key may be used to unlock and/or access the local license database and allow the central server to identify the particular device. The UCID and the dedicated user equipment key may also be combined into a combined key by simply appending one to the other or by mixing the keys according to some type of encoding algorithm. The combination of the UCID and the private user device key may be used to distinguish private user devices belonging to a particular user (e.g., so that a central server can track on which devices the licensed file resides).

Process 700 involves operations on and communications between user device 705, BIOS 710 of user device 705, central server 715, and central database 720. Installation of the solution software on the user device 705 is initiated (step 722). As a result, the user device 705 sends a request 724 for solution software to the central server 715. In response to the request 724, the solution software is downloaded from the central server 715 to the user device 705 (726). Instead of sending the request 724 and performing the download 726, the solution software may be loaded locally (e.g., from a file located on the user device 705 or from a disk). The user may be prompted to accept the terms and conditions of the license agreement for the solution software and may receive acceptance of the license agreement, step 728.

The solution software loaded onto the user equipment 705 includes executable code required to collect certain user-related information (step 730). Some information may be automatically collected, while other information may require manual input by the user. For example, the user may be prompted to enter a unique username or "handle", a password, an email address, and other user input information. This information may be used to access user licenses and other information stored in a central database and/or to access a local database on the user device 705 that may be shared by multiple users that is specific to that user. The automatically collected information may include device specific information (e.g., system generic user ID, CPU ID, MAC address, BIOS boot block) and access and location information for local databases.

The solution software loaded onto the user device 705 also includes executable code required to establish a connection 732 between the user device 705 and the central server 715. Typically, the internet connection between the user device 705 and the central server 715 is made automatically. If automatic connection is not possible, a manual process is initiated to prompt the user to initiate a connection (using a modem, network, etc.). If no internet connection is made, the installation aborts, in which case the information collected at step 730 may be stored for later attempts to install the UCID and private device key when an internet connection is available. In the case where the solution software is installed from the central server 715, the installation of the solution software may similarly abort at steps 722, 724, and 726. The internet connection is made via a secure channel such as Secure Sockets Layer (SSL).

Information sent to the central server 715 may be sent over the secure tunnel and may have additional encryption applied to it (e.g., using PGP in addition to the encryption provided by the SSL connection). The success or failure code may be used to respond to messages sent to the central server 715. A sent message that did not receive a response within a reasonable time frame determined by the procedure is assumed to have failed. Using the established connection, the user information collected at step 730 is sent to the central server 715 (734).

The central server 715 may search the central database 720 to see if the user is known 736. Determining whether the user is known may involve comparing one or more of the data items of the user information with known data items stored in the central database 720. For example, if the username is already located in the central database 720 but the passwords do not match, the user may be prompted to log in with the correct password and/or notified that the username has been used.

If the user is not known, the central server 715 generates a UCID and/or device key (step 738). The UCID and device key may be generated by combining a selected number of data items, which may be selected from a variety of available data items including received device-specific information, received user information gathered from user input, received access and location information of a local database, data generated by the central server 715, and information about the date and time of the transaction or other information about the transaction. As described above, the UCID may be combined with the private device key to create a combined key. Which data items to use and how to combine the data items may be defined by an algorithm stored in the central server 715. By generating the UCID, device keys, and/or combination keys at the central server 715, algorithms used to generate the UCID, device keys, and combination keys may be kept secure, which may help prevent users from being able to generate counterfeit UCID, device keys, and combination keys. Furthermore, reverse design of UCID, device keys and combination keys and/or algorithms for generating UCID, device keys and combination keys may be further prevented by using less than all of the information received from user device 705 and/or randomly selecting some of the data items to be used for generating UCID and by encrypting UCID before sending it to user device 705.

The UCID, device keys, combination keys, and/or other machine specific information, as well as other user information, are stored in the central database 720 (740). The UCID, device key and/or combination key may also be encrypted (step 742), and the encrypted UCID, device key and/or combination key is sent to the user device 705(744), the user device 705 storing the encrypted UCID, device key and/or combination key in the BIOS 710. The key may be divided into multiple portions, and different portions of the key may be stored in separate locations of the BIOS. The UCID, device key, and/or combination key may represent a public key that may be subsequently used to encrypt messages between the client and the central server. A local license database is created on the user device 705 (step 748). For example, a portion of the solution software code is run to create an encrypted license database on the user device 705. By encrypting the database and/or the information stored in the database, it is possible to prevent the information contained in the database from being readable unless a suitable key is used. Typically, the license database is created on the hard drive of the user device 705 and a location pointer is stored in the BIOS 710, but the license database may also be created in the BIOS 710. The encrypted UCID, device key, and/or combination key, which may include one or more location pointers, may be written to BIOS using industry standard procedures for storing extended data structures, such as Desktop Management Interface (DMI).

Consumers typically have multiple devices and want to be able to use licensed files on each device. Thus, in some cases, process 700 may be initiated on a new device by a user that already has a UCID. Based on the UCID, username and password, and/or other identifying information, the central server 715 may determine that the user is known during the search 736. The user is still able to install the solution software on other devices and log in using his/her username and password. The central server 715 may generate a new device key without having to generate a new UCID (at step 738) and update the combined key with the new device information. Thus, the combined key may include the UCID and device-specific information (e.g., a private device key) for all devices owned or used by the user.

When the combined key is received by the central database, the combined key may be decrypted by the central server to identify the user (using the UCID portion of the combined key) and determine whether the user device is a new device or a known device for the user (using the device-specific information contained in the combined key). If the device is a new device, the new device may be added to the registered user's list of known devices, and the device may then use the data files based on the license permissions of the respective files (e.g., the number of different devices on which the media files may be used without purchasing additional licenses). The UCID and/or updated combination key (and new device key) may also be added to the BIOS of the new device so that the device may be associated with the particular user. The UCID and/or updated combination key may also be added to the BIOS of the user's other devices when these devices are next connected to the central server. The dedicated device may also be associated with multiple users, in which case each user may have a separate license database that may be distinguished using a username and password. Further, devices that do not have solution software but are authorized to communicate with the license store in the local database or central database 720 may be allowed to use the licensed file based on the license information located in the license store.

In some cases, the user may be allowed to access the licensed file on a temporary basis using, for example, a borrowed device. For example, a user may want to listen to a music file when at a friend's home. In such a case, the device may be temporarily added as an additional device (e.g., having an expiration date/time), a temporary license may be given to the file on the device, or the file may be streamed to the device. However, to prevent users from allowing others to access their licenses, users may be restricted to simultaneously login one at a time and/or such temporary licenses may be given a limited time or only one device at a time.

FIG. 8 is a signaling and flow diagram of a process 800 for accessing a media file in the event that the user already has a license for the media file. The process 800 involves operations on and communications between the user device 805, the BIOS 810 of the user device 805, the local database 815, the central server 820, and the central database 825. The user device 805 receives the wrapped file as in step 715 of fig. 7. When a user attempts to open a wrapped file, executable wrapper code is run on the user device 805 (step 830). These executable codes may cause user equipment 805 to first check for a valid installation of solution software (step 835). Assuming a valid installation is found, the executable code may cause the user device 805 to check for a valid UCID, device key, and/or combination key in the BIOS 810 (step 840), which may involve a memory read of the DMI table to which the key was written when the solution software was installed.

If a valid UCID, device key, and/or combination key is found, the solution software on the user device 805 may check the local database 926 for the license for the wrapped file by sending a file license request 742. Such a search may be conducted by identifying the UFID of the media file contained in the digital wrapper and attempting to locate the UFID in local database 815. The local database 815 may be unlocked by comparing unique machine information from one or more keys stored in the BIOS to actual unique machine information. If the information matches, the solution software may decrypt the local database to read the license information. If the information does not match, the key may be designed such that the attempt to decrypt the local database is unsuccessful (e.g., thwarting unauthorized copying of the license database to a different device), in which case it may be necessary to contact central server 820 to obtain an authorized or registered user device 805 (see FIG. 17). The digital key stored in the BIOS may be used to decrypt license information contained in the local database 825 and/or the local database 805 to unlock the local database 825 or its contents.

Assuming that the local database 825 is successfully decrypted, a response 844 containing an indication that the necessary license information or files are not currently licensed on the user device 805 is returned to the user device 805. If license information is returned, access to the file is allowed (step 855). Otherwise, it may be necessary to access the central database 825 to determine whether the user device 805 is an authorized device and/or to determine whether a valid license exists. Each time the central server 820 and/or central database is accessed, it may be necessary to test the keys stored on the user devices against the information stored in the central database 825 to ensure that the communication involves a valid, authorized user device 805. The following steps describe the testing of the combined key. Although a combined key may be used, other implementations may use UCID, device keys, and/or other information. If the combined key is found in BIOS 810, the found key is sent to central server 820(845) for verification with additional machine-specific information (i.e., some of the information or information originally used to generate the combined key). The central server 820 decrypts the received combined key to retrieve the UCID (step 850) and the embedded device information. The central server may additionally calculate a checksum for the unencrypted combination key (step 855). The central server then verifies the unencrypted combination key against the information stored in the central database (step 860). The verification of the combined key may include a calculation using the checksum. If the unencrypted combination key, UCID and machine information match the information stored in the central database, then authorization 865 to proceed is sent to the user device 805 indicating successful verification of the combination key. If the combined key is forged or copied from another device, the machine-specific information sent along with the combined key will not match the information contained in the unencrypted key and the information stored in the central server.

In response to authorization 865, which may be used once per session when connected to central database 825, the executable code causes user device 805 to search local database 815 for a license for the media file by attempting to locate the UFID of the media file in local database 815 (step 875). In some cases, the search at step 875 may be successful even if the original search (at 842) was unsuccessful if, for example, locally stored key information was ever corrupted but updated via authorization 865. If the UFID is not found in local database 815, central database 825 may be searched for the UFID. If the UFID is found in central database 825, the local database is updated with license information (880). Assuming a license is located, use of the media file is allowed (step 885). For example, the solution software may allow a media player application to access a requested music file. In some implementations, once a media file is allowed to be used on a particular user device 805, the media file is stored on the user device 805 in an unpackaged form. The wrapper is applied again only when the solution software detects that the media file is copied or moved from the user device 805 to another device or storage medium, such detection being determined by monitoring the file I/O system as described above. In other implementations, the media file may be stored on the user device 805 in a wrapped form, and each time the file is opened, the wrapper may be opened using the license information stored in the local database 815.

FIG. 9 is a signaling and flow diagram of a process 900 for accessing a media file in the event that the user does not have a license for the media file. The process 900 involves operation on and communication between the user device 905, the local database 915, the central server 920, and the central database 925. The process 900 begins with a determination that the user does not have a license for the media file (step 930). This determination may be the result of a failed search for licenses in step 875 of fig. 8. In response to the determination, the user device 905 notifies the central server 920 that a license is required (935). The central server 920 responds with a payment request 940, which is displayed on the user device 905 or the user is directed to a website where payment information may be obtained. The user device 905 receives payment information from the user (step 945) and sends the payment information to the central server 920. Payment information is processed (step 955), which may involve determining how much of a license fee is allocated to the content owner and/or the user or users who have distributed the media file. The central database 925 is updated with information indicating that the user has a license for the media file (960). The central database 925 may also be updated with payment assignment information. In addition, local database 915 may also be updated 965 with information indicating that the user has a license for the media file. Based on the updated license information, the user may be allowed to use the media file on the user device 905 (step 970).

If, for example, certain devices are not conveniently connected to the internet, the devices may not be able to communicate directly with the central server. The media files may be transferred to these devices in a manner that prevents the media files from being further transferred to other devices without packaging. In these cases, a portion of the computer code may be installed in firmware, and a small local license database may be installed in the writable memory of the device. Fig. 10 is a signal transmission and flow diagram of a process 1000 for copying or moving a media file from a user device 1005 to a second device 1010. Process 1000 involves operations on and communications between user device 1005, second device 1010, local database 1015, second device database 1020, and central server 1025. The second device 1010 may be, for example, a satellite-connected car audio system, a cell phone, an MP3 player, or other portable device, and may be connected to the user device using a cable such as, but not limited to, an IEEE 1394 fire wire or a USB cable, or may be connected via a wireless connection. A version of the solution software may be pre-installed (e.g., in the factory) on the second device 1010.

A request to transfer a media file is received by user device 1005 (step 1030). In response, the user device 1005 requests a device ID from the second device 1010 (1035). The second device responds with its device ID (1040). User device 1005 confirms that the business rules contained in the package of the media file allow the requested transfer (step 1045). For example, business rules may impose limits on the number of devices that can copy the media file. Assuming that the transfer is allowed, the wrapped media file and corresponding license information may be transferred to the second device 1010 (1050). The second device 1010 may store the license information in the second device database 1020 (step 1055). The license information in combination with the pre-installed solution software may allow the second device 1010 to access the packaged media file. In addition, user device 1005 may update local license information in local database 1015 (step 1060). Such an update may store information indicating that a copy of the media file has been transferred to the second device 1010.

Subsequently, a connection may be established between the user device 1005 and the central server 1025 (1065). The connection may be established in response to an attempt to access a new media file, an attempt to locate license information, or a requirement that user device 1005 periodically confirm a license stored in local database 1015 to continue using the license. Using this connection, license updates stored in the local database 1015 may be uploaded to the central server 1025 (and stored in the central database) (1070), which allows the central server to track the device on which the copy of the media file is located and prevent the media file from being copied to more devices than allowed under business rules. The central server 1025 may also validate the existing licenses stored in the local database 1015 (1075).

Techniques may also be provided for supporting distribution of media files among users and allowing users to benefit from revenue generated as a result of their distribution of media files to others. A user may electronically send information about media files he owns or enjoys to other consumers. If the sale is made as a result of the transfer, the user may earn a percentage of revenue generated by the sale of the media file or even a subsequent sale of the media file. The media file package may contain information identifying the original reseller and distributor, in the case where the user receives the media file from an identified reseller and distributor, as well as information identifying the user who further distributes the media file. This information allows the reseller and user to receive consideration for purchases made while the media file is being delivered, based on business rules associated with the file. Furthermore, when the file is sent or received without packaging, the referring user, reseller, distributor can still be compensated as long as their unique identification is included with the transaction data. For example, the purchaser may identify the referring user, in which case the central server may determine how the referring user receives the file and may reconstruct the distribution chain, including identifying who should share revenue.

The business rules may determine whether a user of an unlicensed media file may still benefit from the redistribution of that media file. For example, a user may host a file on a server that serves as a redistribution point and may be paid for delivery for a fee, even if the user does not have a license for the file he/she is distributing.

When someone begins the process of sending a file to a friend, the solution software creates a newly wrapped version of the media file, preparing the media file for the delivery process. This new package includes the UFID of the media file, the business rules applied to the media file, and the UCID of the originating user or users, which allows the user or users to be compensated for when he/she promotes a song purchased by the receiving user. Reseller and distributor ID information may also be included in the package. The solution software performs this same process when the user device is used to grab a track on a CD or DVD. For example, when a song on a CD is tracked onto a computer, a license for the song is installed in the license database. Subsequently, if the songs are transmitted via the I/O system of the computer, packaging may be applied to the songs. The packaging may include licensing and payment information that may be retrieved from a central database based on song identification information contained in the scratch-out file or based on identification information obtained using the file identification techniques described above. If the song is burned onto a CD, the packaged file can be written to the CD. Alternatively, the solution software may create a dual session CD that contains media information files, such as UFID and UCID and reseller and distributor information, in the PC readable area of the CD. In the dual session CD format, conventional audio files may be allowed in the audio portion of the CD, allowing the CD to be played on a conventional CD player. However, if the file is loaded onto a device on which the solution software is installed, the file will require a license.

FIG. 11 shows a flow diagram of an illustrative process 110 for performing delivery distribution. Initially, user 2 receives a media file from user 1 (step 1105). User 2 purchases a license for the media file received from user 1 (step 1110). In connection with the payment process, the business rules associated with the media file are checked (step 1115). Such checking may be performed on the user device, at a central server, or at another location. User 1 is then discounted using the amount of the commission specified in the business rules (step 1120). The commission may be debited to a micropayment account managed by the central server, credited to user 1 for use in future purchases of media file licenses, or credited to user 1's bank account via a micropayment system.

Subsequently, user 3 receives the media file from user 2 (step 1125). User 3 purchases a license for the media file received from user 2 (step 1130). The business rules associated with the media file are again checked in connection with the payment process (step 1135). User 1 and user 2 are then discounted using commissions by the amount specified in the business rules (step 1140). Thus, multi-level payment can be made for the distribution of media files.

In some implementations, the central server deducts and tracks all accounts from the user's delivery activities, much like a savings account. All account holders may track their funds and use them in payments for other music, or use the funds as a withdrawal to be transferred as monetary funds via Electronic Funds Transfer (EFT) or another suitable method. This applies to all parties separated in the revenue stream, including users, resellers, distributors, and content managers, such as record companies, publishers, and artists. The number of levels paid, and the amount paid at each level, is established when the file ownership holder (typically the copyright holder or publisher) creates the UFID, and may vary according to business rules.

Fig. 12 is a flow diagram of a process 1200 for packaging media files. The process begins with the selection of a media file to be packaged (step 1205). Business rules to be associated with the media file are identified (step 1210). Business rules may be established by the owner or distributor of the media file. The business rules may include payment information and information related to restrictions on the use and copying of the media file. A UFID is generated for the media file (step 1215). The UFID may include the business rule and/or may be used as a pointer to the business rule stored in the central database. In general, a UFID is associated with a particular work (e.g., a particular album of a particular artist), regardless of whether a particular copy of the work is packaged or unpacked. Thus, when a media file is identified using file identification techniques, the identified media file will have a particular UFID corresponding to the media file. The wrapper incorporating the UFID is then applied to the media file (step 1220). The wrapper typically includes encryption of the media file so that the user can only remove the wrapper using the license for the media file. While solution software generally prevents files from being moved without packaging, there may be situations where files may be moved without packaging, such as if a user writes a standard audio CD and the content of that CD is subsequently tracked into another computer. If a file is moved without packaging, a recognition technique may be used to identify the file and look up the associated UFID and its business rules in a central database.

The techniques may be implemented using digital electronic circuitry, integrated circuitry, or computer hardware, firmware, software, or a combination thereof. An apparatus for implementing the techniques may be implemented using a software product (e.g., a computer program product) tangibly embodied in a computer-readable storage device for execution by a programmable processor; and the processing operations can be performed by a programmable processor executing a program of instructions to perform functions by operating on input data and generating output. The techniques may be implemented advantageously in one or more software programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. Each software program may be implemented in a high level procedural or object oriented programming language, or in assembly or machine language if desired; and in any case, such language may be a compiled or interpreted language.

Suitable processors include, by way of example, both general and special purpose microprocessors. Generally, a processor will receive instructions and data from a read-only memory, a random access memory, and/or a machine-readable signal (e.g., a digital signal received over a network connection). Generally, a computer may include one or more mass storage devices for storing data files; such devices include magnetic disks, such as internal hard disks and removable disks, magneto-optical disks, and optical disks. Storage devices suitable for tangibly embodying software program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as ERPROMs (electrically programmable read Only memory), EEPROMs (electrically erasable programmable read Only memory), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and a CD-ROM disk. Any of the foregoing may be supplemented by, or incorporated in, ASICs (application-specific integrated circuits).

In some implementations, the user device on which the files are displayed, played, or otherwise communicated to the user may not have a local storage medium or memory capable of or sufficient to store the solution software and/or local license database. In such a case, the file may be streamed or temporarily stored on the user device. Thus, one or more processors on which the solution software runs and thus controls access to files may be remotely located. Such a remote processor may act as a proxy for a user device that is not capable of storing information locally.

To provide for interaction with a user, these techniques may be implemented on a computer system having a display device such as a monitor or LCD (liquid crystal display) screen for displaying information to the user, a keyboard and a pointing device such as a mouse or a trackball by which the user may provide input to the computer system, or a system that allows information to be input and presented via voice, symbols, or other means such as a Braille input and output system. The computer system may be programmed to provide a graphical user interface through which the computer program may interact with a user. With new technologies such as voice input and output, it is not required to have a visual display to implement the described technologies.

Various implementations are described. Nevertheless, it will be understood that various modifications may be made. For example, steps in the processes described in FIGS. 2A-C, 4-12 may be rearranged and/or certain steps may be omitted. Accordingly, other implementations are within the scope of the following claims.

Claims (27)

1. A method for managing license rights in digital media, the method comprising:

storing digital media license records associated with a plurality of user identities, the license record for each user identity being accessible from a remote device using first authentication credentials corresponding to the user identity;

providing a digital media license for purchase using the second authentication credential;

associating a particular second authentication credential with the first authentication credential corresponding to a particular user identity; and

storing a record of digital media licenses purchased using the particular second authentication credentials in association with a particular user identity based on the association of the particular second authentication credentials with the first authentication credentials corresponding to the particular user identity.

2. The method of claim 1, wherein each of the first authentication credentials and the second authentication credentials for each user identity comprises a username and a challenge response.

3. The method of claim 1, wherein the digital media license record includes at least one of a parameter of a license or a digital media file identifier.

4. The method of claim 1, further comprising storing a plurality of device identifiers associated with the particular user identity, wherein a license for digital media identified by a license record for the particular user identity allows the digital media to be used on a device having one of the plurality of device identifiers.

5. The method of claim 1, wherein the license record includes data identifying digital media found on a device associated with a user identity.

6. The method of claim 1, wherein the first authentication credential is associated with a central server and the second authentication credential is associated with a retailer server.

7. The method of claim 6, wherein the central server stores rules defining revenue allocations among a plurality of entities for purchases of digital media.

8. The method of claim 1, further comprising assigning a debit to an account associated with a first user identity in response to purchasing a digital media license using a second user identity, wherein the purchase is made in response to an introduction by the first user identity to the second user identity.

9. A method for managing license rights in digital media, the method comprising:

storing digital media license records associated with a plurality of user identities;

receiving data identifying a first purchase of a first digital media license from a first retailer entity, the data including information sufficient to identify a particular user identity associated with the first purchase;

storing a record of the first purchase associated with the particular user identity in the digital media license record;

receiving data identifying a second purchase of a second digital media license from a second retailer entity, the data including information sufficient to identify a particular user identity associated with the second purchase; and

storing a record of the second purchase associated with the particular user identity in the digital media license record.

10. The method of claim 9, wherein each of the first purchase and the second purchase is made using the particular user identity.

11. The method of claim 10, wherein the record of the first purchase includes an association of a digital media license for the first digital media with the particular user identity, and the record of the second purchase includes an association of a digital media license for the second digital media with the particular user identity.

12. The method of claim 9, wherein each of the first purchase and the second purchase is made in response to an introduction made using the particular user identity.

13. The method of claim 12, wherein the record of the first purchase and the record of the second purchase comprise a debit against an account associated with the particular user identity.

14. The method of claim 13, wherein the rebate is available for purchase of digital media licenses via at least one of the first retailer entity or the second retailer entity.

15. The method of claim 9, further comprising providing each of the first retailer entity and the second retailer entity access to the record.

16. The method of claim 9, further comprising allocating revenue from the purchase among the first retailer entity, the owner of the digital media, and an entity associated with the central server.

17. The method of claim 9, wherein each of the first retailer entity and the second retailer entity has a separate digital media catalog for purchase.

18. A system for managing license rights in digital media, the system comprising:

at least one retailer server operable to provide a digital media license for purchase using retailer-specific authentication credentials associated with a particular user identity;

a central server operable to store digital media license records associated with a plurality of user identities, the license record for a particular user identity accessible from a remote device using primary authentication credentials associated with the particular user identity, wherein the license record for the particular user identity is automatically updated to include a record of digital media licenses purchased using retailer-specific authentication credentials associated with the particular user identity.

19. The system of claim 18, wherein the central server is further operable to store rules defining revenue allocations among at least an operator of each retailer server and an operator of the central server.

20. The system of claim 18, wherein each of the at least one retailer servers is operable to retrieve information from the digital media license record associated with the particular user identity.

21. The system of claim 18, wherein the central server is further operable to store data identifying deductions earned by the particular user identity for purchases made using other user identities, the purchases associated with introductions made using the particular user identity.

22. The system of claim 18, wherein each of the at least one retailer servers is further operable to support the transfer of licensed digital media files using the particular user identity.

23. A system for managing license rights in digital media, the system comprising:

a plurality of retailer servers, each retailer server being operable to provide a digital media license for purchase, and each retailer server having a separate digital media catalog;

a central server operable to store digital media license records associated with a plurality of user identities, the license records for a particular user identity including a record of digital media licenses purchased via a first retailer server of the plurality of retailer servers and digital media licenses purchased via a second retailer server of the plurality of retailer servers.

24. The system of claim 23, wherein the central server is further operable to support a security mechanism for limiting use of digital media files without digital media licenses.

25. The system of claim 23, wherein the central server is further operable to provide access to the digital media license records by the plurality of retailer servers.

26. The system of claim 23, wherein the central server is further operable to store rules for the allocation of revenue at least among an operator of the central server and an operator of a retailer server via which the revenue-generating purchase was made.

27. The system of claim 26, wherein the central server is further operable to store data defining revenue assigned to each of an operator of the central server and an operator of the plurality of retailer servers.