JP2009301513A - Lottery device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a large number of different persons with participation rights, as much as possible, through a plurality of events. <P>SOLUTION: This lottery device has a lottery server 3 for determining a winning person of a ticket by lottery. The lottery sever 3 classifies participants of the lottery recorded in an entry information DB into a plurality of groups different in priorities, based on one or more of conditions, and determines the winning person by the lottery sequentially in the descending order of the priority. The one or more of conditions include, for example, that the number of past purchases of the tickets is a threshold value or less, based on a storage content of a purchase history DB. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a technique for determining winners of participation rights in various events by lottery.

  Conventionally, when purchasing tickets for events or the like, it is common to reserve or purchase tickets for a desired concert at a ticket sales company through the Internet or telephone.

  However, for example, a concert ticket of a popular artist is a fan who really loves the music of the artist because there are people who want to buy it or there are people who purchase it for the purpose of gaining resale. However, it is difficult to obtain.

For this reason, in Patent Document 1 below, each artist's fan club performs membership registration, as is known a lottery method in which a voter registered as a member (lottery applicant) is a winner. There is a case where a person who has obtained a ticket purchase right is given priority. The member who has obtained the ticket purchase right can exchange the ticket purchase right and the ticket by paying the price.
JP 2003-44622 A

  However, recently, there are cases where the number of members of the fan club is large, or there is a person who obtains a large amount of ticket purchase rights through the fan club in some way. A difficult case has arisen.

  In light of the above problems, an object of the present invention is to provide a lottery apparatus for allowing as many different persons as possible to obtain a participation right through a plurality of events.

  In order to achieve the above object, the lottery device of the present invention is a device for determining the winner of the event participation right by lottery, and the member identification information of the applicant for the lottery is selected as the event identification information and the winner. Application information DB stored in association with information indicating whether or not, a purchase history DB that stores member identification information of the purchaser of the participation right in association with identification information of the event, and an application for the lottery A lottery reception means for recording the identification information of the event to be received and the member identification information of the applicant in the application information DB, and the priority of the applicant recorded in the application information DB based on one or more conditions A lottery means for determining the winners in order from the highest priority group, and updating the stored contents of the application information DB; and payment of the participation right And the means for recording the member identification information of the corresponding winner as the member identification information of the purchaser in the purchase history DB, the one or more conditions are stored contents of the purchase history DB. And the condition that the number of purchases of past participation rights is equal to or less than a threshold value.

  In the embodiment of the present invention, the lottery means adds the lost winners generated from the lottery group to the next priority group, and then draws the next priority group lottery. .

  In another embodiment of the present invention, the purchase history DB stores the purchaser's member identification information in association with information indicating whether the purchaser has resold the participation right, and stores the participation right. Accepting resale requests and purchase requests for participation rights to be resold, and on the condition that the purchase requester does not hold duplicate participation rights for the same event based on the stored contents of the purchase history DB In the purchase history DB, information indicating that the reselling request has been resold is recorded in the purchase history DB, and the purchase requester is identified as a purchaser of the entitlement right. You may make it provide the resale means which matches and records information on the identification information of the event corresponding to the said participation right.

  In another embodiment, the one or more conditions may include a condition that the number of reselling participation rights is equal to or less than a threshold based on the stored contents of the purchase history DB.

  In yet another embodiment, member identification information of a purchaser who has not resold the participation right and event identification information corresponding to the participation right are extracted from the purchase history DB, and ticket sales are performed as confirmed information regarding the event participant. You may make it provide the fixed information transmission means transmitted to a system. In this case, the confirmed information transmitting means may be further configured to transmit the confirmed information as information for authenticating a visitor to a terminal installed at a target event venue.

  In still another embodiment, there is provided means for accessing a DB for storing fan club member information for each artist, wherein the event identification information includes artist identification information for each event, and the one or more conditions are: It is preferable to include a condition that the applicant for the lottery is a fan club member of the artist of the event to be applied.

  According to the present invention, the past purchase rights purchase history for each member is managed, and a plurality of events can be obtained by having a member with a small number of purchases of the participation right win a lottery of the participation right in preference to other members. To provide as many different members as possible with opportunities to participate in the event.

  Embodiments relating to the lottery apparatus of the present invention will be described below with reference to the drawings. In the embodiment, the lottery device is configured to be communicable with other devices via a network, and is referred to as a lottery server.

  FIG. 1 shows a configuration of a ticket transaction system 1 configured using a lottery server 3.

  The ticket transaction system 1 is a system for trading the right to participate in an event (for example, a concert) through a network such as the Internet for members of the system 1. In this embodiment, the right to participate in the event is referred to as a “ticket”. The “ticket” includes not only a ticket embodied in paper or the like but also a right to purchase such a ticket (so-called ticket purchase right).

  The ticket transaction system 1 includes a lottery server 3, an FC server 5, a ticket sales company server 7, a venue terminal 9, and user terminals 11 a, 11 b, and 11 c that are connected to each other via a network. .

  The lottery server 3 is a device that plays a major role in the ticket transaction system 1, and recruits applicants for lottery to purchase tickets for each event from members registered as users. When it is determined that the function of determining the winner by performing a lottery, the function of transmitting information related to the winner to the ticket sales server 7 that is the ticket sales system, and the ticket price paid (the ticket has been purchased) In addition, a function for supporting ticket transaction (resale) between the ticket purchaser and another user is provided.

  The FC server 5 is a device that manages a fan club homepage for each target artist in an event such as a singer or entertainer, and also has a function of managing the registration status of fan club members. Further, although one FC server 5 is shown for convenience of explanation, a plurality of FC servers 5 may be installed for each artist.

  The ticket sales company server 7 is a device managed by a ticket sales company that has received a ticket sales request from an event organizer. In the present system 1, the ticket sales company 7 sells tickets to winners of the lottery performed by the lottery server 3. It is a device having a function to perform. Also, one ticket sales company server 7 is shown for convenience of explanation, but a plurality of ticket sales company servers 7 may be set.

  The venue terminal 9 is a device installed at the event venue, and manages information on the prospective visitors as authentication information of the visitors. Venue terminals can also be installed at each event venue.

  The user terminals 11a, 11b, and 11c are devices operated by users who are registered as members in the system 1, and access to resale information provided in the lottery server 3 when applying for the lottery performed by the lottery server 3. Used when applying for the purchase of tickets to be resold. There may be a plurality of user terminals 11a to 11c depending on the number of registered users.

  FIG. 2 shows a hardware configuration of the lottery server 3, the FC server 5, the ticket sales company server 7, the hall terminal 9, and the user terminals 11a to 11c. Each of these devices includes a central processing unit (CPU) 200, a memory 201 such as a RAM, a hard disk drive (HDD) 202, an input device 203 such as a keyboard / mouse, an output device 204 such as a display, and a communication such as a LAN adapter. The apparatus 205 can be realized by a general information processing apparatus connected via a bus. Note that the input device 203 of the venue terminal 9 includes a reading device (for example, a card reader) that reads information recorded on an information portable medium such as an IC card by short-range wireless communication. The user terminals 11a to 11c may be portable information processing apparatuses such as mobile phones and PDAs.

  FIG. 3 is a block diagram showing the configuration of the lottery server 3.

The lottery server 3 realizes the function of determining the winner of the event ticket by lottery,
A member data DB for storing member information registered by the user;
A face image DB for storing an image file of a member's face registered as a user;
The member identification information (user ID assigned by the lottery server 3) of the applicant for the lottery is associated with the event identification information (for example, a performance code described later including the artist identification information) and information indicating whether or not the winner has been won. Application information DB to memorize,
A purchase history DB that stores the member identification information of the ticket purchaser in association with the event identification information and information indicating whether the purchaser has resold the ticket;
A visit history DB that stores member identification information of the ticket purchaser in association with information indicating whether or not the purchaser has actually visited the venue,
Various databases are provided. These DBs are stored in the HDD 202, for example. The data structure of these DBs will be described later with reference to FIG. Note that the face image DB is a DB for storing an image file received from a user who desires user registration, and therefore the illustration of the data structure is omitted.

