Information processing system and information processing method

Abstract

[Problem] To enable a user 15 to confirm information pertaining to an NFT before the NFT is used. [Solution] Provided is an information processing system that includes an information processing device for transmitting, to a smart contract, a request for issuance of an NFT, the information processing device being provided with: a verification unit that, on the basis of check-in information transmitted from a user terminal, verifies the authenticity of participation in an event by a user; a contract coordination unit that, when the verification unit has recognized the authenticity of participation in the event by the user, issues an NFT identifier and transmits the issuance request including the identifier to the smart contract; and a first notification unit that, before the smart contract issues the NFT, transmits a notification related to an NFT issuance schedule including the identifier to a notification address designated by the user.

Description

Information Processing System and Information Processing Method 【0001】 The present disclosure relates to an information processing system and an information processing method. 【0002】 In recent years, the recognition and spread of NFT (Non-Fungible Token) have been progressing. Also, technologies related to the issuance, distribution, etc. of NFTs have been developed. For example, Patent Document 1 discloses a technology for reducing the burden of confirmation by users by notifying that the distribution of NFTs has been completed. 【0003】 Japanese Unexamined Patent Application Publication No. 2024-6370 【0004】 However, in the technology disclosed in Patent Document 1, until the issuance (Mint) of NFTs is confirmed by the system, users cannot grasp information regarding the NFTs scheduled to be issued. 【0005】 According to one aspect of the present disclosure, there is provided an information processing system including an information processing device that transmits a request for issuing an NFT to a smart contract, the information processing device including a verification unit that verifies the authenticity of a user's participation in an event based on check-in information transmitted from a user terminal, a contract cooperation unit that issues an identifier of the NFT and transmits the issuance request including the identifier to the smart contract when the authenticity of the user's participation in the event is recognized by the verification unit, and a first notification unit that transmits a notification regarding a scheduled NFT issuance including the identifier to a notification address designated by the user before the issuance of the NFT by the smart contract. 【0006】 Also, according to another aspect of the present disclosure, there is provided an information processing method in which a processor verifies the authenticity of a user's participation in an event based on check-in information transmitted from a user terminal, issues an identifier of the NFT and transmits an issuance request including the identifier to a smart contract when the authenticity of the user's participation in the event is recognized by the verification, and transmits a notification regarding a scheduled NFT issuance including the identifier to a notification address designated by the user before the issuance of the NFT by the smart contract. 【0007】 This is a diagram illustrating an overview of NFT issuance according to one embodiment of the present disclosure. This is a block diagram showing an example of the functional configuration of the information processing system 1 according to the same embodiment. This is a block diagram showing an example of the functional configuration of the user terminal 10 according to the same embodiment. This is a block diagram showing an example of the functional configuration of the oracle 20 according to the same embodiment. This is a block diagram showing an example of the functional configuration of the service server 40 according to the same embodiment. This is a diagram showing an example of a screen related to the transmission of check-in information according to the same embodiment. This is a diagram illustrating an example of a screen related to the transmission of check-in information according to the same embodiment. This is a diagram schematically showing the verification and issuance request transmission process by the oracle 20 according to the same embodiment. This is a flowchart showing an example of the operation flow of the smart contract 30 according to the same embodiment. This is a sequence diagram showing an example of the processing flow common to synchronous notification and asynchronous notification according to the same embodiment. This is a sequence diagram showing an example of the processing flow of synchronous notification according to the same embodiment. This is a diagram showing an example of the display of My Page after NFT issuance according to the same embodiment. This is a sequence diagram showing an example of the processing flow of asynchronous notification according to the same embodiment. This is a diagram showing an example of the processing flow of asynchronous notification according to the same embodiment. This is a diagram showing an example of My Page displayed in step S362 shown in Figure 14. This is a sequence diagram showing an example of the NFT issuance confirmation flow according to the same embodiment. This is a diagram illustrating an example of NFT issuance based on a series of check-ins according to the same embodiment. This is a diagram illustrating an example of NFT mode control according to the participation status in an event according to the same embodiment. This is a diagram illustrating the issuance of an NFT based on a proximity certificate 80 according to the same embodiment. This is a diagram showing an example of a user interface for issuing an NFT based on a proximity certificate according to the same embodiment. This is a diagram showing an example of a user interface for issuing an NFT based on a proximity certificate according to the same embodiment. This is a block diagram showing an example of the hardware configuration of the information processing device 90 according to the same embodiment. 【0008】 Preferred embodiments of this disclosure will be described in detail below with reference to the attached drawings. In this specification and the drawings, components having substantially the same functional configuration are denoted by the same reference numerals, and redundant descriptions will be omitted. 【0009】 Furthermore, in this specification and drawings, when describing multiple identical components to distinguish them, letters or other symbols may be added to the end of the reference numerals. On the other hand, when there is no need to distinguish multiple identical components, the letters or other symbols may be omitted, and a description common to all identical components may be provided. 【0010】 The explanation will be presented in the following order: 1. Embodiments 1.1. Overview 1.2. Example Functional Configuration 1.3. Processing Details 2. Example Hardware Configuration 3. Summary 【0011】 <1. Embodiments> <<1.1. Overview>> First, an overview of NFT issuance according to one embodiment of this disclosure will be described. 【0012】 In recent years, NFTs have been utilized in a variety of services. In one embodiment of this disclosure, the use of NFTs in a service that supports fan activities (also known as "oshi-katsu" in Japan) is given as the main example. 【0013】 More specifically, in fan activity support services, various measures can be implemented to increase engagement with fans. One such measure is the issuance of NFTs (Net Forecasts) that prove fan engagement based on their actions. 【0014】 Figure 1 is a diagram illustrating an overview of NFT issuance according to one embodiment of the present disclosure. 【0015】 In this embodiment, the information processing system 1 (see Figure 2) issues an attendance certificate NFT 50 (sometimes simply referred to as NFT) as a reward for participation in an event when it is determined that a user 15 who is a fan of a certain artist has participated in an event related to that artist. 【0016】 For example, a two-dimensional code 65 placed at the event venue 60 can be used to verify the authenticity of user 15's participation in the event (also referred to as check-in). 【0017】The two-dimensional code 65 is an example of a code according to this embodiment. The two-dimensional code 65 may be, for example, a QR code (registered trademark). 【0018】 User 15 scans a two-dimensional code 65 placed at the event venue 60 using their own mobile device, user terminal 10. The user terminal 10 uses the scanning of the two-dimensional code 65 as one of the triggers to send check-in information to Oracle 20. 【0019】 The check-in information includes, for example, event information (information identifying the event) contained in the two-dimensional code 65, location information of the user terminal 10, and a notification address (for example, an email address) to which notifications described later will be sent. 【0020】 Oracle 20 verifies the authenticity of user 15's participation in the event based on the check-in information described above. 【0021】 In this way, by utilizing the two-dimensional code 65 placed at the event venue 60 to verify the authenticity of user 15's participation in the event, it is possible to prevent individuals who have not actually been to the event venue 60 from making false applications by falsifying their location information. 【0022】 Oracle 20 verifies the authenticity of user 15's participation in the event based on the check-in information received from user terminal 10. If authenticity is confirmed, Oracle 20 sends a request to smart contract 30 to issue an attendance certificate NFT 50. 【0023】 Oracle 20 is an information processing device that provides information from outside the blockchain to smart contracts 30 on the blockchain. 【0024】 By Oracle 20 guaranteeing the authenticity of User 15's participation in the event and then sending the issuance request, the smart contract 30 becomes capable of self-execution based on accurate and reliable information. 【0025】 Smart contract 30 issues an attendance certificate NFT 50 based on an issuance request received from oracle 20. 【0026】 The attendance certificate NFT 50 may first be issued to the corporate wallet 47 and then granted to the user wallet 17. The corporate wallet 47 and user wallet 17 will be described later. 【0027】 The above outlines the NFT issuance process according to this embodiment. Through the series of processes described above, it becomes possible to verify the authenticity of user 15's participation in the event with high accuracy and to award NFTs to user 15 as a reward for participating in the event. Furthermore, this is expected to improve user 15's motivation for fan activities and further enhance engagement with fans. 【0028】 <<1.2. Example of Functional Configuration>> Next, an example of the functional configuration of the information processing system 1 according to this embodiment will be described. Figure 2 is a block diagram showing an example of the functional configuration of the information processing system 1 according to this embodiment. 【0029】 As shown in Figure 2, the information processing system 1 according to this embodiment may include a user terminal 10, an oracle 20, a smart contract 30, and a service server 40. 【0030】 (User terminal 10) The user terminal 10 in this embodiment is a mobile terminal used by user 15. 【0031】 The user terminal 10 according to this embodiment may be, for example, a smartphone, a tablet, a wearable device, or the like. 【0032】 (Oracle 20) Oracle 20 according to this embodiment is an example of an information processing device that transmits an NFT issuance request to smart contract 30. 【0033】 (Smart Contract 30) The smart contract 30 according to this embodiment is a program that operates on the blockchain. 【0034】 In this embodiment, the smart contract 30 issues an NFT based on an issuance request received from the oracle 20. 【0035】(Service Server 40) The service server 40 according to the present embodiment is an information processing device that cooperates with the oracle 20 and provides various services to support the fan activities of the user 15. 【0036】 Next, a functional configuration example of each component included in the information processing system 1 will be described. 【0037】 FIG. 3 is a block diagram showing a functional configuration example of the user terminal 10 according to the present embodiment. 【0038】 As shown in FIG. 3, the user terminal 10 according to the present embodiment may include a control unit 110, a position information acquisition unit 120, a photographing unit 130, an operation reception unit 140, a display unit 150, and a communication unit 160. 【0039】 (Control Unit 110) The control unit 110 according to the present embodiment controls the operations of each component included in the user terminal 10. The functions of the control unit 110 are realized by the cooperation of various processors and memories. 【0040】 (Position Information Acquisition Unit 120) The position information acquisition unit 120 according to the present embodiment cooperates with GNSS (Global Navigation Satellite System) and acquires the position information (latitude and longitude) of the user terminal 10. 【0041】 The position information acquisition unit 120 includes an antenna for receiving signals emitted by satellites included in GNSS. 【0042】 (Photographing Unit 130) The photographing unit 130 according to the present embodiment performs photographing based on an operation by the user 15. 【0043】 In particular, the photographing unit 130 according to the present embodiment performs photographing with the two-dimensional code 65 as the subject. 【0044】 The photographing unit 130 includes various imaging elements. 【0045】 (Operation Reception Unit 140) The operation reception unit 140 according to the present embodiment receives various operations by the user 15. 【0046】 The operation reception unit 140 includes various input devices such as a touch panel and buttons. 【0047】 (Display unit 150) The display unit 150 according to this embodiment displays information according to the control by the control unit 110. 【0048】 The display unit 150 includes various displays. 【0049】 (Communication unit 160) The communication unit 160 according to this embodiment performs information communication with the Oracle 20, the service server 40, and the like. 【0050】 For example, the communication unit 160 according to this embodiment transmits check-in information to the Oracle 20 according to the control by the control unit 110. 【0051】 Next, a functional configuration example of the Oracle 20 according to this embodiment will be described. FIG. 4 is a block diagram showing a functional configuration example of the Oracle 20 according to this embodiment. 【0052】 As shown in FIG. 4, the Oracle 20 according to this embodiment may include a control unit 210, an identifier DB 220, an event DB 230, and a communication unit 240. 【0053】 (Control unit 210) The control unit 210 according to this embodiment operates as a verification unit 212, a contract cooperation unit 214, and a service cooperation unit 216. 【0054】 The functions of the control unit 210 are realized by the cooperation of various processors and memories. 【0055】 (Verification unit 212) The verification unit 212 according to this embodiment verifies the authenticity of the user 15's participation in an event based on the check-in information transmitted from the user terminal 10. 【0056】 (Contract cooperation unit 214) When the authenticity of the user 15's participation in an event is recognized by the verification unit 212, the contract cooperation unit 214 according to this embodiment issues an identifier of an NFT (for example, a token ID), and transmits an issuance request including the identifier to the smart contract 30. 【0057】 In addition, the contract cooperation unit 214 according to this embodiment checks the issuance status of the NFT by the smart contract 30. 【0058】 (Service linkage unit 216) The service linkage unit 216 according to this embodiment performs various processes related to linkage with the service server 40 or the provision of services to the user terminal 10. 【0059】 One example of processing performed by the service linkage unit 216 is the control of sending notifications to the user terminal 10. 【0060】 For example, the service linkage unit 216 operates as a first notification unit that, before the NFT is issued by the smart contract 30, sends a notification regarding the planned issuance of an NFT (also simply called a planned issuance notification) containing the above identifier to a notification address via the communication unit 240. 【0061】 According to the issuance notification described above, user 15 can confirm that the NFT is indeed scheduled for issuance and verify the identifier of the NFT to be issued, without having to wait for the NFT issuance to be completed. 【0062】 Details of the functions of the control unit 210 will be described later. 【0063】 (Identifier DB220) The identifier DB220 according to this embodiment temporarily stores identifiers issued by the contract linkage unit 214. 【0064】 The identifier DB220 may, for example, temporarily store identifiers and hashed notification addresses in association, and after the NFT is issued and the identifiers and notification addresses are handed over to the service server 40, the stored information may be deleted. 【0065】 The identifier DB220 temporarily stores the identifier, making it possible to resubmit an NFT issuance request, as described later. 【0066】 Furthermore, the identifier DB220 can reduce risks from a data protection perspective by deleting the information it stored after the NFT is issued. 【0067】 (Event DB 230) The event DB 230 according to this embodiment stores various information related to events. 【0068】The information stored in the Event DB230 includes, for example, the name of the event, the duration of the event, the name of the venue, location information of the venue (e.g., latitude and longitude of the center or centroid, threshold distance from the center or centroid, etc.), a two-dimensional code 65, participating artists, and information about the organizer's staff. 【0069】 (Communication Unit 240) The communication unit 240 according to this embodiment communicates information with the user terminal 10, smart contract 30, service server 40, etc. 【0070】 For example, the communication unit 240 according to this embodiment receives check-in information from the user terminal 10. 【0071】 For example, the communication unit 240 according to this embodiment transmits an issuance request to the smart contract 30 in accordance with the control of the control unit 210. 【0072】 For example, the communication unit 240 according to this embodiment sends an issuance schedule notification to the notification address in accordance with the control unit 210. 【0073】 Furthermore, for example, the communication unit 240 according to this embodiment transmits the NFT identifier and notification address to the service server 40. 【0074】 Next, an example of the functional configuration of the service server 40 according to this embodiment will be described. Figure 5 is a block diagram showing an example of the functional configuration of the service server 40 according to this embodiment. 【0075】 As shown in Figure 5, the service server 40 according to this embodiment may include a control unit 410, a user database 420, a metadata database 430, and a communication unit 440. 【0076】 (Control Unit 410) The control unit 410 according to this embodiment operates as an interface control unit 412 and a wallet management unit 414. 【0077】 The functions of the control unit 410 are realized through the cooperation of various processors and memory. 【0078】 (Interface control unit 412) The interface control unit 412 according to this embodiment controls the user interface provided to the user. 【0079】 User 15 may check the issuance schedule of NFTs, check issued NFTs, move (deposit) them, buy and sell them, etc., on the user interface described above. 【0080】 Furthermore, the interface control unit 412 according to this embodiment may also function as a second notification unit that sends an NFT issuance completion notification to a notification address after the NFT is issued by the smart contract 30. 【0081】 The NFT issuance completion notice (also simply referred to as the issuance completion notice) is a notice indicating that the issuance of the NFT by smart contract 30 has been completed. 【0082】 User 15 can confirm the completion of NFT issuance by checking the issuance completion notification and, if necessary, move (deposit), sell, etc., the NFT. 【0083】 (Wallet Management Unit 414) The wallet management unit 414 according to this embodiment manages the user wallet 17 and the corporate wallet 47. 【0084】 The corporate wallet 47 may be a wallet associated with the operator that runs the service server 40. 【0085】 Furthermore, it may function as a temporary holding platform for NFTs issued by smart contract 30. 【0086】 In this embodiment, the wallet management unit 414 moves the NFT from the corporate wallet 47 to the user wallet 17 after the issuance of the NFT is confirmed by the oracle 20. 【0087】 It should be noted that at the time the NFT is issued, the user 15 who is to become the holder of the NFT may not yet have a user wallet 17. In this case, the wallet management unit 414 may move the NFT after the user 15 has created a user wallet 17. 【0088】According to the process described above, it becomes possible to issue NFTs to users 15 who do not yet have a user wallet 17, and it is also possible to support the entry of users 15 who are handling NFTs for the first time. 【0089】 (User DB 420) The user DB 420 according to this embodiment stores various information about user 15. 【0090】 The information stored in the user database 420 includes, for example, the name, address, telephone number, account ID, notification address, and wallet information of user 15. 【0091】 (Meta DB 430) The Meta DB 430 according to this embodiment stores metadata related to NFTs. 【0092】 MetaDB430 may store information such as the URL of the NFT image, the name of the NFT, a description, attributes, and background color in JSON format. 【0093】 (Communication unit 440) The communication unit 440 according to this embodiment communicates information with the user terminal 10, Oracle 20, etc. 【0094】 For example, the communication unit 440 according to this embodiment transmits and receives control signals and the like related to the user interface between itself and the user terminal 10. 【0095】 For example, the communication unit 440 according to this embodiment sends a notification of completion of issuance to the notification address in accordance with the control unit 210. 【0096】 Furthermore, for example, the communication unit 440 according to this embodiment receives the NFT identifier and notification address from the oracle 20. 【0097】 The above describes an example of the functional configuration of the information processing system 1 according to this embodiment. Note that the above functional configuration, described with reference to Figures 2 to 5, is merely an example, and the functional configuration of the information processing system 1 is not limited to this example. 【0098】 For example, some of the functions listed as features of Oracle 20 may be implemented as features of the service server 40. Similarly, some of the functions listed as features of the service server 40 may be implemented as features of Oracle 20. 【0099】 The functional configuration of the information processing system 1 according to this embodiment can be flexibly modified according to specifications, operation, etc. 【0100】 <<1.3. Processing Details>> Next, the processing performed by the information processing system 1 according to this embodiment will be described in more detail. 【0101】 First, we will describe the transmission of check-in information by the user terminal 10. 【0102】 Figures 6 and 7 show examples of screens related to the transmission of check-in information according to this embodiment. 【0103】 The left side of Figure 6 shows an example of the screen that appears when the user terminal 10 reads the two-dimensional code 65. The user 15 may confirm the process of receiving the NFT (referred to as "digital goods" in Figure 6) on this screen. 【0104】 Furthermore, the right side of Figure 6 shows an example of a screen for confirming the submission of check-in information (referred to as the check-in screen). The check-in screen may be displayed, for example, by scrolling the screen shown on the left side of Figure 6, or by clicking a link located on the screen shown on the left side of Figure 6. 【0105】 User 15 may be able to check event information, NFT redemption deadlines, terms of service, privacy policy, etc., on the check-in screen. 【0106】 Furthermore, user 15 instructs user terminal 10 to send check-in information by entering a notification address and pressing button B0, etc. 【0107】 In this embodiment, an email address is given as an example of a notification address, but the notification address may also be, for example, a telephone number for sending and receiving SMS messages, or various addresses for sending and receiving messages in an application. 【0108】If a notification address is entered and button B0 is pressed, the user terminal 10 sends check-in information, including the event information read from the two-dimensional code 65, the location information of the user terminal 10, and the entered notification address, to the oracle 20. 【0109】 Figure 7 shows an example of a screen displayed after submitting check-in information. This screen may display, for example, a message indicating that the notification of scheduled issuance (referred to as "check-in completion email" in Figure 7) has been sent. 【0110】 Next, we will describe the verification and transmission of the issuance request by Oracle 20 according to this embodiment. Figure 8 is a schematic diagram showing the verification and transmission of the issuance request by Oracle 20 according to this embodiment. 【0111】 In this embodiment, Oracle 20 verifies the authenticity of user 15's participation in the event based on user terminal location information P1 and event location information P6. 【0112】 User terminal location information P1 is information indicating the location of the user terminal 10, and as described above, it is included in the check-in information transmitted by the user terminal 10. 【0113】 Furthermore, event location information P6 is location information related to the event venue 60 and is stored in the event DB 230. 【0114】 As an example, the event location information P6 may include the latitude and longitude of the center or centroid of the event venue 60, and a threshold distance from the center or centroid. 【0115】 In this case, Oracle 20 verifies whether the user terminal location information P1 is within a threshold distance from the latitude and longitude defined in the event location information P6. 【0116】 Oracle 20 generates a zero-knowledge proof that user terminal location information P1 is within a threshold distance from the latitude and longitude defined in event location information P6, that is, the authenticity of user 15's participation in the event. 【0117】Oracle 20 may generate the above zero-knowledge proof using an algorithm such as zk-SNARK (Zero-Knowledge Succinct Non-interactive Arguments of Knowledge). 【0118】 The event location information P6 mentioned above is merely an example. The event location information P6 may also be defined by, for example, a geohash. 【0119】 Furthermore, Oracle 20 will issue a token ID (an example of an identifier) ​​if it determines that user 15's participation in the event is genuine. 【0120】 Next, Oracle 20 sends a request for issuance R1, which includes a zero-knowledge proof and a token ID, to smart contract 30. 【0121】 According to the issuance request R1 including the zero-knowledge proof of this embodiment, it becomes possible to provide accurate and reliable information to the smart contract 30 while ensuring security. 【0122】 Oracle 20 may also send an issuance request R1 to the smart contract, specifying the corporate wallet 47 as the recipient of the NFT. 【0123】 Next, the operation of the smart contract 30 according to this embodiment will be described. Figure 9 is a flowchart showing an example of the operation flow of the smart contract 30 according to this embodiment. 【0124】 In the example shown in Figure 9, the smart contract 30 first receives an issuance request (S101). 【0125】 Next, the smart contract 30 verifies the authenticity of the zero-knowledge proof included in the request to issue received in step S101. 【0126】 If the smart contract 30 finds the zero-knowledge proof to be authentic (S102: YES), it issues an NFT (S103). 【0127】On the other hand, if the smart contract 30 does not find the zero-knowledge proof to be authentic (S102: NO), it skips step S103. 【0128】 Next, the smart contract 30 saves the history (S104) and terminates the process. 【0129】 The above history may include the issuance history of NFTs and the verification history of zero-knowledge proofs. 【0130】 Next, we will describe the synchronous and asynchronous notifications according to this embodiment. 【0131】 In this embodiment, the synchronous notification refers to the process of waiting for the smart contract 30 to issue an NFT (i.e., in synchronization with the on-chain processing) and sending an issuance completion notification after the NFT has been issued. 【0132】 On the other hand, the asynchronous notification according to this embodiment refers to the process of sending an issuance schedule notification without waiting for the issuance of the NFT by the smart contract 30 (i.e., asynchronously with the on-chain processing), and then sending an issuance completion notification when the issuance of the NFT is confirmed. 【0133】 First, let's explain the common processing flow for both synchronous and asynchronous notifications. 【0134】 Figure 10 is a sequence diagram showing an example of the processing flow common to both synchronous and asynchronous notifications according to this embodiment. 【0135】 In the example shown in Figure 10, first, a check-in operation is performed on the user terminal 10 (S301). 【0136】 The check-in operation in S301 may be a series of operations such as reading the two-dimensional code 65, entering an email address, and pressing button B0, as explained with reference to Figures 6 and 7. 【0137】 After the check-in operation in step S301, the user terminal 10 sends the check-in information to the oracle 20 (S302). 【0138】Upon receiving the check-in information in step S302, Oracle 20 verifies the event information and email address included in the check-in information (S303). 【0139】 For example, in step S303, Oracle 20 may verify the event information by matching the event information included in the check-in information with information previously registered in the event DB 230. 【0140】 Alternatively, for example, Oracle 20 may verify the email address by performing a validation check of the email address included in the check-in information in step S303. 【0141】 Next, Oracle 20 performs location verification based on the user terminal location information included in the check-in information received in step S302 and the event location information previously registered in the event DB 230 (S304). 【0142】 The position verification in step S304 may be performed using the verification method described with reference to Figure 8. 【0143】 If Oracle 20 finds that all of the following are correct (S305: OK): event verification and email address verification in step S303, and location verification in step S304, it issues a token ID (S306). 【0144】 On the other hand, if Oracle 20 detects an error in either the event verification and email address verification in step S303, or the location verification in step S304 (S305: NG), it skips step S306 and terminates the series of processes. 【0145】 The above describes an example of the processing flow common to both synchronous and asynchronous notifications according to this embodiment. Next, an example of the processing flow for synchronous notifications according to this embodiment will be explained. 【0146】Figures 11 and 12 are sequence diagrams showing an example of the processing flow for synchronization notification according to this embodiment. Steps S311 to S321 shown in Figures 11 and 12 are performed following steps S301 to S306 shown in Figure 10. 【0147】 Oracle 20 generates a zero-knowledge proof based on the result of the position verification in step S304 (S311). 【0148】 Next, Oracle 20 sends a request to issue, including the zero-knowledge proof generated in step S311, to Smart Contract 30 (S312). 【0149】 Upon receiving the issuance request in step S312, the smart contract 30 issues an NFT (S313). 【0150】 Meanwhile, Oracle 20 confirms the issuance of the NFT by smart contract 30 (S314). 【0151】 If Oracle 20 cannot confirm the issuance of the NFT (S315: NO), it returns to step S312. 【0152】 Meanwhile, if Oracle 20 confirms that the NFT has been issued (S315: YES), it sends the token ID issued in step S306 and the email address included in the check-in information received in step S302 to the service server 40 (S316). 【0153】 The service server 40 stores the token ID received in step S316 in association with the email address. 【0154】 Furthermore, Oracle 20 sends a notification of completion of issuance to the email address included in the check-in information received in step S302 (S317). 【0155】 In this embodiment, for convenience, user 15 will use user terminal 10 to confirm the issuance completion notification. 【0156】Meanwhile, the service server 40 assigns the NFT issued in step S313 to the user wallet 17 based on the token ID and email address received in step S316 (S318). 【0157】 In other words, the service server 40 moves the target NFT from the corporate wallet 47 to the target user wallet 17. 【0158】 Note that the processing in step S318 may be batch processing. 【0159】 Furthermore, the service server 40 sends a notification indicating that the NFT has been granted to the target email address (S319). 【0160】 In this embodiment, for convenience, user 15 will use user terminal 10 to confirm the completion notification of the grant. 【0161】 Furthermore, if the target user wallet 17 does not exist in step S318, the service server 40 may send a notification prompting the user to create a user wallet 17 (register an account). 【0162】 User 15 confirms the completion notification using their user terminal and accesses their My Page via the user interface provided by the service server 40 (S320). 【0163】 The service server 40 controls the display of the My Page (S321). 【0164】 Figure 13 shows an example of the display of the My Page after NFT has been granted according to this embodiment. 【0165】 After the NFT is granted, user 15 can check information such as the image 50I and token ID of the granted (owned) NFT on their My Page. 【0166】 Furthermore, user 15 may, for example, perform operations related to moving (depositing) NFTs by pressing button B11, and operations related to selling (listing) NFTs by pressing button B12. 【0167】The interface control unit 412 of the service server 40 accepts the operations related to the movement and the operations related to the sale. 【0168】 The above describes an example of the processing flow of a synchronous notification according to this embodiment. As mentioned above, in the synchronous notification according to this embodiment, the user is notified after the issuance of the NFT by the smart contract 30 is confirmed. 【0169】 However, the time required to issue an NFT using smart contracts 30 is affected by the congestion of the blockchain. 【0170】 Therefore, depending on the congestion of the blockchain, the waiting time until an NFT is issued may become longer, and user 15 may continue to be unable to check the status of NFT issuance. 【0171】 To avoid the situation described above, one could, for example, predict the number of participants in the event and issue a large number of NFTs in advance based on the prediction. However, accurately predicting the number of participants in the event, and the number of users 15 among those participants who wish to issue NFTs, is difficult, and the costs associated with issuing NFTs may be wasted. 【0172】 Therefore, the information processing system 1 according to this embodiment implements an asynchronous notification that sends an issuance schedule notification without waiting for the issuance of the NFT by the smart contract 30 (i.e., asynchronously with the on-chain processing). 【0173】 Figures 14 and 15 are sequence diagrams showing an example of the processing flow for asynchronous notifications according to this embodiment. Steps S351 to S365 shown in Figures 14 and 15 are performed following steps S301 to S306 shown in Figure 10. 【0174】 Furthermore, the following will primarily explain the differences between synchronous and asynchronous notifications, and will omit detailed explanations of processes common to both synchronous and asynchronous notifications. 【0175】In the example shown in Figures 14 and 15, Oracle 20 issues a token ID in step S306 and then sends the token ID and email address to the service server 40 (S351). 【0176】 The service server 40 stores the token ID received in step S351 in association with the email address. 【0177】 Next, Oracle 20 sends an issuance notification to the target email address (S352). 【0178】 In this embodiment, for convenience, user 15 will use user terminal 10 to confirm the scheduled issuance notification. 【0179】 User 15 checks the scheduled issuance notification using the user terminal and accesses My Page via the user interface provided by the service server 40 (S361). 【0180】 The service server 40 controls the display of the My Page (S362). 【0181】 Figure 16 shows an example of the My Page displayed in step S362 shown in Figure 14. 【0182】 At step S362, the issuance of the NFT by the smart contract 30 and the assignment of the NFT to the user wallet 17 by the service server 40 have not yet been completed. 【0183】 User 15 can check information such as the NFT image 50I and token ID to be issued on the My Page displayed in step S312. 【0184】 In other words, one of the features of the interface control unit 412 according to this embodiment is that it presents the image 50I of the NFT to be issued and the token ID before the NFT is issued by the smart contract. 【0185】 According to the control described above, user 15 can check the information of the issued NFT without waiting for the NFT to be issued and granted, thereby improving usability. 【0186】 However, since the issuance and granting of NFTs have not been completed at step S362, the interface control unit 412 deactivates (or hides) the button B11 related to the move operation and the button B12 related to the sell operation. 【0187】 Furthermore, the interface control unit 412 may display a message such as, "Outbound shipments, sales, etc., will be possible after the NFT assignment is complete." 【0188】 Referring again to Figures 14 and 15, we will continue to explain an example of the processing flow for asynchronous notifications. 【0189】 After the transmission of the issuance notification in step S352 is completed, the Oracle 20 and the smart contract 30 perform the processing in steps S353 to S357. 【0190】 Since the processes in steps S353 to S357 may be equivalent to the processes in S311 to S315 shown in Figure 11, a detailed explanation will be omitted. 【0191】 If Oracle 20 confirms that the NFT has been issued by the smart contract 30 (S357: YES), it sends an issuance confirmation notice to the service server 40 indicating this (S358). 【0192】 In step S358, the service server 40, having received the issuance confirmation notice, assigns the NFT issued in step S355 to the user wallet 17 based on the token ID and email address received in step S351 (S359). 【0193】 Note that the processing in step S359 may be batch processing. 【0194】 The processes in the following steps S363 to S365 may be equivalent to the processes in steps S319 to S321 shown in Figure 12, so a detailed explanation will be omitted. 【0195】 The My Page displayed in step S365 is equivalent to the example shown in Figure 13. 【0196】The above describes an example of the processing flow of asynchronous notifications according to this embodiment. According to the asynchronous notification according to this embodiment, the situation in which the user 15 is unable to check the NFT issuance status is avoided, and usability is improved. 【0197】 However, the information processing system 1 according to this embodiment may use both asynchronous and synchronous notifications. 【0198】 For example, if certain conditions are met, the information processing system 1 may send only an NFT issuance completion notice without sending an NFT issuance schedule notice. 【0199】 The specified conditions mentioned above include, for example, that the blockchain is not congested and that the issuance of NFTs is expected to be rapid, and that the fees charged when transactions are conducted on the blockchain (so-called gas fees) are lower than the set threshold. 【0200】 Next, an example of the NFT issuance verification performed by Oracle 20 according to this embodiment will be described. 【0201】 Figure 17 is a sequence diagram showing an example of the NFT issuance confirmation process according to this embodiment. 【0202】 In the example shown in Figure 17, Oracle 20 sends an issuance request to Smart Contract 30 in step S370 and then confirms that the issuance transaction is pending. 【0203】 For example, Oracle 20 may determine whether an issued transaction is still being mined within M blocks (for example, M=3). 【0204】 If Oracle 20 determines that no issued transactions have been mined within M blocks, it determines that a pending transaction has occurred (S371: YES), adds the gas fee (S372), and returns to step S370. 【0205】 Thus, Oracle 20 may verify the issuance of NFTs based on the mining status of issued transactions. 【0206】On the other hand, if Oracle 20 determines that the issued transaction is still being mined within M blocks, it determines that no pending has occurred (S371: NO), and then checks for reorg. 【0207】 For example, Oracle 20 may determine whether the issued transaction has been recorded on the blockchain (for example, after 10-20 minutes) after N blocks have elapsed (for example, N > 255, default value of N = 500). 【0208】 If Oracle 20 determines after N blocks have elapsed that the issued transaction has not been recorded on the blockchain, it determines that a reorg has occurred (S373: YES) and returns to step S370. 【0209】 Thus, Oracle 20 may verify the issuance of NFTs based on the record status of the issuance transaction. 【0210】 On the other hand, if Oracle 20 determines that the issuance transaction has been recorded on the blockchain after N blocks have elapsed, it determines that no reorg has occurred (S373: NO), and determines that the issuance of the NFT in step S375 has been completed. 【0211】 The above describes an example of how Oracle 20, according to this embodiment, confirms the issuance of NFTs. With the control described above, the issuance status of NFTs can be confirmed with high accuracy. 【0212】 Next, we will describe the issuance of NFTs based on a series of check-ins according to this embodiment. 【0213】 In this embodiment, the contract linkage unit 214 may issue a token ID and send an issuance request including the token ID to the smart contract 30 if the verification unit 212 confirms the authenticity of the user 15's participation in multiple events. 【0214】 Figure 18 is a diagram illustrating the issuance of NFTs based on a series of check-ins according to this embodiment. 【0215】In the example shown in Figure 18, user 15 participates in event A and scans a two-dimensional code 65A placed at the event venue 60A using user terminal 10. User terminal 10 transmits check-in information A related to event A to Oracle 20. 【0216】 Furthermore, user 15 participates in event B and reads a two-dimensional code 65B placed at the event venue 60B using user terminal 10. User terminal 10 transmits check-in information B related to event B to Oracle 20. 【0217】 Oracle 20 verifies the authenticity of Check-in Information A and Check-in Information B, and if it confirms the authenticity of User 15's participation in multiple events (Event A and Event B), it sends an issuance request to Smart Contract 30. 【0218】 In this way, by issuing NFTs on the condition of participation in multiple events, it becomes possible to encourage user 15 to participate in more events. 【0219】 Next, we will describe the control of the NFT behavior according to the participation status in the event according to this embodiment. 【0220】 The interface control unit 412 according to this embodiment may change the display mode of the NFT according to the user 15's participation status in the event. 【0221】 Figure 19 shows an example of NFT behavior control according to the event participation status according to this embodiment. 【0222】 Figure 19 illustrates NFT images 50I at each of the following points in time: User 15's first event participation, their first merchandise purchase, and their second event participation. 【0223】 The interface control unit 412 can, for example, change the background color of the NFT stored in the meta DB 430 to enable changes in the display mode of the NFT as shown in Figure 19. 【0224】In this way, by changing the NFT configuration in response to multiple contributions, it becomes possible to encourage more contributions from the user 15. 【0225】 While the above explanation cited participation in events as a primary example of contribution, user contributions may also include purchasing merchandise, as shown in Figure 19. 【0226】 Next, we will describe the issuance of NFTs based on the proximity certificate according to this embodiment. 【0227】 In the above, we described as a primary example a case in which the information processing system 1 verifies check-in information generated using the reading of a two-dimensional code 65 as one of the triggers, and issues an NFT based on the verification result. However, the subject of verification according to this embodiment is not limited to such an example. 【0228】 The verification unit 212 according to this embodiment may verify the authenticity of the user 15's participation in the event based on the proximity certificate 80 transmitted from the user terminal 10 or the organizer terminal 70. 【0229】 The proximity certificate 80 may be generated based on short-range wireless communication between the user terminal 10 and the organizer terminal 70. 【0230】 Figure 20 is a diagram illustrating the issuance of an NFT based on the proximity certificate 80 according to this embodiment. 【0231】 The organizer terminal 70 shown in Figure 20 is a terminal used by the event organizer's staff 75 at the event venue 60. 【0232】 The organizer terminal 70 may be an information processing device having the same configuration as the user terminal 10. 【0233】 The user terminal 10 and the organizer terminal 70 communicate information with each other via short-range wireless communication. 【0234】 For the above-mentioned short-range wireless communication, standards such as Bluetooth®, NFC (Near Field Communication), Wi-Fi®, and UWB (Ultra-Wide Band) may be adopted. 【0235】 For example, in the above-mentioned short-range wireless communication, the user terminal 10 and the organizer terminal 70 may transmit digital certificates to each other to prove their authenticity. 【0236】 Furthermore, the user terminal 10 and the organizer terminal 70 may verify the received digital certificate. 【0237】 Furthermore, if either the user terminal 10 or the organizer terminal 70 determines that the digital certificate is authentic in the mutual verification described above, it may generate a proximity certificate 80 and send the generated proximity certificate 80 to Oracle 20. 【0238】 Furthermore, Oracle 20 verifies the received proximity certificate 80, and if its authenticity is confirmed, it sends an issuance request to the smart contract 30. 【0239】 Oracle 20 may generate a zero-knowledge proof that verifies the authenticity of the proximity certificate 80 and send an issuance request including the zero-knowledge proof to the smart contract 30. 【0240】 Through the series of processes described above, it becomes possible to verify the authenticity of event participation without using latitude and longitude information, thereby more reliably preventing the falsification of latitude and longitude information. 【0241】 Next, with reference to Figures 21 and 22, an example of a user interface for NFT issuance based on a proximity certificate according to this embodiment will be described. 【0242】 Figure 21 mainly shows an example of the user interface of the organizer's terminal 70. 【0243】 The first column of Figure 21 shows an example of the screen after logging in. This screen may display information about multiple events registered in the event database 230. 【0244】 Staff member 75 selects the target event from the displayed events by tapping or other means. 【0245】When a target event is selected, the system transitions to the screen shown in the second column of Figure 21. This screen may display details of the target event (e.g., event name, participating artist names, venue name, etc.). A button, for example, B1, is also placed on this screen. Button B1 is used to instruct the system to wait for short-range wireless communication with the user terminal 10. 【0246】 When button B1 is pressed and short-range wireless communication with the user terminal 10 is initiated, the system transitions to the screen shown in the third column of Figure 21. This screen may display the status of the short-range wireless communication with the user terminal 10. A button B2 is also placed on this screen. Button B2 is used to instruct the system to cancel short-range wireless communication with the user terminal 10 and to cancel standby mode for short-range wireless communication. 【0247】 Figure 22 mainly shows examples of the user interface of the user terminal 10. 【0248】 The first column from the bottom of Figure 22 shows an example of the screen after login. For example, button B3 is placed on this screen. Button B3 is used to instruct the organizer terminal 70 to scan. 【0249】 When button B3 is pressed, the screen shown in the second column from the bottom of Figure 22 is accessed. This screen displays a message indicating that scanning is in progress. This screen also contains, for example, button B4. Button B4 is used to instruct the user to cancel the scan. 【0250】 Once the scan is complete and short-range wireless communication with the organizer terminal 70 is established, the system transitions to the screen shown in the second column from the top of Figure 22. This screen displays the name of the event in question. The screen also includes a field for entering, for example, the address of the user wallet 17. Furthermore, the screen displays, for example, button B5. Button B5 is used to instruct the user to check in, i.e., to send a proximity certificate. 【0251】When the address of user wallet 17 is entered and button B5 is pressed, the screen shown in the third column from the top of Figure 22 is accessed. This screen indicates that the proximity certificate is being verified. 【0252】 If authenticity is not found during verification, the system will transition to the screen shown in the third column from the bottom of Figure 22. 【0253】 On the other hand, if authenticity is confirmed during verification, the user will be redirected to the screen shown in the fourth column from the top of Figure 22. This screen will display the image 50I of the NFT that is scheduled to be issued (or has been issued). The token ID and other information may also be displayed on this screen. 【0254】 The processing performed by the information processing system 1 according to this embodiment has been described in detail above. With the control described above, the user 15 can check the information of the issued NFT without waiting for the NFT to be issued and assigned, thereby improving usability. 【0255】 While the above primarily described events featuring artists as examples, the events according to this embodiment are not limited to such examples. 【0256】 Events according to this embodiment broadly include live performances, talk shows, meet-and-greets, lectures, training sessions, exhibitions, and the like. 【0257】 <2. Hardware Configuration Example> Next, a hardware configuration example common to the user terminal 10, Oracle 20, and service server 40 according to one embodiment of the present disclosure will be described. Figure 23 is a block diagram showing a hardware configuration example of an information processing device 90 according to one embodiment of the present disclosure. The information processing device 90 may be a device having a hardware configuration equivalent to that of the above-mentioned devices. 【0258】As shown in Figure 23, the information processing device 90 includes, for example, a processor 871, a ROM 872, a RAM 873, a host bus 874, a bridge 875, an external bus 876, an interface 877, an input device 878, an output device 879, a storage device 880, a drive 881, a connection port 882, and a communication device 883. Note that the hardware configuration shown here is just an example, and some of the components may be omitted. Furthermore, the information processing device 90 may include components other than those shown here. 【0259】 (Processor 871) The processor 871 functions, for example, as an arithmetic processing unit or a control unit, and controls the overall operation or part thereof of each component based on various programs recorded in the ROM 872, RAM 873, storage 880, or removable storage medium 901. 【0260】 (ROM 872, RAM 873) ROM 872 is a means for storing programs loaded into the processor 871 and data used for calculations. RAM 873 temporarily or permanently stores, for example, programs loaded into the processor 871 and various parameters that change as needed when executing those programs. 【0261】 (Host bus 874, bridge 875, external bus 876, interface 877) The processor 871, ROM 872, and RAM 873 are interconnected via, for example, the host bus 874, which is capable of high-speed data transmission. On the other hand, the host bus 874 is connected to the external bus 876, which has a relatively low data transmission speed, via, for example, the bridge 875. The external bus 876 is also connected to various components via the interface 877. 【0262】 (Input device 878) The input device 878 may include, for example, a mouse, keyboard, touch panel, buttons, switches, and levers. Furthermore, the input device 878 may also include a remote controller (hereinafter referred to as a remote control) capable of transmitting control signals using infrared rays or other radio waves. The input device 878 may also include an audio input device such as a microphone. 【0263】 (Output device 879) The output device 879 is a device that can visually or audibly notify the user of acquired information, such as a display device such as a CRT (Cathode Ray Tube), LCD, or organic EL, an audio output device such as a speaker or headphones, a printer, a mobile phone, or a facsimile. The output device 879 according to this disclosure also includes various vibration devices capable of outputting tactile stimuli. 【0264】 (Storage 880) Storage 880 is a device for storing various types of data. Examples of storage devices used for storage 880 include magnetic storage devices such as hard disk drives (HDDs), semiconductor storage devices, optical storage devices, or magneto-optical storage devices. 【0265】 (Drive 881) Drive 881 is a device that reads information recorded on a removable storage medium 901, such as a magnetic disk, optical disk, magneto-optical disk, or semiconductor memory, or writes information to the removable storage medium 901. 【0266】 (Removable storage medium 901) The removable storage medium 901 is, for example, DVD media, Blu-ray® media, HD DVD media, various semiconductor storage media, etc. Of course, the removable storage medium 901 may also be, for example, an IC card equipped with a contactless IC chip, or an electronic device, etc. 【0267】 (Connection port 882) Connection port 882 is a port for connecting external devices 902, such as a USB (Universal Serial Bus) port, an IEEE 1394 port, a SCSI (Small Computer System Interface), an RS-232C port, or an optical audio terminal. 【0268】 (External connected device 902) The external connected device 902 is, for example, a printer, a portable music player, a digital camera, a digital video camera, or an IC recorder. 【0269】(Communication device 883) The communication device 883 is a communication device for connecting to a network, and is, for example, a communication card for wired or wireless LAN, Bluetooth®, or WUSB (Wireless USB), a router for optical communication, a router for ADSL (Asymmetric Digital Subscriber Line), or a modem for various types of communication. 【0270】 <3. Summary> As described above, the information processing system 1 according to one embodiment of the present disclosure includes an oracle 20 that transmits an NFT issuance request to a smart contract 30, the oracle 20 includes a verification unit 212 that verifies the authenticity of the user 15's participation in an event based on check-in information transmitted from a user terminal 10, a contract linkage unit 214 that, if the verification unit 212 confirms the authenticity of the user 15's participation in an event, issues an NFT identifier and transmits an issuance request including the identifier to the smart contract 30, and a service linkage unit 216 that, before the smart contract 30 issues the NFT, sends a notification regarding the planned issuance of the NFT including the identifier to a notification address specified by the user 15. 【0271】 According to the above configuration, user 15 will be able to verify the information of the NFT before it is issued. 【0272】 While preferred embodiments of the present disclosure have been described in detail above with reference to the attached drawings, the technical scope of the present disclosure is not limited to such examples. It is clear to any person with ordinary skill in the art of the present disclosure that various modifications or alterations may be conceived within the scope of the technical ideas described in the claims, and these will naturally also fall within the technical scope of the present disclosure. 【0273】 Furthermore, each step of the process described in this disclosure does not necessarily have to be processed chronologically in the order shown in the flowchart or sequence diagram. For example, each step of the process for each device may be processed in a different order than described, or in parallel, as long as no technical discrepancies arise. 【0274】Furthermore, the series of processes performed by each device described in this disclosure may be implemented by a program stored on a non-transitory computer-readable storage medium. Each program is, for example, loaded into RAM when executed by a computer and executed by a processor such as a CPU. The storage medium is, for example, a magnetic disk, an optical disk, a magneto-optical disk, or flash memory. Alternatively, the program may be distributed without using a storage medium, for example, via a network. 【0275】 Furthermore, the effects described herein are merely descriptive or illustrative and not limiting. In other words, the technology relating to this disclosure may produce other effects that are obvious to those skilled in the art from the description herein, in addition to or instead of the effects described herein. 【0276】The following configurations also fall within the technical scope of this disclosure: (1) An information processing system including an information processing device that transmits an NFT issuance request to a smart contract, the information processing device comprising: a verification unit that verifies the authenticity of a user's participation in an event based on check-in information transmitted from a user terminal; a contract linkage unit that, if the verification unit verifies the authenticity of a user's participation in an event, issues an NFT identifier and transmits the issuance request including the identifier to the smart contract; and a first notification unit that, before the smart contract issues the NFT, sends a notification regarding the planned issuance of the NFT including the identifier to a notification address specified by the user. (2) The information processing system according to (1), further comprising a second notification unit that, after the smart contract issues the NFT, sends an NFT issuance completion notification to the notification address. (3) The information processing system according to either (1) or (2) above, wherein the verification unit verifies the authenticity of a user's participation in an event based on location information related to the event and location information of the user terminal included in the check-in information. (4) The information processing system according to either (1) or (2) above, wherein the verification unit verifies the authenticity of a user's participation in an event based on a proximity certificate transmitted from the user terminal or the organizer terminal, and the proximity certificate is generated based on short-range wireless communication between the user terminal and the organizer terminal. (5) The information processing system according to any one of (1) to (4) above, wherein the verification unit generates a zero-knowledge certificate to prove the authenticity of the user's participation in an event if the authenticity of the user's participation in an event is recognized, and the contract linkage unit transmits the issuance request including the zero-knowledge certificate to the smart contract. (6) The contract linkage unit confirms the issuance of NFTs based on the transaction mining status, an information processing system as described in any one of items (1) to (5) above.(7) The information processing system according to any one of (1) to (6) above, wherein the contract linkage unit confirms the issuance of the NFT based on the transaction record status. (8) The information processing system according to any one of (1) to (7) above, wherein the contract linkage unit issues an NFT identifier and sends the issuance request including the identifier to the smart contract when the authenticity of the user's participation in multiple events is recognized by the verification unit. (9) The information processing system according to any one of (1) to (8) above, wherein the contract linkage unit sends the issuance request specifying the corporate wallet as the recipient of the NFT to the smart contract. (10) The information processing system according to (9) above, further comprising: a wallet management unit that moves the NFT from the corporate wallet to the user wallet after the NFT has been issued by the smart contract. (11) The information processing system according to (2), wherein if predetermined conditions are met, the first notification unit transmits an NFT issuance completion notification without transmitting a notification relating to the NFT issuance schedule. (12) The information processing system according to any one of (1) to (11), further comprising an interface control unit that presents an image of the NFT to be issued and the identifier before the NFT is issued by the smart contract. (13) The information processing system according to (12), wherein the interface control unit accepts operations relating to the movement or sale of the NFT after the NFT has been issued by the smart contract. (14) The information processing system according to any one of (12) or (13), wherein the interface control unit changes the display manner of the NFT according to the user's participation status in the event. (15) The information processing system according to any one of (1) to (14), further comprising the user terminal, wherein the user terminal transmits the check-in information triggered by the reading of a code placed at the event venue.(16) The information processing system according to (15), wherein the user terminal transmits the check-in information, which includes event information read from the code, location information of the user terminal, and the notification address. (17) The information processing system according to any one of (1) to (16), further comprising a smart contract that issues an NFT based on an issuance request. (18) An information processing method comprising: a processor verifying the authenticity of a user's participation in an event based on check-in information transmitted from a user terminal; if the verification confirms the authenticity of a user's participation in an event, issuing an NFT identifier and transmitting an issuance request including the identifier to the smart contract; and before the smart contract issues the NFT, sending a notification regarding the planned issuance of the NFT, including the identifier, to a notification address specified by the user. 【0277】 1. Information Processing System 10. User Terminal 15. User 17. User Wallet 20. Oracle 210. Control Unit 212. Verification Unit 214. Contract Integration Unit 216. Service Integration Unit 30. Smart Contract 40. Service Server 47. Enterprise Wallet 410. Control Unit 412. Interface Control Unit 414. Wallet Management Unit 50. Attendance Certificate NFT 60. Event Venue 65. QR Code 70. Organizer Terminal 80. Proximity Certificate

