Computer system and method for secure distribution of information products
The present invention relates to a method and a system for secure distribution of information products such as music, text, pictures and video, and for peer to peer trading of such products.
Information products such as music, pictures, text and video, and also other information products such as computer software, can now be distributed electronically without creating a physical copy that embodies the actual product. However, there are usually intellectual property rights such as copyright involved in the information product, and when such information is distributed digitally it is possible to make unlimited copies without any deficiency in quality.
It is a well known problem that unauthorized copies of software, so called warez, are made available on the Internet. With the growing popularity of the MP3 (MPEG Audio Layer 3) file format, this problem has also become substantial with regard to music, as a number of well publicized cases have demonstrated.
Several attempts have been made in order to lessen the impact of such problems. Computer software is often distributed in a partly disabled version or in a version that expires after a certain period of time. The fully functional version will then be made available by purchasing a key that unlocks the software. In order to prevent unauthorized copying of the unlocked software, some information extracted from the hardware of the computer on which the software is installed may be encrypted and hidden in the code of the software, only enabling the software to be used on the computer on which it was first installed. This results in inconvenience for the user, particularly when upgrading hardware or replacing the computer. Several efforts have been made with respect to copy protection of music and pictures, such as watermarking the file in some way in order to prevent copying. The Secure Digital Music Initiative (SDMI) has introduced a specification for a system of preventing the distribution of pirated copies of music.
Traditionally, intellectual property rights in a product are exhausted as of the first authorized sale of that particular product. This means that the owner of the product, while he may not make copies of the product, is free to use or sell the product as he pleases. When an information product is sold in the intangible form of information downloaded from the Internet, it is very difficult to separate between the buyers right to do with his product as he pleases and the rights owner's right to restrict copying, since any movement of information between computers strictly speaking involves the creation of new copies.
By way of the present invention it will be possible to create individualized copies of information products such as music in a manner that to a large extent prevents unauthorized copying and use of such products. According to a particular feature of the invention, however, it is possible for the owner of the individualized copy to move his copy to a different computer or device, or to trade his copy by transferring his rights to the particular copy to someone else. The invention also describes a system for allowing two users to trade their rights to individual copies of respective information products, particularly songs.
In a first embodiment of the invention, a secure system for distributing information products is provided. The system comprises a unique master server upon a server computer system, unique clients upon client computers or devices, and one or more known publisher servers upon server computer systems. The various units of the system communicate over a communication network such as the Internet.
The master server includes at least a user registration database containing data relating to all registered users, a database record of information products downloaded by authorized users, and a file index of authorized information products. It should be noted that registered users may include all with access to the system, e.g. end users who download information products, owners that provide information products, and third party rights holders that may have an interest in accessing statistical information regarding products in which they hold rights.
The master server may also contain the actual information products, but according to a preferred embodiment, the information products are only indexed in the master server, while the actual information products are located on publisher servers.
According to one alternative embodiment of the invention, the master server will also include a trading database listing information products users wish to trade and what information products they want in exchange.
The publisher servers are servers from which the information products are uploaded. According to one embodiment of the invention the information products are uploaded to be stored on the master server, but according to a preferred embodiment the actual information products are contained on the publisher servers and downloaded directly to users who gain access to them through the master server. In order for an information product to be indexed and stored on the master server, it must originate from a known publisher server operated by a publisher that is capable of demonstrating his rights in the information product he wishes to distribute.
The unique clients are user computers or devices that are able to access the master server. By using such a client, a user may register as a user of the system according
to the invention by entering personal information into the user registration database. The registration procedure involves the generation of an encryption key that is unique to the user. This key is stored on the client as well as the master server. After registering he may acquire authorized copies of information products that will be downloaded to his client computer or device as an individualized and encrypted copy of the information product. The information product is individualized by being encrypted by the users key and by having some additional information extracted from the hardware of the users client computer or device incorporated in the file or files containing the information product. The file or files remain encrypted on the users client computer and can only be played or viewed by using special client software that decrypts the file on the fly. When a user acquires an information product in this manner, the database record of information products downloaded by authorized users will be updated to reflect that this information product has been purchased by this user. Preferably, a similar record of all purchased information products will be maintained on the client computer or device.
According to one embodiment of the invention, the user will also be able to access the master server and register information products of which he owns a copy as up for trade in a trading database along with a listing of information products he is willing to accept in exchange. A user can only offer products that are listed in his list of authorized information products, as stored in the database record of information products he has downloaded. If a user can find an information product he wants as offered for trade in exchange for an information product he already owns and wishes to trade, he may initiate such a trade. The master server will then delete the respective information product files from the clients where they were originally stored, remove the respective information products from the lists of authorized information products of their original owners and enter the information product in the list of the new owner. Also, the master server initiates the download of new individualized files of the respective information products to the new owner of the respective product. There is no need to transfer the original file from one client to the other. If a user tries to keep a copy of the information product he is giving away by making a backup copy of the individualized file, he will not be able to access the contents of this file, since it has been removed from his list of authorized information products. If there is a difference between the list found on the client and the list on the master server, the master server will overwrite the list on the client. This prevents the user from making a backup copy of the list of authorized information products. As an additional security measure, the master server may deny access to a user whose list of authorized information products does not conform with the corresponding list on the master server.
The client software according to the invention may include the player/viewer for the information product, or it may be a so called plug-in that enables a payer/viewer to access a file that is encrypted in accordance with the invention.
The actual payment of an information product that is purchased in accordance with the invention is not part of the invention as such. A number of methods for payment may be used, such as subscription, charging to an account etc.
The particular features of the invention is set forth in the appended claims.
The invention will now be described in detail by way of a non-limiting example and with reference to the enclosed drawings. Figure 1 shows an overview of the system according to the invention,
Figure 2 shows a flowchart indicating the flow of information in a system according to the invention,
Figure 3 shows a class overview of a client according to the invention.
In the following example, an embodiment of the invention relating to distribution of music is described. However, it should be noted that with only minor modifications not departing from the scope and spirit of the invention, the example could be modified to include distribution of other information products such as pictures, video or multimedia. The invention is not well suited for the distribution of text-files or other information that can be copied directly when viewed, but it would be possible to distribute text e.g. as graphics or in other formats that allows on screen reading but not editing or copying, such as PDF-files.
Reference is now made to FIG. 1, which illustrates the system according to the invention. The figure illustrates a number of additional features that may or may not be present in a system constructed in accordance with the invention. The system includes a number of unique clients 1 which preferably include an MP3 player, a song list organizer, an audio equalizer, an Internet browser, exchangeable skins (dynamic GUI), peer-to-peer song trading and auction capabilities, a targeted messaging window, access to online CD shopping and to an online MP3 song database, a client for integrated file search and ftp/http-downloading, and unique capabilities for file decryption, song rights tracking, and persistent copyright status notification. The client is preferably embodied as client software installed on a client computer or some other client device such as a personal digital assistant (PDA).
The system further includes a unique master server computer 2 in communication with the clients 1 over the Internet 9 or other communication networks. The master
server may include features that enable the peer-to-peer song trading and auction, the online CD shopping service and the online MP3 song database. Tables or databases controlled by or included on the master server include a database of song lists of unauthorized songs 3 and a database of song lists of authorized songs 4. There is one of each of these lists for each unique user. Further, there is a database of unique user registrations 5, a CD shop and trading database 6, a database with an authorized music file index 7 and a database with an unauthorized music file index 8.
In addition the system comprises one or more known publisher database 10 and optionally it may include one or more unknown publisher servers 11. The publisher database 10 may be part of or controlled by the master server 2, even as an integrated part of the authorized music file index 7, or it may exist on one or more separate servers accessible over the communication network 9.
The master server computer 2 is preferably constructed as one or more server computers complete with the necessary communications and processing means for executing the various functions of the system, a database management system, and various storage means or computer memory.
The system according to the invention allows for two main varieties. According to a first embodiment, the unique master server 1 does not include the actual music files, only the music file index databases 7, 8. In this case a user may search through the index databases 7, 8 in order to locate songs he or she wants to purchase, but the actual song will be downloaded from one of the publisher databases 10, 11. Alternatively, owners of the publisher databases upload music files to the master server 2, and in that case the music file index databases 7, 8 will be extended to also include actual music files. This second alternative can also be described as a system where one or more known servers 10 are operated by the operator of the master server 2 and are more or less tightly integrated with the master server 2.
The following description is based on the alternative where files are stored on the publisher servers 10, 11.
MP3 files may are stored on an unknown computer 11. The files will either be unauthorized, illegitimate (e.g. "Yesterday" by the "Beatles" encoded, or ripped, from a CD released by Capitol Records.), or they will be unauthorized, legitimate MP3 files which are stored on an unknown computer 11, but which are legitimately owned by the owner of the unknown computer (e.g.. "Eat at Joe's" from "Joe's Bar and Grill Garage Band" not released by any record label).
Either of these unauthorized, illegitimate or unauthorized, legitimate music files may be published by an unknown publisher on an HTTP or FTP server 11 that is neither owned nor controlled by the operator of the master server 2. Authorized legitimate songs may be published on an HTTP or FTP server 10, which may or may not be owned or controlled by the operator of the master server, but, by using the known server software, the authorized legitimate song publisher may post a legitimate declaration of ownership of copyright. The known server 10 software is available for publishers who want to use the system according to the present invention in order to publish authorized legitimate files from an independent server, or from a server owned by the operator of the master server. Publishers using the known server software will be registered in the master database 2 as known publishers. Similar software may be available for third party holders of rights in the information product, such as songwriters or authors, in order to access statistical information on the master server 10. On the master server 2 a file index of known publisher MP3 files (authorized legitimate) and a file index of unknown publisher MP3 files (possibly unauthorized illegitimate or possibly unauthorized legitimate) for the entire Internet domain, are maintained. These indices are stored in the database with authorized music file index 7 and the database with an unauthorized music file index 8, respectively. These databases 7, 8 are open and can be searched by all client computers 1 equipped with client software. The authorized music file index is added to periodically by publishers using the known server software and the unauthorized music file index is added to by frequent "crawling" of the Internet by the master server 2 "spider" software. Deletions are made to the index for dead links and unreliable servers.
Using the client software on his client computer or device 1 , a user can search online for keywords by Artist, Song Title, Publisher or Genre, and receives "hits" from the index. The user may then select files he wishes to download from the list of hits and initiate download by clicking the "download" button. Following the request by the user, the client 1 is connected to the known 10 or unknown 11 HTTP server or FTP server and download of the MP3 files to the user client commences. Download may be directly from another client 1 (peer-to-peer), but such a music file will only be playable if it is an authorized legitimate file. A key feature of the invention is that the unique player will only play files uniquely encoded when downloaded to that particular client- that is, only the Known Server is enabled with file encryption capability and unauthorized, illegitimate files received via peer-to-peer transfer will not be playable on the Client 1. All clients will be able to play unencrypted files.
If the received music file is from a known server 10, it is an authorized legitimate file, and the words "authorized copy" will appear with the download message, as well as tagged to the file when the song name is displayed in the unique Play-list. Furthermore, the file is encrypted with an encryption key that is unique to the user when the file is downloaded from the known server. This unique file can only be played using the player that is part of the client to which it was downloaded. If the user transfers the player and the file to another machine, the song will not play until the user re-verifies his anonymous user name and password. This is achieved by embedding unique hardware information derived from the user computer 1 into the encrypted file. Following a re-verification, the player and file will not work on the client that the software was located on prior to transfer (re- verification).
Because of this, the system according to the invention makes it extremely difficult for the user to distribute additional copies of the file, via peer-to-peer file sharing, whether these files are transferred separately or along with a copy of the player. However, if the user wishes to trade authorized, legitimate files, via peer -to peer, this is enabled and controlled via a similar method of unique player and unique file encryption.
If the MP3 file is from an unknown server it is either an unauthorized illegitimate or unauthorized legitimate file. Then the words "unauthorized copy" with a "copyright warning" appears with the download message and the MP3 file is further tagged with the same message when the song title is displayed in the unique play-list. Furthermore, the file is encrypted with the users unique encryption key upon download to the known client 1 (every copy of the client software is numbered and therefore "known" but the user remains anonymous). Again, this unique file will only play on the client computer 1 to which it was downloaded, which means that the user will not be able to redistribute the unauthorized copy. If the user transfers the player and the file to another machine, the song will not play until the user re-verifies his anonymous user name and password. If the user transfers the file to another machine, the song will not play without the authorized player it was downloaded to.
In either case, the encryption software allows the MP3 file to be played only on the unique copy client software on the unique client computer 1, and it will be extremely difficult to play the file on a different computer. The second user would have to get a second unique copy of the client software and to go back to the source server to get a second copy of the file and that file would again be encrypted and unique, either at the known server or at the known client.
The unique master server 2 anonymously tracks, in a database 3, 4, the list of songs that are downloaded to each unique player 1. The players are tracked by number
and the users remain anonymous. The user may freely trade or sell authorized songs in his song-list among other users. Unauthorized songs may be disabled at any time by removal from the master database. A song is then disabled because in order to decrypt the song for playing, the song list located on the client is searched for verification, and this list is periodically updated from the master list, while the client is online.
According to a preferred embodiment of the invention, legitimate paid advertisement messages are sent to the user while the user is online and uses the client software. Users of client computers 1 are able to purchase music through online CD shopping, peer-to-peer trading or auctioning of legitimate music files or CDs, or trade legitimate music files or CDs.
When users first log on to the master server 2 using their client computers, they will be able to download client software that, when installed on their client computer or device 1 enables this to work according to the invention. The user must register either prior to downloading the software or the first time he logs on using the client software, and he will then be registered in the user registration database 5. The client software will be uniquely numbered, and a unique encryption/decryption key will be generated and stored on the users computer 1. FIG. 2 shows a flowchart indicating the flow of information between the client 1, the master server 2 and a known server 10 during an authorized download of an information product. When the user registers with the master server 2, a unique ID including an encryption key is assigned and transferred to the client 1. This encryption key may include information extracted from the client computer hardware, or this hardware information may be embedded directly in the information product file during download as described below. The user's encryption key is stored on the client computer 1 as well as on the master server 2, in the user database 5.
When a file is requested from the known server 10, the user is identified and the known server 10 requests encryption from the master server 2. The master server 2 passes the user's encryption key to the known server 10. The file is then encrypted using the user's encryption key. If this key is not generated using hardware information from the users client computer, information extracted from the client computer, and possibly also the unique serial number for the client software, is embedded in the encrypted file, preferably in the header of the file. This information may be received from the client computer as part of the request for download, or it may be stored in the master server 2 during registration and provided along with the encryption key.
The encrypted file is stored on the client computer 1. If the file is transferred to another device IB, it cannot be decrypted because the information extracted from the client hardware will not be available.
Following a successful download, the necessary updates are made in the database 4, and in the song list on the client computer, as described.
A more detailed description of the client software will now be given. The player is made up of a core and a user interface. The application core contains the engine used for mp3 file processing. Several such engines are available, such as the Freeamp player. The Freeamp engine is preferred for this embodiment of the invention because it is open source, it is free and it uses less resources than if any other Java technology (JMF or the SPI facility from JDK2.1.3) had been used. The Freeamp engine was developed using the standard C language, so it should be portable to any platform after recompilation. For the Freeamp core and the rest of the application to communicate, the JNI (Java Native Interface) is used. This is used to define the native methods which are implemented in the Freeamp core and which are accessed from the rest of the modules. It contains methods used for processing mp3 files (ex. Play), methods for processing control (ex. pause, stop), methods that return information about the file in processing (exp. its length in seconds, the number of frames, the name of the artist) and methods to control the sound intensity and frequency on the sound card of the client computer 1.
The player and virtual shop architecture is based on doc/view architecture. This means that the functionality of the new module is described in doc and the interface in view. With this technology, changing the interface is much easier.
The application architecture of the media player is illustrated in FIG 3. The player FTP download classes (no. anet. download. ftp) includes classes for handling remote ftp transfers, signaling that an FTP exception has occurred etc. Similarly the player HTTP download classes (no.anet.download.http) includes classes for handling downloads of individual files, declaring constants used during HTTP file transfers, signaling that an HTTP exception has occurred, tracking download status etc.
The player core classes (no. anet. MP 3. Core) include classes that handle encoding of a bytes/string array to base64 encoding, creating the users default directories, searching for songs in the local MP3 database initiate the MP3 player with "Play" calls, open the file which is to be played, verify that the file is authorized (i.e. that the file is authorized to be played by this player and on this computer), send the users key to the server, handle MP3 exceptions etc. The core classes also include
classes for creating threads that downloads selected files from a specified URL, manage data that is used for displaying advertising and so on.
The player crypto classes (no. anet. MP3. Crypto) handles encryption and decryption. A file that is being saved locally, is downloaded "piece by piece". Each part of the whole file is encrypted, and then the encryption thread saves it in the local file. When the song is being played, each chunk that is sent to the native player to be played, is decrypted first. The encryption/decryption algorithm is preferably chosen among: RC4, DES, DESede and Blowfish. One class is used for generating the user's encryption key. Algorithms that are supported by this class and that can be used for generation may include RC4, DES, DESede and Blowfish. One very important class of the encryption/decryption process contains two methods. The first one (which is also the constructor) initializes the encryption/decryption mechanism with a specific key (which is read from a file) and sets the encryption/decryption algorithm. The second one actually makes the encryption/decryption.
The player also includes classes for handling dialogs, skins, playlists, XML, authorized song list, searching remote server databases, as well as classes handling shopping such as offering and ordering songs.
The client application is a skin based application which allows the user to import Winamp skins and use them. The application is an XML based application.
Application properties and skin properties are both contained in XML files. In this way it is much easier to modify application properties and skin properties without rebuilding the entire application.
The client application is made of four main modules, player, play list, graphical equalizer and search.
The Player module acts as sort of the secretary of the entire system. Basically, it accepts commands from the user and makes sure those tasks are accomplished by making method calls on objects. To access mp3 files a Freeamp core is used. It is described in further detail below. The player module is 70% Winamp skin compatible, allowing a user to import Winamp skins and completing these with its own images, images that Winamp skins do not contain (Ex. Images used for buttons for activating the shop, search windows)
The user may modify the player layout by using the change layout tool. With this tool the user may create a new layout for a specified skin, beside this the user may
change the skin colors with the change skin colors tool. Both results, for layout and colors are saved in the specified skin's XML.
The play list manager contains the active play list. A play list is a list that contains mp3 files; it contains authorized or unauthorized mp3 files. The authorized and unauthorized songs are shown with different colors. The user has the possibility to create a play list, to add new songs to the play list, to remove songs from this list, to save, load and delete the active play list. This module is 70% Winamp skin compatible. To add a song or a directory to the play list, the user simply clicks the open button and with the open file dialog he selects the specified song or directory and it will be automatically added.
Sometimes an MP3 file, just like any audio recording, may sound better if various parts of the frequency spectrum in the file are adjusted. The client software provides a graphic equalizer to help users to tweak the playback as they prefer.
The equalizer allows users to save equalizer settings in a presets file. These files contain the equalizer values in XML files. In addition, the user may attach preset values to a specified mp3 file. Once the presets autoload feature is activated the equalizer values are automatically loaded at the time when the specified MP3 file is being processed.
This is search engine client, integrated into the client software. With this engine users may search for mp3 songs on the Internet or in the users authorized songs list. For searching the Internet, the client computer 1 is connected to a server, and after querying the server and receiving the search results, the client displays the result in the result list. With returned mp3 files list, user may choose items for download or preview. When downloading authorized songs they are automatically encrypted with the users unique key. In this way it can not be played by any other player, only with the users unique client on the users client computer 1. For searching the users authorized song list; the AuthorizedSongList table is queried for the specified song.
Freeamp is the player core module used for processing mp3 files. FreeAmp is an Open Source effort to build the best digital audio player available.
FreeAmp is a modular media player designed to be easily extensible to new media types, sources and destinations. FreeAmp achieves this by abstracting out the major pieces of functionality into a plugin architecture.
Reference is again made to figure 1. The master server 2 comprises or administers a number of databases. The unauthorized song list database 3 contains a list of songs users have downloaded to their client computers 1 from unknown publisher
servers 11 using the system according to the invention. As already described, these songs will be encrypted using the users unique key, and hence they will be unique and they can not be played on other client computers unless they are traded or updated using the system according to the invention. This database contains one list of unauthorized songs for each user. When an unauthorized song is transferred from one user to another as a result of a trade, the song is deleted from the first users list and added to the second users list.
The authorized song list database 4 is similar to the unauthorized song list database 3 in that it contains one unique list of songs for each user. However, these lists contain songs that the user has acquired either by purchasing the song from a known publisher server 10 or by receiving an authorized song from another user as part of a trade. Of course the system can be designed to only handle purchase and trading of authorized songs, in which case the unauthorized song database 3 will not be present, only the authorized song database. The individual user lists in these databases will be duplicated on each users client computer 1, and the client will not play encrypted songs that are not present in one of these song lists, even if they can be decrypted using the users key. The lists on the respective users' client computers 1 will be updated every time a user performs a purchase or a trade, and e.g. every time the user is online. As an additional security measure it is possible to deny access to a user that has manipulated his song lists by replacing it with an older backed up version that contains songs he has already transferred to some other user.
The client will of course be able to play any un-encrypted songs, since these may be legally recorded by the user. The user registration database 5 contains a list of all registered users. When a user first registers, relevant information is entered in this database. It is possible to implement the system as an anonymous system where the users are only registered with user name and the serial number of their client software, or they may be registered with name and address. The former may be preferable in order to maintain privacy e.g. if the users are subject to targeted advertising based on their behavior, while the latter may be preferable if the master server should also handle e-commerce such as receiving orders and credit card payment for 'songs purchased from known publisher servers 10, CDs or other merchandise. Of course it is also possible to create systems where personal information and behavioral information can not be combined, but the aspects of such a system are beyond the scope of this invention.
Every user registered in the user registration database 5 will have one and only one corresponding song list in each of the song list databases 3, 4, and each song list in
the song list databases 3, 4 will relate to one and only one user in the registered user database 5.
The CD shop and trading database 6 contains an overview of items that are available for sale ore trade. These items may be CDs or other merchandise, and in that case they may be handled by e-commerce systems or auction systems that are beyond the scope of the present invention, or they may be songs that are offered by users or known publishers or requested by users. Songs that are offered are listed as such. If they are offered for trade by a user, other users will be able to send responses to the user, listing songs they are willing to trade for the offered song. Songs that are requested are listed as requested, along with songs that can be offered in trade for the requested song. Songs offered in trade in this way can be offered in the alternative, in combination, or as alternative groups of one or more songs.
The songs that are offered or requested in the trading database 6 can be found by searching or browsing. According to a preferred embodiment of the invention, the songs are organized according to artist, record company, musical category, year published and/or other categories, which makes it easier for users to browse. This information can be encoded in the files when they are first offered by known publisher, and songs will the be automatically categorized. The authorized music file index database 7 contains an index of all songs that are available from known publisher servers 10. These songs are registered in the index database 7 when a publisher uses the known publisher software to upload a song to a known publisher server 10 (which may or may not be operated by the operator of the master server 2) and register the song with the master database 2. This index is accessible for search by the client computers 1.
The unauthorized music file index database 8 contains an index of songs that are available from unknown publisher servers 11. There is no way for the master database 2 to verify whether these files are legitimate or in violation of copyright. In this respect the unauthorized music file index database 8 is similar to search engines on the Internet. It is simply an index of files that are available. However, if a music file is found using this index and downloaded using the client software on a client computer 1 , the file will be encrypted by the users unique key, and the user will not be able to distribute additional copies of the file.
In the following description it is assumed that all involved computers are online. In the case that one or more computers are off-line, messages will be stored and forwarded by the master server, they can be sent by e-mail, or some actions will have to be postponed until the relevant computer again is online. Those skilled in
the art will realize that this can be handled in a number of different ways that are rather trivial.
If a user using his client computer or device 1 finds songs that are offered and that he desires, or songs that are requested and that he is willing to trade for the songs offered in exchange for the requested song, he can respond to the offer or request. If he is responding to an offer, a message is sent from the responding users client computer to the client computer of the user making the offer. This message indicates which song or songs the user is willing to give in trade for the offered song. The user that made the initial offer is able to review received messages and accept or reject them.
If a user using his client computer finds songs that are requested and that he wants, and the song(s) offered in exchange for the requested song are songs he wants, he can indicate which song or songs he wants among those offered in exchange for the offered song and accept the trade. When a trade is accepted in one of these ways a number of steps are performed. Each user receives a file of the song the other user has offered. This file may be transferred from the original user to the new user, but in that case it must first be decrypted using the original users key before it is encrypted using the new users key. Preferably the file is downloaded from a publisher server 10, 11 that is located by way of one of the index file databases 7, 8 in the master server 2. Each file is encrypted using the key of the receiving user. The encryption can be performed either by the known publisher server 10 using a copy of the key received from the master server 2 or the user client computer 1 , it may be performed by the master server 2 using the users key stored in the user registration database 5, or it may be encrypted by the user client computer 1 using client software and the locally stored user key. Each of these alternatives have advantages and drawbacks. The first alternative means that the users key must be transmitted over the Internet every time a file is encrypted. The second alternative means that every download must be routed through the master server 2. The third alternative means that the file will not be encrypted until it arrives at the client computer 1, and that a sniffer on the input port of the computer may be able to make an unencrypted copy of the file. It is a matter of implementation to choose the alternative that is considered preferable. Files are encrypted and downloaded "piece by piece", and they are also handled in this manner at playback, when each piece is decrypted and entered into a buffer. Obviously the alternative of sending the key to the publisher server can not be used when the publisher server is an unknown publisher server 11 , since such a server will not be equipped with the known server software enabling it to handle the encryption.
When the header of the file is encrypted, information unique to the client computer 1 is included. This information can e.g. be the serial number of the hard drive or the network interface card (NIC). Also the unique serial number of the client software is included. In this way the file can only be played by the unique client software by which it was downloaded, on the unique hardware to which it was downloaded, and only with continued access to the users key. If the client software is replaced, moved to another computer or if hardware is upgraded, the user will have to re-register, and all the header files of his songs will be updated accordingly. When a song is successfully downloaded to a client computer 1, it is entered into the authorized or unauthorized song list on the client computer 1, and also on the users song list in either the authorized 4 or unauthorized 3 song list database on the master server 2. If the song was downloaded as a result of a trade as described above, the song(s) given in exchange for the new song will be deleted from the relevant song list. It is not necessary to delete the actual encrypted song from the client computer, since the song can no longer be played after it is removed from the users song list.
In a preferred embodiment all exchange of song files, keys and any other user information including serial numbers, is done using secure communication, such as SSL and HTTPS (HTTP over SSL).
Encryption of song files and song lists are preferably done according to RC4, DES, DESede or Blowfish. The key length of the user key used for encryption is preferably 64 bits. This bit length allows for sufficiently strong encryption while still not demanding too much processor power for a relatively lower scale client computer to decrypt a file during playback. Other bit lengths may be selected based on other implementation specifications.