Statutory license restricted digital media playback on portable devices

Abstract

Systems and methods are described for, e.g., providing a statutory audio content service on a portable device that complies with the provisions of the Digital Millennium Copyright Act (DMCA). The user can select a playlist subject to DMCA restrictions but cannot access individual items. Content playback, including skipping of content, is restricted to enforce relevant DMCA provisions. Encryption used to implement digital rights management (DRM) may be modified to enforce such content play rules or, alternatively, an additional layer of encryption may be imposed. Limitations on playback are stored along with the playlist structure in a form that is protected against modification. Information logging content playback is maintained in protected form to be uploaded and relayed to the service provider for the purpose of calculating royalty payments.

Description

BACKGROUND OF THE INVENTION

Field of the Invention

The present invention is related to digital media and more particularly, in certain embodiments, to systems and methods for presenting digital media to a user.

Improvements in processor speed, digital storage capacity, and network bandwidth have enabled remarkable advances in the consumer audio experience. Examples of this include the advent of services that allow music to be purchased online and maintained on user personal computers, as well as the development of portable MP3 players that allow users to carry their favorite songs anywhere they are. Audio playback capability is also being incorporated into devices such as PDAs and cellphones. Users can populate their MP3 players with songs from their own personal CD library and may also incorporate music purchased from the previously mentioned online services.

To suitably restrict distribution of content that has been purchased online, many current MP3 players incorporate digital rights management (DRM) capabilities. Such content is typically encrypted with a key that is specific to a particular MP3 player. The user can select the individual song on the player and, in response, the player will decrypt the selected song using the player-specific key. The content cannot, however, be played on a different player.

A new type of audio content service is now envisioned where a user subscribes to particular “channels” on his or her personal computer. The channel content is periodically refreshed over a distribution network. A portable player can receive the periodically refreshed content from a personal computer it docks to, or possibly directly from the distribution network. The service has the advantage that the user can simply select the type of content that he or she is interested in without the need to identify particular albums and/or songs. The user experience is much more akin to that of radio. The service is also very useful in presenting news and sports information.

This new type of service needs to be accommodated to the rights of content owners. An advantage is that the service can take advantage of a lower cost so-called “statutory” content license that is typically significantly less expensive than outright purchase of an unlimited right to play the song on the user's computer or portable device. By the provisions of the Digital Millennium Copyright Act, the statutory license is available on a per-song basis to streaming music services.

FIG. 12A shows a typical arrangement for DMCA streaming of content subject to a statutory license. A central streaming server 1202 stores the content and provides real-time access over the Internet. Server 1202 stores one or more playlists, playlists being ordered sequences of digital media content items such as songs. A media content player 1204, such as, e.g., Windows Media Player, Real Player, etc. is running on a client device such as a personal computer.

Such a statutory license places certain restrictions on content play. For example, there are limitations on how often a song can be repeated, how often songs of a particular album can be repeated, how often songs by a particular artist can be repeated, how long a stream should play before repeating, etc. Also, individual sound recordings may not be played within one hour of a request by a listener or at a time specifically designated by the listener. Streaming server 1202 enforces these restrictions by structuring its playlists appropriately and limiting user access to individual songs and information about the ordering of playlists. Streaming server 1202 also tracks content play to calculate the statutory royalty due to the rights holder.

It is desired to make DMCA statutory content available on a portable device such as an MP3 player by way of the new audio content service described above. At the time of playback, the portable device will be entirely under the control of the user and the streaming server will be unable to enforce restrictions in real-time. For example, normally, an MP3 player provides the capability to skip songs, but if this function is used in an unlimited way, the DMCA restrictions may be violated. Also, to prevent content restrictions from being easily circumvented, it will be necessary to somehow lock out user access to individual songs. It will further be necessary to securely log which songs have been played and aggregate this information across users for royalty calculation purposes.

What are needed are systems and methods for providing the above-described channel-based audio service on a portable device while assuring that the conditions of a statutory license under the DMCA are met.

SUMMARY OF THE PRESENTLY CLAIMED INVENTION

Embodiments of the present invention provide systems and methods for, e.g., providing a statutory audio content service on a portable device that complies with the provisions of the Digital Millennium Copyright Act (DMCA). The user can select a playlist subject to DMCA restrictions but cannot access individual items. Content playback including skipping of content is restricted to enforce relevant DMCA provisions. Encryption used to implement digital rights management (DRM) may be modified to enforce such content play rules or, alternatively, an additional layer of encryption may be imposed. Limitations on playback are stored along with the playlist structure in a form that is protected against modification. Information logging content playback is maintained in protected form to be uploaded and relayed to the service provider for the purpose of calculating royalty payments.

Further understanding of the nature and advantages of the inventions herein may be realized by reference to the remaining portions of the specification and the attached drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts elements of a computer system according to one embodiment of the present invention.

FIG. 2 depicts elements of a portable electronic device according to one embodiment of the present invention.

