WO2000055709A2

WO2000055709A2 - System for distribution, authentication and tracking of digitally transmitted media

Info

Publication number: WO2000055709A2
Application number: PCT/US2000/006875
Authority: WO
Inventors: Christopher B. Muir; Christopher Van Rensburg; Thomas Morgan Dolby Robertson; Steven Hales
Original assignee: Beatnik, Inc.
Priority date: 1999-03-17
Filing date: 2000-03-15
Publication date: 2000-09-21
Also published as: AU3887800A; WO2000055709A3

Abstract

The present invention provides an Embedded License Information system, also referred to as an ELI system, in which embedded license information, and a network link, such as a URL, that allows connection to a license authority, are disposed in ELI digital media files. As a result, playing of an ELI media file using an ELI player will, upon connection of the ELI player to the communication network, generate a message to the license authority that has the potential to include information relating to I) the file that is or was previously played, II) the broadcaster location, such as the particular webside, that the ELI digital media file was obtained from, and III) the location from which the ELI digital media is or was played. Reports can then be generated to broadcasters and vendors using information collected by the license authority.

Description

SYSTEM FOR DISTRIBUTION, AUTHENTICATION AND TRACKING OF DIGITALLY TRANSMITTED MEDIA

Field of the Invention

The present invention relates to a system for distributing, authenticating and tracking digital media, and, more particularly, a system in which the distributed digital media includes an authentication stamp that is usable for authentication and tracking purposes.

Background of the Invention

Prior to the advent of digital communications networks such as the Internet, keeping track of usage of copyrighted works, particularly audio and visual works, was a laborious painstaking process. In fact, many usages of such works still cannot be accounted for, since there is no way to know any certainty how many times a particular work, such as a song, has been played. For example, tracking solely the sale of the work from the original seller to the ultimate purchaser cannot provide any information regarding the number of times that a work will subsequently be played. Accordingly, after an initial sale of such a work to a buyer, typically in the form of a CD, cassette, or video, there has been relied upon many different types of reporting mechanisms and approximations to determine usage of the work. The reporting mechanism, approximation used, and the license fee owed will depend on the class of buyer to whom the work was sold, and other factors. As such, a radio station that repeatedly plays copyrighted works over the airwaves are monitored more closely than consumers who purchase a work solely for their own personal usage in their home.

With the advent of the Internet and other digital communication networks, it has now become possible to more easily distribute copyrighted works in the form of digital media to millions of locations. While this offers the possibility of distributing digital media with great ease to ever increasing numbers of users, there is a correspondingly difficult task of keeping track of the digital media that is being distributed.

Many systems have been proposed to assist in licensing digital media over electronic communication networks.

U.S. Patent No. 5,790,664 describes a system for automatically tracking use of software and determining whether the software is validly licensed. A licensing server will then enable or disable a particular software application based upon whether that software application is validly licensed.

U.S. Patent No. 5,765,152 describes a system in which creators of works can create a digital media DOCUMENT that can include, in addition to the digital media, a document header, a document identifier and a digital signature. Potential licensees are given minimum level of permissions to review the DOCUMENT, and if desired to then license the

DOCUMENT, are provided with an auxiliary permission data set that allows for the licensee to then use the DOCUMENT that has been licensed in various manners.

U.S. Patent No. 5,634,012 also describes a system in which an author is allowed to attach usage rights to the digital media that the author has created. These usage rights include a right code along with various conditions for exercising the right.

While systems such as those identified above do assist in licensing digital media over electronic communication networks, they are complex and, therefore, not easily adaptable for distributing, tracking and licensing digital media to extremely large groups of people.

Accordingly, a system that is able to effectively distribute, track and license digital media, while also being as transparent as possible to the ultimate end-user is needed.

SUMMARY OF THE INVENTION Accordingly, it is an object of the present invention to provide a system that is able to effectively distribute, track and license digital media, while also being virtually transparent to the ultimate end-user.

It is a further object of the invention to provide a system that can effectively detect and prevent the usage of pirated digital media. It is a still further object of the invention to implement a system that allows for standardized authentication of digital media so that copyrighted digital media from many different authors and sources can be uniformly distributed, tracked and licensed.

This invention attains the above objects, among others, by providing an Embedded License Information system, also referred to as an ELI system, in which embedded license information, and a network link such as a URL, that allows connection to a license authority, are disposed in ELI digital media files. As a result, playing of an ELI media file using an ELI player will, upon connection of the ELI player to the communication network, generate a message to the license authority that has the potential to include information relating to I) the file that is or was previously played, II) the location, such as the particular website, that the ELI digital media file was obtained from, or III) the location from which the ELI digital media file is or was played. Reports can then be generated to broadcasters and vendors using information collected by the license authority. BRIEF DESCRIPTION OF THE DRAWINGS

The above and other objects, features, and advantages of the present invention are further described in the detailed description which follows, with reference to the drawings by way of non-limiting exemplary embodiments of the present invention, wherein like reference numerals represent similar parts of the present invention throughout several views and wherein:

Figs. 1A and IB illustrate an overview of the embedded license information system according to one embodiment of the invention;

Fig. 2 illustrates in further detail the ELI management system according to the one embodiment of the invention;

Fig. 3 illustrates a flow chart of operation of the media broadcaster system according one embodiment of the invention;

Fig. 4 illustrates a flow chart of operation of the media vendor system according to one embodiment of the invention; Figs. 5 A and 5B illustrate a flowchart of operations of a portion of the ELI management system according to one embodiment of the invention;

Fig. 6 illustrates a flow chart of operation of the media receiver system that communicates with a portion of the ELI management system according to one embodiment of the invention; Fig. 7 illustrates one embodiment of the invention in the presence of a pirate media broadcasting system;

Figs. 8A-8C illustrate various ELI stamped media formats according to one embodiment of the present invention;

Fig. 9 illustrates another embodiment of the ELI system according to the invention; Fig. 10 illustrates one embodiment of the pending message database according to the invention;

Figs. 11A and 1 IB illustrate message types that are transmitted between a media receiver and the ELI management system according to the invention;

Fig. 12 illustrates a raw media format according to one embodiment of the invention; and

Figs. 13A and 13B illustrate examples of reports for the media vendors and media broadcasters according to the invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The ELI system according to this invention is capable of collecting information that can be used to enable the accurate collection of usage royalties and statistics for media that is broadcast across computer networks. Furthermore, the ELI system also allows embedding of media licensee information inside the ELI digital media itself. As a result of the embedded information contained in the ELI media that is distributed, the present invention provides the ability to distribute, authenticate and track licensed ELI digital media. Accordingly, the ELI system according to the present invention can also detect unlicensed ELI media and take appropriate remedial measures. Central to the concept of the present invention is the notion that ELI-stamped media is a core commodity around which the entire ELI "Closed Loop" system is built. It is a premise of the present invention that there is a large audience of end-users who wish to experience media broadcast across networks such as the Internet, and that the current vague and imprecise statistical models of performance tracking are inadequate. Figs. 1A and IB illustrates an overview of the ELI system 10 according to the present invention. Fig. 1A illustrates those components associated with stamped preview media 40, and FIG IB illustrates those components associated with stamped license media 30, as described further hereinafter. As illustrated, the ELI system 10 includes as its four main components an ELI management system 100, a media vending system 200, a media broadcast system 300, and a media receiver system 400, each of which will be discussed in further detail hereinafter.

In general, however, each of the systems 100, 200, 300 and 400 are computer networks, although it is intended that certain of these systems can be combined and have their functions be performed by the same computer. For instance, systems 100 and 200 or 100, 200 and 300 could be combined on a single computer or cluster of computers and operate together as a single system. Preferably, however, these computer networks can and typically are independent of each other, capable of communicating over a communication network such as the Internet. As such, each of the systems 100, 200, 300 and 400 have components that are conventionally associated with computer systems, such as a processor, internal memory and interfaces, input devices such as keyboards and mice, output devices such as speakers, displays and printers, and the like. As is known, each of these components has associated therewith particular software applications that allow for the implementation of the present invention as described herein. Which is not to say that certain software components cannot be implemented in hardware, but rather that the present implementation of the present invention is predominantly software that implements the features described herein using conventional hardware devices. It is anticipated that various vendors associated with systems 200, 300 or 400 will initiate activities that will result in the apparatus and methods according to the present invention being used. As an overview, however, with general reference to Figs. 1A and IB, in one specific embodiment, a media vendor will use the media vendor system 200 to forward each piece of raw media, which will contain digital media related to the work and associated information, from a raw media database 210 to the ELI management system 100. The ELI management system 100 contains a license stamper 120 that will "stamp" the raw media and transmit the stamped media back to the media vending system 200 for storage in a stamped vendor media database 220 or transmission to a broadcaster system 300. Optionally, the stamped media can also be stored in a license database 160. Also, rather than transmit the digital media as part of the raw media, it is possible to instead transmit a pointer that can be used to identify the location of the digital media that is desired.

