JP6868296B2 - Information processing device and information processing method - Google Patents

Description

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

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

Japanese Unexamined Patent Publication No. 2017-49967

However, the invention according to Patent Document 1 only delivers the product purchased in the virtual currency to the user, and does not give an incentive according to the purchased product or the like in the virtual currency.

One aspect is to provide an information processing device or the like that can assist a user in purchasing a product or the like by utilizing a virtual currency.

(1) The first aspect of the present invention is an information processing device capable of giving a virtual currency to a user, and a purchase information acquisition unit for acquiring purchase information about a product or service purchased by the user who holds the virtual currency. , The fee acquisition unit that acquires the fee according to the purchase information of the product or service, the currency acquisition unit that acquires the virtual currency using the fee acquired by the fee acquisition unit, and the fee acquisition unit acquired The virtual currency includes a granting unit that grants the user an amount of the virtual currency corresponding to the purchase information of the product or service.

(2) In the above (1), the holding information acquisition unit that acquires the 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. When it is determined that the user has a predetermined number or more of the virtual currency, the granting unit grants the acquired virtual currency to the user.

(3) In the above (1) or (2), the information processing device controls to display at least a part of the virtual currency amount and the purchase information given to the user on a predetermined terminal.

(4) In any one of (1) to (3) above, the information processing apparatus uses a part of the purchase price of the goods or services as a source of funds from the issuer of the virtual currency or the holder of the virtual currency. The process of purchasing the virtual currency and procuring the virtual currency to be granted by the granting unit is executed.

(5) In any one of (1) to (4) above, when the information processing apparatus determines that the virtual currency is insufficient when the virtual currency is given by the granting unit, the virtual currency is determined. A new virtual currency is issued within a range that does not exceed the upper limit of the total amount of issuance, and the virtual currency is granted by the granting unit.

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

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

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

(9) In any one of (1) to (8) above, the currency acquisition unit requests the issuer of the virtual currency or the holder of the virtual currency to purchase the virtual currency based on the fee. Is output, and the virtual currency is acquired from the issuer or holder.

(10) The second aspect of the present invention is an information processing method capable of imparting virtual currency to a user, in which purchase information regarding a product or service purchased by a user holding the virtual currency is acquired, and the product or service is described. Acquire a fee according to the purchase information of the above, acquire the virtual currency by using the acquired fee, and obtain the amount of the virtual currency according to the purchase information of the goods or services among the acquired virtual currencies. It is an information processing method, which is given to the user and is characterized in that a computer executes a process.

(11) A third aspect of the present invention is that the purchase information acquisition unit that acquires purchase information about the product or service purchased by the user holding the virtual currency and the provider of the product or service provide the product or service. A fee acquisition unit that acquires a fee according to the purchase amount, a currency acquisition unit that acquires the virtual currency in a quantity corresponding to the purchase information using the fee, and the acquired virtual currency are given to the user. Provided is an information processing apparatus including a granting unit.

