KR102816870B1 - Method, apparatus and recording medium for determining validation of ticket - Google Patents

Abstract

A method according to various embodiments of the present disclosure may include: obtaining first ticket information including information corresponding to each of one or more first non-fungible tokens issued by a smart contract associated with an event; recognizing a code displayed on a user terminal of a user associated with a second non-fungible token, which is one of the one or more first non-fungible tokens, to obtain encrypted information corresponding to the code; and determining whether the code is valid based on the first ticket information and the encrypted information.

Description

METHOD, APPARATUS AND RECORDING MEDIUM FOR DETERMINING VALIDATION OF TICKET

The present disclosure relates to a method, device and recording medium for determining the validity of a ticket.

In order to determine and verify the validity of a ticket, various information related to the ticket may be checked to see if it is valid. For example, the validity verification may include checking whether the ticket is issued on the date, the validity period, the identity of the issuer, the identity of the ticket holder, the event name, etc. For this validity verification, various security technologies and safety elements may be utilized.

According to various embodiments of the present disclosure, a technique is provided for a device to determine the validity of a ticket in a situation where communication between the device and a server is blocked.

According to various embodiments of the present disclosure, a technique for determining the validity of a ticket corresponding to a non-fungible token is provided.

According to various embodiments of the present disclosure, a technology is provided for determining the validity of a ticket or obtaining ticket-related information by utilizing metadata of a non-fungible token.

According to various embodiments of the present disclosure, a technique is provided for preventing fraudulent trading of tickets corresponding to non-fungible tokens.

According to various embodiments of the present disclosure, a technology is provided for preventing fraudulent ticket trading even in a situation where communication between a device and a server is blocked.

In one embodiment, a method performed in a device including one or more processors and one or more memories having instructions stored thereon for execution by the one or more processors, the method comprising: obtaining, by the one or more processors, first ticket information including information corresponding to each of one or more first non-fungible tokens issued by a smart contract associated with an event; recognizing a code displayed on a user terminal of a user associated with a second non-fungible token, which is one of the one or more first non-fungible tokens, to obtain encrypted information corresponding to the code, wherein the encrypted information is information encrypted by the user terminal based on second ticket information corresponding to the second non-fungible token; and determining, based on the first ticket information and the encrypted information, whether the code is valid.

In one embodiment, the step of obtaining the first ticket information is performed before the first time point, and the first time point may be a time point before a predetermined time from the start time of the event.

In one embodiment, the first point in time may be a point in time at which changes to information corresponding to each of the one or more first non-fungible tokens are restricted by the smart contract.

In one embodiment, the steps of obtaining the encryption information and determining whether the code is valid may be performed after the first point in time.

In one embodiment, determining whether the code is valid may include determining that the code is invalid if decrypting the encrypted information fails.

In one embodiment, the step of determining whether the code is valid may include the step of decrypting the encrypted information to obtain second ticket information; and the step of determining whether the code is valid based on the first ticket information and the second ticket information.

In one embodiment, the encrypted information may be encrypted information based on a first encryption key and first time information for a first time interval corresponding to a time at which the user terminal encrypts the second ticket information.

In one embodiment, the step of decrypting the encrypted information to obtain the second ticket information may include the step of first decrypting the encrypted information based on second time information for a second time interval corresponding to the time at which the device decrypts the encrypted information; and the step of secondly decrypting the first decrypted encrypted information based on a second encryption key associated with the first encryption key.

In one embodiment, when the first encryption key and the second encryption key are the same, the first encryption key and the second encryption key may include at least one of a symmetric key or a session key, and when the first encryption key and the second encryption key are different, the first encryption key may be a public key and the second encryption key may be a private key.

In one embodiment, the method may further comprise receiving a second encryption key from the server.

In one embodiment, the step of determining whether a code is valid based on the first ticket information and the second ticket information may include the step of determining whether identification data of a non-fungible token that matches identification data of a second non-fungible token included in the second ticket information is present in the first ticket information; and the step of determining the code to be valid based on the determination that the identification data is present in the first ticket information.

In one embodiment, the step of determining whether a code is valid based on the first ticket information and the second ticket information may include the step of determining whether a correspondence between identification data of a second non-fungible token included in the second ticket information and user identification data included in the second ticket information exists in the first ticket information; and the step of determining the code to be valid based on a determination that the correspondence exists in the first ticket information.

In one embodiment, the step of determining whether the code is valid based on the first ticket information and the second ticket information may include the step of determining whether the address of the smart contract included in the second ticket information matches the address of the smart contract included in the first ticket information; and the step of determining the code to be valid based on a determination that the address of the smart contract included in the second ticket information matches the address of the smart contract included in the first ticket information.

In one embodiment, the step of determining whether a code is valid based on the first ticket information and the second ticket information may include the step of determining whether metadata that matches ticket-related metadata included in the second ticket information is present in the first ticket information; and the step of determining the code to be valid based on the determination that the metadata is present in the first ticket information.

In one embodiment, the step of determining whether the code is valid based on the first ticket information and the second ticket information may include the step of determining that the code is valid in response to a determination that an address of a smart contract included in the second ticket information matches an address of a smart contract included in the first ticket information, and a correspondence between identification data of a second non-fungible token included in the second ticket information and user identification data included in the second ticket information exists in the first ticket information.

In one embodiment, the second ticket information includes at least one of identification data of the second non-fungible token, user identification data of a user associated with the second non-fungible token, or ticket-related metadata of the second non-fungible token, wherein the ticket-related metadata of the second non-fungible token may be information regarding a ticket for an event corresponding to the second non-fungible token.

In one embodiment, ticket-related metadata may include information regarding at least one of the name of the event, the schedule, the location, the seat identifier of the ticket, the price, or the terms of purchase.

In one embodiment, the step of obtaining the first ticket information may include a step that is performed repeatedly at regular intervals.

In one embodiment, a method performed in a terminal including one or more processors and one or more memories storing instructions to be executed by the one or more processors, the method comprising: receiving, by the one or more processors, second ticket information corresponding to a second non-fungible token, the second non-fungible token being one of one or more first non-fungible tokens issued by a smart contract associated with an event; generating encrypted information by encrypting the second ticket information; and displaying on a screen a code that enables a reader to obtain the encrypted information, wherein the encrypted information is obtained by a reader that recognizes the code, decrypted by the reader into the second ticket information, and can be used as a basis for determining whether the code is valid together with the first ticket information including information corresponding to each of the one or more first non-fungible tokens.

In one embodiment, the step of generating the encryption information may include the step of first encrypting the second ticket information based on the first encryption key; and the step of secondly encrypting the second ticket information that was first encrypted based on first time information for a first time interval corresponding to the time at which the second ticket information is encrypted.

In one embodiment, the terminal has an application installed that provides a service for trading a second non-fungible token, and the code can be displayed through the application.

In one embodiment, the step of displaying the code on the screen may include the step of performing biometric authentication on the user; and the step of displaying the code on the screen based on the result of the biometric authentication.

In one embodiment, the method may further include receiving a first cryptographic key from a server associated with the event, or transmitting a second cryptographic key associated with the first cryptographic key to the server, upon receipt of the second non-fungible token in the user's wallet.

In another embodiment, the device includes one or more processors; and one or more memories storing instructions to be executed by the one or more processors, wherein upon execution of the instructions, the one or more processors obtain first ticket information including information corresponding to each of one or more first non-fungible tokens issued by a smart contract associated with an event, recognize a code displayed on a user terminal of a user associated with a second non-fungible token, which is one of the one or more first non-fungible tokens, and obtain encrypted information corresponding to the code, wherein the encrypted information is information encrypted by the user terminal based on the second ticket information corresponding to the second non-fungible token; and determine whether the code is valid based on the first ticket information and the encrypted information.