One type of raw media 20 that a vendor using system 200 will forward for stamping to system 100 is media that, once stamped, becomes stamped preview media 40 that can be forwarded to broadcasters owning systems 300 to preview. The vendor can implement the distribution of preview media 40 in various ways, depending on the vendor's preference. It is possible, therefore, for each different piece of digital media to have associated therewith a single file of stamped preview media 40 that is stored in stamped media database 220 that can be distributed to different broadcasters 300. Alternatively, broadcasters owning systems 300 can request a preview of digital media, and at that time the vendor of system 200 can have the requested digital media forwarded as raw media 20 to system 100 for stamping each time, and then forward the received stamped preview media 40 to the system 300 for review by the associated broadcaster.

No matter how the transaction is initiated, the broadcaster will review the received preview media 40. If the operators of the media broadcast system 300 desire to broadcast the contents of the preview media 40, a request for a media license is then transmitted to the media vending system 200. If the request is granted, the media vending system 200 will then transmit further raw media 20 to the system 100, the raw media 20 will again include the digital media ( or a pointer to it as mentioned previously) and associated information related to the agreed upon license terms, as described further hereinafter. In response, system 100 will stamp this raw media 20 to obtain stamped license media 30, which is then received by vendor system 200, stored if desired in stamped media database 220, and then forwarded to broadcast system 300 for storage in a broadcast media storage 310. The media broadcast system 300 can then broadcast the obtained stamped license media 30 to potential users of it.

The recipients of the stamped license media 30 will each have a media receiver system 400 that includes a media receiver 410 for receiving the stamped license media 30, which media receiver 410 includes an ELI media player capable of reproducing the digital media in the appropriate format, such as sounds or images. The media receiver system 400 also preferably contains a general purpose file system (not shown) for storage of various stamped license media 30 that it receives, such that when the media receiver system 400 is not connected to the network, the stamped license media 30 stored within the general purpose file system can still be enjoyed and experienced. Playing of the stamped license media 30 by the ELI media player 420 will cause, as described further hereinafter, a message 50, also called a ping, to be delivered to the ELI management system 100, typically after the media has been played, or at some subsequent time, such as the next time that the media receiver system 400 is connected to the communication network or when a determined number of messages have accumulated, each message 50 indicating that a particular stamped license media 30 selection has been played. The ELI manager 140 that is part of the ELI management system 100 uses the delivered message 50 to authenticate and track the media, as will be described in more detail hereinafter.

Figs. 8 A - 8C illustrate in a preferred embodiment the contents of ELI stamped media, which will now be described. ELI stamped media can take the form of stamped preview media 40 or stamped license media 30. Both of these media types use the same format of ELI stamped media, but the fields will have different information contained therein due to the different usages of stamped media 30 and 40. The stamped media 30 and 40 is obtained from raw media 20, which media is originally received by the license stamper 120 in a form illustrated in Fig. 12. The stamped media 30 and 40 includes certain fields not contained in the raw media 20, in particular the License Number field in the preferred embodiment, which is added by the licensee evaluation module 124 as described hereinafter. Also, the raw media 20 contains fields not needed in the stamped media 30 and 40, particularly the Media Data

Block Pointer field, the Stamped Media File Extension field and the Stamped Media MIME Type, each of which will be described in more detail hereinafter. Further stamped media 30 and 40 is preferably encrypted, for example using an RSA encryption algorithm. While it is possible and most secure to encrypt the entire stamped media 30 and 40, it has been determined that the media data, licensor information and licensee information portions are the preferable minimum portions to be encrypted. Certain other portions of the stamped media 30 and 40, which particularly related to routing efficiency, need not be encrypted, such as router addresses and the like. With that overview of the media types transmitted between the various systems 100,

200, 300 and 400 of the ELI system 10, the ELI media will now be further described. ELI stamped media

ELI-stamped media contains licensing and performance rights information designed to facilitate the tracking of broadcasting / performance of the media across a network. An example of ELI-stamped media is illustrated in Figs. 8A-8C. Each ELI-stamped media preferably includes ELI licensee information, ELI licensor information, ELI playback rules, General ELI information, and a media data block. The fields that are preferably associated therewith include:

ELI licensor information: • Vendor Name

• Vendor Network Address

• Vendor Phone Number

• Vendor fax

and ELI licensee information:

• Licensed to Broadcast System 300

• Expiration Date

• ELI Index/License Number

• ELI manager 140 Location • Use of License field and other information:

• Digital Media data

• ELI stamper ID

Each of these fields will now be described in more detail. Vendor Name

Provides the name of the vendor who is the licensor of the media, which vendor is typically the owner of the vendor system 200 according to the invention. Vendor Network Address

Provides the network address, preferably a Universal Resource Locator ("URL") in the preferred embodiment of the present invention, which can be used to locate the vendor, who, as stated above, is typically the owner of the vendor system 200 according to the invention. Vendor Phone Number and Vendor fax

Other contact information that can be used, particularly if questions need to be asked during the course of a broadcaster owning a broadcasting system 300 negotiating a license for stamped license media 30 after having reviewed stamped preview media 40. Licensed to Broadcast System 300

This is used by the ELI media player 420 to determine if the ELI stamped media 30 or 40 identifies a valid broadcaster for the media to be played. This field will, preferably, be a URL location associated with the broadcast system 300. Thus, if the URL that the media was actually received from does not match the URL specified in this field of the ELI-stamped file, then it can be determined that the media is pirated stamped media 80, as described further hereinafter, and the broadcast is considered illegal. Expiration Date

This field is used by the ELI media player 420 to determine if the license for the received stamped media is still valid and has not expired. Though the owner of the media broadcast system 300 may obtain a license for a number of plays of the media, it may still be part of the license agreement between the owners of the media vending system 200 and the media broadcast system 300 that these licensed plays be used within a limited time period. The balance between expiration date and licensed plays is best left to the pricing structures that the owner of the media vending system 200 believes is most appropriate for marketing the media. There may be cases where an owner of a media broadcast system 300 would be prepared to pay for unlimited plays of the media within a limited time period - the expiration date may be shortly after issuing of the license. This type of license would be well suited to an owner of a media broadcast system 300 that is planning an event, such as a competition, and the licensed media is only needed for the duration of this event.

ELI Index/License Number The index number for an ELI-stamped file enables the ELI manager 140 to match an incoming ELI message that results from a stamped license media 30 being played by an ELI player 420 with the corresponding license record inside the license database 160. Because the index number is needed in order to make a conclusive match between an ELI message or ping and a license record, every unique ELI-stamped file from the same ELI management system 100 must have a unique ELI index number, which is obtained in the manner previously discussed, which license number is mirrored in the license database 160.

ELI manager 140 Location

In order for the ELI media player 420 to deliver each message 50 within its message database 430 to the ELI manager 140, as well as any messages 60 that may be required by ELI-stamped files as discussed hereinafter, the ELI media player 420 communicates with the

ELI manager 140. In the preferred embodiment, the ELI manager 140 has a CGI (Common

Gateway Interface) interface to the Internet. In this case, the ELI manager 140 location is the

URL of a CGI script that processes an incoming message 50.

Use of License Field The license usage field provides an indication of the medium in which the stamped media files can be used. For instance, if a broadcaster has usage rights for the World Wide

Web, then that broadcaster would not be permitted to use the stamped media files for broadcast on a customer's proprietary internal computer network.

Digital Media data The digital media data stored in the Media Datablock is the data that makes up the work

ELI stamper ID

The ELI stamper ID provides the identity of the application or hardware that created the stamped media. Media Data Block MIME Type

When stamped media is created, the "Media Data Block MIME Type" field designates the type of digital media within the stamped media. This field is also written into the stamped media such that when the ELI Media Player decrypts and parses ELI-stamped Media, the

