[go: up one dir, main page]

WO2018142587A1 - Système et procédé de gestion de ticket - Google Patents

Système et procédé de gestion de ticket Download PDF

Info

Publication number
WO2018142587A1
WO2018142587A1 PCT/JP2017/004039 JP2017004039W WO2018142587A1 WO 2018142587 A1 WO2018142587 A1 WO 2018142587A1 JP 2017004039 W JP2017004039 W JP 2017004039W WO 2018142587 A1 WO2018142587 A1 WO 2018142587A1
Authority
WO
WIPO (PCT)
Prior art keywords
ticket
user
point
points
change history
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2017/004039
Other languages
English (en)
Japanese (ja)
Inventor
友香 西脇
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to PCT/JP2017/004039 priority Critical patent/WO2018142587A1/fr
Priority to JP2018565207A priority patent/JP6707673B2/ja
Publication of WO2018142587A1 publication Critical patent/WO2018142587A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits

Definitions

  • 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. .
  • 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.
  • 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.
  • a ticket can be easily canceled or reissued by referring to a ticketing history recorded in a ticketing history recording unit.
  • 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.
  • 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.
  • 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.
  • 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.
  • tickets can be managed effectively.
  • FIG. 1 is a configuration block diagram of an example of a ticket reservation system 1000.
  • 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.
  • 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.
  • 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.
  • the target of this embodiment is an electronic ticket for an event such as a concert.
  • 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.
  • 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.
  • 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.
  • FIG. 2 is a processing flowchart when a user newly registers in the ticket reservation system.
  • 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.
  • 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.
  • 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.
  • solid arrows indicate the flow of processing
  • 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.
  • 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.
  • transfer resale or transfer
  • 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.
  • the ticket purchase processing unit 1122 of the ticket reservation server 1100 Will be described.
  • the ticket reservation server 1100 receives "biological information”, “user ID”, and “password” input by the user on the login screen via the terminal 1200.
  • the ticket reservation server 1100 selects the user as the user. Identify as A and allow login.
  • 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.
  • 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.
  • 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.
  • 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.
  • process S405 the fact that the ticket cannot be purchased is transmitted to the terminal 1200 of user A, and the process is terminated.
  • 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.
  • 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.
  • data of “MNO1”, “MNO2”, “MNO3”, “MNO4”, and “MNP1”, which are IDs corresponding to the five tickets purchased by the user A, are generated.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 7 is a flowchart when the ticket owner is changed.
  • 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”).
  • the transfer of the electronic ticket is performed, for example, by transferring ticket ID data from the user A to the user E.
  • the ticket owner change determination unit 1123 of the ticket reservation server 1100 This will be described as processing to be performed.
  • 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.
  • 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.
  • 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.
  • 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.
  • process S704 the fact that the ticket cannot be transferred is transmitted to user E's terminal 1200, and the process is terminated.
  • 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.
  • a confirmation process may be performed before the ticket owner change history table update process S705.
  • 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.
  • 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.
  • 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.
  • the change of owner for each ticket is stored in the ticket owner change history table 1143 as a history.
  • 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.
  • 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.
  • P ticket owner update history point
  • nP new ticket owner update history point
  • (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.
  • 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.
  • 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.
  • 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.
  • the calculation rule is based on the following two rules.
  • Rule 2 The final user has the same number of points as the first purchaser.
  • 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.
  • the additional points (AP) of users who are often involved in tickets with a large number of transfers are increased.
  • the addition point (AP) is 0.
  • the additional points (AP) of primary resellers who are involved in a large number of tickets and resell each ticket become very large.
  • the person who uses the resold ticket also increases the points added.
  • 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.
  • 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
  • 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.
  • 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.
  • the target ticket is invalidated when even one user whose (nP) is equal to or greater than the threshold value S3 passes.
  • the target ticket is validated when none of the users whose (nP) is the threshold value S3 or more pass through.
  • 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.
  • the ticket reservation server 1100 desirably notifies the user terminal 1200 that the ticket has been invalidated at an appropriate timing.
  • (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.
  • (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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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. .
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the ticket valid / invalid flag 604 is set to “invalid”.
  • the ticket validation / invalidation flag 604 of the ticket “MNO5” via the user K is set to “validation”.
  • the ticket transfer destination user 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 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.
  • an additional point is given to a user who passes the ticket.
  • AP addition points
  • 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.
  • the process is repeated for each ticket to calculate (AP).
  • the sum of the (AP) of the plurality of tickets is calculated in step S904 (P ).
  • 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.
  • 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. .
  • AP addition point
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the processing performed by the ticket validation determination unit 1124 of the ticket reservation server 1100 will be described.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • It can be used for an electronic ticket management system using an electronic computer.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

La présente invention réalise une gestion efficace de tickets. Le système de gestion de ticket selon l'invention est pourvu d'un dispositif de traitement, d'un dispositif de stockage et d'une interface d'entrée et de sortie. Dans ce système, le dispositif de stockage stocke un historique de changement de propriétaire de ticket qui indique des données de série temporelle pour chaque ticket selon lequel des utilisateurs ont possédé le ticket. Le dispositif de traitement calcule, pour chacun des utilisateurs, des points qui reflètent l'historique de changement de propriétaire du ticket. Le dispositif de stockage enregistre les points et l'utilisateur correspondant en association les uns aux autres. En réponse à une demande reçue par le biais de l'interface, le dispositif de traitement, selon les points, impose (1) une restriction sur l'achat de ticket et/ou le transfert de ticket par un utilisateur correspondant aux points qui satisfont à une condition spécifique, et/ou (2) une restriction sur l'utilisation d'un ticket possédé par l'utilisateur correspondant aux points qui satisfont à la condition spécifique.
PCT/JP2017/004039 2017-02-03 2017-02-03 Système et procédé de gestion de ticket Ceased WO2018142587A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/JP2017/004039 WO2018142587A1 (fr) 2017-02-03 2017-02-03 Système et procédé de gestion de ticket
JP2018565207A JP6707673B2 (ja) 2017-02-03 2017-02-03 チケット管理システムおよびチケット管理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2017/004039 WO2018142587A1 (fr) 2017-02-03 2017-02-03 Système et procédé de gestion de ticket

Publications (1)

Publication Number Publication Date
WO2018142587A1 true WO2018142587A1 (fr) 2018-08-09

Family

ID=63039461

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/004039 Ceased WO2018142587A1 (fr) 2017-02-03 2017-02-03 Système et procédé de gestion de ticket

Country Status (2)

Country Link
JP (1) JP6707673B2 (fr)
WO (1) WO2018142587A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190043040A1 (en) * 2017-08-07 2019-02-07 Skidata Ag Method for preventing the misuse of electronic access permissions, which can be managed in mobile electronic devices using a wallet application and which are transmitted to the mobile electronic devices by a server, in each case using a link for downloading the access permission
JPWO2022014223A1 (fr) * 2020-07-13 2022-01-20
JP7262163B2 (ja) 2017-02-07 2023-04-21 ｐｌａｙｇｒｏｕｎｄ株式会社 興行品質制御装置、興行品質制御方法、及びプログラム

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000090168A (ja) * 1998-09-16 2000-03-31 Nec Corp Ｉｃカードチケットシステムおよびｉｃカードチケットの製造方法
JP2009043007A (ja) * 2007-08-08 2009-02-26 Csk Systms Corp ポイント管理装置、投資金額算定装置、運用管理装置、及び、ポイント管理プログラム
JP2009301513A (ja) * 2008-06-17 2009-12-24 Excite Music Entertainment Japan Co Ltd 抽選装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000090168A (ja) * 1998-09-16 2000-03-31 Nec Corp Ｉｃカードチケットシステムおよびｉｃカードチケットの製造方法
JP2009043007A (ja) * 2007-08-08 2009-02-26 Csk Systms Corp ポイント管理装置、投資金額算定装置、運用管理装置、及び、ポイント管理プログラム
JP2009301513A (ja) * 2008-06-17 2009-12-24 Excite Music Entertainment Japan Co Ltd 抽選装置

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7262163B2 (ja) 2017-02-07 2023-04-21 ｐｌａｙｇｒｏｕｎｄ株式会社 興行品質制御装置、興行品質制御方法、及びプログラム
US20190043040A1 (en) * 2017-08-07 2019-02-07 Skidata Ag Method for preventing the misuse of electronic access permissions, which can be managed in mobile electronic devices using a wallet application and which are transmitted to the mobile electronic devices by a server, in each case using a link for downloading the access permission
US20230342756A1 (en) * 2017-08-07 2023-10-26 Skidata Ag Method for preventing the misuse of electronic access permissions, which can be managed in mobile electronic devices using a wallet application and which are transmitted to the mobile electronic devices by a server, in each case using a link for downloading the access permission
US12008546B2 (en) 2017-08-07 2024-06-11 Skidata Gmbh Method for preventing the misuse of electronic access permissions, which can be managed in mobile electronic devices using a wallet application and which are transmitted to the mobile electronic devices by a server, in each case using a link for downloading the access permission
JPWO2022014223A1 (fr) * 2020-07-13 2022-01-20
WO2022014223A1 (fr) * 2020-07-13 2022-01-20 合同会社Ｈ．Ｕ．グループ中央研究所 Procédé de traitement d'informations
JP7705398B2 (ja) 2020-07-13 2025-07-09 合同会社Ｈ．Ｕ．グループ中央研究所 情報処理方法

Also Published As

Publication number Publication date
JPWO2018142587A1 (ja) 2019-06-27
JP6707673B2 (ja) 2020-06-10

Similar Documents

Publication Publication Date Title
JP7216770B2 (ja) チケットシステム、プログラム、および方法。
CN113077253B (zh) 便携式电子装置、计算机可读介质及个人信息管理方法
JP6723233B2 (ja) データ許可を制御する方法及び装置
JP2007529802A (ja) 同一実行のための人物識別制御方法及びシステム
US20150081346A1 (en) Event ticket sharing via networked mobile computing devices
CN107949860A (zh) 用于管理事件访问权限的系统和方法
JP6707673B2 (ja) チケット管理システムおよびチケット管理方法
JP7230120B2 (ja) サービス提供システム、サービス提供方法、及びプログラム
KR20250008411A (ko) 토큰을 이용한 투표 시스템 및 방법
JP7177303B1 (ja) サービス提供システム、サービス提供方法、及びプログラム
US20190066146A1 (en) Premium giving system, recording medium having stored premium giving program, and premium giving method
JP2020095590A (ja) チケット譲渡装置、チケット譲渡方法及びプログラム
CN119213732B (zh) 针对基于网络的交换的网络级用户验证
JP7271778B2 (ja) サービス提供システム、サービス提供方法、及びプログラム
CN111507826A (zh) 手机号与银行账户关联时保证幂等性的方法及装置
WO2021009969A1 (fr) Système de gestion de traitement, dispositif de gestion de traitement, procédé de gestion de traitement et programme d'ordinateur
JP6583460B2 (ja) 認証システム
JP7165840B1 (ja) 不正検知システム、不正検知方法、及びプログラム
WO2020261425A1 (fr) Système de déduction de fraude, procédé de déduction de fraude et programme
JP7165841B1 (ja) 不正検知システム、不正検知方法、及びプログラム
JP2010020572A (ja) 利用者識別システムおよびその方法
JP7658098B2 (ja) 個人情報管理装置、プログラム及び個人情報管理システム
JP7521185B2 (ja) 決済装置、制御方法、プログラム、及びシステム
JP2010286980A (ja) 情報処理装置、情報処理システム及びプログラム
JP6645081B2 (ja) ポイント管理装置、制御方法及びプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17894994

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2018565207

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17894994

Country of ref document: EP

Kind code of ref document: A1