JP2023118842A - Information processing device, information processing method, and information processing program - Google Patents

Abstract

To provide an information processing device capable of supporting user's economic activities by utilizing virtual currency.SOLUTION: According to the present invention, an information processing device 1 capable of giving virtual currency to a user includes an information acquisition part for acquiring information on a user's prescribed service, a usage fee acquisition part for acquiring information on a usage fee corresponding to a purchase amount of a merchandise or a service, a currency acquisition part for acquiring virtual currency by using the information on the usage fee to be acquired by the usage fee acquisition part, and a giving part for giving virtual currency of an amount corresponding to the service in the virtual currency acquired by the currency acquisition part to the user.SELECTED DRAWING: Figure 1

Description

The present invention relates to an information processing device and an information processing method.

In recent years, interest in virtual currency based on blockchain technology has increased, and various service methods using virtual currency have been proposed. For example, Patent Literature 1 discloses an information processing device or the like that accepts payment in virtual currency when purchasing a product at a physical store, and notifies a delivery person to deliver the purchased product to the user's home.

JP 2017-049967 A

However, the invention according to Patent Document 1 only delivers products purchased with virtual currency to users, and does not provide incentives according to purchased products with virtual currency.

An object of one aspect of the present invention is to provide an information processing device or the like that can assist a user in purchasing a product or the like by using virtual currency.

(1) A first aspect of the present invention is an information processing device capable of giving virtual currency to a user, comprising: an information acquisition unit that acquires information on a predetermined service of the user; a usage fee acquisition unit that acquires information on the usage fee obtained by the usage fee; a currency acquisition unit that acquires a virtual currency using the information on the usage fee acquired by the usage fee acquisition unit; and the virtual currency acquired by the currency acquisition unit. and a granting unit that grants the user a virtual currency in an amount corresponding to the service.

(2) In (1) above, a holding information acquisition unit that acquires holding information of the virtual currency of the user, and whether or not the user holds a predetermined number or more of the virtual currency based on the holding information and a determining unit that determines the virtual currency, and the granting unit grants the virtual currency to the user when it is determined that the virtual currency is held in a predetermined number or more.

(3) In (1) or (2) above, the information processing device performs control to display on a predetermined terminal at least part of information corresponding to the amount of virtual currency granted to the user and the user's service. .

(4) In any one of (1) to (3) above, the information processing device uses part of the usage fee acquired by the usage fee acquisition unit as a source of funds for issuing the virtual currency or issuing the virtual currency. A process of purchasing the virtual currency from the holder and procuring the virtual currency to be given by the giving unit is executed.

(5) In any one of (1) to (4) above, when the information processing device determines that the virtual currency is insufficient when the virtual currency is awarded by the granting unit, the virtual currency A new virtual currency is issued within a range not exceeding the upper limit of the total issued amount of the virtual currency, and the virtual currency is given by the giving unit.

(6) In any one of (2) to (5) above, the currency acquisition unit calculates the amount of the virtual currency to be acquired based on the virtual currency holding information of the user.

(7) In any one of (2) to (6) above, the holding information of the virtual currency includes information on at least one of the holding amount and holding period of the virtual currency of the user, and the currency acquisition unit and calculating the amount of the virtual currency to be acquired based on the holding amount and holding period of the virtual currency of the user.

(8) In any one of (2) to (7) above, if the virtual currency is distributed and managed in a plurality of nodes, holding the virtual currency owned by the user by referring to transaction data Get information.

(9) In any one of (2) to (8) above, the holding information acquiring unit acquires holding information indicating a holding period and holding amount of the virtual currency of the user, and the currency acquiring unit The usage fee is used to acquire the information on the service and the amount of the virtual currency corresponding to the retention period and retention amount.

(10) A second aspect of the present invention is an information processing method capable of giving a virtual currency to a user, which acquires information on a predetermined service of the user, obtaining information, obtaining a virtual currency using the information relating to the usage fee obtained by the usage fee obtaining unit, and obtaining a virtual currency in a quantity corresponding to the service among the virtual currency obtained by the currency obtaining unit; Provided is an information processing method characterized by causing a computer to execute processing given to a user.

(11) A third aspect of the present invention includes a purchase information acquisition unit that acquires purchase information regarding a product or service purchased by a user who holds virtual currency, and a purchase information of the product or service from a provider of the product or service. A commission acquisition unit that acquires a commission corresponding to a purchase amount, a currency acquisition unit that acquires a quantity of the virtual currency corresponding to the purchase information using the commission, and gives the acquired virtual currency to the user. An information processing apparatus characterized by comprising a granting unit.

(12) In (11) above, the currency acquisition unit outputs a purchase request for the virtual currency based on the fee to the issuer of the virtual currency or the holder of the virtual currency, and Obtaining said virtual currency from a holder.

(13) In (11) or (12) above, a holding information acquisition unit that acquires holding information indicating the holding status of the virtual currency of the user; and a determination unit that determines whether or not the user holds the currency, and the grant unit grants the virtual currency when it is determined that the virtual currency is held in a predetermined number or more.

(14) In (13) above, the granting unit grants the virtual currency in a quantity corresponding to the holding information.

(15) In the above (11) to (14), an extraction unit for extracting a part of the virtual currency given to the user, and sending the extracted virtual currency to a predetermined destination. and a transmission unit for transmitting.

(16) In (15) above, the destination is a donation destination to which the virtual currency is donated, and a purchase information storage unit that stores the purchase information; a determination unit that determines a plurality of the donation destinations to which the virtual currency is to be transmitted and allocation of the virtual currency to be transmitted to each of the donation destinations based on the purchase history, wherein the transmission unit is determined by the determination unit; The virtual currency is transmitted to each of the donation destinations in accordance with the distribution thus made.

(17) In (16) above, a material storage unit that stores posted material related to the product, service, or donation destination for generating posted information to be posted on the network, and the user indicated by the purchase information. a material output unit that outputs candidates for the posted material to the user based on the product or service purchased by the user or the donation destination determined by the determination unit; and a selection unit that receives selection of the posted material from the user. and a posting output unit that generates the posted information using the selected posted material and outputs the posted information on a network.

