JP4368170B2 - Ticket allocation system and computer program and method for realizing the same - Google Patents

Description

  The present invention relates to a system related to sales of electronic tickets.

Currently, many performances such as concerts and sports are held in various places. In general, ticket sales companies sell tickets by accepting telephone calls directly from applicants. Recently, there are increasing cases of selling electronic tickets using the Internet.
When a ticket sales company receives a ticket application by telephone or the Internet, the ticket sales company allocates a predetermined seat to the purchaser and sells the ticket.
In addition, ticket sales companies draw lots and sell tickets only to winners when the number of ticket applications exceeds the limit at popular concerts.

Japanese Patent Application No. 11-310722

However, with the conventional methods, the organizer has unilaterally decided who will be assigned to which seat, so it has not been possible to satisfy the purchasers' various “feelings”. In other words, each ticket purchaser has a discerning seat and seating zone (persons who want a position close to the stage, on the contrary, those who want a position away from the stage, people who want a seat along the aisle, seats on the second floor, The person who wants the front row of the company, etc.) has not been able to satisfy the purchaser's commitment.
In addition, lottery is performed for popular box offices because the application for ticket purchase is inundated, but in the conventional method, the purchaser has to leave it to luck whether to win or lose, and increase the probability of winning by himself. I couldn't.
The present invention has been made in view of such problems. By introducing the concept of a seat zone, it is possible for a ticket purchaser to designate a special zone and to increase the winning rate by himself in the lottery. It also provides a system that makes it possible.

The present invention is, for example, a system, method, and computer program that causes a computer to function as follows. (1) It comprises a plurality of seating areas at the entertainment venue, storage means for storing the allowable number of people in each seating area, and ticket management means for managing tickets, wherein the ticket management means is a ticket for application data for purchasing an entertainment ticket. Application data receiving process for receiving application data including ticket purchase means for applying for purchase, wherein the ticket management means includes a purchaser and a desired area for specifying the seat area desired by the purchaser. Means for calculating the number of applications for each seat area based on the application data and creating application status management information consisting of the purchaser and the desired area, for seat areas where the number of applications is less than the allowable number Means for performing a second allocation process for allocating the purchaser as a ticket right holder to the desired area included in the application data; Means for updating the allowable number of persons and the number of applications based on the allocated number of persons, each seat based on the number of applications updated by the number of persons update process and the allowable number of persons after completion of the number of persons update process Means for performing a congestion status browsing process for creating a congestion status of an area and allowing the ticket application means to browse the congestion status, data for changing a desired area, and change application data including the purchaser and the desired area Means for performing a change application accepting process to be accepted after the completion of the number update process, updating the application status management information based on the change application data, and adding the purchaser to the desired area included in the updated application status management information And a means for performing a third assignment process for assigning as a ticket right holder. (2) The second allocation process includes a seat area in which the number of applications is less than an allowable number of persons and a seat area in which the number of applications is greater than or equal to the allowable number of seat areas and meets an allocation execution condition stored in the storage unit. It is characterized by being performed about.

The present invention has the following effects.
(1) By using the present invention, a purchaser can view a concert or the like in a special zone or a favorite zone. This increases customer satisfaction.
(2) In the present invention, once desired zone can be changed later, the winning probability can be increased by itself.
(3) If the allocation process is performed after the first application data is received, the first application data reception process does not send the application data for the first time, and after viewing the reservation status, the application is made in the second application data reception process. The case of transmitting data can be prevented, and fairness with the person who transmitted the transmission data in the first application data reception process can be secured. In addition, application data is not concentrated in the second application data reception process, and the load on the server 1 can be reduced.

  The present invention relates to a system related to sales of electronic tickets. Hereinafter, description will be given based on the drawings.

A first embodiment of the present invention will be described with reference to the drawings. FIG. 1 is a schematic diagram showing hardware necessary for implementing the present invention and the connection of the hardware.
These hardwares consist of a server 1 and a PC 2 (personal computer).
The server 1 and the PC 2 can transmit and receive data via the Internet 3 (or other communication means).
The server 1 and the PC 2 each include a storage device for storing data, a data transmission unit for transmitting / receiving data, and a data reception unit, and perform data transmission / reception using them.

