JP2024032491A - Lottery method, lottery program and lottery device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a lottery method, a lottery program and a lottery device consuming crypto assets.

SOLUTION: In a lottery method, a computer receives a lottery request including a user ID, updates the number of held tickets associated with the received user ID, and purchasable with on-chain token of crypto assets, performs a lottery and transmits a lottery result.

SELECTED DRAWING: Figure 11

COPYRIGHT: (C)2024,JPO&INPIT

Description

The present invention relates to a lottery method, lottery program, and lottery device that consume cryptographic assets.

In online games, a random item provision system is used. The random item provision method is so-called "Gacha" (registered trademark). Gacha is a system that provides characters, items, etc. that can be used in an online game by electromagnetically displaying letters, pictures, codes, etc., by a method in which the types of items, etc. are determined using chance.

In online games, a virtual world is constructed in which users act as avatars. In the virtual world, commercial activities similar to those in the real world are carried out, and currency is used to carry out these activities. The currency is called a virtual currency because it is a currency in the virtual world. Patent Document 1 discloses a game program that promotes consumption of virtual currency.

Japanese Patent Application Publication No. 2022-49419

Crypto assets have been attracting attention in recent years. Crypto assets are property values that can be exchanged over the Internet. Since the Internet is considered a virtual world, it was once called virtual currency. However, while the above-mentioned virtual currencies include limited ones that can only be used in online games, the places where crypto assets can be used are not limited to online games. In addition, as a characteristic of crypto assets, they use blockchain technology and cryptographic technology, so they are called crypto assets to distinguish them from virtual currencies that can only be used in the virtual world.

Generally, crypto assets can be obtained and converted into cash from businesses called "exchanges" or "exchanges" (crypto asset exchange companies). Although crypto assets are also used as a payment method in commercial transactions, they are primarily used for investment purposes. The present invention has been made in view of this situation. The purpose is to provide a lottery method, lottery program, and lottery device that consume crypto assets.

In the lottery method disclosed in this application, a computer receives a lottery request including a user ID, updates the number of tickets held that are associated with the received user ID, and can be purchased with on-chain tokens of crypto assets, and draws a lottery request. and send the lottery results.

According to one aspect of the present application, it is possible to provide a lottery method, a lottery program, and a lottery device that consume cryptographic assets.

FIG. 2 is an explanatory diagram showing a configuration example of a token back system. FIG. 2 is a block diagram showing an example of the hardware configuration of a server. FIG. 2 is a block diagram showing an example of the hardware configuration of a terminal. It is an explanatory diagram showing an example of user DB. It is an explanatory diagram showing an example of member store DB. It is an explanatory diagram showing an example of purchase history DB. It is an explanatory diagram showing an example of grant history DB. It is an explanatory diagram showing an example of restriction DB. It is an explanatory diagram showing an example of a privilege DB. It is an explanatory diagram showing an example of a winning situation DB. It is a flowchart which shows the example of a procedure of lottery execution processing. It is a flowchart which shows the example of a procedure of privilege receiving processing.

Embodiments will be described below with reference to the drawings.
(Embodiment 1)
FIG. 1 is an explanatory diagram showing an example of the configuration of a token back system. The token back system 100 in this embodiment provides tokens to users who purchase products or services (hereinafter referred to as "products, etc.") with legal currency at a predetermined member store. Such tokens can also be obtained by exchanging fiat currency. The token back system 100 provides users with a lottery game that allows them to consume tokens.

The token back system 100 includes a lottery device 1, terminals 2, 2, 2, . . . , an exchange server 3, an EC (Electronic Commerce) server 4, and an issuing server 5. Each device is connected to be able to communicate with each other via a network N such as the Internet.

The lottery device 1 is capable of various information processing and transmission/reception of information, and is composed of, for example, a server computer, a personal computer, etc. In this embodiment, the lottery device 1 is constituted by a server computer, and will be referred to as server 1 below for the sake of brevity. The server 1 is a server computer of an administrator who manages the tokenback system 100. The server 1 provides a lottery game to users and also performs processing related to token back, which is a basic function of the token back system 100. The server 1 provides cash back (token back) in tokens to users who purchase products at member stores affiliated with the token back system 100. The token here is a token unique to this system (hereinafter referred to as "unique token").

