CA2323427A1 - Method and system for registering and licensing works over a network - Google Patents

Abstract

The system and method of the invention generally provides for registering works of authorship in an online database (100) and providing licensing information about authorship with several rights agencies, royalty collecting societies and copyright offices, and the online database (100) in a single process. The invention allows individuals to identify a particular work of authorship form among many close variants; analyzing the license rights (143148) necessary for a particular use of the work by an individual in a particular territory, determining the source of the licensing rights (151) in that territory and forwarding a request for a license to that source (152). Finally, in a preferred embodiment, the invention may issue a license (154) to an individual for the use of a work contemplated.

Description

METHOD AND SYSTEM FOR REGISTERING AND
LICENSING WORKS OVER A NETWORK
RELATED APPLICATIONS
This application claims the benefit of priority of U.S. Provisional Application Serial No. 60/i15,606, filed January 12, 1999.
FIELD OF THE INVENTION
This invention relates generally to a method and system for registering works of authorship in an online database and providing licensing information about registered works to individuals who access the online database; and more particularly to a method and system for registering works of authorship with several rights agencies, royalty collecting societies and copyright offices, and simultaneously entering the work into the online database. The online database contains information about the licensing rights sources for various license rights in each territory of the world. Individuals can use the online database to identify a particular work of authorship from among many close variants, analyze the licensing rights necessary for a particular use of the work in a given territory, determine the source of the licensing right needed for their use and forward a request for a license to that source. In a preferred embodiment, the method and system can issue a license to the individual for the particular use of a work in the particular territory desired.
BACKGROUND OF THE INVENTION
With the growth and ready accessibility of the Internet, it has now become possible and easy to locate and copy works of authorship placed on the Internet. In fact, many individuals who locate and copy a work that they are interested in can also easily distribute that work to others. In general, copying and distributing works of authorship in this way may constitute a violation of the rights of authorship in the work, and in particular may be a copyright violation. Yet, if an individual wishes to lawfully copy and distribute the work, such person may not have an easy time locating the appropriate entities which may grant a license for the distribution. In fact, it may be extremely difficult for the individual to even determine what rights are needed with regard to any given work in a given territory.
For an individual who wishes to distribute many different works, such as on an Internet site or on a CD compilation, the task of obtaining and clearing all of the appropriate license rights may be daunting. It is therefore desired to have a method and system for allowing individuals to easily determine the license rights needed and locate the source of such license rights in a given territory for works of authorship. It is also desired to provide a means for generating and transmitting a request for a license to the appropriate licensing rights sources.
While the invention is directed to works of authorship in general, in order to illustrate the problems presented, and the solution of the invention herein, the following discussion focuses on musical works, and in particular, songs. Thus, in this example, to make a recording, use a musical work in a movie or a commercial, perform the work in public or distribute the lyrics on an Internet site, an individual needs to request the appropriate licenses from the song writer, the publisher or the royalty collection society that administers the rights needed in a given territory.
A major licensing agency, which may represent up to 17,000 publishers in the United States, could handle on average more than a thousand requests a day from individuals (or companies) requesting mechanical rights licenses to make mechanical reproductions of song recordings. Furthermore, with the growth of the Internet and online distribution of songs, that volume is expected to increase to 10,000 a day or more over the next few years. Unfortunately, individuals requesting mechanical rights may not know which agency represents a given publisher and may assume that it is a given major licensing agency even when it is not. In this case, that agency must expend resources dealing with requests for licenses of works it does not represent.
The Internet represents a new international distribution channel where as many as 100,000 sites are expected to use and distribute music. At the same time the use of music in other multimedia products and services is increasing. If obtaining the appropriate rights to use the music is not made significantly easier than it currently is, the volume of unlicensed distribution will likely increase, and the ability to protect the intellectual property rights of the authors will be in danger. Thus, it is desired to provide a WO 00!42555 PCT/US00/00835 system and method for easily determining which rights are necessary for a given use of a work, which agencies or companies administer and grant those rights and that can format a request for that license right to the appropriate licensing rights sources easily. Such a system would be accessible by publishers and rights sources for entering the appropriate information about a given work, and would be accessible by rights requestors who wished to license the works. Therefore, it is desired to provide an online, Internet based licensing system for accomplishing these goals.
SUMMARY OF THE INVENTION
Generally speaking, in accordance with the present invention, a method and system for assisting individuals, recording companies, publishers, multimedia producers, Internet distributors and others in obtaining the appropriate rights to license a work of authorship easily, using an online system and database, and more particularly, a single World Wide Web site, is provided. The Web site is accessible by works publishers who wish to register their works in the system of the invention, and works users who wish to identify and license a work.
More specifically, the method and system of the invention provides an online, multimedia license, registration and tracking system for storing, retrieving and tracking Licensing rights sources information, and for registering copyrights and the like for works of authorship in general; and for identifying and licensing multimedia works through the system. The system may be used by multimedia publishers and licensor's to register, store and track multimedia works, and by perspective licensee's (such is CD
manufactures, compilation producers and Internet download services) to retrieve information about licensing a multimedia work.
With reference to musical works, for example, the system may be used by music publishers as a one step clearinghouse to enter data about a published musical work and forward in the relevant information to various licensing databases, such as the International Common Works Database (CIS) and registration databases, such as the U.S.
Copyright Office at the Library of Congress. Information about the musical work will also be stored in the centralized database of the invention in a digital representation of the work may be archived in the digital sound archive of the invention. Advantageously, the system can send structured email messages containing information about the new work to other agencies, registration services or royalty rights collection societies. A
publisher may access to system to update all these databases from a single update screen.
A central component of the system of the invention is an Internet based works database which stores information about the work of authorship and includes information about which entities can grant particular licenses for any particular use of the work. The information will generally include a worldwide licensor for each of mechanical rights, synchronization rights, Internet download rights, performance rights and master recording rights, and then list territorial exceptions, such as mechanical rights in 3apan or the IIK. Initially, the information will be provided by the publisher of the work, but each licensing agency can update database records as well. The system allows for online registration of single songs, multiple songs which are part of a single product (such as a cassette, a CD or a movie), and batch file registration allowing a large number of works to be imported using a single file transfer. Typically, the system will provide links to additional information about the work provided by the registrant and an example of the work itself.
A person or company, such as a CD manufacturer, Internet service provider or multimedia producer, that wants to use or license a work can search the database over the Internet for the correct data record for that work of authorship, and that record will include information as to which licensing agency has the right to grant a license for the particular use. In use, a user searches for a work by selecting a field of search, such as the title of the work, the author of the work, the physical production of the work such as from a movie, or a book, and enters keywords in the search box. Results of the search are presented in a list, and when the user clicks on the desired title, information about that work is presented which will include which agencies license that work for any particular use in the given territory.
Once licensing source resources have been identified, a new screen is presented allowing the user to prepare a structure email message requesting the appropriate licenses. The user may then send a license request email to some or all of the rights sources identified for that work.
The invention includes several major components, each generally linked to a central database of works of authorship, called herein the "WorksDB."
Publishers and authors may enter new works in the WorksDB using a simplified works entry screen on their Internet browser. At the same time, the invention allows the registrant to register the work with the U.S. Copyright Office, with the International Common Works Database, and with other agencies and royalty collecting societies around the world.
The invention allows interested users to identify a particular work of authorship by using a simplified look up screen on their Internet browser. For example, in the music industry, many songs have similar titles, and some songs have multiple copyrighted arrangements. In accordance with the invention, the WorksDB
provides a searchable database of all copyrighted songs in the American or other repertoire so that the user can determine which work, which version and which arrangement he or she wishes to license.
The system of the invention can determine the rights required for a particular use of a particular work by analyzing responses from the requestor to questions presented on a simplified intended use screen shown to the requestor on their Internet browser. The WorksDB service includes an expert system which identifies the usage being proposed and determines which rights are required in a given territory. In the example of music, there are mechanical rights needed to make copies, performance rights needed to perform the work in public, synchronization rights to use the work in a movie or commercial, print rights to distribute the lyrics or the score, digital rights to distribute the work on the Internet, grand rights to stage a dramatic performance and master rights to reproduce an existing recording among others. For other works, different rights apply.
Outside the U.S., "moral rights" may also exist, permitting the author of a work to grant or withhold permission to use the work in any specific context. Sometimes several of the possible rights are required for a particular use. By comparing the user's information and responses to the intended use questions with a database of rules based on expert knowledge of world wide licensing laws and practices, the WorksDB service can identify which rights the user will require for the intended use.
The WorksDB also includes information about the identity of any particular licensing rights source. For example, different rights are administered by different publishers, agencies and collecting societies in different territories around the world, and individual works may have additional specific and unusual requirements. Based on the territory in which the work is to be produced and distributed, among other information stored in the WorksDB, the WorksDB service uses a data structure to determine which sources need to be contacted by the user to get all the rights that are required for the intended use.
The system of the invention can preferably forward the request for a license to the appropriate rights source. Thus, the WorksDB service offers the user the ability to send all the necessary rights requests immediately to the correct licensing rights sources at once. The system prompts the user for the necessary information, formats the request, determines the current address and preferred request format for each of the rights sources involved, and sends the request message to the correct agency. In most cases the message goes out by electronic mail with a copy to the user, but in other cases the request may go by fax or ordinary mail. The system of the invention preferably logs the requests each user has made, and, with the participation of the rights sources, may track whether the request is answered or the license is issued.
In a preferred embodiment of the invention, the system may issue a pro forma license, where appropriate. For agencies and publishers who request it, the WorksDB service will evaluate the rights application, assemble the appropriate clauses and conditions required in the license and determine what rate the user will be charged. This pro forma license is forwarded to the requestor, with a copy to the publisher.
To complete the license, the requestor may respond to the agency, publisher or other rights source directly with their acceptance, or may contact the rights source through the WorksDB
service in order to accept the terms of the pro forma license.
The WorksDB service is preferentially accessed over the Internet, and a preferred embodiment of the invention incorporates a central Web site providing links to the various functions, which is available free to all users around the world.
As an example, in the field of musical works licensing, the WorksDB service is implemented as an Internet-based Licensing Service described in the attached Appendix 1.
The method and system of the invention benefits the licensing rights sources in at least two ways. It is estimated that more than a third of the license requests now received by the largest agencies and publishers cannot be processed either because the information is not complete or correct, or because that agency or publisher is not the appropriate rights source for the work being requested. The WorksDB service eliminates the work associated with unprocessable requests by helping the user create a complete request in the first place, and by sending license requests to the correct licensing source in the second place.
The service also benefits the individuals and companies that wish to License a work of authorship. The user of the WorksDB service can create and send a license rights request within minutes, and participating rights sources which incorporate automated licensing systems may respond in as short a time as three minutes. Or, where the WorksDB service provides a pro forma license, such a license can be prepared nearly instantly. This is especially important for Internet distributors who can now add a new work to their online catalog in minutes. This makes it easier for Internet sites to comply with the copyright law, and lessens the likelihood of non-compliance, and provides licensing revenues to the appropriate rights sources.
Updating the information necessary to ensure the complete and up to date accuracy of the system, namely the information about a given work and the licensing rights sources associated with given territories for that work, will be done largely by the publishers who have the greatest incentive in having rights requests processed efficiently.
The Internet, and particularly the World Wide Web, makes it feasible for thousands of individual publishers and song writers to maintain their works information in a central directory, such as the WorksDB. The WorksDB service takes advantage of this new capability by building and maintaining a system, a protocol, and an administration staff that keeps the database current and accurate.
The system and the method of the invention includes a works database containing information about works, including a unique work identifier and licensing sources for individual license rights in individual territories. It also includes means for determining a unique work identifier for a work to be licensed by a user and the appropriate license rights necessary for a particular use of the work in a particular territory. The system and method then matches the unique work identifier and the appropriate license rights for the territory in the database to determine the appropriate licensing sources and generates and transmits a license request to the licensing sources.

Accordingly, it is an important object of this invention to provide an online works database accessible by authors or publishers for entering information about their works, including information about licensing rights sources in particular territories for those works, which works database is also accessible by users who wish to request license rights to a work.
Another object of the invention is to provide a means for determining the license rights necessary for a particular use of a work in a territory and generating and transmitting a license request to the appropriate licensing rights source; and preferably additionally provide means for generating a pro forma license for that use.
Yet another object of the invention is to provide means for registering a work with several international works databases or copyright offices at once by entering registration information about the work in the online works database.
Still other objects and advantages of the invention will in part be obvious and will in part be apparent from the following detailed specification.
The invention accordingly comprises the several steps and the relation of one or more of such steps with respect to each of the others, and the system embodying features of construction, combinations of elements and arrangement of parts which are adapted to effect such steps, all as exemplified in the following detailed disclosure.
BRIEF DESCRIPTION OF THE DRAWINGS
For a more complete understanding of the present invention and its associated advantages, reference is now made tv the following descriptions taken in conjunction with the accompanying drawings, in which:
Fig. 1 shows an interconnection block diagram depicting an overview of the WorksDB system, in accordance with an embodiment of the present invention;
Fig. 2 shows a simplified account entry screen for the WorksDB system, in accordance with an embodiment of the invention;
Fig. 3 shows a simplified work update or entry screen for the WorksDB
system, in accordance with an embodiment of the invention;
Fig. 4 shows a current rights sources screen for the WorksDB system, in accordance with an embodiment of the invention;

Fig. 5 shows a rights sources modification screen for the WorksDB system, in accordance with an embodiment of the invention;
Fig. 6 shows a search results table for the WorksDB system, in accordance with an embodiment of the invention;
Fig. 7 shows a simplified rights request information screen for the WorksDB
system, in accordance with an embodiment of the invention; and Fig. 8 shows a detailed right request information screen for the WorksDB
system, in accordance with an embodiment of the invention.
DESCRIPTION OF THE PREFERRED EMBODIMENT
An embodiment of the present invention and its advantages are best understood by referring to Figs. 1 - 8 of the drawings, like numerals being used for like and corresponding parts within the various drawings. While it is to be understood that the system and method of the invention applies to any works of authorship, for ease of explanation an embodiment of the invention pertaining specifically to the licensing of musical works or songs is described.
Referring first to Fig. 1, there is illustrated an interconnection block diagram depicting an overview of the WorksDB system in an embodiment of the invention.
The WorksDB system generally indicated at 100 includes several functional elements which may be accessed from a main page 105. As is typical with Internet pages, main page 105 may typically include a splash 110 or other graphic identifier, news 111 providing information about the status of WorksDB system 100, and optionally, advertisements 112 or other links.
Main page 105 includes links allowing a user to find a work of authorship, create a request to license a work of authorship and send it to a rights source, or register a new work.
When the user clicks the link to register a new work, the user is brought to a register page 115. As will be further described below with reference to Fig.
2, the user is prompted to provide an account ID 116 or, if unavailable, create a new account I17. A
new account ID is sent to the user by email, which serves to confirm and verify the email address of the user. Once an account ID is established, the user may register a new work 118 or update the information of an existing work 119. The WorksDB system 100 can forward information about the new work or the updated work to the WorksDB 120, other databases 121, a national copyright office 122 and a digital archive 123.
Digital archive 123 contains a digital representation of the work provided by the user upon registration of that work and may also function as a deposit for copyright purposes.
A user who is interested in finding out information about a particular work, or licensing use of the work, can use WorksDB system 100 by clicking the link to find the work. The user is then brought to a search page I25 where the user can enter whenever information about the work that the user knows, in order to search for the work.
Information about works of authorship in the WorksDB will generally include a unique identifier, identifier 126, the title of the work 127, any alternative titles 128, usage notes 129, authors 130, a show, movie or other place in which the work was featured 131, the publisher and catalog 132, and any international standard registry numbers 133 which may be appropriate.
As will be further described in detail below, a user searching for a particular work will typically enter some or only incomplete information in any given field, and will typically only provide a title 127, alternative title I28 or the show or movie in which the I5 work was featured 131. The WorksDB system 100 will return a work search result table, for example the work search result table of Fig. 6 displaying the results of a search for songs containing the word "Godfather" in its title. As shown in Fig. 6, additional information about the search result works is provided in the table to help the user find the exact song and version being looked for.
The work search result table also optionally includes links provided by the publisher or other entity that entered the work into the WorksDB system 100, to additional information, such as, in the example of musical works and songs, a sample of the work 134, information about the work from the publishers web site 135, a discography 136, the lyrics 137, and the score 138. As shown in Fig. 6, not all entries in the work search result table will include links to each of these sources of further information. In the case of different kinds of works, i.e., other than musical works, different links to additional information will be appropriate. For example, in the case of a photographic work or photograph, a link providing information as to the exposure and camera equipment used, or to a thumbnail graphical image of the photograph, may be provided.

