JP2019200823A - Information processing system, information processing method and information processing device - Google Patents

Abstract

To provide an information processing system and the like capable of constructing a sustainable purchase cycle in which a user purchases a product or the like by utilizing virtual currency.SOLUTION: An information processing system includes an issue section in which an issuing device issues virtual currency within a predetermined upper limit of a total issued amount, and a supply section which supplies the issued virtual currency to a device in an exchange that enables the virtual currency to be bought and sold. An information processing device includes: a purchase information acquisition section for acquiring purchase information related to a product or service purchased by a user; a commission acquisition section for acquiring a commission according to a purchase amount of the product or service from a provider of the product or service; output section for outputting a purchase request of the virtual currency in the amount according to the commission for the issuing device or the exchange; a currency acquisition section for acquiring the virtual currency from the issuing device or the exchange; and addition section for adding the acquired virtual currency to the user.SELECTED DRAWING: Figure 1

Description

  The present invention relates to an information processing system, an information processing method, and an information processing apparatus.

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

JP 2017-49967 A

  However, the invention according to Patent Document 1 only delivers products purchased in virtual currency to the user, and has not provided incentives according to the purchased products in virtual currency.

  In one aspect, an object is to provide an information processing system or the like that can support purchase of a product or the like by a user using virtual currency.

  An information processing system according to one aspect is an information processing system including an issuing device that issues a virtual currency and an information processing device that grants the virtual currency to a user, and the issuing device is a predetermined issue An issuing unit that issues the virtual currency within the upper limit of the total amount, and a supply unit that supplies the issued virtual currency to a device of an exchange capable of buying and selling the virtual currency, A purchase information acquisition unit that acquires purchase information related to the product or service purchased by the user; 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; An output unit that outputs a purchase request for the virtual currency in a quantity corresponding to the fee to an issuing device or an exchange; and a currency collector that acquires the virtual currency from the issuing device or the exchange. Characterized in that it comprises a part, and a deposition unit for the acquired the virtual currency given to the user.

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

It is a schematic diagram which shows the structural example of a virtual currency transaction system. It is a block diagram which shows the structural example of a server and a terminal. It is explanatory drawing which shows an example of the record layout of user DB, member store DB, and donation destination DB. FIG. 3 is an explanatory diagram showing an outline of the first embodiment. It is explanatory drawing for demonstrating a token back process and a donation process. It is explanatory drawing which shows an example of a token back screen. It is explanatory drawing which shows an example of a SNS screen. It is a flowchart which shows an example of the process sequence of a token provision process. It is a flowchart which shows an example of the process sequence of a token acquisition process. FIG. 6 is an explanatory diagram showing an outline of a second embodiment. It is explanatory drawing for demonstrating the screen transition in a terminal. 10 is a flowchart illustrating an example of a token grant process according to the second embodiment.

Hereinafter, the present invention will be described in detail with reference to the drawings illustrating embodiments thereof.
(Embodiment 1)
FIG. 1 is a schematic diagram illustrating a configuration example of a virtual currency trading system. In the present embodiment, a virtual currency transaction system that gives virtual currency to a user according to the actual purchase situation of the user will be described. The virtual currency transaction system includes an information processing device 1, a terminal device 2, and an issue server 3. The devices are connected to each other via a network N such as the Internet.

  The information processing apparatus 1 is an information processing apparatus capable of various information processing and information transmission / reception, and is, for example, a server apparatus or a personal computer. In the present embodiment, the information processing apparatus 1 is assumed to be a server apparatus, and will be read as the server 1 below for the sake of brevity. The server 1 functions as an operator (sales office) that accepts payment from the user and sells virtual currency, and transmits virtual currency corresponding to the deposit amount to the terminal device 2. In this embodiment, the server 1 sells the system's unique virtual currency (token) issued by the issuing server 3 to the user. At the same time, the server 1 collects purchase information when a user purchases a product or service at a predetermined member store, and newly uses a token corresponding to the purchase amount as a cashback as a privilege for the user to shop at the member store. Provide tokenback service to be granted to. The specific contents of this service will be described later in detail.

  The terminal device 2 is an information processing terminal owned by the user, and is, for example, a smartphone, a personal computer, a tablet terminal, or the like. Hereinafter, for simplicity, the terminal device 2 is replaced with the terminal 2. In the terminal 2, an application program provided by the server 1, for example, an application program that functions as a virtual currency wallet is installed. The user holds virtual currency with the wallet.

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

  The issue server 3 is a server device that functions as an issuer that issues tokens. The issue server 3 receives remittance from the server 1 and transmits a token according to the remittance amount to the server 1. The server 1 distributes the token purchased from the issuing server 3 to the user.