"Media Data Block MIME Type" field is used to determine what form of internal process should be used to perform the media. This mechanism is useful, especially for applications such as the World Wide Web, because browsers typically use the MIME type that is sent with the media across the Internet to determine which browser add-on component should deal with the media. Traditionally, this has caused problems with competing add-on components that may have support for overlapping media MIME types. Conflicts between shared MIME types are resolved by the browser and/or user, giving authors no reliable means of requiring that a particular player technology handle their media content. By encapsulating all a player's supported media types into the same type of ELI wrapper, and then specifying the media's actual MIME type inside this ELI wrapper, just one type of external MIME type need be used for ELI-stamped media that is to be handled by a specific player technology, regardless of how many media types can be supported by the player.

In one embodiment of an ELI Media Player based upon RMF file types, the MIME type of the ELI wrapper will be "audio/rmf, but internally the .RMF file could contain data of varying media types, including "audio/midi", "audio/aiff, "audio/wav", "audio/basic".

Playback Rules

ELI playback rules are also contained within an ELI stamped media 30 or 40. These playback rules also contain fields, described hereinafter, which are used to assist in deter- mining whether a particular ELI player 420 should play a particular stamped media 30 or 40.

As noted previously, the stamped media 30 and 40 is obtained from the raw media 20.

Fig. 12 illustrates that format of the raw media 20. Most of the fields are the same as in the stamped media 30 and 40, and therefore need not be further described. Additional fields are, however, the Media Data Block Pointer field, the Stamped Media File Extension field and the Stamped Media MIME Type, which will be further described.

Stamped Media File Extension

The stamped media file extension is necessary in order to transmit a stamped file across the network medium. For example, HTTP protocol has various different extensions, and the stamped media file will use an existing extension type, or another new extension could be implemented. Thus, this field goes hand in hand with the "Stamped Media MIME

Type" field, described below. It is used by the ELI License Stamper in constructing the filename for the stamped media that is to be delivered to the Media Vendor 200, and is not actually stamped into the ELI file. Stamped Media MIME Type

The "Stamped Media MIME Type" field represents the MIME type that is desired for the output of the ELI License Stamper 120. This MIME type is not stamped into the file, as such, but is used to send the stamped file across the network back to the Media Vendor 200. The ELI Management Center 120 may also make a record of the MIME type and associated file extension for future reference. This information may be generally useful in observing the usage of MIME types by ELI-stamped media, and will help the ELI Management Center build a profile of the ELI Media Player technologies being developed. Through requests to stamp media, the ELI Management Center is not only able to gauge the number of unique stamped media MIME types that are in use, correlating closely to the number of unique ELI Media Player technologies, but also the number of media types being supported and used for each of these player technologies. Media Data Block Pointer The media data block pointer can be used to provide a pointer to a media data block that is not transmitted with raw media 20. Accordingly, in creating stamped digital media, as described hereinafter, media that is located on system 100, or in another location, can be located using this pointer information.

Fig. 10 illustrates another significant message type according to the present invention. As discussed previously, in the preferred embodiment of the present invention, the typical end-user does not pay a fee for experiencing the associated media, much like a typical end- user does not pay a fee when listening to a radio station. When, however, the user experiences the digital media associated with a stamped license media 30, there is the need to account for that usage, which accounting is performed by the ELI manager 140 collecting content that is delivered in a message 50 for each stamped license media 30 that has been played. Accordingly, playing such stamped license media 30 will ultimately cause, as described further hereinafter, a message 50 to be sent from the ELI player 420 to the ELI manager 140. The message 50 contains, for each play of stamped license media 30, certain information that is contained within the associated stamped license media 30, such as the License Number, and also the time and duration of play, whether the play was legal or not, and the Broadcaster URL. A message 50 can be sent for a single play of stamped license media 30, in which case the contents illustrated in one row of Fig. 10 will be transmitted. Alternatively, after a predetermined number of plays, or a predetermined period of time, or at some other interval, a group of messages 50, as illustrated by a number of rows in the illustrated pending message database in Fig. 10, can be transmitted. Of course, a different message is needed for each different ELI manager URL. The appropriate message 50 is thus sent to the appropriate ELI manager URL, which network location is known due to the ELI manager field that exists within the stamped license media 30 and is associated with each play, as shown in Fig. 10. The message 50 is also preferably encrypted, such that the ELI manager 140 decrypts the received encrypted message.

In another embodiment, discussed hereinafter, the ELI playback rules can require a message 60 to be sent by the ELI player 420 to the ELI manager 140, and that a response message 70 be received from the ELI manager 140 before initiating the playback of the stamped license media 30. Alternatively, playback of the stamped license media may initiate, but also cause a message 60 to be transmitted to the ELI manager 140 by the ELI player 420, and a response message 70 can be received during playback instructing ELI player 420 to no longer play a particular stamped license media 30 ( for instance if it was obtained illegally and detected as such as described hereinafter). Messages 60 and 70 are illustrated in Figs. 11A-11B.

In addition to the fields discussed above, other license and formatting fields can also be contained in ELI stamped media. For example, other fields such as: • Song Title

• Composer(s)

• Copyright

• Performed by

• Publisher Contact Info • Composer Notes

With that overview of the contents of various types of ELI stamped media, a more detailed description of the components and the various functional capabilities of the ELI system 10 will now be provided. ELI management system 100 The ELI management system 100 performs the overall administrative function that enables the tracking of performance statistics for any given ELI-stamped media. The ELI management system 100 can be further broken down into two modules that cooperate with one another: the license stamper module 120, and the ELI manager module 140. Both of these modules share a common ELI license database 160 that contains the license information for all ELI-stamped media that is to be managed through the ELI management system 100.

While it is not essential that the license stamper module 120 and the ELI manager module 140 be hosted on the same computer system, or even at the same location, the two modules need to be able to access and update the common database 160, whether this is done through a LAN (Local Area Network) or a WAN (Wide Area Network, such as the Internet). Of course, the most efficient implementation of an ELI management system 100 will be where the license stamper module 120 and the ELI manager module 140 are closely integrated and residing at the same geographical location, preferably connected through a LAN or part of the same computer system.

According to the present invention, the license stamper 120 is responsible for processing requests from media vending systems 200 to stamp raw media 20, preferably having content illustrated in Fig. 12, and deliver the stamped media 30 or 40, preferably having content such as illustrated in Figs. 8A-8C, back to the media vending system 200 if the request is successful. Built into the transaction can be a service fee that is paid by the media vendor to the ELI management system 100 owner, which payment is preferably, but not necessarily, electronically implemented using conventional electronic banking systems that are built into each of the ELI management system 100 and each media vending system 200. Fig. 2 illustrates the ELI management system 100 in more detail, which as previously mentioned contains three main components: the license stamper 120, the ELI manager 140, and the license database 160. The license stamper 120 and the ELI manager 140 are preferably implemented as application software that is processed using the processor of a single or various computers that make up the system 100. The license stamper 120 contains a request service module 122 that operates upon incoming raw media 20 from a media vending system 200. The request service module 122 formats received raw media 20, so that the licensee evaluation module 124 can evaluate each. The licensee evaluation module 124 determines if the required fields have been specified and, if so, approves the submitted raw media 20 and then associates a unique ELI index number with the other information in the raw media 20. The licensee evaluation module 124 then initiates storage of at least certain of the license information, and, if desired, the digital media related to what will become the stamped preview media file 40 or stamped license media file 30, in the database 160. The license portions of the preview media or license media is preferably stored in a license database 162, that is relationally related to performance database

164, described hereinafter.

The licensee evaluation module then passes the formatted raw media 20, with the respec- tively assigned ELI index number and the digital media being licensed, to the license stamper module 126, which operates upon the provided information to obtain the stamped preview media 40 or stamped license media 30, respectively. The stamped preview media 40 and stamped license media 30 are preferably formatted in a way that makes it difficult to alter their contents, as described previously. The stamped preview media 40 or stamped license media 30 is then transmitted back to the media vending system 200.

Further, the report generator module 128 generates reports using data from the license database 160 for distribution to media vending systems 200 and media broadcasting systems 300, as described further hereinafter.

The ELI manager 140 includes a message gatherer module, which operates upon incoming messages 50 and 60 from any one of the various ELI media players 420 that are being used. The message gatherer module 142 formats each received message so that it can be evaluated by the message processing module 144. In a preferred embodiment, the message processing module 144 evaluates each message 50 to determine which stamped license media has been played and to record statistics related to such playing. In a modified embodiment, the message processing module 144 also has the ability to evaluate a message 60 that is used to determine whether a particular stamped license media can be played and return a message 70 to an ELI media player 420 indicating the same. In another modified embodiment, the message processing module 144 has the ability to evaluate whether a particular stamped license media has been illegally played using messages, and returns a return message to an ELI media player 420 indicating that the particular stamped license media should not be played again.