In another embodiment, a non-transitory computer-readable recording medium having recorded thereon instructions to be executed by one or more processors, the instructions, when executed by the one or more processors, cause the one or more processors to obtain first ticket information including information corresponding to each of one or more first non-fungible tokens issued by a smart contract associated with an event, recognize a code displayed on a user terminal of a user associated with a second non-fungible token, which is one of the one or more first non-fungible tokens, and obtain encrypted information corresponding to the code, wherein the encrypted information is information encrypted by the user terminal based on the second ticket information corresponding to the second non-fungible token; and determine whether the code is valid based on the first ticket information and the encrypted information.

According to various embodiments of the present disclosure, in a situation where communication between a device and a server is blocked, the device can determine the validity of a ticket.

According to various embodiments of the present disclosure, the validity of a ticket corresponding to a non-fungible token can be determined.

According to various embodiments of the present disclosure, the validity of a ticket can be determined or ticket-related information can be obtained by utilizing metadata of a non-fungible token.

According to various embodiments of the present disclosure, fraudulent trading of tickets corresponding to non-fungible tokens can be prevented.

According to various embodiments of the present disclosure, fraudulent ticket trading can be prevented even in a situation where communication between a device and a server is blocked.

FIG. 1 is a diagram illustrating a system for determining the validity of a ticket according to various embodiments of the present disclosure.
FIG. 2 is a block diagram illustrating a device according to various embodiments of the present disclosure.
FIG. 3 is a flowchart illustrating a method for determining the validity of a ticket using a non-fungible token according to various embodiments of the present disclosure.
FIG. 4 is a flowchart illustrating a method for issuing a non-fungible token and changing information corresponding to the non-fungible token according to various embodiments of the present disclosure.
FIG. 5 is a diagram illustrating a method for determining the validity of a ticket based on time information in various embodiments of the present disclosure.
FIG. 6 is a flowchart illustrating a method of displaying a screen of a device according to a result of determining the validity of a ticket according to various embodiments of the present disclosure.
FIG. 7 is a flowchart illustrating a method for determining the validity of a ticket by generating a code in a terminal according to another embodiment of the present disclosure.
FIG. 8 is a flowchart illustrating a method of determining the validity of a ticket by generating a code in a server according to another embodiment of the present disclosure.
FIG. 9 is a flowchart of the operation of a device according to various embodiments of the present disclosure.
FIG. 10 is a flowchart of operations of a terminal according to various embodiments of the present disclosure.

The embodiments of the present disclosure are provided for the purpose of explaining the technical idea of the present disclosure. The scope of rights according to the present disclosure is not limited to the embodiments presented below or the specific description of these embodiments.

All technical and scientific terms used in this disclosure, unless otherwise defined, have the meaning commonly understood by one of ordinary skill in the art to which this disclosure belongs. All terms used in this disclosure have been selected for the purpose of more clearly describing this disclosure and are not selected to limit the scope of rights under this disclosure.

The expressions “including,” “comprising,” “having,” and the like, used in this disclosure, should be understood as open-ended terms implying the possibility of including other embodiments, unless otherwise stated in the phrase or sentence in which the expression is included.

The singular forms described in this disclosure may include plural meanings unless otherwise stated, and the same applies to the singular forms recited in the claims.

The expressions “first,” “second,” etc. used in this disclosure are used to distinguish between multiple components, and do not limit the order or importance of the components.

The term "unit" as used in this disclosure means software or a hardware component such as a field-programmable gate array (FPGA) or an application specific integrated circuit (ASIC). However, the "unit" is not limited to hardware and software. The "unit" may be configured to be on an addressable storage medium, and may be configured to execute one or more processors. Thus, by way of example, the "unit" includes components such as software components, object-oriented software components, class components, and task components, as well as processors, functions, properties, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functionality provided within a component and a "unit" may be combined into a smaller number of components and "units" or further separated into additional components and "units."

The expression "based on" as used in this disclosure is used to describe one or more factors affecting a decision, act of judgment, or action described in a phrase or sentence containing the expression, and the expression does not exclude additional factors affecting the decision, act of judgment, or action.

In this disclosure, when a component is referred to as being "connected" or "connected" to another component, it should be understood that said component can be directly connected or connected to said other component, or can be connected or connected via a new other component.

In this disclosure, a "ticket" is a certificate that represents the right of a user to use a service or enter an event (e.g., a concert, etc.). A ticket may include set conditions and restrictions, and accordingly, allows the owner of the ticket to receive the service or participate in the event.

In this disclosure, "validation of a ticket" may be determining whether a holder of a ticket has the right to use a service or enter an event. Accordingly, if a ticket is valid, the holder of the ticket can use the service or enter an event, but if a ticket is invalid, the holder of the ticket cannot use the service or enter an event.

The term "blockchain network" used in the present disclosure may include two or more nodes that manage a blockchain. Here, a block may refer to a specific data type. In addition, a blockchain may refer to a data structure in which one or more blocks are linked in a chain form. One or more blocks included in a blockchain may be independently stored in multiple nodes included in the blockchain network, or may be distributedly stored across multiple nodes. A block is a data structure that includes multiple transaction records. Each block includes transaction data, a timestamp, a hash value of a previous block, and a hash value of the block itself. This hash value ensures the integrity of the block and acts as a link to the previous block in the blockchain. This structure is formed in such a way that blocks are linked to timestamps and are continuously linked in a chain, and all blocks have a security property that prevents alteration of the chain. For example, a block may include a block hash value, a block header, or a block body. The block hash value is unique information that can identify a block, and may be, for example, a string expressed in 256 bits. The block header may include at least one of, for example, version information of software or protocol, a hash value of a previous block according to the block connection order on the blockchain, a merkle root, time information indicating the time when the block was created, bits indicating the difficulty of calculation, or a nonce which is a value required for mining to add a new block to the blockchain. The block body may include at least one transaction. A transaction may be a set of data having a specific data structure and may be a unit of information stored in the block body. A transaction may include information regarding the creation or transaction of a token.

Each of at least one node included in the blockchain network may be referred to as a "participant" of the blockchain network. The at least one node included in the blockchain network may operate by a hierarchy. The hierarchy may include, for example, at least one of a data layer that defines the structure of data handled by the blockchain network and manages the data, a consensus layer that verifies the validity of blocks, performs mining to generate blocks, and is responsible for processing fees paid to miners during the mining process, a common layer that implements or manages P2P network protocols, hash functions, digital signatures, encoding, and common storage, or an application layer where various applications are created or processed.

At least one node included in the blockchain network can share or store a transaction recorded on the blockchain. In addition, at least one node included in the blockchain network can perform a verification task on a transaction transmitted to the blockchain network through the blockchain consensus algorithm, and, when verification is complete, can perform a function of recording the verified transaction in a block on the blockchain. There is no limitation on the type of consensus algorithm performed by the blockchain network, and all types of consensus algorithms that can be adopted and modified by a person skilled in the art can be performed.

In the present disclosure, a "smart contract" may be a specification or script written in a programming language such as Solidity, and may be a program or application that operates on a virtual machine executed by at least one node included in a blockchain network. A smart contract may be written so that a specific action is executed when a specific condition is satisfied. In this case, the specific condition may be, for example, a condition such as a specific type of token being input or a file in a specific format being input. In addition, the specific action may be, for example, an action such as transmitting a specific type of token to an arbitrary node of the blockchain network. Each of at least one node included in the blockchain network may store a smart contract. Through this, at least one node included in the blockchain network may share the same smart contract. In addition, a smart contract may be recorded in a block on a blockchain managed by the blockchain network.

