Information processing method, information processing device, and information processing program

Abstract

To provide an information processing apparatus and the like that can support a user's economic activity by using virtual currency.SOLUTION: The present invention relates to an information processing apparatus 1 capable of providing virtual currency to a user, and comprising: an information acquisition unit that acquires information on a predetermined service for the user; a usage fee acquisition unit that acquires information on a usage fee according to an amount of purchase of commodities or the service; a currency acquisition unit that acquires virtual currency by using the information on the usage fee acquired by the usage fee acquisition unit; and an imparting unit that imparts virtual currency in a quantity according to the service out of the virtual currency acquired by the currency acquisition unit to the user.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to an information processing method, an information processing device, and an information processing program. [Background technology]

[0002] In recent years, interest in virtual currencies based on blockchain technology has been growing, and various service methods utilizing virtual currencies have been proposed. For example, Patent Document 1 discloses an information processing device that accepts payment in virtual currency when purchasing goods at a physical store and notifies a delivery person to deliver the purchased goods to the user's home. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Publication No. 2017-049967 Summary of the Invention [Problem to be solved by the invention]

[0004] However, the invention of Patent Document 1 only delivers products purchased with virtual currency to the user, and does not provide incentives based on the purchased products, etc., using virtual currency.

[0005] In one aspect, an object is to provide an information processing device or the like that can utilize virtual currency to assist users in purchasing products or the like. [Means for solving the problem]

[0006] (1) A first aspect of the present invention is an information processing device capable of granting virtual currency to a user, characterized in that it comprises an information acquisition unit that acquires information regarding a specified service of the user, a usage fee acquisition unit that acquires information regarding a usage fee corresponding to the purchase amount of a product or service, a currency acquisition unit that acquires virtual currency using the information regarding the usage fee acquired by the usage fee acquisition unit, and an awarding unit that grants to the user a quantity of the virtual currency acquired by the currency acquisition unit corresponding to the service.

[0007] (2) In the above (1), the system includes a holding information acquisition unit that acquires information on the user's holdings of the virtual currency, and a judgment unit that determines whether the user holds a predetermined number or more of the virtual currency based on the holding information, and the granting unit grants the virtual currency to the user when it is determined that the user holds a predetermined number or more of the virtual currency.

[0008] (3) In the above (1) or (2), the information processing device controls to display on a predetermined terminal the amount of virtual currency to be granted to the user and at least part of the information corresponding to the service provided by the user.

[0009] (4) In any one of (1) to (3) above, the information processing device purchases the virtual currency from the issuer or holder of the virtual currency using a portion of the usage fee acquired by the usage fee acquisition unit as a source of funds, and executes a process of procuring the virtual currency to be granted by the granting unit.

[0010] (5) In any one of (1) to (4) above, if the information processing device determines that there is insufficient virtual currency when the granting unit grants the virtual currency, the information processing device issues new virtual currency within the limit of the total amount of virtual currency to be issued, and grants the virtual currency using the granting unit.

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

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

[0013] (8) In any one of (2) to (7) above, if the virtual currency is managed in a distributed manner across multiple nodes, the transaction data is referenced to obtain information on the virtual currency held by the user.

[0014] (9) In any one of (2) to (8) above, the holding information acquisition unit acquires holding information indicating the holding period and holding amount of the virtual currency held by the user, and the currency acquisition unit uses the usage fee to acquire information about the service and the amount of the virtual currency corresponding to the holding period and holding amount.

[0015] (10) A second aspect of the present invention provides an information processing method capable of granting virtual currency to a user, characterized in that the information processing method causes a computer to execute a process of acquiring information about a specified service of the user, acquiring information about a usage fee corresponding to the purchase amount of a product or service, acquiring virtual currency using the information about the usage fee acquired by the usage fee acquisition unit, and granting to the user an amount of virtual currency acquired by the currency acquisition unit corresponding to the service.

[0016] (11) A third aspect of the present invention provides an information processing device comprising: a purchase information acquisition unit that acquires purchase information regarding a product or service purchased by a user who holds virtual currency; a fee acquisition unit that acquires a fee according to the purchase amount of the product or service from the provider of the product or service; a currency acquisition unit that uses the fee to acquire the virtual currency in a quantity according to the purchase information; and an awarding unit that awards the acquired virtual currency to the user.

[0017] (12) In the above (11), 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 acquires the virtual currency from the issuer or holder.

[0018] (13) In (11) or (12) above, a holding information acquisition unit is provided that acquires holding information indicating the user's holding status of the virtual currency, and a judgment unit is provided that judges whether the user holds a predetermined number or more of the virtual currency based on the holding information, and if it is judged that the user holds a predetermined number or more of the virtual currency, the granting unit grants the virtual currency.

[0019] (14) In the above (13), the granting unit grants the virtual currency in an amount corresponding to the holding information.

[0020] (15) In the above (11) to (14), an extraction unit is provided that extracts a portion of the virtual currency from the virtual currency to be granted to the user, and a transmission unit is provided that transmits the extracted virtual currency to a predetermined destination.

[0021] (16) In (15) above, the destination is a recipient to which the virtual currency is donated, and includes a purchase information storage unit that stores the purchase information, and a determination unit that refers to the purchase information storage unit and determines, based on the user's purchase history, multiple recipients to which the virtual currency is sent and the allocation of the virtual currency to be sent to each of the recipients, and the sending unit sends the virtual currency to each of the recipients in accordance with the allocation determined by the determination unit.

[0022] (17) In (16) above, the system includes a material storage unit that stores posting materials related to the product, service, or donation destination in order to generate posting information to be posted on a network; a material output unit that outputs candidates for the posting materials to the user based on the product or service purchased by the user indicated by the purchase information or the donation destination determined by the determination unit; a selection unit that accepts a selection of the posting materials from the user; and a posting output unit that generates the posting information using the selected posting materials and outputs it on a network.

