WO2018142587A1

WO2018142587A1 - Ticket management system and ticket management method

Info

Publication number: WO2018142587A1
Application number: PCT/JP2017/004039
Authority: WO
Inventors: 友香西脇
Original assignee: 株式会社日立製作所
Priority date: 2017-02-03
Filing date: 2017-02-03
Publication date: 2018-08-09
Also published as: JP6707673B2; JPWO2018142587A1

Abstract

The present invention performs effective management of tickets. This ticket management system is provided with a processing device, a storage device, and an interface for input and output. In this system, the storage device stores a ticket owner change history that indicates time-series data for each ticket as to which of users owned the ticket. The processing device calculates, for each of the users, points that reflect the ticket owner change history. The storage device records the points and the corresponding user in association with each other. In response to a request received via the interface, the processing device, according to the points, imposes (1) restriction on ticket purchase and/or ticket transfer by a user corresponding to the points that satisfy a specific condition, and/or (2) restriction on the use of a ticket owned by the user corresponding to the points that satisfy the specific condition.

Description

Ticket management system and ticket management method

The present invention relates to a ticket management system, and more particularly to a ticket management system based on a ticket owner change history.

The online ticket reservation system allows users to purchase tickets regardless of time and place, and in recent years, the use of electronic tickets has increased. The widespread use of the Internet has facilitated fraudulent resale of purchasing large numbers of tickets and reselling them for profit. Many of the current measures for ticket purchasers for the purpose of fraudulent resale are those that authenticate the person locally, and it currently takes a lot of cost and time on the day of the event covered by the ticket. .

As a technique for preventing unauthorized resale or forgery of tickets, Japanese Patent Laid-Open No. 2006-201997 (Patent Document 1) embeds an authentication code as an electronic watermark in an electronic ticket, thereby ensuring the identity of the ticket purchaser and the user. It is disclosed to secure and prevent unauthorized resale.

JP 2006-201997

The method of Patent Document 1 issues a ticket having an image in which a predetermined authentication code is embedded as a digital watermark in the purchaser's own face photo, and collates the face photo and uses the authentication code embedded in the face photo when using the ticket Can be confirmed to be authentic. In addition, it is disclosed that a ticket can be easily canceled or reissued by referring to a ticketing history recorded in a ticketing history recording unit.

However, in Patent Document 1, in the ticketing history recording unit, the ticket owner change history and the biological information of the ticket owner (or the purchaser) are recorded, and the canceled information of the second party is rewritten with the information on the waiting list for cancellation. , It is not possible to utilize the entire change history.

In order to effectively prevent resale, it is effective to use not only information on the date of purchase and the date of purchase, but also information on the period during which the ticket is owned by the user for ticket management such as validation determination.

One aspect of the present invention is a ticket management system including a processing device, a storage device, and an interface for input and output. In this system, the storage device stores a ticket owner change history indicating in time series which of the users owns the ticket for each ticket. The processing device calculates a point reflecting the ticket owner change history for each user. The storage device records the points in association with the user. The processing device, based on the points for the request received via the interface, (1) at least one restriction on the purchase and transfer of the ticket of the user corresponding to the point satisfying the specific condition, and (2) At least one of the restrictions on the use of the ticket owned by the user corresponding to the point satisfying the specific condition is performed.

Another aspect of the present invention is a ticket management method using a server having a processing device, a storage device, and an interface for input and output. This method is a first step in which the storage device stores a ticket owner change history indicating in time series which one of the users owns the ticket for each ticket, and the processing device reflects the ticket owner change history. A second step of calculating points for each user; a third step of storing the points in association with the users; and a fourth step of accepting a predetermined request made by the user specifying a ticket with the interface. The step, the processing device, executes the fifth step of referring to the point corresponding to the user specified in the fourth step and determining whether or not the predetermined request is permitted.

According to the present invention, tickets can be managed effectively.

1 is a configuration block diagram of an example of a ticket reservation system 1000. FIG. The flowchart of an example of the process which the new registration process part 1121 performs. The table of an example of the purchaser information table 1141. FIG. The flowchart of an example of the process which the ticket purchase process part 1122 performs. FIG. 6 is a table illustrating an example of a ticket information table 1142. FIG. 14 is a table illustrating an example of a ticket owner change history table 1143. The flowchart of an example of the process which the ticket owner change judgment part 1123 performs. The flowchart of an example of the process which the ticket validation judgment part 1124 performs. The flowchart of an example of the update process to (nP) of ticket owner change log | history point (P). The conceptual diagram which shows the principle of ticket owner change log | history point addition. FIG. 3 is a table showing a calculation process of point addition according to the first embodiment. FIG. 12 is a flowchart of an example of a calculation process of ticket owner change history points (nP) according to the second embodiment. FIG. 6 is a table showing the calculation process of point addition according to the second embodiment.

Hereinafter, embodiments of the present invention will be described with reference to the drawings. This embodiment is merely an example for realizing the present invention, and does not limit the technical scope of the present invention.

In the following embodiment, a technique for collecting the owner change history during the period in which the user owns the ticket and using it for determination of ticket validity will be described. In particular, the technical logic for determining the validity of a ticket is disclosed by pointing the resale status based on all owner change histories.

A typical configuration example of the present embodiment is a ticket reservation server that makes a ticket validation determination based on a ticket owner change history in an online ticket reservation system for an electronic ticket. A new registration processing unit for performing ticket purchase processing, a ticket purchase processing unit for performing user ticket purchase processing, a ticket owner change determination unit for writing history when the ticket owner is changed, And a ticket validation determination unit that finally implements validation validation.

In the following, a method for operating the ticket reservation server to prevent resale will be described. The target of this embodiment is an electronic ticket for an event such as a concert.