(18) A fourth aspect of the present invention acquires purchase information related to a product or service purchased by a user who holds virtual currency, and obtains purchase information from a provider of the product or service according to the purchase amount of the product or service. Information characterized by causing a computer to execute a process of acquiring a fee, using the fee to acquire a quantity of the virtual currency corresponding to the purchase information, and giving the acquired virtual currency to the user. Provide processing methods.

(19) A fifth aspect of the present invention acquires virtual currency from a virtual currency provider in accordance with the amount of money deposited by the user, and sends purchase information on the product or service purchased by the user to the provider. , and acquires the amount of the virtual currency corresponding to the purchase information from the provider, causing a computer to execute a process.

(20) In (19) above, acquiring a captured image of the medium in which the purchase information is described, and outputting information about the captured image to the provider.

(21) In (19) or (20) above, the amount of the virtual currency acquired according to the purchase information, the recipient to whom a portion of the virtual currency was donated, and the virtual currency donated to the recipient Display currency quantities and

(22) In (21) above, obtaining posted material candidates related to the goods, services, or donation recipients for generating posted information to be posted on the network from the provider, and obtaining the posted material candidates; is displayed, the selection of the posted material is accepted, the posted information is generated using the selected posted material, and a request is made to the provider to output it on the network.

(23) A sixth aspect of the present invention acquires virtual currency from a virtual currency provider according to the amount of money deposited by the user, and purchases the amount of virtual currency according to the purchase information related to the product or service purchased by the user. a first program for causing a first computer to execute a process of acquiring said virtual currency from said provider, to be installed in said first computer, receiving a purchase request for goods or services from said user, and receiving said purchase request is received, the purchase information is output to the provider, a notification indicating the amount of the virtual currency granted to the first computer according to the purchase information is obtained, and the notification is sent to the user A manufacturing method for manufacturing a virtual currency trading system composed of the first computer and the second computer by transmitting a second program to be output, which causes the second computer to execute the process, to be installed in the second computer. provide.
(24) In (23) above, when the purchase request is received, the second program determines whether or not the user possesses a predetermined number or more of the virtual currency, When it is determined that the virtual currency is held, the purchase information is output to the provider to obtain the notification.

In one aspect, virtual currency can be used to assist users in purchasing products and the like.

It is a schematic diagram which shows the structural example of a virtual currency trading system. 3 is a block diagram showing a configuration example of a server and terminals; FIG. FIG. 4 is an explanatory diagram showing an example of record layouts of a user DB, a member store DB, and a donation destination DB; 1 is an explanatory diagram showing an overview of Embodiment 1; FIG. FIG. 10 is an explanatory diagram for explaining token back processing and donation processing; FIG. 10 is an explanatory diagram showing an example of a token back screen; It is explanatory drawing which shows an example of a SNS screen. FIG. 10 is a flowchart showing an example of a processing procedure of token granting processing; FIG. FIG. 11 is a flowchart showing an example of a processing procedure of token acquisition processing; FIG. FIG. 10 is an explanatory diagram showing an overview of Embodiment 2; FIG. 4 is an explanatory diagram for explaining screen transitions in a terminal; FIG. 11 is a flow chart showing an example of token granting processing according to the second embodiment; FIG.

Hereinafter, the present invention will be described in detail based on the drawings showing its embodiments.
(Embodiment 1)
FIG. 1 is a schematic diagram showing a configuration example of a virtual currency trading system. In the present embodiment, a virtual currency transaction system that gives virtual currency to the user according to the user's actual purchase situation will be described. The virtual currency trading system includes an information processing device 1 , a terminal device 2 and an issue server 3 . Each device is interconnected for communication via a network N such as the Internet.

The information processing device 1 is an information processing device capable of various types of information processing and transmission/reception of information, and is, for example, a server device, a personal computer, or the like. In the present embodiment, the information processing apparatus 1 is assumed to be a server apparatus, and is replaced with the server 1 for the sake of brevity below. The server 1 functions as an operator (sales office) that accepts deposits from users and sells virtual currency, and transmits virtual currency corresponding to the amount of deposit to the terminal device 2 . In this embodiment, the server 1 sells a virtual currency (token) unique to this system issued by the issuing server 3 to users. At the same time, the server 1 collects purchase information when the user purchases a product or service at a predetermined affiliated store, and as a privilege for the user shopping at the affiliated store, tokens corresponding to the purchase amount are newly given as cash back. Provide a token back service that grants to The specific content of this service will be detailed later.

The terminal device 2 is an information processing terminal owned by a user, such as a smart phone, a personal computer, a tablet terminal, or the like. For the sake of brevity, the terminal device 2 is replaced with the terminal 2 below. The terminal 2 is installed with an application program provided by the server 1, for example, an application program functioning as a virtual currency wallet. The user holds the virtual currency with the wallet.

In addition to installing an application program that functions as a wallet on the user's terminal 2 and holding the virtual currency (token) on the local terminal, the user can hold virtual currency (tokens) in an online account provided by the server 1 or the like on the Web. A form of managing virtual currency may also be included in the present embodiment. That is, the storage location of the virtual currency is not limited to the local terminal, and may be a server device on the cloud.

The issuing server 3 is a server device that functions as an issuer that issues tokens, receives remittances from the server 1 , and transmits to the server 1 tokens corresponding to the remittance amount. The server 1 distributes the tokens purchased from the issuing server 3 to the users.

FIG. 2 is a block diagram showing a configuration example of the server 1 and the terminal 2. As shown in FIG. 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 unit 11 has an arithmetic processing unit such as one or more CPU (Central Processing Unit), MPU (Micro-Processing Unit), GPU (Graphics Processing Unit), etc., and executes the program P1 stored in the auxiliary storage unit 14. By reading and executing, various information processing, control processing, etc. related to the server 1 are performed. The main storage unit 12 is a temporary storage area such as SRAM (Static Random Access Memory), DRAM (Dynamic Random Access Memory), flash memory, etc., and temporarily stores data necessary for the control unit 11 to perform arithmetic processing. Remember. The communication unit 13 includes a processing circuit and the like for performing processing related to communication, and transmits and receives information to and from the terminal 2 and the like.