FIG. 2 is a block diagram illustrating 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 includes an arithmetic processing device such as one or a plurality of CPUs (Central Processing Units), MPUs (Micro-Processing Units), GPUs (Graphics Processing Units), and the program P1 stored in the auxiliary storage unit 14 is stored. Various information processing, control processing, and the like related to the server 1 are performed by reading and executing. 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. Remember. The communication unit 13 includes a processing circuit for performing processing related to communication, and transmits and receives information to and from the terminal 2 and the like.

  The auxiliary storage unit 14 is a large-capacity memory, 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 stores a user DB 141, a member store DB 142, and a donation destination DB 143. The user DB 141 is a database that stores information on each user. The member store DB 142 is a database that stores information on each member store. The donation destination DB 143 is a database that stores information on a donation destination to which a user can donate a token. 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 constructed virtually 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 a 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 includes one or a plurality of arithmetic processing devices such as a CPU and an MPU, and reads and executes the program P2 stored in the auxiliary storage unit 27, thereby performing various information processing and control processing related to the terminal 2. Etc. The main storage unit 22 is a temporary storage area such as an SRAM (Static Random Access Memory) or 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 performing communication, a processing circuit, and the like, and transmits and receives information to and from the server 1 and the like. The display unit 24 is a display device such as a liquid crystal display or an organic EL (Electro Luminescence) display, and displays an image given from the control unit 21. The input unit 25 is an operation component such as a touch panel or a mechanical key, and receives an operation input from the 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 a user.

  The auxiliary storage unit 27 is a nonvolatile memory such as a ROM (Read Only Memory), and stores a program P2 and other data necessary for the control unit 21 to execute processing. The auxiliary storage unit 27 stores a wallet 271 that stores token data held by the user. The wallet 271 holds information such as a wallet address and a secret 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 name of the user 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 a purchase history in which a user purchases a product or service at a member store in association with the user ID. As shown in FIG. 3, the purchase history includes a cashback history indicating the amount cashed back to the user according to the purchase amount (the amount returned by the token). The SNS column stores information related to 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 a collection ratio of a fee collected from the member store according to the purchase amount when the user purchases a product or service at the member store in association with the member store ID. The merchandise column stores information related to merchandise (or service) provided by the member store in association with the member store ID. The SNS image sequence stores image data for SNS posting related to each product in association with the member store ID and the product. The link column stores a link address for transition to a Web page related to the member store in association with the member store ID. The hyperlink is, for example, an address for transitioning to a member store's home page.

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

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

  FIG. 4 is an explanatory diagram showing an outline of the first embodiment. FIG. 5 is an explanatory diagram for explaining the token-back process and the donation process. FIG. 4 illustrates a state where a token equivalent to cashback 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 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 described above, this system handles a unique currency (token) issued by the issuing server 3. For example, the issuing server 3 performs ICO (Initial Coin Offering) and sells all or part of the token generated by itself. For example, the issuing server 3 sells the token to a general user (“Token Holder” shown in FIG. 4) and sells it to the server 1 that functions as an operator (provider) of token sales.

  When the ICO is performed, the issuing server 3 determines the upper limit of the total issued amount of tokens and supplies tokens corresponding to a part of the total issued amount to the market. For example, when the total issued amount of tokens is 10,000, the issuing server 3 supplies 1000 tokens corresponding to 10% of the total issued amount at the ICO stage. As will be described later, when a new token purchase request is received from the server 1, the issuing server 3 issues a new token within a range that satisfies the upper limit (10,000) of the total issued amount and transmits (sells) it to the server 1. .

  The server 1 accepts the deposit from the user and sells the token. The server 1 obtains (purchases) a token corresponding to the deposit amount from the issuing server 3 and transmits (remits) it to the wallet address owned by the user. The transmitted token is stored in the wallet 271 in the terminal 2. Thereby, the user becomes a holder who holds the token.

  In the present embodiment, the server 1 is described as transmitting (sending money) a token to the terminal 2, but the server 1 communicates between the token exchange, exchange office, etc. (not shown) and the terminal 2. The terminal 2 may acquire a token from an exchange or the like instead of the server 1 only by mediating. That is, the server 1 only needs to be operable so that a token is given to the user according to the deposit amount, and does not have to accept the deposit and sell (send) the token.

  Here, when shopping at a member store, the user who owns the token can receive token transfer corresponding to the purchase amount of the product, that is, cashback (tokenback) by the token. The member store is one or a plurality of stores that are members of the token back service according to the present system, and is a provider that provides goods or services to the user. Note that 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 Embodiment 2 described later.

  Processing for giving a token equivalent to cashback to a user will be described in detail. First, a user purchases a product or the like at a member store. The purchase of a product or the like may be made using the above-described token, but it is preferable that the purchase is based on a settlement means other than the token (for example, legal currency).

  When purchasing a product or the like, the user operates the terminal 2 to image a paper medium such as a receipt or receipt, and transmits the captured image to the server 1 in order to prove to the server 1 that shopping has been performed at the member store. To do. Note that the means for verifying that shopping has been performed is not limited to imaging of receipts or the like. For example, the terminal 2 may read a predetermined QR code (registered trademark) printed on a receipt, obtain purchase information such as a product, and transfer it to the server 1.

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