While many search techniques are well-known in the art and may be used in the system of the invention, it has been found that the searching design described in Appendix 2 is well-suited to meet the objectives.
Once the user has identified the specific work of interest, the user may S request a license for the work by clicking on the appropriate link and going to the request page 140. If available, the user can provide their user ID 141, or request a new user ID
142. The new user ID is forwarded to the user by email in order to verify and confirm the email address of the user. Once a user ID is provided, the user it brought to a rights analysis page, as shown in Fig. 7 and described in further detail below.
The rights analysis page as shown in Fig. 7 will allow the user to select from a comprehensive list of rights appropriate to that work, the license rights to be requested 143 and provide other basic information about the use of the work. Depending on the rights requested, additional questions will be presented to the user seeking the information pertinent to the particular rights to be requested. For example in the case of musical works or songs, additional questions pertaining to recording rights 144, broadcast rights 145, electronic rights 146, performance rights 147, or print rights 148 will be presented to the user. Once all the questions pertinent to the license request are answered by the user, the user will typically be given the chance to review their answers 149 and make corrections.
WorksDB system 100 also includes a license request assembly function which first identifies the appropriate rights required for the use intended by the user 150, and then identifies the appropriate sources for those rights 151. WorksDB
system 100 can transmit the license request to the licensing rights source 152 and store a record of the request 153 for confirmation and archival purposes.
In a preferred embodiment of the invention, WorksDB system 100 can use information generated by the request assembly function to create a pro forma license 154, determine the rate for that license 155 by reference to information in the WorksDB, send the pro forma license to the user 156 and a copy of the license request to the licensing rights source, and record the transaction 157 in the WorksDB. In this way, WorksDB
system 100 can provide the appropriate licenses to users who wish to use a work in a simple and efficient manner, in a minimal amount of time. Even where a pro forma license is not created by WorksDB system I00, the license request can be sent to the licensing 11~

rights source and processed efficiently and without delay because WorksDB
system 100 provides all of the information required by the licensing rights source in the request.
While many techniques for accomplishing the above objectives will be apparent to those of ordinary skill in the art, one embodiment that is well-suited to provide this functionality is described with reference to Appendix 3.
Various functions of WorksDB system 100 will now be described in further detail. While it is to be understood that these functions can apply to any type of works of authorship, for ease of explanation, the embodiment described will make reference to musical works and songs. With reference to Fig. 2, the simplified works registration is described. Any publisher or other works source with an account ID may register a work.
The process requires the publisher to enter information about both the registering organization and the work. Once the work is registered in the WorksDB system, the publisher may choose to register the work with the U.S. Copyright Office as well as other agencies and rights collection societies at the same time. With reference to Fig. 3, the WorksDB system prompts the user to enter a common set of information required by the WorksDB and the CIS Common Works Database. If the user also wishes to register the work with the U.S. Copyright Office, or other registration agency, additional information elements may be required and presented on an additional screen.
The registrant is also prompted to provide information for handling requests for all the different rights which may be assigned in all territories.
Normally it will be sufficient for the registrant to indicate that the rights should be handled according to standard worldwide default practices of the music industry, but alternatively, it is possible for the registrant to specify different sources for all the different rights in all the known territories. For example, Fig. 4 shows the default rights sources table for the top 20 music markets. Any entry in this table can be modified for a particular work by the registrant by clicking the change button. In this case, the registrant will be taken to a rights source change page, as shown in Fig. 5.
Any publisher may create a new song record in the WorksDB or add licensing rights sources information to the record of an existing work for which he represents 100% of the owners of that work. In other cases where ownership of the song is shared, all changes by any owner are automatically reported by the system to all other owners of that song, and the approval of each may be required before the changes are made.
The registrant may elect to send the new song information to other agencies and rights collection societies as well. If this option is elected, the system selects the information appropriate to that agency or society and sends the data as an email message.
If appropriate, WorksDB system 100 can present a screen requesting additional information that may be requested by the other agency or rights collection society.
For example, in the case of the U.S. Copyright Office, the WorksDB system creates and transmits an electronic copyright application directly to the CORDS system.
The application is conveyed electronically to the U.S. Copyright Office and any subsequent correspondence occurs exclusively between that office and the registrant as more fully described in Appendix 4. In filing with the U.S. Copyright O~ce, the user may also deposit the work itself in electronic form in the digital archive of WorksDB
system 100.
The digital copy of the work may consist of a recording in MP3, MIDI or another standard format, or it may be a text file of the lyrics and score.
WorksDB system 100 digital archive includes a secure database of all song information as it is added or amended in order to provide participating publishers with a permanent audit trail of changes to the record. The digital archive includes digital sound recordings submitted to the U. S. Copyright Office, or otherwise provided by the publisher, and may grow to become a major repository of digital music on the Internet.
WorksDB system 100 preferably uses public and private key encryption to certify that the registrant is authentic, and that the record of the registration or update of the song information is stored with a date/time stamp and digital signature in a secure format.
Publishers may register multiple songs in batches through a predefined transfer of files. When the data is provided in a large batch, the format of that batch is typically as a spreadsheet, or any other data format that can be normally imported, such as txt, csv, or dbf. In the preferred format the first row should include the name of the data element in that column.
At the WorksDB system 100 registration site, the original registrant may retrieve a complete record of the information for a song as of that moment, as well as see a history of changes that may have occurred since the original registration. The original registrant may modify this information and elect to have the WorksDB system send those modifications to other databases, agencies or rights collection societies.
A person or entity seeking the rights to a musical work may access WorksDB system 100 over the Internet. The user must first identify the work specifically from a catalog of copyrighted works, derivative works and arrangements. Having identified the song from a list of similar titles or multiple arrangements, the system then uses the identifier 126 to access information and rights management instructions.
Ultimately identifier 126 is incorporated into any rights agreement or license generated by participating publishers, and in the future may be used to manage royalty collections and distribution.
The user rnay search individual catalogs within WorksDB system 100, or search all catalogs at the same time. The catalogs are created by WorksDB
system 100 to separate very different groups of, for example, music, such as by national repertoires, theatrical productions and music libraries. Within the selected catalog, the user can search the file by writer, title or alternate title, show or movie in which the work appeared, or identifier 126 which is the primary key for each work. Optionally, WorksDB may be searched by International Standard Recording Code (ISRC) or CAE number, part of the international CIS system for identifying authors and composers.
The user selects the field to search on, selects the catalog to be searched, enters the text to search for and launches the search. In one embodiment, in the text window, multiple words separated by a space must all occur in that sequence for the song to be selected by the search engine. Multiple words separated by a connma may occur in any sequence or not at all. Thus a search on "Moonlight and Roses" would find only songs where those word appear in the field in that sequence. However, a search on "moonlight, roses" , on the other hand, would find all songs in which either word appeared anywhere in the title.
Once the search is complete, the results are displayed, for example, in groups of 40 songs. Each song is represented by title and alternative title, writers, and the show or movie in which it appeared. When the user selects a song, links to additional information, which may be provided by the registrant, are presented. The additional information may include a 30-second audio sample of the work, lyrics, the score, information from the publisher or a list of recordings (discography) made of this work.
Clicking on those links brings the additional information to the screen, or causes the audio sample to be played by the Internet browser.
Preferably, WorksDB system 100 includes help screens associated with all major transactions, leading the user step by step through the licensing process. WorksDB
system 100 also includes advertising from related companies, intended to reach the music professional, producer or multimedia director. Selection of the advertisement to be displayed may depend on the catalog being searched, the usage being proposed or another characteristic of the particular transaction.
The user may request rights for any work in WorksDB system lOC by clicking on the "License" icon in the results table. Through a series of diagnostic screens, to be described further below and with respect to the attached Appendix 1 and Appendix 3, WorksDB system 100 prompts the user to indicate what usage is proposed, which market is addressed, and the size of the commercial venture.
The User ID entered by the user at the beginning of the licensing process retrieves the organization information entered during the first visit, as well as the account ID number and ASCAP/BMI/SESAC information if appropriate. The selection of the rights requested category will determine the screen next presented to the user.
Information about the user includes organization and contact name entered the first time the user uses the system. The next time the user comes to WorksDB system 100, WorksDB system 100 will look for information in a record associated with the User ID. If that information is available, the user will not have to re-enter it. A
user who has no User ID is directed to a page where the ID can be set up quickly.
The user is prompted to indicate which country or territory the work will be manufactured or produced in, which territory it will be distributed from, and which territory it will be distributed to. The user is prompted to indicate which of five major usage categories apply: 1) Make a new recording (Album, Single, Chip, Music Box or other); 2) Use in broadcast, film or video (Television program, Radio program, Satellite or cable broadcast, Motion picture, Video release, Other multimedia product); 3) Distribute electronically, jukebox or background music (Permit download from Web or online site, Broadcast from Web or online site, Juke box, kiosk or other public interactive player, Restaurant, in-flight or other background music); 4) Perform in public (Theatrical production or rewe, School or community production, Opera, symphony or ballet, Nightclub, cabaret or other public performance); and 5) Distribute in printed form (Lyrics only, Lyrics melody and chords, Musical score).
S Typically, only one of these categories is selected for a single rights request, although within that category, the user may request several related rights.
Based on the response to this question, a second screen, specific to that usage category, gathers additional information required in order to generate the license rights request. The system employs an expert system to evaluate usage categories, commercial conditions, territories involved and applicable rules in order to determine which rights will be required in this case. Such an expert system can be in the form of a data structure, such as a table, or as a rules-based systerr~. The rights analysis system is maintained and updated from time to time to reflect changing laws and commercial practices around the world.
Once the required rights have been identified, WorksDB system 100 looks up the source for those rights in the WorksDB database. For most musical works, for example, the rights are administered by certain major rights organizations around the world. However, song writers and publishers may choose to have certain works or certain rights administered differently or in accordance with special instructions.
Some publishers, for example, prefer to have direct control over the use of any work in a commercial or a movie. In other cases, the song writers may choose to handle all rights requests themselves. WorksDB system 100 maintains a database of where the requesting user must apply for any of the rights to a work, in any territory of the world, and provides song writers and publishers with a simple mechanism for creating and maintaining individual instructions particular to any song or group of songs.
Once WorksDB system 100 has established the work, the user, the usage proposed, the rights required and the current source of those rights, it assembles a rights request message and presents it to the user for confirmation. If approved, the request is sent to each rights source immediately. Typically, all rights requests are sent by email, in a standard format. As requested by a given rights source, WorksDB system 100 will also use other formats. It may, for example, send the request by fax as well, and under certain circumstances by regular mail. Other formats may be developed to convey the rights request in other languages, and to construct alternative email formats to be read by automated licensing systems set up by the licensing rights source.
In a preferred embodiment, WorksDB system 100 can even prepare a pro forma license, and upon approval by the user, can transmit copy to the licensing rights source. In this case, the rights source will provide generic text clauses to be included for any given license request and the system will construct the appropriate license.
WorksDB system 100 keeps a record of all rights requests transmitted on behalf of the user, and enables the user to view that request history at any time. WorksDB
system 100 may track responses to the license requests and may also participate in the subsequent rights and permissions or licensing activity by constructing pro forma licenses.
The method and system of the invention thus described accomplishes the objectives stated above by providing an online, multimedia license, registration and tracking system for storing, retrieving and tracking licensing rights sources information, and for registering copyrights and the like for works of authorship in general; and for licensing multimedia works through the system. As a further example of an embodiment of the WorksDB system thus described, pertaining to the field of musical works licensing, the WorksDB service is implemented as the Internet-based Licensing Service of the attached Appendix 1.
This specification makes reference to several Appendices throughout. It is intended that each such reference to an Appendix be interpreted as incorporating the contents of such Appendix in this specification as if such Appendix were fully set forth herein where iadicated.
It will thus be seen that the objects set forth above, among those made apparent from the preceding description, are efficiently attained and, since certain changes may be made in carrying out the above method and in the system set forth without departing from the spirit and scope of the invention, it is intended that all matter contained in the above description and shown in the accompanying drawings shall be interpreted as illustrative and not in the limiting sense.
It is also to be understood that the following claims are intended to cover all of the generic and specific features of the invention herein described and all statements of thz scope of the invention which, as a matter of language, might be said to fall therebetween.

Internet-Based Licensing System and Service Specification Overview To make a recording, use a musical work in a commercial, perform the work in public or distribute the lyrics in print, the user needs a license from the song writer, his publisher or the collection society that administers rights in that country. A
major licensing agency, which may represent over 17,000 publishers in the US alone, would typically have to handle more than a thousand licensing requests a day, and that volume is expected to increase to 10,000 a day over the next few years. The Internet represents a new international distribution channel where as many as 100,000 sites are expected to use and distribute music. At the same time the use of music in multimedia products and services is increasing, and the major licensing agencies will need to simplify and speed up their licensing process. If getting rights to use the music is not made significantly easier, the volume of unlicensed distribution will increase, and the ability to protect this intellectual property will be in danger.
The Internet-based Licensing System ("IBLS") and service is designed and developed by a major licensing agency to assist recording companies, multimedia producers, Internet distributors and others in getting the music rights quickly at a single Web site. The IBLS service has six major components:
~ 1. Register new songs in the IBLS: The service permits participating publishers to enter a new musical work into the IBLS database from a simplified registration screen. At the same time, the user may register the work with the US
Copyright Office, with the international Common Works Database, and with other agencies and collecting societies around the world.
~ 2. Identify the work: Many songs have similar titles, and some songs have multiple copyrighted arrangements. IBLS provides a searchable database of all copyrighted songs in the American and world-wide repertoire so the professional user can determine which work, which version and which arrangement he or she wishes to license.
~ 3. Analyze the rights required: The IBLS service includes an expert system that identifies the usage being proposed and determines which rights are required. In music there are mechanical rights needed to make copies, performance rights needed to perform the work in public, synchronization rights to use the work in a movie or commercial, print rights to distribute the lyrics or the score, digital rights to distribute the work on the Internet, grand rights to stage a dramatic performance and master rights to reproduce an existing recording. Outside the US, "moral rights" exist, permitting the song writer to grant or withhold permission to use the work in a specific context. Sometimes several of these rights are required for a particular use. By comparing the user's information to a proprietary database of rules based on expert knowledge of world-wide music licensing laws and practices, the IBLS service identifies which rights the user will require.
4. Identify the rights source: Different rights are administered by different publishers, agencies and collecting societies in different countries around the world, and individual songs may have additional specific and unusual requirements. Based on the territory in which the work is produced and distributed, the IBLS service uses a proprietary database to determine which sources need to be contacted by the user to get all the rights that are required.
5. Forward the request: The IBLS service offers the user the ability to send all the necessary rights requests immediately to the correct agencies. It prompts the user for the necessary information, formats the request, determines the current address and preferred request format for each of the rights sources involved, and sends the request message. In most cases the message goes out by electronic mail with a copy to the user, but in other cases the request may go by fax or mail. The system logs the requests each user has made in the last 30 days, but typically does not keep track of whether the request is answered or the license is issued.
6. Issue a Proforma License: For agencies and publishers who request it, the IBLS service will evaluate the rights application, assemble the appropriate clauses and conditions required in the license and determine what rate the user will be charged. This proforma license is forwarded to the requestor, with a copy to the publisher.
To complete the license, the requestor must respond to the Agency or Publisher accepting the terms.
The IBLS service operates as a World Wide Web site on the Internet, available free to all users around the world. The system benefits the major licensing agencies which sponsor it in at least two ways. More than a third of the license requests now received by major licensing agencies cannot be processed (a) because the information is not complete or correct or (b) because that licensing agency is not the appropriate rights source for the work being requested. The IBLS service eliminates the work associated with these unprocessable requests by helping the user create a complete request in the first place, and by sending requests to the correct licensing source.
The service also benefits the user. Because of the engineering of the system itself and the availability of proprietary databases and analytical systems, the user should be able to create and send a rights request within a minute, and automated licensing systems may respond in as short a time as three minutes. This especially important for Internet distributors who can now add a new work to their online catalog in minutes.
This makes it easier for Internet sites to comply with the copyright law, and lessens the likelihood of non-compliance.
Updating the information necessary to make the system work will be done largely by the publishers who have the greatest incentive in having rights requests processed efficiently. The Internet, and particularly the World Wide Web, makes it feasible for thousands of individual publishers and song writers to maintain their information in a central directory. The IBLS service takes advantage of this new capability by building and maintaining a system, a protocol, and an administration staff that keeps the database current and accurate.
I. Simplified Works Registration Any publisher with a IBLS account may register a work. The process requires the publisher to enter information about both the registering organization and the work. Once the work is registered in the IBLS, the publisher may choose to register the work with the US Copyright Office as well as other agencies and rights collection societies at the same time. All data entered into the IBLS Registry is maintained permanently in a secure format, offering the publisher a digital archive of his works.
A. Information about the work The screen prompts the user to enter a common set of information required by IBLS
and the CIS Common Works Database. If the user also wishes to register the work with the US Copyright Office, additional information elements are required.

B. Rights management information The registrant is prompted to provide information for handling requests for all different rights in all territories. Normally it will be sufficient for the registrant to indicate that the rights should be handled according to standard worldwide practices, but alternatively it is possible for the registrant to specify different sources for all the different rights in all the known territories.
Any publisher may create a new song or add rights management information to the record of an existing work for which he represents 100% of the owners. In other cases where ownership of the song is shared, all changes by any owner are automatically reported by the system to all other owners of that song, and their approval is required before the changes are made.
C. Information for rights management organizations The registrant may elect to send the new song information to other agencies and rights collection societies as well. If this option is elected, the system selects the information appropriate to that agency or society and sends the data as an email message.
D. US Copyright Office The IBLS creates and transmits an electronic application for US copyright in the CORDS system format. The application is conveyed electronically to the US
Copyright Office and subsequent correspondence occurs exclusively between those parties.
E. Upload the object In filing with the US Copyright Office, the user may also deposit the work itself in electronic form. The work may consist of a recording in MP3, MIDI or another standard format, or it may be a text file of the lyrics and score.
F. Digital archive The IBLS service includes a secure database of all song information added or amended in order to provide participating publishers with a permanent trail of changes.
The digital archive includes digital sound recordings submitted to the US
Copyright Office, or otherwise provided by the publisher, and may grow to become a major repository of digital music.