The auxiliary storage unit 14 is a large-capacity memory, hard disk, or the like, and 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 and a donation destination DB 143 . The user DB 141 is a database that stores information on each user. The member store DB 142 is a database that stores information on each member store. The donation destination DB 143 is a database that stores information on donation destinations to which users can donate tokens. Token donation will be detailed later.

Incidentally, the auxiliary storage unit 14 may be an external storage device connected to the server 1 . Moreover, the server 1 may be a multicomputer consisting of a plurality of computers, or may be a virtual machine virtually constructed by software.

Further, in the present embodiment, the server 1 is not limited to the configuration described above, and may include, for example, a reading unit for reading information stored in a portable storage medium.

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 has an arithmetic processing unit such as one or more CPUs and MPUs, and reads out and executes a program P2 stored in the auxiliary storage unit 27 to perform various information processing and control processing related to the terminal 2. etc. The main storage unit 22 is a temporary storage area such as SRAM (Static Random Access Memory) or DRAM (Dynamic Random Access Memory), and temporarily stores data necessary for the control unit 21 to perform arithmetic processing. The communication unit 23 includes an antenna for communication, a processing circuit, and the like, and transmits and receives information to and from the server 1 and the like. The display unit 24 is a display device such as a liquid crystal display or an organic EL (Electro Luminescence) display, and displays an image given from the control unit 21 . The input unit 25 is an operation component such as a touch panel, mechanical keys, etc., and receives operation input from the user. The image capturing unit 26 is an image capturing mechanism such as a CMOS (Complementary Metal Oxide Semiconductor) camera, and captures an image according to an operation input by a user.

The auxiliary storage unit 27 is a non-volatile memory such as a ROM (Read Only Memory), and stores a program P2 and other data necessary for the control unit 21 to execute processing. The auxiliary storage unit 27 also stores a wallet 271 that stores token data owned by the user. The wallet 271 holds information such as a wallet address and a private key related to the virtual currency wallet.

FIG. 3 is an explanatory diagram showing an example of record layouts of the user DB 141, member store DB 142, and donation destination DB 143. As shown in FIG.
The user DB 141 includes a user ID column, a user name column, a wallet address column, a purchase history column, and an SNS (Social Networking Service) column. The user ID column stores an ID for identifying each user. The user name column stores names of users in association with user IDs. The wallet address column stores the wallet address of the wallet 271 owned by the user in association with the user ID. The purchase history column stores the purchase history of the user's purchase of goods or services at the member store in association with the user ID. The purchase history, as shown in FIG. 3, includes a cashback history indicating the amount of cashback given to the user (the amount returned in tokens) according to the purchase amount. The SNS column stores information about SNS accounts owned by users in association with user IDs.

The member store DB 142 includes a member store ID column, a name column, a collection rate column, a product column, an SNS image column, and a link column. The member store ID column stores an ID for identifying each member store. The name column stores names of member stores in association with member store IDs. The collection rate column stores, in association with the member store ID, the collection rate of the fee collected from the member store according to the purchase amount when the user purchases a product or service at the member store. The product column stores information on products (or services) provided by the member store in association with the member store ID. The SNS image string stores image data for SNS posting related to each product in association with member store IDs and products. The link column stores a link address for transitioning to a web page related to the member store in association with the member store ID. The hyperlink is, for example, an address for transitioning to the member store's home page.

The donation destination DB 143 includes a donation destination ID column, a name column, a wallet address column, an SNS image column, and a link column. The donation destination ID column stores an ID for identifying each donation destination. The name column stores names of donation recipients (for example, facility names, organization names, etc.) in association with donation recipient IDs. The wallet address column stores the wallet address for the recipient to receive the token donation from the user, in association with the recipient ID. The SNS image column stores image data for SNS posting related to the donation recipient in association with the donation recipient ID row. The link column stores a link address to a Web page (for example, home page) related to the donation destination in association with the donation destination ID.

Note that the registration and updating of SNS posting images, links, etc. stored in the donation destination DB 143 may be performed by, for example, the administrator of this system, or may be performed by various facilities or organizations that are donation destinations.

FIG. 4 is an explanatory diagram showing an overview of the first embodiment. FIG. 5 is an explanatory diagram for explaining token back processing and donation processing. FIG. 4 shows how tokens equivalent to cashback are given to a user when he or she purchases a product at a member store, and a portion of the given tokens is donated to a predetermined recipient. FIG. 5 conceptually shows specific processing contents of the token back processing and the donation processing.

First, based on FIG. 4, the outline of this embodiment will be described. As already described, this system handles unique currency (tokens) issued by the issuing server 3 . For example, the issuing server 3 implements ICO (Initial Coin Offering) and sells all or part of the tokens generated by itself. For example, the issuing server 3 sells the tokens to general users (“Token Holder” shown in FIG. 4) and to the server 1 functioning as a token sales operator (provider).

When carrying out an ICO, the issuing server 3 sets an upper limit for the total amount of tokens to be issued, and then supplies the market with tokens corresponding to a portion of the total amount of tokens to be issued. For example, if the total number of issued tokens is 10,000, the issuing server 3 supplies 1,000 tokens, which corresponds to 10% of the total issued amount, at the ICO stage. As will be described later, when a new token purchase request is received from the server 1, the issuing server 3 issues new tokens within a range that satisfies the upper limit of the total issued amount (10,000 tokens) and transmits (sells) them to the server 1. .

The server 1 accepts deposits from users and sells tokens. The server 1 acquires (buys) a token corresponding to the amount of deposit from the issuing server 3, and transmits (remits) it to the wallet address owned by the user. The sent token is stored in the wallet 271 within the terminal 2 . As a result, the user becomes the holder of the token.

In this embodiment, it is assumed that the server 1 transmits (remittance) a token to the terminal 2, but the server 1 performs communication between the terminal 2 and a token exchange, currency exchange, etc. (not shown). The terminal 2 may acquire a token from an exchange or the like instead of the server 1 only by mediating. In other words, the server 1 only needs to be able to operate so that tokens are given to the user according to the amount of money deposited, and it does not have to accept the money itself and sell (transmit) the tokens.