Further, the lottery server 3 provides various functions such as lottery and resale, for example, as a means that is functionally realized by the CPU 200 executing a predetermined program stored in the HDD 202, for example.
User registration means 301 that accepts information necessary for user registration, performs user registration, and updates the stored contents of the member data DB;
Ticket information receiving means 302 for receiving ticket information for each event from the ticket sales company server 7 and updating the stored contents of the purchase history DB;
Event information presenting means 303 for presenting (transmitting) information on events subject to lottery accepting applications in response to user requests transmitted from the user terminals 11a to 11c;
A lottery accepting unit 304 that accepts an application for a lottery in response to a user request transmitted from the user terminals 11a to 11c, and records the identification information of the target event and the member identification information of the applicant in the application information DB;
Based on one or more conditions, applicants recorded in the application information DB are classified into a plurality of groups with different priorities, and the winners are determined by drawing in order from the group with the highest priority. Lottery means 305 for updating the stored contents and accessing an FC member DB (to be described later) for managing member information of the fan club provided in the FC server 5;
Purchaser information recording means 306 for recording the member identification information of the corresponding winner as the member identification information of the purchaser in the purchase history DB when payment of the ticket price is confirmed;
Accepts resale requests for tickets and purchase requests for tickets to be resold, and resells tickets on the condition that the purchase requester will not hold duplicate tickets for the same event based on the stored contents of the purchase history DB In the purchase history DB, information indicating that the ticket has been resold is recorded in the purchase history DB, and the member identification information is added to the ticket as the purchaser of the purchase requester. Resale means 307 for recording in association with identification information of the corresponding event;
From the purchase history DB, the member identification information of the purchaser (ticket holder) who has not resold the ticket and the identification information of the event corresponding to the ticket are extracted and transmitted to the ticket sales company server 7 as confirmed information regarding the event participant. Confirmation information transmitting means 308 for transmitting the confirmation information as information for authenticating the visitor to the venue terminal 9 installed at the venue of the target event,
A visit history update means 309 for updating the storage contents of the visit history DB as necessary;
It has.

  The detailed contents of the processing by these means will be described later with reference to FIGS.

  FIG. 4A shows the data structure of the member data DB provided in the lottery server 3.

  As illustrated, the member data DB includes a login ID, a login password (PW), a user ID, a nickname, an address, a name, a telephone number (TEL), and an e-mail address (E-Mail) for each registered user. , Credit card number (credit number), face image file name (face image), member status, and check flag are stored.

  In the face image column, the file name of the face image received from the user who registered as a member is stored. Specifically, for example, the user registration unit 301 renames the received image file (for example, abcdefg.jpg) using the corresponding user's user ID (for example, changes to 200806190003.jpg) The image file is stored in the image column, and the image file is stored in the face image DB.

  In the member status column, the following values are recorded depending on whether the annual membership fee for using the ticket transaction system 1 is paid for each registered user.

(1) With payment ... 1
(2) No payment ... 0
Specifically, for example, the user registration means 301 is applicable when the user performs membership registration or when the payment from the credit company corresponding to the credit card number stored in the credit number column can be confirmed. 1 is recorded in the member status column regarding the user who performs the operation.

  The method for depositing the annual membership fee is not limited to credit settlement, and other methods such as bank transfer may be used, and the user registration unit 301 performs the first member registration at the time when the deposit can be confirmed, as described above, and Continue membership registration.

  In the check flag column, the following values are recorded for each registered user according to the type of user.

(1) Violation of the rules ... 9
It is a user who violates the terms of use of the ticket transaction system 1 (for example, the rules that tickets should not be resold via other systems such as an auction system).

(2) Attention member… 1
A user who has determined that the system administrator may become a violator of the rules in the future. For example, the number of resales of tickets in the ticket transaction system 1 is very large (for example, users who are reselling five times or more in one year), and member registration information (for example, addresses) is frequently changed. The user is registered as a caution member.

(3) Regular members ... 0
It is a general user who is not a violator of rules or a caution member.

  Specifically, the user registration unit 301 sets 0 for each user at the time of the first member registration. In addition, the user registration unit 301, in the case where the user has become a violator of the rules or a caution member after the member registration, follows the instruction from the system administrator performed via the input device 203 (such as a keyboard). Change the value of the check flag for the user.

  FIG. 4B shows the data structure of the purchase history DB provided in the lottery server 3.

  As shown in the figure, the purchase history DB stores the performance code, performance date, application date, number of applications, application type, status, seat type, seat number, and ticket price in association with the user ID of the ticket purchaser. To do.

  The performance code is event identification information, and is composed of, for example, a combination of artist identification information, information representing the concert year, and information representing the number of concert tours that include the concert. Specifically, when the artist identification information is aaaa, the concert year is 2008, and the concert tour corresponding to the concert corresponds to the second tour in 2008, the performance code is aaaa2008002.

  The application date is, for example, the date of application for the lottery when the ticket purchaser is the winner of the lottery. If the ticket purchaser is the person who purchased the ticket by resale, the ticket is resold. The date of purchase.

  For example, if the ticket purchaser is a winner of the lottery, the number of tickets for the person (1) and the number of companion tickets that were applied for when the lottery was applied (for example, 0 to 3) ). In addition, when the ticket purchaser is a companion or a person who purchased the ticket by resale, the number of tickets (1) of the purchaser himself / herself.

  In the application type column, the following values are set according to the type of ticket purchaser.

(1) Purchaser ... 1
The winner of the lottery and the user who still holds the ticket.

(2) Accompanying person ... 2
A user who is a companion to the winner of the lottery and still holds a ticket.

(3) Reseller ... 3
The user who reselled the ticket.

(4) Resale purchaser ... 4
A user who purchased a ticket through resale.

(5) Invalid setter ... 5
A user who has violated the rules after purchasing a ticket.

  Specifically, since the first holder of the ticket is the winner of the lottery and its companion, the values initially set in the application type column are 1 (buyer) and 2 (accompanying) Any one). This value is set by the purchaser information recording means 306. When the ticket is resold, the resale means 307 sets either 3 (reseller) or 4 (reseller). Furthermore, when the user registration unit 301 sets 9 (the violator of the rules) in the check flag of the member data DB, the user record means (only for records related to events before the performance date) exists in the purchase history DB. Sets the value of the application type included in the record to 5 (invalid setter).

  In the status column, the following values are recorded depending on whether or not the user has resold the ticket.

(1) Effective ... 1
This is a case where the user has a ticket (not resold) and the user is not an invalid setter.

(2) Resale ... 2
The user is reselling the ticket (when the resale is requested to the lottery server 3).

(3) Resold ... 3
This is when the user resells the ticket.

(4) Invalid ... 4
This is a case where the user is an invalid setter.

  The value initially set in the status column is 1 (valid). This value is set by the purchaser information recording means 306. In addition, when there is a ticket resale request or when resale is established, the resale means 307 sets either 2 (resale) or 3 (resold). Further, the user registration unit 301 sets 4 (invalid) in the status column when the value of the application type is set to 5 (invalid setting person).

  FIG. 4C shows the data structure of the application information DB provided in the lottery server 3.

  As shown in the figure, the application information DB stores a performance code, a performance date, an application date, the number of applications, a winning status, a companion id, and a group in association with the user ID of the lottery applicant.

  The date of application for the lottery is recorded in the application date column.

  In the column of the number of applications, the value is 1 if the applicant has applied for the lottery alone, and is 2 or more if the applicant's ticket is also applied (by entering the companion id) (in this example, 2-4) are recorded. The maximum number of tickets that can be applied for as a companion is maximum if the applicant is a member of either the PC homepage or the mobile phone homepage operated by the fan club of the artist of the target event. If you are both members, you may have up to three.

  In the winning status column, the following values are set as information indicating whether or not the player has won.

(1) 0
This is the case when you lose.

