BACKGROUND OF THE INVENTION The invention relates to a system and method for managing content distribution to an audience and, more particularly, to a system and method for regulating access to network-based events such as a method for issuing electronic tickets to specific customers or clients, and accepting redemption of those tickets, thereby permitting customers or clients having valid electronic tickets to access the network-based events.

The Internet is a loose network of connected computers spread throughout the world. A message can be sent from any computer on the Internet to any other by specifying a destination address and passing the message from computer to computer via a series of"hops."Each computer, router, or "node"on the Internet has a unique Internet address. When an intermediate computer or router receives a message in transit, the computer checks the intended destination of the message and passes it along accordingly.

The Internet is growing, in terms of both size and sophistication, at a rapid rate. In the past, most users of the Internet were academic, research, or institutional users; the Internet was primarily used at that time to transmit and receive electronic mail and network news and to allow transfer of computer files. However, since the introduction of the World Wide Web (also known as the"Web" or"WWW") several years ago, the Internet has begun to host increasing amounts of other types of data of general interest, namely representations of images and articles, audiovisual and multimedia content, etc.

The Web protocol and language establish a graphical means to navigate the Internet."Web pages,"often consisting primarily of text and graphical material, are

stored on numerous computers, known as"Web servers," throughout the Internet. A software program known as a "browser"can be used to access and view Web pages across the Internet by specifying the location (i. e. Internet address) of the desired Web page. When a Web page is accessed, its information is transmitted from the remote computer (server or delivery site), wherever in the world it may be located, across the Internet, to the user.

In recent times, the Web has begun to host highly sophisticated types of multimedia content, such as audio and video data, and computer software. Compared to first generation Web content, namely text and still images, audio clips, video clips, and software programs have extremely high storage and bandwidth requirements.

At present, it is difficult, if not impossible, to provide sustained high-speed transmission of large audio/video files over a multi-node link on the Internet.

Because the data is often transferred from afar, many factors can cause the delay or even loss of parts or all of a transmission. It is generally not critical if a user experiences minor delays in receiving small graphic or text files. However, it is recognized that real-time data such as video has very specific and stringent timing requirements for data transfer and display.

Unfortunately, the present design of traditional Internet-like data networks is based on the principle that delays and significant data transmission rate variations are acceptable for ordinary data (e. g. text and still images).

Consequently, because of the high value of permitting access to text and graphical information from locations around the world, such transmission defects are considered acceptable, and the base capacity of the Internet is somewhat "oversubscribed"to reduce data transmission costs. In other words, the timeliness of network data transmission has been significantly compromised in order to render relatively insignificant the aggregate cost of long distance communication connections.

In order to successfully transfer audio-video data across a message-oriented network such as the Internet, for any more than a few users, network resources should be committed in a manner facilitating timeliness of transmittal. A system using committed network resources generally cannot take advantage of the existing pricing method of shared networks like the Internet, since it cannot participate in the sharing of network resources on a data packet by data packet basis. Video data must be transmitted to the exclusion of lower-priority data. Transmission costs thus become significant, especially when the connection is "long distance"or when the connection is continued over an extended period of time.

As discussed above, a browser program can be used to access and view Web pages across the Internet by specifying the location (i. e. Internet address) of the desired Web page, or more commonly, by"hotlinking"to Web pages.

Common browsers are Lynx, NCSA Mosaic, Netscape Navigator, and Microsoft Internet Explorer. The desired Web page is specified by a uniform resource locator ("URL"), indicating the precise location of the file using the syntax "http://internet. address/directory/filename. html".

Web pages are generally described, in terms of layout and content, by way of a language known as"HTML" (HyperText Markup Language). Any particular computer linked to the Internet can store one or more Web pages, i. e. computer files in HTML format, for access by users.

Hotlinking from one HTML Web page to another is accomplished as follows. The user first accesses a Web page having a known address, often on the computer located at the user's ISP (Internet Service Provider). The ISP is the organization providing Internet connectivity to the user.

That Web page can contain, in addition to textual and visual data specified in HTML format,"links,"or embedded information (in the form of URLs) pointing to the Internet addresses of other Web pages, often on other computers throughout the Internet. The user, by selecting a link

(often by pointing and clicking with a mouse), can then access other Web pages, which can in turn contain further data and/or additional links.

Various extensions to HTML, such as the EMBED tag, allow references to other data to be embedded into Web pages. Some browsers are not capable of handling data other than text and images. Other browsers can handle the data in various ways. NCSA Mosaic, for example, handles references to unknown types of data by allowing the data to be downloaded to the user's computer, and then optionally invoking an external program to view or manipulate the data.

Recent releases of Netscape Navigator and Microsoft Internet Explorer take the concept one step further: a browser extension, or"plug-in,"can be automatically invoked to handle the data as it is received from the remote Web page.

Other means, such as network program"applets"written in the Java language (or a similar language), can be used to extend the functionality of the browser environment or network.

Traditionally, outside of the Internet, the primary method for communicating electronically with a substantial number of customers or users has been broadcasting. Radio, television, and other media all use various forms of broadcasting. Although it is possible to reach large numbers of people this way, it is difficult to regulate distribution and receipt of the content.

In cable television systems, the unauthorized receipt of content is regulated by either blocking the signal before it reaches unauthorized individuals, or by encoding the transmissions and providing authorized individuals with decoders. Both approaches are capital-intensive, as blocking equipment must be installed for each unauthorized viewer in the former case, and decoders must be provided to authorized viewers in the latter case.

It is also possible to reach large numbers of customers by replicating content and sending individual copies to each customer. Printed matter, such as newspapers, magazines are

distributed this way. Videotape rentals may also be considered to fall within this model. The Internet, while it uses electronic distribution like traditional broadcasting, acts in most cases more like the distribution of replicated content. Using the traditional model, Internet communications generally will not reach their intended destination unless they are specifically transmitted to that user. This method of reaching a large number of customers is inefficient, however. As described above, audio and video transmissions over the Internet are bandwidth intensive, and sending such data to a large number of customers can easily oversubscribe network capacity.

