Video data transmission method, video data transmission system, and video data transmission program

Abstract

To provide a video data transmission method for lowering a barrier when a user who uses a user device not provided with a wallet uses a virtual space platform in which an object tokenized as non-fungible tokens (NFTs) is used.SOLUTION: In a video transmission system 1, a video data transmission method for transmitting video data including a view of a virtual space in which a plurality of avatars are allowed to participate, the plurality of avatars being associated with a plurality of users including a first user, includes the steps of: generating a first wallet in association with first user identification information identifying the first user in the virtual space; and offering, in response to a first acquisition request from the first user, to the first user, a first non-fungible asset out of one or more non-fungible assets which are digital assets for use in the virtual space and tokenized as non-fungible tokens, and transferring a first non-fungible token associated with the first non-fungible asset to an address of the first wallet.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The disclosure herein relates to a video data transmission method, a video data transmission system, and a video data transmission program. More specifically, the disclosure herein relates to a video data transmission method, a video data transmission system, and a video data transmission program for transmitting a video including a view of a virtual space in which a non-fungible asset tokenized as a non-fungible token is used. The disclosure herein also relates to a game in which a non-fungible asset tokenized as a non-fungible token is used. The disclosure herein further relates to applications other than the above in which a non-fungible asset tokenized as a non-fungible token is used. [Background technology]

[0002] Services are provided that utilize a platform that constructs a virtual space using objects tokenized as non-fungible tokens (NFTs). For example, a user can participate in a virtual space that includes tokenized objects through his or her own avatar and interact with the avatars of other users who are participating in the virtual space. A video including a view of the virtual space captured by a virtual camera installed in the virtual space is delivered to the user's user device. The Sandbox (see Non-Patent Document 1) is known as a platform that can construct a virtual space using NFT-ized objects.

[0003] In a platform that uses tokenized objects to build a virtual space, an editor that can be used by users may be implemented. Using this editor, users can create objects in the virtual space, such as avatars, buildings, and items that make up the virtual space, for example on a voxel basis. The objects that make up the virtual space created by users are tokenized as NFTs. NFTs associated with objects in the virtual space are traded in a marketplace for that virtual space or a marketplace operated by a different operator from that virtual space. A parcel of virtual land in the virtual space may also be tokenized as an NFT.

[0004] Since NFTs can be traded on the marketplace using crypto assets, NFTized objects and NFTed virtual space parcels have asset value in the real world. NFT transactions are conducted using crypto assets such as ERC-20 tokens issued in compliance with ERC-20. NFT transactions (purchasing, selling, exchanging) can be conducted using crypto assets such as ERC-20 tokens. [Prior art documents] [Non-patent literature]

[0005] [Non-Patent Document 1] Animoca Brands Corporation, Welcome / Welcome to The Sandbox's official documentation and help resource., [online], [Retrieved April 22, 2022], Internet〈URL:https: / / sandboxgame.gitbook.io / the-sandbox / 〉 Summary of the Invention [Problem to be solved by the invention]

[0006] In a service that uses a virtual space that includes objects tokenized as NFTs, in order to NFTize (mint) objects and trade NFTs, the user must prepare an environment for conducting transactions using crypto assets at the start of the service. For example, when starting to use the service, the user is required to link an application (application program) for using the service with a cryptocurrency wallet (e.g., an ERC-721 compatible wallet) on the user device used by the user. Many users are unfamiliar with transactions using cryptocurrency wallets (hereinafter simply referred to as "wallets"), and the need to prepare a wallet is a barrier to using a service that uses a virtual space that includes NFTized objects.

[0007] As such, conventional services that utilize virtual spaces in which NFT-ized objects are used have the problem that it is difficult to include users who do not use wallets at the time they begin using the service.

[0008] The object of the invention disclosed herein is to provide a technical improvement that solves or alleviates at least some of the problems of the prior art described above. One of the specific objects of the invention disclosed herein is to lower the barrier for a user using a user device that does not have a wallet to use a virtual space platform in which an NFT-ized object is used. One of the specific objects of the invention disclosed herein is to lower the barrier for a user using a user device that does not have a wallet to use a game or other application in which an NFT-ized object is used.

[0009] Problems to be solved and objects of the invention disclosed in this specification other than those described above will become apparent upon reference to the entire specification. One or more aspects of the invention disclosed in this specification may solve problems that become apparent upon reference to the entire specification. [Means for solving the problem]

[0010] One aspect of the invention described herein relates to a video data transmission method for transmitting video data including a view of a virtual space in which avatars associated with each of a plurality of users including a first user can participate. The video data transmission method in one aspect includes a step of generating a first wallet in association with first user identification information that identifies the first user in the virtual space. In one aspect, the video data transmission method includes a step of granting a first non-fungible asset to the first user in response to a first acquisition request from the first user, among one or more non-fungible assets that are digital assets used in the virtual space and are tokenized as a non-fungible token, and transferring the first non-fungible token associated with the first non-fungible asset to an address of the first wallet. Effect of the Invention

[0011] Embodiments of the present invention can lower the barrier for users of user devices that do not have a wallet to use virtual space platforms that use NFT-ized objects. [Brief description of the drawings]

[0012] [Figure 1] 1 is a block diagram showing a video transmission system 1 according to an embodiment. [Diagram 2] FIG. 2 illustrates an example view of a virtual space including an avatar. [Diagram 3] FIG. 1 is a schematic diagram illustrating an example of a blockchain. [Figure 4] A diagram explaining the data structure of an NFT. [Diagram 5] 2 is a block diagram illustrating functions of a server provided in the video transmission system 1 of FIG. 1. FIG. [Figure 6] 1 is a diagram illustrating user assets used in the video transmission system 1. FIG. [Figure 7] FIG. 13 is a schematic diagram showing an example of an item purchase screen. [Figure 8]FIG. 2 is a schematic diagram for explaining conversion from a fungible asset to a non-fungible asset. [Figure 9] FIG. 13 is a diagram showing an example of a dress-up screen for selecting an item to be worn by an avatar. [Figure 10] 2 is a diagram for explaining asset management data stored in the video transmission system 1 of FIG. 1. FIG. [Figure 11] 2 is a diagram illustrating user management data stored in the video transmission system 1 of FIG. 1. FIG. [Figure 12] 2 is a diagram illustrating avatar management data stored in the video transmission system 1 of FIG. 1. [Figure 13] FIG. 13 is a schematic diagram illustrating an example of a room selection screen for selecting a video to watch. [Figure 14] FIG. 2 is a schematic diagram showing an example of a trading screen for trading non-fungible assets. [Figure 15] FIG. 13 is a flow diagram showing the process flow in which User A acquires a non-fungible asset using a wallet hosted on a server. [Figure 16] FIG. 11 is a flow diagram showing the process of acquiring a non-fungible asset using a user wallet. [Figure 17] FIG. 13 is a flow diagram showing the flow of a process in which a user C acquires a non-fungible asset. [Figure 18] This is a flow diagram showing the process by which user B converts a fungible asset into an NFT. [Figure 19] This is a flow diagram showing the process by which user A converts a fungible asset into an NFT. [Figure 20] This is a flow diagram showing the process by which user C converts a fungible asset into an NFT. [Figure 21] FIG. 10 is a diagram illustrating an example of an asset list displayed on a user device. [Figure 22] FIG. 13 is a diagram illustrating an example of an NFT issuance screen for converting a non-fungible asset into an NFT. [Figure 23] FIG. 11 is a diagram showing an example of a video being played on a user device. [Figure 24] FIG. 13 is a diagram showing an example of a co-starring video. [Diagram 25] FIG. 13 is a diagram showing archived video data. [Figure 26] FIG. 13 is a diagram showing video data for a co-starring video. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] Various embodiments of the invention disclosed in this specification (hereinafter, sometimes referred to as "the present invention") will be described below with reference to the drawings as appropriate. Note that components common to multiple drawings are given the same reference symbols throughout the multiple drawings. The embodiments of the present invention described below do not limit the invention according to the claims. The elements described in the following embodiments are not necessarily essential to the solution of the invention.

[0014] FIG. 1 is a block diagram showing a video transmission system 1 according to an embodiment. The video transmission system 1 shown in FIG. 1 includes a server 20. The server 20 is communicatively connected to a user device 10a, a user device 10b, a user device 10c, a blockchain network 30, a file system 40, and an exchange 50 via a network 5. In addition to the server 20, some or all of the user devices 10a, 10b, 10c, the blockchain network 30, and the file system 40 may be components of the video transmission system 1.

[0015] The network 5 may be a single network or may be configured by connecting multiple networks. The network 5 is, for example, the Internet, a mobile communication network, or a combination of these. As the network 5, any network that enables communication between electronic devices may be applied.

[0016] In the video transmission system 1, video data is transmitted from the server 20 to the user devices 10a, 10b, and 10c. When the user devices 10a, 10b, and 10c receive the video data from the server 20, they can play the video generated based on the video data. The video is generated as a sequence of video frames. Each user of the user devices 10a, 10b, and 10c can watch the video played on each user device. The video data can include object data related to objects included in the virtual space (e.g., data identifying an object placed in the virtual space, coordinate data indicating the position of the object placed in the virtual space in the virtual space), avatar display data for expressing the appearance of the avatar, motion data for expressing the movement of the avatar, and various other data required for generating the video. The motion data for expressing the movement of the avatar may be data that digitally expresses the movement of the user's face (changes in facial expression) or body movement in a time series. The motion data can be generated by a camera provided in the user device or a motion sensor worn by the user. The motion data may be generated at any time as time passes. The motion data may be generated at a predetermined sampling time interval. By rendering video data based on the motion data, a video including animation of an avatar that moves in sync with changes in facial expressions and body movements of a user can be generated.

[0017] The generation of a moving image based on the moving image data may be performed by any device included in the moving image transmission system. In one embodiment, the generation of a moving image based on the moving image data may be performed by each of the user devices 10a, 10b, and 10c. For example, the generation of a moving image based on the moving image data may be performed by executing a drawing application program (e.g., a rendering engine) in the user device. A method of generating a moving image from moving image data by executing a drawing application program in each of the user devices 10a, 10b, and 10c may be referred to as a "client rendering method" in this specification. The moving image transmission system 1 may adopt the client rendering method. In the client rendering method, each of the user devices 10a, 10b, and 10c may obtain a drawing application from, for example, an application distribution platform before generating a moving image. Each of the user devices 10a, 10b, and 10c may hold avatar display data for expressing the appearance of an avatar before starting a video playback process. In the client rendering method, each of the user devices 10a, 10b, 10c receives from the server 20 an avatar's identification information (avatar ID), motion data for expressing the avatar's movements, audio data, and other information necessary for rendering as necessary, generates a video based on the information received from the server 20 and information previously stored therein, and displays the generated video.

[0018] In another embodiment, the generation of a moving image from moving image data may be performed by the user devices 10a, 10b, and 10c acquiring a web page from the server 20 and executing a computer program (e.g., Java script) included in the web page by a browser provided in the user devices 10a, 10b, and 10c. The web page may describe a storage location of data (e.g., object data, avatar display data, motion data, etc.) required for generating a moving image. For example, the Java script included in the web page can acquire various data from a storage location of the data described in the web page, and generate a moving image based on the acquired data. The browser is software for browsing a web page described in HTML, and is software different from a drawing application program. The browser can be used to browse web pages provided by various servers in addition to the web page acquired from the server 20. In this specification, a method of generating a moving image from moving image data by a browser may be called a "browser rendering method." The moving image transmission system 1 can adopt the browser rendering method.

[0019] In yet another embodiment, generation of a moving image based on moving image data may be executed by the server 20. When the moving image is generated by the server 20, the moving image generated by the server 20 is transmitted from the server 20 to the user devices 10a, 10b, and 10c. The user devices 10a, 10b, and 10c play (display) the moving image received from the server 20. In this specification, a method in which the server 20 generates a moving image from moving image data is sometimes referred to as a "server rendering method." In the server rendering method, the moving image generated by the server 20 is transmitted to the user devices 10a, 10b, and 10c.

[0020] As described above, the video transmission system 1 can adopt any of the client rendering method, the browser rendering method, and the server rendering method. Therefore, the transmission of "video data" from the server 20 to the user devices 10a, 10b, and 10c includes the transmission of "video" generated by the server 20 from the video data. For example, when the video transmission system 1 adopts the client rendering method, the server 20 transmits pre-rendered video data (e.g., the above-mentioned object data, avatar display data, motion data, etc.) to the user devices 10a, 10b, and 10c, whereas when the video transmission system 1 adopts the server rendering method, the server 20 transmits the video generated by the server 20 to the user devices 10a, 10b, and 10c in units of frames. That is, in this specification, the "video data" transmitted from the server 20 to the user devices 10a, 10b, and 10c may be pre-rendered video data or post-rendered video data (i.e., video generated from pre-rendered video data).

[0021] In this manner, the server 20 provides a video transmission service to user devices such as user devices 10a, 10b, and 10c. For the sake of simplicity, only three user devices are illustrated in FIG. 1, but the server 20 can transmit video data to a large number of user devices, such as four or more. In this specification, it is assumed that the user device 10a is used by user A, the user device 10b is used by user B, and the user device 10c is used by user C. In addition, in this specification, a device used by a user to utilize the video transmission service provided by the server 20 is referred to as a "user device."

[0022] The user devices 10a, 10b, and 10c may store a video playback application for playing video data transmitted from the server 20. Instructions included in the video playback application may be executed by a processor of each of the user devices 10a, 10b, and 10c. A drawing application program (e.g., a rendering engine) that generates a video based on the video data may be part of the video playback application. The video playback application may be downloaded to the user devices 10a, 10b, and 10c, for example, from an application distribution platform (not shown).

[0023] The administrator of the server 20 (e.g., the provider of the server) can operate a virtual space (virtual space platform) and provide users with services that utilize the virtual space. The video data transmitted from the server 20 may include data representing a view of a portion of the virtual space captured by a virtual camera. The server 20 provides the user with various objects that constitute the virtual space, and the user can construct a portion or the entirety of the virtual space using the objects provided by the server 20. For example, the user can place objects that the user created in the virtual space provided by the server 20. The virtual space provided by the server 20 may have a world defined in a three-dimensional global coordinate system. In this case, the user's avatar can walk around in the virtual space in response to the user's operation. The virtual space provided by the server 20 may not have a three-dimensional world defined. If the virtual space provided by the server 20 does not have a three-dimensional world defined, the user's avatar may not move in the virtual space. In this case, the user's avatar and other objects (e.g., objects constituting the background, objects gifted by other users) may be placed in the virtual space. Hereinafter, for convenience, an entity that operates the virtual space provided by the server 20 or an entity that operates a video transmission service that transmits a view of the virtual space may be referred to as a "virtual space operator."

[0024] The server 20 may provide a function for the user to create objects on a voxel basis, in which case the user can create objects having various shapes using voxels.

[0025] The objects, items, voxels, and other elements that make up the virtual space provided by the server 20 may be collectively referred to as "digital assets" used in the virtual space.

[0026] In the video transmission system 1, video data is transmitted from the server 20. A video generated from the video data transmitted from the server 20 may include a view of a virtual space operated by a virtual space operator. The view of the virtual space is generated based on various objects constituting the virtual space, setting information of a virtual camera arranged in the virtual space (position in the virtual space, gaze position, gaze direction, and angle of view), and other information as necessary. The view of the virtual space may be a view of the virtual space from a first-person perspective as seen from an avatar of a user participating in the virtual space (i.e., photographed by a virtual camera arranged at the same position as the avatar). The view of the virtual space may be a view of the virtual space from a third-person perspective photographed by a virtual camera arranged at a position different from the position of the avatar of the user participating in the virtual space. When a user watches a video including a view of a virtual space from a third-person perspective, the view of the virtual space may include an avatar of the user.

[0027] The virtual space provided by the server 20 may include the avatar of the user. The user may participate in the virtual space using his / her avatar by signing in to the video transmission service provided by the server 20. In other words, the user may display his / her avatar in the virtual space provided by the server 20. The user may, for example, interact with the avatar of another user through his / her avatar in the virtual space. As an example, the user may interact with the other user using a text chat, a voice chat, or a communication function other than these. In this case, an animation in which the avatars of the users chat with each other in the virtual space may be generated, and video data including the animation may be transmitted to the user device. The users may also interact with each other in a manner other than chat. For example, the user may play a game together with another user in the virtual space. The user may play a game in cooperation with another user, or may play against another user in the game. The user's avatar may move in the virtual space together with the avatars of the other users. In this case, the user's avatar can participate in events in the virtual space together with other users' avatars, shop at virtual stores set up in the virtual space, or share experiences in the virtual space with other avatars in other ways.

[0028] A user may generate objects usable and / or installable in a virtual space, or may use objects provided by a virtual space operator. A user may be able to obtain objects from a virtual space operator for a fee or free of charge. Such objects may include objects representing items worn by an avatar, an avatar or a character other than an avatar or parts thereof (head, hairstyle, eyes, nose, mouth, etc.), a background object constituting the background of an avatar, an object representing an interior installed in a virtual space, and items, tools, equipment, weapons used in a game, and other in-game objects used in the game. A user may install an object that he / she created in a virtual space. A user may interact with an object placed in a virtual space. For example, a user may move, destroy, or modify an object in a virtual space. A user may play a game provided in a virtual space. When a user plays a game provided in a virtual space, an object owned by the user may be usable in the game. A user may obtain, purchase, exchange, lend, or sell digital assets such as objects and items in a virtual space.

[0029] FIG. 2 shows an example of a view of a virtual space provided by the server 20. The view 80 of the virtual space shown in FIG. 2 includes a part of the virtual space and the avatar 70a of the user A. The view of the virtual space may include two or more avatars. Various objects may be included in the virtual space. The view 80 shown in FIG. 2 is generated by photographing the avatar 70a in a house arranged in the virtual space with a virtual camera installed in the virtual space. Objects 81, 82, 83, and 84 are arranged in the room of the virtual space. The avatar 70a may move in the virtual space in response to the operation of the user device 10 by the user A. Some or all of the objects 81, 82, 83, and 84 may be arranged in advance in the virtual space by the virtual space operator. Some or all of the objects 81, 82, 83, and 84 may be arranged in the virtual space by the user. The user may remove the objects 81, 82, 83, and 84 from the virtual space (delete them from the virtual space) or move their installation locations.

[0030] In the virtual space provided by the server 20, the avatar of user A may be generated or rendered so as to move in the virtual space or change its appearance in other ways in response to the facial expression and / or body movement of user A captured by the user device 10a. In addition to the avatar of user A, multiple avatars corresponding to multiple users may exist in the virtual space. In addition to the avatars of users, characters (e.g., Minecraft mobs) moving in the virtual space may also exist in the virtual space. Characters moving in the virtual space may appear (be spawned) at predetermined positions in the virtual space based on a predetermined algorithm.