In the token back system 100, there are two types of tokens. The two types of tokens are off-chain tokens and on-chain tokens. Off-chain tokens are valid only within the Tokenback system 100. The quantity of off-chain tokens held by users is stored in a database managed by this system. Off-chain tokens do not have their transaction history recorded in a blockchain system (hereinafter referred to as "blockchain"). When a user sells off-chain tokens to someone else, the tokens need to be moved to a wallet. At this time, the server 1 receives the issuance of tokens from the exchange and sends them to the user's wallet. The token is an on-chain token whose transaction history is recorded on the blockchain. On-chain tokens are crypto assets (cryptocurrency or virtual currency) whose transaction history is recorded on a blockchain. Crypto assets can be obtained and converted into cash from businesses called "exchanges" or "exchanges" (crypto asset exchange companies). Furthermore, crypto assets are property values that can be exchanged over the Internet.

When a user stores off-chain tokens in their wallet as on-chain tokens, it is called a withdrawal. Off-chain tokens exist based on an agreement between the operator of the tokenback system 100 and the user, and when the user withdraws them to a wallet, they become on-chain tokens, that is, ordinary crypto assets. The on-chain token granted by the server 1 does not have to be a unique token. For example, on-chain tokens may be existing crypto assets such as Bitcoin (registered trademark), Ethereum (registered trademark), Ripple, NEM, etc. Note that in this specification, withdrawal and exchange are collectively referred to as movement.

Off-chain tokens are tokens that are promised to be able to be exchanged, for example, on an equivalent basis with on-chain tokens. That is, one unit of off-chain token can be exchanged for one unit of on-chain token. However, the present invention is not limited to this, and points of a point service may be used instead of off-chain tokens. The exchange of points and on-chain tokens does not necessarily have to be one-to-one; an exchange ratio may be determined, and points may be exchanged for on-chain tokens at that exchange ratio. For example, if the exchange ratio is 10:1, 10 points can be exchanged for 1 unit of on-chain token. Exchanging off-chain tokens or points with on-chain tokens is also referred to as converting off-chain tokens or points to on-chain tokens.

The cryptographic assets required to play the lottery game described below are assumed to be unique on-chain tokens newly purchased by the user using legal currency, credit cards, etc. However, the present invention is not limited to this, and participation in the lottery game may be made possible using off-chain unique tokens or points recognized by the operator.

In this specification, supply and demand information is broadly interpreted as not limited to information regarding the supply of cryptographic assets and information regarding demand for cryptographic assets. The supply and demand information shall also include market prices that fluctuate depending on the supply and demand balance of cryptoassets, the amount of cryptoassets issued that is related to the amount in circulation in the market, and the amount held by users and operators. Information that affects the asset value of crypto assets is herein referred to as supply and demand information.

The terminal 2 is a terminal device (user terminal) used by each user who uses the token back system 100. The terminal 2 includes, for example, a smartphone, a tablet terminal, a personal computer, or the like. In this embodiment, the explanation will be given assuming that the terminal 2 is a smartphone equipped with a touch panel. An application program (hereinafter referred to as "app") for realizing functions related to the token back system 100 is installed in the terminal 2 in advance.

The exchange server 3 is a server computer of a crypto asset exchange company that provides a virtual currency exchange. The on-chain token according to this embodiment is listed on one or more exchanges, and users can buy and sell on-chain tokens on the exchanges.

The EC server 4 is a server computer of an EC site (virtual store) business that provides electronic commerce services. In addition to businesses that sell products at physical stores, EC site businesses are members of the tokenback system 100. Each user can receive off-chain tokens when purchasing products at an affiliated physical store or EC site.

The issuing server 5 is a server computer that issues on-chain tokens related to the tokenback system 100, and is a server computer that controls the upper limit of on-chain token issuance. In this system, the issuing server 5 issues on-chain tokens and supplies them to a trading market (exchange, etc.). The issuance upper limit of on-chain tokens is defined by the issuance server 5, and the issuance server 5 adjusts the issuance amount while referring to the supply and demand situation of on-chain tokens in the market.

FIG. 2 is a block diagram showing an example of the hardware configuration of the server. The server 1 includes a control section 11, a main storage section 12, a communication section 13, and an auxiliary storage section 14. The control section 11, the main storage section 12, the communication section 13, and the auxiliary storage section 14 are connected by a bus B.

The control unit 11 includes one or more arithmetic processing devices such as a CPU (Central Processing Unit), an MPU (Micro-Processing Unit), and a GPU (Graphics Processing Unit). The control unit 11 performs various information processing, control processing, etc. related to the server 1 by reading and executing the program P1 (program product) stored in the auxiliary storage unit 14. Furthermore, when the control unit 11 executes the program P1, functional units such as a receiving unit, an updating unit, a lottery unit, and a transmitting unit are realized.