In this disclosure, a "digital asset wallet" (hereinafter referred to as "wallet") may be a tool for safely storing and managing an individual's digital assets in electronic form. The wallet may store and manage information related to cryptocurrency or digital assets. Each wallet has its own address, and when a node transfers a non-fungible token to a specific user, the non-fungible token may be transferred to the wallet address of the user.

In this disclosure, a "Non-Fungible Token (NFT)" is a blockchain-based token that represents ownership of a digital asset. Each non-fungible token cannot be replaced with another and has a unique value. This is a key feature that distinguishes it from traditional cryptocurrencies, which have the same value for each unit and are interchangeable. Non-fungible tokens are primarily used as proof of ownership for performances, artwork, music, game items, and other collectible digital items. Non-fungible tokens are recorded on a blockchain network, so that each change of ownership is publicly verifiable.

The creation and trading of non-fungible tokens are done by utilizing the smart contract function of the blockchain network. Smart contracts consist of code that automatically executes tasks such as the creation, transfer, and destruction of non-fungible tokens.

In this disclosure, QR code is a heterogeneous matrix barcode known as Quick Response code. QR code records data using a black and white square pattern, and has the characteristics of being able to read immediately and process data quickly. QR code can store data in both horizontal and vertical directions due to its structure, so it can contain much more information than existing barcodes. A user can scan a QR code using a QR code reader and quickly obtain information.

Hereinafter, embodiments of the present disclosure will be described with reference to the attached drawings. In the attached drawings, identical or corresponding components are given the same reference numerals. In addition, in the description of the embodiments below, redundant description of identical or corresponding components may be omitted. However, even if the description of a component is omitted, it is not intended that such a component is not included in any embodiment.

FIG. 1 is a diagram illustrating a system for determining the validity of a ticket according to various embodiments of the present disclosure. The system may include a device (110), a code recognition device (111) connected to the device, a terminal (120), a server (130), a blockchain network (140), and/or nodes (141) included in the blockchain network (140).

The device (110) may be a device that determines the validity of a ticket. For example, the device (110) may be a device installed at an event venue. The device (110) may include a code recognition device (111). The device (110) may determine the validity of a ticket using ticket information obtained through the code recognition device (111). The device (110) and the server (130) may be connected to each other through a computer network (150) to transmit and receive ticket information. The code recognition device (111) may obtain ticket information from the terminal (120) in various ways. For example, the code recognition device (111) may obtain ticket information from the terminal (120) using a QR code, a barcode, NFC (Near-field communication), etc. In the present disclosure, the device (110) or the code recognition device (111) may be referred to as a “reader.”

The ticket information may include information used to determine the validity of the ticket. For example, the ticket information may include at least one of the address of a smart contract related to the event, identification data of a non-fungible token corresponding to the ticket information, metadata of the non-fungible token, or user identification data. The address of the smart contract may be a unique identifier indicating the corresponding smart contract on the blockchain network. The address of the smart contract is an address required for the smart contract to be executed or interacted with, and includes information required to record token transactions or transaction history of the token. The address of the smart contract may include a series of letters and numbers, and at least one of the nodes (141) may use the address of the corresponding smart contract to check the contents and conditions of the smart contract or track changes. The identification data of the non-fungible token is unique data used to uniquely identify specific information or items, and may include, for example, an ID of the non-fungible token. The metadata of the non-fungible token may include data related to at least one of the time the non-fungible token was issued, issuer information, transaction history, rental information, or ownership. In the present disclosure, the metadata of the non-fungible token may be ticket-related metadata. Ticket-related metadata may include information about a ticket for an event corresponding to the non-fungible token. User identification data may be data for identifying a user, such as at least one of the user's ID or the user's wallet address.

The terminal (120) is a user's terminal, and may be a terminal of a user who owns or has borrowed a ticket to use a service or enter an event. A code may be displayed on the screen of the terminal (120). For example, a QR code may be displayed on the screen of the terminal (120), and the QR code may be recognized by a code recognition device (111).

The server (130) may be a device that manages various processes related to an event. For example, the server (130) may be a device that issues a smart contract related to an event, manages information on tickets corresponding to each of one or more non-fungible tokens issued by a smart contract, or transmits ticket information to the device (110).

At least one of the nodes (141) included in the blockchain network (140) may mean a device of a participant participating in the blockchain network (140). At least one of the nodes (141) may be an element constituting the blockchain network (140). At least one of the nodes (141) may perform an operation for maintaining the blockchain of the blockchain network (140). For example, any one node of the blockchain network (140) may create a new block of the corresponding blockchain, and the new block may be shared among other nodes of the blockchain network through a distributed consensus process and may be connected to the next block of the blockchain. That is, at least one of the nodes (141) may perform an operation such as creating, verifying, or propagating a transaction and a block in which the transaction is recorded. At least one of the nodes (141) may perform the issuance of a non-fungible token by interacting with the server (110). The issuance of a non-fungible token may refer to the process in which an issuer uses a smart contract to create a specific number of non-fungible tokens and stores the created non-fungible tokens in the issuer's wallet.

At least one of the nodes (141) may be implemented as a computing device. For example, the computing device described above may be, but is not limited to, a desktop computer, a laptop computer, and the like, and may be various types of devices equipped with computing capabilities.

A computer network (150) is a digital telecommunications network, which means connecting various distributed devices to a given communication network. The computer network (150) can be implemented as any type of wired or wireless network, such as a local area network (LAN), a wide area network (WAN), a mobile radio communication network, Wibro (Wireless Broadband Internet), etc.

In one embodiment, the device (110) may obtain first ticket information including information corresponding to each of one or more non-fungible tokens (hereinafter, “first non-fungible tokens”) issued by a smart contract related to an event. The event may occur at a certain place and time by a certain entity. For example, the event may include a performance, an exhibition, an event, etc. The smart contract related to the event may issue and manage a ticket that can enter the event. For example, the device (110) may cause at least one of at least one node (141) of the blockchain network (140) to execute the smart contract, and in this process, the smart contract may issue one or more first non-fungible tokens associated with the specific event. For example, if there are 500 tickets for performance A, 500 first non-fungible tokens corresponding to each ticket may be issued. The first ticket information may be a set of ticket information corresponding to each of the non-fungible tokens issued by the smart contract. The second ticket information may be ticket information corresponding to one non-fungible token among one or more first non-fungible tokens (hereinafter, “second non-fungible token”).

The device (110) may receive the first ticket information from at least one of the server (130) or the nodes (141). In one embodiment, the server (130) may receive the first ticket information from at least one of the nodes (141) via a smart contract and transmit the received first ticket information to the device (110). In one embodiment, the device (110) may also directly receive the first ticket information from at least one of the nodes (141) via the smart contract. For example, the device (110) may receive the first ticket information from at least one of the nodes (141) via an Inter Planetary File System (IPFS), which is a peer-to-peer data transmission method.

In one embodiment, the device (110) can repeatedly obtain the first ticket information at regular intervals. Through this, the device (110) can determine the validity of the ticket by reflecting changes in the ticket information corresponding to the non-fungible token.

In one embodiment, the device (110) may recognize a code displayed on a user's terminal (120) associated with a second non-fungible token and obtain encrypted information corresponding to the code. The encrypted information may be information encrypted by the terminal (120) based on second ticket information corresponding to the second non-fungible token. The user's terminal (or terminal (120)) does not need to be a terminal owned by the user and may be a terminal under the user's possession. The user's terminal (120) associated with the second non-fungible token may be a terminal of a user who owns a ticket corresponding to the second non-fungible token or a terminal of a user who has rented a ticket. The code may be recognized by a code recognition device (111) as a means for obtaining encrypted information. For example, the code may include a QR code, a barcode, an identification code included in an RFID (radio-frequency identification) tag, etc.