[0031] The virtual space provided by the server 20 may be a metaverse space. A plurality of users can simultaneously participate in this metaverse space through their own avatars. In this specification, the term "virtual space" also includes a "metaverse space". In the metaverse space, interactions between users, work in which a plurality of users participate, play in which a plurality of users participate, and other social activities in the real world are virtually reproduced. Users can participate in the metaverse space through their own avatars. The world of the metaverse space may be defined in a three-dimensional global coordinate system. The avatars of the users can freely walk around the world of the metaverse space and communicate with each other.

[0032] The server 20 may transmit video data of a video in which one of a plurality of users participating in the virtual space via avatars is a broadcast user. When a certain user becomes a broadcast user, a video broadcast by the broadcast user includes a view of the virtual space including the avatar of the certain user. The view of the virtual space including the avatar of a certain user can be generated by setting the setting information (position in the virtual space, gaze position, gaze direction, and angle of view) of a virtual camera placed in the virtual space so as to include the avatar.

[0033] A user who watches a video generated from video data transmitted from the server 20 may be called a viewing user. The distinction between a distribution user and a viewing user is not fixed. When a user participating in a virtual space distributes a video, the user becomes a distribution user while the video is being distributed, but becomes a viewing user while the user is not distributing the video and is watching a video distributed by another user. Also, while a user is interacting with other users in a virtual space through an avatar without distributing or viewing a video, the user is neither a distribution user nor a viewing user. In this way, a specific user is not fixedly defined as a distribution user, and a user who distributes a video among users participating in a virtual space is called a distribution user with respect to that video.

[0034] A broadcasting user may broadcast a solo video that includes his / her own avatar but does not include avatars of other users, or may collaborate with other users to broadcast a collaborative video that includes avatars of multiple users. A broadcasting user may host a video chat or voice chat in which multiple users can participate and broadcast this video chat or voice chat. A broadcasting user may host or hold an event (such as a party) in a virtual space in which multiple users can participate and broadcast this event.

[0035] A viewing user views a video distributed by a distribution user. A viewing user not only watches a video, but can also input a reaction to the video being viewed into his / her own user device. When a viewing user participates in a collaborative distribution as a guest, the viewing user may be called a guest user. When a viewing user participates in a video chat, a voice chat, or an event, the viewing user may be called a participating user. When a viewing user only views without participating in a video chat or a voice chat, the viewing user may be called a listener.

[0036] A video generated from video data transmitted by the video transmission system 1 includes a view of a virtual space. The view of the virtual space is a drawing area of ​​a part of the virtual space that is determined based on setting information of a virtual camera (e.g., a position in the virtual space, a gaze position, a gaze direction, and an angle of view). A view 80 of the virtual space included in a video played on the user device 10a of the user A may be determined to include the avatar 70a of the user A. As described above, the view 80 of the virtual space may be determined from a viewpoint from the avatar 70a (i.e., a first-person viewpoint). The view of the virtual space determined from a viewpoint from the avatar 70a may not include the avatar 70a at all, or may include only a part of the avatar 70a that is within the field of view of the avatar 70a (e.g., a hand).

[0037] User A can transmit a delivery request to the server 20 via the user device 10a to deliver a video including a view of a virtual space to other users. As described above, this view of the virtual space may or may not include the avatar 70a. A video delivered at the request of user A may be called a "video delivered by user A" or "video delivered from user A". When the server 20 receives a video delivery request from user A, the server 20 may create a room for user A. Other users can view the video of user A by accessing the room of user A. In this way, users of the video transmission system 1 can deliver a video including a virtual space and can also view videos delivered by other users. In one embodiment, a viewing user can view a video including a view of a virtual space including the avatar 70a by accessing the room of user A. In another embodiment, a viewing user can view a video including a view of a virtual space generated to include the avatar 70a of user A in the virtual space without accessing the room of user A. For example, by setting a virtual camera to track the avatar 70a moving in the virtual space, a view of the virtual space including the avatar 70a is generated, and the viewing user can watch a video including the view of the virtual space including the avatar 70a generated in this way. The view of the virtual space is, for example, a view from the viewpoint of the virtual camera. The virtual camera may be fixed to a specific position in the virtual space. For example, the virtual camera may be fixedly installed in a virtual event space installed in the virtual space, and a video including a view of the virtual space generated by this fixed virtual camera may be generated. In this case, when the avatar 70a moves to the event space in the virtual space, the generated video includes the avatar 70a.

[0038] The user devices 10a, 10b, and 10c are information processing devices capable of playing video data transmitted from the server 20 or videos generated from the video data. The user devices 10a, 10b, and 10c are, for example, smartphones, personal computers (PCs), mobile phones, tablet terminals, personal computers, e-book readers, wearable computers, game consoles, head-mounted displays, or various other information processing devices. Although not shown, each of the user devices 10a, 10b, and 10c includes a processor, a memory, an input interface for receiving user input, an output interface such as a display or speaker for outputting information, a communication interface, storage, and other components required for operating the user devices 10a, 10b, and 10c as an information processing device. The user devices 10a, 10b, and 10c may include a camera. This camera may be a 3D camera capable of detecting the depth of a person's face in order to detect the feature points of the user's face.

[0039] As described above, various digital assets are used in the virtual space operated by the operator of the server 20. Some of the digital assets used in this virtual space may be tokenized as non-fungible tokens on the blockchain network 30, as described in detail below. For ease of explanation, in this specification, tokenizing a digital asset as a non-fungible token may be referred to as "NFTing" the digital asset. In order to NFT a digital asset used in the virtual space, the virtual space operator holds an address (operator address) that uniquely identifies the virtual space operator in the blockchain network 30.

[0040] The server 20 holds operator address information 25e that indicates the address of the virtual space operator in the blockchain network 30. The operator address information 25e is a set of a public key and a private key that pairs with the public key. When Ethereum is used as the blockchain network 30, the operator address information is used to implement an ERC-721 compatible wallet or marketplace. The public key of the operator address information is used as an address unique to the virtual space operator in the blockchain network 30 when issuing or transferring tokens on the blockchain network 30. The private key is used to encrypt (digitally sign) transaction data to be sent to the blockchain network 30 for recording in the blockchain network 30.

[0041] Other information processing devices (e.g., user devices 10a, 10b, 10c) included in the video transmission system 1 may or may not have an address in the blockchain network 30. In the embodiment shown in FIG. 1, the user device 10b includes a user wallet W10b or is associated with the user wallet W10b, whereas the user devices 10a and 10c do not include a wallet and are not associated with the user wallet W10b. For this reason, the user devices 10a and 10c do not have an address in the blockchain network 30 for receiving transfers of tokens such as NFTs. On the other hand, the server 20 can include (host) a wallet for a user of a service provided by the server 20. The server 20 can manage the wallet of each user in association with user identification information that identifies each user in a service using a virtual space provided by the server 20 (e.g., a video transmission service). In the example shown in FIG. 1, the server 20 hosts a wallet W10a for user A in association with user identification information that identifies user A in a service using a virtual space. User A can purchase and generate NFTs and conduct other transactions related to NFTs using the wallet W10a hosted by the server 20. In this way, even if user A who uses a service using a virtual space provided by the server 20 uses the service using a user device 10a that does not have a wallet, the user A can conduct transactions related to NFTs using the wallet W10a managed by the server 20 for user A. Therefore, the service using the virtual space provided by the server 20 can be used not only by users who use a user device that has a wallet, but also by users who use a user device that does not have a wallet. In the example shown in FIG. 1, the server 20 does not host a wallet for user C. Based on a request from user C, the server 20 can host a wallet for user C in association with user identification information that identifies user C.

[0042] 1 illustrates only wallet W10a associated with user A as a wallet hosted by server 20, server 20 may include wallets associated with user identification information of other users who use the virtual space. For the sake of simplicity, wallet W10a associated with user A will be described below, but the description of wallet W10a also applies to other wallets managed by server 20 in association with other users of the virtual space.

[0043] The wallet W10a manages a public key and a private key that pairs with the public key in association with each other. The public key of the wallet W10a is used as an address unique to the wallet W10a in the blockchain network 30.

[0044] In one embodiment, wallet W10a may be generated in association with user A's user identification information when an NFT is acquired, a digital asset is converted into an NFT, or other processes requiring wallet W10a are performed.

[0045] In another embodiment, the wallet W10a may be generated in association with the user identification information of the user A when the user A registers for use of a service provided by the server 20. For example, the wallet W10a may be generated when the user A creates an account for the service provided by the server 20.

[0046] The wallet W10a may be a closed wallet that can be used only within the virtual space provided by the server 20. The closed wallet W10a may not be connected to a marketplace or exchange 50 outside the server 20. For this reason, when the closed wallet W10a is used, transactions of NFTs and crypto assets are conducted only between users who use the services provided by the server 20. When the closed wallet W10a is used, the NFTs associated with the non-fungible assets used in the virtual space provided by the server 20 can be traded in the internal marketplace of the server 20 described later, and may not be traded in an external marketplace. The closed wallet W10a may be used to receive utility tokens generated by executing a smart contract described later.

[0047] The wallet W10a may be an open wallet that can be connected to an exchange (e.g., the exchange 50) or a marketplace outside the server 20. When Ethereum is used as the blockchain network 30, an ERC-721 compatible wallet can be used as the open wallet W10a. Metamask is known as an ERC-721 compatible wallet.

[0048] The wallet W10a may have a first account for using the functions as a closed wallet and a second account for using the functions as an open wallet. By using the wallet W10a having these two accounts, the user can use the first account to conduct transactions within the server 20 and the second account to conduct transactions with the outside of the server 20.

[0049] The user wallet W10b provided in the user device 10b manages a public key and a private key that pairs with the public key in association with each other. The public key of the user wallet W10b is used as an address unique to the user wallet W10b in the blockchain network 30. The user device 10b can download a user wallet (e.g., user wallet W10b) from a known application providing platform as necessary. The user wallet (e.g., user wallet W10b) downloaded to the user device 10b is connected to the address of the operator of the server 20 after downloading. When Ethereum is used as the blockchain network 30, an ERC-721 compatible wallet (e.g., Metamask) can be used as the user wallet W10b.

[0050] Like the wallet W10a, the user wallet W10b may be used for trading NFTs and crypto assets between users of the server 20 and for receiving utility tokens. In this case, the server 20 does not need to generate a wallet associated with the user B. The server 20 may generate a wallet associated with the user identification information of the user B. In this case, the user B can switch between using the user wallet W10b provided in the user device 10b and the wallet hosted by the server 20.

[0051] The file system 40 is a system that is composed of multiple nodes and manages files in a decentralized manner according to IPFS (InterPlanetary File System). IPFS is a P2P type hypermedia protocol. Since IPFS is a well-known protocol, detailed description will be omitted. The server 20 may be one of the nodes that make up the file system 40. Among the digital assets provided by the server 20, NFT-ized digital assets (digital assets associated with non-fungible tokens) are stored in the server 20 for the video transmission service, but in order to reduce the risk of losing the NFT-ized digital assets, a backup of the NFT-ized digital assets is stored in the file system 40.

[0052] The exchange 50 is a trading platform that trades between legal currency (e.g., Japanese yen or US dollar) and crypto assets or between crypto assets. The exchange 50 is, for example, a CEX (Centralized Exchange). The exchange 50 has a digital order book, which is a list of unsettled buying and selling orders, and executes transactions between assets by matching buyers and sellers. The digital order book describes the seller's selling quantity and selling price, and the buyer's buying quantity and buying price. The exchange 50 publishes the exchange rate between crypto assets and legal currency. The exchange 50 may be provided outside the video transmission system 1. In other words, the exchange 50 may be operated by an entity other than the operator (virtual space operator) of the server 20. Binance and Coinbase are known as operators of the exchange 50.

[0053] The blockchain network 30 is a distributed computing platform that is composed of multiple computer nodes and has Byzantine fault tolerance. A known public proof-of-work type blockchain can be used as the blockchain network 30. For example, Ethereum can be used as the blockchain network 30. The server 20 may be one of the computer nodes that make up the blockchain network 30.

[0054] The blockchain held in the blockchain network 30 will be described with reference to FIG. 3. FIG. 3 illustrates a blockchain 31 that is used in the video transmission system 1 for issuing tokens, recording transactions, deploying smart contracts, and for other purposes as necessary. The blockchain 31 includes a plurality of blocks. For convenience of explanation, FIG. 3 illustrates three blocks 31n-1, 31n, and 31n+1. Block 31n is a block linked after block 31n-1, and block 31n+1 is a block linked after block 31n.

[0055] Each block included in the blockchain 31 includes a hash value of the previous block, a hash value of the current block, and transaction information. Although not shown in the figure, each block may include a "nonce" (number used once) to prevent replay attacks. Each block may include a timestamp. The hash value of each block is obtained, for example, by inputting the hash value of the previous block, all transaction data included in the transaction information of the current block, and a nonce into a hash function. Since the input to the hash function in each block also includes the hash value of the previous block, if some transaction information in the blockchain 31 is tampered with, the hash values ​​in the blockchain 31 will not be consistent. For this reason, it is considered virtually impossible to tamper with transaction information recorded on the blockchain.

[0056] The transaction information of each block includes multiple transaction data. Each transaction data describes the contents of the transaction. The transaction data is transmitted from, for example, the server 20. Specifically, the server 20 encrypts the transaction data with the private key of the operator address information 25e to generate digital signature data, and transmits a transaction including the digital signature data and the transaction data to the blockchain network 30. When the transaction is received, the blockchain network 30 verifies the authenticity of the digital signature data by a known method, for example, a known proof-of-work method. When the authenticity of the digital signature data is confirmed, the blockchain network 30 records the transaction data associated with the digital signature data in the latest block of the blockchain 31. The transaction data recorded in this block may be stored in synchronization with all the nodes constituting the blockchain network 30. The transaction data may be transmitted to the blockchain network 30 from a wallet such as the wallet W10a that is managed in association with the user identification information in the server 20. The transaction data may be transmitted from a user wallet (for example, the user wallet W10b) provided in a user device used by a user.

[0057] The transaction sent from the server 20 may include a deployment request to request the deployment of a smart contract on the blockchain 31. In the example shown in Fig. 3, the smart contracts 32 and 33 are recorded in the block 31n-1. In other words, the smart contracts 32 and 33 are deployed on the blockchain 31.

[0058] The smart contract 32 is executed based on a token issuance transaction (NFT issuance transaction) for issuing a non-fungible token. The NFT issuance transaction may be sent from the wallet W10a or may be sent from the user wallet W10b. When the smart contract 32 is executed, a non-fungible token is issued to the address of the sender of the NFT issuance transaction (for example, the address of the operator address information managed by the server 20, the address specified by the public key of the wallet W10a, or the address specified by the public key of the user wallet W10b). The smart contract 32 may be written using various methods defined in ERC-721. When the smart contract 32 is written using a method defined in ERC-721, a non-fungible token conforming to the ERC-721 standard is issued by the execution of the smart contract 32. A non-fungible token issued according to the ERC-721 standard may be called an NFT-721 token. The smart contract 32 may be written to allow NFTs to be issued only to the address that has deployed the smart contract 32. The smart contract 32 may be written using various methods defined in ERC-1125 or other standards instead of ERC-721.

[0059] When a non-fungible token is issued by executing the smart contract 32, NFT issuance transaction data describing the transaction to issue the non-fungible token is recorded in the current block on the blockchain 31. In the example shown in Figure 3, NFT issuance transaction data 32a, 32b are recorded in block 31n.

[0060] The blockchain 31 may record state data 34 indicating the latest state of all addresses in the blockchain. The state data describes the latest state of all addresses in the blockchain 31, including the address of the virtual space operator provided by the server 20 and the address of a wallet (e.g., wallet W10a) associated with the user identification information of a user managed by the server 20. The state data may include a description of the latest state of the address of user wallet W10b.

[0061] A non-fungible token issued to a specific address by the smart contract 32 can be transferred to another address. When a non-fungible token is transferred from address A to address B, an NFT transfer transaction is sent from address A to the blockchain network 30. This NFT transfer transaction includes NFT transfer transaction data describing the transfer of the non-fungible token from address A to address B, and digital signature data obtained by encrypting the NFT transfer transaction data with the private key of address A. When the authenticity of the digital signature data is confirmed in the blockchain network 30, the blockchain network 30 records the NFT transfer transaction data associated with the digital signature data in the latest block of the blockchain 31. In the example of FIG. 3, the NFT transfer transaction data 32c is recorded in block 31n+1. When the NFT transfer transaction data is recorded in the blockchain 31, the state data 34 may also be updated to reflect the transfer of the non-fungible token described in the NFT transfer transaction data, and the updated state data 34 may be recorded in block 31n+1.

[0062] A non-fungible token issued on the blockchain 31 can be transferred to an address of a blockchain other than the blockchain 31 that is compatible with the blockchain 31. For example, if a non-fungible token issued on the blockchain 31 is an ERC-721 token, the non-fungible token can be transferred to an address of another blockchain that complies with ERC-721. For example, the non-fungible token can be transferred between wallets managed in the server 20 in association with the user identification information of each user. If the server 20 has an open wallet, the non-fungible token can be traded on the exchange 50 or other marketplaces, and NFT transfer transaction data describing the transfer resulting from the transaction can be recorded on the blockchain 31.

[0063] The smart contract 33 is executed based on a token issuance transaction (UT issuance transaction) sent from the server 20 (the address of the operator address information managed by the server 20). When the smart contract 33 is executed based on the UT issuance transaction, a utility token is issued to the address of the operator address information managed by the server 20. The smart contract 33 may be written using various methods defined in ERC-20. For example, the total supply of the utility token is defined in the smart contract 33. The smart contract 33 also manages the balance of each user who holds the utility token, and can return the utility token balance of the address to the address in response to a request from the address. When the smart contract 33 is written using a method defined in ERC-20, an ERC-20 token conforming to the ERC-20 standard is issued by executing the smart contract 33.

[0064] The UT issuing transaction for issuing the utility token may be sent from the wallet W10a or the user wallet W10b. For example, as described below, each user may be issued points that can be converted into a utility token. If these points are granted to user A, user A can convert the points into a utility token by sending a UT issuing transaction for converting the points into a utility token from the wallet W10a to the blockchain network 30. The points before being converted into a utility token are not recorded in the blockchain network 30, and therefore may be treated as an off-chain utility token in the server 20. In order to distinguish from this off-chain utility token, the utility token recorded in the blockchain network 30 can be called an "on-chain" utility token.