(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 the issuer or the holder of the virtual currency. Acquire the virtual currency from the holder.

(13) In the above (11) or (12), the holding information acquisition unit that acquires the holding information indicating the holding status of the virtual currency of the user, and the virtual that the user has a predetermined number or more based on the holding information. It is provided with a determination unit for determining whether or not the currency is held, and when it is determined that the virtual currency is possessed in a predetermined number or more, the granting unit grants the virtual currency.

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

(15) In the above (11) to (14), among the virtual currencies given to the user, an extraction unit for extracting a part of the virtual currencies and the extracted virtual currencies are delivered to a predetermined destination. It is provided with a transmission unit for transmitting.

(16) In the above (15), the destination is a donation destination to donate the virtual currency, and the user can refer to the purchase information storage unit that stores the purchase information and the purchase information storage unit. Based on the purchase history, the transmission unit includes a plurality of the recipients for transmitting the virtual currency and a determination unit for determining the distribution of the virtual currency to be transmitted to each of the recipients, and the determination unit determines the transmission unit. The virtual currency is transmitted to each of the recipients according to the allocation.

(17) In the above (16), a material storage unit that stores posted materials 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 recipient determined by the decision unit, and a selection unit that accepts the selection of the posted material from the user. And a post output unit that generates the post information using the selected post material and outputs it on the network.

(18) A fourth aspect of the present invention is to acquire purchase information regarding a product or service purchased by a user holding a virtual currency, and respond to the purchase amount of the product or service from the provider of the product or service. Information characterized by acquiring a fee, using the fee, acquiring the virtual currency in a quantity corresponding to the purchase information, granting the acquired virtual currency to the user, and causing a computer to execute a process. Provides a processing method.

(19) A fifth aspect of the present invention is to acquire the virtual currency from a virtual currency provider according to the deposit amount deposited by the user, and to obtain purchase information regarding the goods or services purchased by the user from the provider. It affects a program characterized by causing a computer to execute a process of acquiring the virtual currency in a quantity corresponding to the purchase information from the provider.

(20) In the above (19), the captured image obtained by capturing the medium in which the purchase information is described is acquired, and the information regarding the captured image is output to the provider.

(21) In the above (19) or (20), the quantity of the virtual currency acquired according to the purchase information, the recipient who donated a part of the virtual currency, and the virtual donated to the recipient. Display the quantity of currency.

(22) In the above (21), candidates for posting materials related to the product, service, or donation destination for generating posting information to be posted on the network are obtained from the provider, and candidates for the posting material are obtained. Is displayed, the selection of the posted material is accepted, and the provider is requested to generate the posted information using the selected posted material and output it on the network.

(23) A sixth aspect of the present invention is to acquire the virtual currency from the provider of the virtual currency according to the deposit amount deposited by the user, and the quantity according to the purchase information regarding the goods or services purchased by the user. The first program for acquiring the virtual currency from the provider and causing the first computer to execute the process is transmitted to be installed on the first computer, a purchase request for a product or service is received from the user, and the purchase request is received. Is received, the purchase information is output to the provider, a notification indicating the quantity of the virtual currency given to the first computer according to the purchase information is acquired, 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 and causing the second computer to execute a process to be installed in the second computer. provide.
(24) In the above (23), when the second program receives the purchase request, it determines whether or not the user holds a predetermined number or more of the virtual currency, and the predetermined number or more of the above. 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 support the purchase of products and the like by users.

It is a schematic diagram which shows the configuration example of the virtual currency trading system. It is a block diagram which shows the configuration example of a server and a terminal. It is explanatory drawing which shows an example of the record layout of a user DB, a member store DB, and a donation destination DB. It is explanatory drawing which shows the outline of Embodiment 1. FIG. It is explanatory drawing for demonstrating token back processing and donation processing. It is explanatory drawing which shows an example of the token back screen. It is explanatory drawing which shows an example of the SNS screen. It is a flowchart which shows an example of the processing procedure of a token granting process. It is a flowchart which shows an example of the processing procedure of the token acquisition processing. It is explanatory drawing which shows the outline of Embodiment 2. It is explanatory drawing for demonstrating screen transition in a terminal. It is a flowchart which shows an example of the token granting process which concerns on Embodiment 2.

Hereinafter, the present invention will be described in detail with reference to the drawings showing the embodiments thereof.
(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 trading system that grants virtual currency to the user according to the actual purchase status of the user will be described. The virtual currency trading system includes an information processing device 1, a terminal device 2, and an issuing server 3. The devices are communicated and connected to each other via a network N such as the Internet.

The information processing device 1 is an information processing device capable of transmitting and receiving various types of information processing and information, and is, for example, a server device, a personal computer, or the like. In the present embodiment, the information processing device 1 is assumed to be a server device, and will be read as a server 1 in the following for the sake of brevity. The server 1 functions as an operator (sales office) that receives payment from the user and sells virtual currency, and transmits virtual currency according to the payment amount to the terminal device 2. In the present embodiment, the server 1 sells the virtual currency (token) unique to the system issued by the issuing server 3 to the user. At the same time, the server 1 collects purchase information when the user purchases a product or service at a predetermined member store, and as a privilege for the user to shop at the member store, a new token corresponding to the purchase amount is used as cash back. Provide a token back service to be given to. The specific contents of this service will be described in detail later.

The terminal device 2 is an information processing terminal owned by the user, such as a smartphone, a personal computer, a tablet terminal, or the like. In the following, for the sake of brevity, the terminal device 2 will be read as the terminal 2. An application program provided by the server 1, for example, an application program that functions as a wallet of virtual currency is installed in the terminal 2. The user holds virtual currency in 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 holds it 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 this 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 remittance from server 1, and transmits tokens according to the remittance amount to server 1. The server 1 distributes the token 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. The server 1 includes a control unit 11, a main storage unit 12, a communication unit 13, and an auxiliary storage unit 14.
The control unit 11 has one or more CPUs (Central Processing Units), MPUs (Micro-Processing Units), GPUs (Graphics Processing Units), and other arithmetic processing units, and stores the program P1 stored in the auxiliary storage unit 14. By reading and executing, various information processing, control processing, and the like related to the server 1 are performed. The main storage unit 12 is a temporary storage area for SRAM (Static Random Access Memory), DRAM (Dynamic Random Access Memory), flash memory, etc., and temporarily stores data necessary for the control unit 11 to execute arithmetic processing. Remember. The communication unit 13 includes a processing circuit or the like for performing processing related to communication, and transmits / receives information to / from the terminal 2 or the like.

The auxiliary storage unit 14 is a large-capacity memory, a hard disk, or the like, and stores the program P1 and other data necessary for the control unit 11 to execute the process. In addition, the auxiliary storage unit 14 stores the user DB 141, the member store DB 142, and the donation destination DB 143. The user DB 141 is a database that stores information of 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 about the donation destination to which the user can donate tokens. The details of donating tokens will be described later.

The auxiliary storage unit 14 may be an external storage device connected to the server 1. Further, the server 1 may be a multi-computer composed 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 above configuration, and may include, for example, a reading unit that reads information stored in the portable storage medium.

The terminal 2 includes a control unit 21, a main storage unit 22, a communication unit 23, a display unit 24, an input unit 25, an imaging unit 26, and an auxiliary storage unit 27.
The control unit 21 has one or more CPUs, MPUs, and other arithmetic processing devices, and by reading and executing the program P2 stored in the auxiliary storage unit 27, various information processing and control processing related to the terminal 2 are performed. And so on. The main storage unit 22 is a temporary storage area such as a SRAM (Static Random Access Memory) and a DRAM (Dynamic Random Access Memory), and temporarily stores data necessary for the control unit 21 to execute arithmetic processing. The communication unit 23 includes an antenna for communication, a processing circuit, and the like, and transmits / receives information to / 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 by the control unit 21. The input unit 25 is an operation component such as a touch panel or a mechanical key, and receives an operation input from a user. The imaging unit 26 is an imaging mechanism such as a CMOS (Complementary Metal Oxide Semiconductor) camera, and captures an image according to an operation input by the user.

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 necessary for the control unit 21 to execute the process. In addition, the auxiliary storage unit 27 stores a wallet 271 that stores token data held 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 the record layout of the user DB 141, the member 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 string 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 the product or service at the member store in association with the user ID. As shown in FIG. 3, the purchase history includes a cashback history showing the amount cashed back to the user (the amount returned by the token) according to the purchase amount. The SNS column stores information about the SNS account possessed by the user in association with the user ID.

The member store DB 142 includes a member store ID column, a name column, a collection ratio 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 ratio column stores the collection ratio of the fee collected from the member store according to the purchase amount when the user purchases the product or service at the member store in association with the member store ID. The product column stores information about 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 the member store ID and the product. The link string stores the link address for transitioning to the 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 homepage of a member store.

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

The registration and update of the SNS posting image, the link, 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 and organizations that are the donation destination.

FIG. 4 is an explanatory diagram showing an outline of the first embodiment. FIG. 5 is an explanatory diagram for explaining the token back processing and the donation processing. FIG. 4 illustrates a state in which a token equivalent to cash back is given when a user purchases a product at a member store, and a part of the token to be given is donated to a predetermined donation destination. FIG. 5 conceptually illustrates the specific processing contents of the token back processing and the donation processing.

First, an outline of the present embodiment will be described with reference to FIG. As already mentioned, this system handles the unique currency (token) 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 token to a general user (“Token Holder” shown in FIG. 4) and also sells the token to a server 1 that functions as a token selling operator (provider).

When implementing ICO, the issuing server 3 sets an upper limit on the total issuance amount of tokens, and then supplies tokens corresponding to a part of the total issuance amount to the market. For example, when the total amount of tokens issued is 10,000, the issuing server 3 supplies 1000 tokens, which is equivalent to 10% of the total amount of tokens issued at the ICO stage. When a new token purchase request is received from the server 1 as described later, the issuing server 3 issues a new token within the range satisfying the upper limit of the total issuance amount (10,000 tokens) and sends (sells) the token to the server 1. ..

The server 1 accepts the payment from the user and sells the token. The server 1 acquires (purchases) tokens according to the deposit amount from the issuing server 3 and sends (remittances) to the wallet address owned by the user. The transmitted token is stored in the wallet 271 in the terminal 2. As a result, the user becomes the holder who holds the token.

In the present embodiment, the server 1 transmits (remittances) tokens to the terminal 2, but the server 1 communicates between the token exchange, the exchange office, etc. (not shown) and the terminal 2. The terminal 2 may acquire the token from an exchange or the like instead of the server 1 only by mediating. That is, the server 1 may be operable so that the token is given to the user according to the deposit amount, and it is not necessary to accept the deposit and sell (send) the token by itself.

Here, the user holding the token can transfer the token according to the purchase amount of the product or the like, that is, receive cash back (token back) by the token when shopping at the member store. A member store is one or more stores that are members of the token back service related to this system, and is a provider that provides goods or services to users. The provider of the product or the like does not have to be an actual store, and may be an EC site or the like that sells the product on the Internet as in the second embodiment described later.

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

When a product or the like is purchased, the user operates the terminal 2 to image a paper medium such as a receipt or a receipt and sends the captured image to the server 1 in order to prove to the server 1 that the shopping has been performed at the member store. To do. The means for proving that shopping has been performed is not limited to imaging receipts and the like. For example, the terminal 2 may read a predetermined QR code (registered trademark) printed on the receipt to acquire purchase information of a product or the like and transfer it 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 purchase date and time. 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. That is, the server 1 may be able to acquire information related to the image obtained by capturing the receipt or the like, and the acquired information may be the image itself or the recognition result of the purchase information recognized from the image.

The server 1 calculates the amount of tokens equivalent to cashback given to the user from the purchase amount of the product or the like extracted from the captured image. For example, the server 1 calculates the token amount based on the token holding information held by the user in addition to the purchase amount of the product or the like.

The holding information is information indicating the holding status of the token by the user, for example, the holding period of holding the token continuously without selling it, the holding amount of the token held in the wallet 271 and the like. In the present embodiment, the server 1 determines the amount of tokens to be transferred to the user according to the token holding period and the holding amount.

Based on FIG. 5, the token back processing will be described based on the possessed information. FIG. 5 illustrates how different quantities of tokens are transferred to two users who have purchased the same product, depending on the token holding status. In the example shown in FIG. 5, "User A" holds a quantity of tokens of "2.000" for "5 years". Further, "User B" holds a quantity of tokens of "1.000", which is smaller than that of User A, for "1 year", which is shorter than that of User A.

First, the server 1 determines whether or not the user holds a predetermined number or more of tokens 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 target the user for token back even if the purchase information is acquired, and does not grant the token. On the other hand, when the user holds one or more tokens, the server 1 grants the tokens. That is, the server 1 determines a qualified person for token back based on the minimum holding amount of tokens, and grants tokens to users who have tokens having a minimum holding amount or more. In the example shown in FIG. 5, since both users A and B have one or more cards (1.000 or more), both of them are subject to token back. On the other hand, the server 1 does not grant tokens to users who have less than one token. By setting the minimum holding amount required to receive token back, the token functions as a kind of membership.

The determination time for determining the holding amount of the token may be, for example, the time of purchase when the user purchases a product or the like at a member store, or the time of transmission when the purchase information (captured image) is transmitted to the server 1. As will be described later, the server 1 may be at the time of acquisition when the fee is acquired from the member store. As described above, the time of determination for determining whether or not the user is a qualified person for token back is not particularly limited.

When the user holds 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 transfers the token in the quantity of "0.050" corresponding to 1% of the purchase amount to the user A who has purchased the product of 500,000 yen. It should be noted that how much of the purchase amount should be cashed back (tokenback) is an arbitrary design matter, and for example, the cashback ratio may be set for each member store or each 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 transfers a quantity of tokens of "0.005", which corresponds to 0.1% of the purchase amount, to the user B who has purchased the same product as the user A. Since the amount of tokens held by user B is half that of user A and the holding period is one-fifth, the server 1 sets the amount of tokens transferred to user B to one-tenth that of user A. In this way, the server 1 multiplies the purchase amount by a coefficient according to the holding period and the holding amount to calculate the token amount to be transferred to each user.

The above calculation method is an example, and the calculation method of the token amount given to the user is not limited to this. For example, as one of the holding information that is the basis for calculating the token amount, the presence or absence of past token sales by the user may be added. Further, the information on which the token amount is calculated is not limited to the purchase information of products and the like and the token holding information, and is other information such as whether or not the token is donated and whether or not the token is posted on the SNS, which will be described later. May be good.

As described above, the server 1 transfers more tokens to the user who holds the token for a long time and holds a large amount of tokens. This gives the user an incentive to hold the token without selling it, which can help increase the value of the token, which will be described later.

The explanation will be continued by returning to FIG. The server 1 that gives the token to the user acquires a commission from the member store according to the purchase amount of the product or the like purchased by the user at the member store. The fee is a matching fee paid in the name of guiding the user holding the token to the member store. As described above, the server 1 encourages the user to shop at the member store by giving the user a token equivalent to cash back. The server 1 collects a fee from the member store in return. For example, the server 1 notifies the member store to pay the amount when the amount of tokens given to the user is converted into legal tender as a commission. The member store remits money to the server 1 via a remittance means (for example, a financial institution such as a bank) (not shown).

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 grants 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 token purchase quantity and the purchase price to the issuing server 3.

When the purchase request is received from the server 1, the issuing server 3 determines whether or not the token is stored (inventory). When it is determined that the tokens are stored, the issuing server 3 transmits the tokens in the quantity requested by the server 1 to the server 1 from the stored tokens. The server 1 transmits (remittances) the fee collected from the member store to the issuing server 3 as a consideration for acquiring the token.

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

In the above, the server 1 is supposed to procure the token from the issuing server 3 which is the issuing entity of the token. However, even if the token is procured from the holder who holds the token (“Token Holder” in FIG. 4), for example. Good. In this case, for example, the server 1 outputs information such as the desired purchase price and desired purchase quantity of tokens, that is, a purchase request to an exchange or the like of a virtual currency (not shown), and searches for a holder whose token sale price or the like matches. Then, the buying and selling of tokens is executed. The server 1 executes a transaction for receiving the token transmission from the holder who has executed the sale, and acquires the token to be given to the user. That is, the server 1 may obtain the token from the issuer or from another token holder as long as the token can be procured based on the fee collected from the member store.

By the above processing, a new token is procured from the inventory of the issuing server 3 (or from the token holder), so that the action of raising the price of the token works. In the above, in order to avoid excessive token value increase, new tokens are issued when the issued tokens are no longer saved, but since new tokens are issued within the limit of the total issuance amount, overall Looking at it, the token price increase effect works.

This increases the value of the tokens held by the user. Therefore, the user can not only obtain tokens by shopping, but can expect the value of the tokens he / she owns to increase as he / she purchases a product or the like. This stimulates the purchasing motivation of users, and member stores can expect an increase in sales. The server 1 functions as an operator that sustainably leads the above-mentioned purchase cycle, grants tokens, and collects fees from member stores.

Further, in the present embodiment, the server 1 performs a donation process of transmitting (remittance) a 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 is affiliated with nature conservation groups, animal protection groups, child support facilities, educational institutions, etc., and donates tokens to each group and facility as a donation destination. These groups and facilities are examples, and the donation destination is not particularly limited. Each donation destination has a wallet address for receiving the donation of the token, and the server 1 transmits the token to the wallet address.

The server 1 extracts a part of the tokens to be transferred to the user and transmits the part of the tokens to each donation destination. The proportion of tokens donated out of the tokens equivalent to cash back is not particularly limited. When donating tokens, the server 1 may accept the designation of the donation destination from the user, but the allocation process that predicts the donation destination that the user will want to donate and the distribution of the tokens to be donated to each donation destination. And donate automatically.

For example, the server 1 determines the donation destination and the distribution based on the purchase history of the product or the like by the user. The method of determining the donation destination and distribution from the purchase history is not particularly limited, but for example, the server 1 has the attributes of the purchased product (for example, whether it is a product for men or a product for women) and the attributes of each donation destination (for example,). Whether it is an environmental protection organization, an education-related organization, etc.) may be linked, and the donation destination and distribution may be decided on a rule basis. Further, for example, the server 1 manually accepts the donation destination and distribution setting input from each user, accumulates a certain amount of samples, matches the users based on the purchase history, and makes the same donation as the user having a similar purchase history. You may decide to go ahead and allocate. Further, for example, the server 1 introduces a machine learning algorithm, constructs a learning model in which the purchase history is used as an input value and the donation destination and distribution as an output value, and determines the donation destination and distribution using the learning model. You may.

By 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 of donations to environmental protection groups and educational institutions. Further, in the case of user B, the server 1 sets a large weight of donations to educational institutions and animal protection groups.

In the above, the token donation destination and distribution are determined based on the user's purchase history, but for example, allocation may be performed based on attributes such as the user's gender, age, and occupation. That is, the server 1 only needs to be able to automatically determine the donation destination and the distribution, and the determination criterion is not limited to the purchase history.

FIG. 6 is an explanatory diagram showing an example of a token back screen. FIG. 6 illustrates an example of a display screen on which the user can confirm the token received as cash back. The token back screen displays purchase information 61 for products that caused the token back, token back 62 indicating the amount of tokens granted, allocation 63 indicating the donation destination and distribution, and SNS images 64, 64, 64, and so on. Including.

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 or the like purchased by the user, or an image of a recipient to whom the user has donated a token. As shown in FIG. 6, on the token back screen, an SNS image 64 for uploading the purchased product to the SNS and an SNS image 64 for uploading the donation destination are displayed. When notifying the user of token back or the like via the token back screen, the server 1 also searches the SNS image 64 of the product or the donation destination from various databases and outputs a plurality of candidates to the token back screen.

The terminal 2 accepts a selection input for selecting one of the SNS images 64 that the user wants to upload from the displayed SNS image 64. When the 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 uploading the SNS. 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 to upload it.

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 on the SNS. FIG. 7A shows a screen example when the purchased product is selected in the SNS image 64, and FIG. 7B shows a screen example when the donation destination is selected.

The posted article posted on the SNS includes, for example, a user's account name, a comment, an SNS image 64, and the like, as well as a link 71. The link 71 is a hyperlink for transitioning to a Web page related to the member store or the donation destination, and is, for example, a link to the homepage 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, information on the member store or the donation destination can be spread on the SNS, and the participation of other users in the service related to this system can be promoted. In addition, it is possible to enhance the social satisfaction of the user who purchased the product or the like and donated the token, and stimulate the user's willingness to purchase and donate.

FIG. 8 is a flowchart showing an example of the processing procedure of the token granting process. Based on FIG. 8, the processing content of the token back processing for granting a token to the user will be described. For the sake of brevity, it is assumed that the user has already made a deposit to the server 1 and holds a certain token.
The control unit 21 of the terminal 2 acquires an captured image of a paper medium in which purchase information is described and transmits it to the server 1 (step S11). The paper medium is, for example, a receipt, a receipt, or the like. The control unit 21 captures a receipt or the like according to an operation by the user, and transmits the captured 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 or the like 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.

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

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

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

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

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

The control unit 21 receives a selection input for selecting one of the images from the SNS image 64 displayed in step S18 (step S19). Further, the control unit 21 accepts 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 (posted information) to be posted on the SNS based on the image selected in step S19 and the comment input in step S20 (step S21). When the 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 material of the image selected in step S19 and the comment etc. input in step S20, and SNS. Upload to the top (step S22). The article includes an image selected in step S19, a comment input in step S20, and a link 71 for transitioning to a Web page related to a member store or a donation destination. The control unit 11 ends a series of processes.

FIG. 9 is a flowchart showing an example of the processing procedure of the token acquisition process. Based on FIG. 9, a token acquisition process for collecting a fee from a member store and acquiring a token will be described.
The control unit 11 of the server 1 starts the following processing by, for example, batch processing. The control unit 11 acquires (collects) a fee for 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 according 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 corresponding 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 tokens using the commission paid by the member store as a source of funds. For example, when the issuing server 3 receives the purchase request in step S32, it determines whether or not the requested tokens are stored (inventory). When it is determined 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 requested tokens, the issuing server 3 issues new tokens within a range not exceeding the upper limit of the total issuance amount, and transmits the tokens in the quantity requested by the server 1 from the newly issued tokens. The control unit 11 ends a series of processes.

In the above, a 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 corporate workers for the purpose of welfare within the company, and may also give a part of tokens to be transferred to other workers as a reward for workers with high performance. Further, for example, the server 1 may sell tokens for which token back can be obtained only in a specific area as a regional promotion measure, and send a part of the tokens transferred to the user to the local government as tax revenue of the local government. Good. As described above, the server 1 may be able to transmit a part of the tokens given to the user to a predetermined destination, and the transmission purpose does not have to be the donation purpose.

Further, in the above, the SNS image 64 is given as an example as the material for posting the SNS, but the posted material is not limited to the image (still image and moving image), and may be, for example, text, voice data, or the like.

Further, for convenience of explanation above, the server 1 collects (acquires) a fee from the member store and procures (acquires) the token from the issuing server 3 after giving the user a token equivalent to cashback. , After the token procurement is completed, a token equivalent to cashback may be given to the user. In this case, for example, the server 1 may display the planned token back amount on the token back screen immediately after shopping by the user, and transmit the token again after the token procurement is completed. As described above, the order of granting the token to the user, acquiring the fee from the member store, and acquiring the token from the issuing server 3 is an arbitrary design matter, and each process may be mixed up.

Further, although the server 1 is assumed to acquire the purchase information from the user's terminal 2 in the above, the purchase information may be acquired from the member store. For example, the server 1 may acquire the purchase history of the user from the POS (Point of Sales) system of the member store.

In this case, for example, the server 1 distributes an application program (first program, program P2) that functions as a wallet for receiving tokens to the user, and also transmits purchase information to the server 1 (second program). Program) is delivered 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, a POS server that manages the terminal device, or the like. The application program receives a purchase request for a product or the like from a user and causes a computer such as a terminal device installed in a member store or a POS server to execute a process of transmitting purchase information to the server 1. Further, the application program acquires a notification indicating the amount of tokens to be given to the user from the server 1 so that the user can know the amount of tokens to be cashed back, and installs the notification (the amount of tokens equivalent to cashback) at the member store. Execute the process of displaying (outputting) on a display or the like.

