WO2000065506A9 - Individual seat selection ticketing and reservation system - Google Patents

Abstract

The invention relates to a method and a system with distributed access to the reservation system of a show. A seating plan of the requested show is transmitted to an unaffiliated customer node. The customer performs a place selection test on the plan. After checking the payment data of the customer, the selected place is marked reserved on the subsequent transmissions of the seating plan.

Description

INDIVIDUAL SEAT SELECTION TICKETING AND RESERVATION SYSTEM

BACKGROUND

This is a continutation-in-part of Serial No. 09/295,577, filed on April 22, 1999, entitled INDIVIDUAL SEAT SELECTION TICKETING AND RESERVATION SYSTEM.

(1) Field of the Invention

The invention relates to making reservations over a wide-area network. More specifically, the invention relates to permitting a widely distributed reservation system accessible over a wide-area network without dedicated hardware and software. (2) Background

Various ticketing and reservation systems are disclosed in the prior art. In U. S. Patent 5,797,126 (1988), Helbling, et al., describes a series of individual kiosks in wireless communication with a central station where a visitor can locate events of interest, view an excerpt of scenes from that venue and purchase tickets. This requires users to physically visit a remote site to avail themselves of the service. Additionally, said prior art makes extensive use of what is called "kiosks," thereby requiring specialized hardware and software to render the services.

U.S. Patent 4,974,252 describes a more interactive theater attendance system where patrons are permitted two way communications between themselves and a broadcast center but this system requires that persons be in attendance at the theater and, further, some attendant be present at the remote broadcast center.

Other prior art exists in the reservations arena, but typically fails to cure the shortcomings of the art set forth above. BRIEF SUMMARY OF THE INVENTION

A method and system of providing distributed access to a venue reservation system is disclosed. A seating chart for the requested venue is served to an unafilliated client node. The client tentatively selects a seat from the seating chart. Upon verification of the clients' payment information, the selected seat is designated as reserved on subsequent servings of the seating chart.

BRIEF DESCRIPTION OF THE DRAWINGS

The advantages of the present invention will be more fully understood hereinafter as a result of a detailed description of a preferred embodiment when taken in conjunction with the following drawings in which:

Figure 1 is a flow diagram of the present invention illustrating the major components thereof and the interactivity that takes place between the potential customer and the instant invention.

Figure 2 is an illustration of the concept of the present invention utilizing the internet as the Wide Area Network to which users connect to perform the desired function and shows an example of a remotely located user accessing the functionality of the instant invention for purposes of reserving seats for a dinner theater performance in a distant city.

Figure 3 is a illustration of the concept of the present invention refined down to the functionality of reserving specific seats and blocking from duplicate sale those seat that are already reserved. Figure 4 is a sample of the screens seen by a remote user of the instant invention during a session wherein the user selects and orders 4 specific seats for a distant dinner theater show.

Figure 5 is a complete code set for one exemplary embodiment of the present invention. Figure 6 is a flow diagram of a host server operation in response to a venue request in an alternative embodiment of the invention.

Figure 7 shows a sample of seating chart in one embodiment of the invention. Figure 8 is a code diagram of a code segment which implements the tentative reservation aspect of one embodiment of the invention.

DETAILED DESCRIPTION

Referring to Figure 1, it will be seen that the operator of a venue implements the disclosed reservation system to allow remotely located users to reserve specific seating for specific events 1. By doing so, the operator initiates those certain actions necessary to displaying an internet web site to all online users 2. A prospective customer for the venues offering(s) logs onto the internet

