Ticket system, program, and method

Abstract

To provide a system capable of effectively motivating people to join events.MEANS FOR SOLVING THE PROBLEM: A program provided herein makes a processor of a computer perform steps of detecting the use of a ticket, and granting an ownership-definable token to an owner of the ticket upon detection of the use of the ticket.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to a ticket system, program, and method. [Background technology]

[0002] 2. Description of the Related Art Conventionally, systems for issuing tickets to events have been known. Patent Document 1 discloses a system that encourages ticket purchases by offering benefits to those who purchase tickets to an event. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Publication No. 2020-98645 Summary of the Invention [Problem to be solved by the invention]

[0004] However, in conventional ticket issuing systems, a special benefit is given to the ticket purchaser. For this reason, if the special benefit is highly valuable, for example, a person may purchase a ticket solely to receive the special benefit, and then resell the ticket after receiving the special benefit. In this case, tickets may not be distributed to those who actually want to attend the event, and even if many tickets are sold, the number of attendees at the event venue may decrease. Furthermore, if an attempt is made to solve this problem by offering visitors actual benefits such as souvenirs, there is the problem that managing such items is time-consuming.

[0005] Incidentally, from the standpoint of the event organizer, having a large number of attendees at the event venue brings many direct benefits, such as increased excitement for the event, increased recognition of the event's performers, increased buzz about the event itself, sales promotion for related merchandise, and the acquisition of sponsorship. For this reason, a small number of attendees is not acceptable as long as tickets are sold; a large number of attendees at the event venue is a desirable situation for the event organizer. For this reason, there has been a demand for effective ways to motivate people to participate in the event.

[0006] An object of the present disclosure is to provide a system that can effectively motivate people to participate in an event. [Means for solving the problem]

[0007] A ticket management program according to one aspect of the present disclosure is a program that causes a computer processor to execute the steps of detecting use of a ticket and, in response to the detection of use of the ticket, granting a token whose ownership can be clarified to the owner of the ticket. [Effects of the Invention]

[0008] According to the present disclosure, a system that can effectively motivate people to participate in an event is provided. [Brief explanation of the drawings]

[0009] [Figure 1] 1 is a block diagram showing the configuration of a ticket system according to an embodiment of the present invention; [Figure 2] FIG. 2 is a block diagram showing the configuration of a user terminal according to the present embodiment. [Figure 3] FIG. 2 is a block diagram showing the configuration of a ticket management server according to the present embodiment. [Figure 4] 1 is a block diagram showing the configuration of a ticket inspection system according to an embodiment of the present invention; [Figure 5] 1 is a block diagram showing an example of the configuration of an input device connectable to the ticket inspection system of the present embodiment. FIG. [Figure 6]FIG. 2 is a diagram illustrating the configuration of a token management ledger according to the present embodiment. [Figure 7] FIG. 1 is an explanatory diagram of an overview of the present embodiment. [Figure 8] 3A to 3C are diagrams illustrating examples of data structures of an event database, a user database, and a ticket database stored in a ticket management server. [Figure 9] 10A and 10B are diagrams illustrating an example of the data structure of an account database and a token database stored in an external server. [Figure 10] A figure showing an example of the data structure of a token management ledger. [Figure 11] 10 is a flowchart of a user registration process according to the present embodiment. [Figure 12] 10 is a flowchart of a ticket issuing process according to the present embodiment. [Figure 13] 10 is a flowchart of a ticket inspection process according to the present embodiment. [Figure 14] 10 is a flowchart of a token granting process according to the present embodiment. [Figure 15] 10A and 10B are diagrams illustrating examples of the data structures of a bonus ticket database stored in a ticket management server and an exchange code database stored in an external server. [Figure 16] 10 is a flowchart of a process in which a user redeems a bonus ticket. [Figure 17] 3A and 3B are diagrams showing a first example of a screen and a second example of a screen according to the present embodiment. [Figure 18] 10A and 10B are diagrams showing a third example of a screen and a fourth example of a screen according to the present embodiment. [Figure 19] 10A and 10B are diagrams showing a fifth example screen and a sixth example screen of the present embodiment. [Figure 20] FIG. 10 is a diagram showing the data structure of a token management ledger 40 according to Modification 1. [Figure 21] 10 is a flowchart of a token granting process according to Modification 2. DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings. In the drawings for explaining the embodiment, the same components are generally designated by the same reference numerals, and repeated description thereof will be omitted.

[0011] (1) Ticket System 1 Configuration The following describes the configuration of the ticket system 1. Fig. 1 is a block diagram showing the configuration of the ticket system 1 of this embodiment.

[0012] As shown in FIG. 1, the ticket system 1 includes a user terminal 10, a ticket management server 20, and a ticket inspection system 30. The user terminal 10, the ticket management server 20, and the ticket inspection system 30 are connected via a network (for example, the Internet or an intranet) NW. The ticket system 1 is connected to a token management ledger 40 and an external server 50 via a network NW.

[0013] The user terminal 10 is an information processing device. The user terminal 10 is configured to request ticket information related to a performance from the ticket management server 20. The user terminal 10 can also be called a ticket purchasing terminal. In this respect, the user terminal 10 may be an information processing device owned by the ticket purchaser himself / herself, or may be an information processing device installed at a ticket sales office.

[0014] In the following description, the information processing device may include various computers, such as a smartphone, a tablet terminal, a personal computer, a server computer (e.g., a web server, an application server, a database server, or a combination thereof), a wearable device (e.g., a smart watch or smart glasses), etc. In this embodiment, the user terminal 10 will be described using a smartphone, which is a mobile computer connectable to a network NW, as an example.

[0015] Ticket information is information related to a ticket. Specifically, the ticket information may include information that identifies the ticket, information related to the authority certified by the ticket (e.g., information related to the performance covered by the ticket), the name and feature values ​​(e.g., facial feature values) of the ticket purchaser, information related to the ticket purchaser (e.g., user ID), or a combination thereof, or code information encoding the same (e.g., a QR code (registered trademark) or other one-dimensional or two-dimensional code).

[0016] The ticket may be an image of the ticket information (i.e., an electronic ticket) displayed on the user terminal 10 held by the user, or may be paper or other medium on which the ticket information is printed. Tickets include tickets to participate in various events, tickets to receive various services at stores, tickets to use public transportation such as trains and airplanes, or tickets to watch online events.

[0017] The ticket management server 20 is an information processing device. The ticket management server 20 is configured to issue tickets (i.e., issue ticket information) in response to a request from the user terminal 10. The ticket management server 20 is also configured to manage the issued ticket information.

[0018] For example, when the performance is an event held at various event venues, the ticket inspection system 30 is an information processing device located at a ticket inspection station. The ticket inspection station corresponds to the boundary between the event venue and its external space. The ticket inspection system 30 is configured to refer to the ticket information held on the ticket presented by a person (hereinafter referred to as a "visitor") attempting to enter the event venue, and determine whether the visitor is allowed to enter.

[0019] Here, the event venue may be indoors or outdoors. For example, the target space may be an entertainment venue (e.g., a concert venue, a theater venue, a game venue, an exhibition venue, a store, or a combination thereof), a public transportation facility, an office, or a store.

[0020] Furthermore, when the event is an online event that is made public in a server space, for example, the ticket inspection system 30 is an information processing device that manages access to the event. The ticket inspection system 30 is configured to refer to ticket information held in a ticket presented by a person viewing the online event (hereinafter referred to as a "visitor") and determine whether the visitor is permitted to view the event.

[0021] (1-1) Configuration of the User Terminal 10 The following describes the configuration of the user terminal 10. Fig. 2 is a block diagram showing the configuration of the ticket purchasing terminal of this embodiment.

[0022] 2, the user terminal 10 includes a storage device 11, a processor 12, an input / output interface 13, and a communication interface 14. The user terminal 10 is connectable to at least one of an input device 15 and an output device 16.

[0023] The storage device 11 is configured to store programs and data, and is, for example, a combination of a read-only memory (ROM), a random access memory (RAM), and a storage (for example, a flash memory or a hard disk).

[0024] The programs include, for example, the following programs: OS (Operating System) programs Applications that process information (e.g., web browsers)

[0025] The data includes, for example, the following data: Databases referenced in information processing Data obtained by performing information processing (i.e., the results of performing information processing)

[0026] The processor 12 is configured to implement the functions of the user terminal 10 by running a program stored in the storage device 11. The processor 12 is an example of a computer.