Further, as described above, in order to grant tokens to users who hold a predetermined number or more, for example, in the above application program, when a purchase request is received, is the user's token holding amount equal to or more than a predetermined number? It may be determined whether or not, and only when the user holds a predetermined number or more of tokens, the purchase information may be transmitted to the server 1 to obtain the notification relating to the token back. In this case, the above-mentioned application program may inquire the server 1 for the token holding amount of the user, or may search the user's token holding amount by referring to the blockchain by itself.

Based on the above, according to the first embodiment, the server 1 grants a token (virtual currency) to a user holding a token (virtual currency) a token equivalent to cash back according to purchase information of a product or the like at a member store. As a result, unlike a simple payment system using virtual currency, it is possible to support the purchase of products and the like by the user by utilizing the virtual currency. In addition, cashback-equivalent tokens are covered based on commissions obtained from merchants, which can support a sustainable purchase cycle.

Further, according to the first embodiment, the server 1 procures a token equivalent to cashback from the issuer or the market by using the fee from the member store as a source of funds. As a result, the circulation volume of tokens can be reduced and the value of tokens can be increased.

Further, according to the first embodiment, a token equivalent to cashback is given only to a user who holds a predetermined number or more of tokens. 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 amount of tokens to be granted is determined according to the token holding status by the user, such as the token holding period and the holding amount. This gives the user an incentive to hold the token without selling it, and it can be expected that the value of the token will increase.

