Information processing device, information processing method, and program

Abstract

To provide an information processing device, an information processing method, and an information processing program for assigning higher value to a waiting time of participants in an event.SOLUTION: An event support device 10 includes an event storage unit 31, a user information storage unit 32, and a first user control unit 26. The event storage unit 31 stores, in association with one another, an event held at a predetermined venue, an event-holding date and time, and an address of an access destination that a user participating in the event access when he / she visits the venue on an event-holding date. The user information storage unit 32 stores, in association with one another, user identification information of the user and tokens held by the user. The first user control unit 26 issues an event-holding date waiting-time token according to the waiting time of the user, and sets the token as a token held by the user. The first user control unit 26 also issues an event-holding date action token according to an event-holding date action performed by the user and sets the issued token as the token held by the user.SELECTED DRAWING: Figure 4

Description

[Technical Field]

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

[0002] Patent Literature 1, for example, discloses a fan management server device that manages fans who support a specific sports team and evaluates the fans based on their support activities. This fan management server device is connected to user terminal devices of multiple users via a network and manages the multiple users' fan activities related to the sports team. The fan management server device includes an attendance detection unit, a location information acquisition unit, a fan activity information storage unit, and a fan activity management unit. The attendance detection unit detects users' attendance at a venue where an event related to the sports team is being held. The fan activity information storage unit stores the number of points to be awarded to the user for each predetermined fan activity. The fan activity management unit receives a report of the user's fan activity related to the sports team from the user terminal device of the user, refers to the fan activity information storage unit, and awards points to the user based on the reported fan activity, while also managing the history of points awarded to the user.

[0003] Patent Document 2 discloses a facility operation support system that provides users with points based on their waiting time at an attraction facility and assists in providing services or goods to them based on the points they have. This facility operation support system includes a server device communicably connected to a mobile terminal device via a network, and wireless transmitting devices located at first, second, and third locations along the user's route through the attraction. Either the mobile terminal device or the server device includes a waiting time measurement unit that measures the user's waiting time at the facility based on the time of wireless communication between the mobile terminal device and the wireless transmitting device. The waiting time measurement unit starts measuring the waiting time based on the time the mobile terminal device wirelessly communicates with the wireless transmitting device located at the first location, ends measuring the waiting time based on the time the mobile terminal device wirelessly communicates with the wireless transmitting device located at the third location, and determines the measured waiting time based on the wireless communication with the wireless transmitting device located at the second location. The system then calculates earned points based on a preset conversion rate according to the determined waiting time, and updates the user's accumulated points with the earned points. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Laid-Open No. 2015-092330 [Patent Document 2] JP 2018-084900 A Summary of the Invention [Problem to be solved by the invention]

[0005] In recent years, large facilities known as arenas, stadiums, and domes have become common venues for events such as concerts featuring specific singers, entertainers, and other entertainers. The larger the venue, the greater the number of spectators typically attending the event. The greater the number of attendees, the longer the waiting time in line for the doors to open. This waiting time before the event begins can be painful for participants. While the fan management server device described in Patent Document 1 and the invention described in Patent Document 2 award points based on the fan activities of sports team fans and the waiting time at an attraction facility, respectively, there is still room for improvement in how the waiting time before the event begins is valued.

[0006] Therefore, an object of the present invention is to provide an information processing device, an information processing method, and an information processing program that can add value to the waiting time of event participants. [Means for solving the problem]

[0007] The information processing device of the present invention includes an event storage unit, a user information storage unit, and a first user control unit. The event storage unit stores, in association with each other, an event held at a predetermined venue, the date and time of the event, and an address of a destination accessed by a user participating in the event when the user arrives at the venue on the day of the event. The user information storage unit stores, in association with each other, user identification information of the user participating in the event and a possession token held by the user. The first user control unit issues an opening day waiting time token, which is preset in association with a waiting time from accessing the address until the venue opens, in accordance with the user's waiting time, and sets the token as the possession token of the user to which the token is issued. The first user control unit further issues, in accordance with the user's opening day action, an opening day action token based on the degree of difference between an opening day action acquired on the opening day from the user who accessed the address and a reference action that is an evaluation criterion for the opening day action, and sets the token as the possession token of the user to which the token is issued.

[0008] It is preferable that the first user control unit issues an attendance token based on the difference between a recommended attendance time previously set for the user and the user's arrival time according to the user's arrival time, and makes the token held by the user to whom the token is issued.

[0009] It is preferable that the information processing device further includes a second user control unit that sets at least one of a pre-event waiting time token based on the time from when the user is accepted to a specified date and time before the event, and a pre-event action token based on a pre-event action obtained from the user between when the user is accepted and the specified date and time, as the held token of the user to be issued.

[0010] It is preferable to further include a third user control unit that issues a specific post-event token to a user as a held token after the end of the event based on the held token before the event is held.

[0011] It is preferable that the third user control unit ranks multiple users based on the tokens they hold before the event, and issues post-event tokens to users ranked at or above a predetermined rank as their held tokens.

[0012] The information processing method of the present invention includes an event storage step, a user information storage step, and a first user control step. The event storage step associates and stores an event held at a specified venue, the date and time of the event, and the address of the access destination that users participating in the event will access when they arrive on the day of the event. The user information storage step associates and stores user identification information of users participating in the event with tokens held by the users. The first user control step issues an event day waiting time token, which is preset to correspond to the waiting time from accessing the address until the venue opens, in accordance with the user's waiting time, and sets the token as the held token for the user to which the token is issued. The first user control step further issues an event day action token based on the degree of difference between an event day action acquired on the day from the user who accessed the address and a reference action that is an evaluation criterion for the event day action, in accordance with the user's event day action, and sets the token as the held token for the user to which the token is issued.

[0013] The information processing program of the present invention causes a computer to execute the above steps. [Effects of the Invention]