Still, it is often desirable to"unicast"streams to large numbers of users since much information can be collected about the user in this one to one communication.

The Internet is the most measurable medium in existence. It is absolutely the goal of the publisher to know exactly why and how their viewers used the content stream (s). It is this specific knowledge of the user that establishes significant value to the provider and its advertisers.

Unfortunately, Internet Multicasting or broadcasting forfeits the opportunity of user data while not capitalizing on the truly efficient cost advantages of the traditional broadcast infrastructure.

The actual problem is three fold. One. Whereas broadcast television in the early days had only three networks, we have now 50 broadcast and cable stations and millions of Web sites. Thus, the competition for viewership is fierce. Even in the best scenario, it is difficult to capture and hold viewers. This new Internet community of viewers migrates from site to site. No one has a favorite channel. This means that very few sites have regular or consistent traffic. In fact, to collect traffic at all, sites have to become increasingly specialized. When there were 3 broadcast networks they each carried variety content.

Now that there are 50 cable stations, each one has to have specialty or niche content in order to attract and maintain

an audience. Since these Internet"TV stations"have smaller audiences, they must increase the value of their audience to the advertiser by increasing their understanding of each viewer in the audience.

Second. As content becomes more specialized, the body of data changes less frequently. Therefore, the viewer has less reason to frequently return to the site. Yet broadcast television is about creating habit. What kind of viewership would Seinfeld have if its show date & time varied week to week? No viewer would set aside the time to watch the program. Audience building is about creating habit. If the content is not changing regularly than one has little hope of creating habit. The publisher's only hope is to reach out and bring the viewer back mechanically.

So, the goals of Internet publishing have to include habit-forming processes or mechanisms that replace habit while at the same time capturing as much information about the viewer as possible.

Third. Unicast streams are profoundly expensive at any level of data rate. The optimal configuration would be to know exactly how many streams are required to support the program for the attending audience. It's like building airliners for just the number of travelers of that day. If this were possible, airline travel would be significantly cheaper. Similarly, a unicast network configuration would also benefit with this type of planning optimization.

The early years of the Internet created navigation structures that merely funneled people by Web content. That is, sites get out and establish what is routinely called "distribution."Distribution is a collection of links that siphon people off of one site on to new sites or pages.

This traffic translates directly into dollars for the Web publisher. To be truly effective however, Web publishers need to create"programming"processes that more dynamically steer viewers to the type of content the user desires to see. The result must become something akin to an amusement park ride. The user needs to be"driven"past sites and

information interesting to the user, rather than be exposed to a continuous stream of loosely related messages and images.

The principle shift for sites is to present Web site facades that deliver different messages for different users.

Advertising on the Web has already made this shift as have Internet search engines with content preferencing. The goal in communication is to speak to each user. What do you do for them? The problem is that the broader the message, the smaller the impact it has on the specific user. The new mission of the Internet communicator is to both sharpen one's point while getting to that point much faster. Focus and brevity are the catchwords of a viable site.

There is also an Internet-based form of broadcasting, which in one embodiment is called"multicasting."In this case, an Internet-based communication can reach a large number of users, but can also be intercepted easily by individuals who are not authorized to do so. Internet broadcasts, like traditional television broadcasts, are difficult to regulate. Audio and video content distributed this way can be encrypted or specially encoded to prevent unauthorized viewing, but this often does not present desirable results. The computational and storage capabilities of many computer systems in common use today are over-burdened or fully utilized simply in the process of receiving and decoding audio and video content. The extra computational resources necessary to decrypt audio and/or video data, as well, frequently results in degraded content quality for a majority of users.

Accordingly, there is a need for the ability to regulate access to Internet content that can be distributed to a potentially large number of individuals. This ability to regulate access should be robust, capable of tracking usage, and easy to use.

SUMMARY OF THE INVENTION The invention relates to a system and method for managing content distribution. In one embodiment, the invention defines a system and method for both regulating and promoting access to Internet content or other events by fostering reservations and issuing electronic tickets to authorized individuals or ideal audiences in advance of the event.

A presently preferred embodiment of the invention includes an event guide, which includes information on when events will take place, what content is included, cost, and restrictions on attendance. The event guide is also used as an"alarm clock"and virtual host for the collection of pre- registered viewers prior to the commencement of the event.

The goal is to identify end users and collect them as the audience for the event.

Limiting event attendance to a certain number of authorized individuals is contrary to current Internet paradigms, but is useful for several reasons. First, access may be restricted to those individuals who have paid for it, as in"pay-per-view"television. This tends to increase the value of the event. Second, it allows the number of attendees to be predicted, so that equipment and bandwidth needs can be assessed prior to the event. Because of this, the drain on scarce network resources can be regulated, resulting in more efficient allocation of network resources.

Third, the individuals who have the greatest interest in an event can be targeted. Not only does the sequence of affirmative steps required to procure and present an electronic ticket deter the most casual users, but the registration process of the invention allows demographic data to be collected for all users who request tickets.

Moreover, because tickets can be redeemed at the time of the event, the invention can also track attendance; a benefit of interest to event sponsors. Maybe more importantly, a goal of all"selling"is to create scarcity of the item to be

sold. The greater the perceived scarcity, the higher the market value of the item.

Another goal of the system is to reduce cost of promotion. Ordinary promotion of an event is transitory and will diminish dramatically once the event has come and gone.

If the content provider instead focuses on collecting viewers for each event using the system described here, the total magnitude of viewers will increase as a consequence of the number of events staged. This existing base of end users (subscribers) can then be used by the content provider to laterally grow the type and diversity of their content offerings.

In one embodiment, the invention also includes a method to encourage participation once tickets have been acquired.

Specifically, if a user does not use tickets he has reserved, even when there was no monetary cost for the tickets, participation in future events may be denied or conditioned.

With the system and method of the invention, payment possibilities are flexible, and are not even required.