The server 1 calculates the token amount equivalent to 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 token amount based on the possession information of the token possessed 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 in which the token is continuously held without being sold, the holding amount of the token held in the wallet 271 and the like. In the present embodiment, the server 1 determines the token amount to be transferred to the user according to the token holding period and the holding amount.

  Based on FIG. 5, the token back process will be described based on the possession information. FIG. 5 illustrates a situation where tokens of different quantities are transferred to two users who have purchased the same product according to the token holding status. In the example illustrated in FIG. 5, “User A” holds tokens of the quantity “2.000” for “5 years”. In addition, “User B” holds a token of “1.000” less than User A for “one year” shorter than 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). When the user does not hold one or more tokens, the server 1 does not make the user a token back target even if the purchase information is acquired, and does not give a token. On the other hand, when the user has one or more tokens, the server 1 grants a token. That is, the server 1 determines qualified persons for token back based on the minimum possession amount of tokens, and grants tokens to users who have tokens exceeding the minimum possession amount. In the example shown in FIG. 5, since both users A and B have one or more (1.000 or more), both are subject to token back. On the other hand, the server 1 does not grant a token to a user who holds less than one token. By defining the minimum amount required to receive token back, the token functions as a kind of membership.

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

  When the user has one or more tokens, the server 1 calculates the token amount to be transferred to the user based on purchase information such as products. In the case of the example in FIG. 5, for example, the server 1 transfers a token having a quantity of “0.050” corresponding to 1% of the purchase amount to the user A who has purchased a product of 500,000 yen. It should be noted that what percentage of the purchase amount is cashbacked (tokenback) is an arbitrary design matter, and for example, the cashback percentage may be determined for each member store and each product. Further, for example, the server 1 may give a fixed amount of tokens to the user regardless of the product purchased by the user.

  On the other hand, the server 1 transfers a token having a quantity of “0.005” corresponding 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 1/5, the server 1 sets the amount of token transfer to user B to 1/10 of that of user A. Thus, the server 1 multiplies the purchase amount by the coefficient according to the holding period and the holding amount, and calculates the token amount to be transferred to each user.

  Note that the above calculation method is an example, and the calculation method of the token amount to be given to the user is not limited to this. For example, presence / absence of past token sale by the user may be added as one of the holding information on which the token amount is calculated. The information used as the basis for calculating the token amount is not limited to the purchase information of the product and the possession information of the token, but is other information such as the presence / absence of token donation and the presence / absence of posting to the SNS described later Also good.

  As described above, the server 1 transfers more tokens to a user who has a longer token holding period and a larger holding amount. This creates an incentive for the user to hold the token without selling it, and can help increase the value of the token, which will be described later.

  Returning to FIG. 4, the description will be continued. The server 1 that has given the token to the user acquires a fee from the member store according to the purchase amount of the product purchased by the user at the member store. The fee is a matching fee that is paid in the name of guiding the user who owns the token to the member store. As described above, the server 1 prompts the user to shop at the member store by giving the user a token equivalent to cashback. The server 1 collects a fee from the member store in return. For example, the server 1 notifies the member store to pay the fee when the token amount given to the user is converted into a legal currency. The member store remits money to the server 1 via remittance means (not shown) (for example, a financial institution such as a bank).

  When the user newly performs shopping at a member store and transfers the token to the user, the server 1 acquires (purchases) the token using the fee paid from the member store as a source and gives it 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 purchase price to the issuing server 3.

  When a purchase request is received from the server 1, the issuing server 3 determines whether or not there is token storage (inventory). If it is determined that the token is stored, the issuing server 3 transmits to the server 1 tokens of the quantity requested by the server 1 from the stored tokens. The server 1 transmits (remits money) 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 that does not exceed the upper limit of the total token issuing amount, and transmits the token to the server 1. For example, if the total issued amount is 10,000 and no token is stored in the issuing server 3, the issuing server 3 increases the issued amount by 10% and issues (generates) 1000 new tokens. The issuing server 3 performs token transmission (sales) from the newly issued token to the server 1.

  In the above description, the server 1 procures a token from the issuing server 3 that is a token issuing entity. However, even if a token is procured from a holder (“Token Holder” in FIG. 4) of the token, for example. Good. In this case, for example, the server 1 outputs information such as a desired purchase price and desired purchase quantity of the token, that is, a purchase request to a virtual currency exchange (not shown) and searches for a holder whose token sale price matches. To make a token sale. The server 1 executes a transaction for receiving transmission of a token from a holder that has been contracted to buy and sell, and acquires a token to be given to the user. That is, the server 1 only needs to be able to procure a token with the fee collected from the member store as a starting point, and may acquire the token from the issuer or from another token holder.

  By the above processing, a new token is procured from the stock of the issuing server 3 (or from the token holder), so that the effect of increasing the token price works. In the above, in order to avoid an excessive rise in the value of tokens, new tokens are issued when the stored tokens are no longer stored. If you look at it, the price increase effect of the token works.

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

  Furthermore, in this embodiment, the server 1 performs a donation process in which a part of a token to be given to the user as a cashback is transmitted (sent) 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 a nature conservation organization, an animal protection organization, a child support facility, an educational institution, etc., and donates tokens to each organization and facility as a recipient. These organizations and facilities are merely examples, and the recipient is not particularly limited. Each donation destination has a wallet address for receiving a token donation, and the server 1 transmits the token to the wallet address.

  The server 1 extracts a part of the token scheduled to be transferred to the user and transmits the part of the token to each donation destination. Of the tokens corresponding to cash back, the ratio of tokens to be donated is not particularly limited. In the case of donating a token, the server 1 may accept designation of a donation destination from the user, but an allocation process for predicting a donation destination that the user would like to donate and a distribution of tokens to be donated to each donation destination. And donate automatically.

  For example, the server 1 determines a donation destination and distribution based on a purchase history of products and the like by the user. Although the method for determining the donation destination and distribution from the purchase history is not particularly limited, for example, the server 1 has an attribute of the purchased product (for example, a product for men or a product for women) and an attribute of each donation destination (for example, Whether the organization is an environmental protection organization or an education-related organization, etc.) and the donation destination and distribution may be determined on a rule basis. In addition, for example, the server 1 manually accepts input of donation destinations and distributions from each user, accumulates samples to some extent, performs matching between users based on the purchase history, and the same donation as a user with a similar purchase history You may decide to get ahead and distribute. In addition, for example, the server 1 introduces a machine learning algorithm, constructs a learning model using a purchase history as an input value, and using a donation destination and distribution as an output value, and determines the donation destination and distribution using the learning model. May be.

  Through the above-described processing, the server 1 generates different donation allocations based on the purchase history of each user, as shown on the right side of FIG. For example, in the case of the user A, the server 1 sets the weight of donation to the environmental protection organization and the educational institution to be large. In the case of the user B, the server 1 sets the specific gravity of donation to the educational institution and the animal protection group to be large.

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

  FIG. 6 is an explanatory diagram illustrating an example of a token back screen. FIG. 6 shows an example of a display screen on which the user can confirm the token received as cashback. The token back screen displays purchase information 61 such as a product causing the token back, a token back 62 indicating the amount of tokens given, an allocation 63 indicating the donation destination and distribution, and SNS images 64, 64, 64. 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 purchased by the user, or an image related to a donation destination to which the user has donated a token. As shown in FIG. 6, an SNS image 64 for uploading purchased products to the SNS and an SNS image 64 for uploading a donation destination are displayed on the token back screen. When notifying the user of the token back or the like via the token back screen, the server 1 also searches 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 any SNS image 64 that the user desires to upload from the displayed SNS images 64. When selection input to the SNS image 64 is received, for example, the terminal 2 displays a pop-up screen (not shown) and receives input of a comment for SNS upload and the like. The terminal 2 notifies the server 1 of the selected content of the SNS image 64 and the input content such as a comment, and generates and uploads an article (post information) to be posted to the SNS.

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

  The posted article posted to the SNS includes, for example, a link 71 in addition to the user's account name, comment, SNS image 64, and the like. The link 71 is a hyperlink for making a transition 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 at the terminal 2 and uploads it to the user's SNS account. Thereby, the information regarding the member store or the donation destination is spread on the SNS, and it is possible to prompt other users to participate in the service according to the present system. In addition, it is possible to increase the social satisfaction of the user who has purchased a product or the like and donated the token, and can stimulate the user's willingness to purchase and donate.