(2) 1
This is the case of winning.

  The companion user ID entered by the applicant is recorded in the companion id field. Therefore, the companion must also be registered as a member in the ticket transaction system 1.

  In the group column, information representing a group determined by the lottery means 305 for each user is stored. In this embodiment, seven types of groups are defined, and a number indicating priority is used as information indicating each group (for example, a group having the lowest priority is represented by 7 and a group having the highest priority). Is represented by 1.)

  FIG. 4D shows the data structure of the visit history DB provided in the lottery server 3.

  As shown in the figure, the visit history DB stores a performance code, a performance date, a visit date and time, and a visit status in association with the user ID of the ticket purchaser determiner. A purchase confirmed person is a user who has a ticket effectively when a predetermined resale period of the ticket has passed, among users who have purchased the ticket through lottery or resale.

  The date and time of visit to the event venue is recorded in the visit date / time column. Specifically, for example, the date and time at which authentication was taken at the venue is recorded.

  In the visit status column, the following values are set as information indicating whether or not the purchase confirmation person has actually entered.

(1) 0
It is the case of not entering (when not attending).

(2) 1
This is the case when you have already entered.

  FIG. 5 is a block diagram showing the configuration of the FC server 5.

  The FC server 5 includes an FC member DB for managing artist fan club members.

  The FC member DB is stored in, for example, the HDD 202 of the FC server 5.

Further, the FC server 5 is a unit that is functionally realized by the CPU 200 executing a predetermined program stored in the HDD 202, for example.
FC member registration means 501 for performing membership registration with the fan club and updating the contents stored in the FC member DB;
A user ID inquiry unit 502 that inquires of the lottery server 3 about the user ID managed by the lottery server 3 regarding the user to be registered when performing membership registration with the fan club;
In response to a request from the lottery server 3, an FC member registration inspection unit 503 that inspects whether the user who is the subject of the lottery performed by the lottery server 3 is a fan club member and transmits the inspection result to the lottery server 3;
Is provided.

  Detailed contents of the processing by each of the above means will be described later with reference to FIGS.

  FIG. 6 shows the data structure of the FC member DB provided in the FC server 5.

  As shown in the figure, the FC member DB stores a login password (FC password), a user ID, and a target site in association with an ID (FC login ID) for logging in to a homepage operated by a fan club. .

  In the user ID column, a user ID issued when a member is registered in the lottery server 3 is recorded.

  In the target site column, the following values are set as information indicating the type of homepage to be registered.

(1) 1
This is the case when you are registered as a member on the PC homepage.

(2) 2
This is the case when you are registered as a member on the mobile phone website.

(3) 3
This is a case where the member is registered on both the personal computer homepage and the mobile phone homepage.

  FIG. 7 is a block diagram showing the configuration of the ticket sales company server 7.

The ticket sales company server 7
A ticket master DB for managing information related to tickets of all events sold by the ticket sales company server 7;
A winner information DB that manages information on the winners of the lottery received from the lottery server 3;
A confirmation information DB for managing information on purchase confirmed persons received from the lottery server 3 and information on tickets purchased by the purchase confirmed persons (collectively referred to as “purchaser confirmed information”);
Is provided.

  Each DB is stored in the HDD 202 of the ticket sales company server 7, for example.

Further, as means that is functionally realized by the CPU 200 executing a predetermined program stored in the HDD 202, for example,
Ticket information transmission means 701 for transmitting information on tickets to be drawn to the lottery server 3;
Winner information update means 702 for updating the stored content related to the corresponding winner among the stored content of the winner information DB when the payment of the ticket price can be confirmed,
Confirmation information DB updating means 703 for updating the storage content of the purchaser information DB based on the purchaser confirmation information received from the lottery server 3;
Ticket issuing means 704 for issuing a ticket (printing or sending an electronic ticket) to a purchase confirmed person recorded in the confirmation information DB;
Is provided.

  In this embodiment, the ticket information transmitting means 701 provides the lottery server 3 with not only information on events such as performance codes and performance dates, but also information on seats such as seat type, seat number, and price as ticket information. In the case of an event without a reserved seat (an event with only a standing seat or an unreserved seat), information on the seat does not have to be transmitted. The detailed contents of the processing by each means will be described later with reference to FIG. 11, FIG. 13, and FIG.

  FIG. 8A shows the data structure of the ticket master DB provided in the ticket sales company server 7.

  As illustrated, the ticket master DB stores the performance date, seat type, seat number, price, and recruitment agency in association with the performance code.

  In the column of the recruiting agency, information on the agency that recruits the purchasers of the tickets handled by the ticket sales company server 7 or recruits the applicants for the lottery is recorded. For example, in the case where the ticket sales company server 7 handles 10,000 tickets for a certain event, when the selection of the winners for all the tickets is left to the lottery server 3, in all records related to the event Information representing the lottery server 3 is stored in the column of the recruiting agency.

  FIG. 8B shows the data structure of the winner information DB provided in the ticket sales company server 7.

  As illustrated, the winner information DB stores a performance code, a performance date, an application date, the number of applications, a companion id, and payment in association with the user ID.

  The values recorded in the columns of user ID to accompanying person id are the same as the stored contents of the application information DB (FIG. 6) provided in the lottery server 3.

  In the deposit field, the following values are set according to whether or not the ticket price is deposited.

(1) 0
This is a value indicating non-payment and is set when a new record is created in the winner information DB.

(2) 1
This value indicates that the deposit has been confirmed.

  FIG. 8C shows the data structure of the confirmation information DB provided in the ticket sales company server 7.

  As shown in the figure, the confirmation information DB stores the performance code, performance date, seat type, seat number, address, and name in association with the user ID.

  FIG. 9 is a block diagram showing the configuration of the venue terminal 9.

  The hall terminal 9 includes an authentication information DB that stores purchaser confirmation information received from the lottery server 3 as authentication information for authenticating a visitor.

  For example, the authentication information DB is stored in the HDD 202 of the hall terminal 9. The data structure of this DB is the same as the data structure of the confirmation information DB (FIG. 8C) provided in the ticket sales company server 7.