[0023] (18) A fourth aspect of the present invention provides an information processing method characterized by having a computer execute a process of acquiring purchase information regarding a product or service purchased by a user who holds virtual currency, acquiring a fee from the provider of the product or service according to the purchase amount of the product or service, using the fee to acquire the virtual currency in an amount according to the purchase information, and granting the acquired virtual currency to the user.

[0024] (19) A fifth aspect of the present invention relates to a program that causes a computer to execute a process of acquiring virtual currency from a provider of the virtual currency in accordance with the amount deposited by a user, outputting purchase information regarding a product or service purchased by the user to the provider, and acquiring the amount of the virtual currency from the provider in accordance with the purchase information.

[0025] (20) In the above (19), a captured image of the medium on which the purchase information is written is acquired, and information relating to the captured image is output to the provider.

[0026] (21) In (19) or (20) above, the quantity of the virtual currency acquired according to the purchase information, the recipient to which a portion of the virtual currency was donated, and the quantity of the virtual currency donated to the recipient are displayed.

[0027] (22) In (21) above, in order to generate posting information to be posted on the network, candidate posting materials related to the product, service, or donation recipient are obtained from the provider, the candidate posting materials are displayed, the selection of the posting material is accepted, the selected posting material is used to generate the posting information, and the provider is requested to output it on the network.

[0028] (23) A sixth aspect of the present invention provides a method for producing a virtual currency trading system constituted by the first computer and the second computer, comprising: transmitting to the first computer, for installation thereon, a first program causing a first computer to execute a process of acquiring virtual currency from a virtual currency provider in accordance with an amount deposited by a user, and acquiring the virtual currency from the provider in a quantity corresponding to purchase information regarding a product or service purchased by the user; accepting a purchase request for a product or service from the user; and, upon acceptance of the purchase request, outputting the purchase information to the provider; obtaining a notification indicating the quantity of the virtual currency to be granted to the first computer in accordance with the purchase information; and outputting the notification to the user; (24) In the above (23), when the second program receives the purchase request, it determines whether the user holds a predetermined number or more of the virtual currency, and if it determines that the user holds a predetermined number or more of the virtual currency, it outputs the purchase information to the provider and obtains the notification. [Effects of the Invention]

[0029] In one aspect, virtual currency can be used to assist users in purchasing products and the like. [Brief explanation of the drawings]

[0030] [Figure 1] FIG. 1 is a schematic diagram illustrating an example of the configuration of a virtual currency trading system. [Figure 2] FIG. 2 is a block diagram illustrating an example of the configuration of a server and a terminal. [Figure 3] 10 is an explanatory diagram showing an example of the record layout of a user DB, a member store DB, and a donation destination DB. FIG. [Figure 4] FIG. 1 is an explanatory diagram showing an overview of a first embodiment. [Figure 5] FIG. 10 is an explanatory diagram for explaining a token back process and a donation process. [Figure 6] FIG. 10 is an explanatory diagram illustrating an example of a token back screen. [Figure 7] FIG. 10 is an explanatory diagram showing an example of an SNS screen. [Figure 8] 10 is a flowchart illustrating an example of a processing procedure of a token granting process. [Figure 9] 10 is a flowchart illustrating an example of a processing procedure for a token acquisition process. [Figure 10] FIG. 10 is an explanatory diagram showing an overview of a second embodiment. [Figure 11] FIG. 10 is an explanatory diagram for explaining screen transitions on the terminal. [Figure 12] 10 is a flowchart illustrating an example of a token granting process according to the second embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0031] The present invention will be described in detail below with reference to the drawings showing embodiments thereof. (Embodiment 1) FIG. 1 is a schematic diagram showing an example of the configuration of a virtual currency trading system. In this embodiment, a virtual currency trading system is described that grants virtual currency to a user according to the user's actual purchasing status. The virtual currency trading system includes an information processing device 1, a terminal device 2, and an issuing server 3. Each device is connected to each other via a network N such as the Internet for communication.

[0032] The information processing device 1 is an information processing device capable of various information processing and information transmission / reception, such as a server device or a personal computer. In this embodiment, the information processing device 1 is assumed to be a server device, and for simplicity, will be referred to as server 1 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 deposited amount to the terminal device 2. In this embodiment, the server 1 sells virtual currency (tokens) unique to this system, issued by the issuing server 3, to users. At the same time, the server 1 collects purchase information when users purchase products or services at specified affiliated stores, and provides a token back service in which tokens corresponding to the purchase amount are newly awarded as cash back as a reward for the user's shopping at the affiliated store. The specific content of this service will be described in detail later.

[0033] The terminal device 2 is an information processing terminal owned by a user, such as a smartphone, personal computer, or tablet terminal. For simplicity, the terminal device 2 will be referred to as the terminal 2 below. An application program provided by the server 1, for example, an application program that functions as a virtual currency wallet, is installed on the terminal 2. The user holds virtual currency through the wallet.

[0034] This embodiment may include not only a mode in which an application program that functions as a wallet is installed in the user's terminal 2 and virtual currency (tokens) is held on the local terminal, but also a mode in which virtual currency held by the user is managed in an online account provided on the web by the server 1, etc. In other words, the storage location of virtual currency is not limited to the local terminal, but may be a server device on the cloud.

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