Here, when a user who owns a token makes a purchase at a member store, the token can be transferred according to the purchase price of a product or the like, that is, cashback (tokenback) can be received using the token. A member store is one or a plurality of stores that participate in the tokenback service related to this system, and is a provider that provides products or services to users. It should be noted that the supply source of the product or the like does not have to be a physical store, and may be an EC site or the like that sells the product on the Internet as in Embodiment 2 described later.

The process of giving the user a token equivalent to cashback will be described in detail. First, a user purchases a product or the like at a member store. Although the above-mentioned tokens may be used to purchase products, etc., it is preferable to use payment means other than the tokens (for example, legal currency).

When a user purchases a product or the like, the user operates the terminal 2, takes an image of a paper medium such as a receipt, and transmits the captured image to the server 1 in order to prove to the server 1 that the user has shopped at a member store. do. It should be noted that means for certifying that shopping has been performed is not limited to taking an image of a receipt or the like. For example, the terminal 2 may read a predetermined QR code (registered trademark) printed on a receipt to obtain purchase information of a product or the like, and transfer the purchase information to the server 1 .

When the captured image is acquired from the terminal 2, the server 1 performs image recognition and extracts (acquires) information such as the product purchased by the user, the purchase price, and the date and time of purchase. In addition, the server 1 stores the extracted purchase information in the user DB 141 and accumulates the purchase history.
Although the server 1 performs image recognition in the above description, the terminal 2 may perform image recognition and transmit the recognition result to the server 1 . In other words, the server 1 only needs to be able to acquire information about an image of a receipt or the like, and the information to be acquired may be the image itself or the recognition result of purchase information recognized from the image.

The server 1 calculates the amount of tokens equivalent to cash back given to the user from the purchase price of the product extracted from the captured image. For example, the server 1 calculates the amount of tokens based on information about the tokens owned by the user, in addition to the purchase amount of the product.

The holding information is information indicating the token holding status of the user, and includes, for example, the holding period during which the user continues to hold the token without selling the token, the holding amount of the token held in the wallet 271, and the like. In this embodiment, the server 1 determines the amount of tokens to be transferred to the user according to the holding period and holding amount of the tokens.

Based on FIG. 5, the token back processing will be described based on the holding information. FIG. 5 illustrates how different amounts of tokens are transferred to two users who have purchased the same item, depending on how many tokens they own. In the example shown in FIG. 5, “user A” has held “2.000” tokens for “5 years”. In addition, "user B" has held tokens in a quantity of "1.000", which is less than user A, for a shorter period of "1 year" than user A has.

First, the server 1 determines whether or not each user possesses a predetermined number of tokens or more based on the token holding information of each user. The predetermined number is, for example, one (1.000). If the user does not have one or more tokens, the server 1 does not treat the user as an object of token back even if the purchase information is acquired, and does not give the token. On the other hand, if the user has one or more tokens, the server 1 gives the tokens. That is, the server 1 determines token-back qualified persons based on the minimum holding amount of tokens, and grants tokens to users who have tokens equal to or greater than the minimum holding amount. In the example shown in FIG. 5, both users A and B have one or more coins (1.000 or more), and therefore both are eligible for token back. On the other hand, the server 1 does not give tokens to users who have less than one token. By setting the minimum holding amount necessary to receive token back, the token functions as a kind of membership.

Note that the time point for determining the amount of tokens held may be, for example, the time point at which the user purchases a product or the like at a member store, or may be the time point at which the purchase information (captured image) is transmitted to the server 1. As will be described later, it may be the time when the server 1 acquires the commission from the member store. In this way, the timing of determining whether or not the user is qualified for the token back is not particularly limited.

If the user possesses one or more tokens, the server 1 calculates the amount of tokens to be transferred to the user based on the purchase information of the product or the like. In the case of the example of FIG. 5, for example, the server 1 assigns a quantity of "0.050" tokens, which is equivalent to 1% of the purchase price, to User A who purchased a product of 500,000 yen. It should be noted that the percentage of the purchase amount to be cashed back (token backed) is an arbitrary design matter, and for example, the cashback percentage may be determined for each member store or product. Further, for example, the server 1 may grant a fixed amount of tokens to the user regardless of the difference in the products purchased by the user.

On the other hand, the server 1 assigns to user B, who purchased the same product as user A, 0.005 tokens corresponding to 0.1% of the purchase price. The amount of tokens held by user B is half that of user A, and the holding period is one-fifth. In this way, the server 1 multiplies the purchase price by a coefficient corresponding to the holding period and holding amount, and calculates the amount of tokens to be transferred to each user.

Note that the above calculation method is an example, and the calculation method of the amount of tokens to be given to the user is not limited to this. For example, whether or not the user has sold tokens in the past may be added as one of the holding information used as a basis for calculating the amount of tokens. In addition, the information used as the basis for calculating the amount of tokens is not limited to purchase information of products, etc., and token holding information, and may be other information such as whether or not tokens have been donated, whether or not there has been a post on SNS, etc., which will be described later. good too.

As described above, the server 1 assigns more tokens to users who have held tokens for a longer period of time and who hold more tokens. This creates an incentive for users to hold tokens instead of selling them, which can help increase the value of tokens, which will be described later.

Returning to FIG. 4, the description continues. The server 1, which has given the token to the user, acquires a fee from the member store according to the purchase amount of the product purchased by the user at the member store. The fee is a matching fee paid under the pretext of guiding a user holding a token to a member store. As described above, the server 1 encourages the user to shop at member stores by giving tokens equivalent to cash back. The server 1 collects commissions from member stores in return. For example, the server 1 notifies the member store to pay the fee when the amount of tokens given to the user is converted into legal currency. The member store remits money to the server 1 via a remittance means (not shown) (for example, a financial institution such as a bank).