[0027] The input / output interface 13 is configured to receive signals (e.g., user instructions, sensing signals, or a combination thereof) from the input device 15 and output signals (e.g., image signals, audio signals, or a combination thereof) to the output device 16.

[0028] The input device 15 is, for example, a keyboard, a pointing device, a touch panel, a physical button, a sensor (for example, a camera, a vital sensor, or a combination thereof), or a combination thereof.

[0029] The output device 16 is, for example, a display, a speaker, a printing device, or a combination thereof.

[0030] The communication interface 14 is configured to control communication between the user terminal 10 and an external device (for example, at least one of the ticket management server 20, the ticket inspection system 30, the token management ledger 40, or the external server 50).

[0031] (1-2) Configuration of ticket management server 20 The following describes the configuration of the ticket management server 20. Fig. 3 is a block diagram showing the configuration of the ticket management server 20 of this embodiment.

[0032] 3, the ticket management server 20 includes a storage device 21, a processor 22, an input / output interface 23, and a communication interface 24. The ticket management server 20 is connectable to at least one of an input device 25 and an output device 26.

[0033] The storage device 21 is configured to store programs and data, and is, for example, a combination of ROM, RAM, and storage (for example, flash memory or a hard disk).

[0034] The programs include, for example, the following programs: OS programs Application programs that perform information processing

[0035] The data includes, for example, the following data: Databases referenced in information processing - Results of information processing

[0036] The processor 22 is configured to implement the functions of the ticket management server 20 by running a program stored in the storage device 21. The processor 22 is an example of a computer.

[0037] The input / output interface 23 is configured to receive signals (e.g., user instructions, sensing signals, or a combination thereof) from the input device 25 and output signals (e.g., image signals, audio signals, or a combination thereof) to the output device 26.

[0038] The input device 25 is, for example, a keyboard, a pointing device, a touch panel, a sensor, or a combination thereof.

[0039] The output device 26 is, for example, a display, a speaker, or a combination thereof.

[0040] The communication interface 24 is configured to control communication between the ticket management server 20 and an external device (for example, at least one of the user terminal 10, the ticket inspection system 30, the token management ledger 40, or the external server 50).

[0041] (1-3) Configuration of ticket inspection system 30 The following describes the configuration of the ticket inspection system 30. Fig. 4 is a block diagram showing the configuration of the ticket inspection system 30 of this embodiment. Fig. 5 is a block diagram showing an example of the configuration of an input device 35 connectable to the ticket inspection system 30 of this embodiment.

[0042] 4, the ticket inspection system 30 includes a storage device 31, a processor 32, an input / output interface 33, and a communication interface 34. The ticket inspection system 30 is connectable to at least one of an input device 35 and an output device 36.

[0043] The storage device 31 is configured to store programs and data, and is, for example, a combination of ROM, RAM, and storage.

[0044] The programs include, for example, the following programs: OS programs Application programs that perform information processing

[0045] The data includes, for example, the following data: Databases referenced in information processing Data obtained through information processing

[0046] The processor 32 is configured to implement the functions of the ticket inspection system 30 by running a program stored in the storage device 31. The processor 32 is an example of a computer.

[0047] The input / output interface 33 is configured to receive signals (e.g., user instructions, sensing signals, or a combination thereof) from the input device 35 and output signals (e.g., image signals, audio signals, or a combination thereof) to the output device 36.

[0048] The input device 35 is, for example, a keyboard, a pointing device, a touch panel, a sensor (for example, a camera, a vital sign sensor, or a combination thereof), or a combination thereof. As shown in FIG. 5, the input device 35 includes, for example, a visible light camera 352.

[0049] The input device 35, either alone or in cooperation with the processor 32, at least realizes an authentication information acquisition means.

[0050] The authentication information acquisition means reads information (hereinafter referred to as "authentication information") necessary for determining whether or not a visitor is permitted to enter the venue when the visitor presents the ticket. The authentication information includes, for example, at least one of the following: Ticket Information Information about visitor characteristics (e.g., facial features / voiceprint / palmprint)

[0051] A ticket has a ticket information area for reading ticket information, where the ticket information is displayed or printed.

[0052] The authentication information acquisition means can acquire ticket information by combining the visible light camera 352 with an application that analyzes an image captured by the visible light camera 352 to extract an image of ticket information and restores the ticket information from the image of ticket information. When acquiring ticket information, information processing such as OCR (Optical Character Recognition) processing or decoding processing is performed as necessary.

[0053] The authentication information acquisition means can acquire information regarding the facial features of a visitor by combining a visible light camera 352 with an application that analyzes the image taken by the visible light camera 352 to extract an image of the visitor's face and calculates features from the image of the visitor's face.

[0054] The tickets and attendees may be photographed simultaneously or sequentially by the same visible light camera 352, or one may be photographed by the visible light camera 352 and the other by another visible light camera not shown.

[0055] The output device 36 may be, for example, a display, a speaker, an alarm, an electric gate, or a combination thereof.

[0056] The communication interface 34 is configured to control communication between the ticket inspection system 30 and an external device (for example, the user terminal 10, or at least one of the ticket management server 20, the token management ledger 40, or the external server 50).

[0057] (1-4) Configuration of the token management ledger 40 6 is a diagram showing the configuration of the token management ledger 40. The token management ledger 40 is a distributed system that includes signal processing devices 40A to 40E that function as nodes.

[0058] The signal processing devices 40A to 40E are, for example, personal computers connected to a network. In this embodiment, the network may be a LAN, or a public network such as the Internet or a communication network provided by a telecommunications carrier. The signal processing devices 40A to 40E are connected to the network, for example, by wire or wirelessly. The signal processing devices 40A to 40E communicate with each other using a peer-to-peer system.

[0059] The signal processing devices 40A to 40E implement the token management ledger 40 using blockchain technology. Furthermore, among the signal processing devices 40A to 40E, for example, one of the signal processing devices 40A to 40E, the signal processing device 40A, acquires data related to token transactions to be recorded. The signal processing device 40A creates a block including the acquired data and adds it to the blockchain. The signal processing device 40A transmits information about the added block to the other signal processing devices 40A. The other signal processing devices 40B to 40E verify the accuracy of the received block, and if the accuracy is verified, add it to the blockchain. The signal processing devices 40A to 40E finalize the blockchain according to, for example, the number of linked blocks (number of approvals). As a result, the same token management ledger 40 is stored in the signal processing devices 40A to 40E. The stored data may be encrypted as appropriate.

[0060] The configuration of the token management ledger 40 is not limited to that shown in Fig. 6. For example, the number of signal processing devices 40A included in the token management ledger 40 may be any number equal to or greater than two.

[0061] The signal processing device 40A includes a storage device 41, a processor 42, an input / output interface 43, and a communication interface 44. The signal processing device 40A is connectable to at least one of an input device 45 and an output device 46.

[0062] The storage device 41 is configured to store programs and data, and is, for example, a combination of a read-only memory (ROM), a random access memory (RAM), and a storage (for example, a flash memory or a hard disk).

[0063] The programs include, for example, the following programs: OS (Operating System) programs Applications that process information (e.g., web browsers)

[0064] The data includes, for example, the following data: Databases referenced in information processing Data obtained by performing information processing (i.e., the results of performing information processing)

[0065] The processor 42 is configured to implement the functions of the signal processing device 40A by running a program stored in the storage device 41. The processor 42 is an example of a computer.

[0066] The input / output interface 43 is configured to receive signals (e.g., user instructions, sensing signals, or a combination thereof) from the input device 45 and output signals (e.g., image signals, audio signals, or a combination thereof) to the output device 46.

[0067] The input device 45 is, for example, a keyboard, a pointing device, a touch panel, a physical button, a sensor (for example, a camera, a vital sensor, or a combination thereof), or a combination thereof.

[0068] The output device 46 is, for example, a display, a speaker, a printing device, or a combination thereof.

[0069] The communication interface 44 is configured to control communication between the signal processing device 40A and an external device (for example, at least one of the user terminal 10, the ticket management server 20, the ticket inspection system 30, or the external server 50).

[0070] (1-5) Configuration of external server 50 1 includes at least a storage unit and a communication interface. The external server 50 is a storage device realized by, for example, a distributed application (DApp). The storage unit stores digital content that constitutes the token. The external server 50 is managed by, for example, a content management company that manages the digital content. The communication interface is configured to control communication between the external server 50 and an external device (at least one of the user terminal 10, the ticket management server 20, the ticket inspection system 30, or the token management ledger 40). The function of the external server 50 may be realized by the ticket management server 20 .