<1. System configuration>
FIG. 1 shows an example of a ticket reservation system according to this embodiment. The ticket reservation system 1000 includes a ticket reservation server 1100, a terminal 1200 used by a ticket purchaser, and a wired or wireless network 1300 that is connected so as to enable communication therebetween.

The ticket reservation server 1100 includes a CPU (Central Processing Unit) 1110 that is a processing device, a memory 1120 configured by a semiconductor storage device, an interface 1130 for input and output, and a storage device 1140 configured by a magnetic disk device. Prepare. The memory 1120 and the storage device 1140 may use different areas of the physically same storage device. The ticket reservation server 1100 can be configured by a general computer (server). Although not shown in the drawing, an input / output device provided in the server such as an output device such as a monitor or an input device such as a keyboard can be connected via the interface 1130. The interface 1130 for input and output does not mean only an input / output function, but an interface having only an input function, an interface having only an output function, and further has both input / output functions. It shall mean any interface.

In this embodiment, functions such as calculation and control are realized in cooperation with other hardware by transferring a program stored in the storage device 1140 to the memory 1120 and executing it by the CPU 1110. Is done. A program executed by the CPU 1110, its function, or means for realizing the function may be referred to as “function”, “means”, “unit”, “unit”, or the like. However, it is also possible to realize equivalent functions with hardware without using software.

When realized by software, the memory 1120 stores a program for realizing each function of the present embodiment. The new registration processing unit 1121 has a function of newly registering a user of the ticket reservation system. The ticket purchase processing unit 1122 has a function of processing ticket purchase. The ticket owner change determination unit 1123 has a function of determining a change of the ticket owner. The ticket validation determination unit 1124 has a function of judging whether a ticket is valid or invalid.

The storage device 1140 stores a purchaser information table 1141, a ticket information table 1142, a ticket owner change history table 1143, and the like as databases.

The terminal 1200 used by the ticket purchaser may be a portable terminal owned by each user, or a common stationary terminal installed in a ticket store or the like. In the present specification, the terminal 1200 is simply referred to without particular distinction.

<2. New user registration process>
FIG. 2 is a processing flowchart when a user newly registers in the ticket reservation system. Here, a process performed by the new registration processing unit 1121 of the ticket reservation server 1100 when the user A newly registers in the ticket reservation system 1000 and becomes a member will be described as an example. The process starts, for example, upon reception of a registration application command transmitted from the terminal 1200 by the user A.

In the user information reception process S201, the ticket reservation server 1100 receives user information input from the terminal 1200 as user A information and transmitted via the network 1300 via the interface 1130.

In the purchaser information table update processing S202, the new registration processing unit 1121 receives, for example, the user A's “name”, “address”, “birth date”, “phone number”, “biological information”, and the like as the received user information. Is registered in the purchaser information table 1141 and registered as a new user. In the figure, solid arrows indicate the flow of processing, and broken arrows indicate the flow of data (the same applies hereinafter).

FIG. 3 is an example of the purchaser information table 1141 stored in the storage device 1140. One data set is stored for each user. Each data set includes, for example, a user's “name” 3001, “address” 3002, “birth date” 3003, “phone number” 3004, and “biometric information” 3005. The biometric information is, for example, a user's fingerprint or finger vein pattern. The above is an example, and not all information is essential, and other information may be added.

In the user ID / password assignment processing S203, the new registration processing unit 1121 uniquely assigns a value associated with the “biometric information” 3005 of the user A to the “user ID” 3006 and “password” 3007 of the purchaser information table 1141. The “user ID” 3006 and “password” 3007 written and confirmed in this way are sent to the terminal 1200 of the user A. A known encryption technique or the like may be used for transmission / reception of important data.

The purchaser information table 1141 includes a ticket owner change history point (P) 3008 as another item for each user. The ticket owner change history point (P) 3008 is set to an initial value of 0 when a user is newly registered. Ticket owner change history points (P) 3008 are added to each user as points reflecting the past ticket history owned by each user. The point is used to determine whether or not the user can purchase a ticket. Further, it is used to determine whether resale or transfer (hereinafter referred to as “transfer”) is possible. The ticket owner change history point (P) 3008 will be described in detail later. This completes the new user registration process.

<3. New ticket purchase processing>
A process performed by the ticket reservation server 1100 when a user newly purchases a ticket will be described with reference to FIG. Here, when the user A registered in the purchaser information table 1141 in FIG. 3 accesses the ticket reservation system 1000 and intends to purchase five tickets, the ticket purchase processing unit 1122 of the ticket reservation server 1100. Will be described.

In the login process S401, the ticket reservation server 1100 receives "biological information", "user ID", and "password" input by the user on the login screen via the terminal 1200. When the correct information is input by comparing the “biological information” 3005, “user ID” 3006, and “password” 3007 of the user A written in the purchaser information table 1141, the ticket reservation server 1100 selects the user as the user. Identify as A and allow login.

In the process S402, the ticket reservation server 1100 uses the terminal 1200 as information on the ticket that the user A desires to purchase, such as “performance name”, “performance date”, “number of sheets”, etc. Receive via. Note that the user inputs only information specifying the ticket, for example, “performance name” and “number of pieces”, and “performance date” and other information are data associated with the information specifying the ticket on the ticket reservation server 1100 side. You may get from.

In process S403, the ticket purchase processing unit 1122 refers to the purchaser information table 1141 and reads the ticket owner change history point (P) 3008 of the user A. If it is known in advance that the login is related to a specific ticket purchase, the desired ticket information reception process S402 may be skipped and the ticket owner change history point reference process S403 and subsequent steps may be executed. good.

