Server device, program, and method executed by computer

Abstract

[Problem] To make it possible to support the purchase of tokens using value media granted to users, even if users are not expected to actively invest in tokens. [Solution] A server device according to the present invention is an operator server connected to a database for managing value media issued to users of a service and to a blockchain for storing token transactions. The server device acquires, from the database, the balance of expiring value media among the value media possessed by the user, and records, in the blockchain, the transfer to the user of an amount of tokens determined on the basis of the acquired balance.

Description

Server device, program, and method executed by computer , ,

[0004] , ,

[0003] ,

[0005] ,

[0001] The present invention relates to a server device, a program, and a method executed by a computer.

[0002] As one of the financing methods by companies, in recent years, financing using virtual currencies such as IEO (Initial Exchange Offering), ICO (Initial Coin Offering), and STO (Security Token Offering) has attracted attention. All of these are methods of raising funds by a company issuing its own cryptocurrency (token) on the blockchain and having investors buy it, and the issued tokens will be traded in the market like stocks. STO is different from IEO and ICO which are conducted outside the regulatory framework in that the tokens issued are treated as securities based on the Securities and Exchange Law. Patent Document 1 discloses a technology that enables tokens by ICO to be used in transactions in the securities market.

[0003] Also, in recent years, the points issued by companies have attracted attention. Points are a type of reward given to consumers based on user actions such as purchasing goods or services, watching advertisements, and visiting specific locations, and usually take the form of electronic currency that can only be used by specific companies or their partners. Customers accumulate points each time they purchase and later use them to obtain goods and services instead of cash. Since points are accounted for as liabilities in a company's balance sheet, many companies set an expiration date for points to make it easier to manage future liabilities related to unused points.

[0004] Japanese Patent Application Laid-Open No. 2023-044810

[0005] By the way, a company that has issued tokens by IEO, ICO, STO, etc. is responsible for maintaining the price of the tokens for investors. However, this is not an easy task as with ordinary stocks, and many companies are struggling to maintain the token price. The fact that the token market is not as common as the stock market also makes it difficult to maintain the token price.

[0006] To address these challenges, the inventors of this application are considering making tokens purchasable using a value medium issued to service users. This value medium includes not only the points mentioned above, but also other types of media that have monetary-like value, such as coupons and electronic vouchers. However, for many users who are not interested in investing in tokens, there is no incentive to choose to purchase tokens from among the many other uses available, and therefore, it is thought that this would not be very helpful in supporting the token's value.

[0007] Therefore, one of the objectives of the present invention is to provide a server device, a program, and a method executed by a computer that can support the purchase of tokens by providing value to users, even if active token investment by users cannot be expected.

[0008] The server device according to the present invention is a server device connected to a database that manages value media issued to service users and a blockchain that stores token transactions, and which retrieves the balance of value media that are expiring from the value media held by the user from the database, and records the transfer of an amount of tokens to the user determined based on the retrieved balance on the blockchain.

[0009] The program according to the present invention is a program that causes a computer connected to a database that manages value media issued to service users and a blockchain that stores token transactions to perform the following steps: retrieve from the database the balance of expired value media held by the user, and record on the blockchain the transfer of an amount of tokens to the user determined based on the retrieved balance.

[0010] The method according to the present invention is a method performed by a computer connected to a database that manages value media issued to users of a service and a blockchain that stores token transactions, and includes the steps of: obtaining from the database the balance of expired value media held by the user; and recording on the blockchain the transfer of an amount of tokens to the user determined based on the obtained balance.

[0011] According to the present invention, since tokens can be supported by expiring mediums of value, even if active token investment by users cannot be expected, it becomes possible to support tokens by using the mediums of value granted to users. Furthermore, it becomes possible to give users an opportunity to become interested in token investment and the operators.

[0012] This figure shows the configuration of the value medium management system 1 according to the first embodiment of the present invention. This figure shows an example of the hardware configuration of each computer constituting the user terminal 2, operator server 3, exchange server 4, and blockchain network 5. (a) to (c) are figures showing the point history table, point balance management table, and user management table stored in the database 7, respectively. This is a sequence diagram showing the token investment process using points approaching expiration. This is a sequence diagram showing the token investment process using points approaching expiration. This figure shows an example of the point history screen displayed on the output device 104 of the user terminal 2, which is a smartphone. This figure shows an example of the modal screen displayed on the output device 104 of the user terminal 2, which is a smartphone. This figure shows an example of the user wallet information screen displayed on the output device 104 of the user terminal 2, which is a smartphone. (a) and (b) are figures showing the adjustment coefficient management table and campaign management table stored in the database 7 according to the second embodiment of the present invention, respectively.