G. Batch registration Publishers may register multiple songs in batches through a prearranged transfer of files. This method is intended primarily for initially loading the database.
H. Updating an existing record At the IBLS registration site the original registrant may retrieve a complete record of the information for a song as of that moment, as well as see a history of changes that may have occurred since the original registration. The original registrant may modify this information and elect to have the IBLS service send those modifications to other databases, agencies or rights collection societies.
I. Owners and Shares The account responsible for maintaining the song record can also view and modify the list of other owners and their shares, although that task may also be performed by the IBLS database manager. If an owner other than the maintaining account wants the information changed, he may contact the IBLS database manager and request the change.
II. IBLS Search A person seeking the rights to a musical work must first identify the work specifically from a library of copyrighted works, derivative works and arrangements.
Having identified the song from a list of similar titles or multiple arrangements, the system then uses the Multimedia Identifier (MMI) to access information and rights management instructions. Ultimately the MMI is incorporated into the rights agreement or license, and in the future will be used to manage royalty collections and distribution.
A. Search The user may search individual libraries within the IBLS service. The libraries are created by IBLS to separate very different groups of music such as national repertoires, theatrical productions and music libraries. Within the selected library, the user can search the file by writer, title or alternate title, show or movie in which the work appeared, or MMI which is the primary key for each work. In the future, additional keys may be added, such as the capability to search by International Standard Recording Code (ISRC) or CAE
number, part of the international CIS system for identifying authors and composers. .
The user selects the field to search on, selects the catalog to be searched, enters the text to search for and launches the search. In the text window, multiple words separated by a space must all occur in that sequence for the song to be selected by the search engine.
Multiple words separated by a comma may occur in any sequence or not at all.
Thus a search on "Moonlight and Roses" would find only songs where those word appear in the field in that sequence. A search on "moonlight, roses", on the other hand, would find all songs in which either word appeared anywhere in the title.
B. Results Once the search is complete, the results are displayed in groups of 40 songs.
Each song is represented by title and alternative title, usage notes, writers, and the show or movie in which it appeared.
When the user selects a song, links to additional information come from a second database. The additional information may include a 30-second audio sample of the work, lyrics, the score, information from the publisher or a list of recordings made of this work.
Clicking on those links brings the additional information to the screen, or causes the audio sample to be played by the browser.
C . Help The IBLS service includes help screens associated with all major transactions, leading the user step by step through the licensing process.
D. Advertising The service also includes advertising from related companies, intended to reach the music professional, producer or multimedia director. Selection of the ad to be displayed may depend on the catalog being searched, the usage being proposed or another characteristic of the particular transaction.
III. Rights Request The user may request rights for any work in the IBLS by clicking on the "License"
icon in the results table. Through a series of diagnostic screens, the system prompts the user to indicate what usage is proposed, which market is addressed, and the size of the commercial venture.
A. User Information Use of the IBLS search system is free and anonymous, but to request a license for a song, the user has to provide a minimal amount of information and receive a User ID. The service records the organization and contact information last entered by each User and fills in the first licensing request form automatically. A user who has no IBLS User ID is directed to a page where the ID can be set up quickly. The user may be an individual employed by the publisher, or he or she may be an independent contractor.
B. Territory The user is prompted to indicate which country or territory the work will be distributed from, and which territory it will be distributed to.
C. Rights Analysis The user is prompted to indicate which of five major usage categories apply:
Make a new recording (Album, Single, Chip, Music Box or other) Use in broadcast, film or video (Television program, Radio program, Satellite or cable broadcast, Motion picture, Video release or Other multimedia product) Distribute electronically, jukebox or background music (Permit download from Web or online site, Broadcast from Web or online site, Juke box, kiosk or other public interactive player, Distribute in Restaurant, in-flight or as other background music) Perform in public (Theatrical production or revue, School or community production, Opera, symphony or ballet, Nightclub, cabaret or other public performance) Distribute in printed form (Lyrics only, Lyrics melody and chords, Musical score) More than one of these categories can be selected for a rights request. Based on the response to this question, a second screen gathers additional information required in order to grant rights. The system may also present a third screen in some circumstances prompting for missing or resolving conflicting information. The system employs a unique and proprietary expert system to evaluate usage categories, commercial conditions, territories involved and applicable rules in order to determine which rights will be required in this case. The rights analysis system is maintained by experts at the major licensing agencies, and is updated from time to time to reflect changing laws and commercial practices around the world.
Once the required rights have been identified, the IBLS service looks up the source for those rights in a proprietary database maintained by the major licensing agencies and by the publishers. For most musical works, the rights are administered by the major rights organizations around the world, but song writers and publishers may choose to have certain works or certain rights administered differently. Some publishers, for example, prefer to have direct control over the use of any work in a commercial or a movie. In other cases, the song writers may choose to handle all rights requests themselves. The IBLS
service maintains a proprietary database of where the user must apply for any of the rights to a work, in any territory of the world, and provides song writers and publishers with a simple mechanism for creating and maintaining instructions particular to any song or group of songs.
D . Request Analysis Once the system has established the work, the user, the usage proposed, the rights required and the current source of those rights, it assembles a rights request message and presents it to the user for confirmation. If approved, the request is sent to each rights source immediately. Initially all rights requests are sent by email, in a standard format proposed by the developer of the IBLS. As the system develops, it will also use other formats that may be useful to particular rights sources. It will send the request by fax as well, and under certain circumstances by regular mail. Other formats will be developed to convey the rights request in other languages, and to construct alternative email formats to be read automatically by licensing agency's automated licensing systems.
The IBLS service keeps a record of all rights requests transmitted on behalf of the user for the past 30 days, and enables the user to view that request history at any time. The IBLS service does not track response to these requests and does not participate in the subsequent rights and permissions or licensing activity.
Technical Specifications 1. Song Registration A. Account ID
In order to enter or modify a record in the IBLS database, the organization has to apply for and receive an Account ID. This process begins by the organization completing the New Account information and submitting it to the IBLS database manager. An account number is issued along with a passsword and this information is sent to the contact person by email. The IBLS database manager may use this opportunity to verify the information to make sure that it is consistent. Large publishers may choose to create an account for each major imprint or catalog. Accounts also include organizations and individuals who appear as Owners in the song record.

The elements of information required for a new account are:
Account ID: Assigned by the IBLS database manager.
Account Master Password: The password to be used for all supervisory actions, primarily adding and deleting the regular passwords.
Account Passkey: The account may have up to six regular passkeys so that access may be granted and withdrawn on an individual basis. The passwords can be changed only by the person gaining access with the master password.
Account Manager: The name of the person who is primarily responsible for the IBLS data and activities.
Account Name: Name of the organization.
Account Address: Street, City, State, ZIP and Country of the organization.
Email: The email address to which all IBLS correspondence is sent.
Passkeys: The Master Account can create or modify up to six passkeys which permit others to enter the IBLS directory and modify or add new songs to the database. Passkeys are seen only by the person who enters with the Master Account Password.
Account Email: The Account also has the option of creating seven separate email addresses to which license requests may be sent, one for each major type of license request. In setting up the individual song record, the publisher may direct that for any territory, the rights request for this song be sent to one of these addresses instead of to the normal national agency.
Mechanical address: Email address for mechanical rights.
Synch address: Email address for Synch rights.
Digital address: Email address for Digital rights.
Performance address: Email address for Performance rights.
Grand address: Email address for Grand rights.
Print address: Email address for Print rights.
Master address: Email address for Master rights.
Last update: The date on which the last changes were made to this record.
Last update ID: The passkey of the person who made the Iast update.