Each storage device stores a computer program and predetermined data for realizing the present invention, and the server 1 and the PC 2 perform predetermined processing in accordance with processing instructions of the computer program. The PC 2 is provided with a display monitor 11 for displaying data and a keyboard 12 for inputting data.
In this embodiment, the server 1 serves as ticket management means, the PC 2 serves as ticket application means, and the storage device provided in the server 1 serves as storage means. The display monitor 11 provided in the PC 2 serves as input means, and the keyboard 12 serves as output means.

  Next, a processing procedure for realizing the present invention will be described. The processing procedure of the present invention is as shown in FIG. 2 <Processing flow A>, and is performed according to the procedure of <first application data reception: STEP1-1> → <lottery and seat assignment: STEP1-2>. In addition, the process connected by the dotted line represents that the processes are similar. Hereinafter, these processes will be described.

<First application data reception: STEP1>
Taro Yamada, who lives in Tokyo, wants to watch a concert by a popular singer. Mr. Yamada accessed the homepage of a ticket sales company to make a reservation application for tickets (electronic tickets). As a result, the contents as shown in FIG. 3 are displayed on the display monitor 11 of the PC 2. That is, the seats of this concert venue are divided into three zones (zone A, zone B, and zone C), and the ticket purchaser can specify which zone seats he / she wants. It is assumed that Mr. Yamada is already a member of this ticket sales company, his address, name, etc. have already been registered, and an ID (customer ID) as a customer of this company has already been acquired.
Mr. Yamada inputs his customer ID and desired zone (zone A) according to the display screen, and clicks “Send” at the bottom of the screen. As a result, the PC 2 creates the first application data (FIG. 4) “customer ID: 9715, desired zone: zone A, number of people: 1”, and transmits it to the server 1. Originally, the ID of the concert desired to be viewed and the desired date of viewing should be transmitted here, but these are not relevant here and are omitted here. In the present embodiment, the first application data plays a role as application data, and the customer ID included in the application data plays a role as a purchaser (purchaser specifying information for specifying the purchaser). The desired zone included in the application data serves as a desired area.

The server 1 that has received (received) the first application data stores it in the storage device.
Next, the server 1 performs processing for updating (creating) the zone management file based on the received application data. In the storage device of the server 1, a zone management file for managing each zone (FIG. 5) “zone name: zone A, allowable number of people: 50, number of applications: 0, applicant ID: no information / zone name: zone B , Allowable number of persons: 70, number of applications: 0, applicant ID: no information / zone name: zone C, allowable number of persons: 90, number of applications: 0, applicant ID: no information ”is stored. This consists of a zone management record (a plurality of records) in which the zone name, the number of people allowed by the zone, the number of applications for the zone, and the applicant ID are associated (corresponding). This file can be used to manage zones.

The server 1 updates the zone management file based on “customer ID: 9715, desired zone: zone A” included in the first application data. That is, 1 is added to the number of applications in zone A in FIG. 5 and “9715” is assigned to the applicant ID item in zone A. Thereby, the zone management file is updated as shown in FIG. This zone management file serves as application status management information.
In this way, the server 1 receives a plurality of first application data from a plurality of customers for a certain period, and updates the zone management file by the same processing. As a result, the zone management file is as shown in FIG. The number of applications included in the zone management file is the number of persons included in the application data by the server 1 for each zone.