FIG. 8 is a flowchart illustrating an example of a processing procedure for token grant processing. Based on FIG. 8, the processing content of the token back process which provides a token to a user is demonstrated. For the sake of brevity, the description will be made assuming that the user has already made a deposit to the server 1 and has a certain token.
The control unit 21 of the terminal 2 acquires a captured image obtained by capturing a paper medium in which purchase information is described, and transmits the captured image to the server 1 (step S11). The paper medium is, for example, a receipt or a receipt. The control unit 21 captures a receipt or the like in accordance with a user operation, and transmits the captured image to the server 1.

  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 a product purchased by the user (step S12). For example, the control unit 11 extracts information such as the purchase price of the product, the purchased product, and the purchase date / 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 block chain, and acquires possession information indicating the possession status of the token retained by the user (step S13). The holding information is information such as a token holding period and a holding amount, for example.

  Based on the acquired possession information, the control unit 11 determines whether or not the user possesses a predetermined number or more tokens (step S14). When it is determined that the predetermined number of tokens or more are not held (S14: NO), the control unit 11 ends the series of processes.

  When it is determined that a predetermined number or more of tokens are held (S14: YES), the control unit 11 caches the user based on the purchase information acquired in step S12 and the acquired information acquired in step S13. The token amount 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, etc., 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 cash back amount in the user DB 141.

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

  When a token corresponding to cashback is acquired from the server 1, the control unit 21 of the terminal 2 displays the number of tokens given from the server 1 on the display unit 24 (step S18). For example, as illustrated in FIG. 6, the control unit 21 is the number of tokens returned (granted) to the user, the donation destination and distribution to which a part of the token is donated, and the SNS upload image candidate. SNS images 64, 64, 64... Are displayed. The SNS image 64 is an image related to a product 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 receives an input of a comment or the like to be posted together with the selected image (Step S20). The control unit 21 requests the server 1 to generate and upload an article (post information) to be posted to the SNS based on the image selected in step S19, the comment input in step S20, and the like (step S21). When receiving an upload request from the terminal 2, the control unit 11 of the server 1 generates an SNS upload article using the posting material such as the image selected in step S19 and the comment input in step S20, and the SNS. Upload to the top (step S22). The article includes an image selected in step S19, a comment input in step S20, and the like, as well as a link 71 for transitioning to a Web page related to the member store or the donation destination. The control unit 11 ends the series of processes.