[0071] (2) Overview of the embodiment An outline of this embodiment will be described below with reference to Fig. 7.

[0072] 7, the ticket inspection system 30 is placed at a ticket inspection station. At the ticket inspection station, a plurality of people are queued up, and tickets are inspected for each person in turn.

[0073] When the visitor TP presents the ticket TC, the visible light camera 352 captures an image of the visitor TP and the ticket TC that are within the imaging range of the visible light camera 352. The ticket inspection system 30 (specifically, the processor 32) acquires ticket information of the ticket TC and feature amounts (e.g., facial feature amounts) of the visitor TP from the image captured by the visible light camera 352.

[0074] Next, the ticket inspection system 30 checks the ticket information and notifies attendees who present appropriate tickets that they are permitted to enter the event, and also notifies the ticket management server 20 of this fact. The ticket management server 20 marks the ticket as used. Marking a ticket as used is also called "torn." That is, if the ticket is for an event held at an event venue, the detection of ticket use is performed by tearing the ticket upon arrival at the event venue. Note that using a ticket refers to a user using a ticket to visit an event venue.

[0075] The ticket inspection system 30 compares the facial features of the visitor TP acquired from the visible light camera 352 with the facial features of the ticket owner stored in advance in the ticket management server 20, and confirms that the ticket owner and user match. If the identity of the ticket owner and user is confirmed, the ticket management server 20 grants a token to the ticket owner.

[0076] That is, the ticket system 1 grants a token with clarified ownership to the owner of a ticket whose use has been detected. A token is data with asset value, and refers to data that is granted to the ticket owner (in other words, the ticket user, i.e., the attendee) as a ticket benefit. In this embodiment, the owner of the token is recorded in the token management ledger 40, which will be described later, making it possible to clarify the ownership. The token of the present invention includes fungible tokens and non-fungible tokens.

[0077] A fungible token refers to data that is treated as an asset equivalent to money, such as virtual currency or points.

[0078] Examples of non-fungible tokens include text data commented on a social networking service (SNS). In this case, the text data itself can be freely copied by a third party. On the other hand, the ownership of the original text data on the SNS remains unchanged even if the text data itself is copied and diverted. Examples of tokens include digital content such as digital images, digital videos, and digital audio files that are given as perks. Such digital content is stored in an external server 50 shown in FIG. 1. In this embodiment, a configuration in which non-fungible tokens are used as tokens will be described as an example.

[0079] The tokens of the present invention can be arbitrarily transferred based on the mutual agreement between users, and may be exchanged for other tokens or may be provided with money or other value.

[0080] In this way, since the ticket system 1 grants tokens to ticket users (attendees), users who wish to receive tokens must not only purchase a ticket but also attend the event venue. This encourages users who want to collect tokens to attend. Furthermore, the ticket system 1 checks the identity of the attendee and the owner, thereby preventing resale, such as acquiring a token by purchasing a ticket and then transferring the ticket to another person.

[0081] (3) Data Structure The databases of this embodiment will now be described. The following databases are stored in the storage device 21 of the ticket management server 20 and the external server 50. However, a copy of at least a portion of the following databases may also be stored in the storage device 31 of the ticket inspection system 30.

[0082] (3-1) Event database An example of the configuration of the event database will be described below. Fig. 8 is a diagram showing an example of the data structure of the event database, user database, and ticket database stored in the ticket management server 20.

[0083] The event database shown in FIG. 8A stores event information. As shown in FIG. 8, the event database includes an "event ID" field, an "event date and time" field, an "event name" field, an "operating company" field, an "performers" field, an "event type" field, and a "token content" field.

[0084] The "Event ID" field stores an event ID. The event ID is information that identifies various events.

[0085] The "Event Date and Time" field stores the event date and time. The event date and time is information indicating the date and time when the event identified by the event ID will be held.

[0086] The "event name" field stores the name of the event. The event name is information indicating the name of the event identified by the event ID.

[0087] The "operating company" field stores information about the operating company. Information about the operating company is information that indicates the operating company of the event identified by the event ID. Information about the operating company may include the name of the operating company, as well as the address of the operating company and contact information for the person in charge.

[0088] The "Performer" field stores performer information. Performer information indicates the performers of the event identified by the event ID. Performer information includes individuals or organizations (group names, team names, band names, etc.).

[0089] The "Event Type" field stores information about the event type. The information about the event type is information that indicates an overview of the event identified by the event ID. For example, event types include "professional baseball," "anime preview," and "online live."

[0090] (3-2) User database An example of the configuration of the user database will be described. The user database shown in FIG. 8B stores user information. As shown in FIG. 8B, the user database includes a "user ID" field, a "login pass" field, a "user name" field, a "user attribute" field, a "contact information" field, and a "feature" field.

[0091] The "User ID" field stores a user ID. The user ID is information that identifies a user.

[0092] The "login password" field stores information related to the login password that the user is required to enter when logging in to the ticket management server 20.

[0093] The "user name" field stores the name of the user corresponding to the user ID.

[0094] The "user attribute" field stores information indicating the attributes of the user corresponding to the user ID. User attributes include age, date of birth, gender, occupation, nationality, residential area, or a combination thereof.

[0095] The "Contact" field stores information indicating the contact information of the user corresponding to the user ID. The contact information may be, for example, an email address, a phone number, account information for a social networking service (SNS) or other messaging-enabled application, or a combination thereof. The contact information is not limited to the examples given here and may include any type of information that can be used to send real-time notifications to attendees via the user terminal 10.

[0096] The "feature" field stores the facial feature of the user corresponding to the user ID. The facial feature of the user is extracted from an image of the user's face.

[0097] (3-3) Ticket database An example of the configuration of a ticket database will be described.

[0098] The ticket database shown in FIG. 8C stores ticket information. As shown in FIG. 8C, the user database includes a "Ticket ID" field, an "Event ID" field, a "Seat Number" field, a "Token ID" field, a "Serial Code" field, an "Owner ID" field, and a "Status ID" field.

[0099] The "Ticket ID" field stores the ticket ID. The ticket ID is information for identifying the ticket.

[0100] The "event ID" field stores the event ID of the event corresponding to the ticket ID.

[0101] The "Seat Number" field stores information identifying the seat corresponding to the ticket ID. The seat number is information about the seat (an example of an "area") assigned at the event venue. Note that if there are no seats, such as in an online event, the seat number ID is not necessary.

[0102] The "token ID" field stores a token ID that identifies a token given as a benefit of the ticket corresponding to the ticket ID.

[0103] The "Serial Code ID" field stores the serial code that must be entered to receive the token corresponding to the token ID. The serial code is an identifier consisting of a specific character string that is set to approve the issuance of the token.

[0104] The "Owner ID" field stores the user ID that indicates the owner of the ticket corresponding to the ticket ID. The ticket owner originally refers to the person who purchased the ticket. When a ticket is transferred after purchase, the ticket owner becomes the user to whom the ticket is transferred.

[0105] The "Status ID" field stores information indicating the status of the ticket corresponding to the ticket ID. Ticket statuses include "before use" and "after use." After the ticket is torn, the ticket status is rewritten to "after use."

[0106] (3-4) Account database FIG. 9 is a diagram showing an example of the data structure of the account database and the token database stored in the external server 50. As shown in FIG.

[0107] FIG. 9A is a diagram showing an example of the data structure of the account database stored in the external server 50. As shown in FIG. The account database shown in FIG. 9A stores account information used for a user to receive a token.

[0108] As shown in Figure 9A, the account database includes a "user name" field, a "user attribute" field, a "contact" field, an "external server login ID" field, an "external server login PASS" field, a "management ledger login ID" field, and a "management ledger PASS" field.

[0109] The "user name" field stores the user's name.

[0110] The "user attribute" field stores information indicating the attributes of the user corresponding to the user name, such as age, date of birth, gender, occupation, nationality, residential area, or a combination thereof.

[0111] The "Contact" field stores information indicating the user's contact information corresponding to the user name. The contact information may be, for example, an email address, a phone number, account information for a social networking service (SNS) or other messaging-enabled application, or a combination thereof. The contact information is not limited to the examples given here and may include any type of information that can be used to send real-time notifications to attendees via the user terminal 10.

[0112] The “external server login ID” field stores the user ID of the user in the external server 50 corresponding to the user name. In other words, the “external server login ID” is the login ID that the user is required to enter when logging in to the external server 50.

[0113] The "external server PASS" field stores the login password that is required to be input when logging in to the external server 50 of the user corresponding to the user name.