When a user newly makes a purchase at a member store and transfers the token to the user, the server 1 acquires (purchases) the token using the commission paid by the member store as a source of funds, and gives the token to the user. For example, the server 1 transmits a token purchase request to the issuing server 3 . For example, the server 1 transmits information such as the number of purchased tokens and the purchase price to the issuing server 3 .

When a purchase request is received from the server 1, the issuing server 3 determines whether or not there are any tokens stored (inventory). When determining that tokens are stored, the issuing server 3 transmits to the server 1 the number of tokens requested by the server 1 from the stored tokens. The server 1 transmits (remits) the fee collected from the member store to the issuing server 3 as consideration for token acquisition.

If it is determined that no tokens are stored, the issuing server 3 issues new tokens within a range not exceeding the upper limit of the total amount of issued tokens, and transmits the tokens to the server 1 . For example, if the total issued amount is 10,000 tokens and no tokens are stored in the issuing server 3, the issuing server 3 increases the issued amount by 10% and newly issues (generates) 1000 tokens. The issuing server 3 transmits (sells) the newly issued token to the server 1 .

In the above description, the server 1 procures the token from the issuing server 3, which is the issuer of the token. good. In this case, for example, the server 1 outputs information such as a desired purchase price and a desired purchase quantity of tokens, that is, a purchase request to a virtual currency exchange (not shown), and searches for a holder whose token sale price etc. matches. to execute the sale of tokens. The server 1 executes a transaction in which a token is sent from a holder to whom a transaction has been concluded, and obtains a token to be given to the user. In other words, the server 1 only needs to be able to procure tokens using fees collected from affiliated stores, and may acquire tokens from issuers or from other token holders.

With the above processing, tokens are newly procured from the stock of the issuing server 3 (or from token holders), so the effect of raising the price of tokens works. In the above, in order to avoid an excessive rise in token value, new tokens are issued when the issued tokens are no longer stored. If you look at it, the price of the token will increase.

As a result, the value of the token held by the user increases. Therefore, users can not only obtain tokens simply by shopping, but can also expect the value of their own tokens to rise as they purchase more products. This stimulates the user's willingness to purchase, and the affiliated store can expect an increase in sales. The server 1 functions as an operator that sustainably leads the above-described purchase cycle, grants tokens, and collects fees from member stores.

Furthermore, in the present embodiment, the server 1 performs donation processing of transmitting (remittance) part of the tokens given to the user as cash back to a predetermined donation destination. The contents of the donation process are conceptually illustrated on the right side of FIG. For example, the administrator of this system cooperates with nature conservation groups, animal protection groups, child support facilities, educational institutions, etc., and donates tokens to each group and facility as the recipient. Note that these organizations and facilities are examples, and the donation destination is not particularly limited. Each donation destination has a wallet address for receiving donation of the token, and the server 1 transmits the token to the wallet address.

The server 1 extracts part of the tokens to be transferred to the user, and transmits the part of the tokens to each donation destination. There is no particular limitation on the ratio of donated tokens among the tokens equivalent to cashback. When donating tokens, the server 1 may accept the designation of the donation destination from the user, but allocation processing that predicts the donation destination that the user would like to donate and the distribution of the tokens to be donated to each donation destination. and automatically donate.

For example, the server 1 determines a donation destination and distribution based on the user's purchase history of products and the like. The method of determining the recipient and distribution from the purchase history is not particularly limited. environmental protection group, education-related group, etc.), and the recipient and distribution of the donation may be determined on a rule basis. In addition, for example, the server 1 manually accepts input from each user of settings for donation destinations and allocations, accumulates samples to some extent, then matches users based on their purchase histories, and makes the same donations as users with similar purchase histories. You may decide to go ahead and share. In addition, for example, the server 1 introduces a machine learning algorithm, constructs a learning model with purchase history as input values and donation destinations and allocations as output values, and determines donation destinations and allocations using the learning model. may

Through the above process, the server 1 generates different donation allocations based on each user's purchase history, as shown on the right side of FIG. For example, in the case of user A, the server 1 sets a large weight for donations to environmental protection groups and educational institutions. In the case of user B, the server 1 sets a large weight for donations to educational institutions and animal protection groups.

In the above description, the destination and distribution of tokens are determined based on the user's purchase history, but the allocation may be performed based on attributes such as the user's gender, age, occupation, and the like. In other words, the server 1 only needs to be able to automatically determine the donation destination and distribution, and the determination criteria are not limited to the purchase history.

FIG. 6 is an explanatory diagram showing an example of the token back screen. FIG. 6 shows an example of a display screen on which the user can check the tokens received as cashback. The token back screen displays purchase information 61 such as the product that caused the token back, token back 62 that indicates the amount of tokens given, allocation 63 that indicates the recipient and allocation, and SNS images 64, 64, 64, and so on. include.

The SNS image 64 is a posting material prepared in advance by the server 1 for uploading to the SNS, and is, for example, an image of a product purchased by the user, or an image of a recipient to which the user has donated a token. As shown in FIG. 6, the SNS image 64 for uploading the purchased product to the SNS and the SNS image 64 for uploading the donation destination are displayed on the token back screen. When notifying the user of the token back or the like via the token back screen, the server 1 also searches various databases for the SNS image 64 of the product or the donation recipient, and outputs a plurality of candidates on the token back screen.

The terminal 2 receives a selection input for selecting one of the SNS images 64 that the user desires to upload from the displayed SNS images 64 . When a selection input to the SNS image 64 is accepted, for example, the terminal 2 displays a pop-up screen (not shown) and accepts an input such as a comment for SNS upload. The terminal 2 notifies the server 1 of the selected content of the SNS image 64 and the input content such as a comment, generates an article (posted information) to be posted on the SNS, and requests it to be uploaded.

FIG. 7 is an explanatory diagram showing an example of the SNS screen. The server 1 generates the posted article shown in FIG. 7 and outputs (uploads) it on the SNS. FIG. 7A shows a screen example when a purchase product is selected in the SNS image 64, and FIG. 7B shows a screen example when a donation destination is selected.