The main storage unit 12 is an SRAM (Static Random Access Memory), a DRAM (Dynamic Random Access Memory), a flash memory, or the like. The main storage unit 12 temporarily stores data necessary for the control unit 11 to perform arithmetic processing.

The communication unit 13 includes a processing circuit and the like for performing communication-related processing. Sends and receives information to and from terminal 2, etc.

The auxiliary storage unit 14 is a large capacity memory, an SSD (Solid State Drive), a hard disk, or the like. The auxiliary storage unit 14 stores a program P1 and other data necessary for the control unit 11 to execute processing. The auxiliary storage unit 14 also stores a user DB 141, a member store DB 142, a purchase history DB 143, a grant history DB 144, a restriction DB 145, a privilege DB 146, and a winning status DB 147. Note that the auxiliary storage unit 14 may be an external storage device connected to the server 1. The database stored in the auxiliary storage unit 14 may be stored in cloud storage.

The server 1 may be configured with a multicomputer consisting of a plurality of computers, a virtual machine virtually constructed by software, or a quantum computer. Furthermore, the functions of the server 1 may be realized by a cloud service.

The server 1 also includes a reading unit (not shown) that reads a portable storage medium 1m such as a CD (Compact Disk)-ROM or a DVD (Digital Versatile Disc)-ROM, and reads the program P1 from the portable storage medium 1m. It may also be executed by Alternatively, the server 1 may read the program P1 from the semiconductor memory 1n. Furthermore, in addition to the above configuration, the server 1 may also include, for example, an input section that receives operation input, a display section that displays images, and the like.

FIG. 3 is a block diagram showing an example of the hardware configuration of the terminal. The terminal 2 includes a control section 21 , a main storage section 22 , a communication section 23 , a display section 24 , an input section 25 , an imaging section 26 , and an auxiliary storage section 27 .

The control unit 21 includes arithmetic processing units such as one or more CPUs and MPUs. The control unit 21 performs various information processing, control processing, etc. related to the terminal 2 by reading and executing the program P2 (program product) stored in the auxiliary storage unit 27. Program P2 corresponds to the above-mentioned application.

The main storage unit 22 is SRAM, DRAM, flash memory, or the like. The main storage unit 22 temporarily stores data necessary for the control unit 21 to perform arithmetic processing.

The communication unit 23 includes an antenna, a processing circuit, etc. for communication. The communication unit 23 sends and receives information to and from the server 1 and the like.

The display unit 24 includes a display panel such as a liquid crystal display or an organic EL (Electro Luminescence) display. The display section 24 displays the image given from the control section 21.

The input unit 25 is, for example, an input interface such as a touch panel or mechanical keys. The input unit 25 receives operation input from the user.

The imaging unit 26 is a camera equipped with an imaging element such as a CMOS (Complementary Metal Oxide Semiconductor) sensor. The imaging unit 26 performs imaging according to the operation input by the user.

The auxiliary storage section 27 is a large capacity memory, SSD, hard disk, etc., and stores the program P2 and other data necessary for the control section 21 to execute processing.

Note that the terminal 2 may include a reading unit (not shown) that reads the portable storage medium 2n, and may read and execute the program P2 from the portable storage medium 2n. Further, the terminal 2 may read the program P2 from the semiconductor memory 2m.

FIG. 4 is an explanatory diagram showing an example of a user DB. User DB 141 stores information regarding users. The user DB 141 includes a user ID column, a user name column, a holding amount column, a wallet column, a rank column, a ticket column, an auxiliary ticket column, and a personal information column. The user ID column stores a user ID for identifying each user. The user name column stores the user's name. The holding amount column stores the amount of off-chain tokens held by the user. The wallet column stores wallet information (for example, hot wallet public key, etc.) in which on-chain tokens held by the user are stored. The rank column stores the user's rank. Ranking is determined by purchase history at member stores, amount of tokens held, holding period, grant history, withdrawal history, etc. For example, the ranks are, from top to bottom, Diamond, Platinum, Gold, Silver, and Bronze. The ticket column stores the number of tickets held by the user necessary to participate in the lottery. The auxiliary ticket column stores the number of pass auxiliary tickets obtained as benefits that the user owns. The pass auxiliary ticket will be described later. The personal information column stores the user's personal information (gender, age, nationality, etc.).