3 and acquires the aforesaid internet web site 4 which implements a reservation system for the venue. The prospective customer can be connected to the internet by any conventional means, yet this by no means implies that the wide-area network must be what is commonly referred to as the "internet." Upon contact by the prospective customer, an inquiry is directed to the appropriate database, which may be located concurrent with the primary server hosting the reservation system software program or may be located remotely, such as at the physical location of the venue, asking for a return of information to the prospective customer of all appropriate information contained therein relative to his inquiry 5. The prospective customer indicates a desired seat or seats through conventional computer input means and directs that information back to the server hosting the code necessary to the implementation of the reservation system 6. Upon contact 7, the server again makes an appropriate database query and returns to the prospective customer all pertinent information relating to that selection, such as which seats are still available for the chosen performance, airline flight, boxing match, etc. The prospective customer is then presented with a representation of all then available seating for the selected venue 8. From this representation, the prospective customer makes a selection of a seat or seats by indicating such through a mouse click, keyboard entry or other means, such as but not limited to a touch screen. Selection through voice command via a speech interface is also within the scope and contemplation of the invention. Simultaneously, the server, through the coding necessary to implement the reservation system, creates a temporary customer identification 9 that is used to associate this potential customer with the customer's later selections and permit system use by multiple simultaneous users. Once the customer has made the seat selection, the system requests payment information from the customer 10. That information is processed through conventional internet or other electronic means, and once the information and payment are verified 11a, the customer information as supplied in 10 is made permanent, and the seat or seats selected are removed from inventory and blocked from duplicate sale, both graphically when presented to the next prospective customer and in the database where information for accounting and administrative purposes is retained. If the customer's payment information cannot be verified lib, then the customer is given an opportunity to correct the information or start over with a new transaction. Upon verification of the customer's payment information, the customer receives a confirmation of the transaction 13 containing all appropriate reference information for the customer's records.

Referring to Figure 2, it will be seen that, for example, a user in Houston 13 is planning to vacation in New York and wishes to see a play at a dinner theater there that utilizes the system for ticketing and reservations 15. The user, in Houston, or in any other location worldwide, connects to the internet in the conventional way and retrieves the appropriate web site through a graphical browser from a host server located in, say, Anaheim, California 14. Notably, the client node is unafilliated with the host server, i.e., need not have dedicated hardware or software to access the system. Rather, the system may be made accessible through any conventional web browser. The host server serves a seating chart for the dinner theater to the user such that the user is able to see the exact seating arrangement of the remote dinner theater and select the exact seat or seats desired for the performance of choice. Such additional information as is appropriate can be provided to the remote user to assist in making an informed decision as to which seat or seats are desired. By way of example, the host server may serve a view as seen from a particular seat tentatively selected. For example, in one embodiment, the tentative selection may be through clicking on the seat or merely detection of the cursor over the seat without a click. While in this example, the "venue" is a dinner theater, venue as used herein is not so limited and is deemed to include any forum for which seating space is sought, including without limitation, airplane or other transportation, stadiums, theaters, and the like. Referring to Figure 3, it will be seen that in view (a) of the user selected venue all seats at table Pll 17 and at table S14 18 have been previously taken and are so indicated by the graphical representation of an "X" over those seats. The potential customer wants to seat a party of four at table SI 16 and so indicates by clicking the mouse on those four seats or by so indicating through alternative standard computer input means. Once his payment method is verified, the selected seats are removed from inventory and so indicated on the graphical representation by placing an "X" over those seats 19 while retaining the "X" over those seats previously sold at table Pll 20 and table S1421. The next prospective customer is advised that these seats are no longer available for this performance by the new graphical representation that is the subsequent customer's first viewing screen upon entry into the system. In the event that two prospective customers wish to reserve the exact same seat or seats, that prospective customer who first receives validation of the payment method is given those seats, while the other prospective customer is notified that the seats desired have already been sold and offers a chance to select other seating.

Figure 4 shows the screens presented to a user when accessing the system and progressing through the process of selecting a specific seat or seats, and reserving and paying for them. Figure 4(a) is where the first screen presented shows links to available performances for that selected venue 22. Figure 4(b) is the second screen 23 and shows a view of the seating available for that venue with seats that have already been taken crossed off with an "X" 24. The hypothetical user wants to have a party of four sit at table Sll 25 and selects the four seats around that table by clicking on them with the mouse. As the mouse moves the cursor over individual seats, the seat number appears in the window at the bottom of the user's screen 26 and when the user clicks on a seat, it is added to a running tally of the seats the user has already taken 27. Only seats having not previously been taken show up in the window 26 when the cursor passes over them. After completing the selections, the user clicks on the "Reserve Seats" button and Figure 4(c) shows the next screen which requests payment information 28. The user enters the required information and again clicks the "Reserve Seats" button 29. Figure 4(d) is the next screen and it tells the user that the payment method has been accepted (or rejected) and relates information about the transaction 30 such as a transaction code and a receipt number that can be used as a ticket or as a voucher with which to redeem a ticket or tickets at the venue box office upon arrival for the performance. Finally, Figure 4(d) shows the opening screen the next visitor to the system is presented with, which is the same set of screens except that the seats reserved by the hypothetical user 31 are marked off as already taken.

