CA2338674A1 - Peer-to-peer file exchange system - Google Patents

Abstract

The present invention provides a method and apparatus for the delivery of files across the Internet and Wireless application networks. The present invention seeks to combine the ability to download music for free, provide compensation to content creators, and provide statistics that may be sold to record labels, artists, and other interested parties. All files in the system are approved by the artist, or copyright holder, and are as such guaranteed for quality. The method also introduces a new feature unavailable on present peer-to-peer systems: it allows the user to search for files based on parameters that are not uniquely associated with the name of the file. In its present embodiment as a music file sharing system, this search feature would include, for example, a search based on genre of music, or record label.

Description

TERMINOLOGY
UPLOADER:
The Client that provides a file to another client.
DOWNLOADER
The Client that requests a file from another client.
BACKGROUND
With the advent of file sharing software, users are increasingly becoming accustomed to free, near-CD
quality music and videos. Soon, it is predicted that other formats such as electronic books will be downloadable. Efforts to encrypt digital files have so far proven unsuccessful.
If it is assumed that digital file transfer cannot be reliably encrypted, a new method must be introduced to reimburse content creators or copyright holders that is radically different from the present "pay-for-play"
model. The present invention seeks to provide this new model by supplying free digital files for the end user while compensating the copyright holder or the content creator.
The present method and apparatus provide a remedy for the current problems facing the peer-to-peer file sharing market. Several peer-to-peer systems exist today, each of which have several drawbacks. None of these systems compensate artists or copyright holders, nor do these systems guarantee the quality of the files being used on their respective systems. Because of their decentralized nature, these systems cannot generate statistical data. A user may only search for songs or artists based on a given string.
The most popular peer-to-peer system, Napster, has had a far-ranging impact on the recording industry.
Napster and similar software allow file sharing among millions of users.
Napster has a centralized server, which contains no files. Instead, it holds records of users and the songs that exist on the respective user's machines. These users generally copy songs on their machines by converting WAV
files from CDs ("ripping"), or by obtaining these files through Napster. A user may obtain virtually any song he or she desires, as Napster has over 50 million clients subscribed to its system.
The most obvious disadvantage to this system is the fact that artists and copyright holders do not get compensated. Also, a file may be of substandard quality.
Gnutella is a file-sharing system that does not use a centralized server.
Gnutella is type of application, not a corporation, and there are many different providers of interfaces in the Gnutella network. As with Napster, content providers do not get paid. Unlike Napster, users on the Gnutella network may share files other than music, such as video and text files. A client connects to another user on the network, and recursively connects to the other users also on the network.
The Secure Digital Music Initiative (SDMI) is a consortium of record industry players who aim to produce a standard format for digital audio files. These files would include a bit which would indicate whether the file has been downloaded illegally or pirated. As their name implies, SDMI
seeks to deliver files in a secure format, which means that current mp3 players would not be able to play these files. The present invention also has its own key that identifies each data file. However, unlike the SDMI proposition, these files can be played on any system that supports MP3 files. With the wide availability of existing compact discs (easily transferable to the MP3 format), and the fact that present MP3 players support these non-secure files, this initiative is predicted to face difficulties in gaining acceptance. It is also questionable whether any type of encryption is secure enough to withstand attacks from hackers.
Therefore, the recording industry and its associated distribution system face radical change in the coming years. In its current embodiment, the present invention seeks to provide users with free downloads, as they are quickly becoming accustomed to, while compensating the artists and copyright holders who provide the content for these files. It seeks to create revenue for the recording industry in an age of free music.
The present method can also be applied to any type of file such as text or video. The Publishing and Motion Picture Industries are expected to face similar challenges as technology improves in the coming years, and this method is applicable to any peer-to-peer system.
SUMMARY OF THE INVENTION
The present invention combines the ability to download files for free, compensate content creators or copyright holders, supply statistics that may be sold to corporations, artists, and other interested parties and provide users the option of purchasing hardcopy versions of the files. All files in the system are approved by the artist, or copyright holder, and are as such guaranteed for quality. In its current embodiment as a music file-sharing system, it also allows the user to search for music based on parameters that are not uniquely associated with the file name, such as genre of music or record label, features unavailable on present peer-to-peer systems.
Method There are two payment models emerging in the file-sharing medium. One entails the end user to pay a set fee for every download performed, and the other a monthly subscription rate for unlimited downloads.
The present method differs in that it proposes a system of payments that rewards the artist on a per play basis while making it free to the general public. The model emulates broadcast models that have been in place for several decades.
Revenues are generated using a number of methods:
l.) Advertising Revenues Advertising would appear prominently on the user interface. Advertisements would appear as a banner ad on each page, as a feature promoting content in the promotions window, nested in the video player's video files, and, where approved, nested in data files.

