Program, method and information processing device

Abstract

To provide a program for further improving a relationship between performers and fans in an event where the number of participants is limited.SOLUTION: A program for operating a computer, causes a processor of the computer to execute the steps of: acquiring not a ticket purchase history for participating in an event where the number of participants is limited due to a size of a venue, but information regarding user behavior taken by a user related to a performer of the event; and outputting a first parameter for the user on the basis of the information regarding the user behavior.SELECTED DRAWING: Figure 20

Description

[Technical Field]

[0001] The present disclosure relates to a program, a method, and an information processing device. [Background technology]

[0002] There are techniques to improve the relationship between performers at events and their fans.

[0003] For example, Patent Document 1 describes a technology in which, when a viewing user performs a promotion operation on a broadcasting user, points corresponding to the amount of behavior in response to the promotion operation are awarded, the awarded points are added to earned points stored in memory, and a first reward corresponding to the added earned points is awarded to the viewing user. This is said to increase the viewing user's motivation to watch the broadcasting user's videos.

[0004] In Patent Document 1, a broadcasting user who is a performer broadcasts a video to a viewing user who is a fan on a broadcasting site. There is no limit to the number of participants in a video broadcasting event on such a broadcasting site.

[0005] On the other hand, for events where the number of participants is limited due to the size of the venue, if the number of applicants for the event exceeds the maximum number of participants, a lottery is held and tickets are sold to the winners. Tickets for popular events are scarce, so they can be resold to other users at high prices. As a result, an increasing number of users who are not particularly fans are applying for lotteries with the intention of reselling tickets. This means that tickets do not go to fans who really want to attend the event, and opportunities to attend the event and improve relationships between performers and fans are lost. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] Japanese Patent Publication No. 2023-075408 Summary of the Invention [Problem to be solved by the invention]

[0007] For these reasons, there is a need for technology that can further improve the relationship between performers and fans at events where the number of participants is limited.

[0008] In view of the above-mentioned problems, the present invention aims to further improve the relationship between performers and fans at events where the number of participants is limited. [Means for solving the problem]

[0009] A program for operating a computer causes a processor of the computer to perform the steps of acquiring information about user behavior taken by a user in relation to performers at an event, rather than a ticket purchase history for attending an event that has a limit on the number of participants due to the size of the venue, and outputting a first parameter about the user based on the information about the user behavior. [Effects of the Invention]

[0010] According to the present disclosure, the relationship between performers and fans can be further improved at events where the number of participants is limited. [Brief explanation of the drawings]

[0011] [Figure 1] 1 is a block diagram showing an example of the overall configuration of a system 1. FIG. [Figure 2] 1 is a block diagram illustrating an example of the configuration of a terminal device 10. FIG. [Figure 3] FIG. 2 is a diagram illustrating an example of the functional configuration of a server 20. [Figure 4] FIG. 1 is a diagram showing the configuration of a distributed ledger system 90. [Figure 5] FIG. 2 is a diagram showing the data structure of a user table 202a. [Figure 6]FIG. 10 is a diagram showing the data structure of a performer table 202b. [Figure 7] FIG. 10 is a diagram showing the data structure of an event table 202c. [Figure 8] FIG. 10 is a diagram showing the data structure of a ticket table 202d. [Figure 9] FIG. 10 is a diagram showing the data structure of an application history table 202e. [Figure 10] FIG. 10 is a diagram showing the data structure of an NFT type table 202f. [Figure 11] FIG. 10 is a diagram showing the data structure of an NFT management table 202g. [Figure 12] FIG. 10 is a diagram showing the data structure of a point condition table 202h. [Figure 13] A diagram showing an example of information associated with an NFT in a distributed ledger system 90. [Figure 14] A flowchart showing an example of the operation of the server 20 and the distributed ledger system 50 when granting an NFT corresponding to a user action to a user who has performed a specified user action. [Figure 15] A flowchart showing an example of the operation of the server 20 and the distributed ledger system 90 when calculating a first parameter based on the NFTs held by a user and holding a lottery while changing the winning rate for the lottery event according to the first parameter. [Figure 16] FIG. 10 is a diagram illustrating an example of an application list. [Figure 17] A flowchart showing an example of the operation of the server 20 and the distributed ledger system 90 when calculating a first parameter based on the NFTs held by a user, determining whether or not to accept an application to participate in a special event based on the first parameter, and notifying users who are eligible to apply for the special event of information about the special event. [Figure 18] FIG. 10 is a diagram showing an example of a guidance list. [Figure 19]A flowchart showing an example of the operation of the server 20 and the distributed ledger system 90 in the special event notification process when the possession of one or more specific types of NFTs is set as an application condition. [Figure 20] FIG. 10 is a schematic diagram showing an example of a screen displayed on the terminal device 10, showing information associated with an NFT held by a user. [Figure 21] 10 is a schematic diagram illustrating an example of a screen showing event information displayed on the terminal device 10. FIG. DETAILED DESCRIPTION OF THE INVENTION

[0012] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. In the following description, the same components are denoted by the same reference numerals. The names and functions of the components are also the same. Therefore, detailed descriptions thereof will not be repeated.

[0013] <Summary> The system according to this embodiment acquires information about actions taken by a user in relation to a performer (particularly actions taken by the user as a fan of the performer), and outputs a first parameter about the user based on the information. The system then grants a benefit to the user based on the first parameter. The benefit is, for example, a benefit intended to increase the user's chances of participating in an event in which the performer appears. This allows the relationship between the user and the event performer to be improved based on the actions taken by the user, who is a fan of the performer, in relation to the performer.

[0014] In this embodiment, an event is an event in which performers of the event and fans who support the performers are present. Events in this embodiment include, for example, the following events: In this embodiment, an event may be an event with a limit on the number of participants due to the size of the venue, or an event held at a real venue. Concerts, live music events, etc. Sports events such as ball games, swimming, and martial arts (including professional leagues and amateur competitions) ·Game tournaments Entertainment events including stage plays, manzai, rakugo, and other performing arts

[0015] In this embodiment, performers include people who perform entertainment, acting, or performances at a specific event, and athletes who participate in sporting events and game tournaments.

[0016] In this embodiment, the first parameter is a numerical value related to the relationship between the performer and the user. The system according to this embodiment visualizes the results of actions (user actions) taken by the user in relation to the performer as the first parameter. The user actions include actions taken by the user as a fan of the performer.

[0017] In this embodiment, the users include users who are fans of the performers and users who are not fans of the performers.

[0018] <1 Overall system configuration> Figure 1 is a block diagram showing an example of the overall configuration of system 1. System 1 shown in Figure 1 includes, for example, a terminal device 10, a server 20, and a distributed ledger system 90. The terminal device 10, the server 20, and the distributed ledger system 90 are connected for communication via, for example, a network 80.

[0019] In this embodiment, the system 1 may include a plurality of terminal devices 10.

[0020] In this embodiment, a collection of multiple devices may be considered as one server. The allocation of multiple functions required to realize the server 20 according to this embodiment to one or more pieces of hardware can be determined appropriately in consideration of the processing capacity of each piece of hardware and / or the specifications required for the server 20.

[0021] The terminal device 10 shown in Fig. 1 is an information processing device operated by a user. The terminal device 10 is realized by, for example, a mobile terminal such as a smartphone or a tablet. The terminal device 10 may be a desktop personal computer (PC) or a laptop PC. The terminal device 10 may also be a wearable terminal such as an HMD (Head Mount Display) or a wristwatch terminal.

[0022] The terminal device 10 includes a communication IF (Interface) 12, an input device 13, an output device 14, a memory 15, a storage 16, and a processor 19. The input device 13 is a device for receiving input operations from a user (for example, a touch panel, a touch pad, a pointing device such as a mouse, a keyboard, etc.). The output device 14 is a device for presenting information to a user (a display, a speaker, etc.).

[0023] 1 is an information processing device that accepts a connection from a terminal device 10 and executes processing requested by the terminal device 10. The server 20 is an information processing device realized by, for example, a computer connected to a network 80. As shown in FIG. 1, the server 20 includes a communication IF 22, an input / output IF 23, a memory 25, a storage 26, and a processor 29. The input / output IF 23 functions as an input device for accepting input operations from a user and as an interface with an output device for outputting information to the user.

[0024] The distributed ledger system 90 manages a distributed ledger. As an example, the distributed ledger system 90 manages transaction history related to the transfer of crypto assets or tokens (which may include NFTs (Non-Fungible Tokens)). In particular, the distributed ledger system 90 manages digital content in association with NFTs through a distributed application implemented using a predetermined smart contract. For example, the smart contract is executed in response to a request from the terminal device 10. The management of digital content may include at least one of the following: Issuance of NFTs linked to digital content Transfer of NFTs from the wallet of a digital content issuer (such as a service operator, event operator, or performer) to another wallet Transferring NFTs from other wallets to the issuer's wallet

[0025] The distributed ledger system 90 includes a plurality of interconnected computers (which may include the terminal device 10).

[0026] <1.1 Terminal device configuration> Fig. 2 is a block diagram showing an example configuration of the terminal device 10 shown in Fig. 1. As shown in Fig. 2, the terminal device 10 includes a communication unit 120, an input device 13, an output device 14, an audio processing unit 17, a microphone 171, a speaker 172, a camera 160, a position information sensor 150, a storage unit 180, and a control unit 190. The blocks included in the terminal device 10 are electrically connected by, for example, a bus or the like.

[0027] The communication unit 120 performs processing such as modulation and demodulation for the terminal device 10 to communicate with other devices. The communication unit 120 performs transmission processing on the signal generated by the control unit 190 and transmits it to the outside (for example, the server 20). The communication unit 120 performs reception processing on the signal received from the outside and outputs it to the control unit 190.