[0065] When the smart contract 33 is executed to issue an on-chain utility token, UT issuance transaction data is recorded in the current block of the blockchain 31. In the example shown in FIG. 3, UT issuance transaction data 33a is recorded in block 31n+1. The utility token issued by the smart contract 33 to a given address may be transferred to another address. To transfer the utility token from address A to address B, a UT transfer transaction is sent from address A to the blockchain network 30. The UT transfer transaction may include UT transfer transaction data describing the transfer of the utility token from address A to address B. When the smart contract 33 is executed based on the UT transfer transaction, the utility token is transferred from address A to address B. In the embodiment shown in FIG. 3, UT transfer transaction data 33b is recorded in block 31n+1.

[0066] The blockchain 31 may maintain a UT balance list 35 that records the balance of the utility token for each address that has the utility token.

[0067] The data structure of a non-fungible token will be described with reference to FIG. 4. FIG. 4 shows a schematic diagram of a data structure of a non-fungible token issued according to the ERC721 standard. As shown in the figure, a non-fungible token (NFT) includes a token ID that identifies the non-fungible token, holder address information that indicates the address of the holder of the non-fungible token, and a token URI that indicates a storage location of metadata. The non-fungible token may include data other than those described above.

[0068] A token ID is an identifier that uniquely identifies a non-fungible token. A non-fungible token is distinguished from other tokens because it is associated with a token ID. In other words, the non-fungibility of a non-fungible token is guaranteed by the uniqueness of the token ID associated with the non-fungible token. The token ID may be an integer that is incremented by "1" each time a token issuance request is made.

[0069] The holder address information of a non-fungible token indicates the address of the holder who holds the non-fungible token. The holder address information may be represented by the address (e.g., public key) of the wallet used by the holder of the non-fungible token. When the smart contract 32 designates only the operator of the virtual space provided by the server 20 as the issuer of the non-fungible token, the holder address information of the non-fungible token issued by the smart contract 32 is set to the address of the operator of the virtual space. The holder address information may be set to an address represented by the public key of the wallet W10a or an address represented by the public key of the user wallet W10b. The fact that a holder "holds" a non-fungible token means that the holder is duly recorded as the holder of the non-fungible token in the blockchain network 30, but does not mean that the holder has ownership or copyright of the non-fungible asset associated with the non-fungible token. Since a non-fungible asset is an intangible object, ownership of the non-fungible asset does not exist depending on the legal jurisdiction. For example, in Japan, at the time of filing this application, ownership of intangibles such as data is not recognized. In addition, the transfer of copyrights for non-fungible assets and the establishment of usage rights for such copyrights are decided separately from the transfer of non-fungible tokens. Therefore, unless otherwise agreed (off-chain), the possession of a non-fungible token does not mean that an agreement has been reached to transfer the copyright of the non-fungible asset associated with the non-fungible token.

[0070] The token URI is index data indicating a storage location of the metadata of the non-fungible token. The metadata of the non-fungible token may be described in the NFT issuance transaction data for issuing the non-fungible token. The metadata of the non-fungible token may include the name, media, description, reference information of the target data of the non-fungible token, and other data related to the non-fungible token. The "name" represents the name of the non-fungible token. The "name" may be identification information (e.g., asset ID) that identifies a non-fungible asset associated with the non-fungible token in a virtual space, identification information that identifies the non-fungible asset in a game in which the non-fungible asset associated with the non-fungible token is used, and / or a character string other than the above that can identify the non-fungible asset associated with the non-fungible token. The "media" represents a file type of data associated with the non-fungible token. In this specification, the data associated with the non-fungible token may be referred to as "target data". Examples of "media" are JPG, GIF, and other file types. "Description" is a description of the target data. If the target data is a glasses object worn by an avatar in a virtual space, for example, it may be described as "Produced in 2022, limited to 100 pairs." The "description" may be appropriately defined in the NFT issuance transaction data within the upper limit of the text length. The reference information for the target data is data that identifies the storage location of the target data, such as a URL.

[0071] The metadata of the non-fungible token is stored in the file system 40. The metadata of the non-fungible token may be stored in storage accessible to the user devices 10a, 10b, the server 20, and the blockchain network 30 other than the file system 40. The metadata of the non-fungible token may be recorded in the blockchain 31 as part of the non-fungible token.

[0072] The target data associated with the non-fungible token is a digital asset used in a virtual space provided by the server 20, such as an object or an avatar to be placed in the virtual space. The target data associated with the non-fungible token is stored on the server 20 for use in the virtual space. A backup of the target data is stored in the file system 40. In this case, the reference information for the target data included in the metadata may be a URL that identifies the storage location of the target data in the file system 40.

[0073] As described above, only a part of the data set of the non-fungible token, such as the token ID, the holder address information, and the token URI, is recorded in the blockchain 31, and the metadata and the target data are not recorded in the blockchain 31 but are recorded in the file system 40. The data set of the non-fungible token recorded in the blockchain 31 may be called the index data of the non-fungible token. Recording the non-fungible token in the blockchain 31 may mean recording only a part of the non-fungible token, specifically, only the index data. In other words, when the index data of the non-fungible token is recorded in the blockchain 31, the non-fungible token can be considered to be recorded in the blockchain 31.

[0074] In another example, metadata of a non-fungible token and target data associated with the non-fungible token may be recorded on the blockchain 31. A method of recording not only index data but also metadata and target data on the blockchain is sometimes called "full on-chain" because the entire non-fungible token is recorded on the blockchain. The non-fungible token used in the video transmission system 1 may be recorded on the blockchain 31 full on-chain.

[0075] A blockchain other than the blockchain 31 may be used to issue non-fungible tokens and utility tokens used in the video transmission system 1. The virtual space operator can select an appropriate blockchain in consideration of gas fees and transaction speed.

[0076] With further reference to FIG. 5, the functionality of the server 20 and the data stored therein will now be described.

[0077] The server 20 includes a processor 21 and a storage 25. Although not shown in the figure, the server 20 may include a memory, an input interface for receiving user input, an output interface for outputting information, a communication interface, and other components. The processor 21 is a computing device that loads an operating system and various other programs from the storage 25 or other storage into memory and executes instructions included in the loaded programs. The processor 21 is, for example, a CPU, an MPU, a DSP, a GPU, various other computing devices, or a combination of these. The storage 25 is an external storage device accessed by the processor 11. The storage 15 is, for example, a magnetic disk, an optical disk, a semiconductor memory, or various other storage devices capable of storing data.

[0078] The storage 25 stores a virtual space asset 25a, asset management data 25b, user management data 25c, avatar management data 25d, and operator address information 25e. The storage 25 may also store data other than those described above.

[0079] The virtual space assets 25a are digital assets used in the virtual space provided by the server 20. The virtual space assets 25a are used to construct the virtual space. The virtual space assets 25a may include avatar display data for displaying a user's avatar, structure data representing buildings, furniture, and other structures to be placed in the virtual space, and various other data used to construct the virtual space. The virtual space assets 25a may include object position information indicating the position of an object in the virtual space. The position in the virtual space may be specified by coordinate values ​​in a three-dimensional global coordinate system set in the virtual space. The virtual space assets 25a may include object identification information for identifying an object used to construct the virtual space and / or an object used in the virtual space in the virtual space.

[0080] The avatar display data is information used to display an avatar in a video. The avatar display data may include, for example, part data showing images of the head, hairstyle, facial features (eyes, nose, mouth, etc.), torso, and other parts that make up the avatar.

[0081] The avatar display data may include wearable item data that indicates wearable items that can be worn by the avatar in the virtual space. Wearable items are objects that are associated with specific body parts of the avatar in the virtual space. Wearable items include accessories (headbands, necklaces, earrings, etc.) worn by the avatar, clothing (T-shirts, hoodies, skirts, etc.), costumes, and other items that can be worn by the avatar. The wearable item data may include wearable position information that indicates which body part of the avatar the wearable item is associated with.

[0082] The virtual space assets 25a may include gift object data representing a gift object that is a digital gift that can be gifted between users. The gift object may be, for example, an object that resembles a stuffed toy, a bouquet of flowers, a bag, or an accessory. The gift object may be a wearable item that is worn by an avatar. A user can gift a wearable item that represents an accessory that is worn by an avatar in the virtual space to another user as a gift. Digital assets that can be gifted to other users are not limited to those mentioned above. Various digital assets (objects representing furniture, blocks, avatar parts, etc.) used in the virtual space provided by the server 20 may be giftable between users.

[0083] The virtual space assets 25a will be further described with reference to FIG. 6. As shown in FIG. 6, the virtual space assets 25a may include user assets that are granted to users and environmental assets that are used exclusively by the virtual space operator. An example of the user assets is the above-mentioned avatar display data. A user can obtain avatar display data and create an avatar according to his / her own personality based on the obtained avatar display data. In addition, a user may obtain structure data and install a desired structure in the virtual space based on the obtained structure data. The user assets may be voxel-based blocks. For example, the exterior wall of a house can be created by obtaining structure data representing a brick block in the virtual space and installing the brick block at a desired position in the virtual space. The environmental assets are, for example, data representing the ground, topography, etc. that correspond to the infrastructure of the virtual space. However, land parcel data related to a parcel of land may be a user asset. The land parcel data may be data that specifies a parcel in the virtual space using coordinates in the virtual space. Such land parcel data may be converted into an NFT, and an NFT corresponding to the land parcel data may be granted or sold to a user.

[0084] The user assets include fungible assets and non-fungible assets. In FIG. 6, fungible assets 60, 62-63 and non-fungible assets 61, 64 are shown as examples of user assets. The non-fungible assets may include native non-fungible assets that are NFTed before being granted or sold to a user, and converted non-fungible assets that are NFTed based on a mint request from the user after being granted to the user.

[0085] A fungible asset means an asset that has not been tokenized as a non-fungible token by the blockchain network 30 or a blockchain network other than the blockchain network 30. Whether a user's asset is a fungible asset or a non-fungible asset is determined, for example, by referring to the asset management data 25b described later. A user can acquire a fungible asset in a video transmission service provided by the server 20 and use the acquired fungible asset in a virtual space provided by the server 20. A fungible asset cannot be traded outside the video transmission system 1. Trading of a fungible asset outside the video transmission system 1 may be prohibited in the user terms and conditions that a user agrees to when receiving the video transmission service provided by the server 20. For example, a user can acquire an attachment item representing a T-shirt worn by an avatar as a fungible asset. The user can use the acquired attachment item in a virtual space operated by the server 20. For example, the user can make an avatar wear the attachment item in the virtual space. On the other hand, the user cannot use or trade the acquired attachment item (fungible asset) outside the video transmission system 1.

[0086] The use of fungible assets in the virtual space may include gifting the fungible assets to other users, exchanging the fungible assets with assets for other users owned by other users, and discarding the fungible assets. Trading of fungible assets outside the video transmission system 1 is prohibited, but trading within the video transmission system 1 may be permitted.

[0087] Non-fungible assets are also used in the virtual space, similarly to fungible assets. In addition, non-fungible tokens associated with non-fungible assets can be traded outside the video transmission system 1. Trades on non-fungible tokens may be made in a marketplace outside the video transmission system 1. Non-fungible tokens may be sold in the marketplace at a price designated by the user or in an auction format. A virtual currency such as Ether may be used as a transaction currency (transaction token) for buying and selling non-fungible tokens. Trades on non-fungible tokens may be made in a known marketplace, for example, OpenSea. In response to the transfer of a non-fungible token to another address, a predetermined fee may be paid to the operator of the server 20 (virtual space operator). The fee required for the transfer of a non-fungible token may be described in a smart contract that issues the non-fungible token. When a non-fungible token is transferred between users of a service provided by the server 20 using the internal marketplace of the server 20, the transfer fee may be free. In other words, the smart contract may be written so that a transfer fee is paid only when a non-fungible token associated with a non-fungible asset available in the virtual space provided by the server 20 is traded outside the server 20 (e.g., when traded on an external marketplace such as OpenSea). A transfer fee for a non-fungible token may be collected each time it is transferred, or may be collected only at the time of the first transfer. A transfer fee may be paid by an on-chain or off-chain utility token.

[0088] A part of the virtual space provided by the server 20 may be provided with a closed space into which only avatars that satisfy an entry condition can enter. The closed space represents a virtual live venue, a party venue, and other partitioned areas in the virtual space. The entry condition is, for example, that the user possesses a specific non-fungible asset associated with the closed space. In this specification, a specific non-fungible asset that the user must possess in order to be allowed to enter the closed space may be referred to as an "entrance non-fungible asset." In one embodiment, the entry non-fungible asset that the user must possess in order to be allowed to enter the closed space is a native non-fungible asset (e.g., the non-fungible asset 61). In another embodiment, the entry non-fungible asset is a converted non-fungible asset (e.g., the non-fungible asset 64). The entry non-fungible asset may be at least one of a native non-fungible asset and a converted non-fungible asset. In one embodiment, multiple non-fungible assets may be required in order to be allowed to enter the closed space. For example, a condition for being granted entry to a closed space may be that a user possesses both a native non-fungible asset and a converted non-fungible asset.

[0089] In another embodiment, when a closed space is set up, a non-fungible token (hereinafter referred to as an "admission ticket token") associated with the closed space may be issued, and only the avatar of a user who possesses the ticket token may be permitted to enter the closed space. By adjusting the number of ticket tokens issued, the number of avatars that may enter the closed space may be limited.

[0090] A user may be able to set up a closed space in the virtual space. For convenience, a user who sets up a closed space is called a host user. The host user may, for example, designate a section in the virtual space as a closed space and request the blockchain network 30 to issue a non-fungible token (admission ticket token) related to the closed space. The host user may sell the admission ticket token in the marketplace. The operator of the server 20 (virtual space operator) may collect a fee for setting up the closed space from the host user. The fee for setting up the closed space may be paid by an on-chain or off-chain utility token. The host user must pay a fee to set up the closed space and a gas fee to issue the ticket token, but can earn revenue by selling the admission ticket token.

[0091] A user can obtain fungible assets and non-fungible assets in various ways. For example, a fungible asset and / or a non-fungible asset may be given to a user as a login bonus when the user logs in to a video transmission service provided by the server 20. After logging in, the user may visit an item purchase screen and purchase an item displayed on the item purchase screen.

[0092] FIG. 7 shows an example of an item purchase screen for a user to purchase a user asset. The item purchase screen is displayed on the display of a user device (for example, the user device 10a). A user can purchase a desired user asset from the item purchase screen via the user device 10a. The item purchase screen of FIG. 7 displays images representing three items, that is, items 61, 62, and 63. The item 61 is an example of a native non-fungible asset, and the items 62 and 63 are examples of fungible assets. An NFT mark 61a is displayed near the image representing the item 61. The NFT mark 61a is an example of a display element indicating that the item 61 is a non-fungible asset. Since the items 62 and 63 are not non-fungible assets (they are fungible assets), the NFT mark is not displayed in association with the items 62 and 63. The price for purchasing the items is paid by legal tender, points given to the user within the service provided by the server 20, utility tokens, or crypto assets.

[0093] After acquiring (e.g., purchasing) a fungible asset, a user can convert the fungible asset into an NFT via the user device 10a. For example, user A can send a tokenization request to the server 20 to convert the fungible asset into an NFT. When the tokenization request is received, the server 20 transmits transaction data (NFT issuance transaction data) to the blockchain network 30 to tokenize the fungible asset as a non-fungible token. After the transaction data is verified in the blockchain network 30, an NFT tokenized from the fungible asset is issued to the address that transmitted the NFT issuance transaction data. For example, when an NFT is issued based on the NFT issuance transaction data transmitted from the wallet W10a associated with user A, the address of the wallet W10a represented by the public key of the wallet W10a is set as the holder address information of the NFT. The NFT issuance transaction data to convert the fungible asset into an NFT may be transmitted to the blockchain network 30 from a user device (e.g., the user device 10b) equipped with a user wallet. In this case, an NFT in which the fungible asset is tokenized is issued to the address of a wallet included in the user device that transmitted the NFT issuance transaction data. In this way, the fungible asset is converted into an NFT. The fungible asset may be converted into an NFT after being transferred between users of the service provided by the server 20. For example, after a fungible asset purchased by user A from a virtual space operator is transferred to user B, user B may convert the fungible asset into an NFT. In this case, NFT issuance transaction data may be transmitted from user wallet W10b of user B to the blockchain network 30. If the smart contract 32 limits the issuance destination of the non-fungible token to the virtual space operator, the NFT associated with the converted non-fungible asset 64 may be transferred to the address of the user who made the tokenization request after being issued to the virtual space operator.

[0094] As shown in FIG. 8, when the fungible asset 62 is NFTized, the fungible asset 62 is converted into a non-fungible asset 64. The non-fungible asset 64 is an example of a converted non-fungible asset. When the non-fungible asset 64 is displayed on a user device, an NFT mark 64a is displayed near the non-fungible asset 64. The NFT mark 64a may be displayed at a position away from the non-fungible asset 64. The NFT mark 64a may not be displayed. The non-fungible asset 64 has the same appearance as the fungible asset 62, but the NFT mark 64a is displayed near the non-fungible asset 64 or superimposed on the non-fungible asset 64, so that the non-fungible asset 64 can be distinguished from the fungible asset 62 in appearance. The NFT mark 64a displayed to identify the converted non-fungible asset 64 may have a different appearance from the NFT mark 61a displayed to identify the native non-fungible asset 61. For example, the NFT mark 64a displayed to identify the converted non-fungible asset 64 may have a different shape and / or color and may include a different character string than the NFT mark 61a displayed to identify the native non-fungible asset 61. This allows a user to see the NFT mark displayed near the non-fungible asset and distinguish whether the non-fungible asset is a native non-fungible asset or a converted non-fungible asset.

[0095] In the virtual space provided by the server 20, a non-fungible asset that has been created outside the video transmission system 1 (for example, a service other than the service provided by the server 20) and converted into an NFT may be used. FIG. 6 shows an external non-fungible asset 65 as an example of a non-fungible asset created outside the video transmission system 1. It is assumed that the external non-fungible asset 65 is an ERC-721 token, similar to the other non-fungible assets 61 and 64. A user of the service provided by the server 20 can purchase the external non-fungible asset 65 sold in an external marketplace by using a user wallet compliant with ERC-721, and transfer an NFT associated with the external non-fungible asset 65 to the user. A user of the video transmission system 1 can use the non-fungible asset acquired in this way in the external marketplace in the virtual space provided by the server 20.