<Lottery and seat assignment: STEP2>
Next, the server 1 performs a lottery process. First, the server 1 determines whether or not the number of applications in each zone exceeds the allowable number of people, and if so, performs a lottery process for that zone. That is, since there are the number of applications “79” for the zone A that greatly exceeds the allowable number of people “50”, the server 1 makes a lottery by selecting 50 winners and the remaining 29 winners. On the other hand, the lottery process is not performed in Zone B and Zone C because the number of applicants is less than the allowable number. This lottery process is known, and for example, an arbitrary 50 people are extracted from 79 applicants (applicant IDs) using a random number generation function provided in the server 1. That is, the server 1 determines a winner and a loser by a lottery process, leaves only the winner's ID in the applicant ID field of the zone management file, and deletes the winner's ID (the winner's ID is The lost winner data “Zone A lost winner: 3331, 2888,...” Etc. may be created and stored separately). An example of other lottery processing is also shown in Japanese Patent Laid-Open No. 2001-155203.

Next, the server 1 performs processing (assignment processing) for assigning each seat to the applicant (winner). That is, a process for assigning a purchaser (a purchaser specified by a customer ID) to a desired zone as a ticket right holder is performed. The storage device of the server 1 stores a seat management file as shown in FIG. This is a file in which the seat number is associated with the ID of the right holder, zone A on the left, zone B on the center, and zone C on the right. FIG. 8 “Zone A“ A001: No information / A002: No information / A003: No information /.../ A049: No information / A050: No information ”Zone B“ B001: No information / B002: No information / B003: Information None /.../ B066: No information / B067: No information / B068: No information / B069: No information / B070: No information, Zone C "C001: No information / C002: No information / C003: No information /.../ “C047: No information / C048: No information / C049: No information /.../ C088: No information / C089: No information / C090: No information” ” Absent.
The server 1 assigns the applicant ID stored for each zone in the zone management file of FIG. 7 to the right holder ID of FIG. 8 for each zone. As a result, the seat management file is updated to the contents shown in FIG.

Thereafter, the server 1 uses an electronic ticket for each seat (ticket data: FIG. 10) “Entertainment ID: T008, Rightsholder ID: 9715, Exhibition Name: XX Concert, Date / Venue: XX Month XX Day XX Stadium, “Seat: A001” is created and issued to each customer. In addition, box office ID etc. shall be obtained with reference to another file memorize | stored in the memory | storage device.
In this way, a person who purchases a ticket can obtain a ticket in a favorite zone (a favorite zone), and can view a concert in the favorite zone.

  A second embodiment of the present invention will be described. In the present embodiment, the zone once designated by the ticket purchaser can be changed later. In other words, in the first embodiment, applications concentrated in Zone A and many lost winners appeared, but on the contrary, many vacant seats remained in Zone C. And if a loser in Zone A can change his original desired zone (Zone A) to Zone C, he must have been able to obtain a ticket for the concert. This embodiment corresponds to such a case, and the zone once designated by the ticket purchaser can be changed later.

The hardware necessary for implementation of the present embodiment and the connection of the hardware are the same as those in the first embodiment described above, and are the same as those in FIG.
Next, a processing procedure for realizing the present invention will be described. The processing procedure of the present invention is as shown in FIG. 2 <Processing flow B>. <First application data reception: STEP2-1> → <Reservation status browsing: STEP2-2> → <Second application data reception: STEP2-3 > → <Lottery and seat assignment: STEP2-4> Hereinafter, these processes will be described.

<First application data reception: STEP2-1>
This process is the same as in the first embodiment. That is, as shown in FIGS. 3 to 7, the process is the same as in the first embodiment until the server 1 receives a plurality of first application data and updates the zone management file as shown in FIG. 7.

<Reservation status browsing (congestion status browsing processing): STEP2-2>
Next, the server 1 performs processing for notifying the ticket applicant of the reservation status. In other words, the ticket applicant is allowed to view the reservation status of each zone (zone A is flooded with applications and the probability of being rejected is high, zone C has a small number of applications and a ticket can be obtained reliably) Processing for causing the ticket purchaser to determine whether or not to change the zone is performed.
In the storage device of the server 1, a display mode file for determining a display mode (FIG. 11) “Condition (number of remaining seats): 0 or less, Display mode: Full / Condition (number of remaining seats): 1 to 5, Display mode: “Remaining / condition (remaining seats): 6 or more, display mode: remaining” is stored. This is for determining what kind of wording is displayed according to the number of remaining seats in each zone. The number of remaining seats is calculated based on the number of applications and the allowable number of people in the zone management file in FIG. 7 (by obtaining the difference between the allowable number of people and the number of applications).
The server 1 searches the display mode file using the number of remaining seats for each zone as a search key, and based on the result, reservation status data (not shown) “Zone A: Full / Zone B: Low / Zone C” : Remaining ”is generated, and the reservation status data is transmitted to the PC 2 in response to the reservation status request from the PC 2. The reservation status data plays a role as a congestion status.

The PC 2 that has received the reservation status data stores it and displays it on the display monitor 11 as shown in FIG. At this point, it is assumed that no customer ID or desired zone has been input. Mr. Yamada who saw FIG. 12 knew that Zone A he wanted was already full (the possibility that he could not win a ticket because he was defeated). Mr. Yamada thought that the desired zone is Zone A, but Zone C can be used as long as the seat can be secured more securely. Therefore, Mr. Yamada entered the customer ID and desired zone in FIG. 12, and clicked “Send” at the bottom of the screen.
As a result, the PC 2 creates the second application data (FIG. 13) “customer ID: 9715, desired zone: zone C, number of people: 1” and transmits it to the server 1. The second application data serves as change application data.

<Second application data reception (change application reception processing): STEP2-3>
The server 1 that has received the second application data stores it in the storage device and updates the zone management file.
Therefore, first, the server 1 searches the zone management file (applicant ID item) in FIG. 7 using “customer ID: 9715” included in the second application data as a search key. Thus, the server 1 specifies that Mr. Yamada originally wanted the zone A, but changed it to the zone C (“desired zone: zone C” included in the second application data). In the zone management file in the state shown in FIG. 7, the server 1 reduces the number of applications for zone A by “1” and selects “applicant ID: 9715” (“customer ID included in the second application data” from the zone A applicant ID item. ID: 9715 ") is deleted. Then, “1” is added to the number of applications in zone C, and “9715” is added to the applicant ID in zone C. As a result, the zone management file changes from the state shown in FIG. 7 to that shown in FIG.
In this way, the server 1 receives a plurality of second application data for a certain period and repeats the update of the zone management file. As a result, the zone management file becomes as shown in FIG. 15, and thereafter the server 1 performs <lottery and seat assignment: STEP2-4>.

<Lottery and seat assignment: STEP2-4>
Next, the server 1 performs a lottery process. That is, in the present embodiment, the number of applications exceeds the allowable number for zone A (FIG. 15), so the server 1 draws for zone A. Since the lottery process is the same as that in the first embodiment, the description is omitted here.
Next, the server 1 performs an allocation process (first allocation process) based on the zone management file updated in the second application data reception process. Since this allocation process is the same as that of the first embodiment, the description thereof is omitted here. By this allocation process, the right holder of each seat determines as shown in FIG.
In this way, the ticket purchaser can change the desired zone and increase the winning rate by himself.

A third embodiment of the present invention will be described. This embodiment is substantially the same as the second embodiment, but differs in that the first seat assignment process is performed after the first application data is received. In the case of the second embodiment, the seat allocation is performed only once after the second application data is received. However, most people ignore the first application data reception process and only apply the application data in the second application data reception process. There is a possibility of sending. That is, in the second embodiment, the application data can be changed or transmitted in the second application data reception process without transmitting the application data in the first application data reception process, so there is no need to dare to transmit the first application data. . Therefore, there are cases where the first application data reception process does not send the application data but looks at the situation or sends appropriate data, and after viewing the reservation status, the application data is transmitted in the second application data reception process. There is a risk of secondary occurrence. However, this impairs the purpose of providing the first application data reception process, and the person who has transmitted the application data in the first application data reception process lacks fairness. Further, if application data concentrates on the second application data reception process, the server 1 may be overloaded and unexpected troubles may occur. It is most likely that applications will concentrate immediately before the deadline of the second application data reception process. Therefore, in the present embodiment, after the first application data reception process, a process for allocating seats immediately is performed for applications where the number of applications is less than the allowable number.
Hereinafter, this embodiment will be described.

  The hardware necessary for implementing the present embodiment and the connection of the hardware are the same as those in the first embodiment described above, and are the same as those in FIG.

  Next, a processing procedure for realizing the present invention will be described. The processing procedure of the present invention is as shown in FIG. 2 <Processing Flow C>, <First Application Data Reception: STEP3-1> → <First Seat Assignment: STEP3-2> → <Reservation Status Browsing: STEP3-3 > → <Second application data reception: STEP 3-4> → <Lottery and second seat assignment: STEP 3-5> Hereinafter, these processes will be described.

<First application data reception: STEP3-1>
This process is the same as in the first embodiment and the second embodiment. That is, as shown in FIG. 3 to FIG. 7, it is the same as the first embodiment and the second embodiment until the server 1 receives a plurality of first application data and updates the zone management file as shown in FIG. It is.

<First seat allocation: STEP3-2>
Next, the server 1 performs seat allocation processing (second allocation processing) for zones where the number of applications is less than the allowable number. In FIG. 7, since the number of applications for the zones B and C is less than the allowable number, seats are allocated for these two zones. The allocation process is the same as in the first embodiment and the second embodiment. Accordingly, since the number of applications for zone B is “67”, seats from B001 to B067 are assigned (FIG. 17), and for zone C, the number of applications is “48”, so seats from C001 to C048 are assigned (FIG. 17). ). On the other hand, since the number of applications for zone A exceeds the allowable number, the allocation process is not performed here.
Next, the server 1 performs processing for updating the zone management file (FIG. 7) (number of people updating processing for updating the zone management file based on the number of people assigned in the second assignment processing). Initially, the allowable number of people in Zone B was “70”, but as described above, up to 67 seats were assigned to Zone B, so Server 1 sets the allowable number of Zone B to “3” and the number of applications to “0”. And the applicant ID is no information (FIG. 18). Similarly, the allowable number of people in zone C is set to “42”, the number of applications is set to “0”, and the applicant ID is set to no information (FIG. 18).

Next, the server 1 performs processing of <reservation status browsing: STEP3-3> for creating a reservation status based on the zone management file (FIG. 18) updated in the number of people update processing. It is the same as the form.
Next, the server 1 performs <second application data reception: STEP3-4>. The contents of the second application data are the same as those in FIG. 13 of the second embodiment. Then, the server 1 that has received the application data updates the zone management file. Specifically, it updates from FIG. 18 to FIG.
The server 1 repeatedly accepts a plurality of second application data, and the zone management file is updated as shown in FIG. 20 after the second application data acceptance process is completed.

Next, the server 1 performs the process of <Lottery and second seat allocation: STEP 3-5>. That is, for the zone A, the lottery is performed as in the first embodiment and the second embodiment. In Zone B, the number of applications exceeds the allowable number, so a lottery is performed.
Then, for zone A, a process for assigning seats from A001 to A050 (third assignment process) is performed (FIG. 21). In addition, since seats have already been assigned to B067 for zone B, seats are assigned to the winners for the remaining B068 to B070 (FIG. 21). In Zone C, seats have already been allocated up to C048 and the number of applications is “15”, so seats are allocated for the remaining C049 to C063 (FIG. 21: No assignment is made since there is no applicant after C064). , Will be vacant).
In this way, if the first allocation process is performed after the first application data reception process, the first application data reception process does not send the application data, and after viewing the reservation status, the second application data reception process is performed. The case where application data is transmitted in the application data reception process can be prevented, and fairness with the person who transmitted the transmission data in the first application data reception process can be ensured. In addition, application data is not concentrated in the second application data reception process, and the load on the server 1 can be reduced.

  A fourth embodiment of the present invention will be described. This embodiment is substantially the same as the third embodiment, but the conditions for performing the first allocation process (second allocation process: STEP3-2) are different. That is, in the third embodiment, the first allocation process is performed only when the number of applications is less than the allowable number. If the number of applications conforms to the allocation execution condition, the first allocation process is performed. Hereinafter, these will be described.