In process S404, it is determined whether or not the ticket owner change history point (P) 3008 of the user A is equal to or greater than a predetermined threshold value S1. If it is equal to or greater than the predetermined threshold value S1, the process proceeds to processing S405 for rejecting purchase. If it is less than the predetermined threshold value S1, the process proceeds to step S406 and subsequent steps for issuing a ticket.

In process S405, the fact that the ticket cannot be purchased is transmitted to the terminal 1200 of user A, and the process is terminated.

In process S406, the ticket purchase processing unit 1122 registers, in the “ticket ID” of the ticket information table 1142, unique “ticket IDs” corresponding to the “number of tickets” received in the desired ticket information reception process S402.

FIG. 5 is an example of the ticket information table 1142 stored in the storage device 1140. Through the ticket ID assignment process S406, a uniquely determined ticket ID 501 corresponding to the number of tickets desired by the user is newly generated and added to the ticket information table 1142. In the example of FIG. 5, data of “MNO1”, “MNO2”, “MNO3”, “MNO4”, and “MNP1”, which are IDs corresponding to the five tickets purchased by the user A, are generated.

In process S407, information such as “performance name” 502 and “performance date” 503 corresponding to the ticket is written corresponding to each ticket ID 501 of the ticket information table 1142. The information is not limited to this.

In process S408, the ticket purchase processing unit 1122 updates the ticket owner change history table 1143.

FIG. 6 is an example of the ticket owner change history table 1143 stored in the storage device 1140. The ticket owner change history table 1143 stores a change history of the ticket owner for each ticket.

The ticket purchase processing unit 1122 stores, in the “ticket ID” 601 of the ticket owner change history table 1143, “MNO1” and “MNO1” that can be cross-referenced with the “ticket ID” 501 of the ticket information table 1142 as the ID of the purchased ticket. Register “MNO2”, “MNO3”, “MNO4”, “MNP1”. Of course, the ticket owner change history table 1143 may be combined with the ticket information table 1142 to form one table.

Since this process is a new issuance of 5 tickets, the owner of each ticket is the first person. Therefore, user ID “1111” of user A is written as “ticket owner change history: first person” 602 (1) corresponding to the above five “ticket IDs” 501 and “ticket purchase time” 603 (1). Write the time when the ticket was purchased. With this process, the user A is registered as the first owner for the five tickets.

In process S409, a temporary electronic ticket is sent to the terminal 1200 of user A. The electronic ticket may be a publicly known ticket as described in Patent Document 1, for example. As a simple example, the electronic ticket is in the form of electronic data that can be transmitted and received via a network, and is, for example, a QR code (trademark) including data of a ticket ID and an owner user ID. When in use, the QR code is read and biometric authentication information is input. The ticket reservation server 1100 can confirm that the proper owner owns the ticket based on the information in the purchaser information table 1141 and the ticket owner change history table 1143.

As described later, the ticket can be used by enabling it on the ticket reservation server 1100 side. If it is not enabled or disabled, it cannot be used. Therefore, the ticket owner change history table 1143 has an item of “ticket valid / invalid flag” 604 for each ticket. This will be described in detail later.

<4. Ticket owner change processing>
FIG. 7 is a flowchart when the ticket owner is changed. As an example, an electronic ticket with the ticket ID “MNO1” is transferred from the user A (user ID “1111”) registered in the purchaser information table 1141 in FIG. 3 to the user E (user ID “1115”). explain. The transfer of the electronic ticket is performed, for example, by transferring ticket ID data from the user A to the user E.

Here, when the user E who has received the electronic ticket accesses the ticket reservation system 1000 and tries to change the owner of the ticket (transfer processing), the ticket owner change determination unit 1123 of the ticket reservation server 1100 This will be described as processing to be performed.

In login processing S701, after the user A sends a ticket to the user E, the ticket reservation server 1100 receives the “biological information”, “user ID”, “password”, and “ticket ID” entered by the user E on the login screen. And received via the terminal 1200 of the user E. Basically, as in the login process S401 of FIG. 4, the purchaser information table 1141 is referred to, and if the user E is registered as a member, login is permitted. If the member is not registered, a member registration screen is sent to the user E, and the input information is newly registered in the purchaser information table 1141. The procedure of the new registration process is the same as that described with reference to FIG.

In process S <b> 702, the ticket owner change determination unit 1123 receives the biological information input from the user E via the terminal 1200. Then, the ticket owner change determination unit 1123 refers to the “ticket owner change history point (P)” 3008 of the user E from the purchaser information table 1141 based on the input biometric information.

In process S703, if the ticket owner change history point (P) is equal to or greater than the predetermined threshold S2, the process proceeds to process S704. If the ticket owner change history point (P) is less than the predetermined threshold S2, the process proceeds to a ticket transfer process subsequent to process S705. The threshold value S2 may be the same as the threshold value S1 in FIG.

In process S704, the fact that the ticket cannot be transferred is transmitted to user E's terminal 1200, and the process is terminated.

In the process S705, when the transfer of the ticket is permitted, the ticket owner change determination unit 1123 determines the ticket owner based on the user ID “1115” and the ticket ID “MNO1” of the user E received in the login process S701. The change history table 1143 is updated.

In addition, in order to confirm that the user E different from the original owner user A has received the transfer, a confirmation process may be performed before the ticket owner change history table update process S705. In the confirmation process, the user ID of the last owner in the ticket owner change history table 1143 is referred to, and the biometric information 3005 of the user in the purchaser information table 1141 is acquired. The biometric information 3005 in the purchaser information table 1141 is compared with the “biometric information” acquired in the login process S701, and if they are the same, the process is terminated as a duplicate procedure by the same user. Only when they are different, the ticket owner change history table update processing S705 and the subsequent steps are performed assuming that the ticket has been transferred.