[0096] An example of a usage mode in which a user uses the external non-fungible asset 65 in a virtual space will be described with reference to FIG. 9. FIG. 9 is an example of an avatar dressing screen. The avatar dressing screen is displayed on a user device (for example, user device 10a, 10b) in response to a user's operation on the user device. The dressing screen is displayed on the user device, for example, by the user selecting a selection button 71 displayed at the bottom of the screen after logging in. On the dressing screen, a list of wearable items owned by the user is displayed. The external non-fungible asset 65 is also included in this list and displayed on the dressing screen. An NFT mark 65a indicating that the external non-fungible asset 65 has been converted into an NFT is also displayed near the icon of the external non-fungible asset 65.

[0097] When the external non-fungible asset 65 is selected by the user on this dress-up screen, the avatar of the user can wear the external non-fungible asset 65. In response to the selection of the external non-fungible asset 65 by the user, the server 20 may check whether the user holds an NFT associated with the external non-fungible asset 65. The smart contract that issued the NFT associated with the external non-fungible asset 65 may include a function that returns the owner address information of the issued NFT in response to a request, in addition to a function that issues the NFT. The server 20 can check the owner of the external non-fungible asset 65 by accessing the smart contract that issued the NFT associated with the external non-fungible asset 65. When the external non-fungible asset 65 is selected by the user, the server 20 may permit the use of the external non-fungible asset 65 only if the user who selected the non-fungible asset 65 matches the owner of the NFT associated with the external non-fungible asset 65, and may not permit the user to use the external non-fungible asset 65 in the case of a mismatch.

[0098] The server 20 may check whether the external non-fungible asset 65 is a digital asset available in the service provided by the server 20, and may permit its use in the virtual space provided by the server 20 only if it is confirmed that the external non-fungible asset 65 is available. For example, the server 20 may verify whether the smart contract that issued the non-fungible token associated with the external non-fungible asset 65 is the same as a smart contract (e.g., smart contract 32) for converting a digital asset used in the virtual space provided by the server 20 into an NFT, and if it is confirmed that they are the same, it may permit the use of the external non-fungible asset 65 in the virtual space provided by the server 20. In another aspect, the server may verify whether the asset ID included in the metadata of the NFT associated with the external non-fungible asset 65 matches the asset ID assigned to the digital asset provided by the server 20, and if it is confirmed that they match, it may permit the use of the external non-fungible asset 65 in the virtual space provided by the server 20. The asset ID will be described below.

[0099] The asset management data 25b will be described with reference to Fig. 10. The asset management data 25b is a data set in which data for managing user assets is structurally stored. The asset management data 25b includes asset identification information for identifying user assets, asset holder information for identifying holders of the user assets in the virtual space, and token information for identifying non-fungible tokens associated with the user assets.

[0100] The asset identification information of a user asset is, for example, an asset ID that identifies the user asset. The asset ID uniquely identifies each user asset in the video transmission system 1. The asset ID is assigned to each user asset by the virtual space operator before the user asset is distributed in the virtual space.

[0101] The asset holder information of a user asset is, for example, the user ID of a user who holds the user asset in the virtual space provided by the server 20. By storing the asset ID that identifies the user asset and the user ID of the user who holds the user asset in association with each other, it is possible to identify which user holds each user asset. A null value may be set for the asset holder information of a user asset that is not held by any user. The asset holder information of a user asset is not data indicating the holder of an NFT in the blockchain network 30, but data specifying a user who has the authority to hold the user asset in the virtual space. For example, when user A purchases a non-fungible asset 61, for example, via the item purchase screen shown in FIG. 7, the user ID of the user A is associated with the asset ID of the non-fungible asset 61 and stored as part of the asset management data 25b.

[0102] The token information of a user asset is, for example, a token ID that identifies a non-fungible token associated with the user asset. When the user asset is a non-fungible asset, the token ID of the NFT associated with the non-fungible asset may be stored as the token information of the user asset. When the user asset is a fungible asset, there is no token ID associated with the user asset, so a null value is set in the token information of the user asset. By storing the asset ID that identifies the user asset and the token ID associated with the user asset in association with each other, it is possible to determine whether each user asset is a non-fungible asset or a fungible asset. In addition, when the user asset is a non-fungible asset, it is possible to identify which non-fungible token the user asset is associated with.

[0103] The user management data 25c will be described with reference to Fig. 11. The user management data 25c includes user identification information of each user of the video transmission system 1, avatar information related to the avatar used by each user, owned asset information for identifying user assets owned by each user, activity information indicating activities of each user in the virtual space, wallet information related to wallets hosted by the server 20, and point information related to points owned by each user.

[0104] The user identification information of a certain user is, for example, a user ID that identifies the user. The user ID of the user may be issued when the user registers for use of a video transmission service provided by the server 20 via a user device (e.g., the user device 10a). This video transmission service is a service that allows the user to view video data transmitted from the server 20 or a video generated from the video data.

[0105] The avatar information of a certain user is, for example, an avatar ID that identifies an avatar that the user uses in the video transmission system 1. The avatar ID is assigned to the user when the user registers the avatar. In the example shown in FIG. 2, user A uses the virtual space through the avatar 70a. In this example, the avatar ID of the avatar 70a is stored as a part of the user management data 25c in association with the user ID of user A. The registration of the avatar is performed in the video transmission system 1 after (or simultaneously with) the registration of the use of the video transmission service. When registering the avatar, the user can select preferred parts from the parts data and combine the selected parts to configure the avatar. The parts that configure the avatar may be stored as a part of the user management data 25c or as a part of another data set in association with the parts ID that identifies each part. When an avatar is configured with multiple parts, the parts IDs that identify each of the multiple parts that configure the avatar may be stored in association with the avatar ID that identifies the avatar. Even after the avatar is registered, the user can change some or all of the parts of the avatar. For example, even after registration, the avatar's hairstyle, facial features, and other features constituting the avatar can be changed. Furthermore, wearable item data such as clothing to be worn by the avatar can be selected, and the avatar can wear the wearable item corresponding to the selected wearable item data in the virtual space. The avatar information may be coordination information that specifies a combination of digital assets (hairstyle, facial features, clothing, accessories, etc.) that determine the appearance of the avatar. A plurality of pieces of coordination information may be stored for each user. By specifying a coordination, the user can determine the appearance of the avatar without having to individually select a hairstyle, facial features, clothing, etc. This allows the user to easily specify and switch the appearance of the avatar by specifying the coordination information.

[0106] The part data and attachment item data selected for the avatar are stored in the storage 25 as avatar management data 25d, as shown in FIG.

[0107] The avatar display data may include 2D display information for displaying the avatar in 2D in the video, and 3D display information for displaying the avatar in 3D in the video. The 3D display information for displaying the avatar in 3D may include, in addition to part data showing images of parts for stereoscopically displaying the avatar in the video, rig data for expressing the avatar's movement in three dimensions, and other known data used for stereoscopically displaying the avatar.

[0108] The wallet information of each user includes information about a wallet that is available to the user within the service provided by the server 20 and is hosted by the server 20. The wallet information associated with the user identification information of a certain user includes, for example, a wallet ID for identifying the wallet, a public key of the wallet used by the user, and a private key paired with the public key. If the user does not use a wallet hosted by the server 20, a null value may be stored in the wallet information. The user can trade non-fungible tokens and use on-chain utility tokens within the service provided by the server 20 using a wallet (e.g., user wallet W10b) provided in the user device, rather than a wallet hosted by the server 20. In this way, if the user uses a wallet provided in the user device and does not use a wallet hosted by the server 20, identification information for identifying the wallet provided in the user device may be stored. For example, the public key of the key pair used by the wallet provided in the user device of the user may be stored as the wallet information of a certain user. To explain a specific example, in the user management data 25c, identification information for identifying a user wallet W10b provided in the user device 10b of user B (for example, a public key used by the user wallet W10b) may be stored in association with the user ID of user B. When a user uses a wallet provided in his / her own user device and does not use a wallet hosted by the server 20, a null value may be stored in the wallet information associated with the user identification information of the user. In addition, the user can also use the service provided by the server 20 without using a non-fungible token or an on-chain utility token. A null value is also stored in the wallet information associated with the user identification information of such a user who does not use a non-fungible token.

[0109] The owned asset information of each user is information about the user assets owned by each user. The owned asset information of a certain user is, for example, the asset ID of the user assets owned by the user. By storing the user ID that identifies the user and the asset ID that identifies the user assets owned by the user in association with each other, it is possible to identify which user assets each user owns. Since the asset management data 25b associates the asset ID of the user asset with the user ID of the user who owns the user asset, the user management data 25c does not need to include the owned asset information.

[0110] When the server 20 receives a request from a user to view the asset information of another user, the server 20 may create a list of user assets owned by the other user by referring to the asset information of the other user, and transmit the asset list to the user device of the one user. The asset list of a user includes information on all or part of the user assets owned by the user. The asset list of a user may include only non-fungible assets owned by the user. The asset list of a user may include, for example, an icon indicating each user asset in association with the name of one or more user assets owned by the user, fungibility information indicating whether each user asset is a fungible asset or a non-fungible asset, native identification information for identifying whether the non-fungible asset is a native non-fungible asset or a converted non-fungible asset for a non-fungible asset among the user assets, and information on the user assets owned by the user other than these. When the asset list of another user is transmitted from the server 20 to the user device of the one user in response to a request from the one user, the information included in the asset list is displayed on the display of the user device of the one user. This allows a user to know which user assets are held by other users. Also, if the held asset list includes fungibility information, a user can know which non-fungible assets are held by other users.

[0111] The activity information of each user may include various information indicating the activities of each user in the virtual space. For example, the activity information of a certain user may include the following information: (Example of activity information) · The time and / or number of logins of the user to the video transmission service provided by the server 20 · The number of other users registered as friends by the user (number of friends) The number of other users the user is following (number of followings) · The number of other users following the user (number of followers) - The amount of tips given by the user to other users The number of gifts that the user has given to other users in videos that the other users have streamed The number of comments sent by the user on videos distributed by other users The number of positive feedbacks the user has given to videos posted by other users (e.g., the number of times the user has selected "likes") - The amount of tips sent to the user by other users The viewing time and / or number of views of the video provided by the video transmission system 1 by the user The distribution time, number of distributions, and / or number of viewers of the video distributed by the user through the video transmission system 1 The user's rank in various rankings managed by the video transmission system 1 The rank of the user managed in the video transmission system 1 (for example, S rank, A rank, B rank, C rank) The number of times the user has visited a room, world, live venue, or other area that is distinct from the above within the virtual space The number of objects that can be placed in the virtual space created by the user (number of objects created) The number of objects placed in the virtual space created by the user (number of objects placed) The number of virtual space contents (UGC) created by the user (number of UGC creations) The number of worlds (instances of virtual spaces created from templates of virtual spaces) customized by the user - The number of games created by the user (number of games created) The number of live shows or events held by the user (number of events held) The number of times the user participated in events held by other users (number of events participated) The purchase price (purchase amount) paid by the user for an event ticket to participate in a specific event in the virtual space The number of user assets held by the user (number of assets) In the case where a paid gacha is provided in the video transmission service provided by the server 20, the amount of the gacha purchased by the user - Indicators other than those mentioned above that show the activity of the user in the virtual space The number of times and / or duration of use of the text chat function by the user The number of times and / or duration of use of the video chat function by the User Indicators other than those mentioned above that indicate the level of activity of the user in the video transmission service provided by the server 20

[0112] In the video transmission system 1, points may be issued to users. The point information of each user indicates the number of points owned by each user. Points in the video transmission system 1 are given according to, for example, the number of logins to the video transmission service, the time spent watching a video, the number of times a video has been watched, and other activities within the video transmission system 1. The point information may be included in the activity information.

[0113] Next, a description will be given of functions executed by the processor 21 of the server 20. The computer processor 21 executes computer-readable instructions included in a program recorded in the storage 25, thereby functioning as a video transmission unit 21a.

[0114] The server 20 can transmit various kinds of videos. In the following, it is assumed that the server 20 transmits video data of a video in which user A is the distributor (hereinafter referred to as "user A's distributed video"), and user B watches the user A's distributed video on the user device 10b. As described above, the generation of a video from the video data may be performed by any device in the video transmission system 1. The user A's distributed video is generated by any of the server rendering method, the client rendering method, and the browser rendering method. A different rendering method may be used for each user device. For example, the user device 10a may play the user A's distributed video generated by the client rendering method, and the user device 10b may play the user A's distributed video generated by the server rendering method.

[0115] When user A logs in, the video transmission unit 21a refers to the user management data 25c to identify an avatar ID associated with the user ID of user A, and generates an avatar 70a of user A based on the avatar display data associated with the avatar ID of user A. The avatar 70a of user A is displayed in the virtual space, for example, as shown in FIG. 2. When a virtual space including the avatar 70a of user A is generated and a video distribution request from user A is transmitted to the server 20, a room selection screen including a "room A" for viewing a video including a view of the virtual space including the avatar of user A is displayed on the user device of the user who is logged in to the video transmission service to view the video. For example, when user B logs in to the video transmission service using the user device 10b and selects a video viewing button for viewing a video on the home screen displayed on the user device 10b, a room selection screen for selecting a video to be viewed is displayed on the user device 10b. An example of the room selection screen is shown in FIG. 13. As shown in Fig. 13, in addition to Room A for viewing a distributed video of User A, Rooms B to D are displayed on the room selection screen. When User B operates User device 10b to select Room A, the distributed video of User A including User A's avatar is played on User device 10b. While viewing User A's distributed video, User B can communicate with User A through a text chat function or a video chat function, give User A a gift object, give a tip, or provide feedback on an evaluation.

[0116] Of the rooms (e.g., Room A to Room D) displayed on the room selection screen, some of the rooms may be selectable only when a specific viewing permission condition is met. The viewing permission condition may be, for example, that a user who wishes to view a video (user B in the above example) possesses at least one non-fungible asset.

[0117] The video transmission unit 21a may transmit video data by a method other than the above. For example, the video transmission unit 21a can transmit video data of a video including a view of a virtual space captured by a virtual camera installed in the virtual space to a user device of a user who has signed in to a service provided by the server 20. This allows the user to watch a video including a view of the virtual space that is not a distribution video from a specific distribution user.

[0118] The processor 21 can execute various functions other than the function as the video transmission unit 21a. For example, the processor 21 can function as an NFT issuance request unit 21b, an NFT transfer processing unit 21c, an NFT trading unit 21d, a reward granting unit 21e, and a wallet generation unit 21f by executing computer-readable instructions included in a program recorded in the storage 25.

[0119] The NFT issuance request unit 21b generates NFT issuance transaction data for the fungible asset. For example, as shown in FIG. 6, the fungible asset 60 is converted into an NFT before being given to the user. In order to convert the fungible asset 60 into an NFT, the NFT issuance request unit 21b stores backup data of the fungible asset 60 in the file system 40. In addition, the NFT issuance request unit 21b transmits transaction data (NFT issuance transaction data) for tokenizing the fungible asset as a non-fungible token to the blockchain network 30. In the blockchain network 30, the smart contract 32 is executed based on the NFT issuance transaction data. By executing the smart contract 32, the fungible asset 60 is converted into an NFT and becomes a non-fungible asset 61, and an NFT having a token ID associated with this non-fungible asset 61 is issued to the address of the virtual space operator. The transaction to issue this NFT is written in the latest block on the blockchain 31. In addition, the NFT issuance request unit 21b can associate the token ID of the issued NFT with the asset ID of the non-fungible asset 61 and store it in the storage 25 as part of the asset management data 25b.

[0120] The NFT issuance request unit 21b can convert a fungible asset into an NFT in response to a request from a user who holds the fungible asset. In this specification, a request from a user to convert a fungible asset into an NFT may be referred to as a "tokenization request" or a "mint request." For example, as shown in FIG. 6, when a user holds a fungible asset 62, the user can transmit a tokenization request to the server 20 to request NFT of the fungible asset 62 by operating a user device. When the tokenization request is received by the server 20, the NFT issuance request unit 21b stores backup data of the fungible asset 62 in the file system 40 in order to convert the fungible asset 62 into an NFT, and also transmits transaction data (NFT issuance transaction data) for tokenizing the fungible asset as a non-fungible token to the blockchain network 30. The smart contract 32 is executed based on this NFT issuance transaction data, whereby the fungible asset 62 is converted into an NFT and becomes a non-fungible asset 64, and an NFT having a token ID associated with the non-fungible asset 64 is issued. The issued NFT is issued to the address of a wallet (e.g., wallet W10a) hosted on the server 20 in association with the user identification information of the user who made the tokenization request. The transaction to issue this NFT is recorded in the latest block on the blockchain 31. In addition, the NFT issuance request unit 21b can store the token ID of the issued NFT in the storage 25 as part of the asset management data 25b in association with the asset ID of the non-fungible asset 64.

[0121] Fungible assets may be NFTed one by one, or a set of multiple fungible assets may be NFTed. For example, wearable items to be worn by an avatar may be coordinated, and the set of the coordinated wearable items may be NFTed. In this case, one non-fungible token is issued for a set of multiple wearable items. The set of multiple wearable items becomes the target data associated with the issued non-fungible token.

[0122] When multiple fungible assets are converted into NFTs as a set, the set of fungible assets to be converted into NFTs is called set data. A user can select multiple fungible assets constituting the set data from, for example, items owned by the user. The set data may be a combination of multiple parts of an avatar. For example, the set data may be a combination of specific facial parts of an avatar and specific hairstyle parts. As described above, the storage 25 may store coordination information that corresponds to the avatar ID of the avatar used by the user and specifies a combination of digital assets (hairstyle, parts, clothing, accessories, etc.) that determine the appearance of the avatar. The combination of digital assets that constitute this coordination information may be set data. When a user's avatar participates in a specific event held in a virtual space, the user can specify, as set data, a combination of digital assets (hairstyle, parts, clothing, accessories, etc.) that determine the appearance of the avatar when participating in the event. For example, a user can specify an event in a virtual space that they participated in through their avatar, select a combination of digital assets that defined the appearance of the user's avatar at that event as set data, and convert the selected set data into an NFT.

[0123] The NFT transfer processing unit 21c performs processing for transferring the NFT from the transfer source address to the transfer destination address. For example, when user A transfers the non-fungible asset 61 to user B, the NFT transfer processing unit 21c generates NFT transfer transaction data for transferring the NFT associated with the non-fungible asset 61 from the address of user A to the address of user B. This NFT transfer transaction data describes the transfer of the NFT associated with the non-fungible asset 61 from the address of user A's wallet W10a to the address of user B's user wallet W10b. The NFT transfer transaction data is encrypted with the private key of user A's wallet W10a hosted by the server 20 to generate digital signature data. The NFT transfer transaction data is transmitted from the server 20 to the blockchain network 30 together with the generated digital signature data. When the authenticity of the digital signature data is confirmed in the blockchain network 30, the blockchain network 30 records the NFT transfer transaction data associated with the digital signature data in the latest block of the blockchain 31.