FIG. 9 is a flowchart illustrating an example of a processing procedure of token acquisition processing. 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 a fee remittance via a financial institution, for example.

  The control unit 11 makes a purchase request for purchasing a token corresponding to the cashback given to the user from the token issuer (issuing server 3) (step S32). And the control part 11 acquires a token using the fee acquired by step S31 from the issuing server 3 (step S33). That is, the control unit 11 purchases a token using the fee paid from the member store as a source. For example, when the issue server 3 receives a purchase request in step S32, the issue server 3 determines whether or not there is storage (inventory) of the requested token. If it is determined that there is a requested token, the issuing server 3 transmits the requested token from the stored token to the server 1. If it is determined that there is no token for the request, the issuing server 3 issues a new token within a range that does not exceed the upper limit of the total issued amount, and transmits the token of the quantity requested by the server 1 from the newly issued token. The control unit 11 ends the series of processes.

  In the above description, 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 a token to a company worker for welfare purposes within the company, and may give a part of the token to be transferred to another worker as a reward for a worker with high performance. Further, for example, the server 1 sells a token that can be obtained as a token back only in a specific region as a regional promotion measure, and transmits a part of the token transferred to the user to the local government as tax revenue of the local government. Good. As described above, the server 1 only needs to be able to transmit a part of the token given to the user to a predetermined transmission destination, and the transmission purpose may not be the donation purpose.

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

  In the above description, for convenience of explanation, the server 1 collects (acquires) a fee from a member store and then procures (acquires) a token from the issuing server 3 after giving a token equivalent to cashback to the user. 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 token back amount planned immediately after shopping by the user on the token back screen, and transmit the token again after completion of the token procurement. As described above, the order of granting a token to a user, obtaining a fee from a member store, and obtaining a token from the issuing server 3 is an arbitrary design matter, and each process may be mixed.

  Moreover, although the server 1 shall acquire purchase information from the user's terminal 2 above, you may make it acquire purchase information from a member store. For example, the server 1 may acquire the purchase history of the user from a 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) functioning as a wallet for receiving a token to the user, and transmits purchase information to the server 1 (second program). Program) is distributed to member stores (providers of goods or services). The application program (second program) is installed in, for example, a predetermined terminal device installed in a member store or a POS server that manages the terminal device. The application program accepts a purchase request for a product or the like from a user and causes a computer such as a terminal device installed at a member store or a POS server to execute processing for transmitting purchase information to the server 1. Further, the application program acquires a notification indicating the token amount to be given to the user from the server 1 so that the user can know the token amount to be cashed back, and sends the notification (a token amount equivalent to cash back) to the member store. A process of displaying (outputting) on a display or the like is executed.

  In addition, as described above, in order to grant a token to a user who holds a predetermined number or more, for example, the above application program has a user's token holding amount of a predetermined number or more when a purchase request is received. Only when the user holds a predetermined number or more of tokens, the purchase information may be transmitted to the server 1 to obtain a notification related to the token back. In this case, the application program may inquire the user's token holding amount with respect to the server 1, for example, or may search the user's token holding amount by referring to the block chain.

  As described above, according to the first embodiment, the server 1 gives a token equivalent to cashback to a user who owns a token (virtual currency) according to purchase information such as a product at a member store. Thereby, unlike a settlement system using a simple virtual currency, the virtual currency can be used to assist the user in purchasing products and the like. In addition, since a token equivalent to cashback is provided based on a fee acquired from a member store, a sustainable purchase cycle can be supported.

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

  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 determining the minimum amount required to receive token back, the token can function as a kind of membership, and a sustainable purchase cycle can be constructed more appropriately.

  Further, according to the first embodiment, the number of tokens to be granted is determined according to the token holding status by the user, such as the token holding period and the holding amount. As a result, the user has an incentive to hold the token without selling it, and the token value can be expected to rise.

  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 transmission destination (for example, a donation destination, a worker in the company, a local government, etc.). Thereby, for example, donation (donation) activities, corporate activities, regional development, etc. can be supported, and virtual currency can be used not only as a purchase support but also as a sustainable social support measure.

  Further, according to the first embodiment, the donation destination and distribution are automatically determined based on the purchase history of the user, and the token is transmitted. Thereby, even if a user does not choose a donation destination himself / herself, it can donate with an appropriate allocation, and convenience can be improved.

  Further, according to the first embodiment, the server 1 presents the material for SNS posting to the user, generates a posted article (post information) in response to the user's selection, and automatically uploads it. This makes it possible for other users to know the items purchased by the user, etc., or the recipients of tokens, to encourage participation in this service, and to increase user satisfaction and further purchase and donation activities. Can be promoted.