[0014] According to the present invention, the waiting time of event participants can be made more valuable. [Brief explanation of the drawings]

[0015] [Figure 1A] 10A and 10B are explanatory diagrams of images displayed on a user terminal of the event assistance system according to the embodiment; [Figure 1B] 10A and 10B are explanatory diagrams of images displayed on a user terminal of the event assistance system according to the embodiment; [Figure 1C] 10A and 10B are explanatory diagrams of images displayed on a user terminal of the event assistance system according to the embodiment; [Figure 2] FIG. 1 is an explanatory diagram of phases. [Figure 3] FIG. 1 is a configuration diagram of an event support system. [Figure 4] FIG. 1 is a configuration diagram of an event support device. [Figure 5] FIG. 2 is an explanatory diagram of a storage mode of an event storage unit. [Figure 6] FIG. 2 is an explanatory diagram of a storage mode of a user information storage unit. [Figure 7] FIG. 10 is an explanatory diagram of a storage mode of a token storage unit. [Figure 8] FIG. 10 is an explanatory diagram illustrating the concept of a token contract that indicates the start of a waiting time. [Figure 9] FIG. 1 is an explanatory diagram showing the concept of an attendance token contract. [Figure 10] FIG. 10 is an explanatory diagram illustrating the concept of a waiting time token contract. [Figure 11] FIG. 10 is an explanatory diagram illustrating the concept of an action token contract. [Figure 12] FIG. 1 is an explanatory diagram showing the concept of an attendance token contract. [Figure 13] FIG. 10 is an explanatory diagram illustrating the concept of a post-event token contract. DETAILED DESCRIPTION OF THE INVENTION

[0016] An event assistance system (hereinafter simply referred to as the "assistance system") 11 (see FIG. 3) including an event assistance device (hereinafter simply referred to as the "assistance device") 10 (see FIG. 3), which is an example of an embodiment of the present invention, is for assisting an event held at a specified venue. Multiple users who visit the venue and participate in the event use their respective terminals (hereinafter simply referred to as user terminals) 12A, 12B, 12C, ... (see FIG. 3) to support performers appearing in the event (e.g., singers appearing in a concert, talent, or other artists) before the event begins, i.e., while waiting for the event, and are issued tokens according to the support activities they have performed. Users can check the tokens they have acquired and transfer or receive tokens using user terminals 12A, 12B, 12C, ...

[0017] For example, as shown in FIG. 1A, in the case of supporting an event "X Concert" to be held at "Y Dome" where the performer is "X," the support system 11 displays a first image G1, a second image G2 (see FIG. 1B), and a third image G3 (see FIG. 1C) on the displays of the user terminals 12A, 12B, 12C, etc., alternatively by a user's display switching operation. If the display is a touch panel display, the display switching operation corresponds to a touch operation on a tab. A "Home" tab image, which is an example of the first image G1, displays a list of image sections G1a and G1b showing tokens as a "history of achievements to date," which is a history of past support activities associated with the event. The tokens are acquired in response to the support activities that the user has performed. By visually checking this list, the user can confirm the support activities they have performed and the tokens they have acquired as a result.

[0018] As shown in FIG. 1B, the display of user terminals 12A, 12B, 12C, etc. displays a list of support activities that the user can perform on the day the image is displayed in a "Today's Mission" tab image, which is an example of second image G2. When the user selects and performs one of the multiple support activities displayed in the list, the support activity for that day is registered. When the "Home" tab image shown in FIG. 1A is subsequently displayed, an image portion showing the token for the performed support activity is added and displayed. In this way, users can use their respective user terminals 12A, 12B, 12C, etc. to check the tokens they have acquired and the support activities they have performed through the tokens. This allows each user to add meaning and value to the waiting time for an event by performing support activities until the event is held.

[0019] The tokens may be either Fungible Tokens (FTs) or Non-Fungible Tokens (NFTs). In this example, all tokens are NFTs, as described below, but they may be both NFTs and FTs, or either one. The NFTs as tokens may differ in either type or number depending on the support activity, or points may be assigned to each NFT, and a predetermined NFT may be issued and acquired by the user depending on the support activity. In this example, the latter is used, and, for example, as shown in FIG. 1B, an NFT is assigned to each of the support activities, such as "visiting Y Dome," "playing a song," "watching a weekly music video" ("MV" stands for music video), and posting an "album review," to which specific points are assigned. The NFT for "attending Y Dome" as a support activity is an NFT with 100 points per NFT, as displayed as "100 points / NFT," the NFT for "playing songs" and "watching weekly MVs" is an NFT with 50 points per NFT, as displayed as "50 points / NFT," and the NFT for "writing album reviews" is an NFT with 200 points per NFT, as displayed as "200 points / NFT."

[0020] Furthermore, as shown in FIG. 1C, the "Ranking" tab image as the third image G3 ranks users based on the tokens (hereinafter referred to as "held tokens") acquired and held by each of multiple users, and displays the top-ranked users and the total points associated with their held tokens. By viewing this image, each user can understand which other users are particularly active in supporting performer "X" and the level of their support activities. As a result, the level of other users' support activities for performer "X" can be understood, which leads to the promotion of support activities and increases the value of waiting time for the event for each user. Note that the images displayed on the displays of user terminals 12A, 12B, 12C, etc. are not limited to the first image G1 to the third image G3, which are displayed in a switching manner.

[0021] The support activities performed by users and the tokens issued are set for each phase, which is a time period before and after the target event, divided along a timeline from any time before the event to after the event. The number of phases and the phase transition timing, which separates the phases, may be set arbitrarily. Furthermore, the end timing of the final phase in the timeline need not be set. In that case, the phases are divided along a timeline from any time before the event to after the event. In this example, the event is the aforementioned "X Concert." As shown in Figure 2, the period from the start of participation acceptance, when participation in the event is accepted and user registration begins, to the end of the issuance of the specified NFTs, which begin issuance 30 minutes after the event ends, is divided into three phases, Phases 1 to 3, in this order. Phases 1 and 2 are set before the start of the event. For example, Phase 1 is the phase from the start of participation acceptance until the day before the event, and Phase 2 is the phase from the start of the event on the day of the event until the doors open. Opening refers to the opening of the venue where the event is held and allowing participating users to enter. The third phase will take place after the event ends, from 30 minutes after the event ends until the issuance of the specified NFTs.