Claims

1. An information processing system comprising: an information processing device that transmits an NFT issuance request to a smart contract, the information processing device comprising: a verification unit that verifies the authenticity of a user's participation in an event based on check-in information transmitted from a user terminal; a contract linkage unit that, if the verification unit verifies the authenticity of a user's participation in an event, issues an NFT identifier and transmits the issuance request including the identifier to the smart contract; and a first notification unit that, before the smart contract issues the NFT, sends a notification regarding the planned issuance of the NFT including the identifier to a notification address specified by the user.

2. The information processing system according to claim 1, further comprising: a second notification unit that, after the issuance of an NFT by the smart contract, sends an NFT issuance completion notification to the notification address.

3. The information processing system according to claim 1, wherein the verification unit verifies the authenticity of a user's participation in an event based on location information related to the event and location information of the user terminal included in the check-in information.

4. The information processing system according to claim 1, wherein the verification unit verifies the authenticity of a user's participation in an event based on a proximity certificate transmitted from the user terminal or the organizer terminal, and the proximity certificate is generated based on short-range wireless communication between the user terminal and the organizer terminal.

5. The information processing system according to claim 1, wherein the verification unit generates a zero-knowledge proof to prove the authenticity of the user's participation in the event if the authenticity of the user's participation is recognized, and the contract linkage unit transmits the issuance request, including the zero-knowledge proof, to the smart contract.

