Patent Publication Number: US-2002003886-A1

Title: Method and system for storing multiple media tracks in a single, multiply encrypted computer file

Description:
CROSS-REFERENCE TO RELATED APPLICATION  
     [0001] This application claims the benefit of U.S. Provisional Application Serial No. 60/200,231, filed on Apr. 28, 2000. 
    
    
     
       TECHNICAL FIELD  
       [0002] The present invention relates to a method and system for storing single or multiple track media (audio or video) and related information in a single computer file.  
       BACKGROUND OF THE INVENTION  
       [0003] The widespread demand for music and the growing availability of the Internet as a means of commerce have resulted in a multibillion-dollar industry for audio compact disks (“CDs”) sales via the Internet. In 1999, the sales of physical CDs via the Internet accounted for $890 million. It is anticipated that this will grow to $6.7 billion by the year 2003.  
       [0004] Along side this growth in the sales of physical CDs is the explosive growth in Internet music downloads. Audio compression technologies such as MP3 (MPEG Layer III) have allowed digital music to be stored at compression rates of 10 to 1 or better. This compression of digital format, along with the rise of the Internet and increasing bandwidth, have led to an explosion of downloadable digital music available over the Internet. Individual tracks of music can now be downloaded from the World Wide Web, sent via e-mail, or stored and downloaded via FTP sites and Usenet newsgroups.  
       [0005] One of the advantages of this new music distribution system is that it is possible to store non-musical information in the same computer file that stores the music track. For instance, the original MP3 specification allowed for the storage of the name of the artist and the song contained in the file, along with basic copyright information. Extensions to the MP3 file format, such as ID3 version one added the ability to record when and where the song was created. All of this additional information was essentially textual in nature, and was appended to the back of a normal MP3 file.  
       [0006] A demand exists to include non-textual information along with the music file. This demand was partially met by ID3 version two. This version of ID3, which was located at the beginning of the MP3 file, allowed for the creator of the file to include any type of digital information, such as a photograph, a web page, or even a computer software application. Of course, in order to work correctly, the software reading the file must be familiar with the ID3 version two standard and must be able to accommodate the type of data included. Assuming such compatibility, it is now possible to display images that are stored with the music file while the music file is playing.  
       [0007] Because of the way in which digital files can be easily duplicated and then distributed over the Internet, many parties have proposed incorporating a license scheme into standard music files. While there is no standard for placing a secure license scheme in the MP3 music format, several vendors have created new music types containing strict licensing standards. Once such format, created by Liquid Audio, Inc., allows a music track file to contain information about whether that music track had been properly licensed. The license itself is tied to a user&#39;s “passport,” which can only be transferred from one machine to another after a password is entered.  
       [0008] Unfortunately, none of these prior art file formats allow multiple tracks of music to be stored in a single physical file. Consequently, music must be downloaded and licensed on a track-by-track basis. Music companies have long known the advantages of selling music by the album, CD, or other such compilation, since consumers would be encouraged to purchase multiple tracks of music to obtain one or two desired songs. Meanwhile, users miss the advantages of hearing an entire grouping of music in the way originally intended by the artists. Finally, storage space is wasted when a user must download multiple independent tracks in order to recreate a CD of music, since common items such as jacket cover images, artist images, and credits must be recreated in each separate file. What is needed is a music file format that allows multiple tracks to coexist in the same file, with common information that is shared among the tracks stored only a single time within the file. What is further needed is a multi-track music file that selectively uses encryption to aid in the development of on-line music license schemes.  
       SUMMARY OF THE INVENTION  
       [0009] The present invention meets these needs by providing a method and system for storing multiple tracks of music in a single physical file. In addition, the invention includes a method and system for associating text, images, and other content within the file with either a single music track or with all of the tracks contained within the file.  
       [0010] This is accomplished by defining a structured storage file containing multiple layers of organization. The top layer contains separate folders for each track, as well information associated with the compilation of all tracks.  
       [0011] The present invention also provides a secure link to licensing schemes. This link is the header file found within the top hierarchy layer of the music file. The header file contains a vendor ID and a product ID, which allows licensing software to examine the file and uniquely associate it with a particular license. If the user attempting to play the file has the correct license for the music present on the PC, the software will play the music found in the file. If no music license is present, then the software will refuse to play the full music tracks, but may still play any “preview” tracks that are included in the file and authorized without licensing.  
       [0012] The link to licensing schemes is secured through the use of selective encryption of the music file. To prevent tampering with the Product ID or Vendor ID, the header file is encrypted, specifically with DES encryption. All software programs that are designed to play the multi-track music files must be able to access the header, so the same DES key is used to encrypt every header used in the present invention.  
       [0013] In addition to securing the header, it is important that the actual music contained in each track be encrypted. In this case, however, it is inappropriate to use the same encryption key with every file of the present invention. Rather, in the preferred embodiment a separate encryption key is used for each compiled file. Ideally, this key is determined or identified by combining the product ID (and perhaps the vendor ID) found in the header of the multi-track file with a user ID associated with the user licensing the file.  
       [0014] While it is possible to encrypt the remaining information in the multi-track file, such as images and liner notes, it is not necessary to do so to maintain the integrity of the music license scheme. Thus, in the preferred embodiment, these additional pieces of information in the file remain unencrypted for easy and fast access during music playback. 
     
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
     [0015]FIG. 1 is a representational view of the multi-track file of the present invention in the context of creation, playback, and licensing.  
     [0016]FIG. 2 is a representational view of the root directory of the multi-track file of FIG. 1, showing the file header, track folders, and other content.  
     [0017]FIG. 3 is a detailed view of the file header shown in FIG. 2.  
     [0018]FIG. 4 is a detailed view of a track folder having a track header and other content.  
     [0019]FIG. 5 is a detailed view of the track header shown in FIG. 4. 
    
    
     DETAILED DESCRIPTION OF THE INVENTION  
     [0020] 1. Construction of File  100   
     [0021] As shown in FIG. 1, the present invention provides a method and system for storing multiple tracks of data in a single computer file  100 . The present invention is ideal for the creation of multi-track files containing musical data. As a result, the following description will be presented using musical data as the type of data contained in the present invention. However, it would be well within the scope of the present invention to apply to the present multi-track file structure to other types of audio-video materials that must be licensed, such as non-musical audio data, textual data, video data, graphical data, and audio-visual data.  
     [0022] The multi-track file  100  is created using a producer program  102 , which is represented in FIG. 1 with a funnel. This representation illustrates that the producer  102  takes numerous and disparate sources of information and combines them into a single file  100 . The file  100  is played with a player program  116 , which is shown as an inverted funnel since this program  116  extracts the data from the multi-track file  100 .  
     [0023] As illustrated in FIG. 1, producer  102  can accept as input multiple tracks of music  104 , liner notes and/or lyrics  106 , images  108 , video data  109 , UPC codes  110 , and general information data  112 . The information data  112  contains information about the music such as the name of the musician(s), the title of the music collection and individual tracks, etc.  
     [0024] The formats of the inputted materials  104 - 112  is immaterial to the present invention, as the formats can either be converted by the producer program  102  to a preferred format in the multi-track file, or the materials  104 - 112  can simply be stored in the file  100  in the original format. Typically, the data in the music tracks  104  is provided in either traditional CD audio format or a standard waveform format such as WAV, AIFF, or AU. If the tracks  104  are provided in one of the uncompressed formats, the producer  102  will compress the tracks  104  into a compressed format such as MP3. In the preferred embodiment, compression ranging from 32 to 320 kb/s per second is supported. Images can be stored in any of the well-known compressed file types such as JPEG or GIF. Video images  109  can also be added and stored in file  100  using a compressed format such as AVI (Video for Windows), MPEG, or Quicktime.  
     [0025] The producer program  102  is in communication with a registration server  114 . This server  114  can be physically located on the same or nearby computer as that operating the producer  102 . Ideally, however, the registration server  114  is remotely located, and in communication with multiple producer programs  102 . The registration server  114  provides the producer  102  with a product identification code for the file  100 . In addition, the registration server  114  provides the producer  102  with an encryption key to be used for encrypting musical data  104 . Both the product ID and the encryption key should be unique to the file  100  being created. Alternatively, vendor identification can be placed in the file  100 , and the combination of the vendor identification and the product ID can uniquely identify a file  100 . At this point, it is also possible to add security features such as watermarking technology to the file in order to add another level of protection to the file.  
     [0026] Once the file  100  is created, the content within it can be presented to end users through player software  116 . Preferably, the player software  116  is capable of playing the musical tracks  104  to end users, while also allowing users access to the lyrics  106 , images  108 , and general information data  112 . A sophisticated player  116  would also be able to take UPC code  110  and electronically search various audio/video Internet-based retailers for the availability and price of physical copies (such as a CD) of the music collection in file  100 .  
     [0027] In the preferred embodiment of the present invention, player  116  offers only limited access to the content of file  100  until the user licenses the file  100 . When the user desires complete access, the player  116  contacts a license server  118 , which ideally is physically distant from the player  116  and is accessed through a computer network such as the Internet. The license server  118  is either the same as the registration server  114 , or can receive information (such as the encryption key associated with a product ID) from the registration server  114 .  
     [0028] The license server  118  receives from player  116  the product ID originally created by the registration server  114 , and returns some kind of license that allows the player  116  to decrypt the music in file  100 . This license either contains the key used for decryption, or provides the player  116  with sufficient information that the key can be generated.  
     [0029] 2. Root Level  
     [0030] The multi-track file  100  is shown in more detail in FIG. 2. The file  100  is a type of structured storage file, such as the structured format specified by Microsoft Corporation (of Redmond, Wash.) in its Object Linking and Embedding (“OLE”) system. Structured storage files allow data to be compartmentalized and stored in a hierarchical structure using directories or folders, just like files in a hard drive. The items shown in FIG. 2 are those items that are found at the root level of the file  100 . In the Figures, thick bold lines indicate encryption, while thinner lines indicate that information is not encrypted.  
     [0031] Conceptually, the multi-track file  100  is structured similar to an album or CD containing music, with some information relating to the CD as a whole, and some information relating to each of the tracks  104  on the CD. As a result, the file  100  must contain a file header  120 , which contains information about all of the tracks  104  in file  100  as a whole, i.e., “meta-data” about the file  100 . The file header  120 , which is described in more detail below in connection with FIG. 3, is where the CD title, artist name, and product identification are kept.  
     [0032] In addition to the file header  120 , the file  100  must also contain a version indicator  122 . This indicator  122  lets player programs  116  that examine this file know what version of the present invention was used to create the file  100 . While this information could easily be stored in the file header  120 , it is maintained outside the header  120  to allow the header  120  to be encrypted without encrypting the version information  122 .  
     [0033] All music in the file  100  is contained in one or more track folders  200 . Although only one track folder  200  is required to exist in the present invention, it is preferable to have multiple track folders  200  in a single file  100 . Three track folders  200  are shown in FIG. 2. In addition to the actual music data for each track, the track folders  200  also contain information that is relevant only to a particular track, such as track title and lyrics. The track folders  200  are discussed in more detail below in connection with FIGS. 4 and 5.  
     [0034] While not required, the multi-track file  100  will often also contain at least one image file  124 . These images  124  can then be displayed to the user while reviewing or playing music from the multi-track file  100 . Image files  124  that are stored at this level in the file  100  are associated with the whole CD. If it is desired to associate an image  108  with only a singe track of music, the image file  124  should be stored in the appropriate track folder  200 , as described below. Although not shown in FIG. 2, it is also possible to have video  109  and other types of data associated with the whole file  100  stored on the root directory.  
     [0035] It may also be desirable to have liner notes  126  or other textual information associated with the entire CD. Such notes  126  could describe the artist, the music in the file  100 , or any other information desired by the creator of the file  100 . In the preferred embodiment, liner notes  126  are stored in rich text format to allow formatting of the text. Any other format for such information would be within the scope of the present invention.  
     [0036] 3. File Header  120   
     [0037]FIG. 3 shows the information that is stored in the file header  120 . As explained above, the file header  120  contains basic information about the collection of music contained in file  120 . Included in such basic information are the title of the collection  150 , the artist&#39;s name  152 , the genre of the music  154 , and the year(s) the music was recorded  156 . The creator of the music may also wish to include links to World Wide Web sites describing the artist (artist URL  158 ) and where a physical copy of the music CD can be purchased (buy URL  160 ).  
     [0038] The file header  120  also contains the vendor ID  162  and the product ID  164 . As explained above, the product ID  164 , either alone or in combination with the vendor ID  162 , will uniquely identify the file  100  to the license server  118 . The vendor ID  162  is also used to inform the license server  118  of the vendor who should be compensated for the granting of a license. Alternatively, the product ID  164  can be uniquely associated with a particular vendor  162 , and the vendor information can be stored in a database on the license server  118  that associates a product ID  164  with a particular vendor. In this case, it would not be necessary to include the vendor ID  162  in the file header  120 .  
     [0039] The track count  166  within file header  120  identifies the number of tracks that are found within the file. The track names  168  identify the names of all of the tracks  104  in file  100 . Since multiple names need to be stored in the track names  168  area of the header, it is preferred to format the track names  168  area as a list type data structure. In this way, multiple names can exist in the track names area  168  of the file header  120 .  
     [0040] Similarly, file header  120  also contains image count  170  and image names  172 , which contain the number and names of images  124  stored at the root level of multi-track file  100 . In addition to number and names of images  124 , the file header  120  also contains the type  174  and the checksum  176  for each image  124  at the root level of file  100 . The type  174  value indicates which type of formatting was used to encode the image  124  into digital format. The checksum values  176  ensure that the images  124  stored in the file  100  have not been altered since the file was created. In FIG. 3, separate areas  174 ,  176  are shown in header  120  for each image  124 . Alternatively, it would be possible to utilize a list type data structure for these values, such as that used for track names  168  and image names  172 .  
     [0041] File header  120  also contains a liner notes checksum value  178  and the UPC Code  180 . The checksum value  178  helps ensure that the liner notes  126 , stored unencrypted at the root level of file  100 , have not been altered since creation. The UPC Code  180  can be used to help search the Internet or a similar network for parties who sell the physical CD represented by file  100 . By searching on the UPC Code  180 , it is possible to avoid the ambiguities involved in searching by artist  152  or CD title  150 .  
     [0042] Finally, the file header  120  contains an export ID  182 , an export mode indicator  184 , and the server name  186 . The export ID  182  and export mode indicator  184  serve to signal the player whether to allow “export” to standard audio CD or portable device, and if so what price, if any, to charge the user. If export were allowed only after obtaining an additional license, the player software  116  would request a license from the license server  118  using the export ID  182  in place of the product ID  164 . The server name field  186  provides the name of the registration server  114  that created the product ID  164  and the encryption code used by the producer  102  to create the multi-track file  100 .  
     [0043] 4. Track Folder  200   
     [0044] The track folder  200  is shown in FIG. 4. As explained above in connection with FIG. 2, one track folder  200  exists for each music track  104  found in file  100 .  
     [0045] The most important elements of the track folder  200  are the track header  202  and the music data  204 . The track header  202  is similar to the file header  120 , in that it is an encrypted data segment that contains basic information about the track. The track header  202  is encrypted to protect the integrity of the information it contains. The decryption key used to decrypt the track header  202  is the same for every multi-track file  100 , and is stored in the player  116 . Typically, this decryption key is also the same key used to decrypt file header  120 . The contents of the track header  202  are explained in detail below in connection with FIG. 5.  
     [0046] The music data  204  contains the actual information needed to play music for the track  104 . This information is preferably compressed in any of the standard compression technologies, such as the MP3 format. The information is encrypted using the encryption key that was received from the registration server  114  by the producer  102 . This decryption key is unique to the individual file  100 , but is shared between all of the music data  204  storing the tracks  104 . Consequently, it would be impractical and counter-productive to basic licensing schemes for the player  116  to store all of the decryption keys used for all of the possible multi-track files  100 . As a result, although the player  116  has access to all of the rest of the data in the file  100 , the actual data containing the music tracks  104  is encrypted and kept from the player until the decryption key is made available to it. This is typically accomplished through interaction with License Server  118 , as described above in connection with FIG. 1.  
     [0047] The track folder  200  also contains preview data  206 , which is typically unencrypted music data. Preview data  206  is generally a subset of the data contained in music data  204 , and is made available to users of the player program  116  that have not obtained a full license to the multi-track file  100 .  
     [0048] Textual data is also saved in track folder  200 , such as lyrics  208  and track liner notes  210  that are specific for the track  104 . Track liner notes  210  can exist in some track folders  200  but not in others. Where track liner notes  210  do not exist, the file wide liner notes  126  are assumed to be applicable. In this way, the liner notes  126  stored at the root level of file  100  can serve as the default liner notes, which are overridden by track liner notes  210  for a specific track.  
     [0049] Track folder  200  can also contain one or more track images  212  that are specific for the track  104 . Much like the track liner notes  210 , track images  212  can be stored in some track folders  200  but not in others, allowing the main images  124  stored at the root level to serve as default images for tracks without track images  212 .  
     [0050] Note that while the preferred embodiment of the player  116  utilizes the track specific images  212  and liner notes  210  to override the general images  124  and liner notes  126 , this is not the only available option within the scope of the present invention. Alternatively, the player  116  could make the general liner notes  126  and the track specific liner notes  210  available at the same time. Similarly, player  116  could display both the file wide images  124  and the track images  212  simultaneous or consecutively during playback of a specific track  104 .  
     [0051] 5. Track Header  202   
     [0052] The track header  202  is shown in detail in FIG. 5. Since it is possible to store track music data  204  and preview data  206  in different types of compressed music formats, the track format type  250  and the preview format type  252  are stored in track header  202 . Possible types that could be indicated in these locations  250 ,  252  include MP3, MOD, AIFF, and WAV. The track header  202  also contains the name  254  of the track  104 , a URL  256  that can be associated with a track  104 , and the duration  258  of the track.  
     [0053] As was the case with images  124  stored in the root area of multi-track files  100 , it is necessary to store the image type  260  of the track images  212  stored in each track folder  200 . It is also useful to maintain a separate checksum  264  for each image, to ensure that the images  212  in the track folder  200  have not been modified since creation. Finally, the track header  202  also contains checksums  266 ,  268  to verify the integrity of the track liner notes  210  and the lyrics  208 , respectively.  
     [0054] 6. Encryption and Distribution of File  100   
     [0055] The multi-track file  100  of the present invention uses partial encryption using different encryption keys to increase the usefulness of the file  100  in license protection schemes. Because of the unique structure of the present invention file  100 , it is possible to develop a licensing scheme that does not require any alteration of the files before, during, or after licensing.  
     [0056] For instance, a licensing scheme could be developed in which the player  116  would allow access only to the preview data  206  for each track  104  before licensing. The player  116  would also allow an unlicensed user to view basic information about the CD contained in the file  100 , such as the title  150 , artist  152 , and images  124 ,  212 . In fact, the user could even access purchase information obtained by the player  116  searching retail web sites using the UPC code.  
     [0057] When the user wishes to obtain a license to the file, the player  116  would contact the license server  118  to obtain the license. The license could be physically embodied as a computer file or as an entry into a registration database saved by the player  116  or the operating system on which the player  116  is operating. The player  116  would automatically search for an appropriate license whenever a multi-track file  100  is opened. The player could verify that the license on the computer is appropriate for the file  100  by comparing the product ID  164  in the file header  120  to a product ID found in the license. In addition, or alternatively, since the decryption code needed to decrypt the music data  204  is unique to the file  100 , only a license for the correct file  100  will decrypt the file  100 .  
     [0058] Because the existence or non-existence of a license does not alter the multi-track file  100 , the file  100  can be distributed freely. Other licensing schemes require that the licensed file be distributed concurrently with the licensing of the file, because the licensed is embedded directly into the file itself. These schemes do not allow the files to be distributed on numerous servers, nor can an already licensed product be effectively distributed to new, unlicensed users.  
     [0059] It is possible to tie a license received by a player  116  to a specific user or computer on which the player  116  is operating. This is accomplished by sending user or computer specific information to the license server  118 , which would allow the license server  118  to incorporate such information into the license sent back to the player  116 . The player  116  would then examine that information in the license to ensure that the license is appropriate for this user or computer.  
     [0060] The player  116  can be a specially configured application designed solely for playing multi-track files  100  of the present invention. Alternatively, the player  116  can be a general music application that accepts plug-ins, where a plug-in is designed to handle licensing and decoding of the encrypted elements of the multi-track files  100 .  
     [0061] The invention is not to be taken as limited to all of the details express above, as modifications and variations may be made without departing from the spirit or scope of the invention. For instance, although the preferred embodiment encrypts the file header  120  and the track header  202 , it would be within the scope of the present invention to leave these unencrypted. Also, although this encryption uses a different key than the encryption used for music data  204 , it would be possible to use the same encryption key.  
     [0062] In addition, while the images  124 ,  212  are not encrypted in the preferred embodiment, it would be well within the scope of the present invention to encrypt the images  124 ,  212 . Finally, while FIGS.  2 - 5  show only one type of complex digital data (images  108 ) as included in the file  100 , it would be well within the scope of the present invention to include video data  109 , or any other type of digital data, including database or word processing files. Many possible combinations of features and elements are possible within the scope of the present invention, and therefore the scope thereof should be limited only by the following claims.