[0022] The support system 11 shown in Figure 3 is an example of an information processing system for supporting an event held at a specified venue. The support system 11 includes a support device 10, which is an example of an information processing device, user terminals 12A, 12B, 12C, etc. used by each of multiple users participating in the event, a two-dimensional code display terminal 15, a client terminal 16, and a blockchain network 17. The support device 10, the two-dimensional code display terminal 15, and the blockchain network 17 constitute an event support unit (hereinafter simply referred to as the "support unit") 18. In the following description, when there is no need to distinguish between the user terminals 12A, 12B, 12C, etc., they will be referred to as user terminals 12.

[0023] The support device 10, the user terminal 12, the two-dimensional code display terminal 15, the client terminal 16, and the blockchain network 17 can communicate with each other via the communication network N, and transmit and receive various information. For example, when a person using the user terminal 12A transmits a participation request including a name, identification information (such as a user name described below), contact information, etc. in the first phase to make a participation request to request participation in an event (for example, a request to purchase an event ticket), the support device 10 acquires this participation request, registers the user as a user participating in the event, and transmits the user registration information to the user terminal 12A that transmitted the participation request.

[0024] As described above, the user terminal 12 is a terminal device used by a user, and the user uses the services provided by the support device 10. The user terminal 12 displays various images, including the first image G1 to the third image G3 described above with reference to FIG. 1, in response to input operations by the user. The user terminal 12 also performs input operations related to cheering activities available in each phase, and outputs in response to the input operations (such as displaying an image and / or outputting sound). For example, in the first phase, an input operation (such as a tap operation) may be performed to display one of the first image G1 to the third image G3, select one of the multiple cheering activities listed in the second image G2 (see FIG. 1B), for example, "play music," and request its execution, play music as an output in response to this input operation, or request the registration of a cheering activity in which the playback of music constitutes the execution of the cheering activity.

[0025] The client terminal 16 is an example of a terminal device used by a client that causes the support device 10 to perform various processes. Examples of clients include an organizer that hosts an event, a sponsor that supports the event, and an agency or company to which performers appear at the event belong. The client terminal 16 performs input operations related to the event. Examples of input operations related to the event include input operations such as setting and registration requests for the event, the date and time of the event, the location, the start time of participation acceptance, phases, tokens, etc., and input operations for managing users.

[0026] The user terminal 12 and the client terminal 16 are computers equipped with a display (display unit) and an input unit (keyboard, mouse, touch panel display, etc.) for performing input operations. The user terminal 12 preferably further includes a speaker for outputting sound such as music playback. The user terminal 12 and the client terminal 16 may be any of a personal computer, a mobile terminal, a smartphone, etc., and are not particularly limited.

[0027] The user terminal 12 and the client terminal 16 may operate on a browser by receiving a program that runs on the browser from the support device 10, or may be equipped with predetermined application software and operate by executing the program of this application software. Although only one client terminal 16 is shown in Fig. 3, there may be multiple client terminals 16, such as when multiple clients each use one terminal.

[0028] The support system 11 may further include a management terminal (not shown). The management terminal is a terminal device that performs various settings of the support device 10, and is connected to the support device 10 via the network N to send and receive various information. Like the client terminal 16, the management terminal is a computer that has an input unit for performing input operations and a display.

[0029] The support device 10 performs predetermined processing in response to input of information from the user terminal 12, the client terminal 16, the blockchain network, and the management terminal.

[0030] The assistance device 10 is configured with a computer. A predetermined program is installed in the assistance device 10, and execution of this program causes the assistance device 10 to function as each unit described below and perform predetermined processing. The program causes the computer to execute an event storage step, a user information storage step, a first user control step, and the like. The event storage step associates and stores an event held at a predetermined venue, the date and time of the event, and the address of the access destination that users participating in the event will access when they arrive on the event day. The user information storage step associates and stores user identification information of users participating in the event with tokens held by the users. The first user control step issues a waiting time token for the user, which is preset in association with the waiting time from accessing the address until the venue opens, in accordance with the waiting time of the user, and sets the token as the held token of the user to which the token is issued. The first user control step further issues an action token for the user's action on the event day based on the degree of difference between the action acquired on the event day from the user who accessed the address and a reference action that is an evaluation criterion for the action on the event day, and sets the token as the held token of the user to which the token is issued. The program may be installed in the client terminal 16 to allow the client terminal 16 to function as the support device 10.

[0031] The two-dimensional code display terminal 15 is a terminal device that is installed near and outside the venue on the day of the event and displays a two-dimensional code on its display, and is composed of a computer equipped with a display. The two-dimensional code indicates the access destination for users who visit the venue to access the support device 10, and is read by the user terminal 12.

[0032] The blockchain network 17 is a platform for utilizing blockchain technology, and comprises a distributed system processed by multiple node devices on a network (which may be network N or a network different from network N). The node devices are computers, and mutual transmission and reception between the multiple node devices is performed via P2P (Peer to Peer). As a result, even if a malfunction occurs in one of the multiple node devices, it does not result in a malfunction of the entire blockchain network 17, and subsequent processing can continue to be maintained.

[0033] The blockchain network 17 compiles various transaction information, such as transaction information between clients and users and transaction information between users, into blocks as transactions, and stores and manages the generated blocks in a chain in chronological order in each node device. Approval of a newly generated block is performed through consensus building processing in the distributed network, i.e., consensus building processing among multiple node devices. Each block stores the hash value of the previous block (the block with the block number one smaller), which makes blockchain difficult to tamper with and allows it to be used as a highly secure and continuous means of data generation and storage.