Referring to FIG. 6 again, the ticket owner change history table update process S705 will be described. Since the current process is the transfer of the ticket corresponding to the received ticket ID from the user A, that is, the first transfer, the ticket owner is the second person. Therefore, the user ID “1115” of the user E is written as “ticket owner change history: second person” 602 (2) of the ticket ID “MNO1”, and “ticket owner change time: second person” 603 (2) is written. Write the time the ticket was transferred. With this processing, the user E is registered in the ticket reservation server 1100 as the second owner for the ticket ID “MNO1”. As the “ticket owner change time”, the time when the ticket owner change history table 1143 is updated may be used.

In the ticket transfer process S706, after the ticket owner change history table 1143 is updated, the ticket reservation server 1100 sends an electronic ticket in a provisional state to the terminal 1200 of the user E as necessary, for example, using a QR code.

FIG. 6 shows only the data of the second owner, but the same processing as described above is performed for the third and subsequent owners. The owner data is added for each ticket ID 601. Through the processing as described above, the change of owner for each ticket is stored in the ticket owner change history table 1143 as a history.

<5. Ticket validation decision processing>
FIG. 8 is a flowchart of processing for determining validity / invalidity of a ticket in the ticket reservation system 1000. Here, the processing performed by the ticket validation determination unit 1124 of the ticket reservation server 1100 will be described.

Ticket validation can be made any number of times at any time. However, in view of efficiency, it is desirable to perform the process once immediately before the specified expiration date of the ticket. For example, the timing is “72 hours (3 days) before the start date and time of the event to be ticketed”. The process starts for each ticket on the condition that it is the timing, but generally, a large number of tickets are issued for one event, and those tickets have the same expiration date. The ticket validation determination may be considered as a process that is collectively performed for a plurality of target tickets at a certain point in time. That is, it is a batch process for a plurality of target tickets associated with predetermined time information. The target ticket can be extracted by narrowing down and searching the ticket information table 1142 with the performance name 502 and the performance date 503 and conditions. The following embodiment will be described on the assumption of such processing.

In process S801, the ticket validation determination unit 1124 performs a process of updating the ticket owner update history point (P) to the new ticket owner update history point (nP) for each user related to the target ticket. Here, (P) and (nP) are the same parameters, but different symbols are used to distinguish before and after the update. Since there are a plurality of target tickets and a plurality of related users, (P) is updated to (nP) based on these pieces of information.

FIG. 9 is a flowchart showing details of the process S801. This flow is performed for each of a plurality of target tickets processed at that time.

In process S901, the ticket validation determination unit 1124 refers to the ticket owner change history table 1143 to identify each user through which the target ticket has passed.

In process S902, the ticket validation determination unit 1124 refers to the purchaser information table 1141 and calls the ticket owner change history point (P) 3008 for each identified owner.

In process S903, an addition point (AP) is calculated for each owner through which the target ticket passes.

FIG. 10 shows a concept of an example of calculation rules for addition points (AP). FIG. 10 shows an example in which the target ticket passes through four users: a user W1001 who is a ticket purchaser, a user X1002 who is an intermediate owner, a user Y1003 who is an intermediate owner, and a user Z1004 who is the final user of the ticket. ing. Here, the calculation rule is based on the following two rules.

Rule 1: Except for the final user (ticket user), an additional point (AP) based on the rule that “if the user is the starting point, then N points are given if N people are passed through thereafter” Will be determined. That is, 1 point is added to the target user every time one user passes through the user.

Rule 2: The final user has the same number of points as the first purchaser.

Based on this rule, the user W passes through the three users X, Y, and Z according to the rule 1, and the addition point (AP) is 3. Since user X subsequently passes through two users Y and Z according to rule 1, the addition point (AP) is 2. Since the user Y subsequently passes one of the users Z according to the rule 1, the addition point (AP) is 1. Further, the user Z has an addition point (AP) of 3 as in the case of the user W according to rule 2.

According to Rule 1, the additional points (AP) of users who are often involved in tickets with a large number of transfers are increased. Usually, if a ticket purchased by himself is used by himself, the addition point (AP) is 0. However, consider a case where a person who has purchased a large number of tickets for the purpose of resale (primary reseller) is subdivided into other persons (secondary resellers) and the secondary reseller sells to the end user. In addition, the additional points (AP) of primary resellers who are involved in a large number of tickets and resell each ticket become very large. Further, according to Rule 2, the person who uses the resold ticket also increases the points added. Here, the rule is that one point is added when one person passes, but the number of times of passing may be weighted. For example, 2 points for the second transfer and 3 points for the third transfer.

Returning to FIG. 9, in step S904, the ticket owner change history point (P) 3008 of each user called in step S902 is added to the addition point (AP) calculated for each user, and each user owns a new ticket. Person change history points (nP) are calculated. Based on the calculated ticket owner change history point (nP), the ticket validation determination unit 1124 changes the ticket owner change history point (P) 3008 of the purchaser information table 1141 from the past data (P) to the new data (nP). Update to

The above process is executed for the target ticket, and the process proceeds to process S802.

Returning to FIG. 8, in step S802, it is determined whether the ticket is valid or invalid based on the owner change history point (nP) of each user through which the target ticket has passed. This process is also repeated for the target ticket.

In one example of the determination, it is determined whether the owner change history point (nP) passes only through a user whose threshold value is less than the threshold value S3 or whether any user whose (nP) is equal to or higher than the threshold value S3 passes. S3 may be the same as S1 and S2, or may be different.

In process S803, the target ticket is invalidated when even one user whose (nP) is equal to or greater than the threshold value S3 passes.

In process S804, the target ticket is validated when none of the users whose (nP) is the threshold value S3 or more pass through.

In process S805, the ticket validation / invalidation flag 604 is recorded in the ticket owner change history table 1143 based on the results of the processes S803 and S804. When the ticket becomes invalid, the ticket reservation server 1100 desirably notifies the user terminal 1200 that the ticket has been invalidated at an appropriate timing.