The ELI processing module 144 also cooperates with the database interface module 148 to store data related to each message 50 and 60 that is received by the ELI manager from an ELI media player 420 in the performance database 164. Media Vending System 200

The media vending system 200 is used by vendors who desire to supply licensable media to broadcasters who wish to broadcast this media to an audience of receivers. As mentioned previously, media vending system 200 will cause stamped preview media

40 to be delivered to the media broadcast system 300 upon a broadcaster's request for preview media. The stamped preview media 40 that is transmitted preferably contains content such as illustrated in Fig. 8A previously described. If a license to the content contained in the preview media 40 is desired, the media broadcast system 300 will be commanded to request a media license from the particular media vending system 200 that delivered the particular stamped preview media 40 of interest. If that license is granted, and upon payment of the license fee, stamped license media 30 that preferably contains content such as illustrated in Figs. 8B-8C, is transmitted to the media broadcast system 300. The licensing, including payment of the licensing fee, is preferably, but not necessarily, electronically implemented. Conventional electronic banking systems that are built into each of the media vending systems 200 and the media broadcast systems 300 can be used for that portion related to payment of the licensing fee.

A typical usage of a media vending system 200 would be within a business-to- business music portal where Web site developers can go to search for and locate music media, so that they can license and broadcast this media from the Web sites that they develop. The Web site developers, using a media broadcast system 300, would communicate with the media vending system 200 and cause a fee to be paid, preferably electronically, for a limited license to broadcast the music media. The fee would, typically, be based upon a limited number of broadcasts by the media broadcast system 300. It is the ELI management system 100, combined with the cooperation of the ELI media player 420, that makes it possible to realistically enforce such a license for limited broadcasts, as is apparent from the discussions herein. Media broadcast system 300 The media broadcast system 300 is used by broadcasters who desire to deliver entertainment and/or information media to an audience across a computer network. Unlike conventional pay-per-play systems, the ELI system 10 focuses primarily on the media broadcast system 300 as the "customer" that will drive the economy behind ELI-stamped media. In other words, it is the broadcaster of the media who pays for each end-user who receives the broadcast and the end-user need not be responsible for paying license fees each time the content associated with a particular stamped media is experienced. Thus, the broadcaster system 300 will contain server components and player components, such that it can review stamped preview media 40 using the player components and distribute stamped license media 30 using the server components. The player components correspond to the media receiver system 400, described hereinafter, and the server components correspond to the broadcast system 300 described herein. Despite the fact that the ELI system 10 is preferably implemented such that owner of the media broadcast system 300 is the customer in the ELI economy, the ELI system 10 does not preclude other financial models - such as pay-per-play - where the end-user is the customer driving the economy. Within the design of the ELI system 10, a pay-per-play model is achieved by combining the media broadcast system 300 and media receiver system 400 into one entity, as will be described hereinafter. Media receiver system 400

The media receiver system 400 is the final component in the ELI system 10. By media receiver system is meant any device containing an ELI media player 420 that is capable of receiving and playing the ELI-stamped media so that an end-user can experience it. In the case of ELI-stamped digital media, the end-user would be a listener, and the media receiver system 400 would most typically be a Web browser that has the increased capability of playing ELI-stamped music media through an add-on component such as a plug-in or ActiveX control.

The ELI system 10 does not require that the media receiver system 400 be connected to the network for the user to use the ELI media player 420. When the user is offline (not connected to the network), the media receiver system 400 (and therefore the ELI media player 420) will not be able to report all plays of ELI-stamped media to the ELI manager module 140 of the ELI management system 100. For the sake of the accuracy and integrity of the ELI model, it is preferably not acceptable for these plays to simply be lost. Therefore, an ELI media player 420 has the capability of counting all plays of ELI broadcast media 30 that have occurred while the media receiver system 400 is not connected to the network.

Depending on the implementation of an ELI media player 420, it may not be deemed appropriate for the player to contact the ELI manager 140 every time that ELI-stamped media is played. In fact, even when the media receiver system 400 is online, one optimization is for the ELI media player 420 to accumulate information until such a time as a predetermined minimum number of backlog of plays has built up and report them all in a group of messages 50 sent at the same time. The accumulated reports that are stored inside the message database 430 can then be sent to the ELI manager 140 in one single connection, thus reducing network traffic and creating a smoother experience for the end-user. Of course, the needs of the end- user have to be balanced with the media vending system 200's needs for accurate up-to-the- minute data on playback. Up-to-date information may also be considered essential for the owner of a media broadcast system 300 who is not willing to pay the owner of media vending system 200 for "overplays" that are generated by end-users who repeatedly experience media while offline without giving the ELI management system 100 any indication of usage status.

The message database 430, an example of which is illustrated in Fig. 10, preferably contains a record corresponding to each piece of stamped license media 30 that has been played (according to the preferred embodiment) and not yet reported to the ELI management system 100. By storing information on each stamped license media 30 that has been played, it is possible to provide detailed usage reports, and also illegal broadcasters for any given license, since the broadcaster ID that is used for generating a message such as illustrated in Fig. 11A is the origin (such as the URL), rather than the broadcaster ID (also referred to as "licensed to Broadcaster 300" field) that is stored within the stamped license media 30. It should be noted, however, that illegal play is prevented in the first instance according to the preferred embodiment of the present invention by having the ELI player 420 interpret certain of the playback rules. Specifically, as described in more detail hereinafter, if the broadcaster ID within the stamped license media 30 does not match the actual broadcaster ID, the playback rules can be set to prohibit usage of the stamped license media 30 even a single time.

Each record of the message database 430 preferably contains at least the following fields:

• License Number

• Broadcaster ID (typically a URL) • Time of Play (includes date and time of day)

• Playback Duration

• Illegal Play query

• ELI Manager Network Address (typically a URL)

Depending on the specific implementation of the ELI manager 140, the message database 430 may also contain additional information to gather, for example, statistical information on demographics of media popularity. With this information, reports can be generated, as described hereinafter, relating to the usage of each stamped license media 30 by end-users operating ELI players 420.

Operation of the ELI system 10 will now be described with reference to Figs. 3-6, which each illustrate operation of the ELI system 10 from the perspective of the ELI management system 100, the media vendor system 200, the media broadcaster system 300, and the media receiver system 400, respectively.

Fig. 3 illustrates the steps of the preferred embodiment of the present invention from the perspective of an owner of broadcast system 300. In step 502, the media broadcaster browses preview media 40 after having sent a request for and received preview media 40 from a vendor system 200. Upon selecting a preview media 40 for licensing, in step 504, the broadcaster sends a request for a license of the preview media, and a response is received. As illustrated by step 506, if that response does not grant a license, then further negotiations are needed or an alternate vendor needs to be sought. If, however, the license is granted, step 508 follows, and the broadcast system 300 receives stamped license media 30, which is then downloaded into the broadcast system 300. A transaction report, described further hereinafter, is also received by the broadcast system 300 from the vendor system 200. In step 510, the broadcaster then integrates the downloaded stamped license media 30 into the broadcast media storage 310. Thereafter, the end step 512 follows, at which time the broadcaster will wait for user system 400 to access the broadcaster system 300 and request the stamped license media 30. Fig. 4 illustrates the steps of the preferred embodiment of the present invention from the perspective of an owner of vendor system 200. In step 550, the vendor system 200 receives a request for a license of digital media from a broadcast system 300. The broadcast system, in step 552, causes to be forwarded to the ELI information system 100 information related to the broadcaster, and received back in step 554 information concerning the broad- caster. In step 556, the vendor decides whether to grant the license requested. If no license is granted, message is sent to the broadcast system 300 indicating no license grant. If a license is granted for raw media 20, depending upon the type of license requested from the broadcaster, the vendor system 200 in step 558 retrieves the digital media content and related license information, and forwards it as raw media 20 to the ELI information system 100. Step 560 follows, with the vendor receiving back either the stamped preview media 40 or the stamped license media 30 and an associated transaction information in a vendor transaction report, described hereinafter. Optionally, the vendor updates the license database 230 associ- ated with licensed media in step 562. Thereafter, in steps 564 and 566, the vendor forwards a broadcaster transaction report, described further hereinafter, to the broadcast system 300, as well as the stamped preview media 40 or the stamped license media 30.