In one embodiment, the device (110) can determine whether the code is valid based on the first ticket information and the encryption information. In the present disclosure, determining whether the code is valid has the same meaning as determining the validity of a ticket corresponding to the code. The device (110) can determine whether the code displayed on the user terminal (120) is valid based on the second ticket information obtained by decrypting the encryption information and the first ticket information including information corresponding to each of one or more first non-fungible tokens. For example, the device (110) can determine whether the code is valid based on whether at least one of various pieces of information included in the second ticket information is present in the first ticket information.

FIG. 2 is a block diagram illustrating a device according to various embodiments of the present disclosure. The device (110) may include one or more processors (210) and/or one or more memories (220). In one embodiment, some components of the device (110) may be deleted or other components (e.g., an output unit (240), etc.) may be added to the device (110). In addition, some components may be implemented in an integrated manner or implemented as a single or multiple entities. In the present disclosure, one or more processors (210) may be referred to as a processor (210). The expression “processor (210)” may mean a set of one or more processors, unless the context clearly indicates otherwise. In addition, in the present disclosure, one or more memories (220) may be referred to as a memory (220). The expression memory (220) may mean a set of one or more memories, unless the context clearly indicates otherwise.

At least some components within the device (110) may be connected to each other via a bus, GPIO (General Purpose Input/Output), SPI (Serial Peripheral Interface), or MIPI (Mobile Industry Processor Interface) to exchange data or signals.

The processor (210) may perform operations or data processing related to control or communication of each component of the device (110). Specifically, the processor (210) may control at least one component of the device (110) connected to the processor (210) by running software (e.g., commands, programs, etc.) received from another component. As an example, the processor (210) may load a command or data into the memory (220), process the command or data stored in the memory (220), and store result data according to the processing in the memory (220). In addition, the processor (210) may be operatively connected to the components of the device (110) to perform various operations, such as operations, processing, data generation, and processing, related to the contents disclosed in the present disclosure.

The memory (220) can store various data. The data stored in the memory (220) is data acquired, processed, or used by at least one component of the device (110), and may include software (e.g., commands, programs, etc.). As an example, the memory (220) may store commands for the operation of the processor (210) as a computer program. Here, the computer program may include one or more commands that cause the processor (210) to perform operations according to various embodiments of the present disclosure when loaded into the memory (220). That is, the processor (210) may perform operations according to various embodiments of the present disclosure by executing the one or more commands described above. In addition, the memory (220) may include a volatile or nonvolatile memory. In one embodiment, the command or program may be software stored in the memory (220), and may include an operating system for controlling the resources of the device (110), an application, or middleware that provides various functions to the application so that the application can utilize the resources of the device (110).

In one embodiment, the device (110) may further include a communication interface (230). The communication interface (230) may establish a wired or wireless communication channel with an external device (e.g., a server (110) or a user terminal (120)) and transmit and receive various data with the external device. In one embodiment, the communication interface (230) may include at least one port for connecting to an external device with a wired cable in order to communicate with the external device via wire. In this case, the communication interface (230) may perform communication with the external device connected via wire through at least one port. In one embodiment, the communication interface (230) may include a cellular communication module and may be configured to be connected to a cellular network (e.g., 3G, LTE, 5G, Wibro, or Wimax). In one embodiment, the communication interface (230) may include a short-range communication module to transmit and receive data with an external device using short-range communication (e.g., Wi-Fi, Bluetooth, Bluetooth Low Energy (BLE), UWB). In one embodiment, the communication interface (230) may include a contactless communication module for contactless communication. The contactless communication may include at least one contactless proximity communication technology, such as NFC communication, RFID (Radio Frequency Identification) communication, or MST (Magnetic Secure Transmission) communication, for example. In addition to the various examples described above, the device (110) may be implemented in various known ways for communicating with an external device, and the scope of the present disclosure is not limited by the examples described above.

In one embodiment, the device (110) may further include an output unit (240). Here, the output unit (240) may display various screens based on the control of the processor (210). For example, the output unit (240) may display a dashboard visualizing the token holding status of platform users based on the control of the processor (210). At this time, in order to display the dashboard on the output unit (240), for example, a web browser or a dedicated application may be installed on the device (110). In one embodiment, the aforementioned web browser or dedicated application may be implemented to provide a token issuance request function or a communication function with other users to the user through a user interface. In addition, the output unit (240) is a configuration capable of interacting with the user, and may display various screens based on the control of the processor (210) and receive user input from the user. This output unit (240) may be implemented in the form of a touch sensor panel (TSP) that can recognize contact or proximity of various external objects (e.g., fingers, stylus, etc.). Here, the touch sensor panel may have various structures and types, and the contents disclosed in the present disclosure may be applied regardless of the structure and type of the touch sensor panel. The output unit (240) may be omitted from the device (110) depending on the embodiment.

In one embodiment, the device (110) may further include an input unit (250) (e.g., a mouse, a keyboard, etc.). Here, the input unit (250) may receive data to be used for a component of the device (110) (e.g., a processor (210)) from an external source of the device (110) (e.g., a user). The input unit (250) may be omitted from the device (110) depending on the embodiment.

In one embodiment, each of the terminal (120) and the server (130) may include one or more processors and/or one or more memories. The terminal (120) and the server (130) may further include a communication interface, an output port, and/or an input port. The configuration of the terminal (120) and the server (130) described above is only an example and the present disclosure is not limited thereto.

FIG. 3 is a flowchart illustrating a method for determining the validity of a ticket using a non-fungible token according to various embodiments of the present disclosure. In one embodiment, the server (130) may transmit second ticket information to the terminal (120) (S331). In response to a ticket purchase request received from the terminal (120), the server (130) may update user identification data corresponding to the second non-fungible token with user identification data corresponding to a user of the terminal (120). In addition, the server (130) may transmit second ticket information to the terminal (120). While transmitting the second ticket information, the server (130) may update first ticket information based on the second ticket information. The operation of updating the first ticket information may be performed by at least one of the nodes (141) executing a smart contract, and in this case, the server (130) may receive updated first ticket information from at least one of the nodes (141) as a result of executing the smart contract.

The terminal (120) can receive the second ticket information (S311). The terminal (120) can first encrypt the second ticket information based on the first encryption key (S312). The encryption key is a specific code or password used to encrypt or decrypt information. The encryption key can be used to protect the information and allow only authorized users to access it. In the present disclosure, for convenience of explanation, the encryption key stored in the terminal (120) is referred to as the first encryption key, and the encryption key stored in the device (110) is referred to as the second encryption key. The first encryption key and the second encryption key may be the same or different. When the first encryption key and the second encryption key are the same, the first encryption key and the second encryption key may include at least one of a symmetric key or a session key. The symmetric key is a key used to generate or decrypt a ciphertext, and may be the same encryption key for decrypting encrypted data. Only parties sharing the symmetric key can decrypt the encrypted information. The session key is used as an authentication means for user authentication and is an encryption key used to maintain the security of session communication. The session key protects and encrypts communication between sessions to maintain security. If the first encryption key and the second encryption key are different, the first encryption key may be a public key and the second encryption key may be a private key. The public key and the private key may be asymmetric keys. The public key is used for encryption and can be provided to the communication partner to safely transmit information. On the other hand, the private key is used for decryption and can be used only by the party owning the key to decrypt information.

In one embodiment, the server (130) can transmit a second encryption key to the device (110) (S332). The device (110) can store the second encryption key (S351).

The execution order of operations (S331) and (S332) can be changed, and the execution order is not limited by the flow chart of Fig. 3. Since operation (S331) is performed when a ticket purchase request is received from the terminal (120), it can be performed at any point in the flow chart.