[0124] The NFT transfer processing unit 21c may accept an NFT transfer request from an address other than that of a user of the service provided by the server 20. If this NFT transfer request is sent from an address of a blockchain network compatible with the blockchain network 30, the NFT transfer processing unit 21c can transfer the NFT in a similar procedure to the transfer to the address of user B described above. For example, if the NFT to be transferred is a non-fungible token conforming to the ERC-721 standard, a process can be performed to transfer the NFT associated with the non-fungible asset to an address of an external blockchain network created according to the ERC-721 standard (for example, the address of a wallet conforming to the ERC-721).

[0125] The NFT trading unit 21d executes transactions between users of non-fungible assets that have been converted into NFTs. The NFT trading unit 21d displays a trading screen shown in FIG. 14 on the user device in response to the user's operation of the user device. FIG. 14 is an example of a trading screen displayed on the user device. The trading screen includes a list of non-fungible assets that have been put up for sale by users. The trading screen shown in FIG. 14 includes non-fungible assets 61, 64, and 66. Although not shown in the figure, the NFT mark may be displayed near each icon of the non-fungible assets 61, 64, and 66 on the trading screen. When not only non-fungible assets but also fungible assets are traded on the trading screen, the non-fungible assets and fungible assets can be distinguished from each other by the NFT mark. Each of the non-fungible assets 61, 64, and 66 is put up for sale by a user who holds the respective non-fungible assets. Each of the non-fungible assets 61, 64, and 66 is, for example, a product that is put up for sale by a user who owns the non-fungible asset. A utility token can be used for trading the non-fungible assets 61, 64, and 66. For each of the non-fungible assets 61, 64, and 66, the price for acquiring the asset is displayed as the quantity of the utility token. For example, 3.49 RLT is displayed in association with the non-fungible asset 61. The unit of the utility token used in the video transmission system 1 is "RLT". Another unit may be used as the unit of the utility token used in the video transmission system 1. In the illustrated embodiment, a user can obtain the non-fungible asset 61 in exchange for paying 3.49 RLT. In the example of FIG. 14, a price designated by the user in association with each non-fungible asset is displayed, but the non-fungible asset may be sold in an auction format. In this way, the NFT trading unit 21d provides the function of a marketplace. The marketplace function provided by the NFT trading unit 21d may be referred to as the “internal marketplace” of the server 20 or the services provided by the server 20.In order to acquire non-fungible assets on the transaction screen (in the internal marketplace), the user needs to be able to use a wallet. The user can trade non-fungible assets using a wallet hosted by the server 20 in association with the user's user identification information in the service provided by the server 20. For example, user A can trade non-fungible assets using wallet W10a hosted by the server 20. The user can also trade non-fungible assets using a wallet provided in the user device used by the user. For example, user B can trade non-fungible assets using user device 10b.

[0126] The reward granting unit 21e can grant points to a user who is logged in to the video transmission service according to the action of the user. For example, when any of the above-mentioned activity information for a certain user becomes equal to or greater than a predetermined threshold, the reward granting unit 21e can grant points to the user. As an example, points can be granted when the viewing time exceeds one hour. As another example, points can be granted as a login bonus every time a user logs in. The reward granting unit 21e can store the points granted to a certain user in a storage (for example, the storage 25) as a part of the user management data 25c in association with the user ID of the user. The points may be exchangeable for legal tender. The points may be exchangeable for items that can be used in a virtual space.

[0127] When a user uses a wallet that can be used as an address in the blockchain network 30, the reward granting unit 21e can grant a utility token issued by executing a smart contract 33 to the user in response to the user's action instead of or in addition to points. The conditions for granting the utility token may be the same as or different from the conditions for granting the points.

[0128] When a user uses a wallet that can be used as an address of the blockchain network 30, the user can convert his / her points into a utility token. For example, the reward granting unit 21e notifies the user of the exchange rate between the points and the utility token. When an exchange request transmitted from the user device of the user is received by the server 20, the reward granting unit 21e executes the smart contract 33 based on the number of points requested for exchange and the exchange rate, and can issue the utility token to the user.

[0129] A user who has acquired a utility token may exchange the utility token he or she holds for other ERC-20 tokens at a DEX (decentralized exchange). A DEX can trade ERC-20 tokens in an order book format or an automatic market maker format, for example, by executing a smart contract on the blockchain 31. However, in the case of an order book format, buy and sell orders are made off-chain and settlement is made on-chain. A DEX does not need to be able to exchange a utility token for fiat currency. If a utility token is listed on the exchange 50 or another exchange, the utility token can be exchanged for fiat currency.

[0130] The wallet generating unit 21f generates a wallet in association with the user identification information of the user. The wallet generated by the wallet generating unit 21f is hosted by the server 20 and is used by the user for NFT transactions, utility token management, and other processes. The wallet generating unit 21f can generate, for example, an ERC-721 compatible wallet. In one embodiment, the wallet generating unit 21f may generate a wallet for the user when the user generates an account for a service provided by the server 20 (i.e., when the user starts using the service provided by the server 20). In another embodiment, the wallet generating unit 21f generates a wallet for the user when the user needs a wallet after the user starts using the service of the server 20. For example, the wallet generating unit 21f can generate a wallet for the user when the user makes a request for a process that requires a wallet through a user device. A request for a process requiring a wallet made by a user through a user device includes (1) a process for requesting the purchase and / or acquisition of an NFT or a non-fungible asset in a service provided by the server 20, (2) a request for converting a non-fungible asset into an NFT, and (3) a request for acquiring an (on-chain) utility token. A request for a process requiring a wallet made by a user through a user device is not limited to the above. In another example, the wallet generation unit 21f can generate a wallet for a user when the user requires a wallet in response to a request from another user or in response to a process by the server 20. For example, when an NFT or a non-fungible asset is given to a user who does not use a wallet by another user, the wallet generation unit 21f can generate a wallet for the user. In addition, when an on-chain utility token is given to a user who does not use a wallet, the wallet generation unit 21f can generate a wallet for the user.

[0131] In one embodiment, the wallet generation unit 21f displays a graphical user interface (GUI) for generating a wallet on the user device of the user in response to a wallet becoming necessary within the service after the user starts using the service of the server 20. In this specification, the GUI for generating a wallet is referred to as a "wallet creation UI." The wallet creation UI displays, for example, terms of use regarding the wallet, and displays a screen for setting a password when the user agrees to the terms of use by operating an operation button included in the GUI. When a password is set by the user, a key pair for the user is created, and a wallet using this key pair is generated for the user. After a wallet for the user is generated, the user can use the generated wallet to trade NFTs and acquire utility tokens.

[0132] The wallet generation UI may be displayed on a user device in response to a user who is not using a wallet performing a process on the user device to send an NFT request to a server.

[0133] Next, the flow of the process in which user A acquires a non-fungible asset will be described with reference to Fig. 15. It is assumed that the user device 10a used by user A does not have a user wallet connected to the blockchain network 30, but that user A uses a wallet W10a hosted by the server 20.

[0134] First, in step S11, the user device 10a transmits an asset acquisition request to acquire the non-fungible asset 61 to the server 20. For example, when a purchase button associated with the non-fungible asset 61 is selected on the item purchase screen shown in FIG. 7, an asset acquisition request to acquire the non-fungible asset 61 is transmitted from the user device 10a to the server 20. The consideration for purchasing the non-fungible asset 61 may be paid by legal tender, points given to the user, utility tokens, crypto assets, or the like. When the consideration for purchasing the non-fungible asset 61 is paid by utility tokens, the user A consumes the amount of utility tokens corresponding to the price of the non-fungible asset 61. As a result, the balance of the utility tokens of the user A managed in the wallet W10a is reduced by the amount corresponding to the price of the non-fungible asset 61.

[0135] When the asset acquisition request is received, in step S12, the user management data 25c is referenced to identify the wallet associated with the user identification information of user A. Since the server 20 hosts the wallet associated with the user identification information of user A, it is possible to identify the wallet W10a of user A. The server 20 grants the non-fungible asset 61 specified in the asset acquisition request to user A. The server 20 can add the asset ID of the non-fungible asset 61 to the owned asset information associated with the user ID of user A in the user management data 25c.

[0136] After step S12 or in parallel with step S12, a process of transferring the non-fungible token associated with the non-fungible asset 61 to user A is started in step S13. For example, in step S13, the server 20 generates NFT transfer transaction data for transferring the non-fungible token associated with the non-fungible asset 61 from the operator address of the virtual space operator to the address of the wallet W10a of user A, and transmits the generated NFT transfer transaction data to the blockchain network 30. The NFT transfer transaction data is transmitted to the blockchain network 30 together with digital signature data generated by encrypting the NFT transfer transaction data with the private key of the wallet W10a.

[0137] Next, in step S14, the authenticity of the digital signature data is verified in the blockchain network 30. When the authenticity of the digital signature data is confirmed, the blockchain network 30 records the NFT transfer transaction data associated with the digital signature data in the latest block of the blockchain 31. As a result, it is recorded on the blockchain 31 that the non-fungible token associated with the non-fungible asset 61 has been transferred from the virtual space operator to user A.

[0138] In the NFT transfer transaction data, a fee (called a gas fee) for the blockchain network 30 to perform verification can be specified. This gas fee can be paid, for example, with utility tokens. The gas fee may be borne by the virtual space operator or by user A. When user A bears the gas fee, the amount of utility tokens corresponding to the gas fee is deducted from the balance of user A's utility tokens in response to the verification in step S14.

[0139] The user A can use the non-fungible asset 61 acquired from the server 20 in the virtual space provided by the server 20. For example, the user A can attach the acquired non-fungible asset 61 to his / her avatar 70a. When the non-fungible asset 61 is used in the virtual space, a display element indicating that the non-fungible asset 61 has been converted into an NFT may be displayed in association with the non-fungible asset 61. For example, on the dress-up screen, an NFT mark 61a may be displayed near the icon of the non-fungible asset 61. Even after the avatar wears the non-fungible asset 61, an NFT mark or other display element indicating that the non-fungible asset 61 has been converted into an NFT may be displayed in association with the non-fungible asset 61 to indicate that the non-fungible asset 61 has been converted into an NFT.

[0140] Since user A has also acquired the non-fungible token associated with the non-fungible asset 61, user A can put the non-fungible asset 61 up for sale on the marketplace. The non-fungible asset 61 put up for sale on the marketplace is displayed on a transaction screen as shown in Fig. 14. In this way, user A can secondary distribute the non-fungible asset 61 through the marketplace.

[0141] Next, the flow of the process in which user B acquires a non-fungible asset will be described with reference to Fig. 16. It is assumed that the user device 10b used by user B is equipped with a user wallet W10b connected to the blockchain network 30 as shown in Fig. 1.

[0142] First, in step S21, the user device 10b transmits an asset acquisition request to acquire the non-fungible asset 61 to the server 20. For example, when a purchase button associated with the non-fungible asset 61 is selected on the item purchase screen shown in FIG. 7, an asset acquisition request to acquire the non-fungible asset 61 is transmitted from the user device 10b to the server 20. The purchase of the non-fungible asset 61 may be performed using a utility token. When the non-fungible asset 61 is purchased by user B, user B consumes a quantity of utility tokens corresponding to the price of the non-fungible asset 61. As a result, the balance of the utility tokens of user B is reduced by the quantity corresponding to the price of the non-fungible asset 61.

[0143] When the asset acquisition request is received, in step S22, the server 20 grants the non-fungible asset 61 specified in the asset acquisition request to the user B. The server 20 can add the asset ID of the non-fungible asset 61 to the owned asset information associated with the user ID of the user B in the user management data 25c. In step S22, the user management data 25c may be referenced to identify the wallet associated with the user identification information of the user B. When the identification information of the user wallet W10b (e.g., the public key of the user wallet W10b) is stored in the user management data 25c, the server 20 can identify the user wallet W10b of the user B. In another embodiment, the asset acquisition request transmitted from the user device 10b may include the identification information of the user wallet W10b (e.g., the public key of the user wallet W10b). The identification information of the user wallet W10b (e.g., the public key of the user wallet W10b) may be transmitted from the user device 10b in association with the asset acquisition request. In these cases, the server 20 can identify the wallet used by user B based on the identification information of the user wallet W10b received from the user device 10b.

[0144] After step S22 or in parallel with step S22, a process of transferring the non-fungible token associated with the non-fungible asset 61 to user B is started in step S23. For example, in step S23, the server 20 generates NFT transfer transaction data for transferring the non-fungible token associated with the non-fungible asset 61 from the operator address of the virtual space operator to the address of user B, and transmits the generated NFT transfer transaction data to the blockchain network 30. The address of user B in the blockchain network 30 is represented by the public key of the user wallet W10b. The NFT transfer transaction data is transmitted to the blockchain network 30 together with digital signature data generated by encrypting the NFT transfer transaction data with the private key of the operator address.

[0145] Next, in step S24, the authenticity of the digital signature data is verified in the blockchain network 30. When the authenticity of the digital signature data is confirmed, the blockchain network 30 records the NFT transfer transaction data associated with the digital signature data in the latest block of the blockchain 31. As a result, it is recorded on the blockchain 31 that the non-fungible token associated with the non-fungible asset 61 has been transferred from the virtual space operator to user B.

[0146] In the NFT transfer transaction data, a fee (called a gas fee) for the blockchain network 30 to perform verification can be specified. This gas fee can be paid, for example, with utility tokens. The gas fee may be borne by the virtual space operator or by user B. When user B bears the gas fee, the amount of utility tokens corresponding to the gas fee is deducted from the balance of user B's utility tokens in response to the verification in step S24.

[0147] User B can use the non-fungible asset 61 acquired from the server 20 in the virtual space provided by the server 20. When the non-fungible asset 61 is used in the virtual space, a display element indicating that the non-fungible asset 61 has been converted into an NFT may be displayed in association with the non-fungible asset 61. For example, on the dress-up screen, an NFT mark may be displayed near the icon of the non-fungible asset 61. Even after the avatar wears the non-fungible asset 61, an NFT mark or other display element indicating that the non-fungible asset 61 has been converted into an NFT may be displayed in association with the non-fungible asset 61 to indicate that the non-fungible asset 61 has been converted into an NFT.

[0148] User B also holds the non-fungible token associated with the non-fungible asset 61, and is therefore able to put the non-fungible asset 61 up for sale on the marketplace. The non-fungible asset 61 put up for sale on the marketplace is displayed on a transaction screen, as shown in Fig. 14. In this way, User B can secondary distribute the non-fungible asset 61 through the marketplace.

[0149] Next, the flow of the process in which user C acquires a non-fungible asset will be described with reference to Fig. 17. It is assumed that the user device 10c used by user C does not have a user wallet connected to the blockchain network 30, and user C does not use a wallet hosted by the server 20.

[0150] First, in step S31, the user device 10c of the user C transmits an asset acquisition request to the server 20 to acquire the non-fungible asset 61. For example, when a purchase button associated with the non-fungible asset 61 is selected on the item purchase screen shown in Fig. 7, an asset acquisition request to acquire the non-fungible asset 61 is transmitted from the user device 10c to the server 20. The price for purchasing the non-fungible asset 61 may be paid in legal tender or points granted to the user.

[0151] When the asset acquisition request is received, in step S32, the user management data 25c is referenced to identify the wallet associated with the user identification information of user C. Since the server 20 does not host a wallet associated with the user identification information of user C, the server 20 determines that a wallet has not been set for user C, and generates a wallet in association with the user identification information of user C. In step S32, the server 20 may display a wallet creation UI on the user device 10c to generate the wallet. The wallet creation UI may be displayed on the user device 10c at any timing before the NFT transfer transaction data is created in step S34 described later after the asset acquisition request is transmitted in step S31. When the wallet for user C is generated, the key pair (a pair of a public key and a private key) of the wallet set for user C in association with the user identification information of user C is stored as part of the user management data 25c.

[0152] After the wallet for user C is set, in step S33, the server 20 grants the non-fungible asset 61 specified in the asset acquisition request to user C. The server 20 can add the asset ID of the non-fungible asset 61 to the owned asset information associated with the user ID of user C in the user management data 25c.

[0153] After the wallet for User C is set up, User C can use the wallet for processes other than acquiring non-fungible assets as shown in Fig. 17. User C can, for example, acquire and consume utility tokens, trade NFTs, and use other wallet functions.

[0154] 15, user A also acquires non-fungible assets using wallet W10a hosted by server 20. Wallet W10a used by user A may be generated when a process requiring a wallet is performed in the service provided by server 20, similar to user C's wallet, or may be generated when user A starts using the service of server 20.

[0155] After step S33 or in parallel with step S33, a process of transferring the non-fungible token associated with the non-fungible asset 61 to user C is started in step S34. For example, in step S34, the server 20 generates NFT transfer transaction data for transferring the non-fungible token associated with the non-fungible asset 61 from the operator address of the virtual space operator to the wallet address of user C set in step S32, and transmits the generated NFT transfer transaction data to the blockchain network 30. The NFT transfer transaction data is transmitted to the blockchain network 30 together with digital signature data generated by encrypting the NFT transfer transaction data with the private key of the wallet W10a.

[0156] Next, in step S35, the authenticity of the digital signature data is verified in the blockchain network 30. When the authenticity of the digital signature data is confirmed, the blockchain network 30 records the NFT transfer transaction data associated with the digital signature data in the latest block of the blockchain 31. As a result, it is recorded on the blockchain 31 that the non-fungible token associated with the non-fungible asset 61 has been transferred from the virtual space operator to user C.

[0157] User C can use the non-fungible asset 61 acquired from the server 20 in the virtual space provided by the server 20. In addition, since User C has also acquired the non-fungible token associated with the non-fungible asset 61, User C can put the non-fungible asset 61 up for sale on the marketplace.

[0158] In FIG. 15 to FIG. 17, the flow of the process for user A to user C to purchase the non-fungible asset 61 from the virtual space operator has been described, but the non-fungible asset 61 may be given to the user by the virtual space operator free of charge. For example, when user A takes a predetermined action in the virtual space provided by the server 20, when any of the activity information of user A becomes equal to or exceeds a predetermined threshold, or when other conditions are satisfied for user A, the non-fungible asset 61 or other non-fungible asset may be given to user A free of charge. In addition, the non-fungible asset 61 or other non-fungible asset may be given (gifted) from another user to user A free of charge. Similar to the free gifting to user A, the non-fungible asset may also be given to user B and other users free of charge. When user A acquires the non-fungible asset 61 by a method other than purchasing it for a fee, the process of step S13 is performed after acquiring the non-fungible asset 61 or in parallel with the process of acquiring the non-fungible asset 61, and the non-fungible token associated with the non-fungible asset 61 acquired by a method other than purchasing is transferred to user A. When user B acquires the non-fungible asset 61 by a method other than purchasing it for a fee, the process of step S23 is performed after acquiring the non-fungible asset 61 or in parallel with the process of acquiring the non-fungible asset 61, and the non-fungible token associated with the non-fungible asset 61 acquired by a method other than purchasing is transferred to user B.