[0114] The "Management Ledger Login ID" field stores the user ID in the token management ledger 40 of the user corresponding to the user name. In other words, the "Management Ledger Login ID" is the login ID that the user or the external server 50 is required to enter when logging in to the token management ledger 40.

[0115] The "Management Ledger PASS" field stores the password that the external server 50 enters into the token management ledger 40 when the external server 50 rewrites the contents of the token management ledger 40 based on input from the user. The user can also directly rewrite the token management ledger 40 using the management ledger login ID and management ledger PASS.

[0116] (3-5) Token database FIG. 9B is a diagram showing an example of the data structure of the token database stored in the external server 50. As shown in FIG. The token database shown in FIG. 9B stores information about tokens. As shown in FIG. 9B, the event database includes a "token ID" field, a "token content" field, a "ledger ID", a "serial code" field, and a "status" field.

[0117] The "token ID" field stores a token ID. The token ID is information for identifying a token. A token ID is a number assigned to the content of a token. For example, if a player image of baseball player A is set as the digital content in a token, one token ID is set for the player image of player A. In contrast, ledger IDs, which will be described later, are set in a quantity corresponding to the number of tokens assigned. For this reason, multiple ledger IDs are set for one token ID.

[0118] The "token content" field contains information indicating the content of the token corresponding to the token ID. The information indicating the token content is information indicating the content of the token granted as a benefit for a ticket to an event identified by the event ID. For example, the token content may include "player image / video," "character image / video," "benefit sound source," etc.

[0119] The "ledger ID" stores a management ID as a management ledger in the token management ledger 40. In other words, the "ledger ID" is an ID set for each token ownership. In this embodiment, the "ledger ID" can also be referred to as a blockchain ID. A unique value is set for each token ownership.

[0120] The "Serial Code ID" field stores the serial code that is required to be entered in order to receive a token.

[0121] The "status" field stores information indicating the status of the token recorded in the ledger corresponding to the ledger ID. The token status is information indicating whether the token has already been used. Using a token means exchanging the token for a preset benefit. Exchanging a token for a benefit may or may not involve transferring the token. Exchanging a token for a benefit will be described later.

[0122] (3-5) Token management ledger 40 and external server 50 As shown in FIG. 10, the token management ledger 40 is associated with digital content recorded on an external server 50. The token management ledger 40 is realized by a blockchain, which is a distributed management ledger. In other words, tokens are managed by a distributed management ledger. Tokens are capable of referencing their transaction history associated with the transfer of ownership, which will be described later. By referencing all transaction history related to a certain token, the owner of that token can be identified.

[0123] The blockchain is composed of blocks that constitute contract data and blocks that include at least hash values ​​and transaction data. When tokens are transferred between users, new transaction data is generated, and after verification by signal processing devices 40A to 40E shown in Fig. 6, a new block is added. The blockchain may also be configured with multiple layers, using a public blockchain and a private blockchain, with normal transactions recording transaction history on the private blockchain and periodically updating the public blockchain with the latest information.

[0124] (4) Ticket processing The ticket processing of this embodiment will be described.

[0125] (4-1) User registration process The ticket issuing process of this embodiment will be described below with reference to the flowchart of user registration in this embodiment. As shown in FIG. 11, first, the user operates the user terminal 10 to input personal information such as the user's name and apply for user registration (step S100).

[0126] After step S100, the ticket management server 20 accepts an application for user registration (step S101). After step S101, the ticket management server 20 issues a user ID and a login password (step S102). At this time, the ticket management server 20 records the personal information, user ID, and password input by the user as a new record in the user database.

[0127] After step S102, the user terminal 10 receives the issued user ID and login password (step S103).

[0128] After step S102, the ticket management server 20 requests the user terminal 10 to input a feature amount (step S104). Specifically, the ticket management server 20 requests the user terminal 10 to input an image of the user's face.

[0129] After step S104, the user operates the user terminal 10 to acquire feature amounts (step S105). Specifically, the user photographs his or her own face using the input device 15 (visible light camera) of the user terminal 10. The processor 12 performs calculations on the acquired image data to acquire feature amounts (for example, facial feature amounts) of the ticket purchaser. After step S105, the user terminal 10 transmits the acquired feature amount, that is, the user's face image, to the ticket management server 20 (step S106).

[0130] After step S106, the ticket management server 20 receives the feature amount transmitted from the user terminal 10 (step S107). After step S107, the ticket management server 20 registers the received feature amount in the user database (step S108). This completes the user registration process.

[0131] (4-2) Ticketing process FIG. 12 is a flowchart of the ticket issuing process of this embodiment.

[0132] As shown in FIG. 12, the user terminal 10 executes reception of a purchase operation (S110). Specifically, the processor 12 receives a purchase operation performed on the input device 15 via the input / output interface 13 . The operator of the user terminal 10 is not limited to the ticket purchaser, but may be a person who operates the user terminal 10 on behalf of the purchaser (for example, a ticket sales attendant). The purchasing operation may include, for example, inputting a user ID, selecting a show, selecting a date and time, selecting a seat type, pressing a purchase button (a button object or a physical button), or a combination thereof.

[0133] After step S111, the user terminal 10 executes a ticket issuance request (S111). Specifically, processor 12 generates a ticket issuance request by referring to the content of the purchase operation accepted in step S110 and the feature acquired in step S111. The ticket issuance request includes, for example, information specifying the type of ticket for which issuance is requested (e.g., information specifying the event, date and time, and seat type), as well as the feature and user ID of the ticket purchaser. Processor 12 transmits the ticket issuance request to ticket management server 20 via communication interface 14.

[0134] After step S111, the ticket management server 20 performs a ticket issuing process (step S120). Specifically, the processor 22 of the ticket management server 20 allocates tickets to be sold based on the purchaser information transmitted from the user terminal 10.

[0135] After step S120, the ticket management server 20 updates the database (S121). Specifically, processor 22 newly registers the user ID included in the ticket issuance request and the reference feature ID identified in step S120 in the ticket database (FIG. 8C) in association with the unissued ticket ID. This makes it possible to identify the ticket purchaser and the reference feature based on the ticket ID. Furthermore, the processor 22 updates the user database (FIG. 8B) using the characteristics of the purchaser transmitted from the user terminal 10. Note that if the characteristics of the user have already been stored, this process may be omitted.

[0136] After step S121, the ticket management server 20 provides the ticket information (S122). Specifically, the processor 22 generates ticket information by referring to the updated contents of the database in step S121. The ticket information includes the ticket ID newly registered in step S121. Furthermore, the ticket information may include at least one of the reference feature ID identified in step S121 and the user ID of the ticket purchaser. Some or all of the information included in the ticket information may be encoded, for example, in a QR code (registered trademark) or other code information. The processor 22 provides the generated ticket information to the ticket purchaser. As an example, the processor 22 transmits the generated ticket information to the user terminal 10 via the communication interface 24.

[0137] After step S122, the user terminal 10 saves the ticket information (S112). Specifically, the processor 12 acquires the ticket information provided in step S122. The processor 12 stores the acquired ticket information in the storage device 11. This allows the processor 12 to display the ticket information as needed. Furthermore, the processor 12 may optionally perform at least one of the following: · Causes the output device 16 (printing device) to print the ticket information onto paper or other media. The communication interface 14 transmits the ticket information to the user terminal 10 of the ticket purchaser.

[0138] (4-3) Ticket inspection The ticket inspection process of this embodiment will now be described with reference to the flowchart of FIG.

[0139] As shown in FIG. 13, a user who has arrived at the event venue operates the user terminal 10 to display the ticket on the user terminal 10 (step S114). Specifically, the processor 12 of the user terminal 10 displays the ticket information stored in the storage device 11.

[0140] After step S114, the ticket inspection system 30 reads the ticket (S130). Specifically, when a visitor presents a ticket, the processor 32 works in conjunction with the visible light camera 352 to read the ticket information (authentication information acquisition means). In step S130, the processor 32 may display the image captured by the visible light camera 352 on the output device 36 (display) for the attendee. This provides the attendee with feedback on how the ticket is being photographed, and encourages them to make fine adjustments to the position and orientation of the ticket.

[0141] Furthermore, the ticket inspection system 30 acquires the feature amount (S131). Specifically, when a visitor presents a ticket, the processor 32 cooperates with the visible light camera 352 to acquire the characteristics of the visitor (for example, facial characteristics). In step S131, the processor 32 may display the image captured by the visible light camera 352 on the output device 36 (display) for the visitors. This provides the visitors with feedback on how they are being photographed, and encourages them to make fine adjustments to their position and posture.