(Embodiment 2)
In the present embodiment, a mode in which a token is given when purchasing a product by an EC service such as an EC site will be described. In addition, about the content which overlaps with Embodiment 1, the same code | symbol is attached | subjected and description is abbreviate | 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 a token corresponding to the purchase amount. An EC site is a virtual store on the Internet, for example, and is a Web site that presents products on a browser. For example, a user can purchase a product from an exhibitor or an EC site operating company via the EC site and receive delivery of the product.

  In this embodiment, the server 1 is affiliated with the EC site, obtains product purchase information from the EC server 4 that manages the EC site, and gives a token to the user who uses the EC site. In this case, the server 1 obtains a fee from the EC site operating company, purchases a token using the fee as a source, and gives it to the user.

FIG. 11 is an explanatory diagram for explaining screen transition in the terminal 2. Based on FIG. 11, a screen transition process for 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 related to products that are on the EC site. The terminal 2 receives an operation input by the user, and receives a designation input of a product that the user desires 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 settlement process and confirms the purchase of the product. The EC server 4 transmits purchase information of a product for which purchase has been confirmed to the server 1. In addition, 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 shopping has been completed.

  Here, the EC server 4 displays a link for starting the application program (program P2) provided by the server 1 in cooperation with the end screen. For example, as shown in FIG. 11, the EC server 4 displays text with a hyperlink “Do you want to share?” On the end screen. When the text is operated, the terminal 2 starts an 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. 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, a link to the application program is displayed on the end screen, and the transition to the display screen of the SNS image 64 is triggered by an operation on the link. As a result, the user can smoothly post to the SNS after shopping at the EC site.