FIG. 3 depicts a physical arrangement of a portable electronic device according to one embodiment of the present invention.

FIG. 4 depicts a content storage architecture for a portable device according to one embodiment of the present invention.

FIG. 5A depicts a data structure representing a playlist according to one embodiment of the present invention.

FIG. 5B depicts a data structure representing a log of user activity according to one embodiment of the present invention.

FIGS. 6A-6C depict elements of a portable device user interface according to one embodiment of the present invention.

FIG. 7 is a flowchart describing steps of preparing audio content for transfer to a portable device according to a first embodiment of the present invention.

FIG. 8 is a flowchart describing steps of playing back audio content according to a first embodiment of the present invention.

FIG. 9 is a flowchart describing steps of preparing audio content for transfer to a portable device according to a second embodiment of the present invention.

FIG. 10 is a flowchart describing steps of playing back audio content according to a second embodiment of the present invention.

FIG. 11 is a flowchart describing steps of logging content play on a portable device according to one embodiment of the present invention.

FIG. 12A depicts DMCA streaming from a streaming server according to the prior art.

FIG. 12B depicts the application of a restricted media playback client according to one embodiment of the present invention.

DETAILED DESCRIPTION

Introduction

Embodiments of the present invention provide systems and methods for playback of DMCA statutory content. Such content may be played back on non-networked media players such as portable media players. A specific application to audio media materials and channel-based content is disclosed but it will be appreciated that other embodiments of the present invention will provide a user interface to video materials or other media.

A specific implementation of the present invention to be described operates in the context of an audio content distribution service. User interfaces of the present invention exploit a variety of systems and devices. Preferably, an appropriately configured personal computer, referred to herein as a “station,” is used for management and organization of content, retrieval of content via a network, rights management and enforcement, recording, etc. Playback of content may be done via either the station or a portable device such as MP3 player, PDA, smartphone, car audio system, etc.

FIG. 1 depicts elements of a representative personal computer 100 serving as a station according to one embodiments of the present invention. Personal computer 100 may be a laptop computer, desktop computer, etc. The various elements are depicted as being interconnected by a bus 102. However, it will be understood that the actual interconnections among the various elements of a modern personal computer are more complex. Further bus details are not presented because they are not germane to the operation of the present invention. Also, it will be appreciated that various elements may be either inside the computer's structure, outside the computer's structure, or implemented by elements both inside and outside the computer body.

Computer 100 incorporates basic elements such as a processor 104, a memory 106, a hard drive 108, and a CD read/write player 110. Processor 104 typically executes instructions stored in memory 106. The instructions perform the functions of the present invention. Longer term storage of instructions may be on hard drive 108, on a CD accessed through player 110, on other media such as a DVD-ROM, etc. Another example of a computer-readable medium that carries the instructions may be a signal received over a network, i.e., downloading of software.

Another key role of the various memory and storage devices is to store content to be played upon command. For example, audio content may be cached on hard drive 108 and loaded into memory 106 while being played.

Computer 100 also includes various elements to interact with the user. There is a display 112, a keyboard/mouse 114, and sound system/speakers 116. Display 112 and keyboard/mouse 114 facilitate customization and selection of content. Sound system/speakers 116 allow playing of user audio content at the station.

Computer 100 can obtain content in many different ways. For example, content may be remotely retrieved from a network via a network interface 118. Network interface 118 may incorporate one or more of, e.g., an Ethernet interface, DSL modem, cable modem, fiber optic transceiver, wireless modem, etc. Content may also be retrieved from a CD inserted in player 110 or from other media inserted in an appropriate peripheral device. Audio material may also be captured via a radio receiver/recorder 120. Radio receiver/recorder 120 may include capabilities for reception of e.g., conventional or digital AM/FM, conventional or digital shortwave, digital satellite, TV audio, etc. To ameliorate the impact of electromagnetic interference, radio receiver/recorder 120 is preferably located outside the body of computer 100.

Audio content that has been organized and collected on computer 100 may also be transferred to another device for more convenient listening. Accordingly, computer 100 is equipped with a synchronization interface 122. Via synchronization interface 122, selected audio content may be transferred to another device. Also, user selections such as ratings of content, purchase orders for content, may be transferred back to computer 100 for relaying to the content publisher. Synchronization interface 122, may be, e.g., a USB interface, wireless interface such as a Bluetooth interface, etc. Synchronization may alternatively occur across a network by employing network interface 118. For example, synchronization may occur via an IEEE 802.11 network or link, or across the Internet. In one implementation, the transfer of information during synchronization is in accordance with the Microsoft Media Transfer Protocol (MMTP™). Computer 100 may encrypt content prior to transfer to a portable device to restrict further distribution, and also, according to embodiments of the present invention, to enforce content playback restrictions as will be explained.