Certain tickets may be charged to the requesting user's credit card, and certain other tickets may be acquired free of charge, as desired by the operator of the ticketing system. Charges may be made to the user at any time, when reservations are made, when a ticket is acquired, or when the event takes place.

To accomplish the method of the invention, the user's terminal exchanges information with a database server and a registration server by way of a custom ticketing program operative for example, at the user terminal. Reservations are requested from the database server. If the user is authorized to attend the event, and space is available, then the registration server processes and issues the user's ticket. When the event occurs, the user redeems the ticket by presenting a code to the server. If the code is authorized, the user terminal will begin receiving data.

BRIEF DESCRIPTION OF THE DRAWINGS FIGURE 1 is a block diagram illustrating several functional blocks, namely a plurality of servers and at least one user terminal, as used in an embodiment of the invention; FIGURE 2 is a block diagram illustrating the intercommunication among the various blocks illustrated in FIGURE 1; FIGURE 3 is a flowchart illustrating a method by which a reservation is requested according to an embodiment of the invention; FIGURE 4 is a flowchart illustrating a method by which ticket availability is confirmed according to an embodiment of the invention; FIGURE 5 is a flowchart illustrating a method by which attendance at an event is authorized according to an embodiment of the invention; FIGURE 6 is a diagram illustrating one possible user interface method for an embodiment of the invention; FIGURE 7 is a diagram illustrating operations related to how information may travel through an audience management system constructed according to an embodiment of the invention; FIGURE 8 is a diagram illustrating operations related to registering in an audience management system constructed according to an embodiment of the invention; FIGURE 9 is a diagram of a screen display that describes new stories and events in an audience management system constructed according to an embodiment of the invention; FIGURE 10 is a diagram illustrating operations related to viewing content and recording activity in an audience management system constructed according to an embodiment of the invention; FIGURE 11 is a diagram of two screen displays that describe a channel changer in an audience management system constructed according to an embodiment of the invention;

FIGURE 12 is a diagram of two screen displays that describe a ticket minder in an audience management system constructed according to an embodiment of the invention; FIGURE 13 is a diagram of two screen displays that describe the process of accessing an about screen in an audience management system constructed according to an embodiment of the invention; FIGURE 14 is a diagram of two screen displays that describe the process of accessing a help screen in an audience management system constructed according to an embodiment of the invention; FIGURE 15 is a diagram of a navigation screen display in an audience management system constructed according to an embodiment of the invention; FIGURE 16 is a diagram of a screen display that describes a method of sorting items in an audience management system constructed according to an embodiment of the invention; FIGURE 17 is a diagram of a screen display that describes a method of displaying events in an audience management system constructed according to an embodiment of the invention; FIGURE 18 is a diagram of a screen display that describes a method of confirming a ticket in an audience management system constructed according to an embodiment of the invention; FIGURE 19 is a diagram illustrating operations related to obtaining a ticket in an audience management system constructed according to an embodiment of the invention; FIGURE 20 is a diagram of a screen display that describes a method of accessing more information about an event in an audience management system constructed according to an embodiment of the invention; FIGURE 21 is a diagram illustrating operations related to registering a publisher in an audience management system constructed according to an embodiment of the invention;

FIGURE 22 is a diagram of a main publisher screen display in an audience management system constructed according to an embodiment of the invention; FIGURE 23 is a diagram of a screen display that describes a method of creating a new entry in an audience management system constructed according to an embodiment of the invention; FIGURE 24 is a diagram illustrating operations related to creating a new entry in an audience management system constructed according to an embodiment of the invention; FIGURE 25 is a diagram illustrating operations related to uploading an entry in an audience management system constructed according to an embodiment of the invention; FIGURE 26 is a diagram of a choice list screen display in an audience management system constructed according to an embodiment of the invention; FIGURE 27 is a diagram illustrating operations related to downloading statistics in an audience management system constructed according to an embodiment of the invention; FIGURE 28 is a diagram of two screen displays that describe the demand reports in an audience management system constructed according to an embodiment of the invention; and FIGURE 29 is a diagram of a screen display that describes a method of uploading media files in an audience management system constructed according to an embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION The invention is described below, with reference to several detailed illustrative embodiments. It will be apparent that the invention can be embodied in a wide variety of forms, some of which may be quite different from those of the disclosed embodiments. Consequently, the specific structural and functional details disclosed herein are merely representative and do not limit the scope of the invention.

Referring initially to FIG. 1, the Internet 110, which is intended to be representative of wide-area communications networks in general, is depicted in the center. The Internet is known to be an interconnected network of a large number of computers. Although Internet-connected computers that are"geographically"near each other can be "electronically"near each other on the Internet, such is not usually the case. However, one computer connected to the Internet can communicate with any other computer connected to the Internet; the message will most likely travel over a path comprising a sequence of links, or "hops,"between computers that are directly connected to each other.

A user terminal 112 is also depicted in FIG. 1. The user terminal 112 is connected to the Internet 110 via an Internet service provider (ISP), which is typically a computer, router, or terminal server connected to the Internet 110. Only one user terminal is shown; however, it should be recognized that the number of concurrent users of the invention is potentially unlimited.

Also connected to the Internet 110 are a ticketing server 114, a database server 116, a registration server 118, and an event server 120. As will be described in further detail below, these servers are employed in a system according to the invention to issue and process electronic tickets.

A browser program 122, as is well known in the art, is adapted to run on the user terminal 112. This browser program 122 is capable of sending and receiving data from the Internet, and is further capable of displaying data in a graphical format. Examples of popular browser programs in common use are Netscape Navigator and Microsoft Internet Explorer. As is also well known in the art, the browser program 122 is capable of interfacing with an e-mail program 124.

A custom ticketing program 126 is provided for use with the invention. In a presently preferred embodiment, the