In one embodiment, the terminal (120) may generate encrypted information by secondarily encrypting the first encrypted second ticket information based on the first time information. The time information may be an arbitrary value generated at each time interval. For example, the time information may include a value “130293” corresponding to a time interval between 10:01:00 and 10:01:59, and a value “920313” corresponding to a time interval between 10:02:00 and 10:02:59, which is a next time interval. Therefore, according to a certain rule, the time information is a value generated at each time interval, and all values generated at a specific time interval may be the same regardless of which device generates it. For example, the value “130293” may be generated identically at the time interval between 10:01:00 and 10:01:59 in the device (110) and the terminal (120). In the present disclosure, for convenience of explanation, the first time information is time information generated in the terminal (120), and the second time information is time information generated in the device (110).

In one embodiment, the server (130) may receive first ticket information from the smart contract and transmit the received first ticket information to the device (110) (S333). The server (110) receiving the first ticket information from the smart contract may mean that at least one of the nodes (141) executes the smart contract, so that the server (110) receives the first ticket information from at least one of the nodes (141). The device (110) may obtain and store the first ticket information from the server (130) (S352). As another example, the device (110) may also receive the first ticket information from at least one of the nodes (141).

In one embodiment, the device (110) may obtain the first ticket information prior to the first time point (301). The first time point (301) may be a time point prior to a predetermined time period from the time of the event. If a large number of people gather at the event, network access at the event venue may be blocked due to increased traffic. Accordingly, communication via the computer network (150) between the device (110), the terminal (120), and the server (130) may become impossible. Accordingly, if the server (130) determines the validity of the ticket, the event venue may not be able to determine the validity of the users' tickets, making it difficult to proceed with the event. Even in this case, the device (110) must recognize the code displayed on the terminal (120) and determine whether the code is valid so that the event can proceed smoothly. To this end, the device (110) may receive and store the most recent first ticket information prior to a predetermined time period from the start time of the event. That is, the first point in time (301) may be a point in time before the point in time at which access to the network at the event venue is expected to be blocked due to increased traffic. The device (110) can determine the validity of the ticket even in a situation where access to the computer network (150) is impossible by using the first ticket information.

However, after the first point in time, due to the sale of the ticket, the ownership of the ticket may change, and the correspondence relationship between the identification data of the non-fungible token included in the second ticket information and the user identification data may change. In this case, since the first ticket information stored in the device (110) does not have a changed correspondence relationship with the first ticket information acquired before the first point in time, the device (110) may determine that the code is invalid. To prevent this, the first point in time may be set as a point in time at which changes in information corresponding to each of one or more first non-fungible tokens are restricted by a smart contract. Accordingly, it is possible to prevent the ownership of the ticket from changing after the first point in time. The device (110) may transmit a ticket transaction prohibition request to the server (130) or the address of the smart contract at the time of acquiring the first ticket information, and in response to the request, changes in information corresponding to each of one or more first non-fungible tokens may be restricted.

The terminal (120) may generate encrypted information by re-encrypting the first encrypted second ticket information based on the first time information for the first time interval corresponding to the time point of encrypting the second ticket information. For example, the time point of encrypting the second ticket information may be the time point at which the terminal (120) receives a code generation request. The user may select the code generation button to display the code on the screen in order to enter or participate in the event.

In one embodiment, the operation of obtaining encrypted information (S353) or the operation of determining whether the code is valid (S357) may be performed after the first time point.

In one embodiment, the terminal (120) can generate a code corresponding to the encryption information and display the code on the screen (S314). The terminal (120) can generate encryption information in response to a code generation request and display the code corresponding to the encryption information on the screen.

In one embodiment, the device (110) can recognize a code displayed on the terminal (120) (S353). The device (110) can recognize the code displayed on the terminal (120) and obtain encrypted information corresponding to the code (S354). In one embodiment, the device (110) can first decrypt the encrypted information based on second time information for a second time interval corresponding to a time point at which the encrypted information is decrypted (S355). The encrypted information may be information encrypted based on a first encryption key and first time information for a first time interval corresponding to a time point at which the terminal (120) encrypts the second ticket information. For example, the encrypted information may be generated by the operation (S312) and the operation (S313). The device (110) can secondarily decrypt the first decrypted encrypted information based on a second encryption key associated with the first encryption key to obtain second ticket information (S356). The device (110) can determine whether the code is valid based on the first ticket information and the second ticket information (S357).

In one embodiment, the device (110) may determine that the code is invalid if it fails to decrypt the encrypted information. For example, the failure to decrypt the encrypted information may include decrypting the encrypted information based on a second encryption key that is not associated with the first encryption key. For another example, the failure to decrypt the encrypted information may include a case where the decryption fails because the first time interval and the second time interval are different. For example, if the first time interval is 10:05:00 - 5:59, and the second time interval is 10:07:00 - 7:59, the device (110) may fail to decrypt because the first time interval and the second time interval are different.

In one embodiment, the device (110) can decrypt the encrypted information to obtain the second ticket information. The device (110) can determine whether the code is valid based on the first ticket information and the second ticket information. Various methods for determining whether the code is valid are described below.

In one embodiment, the device (110) may determine whether identification data of a non-fungible token that matches identification data of a second non-fungible token included in the second ticket information is present in the first ticket information. The first ticket information may include identification data corresponding to each of one or more first non-fungible tokens. For example, the first ticket information may include 500 pieces of identification data corresponding to each of 500 first non-fungible tokens. The device (110) may determine whether identification data of a second non-fungible token included in the second ticket information is present among the 500 pieces of identification data. The device (110) may determine the code to be valid based on a determination that identification data of a second non-fungible token included in the second ticket information is present in the first ticket information. Conversely, the device (110) may determine that identification data of a second non-fungible token included in the second ticket information is not present in the first ticket information. Through this, the device (110) can determine whether a ticket corresponding to the second ticket information is an actually sold ticket by using the identification data of the second non-replaceable token included in the second ticket information.

In another embodiment, the device (110) may determine whether the code is valid based on whether the ownership information of the ticket exists in the first ticket information. The ownership information of the ticket may be expressed as a correspondence relationship between the identification data of the second non-fungible token and the user identification data included in the second ticket information. The device (110) may determine whether a correspondence relationship between the identification data of the second non-fungible token included in the second ticket information and the user identification data included in the second ticket information exists in the first ticket information. For example, the device may determine whether a correspondence relationship between the identification data of the second non-fungible token included in the second ticket information and the user ID exists in the first ticket information. For another example, the device (110) may determine whether a correspondence relationship between the identification data of the second non-fungible token included in the second ticket information and the user's wallet address exists in the first ticket information. The device (110) may determine the code is valid based on a determination that a correspondence relationship corresponding to the first ticket information exists. Conversely, the device (110) may determine that the code is invalid based on a determination that a correspondence relationship corresponding to the first ticket information does not exist. Through this, the device (110) can determine the validity of the ticket by using the ownership information of the ticket and the information associated with the non-fungible token.

In another embodiment, the device (110) can determine whether the code is valid by checking the event. The method of checking the event can be to check the address of the smart contract. This is because the address of the smart contract can be different for each event. The device (110) can determine whether the address of the smart contract included in the second ticket information matches the address of the smart contract included in the first ticket information. The device (110) can determine the code is valid based on a determination that the address of the smart contract included in the second ticket information matches the address of the smart contract included in the first ticket information. Conversely, the device (110) can determine the code is invalid based on a determination that the address of the smart contract included in the second ticket information does not match the address of the smart contract included in the first ticket information. Through this, the device (110) can identify the event and determine the validity of the ticket.