FIG. 2 depicts elements of a representative portable device 200 configured to implement embodiments of the present invention. Portable device 200 is, e.g., a smartphone, MP3 player, PDA, car audio device, etc. Thus many implementations, although not all, of portable device 200 are handheld. Not all of the depicted elements will necessarily be found in all of the device types. Depicted portable device 200 includes a processor 202, a memory 204, a hard drive 206, and a flash memory device 208. The various memory and storage devices can store instructions to be executed by processor 202 in the course of implementing functions of the present invention. Instructions can also be loaded via a network or other link to a computer or other device. Each of the various memory devices are also usable to store audio content. A portion of the available storage is used to store instructions and data related to rights management, encryption, playlist and log file authentication, etc. The instructions are typically microprocessor instructions (also referred to as “firmware”). These instructions and data are not readily modifiable by the user, thereby preventing circumvention of rights management schemes as described herein.

Software to implement the present invention may operate in the context of portable device operating system software. Examples of portable device operating software include, e.g., the Palm™ OS, Windows Mobile™, various types of Symbian™ operating system such as Series 60™, Series 80™, Series 90™, UIQ™, etc. Such operating system software is not necessary, however, and the invention may find application to less powerful devices such as, e.g., portable music players available from, e.g., Creative Labs, Rio, iRiver, Apple, Sony, etc.

Portable device 200 also includes a network/synchronization interface 210. Network/synchronization interface 210 may provide a short range link to computer 100 via, e.g., a USB connection, a wireless Bluetooth™ connection, a wireless 802.11 connection, etc. To implement a longer range synchronization link, there may be, e.g., a 2.5G or 3G cellular interface such as, e.g., GPRS, EDGE, CDMA2000, UMTS, 1×EV-DO, 1×EV-DV. These types of wireless interface may also be used to download audio content directly from a network.

The user interface features of the present invention exploit a display 212 and an input device 214 that can incorporate buttons, dials, a touchscreen, pen-based input, etc. Sounds system/speaker (or headphones) 216 play audio content and can also play audio cues for the user interface.

FIG. 3 depicts a physical arrangement of some of the elements of FIG. 2 in a simplified representative portable device 200. Display 212 is positioned above a series of buttons 302 and a jog dial 304 that form a part of input device 214.

Channels

As has previously been mentioned, a “playlist” is an ordered sequence of digital media content. The term “channel” refers to the integration of a playlist and rules governing under what conditions content of that playlist is played back for a user. These conditions may include the DMCA statutory content restrictions and/or other restrictions relevant to the service provider business model. Some channels correspond to music genres and sub-genres. Other channels may include radio shows, news materials, etc.

It may be convenient to refer to the current contents of a channel as a playlist. It will be understood that the playlist may be modified as channel content is updated.

Portable Device Software Storage Architecture

In a preferred implementation, portable device 200 supports playback of Windows Media Audio (WMA) 9 format. Portable device 200 also then supports the Windows Media DRM 10 scheme as specified by Microsoft. Software operating on computer 100 will be able to discover content relevant to the audio content service on portable device 200. The synchronization process will delete old content before adding new content to prevent clutter and avoid the need for the user to specifically delete content.

Channel content is transferred from computer 100 to portable device 200 at time of synchronization. The user specifies which channels are to have their content transferred upon a synchronization. Memory constraints on portable device 200 may, however, lead to certain channels not being transferred or to paring of channel content prior to transfer.

FIG. 4 depicts data structures used for content storage on portable device 200 according to one embodiment of the present invention. The data structure arrangement of FIG. 4 is only one example and the present invention is able to exploit a wide range of content storage schemes. A playlist lineup file 402 holds a list of available channels (playlists) for the audio content service. There is also a log file 404 that tracks which content has been played and may also log other user interactions such as requests for outright purchase of particular content items. The playback log information is important in assessing royalty payments that are due to be made by the service provider to rights holders. Accordingly, log file 404 is maintained in a protected form, as will be discussed, to assure that it is not corrupted by tampering.

Playlist lineup file 402 points to individual playlist files such as a playlist file 406 and a playlist file 408. Playlist file 406 is labeled as “Channel1.xme” and identifies music that is available under a DMCA statutory content license. Playlist file 406 is protected in a special way as will be discussed. Playlist file 408 is labeled as “Channel2.xml” and identifies content that is subject to conventional digital rights management but is not subject to DMCA statutory content license rules.

Playlist file 406 points to statutory content files such as files 410 (“ABC.srnd”) and 412 (“ABCD.srnd”). Each of these files includes an audio content item such as a song, encrypted in a special way to facilitate enforcement of DMCA statutory content license rules. Playlist file 408 points to non-statutory content files 414 and 416. These files “WXY.wma” and “WXYZ.wma” are conventional .wma files whose encoding and encryption are specified by the Windows DRM 10 scheme. The .srnd files employ either a modification of the .wma encryption scheme or an extra layer of encryption.