A posted article posted to the SNS includes, for example, the user's account name, comments, the SNS image 64, and a link 71. FIG. A link 71 is a hyperlink for transitioning to a web page related to a member store or a donation destination, such as a link to a home page of the member store or the donation destination. The server 1 generates a posted article including the link 71 based on the input content on the terminal 2 and uploads it to the user's SNS account. As a result, the information about the member store or the donation destination is spread on the SNS, and it is possible to encourage other users to participate in the service related to this system. In addition, it is possible to increase the social satisfaction of the user who purchased the product or the like and donated the token, thereby stimulating the user's willingness to purchase and donate.

FIG. 8 is a flowchart illustrating an example of a processing procedure for token grant processing. Based on FIG. 8, the processing contents of the token back processing for granting the token to the user will be described. For the sake of brevity, the explanation will be made assuming that the user has already made a payment to the server 1 and has a certain amount of tokens.
The control unit 21 of the terminal 2 acquires a captured image of the paper medium in which the purchase information is written, and transmits the captured image to the server 1 (step S11). The paper medium is, for example, a receipt, a receipt, or the like. The control unit 21 takes an image of a receipt or the like according to an operation by the user, and transmits the taken image to the server 1 .

When the captured image is acquired from the terminal 2, the control unit 11 of the server 1 performs image recognition on the image, and acquires purchase information regarding the product purchased by the user (step S12). For example, the control unit 11 extracts information such as the purchase price of the product, the purchased product, and the date and time of purchase from the captured image. Control unit 11 stores the extracted purchase information in user DB 141 .

In addition, the control unit 11 refers to the transaction data recorded in the blockchain, and acquires holding information indicating the holding status of tokens held by the user (step S13). The holding information is, for example, information such as holding period and holding amount of tokens.

The control unit 11 determines whether or not the user possesses a predetermined number or more of tokens based on the obtained possession information (step S14). If it is determined that the predetermined number of tokens or more is not held (S14: NO), the control unit 11 terminates the series of processes.

If it is determined that the predetermined number or more of tokens are possessed (S14: YES), the control unit 11 determines the amount of cash given to the user based on the purchase information acquired in step S12 and the possession information acquired in step S13. A token amount corresponding to the back is calculated (step S15). For example, the control unit 11 calculates the amount of cash back based on the purchase amount of the product or the like, the holding period and amount of tokens, and calculates the amount of tokens corresponding to the cash back amount. Note that the control unit 11 stores the calculated cashback amount in the user DB 141 .

The control unit 11 extracts a portion of the calculated tokens, determines one or a plurality of donation recipients to which the partial tokens are donated, and determines the distribution of the tokens to be donated to each donation recipient (step S16). For example, the control unit 11 determines a donation destination and distribution based on the user's past purchase history. The control unit 11 transmits part of the tokens calculated in step S15 to the user's terminal 2 and part to each donation destination determined in step S16 (step S17).

When tokens equivalent to cashback are acquired from the server 1, the control unit 21 of the terminal 2 displays the quantity of the tokens granted from the server 1 on the display unit 24 (step S18). For example, the control unit 21, as illustrated in FIG. 6, is the number of tokens returned (given) to the user, the recipient and distribution of a portion of the tokens, and the image candidates for SNS upload. SNS images 64, 64, 64, . . . are displayed. The SNS image 64 is an image related to the product or the like purchased by the user or an image related to the donation destination.

The control unit 21 receives a selection input for selecting one of the SNS images 64 displayed in step S18 (step S19). Furthermore, the control unit 21 receives an input such as a comment to be posted together with the selected image (step S20). The control unit 21 requests the server 1 to generate and upload an article (post information) to be posted on the SNS based on the image selected in step S19 and the comment or the like input in step S20 (step S21). When an upload request is received from the terminal 2, the control unit 11 of the server 1 generates an article for SNS upload using the posted materials such as the image selected in step S19 and the comment input in step S20, and posts the article to the SNS. upload to the top (step S22). The article includes the image selected in step S19, the comment input in step S20, and a link 71 for transitioning to a web page related to the affiliated store or donation destination. The control unit 11 ends the series of processes.

FIG. 9 is a flowchart illustrating an example of a processing procedure for token acquisition processing. Token acquisition processing for acquiring a token by collecting a fee from a member store will be described with reference to FIG.
The control unit 11 of the server 1 starts the following processes by, for example, batch processing. The control unit 11 acquires (collects) a fee corresponding to the cashback amount given to the user from the member store (step S31). For example, the control unit 11 refers to the cashback (tokenback) history stored in the user DB 141 and notifies the member store to pay a fee corresponding to the cashback amount. The control unit 11 receives remittance of fees via, for example, a financial institution.

The control unit 11 makes a purchase request to purchase the token equivalent to the cashback given to the user from the token issuer (issuing server 3) (step S32). Then, the control unit 11 acquires a token from the issuing server 3 using the fee acquired in step S31 (step S33). That is, the control unit 11 purchases the token using the commission paid by the member store. For example, when the issuing server 3 receives a purchase request in step S32, it determines whether or not there is a storage (inventory) of tokens for the requested amount. When determining that there are the requested tokens, the issuing server 3 transmits the requested tokens from the stored tokens to the server 1 . When it is determined that there are no required tokens, the issuing server 3 issues new tokens within a range not exceeding the upper limit of the total issued amount, and transmits the tokens of the quantity requested by the server 1 from the newly issued tokens. The control unit 11 ends the series of processes.

In the above description, part of the token given to the user is donated to a predetermined donation destination, but the present embodiment is not limited to this. For example, the server 1 may distribute tokens to employees of a company for welfare purposes within the company, and give a portion of the tokens to be transferred to other employees as a reward for employees who perform well. Also, for example, the server 1 sells tokens that can be used to obtain token back only in a specific region as a regional promotion measure, and may transmit part of the tokens transferred to the user to the local government as tax revenue of the local government. good. In this way, the server 1 only needs to be able to transmit part of the tokens given to the user to a predetermined destination, and the purpose of transmission does not have to be the purpose of donation.

In the above description, the SNS image 64 is used as an example of the material for posting to the SNS, but the material to be posted is not limited to images (still images and moving images), and may be text, audio data, and the like.