ticketing program 126 is in the form of a"plug-in"for use in cooperation with the browser. Alternatively, the ticketing program may be a standalone program, an"ActiveX control"for use with Microsoft Internet Explorer, or a Java application or applet for use in cooperation with a browser or operating system capable of interpreting or compiling programs in the Java language.

The functional relationships among the various programs running user terminal 112, the ticketing server 114, the database server 116, the registration server 118, and the event server 120 are illustrated in Figure 2.

The Ticketing/Guide program 126 first interacts with the ticketing server 114; requests for information on ticketed events are sent from the user terminal 112 to the ticketing server 114 (arrow 210). The ticketing server 114 responds by sending back a list of events.

Preregistration information and requests for reservations are sent from the Ticketing/Guide program 126 to the database server 116 (arrow 214). After a request is received, the database server 116 sends a confirmation message and information on the event back to the browser program 122 (arrow 216). The database server 116 also sends an e-mail confirmation message to the e-mail program 124 (arrow 218).

As will be described below with reference to Figure 4, the e-mail confirmation message requires a response by the user. That response is sent from the e-mail program 124 (or optionally the browser program 122) to the database server 116 (arrow 220). The database server communicates its receipt of the user's response to the registration server 118 (arrow 221), which in turn interacts with the browser program 122 to communicate reminders, payment information, and any other desired information between the user terminal 112 and the registration server 118 (arrow 222). Once payment and any other additional details have been processed by the registration server, the electronic ticket, namely an authorization for the user to attend the event, is sent from

the registration server 118 to the ticketing program 126 (arrow 224); the event server 120 is also advised of the user's authorization (arrow 225).

At or about the time of the event to be attended, the user terminal 112 is connected to the event server 120. The ticketing program 126 redeems the electronic ticket by presenting the authorization code previously received from the registration server 118 (arrow 226). If authorization is granted, the event server 120 then begins to send the event data to the browser program (arrow 228).

Figure 3 illustrates in further detail the sequence of steps performed by the invention at the time a user identifies and requests to participate in an event.

Initially, in a preferred embodiment of the invention, the user preregisters to use the ticketing service (step 310).

This is accomplished by having the user send his full name, address, telephone number, payment information (such as a credit card number), and any other desired information to the database server 116, where that information is stored for later use. After preregistration has been completed, the user is free to use the ticketing service.

When the user has identified an event of interest (step 312), for example a live concert presented in audio and video, the user indicates his selection to the ticketing program 126 or to the browser program 122, e. g., by clicking on a button corresponding to the selected event.

In this embodiment of the invention, the event can be identified by one of at least three ways: by noting its listing in the event guide presented by the ticketing program 126 (Figs. 1 and 2), by visiting a Web site that advertises the event, or by word of mouth. In the first case, the ticketing program 126 is used to browse or search a list of upcoming events; this list is typically (but need not be) received periodically or upon request from the ticketing server 126. With the first alternative, the ticketing program 126 is already being run, and selecting an

event in the listing of events will cause the ticketing program to proceed in the ticketing process.

In an embodiment of the second case, when the user notes the existence of an event via a Web advertisement, the advertisement typically would include a hyperlink to another Web page, which includes code (e. g., the EMBED statement) adapted to invoke the ticketing program 126. When this approach is followed, the code may also include information on which event is desired, thereby enabling the ticketing program 126 to proceed in the ticketing process without further input from the user.

In the third case, when the user learns of an event from external sources, such as word of mouth, the user can either search the listing of events with the ticketing program 126 or can enter a specific Internet address into the browser program 122, thereby loading a Web page containing code adapted to invoke the ticketing program, as in the second alternative described above.

A reservation is then requested by transmitting the user's request from the user terminal 112 to the database server 116 (step 314). The database server 116 then checks for the availability of tickets to the event (step 316).

For example, a concert event might be limited to 10,000 attendees. In this case, if the user is one of the first 10,000 individuals to request a reservation, then a message confirming ticket availability is immediately sent via e- mail to the user terminal (step 318). If not, then a message confirming placement on a waiting list can be sent to the user; when (and if) space becomes available later, the confirmation e-mail would then be sent.

Finally, a record is added to a database on the database server 116 (step 320) representative of the user's confirmation or position on the waiting list. If the user is on the waiting list, no further action need be taken unless additional spaces open up.

Figure 4 illustrates the procedure followed by the database server after a reservation request has been placed

by a user (under the procedure of Figure 3). For each user who has placed a reservation request, the database server 116 waits (step 410) until space opens up to accommodate that user, based on the user's priority. As described above, there may be a limited number of available tickets.

If some users who have previously made reservations fail to respond to their confirmation within a predetermined time period, if the event's capacity is increased, or if some previously registered users cancel their reservations (as described below), additional tickets may become available (step 412).

When a ticket becomes available, an e-mail message is sent to the user (step 414). In a presently preferred embodiment of the invention, this e-mail message includes computer code (e. g., in HTML or the Javascript language) adapted to present a response button to the user through the e-mail program 124. Many e-mail programs in common use today are capable of decoding HTML or Javascript content; several other programs are capable of automatically invoking a browser program to decode the HTML or Javascript. In either case, the user is presented with a response button, and the system awaits completion of the confirmation process (step 416) by awaiting a message from the user terminal 112, sent when the user presses the response button.

When the response has been received by the database server, a final registration page is sent to the user's browser program 122 (step 418). This registration page includes a registration program capable of interacting with the ticketing program 126. This registration program is run at the user terminal 112 (step 420); it receives the authorization code from the registration server 118 (step 422) as well as further information on the event, including a request to authorize a credit card payment, if applicable (step 424). Payment authorization is then transmitted from the user terminal 112 to the registration server (step 426), and a countdown timer is initiated (step 428) to remind the user of the event.

While the processing of a credit card payment is disclosed at step 424 above, it should be noted that payment is possible at other times during the method of the invention. For example, a payment could be made at the time a reservation is requested (step 314), or at the time of the event (see Figure 5, described below). Tickets for certain events might not be charged at all.