[Case 1: Transfer from user A to users E, F, G, H, I]
An example in which the user A registered in the purchaser information table 1141 in FIG. 3 transfers five newly purchased tickets will be described using the first embodiment described above. In this example, an example is shown in which the ticket reservation server 1100 effectively activates the function for a target ticket purchased on the date of January 1, 2016 by the user A. In this example, the thresholds S1, S2, and S3 are set to 30, and the fixed time zone for making the ticket validation determination is 0:00 on January 1, 2016, which is the day of ticket use. It is assumed that user A, user E, user F, user G, user H, and user I are not involved in ticket purchases and ticket owner changes other than those shown in the figure.

In case 1, the owner of all 5 tickets owned by the first owner user A was changed, so points were added. As a result, the total points of user A exceeded a certain number and all tickets were invalidated. Pattern.

[Case 1-1: When purchasing a new ticket]
First, when the user A purchases five tickets, the ticket owner change history point (P) of the user A recorded in the purchaser information table 1141 is checked based on the flow of FIG. Judgment is made. In the example of the purchaser information table 1141 in FIG. 3, the point (P) of the user A is 27 and is less than S1 = 30. The data of the five tickets are registered in the table 1143.

[Case 1-2: Ticket transfer]
As shown in the ticket owner change history table 1143 in FIG. 6, the tickets whose user A (user ID “1111”) is the first owner are ticket IDs “MNO1”, “MNO2”, “MNO3”. , “MNO4” and “MNP1”. Hereinafter, the operation of the ticket owner change determination unit 1123 will be described.

When the user A transfers the ticket with the ticket ID “MNO1” to the user E (user ID “1115”) before the ticket validation determination, the change of the ticket owner is performed according to the processes S702 and S703 in the flow of FIG. The determination unit 1123 refers to the purchaser information table 1141 in FIG. 3 and checks the ticket owner change history point (P) 3008 of the user who receives the transfer. Since the ticket owner change history point (P) of the user E is 4 and is less than S2 = 30, the transfer is permitted.

Similarly, for the ticket “MNO2”, (P) of the user F (user ID “1116”) is 7, so that the change of the ticket owner from the user A to the user F is permitted. Similarly, for the ticket of “MNO3”, (P) of the user G (user ID “1117”) is 2, so that the ticket owner change from the user A to the user G is permitted. Similarly, the ticket owner “MNO4” is permitted to change the ticket owner to the user H (user ID “1118”) with the point (P) 1, and the ticket (MNP1) also has the point (P) 6 Change of the ticket owner to the user I (user ID “1119”) is permitted.

User IDs “1115”, “1116” of users E, F, G, H, and I who are new owners of the permitted tickets “MNO1”, “MNO2”, “MNO3”, “MNO4”, “MNP1”, “1117”, “1118”, and “1119” are stored in the ticket owner change history table 1143 of FIG. 6 as “ticket owner change history: second person” 602 (2), “ticket owner change time: second person”. It is registered together with 603 (2).

[Case 1-3: When validating a ticket]
In the following, an example of processing at the time of ticket validation determination performed after the above processing will be described. Based on the “performance date” in the ticket information table, the ticket validation determination unit 1124 of the ticket reservation server 1100 owns the “ticket ID” of the ticket that has reached 0:00 on January 1, 2016, which is the ticket usage date. Referred from the person change history table 1143. Among the purchased tickets of user A, the “ticket IDs” of the tickets that have reached the target time zone are “MNO1,” “MNO2,” “MNO3,” “MNO4,” and “MNP1”. The ticket reservation server 1100 locks the target ticket so that it cannot be sent to the outside.

Based on the flow of FIG. 9, the ticket reservation server 1100 refers to “ticket owner change history: second person” corresponding to the ticket ID “MNO1” from the ticket owner change history table 1143 in step S901, and sets “MNO1 Is changed to the user E, and the current owner is determined to be the user E.

Similarly, the ticket reservation server 1100 determines that the owner of the “MNO2” ticket has been changed to the user F, and determines that the owner of the “MNO3” ticket has been changed to the user G. Then, it is determined that the owner of the ticket “MNO4” has been changed by the user H, and the owner of the ticket “MNP1” has been changed by the user I.

Next, the ticket reservation server 1100 determines the addition points (AP) of each user for the tickets “MNO1”, “MNO2”, “MNO3”, “MNO4”, and “MNP1” based on the algorithm described in FIG. calculate. The final user gives the same points to the purchaser who is the first ticket owner and the target ticket.

FIG. 11 shows an example of a calculation table 11000 for calculating addition points (AP). This table is shown in order to explain the processing contents of the embodiment, and it is not necessary to create a table as an actual system.

From the owner change history of the target ticket based on the ticket owner change history table 1143 in FIG. 6, 5 points are added points (AP) when the five tickets are transferred once to the user A indicated by the name 1101. It is said. The user who received the transfer of the ticket from the user A becomes the same additional point as the user A for the transferred ticket, so that the user E has 1 point, the user F has 1 point, the user G has 1 point, the user One point for H and one point for user I are added points (AP) 1103.

9, the addition point (AP) 1103 is added to the ticket owner change history point (P) of each user, and a new ticket owner change history point (nP) 1104 is calculated. As shown in FIG. 11, the new ticket owner change history point (nP) 1104 is that user A has 32 points, user E has 5 points, user F has 8 points, user G has 3 points, user H has 2 points, User I is calculated as 7 points. The new ticket owner change history point (nP) 1104 is overwritten on the ticket owner change history point (P) 3008 of each user in the purchaser information table 1141 of FIG.

