Patent Application
20110066843
The present disclosure relates generally to digital media, and more particularly, to a system and method for providing rights-managed media to a mobile media play device.
Mobile media play devices have enjoyed increasing popularity in recent years. Mobile media play devices may include handheld computers, wireless telephones, portable media players, personal digital assistants (“PDAs”), and the like. Over time, mobile media playback devices have acquired increasing functionality, and many such devices now provide their users with rich experiences not possible just a few years ago. For example, many mobile media playback devices now include an ability to transmit and receive wireless communications. The ability to communicate wirelessly has further increased the utility of mobile media playback devices. Wireless communications allow mobile media playback devices to access electronic networks such as the Internet. However, some wireless communication channels may offer inconsistent availability and/or may not adequately support high bandwidth communications, such as may be required for delivering media files.
U.S. Pat. No. 7,099,848 to Bratton (“the '848 patent”) discloses methods of delivering media to an electronic device, including dividing a media file into a “residual” data file (hereinafter referred to as a “RAD” file) and an “essential” data file (hereinafter referred to as an “EA” file). The RAD file has had at least one portion removed from each of a plurality of locations within the media file. The EA file includes the portions that were removed. Neither the RAD file, nor the EA file are usable as media files individually. Rather, the RAD and EA files must be recombined in order to render the original media file. The RAD file is typically much larger than the EA file and may be communicated via a first communication channel for storage on the electronic device. The EA file is typically much smaller than the RAD file and is not stored on the electronic device. Rather, when a user wishes to play the media file, the EA file is streamed to the electronic device via a second communication channel. Thus, most of the data needed to render a media file (i.e., the RAD file) may be securely stored on an electronic device, but the media file cannot be rendered without the EA file.
U.S. patent application Ser. No. 10/046,933 to Bratton, et al., is a continuation-in-part of the '848 patent and is directed to power saving methods of streaming media files to a portable computing device. A RAD file is communicated to and stored on a portable device via a high-bandwidth communication channel. When a user wishes to play the media file, the portable device needs to turn on a wireless receiver only for as long as is needed to receive the relatively small EA file. Once the EA file is received, the portable device may turn off the wireless receiver, saving power. The EA file is not stored on the portable device and must be streamed via the wireless receiver each time the user wishes to play the media file.
The above-cited applications are incorporated herein by reference in their entireties, for all purposes.
Bratton's methods of encoding and communicating a media file via RAD and EA files has been commercially adopted by the Rhapsody streaming media service, which is operated by Real Networks, Inc. of Seattle Wash. (the current assignee of the present application, as well as the above-cited applications). However, the need to communicate an EA file to a device each time a media track is played may be a disadvantage in certain contexts.
For example, many users may wish to consume media on mobile phones or other mobile media devices that may lack sufficient resources to obtain and/or process EA files in a timely manner. Using methods such as those described above, a mobile play device may not provide a satisfactory user media play experience if, for example, the device cannot establish a reliable and/or fast wireless data connection at the moment a user wishes to play a particular track. Thus, in at least some cases, methods such as those described above, unavailable, unreliable, and/or unsuitable wireless data connections may hinder a user from playing a desired media track on a mobile play device.
The detailed description that follows is represented largely in terms of processes and symbolic representations of operations by conventional computer components, including a processor, memory storage devices for the processor, connected display devices and input devices. Furthermore, these processes and operations may utilize conventional computer components in a heterogeneous distributed computing environment, including remote file Servers, computer Servers and memory storage devices. Each of these conventional distributed computing components is accessible by the processor via a communication network.
The phrases “in one embodiment,” “in various embodiments,” “in some embodiments,” and the like are used repeatedly. Such phrases do not necessarily refer to the same embodiment. The terms “comprising,” “having,” and “including” are synonymous, unless the context dictates otherwise.
Reference is now made in detail to the description of the embodiments as illustrated in the drawings. While embodiments are described in connection with the drawings and related descriptions, there is no intent to limit the scope to the embodiments disclosed herein. On the contrary, the intent is to cover all alternatives, modifications, and equivalents. In alternate embodiments, additional devices, or combinations of illustrated devices, may be added to, or combined, without limiting the scope to the embodiments disclosed herein.
Some of the limitations of current implementations may be addressed by storing both RAD and EA files on a mobile media play device, thereby enabling a user to play a media track regardless of data network availability. However, storing EA files on a mobile play device opens up potential security concerns, as all of the data needed to play a particular media file would then be stored locally. (Both the RAD file and the EA file are typically encrypted, and it would be nontrivial for an attacker to recombine the two, but it would be much easier to recreate a media file if an attacker had access to both the RAD file and the EA file.)
In various embodiments, network 150 may comprise communication switching, routing, and/or data storage capabilities. In various embodiments, network 150 may comprise some or all of the Internet, one or more intranets, a cellular data network, and wired and/or wireless network portions. In various embodiments, there may be additional media servers 200 and/or mobile media play devices 300A-B (not shown).
Media server 200 also includes a processing unit 210, a memory 225, and an optional display 240, all interconnected, along with network interface 230, via bus 220. Memory 225 generally comprises a random access memory (“RAM”), a read only memory (“ROM”), and/or a permanent mass storage device, such as a disk drive. In some embodiments, memory 225 may also comprise a local and/or remote database, database server, and/or database service.
Memory 225 stores program code for some or all of a provide securely packaged media routine 600. In addition, memory 225 also stores an operating system 255, a play-device license keys store 270, and an unpackaged media file store 275. In various embodiments, play-device license keys store 270 and/or unpackaged media file store 275 may comprise a local or remote database, media, and/or file server. These and other software components may be loaded from a computer readable storage medium 295 into memory 250 of device 200 using a drive mechanism (not shown) associated with the computer readable storage medium 295, such as a floppy disc, tape, DVD/CD-ROM drive, memory card. In some embodiments, software components may also be loaded via the network interface 230 or other non-storage media.
In some embodiments, media server 200 may comprise one or more devices such as that illustrated in
As shown in
Device 300 also includes a processing unit 310, a memory 325, an optional display or video output 340, and an audio output 345, all interconnected, along with optional network interface 330, via bus 320. Memory 325 generally comprises a random access memory (“RAM”), a read only memory (“ROM”), and/or a persistent storage device, such as a disk drive, flash storage, removable storage card, and the like. For example, a removable storage card may include Micro SD, Compact Flash, MultiMedia Card, Secure Digital card, and the like.
Memory 325 also stores program code for some or all of a play secure media routine 900, and a media render engine 370. In some embodiments, play secure media routine 900 (see
Memory 325 further includes a media library 360. In some embodiments, media library 360 may comprise a folder or directory structure designated to hold media content. Media files and other content stored in media library 360 may be accessible by a user via a media play and/or management interface on mobile media play device 300. In some embodiments, media library may be stored on a removable storage card and/or internal storage drive that a user may be able to read to and/or write from via a desktop computer or other computing device. Generally speaking, a moderately sophisticated user may be able to gain at least read access to media library 360 with relative ease. Therefore, a media publisher, distributor, and/or copyright holder may wish to secure media files stored in media library 360.
Memory 325 also includes “private” storage 365. As used herein, the term “private” storage refers to a storage location that is at least somewhat harder for a user access than media library 360. The actual implementation of private storage 365 may vary considerably from one mobile media play device 300 to another, depending on the devices capabilities. Some mobile media play devices 300 may provide a relatively sophisticated security model, including strong encryption capabilities, access-control list permissions, physically separate storage devices for user-accessible and user-inaccessible files, and the like. At the other end of the spectrum, many mobile media play devices 300, including many handsets based on Java ME, may merely provide weak or no encryption capabilities, no permissions-based access control, identical storage device for user-accessible and user-inaccessible files, and the like. Thus, the distinction between media library 360 and private storage 365 necessarily varies according to the capabilities offered by various mobile media play devices 300.
For example, in various embodiments, media library 360 may reside on a storage card or internal storage drive that a user may be able to mount on a desktop computer or other computing device, where contents of the media library 360 may be susceptible to attack by a malicious user. In one embodiment, private storage 365 might reside on a separate storage device from media library. In other embodiments, private storage 365 might reside on the same storage device, but in a location that is not user-accessible when the storage device is mounted on another computing device. In further embodiments, private storage 365 might reside on the same storage device, but in an obscured and/or obfuscated location that would be difficult for a user to discover. In embodiments with less-capable mobile media play devices 300, a storage location may be treated as “private” storage 365 merely by obfuscating file names within an otherwise accessible directory.
The examples provided above illustrate a variety of options for private storage 365, ranging from more secure private storage 365 (e.g., separate, inaccessible, and/or encrypted storage device) to relatively less secure private storage 365 (e.g., obfuscated file names within an otherwise user-accessible directory). As a general rule, it may be desirable to implement a secure form of private storage 365 that the capabilities of a particular mobile media play device 300 reasonably provide. A guiding principle is hindering a user from identifying files in private storage 365 and/or from correlating files in private storage 365 to corresponding files in media library 360.
Unpackaged media file 405 also includes a media-content data block 415. In some embodiments, media-content data block 415 may include media data that has been compressed and/or encoded according to a scheme such as MPEG-4 Part 2, H.263, H.264, Advanced Audio Coding (“AAC”), High-Efficiency Advanced Audio Coding (“HE-AAC”) version 1 or 2, and the like.
Via a packaging process 445 (see
Media server 200 obtains 515 a device identifier from mobile media play device 300, encrypts 520 the generated license key with the device identifier, and communicates 525 the encrypted license key to mobile media play device 300. In some embodiments, the device identifier may comprise an IMEI, a MSISDN, and/or other identifier 375 unique to or associated with the mobile media play device 300. In other embodiments, the device identifier may comprise a randomly generated identifier, a timestamp, and the like.
Mobile media play device 300 stores 530 the encrypted license key. In some embodiments, the encrypted license key may be stored in a location separate from where packaged media files are stored. In one embodiment, the encrypted license key may be stored in Java Record Management System (“RMS”) persistent storage.
At some point after mobile media play device 300 has obtained its play device license key, as discussed immediately above, mobile media play device 300 requests 535 packaged media files for a particular media track identifier (“track ID”) from media server 200. (In some embodiments, mobile media play device 300 may obtain its license key concurrently with or subsequent to requesting packaged media files. See, e.g.,
Media server 200 communicates 545 the packaged EA file to mobile media play device 300 which determines 560 an obfuscated name and optional obfuscated location for the EA file (see also
In subroutine block 800, routine 600 packages media-content data corresponding to the track ID into secure distribution files (i.e., RAD and EA files) for the mobile media play device 300. Packaging subroutine 800 is illustrated in
In block 625, routine 600 communicates the packaged RAD and EA files to mobile media play device 300, and routine 600 ends at block 699. In some embodiments, communicating the packaged secure distribution files may comprise streaming one or both of the packaged RAD and EA files to mobile media play device 300 via network 150 when playback is requested. In one embodiment, a packaged RAD file may be requested and delivered via a standard Hypertext Transfer Protocol (“HTTP”) connection, while a packaged EA file may be requested and delivered via a Hypertext Transfer Protocol Secure (“HTTPS”) connection. In other embodiments, communicating the packaged secure distribution files may comprise side-loading one or both of the packaged RAD and EA files to mobile media play device 300 prior to a playback request. For example, one or both of the packaged RAD and EA files may be transferred to mobile media play device 300 via a serial connection, e.g. Universal Serial Bus (“USB”); wireless protocol, e.g. Bluetooth; and/or by writing to a removable storage card for insertion into mobile media play device 300. In still other embodiments, a mobile media play device 300 may be delivered to a user with one or more packaged RAD and EA files pre-loaded into memory 325. These and similar embodiments may enable offline media play.
In block 710, subroutine 700 stores the generated license key in play-device license keys store 270. In block 715, subroutine 700 obtains a device identifier from mobile media play device 300. As discussed above, the device identifier may comprise an IMEI, MSISDN, and/or other identifier unique to or associated with the mobile media play device 300. In some embodiments, subroutine 700 may further generate and/or obtain additional keys associated with mobile media play device 300 and/or a user associated with the same.
In block 720, subroutine 700 encrypts the generated license key using the device identifier, and in block 725, subroutine 700 communicates the encrypted license key for secure storage in mobile media play device 300. As discussed above, in some embodiments, the encrypted license key may be stored on mobile media play device 300 in Java Record Management System (“RMS”) persistent storage. Subroutine 700 returns in block 799.
In beginning loop block 815, subroutine 800 iterates over a plurality of locations 420A-N within the media-content data block 415 of the unpackaged media file 405 corresponding to the indicated track ID. In one embodiment, the number of locations may be pre-determined (e.g., there may be 128 locations). In other embodiments, the number of locations may be determined based on the size of media-content data block (e.g., there may be a location every 1040, 2064, or N bytes).
In block 820, subroutine 800 removes a number of bytes at the current location, e.g. 420A, to form an “essential” media-content data portion, e.g. 425A. The remaining bytes up to the next location, e.g. 420B, form a “residual” media-content data portion, e.g. 430A. In block 825, subroutine 800 stores the current essential media-content data portion, e.g. 425A, in an EA data buffer or interim file.
In block 830, subroutine 800 encrypts the current residual media-content data portion, e.g. 430A, using the current essential media-content data portion, e.g. 425A. In various embodiments, encrypting the current residual portion may be accomplished in a variety of ways. For example, in one embodiment, the current essential portion may be used as a crypto-key to encrypt the current residual portion using a symmetric-key cryptographic algorithm.
In other embodiments, counter-mode encryption may be utilized to protect the current residual media-content data portion. For example, the current essential media-content data portion (having a length of N bytes) may be encrypted with the EA crypto-key, and the resulting encrypted essential media-content data portion may be logically exclusively disjoined (i.e. “XOR'd”) with the first N bytes of the current residual media-content data portion. The encrypted essential media-content data portion may then be incremented and encrypted again with the EA cypto-key. This result is XOR'd with the next N bytes of the current residual media-content data portion. This process is repeated until the entire residual media-content data portion has been protected.
In block 835, subroutine 800 stores the encrypted current residual media-content data portion, e.g. 430A, in the RAD file 440 corresponding to the track ID. From ending loop block 840, subroutine 800 iterates back to loop block 815 until all locations within media-content data block 415 have been processed. In one embodiment, if there is any data remaining within media-content data block 415, the remaining data may be appended to the RAD file 440.
In block 845, subroutine 845 encrypts the EA data buffer or interim file. As discussed above, the EA data buffer or interim file includes the unencrypted essential media-content data portion 425A-N that were removed in iterations of block 820. In block 850, subroutine 800 stores the encrypted EA data buffer or interim file to a data portion of EA file 435.
In block 855, subroutine 800 encrypts the EA crypto-key with the license key, and in block 860, subroutine 800 stores the encrypted EA crypto-key in a header portion of EA file 435. In block 865, subroutine 800 stores clear metadata associated with the license key in a header portion of EA file 435. For example, in one embodiment, subroutine 800 may store information that would facilitate a media play device to locate the play device's copy of the license in the play device's private storage. In most embodiments, a copy of the license itself is not stored in EA file 435.
In decision block 875, subroutine 800 determines whether to reorder media-content parse metadata in RAD file 440. Referring briefly to
Referring again to
Pseudo-code for an exemplary embodiment of encrypting the current residual media-content data segment, such as is illustrated in
When packaged media files corresponding to the indicated track ID exist on the play device, in block 915, routine 900 determines an obfuscated file name and/or location for a packaged EA file corresponding to the indicated track ID. In some embodiments, routine 900 may determine such a file name and/or location via a one-way algorithm (i.e., an algorithm that is “easy” to compute for a given input, but “hard” to invert, in terms of computational complexity). For example, in one embodiment, routine 900 may provide track-identifying information (e.g., a track ID and a genre ID or other identifier) to a cryptographic hash function, which outputs a unique identifier used to name the EA file.
Using the determined obfuscated EA file name and/or location, routine 900 reads header information from the EA file and in block 920, identifies metadata for a license key associated with the track ID. (Cf. block 865 in
In decision block 925, routine 900 determines whether the indicated license key exists in private storage 365. If not, in some embodiments, routine 900 obtains an encrypted play device license key in block 930. For example, in one embodiment, routine 900 may obtain a license key after the mobile play device's user registers with media server 200 and/or purchases a license from media server 200. In some embodiments, if routine 900 cannot obtain a license key, an error message may be presented, and routine 900 may end without playing the indicated track ID.
Once routine 900 has determined that a play license key for the indicated track ID exists on mobile play device 200, routine 900 enters a play loop, beginning in block 940, in which one or more packaged media-content play segments are unpackaged and played. In various embodiments, the number of media-content play segments may depend on one or more capabilities of the mobile play device 300 and/or media render engine 370.
For example, in one embodiment, media render engine 370 may support a streaming playback method, in which routine 900 acts as a data source supplying media data on request to media render engine 370. In such an embodiment, routine 900 may process the requested media track in many relatively small segments. For example, media render engine 370 may request media data from routine 900 in, e.g., 1000 byte segments, assembling the stream of segments into a continuous stream of rendered media.
In other embodiments, media render engine 370 may not support a streaming playback method. Rather, media render engine 370 may be able to render only discrete, non-continuous segments of media data. (I.e., in some embodiments, media render engine 370 may be configured to process only complete, playable media files.) In such embodiments, routine 900 may preferably process the requested media track as a single play segment.
However, in some embodiments, mobile play device 300 may lack sufficient resources (e.g., processing capability, network bandwidth, and/or memory) to un-package the entire indicated media track in a timely manner. For example, in one embodiment, the indicated media track may comprise a three-minute song, and mobile play device's processing unit 310 may require 45 seconds to process the entire media track. Thus, if routine 900 processed the media track as a single segment, the user would have to wait 45 seconds before he or she could begin to listen to the song, a delay that may present an unacceptable user media play experience. To mitigate the delay, routine 900 may, in one embodiment, process the media track as a first 40-second segment and a second 140-second segment. Thus, the user would have to wait only approximately ten seconds before the first segment began to play. While the first segment is playing, routine 900 may have time to process the second segment, such that the second segment is ready to play as soon as the first segment ends. In some embodiments, this method of non-continuous segment playback may result in a gap, click, or other audible/visible artifact when media render engine 370 switches from rendering the first segment to the second segment. However, in some cases, this artifact may be preferable to making the user wait for the entire track to be processed before playback can begin.
Thus, in various embodiments, as described above, routine 900 may process a packaged media file as a stream of continuous play segments, as a single discrete play segment, or as two or more discrete play segments. Beginning in loop block 940, routine 900 iterates over each play segment. In subroutine 1100, segments of the packaged RAD 440 and EA 435 files are unpackaged into a playable media-content segment. (See
When the RAD file 440 corresponding to the indicated track ID exists in media library 360, subroutine 1000 in block 1020 determines an obfuscated file name and/or location in private storage 365 for the EA file 435 corresponding to the indicated track ID. (See
Beginning in loop block 1115, subroutine 1100 iterates over a plurality of essential portions within EA data bock 1240 of EA file 435. (Cf.
Using the decrypted current essential portion in block 1125, subroutine 1100 decrypts a corresponding residual portion from the RAD file 440 corresponding to the indicated track ID. In block 1130, subroutine 1100 combines the decrypted current essential portion with the decrypted corresponding residual portion to form a playable media-content portion. In ending loop block 1135, subroutine 1100 iterates back to loop block 1115 until all of the plurality of essential portions have been processed.
Once all of the plurality of essential portions have been processed, in block 1140, subroutine 1100 assembles the plurality of combined playable content portions (collected during loop iterations from blocks 1115-35) into a playable media-content segment, and subroutine 1100 ends at block 1199.
Track ID 1205 includes information that may be used to locate 1206 a corresponding EA file 435 (in private storage 365) and RAD file 440 (in media library 360). (Cf.
License key 1245 may be used to decrypt 1110 EA crypto-key 1230 from an encrypted header block in EA file 435. EA crypto-key 1230 may be used to iteratively decrypt 1120 essential portions 425A-N from EA data block 1240. Decrypted essential portions 425A-N may be used in turn to decrypt 1125A-N corresponding residual portions 430A-N from RAD file 440.
Although specific embodiments have been illustrated and described herein, a whole variety of alternate and/or equivalent implementations may be substituted for the specific embodiments shown and described without departing from the scope of the present disclosure. This application is intended to cover any adaptations or variations of the embodiments discussed herein.
