Method and apparatus for managing access to virtual spaces based on digital non-fungible tokens

Abstract

A method according to one embodiment of the content disclosed in this document may include a step in which a processor connected to a computer network including a blockchain network receives, from a user's terminal, an access request requesting access to at least a portion of a virtual space consisting of a plurality of regions; a step in which the processor receives, based on the access request, first information on a non-fungible token determined to allow the user access to at least a portion of the regions; a step in which the processor verifies access authority indicating whether the user is allowed access to at least a portion of the regions by determining, based on the first information, whether the user owns the non-fungible token; and a step in which the processor sends a response corresponding to the access request to the user's terminal based on a result of the verification.

Description

[Technical Field]

[0001] The subject matter disclosed in this document relates to a technology for managing access to a virtual space based on non-fungible tokens. [Background technology]

[0002] In recent years, interest in the metaverse, which is content that embodies real-world interactions in a virtual space, has been increasing. The metaverse is expected to be applied not only to the entertainment industry but also to various other industries, providing users with a three-dimensional experience for various purposes. Summary of the Invention [Problem to be solved by the invention]

[0003] Detailed Description of the Invention technical challenges The technical problem to be solved by the contents disclosed in this document is to provide a technology that allows non-fungible tokens to be used as admission tickets to spaces.

[0004] Another technical problem that the disclosure in this document seeks to solve is providing a technology that allows proof of ownership of non-fungible tokens.

[0005] Yet another technical problem to be solved by the contents disclosed in this document is to provide a technology that can improve user convenience when proving ownership of non-fungible tokens.

[0006] Yet another technical problem addressed by the disclosure herein is that of providing a technique that allows users to retain control over the validation procedures associated with their ownership of non-fungible tokens (e.g., allowing users to control what token information is made public).

[0007] Yet another technical problem that the content disclosed in this document aims to solve is to provide technology that allows users to protect their personal information by allowing them to choose the information they disclose when proving possession of non-fungible tokens sufficient to grant access rights to a space.

[0008] The technical problems disclosed in this document are not limited to (nor are they necessarily included in) the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art of the technology disclosed in this document from the following description. [Means for solving the problem]

[0009] Technical solution A method according to one embodiment disclosed in this document may include a step in which a processor connected to a computer network including a blockchain network receives, from a user's terminal, an access request requesting access to at least a portion of a virtual space consisting of a plurality of regions; a step in which the processor receives, based on the access request, first information on a non-fungible token determined to allow the user access to at least a portion of the regions; a step in which the processor verifies access authority indicating whether the user is allowed access to at least a portion of the regions by determining, based on the first information, whether the user owns the non-fungible token; and a step in which the processor sends a response corresponding to the access request to the user's terminal based on a result of the verification.

[0010] In one embodiment, the at least some area is an area set so that an object corresponding to the user can move, and includes a first area and a second area distinct from the first area, and the step of transmitting the response includes a step of transmitting a response to the user's terminal such that a first service set is activated when the object approaches the first area, and a second service set is activated when the object approaches the second area, and the first service set and the second service set may be distinct.

[0011] In one embodiment, the first service set may include one or more first interactive objects configured to be able to interact with the object, and the second service set may include one or more second interactive objects configured to be able to interact with the object.

[0012] In one embodiment, the step of verifying the access authority may include a step of obtaining second information for a non-fungible token owned by the user, a step of verifying whether one or more first items included in the first information correspond to one or more second items included in the second information, and a step of verifying that the user has access authority to at least a portion of the area by verifying that the one or more first items and the one or more second items correspond to each other.

[0013] In one embodiment, the one or more first items may include a first list of non-fungible tokens determined to be accessible, a token identifier, metadata, a contract address, and a virtual space identifier identifying the virtual space for each of the non-fungible tokens included in the first list, and the one or more second items may include a second list of non-fungible tokens owned by the user, a token identifier, metadata, a contract address, and a virtual space identifier identifying a virtual space associated with each of the non-fungible tokens included in the second list.

[0014] In one embodiment, verifying the access authority includes determining whether the user possesses a first non-fungible token and a second non-fungible token, respectively, related to the first information, and the first non-fungible token may be distinguishable from the second non-fungible token.

[0015] In an embodiment, the step of transmitting the response may include transmitting a link to the virtual space corresponding to the access request to the user's terminal.

[0016] A method according to another embodiment disclosed in this document may include a step in which a processor connected to a computer network including a blockchain network receives, from a user's terminal, an access request requesting access to at least a portion of a virtual space consisting of a plurality of regions; a step in which the processor receives, based on the access request, first information on a non-fungible token determined to allow the user access to the at least a portion of the regions; a step in which the processor receives, from an external device related to a non-fungible token platform, second information on a non-fungible token owned by the user; a step in which the processor verifies access authority indicating whether the user is allowed access to the at least a portion of the regions by determining, based on the first information and the second information, whether the user owns a non-fungible token determined to allow the user access; and a step in which the processor transmits a response corresponding to the access request to the user's terminal based on a result of the verification.

[0017] In another embodiment, the step of obtaining the second information may include the steps of obtaining a first authentication token from a first external device involved in authentication of the non-fungible token platform based on the user information of the user, requesting the second information from a second external device involved in resources of the non-fungible token platform using the first authentication token, and obtaining the second information from the second external device.

[0018] A method according to yet another embodiment disclosed in this document may include a step in which a processor connected to a computer network including a blockchain network receives, from a user's terminal, an access request requesting access to at least a portion of a virtual space consisting of a plurality of regions; a step in which the processor receives, based on the access request, first information on a non-fungible token determined to allow the user access to at least a portion of the regions; a step in which the processor receives, from the user's terminal, a submission certificate generated based on the first information to prove the user's possession of the non-fungible token; a step in which the processor verifies access authority indicating whether the user is allowed access to at least a portion of the regions by determining, based on the submission certificate, whether the user owns the non-fungible token; and a step in which the processor sends a response corresponding to the access request to the user's terminal based on a result of the verification.

[0019] In yet another embodiment, the submission certificate may include one or more verification items related to the non-fungible token owned by the user, and the step of verifying the access authority may include a step of selecting a target verification item from the one or more verification items to determine whether the user is allowed to access at least a portion of the area, and a step of verifying the access authority indicating whether the user is allowed to access at least a portion of the area based on the user's verification input value obtained corresponding to the target verification item.

[0020] In yet another embodiment, the step of obtaining the submission certificate includes the step of obtaining an identifier of the user, the identifier including a storage location of an identification document on the blockchain network, and the identification document including the one or more verification items, one or more verification values corresponding to each of the one or more verification items, and the public key of the user.

[0021] In yet another embodiment, the step of obtaining the submission certificate includes the steps of transmitting the first information to the user's terminal, and obtaining from the user's terminal, in response to the transmission of the first information, a submission certificate including verification items corresponding to at least one or more first items included in the first information, wherein the one or more first items may include a first list of non-fungible tokens determined to be accessible, token identifiers of each of the non-fungible tokens included in the first list, metadata, contract addresses, and a virtual space identifier that identifies the virtual space.

[0022] In yet another embodiment, the verifying the access authority may include generating verification request information by encrypting the target verification item with the public key; transmitting the verification request information to the user's terminal; obtaining, from the user's terminal, a verification input value corresponding to the target verification item decrypted with a private key corresponding to the public key as a response to the verification request information; and verifying the access authority by checking whether the verification value corresponding to the target verification item included in the identification document obtained from the blockchain network corresponds to the verification input value obtained from the user's terminal.

[0023] A method according to yet another embodiment of the present document may include receiving a request to access an area of a virtual space, the access request being generated in response to an interaction between the virtual space and a user based on user input; acquiring conditions for granting access authority through the access request; acquiring non-fungible token information regarding a non-fungible token owned by the user through the access request; and permitting the user to access the area of the virtual space by confirming that the user owns the non-fungible token and that the non-fungible token information satisfies the conditions for granting access authority.

[0024] In yet another embodiment, the method may further include the steps of: obtaining a first authentication token from a first external device associated with authentication of the non-fungible token platform based on user information for the user; requesting the non-fungible token information from a second external device associated with a resource of the non-fungible token platform using the first authentication token; and obtaining the non-fungible token information from the second external device.

[0025] In yet another embodiment, the interaction with the virtual space may include an object manipulated by the user input on a platform that provides the virtual space reaching the area of the virtual space.

[0026] In yet another embodiment, the set of conditions may include two or more of the following: For example, the set of conditions may include at least some of a non-fungible token value condition, a non-fungible token identifier condition, a non-fungible token type condition, a non-fungible token trading system condition, a non-fungible token classification condition, and a non-fungible token smart contract condition.

[0027] In yet another embodiment, the access privilege may allow a device operated by the user to access one or more services associated with the region.

[0028] In yet another embodiment, the granting of access authority may include verifying that the non-fungible token is in the user's possession.

[0029] In yet another embodiment, the non-fungible tokens may be generated by a smart contract.

[0030] In yet another embodiment, the user's ownership of the non-fungible token may be recorded on a blockchain, and granting access authorization may include determining via the blockchain that the non-fungible token is owned by the user.

[0031] In yet another embodiment, the virtual space includes a three-dimensional model, and granting access rights to the area of the virtual space may enable access to services provided through the platform providing the virtual space via a user interface of the virtual space.

[0032] Effect of the invention According to the disclosure in this document, non-fungible tokens can be used as tickets to enter spaces.

[0033] The disclosures in this document make it possible to prove ownership of non-fungible tokens.

[0034] The contents disclosed in this document can improve the convenience for users when proving ownership of non-fungible tokens.

[0035] The disclosures in this document allow users to have control over the validation procedures associated with their ownership of non-fungible tokens (e.g., allowing users to control what token information is made public).

[0036] According to the disclosure in this document, when proving possession of non-fungible tokens sufficient to grant access rights to a space, users can protect their personal information by choosing the information they disclose.

[0037] The effects of the technical ideas disclosed in this document are not limited to (nor should they necessarily be included in) the effects mentioned above, and other effects not mentioned will be clearly understood by those skilled in the art from the description of this document. [Brief explanation of the drawings]