In one embodiment of the invention, the user is allowed to cancel a ticket reservation at any time before a ticket is received (step 426). If payment has already been made, and the cancellation is received before a threshold time or date, the system can be enabled to issue a refund to the user. Alternatively, some events may be designated as non- refundable.

As described above, at the time of the event, the user accesses the event server 120. The interaction between the user terminal 112 and the event server is described in detail with reference to Figure 5. Initially, the user activates the browser program 122 to access the event server 120 (step 510). The event server then waits (step 512) while the ticketing program 126 is activated (for example, by an EMBED code in the page referenced by the browser program 122) and the ticketing program then sends the authorization code to the event server 120. If the code received by the event server is invalid (step 514), then the user's attempt to access the event is rejected (step 516).

If the code is valid, then the user is allowed to participate (step 518).

The database server 116 is updated with information on the user's attendance (step 520), and the event data, which may be audio, video, or other information, is sent from the event server 120 to the user terminal 112 (step 522). In a preferred embodiment, once the authorization code has been presented and accepted by the event server 120, it is no longer valid for use by any other user terminal.

Accordingly, as with traditional tickets, the authorization code of the invention is usable only once.

In one embodiment of the invention, the event server 120 checks the validity of an authorization code presented to it by either checking its own internal database, based on information previously received from the registration server 118. Alternatively, the event server 120 can query the registration server 118 each time a user attempts to access an event.

In a preferred embodiment of the invention, ticket management is handled entirely by the ticketing program 126 installed at the user terminal 112. The registration server 118 automatically transfers the ticketing information to the user's ticketing program 126, and when the user accesses the event server 120 hosting the event, the ticketing program 126 automatically transmits the proper ticket, namely the necessary authorization code, to the event server 120 for verification.

However, certain manual steps may be desirable in certain circumstances. If the user successfully registers for an event at his home computer, but is away from that computer when the event is scheduled to occur, it would be desirable to provide for the ability to print or otherwise export a textual representation of the authorization code.

Accordingly, when the user attempts to access the event from a remote location, the textual representation would be requested by the event server.

Figure 6 illustrates an illustrative user interface for the ticketing program 126 of the invention. As described above, the ticketing program includes an event guide including a list 610 of upcoming events. By manipulating various controls on a graphical user interface, as is well known in the art, the user can request more information about a particular event (button 612), reserve tickets for an event (button 614), or cancel the operation of the ticketing program (button 616).

The user interface of the ticketing program 126 further includes a status area 618, in which information about previously reserved tickets can be displayed. In Figure 6,

a representation of a ticket 620 is shown, indicating that the user has already requested at least one ticket for an event. Further information on that ticket can be displayed by selecting the ticket 620 with a pointing device, as is known in the art.

In a preferred embodiment, as illustrated in Figure 6, the ticketing program is capable of displaying the event guide sorted by date (tab 622), by type of event (tab 624), or by artist or other participant (tab 626).

The ticketing method presented herein is resistant to duplication. As with traditional ticketing, each ticket or authorization code is good for only one admission to the event. Accordingly, the user who receives an electronic ticket according to the invention is responsible for the safe keeping of the ticket or authorization code. If the code is duplicated, and more than one individual attempts to gain access to the event, only the first individual will be granted access. Alternatively, other verification means can be used.

While this disclosure is directed primarily to a method for regulating access to network-based events, it should be noted that the method disclosed herein could easily be adapted to regulate access to non-network events, as well.

For example, tickets to actual live concerts, movies, airline seats, and other limited-supply items could be handled by various embodiments of the invention. In such cases, the authorization code presented to the user by the registration server would serve as a paperless ticket, and would be presented by the user to gain access.

Multiple servers, namely a ticketing server, a database server, a registration server, and an event server, are disclosed and described in detail as separate items herein.

However, it should be noted that the functions of some or all of these servers may be incorporated into one or more servers, with those functions divided among plural servers differently than disclosed herein. Moreover, the servers disclosed above may exist as distributed nodes in

communication over a network, with individual nodes performing only certain functions or sub-functions.

Functions may be allocated to single, plural, or distributed servers according to means well known in the art.

Referring now to Figures 7-29, one embodiment of a management system for managing content distribution to an audience of users will be described. The Audience Management System (AMS) is a software solution for creating and retaining online audiences for a Web site. With AMS, publishers can create and upload information from one or more HTML pages to the system network. Publishers can also gather information about their online audience or viewers through AMS by requesting usage data from the AMS Server and producing reports based on that data.

The Audience Management System also provides: Secure multimedia content delivery through the Internet; Virtual ticketing to events; Content delivery for a community of users; Content maintenance; "Branded channel"displays for publishers; and Reporting.

Audience Management System (AMS) is made up of three main components: The system network; Audience Management System: The Client (AMS: The Client); and Audience Management System: The Publisher (AMS: The Publisher).

The system network is the tool used to communicate to the client. Publishers create and upload information to the system network.

AMS: The Client is an application that runs on a personal computer. It is designed to provide easy access to secure multimedia content as set up by a Publisher.

AMS: The Publisher is designed as an organizational tool for publishers. Through an easy-to-use data entry system, the tool creates data records that are accessed by Audience clients.

In Audience Management System (AMS), there are two types of users: Clients and Publishers. Publishers create and upload information to the system network that the Clients will view.

Figure 7 describes how information travels through AMS.

1. Publisher creates and uploads information to the Staging Area.

2. The information is then downloaded to the Sybase Database on the Database 101 Machine.

3. From there, a process is run that takes the information from the Sybase Database and interprets the information into Channel Data, which is comprised of Event and Content Data.

4. The client obtains Channel Data from the AMS Server when a request is made to view data.

5. Usage Data is downloaded to the Publisher for report production.

Audience Management System: The Client Installing AMS: The Client Before installing AMS: The Client, the end user must obtain a Channel Installation package from the publisher by downloading it from the publisher's Web site, CD-ROM or diskette.