[0036] 2 is a block diagram showing an example of the configuration of the server 1 and the terminal 2. The server 1 includes a control unit 11, a main memory unit 12, a communication unit 13, and an auxiliary memory unit . The control unit 11 has one or more arithmetic processing devices such as a central processing unit (CPU), a micro-processing unit (MPU), a graphics processing unit (GPU), etc., and performs various information processing, control processing, etc. related to the server 1 by reading and executing a program P1 stored in the auxiliary storage unit 14. The main storage unit 12 is a temporary storage area such as a static random access memory (SRAM), a dynamic random access memory (DRAM), or a flash memory, and temporarily stores data necessary for the control unit 11 to execute arithmetic processing. The communication unit 13 includes a processing circuit, etc. for performing processing related to communication, and transmits and receives information to and from the terminal 2, etc.

[0037] The auxiliary storage unit 14 is a large-capacity memory, a 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, an affiliated store DB 142, and a donation destination DB 143. The user DB 141 is a database that stores information about each user. The affiliated store DB 142 is a database that stores information about each affiliated store. The donation destination DB 143 is a database that stores information about donation destinations to which users can donate tokens. Token donations will be described in more detail below.

[0038] The auxiliary storage unit 14 may be an external storage device connected to the server 1. The server 1 may be a multi-computer consisting of multiple computers, or may be a virtual machine virtually constructed by software.

[0039] Furthermore, in this embodiment, the server 1 is not limited to the above configuration, and may include, for example, a reading unit that reads information stored in a portable storage medium.

[0040] The terminal 2 includes a control unit 21 , a main memory unit 22 , a communication unit 23 , a display unit 24 , an input unit 25 , an imaging unit 26 , and an auxiliary memory unit 27 . The control unit 21 has one or more arithmetic processing units such as a CPU or an MPU, and performs various information processing, control processing, etc. related to the terminal 2 by reading and executing a program P2 stored in the auxiliary storage unit 27. The main storage unit 22 is a temporary storage area such as a static random access memory (SRAM) or a dynamic random access memory (DRAM), and temporarily stores data necessary for the control unit 21 to execute arithmetic processing. The communication unit 23 includes an antenna, a processing circuit, etc. for communication, and transmits and receives information to and from the server 1, etc. The display unit 24 is a display device such as a liquid crystal display or an organic electroluminescence (EL) display, and displays images provided by the control unit 21. The input unit 25 is an operation component such as a touch panel or mechanical keys, and receives operation inputs from the user. The imaging unit 26 is an imaging mechanism such as a complementary metal oxide semiconductor (CMOS) camera, and captures images according to operation inputs by the user.

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

[0042] FIG. 3 is an explanatory diagram showing an example of the record layout of the user DB 141, the affiliated store DB 142, and the donation destination DB 143. 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 the user's name in association with the user ID. 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 purchasing goods or services at affiliated stores in association with the user ID. The purchase history includes a cashback history indicating the amount of cashback given to the user (amount returned in the form of tokens) according to the purchase amount, as shown in FIG. 3. The SNS column stores information about the SNS account owned by the user in association with the user ID.

[0043] The affiliated store DB142 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 the name of the member store in association with the member store ID. The collection rate column stores the collection rate of the commission to be collected from the member store according to the purchase amount when a user purchases a product or service at the member store in association with the member store ID. The product column stores information about the product (or service) provided by the member store in association with the member store ID. The SNS image column stores image data for posting on SNS related to each product in association with the member store ID and the product. The link column stores link addresses for transitioning to web pages related to the member store in association with the member store ID. The hyperlink is, for example, an address for transitioning to the homepage of the member store.

[0044] The donation destination DB143 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 the name of the donation destination (e.g., facility name, organization name, etc.) in association with the donation destination ID. The wallet address column stores the wallet address by which the donation destination receives token donations from users in association with the donation destination ID. The SNS image column stores image data for posting on SNS related to the donation destination in association with the donation destination ID column. The link column stores a link address to a web page (e.g., a homepage) related to the donation destination in association with the donation destination ID.

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

[0046] Fig. 4 is an explanatory diagram showing an overview of the first embodiment. Fig. 5 is an explanatory diagram for explaining the token back process and the donation process. Fig. 4 illustrates how, when a user purchases a product at an affiliated store, tokens equivalent to a cash back are given and a portion of the given tokens are donated to a predetermined donation destination. Fig. 5 conceptually illustrates the specific processing contents of the token back process and the donation process.

[0047] First, an overview of this embodiment will be described with reference to Fig. 4. As already mentioned, this system handles unique currencies (tokens) issued by issuing server 3. For example, issuing server 3 implements an ICO (Initial Coin Offering) and sells all or part of the tokens it has generated. For example, issuing server 3 sells the tokens to general users ("Token Holders" shown in Fig. 4) and also sells them to server 1, which functions as an operator (provider) of token sales.

[0048] When an ICO is implemented, issuing server 3 determines the upper limit of the total amount of tokens to be issued and supplies tokens equivalent to a portion of that total amount to the market. For example, if the total amount of tokens to be issued is 10,000, issuing server 3 will supply 1,000 tokens, which is 10% of the total amount to be issued, at the ICO stage. As will be described later, when issuing server 3 receives a request to purchase new tokens from server 1, issuing server 3 will issue new tokens within the limit of the total amount to be issued (10,000) and send (sell) them to server 1.

[0049] The server 1 accepts deposits from users and sells tokens. The server 1 acquires (purchases) tokens according to the deposit amount from the issuing server 3 and sends (transfers) them to the wallet address owned by the user. The sent tokens are stored in the wallet 271 in the terminal 2. As a result, the user becomes a holder of the tokens.