2.) Resale Of Registration Lists T'he system would hold registration lists of all its users. With their permission these lists could be sold to interested parties for a fee. These lists would allow sponsors to target products to specific markets, for sponsors to research the relevance of a sponsorship and for content providers to promote their new product directly to users.

3.) Direct Mail Promotions and Advertising As the system would hold email addresses of its users, emails could be sent to these users promoting related materials. These emails could also display banner ads.

4.) Sales Of Hardcopy Versions Of The Files The system would be attached to an online store. Users could purchase hardcopy versions of the files, or similar files, by browsing the store. All files in the system would be cross-indexed to the store database.

5.) Premium Subscription Offers Subscriptions to the system will be offered for a pre-determined rate.
Subscriptions will include front of the line ticket offers. Merchandise specials and artist club incentives. Subscribers will have advanced preferences, hi-fidelity options, and enhanced feature options.

6.) Commissions Earned From Affiliates Program Copyright holders, content creators and other interested parties would be required to open a commercial account with the designated bank. The bank would act as a gateway between these parties and the system. A percentage of bank user fees would be collected for the system and funds would be distributed electronically through the designated bank. 'The system would share profits with banks on transaction charges and revenues can also be derived from affiliated retail outlets.

7.) Digital Rights Management The present invention provides an ideal setup for Digital Rights Management (DRM) services.
Royalty payments can be calculated through the system. Statistics can be generated based on region, age group, sex, etc. These services can be sold to artists or copyright holders, who can use these statistics to more effectively market hardcopy versions of their product. The tagging aspect can be traced to estimate activity on other systems.

8.) Licensing Of IP's in the system The present invention enables the product to be sampled and licensed by television, film production houses, and ad agencies. The system would collect a portion of the revenue generated from these licenses.
Apparatus The present invention provides nearly as much control over its files as a system which stores files on a centralized Server, while keeping these files distributed among its many clients. In fact, the Server would not hold any multimedia files. It would be used only to mediate the transfers between its clients and to update its database.

