Programs, methods, and systems

Abstract

To provide a program, a method, and a system that promote sales of a ticket to a user who actually uses the ticket.SOLUTION: In an information processing system 1, a ticket management server 20 executing a program detects payment of cost related to a transaction of a ticket, and changes information on an owner of the ticket according to the transaction to another user who has purchased a ticket from a seller. The ticket management server executes processing of paying, to the seller, recovery cost in the transaction which corresponds to at least part of the sales in the transaction so that the recovery cost increases in response to a situation where the ticket has been used.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present disclosure relates to programs, methods, and systems.

Background Art

[0002] In the distribution of tickets for various events, reselling among users is widely practiced. For example, Patent Document 1 discloses a system that facilitates matching between users in the resale of electronic tickets. In this system, by disclosing the information input by the user who wants to resell the electronic ticket to the user who wants to purchase it, the smoothness of electronic ticket transactions is achieved.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] By the way, when ticket reselling becomes active, malicious resellers who hoard a large number of tickets for the purpose of obtaining profits from reselling and drive up ticket prices will appear. If such malicious reselling prevails, the ticket price will soar extremely, making it difficult for users who actually want to participate in the event to obtain tickets. As a result, even if a large number of tickets are sold, it only means that they are hoarded by resellers who do not plan to use them, and there are no actual users using the tickets, which may lead to a situation where the event does not become lively.

[0005] An object of the present disclosure is to provide a system that promotes the sale of tickets to users who actually use the tickets.

Means for Solving the Problems

[0006] A program in one aspect of the present disclosure causes a computer processor to perform the steps of: detecting settlement of fees relating to a ticket transaction; changing information relating to the owner of the ticket relating to the transaction to another user who purchased the ticket from the seller; and paying the seller a collection fee relating to the transaction, which is equivalent to at least a portion of the sales in the transaction, the amount of the collection fee paid to the seller increases in response to the use of the ticket. [Brief explanation of the drawing]

[0007] [Figure 1] This is a block diagram showing the configuration of the information processing system in the first embodiment. [Figure 2] This is a block diagram showing the configuration of the terminal device in the first embodiment. [Figure 3] This block diagram shows the configuration of the ticket management server in the first embodiment. [Figure 4] This figure shows the configuration of the distributed ledger system in the first embodiment. [Figure 5] This figure shows an example of the data structure of a distributed ledger managed by the distributed ledger system in the first embodiment. [Figure 6] This is a diagram illustrating ticket distribution. [Figure 7] This diagram illustrates the circulating price of tickets between users in the first embodiment. [Figure 8] This figure shows an example of the data structure of a user database. [Figure 9] This figure shows an example of the data structure of an event database. [Figure 10] This figure shows an example of the data structure of a ticket master database. [Figure 11] This figure shows an example of the data structure of a ticket database. [Figure 12] This figure shows an example of the data structure of a transaction history database. [Figure 13]This is a diagram for explaining the processing when a ticket related to a transaction is used in the first embodiment. [Figure 14] This is a diagram for explaining the processing when a ticket related to a transaction is not used in the first embodiment. [Figure 15] This is a diagram for explaining the processing when a ticket related to a modification example is used. [Figure 16] This is a diagram for explaining the distribution of tickets to which the system according to the second embodiment is applied. [Figure 17] This is a diagram for explaining the distribution price of tickets according to the second embodiment. [Figure 18] This is a diagram showing an example of the data structure of the transaction history database according to the second embodiment.

Modes for Carrying Out the Invention

[0008] <First Embodiment> Hereinafter, the first embodiment of the present invention will be described in detail based on the drawings. In the drawings for explaining the embodiments, the same reference numerals are generally assigned to the same components, and the repeated description thereof will be omitted.

[0009] (1) Configuration of Information Processing System 1 The configuration of the information processing system 1 (hereinafter simply referred to as the system 1) according to the present embodiment will be described. FIG. 1 is a block diagram showing the configuration of the system 1 according to the first embodiment.

[0010] As shown in FIG. 1, the system 1 includes terminal devices 10 (including 10A and 10B), a ticket management server 20, and a distributed ledger system 50. The terminal devices 10, the ticket management server 20, and the distributed ledger system 50 are connected via a network (for example, the Internet) NW.

[0011] The terminal device 10 is an example of an information processing device that transmits requests to the ticket management server 20 or the distributed ledger system 50. The terminal device 10 is, for example, a smartphone, a tablet terminal, or a personal computer. The system 1 includes a plurality of terminal devices 10. Note that the terminal devices may include the following terminals. · IoT device · Wearable device (a terminal used by being worn on a user's body, such as smart glasses, a smartwatch, a smart speaker, a head-mounted display, smart home appliances, smart wear, a smart wig, etc.) · Implantable device (a terminal used by being built into a user's body, such as a nanobot, a smart eye, a smart contact lens, etc.)

[0012] The ticket management server 20 is an example of an information processing device. The ticket management server 20 provides a response corresponding to a request transmitted from the terminal device 10 to the terminal device 10. The ticket management server 20 is, for example, a web server. The ticket management server 20 is communicatively connected to a terminal used by an issuer described later.

[0013] The distributed ledger system 50 manages a distributed ledger in response to a request from the terminal device 10 or the ticket management server 20.

[0014] (1-1) Configuration of the terminal device 10 The configuration of the terminal device 10 will be described. FIG. 2 is a block diagram showing the configuration of the terminal device 10 according to the first embodiment.

[0015] As shown in FIG. 2, the terminal device 10 includes a storage device 11, a processor 12, an input / output interface 13, and a communication interface 14. The terminal device 10 is connected to a display 15.

[0016] The storage device 11 is configured to store programs and data. The storage device 11 is, for example, a combination of ROM (Read Only Memory), RAM (Random Access Memory), and storage (e.g., flash memory or hard disk).

[0017] The program includes, for example, the following: • OS (Operating System) programs • Programs for applications that perform information processing (e.g., web browsers)

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

[0019] The processor 12 is a computer that realizes the functions of the terminal device 10 by launching programs stored in the memory device 11. The processor 12 is, for example, at least one of the following: ·CPU(Central Processing Unit) ·GPU(Graphic Processing Unit) ·ASIC(Application Specific Integrated Circuit) ·FPGA(Field Programmable Array)

[0020] The input / output interface 13 is configured to acquire information (e.g., user instructions) from an input device connected to the terminal device 10 and to output information (e.g., an image) to an output device connected to the terminal device 10. Input devices include, for example, keyboards, pointing devices, touch panels, or combinations thereof. The output devices are, for example, a display 15, a speaker, or a combination thereof.

[0021] The communication interface 14 is configured to control communication between the terminal device 10 and an external device (for example, a ticket management server 20 or a distributed ledger system 50).

[0022] The display 15 is configured to display images (still images or moving images). The display 15 is, for example, a liquid crystal display or an organic EL display.