In another embodiment, the device (110) may use ticket-related metadata to determine whether a code is valid. The ticket-related metadata may include information about at least one of the event's name, schedule, location, seat identifier, price, or purchase conditions of the ticket. For example, if the event is a concert by singer A, the ticket-related metadata may include the concert name, the concert date and time, the seat number, the purchase price, the purchase conditions, the purchasing user information, and in the case of a transferred ticket, the previous owner information. The seat identifier of the ticket may indicate the seat number, the seat type, etc. The price may include the original sale price, the price sold at the time of transfer, etc. The purchase conditions may be conditions for purchasing the ticket, and may be conditions set by the event organizer, for example. For example, the purchase conditions may include conditions such as prohibiting transfer to others, prohibiting resale above a certain price, etc. The ticket-related metadata may further include coupons related to the event. For example, the coupons may include free food and beverage coupons, food and beverage discount coupons, and/or event-related product discount coupons that can be used within the event. The device (110) can determine whether metadata matching the ticket-related metadata included in the second ticket information exists in the first ticket information. The device (110) can determine the code to be valid based on a determination that metadata matching the ticket-related metadata included in the second ticket information exists in the first ticket information. Conversely, the device (110) can determine the code to be invalid based on a determination that metadata matching the ticket-related metadata included in the second ticket information does not exist in the first ticket information. Since the ticket-related metadata includes various information, it can be utilized as unique information for identifying the ticket. Therefore, the device (110) can determine the ticket to be invalid if the ticket-related metadata does not exist in the first ticket information.

In another embodiment, the device (110) may determine that the code is valid only if the address of the smart contract is verified and the ownership information is verified. The device (110) may determine that the code is valid in response to a determination that the address of the smart contract included in the second ticket information matches the address of the smart contract included in the first ticket information, and that a correspondence between the identification data of the second non-fungible token included in the second ticket information and the user identification data included in the second ticket information exists in the first ticket information. The device (110) may determine that the code is invalid if the address of the smart contract included in the second ticket information does not match the address of the smart contract included in the first ticket information, or if a correspondence between the identification data of the second non-fungible token included in the second ticket information and the user identification data included in the second ticket information does not exist in the first ticket information. As in the above-described embodiments, the device (110) may combine various methods for determining the validity of a ticket, and the present disclosure is not limited thereto.

FIG. 4 is a flowchart illustrating a method of issuing a non-fungible token and changing information corresponding to the non-fungible token according to various embodiments of the present disclosure. In one embodiment, a server (130) may transmit a smart contract corresponding to an event to at least one of nodes (141) included in a blockchain network (140) (S411). In the present disclosure, the operation of transmitting to at least one of the nodes (141) may mean that a node included in the blockchain network (140) executes the smart contract in response to the signal by transmitting a signal to an address of the smart contract. At least one of the nodes (141) may execute the smart contract to issue one or more first non-fungible tokens corresponding to a selected number of tickets (S431). The smart contract may include the number of issued first non-fungible tokens, and at least one of the nodes (141) may issue the corresponding number of first non-fungible tokens.

In one embodiment, the server (130) may receive a ticket purchase request from the terminal (120) and transmit a non-fungible token matching request to at least one of the nodes (141) based on the user identification data of the terminal (S412). At least one of the nodes (141) may transmit identification data of a second non-fungible token corresponding to the user identification data of the terminal (120) (S432). Through this, the second non-fungible token may be received in the user's wallet.

In one embodiment, the server (130) may update the first ticket information based on the correspondence between the user identification data and the identification data of the second non-fungible token (S413). In another embodiment, the server (130) may receive the updated first ticket information from at least one of the nodes (141) instead of the operation (S413).

In one embodiment, the server (130) may transmit a request to modify the user identification data from that of the first user to that of the second user if the first user transfers the ticket to the second user (S414). At least one of the nodes (141) may update the user identification data corresponding to the identification data of the second non-fungible token (S433). At least one of the nodes (141) may update the user identification data corresponding to the identification data of the second non-fungible token from that of the first user to that of the second user. At least one of the nodes (141) may reflect the update result in the first ticket information, and at least one of the nodes (141) may transmit the first ticket information with the update result reflected therein to the server (130).

In one embodiment, at least one of the nodes (141) may restrict changes to information corresponding to each of the one or more first non-fungible tokens (S434). At least one of the nodes (141) may perform an operation (S434) at a first point in time (301). A smart contract may have a point in time set that is a certain amount of time before the start time of the event. For example, if the start time of the event is 19:00 on October 1, 2024, a point in time that is 1 hour before, 18:00 on October 1, 2024, may be set as the first point in time. At least one of the nodes (141) may perform an operation (S434) based on the point in time included in the smart contract.

In one embodiment, the device (110) may receive the first ticket information prior to the first time point (301). In another embodiment, the device (110) may receive the first ticket information immediately after the first time point (301).

FIG. 5 is a diagram illustrating a method for determining the validity of a ticket based on time information in various embodiments of the present disclosure. There may be multiple time intervals (511, 512, 513, 514) as time passes. And there may be time information corresponding to each of the multiple time intervals.

In one embodiment, the terminal (120) may encrypt the second ticket information based on first time information (510) for a first time interval corresponding to a time point (560) at which the second ticket information is encrypted.

In one embodiment, the device (110) can decrypt the encrypted information based on second time information (520) for a second time interval corresponding to the time at which the encrypted information is decrypted.

For example, if the time point (560) of encrypting the second ticket information and the time point A (570) of decrypting the encrypted information are included in the same time interval t ₂ - t ₃ (512), the first time information (510) and the second time information (520) may have the same value. Accordingly, the device (110) may determine that the code is valid through the result of decryption using the second time information (520).

For another example, if the time point (560) for encrypting the second ticket information is included in the time interval t ₂ - t ₃ (512), and the time point B (580) for decrypting the encrypted information is included in the time interval t ₃ - t ₄ (513), the first time information (510) and the second time information (520) may have different values. This is because the time information corresponding to each time interval is different. Accordingly, the device (110) may determine that the code is invalid through the result of decryption using the second time information (520).

Since the terminal (120) generates encryption information based on the first time information (510), different encryption information can be generated at each time interval. If different encryption information is generated at each time interval, if the device (110) does not recognize the code within a certain time from the time at which the time information is generated, the device (110) determines that the code is invalid, so the user has no choice but to generate a code at the time of entering the event. In this case, since there is a restriction that the user must generate a code and immediately recognize it in the device (110), the user can enter the event with only his or her ticket. Accordingly, since the user can only use his or her ticket, he or she cannot sell tickets to other users, so that black market trading, in which a large number of tickets are purchased at one time and then sold to other users at high prices, can be cut off. In addition, since the time information is generated at each time interval, even if communication through the server (130) and the computer network (150) is cut off, the device (110) can safely determine the validity of the ticket.

FIG. 6 is a flowchart illustrating a method of displaying a screen of a device according to a result of determining the validity of a ticket according to various embodiments of the present disclosure. In one embodiment, the device (110) can recognize a code (S610). The device (110) can determine whether the code is valid based on the encrypted information obtained by recognizing the code (S620). The operation (S620) may be the same as the operation (S357) of FIG. 3.

In one embodiment, the device (110) may, in response to determining that the code is valid, display the validity of the code on the screen (S630). For example, the device (110) may display a color (e.g., green) indicating the validity of the code on the screen. As another example, the device (110) may display text on the screen indicating that the ticket is valid (e.g., Ticket has been verified).

In one embodiment, the device (110) may display ticket-related metadata on the screen (S640). For example, the device (110) may display at least one of the event name, schedule, location, seat identifier of the ticket, price, coupon, or purchase conditions on the screen.

In one embodiment, in response to determining that the code is invalid, the device (110) may display on the screen that the code is invalid (S650). For example, the device (110) may display a color (e.g., red) on the screen that indicates that the code is invalid. As another example, the device (110) may display text on the screen that indicates that the ticket is invalid (e.g., Ticket is invalid).