In the first application data reception process, it is assumed that the number of applications for each zone is totaled and the zone management file is updated as shown in FIG. 4-1 (Note that FIG. 4-1 corresponds to FIG. 7 in the third embodiment). The difference between FIG. 7 and FIG. 4-1 is that the number of applications in Zone B is “74”, which exceeds the allowable number of people “70”).
The server 1 has an allocation execution condition “Zone A: 55 people or less, Zone B: 77 people or less, Zone C: 99 people or less” stored in the storage device (the number of allowed people plus 10%: not shown) ) Is stored, and the server 1 compares the number of applications in each zone with this allocation execution condition, and performs the first allocation process only for zones (zone B, zone C) that meet this condition. That is, for the zone B, 70 seats are allocated by lottery, and for the zone C, seats are allocated without lottery.

As a result, the seat management file becomes as shown in FIG. 4B. For zone B, customers are assigned to all seats, and for zone C, seats are assigned to 48 people. Then, the server 1 performs the number update process, and the zone management file is as shown in FIG. 4-3. That is, the allowable number of people in zone B is updated to “0”, and the allowable number of people in zone C is updated to “42”. As described above, the present embodiment preferentially allocates seats not only in the case where the number of applications is less than the allowable number, but also in a zone where the number of applications is slightly higher than the allowable number.
In this way, a customer who wants a zone that is not statistically popular (a niche customer) is more likely to acquire a seat depending on the degree of that niche (popularity). Since the customer can select a popular zone or a less popular zone on his / her will, the customer can be more convinced if he / she is out of the lottery, and he / she can also be convinced about the zone of the ticket that has been taken. That is, this invention can provide a lottery system with high customer satisfaction. In this embodiment, the allocation execution condition is 10% of the allowable number of people, but the present invention is not limited to this.

  In addition, although it is set as the seat zone in the said embodiment, this is not necessarily restricted to having a seat. For example, in the case of standing viewing, a seat is not required, but the seat zone includes a case where there is no seat as in standing standing. In addition, the allowable number of seat zones can be set freely in a form that matches the venue configuration. Therefore, the allowable number of persons may be “1”, and in this case, the seat zone is used as it is.