In step S802 of FIG. 8, the ticket reservation server 1100 determines whether there is a user whose new ticket owner change history point (nP) is equal to or greater than the threshold value S3 = 30. If there is even one corresponding user, the ticket is invalidated in step S803. In the above example, the ticket owner change history point (P) in the purchaser information table 1141 is updated and then the ticket is validated and invalidated. The ticket owner change history point (P) in the purchaser information table 1141 may be updated after the validation and invalidation determination using a simple table.

In this example, since the point of user A is 32 and is 30 or more, all of “MNO1”, “MNO2”, “MNO3”, “MNO4”, and “MNP1” passing through user A are invalidated. No. 6 is written in the “ticket validation / invalidation flag” 604 of the ticket owner change history table 1143.

As can be seen from the above description, in this embodiment, if the user A who is highly involved in the resold ticket and is likely to be an unauthorized reseller is determined, all the tickets in which the user A is involved become invalid. For this reason, since the ticket of the person who purchased from the reseller can no longer be used, an effect of suppressing unauthorized resale can be expected.

Further, the addition points (AP) and new ticket owner change history points (nP) of other users B, C, D, J, K, and L in the first embodiment are also as shown in the calculation table 11000 of FIG. .

[Case 1-4: Subsequent purchase of new ticket or relocation]
Thereafter, when each user newly purchases a ticket, the change history point (P) of the ticket owner of the user A becomes 32 according to the result of “Case 1-3”, and S1 = S2 = 30 or more. Therefore, new purchases and transfers are also prohibited according to the flow of FIGS. On the other hand, as for user E, user F, user G, user H, and user I who received resale, as shown in FIG. 11, the new ticket owner change history point (nP) is less than 30, so the user A has been relocated. Tickets can not be used, but new purchases and legitimate transfers are possible.

[Case 2: Transfer from user C to users K and L]
In Case 2, the user C (user ID “1113”) shown in the purchaser information table 1141 in FIG. 3 replaces the purchased ticket (ticket ID “MNO5” “MNO6”) with user K (user ID “1121). An example of transferring to the user L (user ID “1122”) will be described.

This example shows an example in which the ticket reservation server effectively activates the function for a target ticket purchased on January 1, 2016, which is purchased by user C. In the present embodiment, a certain number S1, S2, S3 is set to 30, and a certain time zone for performing ticket validation determination is 0:00 on January 1, 2016, which is the day of ticket use. It is assumed that the user C, the user K, and the user L are not involved in ticket purchase other than the target ticket in this example and change of the ticket owner.

In this example, user C was going to purchase two tickets “MNO5” and “MNO6” and go to a concert with two friends. However, since both of them become inconvenient, the user C considers an example of transferring one sheet to the user K and the other sheet to the user L. Hereinafter, the processing performed by the ticket validation determination unit 1124 of the ticket reservation server 1100 will be described.

In Case 2, since the owners of two tickets owned by the first owner user C are changed to the user K and the user L one by one, points are added, and as a result, the total points of the user L are a certain number. In this pattern, only the ticket received by the user L is invalidated.

[Case 2-1: When purchasing a new ticket]
When the user C purchases a new ticket, the ticket reservation server 1100 refers to the “ticket owner change history point (P)” 3008 of the user C from the purchaser information table 1141 of FIG. Since the point (P) is 15 and less than 30, the user C is permitted to purchase a ticket. The purchased ticket is added as new data (ticket IDs “MNO5” and “MNO6”) to the ticket information table 1142 and the ticket owner change history table 1143.

[Case 2-2: When a ticket is transferred]
User C (user ID “1113”) transfers the ticket of “MNO5” out of these two tickets “MNO5” and “MNO6” to his friend User K (user ID “1121”), and another one Are transferred to user L (user ID “1122”) who is an addict of resale.

At the time of transfer from the user C to the user K and the user L, the “ticket owner change history point (P)” 3008 of the user K and the user L is referred to based on the flow of FIG. In the example of the purchaser information table 1141 in FIG. 3, the points (P) are 2 and 29, respectively, and since both are less than S2 = 30, transfer is permitted. As a result, the user K and the user L are recorded in the ticket owner change history table 1143 as the second owner by the process S705.

[2-3: When validating a ticket]
Based on the flow of FIGS. 8 and 9, a ticket validation determination is made. By the processing S901, it can be seen that the ticket “MNO5” has been transferred to the user K and the ticket “MNO6” has been transferred to the user L. Therefore, according to the algorithm shown in FIG. 10, as shown in FIG. 11, an additional point (AP) is added to each of the user K and the user L. For user C, 2 additional points (AP) are added.

As a result, as shown in FIG. 11, the new ticket owner change history point (nP) of the user K is 3, and the user L who is reselling from the normal is 30. Therefore, in the process S802 of FIG. 8, the ticket “MNO6” that has passed through the user L whose (nP) is S3 = 30 or more is invalidated in the process S803, and the ticket “MNO6” is displayed in the ticket owner change history table 1143 of FIG. The ticket valid / invalid flag 604 is set to “invalid”. On the other hand, the ticket validation / invalidation flag 604 of the ticket “MNO5” via the user K is set to “validation”.

According to the above example, in the first embodiment, even if the ticket transfer source (user C) performs an appropriate transfer, the ticket transfer destination user (user L) performs an inappropriate resale. It turns out that the ticket which passed through the user who is performing improper resale can be invalidated. Further, when an appropriate user (user K) receives a transfer, the ticket is validated.

[Case 2-4: Subsequent purchase and transfer of new ticket]
For the user L, since the ticket owner change history point (P) in the purchaser information table 1141 is 30 or more, as with the user A, new purchase or transfer of the ticket cannot be performed. For users C and K, the ticket owner change history point (P) is less than 30, so there is no particular limitation.