FIG. 7 is a flowchart illustrating a method of determining the validity of a ticket by generating a code in a terminal (120) according to another embodiment of the present disclosure. The embodiment described below may be one in which a terminal (120) generates a code and a server (130) determines whether the code is valid.

In one embodiment, the server (130) can transmit an encryption key to the terminal (120) (S731). The terminal (120) can receive the encryption key (S731). The terminal (120) can generate a code based on the first time information and the encryption key, and display the code on the screen (S712).

In one embodiment, the device (110) can recognize the code (S751). The device (110) can transmit a code verification request to the server (130) (S752). The server (130) can verify the code based on the encryption key and the second time information (S732). If the first time information and the second time information are different, the server (130) can determine that the corresponding code is invalid, and if the first time information and the second time information are the same, the server (130) can determine that the corresponding code is valid.

In one embodiment, the server (130) can transmit the code verification result to the device (110) (S733). The device (110) can display the code verification result on the screen (S753).

FIG. 8 is a flowchart illustrating a method of determining the validity of a ticket by generating a code in a server according to another embodiment of the present disclosure. In the embodiment described below, the server (130) may generate a code and determine whether the code is valid. The terminal (120) may simply display the code on the screen.

In one embodiment, the server (130) may generate a code based on the first time information and the encryption key and transmit the code to the terminal (120) (S831). The terminal (120) may receive the code (S811). The terminal (120) may display the code on the screen (S812). The device (110) may recognize the code (S851). The device (110) may transmit a code verification request to the server (130) (S852). The server (130) may verify the code based on the encryption key and the second time information (S832). If the first time information and the second time information are different, the server (130) may determine that the code is invalid, and if the first time information and the second time information are the same, the server (130) may determine that the code is valid.

In one embodiment, the server (130) can transmit the code verification result to the device (110) (S833). The device (110) can display the code verification result on the screen (S853).

FIG. 9 is a flowchart of the operation of a device according to various embodiments of the present disclosure. In one embodiment, the device (110) may obtain first ticket information including information corresponding to each of one or more first non-fungible tokens issued by a smart contract related to an event (S910).

In one embodiment, the device (110) may recognize a code displayed on a user terminal (120) of a user associated with a second non-fungible token, which is one of one or more first non-fungible tokens, and obtain encrypted information corresponding to the code (S920).

In one embodiment, the device (110) can determine whether the code is valid based on the first ticket information and the encryption information (S930).

In one embodiment, the device (110) may determine that a code is invalid if it fails to decrypt the encrypted information.

In one embodiment, the device (110) can decrypt the encrypted information to obtain the second ticket information and determine whether the code is valid based on the first ticket information and the second ticket information.

In one embodiment, the device (110) can first decrypt the encrypted information based on second time information for a second time interval corresponding to the time at which the encrypted information is decrypted. The device (110) can secondarily decrypt the first decrypted encrypted information based on a second encryption key associated with the first encryption key.

In one embodiment, the device (110) may determine whether identification data of a non-fungible token that matches identification data of a second non-fungible token included in the second ticket information is present in the first ticket information. Based on the determination that it is present in the first ticket information, the device (110) may determine that the code is valid.

In one embodiment, the device (110) can determine whether a correspondence between the identification data of the second non-fungible token included in the second ticket information and the user identification data included in the second ticket information exists in the first ticket information. Based on a determination that it exists in the first ticket information, the device (110) can determine that the code is valid.

In one embodiment, the device (110) may determine whether the address of the smart contract included in the second ticket information matches the address of the smart contract included in the first ticket information. The device (110) may determine the code to be valid based on a determination that the address of the smart contract included in the second ticket information matches the address of the smart contract included in the first ticket information.

In one embodiment, the device (110) may determine whether metadata that matches ticket-related metadata included in the second ticket information is present in the first ticket information. Based on the determination that the metadata is present in the first ticket information, the device (110) may determine that the code is valid.

In one embodiment, the device (110) may determine that the code is valid in response to a determination that the address of the smart contract included in the second ticket information matches the address of the smart contract included in the first ticket information, and that a correspondence relationship between the identification data of the second non-fungible token included in the second ticket information and the user identification data included in the second ticket information exists in the first ticket information.

In one embodiment, the device (110) may repeatedly perform the operation of obtaining first ticket information at regular intervals until the first time point.

FIG. 10 is a flowchart of operations of a terminal (120) according to various embodiments of the present disclosure. In one embodiment, the terminal (120) may receive second ticket information corresponding to a second non-fungible token, which is one of one or more first non-fungible tokens issued by a smart contract related to an event (S1010).

In one embodiment, the terminal (120) can generate encrypted information by encrypting the second ticket information (S1020). In one embodiment, the terminal (120) can display a code on the screen that enables the reader (e.g., device (110)) to obtain the encrypted information (S1030).

The encrypted information can be obtained by a reader (e.g., device (110)) that recognizes the code. The encrypted information can be decrypted by the reader into second ticket information. The encrypted information can be used as a basis for determining whether the code is valid, together with the first ticket information, which includes information corresponding to each of one or more first non-fungible tokens.

In one embodiment, the terminal (120) may first encrypt the second ticket information based on the first encryption key. The terminal (120) may second encrypt the first encrypted second ticket information based on first time information for a first time interval corresponding to the time at which the second ticket information is encrypted.

In one embodiment, an application that provides a service for trading a second non-fungible token may be installed in the terminal (120). A code may be displayed through the application. An operation for generating encrypted information may be performed through the application. Through the application, users may purchase tickets corresponding to the second non-fungible token. And, through the application, users may transfer tickets corresponding to the second non-fungible token to other users.

In one embodiment, the terminal (120) can perform biometric authentication for the user. Biometric authentication is an authentication method that uses the biometric characteristics of the individual to identify the individual. It is used for access control or user authentication using the biometric characteristics. Biometric authentication is based on various biometric information such as fingerprints, irises, and facial recognition. In one embodiment, the terminal (120) can display a code on the screen based on the result of the biometric authentication. If the biometric authentication passes, the code is displayed on the screen, and if the biometric authentication fails, the code may not be displayed on the screen. In another embodiment, the terminal can generate encrypted information based on the result of the biometric authentication. If the biometric authentication passes, encrypted information is generated, and if the biometric authentication fails, the code or encrypted information may not be generated.

In one embodiment, the terminal (120) may receive a first cryptographic key from a server (130) associated with an event or transmit a second cryptographic key associated with the first cryptographic key to the server (130) upon receiving a second non-fungible token in the user's wallet. As the second non-fungible token is received in the user's wallet, the second ticket information and the first cryptographic key may also be received together in the terminal (120). The server (130) may receive the second cryptographic key and transmit the second cryptographic key to the device (110).

Although the process steps, method steps, algorithms, etc. have been described in a sequential order, such processes, methods, and algorithms may be configured to operate in any suitable order. In other words, the steps of the processes, methods, and algorithms described in various embodiments of the present disclosure need not be performed in the order described herein. Furthermore, even if some steps are described as being performed asynchronously, in other embodiments such some steps may be performed concurrently. Furthermore, the illustration of a process by depiction in the drawings does not imply that the illustrated process is exclusive of other changes and modifications thereof, nor does it imply that the illustrated process or any of its steps is essential to one or more of the various embodiments of the present disclosure, nor does it imply that the illustrated process is preferred.

While the method has been described through specific embodiments, the method can also be implemented as computer-readable code on a computer-readable recording medium. The computer-readable recording medium includes all types of recording devices that store data that can be read by a computer system (10). Examples of the computer-readable recording medium may include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage, etc. In addition, the computer-readable recording medium can be distributed over network-connected computer systems (10), so that the computer-readable code can be stored and executed in a distributed manner. In addition, functional programs, codes, and code segments for implementing the embodiments can be easily inferred by programmers in the technical field to which the present disclosure pertains.