[0050] In this embodiment, the server 1 is described as transmitting (remitting) tokens to the terminal 2, but the server 1 may simply mediate communication between a token exchange, currency exchange, etc. (not shown) and the terminal 2, and the terminal 2 may acquire tokens from the exchange, etc., instead of the server 1. In other words, the server 1 only needs to be operable to grant tokens to users according to the amount of deposit, and does not have to accept deposits or sell (transmit) tokens itself.

[0051] Here, when a user who holds tokens makes a purchase at an affiliated store, the user can receive a transfer of tokens according to the purchase amount of the product, etc., i.e., a cashback (token back) in the form of tokens. An affiliated store is one or more stores that are affiliated with the token back service related to this system, and is a provider of products or services to users. Note that the provider of products, etc. does not need to be a physical store, and may be an e-commerce site that sells products over the Internet, as in the second embodiment described below.

[0052] The process of granting a token equivalent to a cashback to a user will now be described in detail. First, the user purchases a product or the like at a member store. The purchase of the product or the like may be made using the above-mentioned token, but it is preferable to use a payment method other than the token (for example, legal tender).

[0053] When purchasing a product or the like, the user operates terminal 2 to capture an image of a paper medium such as a receipt or invoice, and transmits the captured image to server 1 in order to prove to server 1 that they have shopped at an affiliated store. Note that the means for proving that they have shopped is not limited to capturing an image of a receipt or the like. For example, terminal 2 may read a specific QR code (registered trademark) printed on a receipt to obtain purchase information of the product or the like, and transfer the information to server 1.

[0054] When a 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, the purchase date and time, etc. The server 1 stores the extracted purchase information in the user DB 141 and accumulates the purchase history. In the above, the server 1 performs image recognition, but 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 related to an image of a receipt or the like, and the acquired information may be the image itself or the recognition result of purchase information recognized from the image.

[0055] The server 1 calculates the amount of tokens equivalent to a cashback to be given to the user from the purchase amount of the product, etc. extracted from the captured image. For example, the server 1 calculates the amount of tokens based on the holding information of the tokens held by the user in addition to the purchase amount of the product, etc.

[0056] The holding information is information indicating the status of token holding by the user, such as the holding period for which the tokens have been continuously held without being sold, and the amount of tokens held in the wallet 271. In this embodiment, the server 1 determines the amount of tokens to be transferred to the user according to the holding period and amount of tokens.

[0057] The token back process based on the holding information will be explained with reference to Figure 5. Figure 5 illustrates how two users who purchased the same product are transferred different quantities of tokens depending on their holding status. In the example shown in Figure 5, "User A" has held "2,000" tokens for "5 years." "User B" has held "1,000" tokens, which is less than User A, for "1 year."

[0058] First, the server 1 determines whether a user holds 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 a user does not hold one or more tokens, the server 1 does not consider the user eligible for token back even if it acquires the purchase information, and does not grant the user a token. On the other hand, if a user holds one or more tokens, the server 1 grants the token. In other words, the server 1 determines who is eligible for token back based on the minimum number of tokens held, and grants tokens to users who hold more than the minimum number of tokens. In the example shown in Figure 5, both users A and B hold one or more tokens (1,000 or more), so both are eligible for token back. On the other hand, the server 1 does not grant tokens to users who hold less than one token. By setting the minimum number of tokens required to receive token back, the token functions as a kind of membership right.

[0059] The determination point for determining the amount of tokens held may be, for example, the time when the user purchases a product or the like at an affiliated store, the time when purchase information (captured image) is transmitted to the server 1, or, as will be described later, the time when the server 1 receives a commission from the affiliated store. In this way, the time when it is determined whether or not a user is eligible for token back is not particularly limited.

[0060] If a user holds one or more tokens, the server 1 calculates the amount of tokens to be transferred to the user based on purchase information of the product, etc. In the example of FIG. 5, for example, the server 1 transfers "0.050" of tokens, which corresponds to 1% of the purchase amount, to user A who purchased a product worth 500,000 yen. Note that the percentage of the purchase amount to be cashed back (token back) is a design matter, and the cashback percentage may be determined for each affiliated store and each product, for example. Furthermore, for example, the server 1 may grant a fixed amount of tokens to the user regardless of the product, etc., purchased by the user.

[0061] On the other hand, Server 1 transfers "0.005" of tokens, which is equivalent to 0.1% of the purchase price, to User B, who purchased the same product as User A. Because User B's token holdings are half that of User A and the holding period is one-fifth, Server 1 transfers one-tenth of the amount of tokens to User B compared to User A. In this way, Server 1 multiplies the purchase price by a coefficient according to the holding period and holding amount, and calculates the amount of tokens to be transferred to each user.

[0062] The above calculation method is merely an example, and the method for calculating the amount of tokens to be granted to a user is not limited to this. For example, whether or not the user has sold tokens in the past may be included as one of the pieces of ownership information used as the basis for calculating the amount of tokens. Furthermore, the information used as the basis for calculating the amount of tokens is not limited to purchase information on products, etc., and token ownership information, but may also include other information such as whether or not the user has donated tokens, as described below, or whether or not the user has posted on social media.

[0063] As described above, the server 1 transfers more tokens to users who hold tokens for a longer period and hold a larger amount of tokens. This creates an incentive for users to hold on to their tokens rather than selling them, which can help increase the value of tokens, as described later.

[0064] Returning to Figure 4, we will continue with the explanation. The server 1 that has granted tokens to the user receives a fee from the affiliated store according to the purchase amount of goods, etc., that the user purchases at the affiliated store. This fee is a matching fee paid in the name of guiding the user who holds the tokens to the affiliated store. As described above, the server 1 encourages shopping at the affiliated store by granting the user tokens equivalent to a cashback. In return, the server 1 collects a fee from the affiliated store. For example, the server 1 notifies the affiliated store to pay a fee equal to the amount of tokens granted to the user converted into legal tender. The affiliated store transfers money to the server 1 via a remittance means (for example, a financial institution such as a bank) not shown.