Fig. 5 A illustrates the steps of the preferred embodiment of the present invention from the perspective of an owner of ELI information center system 100, and in particular from the perspective of the license stamper 120. In step 602, the license stamper 120 receives a request for stamping services from a vendor system 200. In step 604, this request is evaluated, and in step 606 an evaluation report is sent to the vendor system 200. Step 606 follows and the system 100 waits for a response from the vendor system 200. If no license is requested, the transaction ends. If, however, the vendor desires a license, step 608 follows, and the license stamper 120 checks the license database 160 to determine if there is an existing license for this exact same media with this same broadcaster. In decision step 610, if there was not previously a license, then a license is created in step 612 and the license database 160 is updated with the new license. If it is not a new license, then step 614 follows, and the old license is updated. Whether step 612 or 614 occurred previously, then steps 616 and 618 follow, and a vendor transaction report, described further hereinafter, and the stamped media are then transmitted to the vendor system 200 for storage, if desired, in local license database 230 and stamped media database 220, respectively.

Fig. 6 illustrates the steps of the preferred embodiment of the present invention from the perspective of a user of an ELI player 420. In step 652, the media receiver 410 receives media from a broadcast system 300 and prepares for playback. In step 654, the media receiver 410 chooses the appropriate player module, such as a media player 420 that can decode a digital music recording. In step 656, a determination is made whether the received media is stamped license media 30. If not, then it is determined that it is media that can simply be played, and it is in the following step 658. If, however, it is stamped license media 30, then the ELI player 420 applies the ELI rules within the stamped license media 30 in step 660. In decision step 662, if the applied rules do not allow broadcast of the broadcast of the media, then step 664 follows and prescribed actions are taken, which actions may not allow for playback, or which may require a message 70 from the ELI information system 100. If the prescribed actions ultimately allow playback, this is decided in decision step 666, and playback results in step 668. If the prescribed actions do not ultimately allow playback, then the transaction stops. In step 668, the media is then played. There follows, in step 670, updating of the message database 430 with the information on the media that has just been played. Subsequently, the message 50 in the message database 430 is forwarded to the ELI information system, so that the ELI manager 130 can use the information within the message

50 to update the license database and, ultimately, generate reports for the broadcasters and vendors.

Fig. 5B illustrates the steps of the preferred embodiment of the present invention from the perspective of an owner of ELI information center system 100, and in particular from the perspective of the ELI manager 140 when a message 60 (shown as a "confirmation request") must be received in order to initiate playback of the stamped license media 30. In particular, in step 622, the ELI manager receives a message 60 from an ELI media player requesting permission to play the stamped license media 30 it has received. Upon receipt, step 624 follows, and the ELI manager 140 parses the message 60 to obtain the data that it needs, and then step 626 follows, whereby a determination is made whether as to the data integrity and authenticity of the message 60. ELI manager 140 uses a validation code to check the integrity of the message 60. Preferably, this takes the form of a hashing algorithm that is used to form a hash number from all data fields in the data packet, except the hash number data field. The resulting hash number is compared with the hash number included in the message 60 to verify the data integrity and authenticity of the message 60. Other types of validation codes can also be used, such as checksums, identifiers and the like. Decision step 628 follows, which decides whether the message 60 is valid. If it is not, then step 630 follows and the ELI manager 140 logs information regarding the origin of the invalid message 60 and other information in the invalid message 60. Since there is no confirmation received by the ELI media player 420, the stamped media file 30 will not be played. If, in decision step 628 the message 60 is valid, then step 632 follows and the license number field is used to locate and retrieve the media license in the license database. If the license information is successfully retrieved, this is determined in decision step 634, and then step 638 follows, and the ELI manager 140 uses the data from the retrieved license to evaluate the data included in the message 60 and determine if performance of the stamped media 30 should be peπnitted. Step 640 follows and the message 70 is compiled, thereafter being sent in step 642. If, in decision steps 634 the license is not successfully retrieved, then step 636 follows and the disparity is logged so that the problem can be pursued, and the disparity noted in generated reports. If the license is valid and retrieved, then regardless of whether play is permitted, a message 70 is sent containing the appropriate value for the

"permission to play" field.

The above-described operations illustrate the basic operation of the ELI system 10 according to the present invention. However, because of the wide array of possible variations in implementation of ELI system 10, and the differing concerns of various participants in a ELI economy, there are also defined a format for sets of rules that can be used to govern the reporting and decision-making of a ELI media player 420 for embodiments other than those mentioned above. In order to not restrict the future evolution of ELI systems, ELI-stamped media may contain an indefinite number of rules, in the form of a list of name/value pairs, preceded by a "count" field indicating the total number of ELI playback rules contained inside the media, as follows: ELI Playback Rules Structure

• Total Rules [integer] • Rule 1 Name [string]

• Rule 1 Value [string]

• Rule 2 Name [string]

• Rule 2 Value [string]

• Rule 3 Name [string] • Rule 3 Value [string]

• Rule n Name [string]

• Rule n Value [string]

A particular set of playback rules that have been developed in order to implement the embodiments described above. These rules can, for example, require permission in order to play a particular stamped preview media 40 and stamped license media 30 and to prohibit further usage of illegally obtained stamped preview media 40 and stamped license media 30.

It is also evident that other modifications to the invention using playback rules are intended.

ELI Playback Rules:

The following ELI playback rules allow for a variety of different behaviors, suitable for several different applications within the ELI economy. Different broadcasters of ELI- stamped media will most certainly have different agendas regarding the protection of their media. The specific rules preferences chosen for ELI-stamped media may even be greatly different between different media that comes from the same media broadcaster. For instance, an original media vendor may choose to make some content available purely for promotional purposes. This content may have the most lax protection set inside the playback rules. On the other hand, other media that this media vendor offers for preview on the e-commerce Web site may have very strong security specific in the ELI playback rules, since these files may represent the core revenue of the vendor and therefore should not be widely played unless originating from a valid licensed broadcaster.

Following is an exemplary set of rules usable to customize the playback behavior of ELI-stamped media

- Play from local file system? [yes | no]

- Issue ELI confirmation request? [always | only if connected | never]

- ELI confirmation request behavior: [start playing immediately | wait to play]

- If illegal condition, play? [yes | no] - If illegal condition, alert end-user? [yes | no]

- Expiration triggers illegal condition? [yes | no]

- Invalid broadcaster triggers illegal condition? [yes | no]

In the listing of the rules, possible values are enclosed in square brackets'^ ]", and are separated by the pipe "|" symbol. A description of considerations related to these playback rules follows.

Play from local file system?

When an end user uses a media receiver 410 to browse for media from a broadcast system 300, it is possible for the user to save the stamped license media 30 to the local file system. Individual files can often also be retrieved from the media receiver's file caching system. There are also applications available that will retrieve entire Web sites from the Internet to be saved and later browsed off the user's local system. It may or may not be the desire of the media vendor or the media broadcaster to allow end users the privilege of playing downloaded files from the local system, as opposed to only being able to play the files when they are broadcast from the media broadcaster system 300.

Of course, there are other variables involved. For instance, it may be an option of the license that the media broadcaster holds with the media vendor that all local file system plays do not count against the licensed number of plays. In this case, the media broadcaster would not mind that the media is replayed off the end user's local system. However, if the agreement between the media vendor and the media broadcaster is that all plays, including local system plays, count against licensed plays, then the media broadcaster may want to insist that the stamped license media 30 be stamped with the rule prohibiting local system plays. This is because stamped license media 30 that is replayed off the local system may not then be broadcast in the context of the media broadcaster's overall site, and therefore the media broadcaster is not likely to gain the benefit that the media would otherwise contribute to the site.

Issue ELI confirmation request?

Although not considered to be the preferred implementation of an ELI system, the media vendor or media broadcaster (valid licensee) may wish that each performance of a piece of ELI-stamped media be preceded by a request to the ELI management system 100 for permission to play, as discussed previously. This transaction between the ELI media player 420 and ELI management system 100 is distinct from the transaction that takes place when the player delivers the contents of its message database 430 to the ELI management system 100. This rule, when set to "yes", does not of itself dictate that an acknowledgement be received before the media can start playing - it simply specifies that a request should be performed. When set to "yes", the actual behavior is affected by the paired rule "ELI confirmation request behavior" described below. Because the message database scheme is geared towards optimizing the performance of the ELI system 10 and reducing the latency between the media downloading and beginning to play, having this rule set to "yes" may have a negative impact on the media broadcaster's site performance.