[0142] The ticket inspection system 30 may execute step S130 and step S131 in an order different from that shown in Figure 13. As an example, the ticket inspection system 30 may execute two or more of these steps simultaneously.

[0143] After steps S130 and S131, the ticket inspection system 30 determines whether or not entry is permitted (S132). Specifically, processor 32 refers to the ticket information read in step S130 to determine whether or not the visitor is permitted to enter the venue. Specifically, the read ticket information is checked against the ticket database to determine whether the ticket information is appropriate for admission. At this time, processor 32 also verifies the identity of the attendee and the ticket owner. That is, it references the ticket owner ID recorded in the ticket database and compares it with the user features associated with the user ID registered in the user database to determine whether the ticket owner (purchaser) is attending the event.

[0144] In step S133, if the read ticket information is not appropriate ticket information, or if the identity of the attendee and the ticket holder cannot be confirmed (No in step S133), the ticket inspection system 30 executes an entry error process (S134). Specifically, when it is determined in step S133 that the visitor's entry is to be denied, the processor 32 performs at least one of the following processes. - Activating an alarm (for example, lighting a lamp, emitting a specified sound, displaying a specified screen, or a combination of these to notify the visitor and staff that entry has been denied and to prompt staff to take follow-up measures) Closing gates (e.g., closing power gate bars or flap doors to physically block visitor entry) In order to prevent congestion near the ticket inspection system 30, the attendant may provide aftercare after conveniently allowing the attendee to enter the target space. The attendant may provide aftercare to determine whether the attendee is the genuine purchaser of the ticket. For example, the attendant may ask the attendee for attribute information, contact information, ticket purchase location, ticket purchase time, or a combination thereof, and compare the information with the ticket information. After step S134, the ticket inspection process of FIG. 13 ends.

[0145] In step S133, if the read ticket information is appropriate and the identity of the visitor and the ticket holder can be confirmed (Yes in step S133), the ticket inspection system 30 will permit entry (S135), or perform the so-called "ticket tearing process." Specifically, when it is determined in step S133 that the visitor is permitted to enter, the processor 32 performs at least one of the following processes. Notification that entry has been permitted (for example, by lighting a lamp, emitting a specified sound, displaying a specified screen, or a combination of these, the visitor and attendants will be made aware that entry has been permitted) Opening gates (e.g., opening electric gate bars or flap doors to allow visitors in)

[0146] The processor 32 may create or update a check-in list during step S135. The check-in list is information about the results of ticket inspection for each visitor. For example, the check-in list includes at least one of the following elements: Check-in time Ticket ID presented by the attendee User ID associated with ticket ID Username associated with the user ID The result of the admission decision (step S133) (admission permitted / admission denied) The area assigned to the user in the target space (e.g., a reserved seat)

[0147] (4-4) Token granting process The token granting process of this embodiment will be described below with reference to the flowchart of FIG. To grant a token, first, a request for granting of a serial code is made to the ticket management server 20 (step S139). The request for granting of a serial code may be made together with a notification that the ticket has been used (a ticket tearing notification). Specifically, the processor 32 of the ticket inspection system 30 identifies the user ID of the ticket owner and the ticket ID used, and transmits a request to the ticket management server 20 to assign a serial code to that user.

[0148] After step S139, the ticket management server 20 receives an application for issuance of a serial code (step S123). Specifically, the processor 22 of the ticket management server 20 receives the user ID to which the serial code is to be assigned from the ticket inspection system 3. At the same time, the ticket management server 20 receives a notification that the torn ticket has been used. The ticket management server 20 changes the "status" field of the ticket in the ticket database to "used."

[0149] After step S123, the ticket management server 20 assigns the serial code to the user terminal 10 (step S124). Specifically, the processor 22 of the ticket management server 20 refers to the ticket database and identifies the token to be assigned and the serial code set for the token to be assigned. The processor 22 transmits the identified serial code to the user terminal 10 used by the user to whom the serial code is to be assigned.

[0150] After step S124, the user terminal 10 receives the serial code (step S115). Specifically, the processor 12 of the user terminal 10 receives the serial code corresponding to the token to be granted from the ticket management server 20. Note that the serial code may be granted, for example, by writing the serial code on the face of the electronic ticket. In other words, the face of the electronic ticket may be rewritten to include the serial code.

[0151] After step S115, the user operates the user terminal 10 to log in to the external server 50 (step S116). Specifically, the user operates the user terminal 10 to input an external server login ID and an external server login PASS, thereby logging in to the external server 50.

[0152] After step S116, the serial code is input into the input form output from the external server 50 (step S117).

[0153] After step S117, the user terminal 10 transmits the serial code to the external server 50. The processor 12 of the user terminal 10 transmits the serial code input by the user to the ticket management server 20. This completes the request for granting of a token.

[0154] After step S117, the external server 50 receives the serial code (step S151). At this time, the external server 50 refers to its own token database to check the input serial code.

[0155] In step S151, if the serial code is an appropriate code, the external server 50 transmits a registration instruction for the token owner to the token management ledger 40 (step S152). At this time, the external server 50 refers to the account database, references the management ledger login ID and management ledger PASS corresponding to the external server login ID, and uses this information to access the token management ledger 40 and instructs it to rewrite the management ledger. The external server ID transmits information on the ledger ID linked to the serial code to the token management ledger 40 in the rewrite instruction.

[0156] After step S152, the token management ledger 40 registers the owner of the token. At this time, the token management ledger 40 identifies the ledger to be recorded in by the ledger ID input from the external server 50, and identifies the user by the management ledger login ID input from the external server 50. As a result, a block in which the ledger login ID is recorded is added as new transaction data on the blockchain. This clarifies the owner of the token. In other words, this process grants the token to the user who has visited the event venue. This completes the token granting process.

[0157] (5) Other functions Next, other functions of the ticket system 1 will be described. The ticket management server 20 provides a benefit to a user who owns a token by using the token as an exchange voucher. The benefit may be, for example, a ticket for a future event, a special discount coupon, preferential ticket purchasing privileges, or merchandise. The exchange process for a ticket (benefit ticket) provided as a benefit using such a token as an exchange voucher will be described below. Note that a portion of a regular ticket is allocated to a benefit ticket. In other words, a portion of an event ticket is provided to a user as a benefit through the exchange process described below.

[0158] A reward ticket is a ticket for an event that will be held a certain period of time (for example, several months or years) after the event for which the token was issued. During this period, the user can transfer the token to another user. In other words, the ticket system 1 changes the owner of the token to another user in response to an instruction from the owner who was issued the token. At this time, the record in the token management ledger 40 is rewritten via the external server 50.

[0159] 15 is a diagram showing an example of the data structure of the bonus ticket database stored in the ticket management server 20 and the exchange code database stored in the external server 50. These databases are generated, for example, as the event in which the bonus ticket is used approaches.

[0160] FIG. 15A is a diagram showing an example of the data structure of the privilege ticket database stored in the ticket management server 20. As shown in FIG. As shown in FIG. 15A, the reward ticket database includes a "Ticket ID" field, an "Event ID" field, a "Seat Number" field, a "Exchange Code" field, an "Owner ID" field, and a "Status" field.

[0161] The "Ticket ID" field stores the ID of the ticket that is the benefit exchanged for the voucher. In this explanation, it is referred to as a benefit ticket, but the benefit ticket may be designed so that a portion of the general ticket is allocated as a benefit ticket.

[0162] The "Event ID" field stores the ID of the event that corresponds to the ticket ID. In this description, the ID of the event that will be the benefit is stored.

[0163] The "seat number" field stores the seat number of the bonus ticket corresponding to the ticket ID.

[0164] The "exchange code" field stores information about the exchange code that the user is required to input when exchanging the bonus ticket corresponding to the ticket ID.

[0165] The "owner ID" field stores the user ID of the owner of the bonus ticket corresponding to the ticket ID.

[0166] The "status" field stores the status of the bonus ticket corresponding to the ticket ID. Bonus ticket statuses include "before redemption," "before use," and "used." The "before redemption" status indicates that the bonus ticket has not yet been redeemed. The "before use" status indicates that the bonus ticket has not been used, i.e., the holder of the bonus ticket has not yet arrived at the event venue. The "used" status indicates that the bonus ticket has been used, i.e., the holder of the bonus ticket has arrived at the event venue and the ticket has been torn off.