Furthermore, the venue terminal 9 is a means that is functionally realized by the CPU 200 executing a predetermined program stored in the HDD 202, for example.
The venue terminal 9 has a confirmation information requesting unit 901 that requests the lottery server 3 to transmit purchaser confirmation information,
IC data acquisition means 902 for acquiring information recorded on the IC card via a card reader;
Authentication result receiving means 903 for receiving information on the result of authentication between the visitor and the purchase confirmed person;
Is provided.

  Details of the processing by each of the above means will be described later with reference to FIG.

  10 to 15 are flowcharts showing the flow of information processing in the ticket transaction system 1. Hereinafter, the flow of information processing will be described with reference to these drawings.

  FIG. 10A shows a flowchart of the FC member registration process in the FC server 5 and the response process of the lottery server 3 in response to an inquiry from the FC server 5.

  First, a user who wishes to register as a member in the ticket transaction system 1 operates a user terminal (for example, 11a) in order to register as a member (FC member registration) with the fan club of the artist who is the subject of the lottery by the lottery server 3. Then, FC member registration application data is transmitted to the FC server 5 (ST1501).

  In the FC member registration application data, as information stored in the FC member DB (FIG. 6), for example, an FC login ID, FC password, and member registration required to log in to a homepage operated by a fan club are requested. Contains information about the target site. For example, the FC login ID and the FC password may be the same as the login ID and password used when registering as a member in the ticket transaction system 1. In addition, when the FC login ID and the FC password are different from the login ID and password registered in the system 1, the user asks the lottery server 3 for the user ID. Is also configured to be transmitted as FC member registration application data.

  Upon receiving the FC member registration application data (ST1502), the FC member registration means 501 of the FC server 5 records a part of the data (FC login ID, FC password, and target site) in the FC member DB by recording FC data. Member registration is performed (ST1503).

  When the FC member registration application data is recorded in the FC member DB, the user ID inquiry means 502 sends the FC login ID and the FC password included in the FC member registration application data received from the user terminal 11a to the lottery server 3. Is used to transmit user ID inquiry data (ST1504). When the FC login ID and the FC password are different from the login ID and password registered in the system 1, the login ID and password of the system 1 are used. The login ID and password included in the inquiry data of the user ID are referred to as “inquiry login ID” and “inquiry password”.

  Also, the FC server 5 omits the FC member registration process (the process of ST1503) for a user who has already completed the FC member registration in the FC server 5, and receives the inquiry login ID and the inquiry password from the user. It is preferable that the user ID inquiry data is transmitted to the lottery server 3.

  Upon receiving the inquiry data from the FC server 5 (ST1505), the user registration means 301 of the lottery server 3 uses the inquiry login ID and the inquiry password included in the received inquiry data to obtain the member data DB (FIG. 4). The user ID is searched for within (A)) (ST1506).

  Specifically, using the inquiry login ID and the inquiry password as search keys, the login ID field and the login PW field of the member data DB are searched, and a record that matches both the inquiry login ID and the inquiry password is found. If found, the user ID is extracted from the corresponding record.

  The user registration means 301 determines whether or not the user ID is found as a result of the above search (ST1507). When the user ID is not found (when the determination of ST1507 is No), that is, when the member is not registered. Newly issues (generates) a user ID (ST1508), creates a new record in the member data DB, and records the issued user ID, received login ID, and received password, thereby registering a temporary member (ST1509).

  If the user ID is found as a result of the above search (when the determination in ST1507 is Yes), that is, if the user has already been registered, the user registration unit 301 issues the extracted user ID or the user who issued in ST1508 The ID is transmitted as an inquiry result to the FC server 1511 (ST1510).

  When receiving the user ID from the lottery server 3 (ST1511), the FC member registration unit 501 of the FC server 5 updates information related to the corresponding user in the stored contents of the FC member DB using the user ID (ST1512).

  FIG. 10B shows a flowchart of member registration processing by the lottery server 3.

  Next, the user operates the user terminal 11a to transmit member registration application data to the lottery server 3 (ST1513).

  The member registration application data includes, as information stored in the member data DB (FIG. 4A), a login ID desired by the user, a login password desired by the user, a nickname, an address, a name, a telephone number, and an e-mail address. , Credit card number, and face image file. It should be noted that a user who has already registered an FC member in the FC server 5 may transmit the inquiry login ID and the inquiry password as the login ID and login password.

  Upon receiving the member registration application data from the user terminal 11a (ST1514), the user registration means 301 of the lottery server 3 determines whether or not the temporary member is registered (ST1515).

  As a result of the determination, if the temporary member is not registered (if the result of ST1515 is No), that is, if the record that matches the login ID and login password included in the member registration application data does not exist in the member data DB, The user registration unit 301 issues a new user ID (ST1516), and updates the contents stored in the member data DB and the face image DB using the received member registration application data and the issued user ID (creates a new record). As a result, member registration is performed (ST1517).

  On the other hand, when it is determined in ST1515 that the temporary member is registered (when the determination of ST1515 is Yes), that is, when a record that matches the login ID and password included in the member registration application data exists in the member data DB. Then, member registration is performed by updating the contents of the corresponding record using data other than the login ID and password in the received member registration application data (ST1517).

  The user registration means 301 performs membership registration in ST1517, then notifies the application result to the user terminal 11a (ST1518), and the user terminal 11a receives the application result (ST1519).

  The application results include, for example, information indicating that the member registration has been performed using the login ID and password included in the member registration application data, the URL of the home page for confirming the contents of the member registration, and access to the page. Then, information indicating that the registration is not performed unless the confirmation button is clicked can be included. When the latter information is included, the user registration unit 301 may consider that the member registration is valid on the condition that the user accesses the page and clicks the confirmation button.

  In the ticket transaction system 1, when the member registration is completed, an IC card is issued to the user, and the IC card is sent to the address and name recorded in the member data DB. The IC card stores information representing the encrypted user ID and face image, and is referred to when entering the event venue.

  FIG. 11A shows a flowchart of the ticket information storing process by the lottery server 3.

  First, the ticket sales company server 5 sends the information assigned to the lottery server 3 to the lottery server 3 among the ticket information (including event information) managed by the ticket master DB (FIG. 8A). On the other hand, it is transmitted at a predetermined timing (for example, timing when information is added to the ticket master DB) (ST1520).

  When the ticket information receiving means 302 of the lottery server 3 receives the ticket information from the ticket sales company server 5 (ST1521), it updates the stored contents of the purchase history DB (FIG. 4B) using the information (ST1522). .

  Specifically, information regarding the performance code, performance date, seat type, seat number, and price is recorded in the stored contents of the purchase history DB. In this way, the lottery server 3 accumulates ticket information that is subject to lottery in the ticket transaction system 1.

  FIG. 11B shows a flowchart of a lottery applicant data storage process by the lottery server 3.

  This flowchart is a process from when a user who has registered as a member of the ticket transaction system 1 applies for the lottery of the ticket until the lottery and resale of the ticket are performed, the purchase confirmation is determined, and the ticket is issued Shows the flow.

  First, the user operates a user terminal (for example, 11b), and transmits a presentation request for information related to a lottery target ticket stored in the lottery server 3 to the lottery server 3 (ST1523). It is assumed that the user has logged in to the lottery server 3 using the login ID and the login password.

  Ticket information presentation requests include information that requests presentation of all ticket information that can be applied for the lottery, information that requests presentation of ticket information related to a specific artist, and information on events that are held on specific days. Or information requesting presentation of ticket information that can be purchased at a specific price range.

  When receiving the ticket information presentation request from the user terminal 11b (ST1524), the event information presentation unit 303 of the lottery server 3 extracts the corresponding ticket information from the purchase history DB (ST1525) and transmits it to the user terminal 11b. (ST1526).

  Upon receiving the ticket information from the lottery server 3 (T1527), the user terminal 11b outputs the ticket information to the output device 204 such as a display, and presents the ticket information to the user. Thereby, the user can select an event to apply for the lottery.

  Then, the user terminal 11b uses the lottery server 3 as the lottery application data on the information of the event selected by the user (not including ticket information such as seat type and seat number), the number of tickets applied, and the companion id. (ST1528). Note that the lottery application data may include information on tickets.

  When the lottery acceptance unit 304 of the lottery server 3 receives the lottery application data from the user terminal 11b (ST1529), the lottery acceptance unit 304 updates the stored content of the application information DB using the information (ST1530).

  The lottery acceptance unit 304 determines whether or not a predetermined application deadline preset for each event has passed (ST1531), and accepts an application for a lottery from the user until the application deadline has passed.

  FIG. 12 shows a flowchart of the lottery applicant classification process by the lottery server 3 and the response process of the FC server 5 in response to the inquiry from the lottery server 3.

  When the application deadline has passed (when the determination of ST1531 is Yes), the lottery means 305 extracts lottery applicant data from the application information DB (ST1532), and whether or not one or more predetermined conditions are satisfied for each applicant. Are determined in the order of application (order of registration in the application information DB), and the applicants are classified into a plurality of groups having different priorities (ST1533 to ST1557).

  As one or more predetermined conditions applied by the lottery means 305, for example, the following conditions may be employed.

(1) The condition that the number of past ticket purchases is equal to or less than a threshold (for example, the number of purchases within the past two years is 0). This condition is a user who has never participated in an event or the number of participation in an event This is a condition for providing an equal participation opportunity to users who wish to participate in an event by preferentially winning the user with few. This condition is determined based on the stored contents of the purchase history DB.

(2) The condition that the number of ticket resales is equal to or less than a threshold (for example, the number of resales within the past two years is 0). This condition determines that a user with a small number of ticket resales is a good user, etc. This is a condition that the user is elected preferentially over other users. This condition is determined based on the stored contents of the purchase history DB.

(3) Conditions that the applicant for the lottery is a fan club member of the artist of the event subject to the application This condition gives priority to users who are registered as members of the fan club of the artist of the event subject to the lottery over other users. It is a condition of the purpose of doing. This condition may be applied, for example, when there is an intention from a fan club or affiliated office of an event artist to give priority to a fan club member.

(4) Conditions that the applicant for the lottery is not a caution member This condition gives the system administrator priority to other good users over users (attention members) who may become violators of the rules in the future. It is the condition of the meaning.

(5) Condition that the applicant for the lottery is not a violator of the rules This condition is a condition that the chances of providing the participation opportunity with a high probability to pure fans by lowering the winning probability of the violators of the rules. .

(6) Condition that lottery applicant pays annual membership fee This is a condition that priority is given to other users over users who have not paid the annual membership fee of the system.