B. IBLS Data Elements The primary database is the IBLS database which contains information about the works themselves. There are several libraries, all of which have the same format. These include the American repertoire, the Italian repertoire, sheet music, music libraries and other collections.
The information about a song may exist in several related databases. The primary database is used for fast searching, and contains only those fields on which the user is permitted to search: MMI (the key field), Title, Alt Title, Writers, Arranger, Show/Movie, Publisher and Catalog. Once found, the MMI links the system to a secondary set of data which includes usage notes, links and other administrative information.
General guidelines: Use upper and lower case for title, alt title, writers, show and usage note. All uppercase information is harder to read.
MMI (Multimedia Identifier): A number assigned to the work by the IBLS
service.
The MMI number has the following format:
200.34.1234/[ISWC]789 200 = a general cross media indication that this is a musical work.
34 = the CIS country designation - in this case, US.
1234 = the registering publisher number assigned by the IBLS service.
[ISWC] = an indicator of the type of number which follows. This may be ISWC, HFA (Harry Fox Numbers), ISRC, or the catalog number of the participating publisher.
789=the object number, assigned by the registering publisher or by the IBLS service at the time the work is entered into the catalog.
Title: The title is presented in upper and lower case, in its most common form. Do not bracket the title in quotes. Do not include information about the movie or show in the title field, put it in the movie or show field.
Alt Title (optional: The alternate title by which the song may be known. The alt title field may include a translation of the title into another language if it is commonly known by that title. As: title might be "Que Sera Sera", alt title: "What Will Be Will Be".
Show or Movie (optional): The name of the movie, theatrical production, television show or other production in which the work most prominently appeared. This should not include the production credits, the producing studio or distributor; just the title. As:
"Singing in the Rain"

Writers: The original composers of the work. The IBLS convention is that writers names are given first name first, separated by a comma, in whatever sequence the registering publisher chooses. As: "Johnny Mercer, Oscar Hammertsein". Please do not use initials for the first name unless the writer preferred to be known that way (T. S. Eliot, for example). Please do not use & or "and" to combine writers names; use the comma.
There is no limit to the size of this field.
Arranger (optional): The name of the arranger or arrangers.
CAE# (optional): The publisher has the option of identifying the writer also by their CAE Numbers, which identifies the author in the context of an international authority file.
The IBLS may also add CAE numbers to songs in the future.
Usage Note (optional): Additional information that may be useful to the user in selecting the right version of the work when more than one is available. As:
"Instrumental version" or "French language" or etc.
Links: The IBLS service has a special provision which allows the registering publisher to link the IBLS record to elements of information stored elsewhere.
Six kinds of links are presently permitted. If a link is present, the system shows the user the appropriate link button on the screen. If not, no button is displayed. The links may be entered by the registering publisher, and may point to object on the IBLS server, on the publisher's own server or elsewhere on the Internet. The link can point to a literal URL
elsewhere on the Internet, or it can point to a DOI in the DOI directory, which in turn directs the user to the then current location of the file.
Link to Audio sample: An Internet link to the location of the 30-second audio file.
The audio file itself should be in MPG3 or some other non-proprietary format for which browser plug-ins are widely available. The link may be a DOI which points through the DOI directory to the then-current location.
Link to Additional Info: The IBLS has the capability of showing an "Info"
button if the record has any information in this field. The publisher should use the field to bring the user to more information about the work, about products or information related to the work, or about any other matter such as the show, the composer or a recent prominent use of the song.

Link to Discography: The publisher has the option of linking the user to a list of recordings made of this work, and in turn of linking the user to a Web site where these recordings can be purchased.
Link to Lyrics: The publisher has the option of linking the user to the lyrics of the work. Some publisher may choose to provide the lyrics in a PDF format which cannot be saved or printed. Other publishers may choose to distribute the lyrics freely, or to use this link to sell a lyrics file, or book of lyrics.
Link to Score: Similarly the registering publisher may offer the user access to the score itself, or to a directory of printed parts.
Library: The user has the option of searching on songs that belong to several large groups - American repertoire, Italian repertoire, music libraries, musical theater. In order to make this easy, the song record contains a field which in turn holds one or more "library" tags. A song that is both American and Italian might have both an A
and an I in this field. An Italian-American song that is often performed as a high school musical may have A,I,M. The user selects which "library" to search in, but in fact is choosing which set of works to search within.
Account ID: The Account ID of the account that is authorized to update this record.
Last Update: The date on which this song record was last modified.
Last Update ID: The password used by the person who last modified this record.
C. Licensing Information In addition to the descriptive information, the song record has several data fields used in the rights request process:
Harry Fox License: This field contains a code that indicates whether the song is licensed by Harry Fox.
Rights source information: Rights requests are sent to the national agencies and rights societies around the world, depending on the type of rights required and the territory from which the work will be distributed. But the publisher has the option for any song, in any territory, to have the request sent to himself - to the email address for that rights type which is maintained in the account information. Creating that special instruction is done on the song update screen by selecting the "Change" button for the territory the publisher wishes to change. On the change screen, the publisher may indicate for each type of rights, whether the request should be sent to one of the major agencies, or to the publishers' own email address. Those instructions are stored in the rights source information field.
The format for the information is:
MMI, TERR, TYPE, RIGHTS, SOURCE, COPY, where: MMI is the Song Identifier, TERR is the territory code (See Code Tables), TYPE is the code for the rights type (see Code Tables), RIGHTS is a word describing the rights, and SOURCE is the agency or society code for the rights source. If the Publisher has indicated that the license should be sent to his own email address, the SOURCE contains the Account/Owner ID. COPY contains the code to indicate whether a copy of the request should be sent to the Publisher.
Special Proforma Clauses: This field contains clauses that are to be used in any license involving this work.
The format of the information is:
TYPE, CLAUSE, TEXT, where TYPE is the license type, CLAUSE is the clause to be replaced, and TEXT
is the language of the new clause to be used.
D. Onli~ze registration Works can be entered into the IBLS database individually online or in batches sent to the IBLS database manager. In order to add a song to the database, the publisher must have a IBLS account. (See Account ID above.) In order to update a song, the user must have a password that is on the key list of the account (publisher) that originally created the record. When the user enters an acceptable password, the account ID is associated with that user for the duration of that session, and the user may update any song that is tagged with that Account ID.
E. Batch registration When the data is provided in a large batch, the format of that batch is as a Microsoft Excel spreadsheet, or any other data format that can be normally imported into Excel, such as txt, csv, or dbf. In this format the first row should include the name of the data element in that column. The columns should then contain the data elements in the following order, reading from left to right:

MMI, Title, Alt title, Show/Movie, Writers, Arrangers, CAE, Usage Note, Link to Audio Sample, Link to Additional information, Link to Discography, Link to Lyrics, Link to Score, Account ID, Publisher, Catalog, HFA
License, Rights Source Information.
A batch file should not contain more than 50,000 works. If necessary the publisher should create multiple sections files no greater than the 50,000 record limit.
The file should be stored on a 100Mbyte ZIP Cartridge and mailed to the IBLS database manager.
F. CIS Registration If the publisher chooses to send information to the CIS Common Works Database as well, the IBLS system will send an email message or file to the CWD containing the required information. The elements of information to b sent to the CWD have not been determined.
G. Copyright Office Registration If the publisher wishes to register the work with the Copyright Office he may do so from the IBLS site using CORDS, the electronic registration package developed by CNRI.
The publisher will download an applet that provides better data entry and data checking functionality, fill out the forms and submit the information to the Office.
H. Agency Data If the publisher wishes to send new song information to any of the major rights agencies (MCPS, GEMA, JASRAC) he can elect to have the new record emailed to those agencies. The format of this email will be defined later.
I. Digital Archive Any transmission of information to CIS, the Copyright Office or another agency is automatically added to the Digital Archive. The file is marked with the date, time and identity of the person making the change, and a digital signature is added to certify the file for later examination.
J. Third Party Registration The IBLS will also accommodate updates from third party copyright management systems like Right Track and Counterpoint. The method of updating from these products has not been determined.

K. Update Protocol All IBLS data can be modified by the IBLS database manager. Beyond that, only the original account that created the song record can update the record. Any change to a song that has more than one owner is reported to all the other owners of the song. If there is a disagreement over the change, it is reversed until the owners resolve the disagreement and notify IBLS that the change should take place.
L. History of Changes Every change to the IBLS database is stored, and the account responsible for the song may retrieve and review the history of changes at any time. The changes are presented in tabular form:
MMI, Password, Field changed, New Value, Date/Time of change.
II. Search System Multiple Libraries.
Searchable Fields.
Primary and Secondary Databases.
Media Players.
III. Guide to Music Licensing IV. License Request Initiating a license request in the IBLS system involves seven steps:
~ 1. Identify the licensee and song.
~ 2. Identify the usage.
~ 3. For each usage, gather information.
~ 4. Based on the information provided, select rights required.
~ 5. Based on the information, select the rights source.
~ 6. Create the rights request.
~ 7. Send the rights request.
A. Licensee and Work Information When the user begins the license process, the system gathers into the transaction record (a structure in memory) the following information elements from the Song record (by their associated codes):

MMI MMI

TTL Title WR Writers PUB Publisher Code CAT Catalog It also gathers from the Rights Form the following information, entered by the User:
UID UserID

LIO Licensee Organization LSTRLicensee Street LCI Licensee City LSTALicensee State LPC Licensee Postal Code LCO Licensee Country LCT Licensee Contact LEM Licensee Email HFA#HFA Account Number B. Uses Based on the information entered in the Rights form, the system indicates which uses the requestor has selected. The types of use are:
Audio 500+
Audio Under 500 Chip Music Box Toy Download Permitted Streaming Audio Play On Web Page InternetBroadcast Karaoke Game CDROM
Kiosk Jukebox RestaurantBackground Other Background Movie TV Program Radio Program Video TV Ad Radio Ad Internet Ad Lyrics Print Music Concert Nightclub Theater School Other Based on the uses planned for the song, the system asks additional questions.
The Questions are grouped into forms. The system looks at the Uses and Rights Table (below) and determines which forms need to be presented to the user. The information gathered by those forms includes:
OrigArtist T R x OrigAlbum T R x Origlabel T R x Whole Y/N R

ModificationY/N R

Play MinutesN If Portion Play SecondsN If Portion NewTitle T If New Recordingx NewArtist T If New Recordingx NewLabel T If New Recordingx ISRC T x Import? Y/N x Import CopiesN !f Import? x Record Date T x Record Mfg Code R x Record Dist Code R x Record WorldY/N x Record US Y/N x Record CanadaY/N x (etc.) First Printing T x Table: Uses and Rights ouuK race i Songs in BookT

Book Mfg Code Book Dist Code Book World Y/N

Book US Y/N

Book Canada Y/N

Book UK Y/N

Book Euro Y/N

Book Asia Y/N

Book USSR Y/N

Book ME Y/N

Book Africa Y/N

Perf ProducerT R

Perf Date T

Perf LocationCode R

Audience AdmissionY/N R

Church SchoolY/N

EstablishmentT R

Other Info T

The forms are assembled sequentially on the page being sent back to the user.
Once the user enters the information required by each question, the system gathers that data into the transaction record. Through this two-step process the system acquires all the necessary information about the use planned for this work.
The last thing the system does is to look at each element and determine if it is required for that usage. To do so the system looks at the third column (Req'd). If the cell contains an R, then the information is required in all cases. If the cell contains an if statement ("If portion") then the information is required only if the "Portion" element is present or non-negative. If required information has not been provided, the screen is returned to the user with an indication of which elements must be completed.

C. Rights Analysis Once the user has completed the answers to the questions in the Rights2 form and selected the "Continue" button, the system does two things: (a) it determines which rights the user will require and (b) which publishers or organizations must provide those rights.
To determine what rights will be required, the system looks at the rights requirements indicators in the Uses and Rights table. In the. actual case the transaction record only contains data rows for those uses that have been indicated. If the element is present or positive, the system concludes that the associated rights will be required.
For example, if the user says that he plans to make a record, and provides information specific to the record - such as Audio 500+ -- the system looks across the rights indicators and determines that mechanical rights will be required. As a result of this analysis, the system compiles a list of the rights that will be required for this application - e.g. Mechanical, Synch, DPD.
The second task is to determine which publishers or organizations must grant those rights, based on the type of rights required and the territory in which the record is manufactured, or where the program is produced, or where the performance will take place, or where the server will be located. For this version of the IBLS
system, we will assume that the country in all cases is the United States. The system then sets up a search:
MMI, Terr = US, Type = Mech, Type = Synch, Type = Perf, Type = DPD, Type = Print, Type = Grand, Type = Master.
There is only one Terr=field, but there may be as many as seven Type= fields for situations where the user will require many different licenses.
The system begins by searching the ownership database, which is structured as follows:

WO 00/42555 PC'T/US00/00835 MMI Song Identifier World y/N

U S YlN

Canada YlN

U K YlN

B ritTerr y/N

Specified Code MechRights SynchRights P= Publ fisher DigitalRights A =Agent PrintRights D=Desk, cc Publisher PerfRights PA = cc Agent GrandRights AP=cc Publisher MasterRights Share Share owned by this publisher Pub ID Publisher, one of several Catalog ID Catalog, as called by the publisher Agent Agent for this publisher, this song Email Email address for this particular song/pub Unused Unused Other Code Note Note to others who maintain data old pub code AS400 code old catalog AS400 code Account ID VVho can maintain the data Last modified Modified by UserID

(One way to make this search comprehensible (if not fast) is to make the search string contain Terr= and Type= in each field. The database will also contain Terr=US or Type=Mechanical. That way the fields can be in the wrong order and still be recognized.) The first step of the search is to find the first record in the Ownership database where the MMI in the search matches the MMI in the record. If no MMI is found, the system selects the HFA default record. The rights request well go to the HFA
trouble desk. This condition occurs if the user has found a song in the IBLS for which no ownership record has been created. This should not occur.
Once a match is found on the MMI, the system looks at the first territory field. If it says "Terr=world" then the system goes on to test the Type. An ownership record that has a Word territory type can issue a license for any territory, and no further search is required. If the first territory is not World, the system compares the first territory it finds to the territory being sought (in this case Terr=US). If there is no match, the system looks at the second territory in the ownership record, and if there is no match there it continues to took at each field in turn until there are no fields left and no matches found. This is an owner of that song who cannot issue rights in the territory being sought.

WO 00/42555 PC'T/US00/00835 If a match is found on territory, the system then tests that record for Type.
It looks at each field in turn to find a match on the Type. If no match is found the system searches for the next record with a match on the MMI. In this case the owner can issue some licenses for that song in that territory, but the not the type of license the user requires.
If a match is found on type, the system has determined that this owner may issue the license required, in the territory required for the song required. This owner will get an email request.
When the system has found a match on MMI, Territory and type it creates an email record containing the following elements of information:
Territory -the territory that was found in the record. If Terr=world, then territory is World.
Rights - the rights found in the record. If the record contained Type=mechanical, then the new email record contains mechanical.
Share - the percentage taken from the ownership record.
PubID - the identity of the publisher.
Catalog - the contents of the catalog field in the ownership record.
Agent - the name of the rights source to which the request will be sent.
Email - the address to which the request should be sent. In most cases the Email address will be the HFA address.
In the next version we will create the ability to look up the email address in another database depending on how the publisher wants to treat the song.
Once the email record has been created, the system looks at the next ownership record to see if there is a match on the MMI. This processis continued until all the ownership records have been examined. If no matches are found at all, the system uses the HFA trouble desk email record.
At the end of the process, the system has compiled one or more email records.
These are added to the transaction structure and reported to the user as part of the Request screen.
D. Rights Source Selection Once the rights and territories are determined, the system identifies the rights source or sources for each usage.

E. Request Assembly The system assembles the elements of a rights request in the following sequence:
~ 1. The Licensee.
~ 2. The Work.
~ 3. Use 1 (Rights Required, Rights Sources, Information) ~ 4. Use 2 (Rights Required, Rights Sources, Information) F. Request Review G. Request Transmission The result of the rights analysis and rights source selection is the construction of an email message that goes to the selected rights source, with a copy to the requestor. The message consists of the following elements:
To: includes the email address of each rights source, in alphabetical sequence.
Cc: includes the email address of the requesting organization.
From: IBLS system.
Subs: The subject line is constructed as follows: request number, catalog name, territory code, type code and MMI. This permits the organization receiving the request to route the message to folders or forward messages to other organizations based on catalog, territory and rights type.
Message: The message consists of one element per line. Elements are included only if they are relevant to the request, although the example here includes them all.
Each element consists of two parts: the element name which is the same all the time, and the element value which is the information provided by the requestor.
End of Message: A general phrase including the name and number of the IBLS
person to call if there is any difficulty receiving this message.
Below is an example of the email message. On the element line is the name of the element, followed by the format of the element value. YIN indicates that the information will be yes or no. T indicates that the information will be text. Code indicates that the information will be the name or code of a country.

Received: (from mail@localhost) by apache. test. net (8.8.5/8.8.5) id QAA21433;
Thu, 2 Jan 1999 16:23:00 -0500 (EST) Received: from esyl7.test.net(206.366.158.147) by apache. test. net via smap/slg (V2.0) id sma021389; Thu Jan 7 16:22:45 1999 Message-ID: <001101be3a84$lbOd40a0$02000003@IBLSdesk>
From: "IBLS" <admin@IBLS.com>
To: "IBLS Rights" <rights@ibls.com>
Cc: "Requestor" <name@isp.com>
Subject: 1234; Catalog;C=US;R=M;56789 Date: Thu, 2 Jan 1999 16:23:56 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative;
boundary="---- -NextPart-000-OOOC_O1BE3A5A.1FF3EDA0"
X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.0810.800 X-MimeOLE: Produced By Microsoft MimeOLE V5..00.0810.800 X-UIDL: 82de0f1f39715704403c38012025459 The following request for rights has been forwarded to you from the IBLS Service. Please respond directly to the requester.
Request Number: N
Date/Time: N
UserID: T
MMI: T
Work: T
Catalog: T
Writers: T
Organization: T
Street: T
City: T
State: T
Postal Code: T
Country: T
Contact: T
Email: T
HFA Account #: T
Audio500+: Y/N
AudioUnder 500: Y/N
Chip: Y/N
Music Box: Y/N
(etc.) FirstPrinting: T
BookPrice: T
SongsinBook: T
BookMfg: Code BookDist: Code BookWorld: Y/N
BookUS: Y/N
BookCanada: Y/N
BookUK: Y/N
BookEuro: Y/N
BookAsia: Y/N
BookUSSR: Y/N
BookME: Y/N
BookAfrica: Y/N
PerfProducer: T
PerfDate: T
PerfLocation: Code AudienceAdmission: Y/N
ChurchSchool: Y/N
Establishment: T
OtherInfo: T
This is the end of the information provided by the requestor. If you have any difficulty with the message, please contact the admin desk --end of message--WO 00/42555 PC1'/US00/00835 Search Specification Web Search Design Specification Search for prerecorded media (i.e. CDs and Tapes) and sheet music wo ooiaasss pc~r~rsooiooa~s Summary This doarment describes a system that will leverage the Internet, existing HFA
data, and partner dat~r to create a crmsumer-oriented business for the HFA. This system, which is part one of several phases, will allow tntemet users to visit an HFA site and shop for prerecorded music, sheet music and movies. This project phase provides a foundation for the industry-oriented music licensing site scheduled for release later in 1999.
The systems in use and proposed by the HFA are primarily database applications. The scope of work outlined here supports extending the delivery of the HFA's existing services over the Internet. This will require data collection from the HFA's existing AS1400 based systems.
This documenl indudes an analysis of the HFA's existing systems and a specification for proposed systems.
Analysis of the existing systems was based on documentation of these systems, Interview with HFA staff system users, managers, and domain experts and, work products, reports, and other artifacts used in processes these systems support. This analysis is presented in natural and structured English and a variety of diagrams.
The work is desaibed in sufficient detal to aNow for analysis by others and act as a road map for detaiied speafication development. Although the first release of this site will not be feature rich media the design presented here wiH allow for natural growth to more sophisticated interfaces.
The initial public launch of the site is scheduled for July 1, 1999. This design has been seated to fac~itate the initial site aeation within this aitical business requirement.

WO 00/42555 PCTlUS00100835 Provided functionality by page These song-search features of the HFA Wcb sift will appear on five types of pages:
~ The home page of the site will offer the Shortcut search field and a link to. ..
~ The Simple search page which will afford field specific searches and offer a link to...
~ The Advanced search page which will allow date-range constraints and boolean operations joining search terms ~ The Search results page will list the songs found and the CDs on which they've been rxorded ~ The Song detail page will show all the information available about a song, and offer links to associated information This section will detail the controls offered on each page and the navigational structure of this content.

Shortcut search form The Shortcut Search control set is a single input field with a "Search"
button, meant to take up very little space on the site's home page. The Shortcut search searches only the song titles, and is labelled to make this clear.
Simple search form The Simple Search page lets the user easily search in a specific field of the song data, and gives the user a simple way to constrain the search to only find recent releases.
Category list The category list is a set of checkboxes labelled with the song categories available. The user can check one or more to constrain the search to songs in only those categories.
Field list The field list is a select control that lets the user select the datum to be searched. It lists every field except "Date", and defaults to "[Ail fields]":
~ [All fields]
~ Title ~ Writer ~ Album title ~ Artist ~ Label ~ Publisher a ~ ~anufect~cr ~ Lyrics Search field The search field is an input field into which the user can type the string to be searched for.
Recent release The Roctnt release check box lets the user find only songs releasod is the last N months.
Search The Search burion initiates the search and shows the user the Search results page.

Advanced search form The Advanced Search form lets the user define a more specific subset of the available songs by using implicit Boolean operations. Separate input fields are entered for each datum in the song record. The user can enter multiple terms in one field to see the union of the sets of songs matching each term in that datum, and enter ternns in multiple fields to see the intersection of the sets of songs matching those terms in those data.
Fields ~ Title ~ Writer ~ Album title ~ Artist ~ Label ~ Publisher ~ TV show ~ Product ~ Manufacturer ~ Motion picture Length ~ Lyrics ~ Category ~ Date Search The Search button initiates the search and shows the user the Search results page.

WO 00/42555 PC'T/US00/00835 Song search results Ns!
The search results list lets the user identify among the songs that match the search crneria the one they wart hoping to End by showing for each matching song its category, writers, pusher, and all the recordings on which that song appears. It also lets the user buy sheet music ~'or that song or any of the its recordings.
Title The song's title wilt be linked to the Song detail page for that song.
Category Writers) The song's writers will be listed in a single field.
Publisher Buy sheet music A sheet-music icon will lx linked directly to a page at a sales partner's site that will let the user order the sheet music for the song.
Recordings Each recording of the song will be listed on a line of its own, with these columns:
Artist The name of the artist will be linked to a Search results page that shows all the songs performed by that artist.
Album name and CD icon The name of the album and an adjacent CD icon will be linked directly to a page at a sales partner's site that will let the user purchase the album on CD.
Date Buy sheet music A sheet-music icon will be linked directly to a page at a sales partner's site that will let the user order the sheet music for this arrangement of the song.
Hear recording If this recording is available for download and play over the Internet, an icon will link to the file.

Song detail page The Song Detail page lists all the information available about a given song:
Title Category Writers) The song's writers will be listed in a single field; each writer's name will be linked to a Search results page that lists all songs that writer wrote or collaborated on.
Publisher The song's publisher will be linked to a Search results page that lists all songs that publisher owns.
Buy sheet music A sheet-music icon will be linkai directly to a page at a sales partner's site that will let the user order the sheet music for the song.
Recordings A table will list all the albums on which the song appears, with these columns:
Artist The name of the artist will be linked to a Search results page that shows all the songs performed by that artist.
Aibun~ ~a~ne and CD icon The name of the album and an adjacent CD icon will be linked diroctly to a page at a sales partner's sift that will let the user purchase the album on CD.
Label Oate Buy sheet music A sheet-music icon will be linked directly to a page at a sales partaer's site that will let the user order the sheet music for this arrangement of the song.
Hsar recording If this recording is available for download aad play over the Internet, an icon will link to the file.
Movies A table will list all the movies in which the song appears, with these columns:
Name The name of the movie will be linked to~~'Search results page that shows all the songs that appeared in that movie.
5t Opening date Length Buy movie A movie icon will be linked directly fo a-page at a salt~.partner's site that will let the user purchase the movie on tape, videodyc, or DVD:
TV shows A table will list all the TV shows in v~ich the song appears, with these columns:
Name of show The name of the show will be linked to a Se~ch results page that shows all the songs that appeared in that show.
Producer Commercials A table will list all the commercials in which the song appears, with'-these columns:
Product The name of the product will be linked to a Search results page that shows all the songs that appeared in ads for that product.
Manufacturer The name of the manufacturer will be linked to a page that shows all the products from that manufacturer for whose ads songs were licensed; each product on that page will be linked to a Search results page that shows all the songs that appeared in ads for that product.
Length Navigation chart This navigation chart shows the connections from page to page by which the user can traverse the connected queries:
a -----~.
i, s,srdmea o yew r~e~.~
Aaanoea wrch emr vsim CO w,dor 1e. ~tso~uo~~
u: ~ u~e,i I
I
~~I one ~~ " ~ wbor e~
gar gar ~rm~ urm ver ~ u~~
~a,,..
Prm~

WO 00/42555 PC'f/US00/00835 Search application This application will be invoked from the Shortcut search, Simple search, Advanced search and Song search results list pages. It produces a "Song search results list" HTML
page based on user input.
Input Input can take several different formats. One or more input parameter may be entered. Multiple entries of the same kind of input parameter are also acceptable. Acceptable input parameters are any or all of the following.
~ Song title ~ Song writer ~ Album title ~ Performing artist ~ Prerecorded media label ~ Sang publisher ~ TV show using a song ~ Product commercial using a song ~ Manufacturer commercial using a song ~ Motion picture using a song ~ Song length ~ Song lyrics ~ Song music category ~ Prerecorded media release date ~ Recent release month count Alternately the input may be a key created by an earlier invocation of this application that allows for continuing a result set.
Output HTML page, known as the "Song search results list", listing one-line entries of songs with matching titles and one-line entries of recordings for each song limited to approximately 50 lines of output. Each song will provide a link to purchase sheet music. Additionally each song will provide a link to invoke the Generate song detail page application with the songs' SongID.
Each recording will provide links for generating a page describing the recording in more detail, purchasing the recording and purchasing sheet music as available. Recordings will also have links to playable media, (as available). These will be references that invoke the "Generate playable media reference application".
If the result set contains more songs and recordings than will fit on the page a "More Results"
link will be generated. The more results link will contain a reference for invoking this application with a key appropriate for generate additional pages.
The page will also contain standard navigation links, (i.e. Home, Refine Search, etc.).