The Channel Installation package contains the data files that comprise the Channel, and program files that direct the installation. EyeQ is invoked to install the Channel into the client's copy of AMS: The Client.

If the client does not have AMS: The Client installed: 1. EyeQ is invoked to download and install the AMS: The Client prior to installing the Channel.

If the client does not have eyeQ installed: 1. EyeQ will automatically be downloaded and installed.

2. AMS: The Client will be installed.

3. Channel will be installed.

An AMS: The Client icon appears on the client's desktop simply labeled INTERVU, along with an eyeQ Multimedia Manager icon if that was not already installed. The Start menu entry for INTERVU is created or updated and entries for starting AMS: The Client as well as for uninstalling it are created, along with entries for installing and uninstalling each channel.

Channel Installation Package To create a Channel Installation package, one must create the artwork for the channel screens and controls, encapsulate them into a fast-format file, and create the . ini file, which defines the location of the controls within each screen. Also, the eyeQ install scripts for the Channel must be created. Finally, the installation program must be included.

Registering AMS: The Client Before launching AMS: The Client, it must be registered. This section explains how information is transferred from the User Registration dialog to the provider of the AMS service.

1. When AMS: The Client is first installed, a User Registration dialog appears.

The client enters: Name E-mail address Country Connection Speed Zip Code 2. The client can also select a checkbox next to the "Send me e-mail about cool stuff"to receive information via e-mail about cool stuff at the AMS provider.

3. When the client fills out the User Registration and clicks OK, the information is sent across the Internet to the AMS Server.

4. From the AMS Server, the registration information is run with a script called evreg. cgi.

5. The script, evreg. cgi, validates the user registration information and sends an e-mail message to the client with a confirmation number.

6. The client replies to the e-mail message and sends it back to the AMS Server.

7. The script, evreg. cgi, creates a password from the registration ID, User ID and e-mail address and sends another e-mail message to the client with a password.

8. When the client replies to that e-mail message, the password is sent to the AMS Server and the script, evsignupm. cgi, makes sure that the password is valid.

9. If the password is valid, a congratulations letter is sent to the client explaining that he/she is now registered.

10. If the password is invalid, then an error message is sent to the client.

11. The user registration information is stored in a text file called evreg. log.

Referring to Figure 8, the registration process includes the following steps: Step #1. Client downloads Audience Management System: The Client from the AMS provider Web site and fills out registration information.

Step #2. Client sends user registration information to AMS Server.

Step #3. Script, evreg. cgi, validates user registration information and sends e-mail message to client with a confirmation number.

Step #4. Client replies to e-mail message and sends it to AMS server. The script, evsignupm, is run to make sure that password is valid.

Step #5. Client receives an e-mail message explaining whether or not the registration process is successful.

Navigating From Screen to Screen In AMS: The Client, there are three main screens: New, Navigate and Events. After registering the copy of AMS: The Client, the New screen appears. As shown in Figure 9, this screen lists and describes the new stories and events at a particular company.

To access any of the three main screens, a client clicks on the Navigation buttons once, located on the left side of the screen. When a client clicks on a navigation button, the corresponding screen appears. For example, if a client clicks Navigate, the Navigate screen appears. If a client clicks Events, the Events screen appears.

The names of the buttons and screens are customizable by the publisher, but the underlying functionality remains the same.

Viewing Content From the New screen, a client can access information by selecting a topic and clicking Go There or by double- clicking on a topic. For example, in the NEWCO Channel, a client can find out about the latest promotions and events by selecting Promotions and Events and clicking Go There.

1. When the client clicks Go There, an Internet Browser is automatically launched to view this information.

2. Using the CGI script, evbeenthere. cgi, a message is sent to the AMS Server. The User ID and URL address of the Web page accessed by the client are stored in a log file called evhits. log.

3. The evhits. log can include the following information: Time Channel Event User ID Ticketed or Not Ticketed Event URL Address Referring to Figure 10, the viewing content and recording activity process includes the following steps: Step #1. Client launches Web Browser when he/she clicks Go There.

Step #2. CGI Script, evbeenthere. cgi, sends message to the AMS Server.

Step #3. User ID and URL address of page accessed by client is stored in a log file called, evhits. log.

Changing Channels From the three main screens in AMS: The Client, there is a Channel Changer located on the bottom left side of the screen. When the client clicks on the Channel Changer, a pop-up menu appears that lists channels that have already been installed. The client can then change the current Channel by selecting another channel from the list.

As depicted in Figure 11, the Channel was changed from NEWCO to MTV. When a client changes channels, he/she is changing the information, look and feel of the screens used in AMS: The Client.

Changing Ticket Minder Ticket Minder is located at the bottom of the screen in AMS: The Client. Ticket Minder lists the events that the client has previously signed up for from the Events Screen.

When the client clicks on Ticket Minder, a pop-up menu appears that lists the registered events. By selecting an event from the list, the Viewer invokes an Internet Browser and URL address of that particular event. See Figure 12.

By selecting Semisonic--Breaking the Speed of Sound from the Ticket Minder pop-up menu, an Internet Browser is invoked with the URL address of the event.

Accessing About Audience From the three main screens in AMS: The Client, an About button is located directly above the Channel Changer.

When a client clicks on the About button, the About Audience Screen appears. See Figure 13.

Accessing Help From the three main screens in AMS: The Client, a Help button is located directly above the Channel Changer. When

a client clicks on the Help button, an Internet Browser is invoked with the URL address of the Audience Help System.

See Figure 14. To exit out of these pages, click Return To Audience.

Navigation Screen The second main screen in AMS: The Client is the Navigation screen. See Figure 15. This screen classifies the stories and events from a Web site into different categories. It lists the categories on the left side of the screen and it lists the stories, events and descriptions on the right side of the screen. The client can change what he/she views on the right hand side of the screen by selecting different categories.