FIG. 5 is an explanatory diagram showing an example of a member store DB. The affiliated store DB 142 stores information regarding affiliated stores. The member store DB 142 includes a member store ID column, a member store name column, a member store information column, and a commission rate column. The member store ID column stores member store IDs for identifying each member store. The member store name column stores the names of member stores. The member store information column stores information regarding other member stores except for the name. The commission rate column stores the percentage of commissions collected from member stores.

FIG. 6 is an explanatory diagram showing an example of a purchase history DB. The purchase history DB 143 stores a history of purchases of products and services by users from member stores. The purchase history DB 143 includes a purchase ID column, a purchaser column, a member store column, a date column, a purchased product column, and a purchase amount column. The purchase ID column stores a purchase ID assigned to each purchase history when a user purchases a product or the like from an affiliated store. The purchaser column stores the user ID of the user who is the purchaser. The affiliated store column stores the affiliated store ID of the affiliated store where the user purchased a product or the like. The date column stores the date when the user purchased the product or the like. The purchased product column stores the names of products etc. purchased by the user. The purchase amount column stores the purchase amount of products, etc.

FIG. 7 is an explanatory diagram showing an example of the provision history DB. The granting history DB 144 stores a history of granting off-chain tokens to users (granting history). The grant history DB 144 includes a date and time column and a token back column. The date and time column stores the date and time when the token was given to the user. The tokenback column stores information regarding tokenbacks to users. The token back column further includes a user column, a grant amount column, and a purchase ID column. The user column stores the user ID of the user to whom the token is given. The amount column stores the amount of tokens given to the user. The purchase ID column stores a purchase ID that specifies the purchase history of the product, etc. that triggered the provision of the token. As mentioned above, points may be awarded to users instead of off-chain tokens.

FIG. 8 is an explanatory diagram showing an example of a restriction DB. The restriction DB 145 stores application restriction status for each user. The restriction DB 145 includes a user column, a function 1 column, a function 2 column, and a function 3 column. The user column stores user IDs. The Function 1 column stores whether or not Function 1 is restricted. The function 2 column stores whether function 2 is restricted. The function 3 column stores whether function 3 is restricted. The function n column provides the number of functions of the application.

FIG. 9 is an explanatory diagram showing an example of a privilege DB. The benefit DB 146 stores information on benefits that will be provided if the player wins in the lottery game. The benefit DB 146 includes a benefit ID column and a benefit column. The benefit ID column stores benefit IDs that can uniquely identify the benefit. The benefit column stores the details of the benefit. The benefits include, for example, cash payments such as 1 million yen, crypto assets such as 0.1 Bitcoin or 10,000 tethers, and highly rare NFTs (non-fungible tokens). It is also possible to provide crypto assets other than Bitcoin and Tether. Furthermore, it is the right to release the function restriction (right to use) of the application for using the token back system 100. Also includes one pass auxiliary ticket as a bonus. If you collect 10 pass auxiliary tickets, you can use them as a FastPass ticket. FastPass tickets allow you to relax the upper limit on exchanging off-chain tokens to on-chain tokens. The predetermined amount is, for example, twice the amount of tokens that the user pays to play the lottery game. As for cash payments, since it is difficult to pay immediately after the lottery, the right to receive the cash payment (monetary claim) is granted to the user. Depending on the settings of the bonus DB 146, if you play the lottery game many times, the probability of winning increases, and in the end, you can make it a winning gacha. It is possible to make it a specification. As a result of the lottery game, there may be a loss in which no benefit is given.

Supplement about the functions of the app. App functions in the tokenback system 100 include shopping functions, withdrawals, crypto asset purchases, and the like. The shopping function is a function that allows you to transition to a shopping site and receive token back when you shop at the shopping site after transitioning. The withdrawal function is a function that converts in-app crypto assets (off-chain tokens) into on-chain tokens that can be withdrawn to a wallet on the blockchain. The crypto asset purchase function is a function to purchase crypto assets using legal currency and store them within the app. If the shopping function is restricted, you will be able to shop at the shopping site, but you will not be able to receive token back. If the withdrawal function is restricted, it will not be possible to convert off-chain tokens to on-chain tokens, or the quantity that can be converted will be limited. In the crypto asset purchase function, a minimum purchase quantity is set, and purchases cannot be made unless the quantity exceeds the minimum limit. The above-mentioned functional restriction release right is a privilege that allows these restrictions to be removed for a predetermined period of time.