[0159] As described above, user A who uses wallet W10a hosted by server 20 can acquire a non-fungible asset and receive a transfer of a non-fungible token associated with the non-fungible asset in the same manner as user B who uses user wallet W10b provided in user device 10b. Furthermore, user C who is not using a wallet (e.g., wallet W10c) hosted by server 20 at the time of transmitting a request to acquire a non-fungible asset can also receive a transfer of a non-fungible token by using a wallet generated in server 20. Thus, even if user A and user C do not have a wallet on their user devices 10a and 10c, they can acquire a non-fungible asset and hold a non-fungible token associated with the non-fungible asset by using a wallet (e.g., wallet W10a) hosted by server 20.

[0160] Next, with reference to FIG. 18, a process flow in which user B acquires a fungible asset using the user device 10b and converts the acquired asset into an NFT (mints it) will be described.

[0161] First, in step S41, the user device 10b transmits an asset acquisition request to the server 20 to acquire the fungible asset 62. For example, when a purchase button associated with the fungible asset 62 is selected on the item purchase screen shown in FIG.

[0162] When the asset acquisition request is received, in step S42, the server 20 grants the fungible asset 62 specified in the asset acquisition request to user B. The server 20 can add the asset ID of the fungible asset 62 to the owned asset information associated with the user ID of user B in the user management data 25c.

[0163] A user can acquire fungible assets 62 in various ways other than by designating a fungible asset 62 and purchasing it for a fee. For example, a user can obtain a fungible asset selected randomly (or pseudo-randomly) through a gacha (or a loot box) available in the virtual space provided by the server 20. Furthermore, the consideration for purchasing the fungible asset 62 and / or the consideration for using the gacha to obtain a fungible asset may be paid with fiat currency, points given to the user, utility tokens, or crypto assets.

[0164] If user B wishes to convert the fungible asset 62 acquired by purchase or other method into an NFT, a process for requesting NFT is performed in step S43. Specifically, in step S43, an NFT issuance transaction for issuing a non-fungible token is sent to the blockchain network 30 in order to convert the fungible asset 62 into an NFT. In step S44, the smart contract 32 is executed on the blockchain network 30 based on the NFT issuance transaction, whereby a non-fungible token associated with the fungible asset 62 is issued to the address of the user wallet W10b of user B. In addition, when a non-fungible token associated with the fungible asset 62 is issued, NFT issuance transaction data describing a transaction for issuing the non-fungible token is recorded in the latest block of the blockchain 31. In this way, the fungible asset 62 is converted into a non-fungible asset 64.

[0165] After the non-fungible token associated with the non-fungible asset 64 is issued to the address of the user wallet W10b, the user device 10b may notify the server 20 that the fungible asset 62 has been converted into the non-fungible asset 64. This notification may include the token ID of the non-fungible token associated with the non-fungible asset 64. Based on this notification, the server 20 can write the token ID included in the received notification to the token information associated with the asset ID of the fungible asset 62 in the asset management data 25b.

[0166] In order to execute the smart contract 32, a gas fee needs to be paid. The gas fee may be paid by the virtual space operator or by user B. When user B pays the gas fee, the amount of utility tokens corresponding to the gas fee is deducted from the balance of user B's utility tokens in response to the issuance of the non-fungible token.

[0167] As described above, user B can convert the acquired fungible asset 62 into a non-fungible asset 64. The user can convert not only fungible assets purchased from the virtual space operator, but also fungible assets acquired in a manner other than purchase into non-fungible assets by following a flow similar to that of Fig. 18. Fungible assets that can be converted into non-fungible assets include fungible assets acquired through gacha, fungible assets gifted by other users, and fungible assets created by the user.

[0168] User B can continue to use the fungible asset 62 in the virtual space even after sending the NFT issuance transaction to the blockchain network 30 in step S43. For example, user B can continue to use the fungible asset 62 in the virtual space until the NFT is issued on the blockchain network 30, and can use the non-fungible asset 64 converted from the fungible asset 62 in the virtual space after the NFT is issued. Since the non-fungible asset 64 is the same as the fungible asset 62 except that it has been converted into an NFT, user B can use the NFTed non-fungible asset 64 in the virtual space in the same manner as the fungible asset 62 before it was converted into an NFT. For example, as shown in FIG. 7, if the fungible asset 62 is an object representing clothing worn by an avatar, and the avatar of user B was wearing the fungible asset 62 before the fungible asset 62 was NFTed, the avatar of user B can wear the non-fungible asset 64 converted from the fungible asset 62 even after the fungible asset 62 is NFTed and converted into the non-fungible asset 64. Therefore, the avatar of user B can maintain consistency in appearance before and after NFTing. However, a display element indicating that the non-fungible asset 64 is a non-fungible asset (has been NFTed), such as an NFT mark, may be displayed near the non-fungible asset 64 worn by the avatar of user B. The display element indicating that the non-fungible asset 64 has been NFTed causes a difference in the appearance of the avatar of user B.

[0169] Next, with reference to FIG. 19, a process flow in which user A acquires a fungible asset using the user device 10a and converts the acquired asset into an NFT (mints it) will be described.

[0170] First, in step S51, the user device 10a transmits an asset acquisition request to the server 20 to acquire the fungible asset 62. When the asset acquisition request is received, in step S52, the server 20 grants the fungible asset 62 specified in the asset acquisition request to the user A. The process by which the user A acquires the fungible asset 62 may be the same as the process by which the user B acquires the fungible asset 62.

[0171] If user A wishes to convert the fungible asset 62 that he or she has purchased or obtained in any other way into an NFT, in step S53, user A operates user device 10a to send an NFT request requesting that the fungible asset 62 be converted into an NFT from user device 10a to server 20.

[0172] When the NFT request is accepted by the server 20, in step S54, the wallet W10a associated with the user identification information of user A is identified. The wallet W10a associated with the user identification information of user A is identified, for example, by referring to the user management data 25c. In order to NFT the fungible asset 62, the server 20 generates an NFT issuance transaction for issuing a non-fungible token to an address specified by the public key of the wallet W10a, and transmits the generated NFT issuance transaction to the blockchain network 30.

[0173] Next, in step S55, the smart contract 32 is executed on the blockchain network 30 based on the NFT issuance transaction, whereby a non-fungible token associated with the fungible asset 62 is issued to the address of the wallet W10a of the user A hosted by the server 20. In addition, when the non-fungible token associated with the fungible asset 62 is issued, NFT issuance transaction data describing the transaction to issue the non-fungible token is recorded in the latest block of the blockchain 31.

[0174] In this manner, the fungible asset 62 is converted into a non-fungible asset 64 based on the NFT request sent to the server 20 from the user device 10a used by user A. In this manner, in one embodiment, user A, who uses a user device 10a that does not have a wallet, can also NFT a fungible asset by using a wallet hosted on the server 20.

[0175] Next, the flow of the process in which user C acquires a fungible asset using the user device 10c and converts the acquired asset into an NFT (mints it) will be described with reference to Figure 20. In the following description, it is assumed that at the start of the process in Figure 20, the server 20 is not hosting a wallet associated with the user identification information of user C.

[0176] First, in step S61, the user device 10c transmits an asset acquisition request to the server 20 to acquire the fungible asset 62. When the asset acquisition request is received, in step S62, the server 20 grants the fungible asset 62 specified in the asset acquisition request to the user C. The process by which the user C acquires the fungible asset 62 may be the same as the process by which the users A and B acquire the fungible asset 62.

[0177] If user C wishes to convert the fungible asset 62 that he or she has purchased or obtained in any other way into an NFT, in step S63, user C operates user device 10c to send an NFT request requesting that the fungible asset 62 be converted into an NFT from user device 10c to server 20.

[0178] When the NFT request is accepted by the server 20, in step S64, the user management data 25c is referenced to identify the wallet associated with the user identification information of user C. Since the server 20 does not host a wallet associated with the user identification information of user C, the server 20 determines that a wallet has not been set for user C and generates a wallet in association with the user identification information of user C. In step S64, the server 20 may display a wallet creation UI on the user device 10c to generate the wallet. The wallet creation UI may be displayed on the user device 10c at any timing after the asset acquisition request is transmitted in step S61 and before the NFT issuance transaction data is created in step S65, which will be described later. When the wallet for user C is generated, the key pair (a pair of a public key and a private key) of the wallet set for user C in association with the user identification information of user C is stored as part of the user management data 25c.

[0179] Once the wallet for user C is set up, in step S65, the server 20 generates an NFT issuance transaction to issue a non-fungible token to an address identified by the public key of the wallet set up for user C, and sends the generated NFT issuance transaction to the blockchain network 30.

[0180] Next, in step S66, the smart contract 32 is executed on the blockchain network 30 based on the NFT issuance transaction, whereby a non-fungible token associated with the fungible asset 62 is issued to the address of the wallet of user C hosted by the server 20. In addition, when the non-fungible token associated with the fungible asset 62 is issued, NFT issuance transaction data describing the transaction to issue the non-fungible token is recorded in the latest block of the blockchain 31.

[0181] Thus, in one embodiment, in response to an NFT request from user C who is not using a wallet hosted by server 20, a wallet for user C is set up, and fungible assets can be NFTed by using the wallet set up after the NFT request is made.

[0182] As described above, each user who uses the service of the server 20 can convert a fungible asset used in the service of the server 20 into an NFT and convert it into a non-fungible asset, and can hold an NFT associated with this non-fungible asset. Since fungible assets are replicable digital data and replicas are easy to create, their asset value is not easily recognized in the real world. According to the above embodiment, a user can convert a fungible asset used in the service of the server 20 into an NFT, and by allowing the user to hold the issued NFT (that is, by recording the address of the wallet used by the user as the owner address information of the issued NFT), the user can become the owner of a unique NFT. Since NFTs can be bought and sold using crypto assets in the marketplace, and crypto assets can be exchanged for legal tender, by allowing the user to become the owner of the NFT issued by converting a fungible asset into an NFT, the asset value in the real world derived from the fungible asset can be attributed to the user who converted the fungible asset into an NFT.

[0183] In the service provided by the server 20, it is considered that many users would like to obtain NFTs issued by converting highly rare fungible assets into NFTs. For this reason, it is considered that NFTs issued by converting highly rare fungible assets into NFTs in the service provided by the server 20 have high asset value due to the supply and demand relationship. Examples of highly rare fungible assets in the service provided by the server 20 include fungible assets that are provided to users in small numbers by the virtual space operator, fungible assets for which an upper limit is set on the number of fungible assets provided to users by the virtual space operator in the past but are not currently provided, fungible assets provided to users for a limited time, fungible assets created by users, and fungible assets held by popular users. Popular users include users who are followed by a predetermined number of followers or more, and users who have achieved a predetermined rank or higher.

[0184] The server 20 may have a function of sending a notification to a user who owns a highly rare fungible asset, recommending that the fungible asset be converted into an NFT. For example, the server 20 may manage the number of fungible assets granted to the user for each fungible asset, identify a fungible asset for which the number of fungible assets granted is smaller than a threshold value as a recommended asset, and send an NFT recommendation notification to a user device of a user who owns the recommended asset. The NFT recommendation notification may include an asset ID that identifies the recommended asset. A user device that receives the NFT recommendation notification can identify the recommended asset from among the fungible assets owned by the user based on the asset ID of the recommended asset included in the NFT recommendation notification.

[0185] When sending an NFT recommendation notification to a user device of a user, the server 20 can refer to the user management data 25c to determine whether the user is using a wallet. If a user to whom the NFT recommendation notification is sent is not using a wallet hosted by the server 20, the server 20 may display the above-mentioned wallet generation UI on the user device of the user. This allows a wallet to be generated for a user who has received an NFT recommendation notification before sending an NFT request to the server 20, so that after making a request to NFT a fungible asset, the fungible asset can be NFTed smoothly (i.e., without being interrupted by the process for generating the wallet).

[0186] A user device (e.g., user device 10a, 10b, 10c) can display an asset list that lists fungible assets owned by a user who uses the user device. The user device can display the recommended assets in the asset list, distinguishing them from other fungible assets. An example of an asset list displayed on a user device is shown in FIG. 21. In the example of FIG. 21, an asset list including five fungible assets, assets A1 to A5, is displayed. If asset A1 is the recommended asset, as shown in the figure, the user device displays the icon representing asset A1 more emphasized than the other icons.

[0187] The server 20 can calculate the market value of each fungible asset based on a predetermined algorithm, and manage the calculated market value of each fungible asset in association with the asset ID of each fungible asset. Since fungible assets are expected to be used in the virtual space provided by the server 20, the market value is calculated based on factors that affect the supply and demand of each fungible asset in the virtual space. Factors that affect the market value of a fungible asset may include one or more of the number of fungible assets provided to a user by the virtual space operator (supply number), the upper limit of the number of fungible assets that can be provided to a user by the virtual space operator (supply upper limit number), whether or not the fungible asset is currently being provided by the virtual space operator (availability), and the elapsed time since the fungible asset was provided to a user. The server 20 may manage a wish list that manages digital assets (e.g., items) that each user wishes to obtain for each user of the virtual space. The wish list may be stored in the storage 25 or other storage that the server 20 can access. The wish list can store asset IDs of digital assets that each user wishes to obtain, in association with the user ID of each user. The wish list can be updated at any time in response to instructions from the user. The server 20 can count the number of users who have registered in the wish list for each fungible asset, and calculate the market value of each fungible asset so that the market value increases as the number of users increases. Factors that affect the market value of a fungible asset are not limited to the above factors.

[0188] The user device may display fungible assets included in the asset list in descending order of market value. For example, in the asset list shown in Fig. 21, asset A1 with the highest market value may be displayed at the top, and fungible assets with lower market values ​​may be displayed further down. In the asset list, the user device may display fungible assets with market values ​​higher than a predetermined reference value in a manner that distinguishes them from other fungible assets.

[0189] As described above, in the user device, highly rare fungible assets and fungible assets with high market value can be displayed in a position that is likely to be selected by the user. This allows the user to easily discover and select fungible assets that are expected to have a high value when issued as an NFT when converted into an NFT.

[0190] A user can select a fungible asset to be converted into an NFT from the asset list and convert the selected fungible asset into an NFT. For example, when an asset A1 is selected by a user operation in the asset list shown in FIG. 21, the user device displays an NFT issuance screen for converting the asset A1 into an NFT. An example of an NFT issuance screen displayed on the user device is shown in FIG. 22. As shown in the figure, the NFT issuance screen includes a window 71 in which information about the asset A1 is displayed, and an NFT conversion button 72 for performing NFT conversion. The window 71 displays information about the asset A1 selected in the item list. In the example shown in the figure, the window 71 displays the upper limit (500) of the asset A1 that can be provided to the user by the virtual space operator, the total number of assets provided (324) that have actually been provided to the user so far, the NFT issuance upper limit (10) indicating the upper limit of NFTs that can be issued by converting the asset A1 into an NFT, and the number of NFTs issued (7) indicating the number of NFTs that have actually been issued by converting the asset A1 into an NFT so far. The NFT issuance screen may include information other than the above. Based on the information about asset A1 displayed in window 71, the user can evaluate the rarity of asset A1 and the asset value of the NFT issued by converting asset A1 into an NFT.

[0191] If the user wishes to convert the asset A1 into an NFT, the user selects the NFT button 72. When the NFT button 72 is selected on the user device, the asset A1 is converted into an NFT in a process flow according to whether or not the user device has a wallet. If the user device has a wallet, an NFT issuance transaction is sent to the blockchain network 30 to convert the asset A1 into an NFT. In the blockchain network 30, the smart contract 32 is executed on the blockchain network 30 based on the NFT issuance transaction, and a non-fungible token associated with the asset A1 is issued to the wallet address of the user device (see the process of step S44 in FIG. 18). If the user device does not have a wallet, an NFT request is sent from the user device to the server 20 to request NFT of the asset A1. If the server 20 hosts the wallet of the user of the user device, an NFT issuance transaction is generated in the server 20, as in step S54 in FIG. 19, and the generated NFT issuance transaction is sent to the blockchain network 30. On the other hand, if the server 20 does not host a wallet for the user of the user device, the user's wallet is set on the server 20 by processing similar to step S64 in FIG. 20, an NFT issuance transaction is generated on the server 20 by processing similar to step S65, and the generated NFT issuance transaction is sent to the blockchain network 30. In the blockchain network 30, a smart contract 32 is executed on the blockchain network 30 based on the NFT issuance transaction, and a non-fungible token associated with the asset A1 is issued to the address of the wallet hosted on the server 20.

[0192] The server 20 can determine an upper limit on the number of NFTs that can be issued for each fungible asset. The upper limit on the number of NFTs that can be issued for each fungible asset is described in, for example, the smart contract 32. The server 20 can indirectly determine an upper limit on the number of NFTs that can be issued by converting a fungible asset into an NFT by determining an upper limit on the supply quantity of fungible assets of the same type. In other words, if an upper limit on the number of fungible assets that can be supplied to a user is determined, the number of NFTs that can be issued by converting the fungible asset into an NFT will not exceed the upper limit on the supply of the fungible asset.

[0193] Next, a co-starring function in a video transmission service will be described. The co-starring function in a video transmission service means a function that allows two or more users to co-star in a video through their respective avatars. In the following description, it is assumed that, as shown in FIG. 23, user B is watching a video including user A's avatar 70a on user device 10b, and user B applies to co-star with user A during the viewing.

[0194] As shown in FIG. 23, a video including an avatar 70a of a user A is being played on a user device 10b of a user B. The avatar 70a is wearing a non-fungible asset 61. In the video being played, an NFT mark 61a (not shown in FIG. 23) may be displayed near the non-fungible asset 61 worn by the avatar 70a or superimposed on the non-fungible asset 61. In the user device 10b, a comment 72 posted by a viewer and a co-starring request button 73 are overlaid on the video being played. When the co-starring request button 73 is selected on the user device 10b, a co-starring request is sent from the user device 10b to the server 20.

[0195] When the co-starring application is received, the server 20 judges whether or not to permit user B and user A to co-star. When user B and user A are permitted to co-star, avatar 70b of user B appears in addition to avatar 70a of user A in the video being viewed, as shown in FIG. 24. Video data of the video (co-starring video) including these avatars 70a and 70b is transmitted from the server 20. In this way, user A and user B can co-star in the video via their respective avatars 70a and 70b.