Sorting Items From the Navigation screen, the client can sort the categories that he/she wants to view alphabetically, by quantity and by date. See Figure 16. The client clicks on the Sort drop-down list, located below the Category screen, and selects Alphabetic, Quantity or Newer. The list is then sorted according to sort criterion. The client can also sort items in each category for the past 1 day, 7 days or all days by clicking the corresponding buttons.

Obtaining a Ticket for an Event The third main screen in AMS: The Client, is the Event screen.

1. To get a ticket for a specific event, select Coming Events from the main screen and click GO THERE. From there, select the event you want to attend and click Go There. See Figure 17.

2. After selecting Go There, a Confirm Ticket screen appears with your name, e-mail address and whether or not you want to be reminded about the event 10

minutes prior to it. If the information is correct, click Sign Up. If it is not correct, make the necessary changes and click Sign Up. See Figure 18.

3. After clicking Sign Up, the CGI script, evticket. cgi, verifies your information and creates a password using your e-mail address, user ID and registration ID. Then it sends the client an e-mail message with that information.

4. The client replies to the e-mail message and sends it back to the AMS Server.

5. Then the CGI script, evticket. cgi, checks the Channel Database File to see if there are any available tickets for the event.

6. If so, the CGI script increases the number of tickets sold in the Channel Database File.

7. The information gets stored in the following text file, evticket. log.

8. The information also gets sent out to the Event Database file so that the number of tickets sold can be updated.

9. Finally, an e-mail message is sent to the client explaining that they are now officially registered for the event.

Referring to Figure 19, the process of obtaining a ticket includes the following steps: Step #1. After the client clicks Go There, a Confirm Ticket screen appears with the name of the event, client's name, e-mail address and whether or not the clients wants to be reminded about the event 10 minutes before it occurs. If the information is correct, the client clicks Sign Up and the information is sent to the AMS Server.

Step #2. From the AMS Server, a CGI script evticket. cgi verifies the user information, creates a

password from the client's e-mail address, user ID and registration ID and sends an e-mail message to the client.

The e-mail message explains that the client must reply to the message if he/she wants to receive a ticket to the event.

Step #3. Client replies to the e-mail message and sends it back to the AMS Server.

Step #4. The CGI script, evticket. cgi, checks the Channel Database Files (newCo/chaninfo. dir and NewCo/chaninfo. pag) to see if there are any available tickets for the event.

Step #5. If so, the CGI script increases the number of tickets sold in the Channel Database Files.

Step #6. The information gets stored in the following text file, evticket. log.

Step #7. Finally, an e-mail message is sent to the client explaining that they are now officially registered for the event.

Accessing More Information about an Event From the Confirm Ticket screen in Events, the client clicks Event Info. See Figure 20. When a client clicks on Event Info, this will launch a Web Browser with the URL of the Event Page.

Audience Management System: The Publisher Registering AMS: The Publisher To register AMS: The Publisher, the publisher must get a Workstation ID Number and Activation Key number. To obtain these numbers, the publisher must contact the AMS provider.

In general, employees of the AMS provider will perform the following steps: 1. Go to the following Url: http://evguide. intervu. net/addclient. html.

2. From this page, enter the following information: Client Name Client Code User Name Password Channels 3. Click Submit.

The Content Producer will receive a valid workstation ID number and activation key number that he/she enters as soon as the Audience Publisher Tool is launched.

4. Publisher launches AMS: The Publisher. A registration dialog appears asking for the Workstation ID number and Activation Key number.

Publisher enters them and clicks OK.

5. The registration information is sent to the AMS Server, which looks up the Workstation ID number and Activation Key number.

6. If the information is valid, then a list of channels is sent to the Publisher's workstation from the AMS Server.

Each time the Publisher launches AMS: The Publisher, the AMS Server looks up the Workstation ID number and Activation Key number to make sure that a valid user is working with the program even though he/she is not queried for them.

Referring to Figure 21, the registering process includes the following steps: Step #1. The publisher, Workstation #1, installs AMS: The Publisher. After installation is completed, the

registration dialog appears. The publisher must enter the Workstation ID Number and Activation Key Number that is obtained from the following site: http://evquide. intervu. net/addclient. html.

Step #2. After the publisher enters this information in the registration dialog and clicks OK, the information is sent to the Global Master Database.

The Global Master Database consists of multiple databases: Channel Database and User Database. The Channel Database consists of the following files: chaninfo. mtv. pag and chaninfo. mts. dir. The User Database consists of the following files: userinfo. mtv. pag and userinfo. mtv. dir.

Note that MTV is the client code and changes according to client accessing the information.

Step #3. When the publisher clicks OK, the information is uploaded to following inbound directories across the Web: /home/httpd/html/inbound/. htaccess /home/www/evglogs/clients/. htpasswd /home/www/evglogs/clients/. htgroup Step #4. Channels are downloaded to the Publisher; if there is an error in registration, an error message is returned to the Publisher.

Main Screen After registering AMS: The Publisher, the main screen appears. From this screen, a publisher can choose to perform the following functions: Create New Entry Edit Entry Delete Entry Upload Entry Arrange"Hot"Entry Identify Entry by Keyword

Download Statistics of Viewers Create Content Demand Reports Create Top 20 Reports Upload Media Files to INTERVU network Simply select an entry and click Run. See Figure 22.

When the publisher selects an entry and clicks Run, the corresponding screen appears.

Creating New Entry 1. From the main screen in AMS: The Publisher, select Create New Entry and click Run. The New Entry screen appears. See Figure 23.

2. Enter the following information set forth in Table 1:

Field:Description: TitleEntertheTitleofthe entry. DescriptionEnterabrief descriptionofentry. LinkEntertheURLofthe site. PostFromEntertheStartDateof theEntry. PostThroughEntertheEndDateof theEntry. Type:Video;Audio;EntertheTypeofentry HTMLitisbyselectingoneof thecorrespondingradio buttons:Video,Audioor HTML. Options:Hot;DisableSelecttheHotcheckbox ifyouwanttheentryto appearinthe"What'sHotor What'sNew"category. Categories:KeywordEnterthecategories