Present peer-to-peer systems do not track files that are being downloaded. In other systems, once a connection is made between two peers, the server removes itself from the transaction. While clients still download from each other as in present systems, the Server in this invention keeps a record of these downloads. It does this by associating system-specific keys to each file, and by forcing clients to update the Server once a download has been completed. If a file does not have one of these keys, it cannot be shared in this system. At present only systems that store files on a centralized Server can track files that are being downloaded and perform the functions that the present invention allows.
A user would access a centralized Server. The user would log in. Upon login, the user would enter a search parameter for the type of file he or she wishes to download. The Server would then send the client a list of files matching the search criteria, or if no file met the criteria, it would notify the client. If possible, the client would then choose a file. Once the file is chosen, the Server will send this client the necessary information so that it may connect with another client who has the desired file. When the transfer is completed between the two Clients, both Clients must notify the Server, who then logs a record of the transaction.
The data files would all be of an approved type. In the current embodiment, files use existing MP3 technology, but include keys that are specific to the present invention. All files are stored on client computers. This is similar to other existing peer-to-peer file-sharing systems. However, unlike other systems, all communication, except for the transfer, is done through the Server. By having the Server mediate the transfer, pertinent information regarding transfers is stored on the Server and its associated database. This ensures that only approved files are being used in the present invention, and allows the Server to generate statistics based on number of downloads, and can keep track of artist remuneration.
The Server database incorporates features that allow the user to search for files based on descriptors other than file name. By keeping a central repository of information relating to files in the system, the present invention allows a wider degree of freedom in searching for said files.
Present peer-to-peer systems do not store descriptive information relating to songs in the system, and therefore cannot incorporate these features.
For every song in the system, two types of files are stored: "low-quality" and "high-quality". The low-quality files are suited for those users who use portable MP3 players. The high-quality files are suited for those users playing these files on their home stereo and similar systems.
Remuneration is calculated once a file has completed its transfer, and has contacted the server. Record labels or artists are paid by a predetermined rate per download.
DETAILED DESCRIPTION OF THE INVENTION
The present invention uses two internal data structures in its server to track the files currently available in the system and the users presently logged on the system. FILES is a data structure which can locate all files which are currently located on user machines throughout the system. USER
is a data structure that stores the name and location of a client. The collection of all USERS
represents all clients logged onto the system.
FIG. 1 displays a definition of the USER data structure.
Type refers to whether this is a regular User, or a Subscriber to the system.
Socket refers to the Socket number the user is connected to.
The Firewall Flag is a Boolean variable, set to TRUE if the user is behind a firewall, FALSE if not.
Speed refers to the speed of the connection.
Filelist refers to the users associated data files.
IP Address refers to the address of the client.

If the client is using a proxy server, the Proxy IP address refers to the address of said proxy server FIG. 2 displays the FILES data structure. FILES is an array of pointers, with each array index representing a file key. For each array entry, there are two pointers, each to a circular linked list. Each of these linked lists contains users who have this particular song on their machines. One list represents those users with high quality files, the other, those users with low quality files.
For every search on a particular linked list, the index is incremented. The next search will include users not returned in the previous search.
The circular nature of the list helps assure that one user won't be accessed an inordinate number of times compared to other users.
FIG 3 displays a general overview of the present invention. In the diagram a central Server is connected to two or more clients. Clients 1 and 2 are connected to the Server through a network, typically the Internet.
The central Server is connected to a database. As in present peer-to-peer systems, all of the actual sound files are contained on user's machines. The Server is used to store information regarding the users and the legitimate files in the system at run time. The database contains information regarding users and files. The database's information is updated only periodically, whereas the information in the Server is constantly changing, depending on which clients have logged in and which clients have logged out. In this diagram, Clients 1 and 2 are also connected, and are sharing files. Client One and Client N are also connected, as clients can be connected to more than one computer at a given time.
FIG 4 displays a detailed view of the Server and its associated Database. In the computer's RAM, there exists the FILES data structure, and multiple USER data structure, as described above. These USER
structures represent all Clients connected to the system. These structures are very dynamic. They are constantly changing depending on which users have logged into the system, and which users have subsequently logged out of the system. The Server uses a fixed TCP/IP Port so clients may easily access the Server.
The database contains information that is much more static than that which appears in the Server. It contains information about artists, their files, the copyright holders of the files, user information which was entered when the user registered, and a counter which tracks the number of times a particular file was downloaded (for remuneration and statistical purposes).
The USER INFORMATION table contains information entered by the user when the user first registered with the system. It contains fields such as user name, password, first name, last name, email address, street address etc.
The FILES table contains information related to all of the data files in the system. It contains fields such as key, title, composer (or author, depending on the application), performer and description etc..
The FILE COUNT table contains information related to artists' remuneration. It contains fields for song identification, copyright holder identification, artist identification, and a download count, which is incremented each time a song transfer is completed.
The FILE SEARCH table permits a search based on parameters other than the file name. It the cross-lists the file key with fields, in its present embodiment as a music file-sharing system, such as genre, record label, and file size. If performing a regular search based only on the file name, the FILE table would be used.
The COPYRIGHT HOLDER table holds contact information for all copyright holders in the system.
The ARTIST INFORMATION holds artist information such as name, genre and artist description.