[0038] [Figure 1] FIG. 1 illustrates an environment in which an apparatus according to one embodiment disclosed herein can be applied. [Figure 2]FIG. 2 illustrates a computing device capable of implementing an apparatus according to one embodiment disclosed herein. [Figure 3] FIG. 3 shows an example of a space that may be referenced in various embodiments disclosed herein. [Figure 4] FIG. 4 shows another example of a space that may be referenced in various embodiments disclosed herein. [Figure 5] FIG. 5 illustrates an example of a non-fungible token that may be referenced in various embodiments disclosed herein. [Figure 6] FIG. 6 is a flowchart illustrating a method according to another embodiment disclosed herein. [Figure 7] FIG. 7 is a flowchart showing the detailed operation of the response transmission operation described with reference to FIG. [Figure 8] FIG. 8 is a flowchart illustrating a method according to yet another embodiment disclosed herein. [Figure 9] FIG. 9 is a flowchart illustrating a method according to yet another embodiment disclosed herein. [Figure 10] FIG. 10 is a flowchart showing the detailed operation of obtaining the list of non-fungible tokens described with reference to FIG. [Figure 11] FIG. 11 is a flowchart illustrating a method according to yet another embodiment disclosed herein. [Figure 12] FIG. 12 illustrates certificates and submission certificates that may be referenced in various embodiments disclosed herein. [Figure 13] FIG. 13 is a flowchart illustrating a method according to yet another embodiment disclosed herein. [Figure 14] FIG. 14 is a flowchart illustrating a method according to yet another embodiment disclosed herein. DETAILED DESCRIPTION OF THE INVENTION

[0039] MODE FOR CARRYING OUT THE INVENTION The following detailed description is provided to help the reader gain a comprehensive understanding of the methods, devices, and / or systems described herein. However, various changes, modifications, and equivalents to the methods, devices, and / or systems described herein will become apparent upon understanding the disclosure of this application. For example, the order of operations described herein is exemplary only and is not limited to those explicitly described; except for operations that must be performed in a specific order, the order of operations may be changed upon understanding the disclosure of this application. Also, descriptions of features that are well known to those skilled in the art may be omitted for clarity and conciseness.

[0040] The features described herein may be embodied in various forms and should not be construed as being limited to the examples set forth herein. Rather, the examples set forth herein are provided to facilitate understanding of the disclosure of this application and to illustrate some of the many possible ways in which the methods, devices, and / or systems described herein may be implemented.

[0041] The terms used herein are merely for the purpose of describing various examples and should not be used to limit the disclosure. The terms "a," "an," and "said" are intended to include the plural unless the context clearly dictates otherwise. The term "and / or" used herein includes one and / or more of the associated listed items. As a non-limiting example, plural expressions (e.g., "comprise" and "comprises," "include" and "includes," and "has" and "have") specify the presence of stated features, numbers, operations, members, elements, and / or combinations thereof, but do not exclude the presence or addition of one or more other features, numbers, operations, members, elements, and / or combinations thereof.

[0042] Throughout this specification, when a component or element is described as being "connected," "coupled," or "coupled" to another component or element, this may be directly "connected," "coupled," or "coupled" to the other component or element, or may be reasonably separated by one or more additional components or elements. When a component or element is described as being "directly connected," "directly coupled," or "directly coupled" to another component or element, there are no additional intervening elements. Similarly, expressions such as "between," "immediately between," "adjacent," and "immediately adjacent" may be interpreted as described above.

[0043] Terms such as "first," "second," and "third," or A, B, (a), (b), etc., may be used herein to describe various members, components, regions, strata, or sections, but such members, components, regions, strata, or sections are not limited by these terms. Each such term is not used, for example, to define the nature, order, or sequence of the member, component, region, strata, or section in question, but is used only to distinguish the member, component, region, strata, or section from other members, components, regions, strata, or sections. Thus, a first member, component, region, strata, or section referred to in an example described herein could also refer to a second member, component, region, strata, or section without departing from the teachings of the example.

[0044] Unless otherwise specified, terms used in this document, including technical or scientific terms, may have meanings commonly understood by those of ordinary skill in the art to which the disclosed subject matter belongs, based on the understanding of the disclosure of this application. Terms defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and the disclosure of this application, and should not be interpreted in an idealized or overly formal sense unless expressly defined herein. In this specification, the term "may" in connection with examples or embodiments means, for example, that an example or embodiment can include or embody such a feature, but not all examples are limited thereto.

[0045] The term "space" as used herein may refer to a physically or abstractly widespread area. In one embodiment, space may refer to a real space, which is a physically widespread area. In another embodiment, space may refer to a virtual space that abstractly embodies interactions in a real space.

[0046] The term "non-fungible token (NFT)" as used in this document may refer to a collection of electronic information that assigns unique recognition value to a digital asset based on blockchain technology. Specifically, non-fungible tokens may be generated by a smart contract created with reference to certain protocols (e.g., ERC-721 or ERC-1155). The integrity of information (e.g., ownership) related to this non-fungible token may be maintained by recording it on a blockchain, which is a distributed storage system. When this non-fungible token is generated to include a specific type (or fragment) of data, the existence of the specific type (or fragment) of data can be guaranteed.

[0047] Specifically, a non-fungible token may be a collection of information including various pieces of information. In one embodiment, a non-fungible token may include at least one of information for accessing a digital asset associated with the token (e.g., a digital asset uniform resource identifier (URI)) or information for accessing metadata for the token (e.g., a metadata URI). In other embodiments, a non-fungible token may further include metadata for the token. A digital asset URI associated with a non-fungible token may be the address of a centralized server or cloud server on which the digital asset is stored. Alternatively, the digital asset URI may be the content identifier (CID) of a digital asset stored on a distributed file system (e.g., the InterPlanetary File System (IPFS)) that distributes files across multiple systems, i.e., a hash value (e.g., "ipfs.io / ipfs / 12345678"). A metadata URI of a non-fungible token may be the address of a centralized server or cloud server on which metadata for the token is stored. Alternatively, it may be the hash value of the metadata stored on IPFS.

[0048] In one embodiment, the metadata of a non-fungible token may refer to a collection of information including various pieces of information about the token. The metadata may include, for example, at least one of the following: the contract address of the token; the token's identification information (hereinafter also referred to as "ID" or "token identifier"); the type of blockchain on which the token is recorded; and the time of creation of the token or the change history of the token's owner. Hereinafter, expressions such as "information included in the non-fungible token" may be understood as "information included in (or recorded in) the metadata of the non-fungible token," and the information may not be included in the non-fungible token itself, but may be included in a location pointed to by the non-fungible token.

[0049] The term "digital asset" as used in this document may refer to any information that can be expressed in binary form and used as an asset. A digital asset may be a representation or identifier of a physical asset, such as a bag, jewelry, furniture, vehicle, building, real estate, game item, or digital card. The authenticity of such a digital asset may be assured by a non-fungible token that corresponds to the digital asset.

[0050] As used herein, the term "platform" may refer to an environment that serves as a user's base of operations by integrating and managing services with the same or similar purposes. This environment may be provided to users by software (e.g., a computer program or application) running on hardware (e.g., a server, client, input device, output device, or network device). While the exact meaning may differ, the term "platform" may be used interchangeably with "software," "application," or "solution." In one embodiment, the platform may expose an application programming interface (API) (e.g., a network API for network services) that can be used by external clients. In one embodiment, a space platform may be an environment that integrates various space-related services. For example, a space platform may provide users with community services, game services, e-commerce services, video conferencing services, music listening services, or advertising services. In another embodiment, a non-fungible token platform may be an environment that integrates various services related to the issuance and management of non-fungible tokens. For example, a non-fungible token platform may provide users with services related to trading non-fungible tokens or community services based on non-fungible tokens.

[0051] Hereinafter, various embodiments described in this document will be described with reference to the accompanying drawings. In the accompanying drawings and descriptions relating to the drawings, identical or substantially equivalent components may be given the same reference numerals. In addition, in the following descriptions of various embodiments, duplicate descriptions of identical or corresponding components may be omitted, but this does not mean that the components are not included in the embodiments.

[0052] FIG. 1 illustrates an environment in which an apparatus according to an embodiment of the present disclosure can be implemented. The environment may include a verification device 110, a user terminal 120, or an external device 130. Each of the devices 110, 120, and 130 applicable to the environment can interact with a particular block of a blockchain 140 through a network. In other words, each of the devices 110, 120, and 130 illustrated in FIG. 1 is a component of a computer network including a blockchain network and can query a particular block of the blockchain 140. While the term "device" is used herein, the device in FIG. 1 is not necessarily limited to a physical device itself. For example, the verification device 110 may actually be a cloud service supported by many cooperating physical devices. While the term "device" is used for simplicity and explanation, the term also encompasses entities that are not strictly individual devices but have similar functionality.

[0053] While Fig. 1 illustrates an example in which one user terminal 120 and the verification device 110 interact with each other, this is merely for ease of understanding, and the number of user terminals 120 may vary. That is, the verification device 110 may interact with one or more user terminals to process the access of one or more users to the space. Also, Fig. 1 illustrates only a preferred embodiment for achieving the objectives of the present disclosure, and some components may be added or omitted as necessary.

[0054] Each of the components shown in FIG. 1 will now be described in more detail.

[0055] The verification device 110 may be a server device of the spatial platform. That is, the verification device 110 may be a server device managed by an operating entity that manages the spatial platform. The verification device 110 may be part of the infrastructure that provides the spatial platform. For example, the verification device 110 may have an internal network address in the private network of the spatial platform and may communicate with the user terminal 120 through, for example, a gateway (or the like) of the spatial platform.

[0056] The verification device 110 may process a user's request to access a space, which is one example of various services provided to users on the space platform. In one embodiment, the verification device 110 may verify whether the user has access to a specific space (i.e., access authority) by determining whether the user owns a specific non-fungible token determined to correspond to the specific space. In another embodiment, the verification device 110 may verify the access authority by interacting with other devices 120 and 130 shown in FIG. 1 or by referring to information recorded in a specific block of the blockchain 140. To avoid redundant description, specific operations performed by the verification device 110 to verify the user's access authority to a space will be described later with reference to FIG. 6 and subsequent drawings.