If, however, the media broadcaster is in agreement with the media vendor where overplays are charged at a premium rate well above that of the standard license rate, the media broadcaster may wish to be protected from such overplays. In this event, the rule would serve the interests of the media broadcaster well. In another situation, the media broadcaster may make it clear from the start that only a once-off limited play license is to be purchased and that the broadcaster has no intention of renewing this license when it expires.

In such an event, having this rule set to "yes" would protect the interests of the media vendor.

Because having this rule set to "yes" may increase the network load on the ELI management system 100, this rule's setting may need to be involved in the media vendor's pricing structure, since the ELI management system 100 may charge a higher service rate to the media vendor for stamped license media 30 that is stamped with this rule set to "yes".

ELI confirmation request behavior

As stated already, the mere issuance of an ELI confirmation request does not dictate that play should not begin until permission is granted. In fact, in order to ensure optimal performance of the media broadcaster system 300 when a confirmation request is to be issued, it may be desirous to begin play immediately. If permission is then denied subsequent to the media beginning play, then the media can stop playing at this point. The two possible values for this rule are "start playing immediately" and "wait to play".

If illegal condition, play?

Depending on the exact objectives of the media vendor and media broadcaster (valid licensee), it may be preferable to always play the stamped license media 30 - even in cases where an illegal condition has been recognized by the ELI media player 420. It has to be considered that the end-user experience of media not playing as anticipated could contribute to negative impressions of the media broadcaster, as well as the underlying player technology itself. Even if this rules is set to "yes", the ELI media player 420 will still be able to gather information regarding illegal broadcasting activities, which can then be compiled into reports for the media vendor and media broadcaster (valid licensee) and remedial actions may be taken.

If illegal condition, alert end-user?

In the case of a media vendor or a media broadcaster (valid licensee) who is extremely paranoid about illegal broadcasting activities, the option is available using this rule to publicly shame any broadcaster who attempts to broadcaster illicitly obtained media for which that broadcaster has no license. When an illegal broadcaster condition is recognized by the ELI media player 420 and this rule is set to "yes", the player may pop up a dialog informing the end-user that the broadcaster who's site they are visiting is in violation of the media's license agreement and is therefore breaking the law. Such a dialog greeting each visitor to a Web site would diminish the reputation of the site, and this alone would act as a powerful deterrent for any would-be illegal broadcasters.

Expiration triggers illegal condition?

The value of this rule could vary significantly, depending on the exact nature of the business relationship between the media broadcaster and the media vendor. For instance, a media vendor may wish to provide the best and most accommodating service to its most valued elite clients. For such clients, the media vendor may never wish the media broadcaster to be embarrassed by licensed media failing to play, even if the license has expired. The media vendor may prefer to deal with these aspects of the licensing agreements "offline", with the aid of reports delivered from the ELI management system 100. The media broadcaster may have an arrangement with the media vendor to automatically renew licenses that have expired. In this case, it is best that the expiration not contribute towards an illegal condition in the ELI media player 420.

In many other cases, however, it may be completely appropriate for the license expiration to contribute to an illegal condition. Consider the example of a media broadcaster who purchases a license for unlimited plays of a piece of media, but within a very restrictive timeframe. In these kinds of licensing situations, the expiration date - rather than maximum- licensed plays - may be the condition that prohibits additional plays.

Invalid broadcaster triggers illegal condition?

In most cases, this rule will be set to its default value of "yes". There may be cases, however, with promotional materials, where the media broadcaster and/or media vendor may not care if the media is redistributed with impunity. Indeed, it may be in the best interest of the media vendor if this media is to be used to establish the media vendor's presence as a source of high quality media. In the case where this rule is set to "no", the ELI media player 420 would still gather information about the media origin and it would still be possible even if play is permitted, for the ELI management system 100 to provide reports to the media vendor and/or media broadcaster (valid licensee) detailing invalid broadcasting activities. Following are some example value sets for the above-described typical playback rules.

Stamped Preview Media (40) - Fig. 8A

Play from local file system? no

- Issue ELI confirmation request? never

- ELI confirmation request behavior: start playing immediately

- If illegal condition, play? no

- If illegal condition, alert end-user? no

- Expiration triggers illegal condition? yes

- Invalid broadcaster triggers illegal condition? yes

Stamped License Media (30) - Typical, Fig. 8B

- Play from local file system? yes

- Issue ELI confirmation request? never

- ELI confirmation request behavior: start playing immediately

- If illegal condition, play? yes

- If illegal condition, alert end-user? no

- Expiration triggers illegal condition? yes

- Invalid broadcaster triggers illegal condition? yes

Stamped License Media (30) - Paranoid, Fig. 8C

- Play from local file system? no

- Issue ELI confirmation request? always - ELI confirmation request behavior: wait to play

- If illegal condition, play? no

- If illegal condition, alert end-user? yes

- Expiration triggers illegal condition? yes - Invalid broadcaster triggers illegal condition? yes ELI Processing Module Rules

- Overplay triggers illegal condition? [yes | no]

- Missing license triggers nack? [yes | no]

- Local plays count against licensed plays? [yes | no] - Immediately inform media vending system 200 of new illegal broadcasters (yes/no)

- Immediately inform media broadcast system 300 of new illegal broadcasters (yes/no)

Transaction Reports

As mentioned previously, with each transaction between the ELI management system 100 and a vendor system 200, or a transaction between a vendor system 200 and a broadcaster system 300, there is preferably an associated transaction report that includes certain details of the license that are contained in the stamped media and other details that are not contained in the stamped media. Since each media vendor system 200 and broadcaster system 300 will typically not have the capabilities to extract certain license information out of the ELI- stamped media, such license information, as well as other transaction information, is preferably supplied in a transaction report. This information is preferably supplied in both human-readable form, and database-ready format, although it may only be supplied in one form.

Thus, a vendor transaction report that is sent to a vendor, for instance during step 616 shown in Fig. 5A, will preferably contain information from the following fields: Vendor Name; Vendor URL; Vendor Phone; Vendor Fax; Licensed to URL; Expiration Date; License Number; ELI Manager URL; Use of License; ELI Stamper ID; Media Data Block MIME Type. Further, the vendor transaction report will contain information specific to the financial transaction process and not contained inside the corresponding ELI-stamped media, including the transaction fee (charge for license-stamping service) and transaction date (time when initial request from the vendor was received by the license stamper). The media vendor system 200 may incorporate some or all of this data contained as part of the transaction report into its license database 230.

Similarly, a broadcaster transaction report, that is sent to a broadcaster, for instance during step 564 shown in Fig. 4, will preferably contain information from the following fields: Vendor Name; Vendor URL; Vendor Phone; Vendor Fax; Licensed to URL; Expiration Date; License Number; ELI Manager URL; Use of License; ELI Stamper ID; Media Data Block MIME Type. Further, the broadcaster transaction report will contain information specific to the financial transaction process and not contained inside the corresponding ELI-stamped media, including the transaction fee (cost of purchasing license to broadcast ELI-stamped media) and the transaction date (time when initial request from the broadcaster was received by the vendor).

The media broadcast system 300 may incorporate some or all of this data contained as part of the transaction report into its license database. Reports As mentioned previously, the ELI system 10 according to the present invention needs to be able to disseminate in batch reports that are typically periodically provided the information collected by the ELI management system 100 to media vending systems 200 and media broadcasting systems 300 in order to reconcile license payments. These batch reports can then be reconciled with the transaction report information. Such reports are also needed to assist owners of media vending systems 200 to enforce protection of their media licenses, as well as helping to protect broadcasters of media using media broadcast system 300 from having their licensed media broadcast by another broadcaster illegally. Of course, not all information with the ELI management system 100 necessarily needs to be distributed to each media vending system 200 and media broadcasting systems 300. Rather, only that informa- tion that pertains to a particular media vending system 200 or media broadcasting system 300 needs to be distributed to that particular system. Thus, it is expected that the batch reports for owners of different media vending systems 200 and media broadcast systems 300 are likely to be quite different, as it is to be expected that a single media vending system 200 will grant licenses to multiple media broadcast systems 300, and a single media broadcast system 300 may obtain licenses from multiple media vending systems 200. The batched data may be provided to media vending systems 200 and media broadcast systems 300 in a database-ready format, where each record of the database contains the performance data for one license. Examples of cumulative reports for the media vendors and media broadcasters are illustrated in Figs. 13A and 13B, respectively.