[0013] Hereinafter, embodiments of the present invention will be described in detail with reference to the attached drawings.

[0014] Figure 1 shows the configuration of a system including a value medium management system 1 according to a first embodiment of the present invention. As shown in the figure, the value medium management system 1 has a configuration in which a user terminal 2, an operator server 3, an exchange server 4, and a blockchain network 5 are interconnected via a network 6. A database 7 is connected to the operator server 3. Below, an example in which points are used as the value medium will be described, but the present invention is also suitably applicable when other types of value mediums such as coupons or electronic vouchers are used.

[0015] The Value Medium Management System 1 manages the expiration dates of points awarded by the operator to users of the operator's services (hereinafter referred to as "operator services"), and automatically invests points that are about to expire (i.e., will expire within a predetermined period) (hereinafter referred to as "points nearing expiration") into tokens issued by the operator through an ICO or STO (i.e., without requiring repeated confirmation of the operator service user's consent). Operator services are typically online services where the entire process from application to delivery is completed online, but they may also be offline services provided at physical stores, etc. The following explanation will continue on the premise that the services are online.

[0016] While there are no specific limitations on the timing of the automatic execution of token investment based on points nearing expiration, it is preferable to execute the investment as close to the expiration date as possible, provided that the load on the operator server 3 does not become excessive, in order to prevent problems where users try to use their points in the short period between the automatic execution of the token investment and the expiration date, only to find that the investment has already been executed and they cannot use the points. For example, it could be one day, half a day, one hour, one minute, or one second before the expiration date. Alternatively, even if points nearing expiration are used as the investment target, the timing of the actual investment can be set to after the points have expired, thereby physically preventing the above-mentioned problems from occurring.

[0017] User terminal 2 is a computer used by users of the operator's services and may be used for purposes such as using the operator's services, checking point balances, using points, and checking the user wallet described later. The specific hardware of user terminal 2 may be any computer, such as a smartphone, tablet, or personal computer.

[0018] Operator Server 3 is a server computer used by the operator of the operator service, and may be used for providing operator services to users, awarding points, and executing token investments using points that are about to expire. Operator Server 3 is also used to purchase tokens that serve as the source of funds for token investments using points that are about to expire (tokens held by the operator itself; hereinafter referred to as "operator-held tokens"). In this regard, Operator Server 3 may purchase operator-held tokens in advance at appropriate times, such as when the market price of tokens falls below a predetermined value, or it may purchase the necessary amount of operator-held tokens at the time of executing token investments using points that are about to expire, or it may purchase operator-held tokens at both of these times.

[0019] The exchange server 4 is a server computer used by the token trading intermediary, and may be used to mediate the trading of issued tokens and to manage the current trading price of issued tokens. Trading of issued tokens mediated by the exchange server 4 includes transactions for the operator server 3 to purchase tokens held by the operator.

[0020] Blockchain Network 5 is a network of multiple computers connected via peer-to-peer technology. There are three types of blockchains: public chains with no specific administrator, private chains managed by a single organization, and consortium chains managed by multiple organizations. Blockchain Network 5 can be any of these. Typical examples include the Ethereum Network, Polygon Network, and Solana, which are classified as public chains, or the LINE Blockchain, which is classified as a private chain.

[0021] Users of Blockchain Network 5 access it through a tool called a wallet. Each wallet is linked to one or more external accounts, and each external account is assigned an address within Blockchain Network 5 called a "wallet address." The transfer of tokens to a user is carried out by recording the transfer of tokens to one of the wallet addresses corresponding to one or more external accounts managed by that user's wallet on the blockchain. Hereinafter, the operator's wallet will be referred to as the "operator wallet," and one of the wallet addresses among the one or more external accounts managed by the operator wallet will be referred to as the "operator address." Similarly, the wallet of a user of the operator's service will be referred to as the "user wallet," and one of the wallet addresses among the one or more external accounts managed by the user wallet will be referred to as the "user address."

[0022] Blockchain Network 5 is configured to allow various types of transactions to be recorded (minted) on the blockchain. These types of transactions include issuance transactions for issuing new externally owned accounts, tokens, or smart contracts (programs recorded on the blockchain), and transfer transactions for transferring ownership of tokens.

[0023] The process of minting a transaction to blockchain network 5 is performed by several computers connected to blockchain network 5 (hereinafter referred to as "miners"). Specifically, each block that makes up the blockchain consists of a block header and data that shows the specific content of the transaction (transaction data). The block header contains the Merkle root, which is data obtained by compressing the size of the transaction data, the hash value of the previous block, and a nonce value, which is an arbitrary string. In blockchain network 5, in order to connect a new block to the blockchain, the hash value of that block must satisfy a predetermined condition (for example, the condition that it is a value that starts with "000"). Therefore, a miner that wants to record a block on the blockchain performs a brute-force search (mining) to find the nonce value so that the hash value of the block header of that block satisfies the above predetermined condition. As a result of this process, the miner who succeeds in finding the nonce value first connects that block to the blockchain, and the minting of the transaction to the blockchain is completed.