Supporting data Shortcut and simple searches will use the Title, TitleSong, Song and Recording tables.
Advanced searches, based on search complexity, may require access to the same tables and additionally the Lyrics, PlayableMedia, TVShow, MotionPicture and Commercial tables. The database was organized to allow for efficient shortcut and simple searches.
Shortcut searches require the following data traversals. The Title table will be searched for partial and complete matches. Based on database platform facilities there is potential for providing near matches. The resulting Title records will be joined with the TitleSong table and those resulting records will be joined with the Song table. Each entry obtained from the Song table will be eligible for producing a line in the output. To generate the complete line a join will be made from the Song.PreferredTitleID field back to the Title.TitleID field to obtain the Title.Title field that matches this song.
Each resulting Song record will be joined with the Recording table to obtain the list of associated recordings. Each recording entry will be joined with the Title table to obtain the title of publication.
A simple search is similar to a Shortcut search but requires additional tests based on the Song.Category and Recording.ReleaseDate fields.
Advanced searches have the potential for taking significant database server resources. This application will analyze the search criteria and find the most efficient means of querying the database.
Side effects None.

WO 00142555 PCT/US00l00835 Generate song detail application This application will be invoked from the Song search results list page. It produces a "Song detail" HTML page based on a song reference.
Input Input will be a single song reference in the form of a SongID.
Output HTML page known as the "Song detail page". This page will contain all available information regarding a song. This information will include all the information contained in the Song, Recording, TVShow, MotionPicture and Commercial tables that relates to the specified SongID
and inferred RecordingID. As appropriate links will be created for purchasing products from partner web sites. Links will also be created as appropriate to invoke the Generate playable media application. Additionally many fields will contain links to invoke an advanced search with the data shown as the lookup key. These fields are listed below.
~ Song. Writers ~ Song.Publishers ~ Recording.Artist ~ Recording.Album ~ MotionPicture.MotionPicture ~ TVShow.TVShow ~ CommerciaLManufacturer ~ Commcrcial.Product The page will also contain standard navigation links, (i.e. Home, Refine Search, etc.).
Supporting data The Title, Song, Recording, TVShow, MotionPicture and Commercial tables.
The Song table will be searched for an exact Song)D match. The resulting song record will be joined with the Title table to obtain the songs proper title. The Song 1D will then be sought in the TVShow, MotionPicture and Commercial tables and the resulting records will be included in the output.
The SonglD will then be sought in the Recording table. Each resulting record will join Recording.TitleID with Titie.TitleID to obtain the proper recording title.
This information will be added to the output. Additionally the RecordingID will be sought in the TVShow, MotionPicture and Commercial tables and the resulting records will be added to the output.
Side effects None.

WO 00/42555 PCTlUS00/00835 Generate playable media reference application This application will be invoked from the Song search results list and Song detail pages. It produces page redirection to a playable media source.
Input Input will be a single recording reference in the form of a RecordingID and a single integer value corresponding to a bit in the Recording.PlayableMediaAvailable field.
Output HTML redirection page providing access to an Internet accessible piece of digital playable media.
Supporting data The Recording and PlayableMedia tables.
The playable media integer identifier passed in will be algorithmically mapped to a playable media format code. The Recording table will be searched for an exact RecardinglD match. The resulting recording record and playable media format code will be joined with the PlayableMedia table to obtain a PlayableMedia.Reference. The reference, which is a URL to the appropriate piece of media, will be wrapped into the HTML redirection page.
Side effects None.

WO 00/42555 PC'T/US00/00835 Available recording database update application This application will need to be invoked when CDUniverse makes a new data set available. The application will then update the Recording and PlayableMedia tables to reflect recordings available at HFA partner CDUniverse.
input Name and location of the CDUniverse data set. Name and location of a format code mapping file. Name and location to create a log file.
The exact format of the CDU data set has yet to be determined however it has been determined that the following fields are required.
~ Song name ~ Indicator of availability of prerecorded media ~ References to Internet accessible playable media and indication of the media format LCC of album Output A log file indicating successful and unsuccessful updates to the web supporting database.
Supporting data The Title, Recording and PlayableMedia tables.
Each record of the CDU data set will be processed in turn. Per CDU record the Title table will be searched for the provided song name. The Recording table will also be searched for an LCC
code matching the LCC provided by the CDU data set record. The resulting records will attempt to be joined.
A successful join will indicate the correct record in the Recording table to update with the CDU
provided availability information. Additionally the RecordinglD of the selected recorded will be used to search for and update the PlayableMedia table with the reference information provided by CDU. The format code mapping file will be used to convert the CDU supplied format codes to codes which are used by the PlayableMedia,Format field. The successful update will be logged as "Successful Update".
An unsuccessful join will be log as an "Unmatched Failure".
Side effects Modification of Recording and PlayableMedia tables.

Available sheet music database update application This application will need to be invoked when JW Pepper makes a new data set available. The application will then update the Recording table to reflect recordings available at HFA partner JW Pepper.
Input Name and location of the JW Pepper data set. Name and location to create a log file.
The exact format of the JWP data set has yet to be determined however it has been determined that the following fields are required.
~ Song name ~ Indicator of availability of sheet music ~ LCC of album Output A log file indicating successful and unsuccessful updates to the web supporting database.
Supporting data The Title and Recording tables.
Each record of the JWP data set will be processed in turn. Per JWP record the Title table will be searched far the provided sang name. The Recording table will also be searched for an LCC
code matching the LCC provided by the JWP data set record. The resulting records will attempt to be joined.
A successful join will indicate the correct record in the Recording table to update with the JWP
provided availability information. The successful update will be logged as "Successful Update".
An unsuccessful join will be log as an "Unmatched Failure".
Side effects Modification of Recording table.

Classified Advertisement Application The classified system for this phase will be purchased, installed, and customized. Issues to be solved are the inclusion of HFA templates into the purchased application and the inclusion of the chosen ad server tags. The system will not include the rich subcategory and attribute data model that future efforts will provide in future phases.
Features will include:
~ User-selectable option on the "Post an Ad" form for choosing whether to display the poster's street address and telephone number in the ad.
~ Optional ability to block "bad words" as defined by the admin ~ Optional creation of logs of all activity, including posting, modifying, or deleting ads. The logfiles also include the IP addresses of the users performing these activities ~ Web-based Control Panel allows the admin to modify or delete any ad, review new ads before they are posted, send out e-mail notices to users whose ads are about to expire, purge old ads, run the Keyword Notify program, view the mailing list, clear the mailing list, and send out mass e-mails to subscribers, all from a point-and-click graphical user interface.
~ Admin can define varying expiration dates for ads (this can be set to any number of days) ~ Ability for users to post ads for varying amounts of time ~ Internationalization features, including a "Country" field ~ Ability to (optionally) use pre-defined caption headers that are also searchable on the Advanced Search form so that users can find specific types of ads ("For Sale", "Wanted", etc.) ~ Support for optional fee-based classifieds ~ Multiple fee levels ~ Optional e-mail invoices to posters on fee-based systems ~ Can optionally charge for renewals and allows admin to set amount of renewal charge ~ Automatically displays specified number of ads on each page, with a "See the Next 10 Hits"
button ~ Displays latest ads first ~ Can limit number of categories ad is posted to ~ Can limit number of times an ad is renewed ~ Can limit number of words per ad ~ Can block duplicate ads ~ Ad owner can modify or delete at any time ~ Automatically inserts the contents of the current ad into the modification form for easier modification ~ Optional e-mail notification to admin when ads are posted, modified, or deleted ~ Optional e-mail response to user when ad is posted ~ Allows clickable URLs in ads ~ Allows clickable e-mail addresses in ads (these can be hidden through the Privacy Mail option) ~ Can collect names and e-mail addresses for mailing list ~ Can send mass e-mails to subscribers who have signed up for your mailing list ~ Optional warning e-mail notices to users whose ads are about to expire ~ Can automatically purge expired ads ~ "Warning" and "Purge" programs can be run automatically by the program or as separate programs that are run either as "crop" jobs or manually ~ Optional pre-screening of new ads by the admin ~ Keyword Notify service sends new ads to users that match their pre-defined keywords ~ Subscribers can select number of days before their Keyword Notify profile expires ' Program can automatically purge old Keyword Notify profiles ~ Boolean searching (any words, all words, or exact phrase) ~ Customizable ad categories that can easily be defined through a setup variable ~ Customizable ad display including the width of the ad tables, table border size, text and background colors within the ad tables, and the text font.

~ Password protection for ads so that only the original poster can modify or delete ~ Administrative password that allows admin to modify or delete any ad ~ Privacy Mail, which hides the e-mail addresses of those posting ads ~ Global variables for defining the appearance of HTML pages generated ~ Date range searching ~ Case-sensitive searching ~ E-mail address validity checking ~ URL validity checking ~ User passwords are stored in a secure area ~ Can display ads in short "Headlines" format or as full ads ~ Allows users to specify whether they want to view ads as "headlines" or full ads WO 00/42555 PCT/US00l00835 CJlent Request Delivery Module This application will need to be invoked an HFA client wishes to forward a song-based request to the HFA. The request will be formed by a cgi application and delivered to the HFA via email.
Input To be defined. All input will be user-entered but could be mapped to any of the fields found in Appendix D. Forms will need to be built to accommodate the chosen fields, these will be presented in series in "wizard" form, with user state being preserved.
For access control, tables will come fram the POLI system to harvest usernames and passwords.
Output A log file indicating successful and unsuccessful updates to the web supporting database, and an email message with a tab-delimited list will be sent to an HFA email address.
Supporting data See Appendix D.
Side effects None.

Song Search : Phasel interface, algorithm For Project:
Songfile.com Web-based Song Search Release No: V1R2M0 Draft / Final as of: April 28, 1999 Printed: July 7, 1999 Author:
Client:

Table of Contents SCOPE.............................................,............................
...............................................................................
...4 USER
INTERFACE......................................................................
................................................................4 SEARCH BY SONG HIT LIST
...............................................................................
...........................................5 SEARCH BY ARTIST HIT
LIST...........................................................................
.............................................6 SEARCH HY ALBUM HIT LIST
...............................................................................
........................................7 SEARCH BY COMPOSER HCf LIST.....................................................,.....................
.........,........................,...,7 SEARCH
ALGORITHM......................................................................
........................................................8 DESCRIPTION OF SEARCH METHODS
...............................................................................
.............................8 Exact Match..........................................................................
...................................................................8 Ordered Word Match..........................................................................
.....................................................8 AND ojSearch Words..........................................................................
....................................................9 OR ojSearch Words ...............................................................................
.................................................9 Phonetic Search.........................................................................
..............................................................9 Partial Phrase l Generic Search.........................................................................
...................................10 Wildcard Search ...............................................................................
.....................................................IO
HOW WILL SEARCH METHODS SE COMBITJED?
...............................................................................
............11 User Search Options........................................................................
......................................................1I
System Search Options ...............................................................................
........................................... l1 SUPPORTING
DATABASE.......................................................................
......................................................13 WO 00/42555 PCT/US0~0/00835 Scope This document overviews the interface requirements and search algorithm of the phase 1 deliver;ibles for the Songfile.com Song-Search project.
User Interface The look and feel of the web-pages will be specified by Mezzina Brown, and delivered to LANS.A.
To aid in their efforts, the following land-marking of the search-related section of the web-page is proposedt:
Search Interface, and sample flow This upper section will always appear. It wi Exsn Mane allow the user to All word, specify the search criteria, and shows the existing search criteria under which matches were found.
The middle section will appear if more ~t than one page of matching records were found. Ln this example, the currrnt page is number 7 of 9 available ~t~ng on the search page. By method (by song, clicking on a number , by ~~ ...) the bwa the user section will show will jtunp the to that pages aPP~~ eohtmns of information.
records, If no - rrcoMs were fotutd, an appropriate message win appear instesd of the uist.

t Tables would be used, not frames. Note that the Search Criteria section would always be visible, while the other two sections would appear only if matches were found.

This section instead focuses the content of the user interface.
The following search methods are required for Phase l:
~ By Song Title ~ By Artist Name ~ By Album Name ~ By Composer Name For all of the above, the search criteria interface will be the same, consisting of:
~ Search method (radio buttons or a drop-down consisting of the above search methods) ~ Search String (a free form I20 character user-provided string) However, far each search method, the resulting "hit list" will contain different columns.
Search by Song Hit List The CD UtllVefSE.' ICO11 will have a link to the CD Universe partner site. The actual URL, used will be of the format:
htto:l/cdu2.cduniverse.~m%as~ owmanyartists.asp?search=<artistnamea where <artistname> is replaced by the appropriate artist's name The system will log each time a user clicks on such a link.
Note that the derivation of <artistname~ will not guarantee a perfect match to an artist in the CD Universe databases.
This is due to the nature of the existing HFA data. For example, the artist "Earth, Wind and Fire" exists in the existing HFA artist database as "EARTH WIND AND FIRE", as "EARTH, WIND
lir. FIRE", eac etc.
Also note that the existing HFA Artist database combines artist names in different ways when they collaborated on a song. For example:
"MICHAEL 3ACKSON AND DIANA ROSS" collaborated on a song HOLLY COLE, BRYAN ADAMS collaborated on a song DIANA. ROSS & LUCIANO PAVORATI collaborated on a song 2 In the event of CD Universe not finding a perfect match, the user will have to select from multiple hits on the artist name in CD Universe.
6~

The Sheet frIhISIC ICOn will have a link to the .11JV Pepper partner web-site.
No URL format exists, so the system must send the user to a hidden form, set hidden search parameters and auto-submit the form. This should be transparent to the user.
The system will also log each time a user clicks on such a link.
The Recording Detai~S Link will bring up a page showing the details of the particular song recording. This link will only be enabled for songs that have multiple licenses. The information included will be a subset of the following:' Title Composer Artist Album Genre Release Date Play time A list of other artists who have recorded this song (Artist Name, Album Title, Release I>ate) None of this information will have underlying links.
The #Times Recorded column will indicate the number of times the song was record<:d. It may also be possible to list the songs in descending order by the number of times recorded. Alternatively, it may be desirable to replace the number by a flag, indicating the most commonly recorded song in the list.
The ~ASCAP column will indicate whether at last one publisher of the song is affiliated to A.SCAP.
The ~M~ column will indicate whether at /cast one publisher of the song is affiliated to BMI.
The ,~CtiVe Flag column will indicate whether royalties have been paid on this song in they last 3 years.
Search by Artist Hit List The C~ Universe ~COCI will be the same as in the By Song HiL List. No oilier column;. of inforntation will have underlying links.
' This list of information was taken from Figure 5 of the Mezzina Brown design specification. The actual information shown will depend on what the existing HFA database will support.
sa WO 00/42555 F'CT/US00100835 If the existing HFA database supports it, the # Albums and the # SOtIC~S will show the number of albums and songs recorded by this artist.
Search by Album Hit List ?'he C17 Universe ICOII will be the same as in the By Song Hit List. No other columns of information will have underlying links.
If the existing HFA database supports it, the # Songs will show the number of son;~s ! tracks on this album.
Searoh by Composer Hit List If the existing HFA database supports it, the # SOtI~S will show the number of songs written t>y this composer. No columns of information will have underlying; links.

Search Algorithm This algorithm will run on the AS/400 host, given input from the user interface described above.
For each of Song Title, Artists, Album, Composer, the following search methods will be conditionally employed:
1. Exact Match 2. Ordered Word Match with n, n-1, n-2, ... words; where n = lesser of pre-defined maximum and the number of words provided by user in search string.
3. AND of search words 4. OR of search words 5. Phonetic-like search 6. Wildcard search Description of Search Methods Exact Match In this method, the entire user search string (up to 256 characters) will be set to upper case and compared with the full upper case name in the appropriate file. Only exact matches will be returned.
Ordered Word Match In this method, each significant' word of thrr user search string will be used as keys against the appropriate Ordered Search Key file. First, all n words will be used, then n-1, then n-2, etc. The search will end when either only 1 word remains, or matched are found.
For example, The song title "There's no cure like travel, Bon Voyage", would be stored in the ordered keyword file with keys THERE, NO, CURE, LIKE, TRAVEL, BON, VOYAGE.
If the user entered a search of "There's no cure like travel, good voyage", it would be converted as:
THERE NO CURE LIKE TRAVEL GOOD VOYAGE.
First, the full 7 words would be used as keys I through 7, finding no match.
Then, words THERE through GOOD would be used ... no match.
Then, words THERE through TRAVEL would be used, finding the one match!
The above would require only 3 file I/O operations, making it a very quick method.
In summary, the Ordered Word Match is a very fast and accurate search for situations where the user accurately spells and orders the significant search words.
Significant words are those not listed in the "Insignificant Word File" (e.g.
the, in, a, to, ...) WO 00142SS5 F'CTlUS00/00835 AND of Search Words In this method, each of the first m significant words are used as keys against the Keyword File. All words must be included in a song in order for it to be considered as a match.
For example, if the user specifies: "Bon Voyage Cure Travel", all four words must be somewhere in the song title.
One possible implementation of this algorithm is:
SELECT records from Keyword file with-key First Word (in this example, First Word = "BON"}
SELECT records from Keyword file with-key Second Word ("VOYA.GE") IF Full title also includes All Other Words (i.e. "CURE" and "TRAVEL") THEN include this record as a match END SELECT
END SELECT
A song "data dictionary" may also be employed to help determine the fastest path to the: match list. It would be populated at time of data conversion with every significant song word. Each record would include the upper case version of the word, then the nurnber of songs in which it appears.
For example, "love" may appear in 200,000 song titles, but "Tuesday" may only appear in 50.
Using "love" as the First Word in the above search would result in over 200,000 I/O operations.
Using "Tuesday" as the First Word would result in at most 100 I/O operations.
By first consulting the data dictionary, the search would be performed in the most efficient order.
The down-side of this is that the data dictionary would 'likely contain on the order of 100,000 records.
OR of Search Wordss In this method, each of the first m significant words are used as keys against the Keyword file.
For example, if the user specifies a starch of "Say Bon Voyage Please", then all records in the Keyword file will be considered matches, as long as any of the words match.
It is likely that this Method would be extended with a match %, and resulting records ordered in a descending fashion.
For example, the result of the above search may be:
Baby, Say Bon Voyage (75%) Please Don't say Goodbye (SO%) There's no cure like travel, Bon Voyage (SO%) Voyage to Heaven (25%) Etc.
A lower limit may be set on the match percentage.
Phonetic Search For each Song that is converted to the LANSA database, a Pbonetic-like code will be generated for each ~of its words. This code will be used as search keys, and used un a way similar to the AND and OR searches above.
' For performance reasons, this search method may not be practically implemented.