Further, according to the first embodiment, the server 1 extracts a part of the token to be given to the user and transmits it to a predetermined destination (for example, a donation destination, a worker in a company, a local government, etc.). As a result, for example, donation activities, corporate activities, regional development, etc. can be supported, and 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 donation destination and the distribution are automatically determined based on the purchase history of the user, and the token is transmitted. As a result, the user can make a donation at an appropriate allocation without choosing the donation destination by himself / herself, and the convenience can be enhanced.

Further, according to the first embodiment, the server 1 presents the material 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 recipients of tokens, and to encourage them to participate in this service. At the same time, the user's satisfaction is enhanced, and further purchasing activities and donation activities are carried out. Can be promoted.

(Embodiment 2)
In this embodiment, a mode in which a token is given when a product is purchased through an EC service such as an EC site will be described. The contents overlapping with the first embodiment are designated by the same reference numerals and the description thereof will be omitted.
FIG. 10 is an explanatory diagram showing an outline of the second embodiment. FIG. 10 conceptually illustrates how a user purchases a product using an EC site and obtains tokens according to the purchase amount. An EC site is, for example, a virtual store on the Internet and 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 receive the delivery of the product.

In the present embodiment, the server 1 is affiliated with the EC site, acquires product purchase information from the EC server 4 that manages the EC site, and grants tokens to users who use the EC site. In this case, the server 1 acquires a fee from the operating company of the EC site, purchases tokens using the fee as a source of funds, and grants the fee to the user.