Although specific cases have been described in the above embodiment, the present invention is not limited to these specific cases. For example, the following cases may be used.
(1) Although the above embodiment has been described by taking a concert as an example, the present invention is not limited to this. For example, it can be used in all cases such as tickets for watching sports. In the above embodiment, the zone A is a zone close to the stage, the zone B is an intermediate zone, and the zone C is the farthest zone from the stage. However, the present invention is not limited to this. The aisle seat may be a single zone, or may be a single zone in the front row of the second floor seats. That is, the zone can be freely divided.
(2) The content of the data is not limited to the data described in the embodiment. That is, any other data may be used as long as it can play the same role.
(3) The hardware is not limited to that described in the embodiment. That is, any other hardware may be used as long as it can play the same role. For example, the ticket application means is not limited to a PC (personal computer) but may be a mobile phone, a PHS, a portable small computer, or the like.
(4) The contents and procedure of the process are not limited to those described in the embodiment. That is, any other processing content / procedure may be used as long as it can play the same role.
(5) It is assumed that data (data items) of data (data records, files) appearing in the above-described embodiments are stored in association with (associated with) each other in principle. The same applies to what is shown in the drawings.

It is a figure which shows the outline of the hardware utilized by this invention. It is a figure showing a processing flow. It is a figure showing desired zone application. It is a figure showing the 1st application data. It is a figure showing a zone management file. It is a figure showing a zone management file. It is a figure showing a zone management file. It is a figure showing a seat management file. It is a figure showing a seat management file. It is a figure showing ticket data. It is a figure showing the display mode file. It is a figure showing a desired zone change application screen. It is a figure showing the 2nd application data. It is a figure showing a zone management file. It is a figure showing a zone management file. It is a figure showing a seat management file. It is a figure showing a seat management file. It is a figure showing a zone management file. It is a figure showing a zone management file. It is a figure showing a zone management file. It is a figure showing a seat management file.