For example, The title "Lemon Tree" wil! be converted as L.550, T600.
This means that the user will get a successful match if the searched for any of:
Lemmon Tree Lenom Tree Linen Tire Lemen Try, etc Since they all have the same phonetic-like sound code.
Partial Phrase I Generic Search Using LANSA'Generic Select, this method would use the search siring as a beginning characters.
For example, if the user's song search string is "'Everg", then songs beginning with these character:. would be considered matches, including: "Evergreen"" "Everglades of Florida", etc.
Witdcard Search6 Using SQL and/or OPNQRYF, this method would be used only as a last resort, in the event that they above methods resulted in no matches.
Basically, each word would be treated as a pattern.
For example, if the user's search string is "Voyag Tra", they will be ueated as patterns, amd songs vvith words such as Voyage, Voyaging, Travel, Trade, Extra will be considered matches.
This search method is much less efficient, and may be too slow to be practical.
6 For performance reasons, this method may not be develop<:d.
7~?

How will Search Methods be combined?
The above search methods will be developed as function modules, allowing them to be used in an,y permutation. The goal is to have a search engine that can be customized without having to re-code nor rr.-compile anything. Customizing the search engine, will be done in two ways: by the user, by a system administration function.
User Search Options Intelligent This is the default search method. As configured Default It is described in the by next section. the system administration function below Exact Match If, for example, the user is confidentExact klatch that s/he knows thc:

full title of a song, s/he might choose this search method.

It will result in the fastest possible performance.

AI! Words By choosing this option, the user Exact Ivfatch, is indicating that matching songs are those with all then Ordered, words matching.

then And Any if'ord By choosing this option, th,e user Exact hiatcb, is indicating that matching songs arc those with any then Or of the words matching.

Partial PhraseThis option allows the user to type Exact Match, in a partial phrase. It will be used as a generic key. ;For then Generic example, a search string of "Evergi' would match with "Evergreen, Everglade, ..."

In addition, the user may click or de-click the check-box of Phonetic Similarity. This options works will the And and Or searches.

The user will have the ability to customize the search. Slhe may choose any one of WO 00/42555 PCT/US(10/008:15 System Search options The system administrator has control over many different parameters of the search algorithm. T'he idea is that ,s~'he may monitor the performance of the site, and modify the search algorithm as necessary without the need for any functions to be changed or recompiled.
The following parameters / tables may be controlled"' " . m ~ ~ n ~ - , Availability ojUser Ordered table of User options to be included on the search Intelligent Dft -I
Options in Dropdown page. Exact Match - 2 All Words - 3 Any Words -- 0 Partial Phrase - 4 Availability ojPbonetic A system variable which controls whether the Phonetic 1 ~ Enabled Simllariry Similarity Checkbox appears on the user's search options, 0 =
Disabled Insignificant Word List' Table of words to be dropped from search strings The, and, it, is Maximum Matches A system variable which sets the maximum number of 25 matching records to be shown on one page. It should be possible to allow the user to continue, looking at the next GS matches.
Alternatively, it may he better to have a link for each page.

For example, if the Song-Search results in 250 hits, the first page of 25 hits will ix shown.
Plus, links to all 9 other pages will be available to the user.

Intelligent Table of ail search methads, and Exact Match Default tht sequence in which - 1 Search Method they should be employed, if at all Ordered -when the user chooses 2 the Intelligent Default Search MethodAND - 3 Phoneaic OR-0' Wildc:ard Continue Flag Part of the Table of Intelligent Exact Match Default search methods, dais - N

flag would indicate whether or not Ordered -the search should N

continue, even after a method resultsAND - N
in 1 or more hits.

Match Percent A match below such a percentage would20%
not be minlxrum considered. This could be used with the OR method, and possibly with the Pbonetic method.

Minimum OrderedUscd by the ordered Word method as 2 the minimum Words number of words to be used.

(i.e. n, n-1, ... , MiniumCNderedWords) Maximum OrderedUsed by the ordered Word method as 9 the maximum Words number of words to be used.

(i.e. MaximumWords, MaximumWords -1, ... ) ' Due to the nature of the HFA database, the data in the music industry, all words may be deemed significant. For example, a band by the name of "TH~ THE" would pose a problem if "THE" were in the insignificant word list.
' A sequence of 0 would disable that particular starch method.

WO 00/42555 P~CT/US00/(10835 Supporting Database In order for this search to run efficiently, the following data file structures will be required. As much as possible, the existing data files will be used, but it is probable that several additional physical and/or logical files will be needed. This "data warehouse" will be automatically populated from existing HFA data by a conversion function written in LANSA.
Below is a list of such needed files for the search by song title. Note that similar structures would b~e required for composer, album, and artist.

Song Title Keyed by complete9 upper case kitleExact match (a logical file over PFSNGTTL?) Wildcard search Ordered Song The first n significant wards will,Ordered \~Vord Key>vords be stored as uppercase keys in the file. Match (A logical fde For example, title "There's no cme over like travel, Bon PFSNGKWD?) Voyage" would have 1 record, including the song identifier, plus:

Key I = THERE

Key2 = NO

Key3 = CURE

Key4 = LIKE, etc.

Song Keyword This file would contain all significantAND
list words of each ewch s song's title.

Included would be the song identifier,OR search plus the upper case word as the key. This file would also store the phonetic code or the word. Phonetic ;search For example, song 123456 with title "There's no cure like travel, Bon Voyage" would .have up to 7 records.

CURE C600 123456, etc.

Data DictionaryThis file would contain one record AND Search for every (significant) unique word in all the song titles in the database.

It would be keyed by the upper casePhonetic ward, and would also Search have a field to contain a title count. It may also be desirable to include tht phonetic code.

9 For the exact match search, even insignificant words will be retained.

WO 00/42555 PCT/US00100~835 License Rights Determination Specification WO 00/4555 PC't'/US00/OO;B35 Agency E~ctranet Functional Specification Section 1: Functional Ove~iew Existing systems support three business functions related to the licensing of rights for music. Three discrete departments within the HFA execute these business functions, Indeac The index department maintains data files that support licensing adivitita. These files inGude recortis for the song tides that the HFA licenses and records for publishers ('fhe HFA's clients) and licensees.
Synch~onizatiors: The Synchronization department licenses rights to music for use with motion pictures, television, or other applications where music is used in conjunction HMh moving images.
Mechanical: The Mechanical departmenk licenses rights to music for use on~
records, tapes, CDs, and other applications where the music is recorded on physical me~~ia inGuding music boxes and musical greeting cards.
This project's goal is to externalize three major functions of the current work flow:
eareh: Users should be encouraged to use the SongFile web property as the searclv~ engine to find music kicensable through the HFA. This will greatly diminish the amount of researd: that gets done for free by the HFA for the public.
Negotiation Handholding: The Negotiation Space, or Deal Space, will enable u:>ers to be more self-sufficient with regard to the arbitration and documentation of licensing.
The HFA spends a lot of time coordinating the negotiating of licensing, and collects no tee if the deal is not strud~ Some dients only approach the HFA to finalQe the license after an agreement is reached, and then HFA collects a fee. The Deal Space should help more licensing processes re<rch the HFA only when an agreement is made_ Conflict Resolution: A lot of License processing is put on hold when conflicts arise. These contficts stem from ownership contlids, etc. The contlid resolution process, unlike the negotiation space, is primarily an HFA hands~n faa7ity, much like a trouble-ticket program, where histories and cases can be traced back in time. This will be a tallow traveler to much of the Index maintenance functionality.
The two main application processes in this system one the fulfiIImeM of valid license requests and the maintenance of Index records. Note that Negotiation Handhokiing and Conflict Resolution processes aren't expliatly ixnken out below. While Negotiations and Conflicts are significant processes, within this system, they are triggerpxl events within She following processes. Therefore, more detail on Negotiations and Con!lids will be given in Section Two of this document.

WO 00/42555 PCT/USO~D/0083:5 Futfi!! Valid License Requests 1) Completed License Request is received. HFA determines if the request per;airs to a song HFA can license. Otherwise reject Request.
2) Shepherti negotiation process. Transmit quotes and offers between the song publisher and producer (License Requestor).
3y Generate and deliver the successfully negotiated license after having the license signed by the publisher.
Maintain Index Records 1) Written authorization for the addition or modification of an Index Record is received.
2) if the request is to add a publisher's account, a membership packet is shipped out to the publisher.
3) If there are exceptions or conflicts, make a record of the disputed record~distribute the record of the dispute such that the r~nflict may be resolved.
4) If there are no exceptions or conflicts, the additions or changes are committed to the Index.
Sec.~tion 2: Function Inventory Pnxessing and t=utfi!ling Requests for Sync and Mech Licenses Front-line bE8-cu~ntl applies significant human resources to the~yalidation and fulfillment of Mechanical nd Synchronization Licenses, also known as 35.54 IicensEa. This system will be ed 1o make these processes more effiaent. By moving some of th~~ related steps onto an electronic system, filing and other paper-handling tasks that comprise a significant portion of licensing processes will be eliminated. Implementation can Ibe broken down into two categories: online forms for electronic data entry, and ;~oftware-based facilitation of validation and routing process steps.
Online Forms a Search SongFile for Songs to license: this may be handled externally to this system (rn the SongFite website).
Synchronization License Request form w,...w.,..:~"~:_., ~ :.,...._., n....,......a s.......