In the current embodiment of the invention, MPEG audio files are used.
However, any file format in which the needed identifying tags can be included is supported in the present invention FIG. 5 displays an MPEG Audio File with an ID3 tag appended to its end. . The ID3 tag is used for storing descriptive information about the file. In such a file of N bytes, the first N-128 bytes are used for audio information, and the final 128 bytes for the tag. The present invention uses the 30 bytes in the ID3 tag set aside for the "Comment". MPEG files rarely use this field. These 30 bytes are divided as follows:
1) The first byte is set to zero. MP3 players, when encountering this zero, will assume they have reached the end of the file. The information contained after the zero is of no use to MP3 players. It is only useful for the present invention.
2) The next four bytes are used to indicate the song key. Every song in the database is given a unique value in the database, and a unique copyright holder is assigned to each song key.
The four bytes of the song key will be the same whether the file is of a high-quality or low-quality type. Song keys are generated in chronological order; as they are entered in the system, they are given the next number in ascending order.
3) The next sixteen bytes are used for verification purposes. These bytes represent an MDS
encoding of the audio portion of the song, and the four bytes referring to the song key, as described in 2). The header, audio, and song key are encoded so that the Server may validate the authenticity of the file. If the file types are the same, the value of the MD5 encoding will be the same. These sixteen bytes will be different for the same song in two separate files if their sound qualities differ. This results because although the same keys are used for every instance of the same song, the audio portion will be different.
4) The last nine bytes are used for a "User License Key". This key is used for proof that the user has downloaded the file from the system, and not from another source. It is a key that is unique for every download, even if the song has been downloaded before. This is used to verify that the file has been legally downloaded from the system and gives the User a legal right to personally use the file.
FIG 6 displays a detailed view of the Client. Files are kept in permanent storage. The file keys and checksums are extracted from these files and stored in RAM. This information is passed to the Server when the Client connects to the system. The files are swapped in and out of RAM when another client requests these files. The Client is connected to another Client through a TCP/IP Port.
FIG. 7 displays a flowchart describing the Servers' actions once a Client logs on. After receiving login information from the Client, the Server must verify whether the user name and its associated password exist in the database. The Server would query the database's User Table. In this table, all Registered Users in the system have their Name and Password stored. If they don't exist in the database, or if the password is incorrect, the Server sends a message to the client informing it that the login process has failed. If the user name along with a correct password exist in the database, the Server sends an acknowledgment to the client. The Client is thus connected to the Server. The Server then performs a test to check whether the Client is behind a firewall by trying to connect itself to this Client. If this client is behind a firewall, the operation will time out. If the Client is not behind a firewall, a connection will be made. The Server stores this information in the Client's assigned USER data structure for future use, as a firewall may affect the transfer between two peers. The Server closes the connection it initiated, as it is not needed anymore.
The Client will then send a list of the data files existing on its machine. A
unique key identifies each of these files. The Server then updates its FILES data structure.
In order for a Client to obtain a file, another Client who possesses this file must also be logged on. The information in the database only describes which files have been approved. If files are found in the database, it does not necessarily mean that the client can download these files at any given time.