6. The information processing system according to claim 1, wherein the contract linkage unit confirms the issuance of NFTs based on the transaction mining status.

7. The information processing system according to claim 1, wherein the contract linkage unit confirms the issuance of an NFT based on the transaction recording status.

8. The information processing system according to claim 1, wherein the contract linkage unit issues an NFT identifier and transmits the issuance request including the identifier to the smart contract when the verification unit confirms the authenticity of the user's participation in multiple events.

9. The information processing system according to claim 1, wherein the contract linkage unit transmits the issuance request, specifying a corporate wallet as the recipient of the NFT, to the smart contract.

10. The information processing system according to claim 9, further comprising: a wallet management unit that moves an NFT from a corporate wallet to a user wallet after the NFT has been issued by the smart contract.

11. The information processing system according to claim 2, wherein, if a predetermined condition is met, the first notification unit does not send a notification relating to the planned issuance of the NFT, but instead sends a notification of completion of the issuance of the NFT.

12. The information processing system according to claim 1, further comprising: an interface control unit that presents an image of the NFT to be issued and the identifier before the NFT is issued by the smart contract.

13. The information processing system according to claim 12, wherein the interface control unit accepts operations relating to the transfer or sale of the NFT after the NFT has been issued by the smart contract.

14. The information processing system according to claim 12, wherein the interface control unit changes the display mode of the NFT according to the user's participation status in the event.

15. The information processing system according to claim 1, further comprising the user terminal, wherein the user terminal transmits the check-in information triggered by the reading of a code placed at the event venue.

16. The information processing system according to claim 15, wherein the user terminal transmits the check-in information, which includes event information read from the code, location information of the user terminal, and the notification address.

17. The information processing system according to claim 1, further comprising a smart contract for issuing NFTs based on an issuance request.

18. An information processing method comprising: a processor verifying the authenticity of a user's participation in an event based on check-in information transmitted from a user terminal; issuing an NFT identifier and sending an issuance request including the identifier to a smart contract if the authenticity of the user's participation in the event is confirmed by the verification; and sending a notification regarding the planned issuance of the NFT including the identifier to a notification address specified by the user before the smart contract issues the NFT.

Images