FIG. 12 is a flowchart illustrating an example of a token grant process according to the second embodiment. Based on FIG. 12, the processing content of the token grant processing according to Embodiment 2 will be described.
The control unit 21 of the terminal 2 accesses the EC server 4 and requests the EC server 4 to output product information (step S201). When receiving the output request for the product information, 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 purchase request for a product 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 settlement process for performing a purchase settlement of the requested product (step S205). For example, the EC server 4 withdraws from the bank account of the user via a credit company or the like based on the user's registered credit card number or the like.

  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 processing to step S13.

  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 an end screen indicating that the payment has ended (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. Based on the operation input by the user, the control unit 21 determines whether to start the application program and post to the SNS (step S209). When it determines with not performing posting (S209: NO), the control part 21 complete | finishes a series of processes. If it is determined that posting is to be made (S209: YES), the control unit 21 activates the application program and displays a token back screen including the SNS image 64 (step S210). The control unit 21 moves the process to step S17.

  In addition, although the form which purchases goods in EC site (Web site) was demonstrated above, the form which installs a dedicated GUI application in the terminal 2, and receives EC service on the GUI screen of the said application is also of this embodiment. Included in the category. That is, the server 1 only needs to be able to grant a token when the user purchases a product using the EC service, and the form of the EC service is not limited to the website.

  As described above, according to the second embodiment, the present system can also be applied to a case where a product is purchased through an EC site.

  The embodiment disclosed this time is to be considered as illustrative in all points and not restrictive. The scope of the present invention is defined by the terms of the claims, rather than the meanings described above, and is intended to include any modifications within the scope and meaning equivalent to the terms of the claims.

1 server (information processing equipment)
DESCRIPTION OF SYMBOLS 11 Control part 12 Main memory part 13 Communication part 14 Auxiliary memory part P1 Program 141 User DB
142 member store DB
143 Donation DB
2 Terminal (terminal equipment)
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 (6)

An information processing system having an issuing device for issuing virtual currency and an information processing device for giving the virtual currency to a user,
The issuing device is:
An issuing unit that issues the virtual currency within a predetermined upper limit of the issued total amount,
A supply unit for supplying the issued virtual currency to a device of an exchange capable of buying and selling the virtual currency;
The information processing apparatus includes:
A purchase information acquisition unit for acquiring purchase information related to the product or service purchased by the user;
A fee acquisition unit for acquiring a fee according to the purchase amount of the product or service from a provider of the product or service;
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;
A currency acquisition unit for acquiring the virtual currency from the issuing device or the exchange;
An information processing system comprising: a granting unit that grants the acquired virtual currency to the user. The issuing unit
Issuing a certain amount of the virtual currency below the upper limit of the total issued amount,
2. The information processing system according to claim 1, wherein the virtual currency is issued stepwise within a range of an upper limit of the total issue amount in response to the purchase request. The information processing apparatus includes a holding information acquisition unit that acquires holding information indicating a holding period and a holding amount of the virtual currency of the user,
The information processing system according to claim 1 or 2, wherein the granting unit grants the virtual currency in a quantity corresponding to the holding period and the holding amount. The information processing apparatus includes:
A receiving unit for receiving input of post information related to the product or service from the user;
A post output unit for outputting the post information on a network;
The information processing system according to claim 1, wherein the assigning unit assigns the virtual currency in a quantity corresponding to whether or not the posting information is output. Issuing device
Issue virtual currency within the upper limit of the total amount issued in advance,
Executing the process of supplying the issued virtual currency to a device of an exchange capable of buying and selling the virtual currency;
Information processing device
Obtain purchase information about products or services purchased by users,
Obtain a fee according to the purchase price of the product or service from the provider of the product or service,
Output a purchase request for the virtual currency in a quantity corresponding to the fee to the issuing device or the exchange,
Obtain the virtual currency from the issuing device or exchange,
The information processing method characterized by performing the process which provides the acquired said virtual currency to the said user. An issuing unit that issues virtual currency within a predetermined upper limit of the total issued amount;
A supply unit for supplying the issued virtual currency to a device of an exchange capable of buying and selling the virtual currency;
A purchase information acquisition unit for acquiring purchase information related to the product or service purchased by the user;
A fee acquisition unit for acquiring a fee according to the purchase amount of the product or service from a provider of the product or service;
An output unit that outputs a purchase request for the virtual currency in a quantity corresponding to the fee to the exchange;
A currency acquisition unit for acquiring the virtual currency from the exchange;
An information processing apparatus comprising: a granting unit that grants the acquired virtual currency to the user.

Images