FIG. 11 is an explanatory diagram for explaining the screen transition in the terminal 2. Based on FIG. 11, the screen transition process of transitioning 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 about products listed on the EC site. The terminal 2 accepts the operation input by the user and accepts the designated input of the product that the user wants to purchase. The terminal 2 requests the EC server 4 to purchase the designated product.

When the purchase request is received, the EC server 4 executes a predetermined payment process and confirms the purchase of the product. The EC server 4 transmits the purchase information of the product whose purchase is confirmed to the server 1. Further, the EC server 4 displays an end screen (not shown) indicating that the payment has been completed on the terminal 2 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 a text with a hyperlink "Do you want to share?" On the end screen. When the text is manipulated, the terminal 2 starts 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 realized in so-called online shopping via an EC site. In particular, in the present embodiment, after the purchase of the product on the EC site is completed, the link to the application program is displayed on the end screen, and the operation to the link is triggered to transition to the display screen of the SNS image 64. As a result, the user can smoothly post to the SNS from shopping on the EC site.

FIG. 12 is a flowchart showing an example of the token granting process according to the second embodiment. The processing content of the token granting process according to the second embodiment 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 the product information (step S201). When the product information output request is received, 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 related to a product purchase request from the user and transmits it to the EC server 4 (step S204).

When the purchase request is received, the EC server 4 executes a payment process for making a purchase settlement of the requested product (step S205). For example, the EC server 4 debits 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 payment process has been completed (step S207). The control unit 21 of the terminal 2 displays an end screen indicating that the payment has been completed based on the notification from the EC server 4 (step S208). The end screen includes a link for starting 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, the purchase price, and the like. The control unit 21 starts the application program and determines whether or not to post to the SNS based on the operation input by the user (step S209). When it is determined that the posting is not performed (S209: NO), the control unit 21 ends a series of processes. When it is determined to post (S209: YES), the control unit 21 starts 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 the product on the EC site (Web site) has been described above, the form of installing the dedicated GUI application on the terminal 2 and receiving the EC service on the GUI screen of the application is also the embodiment of the present embodiment. Included in the category. That is, the server 1 only needs to be able to grant tokens when the user purchases a product using the EC service, and the form of the EC service is not limited to the website.