[0196] When a co-starring request is made by user B, the server 20 may permit co-starring with user A on the condition that user B possesses a specific non-fungible asset, and may reject the co-starring if user B does not possess any specific non-fungible asset. In this manner, possession of a specific non-fungible asset may be set as a condition for permission of co-starring. In this specification, a specific non-fungible asset that a co-starring requesting user (user B in the above example) must possess in order for a co-starring request from the co-starring requesting user to be permitted may be referred to as a "co-starring non-fungible asset." In one embodiment, the co-starring non-fungible asset that user B must possess is a native non-fungible asset (e.g., the non-fungible asset 61). In another embodiment, the co-starring non-fungible asset is a converted non-fungible asset (e.g., the non-fungible asset 64). The co-starring non-fungible asset may be at least one of a native non-fungible asset and a converted non-fungible asset. Possession of both a native non-fungible asset and a converted non-fungible asset by user B may be set as a condition for permission of co-starring by user B.

[0197] In one embodiment, the co-starring non-fungible asset may be a converted non-fungible asset that has been NFTed by user A. In this way, in order to be permitted to perform together with user A, the co-starring requesting user is required to possess a converted non-fungible asset that has been NFTed by user A. By making it a condition that the user possesses a converted non-fungible asset that has been NFTed by user A in order to be permitted to perform together with user A, the utility of the NFT associated with the converted non-fungible asset that user A has NFTed can be increased, and the value of the NFT can be improved.

[0198] In another embodiment, the non-fungible asset required for collaboration with user A may be a converted non-fungible asset NFTed by user B, or may be a converted non-fungible asset NFTed by a user other than user A and user B.

[0199] In one embodiment, the co-starring non-fungible asset may be a non-fungible asset that meets a certain condition. The non-fungible asset that meets the certain condition and can be used as the co-starring non-fungible asset may be a native non-fungible asset issued during a certain period of time, or a converted non-fungible asset that has been NFTed during a certain period of time. The non-fungible asset that meets the certain condition and can be used as the co-starring non-fungible asset may be a specific type of non-fungible asset. The specific type of non-fungible asset may be a co-starring ticket issued for a co-starring or a co-starring ticket that has been NFTed for a co-starring.

[0200] The non-fungible asset for performing together with user A may be a non-fungible asset that has been NFTed by user A. In other words, in order for user B to be permitted to perform together with user A, it may be a condition that user B possesses a non-fungible asset that has been NFTed by user A. User A can generate a non-fungible asset for performing together with himself by NFTing a fungible asset. User A can adjust the amount of issuance of the non-fungible asset for performing together depending on the capacity to accept performances, his branding strategy, and other factors. The non-fungible asset for performing together that is NFTed by user A may have a validity period set so that it can be used as a non-fungible asset for performing together.

[0201] Next, with reference to FIG. 25, the NFT conversion of video data transmitted from the server 20 will be described. The video data transmitted from the server 20 may be archived in the storage 25 of the server 20 for a predetermined period (for example, one week from the end of distribution). FIG. 25 shows video data 90 in which a distributed video of user A is archived. User A can specify a part of the archived video data 90 and convert the part of the section into an NFT. For example, user A can select a partial video 90a, which is a part of the video data 90, from the video data 90 and transmit an NFT conversion request to the server 20 to convert the partial video 90a into an NFT. The partial video 90a may be stored in the storage 25 as a partial video file separate from the video data 90. User A may convert the entire archived video data 90 into an NFT.

[0202] The video data 90 may be archived data of a video of a live event held at a virtual live venue set up by user A in a virtual space. User A can earn revenue by converting the video data 90 of a popular live event or a partial video 90a that is a part of the video data 90 into an NFT and selling the NFT associated with the NFT-converted video data 90 or the partial video 90a.

[0203] The video data 90 may be archived data of a video shot from the viewpoint of the user A's avatar while the user A's avatar moves in a virtual space. Since the video shot from the viewpoint of the user A's avatar reflects the personality of the user A, the user A can convert the video data 90 corresponding to the video in which the user A's personality is reflected or a partial video 90a that is a part of the video data 90 into an NFT. The user A can earn revenue by selling the NFT associated with the NFT-converted video data 90 or the partial video 90a.

[0204] The video data 90 may be archived data of a video of a game played by user A.

[0205] A plurality of virtual cameras may be set in the virtual live venue. The virtual cameras installed in the live venue may include a first virtual camera arranged in the front row of the stage of the live venue and facing the direction of the stage, a second virtual camera arranged on the stage of the live venue and facing the direction of the audience seats, and a third virtual camera that tracks one of the avatars appearing or participating in the live performance. The video data 90 may be a set of a plurality of video data shot in the same time period by such a plurality of virtual cameras. For example, the video data 90 may be a set of first video data representing a video shot by the first virtual camera, second video data representing a video shot by the second virtual camera, and third video data representing a video shot by the third virtual camera. User A may select a partial video 90a from the first video data, the second video data, and the third video data, and convert the selected partial video 90a into an NFT. This allows a variety of video data to be converted into an NFT. There is no limit to the number of virtual cameras installed in the virtual live venue, and four or more virtual cameras may be installed to shoot an event held at the live venue. The event captured by the multiple virtual cameras is not limited to a live event at a virtual live venue. A closed space installed in a virtual space may be captured by the multiple virtual cameras, and the videos captured by each of the multiple virtual cameras may be archived as multiple video data.

[0206] User A may select multiple partial videos 90a from the first video data, the second video data, and the third video data, connect the selected multiple partial videos to create an edited partial video, and convert this edited partial video into an NFT. A user who can edit video may earn revenue by converting the edited partial video into an NFT and selling the NFT associated with the NFT-converted edited partial video.

[0207] The video represented by the video data 90 includes a view of a virtual space. The partial video 90a may include a view of a virtual space including the avatar 70a of the user A. The video data 90 including a view of a virtual space may include a section in which the avatar 70a of the user A exists in the view and a section in which the avatar 70a does not exist in the view. The user A can select a section in the video data 90 in which the avatar 70a exists in the view of the virtual space as the partial video 90a. The area in which the avatar 70a exists in the view of the virtual space included in the video data 90 may be extracted based on a predetermined algorithm based on the video data 90 or related data stored in association with the video data 90. For example, together with the video data 90, setting information of a virtual camera and coordinate information representing the position of the avatar 70a may be stored for each timeline. In this case, whether or not the avatar 70a exists in the view of the virtual space in each timeline is determined based on the setting information of the virtual camera in each timeline and the coordinate information representing the position of the avatar 70a. To assist user A in selecting a partial video 90a, user device 10a of user A may display an area of ​​video data 90 in which avatar 70a is present within a view of the virtual space in a manner that distinguishes it from other areas.

[0208] The server 20 can perform the process of converting the partial video 90a specified in the NFT request into an NFT, in the same way as when an NFT request is received for a fungible asset. In order for user A to make an NFT request, it is necessary for user A to obtain a user wallet and connect the user wallet to the blockchain network 30 (to obtain an address on the blockchain network 30).

[0209] The server 20 does not delete the NFTed partial video 90a from storage even after the archive period has elapsed. Data of the video data 90 other than the NFTed partial video 90a is deleted after the archive period has elapsed. The server 20 also stores the partial video 90a in the file system 40 for backup purposes. In this way, the NFTed partial video 90a continues to be held by the server 20 and / or the file system 40 so that it can be viewed upon user request even after the archive period has elapsed.

[0210] A co-starring video in which user A and user B appear together may also be archived in storage 25 of server 20 for a predetermined period (e.g., one week after the end of distribution). FIG. 26 shows video data 95 corresponding to the co-starring video. User A can specify a portion of the archived video data 95 and convert that portion into an NFT, similar to selecting partial video 90a in video data 90. For example, user A can select partial video 95a, which is a portion of video data 95, from video data 95, and transmit an NFT request to server 20 to convert that partial video 95a into an NFT.

[0211] Since the co-starring video includes not only user A's avatar 70a but also user B's avatar 70b, user B can also specify a section of the video data 95 (for example, a section corresponding to partial video 95b) and convert that section into an NFT.

[0212] In the smart contract 32, when an NFT generated from the video data 95 of a co-starring video is traded, a rule for distributing the revenue may be defined. For example, the smart contract 32 may define a rule for distributing the consideration to user A and user B at a predetermined ratio when an NFT generated from the video data 95 is sold. In a co-starring video generated by user B participating in a distributed video of user A, user A is the host and user B is the guest. When an NFT generated from the video data 95 of a co-starring video is traded, the consideration may be paid to the user who is the host more than to the user who is the guest.

[0213] The conversion of a partial video included in the video data of a co-starring video into an NFT may be executable when permission is obtained from all users who appeared in the co-starring video.

[0214] Next, some of the effects achieved by the above-described embodiment will be described.

[0215] In the above embodiment, a user A using a user device 10a without a wallet can also use a non-fungible asset in the virtual space provided by the server 20 by using a wallet W10a generated in the server 20 in association with the user identification information of the user A. Therefore, in the virtual space provided by the server 20 in which non-fungible assets are used, a user A using a user device 10a without a wallet and a user B using a user device 10b with a user wallet W10b can coexist. In other words, both a user A using a user device 10a without a wallet and a user B using a user device 10b with a user wallet W10b can participate in the virtual space provided by the server 20 through their own avatars. Therefore, according to the above embodiment, a user (e.g., user A) who does not use a wallet in a user device can coexist with a user who uses a wallet in a user device in the virtual space (or its platform) provided by the server 20.

[0216] In the above embodiment, in the virtual space provided by the server 20, in addition to user A who uses a wallet hosted by the server 20 and user B who uses a user wallet W10b provided in the user device 10b, user C who does not use a wallet can also coexist. For example, user C can participate in the virtual space using his or her avatar and interact with user A and user B who use wallets in this virtual space. In addition, when user C performs a process using a wallet, the wallet is generated in the server 20 in association with user C's user identification information, so that user C can also use non-fungible assets and NFTs. In this way, user C can use the service provided by the server 20 without using a wallet, and start using the wallet when the need arises.

[0217] Even if user A does not have a wallet on his / her user device 10a, he / she can make a profit by listing non-fungible assets on the marketplace and connecting to the blockchain network 30 using a wallet hosted in the server 20 in association with his / her user identification information.

[0218] According to the above embodiment, functions using the blockchain network 30 can be provided not only to user B who uses user device 10b equipped with user wallet W10b, but also to users A and C who use user devices 10a and 10c, respectively, that are not equipped with a wallet, by using a wallet hosted by server 20. As a result, the above embodiment can contribute to expanding the user base that uses the blockchain network.

[0219] In the above embodiment, a user who owns a fungible asset can convert the fungible asset into an NFT. When a user uses a fungible asset in a virtual space, the fungible asset may become an item that symbolizes the user. In the real world, when a celebrity repeatedly wears the same clothes, ready-made clothes that are originally fungible may become an item that symbolizes the celebrity. Similarly, in the virtual space, a fungible asset may become an item that symbolizes a certain user. In this case, the user will want the fungible asset to be unique. According to the above embodiment, the fungible asset acquired from the server 20 is tokenized as a non-fungible token in response to a tokenization request from the user, so that the user's desire to convert the fungible asset into an NFT can be met. Since NFTs are traded in the real world and have asset value, by providing an opportunity to convert fungible assets provided by the server 20 or fungible assets created by the user into NFTs, the user can be given an opportunity to form assets in the real world through the use of the services provided by the server 20.

[0220] In the above embodiment, from a video including a virtual space including a first avatar of a first user and a second avatar of a second user, partial videos in which the first user and the second user are different from each other can be tokenized as non-fungible tokens. In this way, partial videos are extracted from a video in which multiple users participate via avatars according to the individuality of each user, and partial videos in which the individuality is expressed can be tokenized as non-fungible tokens.

[0221] The video transmission system 1 shown in FIG. 1 is an example of a system to which the present invention can be applied, and the system to which the present invention can be applied is not limited to that shown in FIG. 1. The video transmission system 1 to which the present invention can be applied may not include some of the components shown in the figure. For example, when a non-fungible token is implemented in a full on-chain, the video transmission system 1 may not include a file system 40. The video transmission system 1 may include components not shown in the figure. Although only three user devices 10 are shown in FIG. 1 for the sake of simplicity of explanation, the video transmission system 1 may include any number of user devices 10, such as four or more. The video transmission system 1 may include a cloud environment for distributing and processing the processing to be performed by the user devices 10 or the server 20.

[0222] In the video transmission system 1, there is no particular restriction on the storage location of data. For example, various data that can be stored in the storage 25 may be stored in a storage or a database server that is physically separate from the storage 25. In this specification, data described as being stored in the storage 25 may be stored in a single storage, or may be distributed and stored in multiple storages. In this specification and the claims, when the term "storage" is used simply, it may refer to either a single storage or a collection of multiple storages, as far as the context permits.

[0223] The embodiments of the present invention are not limited to the above-described embodiments, and various modifications are possible within the scope of the gist of the present invention. For example, a part or all of the functions executed by the processor 21 may be realized by a processor not specified in this specification, without departing from the spirit of the invention. Although the processor 21 is illustrated as a single component in FIG. 5, the processor 21 may be a collection of multiple physically separate processors. In this specification, a program described as being executed by the processor 21 or instructions included in the program may be executed by a single processor, or may be executed in a distributed manner by multiple processors. In addition, a program executed by the processor 21 or instructions included in the program may be executed by one or more virtual processors.

[0224] The programs executed by the processor 21 may be stored in various types of non-transitory computer readable media other than the illustrated storage. The non-transitory computer readable media include various types of tangible storage media. Examples of the non-transitory computer readable media include magnetic recording media (e.g., flexible disks, magnetic tapes, hard disk drives), magneto-optical recording media (e.g., magneto-optical disks), Compact Disc Read Only Memory (CD-ROM), CD-R, CD-R / W, and semiconductor memory (e.g., mask ROM, Programmable ROM (PROM), Erasable PROM (EPROM), flash ROM, Random Access Memory (RAM)).

[0225] As described above, the present invention is applicable not only to the video transmission system 1 but also to other systems. For example, the present invention can be applied to a game system in which user devices and a server cooperate to provide a game. The game system to which the present invention is applied can adopt an architecture similar to that shown in FIG. 1. More specifically, the game system to which the present invention is applied is realized by modifying the video transmission system shown in FIG. 1 as follows. That is, the user devices 10a to 10c are configured to realize various functions related to the game by executing an instruction set included in a game application program. The server 20 is configured to provide various functions related to the game to the user devices 10a to 10c. The user devices 10a to 10c and the server 20 can cooperate with each other to realize various functions of the game.

[0226] In the following, an embodiment in which the present invention is applied to a game system will be described. In the following description, the term "game system" can mean a game system to which the present invention is applicable, and the term "game" can mean a game provided by a game system to which the present invention is applied. In a game provided by a game system, various game media can be used. The game media is electronic data used in the game. The game media can include, for example, characters, cards, items, points, in-service currency (or in-game currency), tickets, characters, avatars, parameters, and other electronic data used in the game. The game media can be acquired, owned, used, managed, exchanged, synthesized, enhanced, sold, discarded, or donated by a user in the game. The game media may be used in a manner other than the above.

[0227] Various digital assets are used in games. Game media is an example of a digital asset used in a game. Various objects constituting a game space can also be a type of digital asset. The game space may be, for example, a three-dimensional virtual space in which a user's character can move. The digital assets used in this game can be classified into a number of categories, including fungible assets and non-fungible assets, similar to the digital assets used in the virtual space of the video transmission service described above.

[0228] The description of fungible assets and non-fungible assets used in the video transmission system 1 included in this specification also applies to fungible assets and non-fungible assets used in a game system to which the present invention is applied. For example, in a game provided by a game system to which the present invention is applied, a user may obtain an item that is a non-fungible asset and use the obtained non-fungible asset in the game. In addition, a user may obtain an item that is a fungible asset and convert the item that is a fungible asset into an NFT.

[0229] If a game includes quests or missions that are intended to be completed by a user, obtaining a predetermined non-fungible asset may be a condition for completing the quest or mission. Alternatively, possession of a predetermined non-fungible asset may be a condition for participating in a quest or mission included in the game.

[0230] When the present invention is applied to a game system that provides a game, the plots of land that make up the game space (virtual space) of that game, the buildings within the game space, and other components of the game space may be converted into NFTs, and these NFT-converted components of the game space may be granted or sold to users.

[0231] As described with respect to the video transmission system 1, in a game provided by a game system to which the present invention is applied, a user who uses a wallet provided in a user device, a user who uses a wallet hosted by a server, and a user who does not use a wallet can coexist. For example, a user A who uses a user device 10a that does not have a wallet can use a non-fungible asset in a game provided by the server 20 by using a wallet W10a generated in the server 20 in association with the user identification information of the user A. Therefore, in a game in which a non-fungible asset provided by the server 20 is used, a user A who uses a user device 10a that does not have a wallet and a user B who uses a user device 10b that has a user wallet W10b can coexist. In addition, in a game provided by a game system to which the present invention is applied, a user C who does not use a wallet can also coexist. For example, the user C can play a game with the user A and the user C by using items and characters that are fungible assets. When the user C performs a process using a wallet, the wallet is generated in the server 20 in association with the user identification information of the user C, so that the user C can also use a non-fungible asset or an NFT. In this way, user C can use the services provided by server 20 without using a wallet, and can start using the wallet when the need arises.

[0232] The game system to which the present invention is applied can provide various types of games, including role-playing games, shooting games, battle games using card games, and various other games.

[0233] A game provided by a game system to which the present invention is applied may be provided to a user via a user device that stores an application program for the game, as described above. In other words, a game provided by a game system to which the present invention is applied may be a native game that can be played by a native application. The application program may be downloaded to a user device from a digital content distribution platform. A game provided by a game system to which the present invention is applied may be a web game executed by a web browser, rather than a dedicated application for providing the game.

[0234] The game system to which the present invention is applied may be a game that utilizes a Move to Earn mechanism (hereinafter, referred to as a "Move to Earn game"). In the Move to Earn game, a user can earn tokens, points, experience points, and / or other rewards that can be used in the game according to the distance traveled by the user while holding or wearing the user device. In the Move to Earn game, an NFT-ized item may be given to the user according to the distance traveled by the user.

[0235] The game system to which the present invention is applied may be combined with a video transmission system 1. The game system to which the present invention is applied may be incorporated into the video transmission system 1. For example, in the game system to which the present invention is applied, a user may play a game using a user device and distribute a video including a screen of the game being played via a server. A user of the game system to which the present invention is applied can perform so-called game commentary. The video including a game screen distributed by the user can be viewed by other users.