(7) Conditions that applicants for lottery have purchased tickets in the past, but there is no record that they did not come to the event venue. Conditions that give priority to other users over users who may not attend the event. It is.

  Note that it is not necessary to apply all of the above conditions, and it is preferable that at least one of the above conditions be applied. When two or more conditions are applied, the order in which the conditions are applied can be changed as appropriate.

  First, the lottery means 305 refers to the member data DB to determine whether or not the user to be classified has paid the annual membership fee (ST1533), and if it has paid (if the determination in ST1533 is Yes), that is, the member If 1 (with payment) is set in the member status column of the data DB, the member data DB is further referenced to determine whether or not the user is in violation of the rules (ST1534).

  When the user to be classified is not a violator of the rules (when the determination of ST1534 is No), that is, when 0 (normal member) or 1 (attention member) is set in the check flag column of the member data DB The lottery means 305 refers to the visit history DB (FIG. 4D) and determines whether or not there is a record that the ticket has been purchased in the past but did not come to the event venue (ST1535).

  The lottery means 305 determines whether the classification target user has not paid the annual membership fee in ST1533 (when the determination is No), the classification target user is a violator of the contract in ST1534 (when the determination is Yes), or in ST1535. If there is a record that the user to be classified did not come (if the determination is Yes), the user to be classified is treated as a loser, and the lottery result is recorded in the application information DB (ST1536).

  Specifically, 0 (decision) is set in the winning status column of the application information DB.

  On the other hand, the lottery means 305 refers to the member data DB if there is no record that the classification target user did not come in ST1535 (if the determination is No), and determines whether the classification target user is a caution member. Judgment is made (ST1537). Specifically, it is determined whether 1 (attention member) is set in the check flag column of the member data DB.

  As a result of the above determination, when the user to be classified is an attention member (when the determination in ST1537 is Yes), the lottery means 305 sets 7 (priority = 7) in the field of the group of the corresponding record in the application information DB. By setting, the user is classified into the seventh group (ST1538). In the group column, arbitrary information (for example, the priority may be identified by using an alphabet starting with a) as long as it is information that can identify the priority of the group after classification. Can be done.

  On the other hand, the lottery means 305 accesses the FC member DB provided in the FC server 5 when the user to be classified is not a caution member (when the determination of ST1537 is No), and the user to be classified is subject to the lottery. Whether or not the event artist is a fan club member is inspected (ST1539). Specifically, the lottery means 305 transmits the user ID of the classification target user to the FC server 5 as FC member registration inquiry data.

  Upon receiving the FC member registration inquiry data from the lottery server 3 (ST1540), the FC member registration checking means 503 of the FC server 5 refers to the user ID column of the FC member DB, and the user ID included in the inquiry data exists. Whether or not to do so is inspected (ST1541), and the inquiry result (whether or not FC member is registered) is transmitted to the lottery server 3 (ST1542).

  Upon receiving the inquiry result from the FC server 5 (ST1543), the lottery means 305 of the lottery server 3 determines whether the classification target user is a fan club member (FC member) of the artist of the lottery event (ST1544). Specifically, it is determined whether the inquiry result received from the FC server 5 is the content that the FC member is registered or the content that the FC member is not registered.

  As a result of the above determination, when the user to be classified is an FC member (when the determination of ST1544 is Yes), the lottery means 305 refers to the purchase history DB (FIG. 5) and purchases tickets within the past two years. It is determined whether the number of times is 0 (ST1545). Specifically, it is determined whether the user ID of the classification target user exists in the user ID column of the record within two years of the purchase history DB.

  As a result of the above determination, if the number of purchases of the ticket within the past two years is one or more (when the determination of ST1545 is No), the lottery means 305 refers to the purchase history DB and purchases the tickets within the past two years. It is determined whether or not the number of resale is 0 (ST1546). Specifically, the user ID of the classification target user exists in the user ID column of the record within two years of the purchase history DB, and 3 (resold) is set in the status column of the corresponding record. It is judged whether or not.

  The lottery means 305 is used when the number of purchases within the past two years is zero (when the determination of ST1545 is Yes), or when the number of resales within the past two years is zero (when the determination of ST1546 is Yes). Classifies the users to be classified into the first group by setting 1 (priority = 1) in the group field of the application information DB (ST1547).

  On the other hand, when the number of resales within the past two years is one or more (when the determination in ST1546 is No), the lottery means 305 sets 2 (priority = 2) in the group field of the application information DB. Thus, the users to be classified are classified into the second group (ST1548).

  In addition, in the determination of ST1544, the lottery means 305 refers to the purchase history DB when the user to be classified is not an FC member (when the determination is No), and the number of ticket purchases within the past two years is 0. It is determined whether or not the number of times (ST1549). The determination method is the same as ST1545.

  As a result of the above determination, when the number of purchases within the past two years is zero (when the determination of ST1549 is Yes), the lottery means 305 refers to the purchase history DB and resells tickets within the past two years. It is determined whether or not the number of times is 0 (ST1550). The determination method is the same as ST1546.

  The lottery means 305 sets 3 (priority = 3) in the group field of the application information DB when the number of resales within the past two years is 0 (when the determination in ST1550 is Yes) The users to be classified are classified into the third group (ST1551).

  On the other hand, when the number of resales within the past two years is one or more (when the determination in ST1550 is No), the lottery means 305 sets 4 (priority = 3) in the group field of the application information DB. Thus, the users to be classified are classified into the fourth group (ST1552).

  In addition, in the determination of ST1549, the lottery means 305 refers to the purchase history DB when the number of purchases within the past two years is one or more (when the determination is No), and resells tickets within the past two years. It is determined whether the number of times is 0 (ST1553). The determination method is the same as ST1546.

  As a result of the above determination, if the number of resales within the past two years is 0 (when the determination in ST1553 is Yes), by setting 5 (priority = 5) in the group field of the application information DB The users to be classified are classified into the fifth group (ST1554).

  On the other hand, when the number of resales within the past two years is one or more (when the determination in ST1553 is No), the lottery means 305 sets 6 (priority = 6) in the group field of the application information DB. Thus, the users to be classified are classified into the sixth group (ST1555).

  As described above, the lottery means 305 determines whether all the applicants have been classified after classifying the users to be classified into any of the first to seventh groups (ST1556), and the classification has been completed. If not (when the determination is No), the next applicant is selected as a classification target (ST1557), and the process returns to ST1533.

  FIG. 13A shows a flowchart of a lottery process by the lottery server 3 and a winner information storage process by the ticket sales company server 13.

Selecting means 305, if the classification of all applicants to draw has been completed (if ST1556 of determination is Yes), sets the winning frame (N _m) for each group (ST1558). The winning frame may be set by equally distributing the total number of lottery target tickets stored in the purchase history DB to each group, or the winning frame occupying the total number of tickets defined in advance for each group May be set based on the ratio of the above, or may be arbitrarily set manually by the system administrator. In the present embodiment, the winning frame is set by equally distributing the total number of tickets to each group. Therefore, for example, when the total number of tickets is 7,000, the winning frame N _m of each group is set to 1,000.

  Next, the lottery means 305 refers to the application information DB and extracts applicant data of the m-th group (ST1559). In the present embodiment, it is assumed that the groups with the highest priority (groups with m = 1) are extracted in order.

  After extracting the applicant data, the lottery means 305 determines whether or not the total number of applications exceeds the winning frame (ST1560). If there is a user who has applied for a companion ticket, the total number of applications will be larger than the number of records of the applicant.

  As a result of the above determination, when the winning frame is not exceeded (when the determination in ST1560 is No), the lottery means 305 selects all applicants to be selected as the winners (ST1561).

In this case, since it seems that there is a surplus in the winning frame (winning frame N _m -the total number of applications), the surplus is determined by the lottery means 305 for the next priority group. It may be configured to be added to N _{m + 1} .