[0057] The verification device 110 may be implemented in one or more computing devices. For example, all functions of the verification device 110 may be implemented in a single computing device. For another example, a first function of the verification device 110 may be implemented in a first computing device, and a second function distinct from the first function may be implemented in a second computing device distinct from the first computing device. For example, the computing device may be, but is not limited to, a desktop computer, a laptop computer, an application server, a proxy server, a virtual machine, or a cloud server, and any type of device equipped with computing functionality may be included in the computing device.

[0058] The user terminal 120 may be a terminal of a user that uses the spatial platform or the non-fungible token platform. In this document, the term user terminal 120 may be used interchangeably with "user terminal." In one embodiment, the user terminal 120 may be installed with a web browser or an application that enables the user to use the spatial platform or the non-fungible token platform. The user terminal 120 may be, for example, any one of devices such as a desktop computer, laptop computer, tablet computer, wearable device, kiosk, or smartphone, but is not limited to these examples, and any type of device equipped with computing functionality may be included in the computing device.

[0059] In one embodiment, the user terminal 120 may be a terminal of a user that generates a submission certificate that can be referenced in a distributed identity authentication (DID Auth) technology. To avoid redundant explanations, various embodiments of the distributed identity authentication technology will be described later with reference to Figures 12 to 14.

[0060] The external device 130 may be a server device of a non-fungible token platform. That is, the external device 130 may be understood as a server device operated under the management of the operator of the non-fungible token platform. In one embodiment, the entity of the verification device 110 and the entity of the external device 130 may have a contractual or business relationship (e.g., subsidiary, mother company, affiliated company, holding company, affiliated company, etc.) for the utilization of non-fungible tokens or the operation of the space platform. Due to this relationship, the verification device 110 and the external device 130 may share resources managed by their respective devices upon the fulfillment of certain conditions (e.g., a user request, etc.).

[0061] The external device 130 may assist in processing of the user's spatial access performed on the spatial platform. In one embodiment, the external device 130 may transmit a list of non-fungible tokens owned by the user to the verification device 110 upon fulfillment of a specific condition (e.g., a user request). In this case, the list of non-fungible tokens owned by the user may be managed by the non-fungible token platform.

[0062] A first external device 131 included in the external device 130 can process a series of operations related to authentication of the non-fungible token platform. Based on the processing of the first external device 131, a second external device 132 included in the external device 130 can process a series of operations related to resources of the non-fungible token platform. To avoid redundant description, specific operations in which the external device 130 interacts with the verification device 110 and the verification device 110 verifies whether a user can access a space will be described later with reference to FIGS. 9 to 11.

[0063] The first external device 131 and the second external device 132 may be implemented as different logic units (e.g., software servers) in a single computing device. Alternatively, each of the first external device 131 and the second external device 132 may be implemented as one or more computing devices. For example, the computing device may be, but is not limited to, a desktop, a laptop, an application server, a proxy server, or a cloud server, and any type of device equipped with computing functionality may be included in the computing device.

[0064] The verification device 110, the user terminal 120, or the external device 130 shown in Fig. 1 can communicate through a network. The network can be implemented by any type of wired or wireless network, such as a local area network (LAN), a wide area network (WAN), a mobile radio communication network (MRCN), wireless broadband (WiBro), a cellular network, the Internet, etc.

[0065] 2 illustrates a computing device 200 capable of implementing an apparatus according to an embodiment of the present disclosure. In the present disclosure, the computing device 200 may be used interchangeably with electronic devices. The verification device 110, the user terminal 120, or the external device 130 described above with reference to FIG. 1 may be implemented by the computing device 200.

[0066] Computing device 200 may include one or more processors 210, one or more memories 220, a communication interface 230, an output unit 240, or an input unit 250. In an embodiment, some components may be omitted from computing device 200, or other components may be added to computing device 200. Additionally, or alternatively, some components may be integrated or embodied as one or more individual components. In this disclosure, one or more processors 210 may be referred to as processor 210. The term processor 210 may refer to a collection of one or more processors, unless otherwise clearly indicated in the context. In this disclosure, one or more memories 220 may be referred to as memory 220. The term memory 220 may refer to a collection of one or more memories, unless otherwise clearly indicated in the context.

[0067] The processor 210 may perform calculations and information processing related to control or communication with each component of the computing device 200. Specifically, the processor 210 may run software / instructions (or computer programs) received from other components and control at least one component of the computing device 200 connected to the processor 210. For example, the processor 210 may load instructions (e.g., instructions, code, or code segments) or information into the memory 220, process the instructions or information stored in the memory 220, and store the resulting information from the processing in the memory 220. The processor 210 may also be connected to the components of the computing device 200 and perform various calculations, processing, generation, processing, and other operations related to the present disclosure.

[0068] The memory 220 may store various information. The information stored in the memory 220 is information that is acquired, processed, or used by at least one component of the computing device 200 and may include software in the form of instructions executable by the processor 210. The software may include one or more instructions that, when loaded into the memory 220, cause the processor 210 to perform operations according to various embodiments of the present disclosure. That is, the processor 210 may perform operations according to various embodiments of the present disclosure by executing one or more of the instructions. The memory 220 may include, for example, volatile or non-volatile memory. In one embodiment, the program is software / instructions stored in the memory 220 and may include an operating system for controlling the resources of the computing device 200, an application, or middleware that provides various functions to applications so that the applications can utilize the resources of the computing device 200.