[0024] If the blockchain network is a public chain such as the Ethereum Network, Polygon Network, or Solana, anyone attempting to mint a transaction onto the blockchain must pay a fee called "gas" in cryptocurrency. Gas is paid as a reward to miners who successfully concatenate blocks.

[0025] In this embodiment, users of the operator service are, in principle, required to possess their own user wallet and user address, because tokens need to be transferred to users of the operator service. However, in reality, it is not possible for all users of the operator service to possess a user wallet and user address. Therefore, the operator server 3 may pre-issue a smart contract for each user of the operator service, with the operator address as the owner, which includes a transfer function that transfers tokens in response to instructions from the owner (of the smart contract), and transfer tokens to users of the operator service by transferring tokens to the address of this smart contract (hereinafter referred to as the "SC address"). Smart contracts do not contain key pairs, which has the management advantage of not requiring the management of private keys, but in principle they cannot initiate token transfer transactions. However, by writing the above transfer function into the smart contract in advance, when a user of the operator service later acquires a user wallet and user address, it becomes possible to transfer tokens from the smart contract to the user address in response to instructions from the operator (including instructions automatically issued in response to user operations).

[0026] Figure 2 shows an example of the hardware configuration of each computer constituting the user terminal 2, operator server 3, exchange server 4, and blockchain network 5. Each computer constituting the user terminal 2, operator server 3, exchange server 4, and blockchain network 5 can be composed of a computer 100 having the configuration shown in the figure. Note that the computer 100 constituting the operator server 3 and the exchange server 4 may be a computer composed of a combination of multiple computers.

[0027] As shown in Figure 2, the computer 100 has a configuration in which a CPU (Central Processing Unit) 101, a storage device 102, an input device 103, an output device 104, and a communication device 105 are interconnected via a bus 106.

[0028] The CPU 101 controls various parts of the computer 100 and reads and executes various programs stored in the storage device 102. The storage device 102 includes a main memory such as DRAM (Dynamic Random Access Memory) and an auxiliary storage device such as a hard disk, and is a device that stores various programs (including smart contracts) for running the operating system and various applications of the computer 100, as well as data used by these programs. The processes shown in Figures 4 and 5 below are realized by the CPU 101 of each computer constituting the user terminal 2, operator server 3, exchange server 4, and blockchain network 5 executing programs stored in their respective storage devices 102. The database 7 shown in Figure 1 may, in reality, be a database stored in the storage device 102 of the operator server 3.

[0029] The input device 103 is a device that receives input from an external source and supplies it to the CPU 101, and includes, for example, a keyboard, mouse, and touch panel. The output device 104 is a device that outputs the processing results of the CPU 101 to the outside, and includes, for example, a display and speakers.

[0030] The communication device 105 is a device for communicating with external devices and sends and receives data according to the instructions of the CPU 101. The user terminal 2, the operator server 3, the exchange server 4, and each computer constituting the blockchain network 5 are configured to use this communication device 105 to communicate with other devices, including the network 6 shown in Figure 1.

[0031] Figures 3(a) to 3(c) show the point history table, point balance management table, and user management table, respectively, which are stored in database 7. The operator server 3 uses these tables to award points to users of the operator service and to execute token investments using points that are about to expire.

[0032] The points history table is a table prepared for each user of the operator's service, and as shown in Figure 3(a), it is configured to store the date and time, summary (reason for acquiring or using points), the amount of points acquired or used (acquired = positive, used = negative), and the expiration date for each point acquisition or use. Figure 3(a) shows an example of a points history table prepared for one user. In this example, 80 points were newly awarded on July 18, 2024 at 12:15 for the user evaluating the app, 25 points were newly awarded on July 20, 2024 at 19:30 for the user playing a game, 150 points were used on July 22, 2024 at 08:45 for the user purchasing a free coffee coupon with points, and 500 points were newly awarded on July 25, 2024 at 20:15 for the user referring a friend. The expiration date is only applied to the points earned, and in the example in Figure 3(a), it is set to September 30, 2025 in all cases.

[0033] The points balance management table is a table prepared for each user of the operator's service, and it serves to manage the expiration dates of the points awarded to that user. Figure 3(b) shows an example of a points balance management table prepared for one user. In this example, the balance of points with an expiration date of September 30, 2024 is 1000 points, and the balance of points with an expiration date of September 30, 2025 is 3605 points. In this way, the points balance management table can store point balances separated by expiration date.