[0023] (1-2) Configuration of ticket management server 20 The configuration of the ticket management server 20 will now be described. Figure 3 is a block diagram showing the configuration of the ticket management server 20 according to the first embodiment.

[0024] As shown in Figure 3, the ticket management server 20 includes a storage device 21, a processor 22, an input / output interface 23, and a communication interface 24.

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

[0026] The program includes, for example, the following: • OS programs • Programs for applications that perform information processing.

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

[0028] The processor 22 is a computer that implements the functions of the ticket management server 20 by launching programs stored in the storage device 21. The processor 22 is, for example, at least one of the following: ·CPU GPU ASIC •FPGA

[0029] The input / output interface 23 is configured to acquire information (user instructions) from an input device connected to the ticket management server 20 and to output information (e.g., an image) to an output device connected to the ticket management server 20. Input devices include, for example, keyboards, pointing devices, touch panels, or combinations thereof. Output devices include, for example, displays, speakers, or a combination thereof.

[0030] The communication interface 24 is configured to control communication between the ticket management server 20 and external devices (for example, terminal devices 10 and distributed ledger system 50).

[0031] (1-3) Configuration of the distributed ledger system 50 The configuration of the distributed ledger system 50 will now be described. Figure 5 is a diagram showing the configuration of the distributed ledger system 50 according to the first embodiment.

[0032] As shown in Figure 5, the distributed ledger system 50 comprises multiple node computers 55-1 to 55-4.

[0033] The node computers 55 are connected to each other via a network (which may include the network NW in Figure 1). In this embodiment, the network may include a public network, a private network, a dedicated line, a VPN (Virtual Private Network), or a combination thereof. The node computers 55 are connected to the network, for example, by wire or wireless. The node computers 55 communicate with each other in a peer-to-peer manner.

[0034] Node computer 55 manages a distributed ledger using, for example, blockchain technology. Specifically, one of the node computers 55 acquires data related to the token transactions to be recorded. Node computer 55 creates a block containing the acquired data and adds it to the blockchain. Node computer 55 sends the information of the added block to other node computers 55. Other node computers 55 verify the correctness of the received block, and if the verification is successful, add the block to the blockchain. Node computer 55 then finalizes the blockchain, for example, according to the number of linked blocks (number of confirmations). This ensures that the same distributed ledger is stored across multiple node computers 55 that constitute the distributed ledger system 50. The stored data is encrypted as appropriate.

[0035] The configuration of the distributed ledger system 50 is not limited to that shown in Figure 5. For example, the distributed ledger system 50 may have five or more node computers 55, or it may have two or three node computers 55. Also, the number of node computers 55 constituting the distributed ledger system 50 may change over time.

[0036] The hardware configuration of the node computer 55 may be the same as or similar to that of any of the terminals or servers described above, so a detailed explanation is omitted. As an example, the node computer 55 includes a processor, storage device, input / output interface, communication interface, input device, output device, or a combination thereof.

[0037] Next, the data structure of the distributed ledger according to this embodiment will be described. Figure 5 shows an example of the data structure of the distributed ledger. As shown in Figure 5, in the distributed ledger of System 1, the information recorded in the token is stored in the distributed ledger. The distributed ledger stores unique information linked to the ledger ID, which is associated with transaction information, which is the history of transactions. Examples of unique information linked to the ledger ID include the following. Note that the ledger ID is synonymous with the ticket ID, and the same identification information may be shared. • Ticket ID: This is the identification information for the ticket; it is not required if the ledger ID is shared. • Issuance date and time… The date and time the token was issued. • Issuer information… Information about the person who initially issued (minted) the token. • Digital content address: Address information where digital content data is stored.

[0038] Furthermore, information regarding the ticket owner is recorded in the transaction data of the latest block on the blockchain linked to the ledger ID. Past transaction history is also accumulated as transaction data for all blocks. Furthermore, as shown in the diagram, the data for the digital content may be stored within the blockchain or on an external server.

[0039] Furthermore, distributed ledgers incorporate contract data that automatically executes processes according to pre-defined rules. Contract data is a computer protocol that performs calculations on input information according to algorithms set in the recorded source code and outputs the results. For example, a smart contract may take an operation related to changing the information of the ticket owner as input and automatically execute the exchange of payment for the ticket transaction. Alternatively, a smart contract may take an operation related to the exchange of payment for the ticket transaction as input and automatically execute the change of information of the ticket owner.

[0040] Additionally, a smart contract may, upon detection of ticket usage, execute a payment of a reward related to that ticket usage. Rewards related to ticket usage will be discussed later. Additionally, the smart contract may, upon detection of the expiration of a ticket's validity period, pay the organizer the amount that was planned as a reward for using the ticket. Thus, the distributed ledger managed by the distributed ledger system 50 is equipped with contract data that automatically executes processes according to pre-set rules, and the distributed ledger system 50 can automatically process payments related to ticket transactions.

[0041] A distributed ledger consists of blocks that make up contract data and blocks that contain at least hash values ​​and transaction data. When tokens are transferred between users, new transaction data is generated, and after verification by multiple node computers 55-1 to 55-4 as shown in Figure 5, a new block is added. Furthermore, the distributed ledger, which is a blockchain, may utilize both public and private blockchains. In other words, it may be configured with multiple layers, such as recording transaction history on a private blockchain for normal transactions and periodically reflecting the latest information on a public blockchain.

[0042] (2) Outline of the Embodiment An overview of the first embodiment will be described. Events that are covered by tickets managed by System 1 include, for example, the following: • Concerts, live music events, etc. • Sports events such as ball games, swimming, and martial arts (including professional leagues and amateur competitions) • Game tournaments held at real-world event venues • Entertainment events including stage plays, stand-up comedy, rakugo (traditional Japanese storytelling), and other performing arts. • Trade fairs, product exhibitions, flea markets, and other exhibitions • World Expos, regional expositions, and other exhibitions • Exhibitions such as art exhibitions and natural history exhibitions Public gambling • Local festivals, commemorative events, and other events organized by local governments. • School festivals, club and group presentations • Various events held at amusement parks • Events held for a limited time in department stores or public areas. The content of the event is not limited to those described above. Furthermore, the event may be held regularly, irregularly, or continuously. In the following explanation, we will use a concert as an example of an event.

[0043] (2-1) The realities and challenges of ticket distribution Figure 6 is a schematic diagram illustrating ticket distribution. As shown in Figure 6, tickets for various events (including paper and electronic tickets) are sold to users who wish to purchase tickets by ticket sales agents who are entrusted with selling tickets by the event organizers. In this case, the regular selling price of the tickets to users is generally set by the event organizers as the face value.

[0044] As illustrated, there are multiple possible scenarios for ticket distribution channels. Case 1: When a user who intends to use the ticket purchases it (Ticket A) This distribution channel, where individuals purchase and use tickets for their own purposes, is the most common scenario. Transactions through this channel are desirable for event organizers because the number of tickets sold reflects the expected number of attendees.