From the above, according to the second embodiment, the present system can be applied to the case where the product is purchased through the EC site.

The embodiments disclosed this time should be considered to be exemplary in all respects and not restrictive. The scope of the present invention is indicated by the scope of claims, not the above-mentioned meaning, and is intended to include all modifications within the meaning and scope equivalent to the scope of 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 Donation 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 (11)

An information processing system that has an information processing device that grants virtual currency to users.
The information processing device
An information acquisition department that acquires information about products or services provided by store owners to users who hold virtual currency from an operator who bundles multiple store owners who provide products or services.
A commission acquisition unit that acquires a commission from the operator according to the information about the product or service provided by the store owner to the user.
The amount of virtual currency to be acquired is calculated based on at least one of the holding amount and holding period of the virtual currency of the user, and the calculated virtual currency is acquired by using the fee acquired by the fee acquisition unit. Currency acquisition department and
An granting unit that grants the virtual currency acquired by the currency acquisition unit to the user ,
A storage unit that stores the user 's information, the store owner 's information, the history of products or services provided to the user, and the history of the given virtual currency .
The information processing device
The virtual currency is granted to the user on condition that the user is a qualified person for token back of the virtual currency.
A virtual currency which is the granted to the user, at least some information about the product or service to view the available confirmation screen to a predetermined terminal,
An information processing system characterized by this. An information processing system that has an information processing device that grants virtual currency to users.
The information processing device
An information acquisition unit that acquires information about products or services provided by a member store by a user who holds virtual currency from the user or the member store.
A fee acquisition unit that acquires a fee from the member store according to the information about the product or service provided by the user from the member store.
The amount of virtual currency to be acquired is calculated based on at least one of the holding amount and holding period of the virtual currency of the user, and the calculated virtual currency is acquired by using the fee acquired by the fee acquisition unit. Currency acquisition department and
An granting unit that grants the virtual currency acquired by the currency acquisition unit to the user ,
A storage unit that stores the user 's information, the member store's information, the history of products or services provided by the user, and the history of the given virtual currency .
The information processing device
The virtual currency is granted to the user on condition that the user is a qualified person for token back of the virtual currency.
A virtual currency which is the granted to the user, at least some information about the product or service to view the available confirmation screen to a predetermined terminal,
An information processing system characterized by this. The holding information acquisition unit that acquires the holding information of the virtual currency of the user, and
It has a determination unit for determining whether or not the user holds a predetermined number or more of the virtual currency based on the holding information.
The information processing system according to claim 1 or 2 , wherein when the granting unit determines that the user holds a predetermined number or more of the virtual currency, the granting unit grants the acquired virtual currency to the user. The currency acquisition department
The virtual currency publisher, or to holders of the virtual currency, and outputs a purchase request of the virtual currency based on the fee to acquire the virtual currency from the publisher or owner, according to claim 1 or 2 Information processing system described in. The information processing system includes an issuing device that issues virtual currency.
The issuing device is
The issuing department that issues the virtual currency within the predetermined upper limit of the total amount of issuance,
It is provided with a supply unit that supplies the issued virtual currency to the equipment of an exchange capable of buying and selling the virtual currency.
The information processing device
It is provided with an output unit that outputs a purchase request for the virtual currency in a quantity corresponding to the fee to the issuing device or the exchange.
The currency acquisition unit acquires the virtual currency from the issuing device or exchange, the information processing system according to claim 1 or 2. When the issuing unit grants the virtual currency by the granting unit, if it is determined that the virtual currency is insufficient, the issuing unit issues a new virtual currency within a range not exceeding the upper limit of the total issuance amount of the virtual currency. The information processing system according to claim 5 , wherein the virtual currency is given by the granting unit. The information processing device is connected to a server operated by the operator via a network.
The information processing system according to claim 1 , wherein the server operated by the operator displays a link for starting an application program provided by the information processing device on the terminal. The information processing system according to claim 2, wherein the information processing device is connected to the member store or the terminal of the user via a network. The information processing system according to claim 3 , wherein when the virtual currency is distributed and managed in a plurality of nodes, the transaction data is referred to to acquire the holding information of the virtual currency held by the user. Information processing method
The information about the product or service merchants provide to the user carrying the virtual currency, and information obtaining step you get from publishers bundling a plurality of merchants that provide goods or services,
A fee acquisition step of acquiring a fee from the operator according to the information about the product or service provided by the store owner to the user, and
The amount of virtual currency to be acquired is calculated based on at least one of the holding amount and holding period of the virtual currency of the user, and the calculated virtual currency is acquired by using the fee acquired in the fee acquisition step. Currency acquisition steps and
A granting step of granting the user an amount of the virtual currency according to the information about the goods or services provided to the user, and
A storage step for storing the information of the user, the information of the store owner , the history of the product or service provided to the user, and the history of the given virtual currency.
Wherein a virtual currency the user is the applied, and a display step of displaying at least a portion that is capable confirmation screen of the product or service information to the predetermined terminal, and
The allocating step may be to condition the user is qualified tokens back of the virtual currency, to impart the virtual currency to the user,
An information processing method characterized by the fact that. Information processing method
The user carrying the virtual currency information about products or services obtained from merchants, and information obtaining step you obtained from the user or the merchant,
A fee acquisition step in which the user acquires a fee according to information about the product or service provided by the member store from the member store.
The amount of virtual currency to be acquired is calculated based on at least one of the holding amount and holding period of the virtual currency of the user, and the calculated virtual currency is acquired by using the fee acquired in the fee acquisition step. Currency acquisition steps and
A granting step of granting the user an amount of the virtual currency according to the information about the goods or services provided by the user, and
A storage step for storing the user 's information, the member store's information, the history of goods or services provided by the user, and the history of the given virtual currency.
Wherein a virtual currency the user is the applied, and a display step of displaying at least a portion that is capable confirmation screen of the product or service information to the predetermined terminal, and
The allocating step may be to condition the user is qualified tokens back of the virtual currency, to impart the virtual currency to the user,
An information processing method characterized by the fact that.

Images