[0028] The input device 13 is a device for inputting instructions or information by a user operating the terminal device 10. The input device 13 is realized, for example, by a touch-sensitive device 131 that inputs instructions by touching the operation surface. If the terminal device 10 is a PC or the like, the input device 13 may be realized by a keyboard, a mouse, or the like. The input device 13 converts instructions input by the user into electrical signals and outputs the electrical signals to the control unit 190. The input device 13 may include, for example, a receiving port that receives electrical signals input from an external input device.

[0029] The output device 14 is a device for presenting information to a user operating the terminal device 10. The output device 14 is realized, for example, by a display 141 or the like. The display 141 displays data according to the control of the control unit 190. The display 141 is realized, for example, by an LCD (Liquid Crystal Display) or an organic EL (Electro-Luminescence) display or the like.

[0030] The audio processing unit 17 performs, for example, digital-to-analog conversion processing of an audio signal. The audio processing unit 17 converts a signal provided from the microphone 171 into a digital signal and provides the converted signal to the control unit 190. The audio processing unit 17 also provides the audio signal to the speaker 172. The audio processing unit 17 is realized, for example, by a processor for audio processing. The microphone 171 receives audio input and provides an audio signal corresponding to the audio input to the audio processing unit 17. The speaker 172 converts the audio signal provided from the audio processing unit 17 into audio and outputs the audio to the outside of the terminal device 10.

[0031] The camera 160 is a device that receives light with a light receiving element and outputs the light as an image capturing signal.

[0032] The position information sensor 150 is a sensor that detects the position of the terminal device 10, and is, for example, a GPS (Global Positioning System) module. The GPS module is a receiving device used in a satellite positioning system. In the satellite positioning system, signals are received from at least three or four satellites, and the current position of the terminal device 10 equipped with the GPS module is detected based on the received signals. The position information sensor 150 may detect the current position of the terminal device 10 from the position of the wireless base station to which the terminal device 10 is connected.

[0033] The storage unit 180 is realized by, for example, the memory 15, the storage 16, etc., and stores data and programs used by the terminal device 10. The storage unit 180 stores, for example, user information 181 and ticket information 182.

[0034] The user information 181 includes, for example, information about the user who uses the terminal device 10. The information about the user includes, for example, a user ID. The user information 181 may also include an email address, a wallet address, and the like.

[0035] The ticket information 182 is, for example, information about an electronic ticket downloaded to the terminal device 10. The ticket information 182 includes, for example, the ticket ID of the ticket. The ticket information 182 may also include the user ID of the user who owns the ticket and the event ID of the event related to the ticket.

[0036] The control unit 190 is realized by the processor 19 reading a program stored in the storage unit 180 and executing instructions included in the program. The control unit 190 controls the operation of the terminal device 10. The control unit 190 functions as an operation reception unit 191, a transmission / reception unit 192, and a presentation control unit 194 by operating in accordance with the program.

[0037] The operation reception unit 191 performs processing for receiving instructions or information input from the input device 13. Specifically, for example, the operation reception unit 191 receives instructions or information input from the touch-sensitive device 131 or the like.

[0038] Furthermore, the operation reception unit 191 receives voice instructions input from the microphone 171. Specifically, for example, the operation reception unit 191 receives a voice signal that is input from the microphone 171 and converted into a digital signal by the voice processing unit 17. For example, the operation reception unit 191 analyzes the received voice signal and extracts a predetermined noun, thereby acquiring an instruction from the user.

[0039] The transmitting / receiving unit 192 performs processing for the terminal device 10 to transmit and receive data to and from an external device such as the server 20 in accordance with a communication protocol. Specifically, for example, the transmitting / receiving unit 192 transmits information input by a user or instructions from a user to the server 20. In addition, the transmitting / receiving unit 192 receives information provided by the server 20.

[0040] The presentation control unit 194 controls the output device 14 to present predetermined information to the user. Specifically, for example, the presentation control unit 194 causes the display 141 to display information related to a user behavior of the user. The presentation control unit 194 also causes the display 141 to display information related to a predetermined event. The presentation control unit 194 also causes the display 141 to display information related to digital content associated with the user behavior.

[0041] <1.2 Functional configuration of the server> 3 is a diagram showing an example of the functional configuration of the server 20. As shown in FIG. 5, the server 20 functions as a communication unit 201, a storage unit 202, and a control unit 203.

[0042] The communication unit 201 performs processing for the server 20 to communicate with external devices.

[0043] The storage unit 202 includes, for example, a user table 202a, a performer table 202b, an event table 202c, a ticket table 202d, an application history table 202e, an NFT type table 202f, an NFT management table 202g, and a point condition table 202h. The tables stored in the storage unit 202 are not limited to these. For example, the storage unit 202 may store a table for accumulating a history of user behavior.

[0044] The user table 202a is a table that stores information about users, and will be described in detail later.

[0045] The performer table 202b is a table that stores information about performers, as will be described in detail later.

[0046] The event table 202c is a table that stores information about events, the details of which will be described later.

[0047] The ticket table 202d is a table that stores information about event participation tickets, as will be described in detail later.

[0048] The application history table 202e is a table that stores information about application history for participation in events, as will be described in detail later.

[0049] The NFT type table 202f is a table that stores information about NFT types. In this embodiment, an NFT associated with predetermined digital content is granted to a user who has performed a specific user behavior. For example, an NFT is granted to a user who attended a specific event to prove that they attended the event. In this case, the NFTs granted to users are distinguished from one another by the serial number associated with the NFT. NFTs that are distinguished from one another by their serial numbers in this way are defined as NFTs of the same type. Note that information other than the serial number may differ for each NFT in the information associated with NFTs of the same type.

[0050] In this embodiment, a different table is created for each performer as the NFT type table 202f, thereby managing the NFT type for each performer. Specifically, an NFT type table 202f-A is created for performer A, and an NFT type table 202f-B is created for performer B. For example, when a new type of NFT is defined for performer A, a new record is added to the NFT type table 202f-A.

[0051] The NFT management table 202g is a table that stores information about NFTs. Details will be described later. In this embodiment, a different table is created for each NFT type as the NFT management table 202g, so that information about NFTs is managed for each NFT type. Specifically, an NFT management table 202g-C001 is created for an NFT with an NFT type ID "C001", and an NFT management table 202g-C002 is created for an NFT with an NFT type ID "C002".

[0052] The point condition table 202h is a table that stores information regarding the conditions for points to be awarded for a predetermined NFT type when calculating the first parameter. Details will be described later. In this embodiment, a different point condition table 202h is created for each event held. For example, a point condition table 202h-A is created for event A, and a point condition table 202h-B is created for event B.

[0053] The control unit 203 is realized by the processor 29 reading a program stored in the storage unit 202 and executing instructions included in the program. By operating in accordance with the program, the control unit 203 exhibits functions indicated as a reception control module 2031, a transmission control module 2032, an event management module 2033, a ticket management module 2034, a behavior information acquisition module 2035, a parameter calculation module 2036, a lottery module 2037, and a presentation control module 2038.

[0054] The reception control module 2031 controls the process by which the server 20 receives signals from external devices in accordance with a communication protocol.

[0055] The transmission control module 2032 controls the process in which the server 20 transmits signals to external devices in accordance with a communication protocol.

[0056] The event management module 2033 manages information about events related to the services of the present disclosure. Specifically, the event management module 2033 accepts registration of information about each event transmitted to the server 20 and updates the event table 202c.

[0057] The ticket management module 2034 manages information about tickets for participating in events. Specifically, the ticket management module 2034 accepts registration of information about event applications, information about ticket lottery results, information about ticket purchases, information about ticket transfers, and the like, and updates the ticket table 202d.

[0058] The behavioral information acquisition module 2035 acquires information about user behaviors taken by users in relation to event performers. In particular, the behavioral information acquisition module 2035 acquires information about user behaviors taken by users as fans of event performers. Specifically, the information about user behavior includes information for identifying the user who performed the user behavior and information for identifying the type of NFT related to the user behavior. The information about user behavior includes, for example, identification information of the user behavior, the user ID of the user related to the user behavior, and the NFT type ID related to the user behavior (the NFT type ID of the NFT assigned to the user who performed the user behavior). Note that the behavioral information acquisition module 2035 may not acquire, as information about user behavior, information about the purchase history of tickets to participate in an event where the number of participants is limited due to the size of the venue.

[0059] The behavioral information acquisition module 2035 may acquire information on the following user behaviors, for example. This makes it possible to grant NFTs to users who have performed the following user behaviors, and allows the achievements of user behaviors to be treated as non-fungible assets. Furthermore, as will be described in detail later, the control unit 203 calculates a first parameter based on the NFTs granted to the user. Therefore, the control unit 203 can acquire information on the following user behaviors and calculate the first parameter based on the acquired information.

[0060] The behavior information acquisition module 2035 may acquire information about user behaviors of one or more predetermined types of user behaviors among the user behaviors described in this disclosure. Furthermore, the behavior information acquisition module 2035 may not acquire information about user behaviors of one or more predetermined types of user behaviors among the user behaviors described in this disclosure. The types of user behaviors for which information is acquired may vary depending on the event organizer, performers, etc.

[0061] Furthermore, the control unit 203 may designate one or more predetermined types of user behavior as targets for NFT assignment and / or calculation of the first parameter, among the user behaviors whose information is acquired by the behavior information acquisition module 2035. Furthermore, the control unit 203 may not designate one or more predetermined types of user behavior as targets for NFT assignment and / or calculation of the first parameter, among the user behaviors whose information is acquired by the behavior information acquisition module 2035. The types of user behavior as targets for NFT assignment and / or calculation of the first parameter may differ depending on the event organizer, performers, etc.