[0034] The assistance device 10 will be described with reference to Figs. 4 to 7. The assistance device 10 is composed of a control unit 21, a registration unit 22, first to third user control units 26 to 28, a database DB, etc. The database DB has an event storage unit 31, a user information storage unit 32, a token storage unit 33, and a blockchain storage unit (hereinafter referred to as BC storage unit) 34.

[0035] The event storage unit 31 stores, in association with one another, event information relating to an event, such as the event, its opening date and time, location, participation acceptance start time, set phase, access destination address, and participating users' names and identification information (hereinafter referred to as user IDs) (see FIG. 5). The access destination address is the address of the access destination that a user accesses via the network N when they arrive at the event on the day of the event, and is, for example, a URL (Uniform Resource Locator).

[0036] The user information storage unit 32 stores the user's name, username used for publication, user ID, contact information, the recommended arrival time and access timing described below, the tokens held by the user, and the total points of the held tokens in association with each other as user information (see FIG. 6). The user's ID may be the same as the address indicating the registration location where individual user information is stored (registered) in the support system 11. The contact information is an email address, telephone number, etc., used when sending messages (including announcements, etc.) from the support unit 18 to the user via the network N (see FIG. 3).

[0037] The token storage unit 33 stores, for each event, the event information, including the phase, token (NFT in this example), and points for each token, in association with each other (see FIG. 7). However, if the token is digital art (image), the image data may be stored in distributed storage as described below, and the storage location may be stored as metadata on the blockchain, as is done in this example. In the example shown in FIG. 7, multiple pre-event waiting time tokens and multiple pre-event action tokens are set as tokens in the first phase. Multiple event day waiting time tokens, multiple attendance tokens, and multiple event day action tokens are set as tokens in the second phase. Multiple post-event tokens are set in the third phase. In this example, the tokens in the first and second phases are NFTs conforming to the ERC1155TD standard, and the tokens in the third phase are NFTs conforming to the ERC721 standard, but this is not limited to this example. The token storage unit 33 in this example stores transaction information for each token, but the transaction information for each token may also be stored in a separate storage unit that stores the transaction information.

[0038] NFTs in the ERC1155TD standard simultaneously represent multiple tokens using a single smart contract. This makes the balanceOf function different from those in the ERC20 and ERC777 standards. NFTs in the ERC1155TD standard have an additional factor for the token identifier used to query the id balance. The ERC1155TD standard assigns a weight to each NFT and defines points based on this weight. This allows the total points to be calculated based on the number of NFTs held by a user and the points associated with each NFT. By calculating the total points, the user's support activity can be evaluated based on the total points, and their activity can be valued and expressed.

[0039] The pre-event waiting time token is a token that is set based on the pre-event waiting time, which is the time from when the user is accepted until the specified date and time before the event is held. The longer the pre-event waiting time, the higher the points are set. For example, in the example shown in FIG. 7, the "pre-event waiting time token A" is set to "200" points for a waiting time of 60 days or more, the "pre-event waiting time token B" is set to "100" points for a waiting time of 30 days or more but less than 60 days, and the "pre-event waiting time token C" is set to "50" points for a waiting time of less than 30 days. As a result, the earlier a user registers after the participation acceptance period begins, the more points they can obtain pre-event waiting time tokens.

[0040] The pre-event action token is a token that is set based on pre-event actions acquired from the user between the time of participation acceptance and the specified date and time. The pre-event action token is set with higher points for pre-event support activities that require more effort and / or time. In this example, the pre-event action "visit Y Dome" is set to "100" points, "play music" to "50" points, "watch weekly music videos" to "50" points, and "review album" to "200" points. Note that "visit Y Dome" is set as a pre-event action that supports the event and ultimately supports the performers by previewing the venue location before the event, which is effective in avoiding congestion, including people lingering around the venue, on the day of the event.

[0041] The event day waiting time token is set in advance in association with the waiting time from when the address indicated in the two-dimensional code is accessed until the venue opens (hereinafter referred to as the event day waiting time). Points for the event day waiting time token may be set based on the time period when it is predicted that the area around the venue will be prone to congestion, or higher points may be set the longer the event day waiting time.

[0042] The event day action token is set based on the difference between an event day action acquired on the event day using the user terminal 12 by a user who accesses the address indicated in the two-dimensional code displayed on the two-dimensional code display terminal 15 and a reference action, which is the evaluation standard for the event day action. If a game (including a quiz) is set as the event day action, clearing (passing) a stage in the game is set as the reference action, and this reference action serves as the criterion for determining the difference. That is, if the stage is cleared, the difference is set to zero (0), which is the same as the reference action, and if the stage is not cleared, the maximum difference (e.g., 100) is set, and a token with points corresponding to zero difference and a token with points corresponding to the maximum difference are set. The points of the token corresponding to zero difference are set to be greater than the points of the token corresponding to the maximum difference. If posting a comment is set as the event day action, at least one of the length of the comment and the content of the comment can be set as the reference action. For example, if the length of the comment is set as the reference action, it can be set based on the number of characters in the comment posted in text format. In this example, a dissimilarity of zero (0) is set for comments consisting of one or more characters, and the maximum dissimilarity (for example, set to 100) is set for comments consisting of less than one character, and points corresponding to zero dissimilarity and the maximum dissimilarity are set. The point corresponding to zero dissimilarity is set to be higher than the point corresponding to the maximum dissimilarity. If no comments are posted, there will be no comments of one or more characters, so the dissimilarity will be the maximum value, and so the points will be smaller than when a comment of one or more characters is posted, and in this example, it is set to zero (0). If the content indicated in the comment is to be the reference action, one method is to set point tokens that are weighted in advance based on vocabulary in text format, and issue tokens with the set points for vocabulary indicated in the posted comment.