[0034] The operator server 3 is configured to generate a point balance management table based on the point history table. In calculating the point balance for each expiration date, it is preferable that the operator server 3 calculates the point balance for each expiration date by allocating points used starting with those with the shortest remaining time until expiration.

[0035] The user management table is a table that stores user information related to points and token investments. As shown in Figure 3(c), it is configured to store, for each user ID, which is the identification information of a user of the operator's service, the expiring point investment flag, the user's address, and the SC address of the smart contract issued by the operator to that user.

[0036] The expiring points investment flag is a Boolean type of information (flag information) that indicates whether token investment using expiring points is enabled or disabled. The operator server 3 is configured to provide the user terminal 2 with a screen to select whether or not to make a token investment using expiring points, and the expiring points investment flag is used to store the result of the selection on this screen. For users whose expiring points investment flag is enabled, the operator server 3 will execute a token investment using expiring points when they occur, while for users whose expiring points investment flag is disabled, the operator server 3 will not execute a token investment even if they occur.

[0037] Here, the system design for token investment using expiring points is preferably an opt-out type, where the investment is executed unless the user of the operator's service explicitly expresses their refusal. In other words, the above selection screen should be a screen for explicitly selecting not to invest in tokens using expiring points, and it is preferable that the token investment using expiring points is executed unless the user actively makes this selection. In this way, users without any particular intention will invest in tokens using expiring points, but since this is an effective use of points that would expire because the user did not use them in the first place, it is unlikely to cause problems, except for the possibility of the troubles mentioned above occurring. Of course, if it is important to reliably avoid the occurrence of the troubles mentioned above, the token investment may be an opt-in type.

[0038] As mentioned above, the user address is the user's wallet address. The operator server 3 provides the user terminal 2 with a screen to input the wallet address, and writes the wallet address entered on this screen to the user management table as the user address of the corresponding user. The user address field in the user management table remains blank until the user enters their user address.

[0039] An SC address is a smart contract address issued individually by the operator server 3 to each user to enable the transfer of tokens to users who do not have a user address. When the operator server 3 registers a new user in the user management table, it issues a new SC address and writes it to the user management table. If a user whose SC address is set in the user management table provides their user address through the input screen mentioned above, the operator server 3 records a transfer transaction on the blockchain to transfer the tokens owned by the corresponding SC address to that user address, and also sets the user address in the user management table. After this, the operator server 3 may or may not delete the user's SC address from the user management table.

[0040] Figures 4 and 5 are sequence diagrams illustrating the token investment process based on points approaching expiration. The following explanation will detail the processes performed by the point management system 1 to implement token investment based on points approaching expiration, referring to these figures.

[0041] Referring to Figure 4, the first step in point allocation is when a user of the operator's service uses the operator's service (Step S1). Upon receiving this use, the operator server 3 issues points (points with an expiration date) according to the content of the use (Step S2) and adds them to the user's point balance management table. After this, the user terminal 2 can access the database 7 via the operator server 3 to find out the balance and expiration date of the issued points (Step S3).

[0042] Next, in the token investment stage using points nearing expiration, the operator server 3 checks for the presence of points nearing expiration for each user of the operator service by periodically referring to the point balance management table shown in Figure 3(b) (step S4). If a user has points nearing expiration, the operator server 3 refers to the user management table shown in Figure 3(c) to determine whether the user's points nearing expiration investment flag is enabled or disabled (step S5). The operator server 3 performs this determination for each user and processes the points nearing expiration for which the corresponding points nearing expiration investment flag is enabled, while terminating the process without performing steps S6 to S15 for points nearing expiration for which the corresponding points nearing expiration investment flag is disabled.

[0043] Here, before the operator server 3 executes steps S4 and S5, for example, at stages such as one year before, six months before, or one month before the expiration date of points, or at any timing considered suitable for investment, such as when the trading price of tokens falls below a predetermined value, the operator server 3 may notify the user that the expiration date of the points will soon expire and encourage the use of points or token investment using points. Specifically, the operator server 3 notifies the user terminal 2 that the expiration date of the points will soon expire, that token investment can be made using points, and that token investment will be automatically executed immediately before the expiration date. At the same time, options such as using points in a rush before expiration, intentionally making token investment using approaching-expiration points, waiting for the automatic execution of token investment by approaching-expiration points, and rejecting the execution of token investment by approaching-expiration points are presented to allow the user to make a choice. By doing so, it becomes possible to give the user an opportunity to choose the use of points according to their own will, and it also becomes possible to prevent the occurrence of the above-mentioned troubles. In addition, when the option of intentionally making token investment using approaching-expiration points is selected in this choice, the operator server 3 may execute the processing of steps S6 to S15 for that approaching-expiration point.