[Case 3: When there is no relocation]
Case 3 is a pattern in which all the tickets are validated without any problem since the owner of the two tickets owned by the first owner user D has not been changed to anyone.

As for user D (user ID “1114”), two ticket IDs “MNP2” and “MNQ3” have been purchased as shown in the ticket owner change history table 1143 in FIG. Absent. In this case, there is no change in the ticket owner change history point (P) according to the flow of FIGS.

In the first embodiment, when a ticket is transferred, in principle, an additional point (AP) is given to a user who passes the ticket. However, there may be good reasons for relocation. If addition points (AP) are also given to these, the addition points are accumulated, so that consideration may be desirable.

The processing for determining validity / invalidity of a ticket in the second embodiment basically follows the processing flow of FIGS. 8 and 9 of the first embodiment. However, a function is added to the process S903 for calculating an addition point (AP) for each user. Therefore, only the additional function part different from the first embodiment will be described below.

FIG. 12 is a flowchart showing details of the process S903 of the second embodiment. Here, for the sake of explanation, it will be described as processing for one ticket. When there are a plurality of target tickets, the process is repeated for each ticket to calculate (AP). When there are a plurality of tickets related to a certain user, the sum of the (AP) of the plurality of tickets is calculated in step S904 (P ).

In process S1201, the ticket validation determination unit 1124 refers to the ticket owner change history table 1143 and checks whether the target ticket has a second owner. If there is no second owner, it is determined in step S1202 that there is no transfer, and no additional points (AP) are added to the ticket in accordance with the rule described with reference to FIG.

In process S1203, the ticket validation determination unit 1124 refers to the ticket owner change history table 1143 to determine whether the target ticket is one of a plurality of tickets purchased by the same user. At this time, conditions may be set for a plurality of ticket types and purchase time zones. If it is not one of a plurality of purchases, that is, if it is the one purchased, one addition point (AP) is calculated based on the rule described in FIG. 10 in step S1206. .

In process S1204, the ticket validation determining unit 1124 refers to the ticket owner change history table 1143, and determines whether one of the plurality of purchases by the first owner is still owned by the first owner. Determine if. If no ticket remains for the first owner, an additional point (AP) is calculated in step S1206 based on the rules described in FIG.

In process S1205, the ticket validation determination unit 1124 refers to the ticket owner change history table 1143 to determine whether a ticket other than that owned by the first owner has been transferred two or more times. If there is at least one ticket that has been transferred two or more times, an additional point (AP) is calculated based on the rules described in FIG. 10 in step S1206.

If there is no ticket transferred more than once, no additional points (AP) are added in step S1202.

According to the above processing, for example, if you purchase multiple tickets for a companion, leave only your ticket, transfer the rest to the companion, and use the ticket with your companion, add Points (AP) are not added. On the other hand, in the case where an unauthorized reseller purchases a large number of tickets for resale, leaves a part for his / her resale, and transfers the rest to another reseller, an additional point can be added.

The algorithm of FIG. 10 and FIG. 12 is an example of a determination method, but improper transfer is performed when various conditions are combined using the transfer history recorded for each ticket as in this embodiment. Users can be narrowed down.

[Case 4: Example of user B and user J in the second embodiment]
In Case 4, the user B (user ID “1112”) shown in the purchaser information table 1141 in FIG. 3 receives one of the purchased tickets (ticket IDs “MNQ1” and “MNQ2”) as the user J (user An example of transferring to ID “1120”) will be described.

In the present embodiment, an example is shown in which the ticket reservation server effectively activates the function for a target ticket purchased on the date of January 1, 2016, which is purchased by the user B. In the present embodiment, a certain number S1, S2, S3 is set to 30, and a certain time zone for performing ticket validation determination is 0:00 on January 1, 2016, which is the day of ticket use. It is assumed that the user B and the user J are not involved in the purchase of tickets other than the target ticket in this example and the change of the ticket owner.

In this case, consider an example where user B uses ticket ID “MNQ1” by himself and transfers ticket ID “MNQ2” to user J. This is the case where family members and friends who go to a concert are purchased at the same time and other than their tickets are transferred to the accompanying person.

The case above is a typical pattern of legitimate ticket transfer. In the first embodiment, as illustrated in FIG. 11, addition points (AP) are also added to the user B and the user J. Therefore, in such a case, it is preferable to perform exception processing so that the ticket owner change history point (P) does not increase in the processing for determining validity / invalidity of a ticket. Hereinafter, the processing performed by the ticket validation determination unit 1124 of the ticket reservation server 1100 will be described.

In Case 4, the owner of one of the two tickets owned by the first owner User B is changed to User J, but the owner has not been changed multiple times, so no points are added. This is a pattern in which all tickets are activated.

[Case 4-1: When purchasing a new ticket]
When the user B purchases a new ticket, the ticket reservation server 1100 refers to the “ticket owner change history point (P)” 3008 of the user B from the purchaser information table 1141 of FIG. Since point (P) is 5, user B's ticket purchase is permitted. The purchased ticket is added as new data (ticket IDs “MNQ1” and “MNQ2”) to the ticket information table 1142 and the ticket owner change history table 1143.

[Case 4-2: When a ticket is transferred]
User B (user ID “1112”) leaves the ticket of “MNQ1” out of the two tickets “MNQ1” and “MNQ2”, and passes the ticket of “MNQ2” to user J (user ID “1120”). Move to. User B and user J are going to go to a concert together with this ticket.

At the time of determination of relocation, the ticket owner change history point (P) of user J is referred to by the determination based on the flow of FIG. 7, and (P) of user J is 12 as seen in FIG. Therefore, the transfer is permitted and the ticket owner change history table 1143 is updated.