[0043] The attendance token is set based on the difference between the user's arrival time and the recommended arrival time set in advance for the user. The smaller the difference, i.e., the closer the match between the recommended arrival time and the arrival time, the higher the points are set for the attendance token.

[0044] Post-event tokens are tokens that are set based on the total points of tokens held by users up until the start of the event. Post-event tokens may be NFTs of digital art, or NFTs that are bonds to acquire specific digital art. The design of the digital art may be set according to the total points. Also, the higher the total points, the fewer NFTs that are issued as post-event tokens.

[0045] The support unit 18 may have a distributed storage (not shown) that stores an image file of an NFT (an image file of digital art) instead of or in addition to the token storage unit 33. The support unit 18 in this example also has a distributed storage, which is a storage unit provided in each of the multiple node devices that make up the blockchain network 17.

[0046] The BC storage unit 34 stores each of the multiple blockchains. Each blockchain is generated in the blockchain network 17, sent from the blockchain network 17, and stored in the BC storage unit 34 by the control unit 21. However, the support device 10 does not necessarily have to include the BC storage unit 34.

[0047] The control unit 21 comprehensively controls the registration unit 22, the first to third user control units 26 to 28, etc. in the support device 10, and also transmits and receives various information to and from the blockchain network 17. When the control unit 21 acquires event information from the client terminal 16, it stores the acquired information in at least one of the event storage unit 31 and the token storage unit 33 of the database DB, depending on the acquired information.

[0048] For example, when an input operation related to an event is performed on the client terminal 16 and a registration request is sent from the client terminal 16, the control unit 21 stores the event information in the event storage unit 31 and the token storage unit 33 according to the content of the event information. When the event information includes the event, its date and time, location, participation acceptance start time, phase, and access address, the control unit 21 stores these in the event storage unit 31. When the event information includes the type of NFT for each phase and the points for each NFT, the control unit 21 generates identification information (hereinafter referred to as a token ID) for each NFT, associates the acquired NFT type, points, and token ID with the phase, and stores them in the token storage unit 33. The control unit 21 has a time counter, and when it is time to start accepting participation for the event, it sends a registration request to the blockchain network 17, requesting that the start of participation acceptance for the event be registered in a blockchain block. The control unit 21 also acquires the block number of a block in which various information is registered from the blockchain network 17, and stores the block number in at least one of the event memory unit 31, the user information memory unit 32, the token memory unit 33, and the BC memory unit 34, depending on the type of registered information.

[0049] In the first phase, when the control unit 21 receives the above-mentioned participation request sent from the user terminal 12, it inputs the participation request to the registration unit 22. In addition, the control unit 21 sends to the blockchain network 17 a generation instruction to generate a block with block number 1, which will be the first block of the blockchain, when participation acceptance, described below, begins, and a block generation instruction to generate blocks with block numbers 2, 3, ..., and update the blockchain every predetermined period of time (15 seconds in this example). The block with block number 1 is the first block of the blockchain. The generation of the blockchain is referred to as including the updating of the blockchain.

[0050] When the registration unit 22 receives a participation request, it stores the name of the person included in the participation request in the event storage unit 31 and the user information storage unit 32 as a user participating in the event, and also generates a user ID and associates it with the user and stores it in the event storage unit 31 and the user information storage unit 32. The registration unit 22 also stores the user name, contact information, and other information included in the participation request in the user information storage unit 32 via the control unit 21. The registration unit 22 then transmits user registration information to the user terminal 12, which is the sender of the participation request, via the control unit 21. This allows the person who sent the participation request to confirm that they have been registered as a user on the user terminal 12, and they can then support the user and request and acquire NFTs. The registration unit 22 sends a registration instruction to the blockchain network 17 to instruct it to register the registered user and the timing at which the user's waiting time in the first phase will start counting in the next block to be generated.

[0051] The registration unit 22 further generates a recommended arrival time for each user at a predetermined timing (period), associates the generated recommended arrival time with the user, and stores the generated recommended arrival time in the user information storage unit 32. The timing of generating the recommended arrival time may be set by inputting information into the client terminal 16, or may be set in advance in a program that operates the support device 10. The recommended arrival time is set for the event date to alleviate congestion around the venue (goods sales area, restaurants, nearest train stations, etc.) on the event date. The registration unit 22 transmits the recommended arrival time to the user terminal 12 via the control unit 21 at a predetermined timing. Since the recommended arrival time is set for each user and the arrival times of multiple users are dispersed in time, congestion around the venue on the event date is alleviated. Furthermore, for users, the timing of their arrival serves as a means for obtaining attendance tokens with higher points.

[0052] The first user control unit 26 performs a predetermined process in the second phase. That is, it issues an event day waiting time token in accordance with the event day waiting time, stores the token in the user information storage unit 32 as a token held by the user, i.e., the user to whom the token is issued, and sends a recording request to the blockchain network 17 via the control unit 21 to record the event day waiting time token for the user. The event day waiting time is the time from when the first user control unit 26 accesses the access destination indicated in the two-dimensional code from the user terminal 12 and receives a check-in notification (arrival notification) notifying the arrival of the event to the opening of the event venue. A predetermined check-out operation using the user terminal 12 may be set in advance, and the time when the check-out notification notifying the check-out is received may be considered the opening of the event venue. The event day waiting time may be calculated using a time counter provided in the first user control unit 26, or the timings of the check-in notification and the opening of the event venue may be registered in blocks, and the time may be calculated based on the difference between the block number where the check-in was registered and the block number where the opening of the event venue was registered. In this example, the latter method is used.

[0053] The event day waiting time token may be a user's possession token in response to the calculation of the event day waiting time, or may be a user's possession token in response to a token request for the event day waiting time token received from the user terminal 12. In this example, the latter is used.