[0044] In step S6, the operator server 3 obtains the current trading price of the tokens from the exchange server 4 (step S6). Also, the operator server 3 obtains the balance of the tokens held by the operator itself from the operator wallet (step S7). In one example, this acquisition is executed by the operator wallet collecting the tokens whose final owner is the operator address in the blockchain and returning the total balance to the operator server 3 as the balance of the tokens held by the operator itself.

[0045] Next, the operator server 3 determines whether the balance of tokens held by the operator is insufficient, based on the total monetary value of the expiring points for which the expiring points investment flag was enabled (step S8). To explain with an example, if the total number of expiring points for which the expiring points investment flag was enabled was X points, and their monetary value as defined in the terms and conditions of the operator service is 2X yen, and the balance of tokens held by the operator is Y yen at the current trading price, then the result of the determination in step S8 is affirmative if Y < 2X, and negative if Y ≥ 2X. However, it is also possible to allow for some leeway, for example, if Y + A < 2X (A is a predetermined positive number), it will be affirmative, and if Y + A ≥ 2X, it will be negative.

[0046] If it is determined in step S8 that there is a shortage, the operator server 3 sends a request to the exchange server 4 to purchase the missing tokens (step S9). Upon receiving this purchase request, the exchange server 4 conducts the buying and selling of tokens in the token trading market and records the transfer of the tokens purchased by the operator to the operator's address on the blockchain (step S10). Although not shown in the diagram, if the transaction is unsuccessful and the missing tokens cannot be purchased, this fact is returned from the exchange server 4 to the operator server 3, and the operator considers alternative measures (such as trying again at a later date or issuing new tokens). After performing step S9, the operator server 3 returns to step S6 and performs the determination in step S8 again. Note that it is common for some time to be required from the sending of the purchase request in step S9 to the completion of the recording in step S10, so it is preferable for the operator server 3 to wait for a predetermined time after performing step S9 before repeating the process from step S6.

[0047] If it is determined in step S8 that there is no shortage, as shown in FIG. 5, the operator server 3 executes the processes of steps S14 to S16 for each user having an expiration approaching point (step S13). Specifically, the operator server 3 first determines whether the user address of the target user is stored by referring to the user management table shown in FIG. 3(c) (step S14). If it is determined that the user address of the target user is stored, the operator server 3 records in the blockchain the transfer of tokens in an amount corresponding to the value of the expiration approaching point of the user among the tokens held by the operator to the user address (step S15). On the other hand, if it is determined that the user address of the target user is not stored, the operator server 3 records in the blockchain the transfer of tokens in an amount corresponding to the value of the expiration approaching point of the user among the tokens held by the operator to the SC address stored in the user management table in association with the user (step S16).

[0048] Here, if the time from checking the expiration approaching point in step S4 to executing steps S13 to S16 becomes long, it is preferable for the operator server 3 to re-check the amount of the expiration approaching point of each user before starting step S13. By doing so, it becomes possible to exclude the points used between step S4 and step S13 from token investment. Also, the operator server 3 may execute steps S13 to S16 after waiting for the expiration of the expiration approaching point. In this case, only the points that have actually expired are the targets of token investment, so it becomes possible to physically avoid the occurrence of the above-mentioned troubles.

