JP7846738B2 - Ticket management server and program - Google Patents

Description

This invention relates to a ticket management server used in a ticket management system that monitors tickets used for entry to events and the like.

In recent years, with the widespread adoption of smartphones and other mobile devices, an electronic ticketing system has been proposed that distributes electronic tickets (digitized versions of admission tickets) to these devices. The system then verifies the electronic ticket stored on the visitor's device at the entrance to determine whether or not they are allowed entry.

For example, Patent Document 1 discloses an electronic ticketing system that uses a stamp capable of simultaneous multi-point contact on a smartphone screen to perform a redemption process for an electronic ticket, marking it as used based on the electronic ticket and the corresponding stamp.

Japanese Patent Publication No. 2015-5275

While electronic ticketing systems like those described above are becoming more common, there is still room for improvement in terms of fraud prevention and convenience. For example, effectively preventing the illegal resale of tickets (so-called scalping) is essential. Furthermore, when transferring tickets to individuals who do not possess a multi-functional device capable of installing a dedicated application (e.g., a smartphone), it is necessary to provide instructions for using the tickets on devices that cannot install the application, or to issue paper tickets. Preventing fraudulent use and issuance of these paper tickets is also crucial.

This invention was made to solve the above-mentioned problems and aims to provide an improved ticket management system.

To solve the above problems, a ticket management system according to one embodiment of the present invention comprises a control unit, a database that stores ticket IDs and user telephone numbers in association with each other, and a communication unit that can communicate with the user's terminal via a network. The control unit determines whether an incoming call has been received from the user telephone number associated with the ticket ID of the ticket to a predetermined ticketing telephone number that can receive calls via the communication unit. If the determination conditions, including the fact that an incoming call has been received from the user telephone number associated with the ticket ID of the ticket to the ticketing telephone number, are met, the control unit causes the ticketing device to issue the ticket.

In this invention, the control unit, upon receiving notification from the communication unit that a ticket issuance start operation has been performed on the user terminal, may determine whether or not an incoming call has been received from the user telephone number associated with the ticket ID of the ticket to a predetermined ticket issuance telephone number that can be received by the communication unit.

In this invention, the communication unit comprises a network communication unit capable of communicating with the user's terminal and ticketing device via a network, and a telephone communication unit capable of communicating with the user terminal via a telephone line. The control unit, upon receiving notification via the network communication unit that a ticketing initiation operation has been performed on the user terminal, determines whether, within a predetermined valid operation time after the ticketing initiation operation, an incoming call was received from the user's telephone number associated with the ticket ID of the ticket to a predetermined ticketing telephone number that can receive calls via the telephone communication unit. If the control unit satisfies the determination conditions, including the fact that an incoming call was received from the user's telephone number associated with the ticket ID of the ticket to the ticketing telephone number within the valid operation time, it sends a command to the ticketing device to issue the ticket.

In this invention, the communication unit comprises a network communication unit capable of communicating with the user's terminal via a network and a telephone communication unit capable of communicating with the user terminal via a telephone line. The control unit, upon receiving notification via the network communication unit that a ticket issuance start operation has been performed on the user's terminal, determines whether, within a predetermined valid operation time after the ticket issuance start operation, an incoming call has been received from the user's telephone number associated with the ticket ID of the ticket to a predetermined ticket issuance telephone number that can be received by the telephone communication unit. If the determination conditions, including the fact that an incoming call has been received from the user's telephone number associated with the ticket ID of the ticket to the ticket issuance telephone number within the valid operation time, are met, the control unit outputs data-embedded audio containing ticket issuance information from the user's terminal speaker, and the ticketing device issues the ticket based on the data-embedded audio output from the user's terminal. The ticket issuance information embedded in the data-embedded audio may include the printed content of the ticket being issued.

In this invention, the data-embedded audio may be transmitted to the user terminal via voice call over a telephone line. Alternatively, the data-embedded audio may be transmitted to the user terminal via live streaming over a network. Alternatively, the data-embedded audio may be transmitted to the user terminal via a network as an audio data file containing the data-embedded audio.

In this invention, upon initiating the ticketing process, identification information indicating which of multiple ticketing devices should be used to issue the ticket is received. If the determination conditions are met, the ticketing device corresponding to the received identification information is instructed to print the ticket.

In this invention, the ticket management server prompts the user's terminal to access a first site before the ticket issuance start operation. In response to the user's terminal accessing the first site, the server records access history information to the first site. To perform the ticket issuance start operation, the server prompts the user's terminal to access a second site. In response to the user's terminal accessing the second site, the server obtains access history information to the first site from the user's terminal. The determination conditions in the control unit's judgment may include the condition that the access history recorded on the user's terminal when accessing the first site matches the access history obtained from the user's terminal when accessing the second site.

In this invention, the ticket management server prompts the user's terminal to access a first site before the ticket issuance start operation. In response to the user's terminal accessing the first site, it obtains first user agent information indicating the user agent used to access the first site from the user's terminal. To perform the ticket issuance start operation, it prompts the user's terminal to access a second site and obtains second user agent information indicating the user agent used by the user's terminal to access the second site. The determination criteria in the control unit's determination may include the condition that the first user agent information and the second user agent information match.

A ticket management server according to another embodiment of the present invention comprises a control unit, a database that stores ticket IDs and user telephone numbers associated with each other, a network communication unit capable of communicating with the user's terminal via a network, and a telephone communication unit capable of communicating with the user's terminal via a telephone line. Upon receiving notification via the network communication unit that the user's terminal has initiated owner registration for a ticket, the control unit determines whether, within a predetermined valid operation time after the owner registration initiation operation, an incoming call has been received from the user's telephone number associated with the ticket ID of the ticket to a predetermined registration telephone number that can receive calls via the telephone communication unit. If the determination conditions, including the fact that an incoming call has been received from the user's telephone number associated with the ticket ID of the ticket to the registration telephone number within the valid operation time, are met, the control unit displays the ticket as usable on the user's terminal.

In this invention, upon initiating the owner registration process, the registration telephone number is sent to the user's contact information.

In this invention, multiple candidate telephone numbers are provided as registration telephone numbers, and upon initiating owner registration, one of the multiple candidate telephone numbers is notified to the user's contact information as the registration telephone number.