FIG. 5A depicts further details of a statutory content playlist .xme file. The individual records are essentially pointers to the .srnd files of the songs belonging to the playlist. Another field includes rules that specify constraints on playing back the content. These may include the DMCA rules as discussed in further detail below. Other rules that may be specified, e.g., prevent the content from being looped more than e.g., 10 times, require deletion of the playlist and associated content after a specified elapsed time since the last synchronization, require deletion of the playlist and associated content after being looped e.g., 3 times, limit number of skips to e.g., 5 times per hour, require shuffling of songs in a channel after being looped, e.g., 3 times, etc. The inclusion of playback rules in the playlist file is a very powerful feature provided by embodiments of the present invention, allowing the service provider to flexibly control the user experience to accommodate both content rights management and the service provider's own business model.

In addition to the rights management encryption described below, the pointer information and rules are preferably encrypted by a suitable mathematical function to form an authentication code to prevent tampering with the playlist. In one implementation, the mathematical function is a hash function. This authentication code is maintained in a field of the playlist file. Authentication codes may also be computed for the individual records.

The playlist file includes two fields that hold key indices that identify keys in a key table stored in both station 100 and portable device 200. The key indices are used in the following way:

Encryption of the playlist file is based on a bitwise XOR of the file contents with a scrambling key. The scrambling key is generated from an XOR of 2 distinct keys that are chosen from a key table at random. The key table has n (e.g., between 5 and 20) hardcoded base keys. There are thus n*(n−1) possible permutations of the keys. The XOR encryption scheme is symmetric. Encryption is done just prior to transferring the playlist file at synchronization.

Decryption is done in real-time when the playlist is selected, and at playback time. The key indices are retrieved and used to access the key table to obtain the two relevant base keys. The key table contents are specific to each portable device type. The key table is “burned into” the portable device at the time of manufacture, e.g., in a ROM. The base keys are XORed to obtain the scrambling key which is itself XORed with the playlist contents to decrypt them. The key indices are preceded by a version field which identifies the version number of the software used to generate the playlist file.

FIG. 5B depicts elements of a log information (.log) file according to one embodiment of the present invention. The same key table index scheme is used for encryption of the .log file. Authentication of the .log file is, however, on a per-record basis with each record incorporating an authentication code which may be a checksum, hash, etc. The authentication code is based on the record content and the record offset within the file. The records themselves store information about user interactions with the audio content service and playback events. Each record includes an Asset ID, an Event ID, and a time stamp. The Asset ID identifies a particular audio content item. The Event ID records the type of event being logged, e.g., playback of the audio content item, request for purchase, rating, etc. The time stamp records the time of the event.

In the currently discussed implementation, the encryption of the audio content items is based on the Windows DRM scheme. The non-statutory audio content items are encrypted using a symmetric encryption algorithm. The encryption/decryption key is the unique device serial number N, typically 16 or 20 bytes. The encryption occurs prior to transferring content to the device, and because of the use of N is specific to that portable device. The decryption occurs at playback time. The decryption process is implemented in firmware (microprocessor instructions) and is not accessible to the user. Thus the audio content item, once encrypted, cannot be played on a different portable device than the one for which the item was encrypted.

For statutory content a modified encryption scheme is used. In a first embodiment, the audio content item is encrypted with a pseudo-device serial number N′ using the same algorithm employed by the Windows DRM scheme. N′ is obtained from N using a suitable one-way function. When the audio content item is to be played, a modified one-way function is used to obtain N′ from N. N′ is only returned if the DMCA statutory content play rules are satisfied. N′ is then used to decrypt the item for playback. If the rules are not satisfied then a NULL value is returned and decryption does not occur.

User Interface Elements

FIGS. 6A-6C depict displays shown by portable device 200 according to one embodiment of the present invention. FIG. 6A depicts an initial menu structure, showing options such as “play”, “record”, “radio service,” “settings,” etc. By selecting “radio service,” one obtains the list of channels shown in FIG. 6B. The channels “DNN News,” “EBC Arkansas Today,” and “Reality Talk” incorporate non-statutory content. The channels “Jazz Hits 1990's” and “Rock and Pop Hits” incorporate statutory content.

Assuming one selects the channel “Jazz Hits 1990's,” the display of FIG. 6C results. A first song in the corresponding playlist is being played. Portable device 200 preferably bookmarks the exit point of a channel when the user switches to another channel or stops listening for some other reason. Upon re-entry to that channel, the playback should begin at the bookmarked point. For non-music programs, playback begins exactly where it left off and for music channels it begins with the next song.