If a Client is behind a firewall, but has a Proxy Server installed, the present invention treats said Client as if it were not behind a firewall. If two Clients are behind firewalls, and neither has a Proxy Server, said Clients cannot share files with one another.
FIG. 8 displays a sequence diagram detailing the interaction between Client, Server, and the Database. The Client sends its search parameters to the Server. The Server then sends a query to the Database, based on the parameters supplied by the Client. . The parameters can be based on various descriptors of the file, depending on the application. The Database contains records of all files that could conceivably be in the System. The Database then returns results based on the parameters. The Server then checks its FILES data structure for each file returned from the Database. If a file is in FILES, it is included in the list sent to the Client. However, in the case that a Client is behind a firewall, those files on other peer's machines that are also behind a firewall are not included in the list. Once every file is checked, the Server sends the list of matching files to the Client.
FIG. 9 displays a flowchart describing the Servers' actions once a Client sends a file search request. Upon receiving the request, the Server sends a query to the database to search for files based on the parameters specified in the file request. If the search parameters encompass information not related to the name of the file, the Server would query the Database's FILE SEARCH table. If the search relates uniquely to the file name, only the FILE table is queried. If a file matching these parameters is not found in the database, the Server sends a message to the Client indicating that no results were found.
The database can return more than one file name based on the search parameters. For each file the database returns, the Server searches its FILES data structure to verify whether or not another user who is logged on possesses a file matching this description. If the Client is behind a firewall, the Server will only return files included on another peer's machine if this peer is not behind a firewall. If two peers are both behind firewalls, the transfer cannot be made. If the Server does not find any files matching the proper description, it sends a message to the Client that no results were found. If it does find files matching the description, it sends a list of these files to the Client. The Server then waits for the Client to choose its desired file. The Client will then send a request to the Server for a specific file as described below in FIG.
7a and FIG. 7b.
FIG. 10a and FIG. lOb display a flowchart describing the actions taken by the Server when a Client requests a file from another Client. After searching for a file, Client 1 sends a request to the Server for a file on Client 2's machine. As alluded to earlier, Client 2's machine only contains files authorized for distribution by their respective copyright holders. The Server then determines whether Client 2 is behind a firewall or not. The case where both Clients are behind a firewall will never present itself at this stage, as the Server won't allow two Clients behind separate firewalls to request files from one another. If Client 2 is not behind a firewall, the Server sends Client 2 the IP address of Client 1, and the requested file name.
Client 2 then generates a random port number. Client 2 then sends this number to the Server, who in turn sends it to Client I. Client 1 has enough information to connect to Client 2, and thus initiates a connection.
If Client 2 is behind a firewall, Client 1 cannot connect to it. Therefore, Client 2 must initiate the connection. The Server sends a message to Client 1 instructing it to expect a connection from Client 2.
Client 1 then generates a random port number, and sends the number of this port to the Server. The Server then instructs Client 2 to send the requested file to Client 1, on the requested port number.
After connecting with each other, the Clients then transfer the file. The Server waits for notification from both Clients that the transfer has been completed. This step assures that the transfer was a legal one, and the Server updates its database by logging another download for the file in the File Count table. This count is used for copyright holders to verify the number of times a particular song has been downloaded. The Server then generates a new User License Key for this file, and sends it to Client 1 (the downloader).