[0236] The present invention is applicable not only to the video transmission system 1 and the game system, but also to various distributed application services using blockchain technology (for example, the above-mentioned blockchain network 30). For example, the present invention is also applicable to DeFi (decentralized finance) services and insurance services using blockchain technology.

[0237] Although the processes and procedures described herein are described as being performed by a single device, software, component, or module, such processes or procedures may be performed by multiple devices, multiple software, multiple components, and / or multiple modules. Furthermore, although the data, tables, or databases described herein are described as being stored in a single memory, such data, tables, or databases may be stored in multiple memories in a single device or multiple memories distributed across multiple devices. Furthermore, the software and hardware elements described herein may be realized by integrating them into fewer components or breaking them down into more components.

[0238] In the processing procedures described in this specification, particularly in processing procedures described using flow charts or sequence diagrams, it is possible to omit some of the steps that make up the processing procedures, to add steps that are not explicitly stated as steps that make up the processing procedures, and / or to rearrange the order of the steps, and processing procedures in which such omissions, additions, or changes in order have been made are also included within the scope of the present invention as long as they do not deviate from the spirit of the present invention.

[0239] The designations "first," "second," "third," and the like in this specification and claims are given to identify components and do not necessarily limit the number, order, or content. Furthermore, numbers for identifying components are used in different contexts, and a number used in one context does not necessarily indicate the same configuration in another context. Furthermore, a component identified by a certain number is not prevented from also having the function of a component identified by another number.

[0240] This specification also discloses the following techniques:

[0241] [Appendix 1] A video data transmission method for transmitting video data including a view of a virtual space in which avatars associated with each of a plurality of users including a first user can participate, comprising: generating a first wallet in association with first user identification information that identifies the first user in the virtual space; In response to a first acquisition request from the first user, granting a first non-fungible asset to the first user among one or more non-fungible assets that are digital assets used in the virtual space and are tokenized as a non-fungible token, and transferring a first non-fungible token associated with the first non-fungible asset to an address of the first wallet; A video data transmission method comprising:

[0242] [Appendix 2] In response to a second acquisition request from the first user, granting to the first user a first fungible asset among one or more fungible assets that are used in the virtual space and are not tokenized as a non-fungible token; performing a tokenization process for tokenizing the first fungible asset as a non-fungible token in response to a tokenization request from the first user; The video data transmission method according to [Appendix 1], further comprising:

[0243] [Appendix 3] The first wallet is generated in response to the first user needing the first wallet. A video data transmission method according to [Appendix 1] or [Appendix 2].

[0244] [Appendix 4] The first wallet is generated in response to receiving the first acquisition request, receiving the tokenization request, or creating the first user identification information. A video data transmission method as described in [Appendix 2].

[0245] [Appendix 5] The one or more processors may further include transmitting transfer transaction data to a blockchain network to record a transaction on a blockchain transferring a holder of a first non-fungible token associated with the first non-fungible asset to an address of the first wallet. A video data transmission method according to any one of [Appendix 1] to [Appendix 4].

[0246] [Appendix 6] The method further includes the step of performing a token issuing process for issuing a utility token that can be used in the virtual space. A video data transmission method according to any one of [Appendix 1] to [Appendix 5].

[0247] [Appendix 7] The utility token is exchangeable for crypto assets other than the utility token. A video data transmission method as described in [Appendix 6].

[0248] [Appendix 8] The utility token is granted to the first user in response to the activity of the first user in the virtual space. A video data transmission method according to [Appendix 6] or [Appendix 7].

[0249] [Appendix 9] In response to the first acquisition request, the utility token of the first user is consumed in an amount corresponding to the price of the first non-fungible asset. A video data transmission method as described in [Appendix 8].

[0250] [Appendix 10] The method further includes the step of performing a token issuing process for issuing a utility token that can be used in the virtual space, The cost of the tokenization process is paid for by the utility token of the first user. A video data transmission method according to any one of [Appendix 1] to [Appendix 9].

[0251] [Appendix 11] The method further includes the step of performing a token issuing process for issuing a utility token that can be used in the virtual space, The cost of recording the transfer transaction data on the blockchain network is paid for by the utility tokens of the first user. A video data transmission method as described in [Appendix 5].

[0252] [Appendix 12] a first avatar associated with the first user participates in the virtual space; The one or more processors further include a step of performing a process for tokenizing, in response to a first video tokenization request from the first user, a first partial video that is part of the video data and includes a view of the virtual space including the first avatar, as a non-fungible token. A video data transmission method according to any one of [Appendix 1] to [Appendix 11].

[0253] [Appendix 13] a second avatar associated with a second user is further participating in the virtual space; and performing a process for tokenizing a second partial video, the second partial video being a part of the video and including a view of the virtual space including the second avatar, as a non-fungible token in response to a second video tokenization request from the second user. A video data transmission method as described in [Appendix 12].

[0254] [Appendix 14] The method further comprises a step of transmitting video data of a co-starring video including the first avatar and the second avatar when the second user possesses at least one of the one or more non-fungible assets in response to receiving a co-starring request from a second user requesting a co-starring between a second avatar associated with the second user and a first avatar associated with the first user, and refusing to co-star with the first avatar when the second user does not possess any of the one or more non-fungible assets. A video data transmission method according to any one of [Appendix 1] to [Appendix 11].

[0255] [Appendix 15] The method further includes a step of transmitting video data of a co-starring video including the first avatar and the second avatar in response to receiving a co-starring request from a second user requesting a co-starring between a second avatar associated with the second user and a first avatar associated with the first user, if the second user holds a converted non-fungible asset in which at least one of the one or more fungible assets is tokenized as a non-fungible token, and refusing to co-star with the first avatar in the case where the second user does not hold the converted non-fungible asset. A video data transmission method according to any one of [Appendix 1] to [Appendix 14].

[0256] [Appendix 16] The virtual space includes a closed space, The method further includes a step of permitting a first avatar associated with the first user to enter the closed space when the first user possesses at least one of the one or more non-fungible assets, and refusing to allow the first avatar to enter the closed space when the first user does not possess any of the one or more non-fungible assets. A video data transmission method according to any one of [Appendix 1] to [Appendix 15].

[0257] [Appendix 17] The virtual space includes a closed space, The method further includes a step of permitting a first avatar associated with the first user to enter the closed space when the first user holds a converted non-fungible asset in which at least one of the one or more fungible assets is tokenized as a non-fungible token, and refusing to allow the first avatar to enter the closed space when the first user does not hold any of the converted non-fungible assets. A video data transmission method according to any one of [Appendix 1] to [Appendix 16].

[0258] [Appendix 18] The first user owns a plurality of wearable assets that can be worn by a first avatar of the first user in the virtual space, among the one or more fungible assets; The one or more processors further comprise a step of performing processing to tokenize the set of the plurality of worn assets as a non-fungible token in response to a tokenization request from the first user. A video data transmission method according to any one of [Appendix 1] to [Appendix 17].

[0259] [Appendix 19] A video data transmission system including one or more processors, the system transmitting video data including a view of a virtual space in which avatars associated with each of a plurality of users including a first user can participate, the system comprising: The one or more processors execute computer readable instructions to: generating a first wallet in association with first user identification information that identifies the first user in the virtual space; In response to a first acquisition request from the first user, granting to the first user a first non-fungible asset among one or more non-fungible assets which are digital assets used in the virtual space and have been tokenized as a non-fungible token, and transferring to the address of the first wallet a first non-fungible token associated with the first non-fungible asset; Video data transmission system.

[0260] [Appendix 20] A video data transmission program for causing one or more processors to transmit video data including a view of a virtual space in which avatars associated with each of a plurality of users including a first user can participate, the program comprising: the one or more processors; generating a first wallet in association with first user identification information that identifies the first user in the virtual space; In response to a first acquisition request from the first user, granting a first non-fungible asset to the first user among one or more non-fungible assets that are digital assets used in the virtual space and are tokenized as a non-fungible token, and transferring a first non-fungible token associated with the first non-fungible asset to an address of the first wallet; A video data transmission program that executes the above.

[0261] The inventions described in the claims of the original application of this application are set forth below. [1] A video data transmission method for transmitting video data including a view of a virtual space in which avatars associated with each of a plurality of users including a first user can participate, comprising: generating a first wallet in association with first user identification information that identifies the first user in the virtual space; In response to a first acquisition request from the first user, granting to the first user a first non-fungible asset among one or more non-fungible assets that are digital assets used in the virtual space and have been tokenized as a non-fungible token, and transferring to the address of the first wallet a first non-fungible token associated with the first non-fungible asset; A video data transmission method comprising: [2] In response to a second acquisition request from the first user, granting to the first user a first fungible asset among one or more fungible assets that are used in the virtual space and are not tokenized as a non-fungible token; performing a tokenization process for tokenizing the first fungible asset as a non-fungible token in response to a tokenization request from the first user; The video data transmission method according to [1], further comprising: [3] The first wallet is generated in response to the first user needing the first wallet. A video data transmission method according to [1]. [4] The first wallet is generated in response to receiving the first acquisition request, receiving the tokenization request, or creating the first user identification information. A video data transmission method according to [2]. [5] The one or more processors may further include transmitting transfer transaction data to a blockchain network to record a transaction on a blockchain transferring a holder of a first non-fungible token associated with the first non-fungible asset to an address of the first wallet. A video data transmission method according to [1]. [6] The method further includes the step of performing a token issuing process for issuing a utility token that can be used in the virtual space. A video data transmission method according to [1]. [7] The utility token is exchangeable for crypto assets other than the utility token. A video data transmission method according to [6]. [8] The utility token is granted to the first user in response to the activity of the first user in the virtual space. A video data transmission method according to [6]. [9] In response to the first acquisition request, the utility token of the first user is consumed in an amount corresponding to the price of the first non-fungible asset. A video data transmission method according to [7].

[10] The method further includes the step of performing a token issuing process for issuing a utility token that can be used in the virtual space, The cost of the tokenization process is paid for by the utility token of the first user. A video data transmission method according to [2].

[11] The method further includes the step of performing a token issuing process for issuing a utility token that can be used in the virtual space, The cost of recording the transfer transaction data on the blockchain network is paid for by the utility tokens of the first user. A video data transmission method according to [5].

[12] a first avatar associated with the first user participates in the virtual space; The one or more processors further include a step of performing a process for tokenizing, in response to a first video tokenization request from the first user, a first partial video that is part of the video data and includes a view of the virtual space including the first avatar, as a non-fungible token. A video data transmission method according to any one of [1] to

[11] .

[13] a second avatar associated with a second user is further participating in the virtual space; and performing a process for tokenizing, in response to a second video tokenization request from the second user, a second partial video, which is part of the video data and includes a view of the virtual space including the second avatar, as a non-fungible token.

[12] A video data transmission method according to the present invention.

[14] The method further comprises a step of transmitting video data of a co-starring video including the first avatar and the second avatar when the second user possesses at least one of the one or more non-fungible assets in response to receiving a co-starring request from a second user requesting a co-starring between a second avatar associated with the second user and a first avatar associated with the first user, and refusing to co-star with the first avatar when the second user does not possess any of the one or more non-fungible assets. A video data transmission method according to any one of [1] to

[11] .

[15] The method further includes a step of transmitting video data of a co-starring video including the first avatar and the second avatar in response to receiving a co-starring request from a second user requesting a co-starring between a second avatar associated with the second user and a first avatar associated with the first user, if the second user holds a converted non-fungible asset in which at least one of the one or more fungible assets is tokenized as a non-fungible token, and refusing to co-star with the first avatar in the case where the second user does not hold the converted non-fungible asset. A video data transmission method according to any one of [1] to

[11] .

[16] The virtual space includes a closed space, The method further includes a step of permitting a first avatar associated with the first user to enter the closed space when the first user possesses at least one of the one or more non-fungible assets, and refusing to allow the first avatar to enter the closed space when the first user does not possess any of the one or more non-fungible assets. A video data transmission method according to any one of [1] to

[11] .

[17] The virtual space includes a closed space, The method further includes a step of permitting a first avatar associated with the first user to enter the closed space when the first user holds a converted non-fungible asset in which at least one of the one or more fungible assets is tokenized as a non-fungible token, and refusing to allow the first avatar to enter the closed space when the first user does not hold any of the converted non-fungible assets. A video data transmission method according to any one of [1] to

[11] .

[18] The first user owns a plurality of wearable assets that can be worn by a first avatar of the first user in the virtual space, among the one or more fungible assets; The one or more processors further comprise a step of performing processing to tokenize the set of the plurality of worn assets as a non-fungible token in response to a tokenization request from the first user. A video data transmission method according to any one of [1] to

[11] .

[19] A video data transmission system including one or more processors, the system transmitting video data including a view of a virtual space in which avatars associated with each of a plurality of users including a first user can participate, the system comprising: The one or more processors execute computer readable instructions to: generating a first wallet in association with first user identification information that identifies the first user in the virtual space; In response to a first acquisition request from the first user, granting to the first user a first non-fungible asset among one or more non-fungible assets which are digital assets used in the virtual space and have been tokenized as a non-fungible token, and transferring to the address of the first wallet a first non-fungible token associated with the first non-fungible asset; Video data transmission system.

[20] A video data transmission program for causing one or more processors to transmit video data including a view of a virtual space in which avatars associated with each of a plurality of users including a first user can participate, the program comprising: the one or more processors; generating a first wallet in association with first user identification information that identifies the first user in the virtual space; In response to a first acquisition request from the first user, granting to the first user a first non-fungible asset among one or more non-fungible assets that are digital assets used in the virtual space and have been tokenized as a non-fungible token, and transferring to the address of the first wallet a first non-fungible token associated with the first non-fungible asset; A video data transmission program that executes the above. [Explanation of symbols]

[0262] 1. Video transmission system 10a, 10b User device 20 Servers 21a Video transmission section 21b NFT issuance request section 21c NFT transfer processing unit 21d NFT Exchange Department 21e Reward Department 21f Wallet Generation Section 30 Blockchain Network 31 Blockchain 40 File Systems 50 Exchanges 70a, 70b Avatar W10a Wallet W10b User Wallet

Claims

1. A video data transmission method for transmitting video data including a view of a virtual space in which avatars associated with each of a plurality of users including a first user can participate, the method being executed by one or more processors that execute computer-readable instructions, the video data transmission method comprising a step of generating a first wallet in association with first user identification information for identifying the first user in the virtual space.

2. The video data transmission method further comprising a step of receiving a request for wallet-required wallet processing from a first user device of the first user, wherein the first wallet is generated in response to receiving the request for wallet-required wallet processing. The video data transmission method according to claim 1.

3. The wallet-required wallet processing includes a process that requests the purchase or acquisition of non-fungible tokens. The video data transmission method according to claim 2.

4. The wallet-required wallet processing includes a process that requests tokenizing fungible assets as non-fungible tokens. The video data transmission method according to claim 2.

5. The wallet-required wallet processing includes a process that requests the acquisition of utility tokens. The video data transmission method according to claim 2.

6. The plurality of users includes a second user, the video data transmission method further comprising a step of receiving a request for wallet-required wallet processing from a second user device of the second user, wherein the first wallet is generated in response to receiving the request for wallet-required wallet processing. The video data transmission method according to claim 1.

7. The wallet-required wallet processing includes a process that requests gifting non-fungible tokens or non-fungible assets from the second user to the first user. The video data transmission method according to claim 6.

8. The video data transmission method further comprising a step of performing wallet-required wallet processing that requires a wallet by a server that provides the virtual space, wherein the first wallet is generated in response to receiving the request for wallet-required wallet processing. The video data transmission method according to claim 1.

9. The wallet-required wallet processing includes a process that grants a utility token to the first user. The video data transmission method according to claim 8.

10. The utility token is exchangeable with crypto assets other than the utility token. The video data transmission method according to claim 5 or 9.

11. The utility token is assigned to the first user according to the activity of the first user in the virtual space. The method for transmitting video data according to claim 5 or 9.

12. A first avatar associated with the first user participates in the virtual space. Further comprising a step of performing a process for tokenizing, as a non-fungible token, a first partial video including a view of the virtual space including the first avatar, which is part of the video data, in response to a first video tokenization request from the first user. The method for transmitting video data according to any one of claims 1 to 11.

13. A second avatar associated with a second user further participates in the virtual space. Further comprising a step of performing a process for tokenizing, as a non-fungible token, a second partial video including a view of the virtual space including the second avatar, which is part of the video data, in response to a second video tokenization request from the second user. The method for transmitting video data according to claim 12.

14. In response to receiving a co-performance request from a second user to request a co-performance between a second avatar associated with the second user and a first avatar associated with the first user, when the second user holds at least one of one or more non-fungible assets that are digital assets used in the virtual space and tokenized as non-fungible tokens, transmitting video data of a co-performance video including the first avatar and the second avatar, and when the second user does not hold any of the one or more non-fungible assets, further comprising a step of rejecting the co-performance with the first avatar. The method for transmitting video data according to any one of claims 1 to 13.

15. The virtual space includes a closed space. When the first user holds at least one of one or more non-fungible assets that are digital assets used in the virtual space and tokenized as non-fungible tokens, permitting the first avatar associated with the first user to enter the closed space, and when the first user does not hold any of the one or more non-fungible assets, further comprising a step of rejecting entry into the closed space. The method for transmitting video data according to any one of claims 1 to 14.

16. The virtual space includes a closed space, when at least one of one or more non-fungible assets that are digital assets used by the first user in the virtual space and tokenized as non-fungible tokens is a converted non-fungible asset tokenized as a non-fungible token, permitting a first avatar associated with the first user to enter the closed space, and when the first user does not hold any of the converted non-fungible assets, further comprising a step of rejecting entry into the closed space, The video data transmission method according to any one of Claims 1 to 14.

17. The first user holds a plurality of wearable assets that can be worn by a first avatar of the first user in the virtual space among the one or more fungible assets, further comprising a step of performing a process for tokenizing a set of the plurality of wearable assets as non-fungible tokens in response to a tokenization request from the first user. The video data transmission method according to any one of Claims 1 to 15.

18. A video data transmission system including one or more processors and transmitting video data including a view of a virtual space in which avatars associated with a plurality of users including a first user can participate, wherein the one or more processors, by executing computer-readable instructions, generate a first wallet in association with first user identification information for identifying the first user in the virtual space. Video data transmission system.

19. A video data transmission program for causing one or more processors to transmit video data including a view of a virtual space in which avatars associated with a plurality of users including a first user can participate, the one or more processors being caused to execute a step of generating a first wallet in association with first user identification information for identifying the first user in the virtual space. Video data transmission program.

Images