[0054] The first user control unit 26 further issues the above-mentioned event day action token in accordance with the user's event day action, stores it in the user information storage unit 32 as a token held by the user to whom it is issued, and sends a recording request to the blockchain network 17 via the control unit 21 to record the event day action token for that user.

[0055] Event day actions are executed using the user terminal 12, and various actions can be set, such as games related to performers (including quiz games) and posting comments. Event day actions are stored in an action storage unit (not shown) included in the first user control unit 26, and are sent to the user terminal 12 in response to a display request for an action menu from the user terminal 12, where they are displayed as a list. When an execution request is received from the user terminal 12 requesting execution of a selected event day action, the action calculation unit included in the first user control unit 26 transmits to the user terminal 12, for example, a game program for executing the event day action and a posted image for posting a comment, for display. Event day action tokens corresponding to the game difficulty, reaction speed, content of the posted comment, etc. are set in advance and stored in the token storage unit 33, so that event day action tokens corresponding to the executed event day action can be used as the user's owned tokens. Furthermore, users who performed event day actions may be ranked based on the total held tokens of the event day action tokens, and tokens corresponding to the ranks may be set as event day action tokens. A quiz, which is an example of a game, may be generated using AI, which may determine whether the answers obtained are correct or incorrect, and may score the answers accordingly.

[0056] The first user control unit 26 issues the above-mentioned attendance token according to the user's arrival time, stores it in the user information storage unit 32 as a token held by the user to whom it is issued, and sends a recording request to the blockchain network 17 via the control unit 21 to record the attendance token for the user.

[0057] The second user control unit 27 performs a predetermined process in the first phase. The second user control unit 27 stores at least one of a pre-event waiting time token and a pre-event action token in the user information storage unit 32 as a token held by the user to be issued. The second user control unit 27 also sends a recording request to the blockchain network 17 via the control unit 21 to record the pre-event waiting time token for the user. The pre-event waiting time token may be made a user's token in response to calculation of the pre-event waiting time, or may be made a user's token in response to a token request for a pre-event waiting time token received from the user terminal 12. In this example, the latter is used. In the latter case, an interest token having interest points may be set for the pre-event waiting time every time a certain amount of time elapses, and the pre-event waiting time token and the interest token may be issued to the user using the user terminal 12 in accordance with the timing of the token request from the user terminal 12. This allows the user to hold a pre-event waiting time token that takes into account the interest token, thereby increasing the value of the waiting time for the user. In addition, a token issued upon logging in once per day and treated as a possession token may be used as a pre-event waiting time token.

[0058] Pre-event actions are executed using the user terminal 12. The pre-event action "Visit Y Dome" can be stored in the event support device 10 by, for example, placing a poster announcing the event around the event venue and displaying a two-dimensional code indicating the access destination on the poster. The user terminal 12 can read and access the two-dimensional code, which can then be stored in the event support device 10. Instead of a poster, a digital signage display may be used. Various actions can be set, such as games (including quiz games) related to performers and posting comments. Pre-event actions are stored in an action storage unit included in the second user control unit 27 and transmitted to the user terminal 12 in response to a display request for an action menu from the user terminal 12, where they are displayed as a list, as shown in FIG. 1B. When an execution request is received from the user terminal 12 requesting execution of a pre-event action with one action selected, the action calculation unit included in the second user control unit 27 transmits, for example, a program for executing the pre-event action to the user terminal 12 and causes the user terminal 12 to display the program. By setting a pre-opening action token corresponding to the executed pre-opening action in advance and storing it in the token storage unit 33, the pre-opening action token corresponding to the executed pre-opening action can be made into the user's owned token.

[0059] The third user control unit 28 performs a predetermined process in the third phase. That is, after the end of the event, a specific post-event token corresponding to the total points of the held tokens of the user is issued based on the tokens held by the user before the event is held, and the specific post-event token is stored in the user information storage unit 32 as the held token of the user. In this way, tokens are issued according to the support activities in the first and second phases, so that the waiting time until the event is valued more highly for the user. The third user control unit 28 also sends a recording request to the blockchain network 17 via the control unit 21 to record the post-event token for the user.

[0060] The third user control unit 28 may rank multiple users based on the tokens they held before the event, and issue post-event tokens to users ranked at or above a predetermined rank as their held tokens. Ranking may be based on the type of tokens held or the total points of the tokens held, with the latter being used in this example. Ranking may be performed multiple times at appropriate times, and each time ranking is performed, tokens according to the rank may be issued.

[0061] The third user control unit 28 preferably sends the names of users ranked at or above a predetermined rank, along with their ranks, to each of the multiple user terminals 12 via the control unit 21. In this example, the control unit 21 generates the aforementioned third image G3 (see FIG. 1C ), which displays a list of multiple users ranked at or above a predetermined rank, and sends it to each user terminal 12 for display. This allows users to use the user terminal 12 to check the level of activity of the support activities of the highly ranked users, compare their own support activity activity with that of other users, and so on. This motivates each user to further increase their support activities in the future. In this way, support activities before an event are reflected after the event ends and are converted into high-value-added post-event tokens, motivating users to increase their support activities before the event and making the waiting time until the event begins more valuable.

[0062] The third image G3 (see FIG. 1C) may have a button B1 (see FIG. 1C) for praising users who have been ranked at or above a predetermined rank. When each user touches this button B1 on the user terminal 12, the number of people who "applaud" the user, indicating that they have praised the user, increases by one, and the number of people shown in the "applaud" column increases with each touch. This allows each user to recognize that the time they have spent supporting the user up to that point has been valued and made meaningful.

[0063] The third user control unit 28 may further transfer and receive at least one of the NFTs, the held tokens and the post-event tokens, between users. The transfer and reception of NFTs is not limited to between users of a common event, but may also be between users registered as users who use the services provided by the support unit 18. In this example, such transfer and reception is enabled by using a blockchain.