FIG. 10 is an explanatory diagram showing an example of the winning status DB. The winning status DB 147 stores the winning status for each benefit. The winning status DB 147 includes a benefit ID column, a maximum number of winners column, a cumulative number of winners column, and a winning number column. The benefit ID column stores benefit IDs. The maximum number of winners column stores the maximum number of users to whom benefits will be given upon winning. The cumulative number of winners column stores the number of users who have won. The winning number column stores winning numbers of benefits. In the example shown in FIG. 10, for the benefits with benefit IDs 40001 and 40002, the maximum number of users who can win is one, and there are no winners yet. The winning number is a 128-bit numerical value. In FIG. 10, a 128-bit value is expressed as a 32-digit hexadecimal number. For the benefit with benefit ID 40003, the maximum number of users who can win is 100, and there have already been 10 winners. The winning number has 4579 in the lower 16 bits. The winning status DB 147 may store the user ID of the winning user, the winning ID, and the expiration date for each benefit.

FIG. 11 is a flowchart showing an example of the procedure of lottery execution processing. The lottery execution process is a process in which a lottery game is played once according to a user's request. When the user instructs the execution of the lottery game from the menu of the application, the lottery execution process is started. Before holding the lottery, users purchase the necessary tickets using on-chain tokens. The control unit 21 of the terminal 2 transmits a lottery game execution request to the server 1 (step S1). The request includes a user ID. The control unit 11 of the server 1 receives the request (step S2). The control unit 11 refers to the value of the ticket string in the user DB 141 and determines whether the user has a ticket necessary for participating in the lottery game (step S3). It is assumed that the number of tickets required to participate in the lottery game is determined in advance and notified to the user. When the control unit 11 determines that the user has the tickets necessary to participate in the lottery game (YES in step S3), the control unit 11 updates the number of tickets held by the user (step S4). The control unit 11 updates the value of the ticket string in the user DB 141 to a value that reduces the number of tickets required to participate in the lottery game. The control unit 11 generates random numbers (step S5). The control unit 11 generates, for example, a 128-bit random number. The control unit 11 determines whether or not the winner has been won (step S6). The control unit 11 determines whether the generated random number matches the value in the column after the winning number in the winning status DB 147, or whether some digits match. When the control unit 11 determines that they match, it compares the values of the maximum number of winners column and the cumulative number of winners column of the winning status DB 147, and determines that the winning party has won if the cumulative number of winners has not reached the maximum number of winners. The control unit 11 determines that the random number does not match the value in the row after the winning number, or that even if the random number does match, the cumulative number of winners has reached the maximum number of winners, the winner is not selected or won. When the control unit 11 determines that the winner has not been won (NO in step S6), the process moves to step S8. When the control unit 11 determines that the winner has been won (YES in step S6), it updates the value of the cumulative number of winners column in the winning status DB 147 (step S7). The control unit 11 generates a notification of winning or losing (step S8). The control unit 11 transmits a notification (lottery result) to the terminal 2 (step S9). The control unit 21 of the terminal 2 receives the notification and displays the notification on the display unit 24 (step S10). The control unit 21 ends the process. If the control unit 11 determines that the user does not have the ticket necessary to participate in the lottery game (NO in step S3), it transmits a notification of non-execution of the lottery game to the terminal 2 (step S11). ). The control unit 21 of the terminal 2 receives the notification of disapproval (step S12). The control unit 21 displays a notification of impossibility (step S13), and ends the process. Note that, after receiving the rejection notification, the control unit 21 may display a message urging the user to purchase a ticket, and may direct the user to a website where the ticket can be purchased using an on-chain token. After the user purchases a ticket, the control unit 21 executes the process again from step S1. Tickets may be available for purchase after exchanging other cryptographic assets such as Bitcoin or Ethereum with the on-chain of the tokenback system 100. In the above explanation, it is assumed that the ticket is purchased before participating in the lottery game, but the purchase is not limited thereto. On-chain money may be collected from users who do not have tickets to participate in the lottery game. In this case, the amount of on-chain tokens required may be larger than when purchasing a ticket. For example, one ticket mentioned above can be used to participate in a lottery game once, and a set of 10 tickets can be sold in exchange for on-chain tokens equivalent to 9 tickets. good. The ticket described above may have an expiration date.