[4-3: When validating a ticket]
At the time of ticket validation determination, referring to the ticket owner change history table 1143 in FIG. 6 based on the determination based on the flow in FIG. 12, the ticket “MNQ1” does not have a second owner, so processing S1202 Therefore, there is no addition point (AP).

The ticket of “MNQ2” has been transferred to the user J, but it can be seen that it is one of a plurality of purchases in the determination in the process S1203, and the other one remains in the hand of the user B in the determination in the process S1204. Since it can be seen that it has been transferred only once by the determination in step S1205, there is no addition point (AP) addition.

FIG. 13 shows an example of a calculation table 11000 (2) for calculating an addition point (AP) in the second embodiment. Through the processes of FIGS. 8, 9, and 12, the ticket reservation server 1100 does not newly add additional points (AP) to the user B and the user J, as indicated by the arrows in the figure, and the new ticket owner. The change history point (nP) 1104 does not change. That is, the ticket reservation server 1100 keeps the “ticket owner change history points (P)” 3008 of the users B and J of the purchaser information table 1141 as they are.

In the ticket validation determination, the ticket owner change history points (nP) of the users B and J are confirmed based on the process S802 in FIG. These are 5 and 12, respectively, as shown in FIG. 13, and since S3 = less than 30, MNQ1 and MNQ2 are all validated, and validation and invalidation are written in the “ticket validation / invalidation flag” of the ticket owner change history table. .

[Case 4-4: Subsequent purchase of new ticket or relocation]
As can be seen from the description of the above case 4, in a specific case, it is possible to configure such that addition points (AP) are not added in consideration of the ticket history. For this reason, the user B and the user J do not suffer from the disadvantage due to the increase of the points (P) at the time of subsequent new ticket purchase and transfer.

In the above embodiment, when the ticket owner change history point (P) exceeds the thresholds S1, S2, and S3, the purchase or transfer is prohibited. Processing may be performed.

According to the embodiment described above, the ticket owner change history is linked to the ticket owner's biometric information from the time of ticket purchase to the time of ticket validation, and is used as the ticket owner change history point (P). When the ticket is validated, if the point (P) is smaller than a predetermined value, the ticket is validated. If the point (P) is larger than the predetermined value, the ticket is not validated. The point (P) generally increases as the change history increases. In addition, since the point (P) is associated with the user by, for example, biometric information, not only a ticket for a certain event but also other performances are inherited for each user. A user with biometric information that is regularly reselling is managed as a user with “high point (P)” even in other events. Therefore, the ticket is valid in other events as unauthorized resale is repeated. It becomes difficult to be done. That is, a ticket that is not activated is resold or used, and as a result, there is an effect of preventing unauthorized resale.

The present invention is not limited to the above-described embodiment, and includes various modifications. For example, a part of the configuration of one embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of one embodiment. Further, it is possible to add, delete, and replace the configurations of other embodiments with respect to a part of the configurations of the embodiments.

It can be used for an electronic ticket management system using an electronic computer.

Claims

A processing device, a storage device, and an interface for input and output;
The storage device stores a ticket owner change history indicating in time series which of the users owns the ticket for each ticket,
The processing device calculates, for each user, a point reflecting the ticket owner change history,
The storage device records the points in association with the user,
The processing device responds to a request received via the interface based on the point,
(1) at least one restriction on purchase and transfer of the ticket of the user corresponding to the point that satisfies a specific condition; and
(2) Restriction of use of the ticket owned by the user corresponding to the point that satisfies a specific condition;
A ticket management system that does at least one of the following.
When the processing device calculates a point reflecting the ticket owner change history for each user, for each ticket,
“Non-final users are given N points if they start from that user and then go through N people” and “final user gives the same points as the first user” Calculate based on algorithm,
The ticket management system according to claim 1.
A ticket management method using a processing device, a storage device, and a server having an interface for input and output,
A first step in which the storage device stores a ticket owner change history indicating in time series which of the users owns the ticket for each ticket;
A second step in which the processing device calculates, for each user, a point reflecting the ticket owner change history;
A third step in which the storage device records the points in association with the user;
A fourth step in which the interface accepts a predetermined request made by identifying the user and the ticket;
A fifth step in which the processing device refers to the point corresponding to the user specified in the fourth step and determines whether or not to permit the predetermined request;
Execute the ticket management method.
In the second step, for each ticket,
The point is calculated based on an algorithm of “for a certain user, when the user is the starting point, and thereafter N points are given if N users are routed”,
The ticket management method according to claim 3.
In the second step, for each ticket,
Calculating by adding an exception algorithm that “the end user gives the same point as the first user”,
The ticket management method according to claim 4.
In the second step, for each ticket,
“However, the ticket is one of a plurality of tickets purchased by the same user, and at least one of the plurality of tickets remains owned by the same user, and of the plurality of tickets. If even one of the images has not been transferred more than once, the calculation is performed by adding an exception algorithm that `` sets the granted points to zero '',
The ticket management method according to claim 5.
The second step includes
Performed in a batch process with respect to a plurality of tickets associated with predetermined time information,
The ticket management method according to claim 3.
The fourth step includes
Receiving a purchase request for the predetermined ticket by the predetermined user;
The fifth step includes
Referring to the point corresponding to the predetermined user and rejecting the purchase request when the point is greater than or equal to a threshold value S1;
The ticket management method according to claim 3.
The fourth step includes
Receiving a transfer request for the predetermined ticket by the predetermined user;
The fifth step includes
Referring to the point corresponding to the predetermined user, and rejecting the transfer request when the point is greater than or equal to a threshold S2.
The ticket management method according to claim 3.
The fourth step includes
Use or activation of the predetermined ticket by the predetermined user,
The fifth step includes
Referring to the points corresponding to all users who own the ticket, and rejecting the use or activation when at least one of the points is a threshold S3 or more;
The ticket management method according to claim 3.