WO2020179863A1 - 情報処理装置、情報処理方法及びプログラム - Google Patents
情報処理装置、情報処理方法及びプログラム Download PDFInfo
- Publication number
- WO2020179863A1 WO2020179863A1 PCT/JP2020/009372 JP2020009372W WO2020179863A1 WO 2020179863 A1 WO2020179863 A1 WO 2020179863A1 JP 2020009372 W JP2020009372 W JP 2020009372W WO 2020179863 A1 WO2020179863 A1 WO 2020179863A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- user
- exchange
- virtual currency
- amount
- server
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
- G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
- G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/085—Payment architectures involving remote charge determination or related payment systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
- G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/381—Currency conversion
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q2220/00—Business processing using cryptography
Definitions
- the present invention relates to an information processing device, an information processing method, and a program.
- Patent Document 1 only promotes the consumption of virtual currency.
- the purpose is to provide information processing devices and the like that can appropriately support consumers using virtual currencies.
- the information processing device is determined by an acquisition unit that acquires purchase information regarding the goods or services purchased by the user, and a determination unit that determines the quantity of virtual currency to be given to the user based on the purchase information.
- An granting unit that grants the virtual currency to the user in the amount of the virtual currency, a reception unit that accepts an exchange request for exchanging the virtual currency for a substitute from the user, and a virtual currency that is granted when the exchange request is received. It is characterized by including a determination unit for determining whether or not it is within a certain period from the time when the virtual currency is executed, and an exchange processing unit for performing processing related to the exchange of the virtual currency when it is determined that the period is within a certain period.
- virtual currency can be used to appropriately support consumers.
- FIG. 1 is a schematic diagram showing a configuration example of a token back system.
- a token back system for granting virtual currency (tokens) to a user who has purchased a product or service (hereinafter referred to as “product or the like”) in a legal tender at a predetermined member store will be described.
- the token back system includes an information processing device 1, terminals 2, 2, 2 ..., an exchange server 3, an EC (Electronic Commerce) server 4, and an issuing server 5.
- the devices are communicated and 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 computer, a personal computer, or the like.
- the information processing device 1 is assumed to be a server computer, and will be read as server 1 in the following for brevity.
- the server 1 is a server computer of an administrator who manages this system, and provides cash back (token back) in tokens to users who have purchased products or the like at member stores affiliated with this system.
- the token is a virtual currency unique to this system and is a virtual currency whose transaction history is recorded on the blockchain.
- the virtual currency given by the server 1 does not have to be a unique token, and may be an existing virtual currency such as Bitcoin (registered trademark) or Ethereum (registered trademark).
- the terminal 2 is a terminal device of each user who uses this system, for example, a smartphone, a tablet terminal, a personal computer, or the like.
- the terminal 2 will be described as a smartphone provided with a touch panel.
- An application program for realizing the function of the present system is installed in the terminal 2 in advance, and the terminal 2 executes the application program to perform the process described below.
- the exchange server 3 is a server computer of a virtual currency exchange company that provides a virtual currency exchange.
- the token according to the present embodiment is listed on one or a plurality of exchanges, and the user can buy and sell the token on the exchange.
- the EC server 4 is a server computer of an EC site (virtual store) provider that provides electronic commerce services.
- EC site businesses are members of this system. Each user can receive tokens when he / she purchases a product or the like at a physical store that is a member store or an EC site.
- the issuing server 5 is a server computer that issues tokens according to this system, and is a server computer that controls the token issuance upper limit. In this system, the issuing server 5 issues tokens and supplies them to the trading market (exchange, etc.). The upper limit of token issuance is defined by the issuing server 5, and the issuing server 5 adjusts the issuance amount (issues new tokens) while referring to the supply and demand situation of tokens in the market.
- FIG. 2 is a block diagram showing a configuration example of the server 1.
- 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.
- the communication unit 13 includes a processing circuit and the like for performing processing relating 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 the program P1 and other data necessary for the control unit 11 to execute processing. Further, the auxiliary storage unit 14 stores the user DB 141, the member store DB 142, the donation destination DB 143, the purchase history DB 144, the posting history DB 145, and the grant history DB 146.
- the user DB 141 is a database that stores information about each user.
- the member store DB 142 is a database that stores information on each member store (actual store or EC site).
- the donation destination DB 143 is a database that stores information on organizations and the like registered as donation destinations for tokens. As will be described later, in the present embodiment, when a token is given to each user, a part of the token to be given is donated to the donation destination registered in the donation destination DB 143.
- the purchase history DB 144 is a database that stores the purchase history of products and the like by the user.
- the posting history DB 145 is a database that stores the posting history of users to SNS (Social Networking Service). As will be described later, in the present embodiment, when a token is given to each user, the token is given on condition that the user posts on the SNS.
- the grant history DB 146 is a database that stores a token grant history (tokenback history) for the user.
- the auxiliary storage unit 14 may be an external storage device connected to the server 1.
- the server 1 may be a multi-computer including a plurality of computers, or may be a virtual machine virtually constructed by software.
- the server 1 is not limited to the above configuration, and may include, for example, an input unit that accepts operation input, a display unit that displays an image, and the like. Further, the server 1 includes a reading unit for reading a portable storage medium 1m such as a CD (Compact Disk)-ROM and a DVD (Digital Versatile Disc)-ROM, and reads and executes the program P1 from the portable storage medium 1m. You can Alternatively, the server 1 may read the program P1 from the semiconductor memory 1n.
- a portable storage medium 1m such as a CD (Compact Disk)-ROM and a DVD (Digital Versatile Disc)-ROM
- FIG. 3 is a block diagram showing a configuration example of the terminal 2.
- 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 a plurality of arithmetic processing units such as CPUs and MPUs, 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 RAM, 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 by the control unit 21.
- the input unit 25 is an input interface such as a touch panel or a mechanical key, and receives an operation input from a user.
- the image pickup unit 26 is a camera provided with an image pickup element such as a CMOS (Complementary Metal Oxide Semiconductor) sensor, and takes 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.
- the terminal 2 may include a reading unit that reads the portable storage medium 2n, and may read the program P2 from the portable storage medium 2n and execute the program P2. Alternatively, the terminal 2 may read the program P2 from the semiconductor memory 2m.
- FIG. 4 is an explanatory diagram showing an example of the record layout of the user DB 141, the member store DB 142, the donation destination DB 143, the purchase history DB 144, the posting history DB 145, and the grant history DB 146.
- the user DB 141 includes a user ID column, a user name column, a wallet column, an SNS column, and a personal information column.
- the user ID column stores user IDs for identifying each user.
- the user name column, wallet column, SNS column, and personal information column are associated with the user ID, respectively, and include the user's name, wallet information (for example, public key, etc.) necessary for sending tokens to the user, and the user's SNS. It stores account information and user's personal information (gender, age, nationality, etc.).
- the member store DB 142 includes a member store ID column, a member store name column, a member store information column, and a commission rate column.
- the member store ID column stores the member store ID for identifying each member store.
- the member store name column, the member store information column, and the commission rate column are associated with the member store IDs, and store the member store name, information about other member stores, and the ratio of fees collected from the member stores. There is.
- the donation destination DB 143 includes a group ID column, a group name column, and an image column.
- the group ID column stores a group ID for identifying a group registered as a donation destination.
- the group name column and the image column respectively store the name of the organization or the like as the donation destination and the image data used by the user to post to the SNS when donating to the group or the like in association with the group ID. ..
- the purchase history DB 144 includes a purchase ID column, a purchaser column, a member store column, a date column, a purchased product column, and a purchase price column.
- the purchase ID column stores a purchase ID assigned to each purchase history (purchase information) when a user purchases a product or the like from a member store.
- the purchaser column, member store column, date column, purchased product column, and purchase amount column are associated with the purchase ID, respectively, and the user ID of the user who is the purchaser and the member store of the member store where the user purchased the product, etc.
- the ID, the date of purchase of the product, etc., the name of the purchased product, etc., and the purchase amount are stored.
- Post history DB 145 includes a post ID column, a post date/time column, an SNS column, a contributor column, and a post information column.
- the post ID column stores a post ID assigned to each piece of post information posted by the user on the SNS.
- the posted date/time column, the SNS column, the contributor column, and the posted information column are each associated with a post ID, and the posted date and time, the SNS of the post destination, the user ID of the user who is the contributor, and the posted content (text, Data such as images) is stored.
- the grant history DB 146 includes a date/time column, a token back column, a donation column, and an approval column.
- the date and time column stores the date and time when the token was given to the user.
- Each of the token back column, the donation column, and the approval column stores information on token back to the user, information on donation, and whether or not the token grant is approved by the member store in association with the date and time.
- the token back column stores, for example, a user ID of a user who is a grant target, the number of granted tokens, and an ID of a transaction created for granting (transferring) tokens.
- the donation column for example, the group ID of the organization to which the donation is made, the number of tokens donated, the transaction ID created for the donation of tokens (remittance), and the user posted to the SNS in connection with the donation of tokens. It stores the posting ID of the posting information.
- FIG. 5 is an explanatory diagram showing an outline of the token granting process. An outline of this system will be described with reference to FIG. As described above, in this embodiment, the token unique to this system is handled.
- the token is supplied to the transaction market by, for example, the issuing server 5 which is separate from the server 1, and controls the issuance upper limit.
- the exchange transaction market
- each user can buy and sell the tokens distributed in the market.
- the server 1 is a management device that manages cashback (tokenback) processing via the token, and grants a quantity of tokens to a user who has purchased a product or the like according to the purchase amount of the purchased product or the like. To do.
- cashback tokenback
- to give a token in the present embodiment means a process of registering a transaction for sending a token to a user in a database (for example, the giving history DB 146) and actually broadcasting the transaction to the blockchain network. It can include any process of sending money to the user's wallet.
- the server 1 receives a request from the terminal 2, broadcasts the transaction registered in the database, and sends the token given to the user to the wallet.
- Multiple member stores such as physical stores and EC sites (virtual stores) are members of this system, and when a user purchases a product or the like at each member store, the server 1 is the purchase amount of the product or the like from the member store.
- the fee will be collected according to the above, and the token will be granted using the fee as a source.
- the commission rate collected from each member store is defined in the member store DB 142.
- the server 1 multiplies the purchase amount by the commission rate to calculate the commission, and requests the member store to pay the calculated commission.
- the server 1 carries out the token back using the fee paid by the member store as a source.
- the server 1 outputs a purchase request (so-called offer) to the exchange server 3 to purchase the token based on the commission paid by the member store, and purchases the token. That is, the server 1 procures tokens from the virtual currency transaction market using the commission from the member store as a source.
- the server 1 acquires from the exchange server 3 the market price information indicating the market price of the token (the price per unit quantity when the token is converted into legal currency). That is, the server 1 acquires from the exchange server 3 the data indicating the market price of the token on the exchange market (exchange or the like).
- the token market value information may be obtained from an external site that discloses the market value information of the virtual currency instead of the exchange server 3.
- the server 1 calculates the number of tokens that can be purchased with a fee from the member store, referring to the market price information. Then, the server 1 outputs a purchase request to the exchange server 3 to purchase the calculated number of tokens at the current market price. The server 1 purchases a token from the token holder via the exchange server 3. The server 1 allocates the purchased token to the user.
- tokens are procured from the exchange server 3 (exchange), but for example, the server 1 may procure (purchase) tokens from the issuing server 5 which is the issuer of the tokens. ..
- the server 1 procures tokens from the market using the commission from the member store as a source of funds. This will result in a forced increase in demand for tokens in the market.
- the server 1 acquires the holding information indicating the holding status of the token by the user, and gives the token according to the acquired holding information.
- the holding information is data indicating the holding amount of the token, the holding period, and the like.
- the server 1 refers to the token grant history stored in the grant history DB 146, and acquires data such as the holding amount and holding period of the token held by the user.
- the server 1 may acquire the user's current possession information from the blockchain based on the wallet information stored in the user DB 141. The server 1 grants tokens based on the acquired holding information.
- the server 1 determines whether or not the amount of tokens held by the user is equal to or greater than a predetermined number, and if it is determined that the user holds more than a predetermined number of tokens, grants tokens.
- the number of tokens used as a criterion is not particularly limited, but for example, the server 1 determines whether or not the user has one or more tokens. In this way, the server 1 implements token back for users who have a predetermined number or more of tokens. As a result, the token itself is made to function as a kind of membership, and the user is given an incentive to hold a predetermined number or more of tokens.
- token holding amount used as the judgment criterion may be set to 0, and token back may be performed for all users.
- the server 1 weights the tokens based on the token possession information by the user, and changes the number of tokens given to the user. For example, the server 1 changes the amount of tokens held by the user and the amount of tokens granted according to the holding period.
- the server 1 increases the number of tokens given to the user as the holding amount increases. Further, the server 1 increases the number of tokens given to the user as the holding period becomes longer. This encourages the user to retain more tokens and longer.
- this system grants tokens (tokenback) as in a general cashback service, but encourages you to continue to hold tokens without consuming them.
- tokenback tokens
- the server 1 increases the amount of tokens granted or the types of products or the like to be granted to users who have acquired tokens by a method other than token back (giving tokens by purchasing products or the like). This can encourage users to purchase tokens and further reduce the amount of tokens distributed in the market.
- FIG. 6 is an explanatory diagram showing an example of the top screen.
- the application program related to this system is installed in the terminal 2, and the application program is executed to perform the following processing.
- the screen may be displayed and operated on an API (Application Programmable Interface) such as a Web browser.
- FIG. 6 shows the top screen of the application.
- the top screen is a screen that displays the amount of tokens held by the user. As shown in FIG. 6, the terminal 2 displays on the top screen the amount of tokens currently held by the user and the legal currency equivalent amount when the tokens are converted into legal currency corresponding to the nationality of the user. indicate.
- the terminal 2 also displays the left swipe icon 61, the right swipe icon 62, and the camera icon 63 on the top screen.
- the left swipe icon 61 is an icon that prompts the operation input of the left swipe (the operation of tracing the screen to the left) in order to transition to the member store list screen (see FIG. 7) described later.
- the right swipe icon 62 is an icon that prompts an operation input of a right swipe (an operation of tracing the screen to the right) in order to transition to an exchange screen (see FIG. 10) described later.
- the camera icon 63 is an icon for transitioning to the image pickup mode of the receipt of the member store (actual store) described later.
- the top screen is changed to another screen by "swipe", but the operation may be an operation of tracing the screen, and may be an operation called flick, drag, or the like. ..
- FIG. 7 is an explanatory diagram showing an example of screen transition during a left swipe operation.
- a swipe operation of tracing the top screen in the left direction (first direction) is accepted according to the left swipe icon 61
- the terminal 2 transitions to the list screen (second screen) shown in the center of FIG. 7.
- the list screen is a display screen showing a list of a plurality of member stores that are members of this system.
- the list screen displays a list of member stores (first member store) of an EC site (virtual store) that provides a commercial transaction service and member stores of the actual store (second member store). To be done.
- Terminal 2 displays link buttons 71, 71, 71 ... Corresponding to each EC site on the list screen.
- the terminal 2 accesses the EC site (EC server 4) corresponding to the operated link button 71.
- the access destination may be the home screen of the EC site or the like, or the link button 71 may directly transition to the screen of each product.
- the terminal 2 applies for the purchase of products etc. at the accessed EC site.
- the server 1 acquires the purchase information regarding the purchased product or the like from the EC server 4.
- the purchase information is data indicating the purchased product, the purchase price, the purchase date and time, and the like.
- the server 1 stores the acquired purchase information in the purchase history DB 144.
- the purchase information is acquired from the EC server 4, but the server 1 may directly acquire the purchase information at the EC site from the terminal 2.
- the server 1 may acquire purchase information via an ASP (Affiliate Service Provider) or the like.
- the server 1 only needs to be able to directly or indirectly acquire the purchase information from the terminal 2 via the list screen of FIG. 7, and the acquisition route is not particularly limited.
- the terminal 2 displays scan buttons 72, 72, 72 ... Corresponding to each member store which is an actual store on the list screen.
- the terminal 2 activates the imaging unit 26, and information about the product etc. purchased in the actual store. A transition is made to an imaging mode for imaging the medium in which (purchase information) is described.
- the terminal 2 transitions to an imaging mode for imaging a receipt distributed to users in a physical store.
- the terminal 2 captures an image of a receipt according to an operation input from the user, performs character recognition on the captured image, and extracts purchase information such as a purchased product, purchase price, purchase date and time.
- the terminal 2 transmits the extracted purchase information to the server 1.
- the receipt will be read, but the target medium is not limited to the receipt, and may be code information such as a QR code (registered trademark). That is, the terminal 2 only needs to be able to capture an image of a predetermined medium and extract purchase information, and the target is not limited to a paper medium on which text is printed.
- code information such as a QR code (registered trademark). That is, the terminal 2 only needs to be able to capture an image of a predetermined medium and extract purchase information, and the target is not limited to a paper medium on which text is printed.
- the server 1 acquires the purchase information from the POS (Point of Sales) system of the actual store, for example. May be.
- the server 1 When the purchase information is acquired from the terminal 2 or the EC server 4, the server 1 requests the member store to pay the fee according to the purchase price of the product etc., as described above. The server 1 outputs a token purchase request to the exchange server 3 based on the commission paid by the member store, and purchases the token.
- the server 1 gives the user the number of tokens corresponding to the purchase price of the product etc. For example, the server 1 acquires the market value information of the token from the exchange server 3, and converts the fee determined according to the purchase amount into the quantity of tokens according to the current market value. The server 1 grants the converted quantity of tokens to the user.
- the server 1 acquires the token holding information by the user and determines the number of tokens to be given by referring to the acquired holding information. Specifically, the server 1 weights according to the token holding amount and the holding period by the user, and determines the token granting amount.
- “reaching the issuance upper limit” may include not only the case where the upper limit value of the issuance amount is actually reached, but also the case where the issuance amount is near the upper limit value.
- the server 1 gives another virtual currency or legal currency to the user instead of the token according to the present system. .. As a result, it is possible to cope with the situation where the issuance limit is reached.
- the server 1 grants the user the number of tokens determined above. In this case, the server 1 grants the token on the condition that a part of the token to be donated is donated to a predetermined donation destination (outside) and the token is posted to the SNS to the effect that the token has been donated.
- FIG. 8 is an explanatory diagram showing an example of a notification screen regarding tokens to be added.
- the terminal 2 receives a notification from the server 1 and transitions to the screen (fourth screen) in FIG. 8.
- the screen is a display screen that displays the number of tokens scheduled to be given to the user and encourages donation of tokens and posting to the SNS.
- the terminal 2 converts the name of the member store that purchased the product, etc., the number of tokens granted by purchasing the product, etc. at the member store, and the tokens granted into legal currency. The amount and the amount are displayed at the top of the screen.
- the server 1 notifies the terminal 2 of this information and displays it on the screen of FIG.
- the terminal 2 donates a part of the token to be granted and displays that the donation should be posted to the SNS. For example, as shown in FIG. 8, the terminal 2 displays an image of the donation destination registered (memorized) in the donation destination DB 143, and displays a text to the effect that the donation and posting should be made at the bottom of the image. In addition, the terminal 2 displays the toggle switch 81 for selecting the SNS as the posting destination, and allows one or a plurality of SNSs to be posted to be selected.
- the terminal 2 transitions to a screen (not shown) and accepts the input of the comment (text) to be posted on the SNS from the user. Then, the terminal 2 outputs the posting information including the text input by the user and the image of the donation destination illustrated in FIG. 8 on the SNS using the SNS account of the user himself.
- the server 1 calls the SNS API to determine whether or not the posting information is output, that is, whether or not the posting to the SNS is completed.
- the server 1 stores the posting information output from the terminal 2 on the SNS in the posting history DB 145 in association with the posting date and time.
- the server 1 grants a token to the user.
- the server 1 creates a transaction for sending a token to the user's wallet, and registers (stores) it in the grant history DB 146. In this case, the server 1 registers the transaction status as "waiting for approval". After that, the server 1 accepts the token grant approval from the member store (EC server 4 or the like) that pays the fee.
- the server 1 updates the status to "approved”.
- the server 1 outputs the transaction to the blockchain in response to the request from the terminal 2 and remits the token excluding the donation to the user's wallet.
- the server 1 remits the donated tokens to the donation destination at any timing after updating the status to “approved”.
- the donation may be made in cash (legal currency) or the like instead of the token.
- the token donation destination and the amount of tokens to be donated may be arbitrarily specified by the user, but may be automatically determined by the server 1.
- the server 1 analyzes the tendency of the user based on the purchase history of the product or the like by the user, and determines the donation destination and the donation amount.
- the server 1 associates a product or the like with a donation destination and a donation amount in advance, and determines the donation destination and the donation amount on a content basis according to the product or the like purchased by the user.
- the server 1 compares the purchase history of the target user with the purchase history of another user, and uses collaborative filtering so that the donation destination is the same as the donation made by a similar other user in the past. And determine the amount of donations.
- the server 1 may distribute tokens to a plurality of donation destinations and remit with one donation.
- the donation destination and the amount of donation may be arbitrarily designated by the user, or may be automatically determined by the server 1 based on the purchase history or the like, similarly to the above.
- the token is given to the user after waiting for the approval from the member store, but the token may be given without the approval from the member store.
- FIG. 9 is an explanatory diagram showing the top screen after token addition.
- the terminal 2 returns to the top screen illustrated in FIG. In this case, the terminal 2 updates the top screen and displays the amount of tokens held after the grant. That is, the terminal 2 adds the number of tokens given above to the previous holding amount, and updates and displays the holding amount after addition. As a result, the user can immediately confirm that he / she has received the token back due to the purchase of the product or the like.
- the terminal 2 displays the holding amount displayed on the top screen by changing the display color so that the user can intuitively grasp that the holding amount has increased. It is preferable to display the amount in a form different from the amount held before the addition shown in the figure. Note that, for convenience, FIG. 9 shows how the display color is changed in bold.
- FIG. 10 is an explanatory diagram showing an example of screen transition during a right swipe operation.
- the terminal 2 displays the link screen (third screen) shown in FIG. 10.
- the link screen is a screen showing a list of a plurality of exchanges where tokens can be bought and sold, and is a link page for accessing the site of each exchange.
- the terminal 2 accepts a selection input for selecting any exchange on the link screen, and accesses the site of the selected exchange.
- the terminal 2 can convert the token into legal currency or another virtual currency at the site (not shown) of the exchange that has accessed.
- the terminal 2 can also purchase additional tokens at the exchange.
- the terminal 2 may accept designation input for designating the account of the exchange to which the token is to be remitted, the number of tokens to be remitted, etc. on the screen of FIG. 10, and may be able to remit the token to the designated account (wallet). ..
- the user can move the token with a simple operation.
- the terminal 2 may display a predetermined alert and prompt the user to reconsider the conversion of the token. This can encourage the user to continue holding the token.
- each user can obtain tokens that can be expected to increase in price by purchasing products etc. at member stores.
- the token can be obtained by a simple operation on the terminal 2.
- FIG. 11 is a flowchart showing an example of a processing procedure executed by the terminal 2.
- the content of processing executed by the terminal 2 will be described with reference to FIG.
- the control unit 21 of the terminal 2 displays a top screen (first screen) showing the amount of tokens (virtual currency) currently held by the user (step S11).
- the control unit 21 determines whether or not the operation input of the left swipe tracing in the left direction (first direction) has been accepted (step S12).
- the control unit 21 determines whether or not the operation input to the camera icon 63 has been accepted (step S13).
- the control unit 21 determines whether or not the operation input of the right swipe tracing in the right direction (second direction) is accepted (step). S14).
- the control unit 21 displays a list screen (second screen) showing a list of member stores (step S15). Specifically, the control unit 21 displays one or more member stores (first member stores) of the EC site (virtual store) and one or more member stores (second member stores) of the actual store. The control unit 21 accepts a selection input for selecting one from the member stores displayed on the list screen (step S16).
- the control unit 21 determines in step S16 whether or not the EC site has been selected (step S17). When determining that the EC site has been selected (S17: YES), the control unit 21 accesses the selected EC site (step S18). The control unit 21 performs a process related to a purchase application for a product or the like on the EC site based on an operation input from the user (step S19). When the user purchases a product or the like on the EC site, the server 1 acquires, from the EC server 4, purchase information regarding the product or the like that the user purchased.
- step S13 or NO in step S17 the control unit 21 transitions to an imaging mode for the user to image the receipt (medium) in which the purchase information in the actual store is described, and the operation input from the user
- the receipt is imaged according to the above (step S20).
- the control unit 21 extracts purchase information from the captured image and transmits it to the server 1 (step S21).
- the control unit 21 After performing the processing of step S19 or S21, the control unit 21 acquires a notification regarding the number of tokens to be granted from the server 1, and makes a donation of tokens and a posting screen for posting to SNS (fourth screen). And outputs the posted information on the SNS based on the operation input from the user (step S22).
- the screen displayed in step S22 is a screen prompting the user to donate the token and to post the donation to the SNS. For example, in addition to the number of tokens to be granted, information on the donation destination determined by the server 1 Display (image, etc.).
- the control unit 21 accepts the input of arbitrary text from the user and outputs the posted information including the input text, the image of the donation destination, and the like on the SNS.
- the server 1 When the post information from the user is output to the SNS, the server 1 adds the number of tokens according to the purchase amount and the like. In addition, the server 1 remits a part of the tokens given to the user to the donation destination.
- the control unit 21 transits to the top screen and updates the token holding amount displayed on the top screen to the token holding amount after the grant (step S23).
- the control unit 21 displays a link screen (third screen) showing a list of exchanges where tokens can be bought and sold (step S24). ..
- the control unit 21 accepts the selection input for selecting the exchange to be accessed, and accesses the selected exchange (step S25).
- control unit 21 After executing the processes of steps S23 and S25, or when NO in step S14, the control unit 21 determines whether or not to log out according to the operation input from the user (step S26). When determining not to log out (S26: NO), the control unit 21 returns the process to step S12. When it is determined to log out (S26: YES), the control unit 21 ends a series of processes.
- FIG. 12 is a flowchart showing an example of a processing procedure executed by the server 1.
- the processing contents executed by the server 1 will be described with reference to FIG.
- the control unit 11 of the server 1 acquires purchase information related to the product or the like purchased by the user from the terminal 2 or the EC server 4 (step S41).
- the control unit 11 reads the commission rate of the member store from the member store DB 142, calculates the commission according to the purchase amount of the product or the like, and requests the member store to pay the commission (step S42).
- the control unit 11 acquires the market value information of the token (virtual currency) in the transaction market and the token possession information by the user (step S43).
- the market price information is data showing the market price (legal currency conversion amount) of the token, and is data showing the market price in the virtual currency trading market (exchange, etc.).
- the holding information is data indicating the holding status of tokens by the user, for example, data showing the holding amount of tokens, holding period, and the like.
- the control unit 11 determines the number of tokens to be given to the user based on purchase information, market price information, possession information, etc. (step S44). Specifically, the control unit 11 converts the commission (legal tender amount) obtained by multiplying the purchase amount of the product or the like by the commission rate of the member store into the quantity of tokens according to the market value of the tokens. In addition, the control unit 11 performs weighting according to the possessed information of the user, and determines the imparted amount so that the possessed amount is large and the held period is long.
- control unit 11 determines a donation destination to which a part of the tokens scheduled to be given to the user will be remitted (step S45). For example, the control unit 11 determines the donation destination from the purchase history of the product or the like by the user.
- the control unit 11 acquires information on the current token issuance amount from the issuing server 5 and determines whether or not the token issuance upper limit is reached (step S46). When it is determined that the issue upper limit is reached (S46: YES), the control unit 11 gives the user another virtual currency different from the token of the present system or legal currency (step S47), and ends the series of processes. ..
- the control unit 11 When it is determined that the issuance upper limit is not reached (S46: NO), the control unit 11 notifies the terminal 2 of the number of tokens to be granted determined in step S44 (step S48). Specifically, the control unit 11 notifies the terminal 2 of the number of tokens to be provided, and also notifies the information of the donation destination determined in step S45.
- the control unit 11 determines whether or not the posting to the SNS by the user is completed (step S49). When it is determined that the posting is not completed (S49: NO), the control unit 11 waits for the processing. When it is determined that the posting is completed (S49: YES), the control unit 11 determines whether or not the token grant approval has been received from the member store (step S50). If it is determined that the token grant approval is not accepted (S50: NO), the control unit 11 waits for processing.
- the control unit 11 When it is determined that the token grant approval has been accepted (S50: YES), the control unit 11 outputs a token purchase request based on the commission calculated in step S42 to the exchange server 3 (step S51). In addition, the control unit 11 grants tokens excluding donations to the user (step S52). Further, the control unit 11 sends the donation tokens to the donation destination determined in step S45 (step S53), and ends the series of processes.
- the number of tokens to be given to the user is determined according to the fee paid by the member store, but the number of tokens to be given to the user is determined regardless of the amount of the fee, and the token back is performed. May be.
- the token is bought back through the exchange, but the configuration via the exchange is not essential, and the server 1 may purchase the token directly from the token holder. ..
- the token is given according to the purchase information of the product etc. by the user, but the present embodiment is not limited to this.
- the server 1 may attach the token to the user's action other than the purchase of the product such as access to the Internet advertisement by the user and use of a specific application as a trigger. That is, the purchase of a product or the like is an example of an opportunity to give a token, and the token may be given according to other user's actions.
- the terminal 2 transits to the member store list screen by a simple swipe operation on the top screen, and purchase information is directly read by receipt or the like, or via the EC server 4. It indirectly outputs to the server 1, receives the token grant, and presents the retained amount after grant to the user. In this way, it is possible to receive token back with a simple operation, and it is possible to appropriately support consumers (users).
- token back can be received corresponding to both the EC site (virtual store) and the actual store.
- this system can be implemented as a social contribution policy by making token donation a condition for token back.
- the system can be made known to general consumers.
- Embodiment 2 In the present embodiment, a mode is described in which machine learning for learning the purchase history of the user is performed to generate an estimation model 147, and the generated estimation model 147 is used to estimate the purchase behavior of the user who uses the member store. ..
- the contents overlapping with the first embodiment are designated by the same reference numerals and the description thereof will be omitted.
- FIG. 13 is an explanatory diagram regarding the estimation model 147.
- the server 1 performs machine learning to learn the user's purchase history of products and the like, the user's posting history to the SNS, the user's personal information, and the like, and generates the estimation model 147. Then, the server 1 estimates the purchase behavior of the user using the generated estimation model 147, and presents the user with information according to the estimation result. For example, the server 1 changes the display order of the member stores displayed on the list screen illustrated in FIG. 7 based on the estimation result output from the estimation model 147, and displays the member stores that are highly likely to be used by the user at the top.
- the EC site (virtual store) is estimated, but the estimation target in the estimation model 147 may include not only the EC site but also the member stores of the actual stores.
- the estimation model 147 is a neural network generated by deep learning and is, for example, an RNN (Recurrent Neural Network).
- the estimation model 147 includes an input layer that receives input of data, an intermediate layer that performs an operation based on the data input to the input layer, and an output layer that outputs data for output based on the operation result of the intermediate layer. Have.
- the input layer has a plurality of neurons that accept input of various data, and passes the input data to the intermediate layer.
- the intermediate layer has a plurality of neurons that perform operations based on the data acquired from the input layer, and performs arithmetic processing for extracting the features of the input data. For example, when the estimation model 147 is an RNN, the intermediate layer performs an operation using the operation results of the preceding and following neurons arranged in time series, while taking into account the correlation between the data input to each neuron in the input layer. Extract features.
- the output layer estimates the data to be output based on the features extracted in the intermediate layer.
- the estimation model 147 may be another neural network.
- the estimation model 147 is not limited to a learned model related to deep learning, and may be a model based on an algorithm such as reinforcement learning, decision tree, random forest, SVM (Support Vector Machine), or the like.
- the server 1 uses the information accumulated in the purchase history DB 144, the post history DB 145, etc. as teacher data, and based on the purchase history, post history, personal information, etc. of each user, the user who uses the member store. Generates an estimation model 147 that estimates the purchase behavior of.
- the server 1 inputs the purchase history and the like, and generates the estimation model 147 which outputs the EC site (member store) that should be recommended to the user. More specifically, the server 1 generates an estimation model 147 that outputs the priority order of the EC sites that should be recommended to the user for the plurality of EC sites that are members of this system.
- the server 1 In addition to the purchase history of each user (data such as purchased products, purchase amount, purchase date and time), the server 1 records the history of posted information (posted comments, posted date and time, etc.) posted on the SNS as conditions for token back. Data) and user's personal information (data such as age, sex, nationality) are read from each database and input to the estimation model 147 as input data for the teacher. The server 1 performs the calculation in the estimation model 147 based on various data, and gives priority to the member stores to be recommended to the user, specifically the member stores to be recommended (for example, the probability value corresponding to each EC site) To estimate.
- the server 1 refers to the purchase history of each user and uses the purchase amount of the product or the like purchased by the user at each EC site and the purchase frequency of purchasing the product or the like at each EC site as the evaluation function. , Do learning. For example, the server 1 calculates a value obtained by multiplying the purchase amount and the purchase frequency for each EC site, and determines the correct answer value of the priority order of each EC site such that the higher the multiplication value, the higher the priority order. The server 1 compares the priority estimated based on the input data with the priority that is the correct answer, and optimizes various parameters (weights, etc.) used in the intermediate layer so that the two are close to each other. As a result, the server 1 generates an estimation model 147 that estimates the EC site where the purchase amount and the purchase frequency are high.
- the server 1 adds the fee of each EC site (member store) to the evaluation function in addition to the purchase amount and the purchase frequency. Specifically, the server 1 multiplies, in addition to the purchase amount and the purchase frequency, the fee paid from each EC site, and determines the correct answer value of the priority order according to the product of the purchase amount, the purchase frequency, and the fee. decide. As a result, the EC site with the higher fee paid to this system is given priority, and the service related to token back can be preferably maintained.
- the server 1 inputs data such as purchase history, posting history, and personal information of each user into the estimation model 147 generated above, and estimates an EC site that should be recommended to each user. Then, the server 1 presents the estimated EC site to the user.
- the server 1 estimates the priority of each EC site using the estimation model 147 and displays each EC site according to the estimated priority. Output the list screen.
- the server 1 may estimate the priorities in batch processing and output the list screens in accordance with the estimated priorities when the list screen is displayed.
- the terminal 2 sequentially displays the EC sites having higher priorities from the top of the screen.
- the terminal 2 displays each EC site and a link button 71 (link information) for accessing each EC site.
- the terminal 2 accesses the EC site and the user can purchase a product or the like.
- the EC site with a high priority that is, the EC site that the user often uses and the usage amount (purchase amount) is high. Then, the user can easily access the EC site by operating the link button 71, and the convenience of the user can be improved.
- FIG. 14 is a flowchart showing a procedure for generating the estimation model 147. Based on FIG. 14, the contents of the process of generating the estimation model 147 by machine learning will be described.
- the control unit 11 of the server 1 reads information such as personal information of each user, purchase history of products, and posting history to SNS from each database as teacher data (step S201).
- the purchase history includes the member store ID of the member store where the user purchased the product, etc., in addition to the product, etc. (product or service) purchased by the user.
- the control unit 11 uses the teacher data to generate the estimation model 147 that outputs the purchase behavior of the user who uses the member store when the data such as the purchase history is input (step S202). Specifically, the control unit 11 generates an estimation model 147 that inputs the purchase history and the like and outputs the member store that is estimated to be used by the user. The control unit 11 inputs data such as purchase history, posting history, and personal information for teachers into the estimation model 147, and estimates the member store used by the user. The control unit 11 compares the estimated member store with the member store that is determined to be recommended according to the purchase price, the purchase frequency, the fee, etc., and optimizes various parameters of the middle tier so that the two approximate each other. Generate an estimation model 147. The control unit 11 ends a series of processes.
- FIG. 15 is a flowchart showing an example of a processing procedure executed by the token back system according to the second embodiment.
- the terminal 2 executes the following process.
- the control unit 21 of the terminal 2 requests the server 1 to output the member store list screen (step S221).
- the control unit 11 of the server 1 reads data such as the purchase history of the target user's product, the posting history to the SNS, and personal information from each database (step S222).
- the control unit 11 inputs the read data into the estimation model 147 and estimates the purchase behavior of the target user (step S223). Specifically, the control unit 11 acquires, as an output, a member store (EC site) estimated to be used by the user. More specifically, the control unit 11 acquires the priority order of the member stores that should be recommended to the user for the plurality of member stores. The control unit 11 outputs a list screen that displays each member store to the terminal 2 according to the acquired priority order (step S224). The control unit 21 of the terminal 2 displays the output list screen (step S225) and shifts the processing to step S16.
- a member store EC site
- the control unit 11 outputs a list screen that displays each member store to the terminal 2 according to the acquired priority order (step S224).
- the control unit 21 of the terminal 2 displays the output list screen (step S225) and shifts the processing to step S16.
- the server 1 estimates the product or the like that the user has a high probability of purchasing by using the estimation model 147, and the estimated product or the like.
- the server 1 stores the products and the like provided by each EC site in the member store DB 142 in association with each other and the pages in the EC site on which the products and the like are posted, and uses the estimation model 147 to inform the user.
- Estimate the priority of products that should be recommended The server 1 displays information on each product or the like in order from the top of the list screen according to the estimated priority, and displays a link button 71 (link information) for accessing the page of each product or the like.
- the purchase behavior of the user who uses the member store is estimated using the estimation model 147, and the information according to the estimation result is output to the user to be the consumer (user). ) Can be suitably supported.
- the EC site (virtual store) that should be recommended to the user is estimated, and the link information for accessing the estimated EC site is output. This can improve the convenience of the user.
- the convenience of the user can be further improved by estimating the priority of the EC sites to be recommended to the user and presenting each EC site according to the estimated priority. ..
- the user can be more favorably supported.
- the posting history to the SNS as an input in addition to the purchase history, it is possible to learn not only the purchase behavior of the user at the member store but also the behavior (action) on the SNS. Therefore, the estimation accuracy of purchase behavior can be improved.
- FIG. 16 is an explanatory diagram showing an outline of the third embodiment. The outline of the present embodiment will be described with reference to FIG.
- the token according to the present system is not intended for consumption but is procured from the market based on the commission from the member store, and the token is granted according to the information held by the user.
- the token is granted according to the information held by the user.
- it will increase demand by creating demand for tokens while promoting long-term holding.
- the token after grant is within a certain purchase guarantee period, the user is given a purchase guarantee to buy back the token at a predetermined purchase amount (exchange amount). This will further promote long-term possession of tokens and relatively increase the value of tokens.
- the server 1 receives, from the terminal 2 of each user, a request for exchanging tokens already attached to fiat currency. Specifically, the server 1 receives a designation input designating the number of tokens to be exchanged. It should be noted that the server 1 may not be the terminal 2 of the user, but may manually accept an input of a replacement request from an operator who receives an inquiry from the user, for example.
- the server 1 When accepting the exchange request, the server 1 identifies the point of time when the token already given to the user is given. For example, the server 1 refers to the grant history DB 146 to identify the token transaction that has been approved by the member store and has not been exchanged by the purchase guarantee in the past. Then, the server 1 identifies the point of time when the token is assigned by each transaction (for example, the point of time when the approval is accepted from the member store). The server 1 determines whether or not the time point at which the token is assigned by each transaction is within a certain period from the current time point (the time point when the exchange request is accepted).
- the server 1 extracts the number of tokens specified by the user in order from the tokens with the oldest granting time among the tokens determined to be within a certain period.
- the server 1 targets the extracted token for exchange.
- the server 1 may output the transactions of the tokens determined to be within a certain period to the terminal 2 in a list and allow the user to select the transaction to be exchanged.
- the server 1 obtains the token price information and calculates the token exchange amount (purchase guarantee amount). For example, the server 1 acquires the market value information at the time of token grant so that the price is the same as the price at the time of granting the token, and calculates the amount of money converted into legal currency according to the market price at the time of grant.
- the token is purchased at the same price as when it was granted, but the exchange amount does not have to be the same as the price at the time of grant.
- the server 1 may use an amount less than the price at the time of grant (eg, 90% amount) as the exchange amount in order to further encourage long-term holding.
- the exchange amount may be the amount obtained by subtracting the fees.
- the server 1 notifies the exchange amount to the terminal 2 and accepts the approval input from the terminal 2 as to whether or not to approve the exchange with the exchange amount.
- the server 1 notifies the wallet address to which the token is to be remitted, and prompts the user to remit the designated token.
- the server 1 After confirming the token remittance from the user, the server 1 performs a process related to remittance of legal currency equivalent to the exchange amount (for example, remittance request to a financial institution). This completes the purchase of tokens.
- the server 1 acquires the current market price information of the token (at the time of accepting the exchange request) from the exchange server 3, and calculates the exchange amount by converting the token into fiat currency according to the current market price.
- the grant time is April 1
- the exchange request is received at the present time (for example, maturity of 10) in addition to the exchange amount calculated at the market price on April 1.
- the server 1 notifies the terminal 2 of the amounts of money of both parties, and also notifies the difference (difference) of both parties and presents it to the user.
- the user can appropriately determine whether or not to perform exchange (purchase) based on the purchase guarantee.
- FIG. 17 is a flowchart showing an example of a processing procedure executed by the token back system according to the third embodiment.
- the control unit 11 of the server 1 receives a token exchange request from the terminal 2 (step S301). When the exchange request is accepted, the control unit 11 identifies the point of time when the token that has already been granted to the user is granted (step S302).
- the control unit 11 determines whether or not the time when the exchange request is received in step S301 is within a certain period from the time when the token specified in step S302 is granted (step S303). When it is determined that it is not within the fixed period (S303: NO), the control unit 11 ends the series of processes. When it determines with it being within a fixed period (S303:YES), the control part 11 acquires the market value information of a token (step S304). For example, the control unit 11 acquires the time value information at the time of granting the token and at the current time (at the time of accepting the exchange request).
- the control unit 11 calculates the token exchange amount according to the market price at the time of grant based on the acquired market price information (step S305). Further, the control unit 11 calculates the exchange amount (second exchange amount) in which the token is converted into the legal currency according to the current market price (step S306). The control unit 11 requests approval for token exchange (step S307). For example, the control unit 11 outputs the exchange amount of the token based on the market price at the time of grant, outputs the exchange amount based on the current market price, and presents the difference between the two. After presenting the amounts of both, the control unit 11 accepts the final approval.
- the control unit 11 determines whether the token exchange is approved (step S308). When it determines with not being approved (S308:NO), the control part 11 complete
- the purchase guarantee period is a fixed period
- the purchase guarantee amount (exchange amount) is also a prescribed amount according to the market price.
- the server 1 uses the token possession information by the user as the basis.
- the guarantee period and the guarantee amount may be changed.
- the server 1 sets the guarantee period and the guarantee amount according to the holding amount and holding period of the token by the user, and stores the set contents in the grant history DB 146.
- the server 1 sets a longer guarantee period and a larger guarantee amount as the holding amount is larger and the holding period is longer. This can further encourage long-term holding of tokens.
- the server 1 refers to the setting contents stored in the grant history DB 146, and if it is within the set purchase guarantee period, exchanges with the set purchase guarantee amount.
- a certain guarantee period was set for the purchase of tokens, but it is not necessary to set a guarantee period. That is, the purchase guarantee may be implemented regardless of the elapsed time between the token grant time and the exchange request acceptance time.
- the exchange amount was set according to the market price at the time of grant, but it may be exchanged at a fixed exchange amount regardless of the market price at the time of grant.
- the user can suitably determine whether or not the exchange should be performed by presenting the difference between the purchase guarantee amount (exchange amount) and the current price.
- the long-term holding of tokens can be more preferably promoted by setting the purchase guarantee period and the purchase amount according to the holding information such as the holding amount and the holding period.
- FIG. 18 is an explanatory diagram showing an example of a top screen according to the modification.
- the top screen of FIG. 18 includes a graph 181.
- the graph 181 shows the guaranteed purchase price (exchange amount) of the token held by the user at each time point in the past according to the market price at the time of grant, and the exchange amount (the second time period) converted according to the market price at each time point. And a redemption amount) in a time series.
- the terminal 2 displays the number of tokens held by the user at each time point in the past with a vertical bar, and the purchase guarantee amount converted according to the market price at the time of grant and the exchange converted according to the market price at each time point. Display forehead and line as a line.
- the purchase guarantee amount is indicated by a thick line
- the exchange amount according to the market price at each time point is indicated by a thin line.
- the thick line represents the amount of money when the purchase guarantee is used for exchange.
- the thin line represents the amount of money when the purchase guarantee is not used and exchanges are performed in the general trading market.
- the server 1 calculates the exchange amount of both at each time point in the past and outputs the graph 181.
- the server 1 calculates the purchase guarantee amount by multiplying the quantity of tokens granted before that time by the market price at the time of grant and integrating the multiplication values at each past time point.
- the exchange amount second exchange amount
- the server 1 at each time in the past, with respect to the amount of tokens held by the user at that time, at that time. Calculate the exchange amount by multiplying the virtual currency's market value.
- the server 1 calculates the exchange amount of both at each time point in the past (each day in the last week in FIG. 18) and displays it on the terminal 2 as a graph 181.
- the graph 181 enables the user to easily confirm that the token purchase guarantee is maintained by comparing with the market price.
- FIG. 19 is an explanatory diagram showing an example of the grant history screen.
- the grant history screen is a display screen for displaying a token grant history.
- the terminal 2 transitions to the grant history screen of FIG.
- the grant history screen includes a grant token display column 191 and a grant history display column 192.
- the granted token display field 191 is a display field that displays the amount of tokens currently owned by the user and the current market price. Note that “determining” represents a state of waiting for approval from the member store.
- the grant history display column 192 is a display column that displays the quantity of tokens granted to the user, the market price at the time of grant, etc. in association with the purchase information of the product or the like that triggered the token grant.
- the terminal 2 displays the number of tokens given according to the purchase amount of the product etc., and the market price at the time of granting guaranteed purchase, for each purchase information that has triggered the token grant, in the grant history display field 192. Display a list.
- the terminal 2 is associated with the name of the member store that purchased the product, the purchase date (use date), etc., the grant date and time (“fixed date” in FIG. 19), and the number of tokens granted (the number of tokens granted).
- the "reduction coin”), the market value at the time of grant (“conversion rate”), etc. are displayed.
- the "status” indicates whether or not it has been approved. The user can easily grasp when and how much purchase guarantee is attached to the granted token in a form associated with the purchase history of the product or the like by referring to the grant history display field 192.
- the third embodiment is common to the first to third embodiments, and therefore detailed description of the flowchart and other details will be omitted in this modification.
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Engineering & Computer Science (AREA)
- Strategic Management (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Entrepreneurship & Innovation (AREA)
- Game Theory and Decision Science (AREA)
- Marketing (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
情報処理装置(1)は、ユーザが購入した商品又はサービスに関する購入情報を取得する取得部と、前記購入情報に基づき、前記ユーザに付与する仮想通貨の数量を決定する決定部と、決定した数量の前記仮想通貨を前記ユーザに付与する付与部と、前記ユーザから、前記仮想通貨を代替物に交換する交換要求を受け付ける受付部と、前記交換要求を受け付けた場合、前記仮想通貨を付与した時点から一定期間内であるか否かを判定する判定部と、一定期間内であると判定した場合、前記仮想通貨の交換に係る処理を行う交換処理部とを備えることを特徴とする。
Description
本発明は、情報処理装置、情報処理方法及びプログラムに関する。
ブロックチェーンに代表される分散型台帳技術を用いて実現される仮想通貨の活用が検討されている。例えば特許文献1では、地域振興のために特定の地域にのみ流通する仮想通貨を取り扱う仮想通貨システムであって、消費者が入金した現金の価値よりも高い仮想通貨を消費者に付与し、時間経過に従って、付与した仮想通貨の価値を減少させる仮想通貨システムが提案されている。特許文献1によれば、仮想通貨の価値が減少していくため、仮想通貨の消費が促進され、地域の経済活動を活発化することができる。
しかしながら、特許文献1に係る発明は仮想通貨の消費を促すに過ぎない。
一つの側面では、仮想通貨を用いて消費者を適切に支援することができる情報処理装置等を提供することを目的とする。
一つの側面に係る情報処理装置は、ユーザが購入した商品又はサービスに関する購入情報を取得する取得部と、前記購入情報に基づき、前記ユーザに付与する仮想通貨の数量を決定する決定部と、決定した数量の前記仮想通貨を前記ユーザに付与する付与部と、前記ユーザから、前記仮想通貨を代替物に交換する交換要求を受け付ける受付部と、前記交換要求を受け付けた場合、前記仮想通貨を付与した時点から一定期間内であるか否かを判定する判定部と、一定期間内であると判定した場合、前記仮想通貨の交換に係る処理を行う交換処理部とを備えることを特徴とする。
一つの側面では、仮想通貨を用いて消費者を適切に支援することができる。
以下、本発明をその実施の形態を示す図面に基づいて詳述する。
(実施の形態1)
図1は、トークンバックシステムの構成例を示す模式図である。本実施の形態では、所定の加盟店において商品又はサービス(以下、「商品等」と記す)を法定通貨で購入したユーザに対し、仮想通貨(トークン)を付与するトークンバックシステムについて説明する。トークンバックシステムは、情報処理装置1、端末2、2、2…、取引所サーバ3、EC(Electronic Commerce)サーバ4、及び発行サーバ5を含む。各装置は、インターネット等のネットワークNを介して相互に通信接続されている。
(実施の形態1)
図1は、トークンバックシステムの構成例を示す模式図である。本実施の形態では、所定の加盟店において商品又はサービス(以下、「商品等」と記す)を法定通貨で購入したユーザに対し、仮想通貨(トークン)を付与するトークンバックシステムについて説明する。トークンバックシステムは、情報処理装置1、端末2、2、2…、取引所サーバ3、EC(Electronic Commerce)サーバ4、及び発行サーバ5を含む。各装置は、インターネット等のネットワークNを介して相互に通信接続されている。
情報処理装置1は、種々の情報処理、情報の送受信が可能な情報処理装置であり、例えばサーバコンピュータ、パーソナルコンピュータ等である。本実施の形態において情報処理装置1はサーバコンピュータであるものとし、以下では簡潔のためサーバ1と読み替える。サーバ1は、本システムを管理する管理者のサーバコンピュータであり、本システムに加盟する加盟店で商品等を購入したユーザに対し、トークン建てでキャッシュバック(トークンバック)を行う。当該トークンは本システム独自の仮想通貨であり、ブロックチェーンに取引履歴が記録される仮想通貨である。
なお、サーバ1が付与する仮想通貨は独自のトークンである必要はなく、例えばビットコイン(登録商標)、イーサリアム(登録商標)等の既存の仮想通貨であってもよい。
端末2は、本システムを利用する各ユーザの端末装置であり、例えばスマートフォン、タブレット端末、パーソナルコンピュータ等である。本実施の形態では端末2が、タッチパネルを備えたスマートフォンであるものとして説明を行う。端末2には、本システムに係る機能を実現するためのアプリケーションプログラムが予めインストールされており、端末2は、当該アプリケーションプログラムを実行することで後述の処理を行う。
取引所サーバ3は、仮想通貨の取引所を提供する仮想通貨交換業者のサーバコンピュータである。本実施の形態に係るトークンは、一又は複数の取引所に上場されており、ユーザは取引所においてトークンを売買可能となっている。
ECサーバ4は、電子商取引サービスを提供するECサイト(仮想店舗)事業者のサーバコンピュータである。本システムには、実店舗で商品等の販売を行う事業者のほかに、ECサイト事業者が加盟している。各ユーザは、加盟店である実店舗又はECサイトで商品等を購入した場合に、トークンを受け取ることができる。
発行サーバ5は、本システムに係るトークンの発行を行うサーバコンピュータであり、トークンの発行上限を制御するサーバコンピュータである。本システムでは、発行サーバ5がトークンの発行を行って取引市場(取引所等)に供給する。トークンの発行上限は発行サーバ5において規定され、発行サーバ5は、市場におけるトークンの需給状況を参照しながら発行量を調整(新規トークンを発行)する。
図2は、サーバ1の構成例を示すブロック図である。サーバ1は、制御部11、主記憶部12、通信部13、及び補助記憶部14を備える。
制御部11は、一又は複数のCPU(Central Processing Unit)、MPU(Micro-Processing Unit)、GPU(Graphics Processing Unit)等の演算処理装置を有し、補助記憶部14に記憶されたプログラムP1を読み出して実行することにより、サーバ1に係る種々の情報処理、制御処理等を行う。主記憶部12は、SRAM(Static Random Access Memory)、DRAM(Dynamic Random Access Memory)、フラッシュメモリ等の一時記憶領域であり、制御部11が演算処理を実行するために必要なデータを一時的に記憶する。通信部13は、通信に関する処理を行うための処理回路等を含み、端末2等と情報の送受信を行う。
制御部11は、一又は複数のCPU(Central Processing Unit)、MPU(Micro-Processing Unit)、GPU(Graphics Processing Unit)等の演算処理装置を有し、補助記憶部14に記憶されたプログラムP1を読み出して実行することにより、サーバ1に係る種々の情報処理、制御処理等を行う。主記憶部12は、SRAM(Static Random Access Memory)、DRAM(Dynamic Random Access Memory)、フラッシュメモリ等の一時記憶領域であり、制御部11が演算処理を実行するために必要なデータを一時的に記憶する。通信部13は、通信に関する処理を行うための処理回路等を含み、端末2等と情報の送受信を行う。
補助記憶部14は大容量メモリ、ハードディスク等であり、制御部11が処理を実行するために必要なプログラムP1、その他のデータを記憶している。また、補助記憶部14は、ユーザDB141、加盟店DB142、寄付先DB143、購入履歴DB144、投稿履歴DB145、付与履歴DB146を記憶している。ユーザDB141は、各ユーザの情報を格納するデータベースである。加盟店DB142は、各加盟店(実店舗又はECサイト)の情報を格納するデータベースである。寄付先DB143は、トークンの寄付先として登録してある団体等の情報を格納するデータベースである。後述するように、本実施の形態では、各ユーザにトークンを付与する場合に、付与するトークンの一部を寄付先DB143に登録してある寄付先に寄付させる。
購入履歴DB144は、ユーザによる商品等の購入履歴を格納するデータベースである。投稿履歴DB145は、ユーザによるSNS(Social Networking Service)への投稿履歴を格納するデータベースである。後述するように、本実施の形態では、各ユーザにトークンを付与する場合に、SNSへの投稿を条件にトークンを付与する。付与履歴DB146は、ユーザに対するトークンの付与履歴(トークンバックの履歴)を格納するデータベースである。
なお、補助記憶部14はサーバ1に接続された外部記憶装置であってもよい。また、サーバ1は複数のコンピュータからなるマルチコンピュータであっても良く、ソフトウェアによって仮想的に構築された仮想マシンであってもよい。
また、本実施の形態においてサーバ1は上記の構成に限られず、例えば操作入力を受け付ける入力部、画像を表示する表示部等を含んでもよい。また、サーバ1は、CD(Compact Disk)-ROM、DVD(Digital Versatile Disc)-ROM等の可搬型記憶媒体1mを読み取る読取部を備え、可搬型記憶媒体1mからプログラムP1を読み取って実行するようにしても良い。あるいはサーバ1は、半導体メモリ1nからプログラムP1を読み込んでも良い。
図3は、端末2の構成例を示すブロック図である。端末2は、制御部21、主記憶部22、通信部23、表示部24、入力部25、撮像部26、補助記憶部27を備える。
制御部21は、一又は複数のCPU、MPU等の演算処理装置を有し、補助記憶部27に記憶されたプログラムP2を読み出して実行することにより、端末2に係る種々の情報処理、制御処理等を行う。主記憶部22は、RAM等の一時記憶領域であり、制御部21が演算処理を実行するために必要なデータを一時的に記憶する。通信部23は、通信を行うためのアンテナ、処理回路等を含み、サーバ1等と情報の送受信を行う。表示部24は、液晶ディスプレイ、有機EL(Electro Luminescence)ディスプレイ等の表示装置であり、制御部21から与えられた画像を表示する。入力部25は、例えばタッチパネル、メカニカルキー等の入力インターフェイスであり、ユーザからの操作入力を受け付ける。撮像部26は、CMOS(Complementary Metal Oxide Semiconductor)センサ等の撮像素子を備えたカメラであり、ユーザによる操作入力に従って撮像を行う。補助記憶部27は、ROM(Read Only Memory)等の不揮発性メモリであり、制御部21が処理を実行するために必要なプログラムP2、その他のデータを記憶している。
制御部21は、一又は複数のCPU、MPU等の演算処理装置を有し、補助記憶部27に記憶されたプログラムP2を読み出して実行することにより、端末2に係る種々の情報処理、制御処理等を行う。主記憶部22は、RAM等の一時記憶領域であり、制御部21が演算処理を実行するために必要なデータを一時的に記憶する。通信部23は、通信を行うためのアンテナ、処理回路等を含み、サーバ1等と情報の送受信を行う。表示部24は、液晶ディスプレイ、有機EL(Electro Luminescence)ディスプレイ等の表示装置であり、制御部21から与えられた画像を表示する。入力部25は、例えばタッチパネル、メカニカルキー等の入力インターフェイスであり、ユーザからの操作入力を受け付ける。撮像部26は、CMOS(Complementary Metal Oxide Semiconductor)センサ等の撮像素子を備えたカメラであり、ユーザによる操作入力に従って撮像を行う。補助記憶部27は、ROM(Read Only Memory)等の不揮発性メモリであり、制御部21が処理を実行するために必要なプログラムP2、その他のデータを記憶している。
なお、端末2は、可搬型記憶媒体2nを読み取る読取部を備え、可搬型記憶媒体2nからプログラムP2を読み取って実行するようにしても良い。あるいは端末2は、半導体メモリ2mからプログラムP2を読み込んでも良い。
図4は、ユーザDB141、加盟店DB142、寄付先DB143、購入履歴DB144、投稿履歴DB145、及び付与履歴DB146のレコードレイアウトの一例を示す説明図である。
ユーザDB141は、ユーザID列、ユーザ名列、ウォレット列、SNS列、個人情報列を含む。ユーザID列は、各ユーザを識別するためのユーザIDを記憶している。ユーザ名列、ウォレット列、SNS列、及び個人情報列はそれぞれ、ユーザIDと対応付けて、ユーザの氏名、ユーザにトークンを送金するために必要なウォレット情報(例えば公開鍵等)、ユーザのSNSアカウントの情報、及びユーザの個人情報(性別、年齢、国籍等)を記憶している。
ユーザDB141は、ユーザID列、ユーザ名列、ウォレット列、SNS列、個人情報列を含む。ユーザID列は、各ユーザを識別するためのユーザIDを記憶している。ユーザ名列、ウォレット列、SNS列、及び個人情報列はそれぞれ、ユーザIDと対応付けて、ユーザの氏名、ユーザにトークンを送金するために必要なウォレット情報(例えば公開鍵等)、ユーザのSNSアカウントの情報、及びユーザの個人情報(性別、年齢、国籍等)を記憶している。
加盟店DB142は、加盟店ID列、加盟店名列、加盟店情報列、手数料率列を含む。加盟店ID列は、各加盟店を識別するための加盟店IDを記憶している。加盟店名列、加盟店情報列、及び手数料率列はそれぞれ、加盟店IDと対応付けて、加盟店の名称、その他の加盟店に関する情報、及び加盟店から徴収する手数料の割合を記憶している。
寄付先DB143は、団体ID列、団体名列、画像列を含む。団体ID列は、寄付先として登録してある団体等を識別するための団体IDを記憶している。団体名列及び画像列はそれぞれ、団体IDと対応付けて、寄付先である団体等の名称、及び当該団体等に寄付する場合にユーザがSNSへの投稿に利用する画像データを記憶している。
購入履歴DB144は、購入ID列、購入者列、加盟店列、日付列、購入商品列、購入額列を含む。購入ID列は、加盟店からユーザが商品等を購入した場合に、個々の購入履歴(購入情報)に対して割り当てられる購入IDを記憶している。購入者列、加盟店列、日付列、購入商品列、及び購入額列はそれぞれ、購入IDと対応付けて、購入者であるユーザのユーザID、ユーザが商品等を購入した加盟店の加盟店ID、商品等を購入した日付、購入した商品等の名称、及び購入額を記憶している。
投稿履歴DB145は、投稿ID列、投稿日時列、SNS列、投稿者列、投稿情報列を含む。投稿ID列は、ユーザがSNSに投稿した個々の投稿情報毎に割り当てられた投稿IDを記憶している。投稿日時列、SNS列、投稿者列、及び投稿情報列はそれぞれ、投稿IDと対応付けて、投稿された日時、投稿先のSNS、投稿者であるユーザのユーザID、及び投稿内容(テキスト、画像等のデータ)を記憶している。
付与履歴DB146は、日時列、トークンバック列、寄付列、承認列を含む。日時列は、ユーザにトークンを付与した日時を記憶している。トークンバック列、寄付列、承認列はそれぞれ、日時と対応付けて、ユーザへのトークンバックに関する情報、寄付に関する情報、及び加盟店からのトークン付与の承認の有無を記憶している。トークンバック列には、例えば付与対象であるユーザのユーザID、付与したトークンの数量、及びトークンの付与(送金)のために作成したトランザクションのIDなどを記憶している。寄付列には、例えば寄付先である団体等の団体ID、寄付したトークンの数量、トークンの寄付(送金)のために作成したトランザクションのID、及びトークン寄付に関連してユーザがSNSに投稿した投稿情報の投稿IDなどを記憶している。
図5は、トークン付与処理の概要を示す説明図である。図5に基づき、本システムの概要を説明する。
上述の如く、本実施の形態では、本システム独自のトークンを取り扱う。当該トークンは、例えばサーバ1とは別個の発行サーバ5が取引市場に供給し、発行上限を制御する。取引所サーバ3が提供する取引所(取引市場)において、各ユーザは市場に流通するトークンを売買可能となっている。
上述の如く、本実施の形態では、本システム独自のトークンを取り扱う。当該トークンは、例えばサーバ1とは別個の発行サーバ5が取引市場に供給し、発行上限を制御する。取引所サーバ3が提供する取引所(取引市場)において、各ユーザは市場に流通するトークンを売買可能となっている。
サーバ1は、当該トークンを媒介としたキャッシュバック(トークンバック)の処理を管理する管理装置であり、商品等を購入したユーザに対し、購入した商品等の購入額に応じた数量のトークンを付与する。
なお、本実施の形態で云う「トークンの付与」とは、ユーザにトークンを送金するためのトランザクションをデータベース(例えば付与履歴DB146)に登録する処理と、トランザクションをブロックチェーンネットワークにブロードキャストして実際にユーザのウォレットへ送金する処理との何れも含み得る。前者の場合、サーバ1は端末2からの要求を受けてデータベースに登録されているトランザクションをブロードキャストし、ユーザに付与したトークンをウォレットへ送金する。
本システムには実店舗、ECサイト(仮想店舗)などの複数の加盟店が加盟しており、ユーザが各加盟店で商品等を購入した場合、サーバ1は、加盟店から商品等の購入額に応じた手数料を徴収し、当該手数料を原資としてトークンを付与する。なお、各加盟店から徴収する手数料率は加盟店DB142で規定されている。サーバ1は、購入額に手数料率を乗算して手数料を算出し、算出した手数料の支払いを加盟店に要求する。サーバ1は、加盟店から支払われる手数料を原資にトークンバックを実施する。
この場合にサーバ1は、加盟店から支払われる手数料に基づき、取引所サーバ3に対し、トークンを購入する旨の購買要求(いわゆるオファー)を出力し、トークンを購入する。すなわちサーバ1は、加盟店からの手数料を原資として、仮想通貨の取引市場からトークンを調達する。
サーバ1はまず、トークンの時価(トークンを法定通貨に換算した場合の単位数量当たりの価格)を示す時価情報を取引所サーバ3から取得する。すなわち、サーバ1は、取引市場(取引所等)におけるトークンの市場価格を示すデータを取引所サーバ3から取得する。なお、取引所サーバ3ではなく、仮想通貨の時価情報を公開している外部サイトからトークンの時価情報は取得してもよい。
サーバ1は、時価情報を参照して、加盟店からの手数料で購入可能なトークンの数量を算出する。そしてサーバ1は、算出した数量のトークンを現在の時価で購入する旨の購買要求を取引所サーバ3に出力する。サーバ1は、取引所サーバ3を介してトークンの保有者からトークンを購入する。サーバ1は、購入したトークンをユーザへの付与に充てる。
なお、ユーザが商品等を購入して加盟店からの手数料の支払い(入金)が完了するまでにタイムラグが存在するため、実際には、ユーザへトークンを付与した後に、購買要求を出力して市場からトークンを調達(補充)することになる。なお、トークンの調達が完了後にユーザへのトークン付与を行ってもよいことは勿論である。
また、本実施の形態では取引所サーバ3(取引所)からトークンを調達するものとするが、例えばサーバ1は、トークンの発行元である発行サーバ5からトークンを調達(購入)してもよい。
上述の如く、サーバ1は、ユーザが加盟店で商品等を購入した場合に、加盟店からの手数料を原資としてトークンを市場から調達する。これにより、市場におけるトークンの需要を強制的に高める結果になる。
また、サーバ1は、トークンを付与する場合に、ユーザによるトークンの保有状況を示す保有情報を取得し、取得した保有情報に応じてトークンを付与する。保有情報は、トークンの保有量、保有期間などを示すデータである。例えばサーバ1は、付与履歴DB146に記憶されているトークンの付与履歴を参照して、ユーザが保有するトークンの保有量、保有期間などのデータを取得する。あるいはサーバ1は、ユーザDB141に記憶されているウォレット情報に基づき、ブロックチェーンからユーザの現在の保有情報を取得してもよい。サーバ1は、取得した保有情報に基づいてトークンの付与を行う。
例えばサーバ1は、ユーザが保有するトークンの保有量が所定数以上であるか否かを判定し、所定数以上のトークンを保有していると判定した場合、トークンを付与する。判定基準とするトークンの数量は特に限定されないが、例えばサーバ1は、ユーザが1トークン以上保有するか否かを判定する。このように、サーバ1は、所定数以上のトークンを保有しているユーザを対象としてトークンバックを実施する。これにより、トークン自体を一種の会員権として機能させ、所定数以上のトークンを保有しておくインセンティブをユーザに与える。
なお、判定基準とするトークンの保有量を0とし、全てのユーザに対してトークンバックを実施してもよい。
さらにサーバ1は、ユーザによるトークンの保有情報に基づいて重み付けを行い、ユーザに付与するトークンの数量を変動させる。例えばサーバ1は、ユーザによるトークンの保有量、及び保有期間に応じて付与量を変動させる。
例えばサーバ1は、保有量が多いほど、ユーザに付与するトークンの数量を増加させる。また、サーバ1は、保有期間が長いほど、ユーザに付与するトークンの数量を増加させる。これにより、トークンをより多く、より長く保有しておくようにユーザに促す。
上記の処理により、トークンを保有し続けるインセンティブをユーザに与える。これにより、ユーザはトークンを消費せず、保有し続けることが期待できる。この状態で、ユーザが加盟店で商品等を購入すれば購入するほど、上述のトークンの調達によって市場に流通するトークンの流通量が減少し、相対的にユーザが保有する既存のトークンの資産価値(市場価格)が上昇する。これにより、購入行為自体がユーザの資産価値形成に資する。
上述の如く、本システムでは一般的なキャッシュバックサービスと同様にトークンの付与(トークンバック)を行うものの、付与したトークンを消費させずに、保有し続けるように促す。これにより、トークンの価格上昇を期待することができ、トークンバックによる直接的な価値の提供だけでなく、間接的な価値(価格上昇による資産価値の形成)を提供することができる。
なお、トークンの流通量を更に減少させるため、取引市場(取引所等)においてユーザが有償でトークンを入手した場合は、商品等の購入によって付与するトークンの数量を増加させる、あるいはトークン付与の対象とする商品等の種類を増やすなどすると好適である。すなわち、サーバ1は、トークンバック(商品等の購入によるトークン付与)以外の方法でトークンを取得したユーザに対し、トークンの付与量を増加、あるいは付与対象とする商品等の種類を増加させる。これにより、ユーザによるトークンの購入を促し、市場での流通量を更に減少させることができる。
図6は、トップ画面の一例を示す説明図である。以下では端末2での操作例を説明しながら、本システムの具体的な処理内容を説明する。
上述の如く、端末2には本システムに係るアプリケーションプログラムがインストールされており、当該アプリケーションプログラムを実行して以下の処理を行う。なお、Webブラウザ等のAPI(Application Programmable Interface)上で画面表示、操作を行ってもよい。図6では、アプリケーションのトップ画面を図示している。
上述の如く、端末2には本システムに係るアプリケーションプログラムがインストールされており、当該アプリケーションプログラムを実行して以下の処理を行う。なお、Webブラウザ等のAPI(Application Programmable Interface)上で画面表示、操作を行ってもよい。図6では、アプリケーションのトップ画面を図示している。
トップ画面は、ユーザが保有しているトークンの保有量を表示する画面である。図6に図示するように、端末2は、ユーザが現在保有しているトークンの保有量と、当該トークンをユーザの国籍に対応する法定通貨に換算した場合の法定通貨相当額とをトップ画面に表示する。
また、端末2は、左スワイプアイコン61、右スワイプアイコン62、及びカメラアイコン63をトップ画面に表示する。左スワイプアイコン61は、後述する加盟店の一覧画面(図7参照)に遷移すべく、左スワイプ(画面を左方向になぞる操作)の操作入力を促すアイコンである。右スワイプアイコン62は、後述する取引所画面(図10参照)に遷移すべく、右スワイプ(画面を右方向になぞる操作)の操作入力を促すアイコンである。カメラアイコン63は、後述する加盟店(実店舗)のレシートの撮像モードに遷移するためのアイコンである。
なお、本実施の形態では「スワイプ」によってトップ画面から他の画面に遷移することとするが、当該操作は画面をなぞる操作であればよく、例えばフリック、ドラッグ等と呼ばれる操作であってもよい。
図7は、左スワイプ操作時の画面遷移例を示す説明図である。左スワイプアイコン61に従って、トップ画面を左方向(第1方向)になぞるスワイプ操作を受け付けた場合、端末2は、図7の中央に示す一覧画面(第2画面)に遷移する。一覧画面は、本システムに加盟する複数の加盟店を一覧で示す表示画面である。図7に示すように、一覧画面には、商取引サービスを提供するECサイト(仮想店舗)の加盟店(第1加盟店)と、実店舗の加盟店(第2加盟店)とが一覧で表示される。
端末2は一覧画面において、各ECサイトに対応してリンクボタン71、71、71…を表示する。リンクボタン71への操作入力を受け付けた場合、端末2は、操作されたリンクボタン71に対応するECサイト(ECサーバ4)にアクセスする。なお、アクセス先はECサイトのホーム画面などであってもよく、あるいはリンクボタン71から個々の商品の画面に直接遷移させてもよい。
端末2は、ユーザからの操作入力に従い、アクセスしたECサイトにおいて商品等の購入申込を行う。ユーザがECサイトにて商品等を購入した場合、サーバ1は、ECサーバ4から、購入された商品等を関する購入情報を取得する。購入情報は、購入された商品等、購入額、購入日時などを示すデータである。サーバ1は、取得した購入情報を購入履歴DB144に記憶する。
なお、本実施の形態ではECサーバ4から購入情報を取得するものとするが、サーバ1は、端末2から直接的にECサイトでの購入情報を取得してもよい。あるいはサーバ1は、ASP(Affiliate Service Provider)などを経由して購入情報を取得してもよい。サーバ1は、図7の一覧画面を経由して端末2から直接又は間接的に購入情報を取得可能であればよく、その取得経路は特に問わない。
また、端末2は一覧画面において、実店舗である各加盟店に対応してスキャンボタン72、72、72…を表示する。一覧画面でスキャンボタン72への操作入力を受け付けた場合、又はトップ画面でカメラアイコン63への操作入力を受け付けた場合、端末2は撮像部26を起動し、実店舗で購入した商品等に関する情報(購入情報)を記述した媒体を撮像するための撮像モードに遷移する。
例えば端末2は、実店舗においてユーザに配布されるレシートを撮像するための撮像モードに遷移する。端末2は、ユーザからの操作入力に従ってレシートを撮像し、撮像画像に対する文字認識を行って、購入された商品等、購入額、購入日時などの購入情報を抽出する。端末2は、抽出した購入情報をサーバ1に送信する。
なお、本実施の形態ではレシートを読み取るものとして説明するが、対象とする媒体はレシートに限定されず、例えばQRコード(登録商標)等のコード情報であってもよい。すなわち、端末2は所定の媒体を撮像して購入情報を抽出可能であればよく、その対象はテキストが印刷された紙媒体に限定されない。
また、本実施の形態では、実店舗の加盟店における購入情報を端末2から取得するものとするが、例えばサーバ1は、実店舗のPOS(Point of Sales)システムから購入情報を取得するなどしてもよい。
端末2又はECサーバ4から購入情報を取得した場合、サーバ1は、上述の如く、商品等の購入額に応じた手数料の支払いを加盟店に要求する。サーバ1は、加盟店から支払われる手数料に基づき、取引所サーバ3にトークンの購買要求を出力し、トークンを購入する。
また、サーバ1は、商品等の購入額に応じた数量のトークンをユーザに付与する。例えばサーバ1は、トークンの時価情報を取引所サーバ3から取得し、購入額に応じて定めた手数料を、現在の時価に従ってトークンの数量に換算する。サーバ1は、換算した数量のトークンをユーザに付与する。
この場合にサーバ1は、上述の如く、ユーザによるトークンの保有情報を取得し、取得した保有情報を参照して付与するトークンの数量を決定する。具体的には、サーバ1は、ユーザによるトークンの保有量及び保有期間に応じて重み付けを行い、トークンの付与量を決定する。
なお、上記のトークン付与に係る処理を行う場合に、トークンが発行上限に到達し、ユーザにトークンを付与できない場合も考えられる。なお、「発行上限に到達」とは、現に発行量の上限値に到達した場合だけでなく、発行量が上限値に近い場合も含み得る。発行上限に到達し、かつ、取引所サーバ3からトークンの購入(調達)が困難な場合、サーバ1は、本システムに係るトークンに代えて、他の仮想通貨、又は法定通貨をユーザに付与する。これにより、発行上限に達する事態にも対応することができる。
発行上限に到達しない場合、又は取引所サーバ3からトークンを購入可能である場合、サーバ1は、上記で決定した数量のトークンをユーザに付与する。この場合に、サーバ1は、付与予定のトークンの一部を所定の寄付先(外部)に寄付させると共に、トークンを寄付した旨をSNSに投稿することを条件に、トークンの付与を行う。
図8は、付与予定のトークンに関する通知画面例を示す説明図である。図7で説明したECサイトでの購入申込、又はレシートの読取が完了後、端末2はサーバ1からの通知を受け、図8の画面(第4画面)に遷移する。当該画面は、ユーザに付与される予定のトークンの数量を表示すると共に、トークンの寄付、及びSNSへの投稿を促す表示画面である。
図8に示すように、端末2は、商品等を購入した加盟店の名称と、当該加盟店での商品等の購入によって付与されるトークンの数量、及び付与されるトークンを法定通貨に換算した金額とを画面上部に表示する。サーバ1は、これらの情報を端末2に通知し、図8の画面に表示させる。
さらに端末2は、付与予定のトークンの一部を寄付し、寄付した旨をSNSに投稿すべき旨を表示する。例えば図8に示すように、端末2は、寄付先DB143に登録(記憶)されている寄付先の画像を表示すると共に、寄付及び投稿を行うべき旨のテキストを画像下部に表示する。また、端末2は、投稿先とするSNSを選択するためのトグルスイッチ81を表示し、投稿する一又は複数のSNSを選択させる。
トグルスイッチ81による選択が完了後、端末2は不図示の画面に遷移し、SNSに投稿するコメント(テキスト)の入力をユーザから受け付ける。そして端末2は、ユーザ自身のSNSのアカウントで、ユーザが入力したテキストのほか、図8で図示した寄付先の画像を含む投稿情報をSNS上に出力する。
サーバ1はSNSのAPIを呼び出して、投稿情報が出力されたか否か、すなわちSNSへの投稿が完了したか否かを判定する。投稿が完了した場合、サーバ1は、端末2からSNSに出力された投稿情報を、投稿日時と対応付けて投稿履歴DB145に記憶する。また、サーバ1は、ユーザへのトークンの付与を行う。具体的には、サーバ1は、ユーザのウォレットへトークンを送金するためのトランザクションを生成し、付与履歴DB146に登録(記憶)する。この場合にサーバ1は、トランザクションのステータスを「承認待ち」として登録する。その後、サーバ1は、手数料を支払う加盟店(ECサーバ4等)からトークン付与の承認を受け付ける。トークン付与の承認を受け付けた場合、サーバ1はステータスを「承認」に更新する。ステータスが「承認」に更新された場合、サーバ1は端末2からの要求に応じてトランザクションをブロックチェーンに出力し、寄付分を除くトークンをユーザのウォレットへ送金する。
また、サーバ1は、ステータスを「承認」に更新後の任意のタイミングで、寄付分のトークンを寄付先に送金する。なお、寄付はトークンではなく、現金(法定通貨)等で行ってもよい。
なお、トークンの寄付先、及び寄付するトークンの数量(寄付額)は、ユーザが任意に指定可能としてもよいが、サーバ1が自動的に決定してもよい。例えばサーバ1は、ユーザによる商品等の購入履歴に基づいてユーザの傾向を分析し、寄付先及び寄付量を決定する。例えばサーバ1は、商品等と寄付先及び寄付量とを予め関連付けておき、ユーザが購入した商品等に応じて、コンテンツベースで寄付先及び寄付量を決定する。また、例えばサーバ1は、対象のユーザの購入履歴と他のユーザの購入履歴とを比較し、協調フィルタリングを用いて、類似する他のユーザが過去に行った寄付と同じになるように寄付先及び寄付量を決定する。
また、サーバ1は、一度の寄付で複数の寄付先にトークンを分配して送金するようにしてもよい。この場合の寄付先及び寄付量の配分についても上記と同様に、ユーザが任意に指定可能としてもよく、サーバ1が購入履歴等に基づいて自動的に決定するようにしてもよい。
なお、上記ではトークンの寄付及びSNSへの投稿をトークン付与の条件としたが、寄付及び投稿は必須の要件ではなく、寄付及び投稿をせずともトークンを付与するように構成してもよい。
また、上記では加盟店からの承認を待ってユーザにトークンを付与するものとしたが、加盟店からの承認を不要としてトークンを付与してもよい。
図9は、トークン付与後のトップ画面を示す説明図である。投稿が完了した場合、端末2は、図6でも例示したトップ画面に戻る。この場合、端末2はトップ画面を更新し、付与後のトークンの保有量を表示する。すなわち、端末2は、上記で付与されたトークンの数量を従前の保有量に加算し、加算後の保有量に更新して表示する。これにより、ユーザは商品等の購入によりトークンバックを受けたことをすぐに確認することができる。
なお、この場合に、例えば端末2は、保有量が増えたことをユーザが直感的に把握可能なように、表示色を変更するなどして、トップ画面に表示する保有量を、図6で図示した付与前の保有量とは異なる態様で表示するようにすると好適である。なお、図9では便宜上、表示色が変更されている様子を太字で図示している。
図10は、右スワイプ操作時の画面遷移例を示す説明図である。トップ画面において、右スワイプアイコン62に従って左から右方向(第2方向)になぞるスワイプ操作を受け付けた場合、端末2は、図10に示すリンク画面(第3画面)に表示する。リンク画面は、トークンを売買可能な複数の取引所を一覧で示す画面であり、各取引所のサイトにアクセスするためのリンクページである。端末2はリンク画面において、何れかの取引所を選択する選択入力を受け付け、選択された取引所のサイトにアクセスする。端末2は、アクセスした取引所のサイト(不図示)において、法定通貨、又は他の仮想通貨にトークンを換金することができる。また、端末2は、取引所においてトークンの追加購入も行うことができる。
なお、図10の例では取引所のサイトに遷移するのみであったが、本実施の形態はこれに限定されるものではない。例えば端末2は、図10の画面でトークンの送金先とする取引所のアカウント、送金するトークンの数量等を指定する指定入力を受け付け、指定されたアカウント(ウォレット)にトークンを送金可能としてもよい。これにより、ユーザは簡易な操作でトークンを移動させることができる。
また、リンク画面において取引所の選択入力を受け付けた場合、端末2は所定のアラート表示を行い、トークンの換金を再考するようユーザに促してもよい。これにより、トークンの継続保有をユーザに促すことができる。
上述の如く、各ユーザは加盟店で商品等を購入することで、価格上昇が期待できるトークンを得ることができる。特に本実施の形態では、端末2での簡便な操作でトークンを得ることができる。
図11は、端末2が実行する処理手順の一例を示すフローチャートである。図11に基づき、端末2が実行する処理内容について説明する。
端末2の制御部21は、ユーザが現在保有するトークン(仮想通貨)の保有量を示すトップ画面(第1画面)を表示する(ステップS11)。制御部21は、トップ画面において、左方向(第1方向)になぞる左スワイプの操作入力を受け付けたか否かを判定する(ステップS12)。左スワイプの操作入力を受け付けていないと判定した場合(S12:NO)、制御部21は、カメラアイコン63への操作入力を受け付けたか否かを判定する(ステップS13)。カメラアイコン63への操作入力を受け付けていないと判定した場合(S13:NO)、制御部21は、右方向(第2方向)になぞる右スワイプの操作入力を受け付けたか否かを判定する(ステップS14)。
端末2の制御部21は、ユーザが現在保有するトークン(仮想通貨)の保有量を示すトップ画面(第1画面)を表示する(ステップS11)。制御部21は、トップ画面において、左方向(第1方向)になぞる左スワイプの操作入力を受け付けたか否かを判定する(ステップS12)。左スワイプの操作入力を受け付けていないと判定した場合(S12:NO)、制御部21は、カメラアイコン63への操作入力を受け付けたか否かを判定する(ステップS13)。カメラアイコン63への操作入力を受け付けていないと判定した場合(S13:NO)、制御部21は、右方向(第2方向)になぞる右スワイプの操作入力を受け付けたか否かを判定する(ステップS14)。
左スワイプの操作入力を受け付けたと判定した場合(S12:YES)、制御部21は、加盟店を一覧で示す一覧画面(第2画面)を表示する(ステップS15)。具体的には、制御部21は、ECサイト(仮想店舗)の加盟店(第1加盟店)と、実店舗の加盟店(第2加盟店)とをそれぞれ一又は複数表示する。制御部21は、一覧画面で表示した加盟店から何れかを選択する選択入力を受け付ける(ステップS16)。
制御部21は、ステップS16において、ECサイトが選択されたか否かを判定する(ステップS17)。ECサイトが選択されたと判定した場合(S17:YES)、制御部21は、選択されたECサイトにアクセスする(ステップS18)。制御部21は、ユーザからの操作入力に基づき、ECサイトにおける商品等の購入申込に係る処理を行う(ステップS19)。ユーザがECサイトで商品等を購入した場合、サーバ1は、ECサーバ4から、ユーザが購入した商品等を関する購入情報を取得する。
ステップS13でYES、又はステップS17でNOの場合、制御部21は、ユーザが実店舗での購入情報が記述されたレシート(媒体)を撮像するための撮像モードに遷移し、ユーザからの操作入力に応じてレシートの撮像を行う(ステップS20)。制御部21は、撮像画像から購入情報を抽出し、サーバ1に送信する(ステップS21)。
ステップS19又はS21の処理を実行後、制御部21は、付与予定のトークンの数量に関する通知をサーバ1から取得し、トークンの寄付、及びSNSへの投稿を行うための通知画面(第4画面)に遷移して、ユーザからの操作入力に基づき、SNS上に投稿情報を出力する(ステップS22)。ステップS22で表示する画面は、トークンの寄付、及び寄付した旨をSNSに投稿することをユーザに促す画面であり、例えば付与予定のトークンの数量のほかに、サーバ1が決定した寄付先の情報(画像など)を表示する。制御部21は、ユーザから任意のテキストの入力を受け付けて、入力されたテキスト、寄付先の画像などを含む投稿情報をSNS上に出力する。
サーバ1は、ユーザからの投稿情報がSNSに出力された場合に、購入額等に応じた数量のトークンを付与する。また、サーバ1は、ユーザに付与するトークンの一部を寄付先に送金する。制御部21はトップ画面に遷移し、トップ画面に表示するトークンの保有量を、付与後のトークンの保有量に更新する(ステップS23)。
トップ画面において右スワイプの操作入力を受け付けたと判定した場合(S14:YES)、制御部21は、トークンを売買可能な取引所を一覧で示すリンク画面(第3画面)を表示する(ステップS24)。制御部21は、アクセスする取引所を選択する選択入力を受け付け、選択された取引所にアクセスする(ステップS25)。
ステップS23、S25の処理を実行後、又はステップS14でNOの場合、制御部21は、ユーザからの操作入力に従ってログアウトするか否かを判定する(ステップS26)。ログアウトしないと判定した場合(S26:NO)、制御部21は処理をステップS12に戻す。ログアウトすると判定した場合(S26:YES)、制御部21は一連の処理を終了する。
図12は、サーバ1が実行する処理手順の一例を示すフローチャートである。図12に基づき、サーバ1が実行する処理内容について説明する。
サーバ1の制御部11は、端末2又はECサーバ4から、ユーザが購入した商品等を関する購入情報を取得する(ステップS41)。制御部11は加盟店DB142から加盟店の手数料率を読み出し、商品等の購入額に応じた手数料を算出して、手数料の支払いを加盟店に要求する(ステップS42)。
サーバ1の制御部11は、端末2又はECサーバ4から、ユーザが購入した商品等を関する購入情報を取得する(ステップS41)。制御部11は加盟店DB142から加盟店の手数料率を読み出し、商品等の購入額に応じた手数料を算出して、手数料の支払いを加盟店に要求する(ステップS42)。
制御部11は、取引市場におけるトークン(仮想通貨)の時価情報、及びユーザによるトークンの保有情報を取得する(ステップS43)。時価情報は、トークンの時価(法定通貨換算額)を示すデータであり、仮想通貨の取引市場(取引所等)における市場価格を示すデータである。保有情報は、ユーザによるトークンの保有状況を示すデータであり、例えばトークンの保有量、保有期間などを示すデータである。
制御部11は、購入情報、時価情報、保有情報などに基づき、ユーザに付与するトークンの数量を決定する(ステップS44)。具体的には、制御部11は、商品等の購入額に加盟店の手数料率を乗算した手数料(法定通貨額)を、トークンの時価に応じてトークンの数量に換算する。また、制御部11はユーザの保有情報に応じて重み付けを行い、保有量が多く、保有期間が長いほど多くなるように付与量を決定する。
また、制御部11は、ユーザに付与予定のトークンの内、一部のトークンを送金する寄付先を決定する(ステップS45)。例えば制御部11は、ユーザによる商品等の購入履歴などから寄付先を決定する。
制御部11は、発行サーバ5から現在のトークンの発行量に関する情報を取得し、トークンの発行上限に到達するか否かを判定する(ステップS46)。発行上限に到達すると判定した場合(S46:YES)、制御部11は、本システムのトークンとは異なる他の仮想通貨、又は法定通貨をユーザに付与し(ステップS47)、一連の処理を終了する。
発行上限に到達しないと判定した場合(S46:NO)、制御部11は、ステップS44で決定した付与予定のトークンの数量を端末2に通知する(ステップS48)。具体的には、制御部11は、付与予定のトークンの数量を端末2に通知すると共に、ステップS45で決定した寄付先の情報を通知する。
制御部11は、ユーザによるSNSへの投稿が完了したか否かを判定する(ステップS49)。投稿が完了していないと判定した場合(S49:NO)、制御部11は処理を待機する。投稿が完了したと判定した場合(S49:YES)、制御部11は、加盟店からトークン付与の承認を受け付けたか否かを判定する(ステップS50)。トークン付与の承認を受け付けていないと判定した場合(S50:NO)、制御部11は処理を待機する。
トークン付与の承認を受け付けたと判定した場合(S50:YES)、制御部11は、ステップS42で算出した手数料に基づくトークンの購買要求を取引所サーバ3に出力する(ステップS51)。また、制御部11は、寄付分を除くトークンをユーザに付与する(ステップS52)。また、制御部11は、ステップS45で決定した寄付先に対して寄付分のトークンを送金し(ステップS53)、一連の処理を終了する。
なお、本実施の形態では、加盟店から支払われる手数料に応じてユーザに付与するトークンの数量を定めたが、手数料の高低に関係なくユーザに付与するトークンの数量を定め、トークンバックを実施してもよい。
また、本実施の形態では取引所を通じてトークンの買い戻しを行うものとしたが、取引所を経由する構成は必須ではなく、サーバ1がトークン保有者から直接的にトークンを購入するようにしてもよい。
また、上記ではユーザによる商品等の購入情報に応じてトークンを付与するものとしたが、本実施の形態はこれに限定されるものではない。例えばサーバ1は、ユーザによるインターネット広告へのアクセス、特定のアプリケーションの利用など、商品等の購入以外のユーザの行動をトリガにトークンを付与してもよい。すなわち、商品等の購入はトークン付与の契機の一例であり、その他のユーザの行動に応じてトークンを付与してもよい。
以上より、本実施の形態1によれば、端末2はトップ画面での簡単なスワイプ操作により加盟店の一覧画面に遷移し、レシート読取などで購入情報を直接的に、あるいはECサーバ4経由で間接的にサーバ1に出力し、トークンの付与を受けて付与後の保有量をユーザに提示する。このように、簡便な操作でトークンバックを受けることができ、消費者(ユーザ)を適切に支援することができる
また、本実施の形態1によれば、トップ画面での簡単なスワイプ操作で取引所にアクセスし、トークンの売買も行うことができる。
また、本実施の形態1によれば、ECサイト(仮想店舗)及び実店舗の双方の加盟店に対応してトークンバックを受けることができる。
また、本実施の形態1によれば、トークンの寄付をトークンバックの条件とすることで、本システムを社会貢献策として実施することができる。
また、本実施の形態1によれば、SNSへの投稿をトークンバックの条件とすることで、本システムを一般消費者に周知することができる。
(実施の形態2)
本実施の形態では、ユーザの購入履歴等を学習する機械学習を行って推定モデル147を生成し、生成した推定モデル147を用いて、加盟店を利用するユーザの購入行動を推定する形態について述べる。なお、実施の形態1と重複する内容については同一の符号を付して説明を省略する。
本実施の形態では、ユーザの購入履歴等を学習する機械学習を行って推定モデル147を生成し、生成した推定モデル147を用いて、加盟店を利用するユーザの購入行動を推定する形態について述べる。なお、実施の形態1と重複する内容については同一の符号を付して説明を省略する。
図13は、推定モデル147に関する説明図である。本実施の形態においてサーバ1は、ユーザによる商品等の購入履歴のほかに、ユーザによるSNSへの投稿履歴、ユーザの個人情報などを学習する機械学習を行い、推定モデル147を生成する。そしてサーバ1は、生成した推定モデル147を用いてユーザの購入行動を推定し、推定結果に応じた情報をユーザに提示する。例えばサーバ1は、推定モデル147から出力された推定結果に基づき、図7で例示した一覧画面で表示する加盟店の表示順序を入れ替え、ユーザが利用する確率が高い加盟店を上位に表示させる。
なお、以下の説明ではECサイト(仮想店舗)について推定を行うものとして説明するが、推定モデル147での推定対象はECサイトだけでなく、実店舗の加盟店を含めてもよい。
推定モデル147は、深層学習により生成されるニューラルネットワークであり、例えばRNN(Recurrent Neural Network)である。推定モデル147は、データの入力を受け付ける入力層と、入力層に入力されたデータに基づく演算を行う中間層と、中間層での演算結果に基づいて出力用のデータを出力する出力層とを有する。
入力層は、各種データの入力を受け付ける複数のニューロンを有し、入力されたデータを中間層に受け渡す。中間層は、入力層から取得したデータに基づいて演算を行う複数のニューロンを有し、入力データの特徴量を抽出する演算処理を行う。例えば推定モデル147がRNNである場合、中間層は時系列的に並ぶ前後のニューロンの演算結果を用いて演算を行うことで、入力層の各ニューロンに入力されたデータ同士の相関を参酌しながら特徴量を抽出する。出力層は、中間層で抽出した特徴量に基づき、出力すべきデータの推定を行う。
なお、上記では推定モデル147の一例としてRNNを挙げたが、推定モデル147はその他のニューラルネットワークであってもよい。また、推定モデル147は深層学習に係る学習済みモデルに限定されず、例えば強化学習、決定木、ランダムフォレスト、SVM(Support Vector Machine)等のアルゴリズムに基づくモデルであってもよい。
本実施の形態においてサーバ1は、購入履歴DB144、投稿履歴DB145などに蓄積された情報を教師データとして用いて、各ユーザの購入履歴、投稿履歴、個人情報などに基づき、加盟店を利用するユーザの購入行動を推定する推定モデル147を生成する。
具体的には、サーバ1は、購入履歴等を入力として、ユーザに推奨すべきECサイト(加盟店)を出力とする推定モデル147を生成する。より詳細には、サーバ1は、本システムに加盟する複数のECサイトについて、ユーザに推奨すべきECサイトの優先順位を出力する推定モデル147を生成する。
サーバ1は、各ユーザの購入履歴(購入した商品等、購入額、購入日時などのデータ)のほかに、トークンバックの条件としてSNSに投稿した投稿情報の履歴(投稿したコメント、投稿日時などのデータ)、及びユーザの個人情報(年齢、性別、国籍などのデータ)を各データベースから読み出し、教師用の入力データとして推定モデル147に入力する。サーバ1は、各種データに基づいて推定モデル147での演算を行い、ユーザに推奨すべき加盟店、具体的には推奨すべき加盟店の優先順位(例えば各ECサイトそれぞれに対応する確率値)を推定する。
この場合に、例えばサーバ1は、各ユーザの購入履歴を参照して、各ECサイトでユーザが購入した商品等の購入額、及び各ECサイトで商品等を購入した購入頻度を評価関数として用い、学習を行う。例えばサーバ1は、各ECサイトについて、購入額及び購入頻度を乗算した値を計算し、乗算値が大きいほど優先順位が高くなるように、各ECサイトの優先順位の正解値を決定する。サーバ1は、入力データに基づいて推定された優先順位を、正解である優先順位と比較し、両者が近似するように、中間層で用いる各種パラメータ(重み等)を最適化する。これにより、サーバ1は、購入額及び購入頻度が高くなるECサイトを推定する推定モデル147を生成する。
上記の学習時に、サーバ1は購入額及び購入頻度に加えて、各ECサイト(加盟店)の手数料を評価関数に加えると好適である。具体的には、サーバ1は、購入額及び購入頻度に加えて、各ECサイトから支払われた手数料を乗算し、購入額、購入頻度、及び手数料の乗算値に応じて優先順位の正解値を決定する。これにより、本システムに支払う手数料が高いECサイトほど優先され、トークンバックに係るサービスを好適に維持することができる。
サーバ1は、上記で生成した推定モデル147に、各ユーザの購入履歴、投稿履歴、個人情報などのデータを入力し、個々のユーザに推奨すべきECサイトを推定する。そしてサーバ1は、推定したECサイトをユーザに提示する。
例えばサーバ1は、図7で例示した加盟店の一覧画面を端末2が表示する場合に、推定モデル147を用いて各ECサイトの優先順位を推定し、推定した優先順位に従って各ECサイトを表示する一覧画面を出力する。なお、例えばサーバ1はバッチ処理で優先順位の推定を行っておき、一覧画面を表示する際に推定済みの優先順位に従って出力を行うようにしてもよい。端末2は、サーバ1からの出力に従い、画面の上から順に、優先順位が高いECサイトを表示する。具体的には、実施の形態1と同様に、端末2は各ECサイトと、各ECサイトにアクセスするためのリンクボタン71(リンク情報)とを表示する。各ECサイトに対応するリンクボタン71への操作入力を受け付けた場合、端末2はECサイトにアクセスし、ユーザは商品等を購入することができる。
上記の処理により、優先順位が高いECサイト、つまりユーザがよく利用し、利用金額(購入額)も高いECサイトが提示される。そしてユーザは、リンクボタン71への操作によってECサイトに簡単にアクセスすることができ、ユーザの利便性を向上させることができる。
図14は、推定モデル147の生成処理の手順を示すフローチャートである。図14に基づき、機械学習によって推定モデル147を生成する処理の内容について説明する。
サーバ1の制御部11は、各ユーザの個人情報、商品等の購入履歴、SNSへの投稿履歴などの情報を教師データとして各データベースから読み出す(ステップS201)。購入履歴は、ユーザが購入した商品等(商品又はサービス)以外に、ユーザが商品等を購入した加盟店の加盟店IDを含む。
サーバ1の制御部11は、各ユーザの個人情報、商品等の購入履歴、SNSへの投稿履歴などの情報を教師データとして各データベースから読み出す(ステップS201)。購入履歴は、ユーザが購入した商品等(商品又はサービス)以外に、ユーザが商品等を購入した加盟店の加盟店IDを含む。
制御部11は教師データを用いて、購入履歴等のデータを入力した場合に、加盟店を利用するユーザの購入行動を出力する推定モデル147を生成する(ステップS202)。具体的には、制御部11は、購入履歴等を入力として、ユーザが利用すると推定される加盟店を出力とする推定モデル147を生成する。制御部11は、教師用の購入履歴、投稿履歴、個人情報等のデータを推定モデル147に入力し、ユーザが利用する加盟店を推定する。制御部11は、推定した加盟店と、購入額、購入頻度、手数料等に応じて推奨すべきものと定めた加盟店とを比較し、両者が近似するように中間層の各種パラメータを最適化し、推定モデル147を生成する。制御部11は一連の処理を終了する。
図15は、実施の形態2に係るトークンバックシステムが実行する処理手順の一例を示すフローチャートである。トップ画面において左スワイプの操作入力を受け付けた場合(S12:YES)、端末2は以下の処理を実行する。
端末2の制御部21は、加盟店の一覧画面の出力をサーバ1に要求する(ステップS221)。一覧画面の出力要求を受け付けた場合、サーバ1の制御部11は、対象とするユーザの商品等の購入履歴、SNSへの投稿履歴、個人情報などのデータを各データベースから読み出す(ステップS222)。
端末2の制御部21は、加盟店の一覧画面の出力をサーバ1に要求する(ステップS221)。一覧画面の出力要求を受け付けた場合、サーバ1の制御部11は、対象とするユーザの商品等の購入履歴、SNSへの投稿履歴、個人情報などのデータを各データベースから読み出す(ステップS222)。
制御部11は、読み出したデータを推定モデル147に入力し、対象のユーザの購入行動を推定する(ステップS223)。具体的には、制御部11は、ユーザが利用すると推定される加盟店(ECサイト)を出力として取得する。より詳細には、制御部11は、複数の加盟店について、ユーザに推奨すべき加盟店の優先順位を取得する。制御部11は、取得した優先順位に従って各加盟店を表示する一覧画面を端末2に出力する(ステップS224)。端末2の制御部21は、出力された一覧画面を表示し(ステップS225)、処理をステップS16に移行する。
また、上記ではECサイト(加盟店)へのリンクを提示するのみであったが、例えばサーバ1は、推定モデル147を用いてユーザが購入する確率が高い商品等を推定し、推定した商品等が掲載されているECサイト内のページへのリンクを提示(出力)してもよい。例えばサーバ1は、各ECサイトで提供する商品等と、各商品等が掲載されたECサイト内のページとを対応付けて加盟店DB142に記憶しておき、推定モデル147を用いて、ユーザに推奨すべき商品等の優先順位を推定する。サーバ1は、推定した優先順位に従って、各商品等の情報を一覧画面の上から順に表示させると共に、各商品等のページにアクセスするためのリンクボタン71(リンク情報)を表示させる。これにより、ユーザの利便性をさらに高めることができる。
以上より、本実施の形態2によれば、推定モデル147を用いて加盟店を利用するユーザの購入行動を推定し、推定結果に応じた情報をユーザ宛に出力することで、消費者(ユーザ)を好適に支援することができる。
また、本実施の形態2によれば、ユーザに推奨すべきECサイト(仮想店舗)を推定し、推定したECサイトにアクセスするためのリンク情報を出力する。これにより、ユーザの利便性を向上させることができる。
また、本実施の形態2によれば、ユーザに推奨すべきECサイトの優先順位を推定し、推定した優先順位に従って各ECサイトを提示することで、ユーザの利便性をより向上させることができる。
また、本実施の形態2によれば、購入額、購入頻度、及び手数料が最大化する加盟店を提示することで、より好適にユーザを支援することができる。
また、本実施の形態2によれば、購入履歴以外にSNSへの投稿履歴を入力に用いることで、加盟店におけるユーザの購入行動だけでなく、SNS上での言動(行動)も学習することができ、購入行動の推定精度を高めることができる。
(実施の形態3)
本実施の形態では、ユーザに付与したトークンについて、一定期間の買取保証を与える形態について説明する。
図16は、実施の形態3の概要を示す説明図である。図16に基づき、本実施の形態の概要を説明する。
本実施の形態では、ユーザに付与したトークンについて、一定期間の買取保証を与える形態について説明する。
図16は、実施の形態3の概要を示す説明図である。図16に基づき、本実施の形態の概要を説明する。
実施の形態1で、本システムに係るトークンは消費を目的とせずに、加盟店からの手数料に基づいてトークンを市場から調達し、また、ユーザの保有情報に応じてトークンの付与を行うことで、長期保有を促しつつトークンの需要を創出し、価値を高める旨を説明した。本実施の形態ではさらに、付与後のトークンについて、一定の買取保証期間にある場合は、規定の買取額(交換額)でトークンを買い戻す旨の買取保証をユーザに与える。これにより、トークンの長期保有をさらに促し、相対的にトークンの価値上昇を図る。
例えばサーバ1は、各ユーザの端末2から、付与済みのトークンについて、法定通貨への交換要求を受け付ける。具体的には、サーバ1は、交換するトークンの数量を指定する指定入力を受け付ける。なお、サーバ1はユーザの端末2ではなく、例えばユーザからの問合せを受けたオペレータから手動で交換要求の入力を受け付けるようにしてもよい。
交換要求を受け付けた場合、サーバ1は、ユーザに付与済みのトークンの付与時点を特定する。例えばサーバ1は、付与履歴DB146を参照して、加盟店から承認済みであり、かつ、過去に買取保証による交換が行われていないトークンのトランザクションを特定する。そしてサーバ1は、各トランザクションによるトークンの付与時点(例えば加盟店から承認を受け付けた時点)を特定する。サーバ1は、各トランザクションによるトークンの付与時点が現時点(交換要求を受け付けた時点)から一定期間内である否かを判定する。
例えばサーバ1は、一定期間内にあると判定したトークンのうち、付与時点が古いトークンから順に、ユーザが指定した数量のトークンを抽出する。サーバ1は、抽出したトークンを交換対象とする。なお、例えばサーバ1は、一定期間内にあると判定したトークンのトランザクションを一覧で端末2に出力し、交換対象とするトランザクションをユーザに選択させてもよい。
サーバ1は、トークンの時価情報を取得し、トークンの交換額(買取保証額)を算出する。例えばサーバ1は、トークンを付与した時点と同じ価格になるように、トークン付与時点の時価情報を取得し、付与時点の時価に従ってトークンを法定通貨に換算した金額を算出する。
なお、本実施の形態では、トークンの付与時点と同じ価格で買い取りを行うものとするが、交換額は付与時点の価格と同一でなくともよい。例えばサーバ1は、長期保有をさらに促すため、付与時点の価格未満の金額(例えば90%の金額)を交換額としてもよい。また、トークンの買い取りに際して取引所での手数料などが発生するため、その手数料を減算した金額を交換額としてもよい。
サーバ1は交換額を端末2に通知し、当該交換額での交換を承認するか否か、端末2から承認の入力を受け付ける。承認された場合、サーバ1は、トークンの送金先とするウォレットアドレスを通知し、指定したトークンの送金をユーザに促す。サーバ1は、ユーザからのトークンの送金を確認後、交換額に相当する法定通貨の送金に係る処理(例えば金融機関への送金依頼)を行う。これにより、トークンの買取を完了する。
なお、上記で交換額を端末2に通知する場合に、単に買取保証による交換額を提示するだけでなく、現時点のトークンの市場価格、すなわち取引市場で交換した場合の交換額(第2交換額)を算出し、両者の差分をユーザに提示すると好適である。
すなわち、サーバ1は、現時点(交換要求を受け付けた時点)のトークンの時価情報を取引所サーバ3から取得し、現時点の時価に従って、トークンを法定通貨に換算した交換額を算出する。図16の例に則して説明すれば、付与時点が4月1日である場合に、4月1日の時価で算出した交換額とは別に、交換要求を受け付けた現時点(例えば満期の10月1日時点)の時価で換算した金額を算出する。例えばサーバ1は、両者の金額を端末2に通知すると共に、両者の差額(差分)を通知し、ユーザに提示する。これによりユーザは、買取保証に基づく交換(買取)を行うべきか、好適に判断することができる。
図17は、実施の形態3に係るトークンバックシステムが実行する処理手順の一例を示すフローチャートである。
サーバ1の制御部11は、端末2からトークンの交換要求を受け付ける(ステップS301)。交換要求を受け付けた場合、制御部11は、ユーザに付与済みのトークンの付与時点を特定する(ステップS302)。
サーバ1の制御部11は、端末2からトークンの交換要求を受け付ける(ステップS301)。交換要求を受け付けた場合、制御部11は、ユーザに付与済みのトークンの付与時点を特定する(ステップS302)。
制御部11は、ステップS301で交換要求を受け付けた時点が、ステップS302で特定したトークンの付与時点から一定期間内であるか否かを判定する(ステップS303)。一定期間内でないと判定した場合(S303:NO)、制御部11は一連の処理を終了する。一定期間内であると判定した場合(S303:YES)、制御部11は、トークンの時価情報を取得する(ステップS304)。例えば制御部11は、トークンの付与時点と、現時点(交換要求を受け付けた時点)の時価情報を取得する。
制御部11は、取得した時価情報に基づき、付与時点の時価に従ったトークンの交換額を算出する(ステップS305)。また、制御部11は、現時点の時価に従ってトークンを法定通貨に換算した交換額(第2交換額)を算出する(ステップS306)。制御部11は、トークンの交換の承認を要求する(ステップS307)。例えば制御部11は、付与時点の時価に基づくトークンの交換額を出力すると共に、現時点の時価に基づく交換額を出力し、両者の差分を提示する。制御部11は、両者の金額を提示した後、最終的な承認を受け付ける。
制御部11は、トークンの交換が承認されたか否かを判定する(ステップS308)。承認されなかったと判定した場合(S308:NO)、制御部11は一連の処理を終了する。承認されたと判定した場合(S308:YES)、制御部11はトークンの交換に係る処理を行い(ステップS309)、一連の処理を終了する。
なお、上記では買取保証期間が一定期間であり、買取保証額(交換額)も時価に応じた規定の金額であるものとして説明したが、例えばサーバ1は、ユーザによるトークンの保有情報に基づき、保証期間及び保証額を変動させてもよい。例えばサーバ1は、トークンをユーザに付与する場合に、ユーザによるトークンの保有量及び保有期間に応じて、保証期間及び保証額を設定し、設定内容を付与履歴DB146に記憶しておく。例えばサーバ1は、保有量が多く、かつ、保有期間が長いほど、保証期間を長く、かつ、保証額を多く設定する。これにより、トークンの長期保有をさらに促すことができる。交換要求を受け付けた場合、サーバ1は付与履歴DB146に記憶された設定内容を参照して、設定された買取保証期間内である場合、設定された買取保証額での交換を行う。
また、上記では法定通貨との交換を行うものとして説明したが、例えば電子ポイント、又は物品など、法定通貨以外の代替物と交換を行ってもよい。すなわち、ユーザに付与したトークンを、付与時点の時価に応じた交換額と等価な代替物との交換が可能であればよく、その代替物は法定通貨に限定されない。
また、上記ではトークンの買い取りに一定の保証期間を設けたが、保証期間を設けずともよい。すなわち、トークンの付与時点と交換要求を受け付けた時点との間の経過時間に関わらず買取保証を実施してもよい。
また、上記では付与時点の時価に応じて交換額を定めたが、付与時点の時価に関わらず一定の交換額で交換を行ってもよい。
以上より、本実施の形態3によれば、トークンの長期保有を促して更なる価値上昇を図ることができる。
また、本実施の形態3によれば、買取保証額(交換額)と現時点での価格との差分を提示することで、交換を行うべきか、ユーザは好適に判断することができる。
また、本実施の形態3によれば、保有量、保有期間等の保有情報に応じて買取保証期間及び買取額を設定することで、トークンの長期保有をより好適に促すことができる。
(変形例)
実施の形態3では、ユーザに付与した仮想通貨の買取保証について説明した。以下では、その買取保証額を端末2に表示する際の表示例について説明する。
実施の形態3では、ユーザに付与した仮想通貨の買取保証について説明した。以下では、その買取保証額を端末2に表示する際の表示例について説明する。
図18は、変形例に係るトップ画面の一例を示す説明図である。図18のトップ画面は、グラフ181を含む。グラフ181は、過去の各時点でユーザが保有していたトークンを、付与時点の時価に応じて換算した買取保証額(交換額)と、各時点の時価に応じて換算した交換額(第2交換額)とを時系列で示すグラフである。例えば端末2は、過去の各時点でユーザが保有していたトークンの数量を縦棒で表示し、付与時点の時価に応じて換算した買取保証額と、各時点の時価に応じて換算した交換額とを折れ線で表示する。なお、図18のグラフ181では、買取保証額を太線で、各時点の時価に応じた交換額を細線で図示している。太線は、買取保証を利用して交換した場合の金額を表す。細線は、買取保証を利用せず、一般の取引市場において交換した場合の金額を表す。
端末2がトップ画面を表示する際に、サーバ1は、過去の各時点における両者の交換額を算出し、グラフ181を出力する。買取保証額を算出する場合、サーバ1は、過去の各時点について、その時点以前に付与したトークンの数量に付与時点の時価を乗算し、乗算値を積算して買取保証額を算出する。また、買取保証を利用しない場合の交換額(第2交換額)を算出する場合、サーバ1は、過去の各時点について、その時点でユーザが保有していたトークンの保有量に対し、その時点の仮想通貨の時価を乗算し、交換額を算出する。サーバ1は、過去の各時点(図18では直近一週間の各日付)について両者の交換額を算出し、グラフ181として端末2に表示させる。グラフ181により、ユーザはトークンの買取保証が保たれていることを相場価格と比較して容易に確認することができる。
図19は、付与履歴画面の一例を示す説明図である。付与履歴画面は、トークンの付与履歴を表示する表示画面である。他の画面から所定のメニュー操作を受け付けた場合、端末2は図19の付与履歴画面に遷移する。
付与履歴画面は、付与トークン表示欄191、付与履歴表示欄192を含む。付与トークン表示欄191は、現在ユーザが保有するトークンの保有量、及び現在の時価を表示する表示欄である。なお、「判定中」は加盟店からの承認待ちの状態を表す。
付与履歴表示欄192は、ユーザに付与したトークンの数量や付与時点の時価などを、トークン付与のトリガとなった商品等の購入情報と関連付けて表示する表示欄である。端末2は、トークン付与のトリガとなった購入情報毎に、商品等の購入額に応じて付与されたトークンの数量と、買取が保証されている付与時点の時価とを付与履歴表示欄192に一覧表示する。
具体的には、端末2は、商品等を購入した加盟店の名称、購入日(利用日)等と対応付けて、付与日時(図19では「確定日」)、付与されたトークンの数量(「還元コイン」)、付与時点の時価(「換算レート」)等を表示する。なお、「ステータス」は承認済みであるかどうかを示す。ユーザは付与履歴表示欄192を参照して、商品等の購入履歴と関連付けた形で、いつ付与されたトークンにどの程度の買取保証が付いているかを容易に把握することができる。
上述の画面表示以外は実施の形態1~3と共通するため、本変形例ではフローチャートその他の詳細な説明は省略する。
今回開示された実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、請求の範囲によって示され、請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。
1 サーバ(情報処理装置)
11 制御部
12 主記憶部
13 通信部
14 補助記憶部
P1 プログラム
141 ユーザDB
142 加盟店DB
143 寄付先DB
144 購入履歴DB
145 投稿履歴DB
146 付与履歴DB
2 端末
21 制御部
22 主記憶部
23 通信部
24 表示部
25 入力部
26 撮像部
27 補助記憶部
P2 プログラム
3 取引所サーバ
4 ECサーバ
5 発行サーバ
11 制御部
12 主記憶部
13 通信部
14 補助記憶部
P1 プログラム
141 ユーザDB
142 加盟店DB
143 寄付先DB
144 購入履歴DB
145 投稿履歴DB
146 付与履歴DB
2 端末
21 制御部
22 主記憶部
23 通信部
24 表示部
25 入力部
26 撮像部
27 補助記憶部
P2 プログラム
3 取引所サーバ
4 ECサーバ
5 発行サーバ
Claims (9)
- ユーザが購入した商品又はサービスに関する購入情報を取得する取得部と、
前記購入情報に基づき、前記ユーザに付与する仮想通貨の数量を決定する決定部と、
決定した数量の前記仮想通貨を前記ユーザに付与する付与部と、
前記ユーザから、前記仮想通貨を代替物に交換する交換要求を受け付ける受付部と、
前記交換要求を受け付けた場合、前記仮想通貨を付与した時点から一定期間内であるか否かを判定する判定部と、
一定期間内であると判定した場合、前記仮想通貨の交換に係る処理を行う交換処理部と
を備えることを特徴とする情報処理装置。 - 前記取得部は、前記仮想通貨の時価情報を取得し、
前記交換要求を受け付けた場合、前記仮想通貨を付与した時点の時価に基づき、前記仮想通貨の交換額を算出する算出部を備え、
前記交換処理部は、前記交換額と等価な前記代替物との交換に係る処理を行う
ことを特徴とする請求項1に記載の情報処理装置。 - 前記算出部は、前記仮想通貨の付与時点の時価に基づく交換額と、前記交換要求を受け付けた時点の時価に基づく第2交換額とを算出し、
前記交換額及び第2交換額の差分を前記ユーザに通知する通知部と
を備えることを特徴とする請求項2に記載の情報処理装置。 - 前記算出部は、過去の各時点で前記ユーザが保有していた前記仮想通貨を、前記仮想通貨の付与時点の時価に応じて換算した交換額と、前記各時点の時価に応じて換算した第2交換額とを算出し、
前記各時点における前記交換額及び第2交換額を時系列で示すグラフを出力する出力部を備える
ことを特徴とする請求項2に記載の情報処理装置。 - 前記購入情報と関連付けて、該購入情報に基づいて付与した前記仮想通貨の数量と、付与時点の前記仮想通貨の時価とを一覧で示す付与履歴を出力する第2出力部を備える
ことを特徴とする請求項2~4のいずれか1項に記載の情報処理装置。 - 前記取得部は、前記ユーザによる前記仮想通貨の保有量及び保有期間を示す保有情報を取得し、
前記保有情報に基づき、前記交換要求を受け付ける期間、及び前記仮想通貨の交換額を設定する設定部を備え、
前記判定部は、設定された期間に基づいて判定を行い、
前記交換処理部は、設定された交換額と等価な前記代替物との交換に係る処理を行う
ことを特徴とする請求項1~5のいずれか1項に記載の情報処理装置。 - 前記取得部は、前記仮想通貨の発行量に関する情報を取得し、
前記ユーザに前記仮想通貨を付与する場合に、前記仮想通貨の発行上限に到達するか否かを判定する第2判定部と
を備え、
前記発行上限に到達すると判定した場合、前記付与部は、前記決定部が決定した数量の前記仮想通貨に相当する他の仮想通貨、又は法定通貨を前記ユーザに付与する
ことを特徴とする請求項1~6のいずれか1項に記載の情報処理装置。 - ユーザが購入した商品又はサービスに関する購入情報を取得し、
前記購入情報に基づき、前記ユーザに付与する仮想通貨の数量を決定し、
決定した数量の前記仮想通貨を前記ユーザに付与し、
前記ユーザから、前記仮想通貨を代替物に交換する交換要求を受け付け、
前記交換要求を受け付けた場合、前記仮想通貨を付与した時点から一定期間内であるか否かを判定し、
一定期間内であると判定した場合、前記仮想通貨の交換を行う
処理をコンピュータが実行することを特徴とする情報処理方法。 - ユーザが購入した商品又はサービスに関する購入情報を取得し、
前記購入情報に基づき、前記ユーザに付与する仮想通貨の数量を決定し、
決定した数量の前記仮想通貨を前記ユーザに付与し、
前記ユーザから、前記仮想通貨を代替物に交換する交換要求を受け付け、
前記交換要求を受け付けた場合、前記仮想通貨を付与した時点から一定期間内であるか否かを判定し、
一定期間内であると判定した場合、前記仮想通貨の交換を行う
処理をコンピュータに実行させることを特徴とするプログラム。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2020545379A JP6886216B2 (ja) | 2019-03-05 | 2020-03-05 | 情報処理装置、情報処理方法及びプログラム |
US17/406,520 US12045785B2 (en) | 2019-03-05 | 2021-08-19 | Information processing apparatus, information processing method, and non-transitory computer-readable storage medium |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201962813953P | 2019-03-05 | 2019-03-05 | |
US62/813,953 | 2019-03-05 | ||
JP2019-132200 | 2019-07-17 | ||
JP2019132200 | 2019-07-17 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/406,520 Continuation US12045785B2 (en) | 2019-03-05 | 2021-08-19 | Information processing apparatus, information processing method, and non-transitory computer-readable storage medium |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2020179863A1 true WO2020179863A1 (ja) | 2020-09-10 |
Family
ID=72338171
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2020/009372 WO2020179863A1 (ja) | 2019-03-05 | 2020-03-05 | 情報処理装置、情報処理方法及びプログラム |
Country Status (3)
Country | Link |
---|---|
US (1) | US12045785B2 (ja) |
JP (1) | JP6886216B2 (ja) |
WO (1) | WO2020179863A1 (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP7201866B1 (ja) | 2022-07-29 | 2023-01-10 | Kddi株式会社 | 情報処理装置及び情報処理方法 |
WO2023058685A1 (ja) * | 2021-10-06 | 2023-04-13 | Social Good Foundation株式会社 | 情報処理方法、プログラム及び情報処理装置 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002049872A (ja) * | 2000-08-01 | 2002-02-15 | E Bank Corp | ネットワークを用いた電子マネーの提供方法、及びネットワークを用いた電子マネーの提供システム |
JP2002109428A (ja) * | 2000-09-28 | 2002-04-12 | Hisatoshi Nakayama | 金を用いた決済システム、金を用いた決済方法およびプログラムを記録したコンピュータ読み取り可能な記録媒体 |
Family Cites Families (27)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4847916B2 (ja) | 2007-05-18 | 2011-12-28 | 日本電信電話株式会社 | 購買順序を考慮したリコメンド装置、リコメンド方法、リコメンドプログラムおよびそのプログラムを記録した記録媒体 |
US11263543B2 (en) * | 2007-11-02 | 2022-03-01 | Ebay Inc. | Node bootstrapping in a social graph |
US10223710B2 (en) * | 2013-01-04 | 2019-03-05 | Visa International Service Association | Wearable intelligent vision device apparatuses, methods and systems |
US20140012647A1 (en) * | 2012-06-15 | 2014-01-09 | Nyz Holdings Inc. | Apparatus, methods, and articles of manufacture for virtual currency transactions |
US20150363769A1 (en) * | 2014-06-16 | 2015-12-17 | Bank Of America Corporation | Cryptocurrency Real-Time Conversion System |
US10223459B2 (en) * | 2015-02-11 | 2019-03-05 | Google Llc | Methods, systems, and media for personalizing computerized services based on mood and/or behavior information from multiple data sources |
US11270299B2 (en) * | 2015-12-07 | 2022-03-08 | Visa International Service Association | Methods and systems of using a cryptocurrency system to manage payments and payment alternatives |
US20170161729A1 (en) * | 2015-12-07 | 2017-06-08 | Leadot Innovation, Inc. | Method of Exchanging Currencies Using an Offline Point of Sale Third Party Payment System and Internet-connected Mobile Computing Device |
WO2017104064A1 (ja) | 2015-12-18 | 2017-06-22 | 楽天株式会社 | 管理装置、管理方法、非一時的な記録媒体、およびプログラム |
US20210019738A1 (en) * | 2016-02-05 | 2021-01-21 | Wells Fargo Bank, N.A. | Systems and methods for performing a foreign exchange transaction |
WO2017187538A1 (ja) | 2016-04-27 | 2017-11-02 | 株式会社野村総合研究所 | 購買活動支援システム |
JP6046295B1 (ja) | 2016-05-19 | 2016-12-14 | office ISEA株式会社 | ポイント寄付システム |
JP2017228040A (ja) | 2016-06-21 | 2017-12-28 | トッパン・フォームズ株式会社 | 加盟店舗情報提供方法 |
US9747586B1 (en) * | 2016-06-28 | 2017-08-29 | Cpn Gold B.V. | System and method for issuance of electronic currency substantiated by a reserve of assets |
JP2018041189A (ja) | 2016-09-06 | 2018-03-15 | 株式会社Nttドコモ | 通信端末、サーバ装置、店舗推奨方法、プログラム |
US11061912B2 (en) * | 2016-10-26 | 2021-07-13 | International Business Machines Corporation | Generating personalized routes for one or more users to improve user well-being |
JP6364516B1 (ja) | 2017-03-09 | 2018-07-25 | 日本リユースシステム株式会社 | 情報生成システム及び情報生成方法 |
JP6698575B2 (ja) | 2017-03-30 | 2020-05-27 | 株式会社ゼンリンデータコム | レコメンドシステム及びレコメンド方法 |
US11436585B2 (en) * | 2017-12-19 | 2022-09-06 | American Express Travel Related Services Company, Inc. | Virtual point of sale |
US11551212B2 (en) * | 2018-01-10 | 2023-01-10 | Rajeev Malhotra | Methods and systems for management of a blockchain-based computer-enabled networked ecosystem |
JP6590167B2 (ja) | 2018-01-17 | 2019-10-16 | Social Good Foundation株式会社 | 情報処理装置、情報処理方法、プログラム及び製造方法 |
JP6469276B2 (ja) | 2018-03-09 | 2019-02-13 | 株式会社三菱総合研究所 | 仮想通貨システム |
US20190308103A1 (en) * | 2018-04-06 | 2019-10-10 | Zynga Inc. | Real-time virtual goods inventory mechanism |
US20190385183A1 (en) * | 2018-06-19 | 2019-12-19 | Sang Mi RYU | Method for automatically providing cryptocurrency to recommender using propagation on sns |
JP6475387B1 (ja) | 2018-07-17 | 2019-02-27 | 株式会社メルカリ | 情報処理方法、情報処理装置、およびプログラム |
US20200042971A1 (en) * | 2018-07-31 | 2020-02-06 | American Express Travel Related Services Co., Inc. | System and method for transaction account based micro-payments |
KR102069979B1 (ko) * | 2018-08-07 | 2020-01-23 | 주식회사 바디프랜드 | 마사지 장치 기반 사용자 정보 거래 방법 및 시스템 |
-
2020
- 2020-03-05 WO PCT/JP2020/009372 patent/WO2020179863A1/ja active Application Filing
- 2020-03-05 JP JP2020545379A patent/JP6886216B2/ja active Active
-
2021
- 2021-08-19 US US17/406,520 patent/US12045785B2/en active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002049872A (ja) * | 2000-08-01 | 2002-02-15 | E Bank Corp | ネットワークを用いた電子マネーの提供方法、及びネットワークを用いた電子マネーの提供システム |
JP2002109428A (ja) * | 2000-09-28 | 2002-04-12 | Hisatoshi Nakayama | 金を用いた決済システム、金を用いた決済方法およびプログラムを記録したコンピュータ読み取り可能な記録媒体 |
Non-Patent Citations (2)
Title |
---|
"Case:Whoppercoin", RUSSIA BURGER KING ISSUES ITS OWN VIRTUAL CURRENCY WHOPPER COIN, 8 September 2017 (2017-09-08), pages 1, 2, Retrieved from the Internet <URL:https://adgang.jp/2017/09/1502266.html> [retrieved on 20190117] * |
DSPLUS A DECENTRALIZED CASHBACK PLATFORM ON THE ETHEREUM BLOCKCHAIN, 8 December 2017 (2017-12-08), pages 1 - 20, Retrieved from the Internet <URL:http://web.archive.org/web/20171208011526/https://pluscoin.io/whitepaper/WP%20PlusCoin%20-%20(ENG).pdf> [retrieved on 20190404] * |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2023058685A1 (ja) * | 2021-10-06 | 2023-04-13 | Social Good Foundation株式会社 | 情報処理方法、プログラム及び情報処理装置 |
JP7201866B1 (ja) | 2022-07-29 | 2023-01-10 | Kddi株式会社 | 情報処理装置及び情報処理方法 |
JP2024018155A (ja) * | 2022-07-29 | 2024-02-08 | Kddi株式会社 | 情報処理装置及び情報処理方法 |
Also Published As
Publication number | Publication date |
---|---|
JP6886216B2 (ja) | 2021-06-16 |
JPWO2020179863A1 (ja) | 2021-03-11 |
US12045785B2 (en) | 2024-07-23 |
US20220036321A1 (en) | 2022-02-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20210217046A1 (en) | Pos terminal(s) with free form rewards architecture | |
US9875469B1 (en) | Bill splitting | |
JP6590167B2 (ja) | 情報処理装置、情報処理方法、プログラム及び製造方法 | |
JP2018060300A (ja) | 購買管理システム | |
JP7121850B1 (ja) | 情報処理装置、情報処理方法、および情報処理プログラム | |
JP2022157746A (ja) | 情報処理装置、情報処理方法、および情報処理プログラム | |
JP2019128932A (ja) | 情報処理装置、情報処理方法及びプログラム | |
WO2020179863A1 (ja) | 情報処理装置、情報処理方法及びプログラム | |
JP2019139297A (ja) | プログラム、情報処理装置、情報処理方法及び製造方法 | |
US20170004481A1 (en) | Systems and methods for retrieving electronically stored information in real-time for electronic transactions | |
WO2020179861A1 (ja) | 情報処理装置、情報処理方法及び学習済みモデルの生成方法 | |
KR20200034390A (ko) | 소비연동형 연금 적립 관리시스템 | |
WO2020179862A1 (ja) | プログラム、情報処理方法及び情報処理装置 | |
JP6883900B2 (ja) | 情報処理装置、情報処理方法及びプログラム | |
JP6635536B2 (ja) | 情報処理システム、情報処理方法及び情報処理装置 | |
JP2022158810A (ja) | 情報処理装置、情報処理方法、および情報処理プログラム | |
JP6592170B1 (ja) | 情報処理方法、情報処理装置、及びプログラム | |
WO2023058683A1 (ja) | 情報処理方法、プログラム及び情報処理装置 | |
WO2023058685A1 (ja) | 情報処理方法、プログラム及び情報処理装置 | |
JP6999993B1 (ja) | プログラム | |
JP7059422B2 (ja) | 情報処理システム | |
JP7270823B1 (ja) | 情報処理装置、情報処理方法及び情報処理プログラム | |
JP6629415B1 (ja) | 情報処理方法、情報処理装置、及びプログラム | |
JP7155446B1 (ja) | 情報処理装置、情報処理方法及び情報処理プログラム | |
JP7452946B2 (ja) | 情報処理方法、情報処理装置、及びプログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
ENP | Entry into the national phase |
Ref document number: 2020545379 Country of ref document: JP Kind code of ref document: A |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 20766398 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 20766398 Country of ref document: EP Kind code of ref document: A1 |