Abstract:
A system for managing conditional purchase offers is disclosed where an individual searching for a ticket to a particular event may provide a guaranteed purchase offer to a plurality of potential sellers. Various methods and systems for completing such a transaction are also disclosed. An exemplary method includes: making available a guaranteed purchase offer to a plurality of potential sellers; potential sellers examining offers corresponding to a ticket they possess; and a potential seller providing an acceptance to the guaranteed purchase offer. The disclosure describes a method of payment whereby both the buyer and seller must provide credit card pre-authorization to ensure payment and delivery of the ticket. Also, one embodiment discloses a delivery of the ticket that includes the participation of the venue hosting the event. In this embodiment, the traditional practice of exchanging tickets for cash is replaced with an electronic serial number system. According to this system, the venue may be notified to cancel the serial number originally assigned to the ticket held by the seller, and re-assign a new serial number directly to the buyer. The buyer may then exchange this number for a ticket at the venue box office.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This is a continuation-in-part of U.S. Patent Application Ser. No. 08/889,319 filed Jul. 8, 1997 USP 6,085,169 which is a continuation-in-part of U.S. Patent Application Ser. No. 08/707,660 filed Sep. 4, 1996 USP 5,794,207 and U.S. application entitled “Method and System for Controlling Access to a Venue using Alterable Tickets,” U.S. Patent Application Ser. No. 08/916,656 (Attorney Docket No. “WD 2-97-052 ”) filed Aug. 22, 1997, each incorporated by reference herein. 
     The present invention is related to the following United States Patent Applications filed contemporaneously herewith: “Conditional Purchase Offer Management System for Packages,” U.S. Patent Application Ser. No. 08/923,317 (Attorney Docket No. WD 2-97-065 ); “Conditional Purchase Offer Management System for Telephone Calls,” U.S. Patent Application Ser. No. 08/923,317 (Attorney Docket No. WD 2-97-028 ); “Conditional Purchase Offer Management System for Cruises,” U.S. Patent Application Ser. No. 08/923,618 (Attorny Docket No. WD 2-97-069 ); and “Conditional Purchase Offer and Third-Party Input Management System,” U.S. Patent Application Ser. No. 08/923,524 (Attorney Docket No. WD 2-97-067 ), each assigned to the assignee of the present invention and incorporated by reference herein. 
    
    
     TECHNICAL FIELD 
     This invention relates generally to a method and system for facilitating the remote purchase and sale of tickets, and more particularly, to a method and system for electronically facilitating buying and selling tickets for an event, such as the ballet, theater or a sporting event. 
     DESCRIPTION OF THE RELATED ART 
     Attending an event such as a concert, play, or sporting event generally requires purchasing a ticket in advance. Tickets are traditionally provided by the venue hosting the event and are sold at the venue&#39;s box office. Tickets are also available through ticket distributors, in coordination with the hosting venue and the event promoter. Aside from the venue box office, tickets are also available through ticket outlets, ticket brokers, telephone sales, remote ticket printing applications, ticket kiosks and Internet web sites. 
     It is not uncommon, however, for a venue to sell out quickly for a particular event, whereby available tickets are limited to ticket brokers and “scalpers.” For instance, a popular concert may sell out well before many people interested in attending are aware that the original tickets are available. Thus, these individuals are forced to explore the resale market. 
     Resellers of tickets are limited in their ability to advertise availability to the public. Resellers may rely on classified advertisements in the newspaper, electronic bulletin boards, established contacts or “chat rooms” on the Internet. Also, resellers usually must complete sales either through the mail, or in person. 
     A number of shortcomings, however, exist for both buyers and sellers in the present resale market. First, the aforementioned methods of advertising are generally neither efficient nor flexible. The cost of advertising often outweighs the marginal profit gained through advertising, particularly for a single ticket. For instance, an advertiser may pay $30 for a classified ad that results in an additional profit of only $15. Moreover, advertisements are difficult to remove from the public realm once tickets are resold. Thus, a person selling a ticket may get many telephone inquiries after the ticket has been sold. Further, advertising is especially difficult because many transactions need to be completed just before an event occurs. This is problematic because the buyer requires the ticket to attend the event, and delivering the ticket immediately prior to the event may be difficult. Presently, ticket sellers are often forced to leave tickets at will-call windows or with local proprietors for pick up. 
     Related shortcomings with the current resale market are timing and delivery. Ticket resellers may not have tickets available until very near to the start time of a particular event, and buyers may not decide to attend an event until shortly before it begins. Specifically, the prior art does not allow substantially immediate efficient consummation of an offer to purchase or sell tickets. Accordingly, there is not a system that solves the problems associated with reselling tickets on the day of the event. 
     For example, if a person holding a ticket to a hockey game discovers two hours before the game begins that he cannot attend, his options for reselling his ticket are severely limited. His best chance to resell his ticket is to stand outside the arena and hope to find a buyer for the ticket. Such conduct is illegal in most states. Using a similar example, if a person decides he would like to attend that game two hours before it begins, his best option to acquire a ticket is to appear outside the arena and search for a ticket reseller. In both cases, the options presented to both the buyer and the seller are limited to particularly inconvenient and unpredictable ways of purchasing and reselling tickets. 
     Finally, potential buyers often possess a general distrust of ticket resellers. The act of ticket reselling is often perceived as illegal, and potential buyers are sometimes unhappy about resale prices that are significantly higher than those originally determined by the venue. As a result, buyers simply do not trust ticket resellers, but are often forced to use them as a last resort to purchase tickets. Markups on marquis events can often be as high as 500%. Further, unless a buyer is face-to-face with a ticket reseller, the buyer is typically unwilling to pay for tickets without some assurance of delivery. Likewise, a ticket reseller is typically unwilling to deliver tickets without payment in advance. 
     SUMMARY OF THE INVENTION 
     The problems identified above are solved and a technical advance is achieved by providing, in accordance with the present invention, a system and method for purchasing a ticket for a specified event on a specified date at a specified price. 
     A method according to the preferred embodiment of the present invention includes: a potential buyer electronically transmitting a guaranteed purchase offer for a ticket to a central controller; the central controller electronically making the offer available to a plurality of potential sellers; a first-accepting seller transmitting an acceptance of the offer to the central controller; and the central controller transmitting this acceptance to the buyer along with a code to use at a venue to verify his purchase of the ticket. 
     Thus, the preferred embodiment of the present invention provides individuals a quick and easy way to purchase a ticket from a ticket reseller, and allows them to avoid the traditional problems of the ticket resale market. Moreover, ticket resellers can sell a ticket based on a guaranteed purchase offer provided by a potential buyer. In addition, the present invention includes mechanisms which prevent fraud both during and after the transaction. 
    
    
     Further aspects of the present invention will become apparent during the course of the following detailed description and by reference to the attached drawings. 
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 is a schematic view of a system according to one embodiment of the present invention; 
     FIG. 2 is a schematic view of a central controller used in the system of FIG. 1; 
     FIG. 3 is a schematic view of a remote user terminal used in the system of FIG. 1; 
     FIG. 4 is a schematic view of a venue controller used in the system of FIG. 1; 
     FIG. 5 a  is a table illustrating the contents of an event table used in the system of FIG. 1; 
     FIG. 5 b  is a table illustrating the contents of a venue table used in the system of FIG. 1; 
     FIG. 5 c  is a table illustrating the contents of a customer table used in the system of FIG. 1; 
     FIG. 5 d  is a table illustrating the contents of an offer table used in the system of FIG. 1; 
     FIG. 5 e  is a table illustrating the contents of a transaction table used in the system of FIG. 1; 
     FIG. 6 a  is a table illustrating the contents of a ticket table used in the system of FIG. 1; 
     FIG. 6 b  is a table illustrating the contents of a replacement ticket table used in the system of FIG. 1; and 
     FIGS. 7 a - 7   g  are flow diagrams depicting a method of submitting and accepting a guaranteed offer to buy an event ticket over the Internet according to one embodiment of the present invention. 
    
    
     DETAILED DESCRIPTION 
     A method and apparatus of the present invention will now be discussed with reference to FIGS. 1-7 g . The present invention allows a buyer to present a guaranteed purchase offer for a ticket to a certain event, such as a hockey game, to a number of potential sellers. The sellers may review the offer, and accept the offer if the terms are agreeable. Thus, a buyer may quickly submit an offer to purchase tickets which are guaranteed to be delivered in a safe, convenient manner. 
     System Architecture 
     With reference to FIGS. 1-6, the system architecture of one embodiment of the apparatus and method of the present invention is illustrated. As shown in FIG. 1, the apparatus of the present invention generally comprises a venue controller  400 , a central controller  200 , a credit card processor  230  and a remote user terminal  300 . The remote user terminal  300  is connected to the central controller  200  through a network  245 . 
     Using the above components, the present embodiment of the invention provides a method and apparatus to allow a central controller to facilitate the purchase and sale of event tickets. Specifically, central controller  200  receives and posts offers to purchase tickets for a particular event. Such offers are guaranteed, for example, using a line of credit on a credit card account. Central controller  200  further makes each offer available to a plurality of potential sellers, and allows sellers to accept the offer and thereby form a legally binding contract. 
     As shown in FIG. 2, central controller  200  includes central processing unit (CPU)  205 , random access memory (RAM)  215 , read only memory (ROM)  220 , clock  235 , input/output (“I/O”) port  255 , and data storage device  250 . The data storage device  250  is a memory device containing an event table  500 , a venue table  520 , a customer table  530 , an offer table  550 , and a transaction table  580 , discussed in greater detail with reference to FIGS. 5 a  through  5   e , respectively. 
     Central Controller Data Tables 
     FIG. 5 a  illustrates an exemplary event table  500  that preferably stores information on events for which tickets may be resold using the system of FIG. 1, including location and scheduling information. Event table  500  maintains a plurality of records, such as record  514 , each associated with a different event. For each event identifier listed in event ID field  502 , event table  500  includes an event type code stored in field  504  and an event description stored in field  506 . The event type code stored in field  504  represents the format of the event, for instance, a National Hockey League game is denoted as “NHL.” The event description stored in field  506  describes the specific event. 
     Event table  500  also preferably includes a venue ID stored in field  506 . The venue ID stored in field  506  may be utilized, for example, to index venue table  520 , more fully described with reference to FIG. 5 b . As shown in FIG. 5 a , each record stored in event table  500  further includes a date stored in field  510  and a time stored in field  512 . The date and time of fields  510  and  512 , respectively, represent the starting time of the event associated with the record. The information stored in this table may be supplied to the central controller  200  from any number of sources, including promoters, venues and potential buyers and sellers. 
     FIG. 5 b  illustrates an exemplary venue table  520 . Each record of venue table  520 , such as record  528 , preferably stores data associated with and describing a venue. Venue table  520  is preferably indexed by field  522  which stores a unique venue identifier. Venue table  520  further stores a theater, auditorium or stadium name in field  524  and an address in field  526 . 
     FIG. 5 c  illustrates an exemplary customer table  530  which preferably stores information on each customer registered with the electronic ticket sales system. Customer database  530  maintains a plurality of records, such as records  546  and  548 , each associated with a different customer. Customers registered in customer table  530  may buy tickets, sell tickets or both buy and sell tickets. Customer table  530  stores a unique customer identifier for each customer in field  532  and name and address information in fields  534  and  536 . Preferably, the data maintained in customer table  530  is provided by the customer during a registration process, at which time the customer is assigned a unique customer identifier. 
     Customer table  530  further stores customer credit card data. The customer&#39;s credit card number is stored in field  538 . The expiration date of the customer&#39;s credit card is stored in field  540 , and the name of the cardholder as it appears on the credit card is stored in field  542 . 
     FIG. 5 d  illustrates an exemplary offer table  550  that preferably stores information relating to offers posted using the ticket sales system of the present embodiment. Offer table  550  maintains a plurality of records, such as records  570  and  572 , each associated with an offer to buy or sell tickets. Each record of offer table  550  includes a unique offer identifier stored in field  551  that is assigned by central controller  200  when the offer is posted. Each record of offer table  550  includes fields for identifying the customer making the offer, conditions of the offer, the customer accepting the offer, and administrative information related to the offer. 
     The customer identifier of the customer extending the offer is stored in field  552 . Information relating to the customer extending the offer may be easily obtained using the customer identifier of field  552  as an index into customer table  530 . Each record in offer table  550  further stores an event identifier in field  553 . The event identifier indicates the event to which the offered ticket(s) relate. Information regarding the event may be easily obtained using the event identifier of field  553  as an index into event table  500 . 
     Each record of offer table  550  further includes fields  554  and  555  that store the date the offer was made and the last day on which the offer may be accepted, respectively. Data indicating an offer type and offer status are also stored in each record of offer table  550  in fields  556  and  557 . Field  556  stores a code indicating whether the offer is an offer to buy or an offer to sell one or more tickets. Field  557  stores a code indicating the status of the offer. Offer status possibilities include: pending, active, expired and fulfilled. 
     Field  558  of each record in the offer table stores the number of seats to which the offer applies. Data identifying the location of seats related to the offer populate fields  559 - 564 . In the event an offer requires a range of seat locations, data stored in fields  559 - 561  are used to identify the first seat in a range, and data stored in fields  562 - 564  are used to identify the last seat in a range. Field  565  stores the price per seat. 
     In addition, each record of offer table  550  includes administrative data in fields  566 - 569 . Data stored in field  566  stores an amount of credit authorized to support the offer. Once an offer has been accepted, field  567  stores a transaction identifier that may be used as an index into transaction table  580 , discussed more completely with reference to FIG. 5 e . Each record of offer table  550  optionally stores a pointer to a related, or linked, offer record. The pointer is stored in field  568  and represents the offer identifier of the next related record in offer table  550 . Finally, field  569  of each record of offer table  550  stores one or more serial numbers of the original tickets that a seller would like to sell. 
     Once an offer is accepted, central controller  200  adds a transaction record to transaction table  580 . FIG. 5 e  illustrates an exemplary transaction table  580  that preferably stores information relating to each accepted offer. Each accepted offer is assigned a unique transaction identifier that is stored in field  581  of transaction table  580  and field  567  of offer table  550 . An offer identifier of an associated record in offer table  550  is stored in field  582 . This offer identifier may be used as an index into offer table  550  to retrieve information regarding the offer associated with a transaction record. 
     Each record of transaction table  580  preferably further includes field  583  which stores the date the associated offer was accepted and field  584  which stores the total value of the transaction. Field  585  stores the amount charged to the buyer&#39;s credit card; field  586  stores the amount of the seller&#39;s credit line reserved to support the acceptance; and field  587  stores the fee charged for processing the transaction. Each record of transaction table  580  also stores a date in field  588  indicating the date the ticket(s) are received by the operator of central controller  200 . 
     The customer identifier of the seller is stored in field  589 , and data identifying the ticket(s) is stored in fields  590  and  594 . Field  590  stores the original ticket number(s), and field  594  stores new ticket number(s). The new ticket numbers are assigned to distinguish original tickets from resold tickets and promote efficient resolution of potential conflicts between ticket holders. 
     Optionally, central controller  200  may include a contract detail table (not shown) containing form contract provisions which the central processor  200  retrieves and transmits to users at various times. For example, the contract table may include a contract provision that is transmitted to a buyer and incorporated into the guaranteed purchase offer. The contract table may also include a contract provision which is transmitted to a seller prior to requesting an acknowledgment of his intent to bind a buyer&#39;s offer and create a legally binding contract. These form provisions effectively fill the gaps between conditions specified by the buyer, specifying the generic contract details common to most contracts of this nature. 
     User Terminal 
     Referring now to FIG. 3, remote user terminal  300  will now be described in greater detail. Remote user terminal  300  can be a personal computer, screenphone, stand alone kiosk, or any other device through which a customer can access the central controller  200 . Remote user terminal  300  generally includes a central processing unit (“CPU”)  305  that controls the operation of remote user terminal  300 . CPU  305  is electronically connected to a random access memory (“RAM”)  315 , a read only memory (“ROM”)  320 , an input/output port  325 , a clock  335 , a communication port  340  and a data storage device  360 . CPU  305  receives inputs from a remote user with the input/output port  325  and an input device  345 , such as a keyboard. CPU  305  transmits outputs to a remote user via the input/output port  325  and a video monitor  330 . Further, the communication port  340  provides the communication path to network  245 . Finally, the data storage device  360  is a memory device containing central controller interface software  365 . 
     Venue Controller 
     Referring now to FIG. 4, venue controller  400  will now be described in greater detail. Venue controller  400  generally includes a central processing unit (“CPU”)  410  that controls the operation of venue controller  400 . The CPU  410  is electronically connected to a random access memory (“RAM”)  420 , a read only memory (“ROM”)  430 , a clock  440 , a communication port  450  that provides a communication path to central controller  200 , and a data storage device  460 . Data storage device  460  is a persistent memory device containing a ticket table  610  and a replacement ticket table  630 . Venue controller  400  further includes input device  480  for receiving input data and output device  470  for presenting or displaying information to an operator. 
     FIG. 6 a  illustrates an exemplary ticket table  610  that preferably stores information about tickets issued for various seats at a particular venue. Each ticket has a specific ticket number assigned to it by venue controller  400  prior to issuance. Each record of ticket table  610  preferably includes field  611  that identifies the event for which the ticket is valid, field  612  that identifies the number assigned to each ticket issued for an event, and fields  614 - 620  that represent the location of the seat in the auditorium (i.e. the section, row and seat, respectively). Ticket table  610  could also contain fields representing other information specific to a venue, an event, or a seat. 
     FIG. 6 b  illustrates an exemplary replacement ticket table  630  that preferably stores data relating to original ticket numbers that have been voided and assigned replacement ticket numbers. Replacement ticket table  630  stores the ticket numbers that have been resold by the central controller  200  in field  632  and stores the replacement ticket numbers in field  642 . Each record of ticket table  630  further includes a field  631  that stores an event identifier and a field  640  that stores a buyer identifier. 
     It will be recognized by one of ordinary skill that the present invention could be constructed and operated without the illustrated distributed processing architecture. If venues and ticket distributors so desired, central controller  200  could incorporate all or part of the database of venue controller  400  and perform all or part of the processing steps performed by venue controller  400  in the present embodiment. In such an alternate embodiment, data processing and data storage could be centralized, and venues could access the data as appropriate using conventional remote terminals or work stations. 
     Online Embodiment 
     In one embodiment of the present invention, communications between potential buyers and sellers take place via an electronic or digital network, such as the Internet, with central controller  200  hosting an Internet web site that users can access or “log on” to by means of a personal computer. It is important to note that users can access the central controller via other communications links such as a conventional telephone line linked to a voice response unit (“VRU”). 
     To use the ticket reselling service, a user who is a potential buyer logs on to central controller  200  through network  245 , creates and submits a guaranteed purchase offer, and disconnects from the network  245 . In one embodiment, a guaranteed purchase offer is a legally binding offer to purchase tickets that is backed by a pre-authorized credit card transaction. Upon receiving the offer, central controller  200  contacts the buyer&#39;s credit card issuer to ensure that the buyer has a valid credit card account and/or sufficient credit to pay for the requested tickets. The guaranteed purchase offer is then made available to potential sellers by posting the offer using the web site linked to central controller  200 . Periodic maintenance is performed by central controller  200  to ensure that “active” offers have not expired. A potential seller can use the system of the present invention to browse offers and submit an electronic acceptance of a desirable offer. The acceptance by the potential seller is transmitted electronically to central controller  200 . Central controller  200  processes the acceptance and contacts the seller&#39;s credit card issuer to ensure that there is sufficient credit to cover a potential penalty for non-performance. This reservation of the seller&#39;s credit is intended to promote trust between the parties and, thereby, protect the transaction. After verifying available credit, both parties are notified of the binding transaction, and the tickets are electronically voided and assigned a replacement ticket number. The seller is then required to surrender the voided tickets. This may be accomplished by returning them to the venue, or the seller may mail the tickets to the operator of central controller  200 . Upon receiving the surrendered tickets, the operator of central controller  200  directs payment to be transferred to the user selling the tickets. 
     With reference to FIG. 7 a , a process by which a user logs on and begins using the system will now be described. As shown in step  700 , a user operating a remote terminal  300  establishes a connection with the central controller  200  through network  245 . The user may be either a potential buyer wishing to place a guaranteed purchase offer for tickets, or a potential seller wishing to review offers for tickets. 
     At step  702 , central controller  200  requests a customer ID from the user. At step  704 , central controller  200  determines how to proceed based on whether or not the user already has a customer ID. If the user is registered with this service, and remembers his customer ID, he transmits his customer ID to central controller  200  at step  712 , and the process continues with step  714 . 
     If, on the other hand, the user is not registered with the service, or does not remember his customer ID, he must submit a negative response at step  704  and present relevant customer information to central controller  200 , as shown by step  706 . At step  708 , central controller  200  creates a record of the customer based on the received customer information. This information, including name, address, credit card and number, expiration date, and name as it appears on the credit card, is stored in customer table  530 . At step  710 , central controller  200  compares the information provided by the user with information already stored in customer table  530 . If a match is found, central controller  200  retrieves the customer ID from field  532  of customer table  530 , and transmits the customer ID number to the user. This service is provided for users who have given information previously, but do not remember their customer ID number. If no match is found, the central controller  200  assigns a new customer ID to the user, stores it in field  532  of customer table  530 , and transmits it to the user. 
     At step  714  the user indicates whether he would like to submit a guaranteed purchase offer, or review offers from potential buyers. The process steps relating to submitting offers are described more fully with reference to FIGS. 7 b - 7   c . The process steps relating to reviewing offers are described more fully with reference to FIGS. 7 d - 7   g . In an alternative embodiment, the user could also elect to advertise the availability of tickets for a certain event to potential buyers. Furthermore, a user could elect to review such advertisements, to get a better understanding of what a fair price might be, prior to submitting an offer. 
     FIGS. 7 b  and  7   c  illustrate the process steps executed following the user&#39;s choice at step  714  to submit a guaranteed purchase offer. At step  716 , the central controller transmits general venue and event information to user terminal  300  for display to the user. For instance, in one embodiment, central controller  200  may provide a number of options to the user in order to pinpoint the specific event that the user would like to attend. The user could directly request a particular event, or proceed through a group of narrowing choices to ultimately find the right event. A user, for example, may be asked to identify any of the fields from event table  500 . Depending on the amount of information provided, the choice of events will be narrowed accordingly. For instance, if the user provides only the event type (e.g. “NHL”), central controller  200  scans the event table  500  and provides all matches found in the event type field  504 . This may be a long list of events, however, central controller  200  may prompt the user for more information to narrow the list. The user may then select from the narrow list to find the event for which he is looking. For example, the user may specify only Saturday matinee performances of a particular Broadway production in order to narrow the list. Central controller  200  then provides the user with the correct event information, including the event ID from field  502  of the event table  500 . The user includes this event ID as part of their guaranteed purchase offer so that it may be tracked by central controller in the offer table  550 . 
     Next, at step  718 , the user selects the desired event based on the event ID number. At step  720 , central controller  200  requests certain information from the user pertaining to the offer, such as 
     (1) the number of tickets desired; 
     (2) the price for each ticket; 
     (3) the location desired for each ticket; and 
     (4) optionally, a date through which the offer is valid. 
     The user indicates the number of tickets he would like and the price he is willing to spend, based on the particular location of the tickets. The user may choose the exact location of seats that correspond to the price he is willing to pay using a graphical representation of the venue. For instance, based on the venue ID number (stored in field  522  of venue table  520 ), central controller  200  retrieves from memory and provides to the user at remote user terminal  300  a graphical representation of seating at that particular venue. In one embodiment, central controller  200  first provides a broad general outline of the entire venue (e.g., display by sections). The user can then click on a particular area to narrow his search for exact seats. With each successive selection click, the display screen at user terminal  300  narrows the scope of displayed seating until the user finds the seats he desires. The user can then select the group of seats which corresponds to the purchase offer. Central controller  200  stores the selected seats in fields  559 - 564  of the offer table  550 . If the user prefers to select one section or multiple sections instead of specific seats, he can enter a range of selections. Central controller  200  then stores this broader selection by only using the section fields  559  and  562 , and leaving the other four fields empty. 
     Further, the user may provide a close date to denote a date on which the offer expires. As previously discussed, central controller  200  periodically reviews this close date, and changes the status of the offer to “expired” in field  557  of the offer table  550  once the date has passed. 
     At step  722 , central controller  200  receives the offer information transmitted by the user, and as shown in step  724 , central controller  200  creates a record of the offer in offer table  550 . At step  728 , the user is asked if he would like to make additional offers. At this point, if the user would like to make an offer for a separate event, he may go through the same process discussed in steps  716 - 724 . However, if the user would like to make a related, or linked offer to the offer previously provided, they may do so as follows. First, in one embodiment they provide the same event ID as at step  718 . Next, after submitting the same general information previously discussed, the user indicates that this offer is linked. The central controller then assigns the offer ID number created for the initial offer as the link ID number for the related offer, and stores in the link ID field  568  of the offer table  550 . 
     A user might provide a linked offer based on the type of seat desired. For instance, the user might select a number of the “high quality” seats in a particular venue, and offer a higher purchase price. The linked offer would include “lower quality” seats for a particular venue, perhaps at a lower purchase price. Thus, based on the link ID, potential sellers will consider both offers together during their review. 
     Also, the user may link offers for two separate events as opposed to the same one. For example, instead of linking offers based on seat selection and price, the user may prefer to attend one of two events in the local area, but not both. Thus, he could link these offers so that potential sellers would be made aware that the offers were conditioned against an “either/or” proposition. 
     The central controller  200  assigns an offer ID number to each offer in the offer ID field  551 , and assigns this number as the link ID number for linked offers in link ID field  568 . Also, the offer date field  554  is populated with a timestamp (e.g., date and time) indicating when the offer was posted. Next, central controller  200  assigns the value “pending” to the status field  557 . This value will change to “active” upon receipt of authorization from the user&#39;s credit card issuer. Further, central controller  200  calculates the authorized amount, and stores it in authorized amount field  566 . The authorized amount field represents the amount of the user&#39;s credit which is reserved to “back up” the offer and is usually equal to the total transaction amount. By reserving a portion of the user&#39;s credit, the ticket seller and ticket service can be guaranteed that they will receive payment if the offer is accepted. In case of linked offers to buy, the authorized amount is the highest transaction amount of the linked offers. When a linked offer is accepted, the system automatically considers all related offers to be withdrawn. Finally, central controller  200  stores all the information provided by the user, including the seat location based on the graphical representation of the venue, in the respective fields of the offer table  550 . 
     At step  730 , the central controller  200  extracts legal contract language from the contract detail table (not shown) and transmits to the user at user terminal  300 . This language describes the legal implications of offering the guaranteed purchase offer, and the process is similar to reviewing terms before signing a written contract. If the user elects not to abide by these terms, he may cancel the offer. However, if the user does elect to abide by the terms, the user transmits a positive acknowledgment to central controller  200 , and is legally bound to the terms of the guaranteed purchase offer. 
     In FIG. 7 c , central controller  200  then contacts the user&#39;s credit card issuer at step  732  to receive authorization for the offer. First, central controller  200  collects the user name, address, credit card type, credit card number, and expiration date from customer table  530 , based on the customer ID from the offer table  550 . This information along with the authorization amount from field  566  of the offer table  550  is transmitted to the credit card issuer through credit card processor  230 . 
     At step  734 , the central controller  200  receives either an authorization or rejection from the credit card issuer through credit card processor  230 . The credit card issuer may reject the request for any number of reasons, including an expired card, overextended credit limit, or delinquency in payments. Upon rejection, at step  736  central controller  200  notifies the user at user terminal  300  of this rejection and requests separate credit card information. Alternatively, the user may transmit information corresponding to a separate credit card, which supplements or replaces his present information in the customer table  530 . If alternative credit card information is provided, step  732  is repeated in order to receive authorization for the charge. Upon receiving authorization from the credit card issuer through the credit card processor  230 , central controller  200  updates offer table  520 , including changing status field  557  to “active” to confirm the posted offer. 
     FIGS. 7 d - 7   g  illustrate the processing steps executed based on the user&#39;s choice at step  714  to review offers from potential buyers. At step  740 , central controller  200  transmits general venue and event information to user terminal  300  for display to the user. As discussed earlier at step  716 , central controller  200  may provide a number of options to the user to identify the exact event the user wishes to review. Ultimately, central controller  200  provides the user with the event ID from field  502  of the event table  500 . At step  742 , the user supplies the event ID to central controller  200  so it may identify associated offers in offer table  550 . 
     At step  744 , central controller  200  identifies offer records associated with the selected event ID and having an “active” status. Central controller  200  transmits this data to user terminal  300  for display to the user. The user may review all offers for the specific event together, or one at a time. In one embodiment, the user may review each individual offer through a graphic display of the venue, to pinpoint exactly where the buyer is requesting seats. In some cases, the offer may be for seats anywhere in the entire arena. In others, the offer may only be for a specific range of sections, rows or seats. In one embodiment, the user may be able to enter their exact ticket information to confirm whether it meets the requirements of the offer. 
     As previously discussed, linked offers will be appropriately identified upon presentation to the user. In this case, central controller  200  allows associated linked offers to be reviewed simultaneously, so that the user can compare the conditional offers submitted from a single buyer. 
     Next, at step  746 , central controller  200  receives either a request to accept a particular offer, or a request to review offers for other events. In the latter case, steps  740 ,  742  and  746  will be repeated. It should be noted that the user may exit the system at any time prior to accepting an offer. 
     After the user transmits a request to accept a particular offer, at step  748  the user transmits the original ticket number and seat location (i.e. section, row and seat) to central controller  200 . Upon receiving this information from the user, central controller  200  at step  750  transmits the original ticket number and seat location to the venue controller  400  for verification of the ticket&#39;s validity. 
     Referring now to FIG. 7 e , at step  752  venue controller  400  retrieves a record from ticket table  610  matching the ticket number transmitted by central controller  200  in step  750 . Venue controller  400  verifies that the transmitted ticket number matches the transmitted seat location at steps  754  and  756 . If the transmitted ticket and seat location do not match, at step  758 , venue controller  400  transmits an invalid combination message to central controller  200 . Central controller  200  then transmits a message to user terminal  300  indicating that the ticket number and seat location are an invalid combination at step  760 . Upon receiving the invalid combination message at user terminal  300 , the user can resubmit the ticket and seat location to central controller  200  at step  770 . The process then loops back to step  750 . If the ticket number and seat location combination is valid, the process continues with step  772 . 
     At step  772  of FIG. 7 f , central controller  200  transmits to user terminal  300  legal contract language which is displayed to the user selling his ticket. As previously indicated, this contract language may be stored in a contract detail table (not shown). This language describes the legal implications of accepting the guaranteed purchase offer, and the process is similar to reviewing terms before signing a written contract. If the user selling his ticket elects not to abide by these terms, the user may cancel his acceptance. However, if the user elects to abide by the terms, the user transmits a positive acknowledgment to central controller  200 , and is legally bound to the acceptance. 
     Central controller  200  then contacts the user&#39;s credit card issuer at step  776  to receive authorization for the acceptance. Central controller  200  requests authorization from the credit card issuer to reserve a portion of the user&#39;s credit based on the offer information and credit information collected from the user at step  706  and stored in customer table  530 . This credit reservation is a fraud deterrent and may be used as a penalty in the event the seller fails to deliver the tickets. Such a penalty creates buyer confidence and provides assurance to a user buying the ticket that the user selling the ticket will, in fact, relinquish the tickets. The penalty could be paid to the user buying the ticket if the user selling the ticket attempts to repudiate the agreement. This penalty may be determined in a number of ways including imposing a flat penalty on the user selling the ticket or imposing a penalty equal to the entire amount offered by the user buying the ticket. 
     At step  774 , central controller  200  collects information from the user selling the ticket. The information may include the user name, address, credit card number and expiration date from customer table  530 , based on the customer ID retrieved from the offer table  550 . This information, along with the authorization amount from field  566  of the offer table  550 , is transmitted to the credit card issuer through credit card processor  230 . 
     At step  776 , central controller  200  receives either an authorization or rejection from the credit card issuer through credit card processor  230 . The credit card issuer may reject the request for any number of reasons, including an expired card, overextended credit limit, or delinquency in payments. Upon rejection, at step  728  central controller  200  notifies the user at user terminal  300  of the rejection and requests alternate credit card information. The user may attempt to transmit the same credit information as provided earlier, because the user may have mistakenly transmitted incorrect information earlier. Alternatively, the user may transmit information corresponding to an alternate credit card, which will supplement or replace the credit card information in customer table  530 . Further, the user could cancel the transaction altogether. If alternative credit card information is provided, step  774  is repeated in order to receive authorization for the charge. 
     If central controller  200  receives authorization from the credit card issuer through credit card processor  230 , the process continues with step  780  wherein central controller  200  generates and assigns a transaction ID to the sale. This transaction ID is stored in field  567  of the offer table  550 . Further, central controller  200  creates a new record in transaction table  580 , indexed by the assigned transaction ID. The assigned transaction ID is also stored in field  581  of transaction table  580 . The original ticket number  590  field of transaction table  580  is populated with the appropriate ticket number(s) from the user selling the ticket. Further, central controller  200  timestamps the acceptance using date field  583  indicating when the acceptance was posted. 
     Once the guaranteed purchase offer has been accepted, central controller  200  uses the customer ID from field  552  as an index into customer table  530  to retrieve the name of the user buying the ticket. At step  782 , central controller  200  transmits the name of user buying the ticket to the venue controller  400 . 
     At step  784 , venue controller  400  creates a new record in replacement ticket table  630 . The new record is populated with information indicating the buyer&#39;s name, the original ticket number, the section, row and seat of the ticket. As shown at step  786 , the new record is further populated with a replacement ticket number assigned by venue controller  400 . The replacement ticket number is then transmitted to central controller  200   
     Once central controller  200  has received the replacement ticket number  642  from venue controller  400 , central controller  200  then updates the new ticket number field  594  of transaction table  580  at step  788 . At step  790 , central controller  200  determines the payment due and charges the credit card, of the user buying the ticket, the price of the ticket plus a processing fee  587 . Central controller  200  also updates field  585  of the transaction table  580  with the amount charged. Finally, central controller  200  updates field  589  with the seller ID of the user accepting the offer, and central controller  200  updates field  586  with the seller amount authorized in the event that the seller tries to use his sold ticket. Field  584  is updated based on buyer amount charged  585  less the processing fee  587 . Although fees of the present embodiment are illustrated as being stored in a table, such fees could easily be calculated instead of being retrieved from a table. 
     At step  792 , central controller  200  transmits a message to user terminal  300  to notify the user selling the ticket that it will credit his credit card account with the sale amount of the ticket as soon as central controller  200  receives verification that the original tickets have been surrendered. 
     At step  794  the central controller transmits replacement ticket number  692  and a message to the user buying the ticket indicating that his guaranteed offer has been accepted. The user buying the ticket may then print the replacement ticket number, take it to the venue and use it to gain access to the desired event, at step  796 . The cancellation of the original number and issuance of a replacement ticket number tied to the purchasing user&#39;s name is done in order to prevent fraud by either the ticket seller and/or the purchaser. 
     For instance, if a seller arrives at a venue with a ticket, and a purchaser also arrives to the same venue with a replacement ticket for the same seat, the venue controller can be accessed to determine which ticket is valid. The replacement ticket always supersedes the original ticket, provided it is registered in the replacement ticket table  630  of the venue controller  400 . If such fraud is attempted by the seller and detected by central controller  200 , the central controller can charge the seller&#39;s credit card account the seller amount authorized in field  856  of transaction table  580 . 
     As another example, if two people arrive at the venue with the same replacement ticket, the venue controller can be accessed to determine the rightful owner, based on the contents of the new buyer name field  640 , of replacement ticket table  630 . These measures taken against fraud will assure customers that there will be no problems in using central controller  200  to buy and sell tickets. 
     Finally, at step  798 , central controller  200  receives verification that the original ticket has been received from the seller, and credits the credit card account of the user selling the ticket with the transaction amount  584 . Central controller further updates the date tickets received field  588  accordingly. Surrender of the ticket is preferably accomplished by delivery of the ticket to a will call window of the venue, however other surrender arrangements are possible, such as through the postal service or Federal Express. Once the ticket has been surrendered and the transaction is complete, central controller  200  updates status field  557  of the offer table  550  to “completed” for tracking purposes. Upon receipt of the surrendered tickets, central controller  200  credits the account of the user selling the tickets. 
     Although the preferred method of surrendering the original tickets is using the mail or other delivery mechanism, numerous alternate embodiments are possible. Using one alternate embodiment, ticket redemption could be constructively accomplished at the time an offer to buy is irrevocably accepted. The alternate embodiment employs event tickets that can be physically altered to render them invalid or void. Each ticket includes a unique ticket number that is pre-printed on the face of the ticket, but obscured from view by a scratch-off covering, such as an opaque latex coating. The ticket number is unknown to the ticket holder unless the scratch-off covering is removed. 
     At the time of acceptance, the seller possessing the tickets is instructed to remove the covering over the ticket number on each ticket to be sold. The ticket number is provided to central controller  200  to verify that the ticket seller is, in fact, in possession of valid tickets. The ticket number provided for each ticket involved in the transaction is then electronically voided and replacement ticket number is assigned as previously described. 
     The act of revealing the ticket number not only serves to verify the ticket seller&#39;s possession of the tickets, but also eliminates the need for the seller to surrender the tickets because removal of the scratch-off covering voids the tickets. While this alternate embodiment requires additional structure with respect to the event tickets, it eliminates the need to reserve a portion of the seller&#39;s credit line as a penalty for failing to return the unused tickets. 
     Illustrative Example 
     An illustrative example of the invention will now be described using the data populating various fields of the figures. Record  572  of the offer table  550  is a guaranteed offer to buy as indicated by type field  556  that has been submitted by user  4000  as identified by customer ID field  552 . User  4000 , as denoted by record  548  in the customer table  530  is Sue Black, residing at 101 Pink Ave in Norwalk, CT. The credit card number submitted to central controller  200  is Discover card number 4444-4444-4444-4444 that expires August 2002 and was issued to Susan Black. 
     In record  572  of the offer table  550 , Sue Black has posted a guaranteed offer to buy two tickets to event ID E001, as denoted by event ID field  553 , for $200.00 per ticket in the first row of the first section of the venue. As denoted by record  514  of event table  500 , event E001 is an NHL game, specifically NJ Devils vs. New York Rangers, occurring on 5/6/97 at 7:30 PM at “MSG” as denoted by venue ID field  508 . Record  526  of venue table  520  identifies MSG as the Madison Square Garden venue in New York, N.Y. 
     In addition to this guaranteed purchase offer, Sue Black has also posted a link offer as denoted by linked ID field  568 . This linked offer has an ID code of 0333. Record  570  of offer table  550  has the offer ID 0333, and is therefore the offer that is linked to record  572 . Record  570  is an offer by Sue Black to purchase four tickets to the NHL game NJ Devils vs. New York Rangers having the same date and time as the offer request of record  572 . In record  570 , Sue Black indicates that she will pay $250 each for four tickets in the first row of the first section of the venue. Because offer  570  is linked to offer  572 , Sue Black has indicated that she would like one or the other of the two offers. 
     Field  566  of offer table  550  indicates that $1,000 has been authorized by Discover for account 4444-4444-4444-4444 for both records  570  and  572 , submitted by Sue Black. $1,000 is the maximum possible amount that Sue Black&#39;s offers could cost her if one of them is fulfilled. 
     For record  572 , the transaction ID field  567  has been populated with a transaction ID, indicating that a buyer has accepted Sue Black&#39;s guaranteed offer to buy. Status field  557  of record  572  registers that the offer has been fulfilled, and the status record  570  is expired, since it was linked to record  572  in a way indicating that if one was filled, the other should be disregarded. 
     Record  595  of transaction table  580  describes the detail of transaction TR001, which is the acceptance of Sue Black&#39;s guaranteed offer to buy by seller  2000 , as indicated by seller ID field  589 . 
     Record  570  of the customer table  530  indicates that customer having the ID number  2000 , as indicated by customer ID field  532 , is Jill Janson, residing in 456 Red Drive, Atlanta GA, and having Master Card number 2222-2222-2222-2222 with expiration date 9/99 registered with central controller  200 . 
     Record  595  indicates that Sue Black was charged $420 on 5/2/97 for her purchase of seats 003 and 004 of row 1, seat 1 of the event tied to the record of her guaranteed purchase offer in offer table  550 . Record  595  also indicates that Jill Janson has sold her original ticket numbers 667913 and 667914, stored in the original ticket number field  810 , for section 001, row 001, and seat 003 and 004. The seller amount authorized field  585  stores $400, the amount that central controller  200  has been authorized by Mastercard to debit from account 2222-2222-2222-2222 in the event that Jill Janson does not honor her agreement to sell her tickets. All or a portion of this amount can be credited to Sue Black if there is a problem using her new ticket number for access to the venue event. 
     The date tickets received field  588  is blank for this record, indicating that central controller  200  has not yet received verification that Jill Janson has surrendered her tickets. Once central controller  200  has received verification that Jill Janson has surrendered her tickets, Jill Janson&#39;s credit card account will be credited $380, the amount stored in transaction amount field  584 . 
     Central controller  200  has issued replacement ticket numbers to Sue Black for both seats. These replacement ticket numbers are stored in field  594 . Preferably, Sue Black will print out these replacement ticket numbers and take them with her to the venue to gain access to the event. 
     Records  622  and  624  of ticket table  610  store information relating to the original tickets issued to Jill Janson. Records  644  and  646  of replacement ticket table  630  store the replacement ticket numbers issued by central controller  200  to Sue Black, which replace the original ticket numbers given to Jill Janson. These records are stored by venue controller  400  to be used in the event of fraud as previously described. 
     It is important to note that in the embodiment described above, the notification of the parties, both buyer and seller is performed through contacting their respective remote user terminals. This notification can also be performed using conventional technology including but not limited to telephone, facsimile, e-mail and paging. 
     In addition to the guaranteed offer and acceptance system of the present invention, the present embodiment is also well suited for other aspects of ticket resale. For example, the present embodiment can include a registration process for certain events or tickets. Such a process would enable a prospective ticket buyer to set up a ticket watch which could be implemented by central controller  200 . Central controller  200  could periodically poll offers to determine if specific tickets are available. Availability could be transmitted to a user via conventional telephone lines, E-mail, facsimile or pager. A notification preference could be determined by the user during the registration process. 
     Another aspect of ticket resale that is well suited to the present embodiment is advertising. Instead of simply allowing users to place, review and accept offers, the system could provide advertising for products related to events and tickets. 
     Of course, these and many other features and advantages of the present invention are apparent from the detailed specification. Thus, it is intended by the appended claims to cover all such features and advantages of the invention which fall within the true spirit and scope of the present invention. 
     Furthermore, since numerous modifications and variations will readily occur to those skilled in the art, it is not desired that the present invention be limited to the exact construction and operation illustrated and described herein, and accordingly, all suitable modifications and equivalents which may be resorted to are intended to fall within the scope of the claims.