Figure 5 is a code diagram of one embodiment of the invention. The ticketing and reservation system of the present invention, in one particular embodiment thereof, includes a computer program operating on a server for a wide area network (WAN), generally described by the flow chart of Figure 1 and the accompanying code example which implements one embodiment of the instant invention. First, when a user accesses the system means is provided to initialize the process and return to the user a menu from which he selects his venue of interest. This can be a selectable menu arranged by artist or date or time or specific theater or football team or baseball team or name or activity or any combination thereof such that the user is given sufficient information from which to make a decision. An example would be someone looking for the next event at a given theater at a time that starts at 7:00pm. One of many possible series of computer instructions to perform this function is:

< -.Send database query to retrieve all venues that are currently available in the system - >

< - Server receives and processes query - >

< - Query is looped until all available performances and venues are retrieved. - >

< - Markup Language engine converts result to display compatible format for output to client computer - >

< - Begin normal markup language here - >

< - Begin reservation process selecting the event date /time next to the desired venue ->

Then, upon user submittal, the server initializes the process of returning to the user all available seats:

< -.Send database query to retrieve all seats that are currently available in the system for this event - >

< - Server receives and processes query - >

< - Query is looped until all available seats are retrieved. - > < - markup language engine converts result to markup language format for output to client computer - >

< - Begin normal markup language here - >

< - Continue reservation process by selecting the desire seat or seats ->

Then, upon user submittal, a new customer record is created in the Wide Area Network server and the system is notified which database to connect to to fulfill the users request(s):

< - Send database command to insert new record in customer database and obtain record id - >

< - Send database command to insert new record in reservation "order" database and obtain record id - >

< - Send database command to insert new record for each selected seat in the reservation "detail" database - > < - Begin normal markup language here - >

< - Continue reservation process by requesting client payment information - >

Then, upon user submittal the information is passed for verification:

< - Submit client information for verification - > < - if verification is successful, send database command to update customer record in customer database with information previously collected - >

< - if verification is successful, send database command to update reservation record in reservation "order" database with verification information - >

< - if verification is successful, send database command to remove selected seats from seat inventory database and marked as no longer available for future selection - >

< - Markup language engine converts result to markup language format for output to client computer - >

< - Begin normal markup language here - >

< - If verification is successful, confirmation is generated via Markup language engine to markup language format for output to client computer - > < - if verification is unsuccessful, a failure notice is generated via Markup language engine to markup language format for output to client computer - >

< - if verification is unsuccessful, client is presented with option to provide his payment information again or abandon his reservation

- > While this is one preferred form of the code there are many other code sequences that will perform the same function that will be immediately obvious to one skilled in the art. Figure 6 is a flow diagram of a host server operation in response to a venue request in an alternative embodiment of the invention. A host server receives a venue request at functional block 600. Then, at functional block 602, the host server serves a seating chart for that venue to the requesting client node. In one embodiment, the seating chart is served as a HTML page with active links for the seats which are currently available. In another embodiment, the seating chart may be served as a Java applet. At functional block 604, the host server receives a tentative seat selection from the client node. Then at decision block 606, a determination is made on the host server whether the tentative seat selection selected at functional block 604 would orphan one or more seats. An orphan seat is deemed to be any single seat that has no available a? seat within the row.

Some venues may wish to force alternative seat selections if the tentative seat selections would orphan seats. Following alternative seat selection and the criterion for doing so may differ from venue to venue, as well as depending on the existing availablity of comparable seating that would not orphan seats. A determination is made by the host server seat at decision block 608 whether the selected venue wishes to force alternative seat selection. If the venue does not wish to force alternative seat selection, the host server may optionally nevertheless send a request that alternative seats be selected at functional block 610. A determination is made at decision block 612 after the request that alternative seats be selected is sent at functional block 610 whether the client node has accepted the request. Alternatively, if the venue wishes to force alternative seat selection at functional block 608, a message indicating that the selected seats are unavailable and possibly explaining that the venue does not permit seat selection that would orphan seats sent to the client node at functional block 614.