[0167] FIG. 15B is a diagram showing an example of the data structure of the exchange code database stored in the external server 50. As shown in FIG. As shown in FIG. 15B, the reward ticket database includes a "ledger ID" field, a "token ID" field, a "token content" field, and a "exchange code".

[0168] The "ledger ID" field stores the management ID of the token in the token management ledger 40.

[0169] The "token ID" field stores a token ID for managing the type of token.

[0170] The "token content" field stores the content of the token whose ownership is managed in the ledger corresponding to the ledger ID. In reality, instead of the "future ticket voucher" shown in this diagram, a specific event name such as "voucher for the Budokan live concert scheduled to be held on yymmdd (date)" or "voucher for the Osaka performance of the national tour scheduled to be held in Reiwa *" is stored. Alternatively, the voucher may be more flexible in scope, such as "priority purchase rights for the 10th anniversary live concert," "voucher for the Budokan live concert," "right to have priority purchase once only for any live concert hosted by XX agency," or "priority purchase rights for special merchandise."

[0171] The "exchange code" field stores information about the exchange code that a user is required to enter when exchanging a reward ticket corresponding to the ticket ID. In other words, it stores information indicating the user's authority when obtaining a reward ticket using a token as an exchange voucher.

[0172] Next, a process for a user to exchange a bonus ticket will be described with reference to Fig. 16, which is a flowchart of the process for a user to exchange a bonus ticket. 16, in the process of a user exchanging a privilege ticket, first, the ticket management server 20 issues a privilege ticket (step S221). The privilege ticket is issued, for example, when it is specifically decided that a future event will be held.

[0173] At this time, a bonus ticket database is created in the ticket management server 20. At this point, the "exchange code" field and the "owner ID" field in the bonus ticket database are blank. Also, at this point, all of the "status" fields in the bonus ticket database shown in FIG. 15A are set to "before exchange."

[0174] 16, after step S221, the ticket management server 20 notifies the external server 50 of the issuance of the privilege ticket (step S222). Specifically, the processor 22 of the ticket management server 20 outputs to the external server 50 a notification that the privilege ticket has been issued.

[0175] After step S222, the external server 50 issues an exchange code (step S251). Specifically, the external server 50 receives a notification of the issuance of the bonus ticket from the ticket management server 20 and creates an exchange code database shown in Fig. 15B. At this time, the exchange code is created so as to be assigned to a ledger ID.

[0176] After step S251 shown in FIG. 16, the external server 50 notifies the ticket management server 20 and the user terminal 10 of the issuance of an exchange code (step S252). Specifically, the external server 50 notifies the ticket management server 20 of the exchange code. As a result, the ticket management server 20 assigns the exchange code to the ticket ID of the benefit ticket in the benefit ticket database. As a result, the benefit code is recorded in the "benefit code" field in the benefit ticket database shown in FIG. 15A. As a result, the exchange code is allocated so as to correspond to the seat number in the benefit ticket database. Note that seat numbers may be allocated to the exchange code when an exchange code is entered or when the reception is completed, as described below. Furthermore, when an exchange code is entered, the user may be allowed to select a seat number, for example, on a first-come, first-served basis. Furthermore, an acceptance deadline for accepting exchange codes may be set, and after the acceptance deadline has passed, a lottery may be held to allocate the tickets to be exchanged.

[0177] 16, the external server 50 notifies the user terminal 10 that an exchange code has been issued and the exchange code corresponding to the user. Specifically, the external server 50 notifies the user who is recorded as the owner of the token in the ledger ID of the exchange code corresponding to the ledger ID. This allows the user to exchange the benefit ticket. The redemption code is notified by contacting the user at a contact address (e.g., email address) listed in the account information database (see FIG. 9A) managed by the external server 50. The redemption code may also be displayed on the user terminal 10 when the user logs in to the external server 50 using an external server login ID and an external server login PASS. In addition, as a method of managing the redemption code, the redemption code may be recorded on a ledger (blockchain) managed by the token management ledger 40.

[0178] After step S252, the user inputs the notified exchange code to the user terminal 10 (step S211). Specifically, the user operates the user terminal 10 to log in to the ticket management server 20 and inputs the notified exchange code. This completes the application for exchange of the bonus ticket.

[0179] After step S211, the ticket management server 20 checks the exchange code entered by the user (step S223). Specifically, the processor 22 of the ticket management server 20 checks whether the privilege code is valid by referring to the privilege ticket database.

[0180] After step S223, the ticket management server 20 provides the bonus ticket information (step S224). Specifically, if the bonus code entered by the user is valid, the processor 22 records the user ID of the user in the "owner ID" field of the corresponding bonus ticket in the bonus ticket database. This records the owner of the bonus ticket in the bonus ticket database. At this time, the "status" field in the bonus ticket database is also rewritten from "before redemption" to "before use." Then, the processor 22 generates information about the bonus ticket (bonus ticket information) and provides it to the user terminal 10. Some or all of the information included in the bonus ticket information may be encoded, for example, into a QR code (registered trademark) or other code information.

[0181] After step S224, the user terminal 10 saves the privilege ticket information (S212). Specifically, the processor 12 of the user terminal 10 acquires the bonus ticket information provided in step S224. The processor 12 stores the acquired bonus ticket information in the storage device 11. This allows the processor 12 to display the bonus ticket information as needed. This completes the bonus ticket exchange process.

[0182] In the above description, an example in which the redemption code is managed by the external server 50 has been described, but this is not limiting. For example, the redemption code may be managed on each ledger (blockchain) managed by the token management ledger 40. In this case, the redemption process may be performed by transferring ownership of the token. That is, the redemption right may be cleared by rewriting information indicating the token owner from the user to the promoter on the blockchain. In this case, the user may apply for a benefit redemption by sending the token to the promoter (transfer of the blockchain) rather than by entering the redemption code.

[0183] Furthermore, the ticket management server 20 that manages the bonus tickets may be realized by a server different from the ticket management server 20 that manages the serial codes for granting tokens. This is because, considering the period from the time when the first event is held to the time when future events are held, it is more useful and realistic to use a different server.

[0184] Alternatively, a new token may be granted to a user after the use of a special ticket. In this case, the token ID and serial code are managed in the ticket database shown in Fig. 15A, and the process of granting a new token from the use of the ticket described above is performed after the special ticket is used.

[0185] The reward ticket may be a paper ticket, or the reward given in exchange for a token may be a tangible object. For example, the reward may be a rare item such as a limited number of official goods (autographs, etc.). In other words, the token holder is certified as having participated in a specified event. In return for participating in the event, the reward is provided in the form of a physical object, not digital information such as an electronic ticket.

[0186] Furthermore, the ticket management server 20 grants additional tokens when the token ownership status satisfies predetermined conditions. Additional tokens are additional tokens that are granted to those who have participated in all events set as a predetermined series, such as a tour performance, and have acquired all of the corresponding tokens. Possession of additional tokens serves as proof that one has participated in all events in the predetermined series. For this reason, additional tokens appeal to the collecting desire of fans (users).

[0187] (6) Screen example Next, we will explain examples of screens on the user terminal 10 in the ticket system 1. Fig. 17 shows a first example of a screen and a second example of a screen. The first example of a screen shown in Fig. 17A is an example of a screen when purchasing a ticket (step S110 in Fig. 12). As shown in Figure 17A, when purchasing tickets, the event details, the items to be purchased, and the price are displayed. The user inputs the quantity and submits a purchase request to complete the purchase.

[0188] The second screen example shown in FIG. 17B is an example of a screen when ticket issuance is completed and ticket information is saved (step S113 in FIG. 12). 17B, ​​when the ticket information is saved, the details of the purchased ticket are displayed on the user terminal 10. This allows the user to confirm that the purchase has been made properly.

[0189] 18A and 18B are diagrams showing examples of a third and fourth screens, respectively. The third screen example shown in Fig. 18A is an example of a screen displayed when a serial code for requesting the issuance of tokens is received (step S115 in Fig. 14). As shown in FIG. 18A, when the serial code is received, the serial code is displayed on the user terminal 10. The serial code may be sent by SMS to the email address or phone number registered during user registration, or may be displayed on the My Page that is displayed when the user logs in to the ticket management server 20.

[0190] The serial code may also be sent by issuing a new ticket bearing the serial code number. That is, when issuing the serial code, a ticket ID may be assigned to the serial code ticket and recorded as a new record in the ticket database. This allows the received serial code itself to be circulated in the same way as a "ticket," and can be traded between users, for example, thereby increasing its versatility.