As shown, the media vendor report illustrated in Fig. 13A contains information relating to the top illegal broadcasters of licensed media that originated from the vendor, the top legal broadcasters of licensed media that originated from the vendor, and a breakdown of information, as shown in each column, associated with each license that the particular vendor has entered into. As shown, the media vendor report illustrated in Fig 13B contains information relating to the top illegal broadcasters of licensed media that originated from the broadcaster, an indication of licenses that will soon need to be renewed, and a breakdown of information, as shown in each column, associated with each license that the particular broadcaster has entered into.

As described previously, the ELI management system 100 is responsible for generating these periodic statistical reports based upon the ELI information that is transmitted to the ELI manager 140 by each of the ELI media players 420. The report data will also help both the owners of the media vending system 200 and media broadcast system 300 to gain some understanding of the tastes of end-users and to gauge the success of the media itself.

Among the data that is preferably reported to both the media vending system 200 and the media broadcast system 300 is the following: Raw Data obtained from ELI manager 140 • number of legal plays

• number of illegal plays

• number of illegal broadcasters

• total time played for legal plays

• total time played for illegal plays Statistical data derived from raw data

• number of remaining plays

• average play rate

• estimated expiration date of remaining plays

• total time played • average listening time

• average repeats (loops)

• average listening time for legal plays • average listening time for illegal plays

Other reports can also be generated by the ELI manager 140, including reports that contain a listing of all illegal broadcasters and the number of illegal plays for each, thus helping the owners of the media vending systems 200 and the media broadcast systems 300 to deteπnine the most serious offender. Determining Illegal Play Status

In order to protect the interests of the media vending system 200 as well as the media broadcast system 300, the ELI media player 420 is required to evaluate the rights of the broadcaster to broadcast the ELI-stamped media. Fig 7 illustrates how the ELI system 10 operates when a pirate broadcasting system 700 intercepts the stamped license media 30 for illegal rebroadcast without paying an appropriate license to the media vending system 200.

ELI media player 420 determines that the pirated media 80 is being illegally played using playback rules as described above and can then initiate various actions. It can, for example, provide a message 50 to the ELI management system 100 so that a vendor or broadcaster can take action. It can also initiate a sequence according to playback rules and transmits a message 60 that can result in the generation and transmission of a message 70 that prevents pirated media 80 obtained from a pirate media broadcaster system 700 from being played, thereby protecting the interests of all parties invested in the content economy. For example, on determining illegal play status, a report 90 can be issued alerting the media vending system 200 as well as the media broadcast system 300 of an illegal broadcast. The report 90 can also identify the origin of the illegal broadcast, thereby facilitating possible legal recourse. In addition to a report, it may be an option of an ELI-stamped file that it not be played if the broadcaster is not found to be a valid licensee of the media. ELI manager 140 Acknowledgement

In addition to the fields already described that assist the ELI media player 420 in determining illegal play status, stamped license media 30 can optionally be programmed to demand that an acknowledgement request be processed by the ELI manager 140 before the stamped license media 30 may be played. Thus, a message 60, mentioned previously, will be delivered to the ELI Manager 140, and a return message 70 sent back indicating whether play can proceed. This can, for example, protect the media broadcast system 300 against "overplays" which the media vending system 200 may, depending on the financial nature of the license agreement, insist be chargeable transactions.

Validating messages

Since both the content author and the media vending system 200 stand to profit from increased performance of media, the ELI system 10 provides for the ELI manager 140 to validate incoming messages received from each ELI media player 420 and ensure that they are not being issued from a rogue ELI player 420.

An individual or organization may try to illicitly increase the performance tally to suit their own agenda, such as an artist trying to "bump up the charts", or a media vending system 200 trying to illegally increase media licensing revenues. In order to remove the possibility of rogue messages, the present invention provides for including a hash value with each message 50. A complex hashing algorithm that is known only to the ELI management system 100 and certified ELI media players 420 thus allows the ELI manager 140 to invalidate virtually all rogue messages 50 that are received. Flushing the message database In order to be able to safely clear the contents of the message database 430, it is advantageous that the ELI media player 420 know whether the ELI manager 140 was able to successfully receive and process each message 50. In order to achieve this certainty, it is advantageous to have a confirmation message sent back to the ELI media player that causes the flushing or clearing of the corresponding message 50 in the message database 430. Thus, the ELI media player 420 preferably does not flush the message database 430 until a confirmation response is received from the ELI manager 140 indicative of the successful receipt and processing of the corresponding message 50.

Thus, to ensure reliable reporting of performance data, the ELI media player 420 should preferably allow for the possibility that a message 50 that is sent is not successfully processed. Since a message 50 may need to resent, the present invention can also implement the confirmation message that will cause the ELI media player 420 to flush or clear the message database 430 of any messages 50. Accordingly, since messages 50 will not be flushed from the message database 430 until the confirmation response is received, if a confirmation response is not received within some interval of the initial message 50 being transmitted, a duplicate message 50 will be sent to the ELI manager 140 by the media player 420. Further, the ELI manager 140 should also be able to recognize incoming resent message 50 that may already have been processed. This is preferably accomplished using a unique hashed identifier for each message. This hashed identifier is preferably the same as the hash that is used to validate incoming messages 50 and identify rogue messages.

The ELI manager 140 will preferably store in the performance data section 164 of the license database 160 a list of ELI identifiers for all messages 50 that have been received. Each time a new message 50 is received, the identifier of the incoming message 50 will be looked up inside this list and, if present, the performance data from the incoming message 50 will not be reentered into the performance data section 164 of the license database 160. The

ELI manager 140, in its response to the ELI media player 420, will send the confirmation response, as just previously described, indicating that the message 50 was processed. If the media player 420 is disconnected from the network before receiving the ELI manager 140's response, or for whatever other reason is not able to receive the confirmation response, then the player 420 will not flush the message database 430 and the message 50 (or groups of messages 50) will be resent again the next time the player 420 attempts to clear the message database 430. This process will be repeated until the player 420 is able to receive a confirmation response from the ELI manager 140 and then flush the message database 430. Pay-per-play

Although a pay-per-play financial model is not the focus of the ELI system 10, the ELI system 10 does also not preclude this financial model from being implemented. In order to implement a pay-per-play model, a modified ELI system 800, illustrated in Fig 9, is preferably implemented. In the modified ELI system 800, the media vendor system 200 will contain digital media for distribution to potential pay per play viewers. Descriptions of the digital media available will be available, such that a decision can be made whether to request, obtain and thereby be able to experience the digital media work. Once the stamped license media 30 is received by the media gatherer module 830 of the pay per play module 810, a pay per play viewer 840, which is essentially the media receiver system 400 described in earlier embodiments, is used to receive the stamped license media and allow the viewer to experience it.

The media gatherer module 830 is responsible for browsing and acquiring stamped license media 30 from a media vending system 200. In this embodiment, however, preview media 40 will not typically be provided. Rather, either the displays describing the work such as described previously will be available, or a short sample of the digital media that is requested may be available for viewing. Each time the user wishes to experience the entire work, the corresponding stamped license media 30 is then delivered, via the media gatherer module 830, to the pay per play viewer system 840. The system 840 also includes offline media cache 850 (that corresponds to the previously mentioned general purpose file system) that stores the stamped license media 30. In this embodiment, the contents of the pending message database 430 accumulate while the pay per view player 840 is offline. When the pay per view player 840 is subsequently connected online, the contents of the pending message database 430 will be transmitted to the pending message reporter 860, which will then communicate with the ELI manager 140 as previously described to ensure that proper accounting takes place. Alternatively, the contents of the pending message database can be transmitted directly to the ELI manager 140 as has been previously described.

According to this pay per play viewer system 840, therefore, there are a number of ways that the stamped license media 40 can be programmed in order to allow the viewer to experience it. For instance, payment may occur at the time the viewer, using the media gatherer, decides it would like to experience the work. The viewer will request a license using the media gatherer module 830, which license will be granted if the corresponding fee is paid. Accordingly, the stamped license media will be transmitted once payment is made, and will contain rules that permit, for example, one play. In this embodiment, the messaging described previously is not needed.