[0064] The blockchain network 17 acquires information such as user registration, the timing of the start of waiting time, and token issuance via the control unit 21, and records this information in blocks to generate a blockchain. That is, each of the multiple node devices functions as an authentication device that authenticates transaction information and the like indicated in this information. When a node device is authenticated by the multiple node devices constituting the blockchain network 17, a blockchain is generated in which the authenticated information is recorded in a block. The blockchain network 17 generates a block in which the start of event participation acceptance is registered, and further generates a block in which transaction information such as the issuance of each token and its ownership by a user, and the transfer and acquisition of tokens is registered, thereby generating a blockchain linked to the previously generated block. In this example, a blockchain is generated in which blocks generated by registering the above various information are linked to an existing blockchain. When generating a block, a block number is generated, and the block number is registered in the generated block. The blockchain network 17 may also acquire a block generation instruction from the control unit 21 and start generating blocks and blockchains in response to this generation instruction. In this case, the start timing for block generation and a generation instruction are sent to the blockchain network 17 in advance, and when the start timing arrives, the blockchain network 17 generates a block with block number 1 and begins generating the blockchain.

[0065] For example, a node device of the blockchain network 17 receives a recording request from the support device 10 to record an event date waiting time token for a user. The recording request includes a token ID and a user address. The user address is generated as user identification information for registration in a blockchain block when the user first accesses the support device 10 and is transmitted to the user terminal 12. This user address is transmitted from the user terminal 12 to the support device 10 when the aforementioned participation request is made and is also used as the aforementioned user ID. The node device identifies the last block of the blockchain it stores, i.e., the block number of the most recently generated block, increments the number by 1, sets the block number of the new block, and generates a block including the token ID, user address, and block number as transaction information, thereby setting the block as the final block of the blockchain. The node device then transmits transaction information including the block number, user address, and token ID recorded in the newly generated block to the support device 10. When transaction information is input, the control unit 21 identifies the token ID included in the transaction information in the token storage unit 33, and stores the user address and block number as transaction information for the identified token ID in the token storage unit 33. Furthermore, when transaction information is input, the control unit 21 identifies the user address included in the transaction information in the user information storage unit 32, and associates the token ID with the identified user address as indicating the held token and stores the associated token. The support device 10 may be provided with a BC storage unit 34 that stores a blockchain, or a blockchain generated from the blockchain network 17 may be sent to the support device 10 and stored in the BC storage unit 34.

[0066] In this example, the blockchain network 17 generates a token (NFT) that indicates the start of the waiting time. As shown in FIG. 8, the token that indicates the start of the waiting time sets timestamps for the start and end of the waiting time, and the start of measurement of the waiting time for each user is recorded as a mint (MINT) in the next generated block. Transaction information T1 that indicates the issuance of the waiting time token includes an "owner address" as the user address, a token ID, and a block number. In this example, numbers corresponding to the block numbers are generated sequentially in the node devices of the blockchain network 17, and the node devices are configured to automatically register the numbers corresponding to the block numbers in the contract, but for convenience, they are referred to as "block numbers" in FIG. 8.

[0067] When a user checks in by accessing the destination indicated by the two-dimensional code, the contract for the token indicating the start of the waiting time contains the event date waiting time token, the "block number" of the block where the check-in is registered, the user address of the accessing user, and the token ID.When a user checks out, the "block number" is rewritten from the "block number" of the block where the check-in is registered to the "block number" where the check-out is registered.This contract is owned by the client.

[0068] The token indicating the start of waiting time affects each of the waiting time tokens (pre-event waiting time tokens and event day waiting time tokens), action tokens (pre-event action tokens and event day action tokens), attendance tokens, and post-event tokens. For example, the post-event token depends on the action token and the token indicating the start of waiting time, and the action token depends on the token indicating the start of waiting time. In other words, the direction of token influence starts from the token indicating the start of waiting time, and the transaction information in each contract for the waiting time token, action token, and attendance token is determined depending on this starting point, and the transaction information in the contract for the post-event token is determined depending on the action token.

[0069] When setting and issuing an arrival token, the contract owner (client in this example), who is the owner of the contract, sets the recommended arrival time. The recommended arrival time can also be set by specifying the block number corresponding to that time. The recommended arrival time set for each token is recorded as information T2, or as shown in Figure 9, a "recommended waiting time record" calculated according to the recommended arrival time is recorded as information T2, and the arrival token is set and issued, and if a checkout time is set in advance, the "checkout time record" which is the set checkout time is recorded as information T2.

[0070] 10, the contract for the waiting time token records, as transaction information T3 for the waiting time token, the type of transaction (hereinafter referred to as transaction type), the "contract address of the waiting history NFT" which is the contract address of the token indicating the start of the waiting time, the token ID of the waiting time token, the "owner address" which is the user address of the user who is the token requestor when a token request is obtained for a token having the token ID, and "claim" which indicates a token request as the transaction type for the token. When this token is issued to a user and the held token is registered, "issue" indicating issuance is recorded as the transaction type.

[0071] As shown in FIG. 11, the contract for the action token records transaction information T4 for the action token. The transaction information for the action token includes, for example, the transaction type (such as "request" or "issue," as described later), the "contract address of the pending NFT," the user address of the user requesting the token (the "owner address"), the "clear passphrase," the "quantity," the type of game, and the token ID of the action token. When the token is issued to a user and registered as a held token, "issue" is recorded as the transaction type. When the game is the aforementioned quiz, a quiz number identifying the quiz is assigned to each quiz, and the quiz number is recorded as the game type. The "clear passphrase" is associated with the action token and is used to identify the action token to be issued when issuing the action token. The "clear passphrase" is recorded when the transaction type is "request" and when a predetermined stage of the game is cleared (passed) (when the quiz is answered correctly). The "clear passphrase" is generated in a specific one-way manner and is set to be restorable only by the game provider (the client in this example) and the user who cleared the stage of the game. The "clear passphrase" is used by the first user control unit 27 to identify the action token in the token storage unit 33 when a "request" for an action token is sent from the user terminal 12 to the support device 10. The "number" indicates the number of action tokens to be issued.

