METHOD AND SYSTEM FOR REGISTERING AND LICENSING WORKS OVER A NETWORK

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 (143-148) 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/115,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 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 mvention, 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 Japan or the UK. 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 to 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 117. 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 125 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 128 or the show or movie in which the 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 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 100, the license request can be sent to the licensing 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 Office, 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 may 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 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. 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 100 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 revue, 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). 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 system. 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 indicated. 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 feamres of the invention herein described and all statements of the scope of the invention which, as a matter of language, might be said to fall therebetween. APPENDIX 1 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 I. 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 last 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. Online 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, GEM A, 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 signamre 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 foil. UID UserlD LIO Licensee Organization LSTR Licensee Street LCI Licensee City LSTA Licensee 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: Table: Uses and Rights I em t Data R ' ft- New Recording Y/N R X OπgArtist T R OπgAlbum T R OπgLabel T R Whole Y/N R Modification Y/N R Play Minutes N If Portion Play Seconds N If Portion NewTitle T If New Recording X NewArtist T If New Recording X NewLabel T If New Recording X ISRC T X Import? Y/N X Import Copies N If Import? X Record Date T X Record Mfg Code R X Record Dist Code R X Record World Y/N X Record US Y/N X Record Canada Y/N X (etc.) First Printing Songs in Book T Book Mfg Code Book World Y/N Book US Y/N Book Canada Y/N Book UK Y/N Book Euro Y/N Book USSR Y/N Book ME Y/N Book Africa Y/N Pert Producer T R Perf Date T Pert Location Code R Audience Admission Y/N R Church School Y/N Establishment T 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: World Y/N US Y/N Canada Y/N UK Y/N BritTerr Y/N Specified Code MechRights SynchRights DigitalRights PrintRights Perf Rights GrandRights 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 old pub code AS400 code old catalog AS400 code Account ID Who can maintain the data Last modified Modified by UserlD (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 look 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. 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. Sub j : 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. Y/N 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 mailolocalhost) 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$lb0d40a0$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; oundary=" =_NextPart_000_000C_01BE3A5A.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: 82de0flf39715704403c38012025459 The following request for rights has been forwarded to you from the IBLS Service. Please respond directly to the requestor. Request Number: N Date/Time: N UserlD: 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 Otherlnfo: 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- - APPENDIX 2 Search Specification Web Search Design Specification Search for prerecorded media (i.e. CDs and Tapes) and sheet music Summary This document describes a system that will leverage the Intemet, existing HFA data, and partner όaψ to create a consumer-oriented business for the HFA This system, which is part one of several phases, will allow Intemet 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 Intemet. This will require data collection from the HFA's existing AS/400 based systems. This document includes 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 staf 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 described in sufficient detail to allow for analysis by others and act as a road map for detailed specification development. Although the first release of this site will not be feature rich media the design presented here will 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 created to facilitate the initial site creation within this critical business requirement. Provided functionality by page These song-search features of the HFA Web site 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 recorded ■ 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 "[All fields]": [All fields] Title Writer Album title Artist Label Publisher TV-show" Piuduci Maiiufkctuier Mβ&en-picSfe 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 Recent release check box lets the user find only songs released in the last N months. Search The Search button 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 terms 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. Song search results list The search results list lets the user identify among the songs that match the search criteria the one they were hoping to find by showing for each matching song its category, writers, publisher and all the recordings on which that song appears. It also lets the user buy sheet music for that song or any of the its recordings. Title The song's title will be linked to the Song detail page for that song. Category Writer(s) The song's writers will be listed in a single field. Publisher 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 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 performe 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. atøe 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 fil Song detail page The Song Detail page lists all the information available about a given song: Title Category Writer(s) 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 linked 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. Aibum 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. Label 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 fil Movies A table will list all the movies in which the Bong appears, with these columns: Name The name of the movie will be linked td\^earch results page that shows all the songs that appeared in that movie. Opening date Length Buy movie A movie icon will be linked directly to a page at a safes partner's site that will let the user purchase the movie on tape, videodisc, or DND. TV shows A table will list all the TN shows in hich the song appears, with these columns: Name of show The name of the show will be linked to a Search results page that shows all the songs that appeared in that show. Producer Commercials A table will list all the commercial^ in which the song appears, with-t ese 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: 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 Song publisher TN 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' SonglD. 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, TNShow, 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.PreferredTitlelD field back to the Title.TitlelD 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. 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 SonglD. 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 SonglD and inferred RecordinglD. 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 • Commercial.Manufacturer • Commercial.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 SonglD match. The resulting song record will be joined with the Title table to obtain the songs proper title. The Song ID will then be sought in the TVShow, MotionPicture and Commercial tables and the resulting records will be included i the output. The SonglD will then be sought in the Recording table. Each resulting record will join Recording.TitlelD with Title.TitlelD to obtain the proper recording title. This information will be added to the output. Additionally the RecordinglD will be sought in the TVShow, MotionPicture and Commercial tables and the resulting records will be added to the output. Side effects None. 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 RecordinglD and a single integer value corresponding to a bit in the Recording.PlayableMediaAvailable field. Output HTML redirection page providing access to an Intemet 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 RecordinglD match. The resulting recording record and playable media format code will be joined with the PlayableMedi 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. 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 searched for the provided song 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 attem to be joined. A successful join will indicate the correct record in the Recording table to update with the JW provided availability information. The successful update will be logged as "Successful Updat 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 an m t number o t mes an ad s renewe 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 "cron" 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 Client 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 from the POLI system to harvest usemames 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 BY ALBUM HIT LIST 7 SEARCH BY COMPOSER HIT LIST 7 SEARCH ALGORITHM 8 DESCRIPTION OF SEARCH METHODS 8 Exact Match 8 Ordered Word Match 8 AND of Search Words 9 OR of Search Words 9 Phonetic Search 9 Partial Phrase / Generic Search 10 Wildcard Search 10 How WILL SEARCH METHODS BE COMBINED? 11 User Search Options II System Search Options 12 SUPPORTING DATABASE 13 Scope This document overviews the interface requirements and search algorithm of the phase 1 deliverables 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 LANSA. To aid m their efforts, the following land-marking of the search-related section of the web-page is proposed 1 : Search Interface, and sample flow 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 1 : • 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 120 character user-provided string) However, for each search method, the resulting "hit list" will contain different columns. Search by Song Hit List CD JW Song Title Artist Albu # Times ASCAP Active U iv Pepper with link to Recorded Flag Icon icon Recording with with Details page link link if multiple artists exist The CD Universe lCOn will have a link to the CD Universe partner site. The actual URL used will be of the format: httρ://cdu2.cduniverse.com/asp/howmanvartists.asp?search=<artistname> 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 database 2 . 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 & FIRE", etc etc. Also note that the existing HFA Artist database combines artist names in different ways when they collaborated on a song. For example: "MICHAEL JACKSON AND DIANA ROSS" collaborated on a song HOLLY COLE, BRYAN ADAMS collaborated on a song DIANA ROSS & LUCIANO PAVORATI collaborated on a song 1 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. The Sheet mUSiC ICOn will have a link to the JW 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 Details 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: 3 Title Composer Artist Album Genre Release Date Play time A list of other artists who have recorded this song (Artist Name, Album Title, Release Date) None of this information will have underlying links. The #TimeS Recorded column will indicate the number of times the song was recorded. 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 AS CAP column will indicate whether at least one publisher of the song is affiliated to ASCAP. The BMI column will indicate whether at least one publisher of the song is affiliated to BMI. The Active Flag column will indicate whether royalties have been paid on this song in the last 3 years. Search by Artist Hit List The CD Universe lCOn will be the same as in the By Song Hit List. No other columns of information will have underlying links. 3 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. If the existing HFA database supports it, the # AlbUtTlS and the # SongS will show the number of albums and songs recorded by this artist. Search by Album Hit List CD Universe Album Name Artist .F-F-TTOtl Icon with link The CD Universe ICOn 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 # Son S will show the number of songs / tracks on this album. Search by Composer Hit List Composer g;*YP77-n Name If the existing HFA database supports it, the # SθnQS will show the number of songs written by 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 4 word of the 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 1 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. 4 Significant words are those not listed in the "Insignificant Word File" (e.g. the, in, a, to, ...) 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 ("VOYAGE") 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 number 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 Words 5 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 search 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 (50%) There's no cure like travel, Bon Voyage (50%) 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 Phonetic-like code will be generated for each of its words. This code will be used as search keys, and used in 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" will be converted as L550, 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 / Generic Search Using LANSA *Generic Select, this method would use the search string as a beginning characters. For example, if the user's song search string is "Everg", then songs beginning with these characters would be considered matches, including: "Evergreen", "Everglades of Florida", etc. Wildcard Search 6 Using SQL and/or OPNQRYF, this method would be used only as a last resort, in the event that the 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 treated as patterns, and songs with 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. 1 For performance reasons, this method may not be developed. How will Search Methods be combined? The above search methods will be developed as function modules, allowing them to be used in any permutation. The goal is to have a search engine that can be customized without having to re-code nor recompile anything. Customizing the search engine, will be done in two ways: by the user, by a system administration function. User Search Options The user will have the ability to customize the search. S he may choose any one of : User Search Option Description Module(s) performed Intelligent Default This is the default search method. It is described in the As configured by next section. the system administration function below Exact Match If, for example, the user is confident that s he knows the Exact Match full title of a song, s/he might choose this search method. It will result in the fastest possible performance. All Words By choosing this option, the user is indicating that Exact Match, matching songs are those with all words matching. then Ordered, then And Any Word By choosing this option, the user is indicating that Exact Match, matching songs are those with any of the words matching. then Or Partial Phrase This option allows the user to type in a partial phrase. It Exact Match, will be used as a generic key. For example, a search string then Generic of "Evergr" would match with "Evergreen, Everglade, ..." In addition, the user may click or de-click the check-box of Phonetic Similarity. This options works with the And and Or searches. System Search Options The system administrator has control over many different parameters of the search algorithm. The 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" BlMliiilMhiΛ -ra-JW.-./-I¥-WftJa Availability of User Ordered table of User options to be included on the search Intelligent Dft -1 Options in Dropdown page. Exact Match - 2 All Words - 3 Any Words - 0 Partial Phrase - 4 Availability of Phonetic A system variable which controls whether the Phonetic 1 = Enabled Similarity Similarity Checkbox appears on the user's search options. 0 = Disabled Insignificant Word List 7 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 25 matches. Alternatively, it may be 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 be shown. Plus, links to all 9 other pages will be available to the user. Intelligent Default Table of all search methods, and the sequence in which Exact Match - 1 Search Method they should be employed, if at all when the user chooses Ordered - 2 the Intelligent Default Search Method AND - 3 Phonetic - 5 OR - 0* Wildcard - 0 Continue Flag Part of the Table of Intelligent Default search methods, this Exact Match - N flag would indicate whether or not the search should Ordered - N continue, even after a method results in 1 or more hits. AND - N Match Percent A match below such a percentage would not be 20% minimum considered. This could be used with the OR method, and possibly with the Phonetic method. Minimum Ordered Used by the ordered Word method as the minimum Words number of words to be used. (i.e. n, n-1, ... , MiniumOrderedWords) Maximum Ordered Used by the ordered Word method as the maximum Words number of words to be used. (i.e. Maximum Words, Maximum Words -1, ... ) 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 "THE THE" would pose a problem if "THE" were in the insignificant word list. 8 A sequence of 0 would disable that particular search method. 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 be required for composer, album, and artist. WUMMMMΛ ^m,h»Λ Song Title Keyed by complete 9 upper case title Exact match (α logical file over PFSNGTTL?) Wildcard search Ordered Song Keywords The first n significant words will be stored as uppercase Ordered Word keys in the file. Match (A logical file over For example, title "There's no cure like travel, Bon PFSNGKWD?) Voyage" would have 1 record, including the song identifier, plus: Keyl = THERE Key2 = NO Key3 = CURE Key4 = LIKE, etc. Song Keyword list This file would contain all significant words of each AND search song's title. Included would be the song identifier, plus the upper case OR search 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. THERE T600 123456 NO N000 123456 CURE C600 123456, etc. Data Dictionary This file would contain one record for every (significant) AND Search unique word in all the song titles in the database. It would be keyed by the upper case word, and would also Phonetic Search have a field to contain a title count. It may also be desirable to include the phonetic code. ' For the exact match search, even insignificant words will be retained. APPENDIX 3 License Rights Determination Specification Agency Extranet Functional Specification Section 1: Functional Overview 1.1 Business Operations Existing systems support three business functions related to the licensing of rights for music. Three discrete departments within the HFA execute these business functions. Index: The index department maintains data files that support licensing activities. These files include records for the song titles that the HFA licenses and records for publishers (The HFA's clients) and licensees. Synchronization: The Synchronization department licenses rights to music for use with motion pictures, television, or other applications where music is used in conjunction with moving images. Mechanical: The Mechanical department licenses rights to music for use on records, tapes, CDs, and other applications where the music is recorded on physical media including music boxes and musical greeting cards. This project's goal is to externalize three major functions of the current work flow: egotiation Handholding: The Negotiation Space, or Deal Space, will enable users 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 fee if the deal is not struck. Some clients only approach the HFA to finalize the license after an agreement is reached, and then HFA collects a fee. The Deal Space should help more licensing processes reach the HFA only when an agreement is made. Conflict Resolution: A lot of license processing is put on hold when conflicts arise. These conflicts stem from ownership conflicts, etc. The conflict resolution process, unlike the negotiation space, is primarily an HFA hands-on faculty, much like a trouble-ticket program, where histories and cases can be traced back in time. This will be a fellow traveler to much of the Index maintenance functionality. 1.2 Application Overview The two main application processes in this system are the fulfillment of valid license requests and the maintenance of Index records. Note that Negotiation Handholding and Conflict Resolution processes arent explicitly broken out below. While Negotiations and Conflicts are significant processes, within this system, they are triggered events within the following processes. Therefore, more detail on Negotiations and Conflicts will be given in Section Two of this document. Fulfill Valid License Requests 1) Completed License Request is received. HFA determines if the request pertains to a song HFA can license. Otherwise reject Request. 2) Shepherd negotiation process. Transmit quotes and offers between the song publisher and producer (License Requestor). 3) 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 conflict may be resolved. 4) If there are no exceptions or conflicts, the additions or changes are committed to the Index. Section 2: Function Inventory 2.1 Main Extranet Functions Processing and Fulfilling Requests for Sync and Mech Licenses of This system will related a can be software- b d f i i i i d ti Online Forms ■ Search SongFile for Songs to License: this may be handled externally to this system n the SongFile website). Synchronization License Request form _ l l.^k . -.:-.-, i :-,-.---.-» r. --.-..-.—- .-. Validation and Routing ■ Direct non-registered Requestors (Manufacturers and Producers) to New Account Application process ■ 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 the song, a "Do Not Represent" or DNR form is sent to the Requestor, most likely a Producer. ■ 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. ■ Store record of negotiated price quotes ■ Generate License for negotiated License Request ■ Deliver License for negotiated License Request Processing Updates and Additions to Account and Song Records The system will include data entry fonms supported by software-based form-field validation. Adding New Account Records ■ Get request online ■ Send packet or online packet ■ Assign M or AT Number Adding New Song Records Functionality to add new song records will be implemented in two ways: single record entry mode and batch (multiple record) entry mode. Single record entry mode is implemented as an online form with software validation of form-field data. Batch entry mode is implemented as an upload of a document formatted according to pre-defined rules. New records will be queued for review by a human administrator. Therefore, the system will include a display screen for administrators that facilitates reviewing and editing queued records. ■ Online form for each record or batch mode upload ■ Drop in without checking for conflicts ■ Queue for human review ■ Commit new records with date/time stamp Update/Change Account Records ■ Compare updated data with old data and look for conflicts ■ Update records and log changes if no conflicts exist ■ If conflicts exist, freeze record and send to conflict resolution system Update/Change Song Records ■ Compare updated data with old data and look for conflicts ■ Update records and log changes if no conflicts exist ■ If conflicts exist, freeze record and send to conflict resolution system Facilitating Resolution of Data Conflicts The system will provide functionality to support conflict-resolution processes triggered by certain Index department tasks. An example case in which conflict-resolution processes are triggered: A Check Claims procedure identifies a piece of disputed information. Data pertaining to such conflicts must be appropriately flagged within pertinent databases. This data may be "frozen" pending resolution of the corresponding conflict Such conflicts may be discovered automatically by software, or resolved manually by personnel. In both cases, the system facilitates resolution by personnel with display screens that consolidate 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, and data entered in by personnel responsible for handling such conflicts. One example of an automatically discovered conflict is when the total ownership of a song exceeds 100%. Package and tag data pertaining to conflict ■ Online form combined with data automatically pulled upon discovery of conflict. For easy retrieval and reference by parties to conflict. Packaged data includes: ■ Date time of conflict generation ■ Identifier code for item in dispute (Song Index code or Account Index code) ■ Ownership data ■ Nature of conflict ■ Parties to conflict' personnel dealing with conflict will log in and out of system so ■ Status & 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. Licensing 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 documents 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 hart-copy 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 screens will be comprised of: ■ Contact information for all pertinent parties ■ Status & Date of last status change ■ License Request data ■ General Notes: much like a log of an online 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 contracts may be printed out at the user's discretion. This will eliminate the need to print and deliver hard-copy drafts of contracts to involved parties during the negotiation process. Upload document Online editing of document Version Control of edited documents, including tracking of changes made and by whom Download of document (so that it can be printed) Objectives This design document is based on several interviews and meetings at the Harry Fox Agency. The objectives, as laid out in the Project Scope document, which are addressed and designed in this document are: 1. Enhance Songfilc.com to provide a professional search for authorized users 2. Interactive Q&A for Rights determination 3. Automation of Rights Matrix logic for determining correct processing for license requests 4. Extend Professional extranet functions to include SIRNET style license requesting for both large volume mech and DPD licensing 5. Process 35.50 licenses, including payment, over the intemet Professional Song Search The Songfile.com search engine which is live on the internet, provides searches via song, writer, album and artist over the HFA song and license database. The results from the search shows consumer information about the song (or whatever was searched over), including links to partner sites for CD's, sheet music, audio clips, and lyrics. HFA would like to extend this search, for use by authorized users of the professional area of the site, to allow music professionals to also find information on the owner/music publisher for a particular song. Additionally, this will feed into a SIRNET style licensing request form for manufacturers. Generation ofUserids All publishers and manufacturers that Haπy Fox deals with are to be given User Names and Passwords for authenticated access to SongFile's Professional Search, and related functionality. The Name and Address file (NMAST) contains entries for all such publishers and manufacturers. A subset of manufacturers are registered SIRNET users, For these, additional information is available in the SIRNET file "SIRUSERS": Some SIRNET manufacturers are registered as "Multi-manufacturers". This means that they have a unique, but dummy M-number - and the ability to act on behalf of several other manufacturers. The relationships between multi-manufacturers and their "child" manufacturers is maintained in file "PFMLCHM": 1 HFA will make the necessary modifications to their systems and procedures to collect, store and maintain this new information-. Based on the NMAST and SIRUSERS files, a LANSA function will be developed to generate User Names and Passwords as follows: 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 be 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 instructions 2 • Usemame & Password for authentication • An imbedded URL to take the user directly into the ExtraNet portion ofSongFile.com If Harry Fox has no e-mail address in its database, users will be notified via snail mail. Sign-on to Professional Search There will likely be several entry points into the ExtraNet portion of SongFile.com: • imbedded 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 ExtraNet via any of the above, s/he will be asked to authenticate his/herself. In addition, a link to the Online Account Registration Form will be accessible, for users who are not valid users but wish to apply to be a manufacturer with HFA. 2 HFA will provide this content 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 web-site) will be provided on the Intemet. 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. Extend Search Capabilities The professional search will extend the search capabilities of the Intemet songfile.com site by allowing two search criteria. The search options on songfile.com will 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 search criteria, then the search engine will do an AND search - which means the results must match both criteria. Technically, this will be achieved by leveraging the existing Search functionality developed for SongFile.com. 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. then s/he will get results such as: APPLE BEAST (BMI) THE OEKΠSTS MH1K0TH POOR I EEP OHE 806 COl-UNS. RCft L UNIVERSE 6R1GS. APPLE PIE f Add-tjoml Recordinot- WHΓTE TRASH WHITE TRASH 0. AIV-K. A. CO-JUHS However, the Song Code and Publisher Split will also appear in the results, as described in the Extended Hit List section below. Note that the first search will determine the type of results to be displayed. In the above case, songs are displayed because the first 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 title SongFile site will offer the user the abihty to bypass this limit. If this is offered in the SongFile site, it will be included in the Professional Search as well. Extend Hit List The search results list for songs must be extended to include the Song Code and the Publisher name(s). If ownership/publishing rights to a song are shared by several publishers, all publishers will be shown, along with their %splits. To show the publisher splits for a given song, the following algorithm will be used. Select all records in PFSNGPUB with the current song code IfSGPBSL > 0, use the SGPBNO to fetch from NAMAST (this publisher has some ownership of the song) IfNACODA <> W (HFA represents this publisher -perhaps highlight that for the user) Each publisher name will be a link to a publisher detail page - descnbed below. Publisher Detail Page A new web page 3 will be designed which shows, for a selected publisher, its contact information, and 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 mclude this information as well, if desired. Professional Search Extended Functionality After the professional search engine has been set up in a secured extranet environment for manufacturers and publishers, the ultimate goal will be to allow users to enter license requests and Notice of Claims forms. License Requests There are 3 main types of licenses to be addressed by the web-application: • Mechanical Licenses • Restricted Mechanical Licenses (a.k.a 35.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 to the general public, and not to authenticated publishers. After authenticating, a manufacturer can click on the license icon in the upper frame. Then s/he will be guided through a series of Questions to help determine the type of license that s he requires. Then, the user will build a "shopping cart" full of songs by using the professional search functionality 4 . Then, a separate license is required for each song, the user can specify information with each song being requested. 1 It may be desirable to have this information appear in a window, rather than replacing the current web- page. This is to be determined. It may be required for a blank mechanical license request form to be provided in the event that • song is not available in SongFile.com. The following Diagram depicts the proposed flow for an authenticated user to obtain regular mechanical licenses for several songs. After a mechanical license request has been roughly validated by the application (e.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 existing license request files will be updated for each license request: If the information is not already available, it is recommended that the SIRNET license request files be updated to include a ''source of license request" flag. This would allow Harry Fox to distinguish between a request originating from the Extranet versus one received by the SIRNET client-server application. It is further recommended that a new status flag value of "incomplete" be used to indicate that a license request is still in the control of the user, and should not yet be processed by Harry Fox. This is analogous to the license requests in SIRNET that have not yet been transmitted / uploaded to Harry Fox. In the current SIRNET solution, such license requests sit in their client-database. There is no such client-side database in this solution. DPD Licenses DPD, or Digital Phono Download, licenses are for digitized music files that can be passed around and downloaded via the Intemet (or via computer media like diskettes). The process of granting a DPD license will be the same as the above mechanical license process; DPD is simply one of many different configurations (CD, Cassette, LP, ...) available to the user. The only difference 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 and publishers. For the most part, Restricted Mechanical licenses will be processed in a similar fashion to regular Mechanical licenses. Even the user interface will be very similar. However, there are some important differences: 1. The volume of recordings will be restricted (e.g. 500 or less) 2. 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. Further, regular mechanical licenses will only be available via the Professional SongFile site, and not from the unauthenticated 5 The DPD configuration will only be available to authenticated manufacturers, not to die general public (i.e. not for 35.50 licenses). Restricted Mechanical Licenses (35.50) HFA 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 Songfile.com 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 imauthenticated SongFile site. Technically, this is a simple matter 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 s he requires. Then, the user will build a "shopping cart" full of songs by using the existing SongFile search functionality 4 . 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 confirmation page will appear, asking the user to provide their personal 5 and payment information. The user's credit card information will be automatically approved over the web. This typically requires 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 page. The following Diagram depicts the proposed flow for a user to obtain 35.50 licenses for several songs. public SongFile site. Technically, this is a simple matter of knowing whether or not the current user has authenticated his/herself 3 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 confirmation page will appear, asking the user to provide their personal 6 and payment information. 4 The user's credit card information will be automatically approved over the web This typically requires 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 page. 5 The license will be automatically and immediately distributed (via-email) to the user - no back-end processing is required prior to this 7 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)*. * 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. 7 It may be desirable to wait for night-end settlement of the credit card payment, rather than distributing the license immediately after credit card approval. 1 Note that SSL pages are sent and received on a separate TCP/IP port - usually 443. License inquiry This proposed functionality will allow the user to view the status of any license request they may have 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?"): If the user had clicked the "eyeball" to select a song, and chcked on the Ucense logo to get to the above page, then the user's license requests and active licenses (if any) for that song will be shown. The user will also have the ability to search for his/her own Ucense requests and Ucenses by providing a date range. Since the user has authenticated his/herself, s/he will be able to see only his/her own Ucense information. In other words, license information will be secured to Harry Fox and the Ucensee. Rights Matrix The project scope and proposal document mentions that: "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 rights in various locations. For example, mechanical licensing in North America is typically the Harry Fox Agency; however, if you are in Brazil, it would be another agency. A static form of the default matrix was created at 206.192.216.28fsongfile6xJregister.htm. A sample group of questions or a script for determining the correct path through the Rights Matrix, is being supplied by Jeff Okkonen. These questions apply more to the default matrix than the publisher or song specific 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 determine 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 determine if each can be [partially] licensed to the user by Harry Fox. Rights Determination Q & A This part of the system will ask the user a set of pre-determined 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, s/he must authenticate as a manufacturer. If the user is seeking a license of a type other than mechanical, restricted mechanical, or DPD, then it wiU be requested via the existing web-pages and the existing PDF forms. The questions and answers will be database-driven via the following new database: Once the user selects a license category via the existing web-page ... ... the following steps are performed: 1. Build the on-line questionnaire form The algorithm is: Select all 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 foUowing questions and possible answers could be shown: How many recordings will you make? 500 copies or more fewer than 500 copies Recordings to be in what format? Multi-song album orMaxi Single recording Computer chip Music box Other mechanical format Recording in what Country? <Drop-down ofcountries> Distributed in what Country? <Drop-down ofcountries> 2. Identify required rights based on user response. (i.e. for each question, get required rights from rights file using Category ID, Question^, Answer#) 3. Check for territory override for required rights. (i.e. if the country-related answers are non-US, check for society referrals) Note that all of the above may require multilingual communication with the user. This is yet to be determined, but it should be noted that LANSA's architecture supports multilingual systems. 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 [partially] licensed to the user by Harry Fox. At this step in the process, the user has already selected a set of songs and configurations; no further user mput is required. Rights Analysis -B-rt- of lo ftigs in Shopping Basket > PFLICBLK PFMLHCOD SPECPAR NMAST PF FCPUB PFMU BBC The following is the supporting database that support the logic depicted above: Quit Claims Process At some point in the future, publishers who visit the professional search site will be able to fill in a Quit Claim form to dispute song ownership. Initially, some improvements to the process will be developed, internally, before deploying this function to the web site. This is described later. Some information about the current process has been gathered, but is still paper based, and has not yet 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. Extranet versus Internet Functions www.songfile.com intemet site - available to " / w.ww.songfile.com extranet options - must be signed Assumpϋons This document makes some assumptions, including: • HFA will update NMAST file to include country code, email address, and periiaps web URL • New Rights matrix black-box fimction will not use any of existing RPG programs, but those programs may 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 Ucense request files - not license files • There is no SIRNET-style client-side database in this solution - all data resides on the AS/400 Appendix A: Database Taken from the proposal/scope document There are three primary areas of the HFA database, which arc. clients, songs, and licenses. The following Entity Relationship diagram shows some of these files- A-tt- Appendix B: SIRNET Screen Prints Taken from the proposal/scope document: 102 103 105 108 APPENDIX 4 U.S. Copyright Office CORDS Interface Specification 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 username and password) If they enter a valid password, they are then able to navigate through the PA Form and fill in the information for an individual work. One of the fields in the form allows them to enter in the file name of their electronic deposit. Which will later be uploaded from 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 the HFA Registration Server. Once the publisher has verified the information, they submit the application to the HFA Registration Server. The applet 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 die server. If the application is inserted to the database, and the deposit is received by the server successfully, a "SUCCESS" response, and an MMI (Multi-Media Identifier) is sent back to the applet, 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 use to track the status of their application. The HFA B 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 cron job, which runs every 5 minute, checks the application queue table in the HFA DB to see if there are any "new" jobs to process. If there are "new" copyright applications, the cron job creates application files of die jobs that need to be processed, and creates a CORDS batch file. _ The " batch"file ~ ts"then " ϊubπ-itted tothe-CORDS system tismg-me-^RBS- submit rogram.- When the CORDS system has received an application from the HFA Registration System, the correspondence email address will be hfa-email@cnri.reston.va.us. All email correspondence from CORDS should go to this email address. If any email correspondence is sent to hfa-email@cnri.reston.va.us from the Copyright Office, it will be processed by die 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 time the system receives email from CORDS. All email is forwarded to an HFA Agent. And all non-administrative email is forwarded to the music publisher. In the event that a music publisher has to re-submit a copyright application, they will be sent an email message with an HFA Registration file attached to the email and instructions explaining what needs to be done to resubmit the application. They will then have to start the HFA CORDS PA Form Applet. Once the applet has started, they will be able to open the attachment so they can modify the information, and re-submit the application to the HFA Registration System, which will then re-submit the application to the Copyright Office. CORDS XMUDTD Content Model Diagrams Draft 11/22/99 CORDSSubmission.dtd (1/3) CORDSSubmission.dtd (2/3) CORDSSubmission (3/3) TransmissionACK.dtd . WbrMnProyessNo * " AccoϋfiNo η AckDβte AcKStatm *1 tr awnfes-iytAck " yj — ' St- tto-o-TP -* 'PuttVorkNo *| yVbrte+ ' j j— j~~ Wori-StetuQ TestModβ * Lf TransTimeSfaBnp CORDSResponce.dtd

Claims: CLAIMS 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 claim 16, 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.

Inventors: BURNS CHRISTOPHER, MURPHY EDWARD P, BURNS, CHRISTOPHER, MURPHY, EDWARD, P.
Applicants: HARRY FOX AGENCY INC, THE HARRY FOX AGENCY, INC.
Application year: 2000
Main classification: G06F17
IPC codes: G06F1, G06F21