[0049] Furthermore, the specific amount of tokens distributed to the user in step S14 or step S15 (i.e., the amount equivalent to the value of the user's points nearing expiration) is preferably determined as follows: That is, if the terms and conditions of the operator service stipulate that 1 point = A yen, the value of one unit of token is B yen at the current trading price, the operator's fee (including the gas required for the transfer of tokens) is C yen, and a user's amount of points nearing expiration is P points, then it is preferable to distribute the tokens to that user in units of (P × A - C) / B. Note that the fee C may be set to 0, in which case the tokens distributed to the user will be in units of (P × A) / B.

[0050] As a result of the processing up to this point, for users who have expiring points, except for those who have explicitly indicated their intention not to invest in tokens using expiring points, the token investment using expiring points will be automatically executed. After this, users who have a user wallet can check the balance of tokens transferred to them by referring to their user wallet (step S17). On the other hand, users who do not have a user wallet can obtain a user wallet and a user address, and then register that user address with the operator server 3 (step S18). The operator server 3 will then record the transfer of tokens from the corresponding SC address to the registered user address on the blockchain (step S19), and after that, they will be able to check the balance of tokens transferred to them by referring to their user wallet (step S20). Note that the balance check in steps S17 and S20 is performed, in one example, by the user wallet gathering tokens in which the user is the final owner within the blockchain, and returning the total balance as the balance of tokens held by the user to the user terminal 2.

[0051] Figures 6 to 8 show examples of screens displayed on the output device 104 of the user terminal 2, which is a smartphone. Each of the screens in the figures constitutes a portal site for the operator service generated by the operator server 3. Figure 6 shows the points history screen for checking the history of point acquisition and usage, Figure 7 shows a modal screen for notifying the user that a token investment has been made using points that are about to expire, and Figure 8 shows the user wallet information screen.

[0052] To explain in more detail, the points history screen in Figure 6 is composed of a summary unit 10, an expiring points information unit 11, and a history unit 12. The summary unit 10 includes the balance of points held by the user, the total amount of points earned this month, and the total amount of points used this month. The expiring points information unit 11 includes the total amount of points scheduled to expire on the earliest expiring date and that expiring date. The history unit 12 includes a list of the history of point acquisition and usage. The operator server 3 generates the points history screen in response to a request for display of the points history screen made by the user's operation on the user terminal 2. Specifically, it refers to the user's points history table and point balance management table (see Figure 3(a)), generates the history unit 12 based on each record in the points history table, generates the summary unit 10 by aggregating each record in the points history table, and further generates the expiring points information unit 11 based on the point balance management table.

[0053] The modal screen in Figure 7 is composed of a token acquisition notification section 20, an acquired token information section 21, an exchange rate information section 22, a token distribution schedule information section 23, a token benefit information section 24, an expired points information section 25, a back button 27, and a wallet button 26. The token acquisition notification section 20 is an area for informing the user that they have acquired tokens, and includes an image (in this example, a picture of a cracker) and text (in this example, "Congratulations on acquiring tokens!") that highlights the token acquisition. The acquired token information section 21 includes the amount of tokens newly acquired by the user and the amount of points used to acquire them. The exchange rate information section 22 includes the actual exchange rate between points and tokens for the tokens newly acquired by the user. The token distribution schedule information section 23 includes the date on which the tokens will be available for viewing in the user's user wallet. The token benefit information section 24 is an area for informing the user of the benefits of holding tokens, and includes text and images that explain the benefits of holding tokens. The expired points information section 25 includes information on the expiration date of the points used to purchase the tokens that have been notified of being acquired on this modal screen. The back button 27 is a button for closing this modal screen. The wallet button 26 is a button for transitioning to the user's user wallet. If the user does not have a user wallet, it is preferable to gray out the wallet button 26.

[0054] The user wallet information screen in Figure 8 is a user interface for a user wallet specially prepared for users of the operator's service, and consists of a summary section 30, a purchase button 31, a transfer button 32, a usage button 33, a transaction history section 34, and a wallet information section 35. The summary section 30 includes the balance of tokens held by the user, the total amount of tokens acquired through conversion from points, and the total amount of tokens purchased (not converted from points). The purchase button 31 is a button to launch a token purchase screen (not shown), on which the user can purchase tokens. The transfer button 32 is a button to launch a transfer screen (not shown), on which the user can send tokens to any wallet. The usage button 33 is a button to launch a usage screen (not shown), on which the user can use tokens for various purposes (such as shopping at online shops or physical stores). The transaction history section 34 includes the history of token transactions related to the user wallet. The wallet information unit 35 includes the wallet address of the user wallet displayed on this user wallet information screen. The operator server 3 generates the user wallet information screen by accessing the blockchain network 5 in response to the user accessing the user wallet information screen, such as by pressing the wallet button 26 in Figure 7.

[0055] As explained above, according to the value medium management system 1 of this embodiment, tokens can be supported by the value medium that is about to expire. Therefore, even if active token investment by users cannot be expected, it becomes possible to support tokens by the value medium that has been granted to users.

[0056] Furthermore, the value medium management system 1 according to this embodiment makes it possible to give users of the operator service an opportunity to become interested in token investment or the operator (not only the operator service but also the operator themselves).

[0057] Next, a value medium management system 1 according to a second embodiment of the present invention will be described. The value medium management system 1 according to this embodiment differs from the value medium management system 1 according to the first embodiment in that it differentiates the value of expiring points depending on the user, and may distribute tokens to users regardless of the expiring points. In other respects, it is the same as the value medium management system 1 according to the first embodiment, so the following description will focus on the differences from the value medium management system 1 according to the first embodiment.

[0058] Figures 9(a) and 9(b) show the adjustment coefficient management table and campaign management table stored in the database 7 according to this embodiment.

[0059] The adjustment coefficient management table is a table that stores the adjustment coefficient AF for the exchange rate between points and tokens for each user ID. The adjustment coefficient AF is usually a number that satisfies the condition 0 < AF ≤ 1. The user IDs are the same as those shown in Figure 3(c). Alternatively, the adjustment coefficient management table and the user management table shown in Figure 3(c) may be merged and managed as a single table.

[0060] Each user's adjustment coefficient AF is set based on the user's actions within the operator's service. For example, the operator server 3 may be configured to increase a user's adjustment coefficient AF when the user views a predetermined advertisement, and to increase the user's adjustment coefficient AF when the user completes a predetermined mission. The operator server 3 may also be configured to decrease a user's adjustment coefficient AF if a predetermined amount of time has passed without the user viewing a predetermined advertisement or completing a predetermined mission. If the operator's service has a user ranking system (a service that ranks users according to their usage status, etc., and grants benefits only to higher-ranked users), the operator server 3 may also vary the user's adjustment coefficient AF according to the user's rank.

[0061] The tokens distributed by the operator server 3 in step S15 or step S16 of Figure 5 in this embodiment can be expressed using the above-mentioned A, B, C, and P as ((P × A - C) / B) × AF units. As can be understood from this formula, the amount of tokens distributed to users decreases as the adjustment coefficient AF decreases. Therefore, according to this embodiment, an incentive is created for each user to increase the adjustment coefficient AF, making it possible to encourage the use of the operator service.

[0062] The campaign management table is a table that stores the source of funds (amount of tokens), the amount distributed per person, and the campaign completion conditions for each campaign ID, which is the identification information of the campaign implemented to distribute tokens to users. The operator server 3 is configured to use this campaign management table to distribute tokens to users regardless of the points approaching expiration.

[0063] It is preferable to use some or all of the tokens that were not distributed to users because the adjustment coefficient AF was less than 1 as the source of funds for the campaign. To explain this in more detail, in step S8 of Figure 4, the operator server 3 determines whether or not the balance of tokens held by the operator is insufficient, without considering the adjustment coefficient AF of each user. Therefore, in steps S15 and S16 of Figure 5, if the amount of tokens to be transferred to each user is reduced according to each user's adjustment coefficient AF, a surplus will occur. It is preferable to use some or all of the tokens corresponding to this surplus as the source of funds for each campaign. However, it is also possible to purchase tokens separately as the source of funds for the campaign.

[0064] The campaign achievement conditions are the requirements necessary to be eligible for token distribution, and as shown in Figure 9, for example, "use the operator service at least once between January 1st and March 31st" or "access the operator service site at least 10 times between July 1st and July 31st." The operator server 3 preferably distributes tokens to users who meet the achievement conditions set in the campaign management table on a first-come, first-served basis, according to the per-person distribution amount set in the campaign management table, until the total amount of tokens distributed reaches the fund set in the campaign management table. As for the specific distribution method, the operator server 3 can perform the transfer to users whose user addresses are stored by recording the transfer to their user addresses on the blockchain, as described in steps S14 to S16 of Figure 5, and to users whose user addresses are not stored by recording the transfer to the SC address stored in the user management table associated with that user on the blockchain.

[0065] As explained above, the value medium management system 1 according to this embodiment makes it possible to utilize token investment using expiring points (value medium) to encourage each user to use the operator's services. Furthermore, by applying the adjustment coefficient AF set for this purpose, it becomes possible to conduct campaigns with tokens as prizes using the surplus tokens as the source of funds, thereby further encouraging each user to use the operator's services.

[0066] Although preferred embodiments of the present invention have been described above, the present invention is not limited in any way to these embodiments, and it goes without saying that the present invention can be implemented in various forms without departing from its essence.

[0067] For example, in the first embodiment described above, the present invention was explained in the case of applying it to token investment using points approaching expiration. However, by replacing tokens with stocks or investment trusts, it is also possible to apply the present invention to stock investment or investment trust investment using points approaching expiration. However, since investments using points approaching expiration are generally small amounts, the present invention is considered to be more suitable for investment in tokens or investment trusts than for stocks, which cannot be invested in unless the amount is less than a unit share.

[0068] Furthermore, in the first embodiment described above, users of the operator service checked the balance of tokens they held by accessing their user wallet. However, the amount of tokens transferred to each user could be stored off-chain, for example, in a database 7, and this information could be made available to users. This would allow users who do not possess a user wallet to check the amount of tokens transferred to them.

[0069] Furthermore, while the first embodiment described above only considered token investment using points nearing expiration, it is certainly possible to allow users to convert points into tokens at their own discretion. In this case, the operator server 3 can receive a conversion operation from a user specifying some or all of the valid points recorded in the point balance management table, and record the transfer of an amount of tokens equivalent to the value of the points specified as the target of conversion to the user (specifically, a transfer to the user's address or SC address) on the blockchain.

[0070] Furthermore, in each of the above embodiments, we have described an example in which the operator server 3 performs all of the following: providing operator services, awarding points, executing token investments using points that are about to expire, purchasing tokens that serve as the source of funds for token investments using points that are about to expire, distributing (transferring) tokens to each user, and conducting campaigns. However, it is of course possible for other servers to handle some of these tasks. Similarly, in each of the above embodiments, we have described an example in which the point history table, point balance management table, user management table, adjustment coefficient management table, and campaign management table are all stored in database 7. However, it is also possible for some of these tables to be stored in other databases.

[0071] Furthermore, in the second embodiment described above, an example was explained in which the amount of tokens to be distributed to each of the one or more users who have achieved the campaign conditions is predetermined in the campaign table. However, the operator server 3 may also divide the funds among the users who have achieved the campaign (that is, distribute the amount of tokens obtained by dividing the funds by the number of users who have achieved the campaign to each user).

[0072] 1 Value medium management system 2 User terminal 3 Operator server 4 Exchange server 5 Blockchain network 6 Network 7 Database 100 Computer 101 CPU 102 Storage device 103 Input device 104 Output device 105 Communication device 106 Bus

Claims

1. A server device connected to a database that manages value media issued to users of a service, and a blockchain that stores token transactions, wherein the server device retrieves the balance of value media that are expiring from the database held by the user, and records the transfer of an amount of tokens to the user, determined based on the retrieved balance, on the blockchain.

2. The server device according to claim 1, wherein the token that records the transfer to the user on the blockchain is a token stored on the blockchain as a token owned by the operator of the service.

3. The server device according to claim 1, further connected to an exchange server that mediates token transactions, obtaining the current trading price of the token from the exchange server, and determining the amount of the token to be transferred to the user and recorded on the blockchain based on the obtained current trading price.

4. The server device according to claim 1, wherein the database manages the expiration dates of the value media, and the balance of the value media that will expire among the value media held by the user is the balance of the value media stored in the database with respect to the user that will expire within a predetermined period.

5. The server device according to claim 1, wherein the database stores flag information for each user indicating whether token investment using a medium nearing expiration is valid or invalid, and if the flag information stored for the user indicates that token investment using a medium nearing expiration is valid, the transfer of an amount of tokens corresponding to the acquired balance to the user is recorded on the blockchain, while if the flag information stored for the user indicates that token investment using a medium nearing expiration is invalid, the process of transferring an amount of tokens corresponding to the acquired balance to the user to the blockchain is not performed.

6. The server device according to claim 1, wherein the database is configured to store, for each user, a user address which is the wallet address of the user, and an SC address which is the address of a smart contract that includes a transfer function that transfers tokens in accordance with instructions from the operator of the service, and if the user's wallet address is stored in the database, the transfer of an amount of tokens corresponding to the acquired balance to the user is recorded on the blockchain, and if the user's wallet address is not stored in the database, the transfer of an amount of tokens corresponding to the acquired balance to the SC address is recorded on the blockchain, and the transfer of an amount of tokens corresponding to the acquired balance to the user is recorded on the blockchain.

7. The server device according to claim 1, which receives a conversion operation from a user to a token that designates some or all of the valid value media recorded in the database, and records the transfer of an amount of tokens corresponding to the value media designated as the target of conversion by the conversion operation to the user on the blockchain.

8. The server device according to claim 1, wherein the database stores an adjustment coefficient for the exchange ratio between the medium of value and the token for each user, and the server device reduces the amount of the token to be transferred to the user and recorded on the blockchain based on the adjustment coefficient.

9. The server device according to claim 8, wherein the database stores the conditions for achieving the campaign, and records the transfer of the tokens to one or more users who have achieved the conditions on the blockchain, using a portion or all of the surplus tokens resulting from reducing the amount of tokens to be transferred to the users based on the adjustment coefficient as the source of funds.

10. A database for managing value media issued to users of a service, a blockchain for storing token transactions, and a program for causing a computer connected to the database to perform the steps of: obtaining from the database the balance of value media that will expire among the value media held by the user; and recording on the blockchain the transfer of an amount of tokens to the user determined based on the obtained balance.

11. A method performed by a computer connected to a database for managing value media issued to users of a service, and a blockchain for storing token transactions, the method comprising: obtaining from the database the balance of value media held by the user that are about to expire; and recording on the blockchain the transfer of an amount of tokens to the user determined based on the obtained balance.

Images