[0065] When a user makes a purchase at a new affiliated store and transfers tokens to the user, the server 1 acquires (purchases) tokens using the fees paid by the affiliated store as funds and grants them 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 tokens to be purchased and the purchase price to the issuing server 3.

[0066] When a purchase request is received from the server 1, the issuing server 3 determines whether or not there are tokens stored (in stock). If it determines that there are tokens stored, the issuing server 3 sends the number of tokens requested by the server 1 from the stored tokens to the server 1. The server 1 sends (transfers) the fee collected from the affiliated store to the issuing server 3 as payment for acquiring the tokens.

[0067] If it is determined that no tokens are stored, the issuing server 3 issues new tokens within the upper limit of the total amount of tokens that can be issued, and sends them to the server 1. For example, if the total amount to be issued is 10,000 and the issuing server 3 has no tokens stored, the issuing server 3 increases the amount to be issued by 10% and issues (generates) 1,000 new tokens. The issuing server 3 sends (sells) the newly issued tokens to the server 1.

[0068] In the above description, the server 1 procures tokens from the issuing server 3, which is the entity that issues the tokens. However, the server 1 may also procur tokens from a token holder ("Token Holder" in FIG. 4), for example. In this case, the server 1 outputs information such as the desired purchase price and desired purchase quantity of the tokens, i.e., a purchase request, to a virtual currency exchange (not shown), searches for a holder whose selling price matches the token, and enters into a contract for the sale of the tokens. The server 1 executes a transaction to receive the tokens from the holder with whom the contract for sale has been concluded, and acquires the tokens to grant to the user. In other words, the server 1 only needs to be able to procure tokens using the fees collected from affiliated stores, and may acquire the tokens from the issuer or from another token holder.

[0069] The above process raises the price of tokens by procuring new tokens from the inventory of the issuing server 3 (or from token holders). Note that in the above process, new tokens are issued when the stock of issued tokens runs out in order to avoid excessive increases in the value of tokens, but new tokens are issued within the limit of the total amount issued, so overall this has the effect of raising the price of tokens.

[0070] This increases the value of the tokens held by the user. Therefore, users can not only earn tokens by shopping, but can also expect the value of their tokens to increase the more products they purchase. This stimulates users' desire to purchase, and member stores can expect to see an increase in sales. Server 1 functions as an operator that sustainably leads the above-mentioned purchase cycle, granting tokens and collecting fees from member stores.

[0071] Furthermore, in this embodiment, the server 1 performs a donation process in which a portion of the tokens given to the user as cashback is sent (transferred) to a predetermined donation destination. The right side of FIG. 5 conceptually illustrates the contents of the donation process. For example, the administrator of this system is affiliated with nature conservation organizations, animal protection organizations, child support facilities, educational institutions, etc., and donates tokens to each organization and facility as a donation destination. Note that these organizations and facilities are merely examples, and the donation destinations are not particularly limited. Each donation destination has a wallet address for receiving donated tokens, and the server 1 sends the tokens to that wallet address.

[0072] The server 1 extracts a portion of the tokens to be transferred to the user and transmits the portion to each recipient. The proportion of the tokens to be donated among the tokens equivalent to the cashback is not particularly limited. When donating tokens, the server 1 may accept a designation of the recipient from the user, but performs an allocation process that predicts the recipients to which the user will likely wish to donate and the allocation of tokens to be donated to each recipient, and then automatically donates the tokens.

[0073] For example, the server 1 determines the donation recipients and allocations based on the user's purchase history of products, etc. The method for determining the donation recipients and allocations from the purchase history is not particularly limited. For example, the server 1 may link the attributes of the purchased products (e.g., whether the products are for men or women) with the attributes of each donation recipient (e.g., whether the recipient is an environmental protection organization or an education-related organization) and determine the donation recipients and allocations based on rules. Alternatively, for example, the server 1 may manually input the settings for the donation recipients and allocations from each user, accumulate a certain number of samples, and then match users based on their purchase histories to determine the same donation recipients and allocations for users with similar purchase histories. Alternatively, for example, the server 1 may incorporate a machine learning algorithm, construct a learning model using purchase history as input values ​​and donation recipients and allocations as output values, and use the learning model to determine the donation recipients and allocations.

[0074] 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 Figure 5. For example, for user A, the server 1 assigns a higher weight to donations to environmental protection organizations and educational institutions. For user B, the server 1 assigns a higher weight to donations to educational institutions and animal protection organizations.

[0075] In the above, the recipients and allocation of tokens are determined based on the user's purchase history, but allocation may also be based on the user's attributes, such as gender, age, occupation, etc. In other words, the server 1 only needs to be able to automatically determine the recipients and allocation, and the criteria for this determination are not limited to the purchase history.

[0076] Fig. 6 is an explanatory diagram showing an example of a token back screen. Fig. 6 shows an example of a display screen on which a user can check the tokens they have received as cash back. The token back screen includes purchase information 61 of the product or other item that caused the token back, token back 62 indicating the amount of tokens given, allocation 63 indicating the donation recipient and allocation, as well as SNS images 64, 64, 64...

[0077] The SNS images 64 are posting materials prepared in advance by the server 1 for uploading to the SNS, such as images of products purchased by the user or images of recipients to which the user has donated tokens. As shown in Fig. 6, the token back screen displays an SNS image 64 for uploading purchased products to the SNS, and an SNS image 64 for uploading recipients. When notifying the user of token back or the like via the token back screen, the server 1 also searches various databases for SNS images 64 of the products or recipients, and outputs multiple candidates on the token back screen.