[0191] Furthermore, when issuing a serial code ticket, instead of directly displaying the serial code, an action corresponding to the "tear" process may be performed, such as tapping a "use" button, just like with an admission ticket. This allows the serial code to be displayed only when the ticket itself has been "used," thereby ensuring that the serial code is "unused."

[0192] The fourth screen example shown in Figure 18B is an example of a login request screen that is displayed before transitioning to a specific form screen to receive a token. When a user logs in by entering their login ID and password, a specific form screen for entering a serial code is displayed.

[0193] Fig. 19A shows a fifth and sixth screen examples. The fifth screen example shown in Fig. 19A is an example of a screen when inputting a serial code (step S116 in Fig. 14). As shown in FIG. 19A, the user enters the serial code in a predetermined input field that is displayed, and clicks the execute button.

[0194] The sixth screen example shown in FIG. 19B is an example of a screen when the token owner is recorded (step S125). As shown in Figure 19B, once the token owner is recorded, a message to that effect is displayed to the user who entered the serial code, and a bonus image (in this example, an image of a professional baseball player) is displayed as the digital content that constitutes the token.

[0195] (7) Effects As explained above, the ticket system 1 can provide users with content data as a benefit by actually using a ticket (i.e., by attending an event venue or watching an event online). For this reason, users cannot purchase a ticket to receive the benefit and then resell the ticket after receiving it; they must actually use the ticket to participate in the event. This effectively motivates users to participate in the event.

[0196] Furthermore, since the identity of the ticket purchaser and user is confirmed, ticket hoarding and resale for the purpose of receiving tokens can be effectively prevented.

[0197] In addition, the identity of the ticket owner and user is confirmed using an image of the ticket owner's face, making it difficult to impersonate someone else and ensuring the accuracy of the confirmation results.

[0198] Furthermore, since an identifier is issued to the owner of the token, and then the input of the identifier is accepted and the token is granted, it is possible to effectively prevent unauthorized acquisition of the token by others.

[0199] Furthermore, since tokens can be traded individually between users, the motivation to collect tokens can be increased.

[0200] In addition, the value of tokens can be further increased by offering rewards such as event tickets to token holders.

[0201] Furthermore, when the token ownership status satisfies a predetermined condition, additional tokens are awarded, which can more effectively increase motivation to collect tokens and, ultimately, to participate in the event.

[0202] (8) Variations A modification of this embodiment will now be described. (8-1) Variation 1 In the first modification, the content data as a token is different from that in the above-described embodiment. Fig. 20 is a diagram showing another example of the structure of the content data. 20, the content data according to the modified example is incorporated as part of the blockchain. In this case, information on the token and the token management ledger 40 is recorded in the distributed management ledger as the blockchain.

[0203] (8-2) Variation 2 In Modification 2, an example will be described in which a token is granted without a serial code. Fig. 21 is a diagram illustrating the token granting process according to Modification 2. In this modification, the user database stores the user ID of the external server 50. Note that the flow up to the ticket inspection process is the same as in the embodiment, and therefore a description thereof will be omitted.

[0204] 21, the ticket inspection system 30 executes a ticket tear notification process (step S139B). Specifically, the ticket inspection system 30 notifies the ticket management server 20 that the ticket has been used.

[0205] After step S139B, the ticket management server 20 receives the ticket tearing notice (step S125). At this time, based on the ticket tearing notice, the ticket management server 20 updates the "status" field of the ticket database for the ticket to "used."

[0206] After step S125, the ticket management server 20 executes a token granting instruction (step S126). At this time, the ticket management server 20 transmits the token granting instruction to the external server 50 by using the token ID associated with the ticket and the login ID in the external server 50 associated with the user who owns the ticket.

[0207] After step S126, the external server 50 receives a token grant instruction (step S153). After step S153, the external server 50 transmits a registration instruction for the token owner to the token management ledger 40 (step S154). At this time, the external server 50 refers to the account information database and references the management ledger login ID and management ledger PASS corresponding to the login ID in the external server 50. Then, the external server 50 logs in to the token management ledger 40 and issues an instruction to register the user in the token ID.

[0208] After step S152, the token management ledger 40 registers the owner of the token. At this time, the token management ledger 40 adds a block in which the user ID of the external server 50 is recorded as new transaction data on the blockchain. This clarifies the owner of the token. In other words, this process grants the token to the user who has visited the event venue. This completes the token granting process.

[0209] (9) Other variations The storage device 11 may be connected to the user terminal 10 via a network NW. The storage device 21 may be connected to the ticket management server 20 via the network NW. The storage device 31 may be connected to the ticket inspection system 30 via the network NW.

[0210] The above ticket inspection process may be performed by the ticket inspection system 30 alone as shown in FIG. 13, or may be performed in cooperation with the ticket inspection system 30 and another device (for example, the ticket management server 20).

[0211] In the embodiment, a configuration has been described in which the identity of the ticket owner and the ticket user (attendee) is confirmed, and a token is granted to the ticket owner once the identity is confirmed. However, the ticket system 1 may uniformly grant a token to the ticket owner after a certain time has passed after the ticket inspection system 30 has torn the ticket, without confirming the identity of the ticket owner and the ticket user (attendee). Alternatively, a token may be granted when an administrator issues an instruction regarding token granting to the ticket management server 20. Furthermore, the identity of the ticket holder and the attendee may not be confirmed when determining whether or not to allow entry (step S132), but may be confirmed before applying for the issuance of a serial code (step S139).

[0212] Furthermore, the identity of the ticket owner and the attendee may be confirmed by personal authentication required when accessing ticket information. Specifically, the identity of the ticket owner and the attendee may be confirmed by account information entered by the user when displaying ticket information, SMS authentication, device ID authentication, etc.

[0213] In the embodiment, the user visits the event venue. However, if the event is an online event, the user presses the view button displayed on the user terminal 10, which executes the ticket display process (step S114) shown in FIG. In other words, if the ticket relates to an event that is provided via information communication, the user receiving the provision of information communication using the ticket is called using the ticket, and the detection of the use of the ticket is performed when the provision of information communication begins.

[0214] Furthermore, the ticket inspection system 30 determines whether or not a viewer is permitted to watch, instead of determining whether or not entry is permitted (step S132 shown in FIG. 13). In this case, instead of using the visible light camera 352 of the ticket inspection system 30, a process may be performed in which a face photograph of the viewer taken by the user terminal 10 is transmitted to the ticket inspection system 30.

[0215] In the embodiment, an example has been described in which facial features are used to determine whether a visitor is allowed to enter, but instead of facial features, features related to other biometrics (e.g., fingerprints, palm prints, irises, veins, myoelectric potentials, etc.) may also be used to determine whether a visitor is allowed to enter. Additionally, user-specific information may be acquired by other sensors such as infrared, RFID, sonic, and laser-type one-dimensional barcode readers. Furthermore, a plurality of types of feature amounts may be used to determine whether or not a visitor is permitted to enter the venue.

[0216] In the embodiment, the process of acquiring feature amounts during user registration has been described, but the timing of acquiring feature amounts is not limited to this. For example, after the ticket is issued, a process of transitioning from the ticket face displayed on the user terminal 10 to a screen for inputting feature amounts may be performed. Furthermore, after purchasing a ticket, the acquired feature amount may be input using the user terminal 10 before the ticket is issued.

[0217] In the embodiment, a configuration has been described in which a blockchain is used as the token management ledger 40, but the configuration is not limited to this. That is, the token management ledger 40 may be a database configured with columns necessary for managing tokens.

[0218] In the embodiment, a ticket is used as an authentication information carrier for carrying authentication information. However, the authentication information carrier may also be the visitor's biometric data. Specifically, the authentication information carrier may be the visitor's face or palm. Such an authentication information carrier holds information related to the visitor's features as authentication information. In this case, the ticket inspection system 30 can acquire the visitor's features and use the features as a clue to identify the ticket ID that identifies the ticket purchased by the visitor. In other words, the ticket database stores the biometric information (including the features) of the purchasing user instead of the ticket ID.

[0219] In the embodiment, an example has been shown in which the ticket management server 20 transmits ticket information to the user terminal 10. However, instead of the ticket information, the ticket management server 20 may transmit resource information (e.g., a URL (Uniform Resource Locator)) for referencing the resource in which the ticket information is saved to the user terminal 10. A visitor can display the ticket information on the display of the user terminal 10 by accessing the resource indicated by the resource information using their own user terminal 10.