In this invention, the ticket management server prompts the user's terminal to access the first site before the owner registration start operation. In response to the user's terminal accessing the first site, the server records access history information to the first site. To perform the owner registration start operation, the server prompts the user's terminal to access the second site. In response to the user's terminal accessing the second site, the server obtains access history information to the first site from the user's terminal. The determination conditions in the control unit's judgment may include the condition that the access history recorded on the user's terminal when accessing the first site matches the access history obtained from the user's terminal when accessing the second site.

In this invention, the ticket management server prompts the user's terminal to access a first site before the owner registration initiation operation. In response to the user's terminal accessing the first site, the server obtains first user agent information indicating the user agent used to access the first site from the user's terminal. To perform the owner registration initiation operation, the server then prompts the user's terminal to access a second site and obtains second user agent information indicating the user agent used to access the second site. The determination criteria in the control unit's decision-making process may include the condition that the first user agent information and the second user agent information match.

To solve the above problems, the program according to the embodiment of the present invention may function as one of the above-mentioned ticket management servers on a computer.

This is a schematic diagram showing the configuration of ticket management system 1. This is a block diagram showing the configuration of Server 2. This is a block diagram showing the configuration of the ticket issuing device 3. This is a block diagram showing the configuration of user terminal 4. This is a flowchart showing the steps for receiving your ticket. This is a flowchart showing the procedure for registering ownership. This flowchart shows the procedure for using tickets electronically. This is a flowchart showing the procedure for issuing paper tickets. This is a flowchart showing the procedure for electronically transferring tickets. This is a flowchart showing the procedure for issuing paper tickets in the second embodiment. This is a flowchart showing the procedure for issuing paper tickets in the third embodiment.

The embodiments of the present invention will be described below with reference to the drawings.

[Basic configuration of the ticket management system]
As shown in Figure 1, the ticket management system 1 according to the first embodiment of the present invention consists of a server 2, a plurality of ticket issuing devices 3, and a plurality of user terminals 4. The server 2, the ticket issuing devices 3, and the user terminals 4 are connected via a network NW such as the Internet. The server 2 and the user terminals 4 are also connected to a telephone line network TL.

[Server Configuration]
Server 2 is, for example, a computer system, and consists of an input/output device such as a keyboard, mouse, and touch panel, a main unit equipped with an arithmetic unit such as a CPU (Central Processing Unit) and storage devices such as RAM (Random Access Memory) and ROM (read-only memory), and a display device such as a CRT (Cathode Ray Tube) or LCD (Liquid Crystal Display).

As shown in Figure 2, Server 2 comprises at least a storage unit 201, a control unit 202, a network communication unit 203, and a telephone communication unit 204. The storage unit 201 of Server 2 stores programs executed by the control unit 202, as well as data used by those programs. For example, the storage unit 201 stores programs for realizing the functions of Server 2 in the ticket management system 1, a database DB related to electronic tickets managed by the ticket management system 1, and programs for payment processing. Server 2 does not necessarily have to be physically integrated with all of the above components. For example, some or all of the above components may be distributed to remote locations, and they can work together to function as Server 2.