The display of FIG. 6C shows the title of the currently played channel, the artist name (“Louis Armstrong”) of the currently played track, the title (“It's a good life”) of the currently played track, the album title (“Greatest Hits”) of the currently played track, and the play position within the track (“01:23”).

The user can employ an appropriate button or other element of portable device 200 to request a skip but as will be explained this capability will be limited. The user can also switch between channels. An important aspect of the user interface for statutory content, however, is the functionality that is left out. The user has no visibility as to the identity of the audio content items on the playlist other than the ones that are being played. There is no ability to rewind, skip backward, or fast forward either within an audio content item or across audio content items. The ability to skip forward is limited.

The encryption and authentication features of the playlist file assure that these restrictions are not easily circumvented and that audio content items are not individually addressable.

Statutory Content Restrictions

The relevant DMCA statutory license restrictions are as follows:

• • 1. Specific sound recordings may not be played within one hour of a request by a listener or at a time specifically designated by the listener.
  • 2. In a three-hour period, no more than three tracks from a given album may be played.
  • 3. In a three-hour period, no more than four tracks by a given artist or from a boxed set may be played.
  • 4. No more than two tracks from a given album may be played consecutively.
  • 5. No more than three tracks by a given artist or from a boxed set may be played consecutively.
  • 6. A channel duration is at least three hours and may not be fully looped and played again until the user has listened for three hours.
  • 7. A listener should not be aware of the songs contained in the channel, when the songs will be played or the order in which they will be played.
  • 8. Archived programs (i.e., channels that always starts at the same place and that allows users to start at any time) must greater than 5 hours long and should not be available for more than two weeks at a time. For example, a 30 minute playlist with a fixed start cannot be made available for repeated play and a 6 hour playlist can be made available for repeated play, but not indefinitely.

Also, royalties should be paid to the rights holders based on the number of times their statutory content is played. To exploit the full legal rights for play on a portable device, rule 6 may be replaced by a rule that permits looping of the channel after 3 hours of elapsed time rather than playback time. This adaptation is particularly useful in situations where portable device memory limitations restrict storage of a statutory channel to less than three hours.

In one implementation, rules 1 and 7 are enforced by encryption and authentication of the playlist contents. Rules 2 through 5 are enforced by playlist ordering and the DMCA check function performed when decrypting audio content. Even without appropriate ordering or in a “shuffle” playback mode, the DMCA check function guarantees that these rules are enforced. Rule 6 is enforced by the playlist length and the DMCA check function. For playlists to which it applies, rule 8 is enforced by specifying within the playlist rule field that the playlist (although not necessarily individual content items) is to be deleted after two weeks. The deletion can be invoked as a result of applying the DMCA check function.

One embodiment of the present invention provides dynamic DMCA enforcement. Before playing a statutory audio content item, the DMCA check function is invoked. The DMCA check function involves consulting a playback history to verify whether playing that item would violate any of the DMCA constraints. Besides being logged in the log file, playback events are stored in chronological order separately for each playlist. Two indices are used to point to the head-end and tail-end of the list. Events between the head-end and a point representing three hours in the past are scanned to verify DMCA compliance. Events between the tail-end and the three hour point are periodically deleted by a clean-up procedure.

Other rules may be specified in the appropriate field of the playlist file. For example, when the total playback count of any audio content item in the channel exceeds an allowed number, portable device 200 will playback an audio clip that suggests the user should resynchronize with station 200 to refresh the channel with new content. Another rule can specify portable device 200 will stop playing the channel when there has been no synchronization for three or some other number of days. A further rule can specify that if every song has been played more than, e.g., ten times, the play of that channel will be stopped. Also, a rule can specify that content will be deleted after a specified time and date, such as Jan. 1, 2005 at 11:30 AM.

Other DMCA implementations enforce rules 2 through 5 by essentially never allowing skip. Dynamic DMCA has the advantage of allowing unlimited skips, if those skips do not cause the rules to be violated.

Procedures for Encrypting and Playing Content

FIG. 12B depicts statutory content distribution according to one embodiments of the present invention. Rather than employing a streaming server as in the prior art, a conventional download server 1252 stores channel content. The audio content is transferred in a non-streaming download to a restricted media playback client 1254. In one implementation, restricted media playback client 1254 operates on a handheld device. Also, a personal computer operating as a staging device may serve as a proxy for download server 1252. The transfer to restricted media playback client 1254 thus may be either by synchronization to the personal computer or by connection to download server 1252 via a network or other link.

FIG. 7 is a flowchart describing steps of transferring content to the portable device according to one embodiment of the present invention. A step 702 determines wither the audio content item to be played is statutory or non-statutory. If the content is non-statutory, it is encrypted at step 704 in accordance with the Windows Media DRM procedure using the device serial number N as a key. If the content is statutory, the previously described pseudo-serial number N′ is used as the encrypting key at step 706. Following either step 704 or step 706, at step 708, the encrypted audio content item is transferred to portable device 200 as part of a synchronization event. The synchronization event may occur when the portable device is docked to a client or over some type of network, whether it be a local network or a wide area network.

FIG. 8 is a flowchart describing steps of playing content on a portable device where the content has been encrypted according to the technique of FIG. 7. A step 802 represents an event that would lead to play of an audio content item. Examples include a skip request, selection of a channel, or simply completion of play of a previous audio content item. A step 804 tests whether the audio content item to be played is statutory or non-statutory. If the content is non-statutory, processor code decrypts the content using N as a decryption key at step 806 and the audio content item is played at step 808.

If step 804 determines the content to be statutory then, at step 810, processor 210 invokes a function SRND_DMCA_ID using the device serial number N as input. The function will return N′ if DMCA compliance rules are satisfied and NULL otherwise. The DMCA check includes verifying compliance with the above-mentioned DMCA rules. The DMCA check thus involves consulting a playback history to verify compliance with rules two through five and tracking elapsed time within a channel to determine when a channel can be looped (rule 6) and when it should be deleted (rule 8). Also, as part of the DMCA check, the relevant playlist is checked against its authentication code that was included in the playlist file to assure that there has been no tampering with the playlist contents. The records of the log file are similarly checked (or may be checked at some other time). If either the playlist or the log file has been deleted or tampered with, the DMCA check fails. If DMCA check fails for any reason, NULL is returned rather than N′. If a log file has been impermissibly modified or deleted, all of the statutory content may be deleted. These DMCA check steps are implemented by microprocessor code such that circumvention is very difficult.

Step 812 tests whether NULL or N′ is returned. If NULL is returned then, at step 814, an error message is displayed or possibly audiblized. If DMCA check failed because of an illegal ordering of songs, artists, or albums, then the next item on the playlist is selected for possible playback and the DMCA check procedure repeats. If DMCA check fails because the content should be deleted, deletion occurs now. If DMCA check fails because the content is stale, has been played too often, or there have been no sufficiently recent synchronization events, the user is cued to resynchronize her device to obtain fresh content. If N′ is returned, the item is decrypted using N′ as a key at step 816 and played back at step 818. The playback history information used for DMCA check is updated as a part of step 818.

FIG. 9 is a flowchart describing an alternative way to transfer content. Non-statutory content is handled in a similar way to that described in reference to FIG. 7 and steps 902, 904, and 906 are essentially similar to steps 702, 704, and 706, respectively, in FIG. 7. In FIG. 9, statutory content is handled by using two layers of encryption. At step 908, the audio content item is encrypted in accordance with the Windows DRM scheme using the portable device serial number N. Then at step 910, a second layer of encryption is applied using a key P. This second layer of encryption is used to enforce the content play restrictions.

FIG. 10 is a flowchart describing steps of using a portable device to play content that has been encrypted in the way described in connection to FIG. 9. Steps 1002, 1004, 1006, and 1008 operate in the same way as comparable steps 802, 804, 806, and 808, respectively, in FIG. 8. For statutory content, a step 1010 determines whether the DMCA check passes. If the DMCA check doesn't pass then, at step 1012, the previously discussed consequences of a failed DMCA check follow. If the DMCA check does pass then at step 1014, the first layer of encryption is removed from the audio content item by use of the key P. The key P and the decryption process are maintained at the firmware level to avoid decryption. Then at step 1016 the DRM encryption is removed using the serial number N as the key, again at the firmware level. At step 1018, the decrypted content is played back for the user. The playback history information is updated to reflect playback of the content in conjunction with step 1018.

Procedure for Logging Playback

Another aspect of DMCA compliance is logging content playback and aggregating user playback statistics to assess necessary royalty payments. FIG. 11 is a flowchart describing steps that occur on portable device 200 to support this process in a secure way according to one embodiment of the present invention. At step 1102, a statutory audio content item is played on portable device 200. At step 1104, portable device 200 updates its log file to reflect that the content has been played and for how long. This step involves decrypting the log file, adding a new record, and reencrypting the log file. It should again be noted that if the log file is unavailable or the authentication code indicates tampering the content item will not be played in the first place. The record will include an asset ID (found in the .srnd file header) identifying the audio content item, an event ID identifying the logged event as a playback event, and a time stamp indicating the time of the playback event.

Steps 1102 and 1104 will repeat for every playback event. Then at step 1106, the log file is transferred to station 100 at the next synchronization. Station 100 can then send the logged information to an appropriate database server, at step 1108, so that statistics can be evaluated and royalty payments can be computed. Preferably, the playback log information is anonymized so that individual usage information is unavailable. It is also possible to directly transfer information from the portable device to the database server without using station 100 as a staging device. It should also be noted that station 100 and/or the database server can filter out playback events shorter than 30 seconds since royalty payments will not typically be due for these.

Using DMCA Check to Introduce Advertisements and Announcements

Playlists can contain pointers to audio other than songs. This includes advertisements, announcements, etc.

For example, a DMCA-compliant playlist can include a mixture of songs, announcements, and advertisements as follows:

• • [Srnd1, Srnd2, Playlist Ad1, Srnd3, Playlist Ad2, Srnd4, Announcement List 1, Srnd5] where srndn refers to a song, Playlist Adn refers to an advertisement playlist, and Announcement List n refers to an announcement playlist.

A representative advertisement playlist would then be structured as follows:

• • Playlist Ad1 [Ad1, Ad2, Ad3, Ad4,]. The rules field would specify that an advertisement from this playlist would only be played from 4 PM to 6 PM. A running pointer of played items should be maintained and playback of the advertisements is looped when the last advertisement is reached.

Another representative advertisement playlist would be structured as follows:

• • Playlist Ad2 [Ad1, Ad2, Ad3, . . . ]. The rules field here also specifies a running pointer and looped playback but these advertisements are only played after 8 PM on Saturday nights.

A representative announcement playlist is as follows.

• • Announcement List 1 [Announcement 1, Announcement 2, . . . . ] The rule field for this list specifies that it is only to be played on Aug. 8, 2004.

The primary playlist, advertisement playlists, and announcement playlists are established and appropriately encrypted on a server and transferred to a user station or portable device in any of the ways previously described. The playlist rules fields of the advertisement and announcement playlists include appropriate limitations on content playback.

When the original playlist is being played, reference to an advertisement playlist or announcement playlist causes a redirection to the referenced playlist to obtain the next item for playback from there. However, these advertisements and announcements are still subject to DMCA check which is used in a special way. For advertisements, during DMCA check the absolute date and/or time is checked against the permitted play period, if there is a match then the currently pointed advertisement is played back. This allows restriction of advertisements to time contexts where they are relevant. For announcements, during DMCA check the date is checked against the date specified by the rules field and if there is a match, the announcement is played.

The announcement playlists and advertisement playlists are tailored to the particular user. For example, they may be customized with reference to demographic data as available at a server that transfers content to the station. The announcement playlists and advertisement playlists may also be customized based on input from another user such as a friend. For example, another user may request that a birthday greeting be inserted as an announcement. Such requests may be made by, e.g., email, by cellphone SMS, etc. Announcements can include, e.g., jingles, user-recorded messages, user text messages that have been converted to speech, etc.

The use of pointers to announcement and advertisement playlists provides flexibility. While all users share the same “broadcast playlist,” the advertisements and announcements can be tailored to specific characteristics. No modification or customization of the broadcast playlists is required. The rules associated with announcement and advertisement playlists provide flexibility to download the audio content to portable devices well in advance of the required playback time. A portable device without a network connection can play what seems like fresh content even when it has not been refreshed recently. For example, a birthday greeting may have been loaded up to a month in advance and will playback on the birthday, as long as the user has connected the device to the network at least once within the prior month.

The announcement and advertisement features are not restricted to statutory content and apply equally to non-statutory content. Furthermore, in addition to time-based constraints, the DMCA check function can also be used to constrain playback based on location by employing GPS or other location discovery tools. The announcement and advertisement features are applicable to both station clients and portable device clients that obtain their content through synchronization.

Requesting Content to be Played for Other Users

A friend can also request that a particular song be played back in one of the user's playlists subject to the usual DMCA restrictions including the requirement that specific sound recordings may not be played within one hour of a request by a listener or at a time specifically designated by the listener.

Such a request mechanism can be implemented in many ways. For example, Friend1 sends a request to a specified email address at the media service provider. The request indicates a particular song and the email address of a Friend2 for whom the song has been requested. The song is identified by an asset identifier. Friend2 is identified by an email address.

The asset identifier can be generated in a number of ways. For example: When Friend1 was listening on her portable device she tags a song by clicking on a “Info/Remember Me” button. This user interaction is logged. When synchronizing to the station, the tagged song's name and artist name are displayed by the station for further action by Friend1. The action could be to “purchase” the song or “play” it for my Friend2. Friend1 enters the email address of Friend2 with action specified to “play.” The asset ID is locally available from the playlist or .srnd file header. An email with the necessary information is automatically generated and sent.

Alternatively, Friend1 specifies the song name and the email address of Friend2 in an email to the media service provider. An automatic software function will translate the song name requested by email into an asset identifier. Human intervention occurs when automatic matching fails.

On a periodic basis (e.g., daily), new and refreshed DMCA-compliant playlists are generated for each channel by a DJ or automatic software. The playlists are broadcast to the relevant playlist subscribers. However, individual playlists may be modified for subscribers for whom content has been requested by others. These playlists are modified to include the request song and possibly an announcement.

There are a variety of playlist modification mechanisms that can be employed for this purpose. In one such mechanism, for each subscriber, for each song in the playlist, a check is run through a database to see if there have been requests for that song for that subscriber. If “yes”, then the playlist is modified/customized for the “requestee” and a pointer is placed in the playlist to play an “announcement” before the song is played. The announcement in this case is another audio asset and is just part of the same playlist. The Announcement says, e.g., “Jill has requested this song for you—here it is . . . ”. The playlist is then transferred to the requestee's station or portable device. With this mechanism, the requestee does not hear of the user's request until the requested song is programmed into a channel she subscribes to.

In an alternate playlist modification mechanism, modification of the playlist results in the actual insertion of the specific song in a DMCA compliant manner. The requested song along with the announcement is inserted into the broadcast playlist in a DMCA compliant manner. The playlist is then transferred to the requestee's station or portable device. In this alternate mechanism, the request is likely to be played sooner since there is no requirement for the requested song to be programmed into the channel.

CONCLUSION

It will be appreciated that the statutory audio content service, announcement and advertisement service, and “request for a friend” service that have been presented have many benefits. Statutory audio content is now available on portable devices even when those devices lack network access. Content is transferred to the portable device at relatively low cost since real-time streaming to the device is not a requirement. The ability to avoid real-time streaming is particularly advantageous where there is no constantly available network connection to the portable device or only a relatively expensive and unreliable wireless connection. Additionally, content may be readily customized for a user and his situation. Such customization may occur by request of another user.

It is understood that the examples and embodiments that are described herein are for illustrative purposes only and that various modifications and changes in light thereof will be suggested to persons skilled in the art and are to be included within the spirit and purview of this application and scope of the intended claims and their full scope of equivalents.

Claims

1. A method for permitting playback of digital content comprising: retrieving a list of encrypted digital content at a portable device, wherein the encrypted digital content includes a plurality of content types, the plurality of content types including a first content type and a second content type, and wherein the first content type is encrypted using a first encryption scheme and the second content type is encrypted using a second encryption scheme;identifying each of a plurality of items of encrypted digital content on the retrieved list as being of a first content type or a second content type;decrypting a second content type using a first key maintained at a firmware level;decrypting a first content type item using a second key maintained at the firmware level when the first content type item satisfies a plurality of content play rules, wherein the content play rules require location of the portable device within one or more predefined locations; andpermitting playback of the decrypted second content type items and the decrypted first content type items on the portable device, wherein playback of each content type items is permitted until at least one content play rule has been violated.

2. The method of claim 1, wherein at least one content play rule limits content looping to a predetermined number of times.

3. The method of claim 1, wherein at least one content play rule requires content deletion after a predetermined period of time.

4. The method of claim 1, wherein at least one content play rule requires content deletion after a predetermined number of content loops.

5. The method of claim 1, wherein at least one content play rule limits content skipping to a predetermined number of times.

6. The method of claim 1, wherein at least one content play rule requires content shuffling after a predetermined number of content loops.

7. The method of claim 1, further comprising decrypting a digital log file, updating the digital log file, and re-encrypting the digital log file when playback occurs.

8. The method of claim 7, wherein the digital log file includes at least one content identification and at least one length of playback associated with a playback.

9. The method of claim 1, wherein at least one content play rule is predetermined by a content owner.

10. The method of claim 1, wherein at least one content play rule is predetermined by a content provider.

11. A system for permitting playback of digital content, the system comprising: memory; anda processor that executes instructions stored in memory, wherein execution of the instructions by the processor: retrieves at list of encrypted digital content at a portable device, wherein the encrypted digital content includes a plurality of content types, the plurality of content types including a first content type and a second content type, and wherein the first content type is encrypted using a first encryption scheme and the second content type is encrypted using a second encryption scheme,identifies each of a plurality of items of encrypted digital content on the retrieved list as being of a first content type or a second content type,decrypts a second content type using a first key maintained at a firmware level,decrypts a first content type item using a second key maintained at the firmware level when the first content type item satisfies a plurality of content play rules, wherein the content play rules require location of the portable device within one or more predefined locations, andpermits playback of the decrypted second content type items and the decrypted first content type items on the portable device, wherein playback of each content type items is permitted until at least one content play rule has been violated.

12. The system of claim 11, wherein at least one content play rule limits content looping to a predetermined number of times.

13. The system of claim 11, wherein at least one content play rule requires content deletion after a predetermined period of time.

14. The system of claim 11, wherein at least one content play rule requires content deletion after a predetermined number of content loops.

15. The system of claim 11, wherein at least one content play rule limits content skipping to a predetermined number of times.

16. The system of claim 11, wherein at least one content play rule requires content shuffling after a predetermined number of content loops.

17. The system of claim 11, wherein a digital log file is decrypted, updated, and reencrypted when playback occurs.

18. The system of claim 17, wherein the digital log file includes at least one content identification and at least one length of playback associated with a playback.

19. The system of claim 11, wherein at least one content play rule is predetermined by a content owner.

20. A non-transitory computer-readable storage medium having embodied thereon a program executable by a processor to perform a method for permitting playback of digital content, the method comprising: retrieving a list of encrypted digital content at a portable device, wherein the encrypted digital content includes a plurality of content types, the plurality of content types including a first content type and a second content type, and wherein the first content type is encrypted using a first encryption scheme and the second content type is encrypted using a second encryption scheme,identifying each of a plurality of items of encrypted digital content on the retrieved list as being of a first content type or a second content type,decrypting a second content type using a first key maintained at a firmware level,decrypting a first content type item using a second key maintained at the firmware level when the first content type item satisfies a plurality of content play rules, wherein the content play rules require location of the portable device within one or more predefined locations, andpermitting playback of the decrypted second content type items and the decrypted first content type items on the portable device, wherein playback of each content type items is permitted until at least one content play rule has been violated.