If neither Client sends a notification, or if only one of the clients sends a notification, the Server does not log the transaction in its database. This is done for security purposes. It prevents hackers from illegally logging downloads on the Server without performing system-approved downloads.
Periodically, the copyright holder can query the database to determine the royalty payable for the songs downloaded. When the copyright holder queries the database, he/she receives a number representing the total number of downloads, multiplied by the rate paid for each download, giving total payment due. This data is then forwarded to an accounts server for storage or to the servers of a financial institution for payment of the calculated royalty. The data would be secured according to the financial institutions requirements. The onus is on the receiver of this data to distribute the funds correctly.
Although two people may, for example, have written a tune, in this system (as presently implemented), only one person, or corporation, receives the royalty payment. The system could be easily changed to pay both songwriters without fundamentally altering the nature of the system.
FIG. 11 displays a sequence describing the interaction between two Clients and the Server after Client 1, the downloader, has chosen a file. Client 1 sends a message to the Server describing which file it wishes to download, and from which user. The Server then checks whether Client 2, the uploader, is behind a firewall or not. In this scenario, Client 2 is not behind a firewall, so the Server sends a message to Client 2 instructing it to expect a message from Client 1. The Server supplies Client 2 with Client 1's IP address and the name of the file it wishes to download. Client 2 then generates the random port number to be used by Client 1. It sends this information to the Server who passes it on to Client 1 along with Client 2's IP
address. Client 1 then connects directly to Client 2. It sends a message stating which file it wants, and at what index. Clientl may have already downloaded part of the file, so it can download the file starting at any index in the file. Client 2 verifies that the Client 1's IP address matches the one supplied by the Server.
If it does, the connection is made, and the file is transferred. Once completed, both Clients send a confirmation to the Server that the file has finished being transferred. The Server then increments the counter in the File Count table. The Server then sends the Downloader the User License Key, which is described in FIG. S.
FIG 12 displays a sequence describing the interaction between two Clients and the Server after Client l, the downloader, has chosen a file. In this scenario, however, Client 2 is behind a firewall. Client 1 sends a message to the Server describing which file it would like, and from which user. The Server then checks whether Client 2, the uploader, is behind a flrewall or not. Client 2 is behind a firewall, so Client 1 cannot connect to it. The Server sends a message to Client 1 instructing it expect a message from Client 2. The Server supplies Client 2 with Client 1's IP address and the name of the file it wishes to download. Client 2 then sends, to the Server, the port number (generated randomly) to be used by the downloader. The Server passes this information to Client 1. Client 1 then connects directly to Client 2. It sends a message stating which file it wants, and at what index. Client 1 verifies that the Client 2's IP address matches the one supplied by the Server. If it does, the connection is made, and the file is transferred. Once completed, both Clients send a confn-mation to the server that the file has finished being transferred. The Server then sends the Downloader the User License Key, which is described in FIG. 5.
FIG. 13a and 13b display a flowchart from a downloading Client's point of view. After the application is loaded, the Downloader sends a list of its files to the Server. The user then enters a file search request.
The Downloader sends this search request to the Server. If no files match the search parameters, the Downloader receives a message from the Server. If there are files in the system that match the search parameters, the Downloader receives a list of files. The Downloader then sends to the Server the name of the file that it desires. The Downloader then receives a list of users who have this file on their machines.
The Downloader then chooses another Client (the Uploader) from which it wishes to download the file, based on information such as connection speed and bit rate. The Downloader sends this information to the Server.

If the Downloader is behind a firewall, no Client in the list of users that was sent to the Downloader will be behind a firewall. If he is not behind a firewall the other users may or may not be behind a firewall. This way, two Clients situated behind firewalls will never try to connect to one another.
If the Uploader is not behind a firewall, the Downloader can connect to it.
Therefore, the server sends the Downloader the IP address of the uploader and the port number of the Uploader.
If the Uploader is behind a firewall, the Uploader must initiate the transfer.
Therefore, the Downloader receives the IP address of the Uploader so that when the Uploader tries to connect, the Downloader can verify that this in fact is the proper Uploader, and not a hacker. The Downloader then generates a port number for the Uploader to connect to, and sends this number to the server.
The Downloader receives a connection request, and the IP address of the Uploader is verified. If it doesn't match the IP sent by the Server, the connection is refused.
A file may exist in a partial form on the Downloader's machine, as a previous download may have been terminated prematurely. At this stage, the Downloader verifies at which point in the file it needs to start downloading from. The Downloader may verify the correct restart point for the download from the byte count of the portion of the file actually downloaded, from the packet download count of the portion of the file actually downloaded or via other means known to those skilled in the art.
The connection is then made between the two Clients, and the Downloader tells the Uploader at which point in the file it wishes to start downloading. The Downloader then begins receiving the file. Once the end of the file is reached, the Downloader calculates the checksum to verify that this is indeed a system file. If it isn't correct, the file is discarded. If it is correct, the Server is notified that the file has finished being transferred.
If the Downloader accepts the File, the Server then sends the Client its User License Key for this file. At this stage, this file contains the User License Key that the Uploader had in its file. So the Downloader replaces the old Key with the new unique Key sent from the Server.

February 26, 2001

9

Claims

WE CLAIM:

1. A method of downloading an audio file over a network, comprising the steps of:
maintaining a database of audio files approved for download, and a respective network location for each of the audio files;
receiving from a client a request over the network for one of the audio files;
and providing the client with an indication of the network location associated with the requested audio file.