The database (DB) stores information related to electronic tickets, including ticket information (e.g., unique ticket ID, event ID, ticket type, seat number, redemption key, purchaser's user ID, status (used/unused, etc.), ticket image, etc.), user information (e.g., unique user ID, name, age, telephone number (user telephone number), address, gender, other attributes, contact information, etc.), and event information (e.g., event ID, event name, date and time, venue, etc.). In this embodiment, a mobile phone number and contact information are required as user information. This contact information should be a contact method (e.g., email address, SNS) that allows information to be sent and received via the user terminal 4. One ticket ID is associated with one user ID and one event ID. By identifying the ticket ID, information about the user who purchased the ticket and information about the event that the ticket can be used for entry can be identified. If a single user purchases multiple tickets for the same event, multiple ticket IDs with the same event ID will be associated with that single ticket ID.

The control unit 202 of server 2 executes processing according to the program stored in the storage unit 201 based on requests and other information transmitted from the user terminal 4. For example, the control unit 202 performs processes such as searching, adding, deleting, and updating data in the database DB stored in the storage unit 201, and communicates with the ticketing device 3, user terminal 4, etc., via the network communication unit 203 and the network NW. Furthermore, the control unit 202 controls the telephone communication unit 204 to obtain the incoming telephone number and transmit necessary voice messages over the telephone line.

[Configuration of the ticketing device]
The ticket issuing device 3 prints ticket information on a predetermined form and issues it based on a command from the server 2. As shown in Figure 3, the ticket issuing device 3 includes at least a storage unit 301, a control unit 302, a communication unit 303, a printing unit 304, a display unit 305, a microphone 306, and a camera 307.

The memory unit 301 stores programs executed by the control unit 302, as well as data used by those programs. For example, the memory unit 301 stores programs that control the printing unit 304 to print ticket information based on commands from the server 2, and programs that control the display unit 305 to display the ticket machine number and various screens based on commands from the server 2. In a ticket management system 1 equipped with multiple ticketing devices 3, each ticketing device 3 is assigned a ticketing device number to identify it, and each ticketing device 3 stores its own ticketing device number in the control unit 302. The ticketing device number may also be a ticketing telephone number individually assigned to each ticketing device 3.

The control unit 302 executes various programs stored in the memory unit 301. For example, the control unit 302 controls the printing unit 304 to print tickets in response to commands from the server 2, and controls the display content of the display unit 305.

The communication unit 303 communicates with the server 2 via the network NW. The communication unit 303 may also be configured to enable near-field communication (NFC), infrared communication, visible light communication, etc. The printing unit 304 is a printer that prints tickets on predetermined paper. The ticket paper may be, for example, pre-cut to predetermined dimensions and perforated as needed, or it may be roll paper that is cut to a predetermined length each time printing is required.

The display unit 305 is a display element such as a liquid crystal display, and displays the ticket machine number, which is an identification number for identifying the ticketing device 3, as well as various notifications and guidance screens. Alternatively, the ticket machine number may be displayed on a label or the like, either in place of the display unit 305 or in conjunction with the display unit 305. The microphone 306 accepts voice input.

[User terminal configuration]
The user terminal 4 is, for example, a tablet or a smartphone, and is equipped with a touch panel, a processing unit such as a CPU, a storage device such as RAM or ROM, a display device such as an LCD, a speaker that outputs sound, a microphone that collects sound, and so on.

As shown in Figure 4, the user terminal 4 comprises at least an operation unit 401, a storage unit 402, a control unit 403, a communication unit 404, a display unit 405, a microphone 406, and a speaker 407.

The operation unit 401 receives user input. The operation unit 401 includes a touch panel superimposed on the display unit 405, and other buttons. The storage unit 402 stores programs executed by the control unit 403, data used by those programs, etc. For example, the storage unit 402 stores the operating system (OS), application programs for the ticket management system 1, data on purchased electronic tickets used by these application programs, user information, etc.

A dedicated application software may be used as the application program for using the ticket management system 1, but a more general-purpose browser or messenger application may also be used. When using a browser or messenger application (hereinafter referred to as "browser, etc."), it is preferable to configure the system so that the user terminal 4 accesses the server 2 using the browser, etc., and retrieves and displays data related to purchased electronic tickets from the server 2's database DB as needed. In the embodiments described below, the explanation assumes that a browser, etc., is used as the application program for using the ticket management system 1.

The control unit 403 executes various programs, including a browser, stored in the memory unit 402. The browser accesses a specified URL to display a website, and, as will be detailed later, performs processing based on various data stored in the memory unit 402 and operations performed by the operation unit 401.

The communication unit 404 communicates with the server 2 via the network NW. The communication unit 404 also performs voice calls using the telephone network TL. Note that the network NW and the telephone network TL may be the same.

The display unit 405 is a display element such as a liquid crystal display, and under the control of the control unit 403, it displays various information (the face of the electronic ticket). The display unit 405 works in cooperation with the touch panel of the operation unit 401 to realize various input interfaces.

[Basic operation of the ticket management system]
This section explains the basic process of a user purchasing and using a ticket using the ticket management system 1 configured as described above.

[Purchasing and receiving tickets]
Users purchase tickets for their desired event from ticket vendors (e.g., ticket shops, ticket terminals, online ticketing sites, etc.). At this time, users select various conditions such as the event, seat type, number of seats, and ticket delivery method, and then proceed with the payment process. If electronic tickets are selected as the ticket delivery method, users will use the ticket management system via their mobile device. The following describes the ticket delivery process when electronic tickets are selected, referring to the flowchart shown in Figure 5.

Once payment for the purchased ticket is complete, the ticket seller sends the ticket ID of the purchased ticket and the user ID of the user who purchased the ticket to server 2, which receives them (step S100). Server 2 then records the user ID received from the seller as the user ID of the purchaser associated with the ticket ID received from the seller (step S110). Server 2 also sends a receiving URL for the purchased ticket to the user terminal 4 to the contact information (email address, SNS account, etc.) associated with the user ID (step S120). Note that the system may be configured to require the input of a ticket number, phone number, etc., before receiving the ticket. Access to this receiving URL is managed by server 2.

The user receives the ticket (step S130) by accessing the receiving URL sent from server 2 in step S120 using the browser on user terminal 4. This allows the user to use the ticket via the browser on user terminal 4. At this time, predetermined identification information is recorded as history information (so-called Cookie) indicating that the receiving URL was accessed in the browser of user terminal 4 used to access the receiving URL. Server 2 records the purchaser's user ID and the Cookie in association. Furthermore, server 2 records information regarding the user agent (hereinafter referred to as "UA information"), indicating the model, browser, OS, etc. of user terminal 4 that accessed the receiving URL, in association with the purchaser's user ID.

In this embodiment of the ticket management system, tickets that have not been registered as owner-registered will not be usable. Therefore, users who purchase tickets must register as owner-registered using the procedure described below.

[Owner Registration]
Figure 6 is a flowchart showing the procedure for owner registration. When a user uses user terminal 4 to launch a browser or the like and access the ticket management system site, the performances for which tickets have already been purchased are displayed for selection (step S200). If the user selects a desired ticket from these, and the ticket owner registration has not been completed, the ticket image and an owner registration screen for registering the ticket are displayed (step S210). Access to this owner registration screen is managed by server 2. The user accesses the displayed owner registration screen. At this time, user terminal 4 sends UA information of the browser used for access and cookie information left in the browser when accessing the receiving URL to receive the ticket to server 2 (step S220). In addition, server 2 notifies the user of the registration telephone number in response to access to the owner registration screen (step S230). The method of notifying the user may be to send the registration telephone number to the user's contact information, or to display it on a web page that the user can view using user terminal, etc. This registration phone number can be a landline number, but it may also be possible to send a different number each time it is displayed, by selecting one number from several candidate phone numbers.

Next, the user terminal 4 displays an authentication button on the display unit 405 to initiate the owner registration process (step S235). When the user presses the authentication button, the server 2 records the press time, linking it to the ticket ID (step S240). Authentication button B1 is an example of the owner registration initiation operation in this invention. Furthermore, in response to the authentication button being pressed, the user terminal 4 displays the registration telephone number received in step S220 (step S245). Alternatively, instead of sending the registration telephone number from the server 2 to the user terminal 4 in step S230, the registration telephone number may be sent from the server 2 to the user terminal 4 in response to the authentication button being pressed and displayed on the display unit 405.

Next, Server 2 determines whether a call was made to the registered telephone number from the user's telephone number (usually the user terminal 4) associated with the ticket within a predetermined valid operation time (for example, within 4 seconds) from the time the button was pressed (Step S250). This valid operation time should be short enough that it would be difficult for a third party in a remote location to make a call by transmitting the ticketing telephone number and performing the call remotely.

In step S250, Server 2 determines whether a call was made to the registered telephone number from the user telephone number associated with the ticket (usually the user terminal 4) within a predetermined valid operation time (for example, within 4 seconds) from the time of pressing the button, as follows: Server 2 receives the call to the registered telephone number via the telephone communication unit 204. The telephone communication unit 204 then identifies the originating telephone number and the dialed telephone number (one of the candidate telephone numbers). Server 2 identifies the ticket ID based on the dialed telephone number and determines whether a call was made to the registered telephone number within the valid operation time by confirming that the ticket ID is one whose press time was recorded within the period preceding the time of receiving the call by the valid operation time.

If a call is not made to the registered telephone number within the valid operation time from the time of pressing the button (step S250; No), the owner registration will not be completed. A screen notifying the user that owner registration could not be completed will be displayed on the display unit 405 of the user terminal 4 (step S260), and the owner registration process will end. It is advisable to configure the system to provide a notification if the caller's telephone number differs by only one character from the user's telephone number recorded on the ticket, or if the first character is missing, or if other input errors are suspected. This makes it easy for users to realize that they have registered the wrong telephone number and prompts them to correct it.

On the other hand, if a call is made to the registered telephone number within the valid operation time from the time of pressing the button (step S250; Yes), Server 2 performs a verification process (step S270). In the verification process, the telephone number of the purchaser associated with the ticket ID is extracted from the database DB and verified against the number that was called in step S250. In addition, Server 2 verifies the Cookie information and UA information recorded when the purchaser accessed the receiving URL associated with the user ID against the Cookie information and UA information sent from the user terminal 4 in step S220. If the verification process does not confirm a match between the pieces of information (step S270; No), the owner registration is not performed, and a screen notifying the user that owner registration could not be performed is displayed on the user terminal 4 (step S260), and the owner registration process ends. On the other hand, if the matching process confirms a match in the information (step S270; Yes), server 2 records in the database DB that the owner registration for the ticket has been completed and makes the ticket available for use on the user terminal 4 (step S280). Thereafter, when the user terminal 4 launches a browser or similar application to access the ticket management system site and displays the ticket, it will be displayed in a usable state.

According to the owner registration process described above, tickets cannot be used unless the person who purchased them registers them as the owner, thus deterring fraudulent transfers and resales.
[Use of electronic tickets]

As described above, electronic tickets managed by ticket management system 1 become usable after owner registration. As explained below, tickets can be used electronically or as printed paper tickets.

Figure 7 is a flowchart illustrating an example of the processing procedure for the ticket management system 1 when a ticket with registered ownership is used electronically (i.e., displayed on the user terminal 4 without issuing a paper ticket). The user, having already completed the ownership registration described above, launches the browser on the user terminal 4 and accesses the ticket URL to display the electronic ticket. This displays the electronic ticket on the display unit 405 of the user terminal 4 (step S300), which the user then presents to the attendant at the entrance. Access to the ticket URL is managed by the server 2. When the user terminal 4 accesses the ticket URL, it sends the UA information of the browser used for access and the Cookie information left in the browser when accessing the receiving URL to receive the ticket to the server 2.

The staff member visually confirms that the electronic ticket for the event in question is indeed for that event, and then performs a "cancellation" operation to mark the ticket as used (for example, by performing a predetermined operation on the touch panel of the user terminal 4) (step S310). When the user terminal 4 receives the cancellation operation, it overlays text or an image indicating that the ticket has been used (hereinafter referred to as "postmark information") onto the ticket and sets the status of the ticket to "used" (step S320). The user terminal 4 also notifies the server 2 that the ticket has been used at an appropriate time (it may be immediately after verification or after some time has passed), and the server 2 also sets the status of the ticket to "used" (step S330) and terminates the process. It is recommended that the user terminal 4, upon receiving the cancellation operation, verify whether the cancellation operation is correct, and only mark the ticket as used if it is correct; otherwise, it should issue a warning or notification. In addition to verifying the redemption operation, the Cookie information and UA information transmitted from the user terminal 4 in step S300 may also be verified against the Cookie information and UA information recorded in association with the user ID of the ticket holder. In the above example, redemption was performed by receiving a redemption operation from the user terminal 4, but redemption may be performed by other methods. For example, the display unit 405 of the user terminal 4 could display an identification code (e.g., a QR code (registered trademark), etc.) along with the ticket image, and this code could be read at the entrance and verified with the server 2, allowing the server 2 to perform the redemption process.

[Issuance of paper tickets]
On the other hand, the ticket management system 1 also allows purchased tickets to be issued and used as paper tickets. Paper tickets can be issued by permanently installing the ticketing device 3 in a ticket shop or similar location, allowing tickets to be issued in advance of the performance, or by installing the ticketing device 3 near the entrance to the performance, allowing tickets to be issued immediately before entry. The procedure for issuing paper tickets using the ticket management system 1 will be explained below with reference to the flowchart shown in Figure 8.

Prior to ticket issuance, the user launches a browser or similar application on user terminal 4 and accesses the ticket URL. Access to the ticket URL is managed by server 2. When user terminal 4 accesses the ticket URL, it sends the user agent information of the browser used for access, as well as the cookie information left in the browser when accessing the ticket receipt URL, to server 2. The processing steps up to this point are the same as when using tickets electronically.

When the user accesses the URL on the ticket, the display unit 405 of the user terminal 4 will show the ticket image along with a paper ticket issuance button. Pressing this paper ticket issuance button (step S400) will start the ticket issuance process. Upon starting the issuance process, the ticket will be rendered unusable, untransferable, and no further tickets can be issued.

In step S400, when the user presses the paper ticket issuance button, a screen prompting the user to enter the ticket machine number is displayed on the user terminal 4. When the user enters the ticket machine number displayed on the display unit 305 into the user terminal 4, the user terminal 4 transmits the ticket machine number to the server 2 (step S410). Pressing the paper ticket issuance button is an example of the ticket issuance start operation in this invention. Upon receiving the ticket machine number, the server 2 transmits a ticketing telephone number to the user terminal 4, which the user terminal 4 receives (step S420). At this time, the server 2 records the ticket ID of the ticket to be issued and the ticketing telephone number linked together. The ticketing telephone number may be a fixed telephone number, but it may also be a different number each time it is displayed, by transmitting one number selected from multiple candidate telephone numbers. Note that in a configuration where the ticketing telephone number is individually assigned to each ticketing device 3 as the ticket machine number, steps S410 and 420 can be omitted, and the ticketing process can be started simply by calling the ticketing telephone number displayed on the display unit 305. Therefore, paper tickets can be issued even from devices that cannot install a dedicated application.

Next, the user terminal 4 displays the ticketing telephone number received in step S420 and a verification start button to initiate verification for issuing paper tickets on the display unit 405 (step S430). Note that the ticketing telephone number transmitted and displayed in steps S420 and S430 may be configured to be displayed on the display unit 305 of the ticketing device 3 instead of the display unit 405 of the user terminal 4. When the user presses the verification start button, the server 2 records the press time and associates it with the ticket ID (step S440).

Next, Server 2 determines whether a call was made to the ticketing telephone number from the user's telephone number (usually the user terminal 4) recorded in the ticket, within a predetermined valid operation time (for example, within 4 seconds) from the time the button was pressed (step S450). This valid operation time should be short enough that it would be difficult to transmit the ticketing telephone number to a remote location and have someone remotely make the call.

In step S450, Server 2 determines whether a call was made to the ticketing telephone number from the user telephone number associated with the ticket (usually the user terminal 4) within a predetermined valid operation time (for example, within 4 seconds) from the time of pressing the button, as follows: Server 2 receives the call to the ticketing telephone number via the telephone communication unit 204. The telephone communication unit 204 then identifies the originating telephone number and the dialed telephone number (one of the candidate telephone numbers). Server 2 identifies the ticket ID based on the dialed telephone number and confirms whether the ticket ID is one whose press time was recorded within the period preceding the valid operation time from the time of receiving the call, thereby determining whether a call was made to the ticketing telephone number within the valid operation time.

If the ticketing telephone number is not called within the valid operation time from the time of pressing the button (step S450; No), the ticket will not be issued. A screen notifying the user that the ticket cannot be issued will be displayed on the display unit 405 of the user terminal 4, and the ticket will be returned to a usable state (step S460), ending the ticketing process. It is advisable to configure the system to provide a notification if the originating telephone number differs by only one character from the user's telephone number recorded with the ticket, or if the first character is missing, or if other input errors are suspected. This makes it easy for users to realize that their telephone number has been registered incorrectly and prompts them to correct it.

On the other hand, if a call is made to the ticketing telephone number within the valid operation time from the time of pressing the button (step S450; Yes), Server 2 performs a verification process (step S470). In the verification process, the user telephone number associated with the ticket ID is extracted from the database DB and verified against the number that received the call in step S450. Server 2 also verifies the Cookie information and UA information recorded in association with the ticket holder's user ID against the Cookie information and UA information transmitted from the user terminal 4 when accessing the ticket URL. If the verification process fails to confirm a match (step S470; No), the ticket will not be issued. A notification screen informing the user that the ticket cannot be issued is displayed on the display unit 405 of the user terminal 4, and the ticket is returned to a usable state (step S460), thus ending the ticketing process.

On the other hand, if the information matches during the verification process (step S470; Yes), the server 2 records in the database DB that a paper ticket has been issued for that ticket, and sends a command to the ticketing device 3 corresponding to the ticketing machine number received in step S420 to print the ticket from the printing unit 304 (step S480). The ticketing device 3 receives this command, prints the ticket using the printing unit 304 (step S490), and terminates the ticketing process.

As described above, it is possible to issue paper tickets. In the ticketing process of this embodiment, verification is performed using telephone number, cookie information, UA information, etc., at the time of issuance. This prevents the issuance of fraudulent tickets, such as those obtained by performing the necessary verification operations remotely. The discovered paper tickets can be used at the event entrance in the same way as conventional paper tickets.

[Issuance of ticket stub]
The above-described paper ticket issuance process can be applied not only to issuing unused paper tickets, but also to issuing stubs of used tickets after entry using electronic tickets. It is advisable to redeem tickets at the entrance of the event venue, and then issue stubs after verification using a telephone number, cookie, UA, etc., following the same procedure as the above-described ticket issuance process. In this case, the ticket issuing device 3 should be installed inside the venue (for example, immediately after passing through the entrance). In this way, when multiple people enter using electronic tickets together, stubs can be issued to attendees who do not have a user terminal 4 as proof of seat number information or for re-entry. It is also possible to issue paper stubs in case the battery level of the user terminal 4 is low. Furthermore, when the user terminal 4 redeems electronic tickets, if there are multiple tickets being used simultaneously or if the battery level falls below a predetermined threshold, it is advisable to prompt the user to issue paper stubs by displaying a message on the display unit 405 or emitting a notification sound.

[Ticket Transfer]
The ticket management system 1 makes it possible to transfer the tickets it manages from the owner to another person.

Ticket transfers can be done either electronically by having the recipient re-register as the ticket holder, or by issuing and delivering a paper ticket.

[Electronic ticket transfer]
Referring to the flowchart in Figure 9, the procedure for electronically transferring tickets will be explained. In this method, the user transferring the ticket first accesses the ticket URL, having already completed the owner registration described above, to display the ticket to be transferred. Then, they press the recipient registration button displayed along with the ticket (step S600). When this recipient registration button is pressed, a screen prompting the user to enter the recipient's phone number is displayed on the user terminal 4. When the recipient's phone number is entered on this screen (step S610), that phone number is sent to the server 2 along with the ticket ID and recorded in the database DB linked to the ticket ID (step S620). Furthermore, the user transferring the ticket is disabled in their browser, etc. (step S630).

When Server 2 receives the ticket ID and the recipient's phone number, it issues an owner registration URL that allows the recipient to access the owner registration screen and complete the owner registration process. This URL is then sent to the original user's contact information (email address, SNS, etc.) (Step S640). The original user forwards this owner registration URL to the recipient (Step S650). Alternatively, the owner registration URL may be sent directly from Server 2 to the recipient without going through the original user.

The recipient user receives the URL sent in step S650 using their user terminal 4 (step S660). The recipient user then registers as the owner in the same way as in steps S200 to S280 of the owner registration process at the time of purchase (Figure 6). Server 2 determines whether the recipient user has successfully completed the owner registration within a predetermined period (step S670). If it is determined that the registration has been successfully completed (step S670; Yes), the recipient user is recorded as the owner of the ticket in the server 2 database DB, and the original user ceases to be the owner. The ticket then becomes available for use on the recipient user's user terminal 4 (step S680). On the other hand, if the recipient user does not successfully complete the owner registration, for example, if the registration is not completed within the predetermined transfer validity period (step S670; No), Server 2 deletes the recipient's phone number from the database DB and makes the ticket available for use on the original user's user terminal 4 (step S690).

As described above, tickets can be transferred electronically. By requiring the same owner registration as at the time of purchase when transferring tickets electronically, the ticket management system 1 can track both the transferor and the recipient, thereby deterring fraudulent transfers and resales.

[Transfer of paper tickets]
On the other hand, the method of issuing and handing over paper tickets involves the user, who is the owner, issuing the ticket using the ticket issuing device 3 and then handing over the issued ticket to the recipient. The issuance of paper tickets should be implemented in the same way as when using paper tickets as described above. Furthermore, even when transferring paper tickets, configuring the system to require owner registration before issuing the paper ticket can deter fraudulent transfers and resales. In this case, configuring the system to print the name of the registered owner on the surface of the issued paper ticket can be particularly effective in deterring fraudulent transfers and resales.

[Second Embodiment]
The ticket management system according to the second embodiment of the present invention differs from the first embodiment in its method of issuing paper tickets. Specifically, in the second embodiment, the procedure is the same as the first embodiment up to the verification step (step S450 in Figure 8), but after successful verification, the procedure for issuing paper tickets from the ticketing device 3 and the hardware configuration related to this procedure differ.

Figure 10 is a flowchart showing the procedure for ticket issuance by the ticketing device 3 in the second embodiment. Prior to ticket issuance, the user launches a browser on the user terminal 4 and accesses the ticket URL. Access to the ticket URL is managed by the server 2. When the user terminal 4 accesses the ticket URL, it sends the UA information of the browser used for access and the cookie information left in the browser when accessing the receiving URL to receive the ticket to the server 2.

When the user accesses the URL on the ticket, the display unit 405 of the user terminal 4 will show the ticket image along with a paper ticket issuance button. Pressing this paper ticket issuance button (step S700) will start the ticket issuance process. Upon commencement of the issuance process, the ticket will be rendered unusable, untransferable, and no further tickets can be issued.

In step S700, when the user presses the paper ticket issuing button, a screen prompting the user to enter the ticket issuing machine number is displayed on the user terminal 4. When the user enters the ticket issuing machine number displayed on the display unit 305 into the user terminal 4, the user terminal 4 transmits the ticket issuing machine number to the server 2 (step S710). Pressing the paper ticket issuing button is one example of the ticket issuance start operation in this invention. Upon receiving the ticket issuing machine number, the server 2 transmits a ticket issuing telephone number to the user terminal 4 (step S720). This ticket issuing telephone number may be a fixed telephone number, but it may also be a different number each time it is displayed, selected from multiple candidate telephone numbers.

Next, the user terminal 4 displays the ticketing telephone number received in step S720 and a verification start button on the display unit 405 to initiate verification for issuing paper tickets (step S730). When the user presses the verification start button, the server 2 records the time of the press (step S740).

Next, Server 2 determines whether a call was made to the ticketing telephone number from the user's telephone number (usually the user terminal 4) recorded in association with the ticket, within a predetermined valid operation time (for example, within 4 seconds) from the time the button was pressed (step S750). This valid operation time should be short enough that it would be difficult to transmit the ticketing telephone number to a remote location and have someone remotely make the call.

In step S750, Server 2 determines whether a call was made to the ticketing telephone number from the user telephone number associated with the ticket (usually the user terminal 4) within a predetermined valid operation time (for example, within 4 seconds) from the time of pressing the button, as follows: Server 2 receives the call to the ticketing telephone number via the telephone communication unit 204. The telephone communication unit 204 then identifies the caller's telephone number and the dialed telephone number (one of the candidate telephone numbers). Server 2 identifies the ticket ID based on the dialed telephone number and confirms whether the ticket ID is one whose press time was recorded within the period preceding the valid operation time from the time of receiving the call, thereby determining whether a call was made to the ticketing telephone number within the valid operation time.

If the ticketing telephone number is not called within the valid operation time from the time of pressing the button (step S750; No), the ticket will not be issued. A screen notifying the user that the ticket cannot be issued will be displayed on the display unit 405 of the user terminal 4, and the ticket will be returned to a usable state (step S760), ending the ticketing process. It is advisable to configure the system to provide a notification if the originating telephone number differs by only one character from the user's telephone number recorded with the ticket, or if the first character is missing, suggesting an input error. This makes it easy for users to realize they have registered an incorrect telephone number and prompts them to correct it.

On the other hand, if a call is made to the ticketing telephone number within the valid operating time (step S750; Yes), server 2 performs a verification process (step S770). In the verification process, the user telephone number associated with the ticket ID is extracted from the database DB and compared with the number that received the call in step S750. Server 2 also compares the Cookie information and UA information recorded in association with the ticket holder's user ID with the Cookie information and UA information transmitted from the user terminal 4 when accessing the ticket URL. If the information does not match during the verification process (step S770; No), the ticket will not be issued. A notification screen informing the user that the ticket cannot be issued will be displayed on the display unit 405 of the user terminal 4, and the ticket will be returned to a usable state (step S760), thus ending the ticketing process.

On the other hand, if the matching process confirms that the information matches (step S770; Yes), the server 2 initiates a voice call on the phone received in step S750 using the telephone communication unit 204 (step S780). The telephone communication unit 204 then transmits data-embedded voice to the user terminal 4 using the voice call, containing information for printing tickets on the ticketing device 3 (hereinafter referred to as "ticketing information"). It is preferable that the voice call be disconnected after a predetermined call time has elapsed. Here, the ticketing information may include all the data on the ticket face, or it may include only the encrypted ticket ID as needed. If the ticketing information includes only the ticket ID, the ticketing device 3 may receive data linking the ticket ID and the data on the ticket face from the server 2 in advance and store it in the storage unit 301. Alternatively, each time ticketing information is received, the ticketing device 3 may query the server 2 for the ticket face data corresponding to the ticket ID and receive it via the network NW. Furthermore, the ticketing information may include the ticketing machine number entered in step S710. Additionally, the ticketing information may include timestamp information indicating the time of the ticketing process, such as the time the button was pressed and the time the ticketing telephone number was dialed, as recorded in step S740.

The user holds the speaker 407 of the user terminal 4 over the microphone 306 of the ticketing device 3, inputting the data-embedded audio into the microphone 306 (step S800). The ticketing device 3 decodes the audio input into the microphone 306 and obtains the ticketing information (step S810). Then, the ticketing device 3 determines whether the received ticketing information is valid or not (step S820).

Whether the received ticketing information is valid can be determined, for example, as follows: If the ticketing information includes a ticketing machine number, the condition for determining validity should include a match between the ticketing machine number of the ticketing device 3 to which the data-embedded voice was input and the ticketing machine number included in the ticketing information. Furthermore, if the ticketing information includes a timestamp, the condition for determining validity should include a match between the current time and the predetermined ticketing validity period indicated by the timestamp information. The ticketing validity period should be a time (e.g., 3 minutes) that makes it difficult to record the data-embedded voice and send it to a remote location via a network. Additionally, the condition may include a requirement that the voice was input within a predetermined time after the information match was confirmed in the verification process. Other conditions for determining validity may include the inclusion of information indicating that verification in step S780 was performed in the ticketing information.

If the received ticketing information is valid (Step S820; Yes), the ticketing device 3 prints the ticket using the printing unit 304 and sends information indicating that the ticket has been issued, such as the result of the determination in Step S820, to the server 2 (Step S830). Upon receiving this, the server 2 records in the database DB that a paper ticket has been issued for that ticket (Step S840) and terminates the ticketing process.

On the other hand, if the received ticketing information is invalid (step S820; No), the ticketing device 3 displays a message on the display unit 305 indicating that the ticket cannot be issued, and transmits information to the server 2 indicating that the ticket was not issued, such as the result of the decision in step S840 (step S850). Upon receiving this, the server 2 returns the ticket to a usable state (step S860) and terminates the ticketing process.

As described above, by transmitting ticketing information from the user terminal 4 to the ticketing device 3 via data-embedded voice during the issuance of paper tickets, even if a remote call is successfully made during verification, the data-embedded voice necessary for ticketing cannot be transmitted to the ticketing device 3. Therefore, the issuance of fraudulent tickets can be more effectively deterred.

[Modified version of the second embodiment]
In the second embodiment described above, data-embedded audio was transmitted from the server 2 via a voice call over a telephone line TL and received by the user terminal 4. However, the data-embedded audio may be transmitted to the user terminal 4 by a method other than a voice call over a telephone line TL and output from the speaker 407 of the user terminal 4. For example, the data-embedded audio may be transmitted from the server 2 via live streaming over a network NW and received by the user terminal 4, and then output from the speaker 407 by streaming playback on the user terminal 4. Alternatively, the data-embedded audio may be transmitted as an audio data file over a network NW, received by the user terminal 4, and then output from the speaker 407 by playing the audio data file on the user terminal 4. With these methods, the data-embedded audio is not degraded during the transmission process from the server 2 to the user terminal 4, making it less likely for errors to occur in the transmission of ticketing information.

Furthermore, in a configuration where data-embedded audio is transmitted as an audio data file via a network (NW), the system may be configured to restrict the transfer of the received audio data file by the user terminal 4, or to restrict playback of the audio data file on other terminals. For example, the audio data may be linked to cookie information used during ticketing or session information for data communication via the network (NW), allowing playback of the audio data file only on the user terminal 4 used for ticketing.

[Third Embodiment]
The ticket management system according to the third embodiment of the present invention differs from the first embodiment in its method of issuing paper tickets. Specifically, in the second embodiment, the procedure is the same as the first embodiment up to the verification step (step S450 in Figure 8), but after successful verification, the procedure for issuing paper tickets from the ticketing device 3 and the hardware configuration related to this procedure differ.

Figure 11 is a flowchart showing the procedure for ticket issuance by the ticketing device 3 in the third embodiment. Prior to ticket issuance, the user launches a browser on the user terminal 4 and accesses the ticket URL. Access to the ticket URL is managed by the server 2. When the user terminal 4 accesses the ticket URL, it sends the UA information of the browser used for access and the cookie information left in the browser when accessing the receiving URL to receive the ticket to the server 2.

When the user accesses the URL on the ticket, the display unit 405 of the user terminal 4 will show the ticket image along with a paper ticket issuance button. Pressing this paper ticket issuance button (step S900) will start the ticket issuance process. Upon starting the issuance process, the ticket will become unusable, untransferable, and no further tickets can be issued.

In step S900, when the user presses the paper ticket issuing button, a screen prompting the user to enter the ticket issuing machine number is displayed on the user terminal 4. When the user enters the ticket issuing machine number displayed on the display unit 305 into the user terminal 4, the user terminal 4 transmits the ticket issuing machine number to the server 2 (step S910). Pressing the paper ticket issuing button is one example of the ticket issuance start operation in this invention. Upon receiving the ticket issuing machine number, the server 2 transmits a ticket issuing telephone number to the user terminal 4 (step S920). This ticket issuing telephone number may be a fixed telephone number, but it may also be a different number each time it is displayed, by transmitting one number selected from multiple candidate telephone numbers.

Next, the user terminal 4 displays the ticketing telephone number received in step S720 and a verification start button on the display unit 405 to initiate verification for issuing paper tickets (step S930). When the user presses the verification start button, the server 2 records the time of the press (step S940).

Next, Server 2 determines whether a call was made to the ticketing telephone number from the user's telephone number (usually the user terminal 4) associated with the ticket, within a predetermined valid operation time (for example, within 4 seconds) from the time the button was pressed (step S950). This valid operation time should be short enough that it would be difficult to transmit the ticketing telephone number to a remote location and have someone remotely make the call.

In step S950, Server 2 determines whether a call was made to the ticketing telephone number from the user telephone number associated with the ticket (usually the user terminal 4) within a predetermined valid operation time (for example, within 4 seconds) from the time of pressing the button, as follows: Server 2 receives the call to the ticketing telephone number via the telephone communication unit 204. The telephone communication unit 204 then identifies the originating telephone number and the dialed telephone number (one of the candidate telephone numbers). Server 2 identifies the ticket ID based on the dialed telephone number and confirms whether the ticket ID is one whose press time was recorded within the period preceding the valid operation time from the time of receiving the call, thereby determining whether a call was made to the ticketing telephone number within the valid operation time.

If the ticketing telephone number is not called within the valid operation time from the time of pressing the button (step S950; No), the ticket will not be issued. A screen notifying the user that the ticket cannot be issued will be displayed on the display unit 405 of the user terminal 4, and the ticket will be returned to a usable state (step S960), ending the ticketing process. It is advisable to configure the system to provide a notification if the originating telephone number differs by only one character from the user's telephone number recorded with the ticket. This makes it easy for users to realize that their telephone number has been registered incorrectly and prompts them to correct it.

On the other hand, if a call is made to the ticketing telephone number within the valid operating time (step S950; Yes), server 2 performs a verification process (step S970). In the verification process, the user telephone number associated with the ticket ID is extracted from the database DB and compared with the number that received the call in step S950. Server 2 also compares the Cookie information and UA information recorded in association with the ticket holder's user ID with the Cookie information and UA information transmitted from the user terminal 4 when accessing the ticket URL. If the information does not match during the verification process (step S970; No), the ticket will not be issued. A notification screen informing the user that the ticket cannot be issued will be displayed on the display unit 405 of the user terminal 4, and the ticket will be returned to a usable state (step S960), thus ending the ticketing process.

On the other hand, if the matching process confirms that the information matches (step S970; Yes), the server 2 transmits an identification code (barcode, QR code (registered trademark), etc.) and displays it on the display unit 405 of the user terminal 4 (step S980). The identification code transmitted by the server 2 may include the data on the ticket face, or it may contain only the encrypted ticket ID as needed. If only the ticket ID is included, the ticketing device 3 may receive data linking the ticket ID and the data on the ticket face from the server 2 in advance and store it in the storage unit 301. Alternatively, each time the identification code is read, the ticketing device 3 may query the server 2 for the ticket face data corresponding to the ticket ID and receive it via the network NW. The identification code may also include information such as a URL indicating the location of the information necessary for issuing the ticket on the network NW. The identification code may also include the ticketing machine number entered in step S910. Furthermore, the identification code may include timestamp information indicating the time of the ticketing process, such as the time the button was pressed and the time the ticketing telephone number was dialed, as recorded in step S940. The identification code should be configured so that it disappears from the display unit 405 of the user terminal 4 after a predetermined time has elapsed.

The user holds the display unit 405 of the user terminal 4 over the camera 307 of the ticket issuing device 3, allowing the ticket issuing device 3 to read the identification code (step S990). The ticket issuing device 3 then determines whether the read identification code is valid or not (step S1020).

Whether a received identification code is valid can be determined, for example, as follows: If the identification code includes a ticket machine number, the condition for determining its validity should include that the ticket machine number of the ticketing device 3 that read the identification code matches the ticket machine number included in the identification code. Furthermore, if the identification code includes timestamp information, the condition for determining its validity should include that the current time falls within the predetermined ticketing validity period from the time indicated in the timestamp information. Additionally, the condition may include that the identification code was read within a predetermined time after the information match was confirmed in the verification process. Other conditions for determining its validity may include that the ticketing information includes information indicating that verification in step S980 was performed.

If the read identification code is valid (Step S1020; Yes), the ticketing device 3 prints the ticket using the printing unit 304 and sends information indicating that the ticket has been issued based on the determination in Step S1020 to the server 2 (Step S1030). Upon receiving this, the server 2 records in the database DB that a paper ticket has been issued for that ticket (Step S1040) and terminates the ticketing process.

On the other hand, if the read identification code is not valid (step S1020; No), the ticketing device 3 displays a message on the display unit 305 indicating that the ticket cannot be issued, and transmits information to the server 2 indicating that the ticket was not issued as a result of the decision in step S1040 (step S1050). Upon receiving this, the server 2 returns the ticket to a usable state (step S1060) and terminates the ticketing process.

As described above, when issuing a paper ticket, the identification code displayed on the user terminal 4 is read by the ticketing device 3. Therefore, even if a remote call is successfully made during verification, the identification code necessary for ticket issuance cannot be transmitted to the ticketing device 3, thus more effectively deterring the issuance of fraudulent tickets.

While embodiments of the present invention have been described above, the present invention is not limited to these examples. Furthermore, any additions, deletions, or design modifications of components to the aforementioned embodiments, or combinations of features from each embodiment, as appropriate by those skilled in the art, are also included within the scope of the present invention, as long as they retain the essence of the invention.

1 Ticket management system 2 Server 3 Ticket issuing device 4 User terminal NW Network TL Telephone network

Claims (4)

An information processing device comprising a control unit,
The control unit,
The steps include receiving a notification that an authentication operation for the ticket has been performed on the user's terminal , and storing the time the said operation was performed ,
A database that stores information that can identify the ticket in association with the user's user telephone number, a step of determining whether an incoming call from the user telephone number associated with the ticket to a predetermined authentication telephone number occurred within a predetermined time from the stored operation time ,
An information processing device that performs the step of allowing the user to use the ticket if an incoming call from the user's telephone number associated with the ticket to the authentication telephone number occurs within a predetermined time from the stored operation time . A program for operating a computer equipped with a processor, wherein the program is configured to operate the processor,
The steps include receiving a notification that an authentication operation for the ticket has been performed on the user's terminal , and storing the time the said operation was performed ,
A database that stores information that can identify the ticket in association with the user's user telephone number, a step of determining whether an incoming call from the user telephone number associated with the ticket to a predetermined authentication telephone number occurred within a predetermined time from the stored operation time ,
A program that, if an incoming call from the user's telephone number associated with the ticket to the authentication telephone number occurs within a predetermined time period from the stored operation time , causes the program to make the ticket available to the user. A method to be performed on a computer having a processor, wherein the processor
The steps include receiving a notification that an authentication operation for the ticket has been performed on the user's terminal , and storing the time the said operation was performed ,
A database that stores information that can identify the ticket in association with the user's user telephone number, a step of determining whether an incoming call from the user telephone number associated with the ticket to a predetermined authentication telephone number occurred within a predetermined time from the stored operation time ,
A method of performing the steps of enabling the user to use the ticket if an incoming call from the user's telephone number associated with the ticket to the authentication telephone number occurs within a predetermined time period from the stored operation time . A means for receiving notification that an authentication operation for a ticket has been performed on the user's terminal , and for storing the time the said operation was performed ,
A database that stores information that can identify the ticket in association with the user's user telephone number, includes means for determining whether an incoming call from the user telephone number associated with the ticket to a predetermined authentication telephone number occurred within a predetermined time from the stored operation time .
A system comprising means for allowing the user to use the ticket if an incoming call from the user's telephone number associated with the ticket to the authentication telephone number occurs within a predetermined time period from the stored operation time .