[0045] Case 2: Purchasing tickets in bulk for friends and acquaintances (Tickets B-D) This distribution channel, for example, involves purchasing tickets for companions in bulk, and is not limited to paper tickets; it is also commonly used for electronic tickets. Transactions through this distribution channel are desirable for event organizers because the number of tickets sold corresponds to the expected number of attendees.

[0046] Case 3: Cases where resale is carried out by a reseller (including professional resellers) whose sole purpose is resale (Tickets E-I) This distribution channel involves scalpers who are solely responsible for profiting from reselling tickets. In this scenario, it is assumed that scalpers purchase a large number of tickets. If the tickets fail to sell due to excessively inflated prices, the unsold tickets will go unused. This can lead to a discrepancy between the number of tickets sold and the expected number of attendees. Furthermore, when tickets are hoarded and prices are inflated, the distribution of tickets to users who genuinely wish to attend the event is hindered. Thus, the involvement of unscrupulous resellers in the distribution channels can become a breeding ground for reducing event attendance, making this type of transaction undesirable for event organizers.

[0047] In other words, to avoid the undesirable situation for event organizers of a discrepancy between the number of tickets sold and the number of event attendees, it is effective to promote ticket sales to users who actually intend to use the tickets. To address these challenges, System 1 manages information about tickets tradable between users (including paper tickets) as non-fungible tokens, thereby facilitating the sale of tickets to users who actually intend to use them. Furthermore, System 1 is expected to help ensure fair market prices in transactions between users. As shown in Figure 6, System 1 primarily applies to ticket transactions between users, including resale. However, System 1 may also be applied to primary distribution from event organizers to ticket sales agents.

[0048] Here, a token is data with asset value, and in this embodiment, it refers to data that constitutes information about an electronic ticket or a paper ticket. In this embodiment, information about the owner of a token is recorded in a distributed ledger managed by the distributed ledger system 50, so that it is always clear who the owner of the ticket is.

[0049] Generally, fungible tokens refer to data that is treated as an asset equivalent to money, such as cryptocurrencies or points. On the other hand, non-fungible tokens include, for example, digital content data such as text data commented on a social networking service (SNS), or address information (such as a URL) indicating the address where such digital content data is stored. In this case, the data related to the digital content itself can be arbitrarily copied by a third party. On the other hand, even if the original text data on the SNS is copied and reused, the owner can be clearly identified because the owner is recorded in the distributed ledger.

[0050] In this invention, the digital content included in the token may include, for example, a digital image showing information about an electronic ticket (e.g., a ticket image), a digital video that is a perk of the ticket, or a digital audio source. The ticket image may display information about various events that can be attended by possessing the electronic ticket. Thus, the digital content linked to the token may be stored, for example, within a distributed ledger, or on an external server that manages the digital content. In this invention, we will explain an example of how to handle non-fungible tokens as tokens that constitute information about tickets.

[0051] Furthermore, tokens may be traded on a system that exists outside the distributed ledger system 50 (for example, sometimes called a private chain or second layer). In this case, the ticket transaction can be carried out using information that identifies the system in which the tickets held by the user are actually being traded, and the customer's wallet information in that system.

[0052] (2-2) Ticket market price in System 1 Next, we will explain the ticket market price in user-to-user distribution (resale) using System 1. Figure 7 illustrates the ticket transaction price between users in the first embodiment. As shown in Figure 7, in ticket sales using System 1, the share of those involved in the transaction changes depending on whether (1) the ticket is used or (2) the ticket is not used.

[0053] First, a commission is charged on the market price (the selling price in resale) based on a predetermined commission rate, consisting of the various expense items described below. The difference between the market price and the commission (sales basis) is paid to the seller upon completion of the transaction. In the example shown, the commission is set at 40% of the market price. Note that the commission rate can be changed as needed.

[0054] Next, we will explain the breakdown of fees, separating them based on whether or not a ticket was used. First, we will explain the breakdown of fees when a ticket is used.

[0055] (1) Breakdown of fees when a ticket is used • Amount collected by the organizer: The organizer's share; in the illustrated example, it is free. • System usage fee: A fee paid to the system provider who manages and provides System 1, based on a predetermined system usage fee rate (10% of the market price in the illustrated example). • User Reimbursement Fee: A fee paid to ticket users as a reward based on a predetermined reimbursement rate, in recognition of their use of the ticket (10% of the market price in the illustrated example). • Usage valuation: A fee paid to the seller of a ticket as compensation, based on a predetermined payment ratio, to assess that the ticket has been used (20% of the market price in the illustrated example). In other words, in this case, the recovery costs that the seller can recover through the transaction will be the sales basis amount and the usage valuation amount.

[0056] The system usage fee rate, return rate, and payment ratio mentioned above are merely examples, and these ratios can be changed at will within the scope of the fees. In other words, by changing these ratios, the organizer may be charged a fee when a ticket is used. Alternatively, either the system usage fee rate or the return rate may be set to 0%.

[0057] Next, I will explain the breakdown of fees incurred when tickets are not used. (2) Breakdown of fees if tickets are not used • Amount collected by the organizer: The organizer's share, 30% in the example shown. • System usage fee: Same as above, no change. • Costs to be returned to users: None • Usage valuation: None In other words, if the ticket is used, the rebate fee that was to be paid to the user and the usage valuation that was to be paid to the seller will be paid to the organizer if the ticket is not used. In this case, the only recovery fee that the seller can recover through the transaction will be the sales basis amount.

[0058] Furthermore, for example, the system usage fee may be different when a ticket is not used compared to when a ticket is used. Furthermore, if the ticket is not used, a portion of the fee, less than the estimated usage value, may be paid to the seller as an additional payment.