Explanation of symbols

1 Server 2 PC (computer)
3 Internet 11 Display monitor 12 Reader / writer

Claims (6)

The ticket management means comprises a plurality of seating areas in the entertainment venue, storage means for storing the allowable number of persons in each seating area, and ticket management means for managing tickets. Means for accepting the application data including the purchase area and the desired area for specifying the seat area desired by the purchaser. , Means for calculating the number of applications for each seat area based on the application data and creating application status management information consisting of the purchaser and the desired area; for seat areas where the number of applications is less than the allowable number, Means for performing a second allocation process for allocating the purchaser as a ticket right holder to the desired area included; Means for updating the number of applications and the number of applications based on the number of registered persons, and each seat area based on the number of applications updated by the number of persons update process and the allowable number of persons after completion of the number of persons update process Means for performing congestion status browsing processing for creating the congestion status of the ticket and allowing the ticket application means to browse the congestion status, and data for changing the desired area, the change application data including the purchaser and the desired area A means for performing a change application acceptance process received after completion of the number update process, updating the application status management information based on the change application data, and placing the purchaser in the desired area included in the updated application status management information A ticket allocation system comprising: a third allocation process for allocation as a ticket right holder. The second allocation process is performed for a seat area where the number of applications is less than the allowable number of persons and a seat area where the number of applications is equal to or greater than the allowable number of seat areas and meets the allocation execution condition stored in the storage means. The ticket allocation system according to claim 1. Ticket management means for managing a ticket comprising a plurality of seat areas at the entertainment venue and storage means for storing the permissible number of persons in each seat area includes a purchaser and a desired area for specifying the seat area desired by the purchaser A means for performing application data reception processing for receiving application data for box office ticket purchase, a means for counting the number of applications for each seat area based on the application data and creating application status management information comprising the purchaser and the desired area The seat area for which the number of applications is less than the allowable number, means for performing a second allocation process for allocating the purchaser as a ticket right holder to the desired area included in the application data, the number of persons allocated by the second allocation process Means for performing a number update process for updating the allowable number of persons and the number of applications based on the number of persons updated by the number update process after completion of the number update process Data for changing a desired area, a means for performing a congestion situation browsing process for creating a congestion situation of each seat area based on the number of applications and the allowable number of persons and allowing the ticket application means to browse the congestion situation; Means for performing change application reception processing for receiving change application data including the purchaser and the desired area after completion of the number of people update processing, updating the application status management information based on the change application data, and updated application status A computer program for ticket allocation, which functions as means for performing a third allocation process for allocating the purchaser as a ticket right holder to the desired area included in management information. The second allocation process is performed for a seat area where the number of applications is less than the allowable number of persons and a seat area where the number of applications is equal to or greater than the allowable number of seat areas and meets the allocation execution condition stored in the storage means. The computer program for ticket allocation according to claim 3. A ticket management means for managing a ticket comprising a plurality of seat areas at a performance hall and a storage means for storing the allowable number of persons in each seat area includes a purchaser and a desired area for specifying the seat area desired by the purchaser. Perform application data reception processing to accept application data for box office ticket purchase, total the number of applications for each seat area based on the application data, create application status management information consisting of the purchaser and desired area, and apply For seat areas whose number is less than the allowable number, perform a second assignment process for assigning the purchaser as a ticket right holder to the desired area included in the application data, and based on the number of persons assigned by the second assignment process A number update process is performed to update the allowable number of persons and the number of applications, and the number of applications updated by the number of persons update process and the permission Data for changing the desired area by creating a congestion situation of each seat area based on the number of people and performing the congestion situation browsing process for allowing the ticket application means to browse the congestion situation, and the purchaser and the desired area Change application reception processing is received after completion of the number of people update processing, the application status management information is updated based on the change application data, and the desired area included in the updated application status management information And performing a third allocation process for allocating the purchaser as a ticket right holder. The second allocation process is performed for a seat area where the number of applications is less than the allowable number of persons and a seat area where the number of applications is equal to or greater than the allowable number of seat areas and meets the allocation execution condition stored in the storage means. The ticket allocation method according to claim 5, wherein:

Images