[0062] (1) Application to participate in the event The behavior information acquisition module 2035 may acquire information related to a participation application for a predetermined event related to a performer. For example, when information related to the participation application for an event is transmitted to the server 20 from the terminal device 10 operated by a user who applies for the event, the behavior information acquisition module 2035 acquires information including the event ID of the event related to the participation application and the user ID of the user related to the participation application.

[0063] Furthermore, the behavior information acquisition module 2035 may acquire information regarding the following behaviors as information related to the application to participate in the event. -Applying for a lottery to participate in the event - Number of times a user has applied for the lottery for the same event. By obtaining this information, it can be assumed that a user who has applied for the same event multiple times is an avid fan of the performer. Whether or not the user won the lottery. By acquiring this information, different processing can be performed depending on whether the user won or lost the lottery. For example, by increasing the points of users who lost, it is possible to increase the chances of participating in the next event. Whether or not the users who won the lottery actually obtained the tickets. By obtaining this information, it is possible to determine whether or not the users who won the lottery actually obtained the tickets by completing the payment procedures without forgetting to do so. The user who applied to participate transferred the ticket they obtained to another company through appropriate means. By acquiring this information, it is possible to evaluate the user's appropriate behavior regarding the transfer of tickets as user behavior. For example, if a user transfers a ticket through a ticket transfer service officially provided by the organization running the event, the behavior information acquisition module 2035 identifies the ticket transferor from the user ID associated with the transferred ticket. Then, the behavior information acquisition module 2035 acquires information indicating that the transferor transferred the ticket through appropriate means.

[0064] (2) Participating in events The behavior information acquisition module 2035 may acquire information regarding participation in a predetermined event related to the performer. The behavior information acquisition module 2035 may acquire information regarding the following user behaviors as information regarding participation in an event related to the performer:

[0065] Admission to the event venue When a user enters an event venue, for example, the terminal device 10 of the user participating in the event displays an image of the admission ticket (electronic ticket) on the display 141. An event staff member operates the terminal device 10 to mark the electronic ticket as used. The terminal device 10 transmits information to the server 20 indicating that the electronic ticket has been used, i.e., that the user has entered the event venue. This information includes, for example, the user ID of the entering user, the event ID of the event being held, the ticket ID of the used ticket, and the date and time of admission (for example, the date and time the ticket was marked as used).

[0066] In this case, by acquiring the entry date and time as described above, it is possible to determine whether the user entered in accordance with the rules specified by the event organizer.

[0067] Furthermore, for example, when a user leaves the event, an event staff member may operate the terminal device 10 to transmit information indicating the date and time of the user's exit to the server 20. The behavior information acquisition module 2035 may acquire the information indicating the date and time of the user's exit. This makes it possible to determine whether the user has exited in accordance with rules specified by the event organizer, such as regulated exit.

[0068] Purchasing merchandise at the event venue For example, when a user purchases certain goods at an event venue, the goods come with a code that stores the event ID of the event being held at the venue. When the terminal device 10 reads the code in response to a user operation, it transmits the user's user ID, the event ID stored in the code, information about each of the goods purchased by the user, information indicating the date and time of purchase of the goods, etc. to the server 20. The behavioral information acquisition module 2035 acquires this information as a history of the user's actual visit to the event venue.

[0069] (3) Purchase of items related to performers The behavior information acquisition module 2035 may acquire information about the history of purchasing items related to performers as information about user behavior. Items related to performers include, for example, the following items: · Media containing content featuring the performers (CD, DVD, etc.) Goods related to the performer (e.g., clothing, towels, penlights, accessories, stickers, etc.) The goods may be goods associated with the event in which the performer appears.

[0070] For example, the above-mentioned item may come with a printed matter on which a code storing the item's identification information and the NFT type ID is printed. After purchasing the item, the user uses the camera of the terminal device 10 to read the code printed on the printed matter attached to the item. This causes the terminal device 10 to access the server 20 and transmit information indicating that the item has been purchased. This information includes the user's user ID, the item's identification information stored in the code, and the NFT type ID. The behavioral information acquisition module 2035 acquires the information transmitted from the terminal device 10.

[0071] (4) Providing information about performers The behavior information acquisition module 2035 may acquire information related to the history of transmitting information about performers. The behavior information acquisition module 2035 may acquire information related to the following user behaviors as information related to transmitting information about performers:

[0072] Posts about performers on designated social networking services (SNS) For example, the user operates the terminal device 10 to associate, via the server 20 in advance, a user ID in the SNS (hereinafter referred to as an SNS user ID) with a user ID of the service of the present disclosure (user ID stored in the user table 202a).

[0073] Server 20 accesses the server that operates the SNS at a predetermined timing and acquires the SNS posting history related to the performer and the SNS user ID of the user who posted based on predetermined search criteria. The predetermined search criteria may, for example, be tagged with a specific word related to the performer or contain a word related to the performer. Furthermore, the search criteria and the NFT type ID of the NFT assigned in response to a post related to the search criteria are associated in advance. This makes it possible to evaluate posts that match the search criteria as user behavior and assign to the target user an NFT related to the NFT type ID associated with the search criteria.

[0074] · Creating content related to the performers The server 20 associates in advance the user ID of a predetermined platform for users to post content with the user ID of the service of the present disclosure.

[0075] For example, a user creates content related to a performer and posts it to a predetermined platform on the Internet by operating a terminal device 10 or the like. The server 20 accesses the server that operates the platform at a predetermined timing and acquires posts based on predetermined search criteria. The predetermined search criteria may, for example, be tagged with a specific word related to the performer, or contain a word related to the performer. Furthermore, the search criteria and the NFT type ID of the NFT assigned in response to a post related to the search criteria are associated in advance. This allows posts that match the predetermined search criteria to be evaluated as user behavior and NFTs to be assigned to the target user.

[0076] Examples of content related to performers that users can create are shown below for each type of content, but the content examples are not limited to those shown below. · Text content: Text summarizing information about the performers Video content: videos introducing the performers, videos re-edited from other videos about the performers, etc. Still image content: illustrations, photographs, etc. Audio content: Radio content introducing performers, etc. Music content: songs edited from songs related to performers, etc. · Content that translates at least one of the above contents into another language

[0077] In addition, the predetermined platforms on which content is posted include, for example, the following platforms: Official websites operated by performers or people related to performers · Websites unofficially operated by people not related to the performers Social media

[0078] It should be noted that a user may create content related to a performer and sell it on a predetermined real-world platform (for example, selling magazines at a sales event) or post it (for example, posting an advertisement at a predetermined facility such as a train station). In this case, for example, the user sends information to the server 20 to the effect that they will sell, post, etc. the content via a predetermined application web page. Based on this information, the behavioral information acquisition module 2035 acquires information related to the user creating content related to the performer and selling, posting, etc. in a real-world location, in association with the NFT type ID associated with the web page.

[0079] (5) Actions to publicize the presence of the performers The behavior information acquisition module 2035 may acquire, as information about user behavior, information about behavior for publicizing the presence of a performer. The behavior information acquisition module 2035 may acquire, as information about user behavior for publicizing the presence of a performer, information about the following user behavior:

[0080] A request for the performer's content (music content, video content, etc. that the performer was involved in creating) on ​​a designated media (radio program, TV program, etc.). If the performer's content is played in response to the request, the performer's existence will become known to the public. Playback of the performer's content on a designated streaming service that provides music content, video content, etc. If users play content on a streaming service, the number of times the content is played on the streaming service increases, increasing the chances of the performer being included in the rankings, etc. of that service, and thus making the performer's existence known to the general public.

[0081] For example, the user operates the terminal device 10 in advance to associate a user ID in the above media or streaming service with a user ID in the service of the present disclosure (a user ID stored in the user table 202a) via the server 20. Then, the user logs in to the above media or streaming service and posts a request for media or plays content in the streaming service.

[0082] The behavioral information acquisition module 2035 accesses the server that operates the media or the streaming service at a predetermined timing and acquires the history of requests posted to the media or playback on the streaming service. The behavioral information acquisition module 2035 identifies the type of NFT to be granted to the user from the media title, artist name, etc. included in the acquired information.

[0083] The above-mentioned "disseminating information about performers" can be included in actions for publicizing the presence of performers.

[0084] (6) Conduct related to performers in relation to membership services The behavioral information acquisition module 2035 may acquire information about user behavior related to a membership service for a performer. The behavior related to a membership service for a performer includes, for example, operations related to joining (including new membership and re-joining), canceling membership, and continuing membership in the membership service for a performer.

[0085] For example, the user operates the terminal device 10 in advance to associate, via the server 20, a user ID for the membership service (hereinafter referred to as a member ID) with a user ID for the service of the present disclosure.

[0086] The server 20 accesses the server that operates the membership service at a predetermined timing and obtains information regarding at least one of the date of joining the membership service of the user associated with the member ID (the date of joining for the first time and the date of rejoining may be distinguished), the date of withdrawal, and the period of membership.

[0087] The length of time a user has been a fan of a performer can be estimated from the membership date, cancellation date, and length of membership. This makes it possible to estimate whether the user is a new fan or a long-time fan. Therefore, it is possible to distinguish between the length of time a user has been a fan and evaluate user behavior.