[0078] The terminal 2 accepts a selection input from the displayed SNS images 64, in which the user selects one of the SNS images 64 that the user wishes to upload. When a selection input for an SNS image 64 is accepted, the terminal 2 displays, for example, a pop-up screen (not shown) and accepts input of a comment or the like for uploading to the SNS. The terminal 2 notifies the server 1 of the selection of the SNS image 64 and the input content of the comment or the like, and requests that an article (posting information) to be posted to the SNS be generated and uploaded.

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

[0080] A post posted to the SNS includes, for example, the user's account name, comments, SNS image 64, etc., as well as a link 71. The link 71 is a hyperlink for transitioning to a web page related to the affiliated store or donation recipient, for example, a link to the homepage of the affiliated store or donation recipient. Based on the input content on the terminal 2, the server 1 generates a post including the link 71 and uploads it to the user's SNS account. This spreads information about the affiliated store or donation recipient on the SNS, encouraging other users to participate in services related to this system. It also increases the social satisfaction of users who purchase products and donate tokens, stimulating their desire to purchase and donate.

[0081] Fig. 8 is a flowchart showing an example of the processing procedure for the token granting process. The processing details of the token back process for granting tokens to a user will be described with reference to Fig. 8. For simplicity of explanation, the explanation will be given assuming that the user has already made a deposit into the server 1 and holds a certain amount of tokens. The control unit 21 of the terminal 2 acquires a captured image of a paper medium on 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, invoice, etc. The control unit 21 captures an image of the receipt, etc. in accordance with an operation by the user, and transmits the captured image to the server 1.

[0082] When a 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 related to products 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 purchase date and time from the captured image. The control unit 11 stores the extracted purchase information in the user DB 141.

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

[0084] The control unit 11 determines whether the user holds a predetermined number of tokens or more based on the acquired holding information (step S14). If it is determined that the user does not hold the predetermined number of tokens or more (S14: NO), the control unit 11 ends the series of processes.

[0085] If it is determined that the user holds a predetermined number of tokens or more (S14: YES), the control unit 11 calculates the amount of tokens equivalent to a cashback to be given to the user based on the purchase information acquired in step S12 and the holding information acquired in step S13 (step S15). For example, the control unit 11 calculates the amount of cashback based on the purchase price of a product or the like and the holding period and amount of tokens, and calculates the amount of tokens equivalent to the cashback amount. The control unit 11 stores the calculated cashback amount in the user DB 141.

[0086] The control unit 11 extracts a portion of the calculated tokens, and determines one or more recipients to which the portion of tokens will be donated and the allocation of the tokens to each recipient (step S16). For example, the control unit 11 determines the recipients and allocation based on the user's past purchase history. The control unit 11 transmits a portion of the tokens calculated in step S15 to the user's terminal 2 and a portion to each recipient determined in step S16 (step S17).

[0087] When tokens equivalent to a cashback are acquired from the server 1, the control unit 21 of the terminal 2 displays the number of tokens granted by the server 1 on the display unit 24 (step S18). For example, as shown in Fig. 6, the control unit 21 displays the number of tokens returned (granted) to the user, the recipients and allocations to which some of the tokens have been donated, and SNS images 64, 64, 64... which are candidates for images to be uploaded to SNS. The SNS images 64 are images related to products purchased by the user or images related to the recipients.

[0088] The control unit 21 accepts a selection input for selecting one of the SNS images 64 displayed in step S18 (step S19). The control unit 21 further accepts an input of a comment or the like to be posted along with the selected image (step S20). The control unit 21 requests the server 1 to generate and upload an article (posted information) to be posted to the SNS based on the image selected in step S19 and the comment or the like entered in step S20 (step S21). When an upload request is accepted from the terminal 2, the control unit 11 of the server 1 generates an article for uploading to the SNS using posting materials, such as the image selected in step S19 and the comment or the like entered in step S20, and uploads it to the SNS (step S22). The article includes, in addition to the image selected in step S19 and the comment or the like entered in step S20, a link 71 for transitioning to a web page related to the affiliated store or the donation destination. The control unit 11 then terminates the series of processes.

[0089] 9 is a flowchart illustrating an example of a procedure for a token acquisition process, which will be described with reference to FIG. 9, in which a token is acquired by collecting a fee from a member store. The control unit 11 of the server 1 starts the following process, for example, by batch processing. The control unit 11 acquires (collects) a fee equivalent to the cashback amount granted to the user from the affiliated store (step S31). For example, the control unit 11 refers to the cashback (token back) history stored in the user DB 141 and notifies the affiliated store to pay a fee according to the cashback amount. The control unit 11 receives the fee remittance via, for example, a financial institution or the like.

[0090] The control unit 11 makes a purchase request to purchase tokens equivalent to the cashback granted to the user from the token issuer (issuing server 3) (step S32). Then, the control unit 11 acquires tokens from the issuing server 3 using the fee acquired in step S31 (step S33). That is, the control unit 11 purchases tokens using the fee paid by the affiliated store as a source of funds. For example, when the issuing server 3 accepts the purchase request in step S32, it determines whether or not the requested number of tokens are stored (in stock). If it determines that the requested number of tokens are available, the issuing server 3 transmits the requested number of tokens from the stored tokens to the server 1. If it determines that the requested number of tokens are not available, the issuing server 3 issues new tokens within the upper limit of the total issuance amount, and transmits the newly issued tokens in the number of tokens requested by the server 1. The control unit 11 ends the series of processes.