If at decision block 612, the request has been accepted, suggested alternative seat selections may be sent at functional block 616. The alternative suggested seat selections may also be sent subsequent to the notice that selected seats are unavailable at functional block 614. After the suggested alternative seat selection is sent at functional block 616, the determination is made whether the suggestion has been accepted by the client at decision block 618. If the suggested alternative seat selection is not accepted, a determination is made at decision block 620 whether an alternative seat selection has been received, e.g., different than the original tentative seat selection and different from the suggested alternative seat selection. If not, the interaction with the client ends. If it has, the server makes an orphan determination as to the new alternative seats. After the request is not accepted at decision block 614, or no seats would be orphaned at decision block 606, the server places a tentative reservation on the seats at functional block 622. Alternatively, the tentative reservation may be made prior to the orphan determination and cancelled if alternative seats are forced or selected. Once the tentative reservation is placed on the seats, all subsequent users accessing the server will be served the seating chart with the tentative seats shown in a representation that is different from both the representation of sold seats and the representation of unsold seats. This is termed the tentative reserve representation. In one embodiment, this takes the form of a question mark appearing over the seats, as displayed on the seating chart.

At functional block 624, a request for payment information is issued by the host server. A determination is made at decision block 626 if the payment information received is valid. If the payment information is not valid, a request is made by the server at functional block 628 for alternative payment information coupled with an indication that the prior payment information was unacceptable. If the alternative payment information is received at decision block 630, that payment information is then verified at functional block 626. If not, the tentative reservation is removed at functional block 632. This returns the representation of the seat on subsequently served seating charts to the unsold representation. If the payment information is valid at decision block 626, the reservation is made permanent, and the representation of the seat on the seating chart is changed to the permanently reserved reservation representation. A printable receipt, ticket, or voucher sufficient to permit access to the event is then served to the client node.

Figure 7 shows a sample of seating chart in one embodiment of the invention. As shown in the figure, seats C and D in row 10 are shown in a tentatively reserved representation. The "Xs" mark seats which are permanently reserved, and the circles with no indication represent seats in the unsold state. Seat 10(i) would be considered an orphan seat.

Figure 8 is a code diagram of a code segment which implements the tentative reservation aspect of one embodiment of the invention. Numerous other codings are, of course, possible.

Those having skill in the art to which the present invention pertains will now understand that there are virtually unlimited uses for the present invention. By way of example, the present invention may be readily used to reserve specific seats on commercial airliners or reserve specific staterooms on a cruise ship, as well as for reserving seats for any venue from community theater or little league baseball to major league sporting events.

In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes can be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. Therefore, the scope of the invention should be limited only by the appended claims.

Claims

CLAIMSWhat is claimed is:

1. A method comprising: transmitting specific seat availability information to a user across a wide area network to an unaffiliated client node; receiving an indication of tentative seat selection from the user across the wide area network; and accepting payment from the user; and denoting the seat as unavailable to future users.

2. The method of claim 1 further comprising: indicating to any subsequently requesting client node that the tentative seat selections are tentatively unavailable until a transaction is completed or voided.

3. The method of claim 1 further comprising: identifying if the tentative seat selection would orphan at least one unselected seat.

4. The method of claim 3 further comprising: denying a reservation of the tentative seat selection if the tentative seat selection would orphan at least one unselected seat.

5. The method of claim 3 further comprising: requesting that the user make a different selection if the tentative selection would orphan at least one seat; and suggesting a different selection that would not orphan at least one seat.

6. The claim of 5 further comprising: denying a reservation of the tentative seat selection if the tentative seat selection would orphan at least one selected seat if alternative seats of a same class are available that would not orphan a seat.

7. The method of claim 2 wherein indicating comprises: changing a representation of a seat from a first representation to a second representation; and transmitting the second representation to a client node.

8. The method of claim 7 further comprising: changing the representation of the seat from the second representation to a third representation if the transaction is completed; and changing the representation of the seat from the second representation to the first representation of the transaction is voided.

9. The method of claim 1 further comprising: providing additional information about the tentative seat selection to the user across the wide area network.