[0088] Furthermore, the behavioral information acquisition module 2035 can determine whether a user was enrolled in a membership service at a specific time based on the membership date, cancellation date, and enrollment period of the membership service. This makes it possible to estimate whether the user was active as a fan at a specific time. The specific time can be determined appropriately by the performer, etc., and may be, for example, a specific anniversary related to the performer (such as the performer's birthday, formation anniversary, or start date of activities). Alternatively, the specific time may be a period related to a specific event held in the past (such as the date of the event, the period during which a series of events was held, etc.).

[0089] (7) Any other actions to improve the relationship between the performer and the user. The behavior information acquisition module 2035 may acquire, for example, information on the following behaviors as information on user behavior: Participating in social causes related to the performer, such as volunteering or charitable activities organized, endorsed, supported, or sponsored by the performer. Participating in events run by organizations that support performers (e.g., sponsors) at event venues, etc.

[0090] For example, when a user participates in the above activities, the camera of the terminal device 10 reads a code storing identification information for the above activities and an NFT type ID. As a result, the terminal device 10 associates information indicating that the user has participated in the above activities with the user ID and transmits the information to the server 20. The behavior information acquisition module 2035 acquires information indicating that the user has participated in the above activities, together with the type ID of the NFT to be assigned to the user.

[0091] As described above, the behavioral information acquisition module 2035 acquires information about the user behavior exemplified above. This allows the control unit 203 to grant NFTs corresponding to the user behavior performed by the user, making it possible to treat the results of user behavior as non-fungible assets.

[0092] The parameter calculation module 2036 calculates a first parameter based on information about the user's user behavior. Specifically, the parameter calculation module 2036 acquires the NFT holding status granted for the user's user behavior and calculates the first parameter by summing up the points assigned to each NFT. The points assigned to each NFT are determined in the point condition table 202h, for example, for each event for which the first parameter is calculated.

[0093] The lottery module 2037 conducts a lottery for applications for the event to determine participants for the event. Specifically, the lottery module 2037 conducts a lottery while changing the winning probability according to a first parameter of the user who applied for the lottery, and determines participants. For example, the lottery module 2037 acquires a first parameter related to the performers of the event that is the subject of the lottery from the user who applied for the lottery. The lottery module 2037 weights the winning probability of each user by increasing or decreasing the winning probability of the corresponding user according to the first parameter. The lottery module 2037 conducts a lottery based on the weighted winning probability and determines winners. As a result, the winning probability of the lottery changes according to the user's behavioral record, so that the more enthusiastic the fan with a history of user behavior, the more opportunities they have to participate in the event, and the relationship between the fan and the performers can be improved.

[0094] The presentation control module 2038 presents the information extracted from the storage unit 202 to the user.

[0095] <1.3 Configuration of Distributed Ledger System90> Figure 4 is a diagram showing the configuration of a distributed ledger system 90. As shown in Figure 4, the distributed ledger system 90 includes multiple node computers 90A to 90E.

[0096] The node computers 90A to 90E are connected to one another via a network (which may include the network 80 of FIG. 1). In this embodiment, the network may include a public network, a private network, a dedicated line, a virtual private network (VPN), or a combination thereof. The node computers 90A to 90E are connected to the network, for example, by wire or wirelessly. The node computers 90A to 90E communicate with one another in a peer-to-peer manner.

[0097] The node computers 90A to 90E manage the distributed ledger using, for example, block chain technology. Specifically, one of the node computers 90A-90E acquires data related to cryptocurrency or token transactions to be recorded. The node computers 90A-90E create a block including the acquired data and add it to the blockchain. The node computers 90A-90E transmit information about the added block to the other node computers 90A-90E. The other node computers 90A-90E verify the accuracy of the received block, and if the verification is successful, add the block to the blockchain. The node computers 90A-90E finalize the blockchain, for example, according to the number of linked blocks (number of approvals). As a result, the same distributed ledger is stored across the multiple node computers 90A-90E that make up the distributed ledger system 90. The stored data is encrypted as appropriate.

[0098] The configuration of the distributed ledger system 90 is not limited to that shown in Figure 4. For example, the distributed ledger system 90 may include six or more node computers, or two to four node computers. Furthermore, the number of node computers that make up the distributed ledger system 90 may change over time.

[0099] Detailed description of the hardware configuration of the node computers 90A to 90E will be omitted as it may be the same as or similar to that of the terminal device 10. As an example, the node computers 90A to 90E include a processor, a storage device, an input / output interface, a communication interface, an input device, an output device, or a combination thereof.

[0100] <2 Data Structure> 5 to 12 are diagrams showing the data structures of tables stored in the server 20. Note that Figures 5 to 12 are merely examples and do not exclude data that is not listed. Furthermore, even data that is listed in the same table may be stored in separate storage areas in the storage unit 202.

[0101] 5 is a diagram showing the data structure of the user table 202a. The user table 202a includes the items "user ID", "user name", "email address", "wallet address", and "NFT type ID".

[0102] The item "user ID" is an item for storing a user ID that identifies a user.

[0103] The item "user name" is an item for storing the name of the user. The user name may be set to any character string such as the user's name or nickname.

[0104] The item "email address" is an item for storing the user's email address.

[0105] The item "wallet address" is an item for storing the user's wallet address. A wallet address is an address that uniquely identifies a wallet that manages token holdings on the blockchain.

[0106] The item "NFT type ID" is an item that stores the NFT type ID of the NFT held by the user.

[0107] 6 is a diagram showing the data structure of the performer table 202b. The performer table 202b includes an item "performer ID" and an item "performer name".

[0108] The "performer ID" item stores a performer ID that identifies a performer. A performer ID may be assigned to a group consisting of multiple members (e.g., a music group, an idol group, a sports team, etc.), or a different performer ID may be assigned to each member of the group, or both. The performer ID assigned to a specific group and the performer ID assigned to a member of that group may be associated with each other.

[0109] The item "performer name" is an item for storing the name of the performer. The performer name may be set to any character string, such as the performer's name, stage name, or group name.

[0110] 7 is a diagram showing the data structure of the event table 202c. The event table 202c includes an "event ID", an "event name", an "event type", an "performer ID", an "venue", an "organizer ID", an "event date and time", an "application conditions", and an "NFT type ID".

[0111] The item "event ID" is an item for storing an ID that identifies an event.

[0112] The item "event name" is an item for storing the name of the event.

[0113] The "event type" item is an item that stores the type of event. Specifically, the "event type" item stores information indicating the type of event, such as "music live" or "talk live." The "event type" item may store information indicating multiple types.

[0114] The "performer ID" item is an item for storing the performer ID of a performer who will appear in the event related to the event ID. The "performer ID" item may store multiple performer IDs.

[0115] The item "venue" is an item for storing information indicating the venue of the event, for example, a character string indicating the name of the venue.

[0116] The item "organizer" is an item for storing information identifying the organizer of the event, for example, the name of the organizer.

[0117] The item "Event Date" is an item for storing the event date and time.

[0118] The item "application conditions" is an item that stores information indicating application conditions regarding whether or not to apply for an event. Specifically, the item "application conditions" stores information regarding the conditions of a first parameter that a user has regarding whether or not to apply for an event. The item "application conditions" stores, for example, information regarding conditions based on a comparison between the first parameter and a predetermined value. Examples of conditions are shown below. The user's first parameter related to a predetermined event is greater than or less than a predetermined value. The first parameter of the other user accompanying the user in a predetermined event is greater than or less than a predetermined value.

[0119] Additionally, the application conditions may be that the user holds a specific NFT, i.e., that a specific NFT is associated with the user's wallet address.

[0120] If no particular conditions are set regarding whether or not to apply for an event, the item "application conditions" stores information indicating that no application conditions are stored in this item, such as a blank or null value.

[0121] The "NFT type ID" item is an item that stores the NFT type ID of an NFT that is granted to a user who has performed a predetermined user action in relation to an event related to the event ID. For example, the "NFT type ID" item stores the NFT type ID of an NFT that is granted to a user who attended an event related to the event ID. Note that if an NFT is not granted to a user in relation to an event related to the event ID, the "NFT type ID" item stores information indicating that no NFT type ID is stored in this item, such as a blank or null value.

[0122] 8 is a diagram showing the data structure of the ticket table 202d. The ticket table 202d includes the following items: "Ticket ID," "Event ID," "Application ID," "Owner," and "Status."

[0123] The item "ticket ID" is an item for storing a ticket ID that identifies a ticket.

[0124] The item "event ID" is an item for storing the event ID of the event associated with the ticket.

[0125] The item "application ID" is an item for storing an application ID that identifies a participation application associated with a ticket.

[0126] The item "Purchase Date and Time" is an item for storing the date and time when the user purchased the ticket.

[0127] The "holder" item is an item that stores information about the user who is the ticket holder. Specifically, the "holder" item stores the user ID of the user who holds the ticket. When the ticket is transferred from the holder user to another user, the information in the "holder" item is updated with the user ID of the other user to whom the ticket is transferred. The "holder" item may also store the user who is the original ticket holder and the ticket transfer history.

[0128] The item "status" is an item that stores the usage status of the ticket related to the ticket ID. Specifically, the item "status" stores information that indicates whether the ticket is unused or used.

[0129] 9 is a diagram showing the data structure of the application history table 202e. The application history table 202e includes an item "application ID," an item "event ID," an item "user ID," an item "application date and time," and an item "lottery result."

[0130] The item "application ID" is an item for storing an application ID that identifies an application to participate in an event.

[0131] The item "event ID" is an item for storing the event ID of the event to be applied for.

[0132] The item "user ID" is an item for storing the user ID of the user who made the application.

[0133] The item "application date and time" is an item for storing the date and time when the application was made.

[0134] The "lottery result" item stores the results of the lottery for event participation tickets. Specifically, the "lottery result" item stores information indicating whether or not the application was successful. In the case of an event in which participants are determined by a method other than lottery, the "lottery result" item stores information such as a blank or null value indicating that the lottery result is not stored in this item.

[0135] 10 is a diagram showing the data structure of the NFT type table 202f. The NFT type table 202f includes an item "NFT type ID" and an item "NFT type name".

[0136] The item "NFT type ID" is an item for storing an NFT type ID that identifies an NFT type.

[0137] The "NFT Type Name" item stores information related to the name of the NFT type. Specifically, the "NFT Type Name" item stores the name of a specific event associated with the NFT related to the NFT Type ID. For example, the "NFT Type Name" item stores a string related to the content and type of user behavior associated with the NFT, the title of the event, the name of the goods, etc., such as "Proof of Attendance at XX Event" or "Proof of Purchase of XX Goods." Alternatively, the "NFT Type Name" item stores a string related to a specific event associated with the NFT, such as "1st Anniversary." The information stored in the "NFT Type Name" can also be considered the name given to each NFT related to the NFT type itself.

[0138] 11 is a diagram showing the data structure of the NFT management table 202g. The NFT management table 202g includes an item "NFT ID", an item "serial number", and an item "granted status".

[0139] The item "NFT ID" is an item that stores an NFT ID that identifies an NFT.

[0140] The "serial number" item stores the serial number associated with the NFT. Specifically, the "serial number" item stores information indicating a number for distinguishing NFTs of the same NFT type from one another.

[0141] The "Assignment Status" item stores information about the assignment status of the NFT associated with the NFT ID. Specifically, the "Assignment Status" item stores information indicating whether the NFT associated with the NFT ID has been transferred to a specific user or has not yet been transferred (remains in the possession of the NFT issuer).

[0142] 12 is a diagram showing the data structure of the point condition table 202h. The point condition table 202h includes an item "condition ID", an item "condition", and an item "granted points".

[0143] The item "condition ID" is an item for storing a condition ID that identifies the condition for point allocation.

[0144] The item "NFT type ID" is an item that stores the NFT type ID of the NFT type for which points are awarded.

[0145] The item "NFT type name" is an item that stores the name of the NFT type to which points are awarded.

[0146] The "Points" item is an item that stores the numerical value of points associated with an NFT related to the NFT type ID stored in the "NFT Type ID" item. The numerical value of the "Points" item can also be said to be the numerical value of points given to a user who holds an NFT related to the NFT type ID stored in the "NFT Type ID" item. In the example shown in FIG. 12, a user who holds an NFT related to the NFT type ID "C001" is given 100 points. The first parameter related to the user is calculated by adding up the points given to the NFTs held by the user.

[0147] As described above, in this embodiment, a different table is created as the point condition table 202h for each event held. For example, a point condition table 202h-A is created for event A, and a point condition table 202h-B is created for event B. Therefore, the conditions for the point values ​​associated with the types of NFTs held by the user differ for each event held. For example, in the table shown in FIG. 12, points are associated with each of the NFT type IDs "C001," "C010," "C003," and so on. However, in other tables (other events), these NFT type IDs may be associated with point values ​​different from those in the example shown in FIG. 12, or may not be associated with points at all (i.e., 0 points). The point conditions can be determined appropriately for each event by the event performers, etc. Note that the point conditions do not have to differ for each event held.

[0148] That is, in this embodiment, by setting point conditions for each event held, it is possible to set the value of NFTs held by users for each event held. For example, if the organizer or performers of event A want to highly evaluate users who have a track record of performing user actions related to specific event a, they may set the points associated with NFT types related to event a (for example, "proof of attendance at event a," "proof of purchase of merchandise for event a," etc.) higher than those of other NFT types, while setting the points associated with NFT types not related to event a lower or no points at all.

[0149] <Information associated with NFTs in the distributed ledger system 90> 13 is a diagram showing an example of information associated with an NFT in the distributed ledger system 90. For example, when an NFT is issued in the distributed ledger system 90, the information shown in FIG. 13 is associated with the NFT and recorded on the distributed ledger system 90.

[0150] "NFTID" is information indicating the NFTID of the NFT, and corresponds to information such as the "NFTID" item in the NFT management table 202g.

[0151] "NFT type ID" is information indicating the NFT type ID of the NFT, and corresponds to information such as the "NFT type ID" item in the NFT type table 202f.

[0152] "NFT type name" is information indicating the type name of the NFT, and corresponds to information in the "NFT type name" item of the NFT type table 202f.

[0153] A "digital content address" is information for identifying digital content associated with an NFT. For example, if the digital content is stored on a specific server, the digital content address is information that indicates the reference destination of the digital content. For example, if the digital content is managed by a distributed storage system, the digital content address is information for identifying the digital content in the distributed storage system (such as an identification ID for the content).

[0154] The information associated with the NFT may directly include the digital content data. In this case, the digital content data may be converted into any format. Also, if the information associated with the NFT directly includes the digital content data, the information associated with the NFT does not need to include information corresponding to the "digital content address."

[0155] "Serial number" is information indicating the serial number associated with the NFT, and corresponds to information such as the "serial number" item in the NFT management table 202g.

[0156] The "issue date and time" is information indicating the date and time when the NFT was issued. For example, the "issue date and time" is information indicating the date and time when the transaction related to the issuance of the NFT was recorded in the distributed ledger system 90.

[0157] Note that the information associated with an NFT may include information other than the information shown in Figure 13. For example, the information associated with an NFT may include information regarding whether the NFT is transferable. The information regarding whether the NFT is transferable is information regarding whether or not the NFT is permitted to be further transferred from the user to another user after being transferred from the issuer to the user.

[0158] <3 operations> The operations of the terminal device 10 and the server 20 will now be described.

[0159] (NFT granting process to users) FIG. 14 is a flowchart showing an example of the operation of the server 20 and the distributed ledger system 50 when granting an NFT corresponding to a user action to a user who has performed a predetermined user action.

[0160] In addition, when explaining the content of the process shown in FIG. 14, the explanation will be given by taking as an example user behavior entry into an event venue related to a predetermined performer.

[0161] First, when a user performs a predetermined user action, a predetermined information processing device related to the user action transmits information related to the user action to the server 20. The information related to the user action includes at least information for identifying the user who performed the user action and information for identifying the NFT related to the user action. For example, when entering an event venue, the user operates the terminal device 10 at the entrance to display the electronic ticket on the display 141. When the electronic ticket is deemed used by an entrance staff member or the like at the event venue, the terminal device 10 transmits information including the ticket ID associated with the electronic ticket and the user ID of the user to the server 20.

[0162] In step S11, the control unit 203 of the server 20 acquires information related to user behavior. Specifically, the control unit 203 acquires information related to user behavior transmitted from a predetermined information processing device. For example, the control unit 203 acquires information including a ticket ID and a user ID transmitted from the terminal device 10. The control unit 203 also searches the ticket table 202d using the acquired ticket ID, acquires information on the "event ID" of the corresponding record, and sets the item "status" to "used."

[0163] In step S12, the control unit 203 identifies the NFT type related to the user action. Specifically, for example, the control unit 203 searches the event table 202c using the acquired event ID and acquires information on the items "performer ID" and "NFT type ID" of the corresponding record. This identifies the type of NFT to be granted to the user who performed the user action.

[0164] In step S13, the control unit 203 identifies the NFT to be assigned to the user. Specifically, for example, the control unit 203 selects one record from among the records in the NFT management table related to the acquired NFT type ID whose assignment status is "Not assigned" and acquires information from the "NFT ID" and "Serial Number" fields of that record. This identifies the NFT to be assigned to the user who performed the user action. In addition, at this time, the control unit 203 may select the record with the smallest value in the "Serial Number" field from among the records whose status is "Not assigned."

[0165] The control unit 203 searches the user table 202a based on the user ID acquired from the terminal device 10 in step S11, and acquires information in the "wallet address" field. This identifies the user's wallet to which the NFT is to be transferred.

[0166] In step S14, the control unit 203 instructs the distributed ledger system 50 to grant an NFT to the user. Specifically, the control unit 203 instructs the distributed ledger system 50 to grant an NFT by specifying a predetermined contract address and sending information including the identification information of the NFT to be granted to the user, the wallet address of the NFT transfer source, and the user's wallet address to which the NFT is to be transferred to the distributed ledger system 50. The transfer source of the NFT may be, for example, the operator of a service related to the present disclosure, the operator of an event, a performer, etc., and the wallet address of the transfer source is stored in advance in the server 20.

[0167] In step S15, the distributed ledger system 50 grants the NFT to the user. Specifically, the NFT is transferred to the user's wallet by executing a transaction to transfer the NFT from the transfer source wallet to the user's wallet. By granting the NFT to the user, the digital content associated with the NFT is also effectively granted to the user. Once the NFT has been transferred, the distributed ledger system 50 notifies the server 20 of this fact.

[0168] The NFT granted to the user in step S15 does not have to be created in advance. For example, the distributed ledger system 90 may grant the NFT to the user by issuing a new NFT associated with the information received from the server 20 to the user's wallet.

[0169] In step S16, the control unit 203 updates the user's NFT holding status. Specifically, for example, the control unit 203 searches the user table 202a based on the user's user ID, and adds the NFT type ID of the NFT assigned to the user in step S15 to the item "NFT type ID."

[0170] In step S17, the control unit 203 notifies the user that an NFT has been granted to the user as a result of the user's action. Specifically, for example, information indicating that an NFT has been granted is sent to the user's terminal device 10. The information may include information such as the NFT type name, serial number, and digital content reference destination for the NFT granted to the user.

[0171] The assigned NFT can be transferred to another user. This effectively transfers the digital content associated with the NFT to the other user. For example, a user who wants to transfer an NFT operates the terminal device 10, specifies the NFT ID of the NFT to be transferred and the user ID of the other user who will receive the NFT, and sends information indicating that the NFT will be transferred to the server 20.

[0172] The control unit 203 searches the user table 202a to identify the user's wallet address and the wallet addresses of other users. The control unit 203 transmits each user's wallet address and information about the NFT related to the transfer to the distributed ledger system 50, and executes the process of transferring the NFT. When the transaction related to the transfer is recorded on the blockchain, the NFT is registered in the wallet of the other user, and the registration of the NFT in the user's wallet is cancelled.

[0173] The control unit 203 may manage the distribution of NFTs on the server 20, for example, by storing the following information in the memory unit 202: NFTID of the transferred NFT User ID of the user from whom the transfer is being made User ID of the destination user Transaction timestamp for NFT transfers

[0174] The control unit 203 may also acquire information regarding a user's transfer of NFTs to another user as information related to the user's user behavior. This allows the transfer of NFTs to be evaluated as user behavior and can be used as a target for NFT allocation and for outputting the first parameter. A case in which the transfer of NFTs is evaluated as user behavior may be when a user transfers NFTs to another user who is unfamiliar with a performer or event in order to convey the appeal of the performer or event.

[0175] Digital content is associated with an NFT, so transferring an NFT essentially transfers the digital content to another person, and records the history of the transfer.

[0176] (Lottery process) Some events require advance registration to participate, and if the number of registrations exceeds the participant limit, participants (those with the right to participate and those with the right to purchase an event ticket) are determined by lottery. Hereinafter, such events may be referred to as lottery events. FIG. 15 is a flowchart showing an example of the operation of the server 20 and the distributed ledger system 90 when calculating a first parameter based on the NFTs held by users and holding a lottery while varying the winning rate for the lottery event according to the first parameter.

[0177] The lottery process shown in FIG. 15 is started, for example, when the control unit 203 of the server 20 acquires the event ID of the event from the storage unit 202 at a predetermined timing after the application period for the lottery has ended.

[0178] In step S21, the control unit 203 of the server 20 acquires the user ID of the user (applicant user) who applied for the lottery to participate in the event that is the target of the lottery processing from the storage unit 202. Specifically, for example, the control unit 203 searches the application history table 202e based on the event ID of the event that is the target of the lottery processing, and acquires information on the item "user ID."

[0179] In step S22, the control unit 203 searches the user table 202a based on the acquired user ID and acquires the wallet address of the applying user. The control unit 203 then queries the distributed ledger system 90 about the NFT holding status of the wallet associated with the acquired wallet address.

[0180] In step S23, the distributed ledger system 90 identifies the wallet of each applicant user based on the obtained wallet address and obtains a list of NFT type IDs of the NFTs held by each applicant user. The distributed ledger system 90 transmits information regarding the list of NFT type IDs of the NFTs held by each applicant user to the server 20 for each user ID of the applicant user.

[0181] In step S24, the control unit 203 obtains information regarding a list of NFT type IDs of NFTs held by each applying user from the distributed ledger system 90. The control unit 203 updates the applying user's NFT holding status based on the obtained information. Specifically, the control unit 203 searches the user table 202a using the user ID obtained from the distributed ledger system 90, and updates the information in the "NFT type ID" item with the NFT type ID obtained from the distributed ledger system 90.

[0182] In step S25, the control unit 203 identifies the point condition table 202h for the event that is the subject of the lottery, based on the event ID of the event that is the subject of the lottery. Note that the point condition table 202h for the event that is the subject of the lottery does not have to be created in advance, and in this step, the point condition table 202h for the event that is the subject of the lottery may be created by a terminal device operated by the event organizer or the like.

[0183] The control unit 203 calculates a first parameter related to the applying user. Specifically, for example, the control unit 203 searches the point condition table 202h based on the NFT type ID of each NFT held by the applying user acquired in step S24, and adds up the values ​​stored in the "points" item of the corresponding records. This calculates the first parameter related to the NFTs held by the applying user for the event that is the subject of the lottery.

[0184] Here, the NFTs held by the applicant user are granted to the applicant user based on information about the applicant user's user behavior, as in the process shown in Figure 14. Therefore, in step S25, it can be said that a first parameter is output for the applicant user based on information about the applicant user's user behavior.

[0185] In step S26, the control unit 203 changes the applicant user's probability of winning the lottery based on the calculated first parameter. Specifically, the control unit 203 changes the applicant user's probability of winning by weighting the user's original probability of winning according to the first parameter. For example, the control unit 203 calculates the weight of the applicant user's probability of winning by adding a value obtained by dividing the numerical value of the first parameter by a predetermined number to the original probability of winning. The control unit 203 then calculates the applicant user's new probability of winning by dividing the weight of the applicant user's probability of winning by the sum of the weights of the winning probabilities of each applicant user. Note that the method for changing the winning probability is merely an example, and the control unit 203 may change the winning probability using any method.

[0186] In step S26, the control unit 203 may vary the winning probability of a user who holds one or more specific types of NFTs without calculating the first parameter. For example, the winning probability of the applying user may be changed by multiplying the winning probability by a predetermined factor in proportion to the number of NFTs of a specific type held. This allows the winning probability to be changed according to the NFT holding status without calculating the first parameter.

[0187] In step S27, the control unit 203 performs a lottery to determine winners and losers. Specifically, for example, the lottery is performed using an arbitrary lottery algorithm based on the new winning probability. As a result, winners and losers are determined from among the applicant users.

[0188] In step S27, the control unit 203 may select users whose first parameter is equal to or greater than a specific value, and / or users who hold one or more specific types of NFTs, as winners without being subject to a lottery, thereby allowing those users to acquire the right to participate in the event. All winners may be determined in this manner, i.e., an actual lottery need not be held. If there are any winning slots remaining, a lottery may be held for users other than the user in question for the remaining winning slots. In this case, the winning probability may or may not be changed.

[0189] In addition, the control unit 203 may disqualify users whose first parameter is equal to or less than a specific value, and / or users who do not hold one or more specific types of NFTs, from the lottery, thereby preventing those users from obtaining the right to participate in the event.

[0190] Furthermore, the control unit 203 may disqualify users who hold one or more specific types of NFTs from the lottery, thereby preventing those users from acquiring the right to participate in the event. For example, the control unit 203 may disqualify users who hold NFTs related to participation in events held within a predetermined period or a predetermined number of times prior to the event related to the lottery from the lottery.

[0191] The control unit 203 searches the application history table 202e based on the user ID of the applying user and the event ID of the event related to the lottery, and stores information indicating whether the user won or lost in the ``lottery result'' item depending on the lottery result for each applying user.

[0192] The control unit 203 may manage information about the applying user by creating an application list such as that shown in FIG. 16. In the application list, the item "User ID" stores the user ID of the applying user. The item "Owned NFT" stores the NFT type ID of the NFT held by the applying user. The item "Parameter" stores the value of the first parameter calculated for the applying user. The item "Lottery result" stores information indicating the lottery result for the applying user.

[0193] In step S28, the control unit 203 acquires information about the winning user from the storage unit 202. Specifically, for example, the control unit 203 acquires information about the items "Application ID" and "User ID" of the record that stored information indicating "Winning" in the item "Lottery Result" in step S24.

[0194] The control unit 203 generates event ticket information for the successful user. Specifically, for example, the control unit 203 stores the event ID of the event related to the lottery, the application ID acquired in step S25, and the user ID acquired in step S25 in a new record in the ticket table 202d. Note that the ticket information may be created when the successful user performs a ticket purchase process.

[0195] In step S29, the control unit 203 notifies the applicant user of the lottery result. Specifically, the control unit 203 transmits information regarding whether the applicant user has won the lottery to the terminal device 10.

[0196] The terminal device 10 receives the information transmitted from the server 20. The terminal device 10 notifies the user of the lottery result, for example, by displaying information about the lottery result on the display 141. The terminal device 10 may present the user, via the display 141, with information for receiving a ticket to participate in the event for the selected user.

[0197] As described above, in the lottery process, a first parameter is calculated based on the NFTs held by the user, and the lottery is held while varying the winning rate for the lottery event according to the first parameter. As described above, NFTs are awarded according to the performance of user behavior. Therefore, in other words, the more proactively a user performs user behavior (actively acquires NFTs), the more the probability of winning the event changes (increases). Therefore, users who perform user behavior can increase their opportunities to participate in events, and the relationship between the users who perform user behavior and the performers can be improved.

[0198] The above description has been given with an example of a lottery to determine participants in an event, but the subject of the lottery is not limited to this. The lottery process can be applied to any lottery that determines winners and losers. For example, the lottery process can be applied to a lottery held when the number of potential buyers exceeds the actual number of products. In this case, the products may be products (e.g., limited edition goods) associated with the performer. This makes it easier for users who actively engage in user behavior (actively acquire NFTs) to obtain the products. On the other hand, it becomes more difficult for those who are not fans of the performer, for example, those who intend to resell the products at high prices, to obtain the products.

[0199] It should be noted that the merchandise does not have to be related to the performers, as long as it is sold by lottery or other means and requires a lottery to be purchased. Examples of merchandise include, but are not limited to, branded products, limited quantity products, limited time products, new products, high-priced products, etc.

[0200] (Special event information processing) Figure 17 is a flowchart showing an example of the operation of the server 20 and the distributed ledger system 90 when calculating a first parameter based on the NFTs held by a user, determining whether or not to apply to participate in an event (hereinafter sometimes referred to as a special event) in which whether or not to apply to participate is determined based on the first parameter, based on the first parameter, and notifying users who are eligible to apply to the special event of information about the special event.

[0201] First, the organizer of the special event operates a predetermined terminal to send information about the special event to the server 20. The information about the special event includes information corresponding to each item in the event table 202c (at least information corresponding to the item "application conditions"). The information about the special event also includes information for generating the point condition table 202h related to the special event (information corresponding to each item in the point condition table 202h).

[0202] In step S31, the control unit 203 of the server 20 receives information about the special event from the terminal. The control unit 203 stores the received information in a new record in the event table 202c. The control unit 203 also generates a point condition table 202h related to the special event based on the received information.

[0203] In step S32, the control unit 203 refers to the user table 202a to obtain the user's wallet address. The control unit 203 inquires of the distributed ledger system 90 about the NFT holding status of the wallet associated with the obtained wallet address.

[0204] In step S33, the distributed ledger system 90 identifies the user's wallet based on the acquired wallet address and acquires a list of NFT type IDs of the NFTs held by the user. The distributed ledger system 90 transmits information regarding the list of NFT type IDs of the NFTs held by the user for each user ID to the server 20.

[0205] In step S34, the control unit 203 obtains information regarding a list of NFT type IDs for NFTs held by each user from the distributed ledger system 90. The control unit 203 updates each user's NFT holding status based on the obtained information. Specifically, the control unit 203 searches the user table 202a using the user ID obtained from the distributed ledger system 90, and updates the information in the "NFT type ID" item with the NFT type ID obtained from the distributed ledger system 90.

[0206] In step S35, the control unit 203 identifies users who hold NFTs related to the special event. Specifically, for example, the control unit 203 obtains a list of the "NFT type ID" item in the point condition table 202h related to the special event, and searches the user table 202a based on each obtained NFT type ID, thereby obtaining the user IDs of users who hold NFTs related to each NFT type ID.

[0207] In step S36, the control unit 203 calculates a first parameter for users who hold NFTs related to the special event. Specifically, the control unit 203 searches the point condition table 202h based on the NFT type ID of each NFT held by the users who hold NFTs related to the special event, and calculates the first parameter by summing up the values ​​stored in the "points" item of the corresponding records.

[0208] Here, the NFTs related to the special event are granted to the users who hold the NFTs related to the special event based on information about the user behavior of the users who hold the NFTs related to the special event, as in the process shown in Figure 14. Therefore, in step S36, it can be said that the first parameter is output for the users who hold the NFTs related to the special event based on information about the user behavior of the users who hold the NFTs related to the special event.

[0209] In step S37, the control unit 203 identifies users who can apply for the special event based on the first parameter. Specifically, the control unit 203 compares the information in the "application conditions" item of the event table 202c related to the special event with the calculated first parameter of each user to extract the user IDs of users who meet the application conditions. For example, if the application condition is "the first parameter is 100 or more," the control unit 203 identifies users who can apply for the special event by extracting the user IDs of users whose calculated first parameter is 100 or more.

[0210] The control unit 203 may manage information about users who can apply for a special event by creating a notification list such as that shown in FIG. 18. In the notification list, the item "User ID" stores the user IDs of users who can apply for a special event. The item "Owned NFT" stores the NFT type IDs of the NFTs held by the user. The item "Parameter" stores the value of a first parameter calculated for the user.

[0211] In step S38, the control unit 203 notifies the users who are eligible to apply for the special event that they can apply for the special event. For example, the control unit 203 sends a message to the email address associated with the user ID of the user who is eligible to apply for the special event, informing the user that they can apply for the special event. The terminal device 10 of the user who is eligible to apply for the special event notifies the user that they can apply for the special event by, for example, displaying information indicating that the message has been received on the display 141. Note that users who are not eligible to apply for the special event are not notified that they can apply for the special event.

[0212] Furthermore, when a user eligible to apply for a special event operates the terminal device 10 to access a personal page prepared for each user in the service of this embodiment, the control unit 203 notifies or presents to the user eligible to apply for the special event that the user is eligible to apply for the special event by displaying information indicating that the user is eligible to apply for the special event on the display 141 of the terminal device 10. The user IDs stored in the storage unit 202 may be pre-associated with user IDs stored and managed in another system (e.g., a predetermined customer management system) different from the system 1. The association between user IDs may be performed by any method utilizing, for example, a predetermined API. The server 20 may then transmit information about users eligible to apply for the special event to the other system. This allows the other system to store and manage information about whether or not a user can apply for the special event. Therefore, the service provided by the other system can also control whether or not a user can apply for the special event and provide the user with information about whether or not the user can apply for the special event.

[0213] Note that even if a user who is not eligible to apply for a special event operates the terminal device 10 to access My Page, information that the user who is not eligible to apply for the special event can apply for the special event will not be notified or presented. However, at least one of the following information may be presented on the My Page of a user who is not eligible to apply for the special event: information that a special event will be held, information that the user cannot apply for the special event, or information that the user will be given the opportunity to participate in the special event by taking a predetermined user action (user action to acquire a predetermined NFT). This can increase the motivation of users who do not have the right to participate in the special event to take user action in order to participate in the next special event.

[0214] The special event may be a lottery event. In this case, the number of users who can apply for the lottery for the special event varies depending on the conditions stored in the "Application Conditions" field of the event table 202c. Therefore, the control unit 203 can set the parameter number of users who can apply for the lottery for the special event by setting the condition of the first parameter stored in the "Application Conditions" field based on information about the condition of the first parameter related to the application conditions transmitted to the server 20 from a terminal of, for example, the organizer or manager of the special event. For example, if the condition of the first parameter is set so that the parameter number of users who can apply for the lottery is reduced, the probability of winning the special event increases. Therefore, the control unit 203 can increase the probability of winning the lottery for a special event compared to the probability of winning the lottery for an event that is not a special event.

[0215] (If owning an NFT is a requirement for application) In the special event notification process shown in FIG. 17, a condition related to the first parameter was set as the application condition. However, for a special event, the application condition may be set not as a condition related to the first parameter, but as the possession of one or more specific types of NFTs. In this case, the "application condition" item in the event table 202c stores the possession of one or more NFTs related to one or more specific NFT type IDs as the condition, rather than the condition related to the first parameter. For example, the "application condition" item may store the possession of an NFT related to a history of participation in a specific event a as the condition.

[0216] Figure 19 is a flowchart showing an example of the operation of the server 20 and the distributed ledger system 90 in the special event notification process when the possession of one or more specific types of NFTs is set as an application condition.

[0217] The processing in steps S41 to S44 is the same as the processing in steps S31 to S34 shown in FIG.

[0218] In step S45, the control unit 203 identifies users who hold NFTs related to the special event through processing similar to that in step S35. However, in step S45, unlike the processing shown in Fig. 17, all users who hold NFTs related to the special event are identified as users who can apply for the special event. This allows users who hold NFTs related to the special event to equally acquire the right to apply for the special event.

[0219] The process of step S46 is similar to the process of step S38.

[0220] 19, if the special event is a lottery event, setting the NFT holding conditions so as to reduce the number of users who can apply for the lottery will increase the probability of winning the special event. Therefore, the control unit 203 can make the probability of winning the lottery for a special event higher than the probability of winning the lottery for an event that is not a special event.

[0221] The above description exemplifies a mode in which a first parameter is calculated based on NFTs held by a user and whether or not to allow a user to apply to participate in a special event is determined based on the first parameter. However, the server 20 can also apply the above process when selecting a number of users equal to or less than a predetermined number of users from the predetermined number of users. For example, the above process can be applied when granting a limited number of users the right to apply to purchase a specific product (e.g., a product related to a specific performer (especially limited edition goods)). This makes it easier for users who actively engage in user behavior (actively acquire NFTs) to obtain the product. On the other hand, it becomes difficult for those who are not fans of the performer, such as those who intend to resell the product at a high price, to obtain the product.

[0222] <Screen example> Figure 20 is a schematic diagram showing an example of a screen that shows information associated with NFTs held by a user, which is displayed on the terminal device 10 when the terminal device 10 accesses a personal page prepared for each user in the service of this embodiment.

[0223] The user name display section 1411 is an area that displays the user name of the user who has accessed the My Page.

[0224] The performer name display section 1412 is an area that displays the names of performers related to the NFTs held by the user.

[0225] The NFT information display section 1413 is an area that displays information associated with each NFT held by the user. The NFT information display section 1413 includes a date display section 14131, an NFT type name display section 14132, and a content display section 14133.

[0226] The date display section 14131 is an area that displays the date on which the user acquired the NFT. The date display section 14131 may display the date on which the user performed the user action related to the granting of the NFT.

[0227] The NFT type name display section 14132 is an area that displays the NFT type name. Specifically, the NFT type name display section 14132 displays a character string that indicates the NFT type name related to the NFT.

[0228] The content display section 14133 is an area that displays digital content associated with the NFT.

[0229] FIG. 21 is a schematic diagram showing an example of a screen showing event information displayed on the terminal device 10. As shown in FIG.

[0230] For each event, the event display section 1415 displays the date the event is held, the name of the event, and an application button for transitioning the screen to an application screen for the event. In the example shown in Fig. 19, the event display section 1415 includes areas 1415A, 1415B, 1415C, and 1415D that display information about each individual event.

[0231] The event display unit 1415 displays information about an event in which the probability of winning the lottery varies according to the first parameter, and information about an event in which application acceptance is determined according to the first parameter, in a manner that allows the information to be distinguished from other events. Hereinafter, information about NFTs refers to, for example, information about NFTs stored in the user table 202a to the point condition table 202h.

[0232] For example, icon 14151B included in area 1415B indicates that the event information displayed in area 1415B is a lottery event, and that the user's winning probability is changing (increasing) according to the user's first parameter. By accepting a selection operation of icon 14151B from the user, event display unit 1415 may display information about the NFT that contributed to the increase in winning probability.

[0233] Also, for example, icon 14152C indicates that the event whose information is displayed in area 1415C is an event for which application acceptance is determined according to a first parameter, and that the user can apply for the event. Event display unit 1415 may display information about the NFT that contributed to the application acceptance determination by accepting a selection operation of icon 14152C from the user.

[0234] Furthermore, for example, icon 14153D indicates that the event whose information is displayed in area 1415D is a lottery event, whether or not it is possible to apply for the event is determined according to a first parameter, and that the user can apply for the event. By accepting a selection operation of icon 14153D from the user, event display unit 1415 may display information about the NFT that contributed to the determination of whether or not to apply.

[0235] <Modification>

[0236] In the above embodiment, the control unit 203 granted an NFT of a type corresponding to the user action to a user who performed the user action. Then, the first parameter was calculated according to the type of NFT held. However, granting an NFT to a user is not essential. For example, the control unit 203 may store information related to the user action history (for example, information acquired by the above-mentioned action information acquisition module 2035, such as event attendance history, merchandise purchase history, and SNS posting history) in the storage unit 202. Then, the first parameter of each user may be calculated based on the user action history stored in the storage unit 202.

[0237] In the above embodiment, the user behavior was behavior that increased the fan rating. However, the behavior information acquisition module 2035 may acquire information about behavior that lowers the fan rating as the user behavior. Then, for a user who has performed behavior that lowers the fan rating, the control unit 203 may calculate a new first parameter by, for example, multiplying the first parameter by a predetermined factor less than 1 so that the calculated first parameter is lowered.

[0238] The following are examples of user behavior in this modified example. - Not attending an event despite obtaining a ticket. For example, the control unit 203 acquires ticket acquisition history for a specific event from the ticket table 202d. Then, after the event is held, it acquires admission history data for the event. The control unit 203 compares the ticket acquisition history with the admission history for the event to identify users who obtained a ticket but did not attend the event. The user transfers the ticket they obtained to another person on an unofficial distribution site. For example, the control unit 203 acquires the ticket ID of a ticket registered for sale on an unofficial distribution site from the server of the distribution site, and compares it with the ticket ID stored in the ticket table 202d to identify the user who transferred the ticket on the distribution site. The ticket was obtained from an unofficial distribution site. For example, the control unit 203 acquires the ticket ID of a ticket registered for sale on an unofficial distribution site from the distribution site's server, and compares it with the admission history data for the event venue related to the ticket to identify the user who obtained the ticket from the distribution site.

[0239] Furthermore, the control unit 203 may set behaviors that do not necessarily result in a low fan rating but that result in a low first parameter (making it less likely that a benefit corresponding to the first parameter will be received). For example, a user who has participated in an event featuring a specific performer a predetermined number of times or more may be identified from user participation history data for the event. Then, the first parameter may be calculated to be low for the user. This relatively increases the opportunities for users who have participated in events featuring the performer a small number of times or who have never participated before to participate in the event. This can promote an increase in new fans and the retention of fans with a short fan history.

[0240] Although several embodiments of the present disclosure have been described above, these embodiments can be embodied in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and modifications are intended to be included in the scope of the inventions and their equivalents as defined in the claims, as well as in the scope and spirit of the inventions.

[0241] <Additional Notes> The matters described in the above embodiments will be supplemented below. (Appendix 1) A program for operating a computer, the program causing a processor of the computer to perform the steps of obtaining information about user behavior taken by a user in relation to performers at an event, rather than a ticket purchase history for attending an event that has a limit on the number of attendees due to the size of the venue, and outputting a first parameter about the user based on the information about the user behavior. (Appendix 2) A program as described in Appendix 1, in which participation in an event requires advance application, and if the number of applications exceeds the maximum number of participants, participants are determined by lottery, and the program causes the processor to execute a step of changing the probability of winning the lottery according to a first parameter. (Appendix 3) A program as described in Appendix 1 or Appendix 2, in which whether or not participation in an event can be applied for is determined based on a first parameter, and the program causes a processor to execute a step of identifying users who can apply for the event based on the first parameter. (Appendix 4) 4. The program according to claim 3, wherein the program causes the processor to execute a step of notifying users who are eligible to register for the event that they are eligible to register for the event. (Appendix 5) The program of claim 3 or 4, wherein the event requires advance registration to participate, and if the number of registrations exceeds the maximum number of participants, participants are selected by lottery, and the probability of winning the lottery is higher than for events where the eligibility to register for participation is not determined based on the first parameter. (Appendix 6) 6. The program of claim 1, wherein in the step of outputting the first parameter, the program outputs the first parameter based on an NFT (Non-Fungible Token) held in the user's wallet and assigned to the user's wallet in connection with user behavior. (Appendix 7) The program described in Appendix 6, wherein in the step of outputting the first parameter, the first parameter is output based on the value of a predetermined point associated with the NFT. (Appendix 8) The program described in Appendix 7, in which the NFTs are associated with different point values ​​for each event. (Appendix 9) A program described in any one of Appendix 1 to Appendix 8, wherein in the step of outputting the first parameter, the first parameter is output based on the user's history of participation in a specified event related to the performers of the event. (Appendix 10) A program described in any one of Appendix 1 to Appendix 9, wherein in the step of outputting the first parameter, the first parameter is output based on the user's history of purchasing specified items related to the performers of the event. (Appendix 11) 11. A program as described in any one of Appendixes 1 to 10, wherein in the step of outputting the first parameter, the first parameter is output based on a history of posts made by a user regarding event performers on a social networking service. (Appendix 12) A program described in any one of Appendix 1 to Appendix 11, wherein in the step of outputting the first parameter, the first parameter is output based on a history of a user translating specified content related to a performer into other languages. (Appendix 13) A program described in any one of Appendix 1 to Appendix 12, wherein in the step of outputting the first parameter, the first parameter is output based on the user's length of membership in a specified membership service related to the performer. (Appendix 14) A program described in any one of Appendix 1 to Appendix 13, wherein in the step of outputting the first parameter, the first parameter is output based on whether or not the user is enrolled in a specified membership service related to the performer at a specific time. (Appendix 15) A method executed by a computer having a processor, the method comprising the steps of: obtaining information about user behavior taken by a user in relation to performers at an event, rather than a ticket purchase history for attending an event that has a limit on the number of attendees due to the size of the venue; and outputting a first parameter about the user based on the information about the user behavior. (Appendix 16) An information processing device having a control unit, the control unit performing the steps of acquiring information regarding user behavior taken by a user in relation to performers at an event, rather than a ticket purchase history for participating in an event that has a limit on the number of participants due to the size of the venue, and outputting a first parameter about the user based on the information regarding the user behavior. [Explanation of symbols]

[0242] 1. System 10...Terminal device 120…Communications Department 13...Input device 131...Touch-sensitive devices 14...Output device 15...Memory 16…Storage 19...Processor 20...Server 22...Communication IF 23...Input / output interface 25…Memory 26…Storage 29...Processor

Claims

1. A program for operating a computer, the program causing a processor of the computer to: obtaining information about user actions taken by users in relation to performers at an event that has a limited number of attendees due to the size of the venue, but not ticket purchase history for that event; outputting a first parameter for the user based on information about the user behavior; A program that executes the following.

2. The event requires advance registration for participation, and if the number of registrations exceeds the upper limit of the number of participants, participants are selected by lottery; The program causes the processor to: Executing a step of changing the probability of winning the lottery in accordance with the first parameter; The program according to claim 1.

3. Whether or not to apply for participation in the event is determined based on the first parameter; The program causes the processor to: executing a step of identifying users who can apply for the event based on the first parameter; The program according to claim 1.

4. The program causes the processor to: executing a step of notifying users who are eligible to apply for the event that they are eligible to apply for the event; The program according to claim 3.

5. The event is Participation requires advance application, and if the number of applications exceeds the participant limit, participants will be selected by lottery; and The probability of winning the lottery is higher than in an event in which the acceptance or rejection of an application for participation is not determined based on the first parameter. The program according to claim 3.

6. In the step of outputting the first parameter, outputting the first parameter based on a non-fungible token (NFT) held in the user's wallet and assigned to the user's wallet in connection with the user's behavior; The program according to claim 1.

7. In the step of outputting the first parameter, outputting the first parameter based on a value of a point associated with the NFT; The program according to claim 6.

8. The NFT is associated with a different point value for each of the events. The program according to claim 7.

9. In the step of outputting the first parameter, outputting the first parameter based on a history of the user's participation in a predetermined event related to performers of the event; The program according to claim 1.

10. In the step of outputting the first parameter, outputting the first parameter based on a history of the user purchasing predetermined items related to performers of the event; The program according to claim 1.

11. In the step of outputting the first parameter, outputting the first parameter based on a history of posts made by the user on a social networking service regarding performers of the event; The program according to claim 1.

12. In the step of outputting the first parameter, outputting the first parameter based on a history of the user translating predetermined content related to the performer into other languages; The program according to claim 1.

13. In the step of outputting the first parameter, outputting the first parameter based on the user's membership period in a predetermined membership service related to the performer; The program according to claim 1.

14. In the step of outputting the first parameter, outputting the first parameter based on whether the user is enrolled in a predetermined membership service related to the performer at a specific time; The program according to claim 1.

15. 1. A computer-implemented method comprising a processor, the processor comprising: obtaining information about user actions taken by users in relation to performers at an event that has a limited number of attendees due to the size of the venue, but not ticket purchase history for that event; outputting a first parameter for the user based on information about the user behavior; How to do it.

16. An information processing device including a control unit, The control unit obtaining information about user actions taken by users in relation to performers at an event that has a limited number of attendees due to the size of the venue, but not ticket purchase history for that event; outputting a first parameter for the user based on information about the user behavior; An information processing device that executes the above.

Images