[0069] The communication interface 230 can establish a wired or wireless communication channel with other devices and transmit and receive various information to and from other devices. In one embodiment, the communication interface 230 may include at least one port for connecting to another device via a wired cable to communicate with the other device via a wired cable. In this case, the communication interface 230 can communicate with the other device via the at least one port. In one embodiment, the communication interface 230 may include a cellular communication module and be configured to connect 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 and be able to transmit and receive information to and from other devices using short-range communication (e.g., Wi-Fi, Bluetooth, Bluetooth Low Energy (BLE), or 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 near field communication (NFC), radio frequency identification (RFID), or magnetic secure transmission (MST). In addition to the various examples described above, the computing device 200 may be embodied in various known ways for communicating with other devices, and the scope of the present disclosure is not limited to the examples described above.

[0070] The output unit 240 can output the results of the computing device 200 to the outside. The output unit 240 may include, for example, a display, a speaker, a printer, a plotter, etc.

[0071] In one embodiment, the computing device 200 may include a display. The display may display various screens under the control of the processor 210. For example, the display may display screens to which various interfaces (e.g., GUIs, etc.) of the spatial platform or the non-fungible token platform are applied under the control of the processor 210. To display screens to which various interfaces are applied on the display, for example, a web browser or a dedicated application may be installed in the computing device 200. The display may also be configured to be able to interact with a user and to receive user input from the user. Such a display may be implemented in the form of a touch sensor panel (TSP) that can recognize contact or proximity of various external objects (e.g., a user's finger, an electronic pen, or a stylus). The display may also display various content (e.g., text, images, videos, icons, symbols, etc.) to be provided to the user.

[0072] The input unit 250 can acquire information used by components of the computing device 200 from outside the computing device 200. The input unit 250 may include, for example, a mouse, a joystick, a keyboard, a steering wheel, hardware buttons, etc. Furthermore, the external input that the input unit 250 can acquire may include, for example, touch using a part of the user's body, a user's gesture, proximity or hovering input of a part of the user's body, etc.

[0073] The processor 210, memory 220, communication interface 230, output unit 240, or input unit 250 shown in FIG. 2 are connected to each other via a bus, a GPIO (General Purpose Input / Output), an SPI (Serial Peripheral Interface), or an MIPI (Mobile Industry Processor Interface), and can exchange information or signals.

[0074] The following describes the spaces and non-fungible tokens that can be referenced in various embodiments disclosed in this document. Figures 3 and 4 show the spaces that can be referenced in various embodiments disclosed in this document.

[0075] 3 and 4 may be a type of virtual space that can be provided to the user terminal 120. For example, the virtual space may be virtual reality (VR) or augmented reality (AR). The screen of the virtual space may include a user interface and may be displayed on the display of the user terminal 120. The user interface may include a rendering of the virtual space. The user interface of the virtual space may provide the user terminal 120 with an output associated with a user input received from an input device of the user terminal 120.

[0076] In connection with displaying the spaces 310, 410, for example, the verification device 110 may transmit to the user terminal 120 a link (e.g., a URL or a URI) that enables the spaces 310, 410 to be displayed on the display of the user terminal 120. The user terminal 120 may connect to the link to display the spaces 310, 410 on the display of the user terminal 120. In one embodiment, the process of displaying the link on the user terminal 120 may be omitted. In one embodiment, the verification device 110 may store the link corresponding to the space in memory in advance.

[0077] In connection with the configuration of the spaces 310, 410, in one embodiment, the size of the spaces 310, 410, the components included in the spaces 310, 410 (e.g., interactive objects such as non-player characters (NPCs), furniture, etc.), or the set of services provided in the spaces 310, 410 may be configured according to the management intentions of the space platform operator. According to one embodiment, the set of services provided in the spaces 310, 410 may refer to a collection of various services including, for example, community services, game services, e-commerce services, video conferencing services, music listening services, and advertising services. Such services may be invoked when a user interacts with the space. In some spaces, the available services may vary depending on the part of the space where an avatar is located.

[0078] In connection with the configuration of the spaces 310, 410, in other embodiments, the size of the spaces 310, 410, the components included in the spaces 310, 410, or the set of services provided in the spaces 310, 410 may be customized by the user's intention in the space platform. By configuring the spaces 310, 410 as described above, an interface related to the spaces 310, 410 and the configuration of the spaces 310, 410 may be provided to the user terminal 120. For example, referring to FIG. 3 , by configuring the space 310 to provide a video conferencing service, an interface 330 related to the video conferencing service may be displayed on the display of the user terminal 120 along with the space 310. In some implementations, access to the service may be based on the user's access to a specific portion or area of the space, and such access may be regulated using a non-fungible token. As another example, referring to FIG. 4, when a community service is configured to be provided in space 410, an interface 430 related to that community service may be displayed on the display of user terminal 120 along with space 410.

[0079] Spaces 310 and 410 may include one or more areas. For example, referring to FIG. 4, space 410 may include multiple areas including a first area 441 and a second area 442. In one embodiment, the first area 441 and the second area 442, which are distinct from one another, may be accessible based on access authority (e.g., area access authority) for the distinct areas. For example, a first user with first area access authority may be able to access first area 441, while a first user without second area access authority may be unable to access second area 442. Furthermore, a second user with second area access authority may be able to access second area 442, but may be unable to access first area 441.

[0080] The spaces 310 and 410 may include objects 320, 421, and 422 corresponding to the user. The objects 320, 421, and 422 corresponding to the user may be a type of PC (Player Character) and may refer to objects that the user can play or control. The spaces 310 and 410 may also include interactive objects. The interactive objects may refer to a type of NPC (e.g., an object that acts autonomously) and may refer to objects that the user cannot play or control but can interact with the objects 320, 421, and 422 corresponding to the user in the virtual space.

[0081] The spaces 310 and 410 may be configured to allow objects 320, 421, and 422 corresponding to the user to move. That is, the objects 320, 421, and 422 corresponding to the user may move within the spaces 310 and 410 according to the user's intention, and the movement of the objects 320, 421, and 422 may be displayed on the display of the user terminal 120. In this case, the user's intention may refer to an input via an input device such as a touch panel, a mouse, a keyboard, or a video gesture recognition system of the user terminal 120.

[0082] Regarding the movement of objects 320, 421, and 422, in one embodiment, the movement of objects 320, 421, and 422 may be permitted or prohibited depending on the area access authority. For example, it is assumed that a first user with first area access authority is permitted to access first area 441 but is prohibited from accessing second area 442. In this case, a first object corresponding to the first user may be permitted to approach and move within first area 441 but may not be permitted to approach and move within second area 442. It is also assumed that a second user with second area access authority is permitted to approach second area 442 but is prohibited from approaching first area 441. In this case, a second object corresponding to the second user may be permitted to approach and move within second area 442 but may not be permitted to approach and move within first area 441.

[0083] In one embodiment, with respect to the service sets of the areas included in the spaces 310 and 410, a first service set provided to a first user approaching the first area 441 and a second service set provided to a second user approaching the second area 442 may be distinguished. For example, the first service set may include community services, while the second service set may not include community services. As another example, the first service set may include a first interactive object configured to be able to interact with the objects 320, 421, and 422, while the second service set may include a second interactive object distinct from the first interactive object. In other words, the service sets provided in each area may differ from each other.

[0084] The operator of a spatial platform may provide premium services in a specific area, including a set of services preferred by a user. In one embodiment, to use the premium services, a user must meet the terms and conditions of use for the premium services. The terms and conditions may involve obtaining area access privileges that allow access to the specific area. For example, to access a specific area where premium services are provided, area access privileges may be obtained by proving possession of a certain number of non-fungible tokens or a certain value of non-fungible tokens. Attributes of the non-fungible tokens or information (e.g., metadata) indicated by the token may be used to determine whether to grant access privileges to the specific area.

[0085] In connection with a request to access a specific area, in one embodiment, when an object 421 or 422 corresponding to a user is located at a specific point 450 included in the space 410, a series of verification procedures for area access authority may be initiated. This verification procedure may be automatically initiated based on a determination that one of the objects moving on the spatial platform has reached or intersected with the specific space. In this case, the specific point 450 may be, for example, an entrance to the specific space, a passageway, a door, a switch, or a location where an object is located, or the periphery of the specific space. In another embodiment, when the object 421 or 422 corresponding to the user performs a specific action within the space 410, a series of verification procedures for area access authority may be initiated. Here, the specific action is an action of the object 421 or 422 corresponding to the user that is preset in response to a user input acquired through an input device of the user terminal 120, such as an action of displaying a specific message or an action of performing a specific movement.

[0086] FIG. 5 illustrates a non-fungible token 500 that may be referenced in various embodiments disclosed herein. The non-fungible token 500 illustrated in FIG. 5 may be a screen displaying an interface that can be displayed on the display of a user terminal 120. Such a non-fungible token 500 may be generated based at least in part on a collection of information recorded in blocks. That is, the non-fungible token 500 may be in a form that can be recognized through a screen displayed on the user terminal 120 of a user connected to a spatial platform or a non-fungible token platform. As illustrated in FIG. 5, the non-fungible token 500 may include digital assets 510 and metadata 520. The digital assets 510 or metadata 520 of the non-fungible token 500 may be referenced as an operation for determining ownership of the non-fungible token 500 in various embodiments described below. The non-fungible token may be structured or configured to comply with various standards that specify attributes of non-fungible tokens. For example, the non-fungible token 500 may comply with the ERC-721 standard or the ERC-1155 standard.

[0087] The steps of the methods described with reference to the following drawings may be performed by a computing device. In other words, the steps of the methods may be embodied by one or more instructions executed by a processor of the computing device. All steps included in such a method may be performed by a single physical computing device, but a first step of the method may be performed by a first computing device and a second step of the method may be performed by a second computing device. Hereinafter, unless otherwise specified in the context, the steps of the above-described methods will be described as being performed by the verification device 110 shown in FIG. 1 . However, for convenience of explanation, the description of the actors of the steps included in the methods may be omitted.

[0088] 6 is a flowchart illustrating a method according to an embodiment of the present disclosure. The method illustrated in FIG. 6 involves a series of operations starting from an operation of receiving an access request from a user requesting access to a virtual space (S610) to an operation of transmitting a response corresponding to the access request to the user terminal 120 (S640). Through the series of operations illustrated in FIG. 6, a non-fungible token may be used as a kind of admission ticket that verifies access authority to the virtual space (or a specific portion or space of the virtual space).

[0089] A processor connected to a computer network including a blockchain network may receive an access request from a user's terminal requesting access to at least a portion of a virtual space consisting of a plurality of areas (S610). According to one embodiment, the access request may be an information message including information requesting access to the virtual space.

[0090] Specifically, the verification device 110 may receive an access request from the user terminal 120 in various ways. For example, when a user selects a specific button displayed on the user terminal 120 connected to the spatial platform, the verification device 110 may receive an access request for a specific virtual space associated with the specific button. As another example, when a user's object displayed on the user terminal 120 connected to the spatial platform is located at a specific point in a first virtual space, the verification device 110 may receive an access request for a second virtual space determined to correspond to the specific point. In some examples described below, the access request may be generated by the spatial platform. Alternatively, the access request may be received from the spatial platform, and may be issued in response to an interaction between the spatial platform and the user through the user terminal 120 (e.g., in response to the user manipulating an object or avatar to a point that triggers confirmation of access authority).

[0091] If the virtual space includes a plurality of regions, in one embodiment, the operation of acquiring an access request (S610) may include an operation of acquiring a region access request requesting access to at least some of the regions. According to another embodiment, the region access request may be an information message including information requesting access to at least some of the regions included in the virtual space. Since the access request and the region access request differ only in the target of the access request, all technical ideas related to the operation of acquiring an access request (S610) and all technical ideas related to the operation of acquiring a region access request may be mutually applicable.

[0092] In relation to the operation of acquiring an area access request (S610), in one embodiment, the operation of acquiring an area access request (S610) may include an operation of acquiring an area access request when an object corresponding to the user is located at a specific point included in the virtual space. A detailed description of this embodiment can be understood by referring to the description of FIGS. 3 and 4.

[0093] A processor connected to a computer network including a blockchain network may acquire first information about a non-fungible token that has been determined to allow the user (or an object corresponding to the user) access to at least a portion of the area based on the access request (S620). This first information about the non-fungible token may be a type of access rule for the virtual space and may be information that is compared with second information about the non-fungible token owned by the user, which will be described later. In other words, the first information may specify conditions that must be satisfied by the requesting user's non-fungible token, and the second information may be information about the user's non-fungible token, which may be compared with the first information to determine whether the second information satisfies the first information (e.g., a rule, Boolean expression, etc.).

[0094] Specifically, the verification device 110 may predetermine the first information to correspond to the virtual space and store it in memory. Furthermore, when an access request is received from the user terminal 120, the verification device 110 may identify the virtual space corresponding to the access request. Furthermore, the verification device 110 may obtain the first information corresponding to the virtual space from memory based on a predetermine association with the virtual space. The access request may include an identifier for the virtual space and / or a part thereof or the space (or such an identifier may be part of a multi-part transaction and be associated with the access request). As described below, the first information may include other information other than information related to the non-fungible token, for example, information related to the virtual space associated with the non-fungible token. In this document, the term "approach of a user" may be used interchangeably with the term "approach of an object corresponding to a user" unless otherwise specified in the context.

[0095] In relation to the first information, in one embodiment, the first information may include one or more verification items (hereinafter referred to as "first items") for determining whether a user can access a virtual space and one or more values corresponding to the verification items. In one embodiment, the one or more verification items may include items related to a list of non-fungible tokens (hereinafter referred to as "first list"). The items related to the list may include one or more items related to one or more non-fungible tokens included in the list. For example, the one or more items may include a token identifier of the non-fungible token, metadata of the non-fungible token, a contract address of the non-fungible token, the number of non-fungible tokens, the price of the non-fungible token, a market in which the non-fungible token is traded, a wallet address of the non-fungible token, or a digital asset of the non-fungible token. In another embodiment, the one or more verification items may include items related to the virtual space. The items related to the virtual space may include one or more items related to the virtual space. For example, the one or more items may include a type of virtual space, an area of the virtual space, a set of services activated in the virtual space, a virtual space identifier for identifying the virtual space, etc. In yet another embodiment, the one or more verification items may include an item related to an event. The event-related items may include one or more items related to an event held in a virtual space. For example, the one or more items may include a type of event, a period of the event, or an organizer of the event. A specific operation of determining ownership of a non-fungible token using the first information will be described in detail in the operation of verifying access authority (S630).

[0096] If the virtual space includes a plurality of regions, in one embodiment, the operation of acquiring first information (S620) may include an operation of acquiring information as a region access rule for determining whether access to at least some of the regions is possible based on the region access request. That is, the region access rule may be understood as a rule for determining whether a user (or an object corresponding to the user) is possible to access at least some of the regions. Since the access rule (i.e., the first information) and the region access rule differ only in the object for which access is requested, all technical concepts related to the operation of acquiring first information (S620) and all technical concepts related to the operation of acquiring the region access rule may be mutually applicable.

[0097] A processor connected to a computer network including the blockchain network can verify access authority indicating whether the user is allowed to access at least a portion of the area (i.e., whether the user has authority to access at least a portion of the area of the virtual space) by determining whether the user owns a non-fungible token based on the first information (S630). Such information can be requested directly from the blockchain network or indirectly via an external device 130 that can communicate with the blockchain network.

[0098] Specifically, the verification device 110 can determine whether the user owns a non-fungible token corresponding to the virtual space to which the user has requested access by comparing the values of one or more verification items included in the first information with one or more pieces of information on the non-fungible token owned by the user (i.e., the value of the second item in the second information).

[0099] Furthermore, the verification device 110 can verify the access authority based on the result of the determination. For example, assume that the verification item included in the first information corresponding to the first virtual space is determined as an item related to a contract address, and the value of the verification item is determined as {0x77e}. In this case, if the contract address of the non-fungible token owned by the user is {0x77e}, it can be verified that the user has access authority to the first virtual space. Furthermore, if the contract address of the non-fungible token owned by the user is not {0x77e}, it can be verified that the user does not have access authority to the first virtual space. Similarly, the verification item may be a contract address list, which can function as an access control list. In this case, if the user's non-fungible token has a contract address that matches one of the contract addresses, the user may be granted authority.

[0100] As another example, assume that the verification items included in the first information corresponding to the second virtual space are determined as multiple items related to contract addresses, and the value of the verification items is determined as {0x77e;0e663}. In other words, assume that the first information is a rule for determining whether a user owns multiple non-fungible tokens with contract addresses {0x77e} and {0e663}. In this case, if the contract address of the first non-fungible token owned by the user is {0x77e} and the contract address of the second non-fungible token owned by the user is {0e663}, it can be verified that the user has access authority to the second virtual space. Furthermore, if the user does not own any of the non-fungible tokens with contract addresses {0x77e} or {0e663}, it can be verified that the user does not have access authority to the second virtual space.

[0101] As another example, assume that the verification items included in the first information corresponding to the third virtual space are determined to be items related to token identifiers and items related to prices, and the values of the verification items are determined to be {#0 to #500; 0.5 ETH or more}. In this case, if the token identifier of a non-fungible token owned by a user is a number between #0 and #500 and the price of the non-fungible token is 0.5 ETH or more, it may be verified that the user has access authority to the third virtual space. Furthermore, if the token identifier of a non-fungible token owned by a user is a number greater than #500 or the price of the non-fungible token is less than 0.5 ETH, it may be verified that the user does not have access authority to the third virtual space.

[0102] Although specific examples are not provided above for the sake of convenience, the first information can be determined to include one or more verification items and one or more values corresponding to the verification items in a manner similar to the above examples, and it can be determined whether a user owns a non-fungible token that satisfies the first information. That is, ownership of one or more non-fungible tokens having various combinations of attributes and / or attributes associated with or indicating the non-fungible tokens can be used as conditions for determining whether a user (e.g., an identity / object / avatar representing the user) is authorized to access a virtual space or its area. The authorization requirements can be formulated, for example, as any Boolean expression of the non-fungible token attributes (typically obtained from the token itself or a service such as a blockchain network or a service implementing a contract), a list of items to be verified, etc.

[0103] In relation to the operation of verifying access authority, in one embodiment, the operation of verifying access authority may include an operation of determining whether the contract address of the non-fungible token owned by the user is the value of the second item of the second information and corresponds to the contract address (value of the first item) included in the first information. In another embodiment, the operation of verifying access authority may include an operation of determining whether the user owns each of the first non-fungible token and the second non-fungible token related to the first information.

[0104] If the virtual space includes multiple areas, in one embodiment, the operation of verifying access authority (S630) may include an operation of verifying area access authority, which indicates whether the user is allowed to access at least some of the multiple areas by determining whether the user possesses a non-fungible token that satisfies the area access rule. Since the access authority and the area access authority differ only in the object of the authority, all technical ideas related to the operation of verifying access authority (S630) and all technical ideas related to the operation of verifying area access authority may be applied interchangeably.

[0105] A processor connected to a computer network including a blockchain network can transmit a response to the access request to the user's terminal based on the result of the verification of the access authority (S640). Specifically, if the user's access authority is verified, the verification device 110 can transmit a link to the virtual space to the user's terminal as a response to the access request. Also, if the user's access authority is not verified, the verification device 110 can transmit an error message to the user's terminal as a response to the access request.

[0106] In relation to the operation of transmitting a response (S640), in one embodiment, the operation of transmitting a response (S640) may include an operation of transmitting a response to the user terminal 120, in which a first service set is activated when an object corresponding to the user approaches a first area included in the virtual space, and a second service set distinct from the first service set is activated when an object corresponding to the user approaches a second area distinct from the first area. That is, the activated service set may differ depending on which area the object approaches. A detailed description of this embodiment can be understood with reference to the description of FIGS. 3 and 4.

[0107] If the virtual space includes multiple areas, in one embodiment, the operation of transmitting a response (S640) may include an operation of transmitting a response corresponding to the area access request to the user's terminal based on the result of verification of the area access authority. Here, the response corresponding to the area access request may be a link to at least some of the multiple areas or an error message. Since the response corresponding to the access request and the response corresponding to the area access request differ only in the target of the link when the authority is verified, all technical concepts related to the operation of transmitting a response corresponding to the access request (S640) and the operation of transmitting a response corresponding to the area access request may be mutually applicable.

[0108] 7 is a flowchart showing detailed operations of the response transmission operation (S640) described with reference to FIG 6. That is, the operation S700 of FIG 7 may correspond to the response transmission operation (S640) of FIG 6.

[0109] If the access authority is verified, a token identifier of the non-fungible token included in the second information may be extracted (S710), and a link to the virtual space corresponding to the token identifier may be sent to the user's device (S720). That is, if the access authority is verified, the value of the first item in the first information corresponds to the value of the second item in the second information. Therefore, in some cases, items related to the token identifier that may be included in the first information and the corresponding values may be used as allocation rules for the virtual space. Here, the allocation rule for the virtual space may be a rule that allocates a user to one of multiple subspaces when there are multiple subspaces associated with a specific virtual space to which the user has requested access. For example, it is assumed that the multiple subspaces associated with a specific virtual space include a first subspace and a second subspace distinct from the first subspace. In this case, it is assumed that the allocation rule is a rule that allocates a user to the first subspace if the token identifier is {#0 to #10} and to the second subspace if the token identifier is {#11 to #20} based on the token identifier. For example, if the token identifier of the non-fungible token held by a first user is #5, the link to the first subspace can be sent to the first user's device. If the token identifier of the non-fungible token held by a second user is #17, the link to the second subspace can be sent to the second user's device.

[0110] In one embodiment, the plurality of subspaces associated with a particular virtual space may be a plurality of regions included in the particular virtual space, while in another embodiment, the plurality of subspaces may be virtual spaces of different channels of the particular virtual space.

[0111] In relation to the allocation rule, in the above-described embodiment, items related to token identifiers that may be included in the first information and values corresponding to those items are used as allocation rules, but one or more other verification items that may be included in the first information and one or more values corresponding to those items can also be used as allocation rules.

[0112] 8 is a flowchart showing a method according to another embodiment of the present disclosure. The method shown in FIG. 8 relates to a series of operations starting from an operation of receiving a re-approach request from a user requesting re-approach to the virtual space (S810) and ending with an operation of transmitting a response corresponding to the re-approach request to the user terminal 120 (S860). The re-approach process to the virtual space may be performed through the series of operations shown in FIG. 8.

[0113] A reapproach request requesting reapproach to the virtual space may be received from the user's device (S810). For example, as described above, another device may issue a reapproach request in connection with the approach request. The only difference between an approach request and a reapproach request is whether the request is the first or not. Therefore, this operation can be understood by referring to the description of the operation of receiving an approach request (S610) in FIG. 6.

[0114] The difference between the time of verification of the approach authority corresponding to the approach request and the time of the re-approach request may be calculated (S820). Specifically, the verification device 110 may record the processing time of the operation to be performed. For example, the verification time of the approach authority may be obtained by recording the processing time of the approach authority verification operation (S630) of FIG. 6. As another example, the time of the re-approach request may be obtained by recording the processing time of the re-approach request acquisition operation (S810). Furthermore, the verification device 110 may arithmetically subtract the time of verification of the approach authority from the time of the re-approach request. As a result of this subtraction, the period from the time when the verification of the approach authority is completed to the time when the re-approach request is acquired may be calculated. However, since this difference calculation operation (S820) is an operation for determining whether or not verification of the re-approach authority is necessary in subsequent operations, any number of variations on the operation can be applied to this embodiment, such as calculating the difference between the time of the approach request and the time of the re-approach request, calculating the difference between the time of obtaining the first information and the time of the re-approach request, calculating the difference between the time of sending the response and the time of the re-approach request, or calculating the difference between the time the user leaves the virtual space and the time of the re-approach request.

[0115] Whether or not verification of re-approach authority, which indicates whether or not the user is allowed to re-approach the virtual space, is necessary may be determined based on whether or not the difference is within a reference period (S830). Specifically, if the difference is within a reference period, the verification device 110 may determine that verification of re-approach authority is unnecessary.

[0116] If verification of the re-approach authority is required (S840), a verification procedure may be performed (S850), and a response corresponding to the re-approach request may be transmitted to the user's terminal through the verification procedure (S860). Alternatively, if verification of the re-approach authority is not required (S840), a response corresponding to the re-approach request may be transmitted to the user's terminal (S860). Otherwise, the processing of the re-approach request may generally be the same as the processing of the initial approach request, as described above with reference to FIG. 6.

[0117] 9 is a flowchart illustrating a method according to another embodiment of the present disclosure. The method illustrated in FIG. 9 involves a series of operations starting from an operation of receiving an access request from a user requesting access to a virtual space (S910) to an operation of transmitting a response corresponding to the access request to the user terminal 120 (S950). In particular, in the method illustrated in FIG. 9, the verification device 110 can interact with an external device 130 related to a non-fungible token platform. Through the series of operations illustrated in FIG. 9, a non-fungible token may be used as a kind of admission ticket to verify access authority to a virtual space.

[0118] An access request for requesting access to the virtual space may be received from the user's device (S910). This operation may be understood to be the same as the operation of receiving the access request (S610) of Figure 6. In some implementations, the access request may be initiated by another device, such as a server device, intermediary, or proxy that provides the virtual space platform.

[0119] Based on the access request, first information about the non-fungible token that is determined to allow the user to access the virtual space may be acquired (S920). That is, the first information may be configured to be inspected to confirm whether the user has the authority to access the virtual space (or its area). This operation may be understood to be the same as the operation of acquiring first information (S620) of FIG. 6.

[0120] Second information on the non-fungible token owned by the user may be acquired from an external device 130 related to the non-fungible token platform (S930). This second information on the non-fungible token is information on the non-fungible token owned by the user, and may include an item (i.e., a second item) corresponding to the first item included in the first information and the value of that item.

[0121] Specifically, the verification device 110 can transmit a request for the second information to the external device 130, and the external device 130 can transmit the second information for the non-fungible token owned by the user in response to the request.

[0122] The access authority may be verified by determining whether the user owns a non-fungible token corresponding to the virtual space based on the first information and the second information (S940). This operation may be understood to be similar to the operation of verifying the access authority (S630) of Fig. 6, since it differs from the operation of verifying the access authority (S630) of Fig. 6 only in that the second information acquired from the external device 130 is used.

[0123] Based on the result of the access authority verification, a response corresponding to the access request may be sent to the user's terminal (S950). This operation may be understood to be the same as the operation of sending a response (S640) of FIG.

[0124] FIG. 10 is a flowchart showing the detailed operation of the second information acquisition operation (S930) described with reference to FIG. 9. The method shown in FIG. 10 is a method of interaction between the verification device 110 and the first external device 131 and the second external device 132 included in the external device 130, and can be understood with reference to, for example, technology related to the OAuth 2.0 protocol. The OAuth 2.0 protocol defines a method in which an authority server delegates access authority for resources provided by a resource server to a client server. Here, the client server may be an entity that sends a request for an authorization code to the authority server to use the user's resources. The authority server may also be a server that performs authentication or authorization and verifies the credentials of the client server and issues an authentication token (e.g., an access token). The resource server may also be an entity that stores user information (i.e., resources).

[0125] In this document, the client server may be the verification device 110, the authority server may be the first external device 131, and the resource server may be the second external device 132.

[0126] The user terminal 120 may transmit an access request to the verification device 110 (S1010). This operation may be understood to be the same as the operation of obtaining the access request (S610) of FIG.

[0127] The verification device 110 may transmit a request for an authorization authorization code to the first external device 131 involved in authentication of the non-fungible token platform (S1020). Here, the authorization authorization code may be a code used when the verification device 110 requests access to a specific resource (e.g., second information) on behalf of the user terminal 120.

[0128] The user terminal 120 may display a login screen on the display (S1030). Specifically, when a request for an authorization approval code is sent to the first external device 131, the login screen may be displayed on the display of the user terminal 120 as a space platform screen provided by the verification device 110 to the user terminal 120. Here, the login screen may refer to a login screen of a non-fungible token platform associated with the first external device 131.

[0129] The user terminal 120 may transmit user information to the first external device 131 (S1040). Here, the user information may refer to the user ID and password corresponding to the ID entered in response to the login screen. That is, the user information may be transmitted directly to the first external device 131 without going through the verification device 110.

[0130] The first external device 131 can transmit the authorization approval code to the verification device 110 (S1050). Specifically, the first external device 131 can determine whether to transmit the authorization approval code to the verification device 110 by checking the user information transmitted from the user terminal 120. For example, if the user information is legitimate, the first external device 131 transmits the authorization approval code to the verification device 110, and if the user information is illegal, the first external device 131 does not need to transmit the authorization approval code to the verification device 110.

[0131] The verification device 110 may send a request for a first authentication token to the first external device 131 using the authorization approval code (S1060), and the first external device 131 may send the first authentication token to the verification device 110 (S1070). Here, the first authentication token, i.e., Access Token, may refer to a token used when obtaining information from the second external device 132 related to resources of the non-fungible token platform. That is, the authorization approval code may be exchanged for the first authentication token via an API provided by the first external device 131 and sent to the verification device 110.

[0132] The verification device 110 can use the first authentication token to send a request for second information to the second external device 132 (S1080), and the second external device 132 can send the second information to the verification device 110 by authenticating the first authentication token (e.g., through another token authority) (S1090).

[0133] According to the method shown in FIG. 10, a user can delegate access authority to resources (eg, second information) of the non-fungible token platform to a verification device 110 associated with the spatial platform.

[0134] Fig. 11 is a flowchart illustrating a method according to another embodiment of the present disclosure. The method illustrated in Fig. 11 is a method in which the verification device 110 receives a reissue of the first authentication token from the first external device 131 when the first authentication token described with reference to Fig. 10 expires, and can be understood with reference to techniques related to the OAuth 2.0 protocol, for example.

[0135] When the validity period of the first authentication token expires, a second authentication token, i.e., a Refresh Token, for having the first authentication token reissued may be transmitted to the first external device 131 (S1110). Thereafter, the first authentication token may be acquired from the first external device 131 based on the second authentication token (S1120). Specifically, the verification device 110 may transmit the second authentication token to the first external device 131 when the validity period of the first authentication token expires. Thereafter, when the first external device 131 receives the second authentication token from the verification device 110, the first external device 131 may reissue the first authentication token corresponding to the second authentication token and transmit it to the verification device 110. Here, the second authentication token may be generated together with the first authentication token when the first authentication token is initially generated, and then transmitted to the verification device 110. In one embodiment, the validity period of the second authentication token may be longer than the validity period of the first authentication token. Therefore, even if the validity period of the first authentication token has expired, the validity period of the second authentication token does not have to expire. By using the second authentication token that has remaining validity period, the verification device 110 can have the first authentication token reissued through a procedure that is simpler than the authentication procedure shown in FIG.

[0136] FIG. 12 shows a certificate 1210 and a submission certificate 1220 that can be referenced in various embodiments disclosed herein. The certificate 1210 and the submission certificate 1220 shown in FIG. 12 may be documents that can be referenced in a distributed identity authentication technology. Distributed identity authentication (DID Auth) technology may be a technology that authenticates a user (or user information) through interaction between a user terminal 120 and a verification device 110. In this case, by allowing the user to control the authority to generate an identifier (Decentralized Identity, DID) or a submission certificate 1220, authentication can be performed even in a situation where the user does not unintentionally disclose information.

[0137] The certificate 1210, i.e., VC (Verifiable Credentials), is a verifiable credential and can refer to a document that proves specific information related to a user through a substantial identity document used by the user. For example, it can refer to a document that shows the user's qualifications, such as a resident registration card, passport, qualification certificate, graduation certificate, or employment certificate. The VC disclosed in this document can refer to identity proof for proving possession of a non-fungible token. In other words, the non-fungible token itself can be a document that proves specific information related to a user.

[0138] On the other hand, the VC may be issued by an issuer and submitted to a business operator. For example, the certificate 1210 may be issued by the generator of the non-fungible token and submitted to the operator of the verification device 110.

[0139] However, because the certificate 1210 is the non-fungible token itself, information about the non-fungible token that the user did not intend to transmit may be transmitted to the business operator (i.e., the operator of the verification device 110). Therefore, by generating a submission certificate 1220, i.e., a VP (Verifiable Presentation), based on the certificate 1210 to include one or more verification items, the user can ensure the authority to control the verification procedures related to the possession of the non-fungible token.

[0140] A VP (Verifiable Presentation) is a collection of verifiable provided data, and can refer to a document that has been processed to include some of the information contained in the VC, rather than being submitted directly to the business operator.

[0141] Regarding verification items that may be included in the submission certificate 1220, in one embodiment, one or more verification items may include items related to the inventory of the non-fungible token. The items related to the inventory may include one or more items related to one or more non-fungible tokens included in the inventory. For example, the one or more items may include a token identifier of the non-fungible token, metadata of the non-fungible token, a contract address of the non-fungible token, the number of non-fungible tokens, the price of the non-fungible token, the market in which the non-fungible token is traded, a wallet address of the non-fungible token, or a digital asset of the non-fungible token. In another embodiment, one or more verification items may include items related to a virtual space. The items related to the virtual space may include one or more items related to the virtual space. For example, the one or more items may include a type of virtual space, an area of the virtual space, a set of services activated in the virtual space, a virtual space identifier that identifies the virtual space, or the like. In yet another embodiment, one or more verification items may include items related to an event. The items related to the event may include one or more items related to an event held in the virtual space. For example, the one or more items may include the type of event, the duration of the event, or the organizer of the event.

[0142] The generation of such a submission certificate 1220 may be an operation in which the user selectively includes at least some of the above-mentioned items using the certificate 1210, i.e., the non-fungible token itself, through the user terminal 120. To avoid redundant explanation, a method for generating the submission certificate 1220 based on the certificate 1210 will be described in detail later with reference to FIG. 14.

[0143] 13 is a flowchart illustrating a method according to another embodiment of the present disclosure, which may be a method for processing distributed identity authentication using the submission certificate 1220 described with reference to FIG.

[0144] The user terminal 120 may transmit an access request to the verification device 110 (S1301). This operation may be understood to be the same as the operation of obtaining the access request (S610) of FIG.

[0145] The verification device 110 may acquire first information about the non-fungible token determined to allow the user to access the virtual space based on the access request (S1302). This operation may be understood to be the same as the first information acquisition operation (S620) of Fig. 6. The first information may be information that must be filled with the user's non-fungible token to be granted access authority to the virtual space.

[0146] The verification device 110 can transmit the first information to the user terminal 120 (S1303). Then, the user terminal 120 can confirm the non-fungible token that can access the virtual space based on the first information. In this case, the non-fungible token that can access the virtual space is a document proving the qualification to access the virtual space, and can represent the certificate 1210.

[0147] The user terminal 120 can generate the submission certificate 1220 based on the certificate 1210 (S1304). That is, the user terminal 120 can obtain, from the verification device 110, first information including information related to a non-fungible token that allows access to the requested virtual space. From this information, the user terminal 120 can determine what information (second information) must be provided to satisfy the first information. The user terminal 120 can generate the submission certificate 1220 based on the non-fungible token, i.e., the certificate 1210, that can verify eligibility to access the virtual space using the first information. In other words, the user can generate the submission certificate 1220 using the user terminal 120 so that information related to the first information is included in the submission certificate 1220. To avoid redundant description, a method for generating the submission certificate 1220 will be described in detail later with reference to FIG. 14.

[0148] The user terminal 120 may transmit the identifier (DID) and the submission certificate 1220 to the verification device 110 (S1305). Here, the identifier is the identifier of the user involved in the distributed ID authentication, and may include, for example, the storage location of the identification document (DID Document) corresponding to the identifier (e.g., the address of a specific block in the blockchain where the identification document is recorded). Also, here, the identification document may include one or more verification items included in the submission certificate 1220, one or more verification values corresponding to the verification items, and the user's public key.

[0149] The verification device 110 may select a target verification item from one or more verification items included in the submission certificate 1220 to determine whether the user is allowed to access the virtual space (S1306). In one embodiment, the verification device 110 may randomly select a target verification item from one or more verification items. The randomly selected target verification item may be used for verification. Other methods for selecting a subset of verification items may also be used.

[0150] The verification device 110 can use the identifier to query the public key of the identification document (S1307), generate verification request information by encrypting the selected target verification item with the public key (S1308), and send the verification request information to the user terminal 120 (S1309).

[0151] In relation to the verification request information generation operation (S1308), in one embodiment, the verification device 110 may generate the verification request information by encrypting unique information for determining the legitimacy of the verification procedure with a public key. The verification device 110 may perform an operation of processing a randomly generated string for the verification request, and the unique information may be the randomly generated string assigned to the verification request information.

[0152] The user terminal 120 can decrypt the verification request information using a private key corresponding to the public key (S1310). Because the private key is a secret key that is not disclosed to the public (i.e., not included in the identification document), the target verification item selected by the verification device 110 can only be viewed by the user using the user terminal 120. Through this viewing, the user terminal 120 can receive a verification input value corresponding to the target verification item decrypted from the user's input (S1311) and transmit the verification input value to the verification device 110 (S1312). The user input (verification input) can be used (e.g., in step S1314) to determine whether the input matches or satisfies the verification value corresponding to the verification item.

[0153] In connection with the operation of transmitting the verification input value (S1312), in one embodiment, the user terminal 120 may transmit the unique information included in the verification request information and decrypted with the private key to the verification device 110. If the unique information encrypted with the public key transmitted by the verification device 110 to the user terminal 120 matches the unique information decrypted with the private key transmitted by the user terminal 120 to the verification device 110, the reliability of the legitimacy of the verification procedure may be improved.

[0154] The verification device 110 can query the verification value of the identification document corresponding to the target verification item (S1313). Since the identification document includes one or more verification items included in the submission certificate 1220 and one or more verification values corresponding to the verification items, by querying the identification document, the authenticity of the verification input value obtained from the user terminal 120 in a subsequent operation can be determined.

[0155] The verification device 110 can verify the access authority by comparing the verification value with the verification input value (S1314). Specifically, if the verification value matches the verification input value, the verification device 110 can verify that the user has the access authority, and if the verification value does not match the verification input value, the verification device 110 can verify that the user does not have the access authority.

[0156] In relation to determining the legitimacy of the verification procedure, in one embodiment, the verification device 110 can verify the access authority based on whether a verification input value is acquired from the user terminal 120 within a critical period from the time when the verification request information is transmitted to the user terminal 120. That is, the verification device 110 compares the time when the verification input value is acquired with the time when the verification request information is transmitted, and if the processing is completed within the critical period, the verification device 110 can process the verification procedure as legitimate, and if the processing is not completed within the critical period, the verification device 110 can process the verification procedure as illegitimate. The operator of the space platform can appropriately adjust the critical period depending on the actual implementation. In other words, the operator of the space platform can relax the intensity of the verification procedure by increasing the critical period, or can strengthen the intensity of the verification procedure by decreasing the critical period.

[0157] The verification device 110 may transmit a response corresponding to the access request to the user terminal 120 (S1315). This operation may be understood to be the same as the operation of transmitting the response (S640) of FIG.

[0158] Fig. 14 is a flowchart showing a method according to yet another embodiment disclosed in the present document. The method shown in Fig. 14 may be a method for generating the submission certificate 1220 described with reference to Fig. 12. Furthermore, the method shown in Fig. 14 may be a detailed operation of the operation of generating the submission certificate 1220 (S1304) described with reference to Fig. 13. Hereinafter, each step of the method shown in Fig. 14 will be described assuming that it is performed by the user terminal 120 shown in Fig. 1.

[0159] Based on the first information, a second set of information regarding the non-fungible tokens owned by the user may be obtained (S1410). As described with reference to FIG. 13 , the first information may be used in this operation (S1410) to generate the submission certificate 1220 so that information related to the first information is included in the submission certificate 1220 and a legitimate verification procedure can be performed. The second set of information may also represent a collection of information regarding the non-fungible tokens. For example, the second set of information may include, as variables, items related to the inventory of non-fungible tokens, token identifiers for each of the non-fungible tokens included in the inventory, metadata for each of the non-fungible tokens included in the inventory, contract addresses for each of the non-fungible tokens included in the inventory, the number of non-fungible tokens included in the inventory, prices for each of the non-fungible tokens included in the inventory, markets in which each of the non-fungible tokens included in the inventory was traded, wallet addresses for each of the non-fungible tokens included in the inventory, or digital assets for each of the non-fungible tokens included in the inventory. The second information set is a value corresponding to the variable, and may include values corresponding to the items described above as examples.

[0160] Based on the second information set, a third information set regarding a virtual space to which access is permitted based on the user's possession of non-fungible tokens may be obtained, and based on the second information set or the third information set, a fourth information set regarding an event corresponding to that virtual space may be obtained (S1420).

[0161] The third information set may refer to a collection of information about a virtual space to which a user is permitted access based on the user's ownership of a non-fungible token. For example, the third information set may include variables such as a type of virtual space, an area of the virtual space, a set of services activated in the virtual space, or a virtual space identifier for identifying the virtual space. The third information set may also include values corresponding to the variables, such as those described above as examples. In one embodiment, the third information set may be obtained based on the second information set by predetermining a mapping relationship between the non-fungible token and the virtual space.

[0162] The fourth information set may represent a collection of information about an event corresponding to the virtual space. Here, the event may be a temporary event (i.e., not a permanent part of the virtual space). For example, the fourth information set may include variables such as the type of event, the duration of the event, or the organizer of the event. The fourth information set may also include values corresponding to the variables, such as those described above as examples. In one embodiment, the fourth information set may be obtained based on the second information set or the third information set by determining in advance a mapping relationship between the non-fungible token or the virtual space and the event.

[0163] At least some of the information included in the second information set, the third information set, and the fourth information set may be selected (S1430). In one embodiment, at least some of the information included in the second information set, the third information set, and the fourth information set may be selected to generate a submission certificate 1220 suitable for the verification procedure based on the user's intention (e.g., input via the user terminal 120) or first information obtained from the verification device 110. The part of the information selected in this operation (S1430) corresponds to the second information for the non-fungible token owned by the user described with reference to FIG. 9 and may be understood as information used in the verification procedure.

[0164] The submission certificate 1220 may be generated by deleting the respective values of at least a portion of the selected information (S1440). Because the submission certificate 1220 is a document to be sent to the business, the respective values of at least a portion of the selected information may be deleted so that the user can ensure control over the verification procedures related to the ownership of the non-fungible token. The submission certificate generated in this manner may be used in the operations for processing the series of distributed identity authentication shown in FIG. 13.

[0165] The space according to various embodiments disclosed herein may be understood as a real space. If the technical concepts disclosed herein are applied to a real space, it may be understood as an embodiment in which a user approaches a space (e.g., a concert hall) or a specific region of a space (e.g., a specific area of a concert hall) by themselves through a verification procedure using a user terminal 120. In this case, the response sent to the user terminal 120 may be a success or failure message for the verification of access authority. Nevertheless, in such a case, the actual / physical space may be modeled as a virtual space to implement the access control described herein.

[0166] According to the disclosure in this document, non-fungible tokens can be used as tickets to enter spaces.

[0167] The disclosures in this document make it possible to prove ownership of non-fungible tokens.

[0168] The contents disclosed in this document can improve the convenience for users when proving ownership of non-fungible tokens.

[0169] The disclosures herein allow users to have control over the validation procedures associated with their ownership of non-fungible tokens (e.g., allowing users to control what token information is made public).

[0170] According to the disclosure in this document, when proving possession of non-fungible tokens sufficient to grant access rights to a space, users can protect their personal information by choosing the information they disclose.

[0171] The effects of the technical ideas disclosed in this document are not limited to (nor necessarily included in) the effects mentioned above, and other effects not mentioned will be clearly understood by those skilled in the art from the description of this document.

[0172] 1-14 , the computing devices, electronic devices, processors, servers, memories, displays, information output systems and hardware, storage devices, and other devices, apparatuses, units, modules, and components described herein may be embodied by or represent hardware components. Where appropriate, examples of hardware components that can be used to perform the operations described herein include controllers, sensors, generators, drivers, memories, comparators, arithmetic logic units, adders, subtractors, multipliers, dividers, integrators, and other electronic components configured to perform the operations described herein. In other examples, one or more hardware components that perform the operations described herein are embodied by computing hardware, such as one or more processors or computers. A processor or computer may be embodied by one or more processing elements, such as logic gate arrays, controllers and arithmetic logic units, digital signal processors, microcomputers, programmable logic controllers, field programmable gate arrays, programmable logic arrays, microprocessors, or other devices or combinations of devices configured to respond to and execute instructions in a defined manner to achieve a desired result. In one example, a processor or computer includes or is coupled to one or more memories that store instructions or software executed by the processor or computer. The hardware components embodied by the processor or computer can execute instructions or software, such as an operating system (OS) and one or more software applications executed by the operating system, to perform operations described in the applications. The hardware components can also access, manipulate, process, generate, and store data in response to the execution of the instructions or software.For simplicity, the singular terms "processor" or "computer" may be used in describing the examples set forth in this application; however, in other examples, multiple processors or computers may be used, or a processor or computer may include multiple processing elements, multiple types of processing elements, or both. For example, a single hardware component or two or more hardware components may be embodied by a single processor, two or more processors, or a processor and a controller. One or more hardware components may be embodied by one or more processors, or a processor and a controller, and one or more other hardware components may be embodied by one or more other processors, or other processors and other controllers. One or more processors, or a processor and a controller, may embody a single hardware component or two or more hardware components. A hardware component may have one or more different processing configurations; examples of such configurations include a single processor, independent processors, parallel processors, single instruction single data (SISD) multiprocessing, single instruction multiple data (SIMD) multiprocessing, multiple instruction single data (MISD) multiprocessing, multiple instruction multiple data (MIMD) multiprocessing, etc.

[0173] The methods illustrated in Figures 1-14 for performing the operations described herein may be performed by computing hardware, such as one or more processors or computers embodied as described above, embodying instructions or software for performing the operations described herein. For example, a single operation or two or more operations may be performed by a single processor, or two or more processors, or a processor and a controller. One or more operations may be performed by one or more processors, or a processor and a controller, and one or more other operations may be performed by one or more other processors, or other processors and other controllers. One or more processors, or a processor and a controller, may perform a single operation or two or more operations.

[0174] For example, instructions or software that control computing hardware, such as one or more processors or computers, to embody the hardware components and perform the methods described above may be created as computer programs, code segments, instructions, or any combination thereof that, individually or collectively, direct or configure one or more processors or computers, operating as a machine or special-purpose computer, to perform the tasks performed by the hardware components and methods described above. In one example, the instructions or software include machine code that is executed directly by one or more processors or computers, such as machine code generated by a compiler. In another example, the instructions or software include higher-level code that is executed by one or more processors or computers using an interpreter. The instructions or software may be created using any programming language based on the block diagrams and flow charts shown in the figures and corresponding descriptions herein, which disclose algorithms for performing the tasks performed by the hardware components and methods described above.

[0175] For example, all data, data files, and data structures associated with instructions or software for controlling computing hardware, such as one or more processors or computers, to embody the hardware components and perform the methods described above may be recorded, stored, or fixed on one or more non-transitory computer-readable storage media. Examples of non-transitory computer-readable storage media include ROM (Read-Only Memory), PROM (Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), RAM (Random-Access Memory), DRAM (Dynamic Random-Access Memory), SRAM (Static Random-Access Memory), flash memory, non-volatile memory, CD-ROM, CD-R, CD+R, CD-RW, CD+RW, DVD-ROM, DVD-R, DVD+R, DVD-RW, DVD+RW, DVD-RAM, BD-ROM, BD-R, BD-R LTH, BD-RE, Blu-ray or optical disc storage devices, HDD (Hard Disk Drive), SSD (Solid State Drive), flash memory, card-type memory such as a multimedia card micro or card (e.g., SD (Secure Digital) or XD (Extreme Digital)), magnetic tape, floppy disk, magneto-optical data storage device, optical data storage device, and all other devices. Here, the device may be configured to store instructions or software and all associated data, data files and data structures in a non-transitory manner, and to provide the instructions or software and all associated data, data files and data structures to one or more processors or computers so that the one or more processors or computers can execute the instructions.In one example, the instructions or software and all associated data, data files and data structures are distributed across a network of connected computer systems, where the instructions or software and all associated data, data files and data structures are stored, accessed and executed in a distributed fashion by one or more processors or computers.

[0176] While this document contains specific examples, it will become apparent after reading the disclosure of this application that various changes in form and detail may be made from such examples without departing from the spirit and scope of the claims and their equivalents. The examples described herein should be considered in an illustrative sense and not for purposes of limitation. Any statement regarding a feature or aspect of each example should be considered to apply to similar features or aspects of other examples. Suitable results can be obtained when the described techniques are performed in a different order, or when the components of the described systems, architectures, devices, or circuits are combined in a different manner, or when other components or their equivalents are substituted or supplemented.

[0177] Therefore, in addition to the foregoing description, the scope of the present invention may also be defined by the appended claims and their equivalents, and all changes that come within the scope of the claims and their equivalents should be construed as being embraced by the present invention.

Claims

1. A processor connected to a computer network including a blockchain network receives, from a user's terminal, an access request for requesting access to at least a part of a virtual space consisting of a plurality of areas; The processor acquires first information about a non-fungible token that is determined to allow the user to access the at least part of the area based on the access request; The processor verifies access authority indicating whether the user is allowed to access at least a portion of the area by determining whether the user owns the non-fungible token based on the first information; and the processor transmitting a response corresponding to the approach request to the user terminal based on the result of the verification.

2. The at least some region is an area set so that an object corresponding to the user can move; a first region and a second region distinct from the first region; The step of sending the response comprises: transmitting a response to the user terminal indicating that a first service set is activated when the object approaches the first area and that a second service set is activated when the object approaches the second area; The method of claim 1 , wherein the first service set and the second service set are distinct.

3. The first service set includes one or more first interactive objects configured to be able to interact with the object, The method of claim 2 , wherein the second service set includes one or more second interactive objects configured to be able to interact with the object.

4. The step of verifying the access authority includes: obtaining second information regarding the non-fungible token owned by the user; verifying whether one or more first items included in the first information correspond to one or more second items included in the second information; and verifying that the user has access authority to at least a portion of the area by verifying that the one or more first items and the one or more second items correspond to each other.

5. The one or more first items are: a first inventory of the non-fungible tokens determined to be accessible; a token identifier, metadata, and contract address for each non-fungible token included in the first catalog; and a virtual space identifier for identifying the virtual space; The one or more second items are: a second inventory of non-fungible tokens owned by said user; a token identifier, metadata, and contract address for each non-fungible token included in the second catalog; and The method of claim 4 , further comprising a virtual space identifier that identifies a virtual space associated with each non-fungible token included in the second inventory.

6. The step of verifying the access authority includes: determining whether the user owns a first non-fungible token and a second non-fungible token related to the first information, respectively; The method of claim 1 , wherein the first non-fungible token is distinct from the second non-fungible token.

7. The step of sending the response comprises: The method of claim 1 , further comprising transmitting, to the user's terminal, a link that allows access to the virtual space corresponding to the access request.

8. A processor connected to a computer network including a blockchain network receives, from a user's terminal, an access request for requesting access to at least a part of a virtual space consisting of a plurality of areas; The processor acquires first information about a non-fungible token that is determined to allow the user to access the at least part of the area based on the access request; obtaining, by the processor, second information for the non-fungible tokens owned by the user from an external device associated with a non-fungible token platform; The processor verifies access authority indicating whether the user is allowed to access at least the part of the area by determining whether the user possesses a non-fungible token that is determined to allow the access based on the first information and the second information; and the processor transmitting a response corresponding to the approach request to the user terminal based on the result of the verification.

9. The step of acquiring the second information includes: obtaining a first authentication token from a first external device participating in authentication of a non-fungible token platform based on user information of the user; requesting the second information from a second external device associated with a resource of the non-fungible token platform using the first authentication token; and obtaining the second information from the second external device.

10. A processor connected to a computer network including a blockchain network receives, from a user's terminal, an access request for requesting access to at least a part of a virtual space consisting of a plurality of areas; a step in which the processor acquires first information for a non-fungible token determined to allow the user access to at least the part of the area based on the access request, and the processor acquires, from the user's terminal, a submission certificate generated based on the first information to prove the user's possession of the non-fungible token; The processor verifies access authority indicating whether the user is allowed to access at least the portion of the area by determining whether the user owns the non-fungible token based on the submission certificate; and the processor transmitting a response corresponding to the approach request to the user terminal based on the result of the verification.

11. The submission certificate includes one or more verification items related to the non-fungible tokens owned by the user; The step of verifying the access authority includes: selecting a target verification item from the one or more verification items to determine whether the user is allowed to access the at least part of the area; The method of claim 10, further comprising: verifying access authority indicating whether the user is allowed to access at least a portion of the area based on a verification input value of the user obtained corresponding to the target verification item.

12. The step of obtaining the certificate for submission comprises: obtaining an identifier for the user; The identifier is a storage location of the identification document on the blockchain network; The identification document comprises: The method of claim 11 , comprising the one or more verification items, one or more verification values corresponding to each of the one or more verification items, and a public key of the user.

13. The step of obtaining the certificate for submission comprises: transmitting the first information to the user terminal; and acquiring, from the user terminal in response to the transmission of the first information, a submission certificate including verification items corresponding to at least one first item included in the first information; The one or more first items are: a first inventory of the non-fungible tokens determined to be accessible; a token identifier, metadata, and contract address for each non-fungible token included in the first catalog; and The method of claim 12 , including a virtual space identifier that identifies the virtual space.

14. The step of verifying the access authority includes: generating verification request information by encrypting the target verification item with the public key; transmitting the verification request information to the user's terminal; acquiring, from the user terminal in response to the verification request information, a verification input value corresponding to a target verification item decrypted with a private key corresponding to the public key; and verifying the access authority by checking whether a verification value corresponding to the target verification item included in the identification document obtained from the blockchain network and the verification input value obtained from the user terminal correspond to each other.

15. receiving an access request for a region of the virtual space, the access request being generated in response to an interaction between the virtual space and a user based on a user input; obtaining a condition for granting access authority through the access request; acquiring non-fungible token information regarding the non-fungible token owned by the user through the access request; and granting the user access to the area of the virtual space by verifying that the non-fungible token is in the user's possession and that the non-fungible token information satisfies the conditions for granting the access authority.

16. acquiring a first authentication token from a first external device associated with authentication of a non-fungible token platform based on user information for the user; requesting information about the non-fungible token from a second external device associated with a resource of the non-fungible token platform using the first authentication token; 16. The method of claim 15, further comprising: obtaining the non-fungible token information from the second external device.

17. The method of claim 15 , wherein the interaction with the virtual space includes an object manipulated by the user input on a platform that provides the virtual space reaching the area of the virtual space.

18. The method of claim 15 , wherein the access privilege allows a device operated by the user to access one or more services associated with the region.

19. The method of claim 15 , wherein the granting of access authority includes verifying that the non-fungible token is in the user's possession.

20. 16. The method of claim 15, wherein the non-fungible tokens are generated by a smart contract.

Images