LiveEventSelectthischeckboxif theentryisgoingtobea liveevent.Thisenables thefollowingoptions:Event Link,EventDate,Duration, TicketType,Numberof Seats,TicketMinderand WarningBeforeEvent. EventLinkEntertheURLofthe site. EventDateEntertheDateofthe event. DurationEnterthelength (duration)oftheevent. TicketType:Chooseiftheeventis Restricted;OpenEventrestrictedoropen. NumberofSeatsEnterthenumberof seatsfortheevent. TicketMinderSelectorDeselect TicketMinderoption. WarningBeforeEventAllowsyoutoreceivea reminderbeforeanevent. NextClickthisbuttonto createanotherentry. CloseClickthisbuttonto saveandclosethe informationyoujustentered offline. CancelClickthisbuttonto canceltheentry.

TABLE 1 3. Click Close.

New Entry screen closes and the information is saved offline in the local database.

Referring to Figure 24, the process of creating a new entry includes the following steps: Step 1. Entry is saved offline in local Database.

Step 2. It is uploaded to Global Master Database when Publisher uploads entry. When a Publisher uploads an entry, he/she pulls out from the local database and uploads it to the Global Master Database as an ASCII Test File. As discussed above, the Global Master Database consists of multiple databases.

Editing Entry 1. From the main screen in AMS: The Publisher, select Edit Entry and click Run. The Select Entry for Edit screen appears.

2. Select the entry to be edited and click Select.

The Edit Entry screen appears.

3. Make any changes necessary and click Close.

The changes are saved offline into a local database.

When the publisher uploads the entry, it is uploaded to the Global Master Database.

Delete Entry 1. From the main screen in AMS: The Publisher, select Delete Entry and click Run. The Select Entry for Delete screen appears.

2. Select the entry that you want to delete and click Select.

3. A pop-up dialog appears asking if you are sure that you want to delete this entry. Click YES if you are sure that this is the entry you want to delete.

The entry is deleted from a local database. When the publisher uploads the entries, it is deleted from the Global Master Database.

Uploading Entry 1. From the main screen in AMS: The Publisher, select Upload Entry and click Run. The Upload Media Files screen appears.

2. Enter your User Name and Password and then click Start.

3. The information is uploaded to following inbound directories across the Web: /home/httpd/htm/inbound/. htaccess /home/www/evglogs/clients/. htpasswd /home/www/evglogs/clients/. htgroup 4. A CGI script, workstation. cgi, verifies your User Name and Password. Then it pulls the data that you want to upload from your local database, changes it to an ASCII Text File and uploads it to the Global Master Database.

Referring to Figure 25, the process of uploading an entry includes the following steps: Step #1. Workstation. cgi script verifies User Name and Password.

Step #2. Workstation. cgi script pulls data out from local database and changes it to an ASCII Text File.

Step #3. Workstation. cgi script uploads ASCII Text File to Global Database.

Arranging Hot Order 1. From the main screen in AMS: The Publisher, select Arrange Hot Order and click Run. The Hot Entries Arrangement screen appears.

2. Select an entry from the Hot Entries Arrangement screen and click Move Up or Move Down. The entry will move up or down in the list.

3. Click Close when you are done arranging the entries.

4. The order of the entries is saved.

Choice List 1. From the main screen in AMS: The Publisher, select Choice List and click Run. The Choice List screen appears. See Figure 26.

2. From this screen, enter keywords that you want to use for your entries.

3. To enter keywords, click Insert. A dialog box appears. Enter the keyword and click OK.

Publisher can also modify, delete and rearrange entries from this screen.

Downloading Statistics 1. From the main screen in AMS: The Publisher, select Download Statistics and click Run. The Download Statistics screen appears.

2. Enter your user name and password and then click Start.

3. A CGI script, evgetdata. cgi, verifies your User Name and Password.

4. CGI script, evgetdata. cgi, pulls data from the Global Master Database with the dates selected and sends it back to the Content Producer as a text file.

5. The downloaded data is then saved to a local database.

There are four types of data log files: hits, user registration, ticket and channel and events.

Referring to Figure 27, the process of downloading statistics includes the following steps:

Step #1. CGI Script, evgetdata. cgi, pulls data from Global Master Database with requested dates and sends it to the Viewer as a text file.

Step #2. The downloaded data or text file is saved to the local database.

Content Demand Reports 1. From the main screen in AMS: The Publisher, select Content Demand Reports and click Run. The Content Demand Report screen appears.

2. Select the checkbox next to All Channels if you want to select all the channels. If you want to select a specific channel, deselect the checkbox next to All Channels and select the specific channel from the drop-down list located below All Channels.

3. Enter the start and end dates of the report.

4. Select which type of report: Web, Live or Both.

5. Click Preview to preview the report.

6. Click Print to print the report.

7. Click Close to get back to the main screen.

Publisher downloads statistics before viewing or printing a report.

Examples of sample content demand reports are depicted in Figure 28.

Top 20 Reports 1. From the main screen in AMS: The Publisher, select Top 20 Reports and click Run. The Top 20 Reports screen appears.

2. Publisher selects how he/she wants to view report.

By URL By Category By What's Hot

By Events 3. Enter the start and end dates for the report.

4. Enter the type: Web or Live 5. Click Print to print the report.

6. Click Close to go to the main screen.

Uploading Media Files 1. From the main screen in AMS: The Publisher, select Upload Media Files and click Run. The Upload Media Files screen appears. See Figure 29.

2. Enter User Name and Password and click Run.

3. A CGI script verifies your User Name and Password.

4. Then it pulls the unsent files from your local database and uploads it to the Global Master Database.

5. From this screen, a publisher can add any file to the filename list and send it to the Global Master Database. Click ADD, navigate to the file to be sent to the Global Master Database, select it and repeat (if adding more than one file). Finally, click Start to send the files to the Global Master Database.

While certain exemplary structures and operations have been described above, the invention is not so limited, and its scope is to be determined according to the claims set forth below.