[0091] In the above description, a portion of the tokens granted to users is donated to a predetermined recipient, but this embodiment is not limited to this. For example, the server 1 may distribute tokens to company employees for in-company welfare purposes, and may also give a portion of the tokens to be transferred to other employees as a reward to employees with high performance. Furthermore, for example, the server 1 may sell tokens that can be earned only in specific regions as a regional development measure, and transmit a portion of the tokens transferred to users to local governments as tax revenue for the local governments. In this way, the server 1 only needs to be able to transmit a portion of the tokens granted to users to a predetermined recipient, and the purpose of the transmission does not have to be for donation.

[0092] Furthermore, although the SNS image 64 has been given above as an example of material for posting to an SNS, the posting material is not limited to images (still images and videos) and may be, for example, text, audio data, or the like.

[0093] Also, for the sake of convenience in the above description, the server 1 grants tokens equivalent to the cashback to the user, collects (obtains) a fee from the affiliated store, and procures (obtains) tokens from the issuing server 3. However, it is also possible to grant tokens equivalent to the cashback to the user after the tokens have been procured. In this case, for example, the server 1 may display the expected token refund amount on the token refund screen immediately after the user has shopped, and send the tokens again after the tokens have been procured. In this way, the order of granting tokens to the user, obtaining a fee from the affiliated store, and obtaining tokens from the issuing server 3 is an arbitrary design matter, and the order of each process may be reversed.

[0094] In addition, although the server 1 has been described above as acquiring purchase information from the user's terminal 2, it may also acquire purchase information from an affiliated store. For example, the server 1 may acquire the user's purchase history from a POS (Point of Sales) system of an affiliated store.

[0095] 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 distributes to the affiliated store (provider of goods or services) an application program (second program) that transmits purchase information to the server 1. The application program (second program) is installed, for example, in a predetermined terminal device installed in the affiliated store, or in a POS server that manages the terminal device. The application program causes a computer, such as a terminal device or POS server installed in the affiliated store, to execute a process of accepting a purchase request for goods or the like from the user and transmitting the purchase information to the server 1. Furthermore, the application program obtains from the server 1 a notification indicating the amount of tokens to be granted to the user so that the user knows the amount of tokens to be cashed back, and executes a process of displaying (outputting) the notification (the amount of tokens equivalent to the cashback) on a display or the like installed in the affiliated store.

[0096] Furthermore, as described above, in order to grant tokens to users who hold a predetermined number or more of tokens, the application program may, for example, determine whether the number of tokens held by the user is a predetermined number or more when a purchase request is received, and only if the user holds the predetermined number or more of tokens, transmit purchase information to the server 1 and obtain a notification regarding the token back. In this case, the application program may, for example, inquire of the server 1 about the number of tokens held by the user, or may itself refer to the blockchain to search for the number of tokens held by the user.

[0097] As described above, according to the first embodiment, the server 1 grants tokens equivalent to cashback to users who hold tokens (virtual currency) in accordance with purchase information of products, etc. at affiliated stores. This makes it possible to support users in purchasing products, etc. by utilizing virtual currency, unlike simple virtual currency payment systems. Furthermore, since the tokens equivalent to cashback are covered by fees obtained from affiliated stores, it is possible to support a sustainable purchasing cycle.

[0098] Furthermore, according to the first embodiment, the server 1 uses the commission fee from the member store as a source of funds to procure tokens equivalent to the cashback from the issuer or from the market. This reduces the amount of tokens in circulation and promotes an increase in the value of the tokens.

[0099] Furthermore, according to the first embodiment, tokens equivalent to cashback are given only to users who hold a predetermined number of tokens or more. By setting a minimum holding amount required to receive token back, the tokens function as a kind of membership, making it possible to build a more sustainable purchasing cycle.

[0100] Furthermore, according to the first embodiment, the number of tokens to be granted is determined according to the status of token holdings by the user, such as the holding period and amount of tokens, etc. This creates an incentive for users to hold tokens rather than sell them, and it is possible to expect an increase in the value of tokens.

[0101] Furthermore, according to the first embodiment, the server 1 extracts a portion of the tokens to be given to the user and sends it to a predetermined destination (for example, a donation recipient, a company employee, a local government, etc.). This makes it possible to support, for example, donation (contribution) activities, corporate activities, regional development, etc., and virtual currency can be used not only to support purchasing but also as a sustainable social support measure.

[0102] Furthermore, according to the first embodiment, the recipient and allocation are automatically determined based on the user's purchase history, and tokens are sent. This allows users to make donations with an appropriate allocation without having to choose the recipient themselves, improving convenience.

[0103] Furthermore, according to the first embodiment, the server 1 presents materials for posting to the SNS to the user, generates a posted article (posted information) based on the user's selection, and automatically uploads it. This allows the user to inform other users of the products etc. purchased by the user or the recipients of the tokens, encouraging them to participate in the service, increasing the user's satisfaction, and promoting further purchasing and donation activities.

[0104] (Embodiment 2) In this embodiment, a form will be described in which a token is given when a product is purchased through an EC service such as an EC site. Note that the same reference numerals will be used to designate the same parts as in the first embodiment, and the description thereof will be 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 receives tokens according to the purchase amount. The 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 a product from a seller or an operating company of the EC site via the EC site and have the product delivered.

[0105] In this embodiment, the server 1 is affiliated with an EC site, acquires product purchase information from an EC server 4 that manages the EC site, and grants tokens to users who use the EC site. In this case, the server 1 receives a fee from the operating company of the EC site, purchases tokens using the fee, and grants them to users.

[0106] 11 is an explanatory diagram for explaining screen transitions on the terminal 2. The process of screen transitions from the EC site to the token back screen (see FIG. 6) will be described with reference to FIG. First, the terminal 2 accesses the EC server 4 and displays a browser screen related to the EC site. The screen displays product information about products offered on the EC site. The terminal 2 accepts operation input by the user, and accepts input specifying the product the user wishes to purchase. The terminal 2 requests the EC server 4 to purchase the specified product.

