Patent Application
20070083467
This application is related to U.S. patent application Ser. No. 10/832,812, filed Apr. 26, 2004, and entitled “METHOD AND SYSTEM FOR SECURE NETWORK-BASED DISTRIBUTION OF CONTENT”, which is hereby incorporated by reference herein.
1. Field of the Invention
The present invention relates to securing media data and, more particularly, to securing media data from unauthorized usage.
2. Description of the Related Art
Today, audio or video information is often provided in a digital format. A digital format greatly simplifies its storage, transmission, play-back and modification of the audio or video information. However, given that digital audio and video require a large amount of digital data for proper representation, there are often difficulties with storage and transmission of media data for digital audio and video. As a result, it is common to compress the digital media data to reduce its size. For example, in the case of an input video stream, compression can be performed to reduce the overall size of the video stream. As another example, in a media file containing media data pertaining to digital audio or video, compression can be performed to reduce the size of the media file.
Compression techniques typically perform signal analysis, quantization and variable length encoding. The signal analysis generally operates to analyze and discard any information that is not discernible to a user. Each event can then be assigned to a code (i.e., quantized). The codes can then be encoded with variable length encoding, wherein those codes that are commonly occurring are assigned only a few bits, whereas those codes that rarely occur as assigned a greater number of bits. Four common methods of compression are: discrete cosine transform (DCT), vector quantization (VQ), fractal compression, and discrete wavelet transform (DWT). Various compression standards exist for digital audio and video. For example, there are various MPEG standards being used or in development by the Moving Picture Experts Group (MPEG).
Due to the advances in compression formats, digital audio and video files can have manageable sizes. However, another problem with digital audio and video is that it is easily copied or duplicated, and thus susceptible to widespread piracy.
One approach to unauthorized copying operates to encrypt the digital audio and video data within media files. Encryption generally refers to algorithmic schemes that encode plain text into cyphertext to provide privacy for the plain text. In the case of digital audio and video data, the text is the media data (media content). A receiver of the encrypted media data uses a “key” to decrypt the encrypted media data, so as to acquire the media data in the original, unsecured form. Encryption schemes are categorized as being symmetric or asymmetric. Symmetric key algorithms, such as Blowfish, AES and DES, work with a single, prearranged key that is shared between sender and receiver. This key both encrypts and decrypts the data. In asymmetric encryption schemes, such as RSA and Diffie-Hellman, a “key pair” is created for the user. The key pair typically includes a public-key and a private key. The public-key can be published so that senders of media data can use the public-key to encrypt media data that will be sent to a recipient that has access to the private key. Once encrypted, the encrypted media data cannot be decrypted except by one who has the private key of the key pair.
Unfortunately, however, these algorithmic schemes for encryption and decryption are computationally expensive. In addition, as encryption algorithms become more complex to provide greater privacy, the computational burden also increases. Many computing devices have high computational capabilities such that processing of encryption and decryption algorithms can be performed without difficulty. However, in the case of small-scale computing devices, such as embedded devices or highly portable computing devices which have limited computational capabilities because they are small in size and battery-powered, processing of encryption and decryption algorithms can overburden their limited resources. Thus, there is a need for improved techniques to process encryption and decryption algorithms on resource limited computing devices.
The invention pertains to improved techniques to partially encrypt media files. The encryption serves to cryptographically secure only a portion of the media data within a media file, while the remaining portion of the media data is not cryptographically secured. Although only partial encryption is used, the portion being encrypted serves to substantially disrupt usefulness of other parts of the media file which are not encrypted. In other words, the partial encryption renders the media file substantially unusable by unauthorized users.
In one embodiment, the partial encryption is performed by a host device and thereafter the partially encrypted media file is delivered to a client device. The client device, if authorized, can subsequently decrypt the partially encrypted media file and utilize (e.g., play) the media file. However, since the media files are only partially encrypted, the decryption is likewise also only partial, which makes decryption faster and less resource intensive.
The host device can be a server device or a personal computer, and the client device can be a personal computer or a portable media device. The invention is particularly well suited for use with portable media devices, such as handheld or palm-sized media players, which are battery powered and have limited computational capacity. Because decryption is only required on part of the data, decryption can be efficiently performed even on portable media devices, which helps preserve its battery resources.
The invention can be implemented in numerous ways including as a method, system, device, apparatus, or computer readable medium. Several embodiments of the invention are discussed below.
As a method for encrypting media data, one embodiment of the invention includes at least the acts of: identifying a media file having media data to be encrypted, the media data being arranged in frames; examining the media data in the media file to locate frame boundaries for the frames within the media data; dividing each of the frames into a plurality of blocks; retrieving encryption parameters to be utilized; and encrypting each of the blocks in accordance with the encryption parameters.
As a method for encrypting media data, another embodiment of the invention includes at least the acts of: identifying a media file having media data to be encrypted, the media data being arranged in frames; examining the media data in the media file to locate frame boundaries for the frames within the media data; dividing each of the frames into a plurality of blocks; and encrypting only a portion of the media data pertaining to each of the blocks.
As a method for decrypting media data, one embodiment of the invention includes at least the acts of: identifying a media file having encrypted media data to be decrypted and unencrypted media data that requires no decryption, the media data being arranged in frames; retrieving encryption parameters associated with the media file; examining the media data in the media file to locate frame boundaries for the frames within the media data; dividing each of the frames into a plurality of blocks; and decrypting each of the blocks in accordance with the encryption parameters.
As a portable media device, one embodiment of the invention includes at least: a memory device for storage of a media file, the media file including encrypted media data and unencrypted media data; a media output device that outputs media data; and a controller operatively connected to the memory device and the media output device. The controller operates to: (i) receive a play request from a user to play the media file, (ii) obtain a cryptographic key and encryption parameters associated with the media file, (iii) decrypt only the encrypted media data within the media file in accordance with the cryptographic key and the encryption parameters; and (iv) outputting the resulting media data so as to play the media file for the user.
As a computer readable medium including at least computer program code for encrypting media data, one embodiment of the invention includes at least: computer program code for identifying a media file having media data to be encrypted, the media data being arranged in frames; computer program code for examining the media data in the media file to locate frame boundaries for the frames within the media data; computer program code for dividing each of the frames into a plurality of blocks; and computer program code for encrypting only a portion of the media data pertaining to each of the blocks.
Other aspects and advantages of the invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings which illustrate, by way of example, the principles of the invention.
The invention will be readily understood by the following detailed description in conjunction with the accompanying drawings, wherein like reference numerals designate like structural elements, and in which:
The invention pertains to improved techniques to partially encrypt media files. The encryption serves to cryptographically secure only a portion of the media data within a media file, while the remaining portion of the media data is not cryptographically secured. Although only partial encryption is used, the portion being encrypted serves to substantially disrupt usefulness of other parts of the media file which are not encrypted. In other words, the partial encryption renders the media file substantially unusable by unauthorized users.
In one embodiment, the partial encryption is performed by a host device and thereafter the partially encrypted media file is delivered to a client device. The client device, if authorized, can subsequently decrypt the partially encrypted media file and utilize (e.g., play) the media file. However, since the media files are only partially encrypted, the decryption is likewise also only partial, which makes decryption faster and less resource intensive.
The host device can be a server device or a personal computer, and the client device can be a personal computer or a portable media device. The invention is particularly well suited for use with portable media devices, such as handheld or palm-sized media players, which are battery powered and have limited computational capacity. Because decryption is only partially required, decryption can be efficiently performed even on portable media devices, which helps preserve its battery resources.
The media data, for example, can be audio, video, or image data. The media data can also be referred to as media content or media (when referring to audio, video, or image data). The media data is typically contained in a file known as a media file. Such media files have a digital form and are stored on a data storage medium. For example, the data storage medium can pertain to a compact disc, a magnetic storage device, a semiconductor memory device, an optical storage device, etc.
A media player plays media, such as MP3 files, MPEG files, H.264 video files, Advanced Audio Coding (AAC) files, compact discs or DVDs, for the benefit of a user. In one embodiment, the media player can utilize a disk drive to provide mass storage of media content that is played by the media player. In another embodiment, the media player can utilize semiconductor memory (e.g., FLASH memory) to provide mass storage of media content that is played by the media player.
Embodiments of the invention are discussed below with reference to
The media distribution system 100 allows users of client machines 112 and 114 to access the media server 102 via the data network (e.g., Internet) 108. Accordingly, users of the client machines 112 and 114 are able to interact with the media server 102. Through such interaction, users of the client machines 112 and 114 are able to browse the media files stored in the media storage 110, select media files for purchase, download the purchased media files, and subsequently play the purchased media files at their respective client machines 112 and 114. The media distribution system 100 operates to impose limitations on access to the media files through encryption processes. The media distribution system 100 also causes usage restrictions to be imposed on the purchased media files that have been downloaded.
The client machines 112 and 114 are computing devices, either general-purpose or special purpose. For example, the client machines 112 and 114 can correspond to personal computers.
In recent times, computing devices have become smaller and more compact. The computing devices can also be designed for primarily stationary or portable usage. One type of portable computing device that the invention is suitable for use with are known as handheld computing devices. Handheld computing devices are sometimes more specialized computing devices than are general-purpose personal computers. For example, one type of handheld computing device is a portable (or personal) media player. In one embodiment, a portable media player can be a palm-sized computing device. Media players can also be referred to as consumer electronics products. A media player plays media, such as MP3 files, MPEG files, Advanced Audio Coding (AAC) files, H.264 video files, compact discs or DVDs, for the benefit of a user. In one embodiment, the media player can utilize a disk drive to provide mass storage of media content that is played by the media player.
Additionally, the client devices 112 and 114 can couple to other computing devices. As shown in
The media files that are downloaded to the client machines 112 and 114 are, in one embodiment, only partially encrypted. These media files received at the client machine 112 can also be provided to and stored on the portable media device 116. However, since these media files are partially encrypted, they need to be processed (i.e., decrypted) to remove the encryption before they are usable. Authorized users or devices are given the appropriate cryptographic information (e.g., keys and encryption parameters) to remove the partial encryption. After successful decryption, the media files can be presented (e.g., played) on the associated client machines 112 and 114 or the portable media device 116.
The media server 200 includes a media storage manager 202, a media purchase manager 204, a media download manager 206, and user accounts 208. The media storage manager 202 operates to receive incoming media files, to process the media files for eventual download, and to store the files to the media storage. The media purchase manager 204 assists users of client machines (e.g., the client machines 112 and 114 shown in
The media storage processing 300 initially receives 302 a media file at the media server. The media file is constructed such that it includes media data and may further include metadata. The metadata describes characteristics of the data. For example, the metadata can indicate characteristics, such as name, artist, copyright information, title, etc. The metadata of the media file is optionally encrypted, such as with a global key. In one embodiment, the global key is used to encrypt the metadata for all the media files at the media server. In another embodiment, if desired, different global keys can be used with different media servers. Typically, the metadata is not that sensitive so the use of a common global key to encrypt such is adequate. However, if stronger encryption is desired, then more specialized keys can be used to increase the level of security. In another embodiment, the metadata is not encrypted.
A cryptographic key is generated 304 for the media file. In one embodiment, the cryptographic key is a substantially random secret key that is generated for each media file to be stored. Next, the media file is encrypted 306 with the download key. Here, the media file is encrypted 306 with the cryptographic key corresponding to that particular media file. At this point, the media file (encrypted media file) is secured through encryption and ready for download to potential users. After the media file is encrypted 306, the encrypted media file is stored 308 to a central media storage. In one embodiment, the central media storage is the media storage 110 of
Once stored in the central media storage, the encrypted media file can be purchased and transmitted to the purchaser in its encrypted format to prevent unauthorized access to the media file. Hence, by storing the encrypted media files to the central media storage, the media files are stored in an encrypted manner and are ready to be downloaded with little or no further processing. Consequently, the server is able to be more efficient and handle greater demands for downloading of media files.
The media file encryption process 400 initially identifies 402 a media file to be encrypted. For example, the media file can be identified 402, with or without the assistance of a user, by a computing device performing the media file encryption process 400. The media file is then examined 404 to locate frame boundaries within the media data. Here, it should be noted that the media file contains media data, and that the media data is such that it is arranged in frames that have frame boundaries. After the frame boundaries have been located, each frame is divided 406 into a plurality of blocks. In one embodiment, the size of the frames within the media file are not all the same size, but the size of the blocks all the same size. For example, if a media file for a video is a compressed or encoded in a H.264 video format, the frame size can vary from about 200 bits to 150k bits (e.g., depending on target resolution), and the block size can be about 512 bytes. The frames may not divide into an integer number of blocks. As a result, there may be a remainder block containing the balance of the media data for a frame that cannot be placed in a full block. The remainder block is not normally encrypted.
Additionally, encrypted parameters to be utilized with the media file encryption process 400 are retrieved 408. The encryption parameters can, in one embodiment, be provided on a per file basis. For example, the encryption parameters could be provided in the media file itself. However, more generally, the encryption parameters need not be provided within the media file. For example, the encryption parameters can be provided by a remote computing device, such as a server. In another embodiment, the encryption parameters can be provided on a more general basis, such as for a group of files, for a user, for a session, etc. In still another embodiment, the encryption parameters could be provided on a per frame or block basis, e.g., with each frame or block potentially having a different set of parameters. Regardless of how the encrypted parameters are provided, in one embodiment, the encryption parameters can be encrypted.
In any case, after the encryption parameters are retrieved 408, each block is encrypted 410 in accordance with the encryption parameters. The encryption of each block in accordance with the encryption parameters is discussed in greater detail below with respect to
Partial encryption and the use of encryption parameters is discussed in additional detail below with reference to
The variable X denotes the size of the initial unencrypted portion 602 or 622 for the partially encrypted block 600 or 620. This initial portion, having its size denoted by the variable X, provides an offset into the partially encrypted block 600 or 620. This offset causes the encryption portion to begin somewhere internal to the block. Typically, a block will include various standard header information at the beginning of each block; hence, this type of information is generally known or easily determined. Accordingly, encrypting the initial portion of a block is not very effective at making a media file including such blocks unusable. Consequently, the partial encryption can be more effective when an initial offset into the block is utilized such as provided by the encryption parameter associated with the variable X. In one embodiment, the initial offset is larger than the entire header of a frame or block. In another embodiment, the initial offset is not larger than the entire header of a frame or block. In such case, a portion of the header could also be within that portion being encrypted. As an example, a header can include a code block containing code for symbols used in the encoding of the media file. In one embodiment, the portion being encrypted can include some or all of the code block, which can make decoding or other parts of the media file very difficult.
In one embodiment, the partially encrypted blocks 600 and 620 can represent all blocks of a given frame that are partially encrypted. In another embodiment, the partially encrypted blocks 600 and 620 can represent only the first of the blocks of a given frame. In such case, the subsequent blocks (other than any remainder block) can be partially encrypted using only two encryption parameters (e.g., Y and Z′), though the variable Z′ in such an embodiment can represent the sum of variables X and Z.
In general, each partially encrypted block can have one or more portions encrypted and one or more portions unencrypted. Preferably, the one or more portions being encrypted are not at the start of the block. The portion to encrypt should be important and difficult to guess so that a decoder is disrupted and not able to easily recover from the errors produced by the partial encryption. The percentage or amount of partial encryption to be performed with respect to a block can be set by the encryption parameters. For the case of the partially encrypted block 600, the percentage of encryption being performed is determined by Y divided by X+Y+Z. In the case in which the offset parameter X is only used in the initial block of a given frame (as opposed to every block in the frame), then the percentage of encryption being performed can be estimated to be Y divided by Y+Z. For the case of the partially encrypted block 620, the percentage of encryption being performed is determined by Y1+Y2 divided by X+Y+Z.
The media purchase and download processing 700 initially permits a user to browse 702 media files that are available for purchase. Here, the user is able to browse the media files to assist the user in determining whether to purchase one or more of the media files. Often the user is able to view at least portions of the metadata for the media files, view text associated with the media files, and/or sample audio, graphics or video pertaining to the media files.
After the browsing 702, a user selects 704 a media file for purchase. Then, the user purchases 706 the media file and receives an associated cryptographic key. The user may also receive a global key or other cryptographic key when a media file is purchased. Here, the purchase of the media file can be an electronic commerce transaction in which the user pays for the access to the media file through any of a variety of financial transfer means, such as credit card, debit card, or payment assistance (e.g., PayPal, Neteller, pre-paid ATM, etc.).
Next, the media file is downloaded 708 to the user. In one embodiment, the download 708 of the media file can be performed by streaming the media file through the data network to the user, namely, to the user's client machine. Here, the downloading 708 of the media file can be efficient because the manner in which the media file can be stored facilitates its immediate download without the need for processing-intensive conversion.
Once the media file is downloaded 708, the media file can then be decrypted 710 at the user's local machine using the cryptographic key. The global key or other cryptographic key may also be used. If the metadata of the media file itself is encrypted, the metadata can also be decrypted using the global key which has previously been provided to the user who has purchased the access rights to the media file. Also, if decrypted 710, the media file can optionally be encrypted 710 again in accordance with another cryptographic key. This optional encryption 710 can be used to re-encrypt the media file for restricted usage by the user. Following the decryption/encryption 710, the encrypted media file is stored 712 to the local data storage. For example, the local data storage can be a disk drive, random-access memory, a removable media, etc. Also, in one embodiment, a database can be used to manage the storage of the modified media files in the local data storage. Any cryptographic keys being used with respect to the encrypted media file are also stored in the client machine. In one embodiment, the cryptographic keys are stored in a local data storage of the user's client machine. Following the operation 712, the media purchase and download processing 700 is complete and ends.
The media file, whether encrypted or not, can have a file format (i.e., encoding) that varies. The file format is typically dependent on the type of media. For example, when the type of media is video, one suitable file format is a H.264 format. Other suitable formats include QuickTime movies, MPEG-1 format, MPEG-2 format and MPEG-4 format.
The playback processing 800 allows a user of a client machine to browse 802 media files in the local data storage for playback. In other words, the media files that are available for playback can be searched, scanned or reviewed (e.g., pre-viewed) by the user. Typically, the user browses through the media files using the metadata for the media files or perhaps samples of the media files. Next, a media file to be played is selected 804. Then, the associated encryption key is obtained 706 from the selected media file. As previously noted, the media files that are stored to the local media storage have associated cryptographic keys also stored in the local media storage.
Next, the encrypted media file can be decrypted 808 using the associated encryption key. At this point, the media portion of the media file is in the “clear.” Finally, the media portion of the media file is played 810 at the client machine. Following the operation 810, the playback processing 800 is complete and ends.
The media file decryption process 900 initially identifies 902 a media file to be decrypted. Typically, a media file would be decrypted when a user or device has requested to play the media file, such as noted in
The host computer 1002, among other conventional components, includes a management module 1006 which is a software module. The management module 1006 provides for centralized management of media items (and/or playlists) not only on the host computer 1002 but also on the media player 1004. More particularly, the management module 1006 manages those media items stored in a media store 1008 associated with the host computer 1002. The management module 1006 also interacts with a media database 1010 to store media information associated with the media items stored in the media store 1008.
The media information pertains to characteristics or attributes of the media items. For example, in the case of audio or video (e.g., audiovisual) media, the media information can include one or more of: title, album, track, artist, composer and genre. These types of media information are specific to particular media items. In addition, the media information can pertain to quality characteristics of the media items. Examples of quality characteristics of media items can include one or more of: bit rate, sample rate, equalizer setting, volume adjustment, start/stop and total time.
Still further, the host computer 1002 includes a play module 1012. The play module 1012 is a software module that can be utilized to play certain media items stored in the media store 1008. The play module 1012 can also display (on a display screen) or otherwise utilize media information from the media database 1010. Typically, the media information of interest corresponds to the media items to be played by the play module 1012.
In addition, to facilitate transfer of media items from the host computer 1002 to the media player 1004, the host computer 1002 includes a media transfer module 1014 and a management data store 1016. The media transfer module 1014 can be a separate module as shown in
When media items are secured so that they may be played or otherwise utilized only on a limited number of authorized computing devices, the transfer of such media items from an authorized computing device to another computing device, such as the media player 1004, by the media transfer module 1014 preferably operates to authorize the media player 1004 to utilize the secured media items. The media transfer module 1014 accesses the account information 1018 pertaining to the host computer or the user of the host computer 1002. The account information 1018, for example, can include at least a cryptographic key that is needed to gain access to the secured media item.
Furthermore, to prevent subsequent unauthorized distribution of the media item, the cryptographic key must remain secured once transferred to the media player 1004. In other words, the cryptographic key should be available for use by the media player 1004 but not otherwise in the clear. As a result, in one embodiment, the media transfer module 1014 uses at least one key obtained from the key table 1020 to encrypt the cryptographic key obtained from the account information 1018. The encrypted cryptographic key can then be transferred to the media player 1004. As discussed below, the media player 1004 has access to the corresponding key that enables the media player 1004 to access the cryptographic key and thereby play the media item at the media player 1004.
The host computer 1002 also includes a communication module 1022 that couples to a corresponding communication module 1024 within the media player 1004. A connection or link 1026 removeably couples the communication modules 1022 and 1024. In one embodiment, the connection or link 1026 is a cable that provides a data bus, such as a FIREWIRE® bus or USB bus, which is well known in the art. In another embodiment, the connection or link 1026 is a wireless channel or connection through a wireless network. Hence, depending on implementation, the communication modules 1022 and 1024 may communicate in a wired or wireless manner.
The media player 1004 also includes a media store 1028 that stores media items within the media player 1004. Optionally, the media store 1028 can also store data, i.e., non-media item storage. The media items being stored to the media store 1028 are typically received over the connection or link 1026 from the host computer 1002. More particularly, the management module 1006 sends all or certain of those media items residing on the media store 1008 over the connection or link 1026 to the media store 1028 within the media player 1004. Additionally, the corresponding media information for the media items that is also delivered to the media player 1004 from the host computer 1002 can be stored in a media database 1030. In this regard, certain media information from the media database 1010 within the host computer 1002 can be sent to the media database 1030 within the media player 1004 over the connection or link 1026. Still further, playlists identifying certain of the media items can also be sent by the management module 1006 over the connection or link 1026 to the media store 1028 or the media database 1030 within the media player 1004.
Furthermore, the media player 1004 includes a play module 1032 that couples to the media store 1028 and the media database 1030. The play module 1032 is a software module that can be utilized to play certain media items stored in the media store 1028. The play module 1032 can also display (on a display screen) or otherwise utilize media information from the media database 1030. Typically, the media information of interest corresponds to the media items to be played by the play module 1032.
However, it should be understood that since the media items are secured (i.e., encrypted), the play module 1032 must first locate the appropriate encrypted cryptographic key before a given media item can be played. Once the encrypted cryptographic key is located, the encrypted cryptographic key must be decrypted in order to be utilized to access a particular secured media item. In this regard, the media player 1004 includes an authorization data store 1034. The authorization data store 1034 can be a separate data store or can be part of the media store 1028 or in the media database 1030. The authorization data store 1034, in one embodiment, includes account information 1036 as well as a key table 1038. The encrypted cryptographic key(s) that have been transferred from the host computer 1002 to the media player 1004 can be stored in the account information 1036 and/or the key table 1038. An appropriate encrypted cryptographic key is located within the account information 1036 or the key table 1038, the corresponding key can be obtained from the key table 1038. The encrypted cryptographic key can then be decrypted using the key. The resulting cryptographic key can then be used to access the particular secured media item. Once the media item is accessible, the play module 1032 can proceed to play the media item at the media player 1004.
Hence, in one embodimnent, the media player 1004 has limited or no capability to manage media items on the media player 1004. However, the management module 1006 within the host computer 1002 can indirectly manage the media items residing on the media player 1004. For example, to “add” a media item to the media player 1004, the management module 1006 serves to identify the media item to be added to the media player 1004 from the media store 1008 and then causes the identified media item to be delivered to the media player 1004. This also involves transfer of an encrypted cryptographic key that is associated with the identified media item. The cryptographic key is obtained from the account information 1018 (perhaps first decrypted), encrypted using another key, and then transferred to the account information 1036 of the media player. As another example, to “delete” a media item from the media player 1004, the management module 1006 serves to identify the media item to be deleted from the media store 1008 and then causes the identified media item to be deleted from the media player 1004. As still another example, if changes (i.e., alterations) to characteristics of a media item were made at the host computer 1002 using the management module 1006, then such characteristics can also be carried over to the corresponding media item on the media player 1004. In one implementation, the additions, deletions and/or changes occur in a batch-like process during synchronization of the media items on the media player 1004 with the media items on the host computer 1002.
In another embodiment, the media player 1004 has limited or no capability to manage playlists on the media player 1004. However, the management module 1006 within the host computer 1002 through management of the playlists residing on the host computer can indirectly manage the playlists residing on the media player 1004. In this regard, additions, deletions or changes to playlists can be performed on the host computer 1002 and then be carried over to the media player 1004 when delivered thereto.
As previously noted, synchronization is a form of media management. Synchronization can also be automatically initiated. Still further, however, the synchronization between devices can be restricted so as to prevent automatic synchronization when the host computer and media player do not recognize one another.
According to one embodiment, when a media player is first connected to a host computer (or even more generally when matching identifiers are not present), the user of the media player is queried as to whether the user desires to affiliate, assign or lock the media player to the host computer. When the user of the media player elects to affiliate, assign or lock the media player with the host computer, then a pseudo-random identifier is obtained and stored in either the media database or a file within both the host computer and the media player. In one implementation, the identifier is an identifier associated with (e.g., known or generated by) the host computer or its management module and such identifier is sent to and stored in the media player. In another implementation, the identifier is associated with (e.g., known or generated by) the media player and is sent to and stored in a file or media database of the host computer.
The media player 1100 also includes a user input device 1108 that allows a user of the media player 1100 to interact with the media player 1100. For example, the user input device 1108 can take a variety of forms, such as a button, keypad, dial, etc. Still further, the media player 1100 includes a display 1110 (screen display) that can be controlled by the processor 1102 to display information to the user. A data bus 1111 can facilitate data transfer between at least the file system 1104, the cache 1106, the processor 1102, and the CODEC 1112.
In one embodiment, the media player 1100 serves to store a plurality of media items (e.g., songs) in the file system 1104. When a user desires to have the media player play a particular media item, a list of available media items is displayed on the display 1110. Then, using the user input device 1108, a user can select one of the available media items. The processor 1102, upon receiving a selection of a particular media item, the media data (e.g., audio file or video file) for the particular media item is first decrypted by the processor 1102 using processing discussed above and then supplied to a coder/decoder (CODEC) 1112. The CODEC 1112 then produces analog output signals for a speaker 1114 and/or the display 1110. The speaker 1114 can be a speaker internal to the media player 1100 or external to the media player 1100. For example, headphones or earphones that connect to the media player 1100 would be considered an external speaker.
The media player 1100 also includes a network/bus interface 1116 that couples to a data link 1118. The data link 1118 allows the media player 1100 to couple to a host computer. The data link 1118 can be provided over a wired connection or a wireless connection. In the case of a wireless connection, the network/bus interface 1116 can include a wireless transceiver.
The media items (or media assets) can be audio items (e.g., audio files, such as for songs or audiobooks). The media items can also pertain to video items (e.g., video files or movies) or image items (e.g., photos).
The various aspects, embodiments, implementations or features of the invention can be used separately or in any combination.
The invention is preferably implemented by software, but can also be implemented in hardware or a combination of hardware and software. The invention can also be embodied as computer readable code on a computer readable medium. The computer readable medium is any data storage device that can store data which can thereafter be read by a computer system. Examples of the computer readable medium include read-only memory, random-access memory, CD-ROMs, DVDs, magnetic tape, optical data storage devices, and carrier waves. The computer readable medium can also be distributed over network-coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.
The advantages of the invention are numerous. Different aspects, embodiments or implementations may yield one or more of the following advantages. One advantage of the invention is that digital media data can be protected from unauthorized usage through encryption of only parts of the digital media data. Another advantage of the invention is that portable, battery-powered media devices can perform decryption in a power efficient manner since the computational burden to decrypt encrypted media files is substantially decreased through use of partial encryption. Still another advantage of the invention is that portable media devices can yield higher quality media output.
The many features and advantages of the present invention are apparent from the written description and, thus, it is intended by the appended claims to cover all such features and advantages of the invention. Further, since numerous modifications and changes will readily occur to those skilled in the art, the invention should not be limited to the exact construction and operation as illustrated and described. Hence, all suitable modifications and equivalents may be resorted to as falling within the scope of the invention.