On the other hand, when the total application number exceeds the winning frame (if ST1560 of determination is Yes), selecting means 305 performs a lottery to determine the winning frame N _m the same number of winners (ST1562) .

  After performing the lottery, the lottery means 305 determines whether m = 7, that is, whether the lottery target group is the final group (ST1563).

  As a result of the above determination, when the lottery target group is not the final group (when the determination of ST1563 is No), the lottery means 305 adds the lost winners resulting from the lottery of ST1562 to the (m + 1) th group. (ST1564).

  Specifically, the lottery means 305 records information (m + 1) representing the group of the next priority in the record group column regarding the loser generated by the lottery of ST1562 in the stored contents of the application information DB. .

  On the other hand, after ST1561, after ST1564, or when the lottery target group is the final group (when the determination of ST1563 is Yes), lottery means 305 records the lottery result in the application information DB (ST1565). . Note that if the lottery target group is the final group, the lost winner is not added to the next priority group, and the winning is confirmed.

  In the case of ST1565, the lottery means 305 sets the status value to 1 for the winner in the stored contents of the application information DB, and sets the status value to 0 for the applicant whose winning is confirmed. .

  Next, the lottery means 305 increments the value of m (m = m + 1) (ST1566), and determines whether m = 8, that is, whether the final group lottery has ended (ST1567).

  If the final group lottery is not completed as a result of the above determination (when the determination of ST1567 is No), the lottery processing ST1559 to ST1567 is executed for the next priority group.

  In this way, after adding the winners from the group that has drawn the lot to the group with the next priority, the lottery of the group with the next priority is performed to classify it into a group with a higher priority in advance. Even if the selected user loses once, since the lottery opportunity is given again, the winning probability is higher than other users.

  On the other hand, when the final group lottery is completed (when the determination of ST1567 is Yes), the lottery means 305 notifies the lottery result to each user terminal operated by the applicant (ST1568).

  The user terminals 11a to 11c operated by each applicant receive the lottery result from the lottery server 3 (ST1569) and present the lottery result to each applicant via the output device 204 such as a display.

  In the lottery server 3, the lottery means 305 refers to the winning status in the application information DB, extracts the winner information (ST1570), and transmits it to the ticket sales company server 7 (ST1571). The winner information includes a user ID, performance code, performance date, application date, number of applications, and companion id.

  When the winner information update means 702 of the ticket sales company server 7 receives the winner information from the lottery server 3 (ST1572), it updates the stored contents of the winner information DB (FIG. 8B) using that information. (ST1573).

  Specifically, the winner information and the value (0) of the deposit status are recorded in the winner information DB for each winner.

  FIG. 13B shows a flowchart of purchaser information transmission processing by the ticket sales company server 7 and ticket information transmission processing by the lottery server 3.

  The elected user can, for example, operate the user terminal (for example, 11c) and perform a ticket purchase price deposit process on the ticket sales company (ST1574). Specifically, the user accesses a predetermined URL designated by the ticket sales company server 7, inputs a credit card number, or displays a payment slip and cash displayed when accessing the URL at a convenience store, etc. You can pay the ticket purchase price by bringing it to the storage agent.

  When the winner information update unit 702 of the ticket sales company server 7 receives the payment information of the purchase price (ST1575), it updates the stored contents of the winner information DB (ST1576).

  Specifically, 1 is set in the deposit field of the record relating to the corresponding winner. Note that the payment information of the purchase price is information indicating that the payment has been made. For example, in the case of credit settlement, a mode transmitted from a credit company system is conceivable. In addition, in the case of bank transfer, a mode of manual input by an administrator of the ticket sales company server 7 or a mode of transmission from a bank system can be considered.

  The winner information update unit 702 determines whether or not a preset payment time limit for the ticket purchase price has passed (ST1577). If the time limit has not expired (if the determination is No), the above-described process ST1575 is performed. Repeat ~ ST1577.

  On the other hand, when the time limit has expired (when the determination of ST1577 is Yes), the purchaser information is extracted from the winner information DB (ST1578) and transmitted to the lottery server 3 (ST1579). The purchaser information is, for example, a user ID related to a winner who has been confirmed to pay the ticket purchase price among the winners recorded in the winner information DB.

  When the purchaser information recording means 306 of the lottery server 3 receives the purchaser information from the ticket sales company server 7 (ST1580), based on the information (user ID), information on tickets purchased by the corresponding user from the application information DB. And the stored contents of the purchase history DB are updated (ST1581).

  Specifically, with respect to the winner himself / herself, in the purchase history DB, by referring to the record related to the winning (purchased) ticket recorded in the application information DB based on the user ID received from the ticket sales company server 7. The user ID, application date, number of applications, application type, and status information of the corresponding record are updated.

  As for the companion, based on the user ID received from the ticket sales company server 7, by referring to the record related to the winning (purchased) ticket recorded in the application information DB and the value of the companion id of the record. In the purchase history DB, the user ID, application date, number of applications, application type, and status information of the corresponding record are updated.

  Furthermore, when the event is composed of designated seats, the purchaser information recording unit 306 may assign a seat type and a seat number to each purchaser when updating the purchase history DB. Specifically, for example, a good seat (for example, a seat close to the center or a seat close to the stage) may be assigned to a user with a small value in the group column of the application information DB (high priority). it can.

  Then, the purchaser information recording means 306 transmits the ticket information to the user terminal operated by each purchaser (ST1582), and each user terminal presents the ticket information received from the lottery server 3 to the user ( ST1583). The ticket information includes a performance code, a performance date, the number of tickets, a seat type, and a seat number.

  FIG. 14A shows a flowchart of resale request acceptance processing by the lottery server 3.

  First, among users who have purchased tickets, a user who wants to resell (reseller requester) operates a user terminal (for example, 11a) and transmits resale request data to the lottery server 3 (ST1584).

  The resale request data includes, for example, a user ID, a performance code, and a desired number of resales. In the present embodiment, it is assumed that the applicant himself / herself for the lottery can also resell his / her companion ticket, and the companion can resell only his / her ticket (one). It can be confirmed by referring to the value in the column of the application type in the purchase history DB whether the resale requester corresponds to the lottery applicant or companion.

  Upon receiving resale request data from the user terminal 11a (ST1585), the resale means 307 of the lottery server 3 refers to the member data DB to determine whether the reseller requester is a violator of the rules (ST1586). The stored contents are updated (ST1589).

  Specifically, as a result of ST1586, when the reseller requester is not a violator, the resale means 307 accepts a resale request for a ticket to be resold and becomes a resale target in the stored contents of the purchase history DB. The value in the status column for the ticket is changed to 2 (resale).

  On the other hand, if the reseller requester is a violator of the contract, the value of the application type column related to the ticket to be resold is changed to 5 (invalid setter) in the stored contents of the purchase history DB, and the status column The value is changed to 0 (invalid), and the ticket to be resold is invalidated. In this case, it is preferable to update the storage contents of the purchase history DB so that all the tickets of the winner and the accompanying person in the lottery are invalidated.

  Then, the resale unit 307 transmits the request result to the user terminal 11a (ST1588).

  As a result of the request, when the reseller requester is not a violator of the rules, it is possible to transmit information indicating that the resale request has been accepted. On the other hand, when the reseller requester is a violator of the agreement, it is conceivable to transmit information indicating that the resale request has not been accepted and information indicating that the ticket has become invalid.

  It is also possible to limit the number of resales per ticket. For example, when the number of resales per ticket is limited to one, a user who purchased a ticket by resale cannot resell the ticket. As a specific process, for example, the resale means 307 receives the resale request data in ST1585, and then refers to the purchase history DB, and the value of the application type column is set to 4 (resale purchaser). It is conceivable that a request result indicating that the ticket cannot be resold is transmitted to the user terminal.

  The user terminal 11a receives the request result from the lottery server 3 (ST1589), and presents the request result to the user via the output device 204 such as a display.

  As described above, the resale means 307 repeats the processing of ST1584 to ST1589, so that information on tickets to be resold is accumulated in the purchase history DB.

  FIG. 14B shows a flowchart of resale processing in the present system 1.

  A user (purchase requester) who wishes to purchase a ticket to be resold operates a user terminal (for example, 11b) and transmits a resale information presentation request to the lottery server 3 (ST1590).

  Examples of the resale information presentation request include information requesting presentation of information on all tickets to be resold, information requesting presentation of information on a specific artist among ticket information to be resold, Information that requests the presentation of information on events that are held on a specific day among information on tickets that are to be held, or information that requests the presentation of information belonging to a specific price range among information on tickets to be resold .

  Upon receiving the resale information presentation request (ST1591), the resale means 307 of the lottery server 3 refers to the purchase history DB, extracts the corresponding resale information (ST1592), and transmits it to the user terminal 11b (ST1593).

  The resale information includes, for example, a performance code, a performance date, the number of tickets, a seat type, a seat number, and a price. In this embodiment, it is assumed that the price of the ticket to be resold is a value (fixed value) set in the price column of the purchase history DB. Thereby, it is possible to prevent the ticket from being bought and sold at a high price.

  When receiving resale information from the lottery server 3 (ST1594), the user terminal 11b presents resale information to the user via the output device 204 such as a display. Accordingly, the user can grasp information on tickets that can be purchased through resale and select a ticket to be purchased.

  Next, the user who has selected a ticket to be purchased from the resale information operates the user terminal 11b and transmits purchase request data to the lottery server 3 (ST1595).

  The purchase request data includes, for example, the user ID of the purchase requester, the performance code, the number of purchases (limited to one in this embodiment), the seat type, and the seat number.

  Upon receiving the purchase request data (ST1596), the resale means 307 of the lottery server 3 refers to the purchase history DB and determines whether or not the purchase requester is a ticket holder (ST1597).

  Specifically, a record corresponding to the performance code of the event to be resold in the purchase history DB so that the purchase requester does not hold duplicate tickets for the same event. It is judged whether it is included in.

  As a result of the above determination, if the purchase requester is not a ticket holder (when the determination in ST 1597 is No), the resale means 307 refers to the member data DB and determines whether the purchase requester is a violator of the contract. Judgment is made (ST1598).

  As a result of the above determination, if the purchase requester is not a violator of the rules (when the determination in ST1598 is No), the resale means 307 determines that the resale of the ticket has been established, and stores the contents stored in the purchase history DB. Update (ST1599).

  Specifically, the resale means 307 changes the value of the application type column to 3 (reseller) as information indicating that the reseller has resold the ticket to the purchase history DB, and the status Change the value in the column to 3 (resold). As for the purchase requester, a record is newly created, and as a ticket purchaser, the user ID, the performance code corresponding to the ticket, the performance date, the application date (purchase request date), the number of applications (1 sheet), Application type (4 (reseller purchaser)), status (1 (valid)), seat type, seat number, and price are recorded in association with each other.

  Then, resale means 307 updates the storage content of the purchase history DB in ST1599, determines that the purchase requester is a ticket holder in the determination in ST1597 (if the determination is Yes), or determines in ST1598 When it is determined that the purchase requester is a violator of the contract (when the determination is Yes), the request result is transmitted to the user terminal 11b (ST1600).

  As a result of the request, if it is determined in ST1599 that resale has been established, information on the purchased ticket (performance code, performance date, number of seats, seat type, seat number, price, etc.) and payment method of the ticket price It is possible to send information about On the other hand, when the resale of the ticket is not established, that is, when the determination result of ST1597 or ST1698 is Yes, it is possible to transmit information indicating that the resale has not been established.

  When receiving the request result from the lottery server 3 (ST1601), the user terminal 11b presents the request result to the user via the output device 204 such as a display. It is assumed that the user pays the ticket price to the resale requester by looking at the information regarding the purchased ticket and the information regarding the payment method of the ticket price as the contents of the request result. The lottery server 3 can also store a ticket purchase price in place of the resale requester based on the credit number for each user managed in the member data DB. In this case, an account may be managed for each user in the member data DB, and the ticket purchase price stored in place may be transferred to the account so that the price is given to the reseller.

  Further, the resale unit 307 of the lottery server 3 determines whether or not a resale time limit set in advance for each event has passed (ST1602), and resell processing (ST1596 to ST1599) in response to a request from the user until the time limit expires. )repeat.

  When the preset resale deadline has passed (when the determination in ST1602 is Yes), the confirmation information transmitting unit 308 refers to the member data DB and the purchase history DB, and purchases that have not resold the ticket (purchase (Determinant) user ID, performance code of event corresponding to the ticket, performance date, seat type, seat number, address, and name are extracted (ST1603), and the ticket sales company server as purchaser confirmation information regarding the event participant 7 (ST1604).

  Further, the confirmed information transmitting means 308 further updates the stored contents of the visit history DB using the purchaser confirmed information (ST1605).

  Specifically, in the visit history DB, a record is created for each purchase confirmed person, and a user ID, performance code, performance date, and status (0) are recorded.

  When receiving the purchaser confirmation information from the lottery server 3 (ST1606), the confirmation information DB update unit 703 of the ticket sales company server 7 updates the stored content of the confirmation information DB using the received information (ST1607), A ticket is issued (for example, printed) to the purchase confirmed person at the timing (ST1608).

  In the present embodiment, for example, a performance code, a performance date, a seat type, a seat number, and a purchase confirmed person's name are printed on the ticket. Alternatively, a two-dimensional code such as a barcode or QR code representing these pieces of information may be printed. Then, the ticket is sent (sent by mail or electronic mail) to the purchase confirmed person by the administrator of the ticket sales company server 7.

  FIG. 15A shows a flowchart of the purchaser confirmation information storing process by the hall terminal 9 and the response process by the lottery server 3 in response to a request from the hall terminal 9.

  First, the confirmation information requesting means 901 of the venue terminal 9 installed at the event venue presents purchaser confirmation information to the lottery server 3 at a predetermined timing (for example, one day before the opening or one hour before the opening). A request is transmitted (ST1609).

  When the confirmation information transmission means 308 of the lottery server 3 receives the purchaser confirmation information presentation request from the venue terminal 9 (ST1610), the member data DB and the purchase history DB are referred to and the corresponding purchaser confirmation information is extracted. (ST1611), it transmits to the venue terminal 9 as information for authenticating the visitor (ST1612).

  As described above, the purchaser confirmation information is information including the user ID, performance code, performance date, seat type, seat number, address, and name of the purchase confirmer.

  Upon receiving the purchaser confirmation information from the lottery server 3 (ST1613), the venue terminal 9 stores the purchaser confirmation information in the authentication information DB (ST1614).

  FIG. 15B shows a flowchart of authentication information reception processing by the venue terminal 9 and visit history DB update processing by the lottery server 3.

  The following describes the authentication process for visitors performed at the event venue at the time of the event.

  First, when a visitor presents an IC card and a ticket issued in advance to the event staff, the event staff operates an IC card reader provided in the venue terminal 9 and the face photo data stored in the IC card. And the user ID is read.

  As a result, the IC data acquisition means 902 of the venue terminal 9 acquires the face photo data and user ID read by the IC card reader (ST1615), refers to the authentication information DB, and includes the IC card in the purchaser confirmation information. Information corresponding to the user ID read by the reader is extracted (ST1616).

  Then, the IC data acquisition unit 902 displays the face photograph data and the information extracted from the authentication information DB on the display (output device 204) (ST1617). In ST1616, if the purchaser confirmation information corresponding to the user ID is not found, it is possible that the IC data acquisition unit 902 displays information indicating that the corresponding purchase confirmation person does not exist.

  The event staff compares the contents displayed on the display with the contents of the ticket and the face of the visitor, determines whether the visitor and the purchase confirmed person are the same person, and operates the input device 203 such as a keyboard and a mouse. And enter the authentication result.

  Specifically, whether the face photo displayed on the display and the visitor's face match, the performance code, seat type, seat number, address, name, etc. displayed on the display and the ticket are displayed. Is checked to see if they match.

  The authentication result receiving means 903 of the hall terminal 9 receives the authentication result input by the event staff (ST1618), and the authentication result indicating that the visitor and the purchase confirmed person are the same is input by the event staff whether or not the authentication is OK. It is determined whether it has been performed (ST1619).

  As a result of the above determination, in the case of authentication OK (when the determination of ST1619 is Yes), the authentication result receiving means 903 sends a visit history DB (see FIG. The update request of 7) is transmitted (ST1620).

  After ST1620 or in the case of authentication NG in ST1619 (when the determination is No), authentication result receiving means 903 displays the authentication result on the display (ST1621).

  For example, in the case of authentication OK, it is possible to display information indicating that, and in the case of authentication NG, it may be possible to display information indicating that and not allowing entry. The event staff confirms that information indicating that the authentication is OK is displayed on the display, and prompts the visitor to enter.

  On the other hand, when the visit history update means 309 of the lottery server 3 receives a visit history DB update request together with the user ID and performance code from the venue terminal 9 (ST1622), it updates the storage contents of the visit history DB (ST1623). .

  Specifically, the value in the status column of the record corresponding to the received user ID and performance code in the stored contents of the visit history DB is changed to 1 (entered).

The embodiment of the present invention has been described above, but the present invention is not limited to the above-described embodiment, and various modifications can be made within the scope of the gist of the invention.
[Modification]
Hereinafter, modifications of the present invention will be described.

  For example, in the embodiment, a concert is given as an example of an event, but in general, whether or not to participate is determined by the presence or absence of a ticket (including an electronic ticket), sports events such as baseball and soccer, stage events such as theater and musical Various events such as car races, public recordings on television stations, and other events such as movies can be targeted.

  In the embodiment, as one or more conditions used by the lottery means 305 in the lottery process, the condition that the applicant for the lottery is a fan club member of the artist of the application target event is adopted. May have adopted the condition that FC member registration is performed on both homepages when a homepage for personal computers and a homepage for mobile phones are opened. The idea is to give priority to fans who have a stronger attachment to artists.

  The DB is appropriately provided in any one of the lottery server 3, the FC server 5, the ticket sales company server 7, and the venue terminal 9, but on a network connected to the respective devices so as to be communicable or other devices. (For example, a configuration in which the member data DB is provided on a network connected to the lottery server 3 so as to be communicable or in an FC server or the like).

  The lottery server 3, the FC server 5, the ticket sales company server 7, and the venue terminal 9 are each provided with functional means corresponding to the use of each device, but the functional means provided in each device is Some of the means may be configured together, or one means may be further divided into a plurality of means.

  Although the lottery server 3, the FC server 5, and the ticket sales company server 7 exist separately in the embodiment, two or all of them may be configured together. In that case, for example, the lottery server 3 may include the functions of the FC server 5 and the ticket sales company server 7.

  In the embodiment, a user who desires to purchase a ticket to be resold can in principle purchase only one ticket, but adopts a configuration in which a companion id is also transmitted as purchase request data, and ST1597 and ST1598. In this process, if the determination is made with respect to both the purchase requester and the accompanying person, a mode in which a plurality of tickets can be purchased through resale is also possible. In this case, it is preferable that records relating to both the purchase requester and the accompanying person are created in the purchase history DB and the confirmer information DB.

  In the lottery applicant classification process by the lottery server 3, the lottery means 305 determines that the user to be classified does not pay the annual membership fee (when the determination of ST1533 is No), or the person who violates the rules (determination of ST1534). In the case of Yes), when there is a history of not having visited in the past (when the determination of ST1535 is Yes), the user is treated as a lost player (ST1536). You may make it classify into a group and perform the next lottery of the 7th group.