WO 00142555 PCT/US00l00835 Validation and Routing r Direct non-registered Requestors (Manufacturers and Producers) to New Account Application process r Reject Invalid License Requests Once the License Request form is completed, HFA determines if it represents any entities with rights to the song.
If HFA does not represent any of the entities with rights to they song, a 'Do Not Represent' or DNR form is sent to the Requestor, most likely a Prraducer.
r Route Valid License Requests to Negotiations Handling License Requests Arriving from Negotiations Once a price has been negotiated, the price quote is stored and the 'pertinent license is generated.
r Store record of negotiated price quotes r Generate License for negotiated License Request r Deliver License for negotiated License Request Processing Updates and Additions to Account and Song Records The system will inGude data entry forms supported by softwan.~based forth-field validation.
Adding New Account Records r Get request online r Send packet or online packet r Assign M or AT Number Adding New Song Records Functionality to add new song records will be implemented in two ways: singf~s record entry mode and batch (multiple record entry mode. Single record entry mode is implemented as an online form with software validation of foml-field data.
Batch entry mode is implemented as an upload of a document formatted accortfing to predefined rules.
New records will be queued for review by a human administrator. Therefore, they system will inGude a display saeen for administrators that facilitates reviewing andl editing queued records.
~ Online form for each record or batch mode upload $0 WO 00/42555 >'CT/US00/00835 r Drop in without checking for contlids r Queue for human review r Commit new recr~rrls with datenime .rtamp UpdatelChange Account Records r Compare updated data with old data and took for conflids Update records and log changes if no contlids exist r if conflids exist, freeze recur-,i and send to conflict resolution systern UpdatelChange Song Records r Compare updated data with old data and look for conflids r Update records and log changes if no conflids exist r If conftids exist, freeze record and send to conflid resolution systern Facilitating Resolution of Data Conflicts The system will provide functionality to support conftid-resolution processes triggered by certain Index department tasks. An example case in which conflid-resolution processEs are triggered: A Check Claims procedure iderriifies a piece of disputed information. Data pertaining to such conflicts must be appropriately flagged within pertinent databases. This data may be "frozen' periling resolution of the corresponding conflict.
Such conflicts may be discovered automatically by software, or resolved manuatly try personnel. In both cases, the system faalitates resolution by personnel with display screens that consol'~iate and organize conflict-related information. These display screens will be comprised of data generated and stored automatically (such as dates and times), data pulled from indexing databases, ar>d data entered in by personnel responsible for handling such conflicts. One example of an automatically discovered conflict is Hrhen thie total ownership of a song exceeds 100%.
Package and tag data pertaining to conflict r Online form combined with data automatically pulled upon discovery of cornftid. For easy retrieval and reference by parties to conflict. Packaged data indudes:
r Dateltime of conflict generation r Identifier code for item in dispute (Song Index code or Account Index code) ~ Ownership data r Nature of conflict r PaAies to conflict: personnel dealing wfth conflict will tog in and oul of system so IL-n .~W _ ..- 1.~_ --- L- ~---1.-J -...J --..--.I-J

WO 00/42555 PCT/US(10/008~5 Status 8 Date of last status change;
~ Resolution Information / Notes: how the conflict is or will be resolved Tag with Identification Number Facilitating Licensing Related Negotiations The system will provide functionality to support the negotiation of licenses.
Liven;>ing negotiations currently involve multiple exchanges of paper documents between HFA and other parties involved in the negotiation. Transferring the bulk of these exchanges onto an electronic system can significantly help the HFA. This is because paper processes involve personnel who are responsible for receiving paper document. and scanning them into a document management system where they are given an identification code.
There is no explicit business reason why these documents must exist in hardcopy form until the final license is generated.
Package Negotiation-Related Information The system will support licensing-related negotiations by consolidating all pertinent data onto easy-to-use display screEns. These display screens replace intermediate document exchange steps between the commencement of negotiations and the generation. of licenses that are currently paper-based.
These display srxeens will be comprised of:
~ Contact information for all pertinent parties ~ Status 8~ Date of last status change ~ License Request data ~ General Notes: much tike a log of an aniine chat session, with usemames preceding pieces of text. Users can use this for anything they wish.
Provide Electronic Contracts The system will provide functionality to display model contracts or working copies of contracts. These contrails may be printed out at the user's disxxetion. This will eliminate the need to print and deliver hard-copy drafts of contrails to involved parties during the negotiation process.
Upload document Online editing of document Version Control of edited documents, including tracking of changes male and by whom Download of document (so that it can be printed) WO 00!42555 1'CT/US00l00835 User arrives at site and firkts song to register in SongFie User search enters If user has no client data ID, user into should fig in additional ~
form entry i form Y
U

.c Should not be needed HFA ~PbY
due to ' Songfib search, but Checks owx ~t of should be N"

present DB

Ayencbs oK

Check and see ( user is an HFI1 HFA

clie nt t Checks Q r< not found, send to help page wth ti sign-in roan DB
V

x --- ox y'a If sorg has a caleuabls !ae stnicwra, go ahead at ebe ( song owners want kind a1 licenses o -...

t~ to bs negotiated, send to Deal ee Deat:Spau structures m Space sr~w.r.-~

c Look for various warring a flags, Send . to ~ ownership that adds r up to > 1t70y6, v etc Any re'.
U Conflicts?

Resa kdion Space Ho tf iCs al good, generate Generate and record license License Deiver licenaa by whsbwr mans has Deliver c been agreed to, such c as e-mall, fax, U.S. License mai ~.i Receive When license comes 8nd I
scan back signed, scan and finished '~av ~ License Send check or irnoia i copyto AIR

NR

WO 00/42555 FCT/US00/'00835 i ~ User arrives at site and finds song to register in SongFie search USer enters ~ If user has no client ID, user d8ta into should fill In additional form end form t ~ Should not be needed due to HFA _~ Display Songfile search, but should be '~'~ ~ Checks prig List of present I Other p ~ Dg 1 Agen:ias ""-? OK
~ Check and see ( user is an HFA ~ HFA
Y
V ~ client Checks -ny~peh t ~ If not found, send to help page wrtt~
u_ V sigrrin form D8 Z
c ~ Look for various warning flays, ownership that adds up to > 1 tX?%, Send to etc Any Conflicts? v~'- Resol rtion x U
w Spaee No h ~ Send request to Deal Space ~ Wait (or agreement to be struck .a = ~ Proceed onu tartns are present Do we have ~r r~r Sendl to V n agreemen Deal Sioace _..~reo ~ H iCs ea pood, generals Generate and record license License ~ Deiver licans~ b/
whatever means hes Deliver c been agreed to, such as ~-mail, fsx, U.S. License c d mai U
J
KBCEIVe ~ When license comes and scan bade signed, scan and finished stop t License ~ Send check or invoice copy to AIR a NR

WO 00/42555 PCT/US00/0083:5 Objectives 'Ibis design document is based on several interviews and meetings at the Harry Fox Agency. The objr_ctives, as laid out in the Project Scope document, which arc addressed and designed in this doetunent are:
1. Enhance Songfilc.com to provide a professional starch for authorized users 2. Interactive Q&A for Rights determination 3. Automation of Rigbts Matrix logic for detrrminirtg correct processing for license requests 4. Extend Professional extranei functions to include SIRNET style license requesting for both large volume meth and DPD licensing 5. Process 35.50 licenses, including payment, over the interact Professional Song Search The Songfile.com search engine which is live on the Internet, provides searches via song, writer, album and artist over the IiFA song and license database. The results from the starch shows consumer information about the song (or whatever was searched over), including links to painter sites for CD's, sheet music, audio clips, and lyrics.
HFA would like to extend this starch, for use by authorized users of the professional area of the site, to allow music professionals to also find information oa the owner/music publisher for a particular song.
Additionally, this will feed into a SIRN>~'T' style liccasing xequest form for manufacdiretx.
Generation of Userids All publishers and manufacturers that Harry Fox deals with are to be given User Names and Passwords for autHeaticatcd access to SongFile's Professional Search, and related functionality. The Name and Address file (NMAST) contains entries for au such publishers and manufacturers.
A subset of manufacturers arc registered SIRNET users. For these, additional information is availatde in the S1RNET file "SIRUSER.S":
Field Description T - " I~gth 1. PINK PINK C har6 2. MANNO MANNO Char 6 FIRSTNAME First nartu Chat 30 LASTNAME Last name 30 SHOWSPLITS Show fits Char 1 SHOW00001 Show all ublishersChar 1 ~>rmail J Etniul addressChar 60 Some SIRNET manufacturers are registered a "Mufti-manufacturert". This mesas that they have a unique, but dummy M-number - and the ability to act on behalf of tcverat other manufaGttuers.
The relationships between mufti-manufacturers sad their "child" maatifacturera is a>sintxintd is file "PFMLCHM":
Fic7d Description MN _ Manufactum Id Char MIvIMFRL Related manufacturesChar ' HFA will make the necessary modifications to their systems and procedures to eotleet, store and mvtintain this new inforrnatioa.
~5 WO 00/42555 PC'T/USO(I/00835 Bascd or. the NMAST and SIRUSERS files, a LANSA function will be developed to generate User Names and Passwords as follows:
User TyptRegistered ~ Generated Muln-manufacturer?
Generated User Name In SIRNET? Password No No <Mnumber>

Manufacturer No <Mnumber>-<plll>Pseudo-random Yes Yes <MultiMnumber>-<plTd>A.lphanumen,c PublisherNo No <Pnumbcr>

Note that this generation will need to be run during initial implementation, but will also have to be triggered on a regular basis as new manufacturers and publishers are added to the Harry Fox database.
The generated User Names and Passwords will be stored in a database file and accessed by the web-server during user-authentication. During initial implementation of the ExtraNet, this file will 'bc used as the basis for an automatic mass-email to all valid users. Included in the e-mail would be:
~ A welcome message and some basic instrucdons~
~ Username & Password for authentication ~ An imbedded URL to take the user directly into the ExtraNet portion of SongFile.ccrm If Harry Fox has no e-rrtail address in its database, use~x will be natified via snail mail.
Sign-on to Professional Search a new "Professional Search" icon will be added to the ~ imhedded URL in the welcome e-mail message sent to manufacturers and publishers ~ the Rights Determination pages - if the user requests an unrestricted mechanical or :DPD license The first time a user attempts to access the ExtnNet via any of the above, afire will be asked to authenticate his/ltersclf In addition, a link to the Online Account Regisdratioa Form will be accessible, for users who an mot valid users but wish to apply to be s manufacturer with HF'A.
~ HFA will provide this content.

There will likely be several entry points into the Extrahlct portion of SongFile.com:

WO 0012555 PnT/US00/00835 Online Account Registration Form An account registration form, similar to the paper version below (with an additional form field for e-mail address and perhaps wcb-site) will be provided oa the Internet. The information entered into this form will be passed to the index department to complete the application. This will not be an automatic account registration, simply a request.
TIfE lIARRY FOX wGFNCY INC.
' . ~I~Yryf \~T10\~f. MXIf 1111t1s1fL1Lt' ~ri0(xA110.'I, l~G
ht8 rl G
~~~a~.c.. ~ . M.a..v.~ u«>~.~ At...w c~.r...~. wr _ ..
f~.~.., uie. ..
Ym I,~r ~.r lJ~irrl4: haNw s.c.s.~.va._ ___ _____--. vwdm.--_ _ c-w.a « p c..~.~"~ p r.~.,.w,, Q rrw~r u....
a t...,p.,rr, slr~r w Orr .f ~a"s~...-_ _ ~.~-_-Iwv wr e.w r.r vuwy w1 HiA7 Y.w_ _. tim~._ fln ww..arm.,pi~rrru _.._..~_._~-_~~~.
YInrwIwrwuwl(aI1F4Y4awwp( 1 1 1 J
~~r~4 bllwy.pnl - _ fw~fMwfi _- _.
A.~qrwl~rw.~lrW Yw~srt~lm~lr ~OwIIC
/<:il~'tQ.l1 GYTOIIt~110N
A.~.r a ~ o... Irr to.s ~
punoo~.~.. pasraa»ow Ouoooou~roo po..c~
w w... _ ~ __ ___.-.._. ___, _-_ Ally _-T,...m. w rte. ra.:
h..r. -.__ ru.-___ n.r~_ taA rr.r Irr orr w.~r~. ,y~r b WO 00142555 PCT/L)SO(1/0083!i Extend Search Capabilifies The professional search will extend the search capabilities of the Internet songfile.com si;e by allowing two search criteria. The search options on songfile.com wi'II be duplicated with the first search criteria defaulting to a song search and the secondary part of the search defaulting to a writer search - similar to the current SIRNET offering. If the user fills in both starch criteria, then the starch engine will do an AMID
search - which means the results must match both criteria.
Basically, each of the two parts of the search will be conducted individually, then the results will be cross-referenced to provide the user with the intersection of the two searches.
For example, if the user searches for:
Song Like This ~ apple Writer Like This Collins~
then s/he will get results such u:
ADP1F AEAST (6Mt) me utrtns i5 QERtKp 1HE DOOR ! KEEP OME IOtS COtJINS, ROt4 L
[tJtIJVERSE '6RN,G~, WHITE TRASH I WHTTE TRASH ' ALViN. A. i.911Itt5 APPtF PIE [Addbon~l Recordimtl However, the Song Code and Publisher Split will also appear in the results, as descn'bed in the Extended Hit List section below.
Note that the first search will determine the type of results to be displayed.
In the above c,asc, songs tree displayed because the fast search criteria was by "song".
Also note that not all permutations of search criteria will make sense. This is still to be determined.
The maximum matches (currently set to 250) will still limit the results of each of the two ;parts of the search. It is yet to be decided if the SongFile site will affer the user the ability to bypass this limit. hf this is oflcred in the SongFile site, it will be included in the Professional Starch as well.
Exfend Hlf Llst The search results list for songs twist be extended to include the Song Code and the Publisher name(t~).
If ov~~nershipipublishing rights to a song are shared by several publishers, all publishers will be; shown, along with their %splits.

Technically, this will be achieved by leveraging the existing; Starch functionality developed for SongFile.com.

WO 00/42555 P(.'T/US0~710083'S
To show the publisher splits for a given song, the following algorithm will be used:
Select al! records in PFSNGPUB with the current song code If SGPBSG > 0, use rice SGPBNO to fetch from NAMAST
(this publisieer has some ownersSip of the sang) IJNACODA <> 'N' (NF~t represents this publisher - perhaps highlight that for the user) Each publisher name will be a Link to a publisher detail page - described below.
Publisher Detail Page A new web pager will be designed which shows, for a selected publisher, its contact information, arid address. This page will be display only - the users will not be able to change any of the information on the page.
Since Harry Fox will be extending their Name and Address file to include e-mail address and web-site, it is possible to include this information as well, if desired.
Professional Search Extended Functionality After the professional starch engine has been set up in a secured extranet environment fot manufacturers and publishers, the ultimate goal will be to allow users to inter license requests and Notice of Claims forms.
License Requests There arc 3 main types of licenses to be addressed by the web-application:
~ Mechanical Licenses ~ Restricted Mechanical Licerues (a.k.a 3.50) ~ DPD licenses The goal is to have these licenses handled by the system in as similar a fashion as possible.
Mechanical Licenses Regular mechanical licenses will only be available to authenticated manufacturers, not w the general public, and not to authenticated publishers.
After authenticating, a manufacturer can click on the license icon in the upper Game. Then s/he wi111 be guided through a series of Questions to help determine the type of license that slhc requires. Then, the user will build a "shopping cart"' full of songs by using the professional search functionality. Then, t separate license is required for each song, the user can specify iafocmation with each song being requested.
t It may be dtsicable to have this information appear irt a window, rather than replacing the eurreat web-~age. This is to be determined.
It may be required for a blank mechanical license request form to be provided in the event that a tong is not available in SongFile.com.

WO 00/42555 PCT/US00/(10835 The following Diagram depicts the proposed flow for an authenticated user to obtain regu ar mechartical licenses for several songs.

WO 00/42555 PCTlUS00/00835 Aftet a mechanical license request has been roughly validated by the application (c.g. mandatory fields have been entered), the existing SIRNET files will be automatically updated.
From that point, the normal back-end (and partially manual) process will take over.
The; following cxi~ting iicensc request files will be updated for each license request:
File Descriptlou PFMLRPRM License request primary file PFMLRART Artist PFMLRALB Album PFMLRSNG Song PFMLRWT' Writer _ _ PFMLRACT Activity PFMLRPAR Paragraph PFMLRREC Request PFMLRTX1' Text If the information is not already available, it is recomrnended that the SIRNET license request files he updated to include a ''source of license request" flag. This would allow Harry Fox to di:ctinguish between a request originating from the Extranct versus one received by the SiRNET client-servo z;pplication.
It is. further recommended that a new status flag value of "incomplete" be used to indicate that a license request is still in the contrerl of the user, and should not yet be processed by Harry Fox. This is analogous to the license requesu in SIRNET that have not yet been transmitted / uploaded to Harry Fox. In the content SIRNET solution, such license requests sit in their client-database.
There is no such client-side database in this solution.
DPD Licenses DP:D, or Digital Phone Download, licenses are for digitized music files that can be passed around and downloaded via the Internet (or via computer media like diskettes).
The process of granting a DPD license will be the same as the above mechanical liccnse~srocess; DPD is simply one of many difFerent configurations (CD, Cassette, LP, ...) available to the user .
The only differcace will be that a MMI number will be generated by the back-end process and distributed to the manufacturer with their license.
Restricted Mechanical Licenses (35.50) Restricted Mechanical licenses will be available only to the general public, but not to authenticated manufacturers gad publishers.
For the most part, Restricted Mechanical licenses grill be processed in a similar fashion to regular Mechanics! licenses. Even the user interface will be very similar. However, there are some important differences:
1. 'Ihe volume of recordings will be restricted (e.g. :500 or leas) 2. Restricted Mechanical licenses will not be available from the Professional SongFili; site. It will only be available to the general public via the unauthenticated SongFile site.
Further, rsgular mechanical licenses will only be available via the Professional SoagFile site, and not from the tmautheaticattd s The DPD configuration will only be available to authcatxcated manufacturers, not to die general public (i.c. not for 35.50 licenses).

WO (10/42555 PCT/US0~0/00835 Restricted Mechanical Licenses 05.50) NFA offers restricted mechanical licenses to those individuals which want to produce a small volume of mechanical recordings (e.g. 500 or less). These types of licenses will now be handled by the Songl:ile.corn web-application.
Restricted Mechanical licenses will not be available from the Professional SongFile site. It will only be available: to the general public via the unauthenticated SongFile site.
Technically, this is a simple:natter ~of knowing whether or not the current user has authenticated his/herself.
The user will be guided through a series of questions to help determine the type of license that slhe requires,. Then, the user will build a "shopping cart" full of songs by using the existing :~ongFile s<:arch functionality. After a user has filled his/her license shopping cart with songs, and after the information they provide for each song recording has been automatically validated, a confumation page will appear, asking the user to provide their personal' and payment information.
The user's credit card information will tx automatically approved over the web. This typically ttqpires as little as :5-15 seconds, using one of the available payment service providers -discussed below. Upon approval, the user will be immediately notified via a web pogo.
The following Diagram depicts the proposed flow for a user to obtain 35.50 licenses for several songs.
~2 WO OOI42555 PCT/US00/1)0835 public SongFile site. Technically, this is a simple matter of knowing whether or not the current user has authenticated his/herself.
After a user has filled his/her license shopping cart W th songs, and after the information they provide fore each song recording has been autatnatically validated., a confirmation page will appear, asking the user to provide their personal° and payment information.
The user's credit card information will be automatically approved over the web. This typically requires as little as S-I S seconds, using one of the available payment service providers - discussed below. Upon appzoval, the user will be immediately notified via a web page.
The license will be automatically and immediately distributed (via-email) to the user - no back-end processing is required prior to this' Electronic credit card payment must be handled in a secured manner. Therefore, certain web pages, including the credit card form, must be encrypted via secured sockets layer (SSL)~.
6 Typically, the Bank and/or payment service provider offer less expensive transaction fees if the user provides name and address information. The user's e-mail address is also required, so their. license can, be distributed.
' It may be desirable to wait for night-cad settlement of the credit card payment, rather than distn'butia~; the license immediately after credit card approval.
s Note that SSL pages are sent and received on a stparatt TCl'/IP port -usually 443.

License Inquiry This proposed functionality will allow the uscr to view the status of any license request they may h:~ve made in the past (via the Extranet or by traditional methods).
It is proposed that the current static license page be made dynamic, and extended to include a license inquiry section (sketched below as "WHAT LICENSE DO YOU HAVE?"):
WHAT LICENSE DO YOU NEED?
T~ fW by w171rbIt H~~Wn y1N fwl. ~~Ivcmh~ pry d w w1 (olvw thv Ilcfe~Inpslndom ~U:e fn t Movlf or Video ~ ~'-- _-. _ _. ... .. ___.._..___ Uff 1n a Commfrclal rrrrsr a rb~v Urr IM ~onp n r JY alnrmn camxmNJ
~~''''_.... _.__ ~.y... _._-_._. ......_.._ _._._._._ _ ake a Recording rporste~n-House Prlt~ntation . crarNte a wyl r Mrd~A cporr w n r cbaN ~ brwataal. nJauar tnrrnp a r~
or r mi(bn. onpNUt a rrw ~nr~p~m~n trr0~ aAOr a eoAleNan -~_._. __..~.-._. ~.~ _._____.,~_~_-__..._ trform In Pubitc ~Utv on t TV Proprtrrn ~cAOOI rlwn caKM a crdr~r, p4y r Pry wn otf lwrordry a wtwkr r nwr orr, for wr on IY.
n tM backyrovn0 or ~np A an afpe GQr a r~trAltr AalMUOn.
_..___._-_.._-__._______. -.-_...~-__._._.__ w--+
Ut~ fhf Sonp In Fllm Fettlval ~~~r ~1t U1r IM woAr .n r proouct a grrtx, bstnOndr on r Juk~Aoi FnYn to be ll~n rf ~ Idm lrNwrl fvw a ~,dMt gyp( 10 GKh9lWrrd n r IItNtN/w a to carunncNrl rrYror .__.. _. ... ..__. .7-.~.._...-.._.
WHAT~ -LICENSE DO YOIJ HAVE?
T1 /rOlly ylNr ~~VI YOr11111 ~11/ 111~ (1N1 ~1 r11111 y0N IM I~~NIIII~
RfQufstt Ba~N~MD~le Repy~~ Soep~~le Tllfe ~~L StrM
1999.ml11 hL00D9t 1Q95t5 N'PIEPIE D. A1VlId,ACOIIMS VEWMlIG
ONr r~cerb inllwu 11H y~N 1~v~ w~ ~dM Nwn~w (~r Yrr ~~~f.
ueh for Llc~ns~t yeN .hNVw~~~ ko~~ ! 1 1~ 1 t,_ If the user had clicked the "eyeball" to select a song, and clicked on the license logo to get to the above page, then the user's license requests and active licrnves (if any) for that song will be shown.
The user will also have the ability to search for his/her own license roquests and licenses by providing a date range. Since the user has authenticated his/hetself, s/hc will be able to see only his/her own lictnse information. In other words, license information will be secured to Harry Fox fund the licensee.

Rights Matrix The: project scope and proposal document mentions drat:
"Some attempts have been made to produce a matrix, or grid, which will assist people in determining what agency to work with for various types of music righu in various location. For exomple, mechanical licensing in North America is typically the Harry Fox Agency; however, rf you are in brazil, a would be another agency. A static form of the default matrix was cre~rted at 106.191.~16.28/son~le6xlregister.htm. A sample group of questions or a script jar determining the correct path through the Rights Matrix, i.s being supplied by Jeff Okkonen. These questions apply nrore to the default matrix than the publisher or song specifrc rules.
"' The proposed automation of the 'Rights Matrix' concept is made up of two main parts.
~ A set of Rights Determination Q&A will ask the 'user a series of questions -which will dctetmine the rights they are seeking.
~ A Black-box function will take in a list of songs and configurations and, by accessing new and existing database files, will detcrmitte if each tan be [partially] licensed to the user by Harry Fox.
Rights Determination Q 8~ A
Thas part of the system wilt ask the user a set of pre-dcterrnincd multiple-choice questions. The rights the user requires will be based on their answers to the questions.
For example if the user will be producing less than 500 copies, s/he may be eligible for a restricted mechanical license (35.50 license). Otherwise, slhe must authenticate as a manufacturer.
If the user is seeking a license of a type other than mechanical, restricted mcc6anical, or DPD, then it will be requested via the existing web-pages and the existing PDF fonts.
The questions and answers will be database-driven via the following new database:
by Gupay ro ou~som 0y Gtapay r~. G~es~o~J
j_ OueatioN. Type ('.041 6aGaty lief~r11 CISAC tioady EY4:0unVy , WSodetY
God~, CoOe IJOMN Typ~

WO 00142555 PCT/USOtIl0083S
File Description License This Gic will have values such as:
Category Usc in a movie or Video Make a Recording Perform in Public, .

Question This fiic will contain one record for each question within a license category. A display sequence number will be used to order the questions on the form.

Possiblt Since the questions are multiple c'hoicc, this Answer file contains the possible answers available to the user.

Required Required right/licensc for each possible answer.
License (e.g. import license is required for importing records, discs or tapes inta US) Country A simple table of all countries CISAC SocietyA simple table of all CISAC societies Society The particular society / societies that should Referral be referenced when a u:;er requests a specific license type in a specific country Once the user selects a license category~
Vla the WHAT
LICEH9E:

V'OU

~.
existing web-pagev....".r.,~...~................
... ~
_ ....,w..

w. ~ ~., v,... ~
. u,..,.

r.... ...,.", ~.".,...,.,.,...,........, .._...~. ~.~......-r.,...._ ~"..,.

r r.w.
w r.., u.,=
.
na.y..

..............
~..
~

~'.u.-.w ~:..-"~
~

W uwrnlw a~wllnw IwwW..r_........~, -..
... she following steps arc ,~'.,::.~~'.:
""
~",.....

performed:

1. Build the on-line questionnaire form The algorithm is:
Select a!1 records from question file by with License category, order by display sequence Select all possible answers to the current question For example when user selects the "Make a Recording" category, the following questions and possible answers could be ahown How rnany recordings ,f00 copies ar more will you make?

fewer than 500 copies Recordings to be in what~lulti-song album or Maxi format?

:Single recording ~~.crmputer chip ~4fusic box ~Jther mechanical format Recording in what Country?~~Drap-down of countries>

Distributed in what Country?~~Dropdown of countries>

2. Identify required tights based oa user response.
(i.e. for each question, get required rights from rlghu.file using Category ID, Questt'on#, ~tnswe~r#) 3. Check for territory override for required rights.
(i.e. if the country-related answers are non-US, check for society nefetrals) Note that all of the above may require multilingual comatutvcatioa with the user. 'Ibis is yet to be determined, but it should be noted that L,ANSA's architecturrr supports multilingual systrms.

WO 0(1/42555 ~CT/US00/00835 Black-box Function This part of the system will take in a list of songs and configurations and, by accessing new and existing database files, will determine if each can be (partiallyj' licensed to the user by Harry Foa;. At this step in the process, the user has already selected a set of songs and configurations; no further user input is required.
Input to Black-boz function Output from Black-boz function M-number (if user is authenticated Same list of song codes, plus, as a for each song:

manufacturer) License eligbility :flag List of songs codes, plus, Message Codes) (explanatioci) for each song:

Configurations}

Play Time Note that the publisher(s), and other information Statutory Rate flag will be retrieved based on the song codes.

Rights Malysis I Shopp(ng Basket PFLICBLK Orertkl8 PFMLHCOD
~pecific J ~~e in vnprkinp list SPECPAR
Get Pudisher [" .. . . ..
split into P Write NMAST
NO arc hio in list P Write PFMFCPUS n~~ ~S Marx~turer ra , spe~fic h1o z Nr Gsl too wrtle PFMLR86C .~on Y~S
spsdCx h1o !n wwkin0 as!
NO
~rx~ot be Status ~T ~ fa ~ ~9 WO 00/42555 1'CT/US00/00835 The 'following is the supporting database that support the logic depicted above:
File Description ~_ Purpose Namc and Address Namc and address Publisher rcpreaentcd by HFA

(NMAST) Publisher and Song Song override by Determine song; override publisher b;y (PFSNGPUB) publisher Publisher and ManufacturerManufacturer overrideDetermine manufacturer by override (PFhdFCPUB) publisher By publisher Publisher , ManufacturerSong specific overrideDetemvne song; specific and override song (PFLICBLK) ' Publisher and configurationConfiguration overcrideDetermine configuration by override (PFMLRBBC) publisher i Quit Claims Process At some point in the future, publishers who visit the professional search site will be able uo fill in a Quit Claun form to dispute song ownership. Initially, some improvements to the process will be developed, internally, before deploying this function to the web site, Thrs tS described later.
Some information about the current process has been gathered, but is still paper based, arid has not y;t been documented. Harry Fox has not expressed and urgent need to include and automated process for Notice of Claims on the Extranet, so no preliminary design is included in this document.
See the project scope and proposal document for an overview.

WO 00/42555 PCT/US0~0100835 Extranet versus Internet Functions wwv.songfile.com intemet site - available to www.songfile.oom extranet options - must be signed public on Sign on to Extranet --' Regular Song Professional Song Search Search - ._ ___.._ Questionnaire - determine rights and/or appropriate fonnlnext step Account Registration Form I -_--_ Rrghts Duit Claim Forms Matrix and Process - future option :iynchroniZati~x~
35.50 License SIRNET-style and License Reqw~st Request Forth DPDt,jcenslnp Forth, Process (Future phase) i Assumptions T7iis document makes some assumptions, including:
~ HFA will update NMAST file to include country code, email address, and perhaps web URL
~ New Rights matrix black-box function will not use: any of existing RPG
programs, but those F~rogram~s tray be used as references ~ HFA will provide a list of all possible questions for each license category ~ HFA will provide a naming scheme for country codes ~ SIRNET style license requests will update only the licetue request files -not license files ~ There is no S)RI~1ET-style client-side database in this solution - all data resides oa the AS/400 9~

Appendix A: Database Taken from the p~oposallscope dorumenr: Therc arc three primary areas of the HFA database, which. arc:
clients, songs, and licenses. The following Entity Relationship diagram shows some of these files:
.... ..................... Soup PuOlnhor Sony Wata . ' SonpMUter PfSNGPUB _............................_..
PfSNGWTR ~~- ................. ~ py ~ ode.
- by Sony Gode .. .. PFSNGPRM -r..,.... Tm, ~ No 6 Seq no -CY Sonp Code t........_............ .
_.. Sano PuW 2 .............._............. ...... ... ................., , PF NG X
Smp W riser Hdex ~ ' bY Sony Colt. Gtmt NsmelAOdt a~~
RVJTRKWO __....._..._1. ~ . .f.., - bY SOnO Code , ... ._. . -. ..... . - 01' Actf Number Sonp Pereprapn -Sanfl TNt .
Sore TWe hoax PFSNGPAR _......_..
a v. ~
PF N L -DY ~W Code PFSNGKWO ~ by Sang Code by s«,o code a see no ' Name h0ex 5ona Llc Gounf Sang ~ Title NEW
PFSNGLIC . by Acct No F N - bY Sore G~dt ~ bY Sap coat. .-Lieence History Sep not. Sep net PFMLNPRM
~ bY Uo~et No .~.............. _-......._...__..._._......__._.___...._; ~
H,u~e .
_....._....._ ........, M
- ey crt code.
..... . ..... . . ~.H. NOUm Trot and cone i PFMLHAL tx. Hiss Pudef>b~
~ by Uc No.
g~nb fMU1 .._.....__..._._._.._.._.~_.._.___._.._._.__,.....__..-___._.__ Mach L.H. Record ~ by Ua n0. Sp na PFMLHRf ~ tYy Uc No. Seqno i l.H. MN Fle Pf ldtJiART Pubs Sore Gatnl ~ by UcN0. Se4no PFSNOCNT
~ 0y Pubs CoOe Appendix B: SiRNET Screen Prints Taken from the proposallrcope document.

WU 0(1/42555 YCT/US00~00835 ______~_._ _ _~_ _. _~,__~.-_._. -_.___ i ROAD

_ _ 6 !F IT MAKES YOU HAPPY' PRINCE
_ 10 _ F

_ JEWE_L __ _ 12 _HAPPY BIRTHDAY ~ ._ __-___ _ _--_' ~

~4 SLAVE DRIVER __ .
____-BOB

18 AIN'T NO MOUNTAIN HIGH
ENOUG

_ ..__ _..-_.._ _~ ._ _.__ i a r ' ' ~

WO 00/42555 PC'f/(IS00/OO~g35 U. S. Copyright Office CORDS Interface Specification WO 00/42555 P~C'T/US00/00835 HFA Copyright Registration Process When a music publisher wants to submit a copyright application, they will start the HFA, CORDS PA 'Form Applet via the Songfile. (This will just be a link to the applet, which forwards their uxrname and password) If they enter a valid password, they are then able to navigate through the PA
Form and 111 in the information far an individual work.
One of the fields in the form allows them to enter in the file name of their electronic deposit.
Which will Inter be uploaded fxom their local machine.
Once the entire form is filled in, the music publisher is shown a screen with all the data they just filled in. They are asked to verify the correctness of the information before submitting it to ithe HFA Registration Server.
Once the publisher has verified the information, they submit the application to the HFA
Registration Server.
The applct uploads the deposit file and does an http post in order to send the application and deposit to the HFA Server.
The application information is inserted into the HFA database, and the deposit file is saved to .a directory on the xrver. If the application is inserted to the database, and the deposit is received by the server successfully, a "SUCCESS" response, and an MMI t;Multi-Media Identifier) is xnt back to the apples, and the publisher is told that their application has been received by the HFA Registration System, and they are given the MMI, which they can ux to track the status of their application.
Thc~AynB has an application queue table that keeps track of all jobs that are inserted in the database. When a new copyright application is inserted in the database, a record is inserted into this table with the copyright workid and "new", as it's status code.
A scheduled crop job, which runs every 5 minute, checks the application queue table in the HFA DB to xe if there are any "new" jobs to process. l:f there are "new"
copyright applications, the cron job creates application files of the jobs that need to be processed, and creates a CORDS batch file.
-'Thefiatch'file~is~then3ubtnitted to the-CORDS system-using~hc-eflRi~S-submit~rogram:
When the CORDS system has received an application from the HFA Registration System, the correspondeact emaii address will be hfa-email~cnri.reston.va.us. All email cornspandence from CORDS should go to this email address.
If aay etnail correspondence is sent to hfa-email~cnri.reston.va.us from the Copyright iDffice"
it will be processed by the HFA Email Processor that is on the HFA Server. The HFA Registration System tracks all email correspondence. The status of an application is updated in the HFA database every tame the system receives ecnail from CORDS. All emaii is forwarded to an HFA Agent. And all non-administrative email is forwarded to the music publisher.

WO 00142555 I'CTIUS00100835 In the event that a music publisher has to re-submit a copyright application, they will be sent any email message with an HFA Regisaation Erie attached to the email and instructions explainiing what needs to be done to resubmit the application. They will then have to start the HF,A CORD~~ PA Form Applet. Once the applet has started, they will be able to open the attachment so tJvey can modify the information, and re-submit the application t.o the HFA Registration System, which wilt then re-submit the application to the Copyright Office.

WO 00/42555 PC'T/US00/0(1835 CORDS XMUDTD
Content Model Diagrams Draft 11122199 CORDSSubmission.dtd (1/3) ~o«~".
[~' iraafNC~
~,~~~
3lbn~ioil p WO 00/4555 lPC'T/LJS00/00835 CORDSSubmission.dtd (2/3) -C~~
r ItoB ik~
DastDueh~
r'fla _,~~ :. .

WO 00/4?555 PCT/US00/00835 CORDSSubmission (3/3) ~.tw .
ca"~n,, .
s~c«~o~ 0 . c«eHo.~
c«.oa~.

WO 00/42555 POT/US00/(10835 Transrr~issionACK.dtd w~,obolWt~fo _.
rrens~is~onAcli . ~~..
,y,__ _ ~ ~f~,rtlWbnoro -'~'I
.. _.4.~ode WO 00/4: 555 PCT/US00/00835 CORDSResponce.dtd _.,~oo,~,tr,p ..E-e.
TW bde Cectl~
CerafiateGete , ~a~a . ~e~CCde~
v~
... . , .
~J

Claims (30)

We claim:

1. A computerized system for automatically determining and generating an appropriate license request for a work, comprising:
a works database containing information about at least one work, including a unique work identifier and at least one licensing source for granting a license right in at least one territory associated with said work;
a user search form accessible by a remote user for querying said works database and identifying said work identifier for said work to be licensed by said remote user for a particular use;
a rights determination form accessible by said remote user for determining said license right necessary for said particular use of said work in said territory;
means for locating said work identifier, said license right and said territory in said works database and determining said licensing source;
means for generating a license request for said license right for said particular use of said work in said territory by said remote user; and means for transmitting said license request to said licensing source.

2. The computerized system of claim 1, further comprising means for adding a new work to said works database accessible by a remote publisher.

3. The computerized system of claim 2, wherein said means for adding a new work to said works database includes means for generating a batch file for adding;
multiple new works to said works database in a single process.

4. The computerized system of claim 2, wherein at least one of said remote user and said remote publisher accesses said works database over the Internet.

5. The computerized system of claim 2, further comprising a publisher update form accessible by said remote publisher for editing said works database.

6. The computerized system of claim 1, further comprising means for transmitting said information about said work for registration with at least one of a works registry, a rights agency, a royalty collecting society and a national copyright office.

7. The computerized system of claim 6, wherein said works registry is the International Common Works Database (CIS), said rights agency is the Harry Fox Agency, said royalty collecting society is ASCAP or BMI and said national copyright office is the United States Copyright Office.

8. The computerized system of claim 1, wherein said license right is at least one of copying rights, mechanical rights, synchronization rights, distribution rights, performance rights, master recording rights, print rights, broadcast rights and display rights.

9. The computerized system of claim 1, wherein said particular use of said work is at least one of a CD compilation, a revue and an Internet distribution website.

10. The computerized system of claim 1, further comprising means for archiving a digital representation of said work.

11. The computerized system of claim 10, wherein said digital representation satisfies a deposit requirement associated with registering said work with a national copyright office.

12. The computerized system of claim 10, wherein said digital representation is one of an MP3 file, a MIDI file, a PDF file, a GIF file, a JPEG file and a PostScript file.

13. The computerized system of claim 1, wherein said means, for transmitting said license request includes means for generating a structured email message addressed to said licensing source.

14. The computerized system of claim 1, wherein said works database further contains at least one of bibliographic information, a discography, lyrics, an arrangement score, photographic exposure conditions, camera equipment used, a thumbnail representation and an electronic sample associated with said work.

15. The computerized system of claim 1, further comprising means for logging and tracking the results of said license request, wherein said results of said license request are accessible by at least one of said remote user and said licensing source.

16. A computerized method for automatically determining and generating an appropriate license request for a work, comprising the steps of:

providing a works database containing information about at least one work, including a unique work identifier and at least one licensing source for granting a license right in a territory associated with said work;
identifying said work identifier for said work to be licensed by a remote user for a particular use by said remote user accessing a user search form for querying said works database;
determining said license right necessary for said particular use of said work in said territory by said remote user accessing a rights determination form;
locating said work identifier, said license right and said territory in said works database and determining said licensing source;
generating a license request for said license right for said particular use of said work in said territory by said remote user; and transmitting said license request to said licensing source.

17. The computerized method of claim 16, further comprising the step of allowing a remote publisher to access said works database and add a new work thereto.

18. The computerized method of claim 17, wherein said step of adding a new work to said works database includes generating a batch file for adding multiple new works to said works database in a single process.

19. The computerized method of claim 17, wherein at least one of said remote user and said remote publisher accesses said works database over the Internet.

20. The computerized method of claim 17, further comprising the step of allowing said remote publisher to access a publisher update form for editing said works database.

21. The computerized method of claim 16, further comprising the step of transmitting said information about said work for registration with at least one of a works registry, a rights agency, a royalty collecting society and a national copyright office.

22. The computerized method of claim 21, wherein said works registry is the International Common Works Database (CIS), said rights agency is the Harry Fox Agency, said royalty collecting society is ASCAP or BMI and said national copyright office is the United States Copyright Office.

23. The computerized method of claim 16, wherein said license right is at least one of copying rights, mechanical rights, synchronization rights, distribution rights, performance rights, master recording rights, print rights, broadcast rights and display rights.

24. The computerized method of claim 16, wherein said particular use of said work is at least one of a CD compilation, a revue and an Internet distribution website.

25. The computerized method of claim 16, further comprising the step of archiving a digital representation of said work.

26. The computerized method of claim 25, wherein said digital representation satisfies a deposit requirement associated with registering said work with a national copyright office.

27. The computerized method of claim 25, wherein said digital representation is one of an MP3 file, a MIDI file, a PDF file, a GIF file, a JPEG file and a PostScript file.

28. The computerized method of claim 16, wherein said step of transmitting said license request includes generating a structured email message addressed to said licensing source.

29. The computerized method of claim 16, wherein said works database further contains at least one of bibliographic information, a discography, lyrics, an arrangement score, photographic exposure conditions, camera equipment used, a thumbnail representation and an electronic sample associated with said work;

30. The computerized method of claim16, further comprising the step of logging and tracking the results of said license request, and wherein said results of said license request are accessible by at least one of said remote user and said licensing source.