10. A system comprising: a host server coupled to a wide area network (WAN); and a database coupled to the server, the database, the database populated with entries reflecting seating availability for at least one venue; wherein the host server serves seating information on demand responsive to a request of an unaffiliated node.

11. The system of claim 10 wherein seating information comprises: a seating chart for the venue showing available seats in a first representation, tentatively unavailable seats in a second representation, and unavailable seats in a third representation;

12. The system of Claim 10 wherein the server serves pages providing a graphical user interface from which a user may select specifically desired seats from the venue.

13. A method comprising: requesting a venue at an unafilliated client node from a host server; receiving a seating chart for the venue; tentatively selecting seats shown in a first representation from the seating chart; and providing payment information.

14. The method of claim 13 further comprising; receiving the seating chart showing the tentatively selected seats in a second representation while a transaction is pending.

15. The method of claim 14 further comprising; receiving the seating chart showing the tentatively selected seats in a third representation once the transaction is complete; and receiving a printable electronic receipt sufficient to permit access to the venue.

16. A method comprising:

(a) communicating on demand, from an information server through a wide area network to a device connected to the wide area network information from a database populated by a multiplicity of entries denoting availabilityfor a venue;

(b) displaying the information such that an end-user connected to the wide area network can view the information on a client node unaffiliated with the server as an aid in determining a best then available space conforming to a need of the end-user;

(c) providing over the wide area network to the end user the capability of interactively selecting a time, a space, and a seat of choice;

(d) accepting over the wide area network from the end user a payment for one of the time, the space, and the seat selection of choice;

(e) returning over the wide area network to the end user verification of the successful completion of the payment.

17. The method described in claim 16 wherein the space, the time, and seat sought is for a theater or theater type setting.

18. The method described in claim 16 wherein the space, the time, and the seat sought is for a stadium type setting.

19. The method described in claim 16 wherein the space or time or seat or seating sought is for an airplane or airliner.

20. The method described in claim 16 wherein the space or time or reservation sought is accommodations on a cruise ship.

21. The method described in claim 16 wherein a communication connection between the information server and the end user includes one of a wire, a cable, and a telephone line connection.

22. The method described in claim 16 wherein a communication connection between the information server and the end user includes a satellite link.

23. The method described in claim 16 wherein a communication connection between the information server and the end user includes a wireless link.

24. The method described in claim 17 wherein the communication connection between the information server and the end user is wireless.

25. A method comprising: receiving at a server a request for a venue from at least one client node remote from and unaffiliated with the server; transmitting from the server an indication of specific availability responsive to the request, the indication of specific availability directed to the client node; receiving a specific indication of a client preference at the server; removing the client preference from any future indication of specific availability.

26. The method of claim 25, wherein the specific availability includes seating, further comprising: retrieving from a database an image showing a view from a seat indicated by the client preference; transmitting the image to the client.

27. The method of claim 25, wherein the indication of specific availability includes a graphical representation of at least a portion of a seating chart for the venue, and wherein the graphical representation shows availability seats in a first representation and previously sold seats in a second representation.

28. The method of claim 25, wherein the indication of the specific availability is transmitted as one of a hypertext markup language page and a Java applet.

29. The method of claim 27 further comprising: linking the representation of a seat to an image of a view from that seat.

30. The method of claim 25 further comprising: accepting payment information at the server sufficient to permit access to the specific client preference; conducting an electronic payment transaction; and providing an electronic receipt.

31. A method comprising: requesting information about a venue across a wide area network (WAN) from a client node to be supplied by an unaffiliated server node; receiving an indication of specific availability at the client node; selecting from a plurality of specific availability options a specific client preference; and receiving an indication that the specific client preference has been reserved through the server node.

32. The method of claim 31 wherein the indication of specific availability includes a graphical representation of at least a portion of a seating chart for the venue, and wherein the graphical representation shows available seats in a first representation and previously sold seats in a second representation.

33. The method of claim 32 wherein selecting comprises: clicking on a desired seat.

34. The method of claim 33 further comprising: receiving an image of a view from the desired seat responsive to the clicking.

35. The method of claim 31 further comprising: supplying payment information for the specific client preference; and

receiving an electronic receipt sufficient to permit access to the specific client preference.