FIG. 12 is a flowchart illustrating an example of a procedure for award receiving processing. The benefit receiving process is a process that is necessary when winning a benefit other than a pass auxiliary ticket. The control unit 21 of the terminal 2 transmits a reception request to the server 1 (step S31). The receipt request includes the user ID. The control unit 11 of the server 1 receives the reception request (step S32). The control unit 11 transmits the input screen to the terminal 2 (step S33). The control unit 21 of the terminal 2 receives the input screen and displays it (step S34). The user enters the necessary information. Necessary information includes the winning ID, contact email address, etc. After inputting the information, the user instructs transmission. The control unit 21 transmits the input information to the server 1 (step S35). The control unit 11 of the server 1 receives the information (step S36). The control unit 11 determines whether the request is valid (step S37). For example, the user ID of the winner is stored in the winning status DB 147. The control unit 11 determines that the user ID of the user requesting receipt is valid if it is stored in the winning status DB 147 and has not passed the expiration date, and determines that it is not valid if it is not stored. If the control unit 11 determines that the request is valid (YES in step S37), it stores the received information in the auxiliary storage unit 14 (step S38). The control unit 11 sends a notification to the terminal 2 that the request has been accepted (step S39). The control unit 21 of the terminal 2 receives the notification (step S40). The control unit 21 displays a notification (step S41), and ends the process. Based on the stored information, the control unit 11 separately performs processing for granting benefits to the user. If the control unit 11 determines that the request is not valid (NO in step S37), it transmits a notification of refusal to the terminal 2 to the effect that the privilege cannot be received (step S42). The control unit 21 of the terminal 2 receives the notification of disapproval (step S43). The control unit 21 displays a notification of impossibility (step S41), and ends the process.

In this embodiment, it is possible to provide a lottery game using crypto assets. Furthermore, by devising the winning benefits of the lottery, it is possible to provide an interesting lottery game.

In the above description, it is assumed that one type of lottery game is provided, but the present invention is not limited to this. Various lottery games may be provided. For example, a game that requires two tickets to participate but has a higher winning probability than a game that requires one ticket may be provided. Further, a game may be provided that has the same probability of winning as the lottery game described above, but requires five tickets and wins more expensive benefits.

The technical features (constituent features) described in each embodiment can be combined with each other, and new technical features can be formed by combining them.
The embodiments disclosed herein are illustrative in all respects and should be considered not to be restrictive. The scope of the present invention is indicated by the claims rather than the above-mentioned meaning, and is intended to include meanings equivalent to the claims and all changes within the scope.
Further, although the scope of claims uses a format in which claims refer to two or more other claims (multi-claim format), the invention is not limited to this format. It may also be written using a multi-claim format that cites at least one multi-claim.

100: Token back system 1: Server, lottery device 11: Control unit 12: Main storage unit 13: Communication unit 14: Auxiliary storage unit 141: User DB
142: Member store DB
142: User DB
143: Purchase history DB
144: Grant history DB
145: Restriction DB
146: Benefits DB
147: Winning status DB
P1: Program 1m: Portable storage medium 1n: Semiconductor memory 2: Terminal 21: Control section 22: Main storage section 23: Communication section 24: Display section 25: Input section 26: Imaging section 27: Auxiliary storage section P2: Program 2m : Semiconductor memory 2n : Portable storage medium 3 : Exchange server 4 : EC server 5 : Publishing server B : Bus N : Network

Claims (7)

The computer is
Receive a lottery request including a user ID,
Updates the number of tickets held that are associated with the received user ID and can be purchased with on-chain tokens of crypto assets,
A lottery will be held,
Send lottery results Lottery method to perform processing. The lottery method according to claim 1, wherein the privilege granted when the lottery result is a win includes a monetary claim. The lottery method according to claim 1, wherein the benefits granted when the lottery result is a win include a predetermined amount of Bitcoin, Ethereum, Tether, or NFT. The lottery method according to claim 1, wherein the privilege granted when the lottery result is a win includes the right to use an application program for managing the cryptographic asset. 5. The lottery method according to claim 4, wherein the right to use is a content that relaxes a quantity limit for converting off-chain tokens of the crypto asset into on-chain tokens. The computer receives a lottery request including the user ID,
Updates the number of tickets held that are associated with the received user ID and can be purchased with on-chain tokens of crypto assets,
A lottery will be held,
A lottery program that executes the process of transmitting lottery results. a receiving unit that receives a lottery request including a user ID;
an updating unit that updates the number of tickets held that is associated with the received user ID and that can be purchased with on-chain tokens of crypto assets;
A lottery department that conducts the lottery,
A lottery device comprising: a transmitter for transmitting lottery results;

Images