[0107] When the purchase request is accepted, the EC server 4 executes a predetermined payment process and confirms the purchase of the product. The EC server 4 transmits purchase information of the confirmed product to the server 1. The EC server 4 also displays a completion screen (not shown) on the terminal 2 indicating that the payment has been completed, and notifies the user that the shopping is complete.

[0108] Here, the EC server 4 displays a link to launch an application program (program P2) provided by the affiliated server 1 on the closing screen. For example, as shown in FIG. 11, the EC server 4 displays text with a hyperlink saying "Would you like to share?" on the closing screen. When the text is operated, the terminal 2 launches the application program. For example, the terminal 2 displays the token back screen exemplified in FIG. 6 and presents the user with multiple SNS images 64, 64, 64.... By selecting the SNS image 64, the user can automatically post to the SNS, as in the first embodiment.

[0109] As described above, this system can also be implemented in so-called online shopping via an e-commerce site. In particular, in this embodiment, after completing a purchase of a product on an e-commerce site, a link to an application program is displayed on the closing screen, and operation on the link triggers transition to a screen displaying an SNS image 64. This allows the user to smoothly post to the SNS after shopping on the e-commerce site.

[0110] 12 is a flowchart showing an example of the token granting process according to the embodiment 2. The processing content of the token granting process according to the embodiment 2 will be described with reference to FIG. 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 the output request for product information is accepted, the EC server 4 outputs the product information to the terminal 2 (step S202).

[0111] 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 accepts an operation input related to a product purchase request from the user and transmits it to the EC server 4 (step S204).

[0112] When the purchase request is received, the EC server 4 executes a payment process to purchase and settle the requested product (step S205). For example, the EC server 4 debits the user's bank account via a credit card company or the like based on the user's pre-registered credit card number or the like.

[0113] 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 the purchase information from the EC server 4 (step S12), and proceeds to step S13.

[0114] The EC server 4 notifies the terminal 2 that the payment process has been completed (step S207). Based on the notification from the EC server 4, the control unit 21 of the terminal 2 displays a closing screen indicating that the payment has been completed (step S208). The closing screen includes the purchased product, the purchase amount, and the like, as well as a link for launching an application program (P2) provided by the server 1 and transitioning to a screen displaying the SNS image 64. Based on the user's operation input, the control unit 21 determines whether to launch the application program and post to the SNS (step S209). If it is determined not to post (S209: NO), the control unit 21 ends the series of processes. If it is determined to post (S209: YES), the control unit 21 launches the application program and displays a token back screen including the SNS image 64 (step S210). The control unit 21 proceeds to step S17.

[0115] Although the above describes a form in which a product is purchased on an EC site (website), the present embodiment also includes a form in which a dedicated GUI application is installed on the terminal 2 and an EC service is received on the GUI screen of the application. In other words, the server 1 is only required to be able to grant tokens when a user purchases a product using an EC service, and the form of the EC service is not limited to a website.

[0116] As described above, according to the second embodiment, the present system can also be applied to cases where products are purchased via an EC site.

[0117] The embodiments disclosed herein are to be considered as illustrative in all respects and not restrictive. The scope of the present invention is defined by the claims, not by the above meaning, and is intended to include all modifications within the meaning and scope of the claims. [Explanation of symbols]

[0118] 1. Server (information processing device) 11 Control section 12 Main memory 13 Communications Department 14 Auxiliary storage P1 Program 141 User DB 142 Member store DB 143 Donation Database 2. Terminal (terminal device) 21 Control section 22 Main memory 23 Communications Department 24 Display 25 Input section 26 Imaging unit 27 Auxiliary storage P2 Program 271 Wallet

Claims

1. A method executed by an information processing device, Obtaining a fee for directing a user to a predetermined website; and a step of procuring tokens using the fee as a source of funds and then granting the tokens to the user, or a step of procuring tokens using the fee as a source of funds after granting tokens to the user from the procured tokens, An information processing method comprising:

2. Inducing a user to a predetermined website includes transitioning to the website via a hyperlink.

2. The information processing method according to claim 1,

3. granting a token to the user in accordance with the user's behavior information on the website; 2. The information processing method according to claim 1,

4. determining whether the user is entitled to be granted a token; 2. The information processing method according to claim 1,

5. A means for receiving a fee for directing a user to a predetermined website; A means for procuring tokens using the fees as a source of funds and then granting the tokens to the user, or a means for procuring tokens using the fees as a source of funds after granting tokens to the user from the procured tokens, 1. An information processing device comprising:

6. Inducing a user to a predetermined website includes transitioning to the website via a hyperlink.

6. The information processing apparatus according to claim 5,

7. granting a token to the user in accordance with the user's behavior information on the website; 6. The information processing apparatus according to claim 5,

8. means for determining whether a user is entitled to be granted a token; 6. The information processing apparatus according to claim 5,

9. A process of acquiring a fee for directing a user to a predetermined website; and causing the information processing device to execute a process of procuring tokens using the fee as a resource and then granting the tokens to the user, or a process of procuring tokens using the fee as a resource and then granting the tokens to the user from the procured tokens. An information processing program characterized by:

10. Inducing a user to a predetermined website includes transitioning to the website via a hyperlink.

10. The information processing program according to claim 9,

11. granting a token to the user in accordance with the user's behavior information on the website; 10. The information processing program according to claim 9,

12. causing an information processing device to execute a process of determining whether or not a user is qualified to be granted a token; 10. The information processing program according to claim 9,

Images