[0059] For example, in the example shown in the lower table of Figure 7, User A (reseller) resells a ticket purchased for 4,000 yen to User B (buyer) for 6,000 yen. In this case, the costs incurred when the ticket is used are as follows: • Transaction price: 6,000 yen • Sales threshold: 3,600 yen (seller's share) • System usage fee: 600 yen (system provider's share) • Rebate fee: 600 yen (user's share) • Estimated usage value: 1200 yen (seller's share) • Amount collected by the organizer: 0 yen (organizer's share) In other words, if the ticket is used, user A, the seller, will be paid 4,800 yen as a recovery fee, which is the sum of the sales base amount and the usage valuation amount. Comparing this amount with the purchase price of 4,000 yen, which corresponds to the previous market price, user A will make a profit of 800 yen from this transaction. On the other hand, User B can receive a payment of 600 yen, equivalent to the rebate fee, as a profit that could not be obtained through conventional resale.

[0060] On the other hand, in the example shown in the table at the bottom of Figure 7, the costs incurred when the tickets were not used are as follows: • Transaction price: 6,000 yen • Sales threshold: 3,600 yen (seller's share) • System usage fee: 600 yen (system provider's share) • Rebate fee: None (user's share) • Usage valuation: None (seller's share) • Amount collected by the organizer: 1800 yen (organizer's share) In other words, if the ticket is not used, User A, the seller, will be paid 3,600 yen, which is the sales basis amount, as a recovery fee. Comparing this amount with the purchase price of 4,000 yen, which corresponds to the previous market price, User A will incur a loss of 400 yen. On the other hand, the organizers can receive a payment of 1,800 yen, equivalent to the amount collected by the organizers, as a profit they would not be able to obtain through conventional resale.

[0061] Thus, in System 1, the use of tickets increases the recovery costs received by the seller in ticket transactions. This provides an incentive for ticket sellers to sell to users who are highly likely to actually use the tickets. Furthermore, since a portion of the profits from resale is returned to the ticket holder, it encourages users who purchased tickets to actually use them. Also, because a portion of the profits from resale is returned to the ticket holder, even if ticket prices skyrocket due to resale, the return of funds can partially compensate for this, thus giving preferential treatment to users who actually want to attend the event (users who want to use their tickets).

[0062] Furthermore, in conventional resales, regardless of whether the ticket was used or not, the seller (User A in the example in Figure 7) received 2,000 yen, which was the difference between the resale price and the market price. In contrast, in System 1, a portion of the profits generated from the resale may be distributed to both the organizer and the user (User B). Therefore, it is expected that extreme price increases in the market price of tickets can be effectively suppressed, contributing to the healthier state of ticket transactions.

[0063] (3) Database The databases according to the first embodiment will be described below.

[0064] (3-1) User Database 211 The user database (DB) 211 according to the first embodiment will now be described. Figure 8 shows the data structure of the user DB 211 according to the first embodiment. The user DB 211 is stored in the storage device 21 of the ticket management server 20.

[0065] User DB211 is a database that stores and manages information about users. New records are recorded in User DB211 when a user joins System 1. User DB211 includes the fields "User ID", "Name", "User Attribute Information", "Contact Information", "Seller Score", and "User Score". Note that the data items included in user DB211211 can be changed at will.

[0066] The "User ID" field stores identification information to identify a user. Each user has a unique User ID value.

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

[0068] The "User Attribute Information" field stores the user's attribute information (gender, age, occupation, place of residence, nationality, language spoken) corresponding to the user ID.

[0069] The "Contact Information" field stores the means of contact (such as an email address) for the user corresponding to the user ID.

[0070] The "Seller" score is a field that stores a score evaluating a user's performance as a ticket seller, corresponding to a user ID. The seller score is calculated based on at least one of the following values: past ticket transaction history and the usage rate of tickets that were actually used. The seller score is an attribute that changes according to the user's ticket sales performance.

[0071] The reason organizers want to evaluate users' ticket sales performance is that they want to reward sellers who sell to users who will actually use their tickets. In other words, they want to reward sellers who sell a large number of tickets, and also sellers who, even if they sell fewer tickets, do not have any unused tickets. Therefore, by automatically setting commissions and payment ratios according to sales performance, organizers can reward sellers who conduct sales in a way that is best suited to them.

[0072] Examples of seller scoring methods include the following: • For sellers who sell in large quantities, we will increase the payment ratio. • If a large percentage of the tickets sold are used, the payment ratio will be increased. • Increase the payment ratio if there is a high sales record to new users. • Combine the above performance data to adjust the payment ratio.

[0073] The "User" score field stores a score that evaluates the ticket usage performance of a user corresponding to a user ID. The user score is calculated based on at least one of the following values: past ticket purchase history and past ticket usage history. The user score is an attribute that changes according to the user's ticket usage history.

[0074] The reason organizers want to evaluate users' ticket usage is that they want to attract users who will actually use their tickets. In other words, they want to encourage more active event participation by rewarding frequent ticket users. Therefore, by automatically setting the return rate based on ticket usage history, organizers can reward valuable ticket users.

[0075] (3-2) Event Database 212 The event database (DB) 212 according to the first embodiment will now be described. Figure 9 shows the data structure of the event DB 212 according to the first embodiment. The event DB 212 is stored in the storage device 21 of the ticket management server 20.

[0076] EventDB212 is a database that stores and manages information about events. New records are added to EventDB212 when an event organizer hosts a new event.EventDB212 includes the following fields: Event ID, Event Type, Event Name, Organizer, Performers, Date, Venue, and Schedule Information. Note that the data items included in Event DB212 can be changed as desired.

[0077] The "Event" field stores identification information to identify an event. The Event ID is a field with a unique value assigned to each event.

[0078] The "Event Type" field stores the type of event corresponding to the event ID. Examples of event types include "Concert," "Sports," "Exhibition," and "Music Festival."

[0079] The "Event Name" field stores the name of the event corresponding to the event ID.

[0080] The "Organizer" field stores information about the organizer of the event corresponding to the event ID.

[0081] The "Performers" field stores information about the performers for the event corresponding to the event ID. For example, if the event is a concert, the names of the performing artists will be stored there.

[0082] The "Date" field stores the date of the event corresponding to the event ID.

[0083] The "Venue" field stores the venue for the event corresponding to the event ID.

[0084] The "Schedule Information" field stores information about the various schedules for the event corresponding to the event ID on the day of the event. These schedules include opening time, start time, end time, and closing time.

[0085] (3-3) Ticket Master Database 213 The ticket master database (DB) 213 according to the first embodiment will now be described. Figure 10 shows the data structure of the ticket master DB 213 according to the first embodiment. The ticket master DB 213 is stored in the storage device 21 of the ticket management server 20.

[0086] Ticket Master DB213 is a database that stores and manages master data about the content of each type of ticket, which forms the basis for creating ticket data. New records are recorded in Ticket Master DB213 as the organizer decides on the content of the tickets to be sold for an event. Ticket Master DB213 includes the fields "Ticket Type ID", "Event ID", "Seat Information", "Wholesale Price", "List Price", "Commission Rate", "Rebate Rate", "Rebate Rate", and "System Usage Fee Rate". Note that the data items included in the ticket master DB213 can be changed as desired.

[0087] The "Ticket Type ID" field stores identification information to identify the type of ticket. Each ticket type has a unique value assigned to it.

[0088] The "Event ID" field stores the event for which the ticket type corresponding to the ticket type ID applies.

[0089] The "Seat Information" field stores information about the seats permitted by the ticket type corresponding to the ticket type ID. The seat information may also include the area of ​​entry.

[0090] The "Wholesale Price" field stores the wholesale price paid by the organizer to the ticket sales agent (play guide) entrusted with selling tickets of the type corresponding to the ticket type ID.

[0091] The "List Price" field stores the initial selling price set by the organizer for the ticket type corresponding to the ticket type ID. The list price is determined, for example, by the organizer.

[0092] The "Commission Rate" field stores the percentage of the commission charged relative to the market price in transactions for tickets of the type corresponding to the ticket type ID. The commission rate is pre-set.

[0093] The "Payment Ratio" field is used to calculate the usage valuation amount paid to the ticket seller when a ticket of the type corresponding to the ticket type ID is used, and stores the ratio to the market price. The payment ratio is pre-set.

[0094] The "Rebate Rate" field is used to calculate the rebate fee paid to the ticket user for tickets of the type corresponding to the ticket type ID, and stores the ratio to the market price. The rebate rate is pre-set.

[0095] The "System Usage Fee Rate" field stores the ratio to the market price used to calculate the usage fee for System 1 paid to the system provider. The system usage fee rate is pre-set.

[0096] (3-4) Ticket Item Database 214 The ticket item database (DB) 214 according to the first embodiment will now be described. Figure 11 shows the data structure of the ticket item DB 214 according to the first embodiment. The ticket item DB 214 is stored in the storage device 21 of the ticket management server 20.

[0097] Ticket DB214 is a database that stores and manages information about tickets. New records are recorded in Ticket DB214 based on the settings of tickets scheduled for sale. Ticket DB214 includes the fields "Ticket ID", "Ticket Type ID", "Sales Status", "Ticket Inspection Status", "Ledger ID", and "Digital Content Address". Note that the data items included in the ticket item DB214 can be changed as desired.

[0098] The "Ticket ID" field stores identification information for identifying a ticket. Each ticket has a unique Ticket ID value.

[0099] The "Ticket Type ID" field stores identification information about the type of ticket corresponding to the ticket ID.

[0100] The "Sales Status" field stores the sales status of the ticket corresponding to the ticket ID. Sales statuses include "Before Sale," "On Sale," and "Sold Out."

[0101] The "Ticket Inspection Status" field stores the usage status of the ticket corresponding to the ticket ID. The ticket usage status can be "Unused" or "Used".

[0102] The "Ledger ID" field stores the identification information of the distributed ledger where the ticket owner's information corresponding to the ticket ID is registered. If the ticket ID and ledger ID are the same, this field is omitted.

[0103] The "Digital Content Address" field stores the address information of the server where the data for the digital content associated with the ticket corresponding to the ticket ID is stored.

[0104] (3-5) Transaction History Database 215 The transaction history database (DB) 215 according to the first embodiment will now be described. Figure 12 shows the data structure of the transaction history DB 215 according to the first embodiment. The transaction history DB 215 is stored in the storage device 21 of the ticket management server 20.

[0105] Transaction History DB215 is a database that stores and manages information related to ticket transactions. New records are created in Transaction History DB215 whenever a ticket transaction takes place between users. Transaction history DB215 includes the following fields: Transaction ID, Ticket ID, Seller User ID, Buyer User ID, Number of Transactions, Market Price, Commission, Sales Base Amount, Usage Valuation, Payment Expenses, Transaction Date and Time, and Ticket Score. Note that the data items included in the transaction history DB215 can be changed at will.

[0106] The "Transaction ID" field stores identification information to distinguish transactions between users. Each transaction between users has a unique Transaction ID value.

[0107] The "Ticket ID" field stores the identification information of the ticket that corresponds to the transaction ID.

[0108] The "Seller User ID" field stores the identification information of the user who sold the ticket in the transaction corresponding to the transaction ID.

[0109] The "Purchasing User ID" field stores the identification information of the user who purchased the ticket in the transaction corresponding to the transaction ID.

[0110] The "Transaction Count" field stores which transaction number corresponds to the ticket with the ticket ID, in the transaction with the transaction ID.

[0111] The "Market Price" field stores the market price for the ticket corresponding to the ticket ID in this transaction.

[0112] The "Fee" field stores the fee charged for the transaction corresponding to the transaction ID. The fee is calculated by multiplying the market price by the fee rate.

[0113] The "Sales Base Amount" field stores the amount of fees paid to the ticket seller upon completion of a transaction corresponding to the transaction ID. The sales base amount is calculated as the difference between the market price and the commission fee.

[0114] The "Usage Value" field stores the amount of fees paid to the ticket seller in response to the detection of ticket usage related to the transaction corresponding to the transaction ID. The usage value is calculated by multiplying the market price by the payment ratio.

[0115] The "Rebate Cost" field stores the cost reimbursed to users who use the ticket corresponding to the ticket ID. The rebate cost is calculated by multiplying the market price by the rebate rate.

[0116] The "Transaction Date and Time" field stores the date and time when the settlement process for the transaction corresponding to the transaction ID was completed.

[0117] The "Ticket Score" item is managed as an attribute related to the ticket associated with the transaction corresponding to the transaction ID. The ticket score is calculated based on at least one of the following values: ticket face value, number of transactions, number of tickets sold, number of tickets sold, and time elapsed since the start of sales. The ticket score is an attribute that changes depending on the conditions or performance of the ticket transaction.

[0118] (4) Information processing Information processing according to the first embodiment will be described.

[0119] (4-1) Processing when a ticket related to a transaction is used The processing when a ticket is used in a ticket transaction according to the first embodiment will be explained. Figure 13 is a diagram illustrating the processing when a ticket is used in a transaction according to the first embodiment. In this diagram, the user who is the seller is a person who purchases tickets at face value from a ticket sales agent commissioned by the organizer for legitimate sales and resells the tickets to other users.

[0120] First, let me explain about ticket transfers. As shown in Figure 13, the ticket transfer process can be initiated, for example, based on an agreement between users. Various methods for obtaining user agreement regarding ticket transfers are envisioned, as described below. • Determination of buyers and market prices through auction • Purchase requests from users interested in buying at the market price specified by the seller. • Sales application from seller in response to a transfer request from a prospective buyer. Furthermore, by making the user score of prospective buyers available to sellers, sellers could select users who are likely to actually use the tickets as recipients. In this case, users who have actively used the tickets in the past could be given preferential treatment based on their usage history.

[0121] In ticket transfer, the seller (user) sends the ticket to the user who wishes to purchase it (Step S101). Specifically, the seller (user) operates the terminal device 10 to input an instruction to the distributed ledger system 50 to change the owner of the ticket they hold to the user who wishes to purchase it.

[0122] In other words, the terminal device 10 instructs the distributed ledger system 50 to change the information of the ticket owner recorded on the blockchain corresponding to the ledger ID in the individual ticket DB 214 from information about the user to information about the user who wishes to purchase the ticket. Here, user information refers, for example, to the seller's wallet information that identifies the seller in a distributed ledger. Furthermore, information about users who wish to make a purchase includes, for example, the wallet information of a user who wishes to make a purchase in a distributed ledger.

[0123] As a result, the distributed ledger system 50 changes the information of the ticket owner. Specifically, the distributed ledger system 50 changes the information of the token owner recorded on the blockchain corresponding to the ledger ID from information about the user to information about the user who wishes to purchase it. The distributed ledger system 50 notifies the user who is the purchaser that the ticket owner's information has been changed. This allows the user, who is the purchaser, to receive information about the ticket (such as the URL to access the ticket itself).

[0124] Next, I will explain the exchange of consideration in a transaction. As shown in Figure 13, the exchange of consideration for a transaction begins in response to the completion of the transaction. In the exchange of consideration for a transaction, the user, who is the buyer, pays the costs related to the transaction (step S201). Payment of transaction fees may be automatically made in response to the sending of tickets using crypto assets (fungible tokens) operated in the distributed ledger system 50.

[0125] In step S201, at least a portion of the fees, including the system usage fee, is paid to the system provider (step S202). Specifically, the distributed ledger system 50 changes the information of the owners of crypto assets equivalent to at least a portion of the fees, including system usage fees, from the wallet information of the user who purchased the asset to the wallet information of the system provider. In the example in Figure 7, the entire fee is paid to the system provider. That is, in the example in Figure 7, the system usage fee, the cost of refunding the ticket user, and the usage valuation amount paid to the seller upon use of the ticket are temporarily paid to the system provider.

[0126] In step S201, the organizer is paid a portion of the commission equivalent to the initial collection amount that the organizer collects upon completion of a transaction (step S203). Specifically, the distributed ledger system 50 changes the information of the owner of the cryptocurrency equivalent to the initial collection amount from the wallet information of the user who purchased it to the wallet information of the system provider. In the example in Figure 7, the initial collection amount is 0, so this payment is not made.

[0127] In addition, in step S201, the seller is paid an amount equivalent to the sales threshold (step S204). Specifically, the distributed ledger system 50 changes the information of the owner of the cryptocurrency equivalent to the sales threshold from the wallet information of the buyer user to the wallet information of the seller user. This completes the exchange of payment for the transaction. Furthermore, the exchange of payment for the transaction may take place before the transfer of the tickets is processed.

[0128] Next, I will explain the payment of compensation. As shown in Figure 13, the distribution of fees is initiated in response to the use of the ticket by the user who purchased it (step 301). In the distribution of fees, the organizer detects the use of the ticket, for example, by conducting a ticket verification process for users who have come to the event venue (S302).

[0129] After step S302, system 1 makes a payment for the use of the ticket (step S303). Specifically, system 1 uses the distributed ledger system 50 to change the information of the owner of the cryptocurrency equivalent to the rebate fee from the system provider's wallet information to the user's wallet information. As a result, the rebate fee is paid to the user who is the ticket user (purchaser) (step S304).

[0130] Furthermore, in step S303, System 1, using the distributed ledger system 50, changes the information of the owner of the cryptocurrency equivalent to the usage valuation from the system provider's wallet information to the seller's wallet information. As a result, the usage valuation is paid to the user who is the ticket seller (step S305). The payment process is now complete.

[0131] (4-2) Handling of cases where the ticket related to the transaction is not used. The following describes the processing in the case where the ticket involved in a transaction is not used, according to the first embodiment. Figure 14 is a diagram illustrating the processing in the case where the ticket involved in a transaction is not used, according to the first embodiment. In this diagram, the processing of ticket transfer and the processing of payment are the same as in Figure 14, so their explanation is omitted.

[0132] This explains the additional fees payable by the organizers. The organizer pays an additional fee in response to the expiration of the ticket's validity period. First, the organizer detects the expiration of the ticket's validity period (step S401). Here, the ticket's validity period is information that is pre-set as schedule information, such as the time when entry to the event venue ends, or the time when viewing of an online event ends.

[0133] After step S401, system 1 makes a payment to the organizer for the ticket fees (step S402). Specifically, system 1, using the distributed ledger system 50, changes the information of the owners of the crypto assets equivalent to the rebate fee and usage valuation from the system provider's wallet information to the organizer's wallet information. In other words, because the tickets were not used, the amount equivalent to the rewards that would have been paid to the seller and user is paid to the organizer as a fee. The organizer receives the additional fee paid (step S403). This completes the payment of additional fees to the organizer.

[0134] (4-3) Processing related to modified examples The processing of System 1 in the modified example will now be explained. Figure 15 is a diagram illustrating the processing when a ticket in the modified example is used. In this diagram, the flow of the ticket transfer process and the exchange of consideration process is the same as in Figure 13, so the explanation will be omitted.

[0135] On the other hand, the amount paid in exchange for consideration differs from the example in Figure 13 mentioned above. In step S202B shown in Figure 15, the amount paid to the system provider is limited to the system usage fee only. Then, in step S203B, the amount paid to the organizer includes the rebate fee and the usage evaluation amount.

[0136] In the payment of rewards, when a user uses a ticket (step S501), the organizer detects the use of the ticket, for example, by checking the ticket of the user who has come to the event venue (S502).

[0137] After step S502, system 1 makes a payment for the use of the ticket (step S503). Specifically, system 1 uses the distributed ledger system 50 to change the information of the owner of the cryptocurrency equivalent to the rebate fee from the organizer's wallet information to the user's wallet information. As a result, the rebate fee is paid to the user who is the ticket user (purchaser) (step S504).

[0138] Furthermore, in step S503, System 1, using the distributed ledger system 50, changes the information of the owner of the cryptocurrency equivalent to the usage valuation from the organizer's wallet information to the seller's wallet information. As a result, the usage valuation is paid to the user who is the ticket seller (step S505). With the above steps completed, the payment process for the reward is finished.

[0139] Furthermore, in this modified version, the organizer receives a lump sum payment of the commission minus the system usage fee upon completion of the transaction. Therefore, if the ticket is not used, there is no need for additional payment. As shown in Figure 14, this method reduces the hassle of processing monetary payments compared to the method in which the usage valuation amount and rebate costs are paid to the system provider in a one-time payment.

[0140] Furthermore, the processing of monetary payments is not limited to these examples. For example, the payment of collection costs to the seller may be made in a single payment. That is, if the ticket was used, based on whether the ticket's expiration date had passed, the seller may be paid a lump sum equivalent to the sales basis amount and the usage valuation amount. If the ticket was not used, only the amount equivalent to the sales basis amount may be paid to the seller in a lump sum.

[0141] Furthermore, upon completion of a ticket transfer transaction, a rebate fee may be paid to the ticket purchaser as an advance payment, and if the purchaser does not use the ticket, the purchaser may pay an amount equivalent to the rebate fee to the organizer. Furthermore, upon completion of a ticket transfer transaction, the buyer may pay the ticket seller an advance payment of the estimated usage value, and if the buyer does not use the ticket, the seller may pay the organizer an amount equivalent to the estimated usage value.

[0142] (5) Summary As explained above, in System 1, the use of tickets increases the seller's costs associated with ticket transactions. This provides an incentive to sell tickets to users who are likely to actually use them, resulting in an increase in event attendees, which is desirable for event organizers. This promotes ticket sales to users who will actually use the tickets.

[0143] Furthermore, since the recovery costs include both the sales basis amount and the usage evaluation amount, even if the tickets are not used, the seller can recover the sales basis amount, thus preventing sellers from being burdened with an excessive cost in ticket transactions.

[0144] Furthermore, the sales revenue is paid to the seller upon completion of the transaction, and the usage revenue is paid to the seller upon detection of the use of the ticket related to the transaction. Therefore, the seller can receive payment for a portion of the collection costs upon completion of the transaction.

[0145] Furthermore, since the commission rate is set using at least one of the ticket score and the seller score, it is possible to set the optimal commission rate by taking into account the popularity and buzz of the event, as well as the seller's past transaction history.

[0146] Furthermore, since the payment ratio is set using at least one of the ticket score and the seller score, it is possible to set an optimal payment ratio that reflects the popularity and buzz of the event, as well as the seller's past transaction history.

[0147] Furthermore, the ticket score is determined by a pre-defined formula using at least one of the following variables: the ticket's face value, the number of transactions, the number of tickets sold, the number of tickets sold, the time elapsed since sales began, and the time remaining until sales end. This allows for the assignment of an evaluation metric to tickets that reflects their price and sales performance.

[0148] Furthermore, the seller score is determined by a pre-defined formula that uses at least one of the following variables: the seller's past transaction history and the usage rate, which indicates the percentage of tickets sold that were actually used. This allows sellers to be given an evaluation metric that reflects the extent to which their past transactions contributed to the organizer's event activities.

[0149] Furthermore, in response to the detection of ticket usage, a rebate fee is paid to the ticket user. Therefore, even if ticket prices skyrocket due to resale, ticket purchasers can receive a rebate fee by using their tickets, thus prioritizing users who actually want to use their tickets.

[0150] Furthermore, since the reward rate is set using the user score, the ratio of rewards to users can be set to reflect the user's actual ticket usage.

[0151] Furthermore, the user score is determined by at least one of the following: past ticket purchase history and past ticket usage history. This allows us to provide ticket purchasers with an evaluation metric that reflects their ticket usage history.

[0152] Furthermore, upon completion of the transaction, at least a portion of the commission is paid to the organizer who issued the ticket. This allows the organizer to recover a portion of the profits generated from the resale.

[0153] Furthermore, if a ticket related to a transaction is not used, at least a portion of the commission will be paid to the organizer who issued the ticket, in response to the expiration of the ticket's validity period. This allows the organizer to recover the costs of returning the funds to the user and the additional payments to the seller.

[0154] <Second Embodiment> A second embodiment of the present invention will be described in detail below with reference to the drawings. In the drawings used to illustrate the embodiments, the same reference numerals are generally used for identical components, and repeated descriptions of them will be omitted. Figure 16 is a diagram illustrating the distribution of applicable tickets by system 2 according to the second embodiment.

[0155] As shown in Figure 16, in this embodiment, the main scope of application of System 2 extends to the primary sale from the organizer (ticket issuer) to the ticket sales agent. Furthermore, general users can also be involved in the primary distribution transactions.

[0156] Figure 17 illustrates the market price of tickets in the second embodiment. As shown in Figure 17, in System 2, a rebate is set on the gross profit, which is the difference between the selling price and the purchase price. Specifically, this will be explained by dividing it into cases depending on whether the selling price exceeds the purchase price.

[0157] (1) When the selling price exceeds the purchase price • System usage fee: A predetermined fixed amount. • Rebate cost… This is set as the amount obtained by multiplying the gross profit by the rebate rate. • Recovery costs: If the tickets are not used, the cost will be equivalent to the purchase price (if the tickets are used, the cost price + sales profit). • Sales profit… Gross profit - (System usage fee + Rebate fee) If tickets are not used, the rebate fees and sales profits will be collected by the organizer as a service fee.

[0158] (2) When the selling price does not exceed the purchase price • System usage fee: A predetermined fixed amount. • Rebate fee: None • Collection fee: The amount obtained by deducting the system usage fee from the sales price, regardless of whether the ticket is used.

[0159] Figure 18 shows an example of the data structure of the transaction history DB216 in the second embodiment. As shown in Figure 18, the transaction history DB216 has the following data items that differ from the transaction history DB215 of the first embodiment: "Purchase price", "Selling price", "Gross profit", "System usage fee", "Rebate cost", and "Sales profit".

[0160] The "Purchase Price" field stores the amount the seller paid to purchase the tickets. In the primary market, the purchase price refers to the wholesale price from the issuer.

[0161] The "Selling Price" field stores the market price in the transaction.

[0162] The "Gross Profit" field stores the difference between the selling price and the purchase price.

[0163] The item "System Usage Fee" stores a pre-set fee amount.

[0164] The item "Rebate Costs" stores the amount obtained by multiplying the gross profit by the rebate rate.

[0165] The "Sales Profit" item stores the amount obtained by deducting system usage fees and revenue sharing costs from gross profit.

[0166] Furthermore, System 2 may perform processing specifically tailored to include primary distribution, which is the distribution from the ticket issuer. For example, users whose seller score exceeds a predetermined threshold may be granted the authority to sell tickets (the authority to purchase a certain number of tickets or more).

[0167] Furthermore, in System 2, the selling price may differ depending on the stage of distribution. For example, in the secondary market, upper and lower limits on the selling price may be set, while in the tertiary market and beyond, prices may be set freely.

[0168] Furthermore, in System 2, upper and lower limits on the selling price may be set in advance. The reason for this is that extremely high ticket prices increase the likelihood of resale for speculative purposes, ultimately leading to unsold tickets that may not actually be used. On the other hand, extremely low ticket prices can damage the brand of the artists performing at the event. For this reason, it is desirable for organizers to sell tickets within a reasonable price range. Furthermore, by setting upper and lower limits on the selling price in advance, the organizer can control the market price to some extent.

[0169] Furthermore, System 2 may include a process where the organizer collects tickets that are unlikely to sell. For example, the organizer may take back tickets at a special price for tickets that are within a certain timeframe (e.g., two weeks) before the event starts. The background to this is that organizers face the challenge of wanting to avoid extreme price reductions by sellers, as mentioned earlier, in terms of damaging their brand, while also wanting to avoid a low attendance rate at the event venue. Therefore, by collecting unsold tickets and distributing them for free (or at a discounted price) to sponsoring companies or valuable customers, organizers can secure attendees while preventing brand damage. Furthermore, the organizer may change the ticket purchase price over time or depending on ticket sales. For example, the purchase price may be gradually reduced as the event approaches.

[0170] Furthermore, in System 2, which includes primary distribution, a minimum guaranteed amount may be set for recovery costs. The minimum guaranteed amount refers to the amount guaranteed as the minimum payment corresponding to the ticket transaction, regardless of whether the ticket is used or not. The minimum guaranteed amount can be arbitrarily set, such as a predetermined absolute value (e.g., 3,000 yen), the seller's purchase price of the ticket, or an amount corresponding to a predetermined ratio to the ticket's market price (e.g., 60% of the market price).

[0171] (8) Other variations The storage device 11 may be connected to the terminal device 10 via a network NW. The display 15 may be built into the terminal device 10. The storage device 21 may be connected to the ticket management server 20 via a network NW. Each of the above information processing steps can be rearranged, provided that no inconsistencies occur in the processing.

[0172] Furthermore, the return rate may be progressively changed with respect to the resale price of the tickets. Specifically, the return rate and payment ratio may be set according to the price range of the resale price, such that the return rate increases as the resale price increases, and the payment ratio to the seller decreases accordingly. For example, the return rate and payment ratio can be set as follows. • If the market price is 10,000 yen or less Discount rate: 10% of the market price Payment ratio: 20% of the market price • When the market price is between 10,000 and 15,000 yen Discount rate: 15% of the market price Payment ratio: 20% of the market price • If the market price exceeds 15,000 yen Discount rate: 20% of the market price Payment ratio: 10% of the market price This means that as the resale price of tickets increases, the payment ratio to sellers decreases, thus preventing sellers from excessively inflating ticket prices.

[0173] Furthermore, if a ticket is not used, and a portion of the fee, less than the estimated usage value, is paid to the seller as an additional payment, the recovery cost will be the sales basis amount plus the additional payment amount. Comparing the recovery costs in the case where the ticket is used with those in the case where it is used, the following relationship holds true. • (Sales basis amount + Usage valuation amount) > (Sales basis amount + Additional payment amount) In other words, the cost of recovering tickets when they are used will be higher than the cost of recovering them when they are not used.

[0174] Furthermore, various fees, usage valuation amounts, and rebate costs may be set at fixed amounts. Furthermore, the fixed price, commission rate, and return rate set for ticket distribution may be made public to ticket sellers. Ticket sellers can then decide whether or not to purchase the tickets in question based on the publicly available information.

[0175] Although the above explanation used event tickets as an example, the tickets handled by Systems 1 and 2 are not limited to events (activities, gatherings). In other words, Systems 1 and 2 can be applied to services that meet the following requirements. • The service is based on a specific concept that has a fan base. • A ticket will be issued as proof of payment for the service in question. Other services that meet these conditions include movie theaters, art galleries, museums, theaters, amusement parks, transportation, restaurants, and brand-name shops. Furthermore, systems 1 and 2 may be applied to tickets for services provided via telecommunication lines among these related services.

[0176] Although embodiments of the present invention have been described in detail above, the scope of the present invention is not limited to the embodiments described above. Furthermore, the embodiments described above can be improved or modified in various ways without departing from the spirit of the present invention. In addition, the embodiments and modifications described above can be combined. [Explanation of Symbols]

[0177] 1, 2: Information Processing Systems 10: Terminal device 10 11:Storage device 12: Processor 20: Ticket management server 21:Storage device 22: Processor 40: Token management / merchandise exchange server 41:Storage device 42: Processor 50: Distributed ledger system 55: Node Computer

Claims

1. In a computer processor, Steps to detect settlement of fees related to ticket transactions, The steps include changing the information regarding the owner of the ticket related to the transaction from the seller to another user who purchased the ticket, The steps include: paying the seller a recovery cost in the transaction, which is equivalent to a portion of the market price in the transaction; A program in which the amount of the recovery fee paid to the seller increases in response to the use of the ticket.

2. The aforementioned recovery costs are The sales base amount obtained by deducting a commission calculated based on a predetermined commission rate from the aforementioned market price, The program according to claim 1, comprising a usage valuation amount paid in accordance with the use of the ticket relating to the transaction, and calculated based on a predetermined payment ratio to the fee.

3. The step of paying the aforementioned recovery costs to the seller may be carried out in installments. The aforementioned sales threshold amount is paid to the seller in response to the completion of the aforementioned transaction. The program according to claim 2, wherein the usage valuation amount is paid to the seller in response to the detection of the use of the ticket relating to the transaction.

4. The program according to claim 2, wherein the commission rate is set using at least one of a ticket score, which is managed as an attribute that changes according to the conditions or performance of the transaction, and a seller score, which is managed as an attribute that changes according to the seller's sales performance of the tickets.

5. The program according to claim 2, wherein the payment ratio is set using at least one of a ticket score, which is managed as an attribute that changes according to the conditions or performance of the transaction, and a seller score, which is managed as an attribute that changes according to the seller's sales performance of the tickets.

6. The program according to claim 4 or 5, wherein the ticket score is determined by a pre-set calculation formula using at least one of the following variables: the list price which is the selling price of the ticket in the primary market, the number of transactions, the number of tickets sold, the number of tickets sold, the time elapsed since the start of sales, and the time remaining until the end of sales.

7. The program according to claim 4 or 5, wherein the seller score is determined by a pre-set calculation formula using at least one of the following as variables: the seller's past transaction history and the usage rate, which indicates the percentage of the tickets sold that were actually used.

8. The aforementioned processor, The program according to claim 2, which, in response to the detection of the use of the ticket relating to the transaction, causes the program to perform the step of paying the user of the ticket a rebate fee calculated based on a predetermined rebate rate to the commission.

9. The program according to claim 8, wherein the redemption rate is set using a user score, which is managed as an attribute that changes according to the user's ticket usage history.

10. The program according to claim 9, wherein the user score is determined by at least one of the user's past ticket purchase history and their past ticket usage history.

11. The aforementioned processor, The program according to claim 2, which, in response to the completion of the transaction, causes the program to perform the step of paying at least a portion of the commission to the issuer of the ticket.

12. The aforementioned processor, The program according to claim 2, which, if the ticket relating to the transaction is not used, causes the program to perform the step of paying at least a portion of the fee to the issuer of the ticket in response to the expiration of the ticket's expiration date.

13. A computer processor Steps to detect settlement of fees related to ticket transactions, The steps include changing the information regarding the owner of the ticket related to the transaction from the seller to another user who purchased the ticket, The steps include: paying the seller the collection costs in the transaction, which are equivalent to at least a portion of the sales in the transaction; A method wherein the amount of the recovery fee paid to the seller increases in response to the use of the ticket.

14. A computer processor A means for detecting the settlement of fees related to ticket transactions, A means for changing the information relating to the owner of the ticket in the aforementioned transaction from the seller to another user who purchased the ticket, The system includes means for paying the seller the collection costs in the transaction, which are equivalent to at least a portion of the sales in the transaction, The amount of the recovery fee paid to the seller increases in response to the use of the ticket.

Images