The figure which shows the structure of the ticket transaction system comprised using the lottery server of an Example. The figure which shows the hardware constitutions of a lottery server, FC server, a ticket sales company server, a meeting place terminal, and a user terminal. The block diagram which shows the structure of a lottery server. (A) is a diagram showing the data structure of the member data DB provided in the lottery server, (B) is a diagram showing the data structure of the purchase history DB provided in the lottery server, and (C) is a lottery. The figure which shows the data structure of application information DB with which the server is equipped, (D) is the figure which shows the data structure of visit history DB with which the lottery server is equipped. The block diagram which shows the structure of FC server. The figure which shows the data structure of FC member DB with which the FC server is equipped. The block diagram which shows the structure of a ticket sales company server. (A) is a diagram showing a data structure of a ticket master DB provided in the ticket sales company server, (B) is a diagram showing a data structure of a winner information DB provided in the ticket sales company server, C is a diagram showing a data structure of a confirmation information DB provided in the ticket sales company server. The block diagram which shows the structure of the hall terminal 9. FIG. (A) is a flowchart of FC member registration processing in the FC server and response processing of the lottery server in response to an inquiry from the FC server, and (B) is a flowchart of member registration processing by the lottery server. (A) is a flowchart of the storage process of the ticket information by a lottery server, (B) is a flowchart of the storage process of the applicant data of the lottery by a lottery server. The flowchart of the classification process of the lottery applicant by a lottery server, and the response process of the FC server with respect to the inquiry from a lottery server. (A) is a flowchart of lottery processing by a lottery server and storage processing of winner information by a ticket sales company server, (B) is a process of transmitting purchaser information by a ticket sales company server, and ticket information by a lottery server. The flowchart of a transmission process. (A) is a flowchart of the resale request reception process by a lottery server, (B) is a flowchart of the resale process in this system. (A) is a flowchart of storage processing of purchaser confirmation information by the venue terminal and response processing by the lottery server in response to a request from the venue terminal, and (B) is an authentication information reception processing by the venue terminal and a visit by the lottery server. 7 is a flowchart of history DB update processing.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Ticket transaction system 3 Lottery server 301 User registration means 302 Ticket information reception means 303 Event information presentation means 304 Lottery reception means 305 Lottery means 306 Purchaser information recording means 307 Resale means 308 Confirmation information transmission means 309 Visit history update means 5 FC server 501 FC member registration means 502 ID inquiry means 503 FC member registration inspection means 7 Ticket sales company server 701 Ticket information transmission means 702 Winner information update means 703 Confirmation information DB update means 704 Ticket issue means 9 Venue terminal 901 Confirmation information request means 902 IC data acquisition means 903 Authentication result acceptance means 11a, 11b, 11c User terminal