Claims (24)

A method performed in a device comprising one or more processors and one or more memories storing instructions to be executed by the one or more processors,
One or more of the above processors,
A step of obtaining first ticket information including information corresponding to each of one or more first non-fungible tokens (NFTs) issued by a smart contract related to an event;
A step of recognizing a code displayed on a user terminal of a user associated with a second non-fungible token, which is one of the one or more first non-fungible tokens, and obtaining encrypted information corresponding to the code, wherein the encrypted information is information encrypted by the user terminal based on second ticket information corresponding to the second non-fungible token; and
A step of determining whether the code is valid based on the first ticket information and the encryption information,
A method according to claim 1, wherein the step of obtaining the first ticket information is performed before a first point in time at which changes to information corresponding to each of the one or more first non-fungible tokens are restricted by the smart contract.
delete delete In the first paragraph,
A method, wherein the step of obtaining the above-mentioned encrypted information and the step of determining whether the above-mentioned code is valid are performed after the first time point.
In the first paragraph,
The steps to determine whether the above code is valid are:
A method comprising the step of determining that the code is invalid if decrypting the encrypted information fails.
In the first paragraph,
The steps to determine whether the above code is valid are:
A step of decrypting the above encrypted information to obtain the second ticket information; and
A method comprising the step of determining whether the code is valid based on the first ticket information and the second ticket information.
In Article 6,
The above encrypted information is encrypted information based on the first encryption key and the first time information for the first time interval corresponding to the time at which the user terminal encrypts the second ticket information,
The step of decrypting the above encrypted information and obtaining the second ticket information is:
A step of first decrypting the encrypted information based on second time information for a second time interval corresponding to the time at which the device decrypts the encrypted information; and
A method comprising the step of secondarily decrypting the encrypted information that has been firstly decrypted based on a second encryption key associated with the first encryption key.
In Article 7,
If the first encryption key and the second encryption key are the same, the first encryption key and the second encryption key include at least one of a symmetric key or a session key,
A method wherein, when the first encryption key and the second encryption key are different, the first encryption key is a public key and the second encryption key is a private key.
In Article 7,
Step of receiving the second encryption key from the server
A method further comprising:
In the first paragraph,
The step of determining whether the code is valid based on the first ticket information and the second ticket information is as follows:
A step of determining whether identification data of a non-replaceable token matching the identification data of the second non-replaceable token included in the second ticket information exists in the first ticket information; and
A method comprising the step of determining that the code is valid based on a determination that the first ticket information exists.
In the first paragraph,
The step of determining whether the code is valid based on the first ticket information and the second ticket information is as follows:
A step of determining whether a correspondence relationship between the identification data of the second non-replaceable token included in the second ticket information and the user identification data included in the second ticket information exists in the first ticket information; and
A method comprising the step of determining that the code is valid based on a determination that the first ticket information exists.
In the first paragraph,
The step of determining whether the code is valid based on the first ticket information and the second ticket information is as follows:
A step of determining whether the address of the smart contract included in the second ticket information matches the address of the smart contract included in the first ticket information; and
A method comprising the step of determining that the code is valid based on a determination that the address of the smart contract included in the second ticket information matches the address of the smart contract included in the first ticket information.
In the first paragraph,
The step of determining whether the code is valid based on the first ticket information and the second ticket information is as follows:
A step of determining whether metadata matching the ticket-related metadata included in the second ticket information exists in the first ticket information; and
A method comprising the step of determining that the code is valid based on a determination that the first ticket information exists.
In the first paragraph,
The step of determining whether the code is valid based on the first ticket information and the second ticket information is as follows:
A step of determining that the code is valid in response to a determination that the address of the smart contract included in the second ticket information matches the address of the smart contract included in the first ticket information, and that a correspondence relationship between the identification data of the second non-fungible token included in the second ticket information and the user identification data included in the second ticket information exists in the first ticket information.
A method comprising:
In the first paragraph,
The above second ticket information is,
At least one of identification data of the second non-fungible token, user identification data of the user associated with the second non-fungible token, or ticket-related metadata of the second non-fungible token;
A method wherein the ticket-related metadata of the second non-fungible token is information about a ticket of the event corresponding to the second non-fungible token.
In Article 15,
The above ticket related metadata is:
A method comprising information regarding at least one of the name, schedule, location, seat identifier, price, or purchase conditions of the event.
In the first paragraph,
A method, wherein the step of obtaining the first ticket information includes a step that is repeatedly performed at regular intervals.
A method performed in a terminal including one or more processors and one or more memories storing instructions to be executed by the one or more processors,
One or more of the above processors,
A step of receiving second ticket information corresponding to a second non-fungible token, which is one of one or more first non-fungible tokens (NFTs) issued by a smart contract related to an event;
A step of generating encrypted information by encrypting the second ticket information; and
Including a step of displaying a code on the screen that enables obtaining the above-mentioned encrypted information from the reader;
The above reader obtains first ticket information including information corresponding to each of the one or more first non-fungible tokens prior to a first point in time at which change of information corresponding to each of the one or more first non-fungible tokens is restricted by the smart contract,
The above encrypted information is
Obtained by a reader that recognizes the above code,
By the above reader, the second ticket information is decrypted,
The first ticket information, which includes information corresponding to each of the one or more first non-fungible tokens, is used as a basis for determining whether the code is valid.
method.
In Article 18,
The step of generating the above encrypted information is:
A step of first encrypting the second ticket information based on the first encryption key; and
A step of secondly encrypting the first encrypted second ticket information based on the first time information for the first time interval corresponding to the time at which the second ticket information is encrypted.
A method comprising:
In Article 18,
In the above terminal, an application is installed that provides a service that can trade the second non-fungible token,
The above code is expressed through the above application, method.
In Article 18,
The steps to display the above code on the screen are:
Steps for performing biometric authentication on a user; and
A method comprising the step of displaying the code on a screen based on the result of the biometric authentication.
In Article 18,
A method further comprising the step of receiving a first cryptographic key from a server associated with the event, or transmitting a second cryptographic key associated with the first cryptographic key to the server, upon receipt of the second non-fungible token in the user's wallet.
one or more processors; and
comprising one or more memories storing instructions to be executed by said one or more processors;
Upon execution of the above instructions, the one or more processors,
Obtain first ticket information including information corresponding to each of one or more first non-fungible tokens issued by a smart contract related to the event,
Recognizing a code displayed on a user terminal of a user associated with a second non-fungible token, which is one of the one or more first non-fungible tokens, and obtaining encrypted information corresponding to the code, wherein the encrypted information is information encrypted by the user terminal based on second ticket information corresponding to the second non-fungible token; and
Based on the above first ticket information and the above encryption information, determine whether the code is valid,
Obtaining the above first ticket information is performed prior to the first point in time when changes to information corresponding to each of the one or more first non-fungible tokens are restricted by the smart contract.
device.
In a non-transitory computer-readable recording medium having recorded thereon instructions to be executed by one or more processors,
The above instructions, when executing the above instructions, cause the one or more processors to:
Obtain first ticket information including information corresponding to each of one or more first non-fungible tokens issued by a smart contract related to the event;
Recognize a code displayed on a user terminal of a user associated with a second non-fungible token, which is one of the first non-fungible tokens, and obtain encrypted information corresponding to the code, wherein the encrypted information is information encrypted by the user terminal based on second ticket information corresponding to the second non-fungible token; and
Based on the above first ticket information and the above encryption information, determine whether the code is valid,
Obtaining the above first ticket information is performed prior to the first point in time when changes to information corresponding to each of the one or more first non-fungible tokens are restricted by the smart contract.
A non-transitory computer-readable recording medium.

Images