In the above description, for convenience of explanation, the server 1 collects (acquires) a fee from the affiliated store after granting the user a token equivalent to cashback, and procures (acquires) the token from the issuer server 3. , after the procurement of tokens is completed, tokens equivalent to cashback may be given to the user. In this case, for example, the server 1 displays the scheduled token back amount on the token back screen immediately after shopping by the user, and transmits the tokens again after completing the procurement of the tokens. In this way, the order of granting a token to a user, obtaining a fee from a member store, and obtaining a token from the issuing server 3 is an arbitrary design matter, and each process may be changed.

Moreover, although the server 1 obtains the purchase information from the user's terminal 2 above, the purchase information may be obtained from the member store. For example, the server 1 may acquire the user's purchase history from the member store's POS (Point of Sales) system.

In this case, for example, the server 1 distributes to the user an application program (first program, program P2) that functions as a wallet for receiving tokens, and an application program (second program P2) that transmits purchase information to the server 1. program) to member stores (providers of goods or services). The application program (second program) is installed, for example, in a predetermined terminal device installed in a member store, or in a POS server or the like that manages the terminal device. The application program receives a purchase request from a user and causes a computer such as a terminal device installed at a member store or a POS server to transmit purchase information to the server 1 . Furthermore, the application program obtains from the server 1 a notification indicating the amount of tokens to be given to the user so that the user can know the amount of tokens to be cashed back, and sends the notification (the amount of tokens equivalent to cashback) to the member store. Display (output) on a display or the like is executed.

Further, as described above, in order to grant tokens to a user who possesses a predetermined number or more of tokens, for example, the above application program, when receiving a purchase request, checks whether the user's token holding amount is equal to or greater than a predetermined number. Only when the user has a predetermined number of tokens or more, the purchase information may be transmitted to the server 1 to obtain a token back notification. In this case, the above application program may, for example, inquire of the server 1 about the amount of tokens held by the user, or may refer to the block chain by itself to search for the amount of tokens held by the user.

As described above, according to the first embodiment, the server 1 grants tokens equivalent to cash back to users who have tokens (virtual currency) according to purchase information of products and the like at affiliated stores. As a result, unlike a payment system using a simple virtual currency, the virtual currency can be utilized to assist the user in purchasing a product or the like. In addition, cashback equivalent tokens can be funded based on commissions earned from merchants, supporting a sustainable buying cycle.

Further, according to the first embodiment, the server 1 procures tokens equivalent to cashback from the issuer or from the market, using commissions from member stores as funds. As a result, it is possible to reduce the circulation of tokens and promote an increase in the value of tokens.

Further, according to the first embodiment, tokens equivalent to cashback are granted only to users who have a predetermined number of tokens or more. By setting the minimum holding amount required to receive token back, the token can function as a kind of membership, and a sustainable purchase cycle can be constructed more appropriately.

Further, according to the first embodiment, the number of tokens to be granted is determined according to the token holding status of the user, such as the token holding period and holding amount. As a result, users will have an incentive to hold tokens without selling them, and they can expect the value of tokens to rise.

Further, according to the first embodiment, the server 1 extracts part of the token to be given to the user and transmits it to a predetermined destination (for example, a donation destination, an employee in the company, a local government, etc.). As a result, for example, donation (donation) activities, corporate activities, regional development, etc. can be supported, and the virtual currency can be utilized not only as purchasing support but also as a sustainable social support measure.

Further, according to the first embodiment, the recipient and distribution are automatically determined based on the user's purchase history, and the token is transmitted. As a result, the user can make a donation with an appropriate allocation without selecting a donation destination by himself/herself, and convenience can be improved.

Further, according to the first embodiment, the server 1 presents materials for SNS posting to the user, generates a posted article (posted information) in response to the user's selection, and automatically uploads the posted article (posted information). As a result, it is possible to inform other users of the products purchased by the user or the destination of the token donation, to encourage participation in this service, increase user satisfaction, and encourage further purchasing and donation activities. can be promoted.

(Embodiment 2)
In this embodiment, a form in which a token is given when a product is purchased by an EC service such as an EC site will be described. In addition, the same code|symbol is attached|subjected about the content which overlaps with Embodiment 1, and description is abbreviate|omitted.
FIG. 10 is an explanatory diagram showing an overview of the second embodiment. FIG. 10 conceptually illustrates how a user purchases a product using an EC site and obtains a token corresponding to the purchase amount. An EC site is, for example, a virtual store on the Internet, and is a website that presents products on a browser. For example, a user can purchase an item from an exhibitor via an EC site or from an EC site operating company, and receive delivery of the item.

In this embodiment, the server 1 cooperates with an EC site, acquires product purchase information from an EC server 4 that manages the EC site, and gives tokens to users who use the EC site. In this case, the server 1 acquires a commission from the EC site management company, purchases a token using the commission as a source of funds, and gives the token to the user.

FIG. 11 is an explanatory diagram for explaining screen transitions on the terminal 2. As shown in FIG. Based on FIG. 11, the screen transition process from the EC site to the token back screen (see FIG. 6) will be described.
The terminal 2 first accesses the EC server 4 and displays a browser screen related to the EC site. The screen displays product information related to products exhibited on the EC site. The terminal 2 accepts an operation input by the user, and accepts a designation input of a product that the user wishes to purchase. The terminal 2 requests the EC server 4 to purchase the designated product.

When receiving the purchase request, the EC server 4 executes a predetermined settlement process to confirm the purchase of the product. The EC server 4 transmits to the server 1 the purchase information of the product whose purchase has been confirmed. In addition, the EC server 4 causes the terminal 2 to display an end screen (not shown) indicating that the payment has been completed, and notifies the user that the shopping has been completed.

Here, the EC server 4 displays a link for starting the application program (program P2) provided by the affiliated server 1 on the end screen. For example, as shown in FIG. 11, the EC server 4 displays text with a hyperlink "Would you like to share?" on the end screen. When the text is manipulated, the terminal 2 activates the application program. For example, the terminal 2 displays the token back screen illustrated in FIG. 6 and presents a plurality of SNS images 64, 64, 64, . . . to the user. By selecting the SNS image 64, the user can automatically post to the SNS as in the first embodiment.