Claims (7)

A lottery device that determines the winner of an event participation right by lottery,
Application information DB for storing member identification information of applicants of the lottery in association with identification information of the event and information indicating whether or not the event has been won,
A purchase history DB for storing member identification information of the purchaser of the participation right in association with identification information of the event;
Lottery acceptance means for accepting application for the lottery and recording the identification information of the target event and the member identification information of the applicant in the application information DB;
Based on one or more conditions, the applicants recorded in the application information DB are classified into a plurality of groups having different priorities, and the winners are determined by drawing in order from the group having the highest priority. Lottery means for updating the stored contents of the DB;
Means for recording, in the purchase history DB, the member identification information of the corresponding winner as the purchaser's member identification information when payment of the participation right is confirmed;
The one or more conditions include a condition that the number of purchases of past participation rights is equal to or less than a threshold based on the stored contents of the purchase history DB.   The lottery device according to claim 1, wherein the lottery means adds lottery winners generated from the group that has performed the lottery to the group having the next priority, and then performs the lottery for the group having the next priority. The purchase history DB stores the purchaser's member identification information in association with information indicating whether or not the purchaser has resold the participation right,
Accepting the resale request for the participation right and the purchase request for the participation right to be resold, and based on the stored contents of the purchase history DB, the purchase requester does not hold duplicate participation rights for the same event. It is determined that the reselling of the participation right is established as a condition, and information indicating that the participation right has been resold is recorded for the reselling requester in the purchase history DB. The lottery device according to claim 1 or 2, further comprising resale means for recording the member identification information in association with the identification information of the event corresponding to the participation right.   The lottery device according to claim 3, wherein the one or more conditions include a condition that the number of resale of the participation right is equal to or less than a threshold based on the storage content of the purchase history DB.   Confirmation information transmission that extracts the member identification information of the purchaser who has not resold the participation right and the identification information of the event corresponding to the participation right from the purchase history DB, and transmits the information to the ticket sales system as the confirmation information regarding the event participant. The lottery device according to claim 3 or 4, comprising means.   6. The lottery apparatus according to claim 5, wherein the confirmed information transmitting means further transmits the confirmed information as information for authenticating a visitor to a terminal installed at a target event venue. A means for accessing a DB for storing fan club member information for each artist,
The event identification information includes artist identification information for each event,
The lottery device according to any one of claims 1 to 6, wherein the one or more conditions include a condition that an applicant of the lottery is a fan club member of an artist of an application target event.

Images