[0220] In the embodiment, an example has been shown in which the purchaser's characteristics are transmitted to the ticket management server 20 when the ticket is purchased. However, the purchaser's characteristics may also be transmitted to the ticket management server 20 after the ticket is purchased. This makes it possible to purchase tickets for multiple attendees in bulk. Note that a deadline for transmitting the attendee's characteristics to the ticket management server 20 may be set, and the contents of the ticket inspection process may differ depending on whether a ticket with registered characteristics is presented within the deadline or not.

[0221] In the embodiment, an example has been shown in which part or all of the information included in the ticket information is encoded in a two-dimensional code including, for example, a QR code (registered trademark), or other code information. As an example, the ticket may include a QR code (registered trademark) as the ticket ID and the reference character string. During the ticket issuance process, the processor 22 of the ticket management server 20 generates a reference string by calculating a predetermined function using, for example, the ticket ID, the event ID (information identifying the event the ticket is for), and the facial features of the ticket purchaser as arguments. The event ID corresponding to the event to be inspected and the above function are stored in storage device 31 of ticket inspection system 30. During the ticket inspection process, processor 32 of ticket inspection system 30 generates a string to be authenticated by performing an operation on the function read from storage device 31 using the ticket ID read from the ticket, the event ID read from storage device 31, and the facial features of the ticket user as arguments. Ticket inspection system 30 compares the reference string read from the ticket with the string to be authenticated to determine whether the ticket user and owner are the same. According to this example, it is possible to prevent illegal resale of tickets without storing personal information of users in the storage device 31 of the ticket inspection system 30.

[0222] In the embodiment, the serial code is assigned by the ticket management server 20, but the present invention is not limited to this. For example, the serial code may be written in a hidden state in the ticket data downloaded in advance into the user terminal 10, and processing may be performed to display the serial code in the user terminal 10 when the ticket is torn by the ticket inspection system 30.

[0223] Although the embodiments of the present invention have been described in detail above, the scope of the present invention is not limited to the above-described embodiments. Furthermore, the above-described embodiments can be improved or modified in various ways without departing from the spirit of the present invention. Furthermore, the above-described embodiments and modifications can be combined, or portions thereof can be omitted.

[0224] (7) Supplementary Notes The matters explained in the embodiment and the modified examples are additionally noted below.

[0225] (Appendix 1) The computer processor Detecting the use of the ticket (step S135); and a step of granting a token whose ownership can be clarified to the owner of the ticket in response to detection of use of the ticket (step S141).

[0226] (Appendix 2) The step of detecting the use of the ticket (step S135) The program described in (Appendix 1) detects use of a ticket by detecting that the user of the ticket has been granted entry to an event venue where an event related to the ticket is being held.

[0227] (Appendix 3) The step of detecting the use of the ticket (step S135) The program described in (Appendix 1) detects use of a ticket by detecting that the user of the ticket has started watching video or audio related to the ticket online.

[0228] (Appendix 4) In the step of granting tokens (step S141), A program according to any one of (Appendix 1) to (Appendix 3), which grants a token to the owner of the ticket when the identity of the ticket user and the owner of the ticket is confirmed.

[0229] (Appendix 5) In the step of granting the token (step S135), The identity of the user and owner is confirmed through personal authentication required when accessing ticket information, A program described in (Appendix 4) that grants a token to the ticket owner when the identity of the two parties is confirmed.

[0230] (Appendix 6) In the step of granting the token (step S135), The identity of the user and the owner is confirmed using a pre-stored face image of the owner and a face image of the user taken when using the ticket, A program described in (Appendix 4) that grants a token to the ticket owner when the identity of the two parties is confirmed.

[0231] (Appendix 7) In the step of granting the token (step S135), a step of transmitting the identifier to the owner of the ticket (step S124); The program according to any one of (Supplementary Note 1) to (Supplementary Note 6), which executes the step of accepting input of an identifier from an owner (Step S151).

[0232] (Appendix 8) In the step of granting tokens (step S141), The program according to (Supplementary Note 7) executes a step (Step S124) of writing an identifier on the face of the ticket.

[0233] (Appendix 9) In the step of granting tokens (step S141), A program described in (Appendix 1) to (Appendix 8) that registers the owner of a token to a server that manages tokens upon use of a ticket, using a user ID in a server 50 that manages tokens that is linked to a user ID in a server that manages ticket information.

[0234] (Appendix 10) The processor A program described in any one of (Appendix 1) to (Appendix 9), which executes a step of changing the owner of the token to another user in response to instructions from the owner who has been granted the token.

[0235] (Appendix 11) The processor Identifying a user who owns the token; A program according to any one of (Supplementary Note 1) to (Supplementary Note 10), which executes a step (step S224) of providing a benefit to a user who owns the token by using the token as an exchange ticket.

[0236] (Appendix 12) The processor Identifying a user whose token ownership state satisfies a predetermined condition; A program according to any one of (Supplementary Note 1) to (Supplementary Note 11), which executes a process of granting additional tokens to a user whose token ownership state satisfies a predetermined condition.

[0237] (Appendix 13) The computer's processor Detecting the use of the ticket (step S135); In response to detecting use of the ticket, granting an ownership-evident token to the owner of the ticket (step S141).

[0238] (Appendix 14) a processor; a first means 30 for detecting the use of a ticket; and second means 40 for granting an ownership-evident token to the owner of the ticket in response to detecting use of the ticket.

[0239] (Appendix 15) The system described in (Appendix 14), wherein the tokens are associated with a management ledger that can reference transaction history.

[0240] (Appendix 16) The system according to (Appendix 14) or (Appendix 15), wherein the tokens are managed by a distributed ledger. [Explanation of symbols]

[0241] 1: Ticket System 1 10: Ticket purchase terminal 11:Storage device 12: Processor 13: Input / output interface 14: Communication interface 15: Input device 16: Output device 20: Ticket management server 21:Storage device 22: Processor 23: Input / output interface 24: Communication interface 25: Input device 26: Output device 30: Ticket inspection system 31:Storage device 32: Processor 33: Input / output interface 34: Communication interface 35: Input device 36: Output device 352: Visible light camera

Claims

1. The computer processor detecting the use of the ticket; and in response to detecting use of the ticket, granting an ownership-evident token to the owner of the ticket.

2. The step of detecting use of the ticket comprises:

2. The program of claim 1, wherein the program detects use of the ticket by detecting that a user of the ticket has been granted admission to an event venue where an event related to the ticket is being held.

3. The step of detecting use of the ticket comprises: The program according to claim 1 , wherein the use of the ticket is detected by detecting that the user of the ticket has started to view online video or audio related to the ticket.

4. In the step of granting the token, 4. The program according to claim 1, wherein the token is granted to the owner of the ticket when the identity of the user of the ticket and the owner of the ticket is confirmed.

5. In the step of granting the token, Verifying the identity of the user and the owner through personal authentication required when accessing the ticket information; 5. The program according to claim 4, wherein the token is granted to the owner of the ticket when the identity of both parties is confirmed.

6. In the step of granting the token, confirming the identity of the user and the owner using a pre-stored face image of the owner and a face image of the user taken when using the ticket; 5. The program according to claim 4, wherein the token is granted to the owner of the ticket when the identity of both parties is confirmed.

7. In the step of granting the token, sending an identifier to the owner of the ticket; The program according to claim 1 , further comprising: a step of receiving an input of an identifier from the owner.

8. In the step of granting the token, The program according to claim 7, further comprising the step of writing the identifier on the face of the ticket.

9. In the step of granting the token, 9. The program according to claim 1, wherein the owner of the token is registered in the server that manages the token upon use of the ticket, using a user ID in the server that manages the token that is linked to a user ID in the server that manages the ticket information.

10. the processor, 10. The program according to claim 1, further comprising: a step of changing the owner of the token to another user in response to an instruction from the owner of the token.

11. the processor, Identifying a user who owns the token; The program according to claim 1 , further comprising: a step of providing a benefit to a user who owns the token by using the token as an exchange ticket.

12. the processor, Identifying a user whose ownership state of the token satisfies a predetermined condition; The program according to claim 1 , further comprising: a program for granting an additional token to a user whose ownership state of the token satisfies the predetermined condition.

13. The computer's processor detecting the use of the ticket; and in response to detecting use of the ticket, granting an ownership-evident token to the owner of the ticket.

14. a processor; a first means for detecting use of the ticket; and second means for granting an ownership-evident token to the owner of the ticket in response to detecting use of the ticket.

15. The system of claim 14 , wherein the token is associated with a management ledger that can reference transaction history.

16. The system according to claim 14 or 15, wherein the tokens are managed by a distributed ledger.

Images