Alternatively, however, payment may be made based upon the number of times the work is experienced, in which case the messaging described previously is used in order to determine the total amount owed by a viewer for experiencing the same work more than once or different works. In such case, the contents of the pending message database can be forwarded to the pending message reporter 860 for reporting to the ELI manager 140 or to the ELI manager 140 directly from the pending message database 420. Delivering messages through the pending message reporter 860 has particular utility when a number of different pay per play viewers 840 are associated with a single media gatherer module, such as in an arcade setting.

While the present invention has been described herein with reference to particular embodiments thereof, a latitude of modification, various changes and substitutions are intended in the foregoing disclosure, and it will be appreciated that in some instances some features of the invention will be employed without a corresponding use of other features without departing from the spirit and scope of the invention as set forth in the appended claims.

Claims

We claim:

1. A method of managing the distribution of digital media over a network comprising the steps of: electronically stamping at an information collection center each piece of digital media to obtain stamped licensed media to be distributed, said stamping including associating a broadcaster network location identifier, a license identifier and an information collection center network location identifier with the digital media; storing in a first memory location associated with the information collection center the broadcast network location identifier and the license identifier for each piece of digital media to be distributed; transmitting each piece of stamped licensed media to a broadcasting system associated with the broadcast network location identifier; broadcasting selected ones of the stamped licensed media using the broadcasting system, such that each selected one of the stamped licensed digital media is received by a remotely located computer associated with a user; causing the user to experience the selected one licensed digital media; and transmitting a message from the remotely located computer to the information collection center using the information collection center network location identifier as a destination address and including in the message the license number and an indication of an actual broadcast network location after completion of said step of causing.

2. A method according to claim 1, such that in the step of broadcasting, the stamped licensed digital media is received by the remotely located user without a monetary fee being incurred by the user.

3. A method according to claim 1, wherein the each message further includes an indication of whether the stamped license media was played in accordance with rules embedded in the stamped license media, and further comprising the steps of: receiving the message at the information collection center; and generating a plurality of reports each indicating the number of times certain ones of said stamped licensed media have been played.

4. A method according to claim 3 wherein each of the plurality of reports contains information relating to stamped licensed media that has been broadcast from one broadcast system, such that each broadcast system receives one of the reports.

5. A method according to claim 1, wherein said step of stamping further includes the step of stamping rules into each said stamped licensed media, said rules capable of being set to prohibit play of the stamped license media if the stamped license media is broadcast from a location other than the associated broadcaster network location identifier.

6. A method according to claim 1, wherein the step of stamping further includes the step of encrypting certain portions of the stamped licensed media, and the step of causing includes the steps of decrypting the encrypted portions of the stamped licensed media.

7. A method according to claim 1, wherein said step of transmitting includes the step of generating a validation code used to check the integrity of the message.

8. A method according to claim 1 wherein the broadcast network location identifier is a URL.

9. A method according to claim 1 wherein the information collection center network location identifier is a URL.

10. A method of broadcasting in which digital media owned by an owner is electronically stamped at an information collection center, and information relating to a number of times that the digital media has been broadcast by a broadcaster is received at the information collection center, comprising the steps of: receiving at a broadcasting system stamped preview media that allows a broadcaster to preview the stamped preview media, the stamped preview media containing rules which prohibit playback of stamped preview media if broadcast by the broadcaster; receiving at the broadcast system stamped license media that allows the broadcaster to broadcast the stamped license media from a specified network location, the stamped license media containing an indicator of the specified network location, and rules which are capable of being set to prohibit play of the stamped license media if the stamped license media is broadcast from a location other than the specified network location; and broadcasting the stamped license media from the specified network location.

11. A method according to claim 10 wherein the step of transmitting takes place when a user visits the network location associated with broadcaster; and wherein the stamped digital media relates to sound and is played while the user visits the network location associated with the broadcaster.

12. A method according to claim 10 further comprising the step of presenting a visual indicator relating to the stamped license media at the network location such that, upon a user's selection of the visual indicator, the step of broadcasting will take place.

13. A method according to claim 10 wherein the stamped license media is obtained in response to successful negotiation of a license by the broadcaster with at least one of the owner and a representative of the owner of the stamped license media.

14. A method according to claim 10, further comprising the step of the broadcaster receiving a report indicating the number of times that the stamped license media has been played.

15. A method according to claim 14 wherein said report is generated after a predetermined duration has passed.

16. A method according to claim 11 wherein the report is generated after the stamped license media has been played a predetermined number of times.

17. A method according to claim 10, further comprising the step of the broadcaster receiving a report indicating the number of times that the stamped license media has been attempted to be played in violation of the rules.

18. A method according to claim 17 wherein the report further includes an indication of a broadcast location that the stamped license media has been broadcast from in violation of the rules.

19. A method according to claim 10, further comprising the step of the broadcaster receiving a report indicating the number of times that the stamped license media has been played in violation of the rules.

20. A method according to claim 19 wherein the report further includes an indication of a broadcast location that the stamped license media has been broadcast from in violation of the rules.

21. A method according to claim 10 wherein the rules prohibit play of the stamped license media if the stamped license media is broadcast from a location other than the specified network location.

22. A method according to claim 10 wherein the indicator of the specified network location is a URL.

23. A method of distributing digital media owned by an owner from a vendor system owned by a vendor comprising the steps of: transmitting digital media to an information collection center for electronic preview stamping; receiving from the information collection center stamped preview media, said stamped preview media including an associated broadcaster network location identifier, a license identifier, an information collection center network location identifier and rules which can be set to prohibit playback of stamped preview media if broadcast by a broadcaster; transmitting, upon receipt of a first broadcaster request, said stamped preview media so that the broadcaster can preview the stamped preview media; transmitting the digital media to an information collection center for electronic license stamping; receiving from the information collection center stamped license media, said stamped license media including a specified network location identifier, a license identifier, an information collection center network location identifier, and rules which are capable of being set to prohibit play of the stamped license media if the stamped license media is broadcast from a location other than the specified network location; and transmitting to the broadcast system stamped license media that allows the broadcaster to broadcast the stamped license media from the specified network location.

24. A method according to claim 23 wherein the stamped license media is obtained in response to successful negotiation of a license by the broadcaster with the vendor of the stamped license media.

25. A method according to claim 23, further comprising the step of the vendor receiving a report indicating the number of times that the stamped license media has been played.

26. A method according to claim 25 wherein said report is generated after a predetermined duration has passed.

27. A method according to claim 25 wherein the report is generated after the stamped license media has been played a predetermined number of times.

28. A method according to claim 23, further comprising the step of the vendor receiving a report indicating the number of times that the stamped license media has been attempted to be played in violation of the rules.

29. A method according to claim 28 wherein the report further includes an indication of a broadcast location that the stamped license media has been broadcast from in violation of the rules.

30. A method according to claim 23, further comprising the step of the vendor receiving a report indicating the number of times that the stamped license media has been played in violation of the rules.

31. A method according to claim 30 wherein the report further includes an indication of a broadcast location that the stamped license media has been broadcast from in violation of the rules.

32. A method according to claim 23 wherein the rules prohibit play of the stamped license media if the stamped license media is broadcast from a location other than the specified network location.

33. A method according to claim 23 wherein the broadcast network location identifier is a URL.

34. A method according to claim 23 wherein the information collection center network location identifier is a URL.

35. A method of managing the distribution of digital media over a network so that it can be experienced by a user using a remotely located viewer system comprising the steps of: electronically stamping at an information collection center each piece of digital media to obtain stamped licensed media to be distributed, said stamping including associating a license identifier and playback rules with the digital media; transmitting the stamped licensed media to a vendor system capable of distributing the stamped licensed media; transmitting a selected one of the stamped licensed media from the vendor system to a remotely located viewer system upon a vendor's receipt of a license grant; causing the user to experience the selected one licensed digital media using the remotely located viewer system if the playback rules have been satisfied; and causing the user to provide payment to the vendor for experiencing the one licensed digital media.

36. A method according to claim 35 wherein the step of electronically stamping includes associating an information collection center network location identifier with the digital media, and the step of causing payment includes the steps of: transmitting a message from the remotely located viewer system to the information collection center using the information collection center network location identifier as a destination address and including in the message the license number and an indication that the licensed digital media has been experienced; generating a report at the information collection center indicating that the user has experienced the work; transmitting the report to the vendor system; billing the user for having experienced the work using the report; and updating the vendor system to indicate payment from the user has been received.