[0072] The visit token contract records visit token transaction information T5, as shown in Figure 12. The visit token transaction information includes, for example, the transaction type, the "contract address of the waiting history NFT," the visit token token ID, and the user address of the user requesting the token, the "owner address."

[0073] As shown in Figure 13, transaction information T6 for the post-event token is recorded in the post-event token contract. The transaction information for the post-event token includes, for example, the transaction type, the "owner address" as the user ID of the user to whom the post-event token is issued, the token ID of the post-event token, the "contract address of the waiting history NFT," and the contrast of the held tokens held by the user. Figure 13 shows an example in which the "action token contrast group" indicates that the contrast of the held tokens is multiple action tokens, and the contract addresses of those action tokens are displayed.

[0074] After all the set phases are completed, post-event tokens may be transferred between users. Transfers and transfers may be free or for a fee. This allows users to convert their waiting time into asset value through the NFTs they acquire during the waiting period. In this regard, a major problem with traditional physical goods, which offer benefits in the form of physical items, is that when these items are bought up for resale and sold on the resale market, not a single yen is received by the performers or their affiliated organizations (agencies, etc.). However, this embodiment makes it possible to set royalties, for example, when transferring, receiving, or reselling post-event tokens in transactions after the third phase is completed. This solves the above-mentioned problems with physical goods.

[0075] The transfer and acquisition of the above tokens is recorded on the blockchain as transaction information in a newly generated block. As a result, even after a performer retires, disbands, or is no longer affiliated with an agency, the issued NFT is recorded on the blockchain, so unlike a centralized database that may become suspended or lost, ownership is clearly defined and transfer and acquisition transactions are possible.

[0076] By making the token an NFT, ownership is clearly defined, and users, as fans cheering on performers, can own digital data of specific mementos and artwork related to a specific event and the various support activities they have undertaken. This transforms the waiting time for an event into limited, specific digital data rather than just points as in the past, increasing the meaning and value of being a fan. [Explanation of symbols]

[0077] 10 Event support equipment 15 Two-dimensional code display terminal 17 Blockchain Network 18 Event Support Unit 26 First user control unit 27 Second user control section 28 Third user control section 31 Event Memory Unit 32 User information storage unit 33 Token storage unit

Claims

1. an event storage unit that stores an event to be held at a predetermined venue, the date and time of the event, and an address of an access destination that a user who will participate in the event will access when arriving at the event on the day of the event, in association with each other; a user information storage unit that stores user identification information of the user participating in the event and tokens held by the user in association with each other; a first user control unit that issues an event day waiting time token, which is set in advance in association with a waiting time from when the address is accessed until the venue opens, to the user in accordance with the waiting time, and sets the token as the owned token of the user to whom the token is issued; Equipped with The first user control further comprises: An event day action token is issued based on the degree of difference between an event day action acquired on the event day from the user who accessed the address and a reference action that is an evaluation criterion for the event day action, in accordance with the event day action of the user, and the token is set as the owned token of the user to whom the token is issued.

1. An information processing device comprising:

2. The first user control An attendance token based on the difference between a recommended arrival time preset for the user and the arrival time of the user is issued according to the arrival time of the user, and the token is set as the owned token of the user to whom the token is issued. The information processing device according to claim 1 .

3. a second user control unit that sets at least one of a pre-event waiting time token based on the time from when the user is accepted to a predetermined date and time before the event and a pre-event action token based on a pre-event action acquired from the user between when the user is accepted and the predetermined date and time as the possessed token of the user to be issued; The information processing device according to claim 1 or 2, further comprising:

4. a third user control unit that issues a specific post-event token to the user after the event ends based on the tokens held before the event is held, and the specific post-event token is used as the held token; The information processing device according to claim 1 or 2, further comprising:

5. The third user control unit:

5. The information processing device according to claim 4, wherein a plurality of users are ranked based on the tokens held before the event is held, and the post-event token is issued to the users ranked at or above a predetermined rank, and the post-event token is used as the held token.

6. an event storage step of storing an event to be held at a predetermined venue, the date and time of the event, and an address of an access destination to be accessed by a user who will participate in the event when the user visits the venue on the day of the event; a user information storage step of storing user identification information of the user participating in the event and a token held by the user in association with each other; a first user control step of issuing an event day waiting time token, which is preset in association with a waiting time from when the address is accessed until the venue opens, to the user in accordance with the waiting time, and setting the token as the owned token of the user to whom the token is issued; and The first user control step further comprises: An event day action token is issued based on the degree of difference between an event day action acquired on the event day from the user who accessed the address and a reference action that is an evaluation criterion for the event day action, in accordance with the event day action of the user, and the token is set as the owned token of the user to whom the token is issued.

1. An information processing method comprising:

7. an event storage step of storing an event to be held at a predetermined venue, the date and time of the event, and an address of an access destination to be accessed by a user who will participate in the event when the user visits the venue on the day of the event; a user information storage step of storing user identification information of the user participating in the event and a token held by the user in association with each other; a first user control step of issuing an event day waiting time token, which is preset in association with a waiting time from when the address is accessed until the venue opens, to the user in accordance with the waiting time, and setting the token as the owned token of the user to whom the token is issued; An information processing program that causes a computer to execute the following: The first user control step further comprises: An event day action token is issued based on the degree of difference between an event day action acquired on the event day from the user who accessed the address and a reference action that is an evaluation criterion for the event day action, in accordance with the event day action of the user, and the token is set as the owned token of the user to whom the token is issued. An information processing program characterized by:

Images