As described above, this system can also be implemented in so-called online shopping via EC sites. In particular, in the present embodiment, after completing the purchase of a product on the EC site, a link to the application program is displayed on the end screen, and an operation to the link triggers a transition to the display screen of the SNS image 64 . As a result, the user can smoothly post to the SNS after shopping on the EC site.

FIG. 12 is a flowchart illustrating an example of token granting processing according to the second embodiment. Based on FIG. 12, the contents of the token granting process according to the second embodiment will be explained.
The control unit 21 of the terminal 2 accesses the EC server 4 and requests the EC server 4 to output product information (step S201). When receiving the product information output request, the EC server 4 outputs the product information to the terminal 2 (step S202).

The control unit 21 of the terminal 2 displays the product information output from the EC server 4 on the browser (step S203). The control unit 21 receives an operation input relating to a purchase request for a product from the user, and transmits the operation input to the EC server 4 (step S204).

When receiving the purchase request, the EC server 4 executes payment processing for purchasing and paying for the requested product (step S205). For example, the EC server 4 withdraws money from the user's bank account via a credit company or the like based on the user's credit card number registered in advance.

The EC server 4 transmits purchase information regarding the product purchased by the user to the server 1 (step S206). The control unit 11 of the server 1 acquires purchase information from the EC server 4 (step S12), and shifts the process to step S13.

The EC server 4 notifies the terminal 2 that the settlement process has ended (step S207). Based on the notification from the EC server 4, the control unit 21 of the terminal 2 displays an end screen indicating that the payment has been completed (step S208). The end screen includes a link for activating the application program (P2) provided by the server 1 and transitioning to the display screen of the SNS image 64, in addition to the purchased product, purchase amount, and the like. Based on the operation input by the user, the control unit 21 determines whether or not to start the application program and post to the SNS (step S209). If it is determined not to post (S209: NO), the control unit 21 terminates the series of processes. If it is determined to post (S209: YES), the control unit 21 activates the application program and displays the token back screen including the SNS image 64 (step S210). The control unit 21 shifts the process to step S17.

In addition, although the form of purchasing products on an EC site (web site) has been described above, a form in which a dedicated GUI application is installed on the terminal 2 and the EC service is received on the GUI screen of the application is also included in the present embodiment. included in the category. In other words, the server 1 only needs to be able to grant a token when a user purchases a product using an EC service, and the form of the EC service is not limited to a website.

As described above, according to the second embodiment, the present system can be applied to the case of purchasing products through an EC site.

The embodiments disclosed this time are illustrative in all respects and should not be considered restrictive. The scope of the present invention is indicated by the scope of the claims rather than the meaning described above, and is intended to include all modifications within the scope and meaning equivalent to the scope of the claims.

1 server (information processing device)
11 Control Unit 12 Main Storage Unit 13 Communication Unit 14 Auxiliary Storage Unit P1 Program 141 User DB
142 Merchant DB
143 Destination DB
2 terminal (terminal device)
21 control unit 22 main storage unit 23 communication unit 24 display unit 25 input unit 26 imaging unit 27 auxiliary storage unit P2 program 271 wallet

Claims (10)

An information processing device capable of giving virtual currency to a user,
an information acquisition unit that acquires information about a user's predetermined service;
a usage fee acquisition unit that acquires information on the usage fee according to the purchase amount of the product or service;
a currency acquisition unit that acquires a virtual currency using information about the usage fee acquired by the usage fee acquisition unit;
a granting unit that grants to the user a virtual currency in a quantity corresponding to the service among the virtual currencies acquired by the currency acquisition unit;
An information processing device comprising: a holding information acquisition unit that acquires holding information of the virtual currency of the user;
a determination unit that determines whether or not the user possesses a predetermined number or more of the virtual currency based on the holding information;
The information processing apparatus according to claim 1, wherein said granting unit grants said virtual currency to said user when it determines that said virtual currency is held in a predetermined number or more. 3. The information processing according to claim 1, wherein said information processing device performs control to display on a predetermined terminal at least part of information corresponding to the amount of virtual currency granted to said user and said user's service. Device. The information processing device purchases the virtual currency from the issuer of the virtual currency or the holder of the virtual currency using a portion of the usage fee acquired by the usage fee acquisition unit as a resource, and grants the virtual currency by the granting unit 4. The information processing apparatus according to any one of claims 1 to 3, which executes a process of raising currency. When the provision unit determines that the virtual currency is insufficient, the information processing device issues a new virtual currency within a range not exceeding the upper limit of the total amount of the virtual currency to be issued. 5. The information processing apparatus according to any one of claims 1 to 4, wherein said granting unit grants said virtual currency. The information processing apparatus according to any one of claims 2 to 5, wherein the currency acquisition unit calculates the amount of the virtual currency to be acquired based on the virtual currency holding information of the user. The holding information of the virtual currency includes information on at least one of the holding amount and holding period of the virtual currency of the user,
7. The information processing according to any one of claims 2 to 6, wherein said currency acquisition unit calculates the amount of said virtual currency to be acquired based on said user's holding amount and holding period of said virtual currency. Device. 8. The method according to any one of claims 2 to 7, wherein when the virtual currency is distributed and managed in a plurality of nodes, transaction data is referenced to obtain holding information of the virtual currency held by the user. The information processing device according to . The holding information acquisition unit acquires holding information indicating a holding period and holding amount of the virtual currency of the user,
9. The currency acquisition unit uses the usage fee to acquire a quantity of the virtual currency corresponding to the information on the service and the retention period and retention amount. The information processing device according to . An information processing method capable of granting a virtual currency to a user,
obtain information about a given service of the user;
Acquiring information on usage fees according to the purchase amount of products or services,
using the information on the usage fee acquired by the usage fee acquisition unit to acquire a virtual currency;
Giving the user a virtual currency in a quantity corresponding to the service among the virtual currencies acquired by the currency acquisition unit;
An information processing method characterized by causing a computer to execute processing.