WO2020179862A1 - プログラム、情報処理方法及び情報処理装置 - Google Patents

プログラム、情報処理方法及び情報処理装置 Download PDF

Info

Publication number
WO2020179862A1
WO2020179862A1 PCT/JP2020/009371 JP2020009371W WO2020179862A1 WO 2020179862 A1 WO2020179862 A1 WO 2020179862A1 JP 2020009371 W JP2020009371 W JP 2020009371W WO 2020179862 A1 WO2020179862 A1 WO 2020179862A1
Authority
WO
WIPO (PCT)
Prior art keywords
screen
user
server
amount
token
Prior art date
Application number
PCT/JP2020/009371
Other languages
English (en)
French (fr)
Inventor
壮一郎 ▲高▼岡
Original Assignee
Ｓｏｃｉａｌ Ｇｏｏｄ Ｆｏｕｎｄａｔｉｏｎ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ｓｏｃｉａｌ Ｇｏｏｄ Ｆｏｕｎｄａｔｉｏｎ株式会社 filed Critical Ｓｏｃｉａｌ Ｇｏｏｄ Ｆｏｕｎｄａｔｉｏｎ株式会社
Priority to JP2020545377A priority Critical patent/JP6884452B2/ja
Publication of WO2020179862A1 publication Critical patent/WO2020179862A1/ja

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
    • 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

Definitions

  • the present invention relates to a program, an information processing method, and an information processing device.
  • Patent Document 1 only promotes the consumption of virtual currency.
  • the purpose is to provide programs that can appropriately support consumers using virtual currencies.
  • a plurality of member stores The second screen showing the list is displayed on the display unit, the selection input for selecting the member store is accepted on the second screen, the purchase information of the product or service at the selected member store is output, and the above.
  • a computer performs a process of acquiring the quantity of the virtual currency given to the user according to the purchase information and updating the holding amount of the virtual currency displayed on the first screen according to the acquired quantity of the virtual currency. It is characterized by having it executed.
  • 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)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

プログラムは、ユーザが保有する仮想通貨の保有量を示す第１画面を表示部に表示し、前記第１画面において第１方向になぞる操作入力を受け付けた場合、複数の加盟店を一覧で示す第２画面を前記表示部に表示し、前記第２画面において前記加盟店を選択する選択入力を受け付け、選択された前記加盟店での商品又はサービスの購入情報を出力し、前記購入情報に応じて前記ユーザに付与される前記仮想通貨の数量を取得し、取得した前記仮想通貨の数量に応じて、前記第１画面に表示する前記仮想通貨の保有量を更新する処理をコンピュータに実行させることを特徴とする。

Description

プログラム、情報処理方法及び情報処理装置
　本発明は、プログラム、情報処理方法及び情報処理装置に関する。
　ブロックチェーンに代表される分散型台帳技術を用いて実現される仮想通貨の活用が検討されている。例えば特許文献１では、地域振興のために特定の地域にのみ流通する仮想通貨を取り扱う仮想通貨システムであって、消費者が入金した現金の価値よりも高い仮想通貨を消費者に付与し、時間経過に従って、付与した仮想通貨の価値を減少させる仮想通貨システムが提案されている。特許文献１によれば、仮想通貨の価値が減少していくため、仮想通貨の消費が促進され、地域の経済活動を活発化することができる。
特開２０１８－８８２９４号公報
　しかしながら、特許文献１に係る発明は仮想通貨の消費を促すに過ぎない。
　一つの側面では、仮想通貨を用いて消費者を適切に支援することができるプログラム等を提供することを目的とする。
　一つの側面に係るプログラムは、ユーザが保有する仮想通貨の保有量を示す第１画面を表示部に表示し、前記第１画面において第１方向になぞる操作入力を受け付けた場合、複数の加盟店を一覧で示す第２画面を前記表示部に表示し、前記第２画面において前記加盟店を選択する選択入力を受け付け、選択された前記加盟店での商品又はサービスの購入情報を出力し、前記購入情報に応じて前記ユーザに付与される前記仮想通貨の数量を取得し、取得した前記仮想通貨の数量に応じて、前記第１画面に表示する前記仮想通貨の保有量を更新する処理をコンピュータに実行させることを特徴とする。
　一つの側面では、仮想通貨を用いて消費者を適切に支援することができる。
トークンバックシステムの構成例を示す模式図である。 サーバの構成例を示すブロック図である。 端末の構成例を示すブロック図である。 ユーザＤＢ、加盟店ＤＢ、寄付先ＤＢ、購入履歴ＤＢ、投稿履歴ＤＢ、及び付与履歴ＤＢのレコードレイアウトの一例を示す説明図である。 トークン付与処理の概要を示す説明図である。 トップ画面の一例を示す説明図である。 左スワイプ操作時の画面遷移例を示す説明図である。 付与予定のトークンに関する通知画面例を示す説明図である。 トークン付与後のトップ画面を示す説明図である。 右スワイプ操作時の画面遷移例を示す説明図である。 端末が実行する処理手順の一例を示すフローチャートである。 サーバが実行する処理手順の一例を示すフローチャートである。 推定モデルに関する説明図である。 推定モデルの生成処理の手順を示すフローチャートである。 実施の形態２に係るトークンバックシステムが実行する処理手順の一例を示すフローチャートである。 実施の形態３の概要を示す説明図である。 実施の形態３に係るトークンバックシステムが実行する処理手順の一例を示すフローチャートである。 変形例に係るトップ画面の一例を示す説明図である。 付与履歴画面の一例を示す説明図である。
　以下、本発明をその実施の形態を示す図面に基づいて詳述する。
（実施の形態１）
　図１は、トークンバックシステムの構成例を示す模式図である。本実施の形態では、所定の加盟店において商品又はサービス（以下、「商品等」と記す）を法定通貨で購入したユーザに対し、仮想通貨（トークン）を付与するトークンバックシステムについて説明する。トークンバックシステムは、情報処理装置１、端末２、２、２…、取引所サーバ３、ＥＣ（Electronic Commerce）サーバ４、及び発行サーバ５を含む。各装置は、インターネット等のネットワークＮを介して相互に通信接続されている。
　情報処理装置１は、種々の情報処理、情報の送受信が可能な情報処理装置であり、例えばサーバコンピュータ、パーソナルコンピュータ等である。本実施の形態において情報処理装置１はサーバコンピュータであるものとし、以下では簡潔のためサーバ１と読み替える。サーバ１は、本システムを管理する管理者のサーバコンピュータであり、本システムに加盟する加盟店で商品等を購入したユーザに対し、トークン建てでキャッシュバック（トークンバック）を行う。当該トークンは本システム独自の仮想通貨であり、ブロックチェーンに取引履歴が記録される仮想通貨である。
　なお、サーバ１が付与する仮想通貨は独自のトークンである必要はなく、例えばビットコイン（登録商標）、イーサリアム（登録商標）等の既存の仮想通貨であってもよい。
　端末２は、本システムを利用する各ユーザの端末装置であり、例えばスマートフォン、タブレット端末、パーソナルコンピュータ等である。本実施の形態では端末２が、タッチパネルを備えたスマートフォンであるものとして説明を行う。端末２には、本システムに係る機能を実現するためのアプリケーションプログラムが予めインストールされており、端末２は、当該アプリケーションプログラムを実行することで後述の処理を行う。
　取引所サーバ３は、仮想通貨の取引所を提供する仮想通貨交換業者のサーバコンピュータである。本実施の形態に係るトークンは、一又は複数の取引所に上場されており、ユーザは取引所においてトークンを売買可能となっている。
　ＥＣサーバ４は、電子商取引サービスを提供するＥＣサイト（仮想店舗）事業者のサーバコンピュータである。本システムには、実店舗で商品等の販売を行う事業者のほかに、ＥＣサイト事業者が加盟している。各ユーザは、加盟店である実店舗又はＥＣサイトで商品等を購入した場合に、トークンを受け取ることができる。
　発行サーバ５は、本システムに係るトークンの発行を行うサーバコンピュータであり、トークンの発行上限を制御するサーバコンピュータである。本システムでは、発行サーバ５がトークンの発行を行って取引市場（取引所等）に供給する。トークンの発行上限は発行サーバ５において規定され、発行サーバ５は、市場におけるトークンの需給状況を参照しながら発行量を調整（新規トークンを発行）する。
　図２は、サーバ１の構成例を示すブロック図である。サーバ１は、制御部１１、主記憶部１２、通信部１３、及び補助記憶部１４を備える。
　制御部１１は、一又は複数のＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro-Processing Unit）、ＧＰＵ（Graphics Processing Unit）等の演算処理装置を有し、補助記憶部１４に記憶されたプログラムＰ１を読み出して実行することにより、サーバ１に係る種々の情報処理、制御処理等を行う。主記憶部１２は、ＳＲＡＭ（Static Random Access Memory）、ＤＲＡＭ（Dynamic Random Access Memory）、フラッシュメモリ等の一時記憶領域であり、制御部１１が演算処理を実行するために必要なデータを一時的に記憶する。通信部１３は、通信に関する処理を行うための処理回路等を含み、端末２等と情報の送受信を行う。
　補助記憶部１４は大容量メモリ、ハードディスク等であり、制御部１１が処理を実行するために必要なプログラムＰ１、その他のデータを記憶している。また、補助記憶部１４は、ユーザＤＢ１４１、加盟店ＤＢ１４２、寄付先ＤＢ１４３、購入履歴ＤＢ１４４、投稿履歴ＤＢ１４５、付与履歴ＤＢ１４６を記憶している。ユーザＤＢ１４１は、各ユーザの情報を格納するデータベースである。加盟店ＤＢ１４２は、各加盟店（実店舗又はＥＣサイト）の情報を格納するデータベースである。寄付先ＤＢ１４３は、トークンの寄付先として登録してある団体等の情報を格納するデータベースである。後述するように、本実施の形態では、各ユーザにトークンを付与する場合に、付与するトークンの一部を寄付先ＤＢ１４３に登録してある寄付先に寄付させる。
　購入履歴ＤＢ１４４は、ユーザによる商品等の購入履歴を格納するデータベースである。投稿履歴ＤＢ１４５は、ユーザによるＳＮＳ（Social Networking Service）への投稿履歴を格納するデータベースである。後述するように、本実施の形態では、各ユーザにトークンを付与する場合に、ＳＮＳへの投稿を条件にトークンを付与する。付与履歴ＤＢ１４６は、ユーザに対するトークンの付与履歴（トークンバックの履歴）を格納するデータベースである。
　なお、補助記憶部１４はサーバ１に接続された外部記憶装置であってもよい。また、サーバ１は複数のコンピュータからなるマルチコンピュータであっても良く、ソフトウェアによって仮想的に構築された仮想マシンであってもよい。
　また、本実施の形態においてサーバ１は上記の構成に限られず、例えば操作入力を受け付ける入力部、画像を表示する表示部等を含んでもよい。また、サーバ１は、ＣＤ（Compact Disk）－ＲＯＭ、ＤＶＤ（Digital Versatile Disc）－ＲＯＭ等の可搬型記憶媒体１ｍを読み取る読取部を備え、可搬型記憶媒体１ｍからプログラムＰ１を読み取って実行するようにしても良い。あるいはサーバ１は、半導体メモリ１ｎからプログラムＰ１を読み込んでも良い。
　図３は、端末２の構成例を示すブロック図である。端末２は、制御部２１、主記憶部２２、通信部２３、表示部２４、入力部２５、撮像部２６、補助記憶部２７を備える。
　制御部２１は、一又は複数のＣＰＵ、ＭＰＵ等の演算処理装置を有し、補助記憶部２７に記憶されたプログラムＰ２を読み出して実行することにより、端末２に係る種々の情報処理、制御処理等を行う。主記憶部２２は、ＲＡＭ等の一時記憶領域であり、制御部２１が演算処理を実行するために必要なデータを一時的に記憶する。通信部２３は、通信を行うためのアンテナ、処理回路等を含み、サーバ１等と情報の送受信を行う。表示部２４は、液晶ディスプレイ、有機ＥＬ（Electro Luminescence）ディスプレイ等の表示装置であり、制御部２１から与えられた画像を表示する。入力部２５は、例えばタッチパネル、メカニカルキー等の入力インターフェイスであり、ユーザからの操作入力を受け付ける。撮像部２６は、ＣＭＯＳ（Complementary Metal Oxide Semiconductor）センサ等の撮像素子を備えたカメラであり、ユーザによる操作入力に従って撮像を行う。補助記憶部２７は、ＲＯＭ（Read Only Memory）等の不揮発性メモリであり、制御部２１が処理を実行するために必要なプログラムＰ２、その他のデータを記憶している。
　なお、端末２は、可搬型記憶媒体２ｎを読み取る読取部を備え、可搬型記憶媒体２ｎからプログラムＰ２を読み取って実行するようにしても良い。あるいは端末２は、半導体メモリ２ｍからプログラムＰ２を読み込んでも良い。
　図４は、ユーザＤＢ１４１、加盟店ＤＢ１４２、寄付先ＤＢ１４３、購入履歴ＤＢ１４４、投稿履歴ＤＢ１４５、及び付与履歴ＤＢ１４６のレコードレイアウトの一例を示す説明図である。
　ユーザＤＢ１４１は、ユーザＩＤ列、ユーザ名列、ウォレット列、ＳＮＳ列、個人情報列を含む。ユーザＩＤ列は、各ユーザを識別するためのユーザＩＤを記憶している。ユーザ名列、ウォレット列、ＳＮＳ列、及び個人情報列はそれぞれ、ユーザＩＤと対応付けて、ユーザの氏名、ユーザにトークンを送金するために必要なウォレット情報（例えば公開鍵等）、ユーザのＳＮＳアカウントの情報、及びユーザの個人情報（性別、年齢、国籍等）を記憶している。
　加盟店ＤＢ１４２は、加盟店ＩＤ列、加盟店名列、加盟店情報列、手数料率列を含む。加盟店ＩＤ列は、各加盟店を識別するための加盟店ＩＤを記憶している。加盟店名列、加盟店情報列、及び手数料率列はそれぞれ、加盟店ＩＤと対応付けて、加盟店の名称、その他の加盟店に関する情報、及び加盟店から徴収する手数料の割合を記憶している。
　寄付先ＤＢ１４３は、団体ＩＤ列、団体名列、画像列を含む。団体ＩＤ列は、寄付先として登録してある団体等を識別するための団体ＩＤを記憶している。団体名列及び画像列はそれぞれ、団体ＩＤと対応付けて、寄付先である団体等の名称、及び当該団体等に寄付する場合にユーザがＳＮＳへの投稿に利用する画像データを記憶している。
　購入履歴ＤＢ１４４は、購入ＩＤ列、購入者列、加盟店列、日付列、購入商品列、購入額列を含む。購入ＩＤ列は、加盟店からユーザが商品等を購入した場合に、個々の購入履歴（購入情報）に対して割り当てられる購入ＩＤを記憶している。購入者列、加盟店列、日付列、購入商品列、及び購入額列はそれぞれ、購入ＩＤと対応付けて、購入者であるユーザのユーザＩＤ、ユーザが商品等を購入した加盟店の加盟店ＩＤ、商品等を購入した日付、購入した商品等の名称、及び購入額を記憶している。
　投稿履歴ＤＢ１４５は、投稿ＩＤ列、投稿日時列、ＳＮＳ列、投稿者列、投稿情報列を含む。投稿ＩＤ列は、ユーザがＳＮＳに投稿した個々の投稿情報毎に割り当てられた投稿ＩＤを記憶している。投稿日時列、ＳＮＳ列、投稿者列、及び投稿情報列はそれぞれ、投稿ＩＤと対応付けて、投稿された日時、投稿先のＳＮＳ、投稿者であるユーザのユーザＩＤ、及び投稿内容（テキスト、画像等のデータ）を記憶している。
　付与履歴ＤＢ１４６は、日時列、トークンバック列、寄付列、承認列を含む。日時列は、ユーザにトークンを付与した日時を記憶している。トークンバック列、寄付列、承認列はそれぞれ、日時と対応付けて、ユーザへのトークンバックに関する情報、寄付に関する情報、及び加盟店からのトークン付与の承認の有無を記憶している。トークンバック列には、例えば付与対象であるユーザのユーザＩＤ、付与したトークンの数量、及びトークンの付与（送金）のために作成したトランザクションのＩＤなどを記憶している。寄付列には、例えば寄付先である団体等の団体ＩＤ、寄付したトークンの数量、トークンの寄付（送金）のために作成したトランザクションのＩＤ、及びトークン寄付に関連してユーザがＳＮＳに投稿した投稿情報の投稿ＩＤなどを記憶している。
　図５は、トークン付与処理の概要を示す説明図である。図５に基づき、本システムの概要を説明する。
　上述の如く、本実施の形態では、本システム独自のトークンを取り扱う。当該トークンは、例えばサーバ１とは別個の発行サーバ５が取引市場に供給し、発行上限を制御する。取引所サーバ３が提供する取引所（取引市場）において、各ユーザは市場に流通するトークンを売買可能となっている。
　サーバ１は、当該トークンを媒介としたキャッシュバック（トークンバック）の処理を管理する管理装置であり、商品等を購入したユーザに対し、購入した商品等の購入額に応じた数量のトークンを付与する。
　なお、本実施の形態で云う「トークンの付与」とは、ユーザにトークンを送金するためのトランザクションをデータベース（例えば付与履歴ＤＢ１４６）に登録する処理と、トランザクションをブロックチェーンネットワークにブロードキャストして実際にユーザのウォレットへ送金する処理との何れも含み得る。前者の場合、サーバ１は端末２からの要求を受けてデータベースに登録されているトランザクションをブロードキャストし、ユーザに付与したトークンをウォレットへ送金する。
　本システムには実店舗、ＥＣサイト（仮想店舗）などの複数の加盟店が加盟しており、ユーザが各加盟店で商品等を購入した場合、サーバ１は、加盟店から商品等の購入額に応じた手数料を徴収し、当該手数料を原資としてトークンを付与する。なお、各加盟店から徴収する手数料率は加盟店ＤＢ１４２で規定されている。サーバ１は、購入額に手数料率を乗算して手数料を算出し、算出した手数料の支払いを加盟店に要求する。サーバ１は、加盟店から支払われる手数料を原資にトークンバックを実施する。
　この場合にサーバ１は、加盟店から支払われる手数料に基づき、取引所サーバ３に対し、トークンを購入する旨の購買要求（いわゆるオファー）を出力し、トークンを購入する。すなわちサーバ１は、加盟店からの手数料を原資として、仮想通貨の取引市場からトークンを調達する。
　サーバ１はまず、トークンの時価（トークンを法定通貨に換算した場合の単位数量当たりの価格）を示す時価情報を取引所サーバ３から取得する。すなわち、サーバ１は、取引市場（取引所等）におけるトークンの市場価格を示すデータを取引所サーバ３から取得する。なお、取引所サーバ３ではなく、仮想通貨の時価情報を公開している外部サイトからトークンの時価情報は取得してもよい。
　サーバ１は、時価情報を参照して、加盟店からの手数料で購入可能なトークンの数量を算出する。そしてサーバ１は、算出した数量のトークンを現在の時価で購入する旨の購買要求を取引所サーバ３に出力する。サーバ１は、取引所サーバ３を介してトークンの保有者からトークンを購入する。サーバ１は、購入したトークンをユーザへの付与に充てる。
　なお、ユーザが商品等を購入して加盟店からの手数料の支払い（入金）が完了するまでにタイムラグが存在するため、実際には、ユーザへトークンを付与した後に、購買要求を出力して市場からトークンを調達（補充）することになる。なお、トークンの調達が完了後にユーザへのトークン付与を行ってもよいことは勿論である。
　また、本実施の形態では取引所サーバ３（取引所）からトークンを調達するものとするが、例えばサーバ１は、トークンの発行元である発行サーバ５からトークンを調達（購入）してもよい。
　上述の如く、サーバ１は、ユーザが加盟店で商品等を購入した場合に、加盟店からの手数料を原資としてトークンを市場から調達する。これにより、市場におけるトークンの需要を強制的に高める結果になる。
　また、サーバ１は、トークンを付与する場合に、ユーザによるトークンの保有状況を示す保有情報を取得し、取得した保有情報に応じてトークンを付与する。保有情報は、トークンの保有量、保有期間などを示すデータである。例えばサーバ１は、付与履歴ＤＢ１４６に記憶されているトークンの付与履歴を参照して、ユーザが保有するトークンの保有量、保有期間などのデータを取得する。あるいはサーバ１は、ユーザＤＢ１４１に記憶されているウォレット情報に基づき、ブロックチェーンからユーザの現在の保有情報を取得してもよい。サーバ１は、取得した保有情報に基づいてトークンの付与を行う。
　例えばサーバ１は、ユーザが保有するトークンの保有量が所定数以上であるか否かを判定し、所定数以上のトークンを保有していると判定した場合、トークンを付与する。判定基準とするトークンの数量は特に限定されないが、例えばサーバ１は、ユーザが１トークン以上保有するか否かを判定する。このように、サーバ１は、所定数以上のトークンを保有しているユーザを対象としてトークンバックを実施する。これにより、トークン自体を一種の会員権として機能させ、所定数以上のトークンを保有しておくインセンティブをユーザに与える。
　なお、判定基準とするトークンの保有量を０とし、全てのユーザに対してトークンバックを実施してもよい。
　さらにサーバ１は、ユーザによるトークンの保有情報に基づいて重み付けを行い、ユーザに付与するトークンの数量を変動させる。例えばサーバ１は、ユーザによるトークンの保有量、及び保有期間に応じて付与量を変動させる。
　例えばサーバ１は、保有量が多いほど、ユーザに付与するトークンの数量を増加させる。また、サーバ１は、保有期間が長いほど、ユーザに付与するトークンの数量を増加させる。これにより、トークンをより多く、より長く保有しておくようにユーザに促す。
　上記の処理により、トークンを保有し続けるインセンティブをユーザに与える。これにより、ユーザはトークンを消費せず、保有し続けることが期待できる。この状態で、ユーザが加盟店で商品等を購入すれば購入するほど、上述のトークンの調達によって市場に流通するトークンの流通量が減少し、相対的にユーザが保有する既存のトークンの資産価値（市場価格）が上昇する。これにより、購入行為自体がユーザの資産価値形成に資する。
　上述の如く、本システムでは一般的なキャッシュバックサービスと同様にトークンの付与（トークンバック）を行うものの、付与したトークンを消費させずに、保有し続けるように促す。これにより、トークンの価格上昇を期待することができ、トークンバックによる直接的な価値の提供だけでなく、間接的な価値（価格上昇による資産価値の形成）を提供することができる。
　なお、トークンの流通量を更に減少させるため、取引市場（取引所等）においてユーザが有償でトークンを入手した場合は、商品等の購入によって付与するトークンの数量を増加させる、あるいはトークン付与の対象とする商品等の種類を増やすなどすると好適である。すなわち、サーバ１は、トークンバック（商品等の購入によるトークン付与）以外の方法でトークンを取得したユーザに対し、トークンの付与量を増加、あるいは付与対象とする商品等の種類を増加させる。これにより、ユーザによるトークンの購入を促し、市場での流通量を更に減少させることができる。
　図６は、トップ画面の一例を示す説明図である。以下では端末２での操作例を説明しながら、本システムの具体的な処理内容を説明する。
　上述の如く、端末２には本システムに係るアプリケーションプログラムがインストールされており、当該アプリケーションプログラムを実行して以下の処理を行う。なお、Ｗｅｂブラウザ等のＡＰＩ（Application Programmable Interface）上で画面表示、操作を行ってもよい。図６では、アプリケーションのトップ画面を図示している。
　トップ画面は、ユーザが保有しているトークンの保有量を表示する画面である。図６に図示するように、端末２は、ユーザが現在保有しているトークンの保有量と、当該トークンをユーザの国籍に対応する法定通貨に換算した場合の法定通貨相当額とをトップ画面に表示する。
　また、端末２は、左スワイプアイコン６１、右スワイプアイコン６２、及びカメラアイコン６３をトップ画面に表示する。左スワイプアイコン６１は、後述する加盟店の一覧画面（図７参照）に遷移すべく、左スワイプ（画面を左方向になぞる操作）の操作入力を促すアイコンである。右スワイプアイコン６２は、後述する取引所画面（図１０参照）に遷移すべく、右スワイプ（画面を右方向になぞる操作）の操作入力を促すアイコンである。カメラアイコン６３は、後述する加盟店（実店舗）のレシートの撮像モードに遷移するためのアイコンである。
　なお、本実施の形態では「スワイプ」によってトップ画面から他の画面に遷移することとするが、当該操作は画面をなぞる操作であればよく、例えばフリック、ドラッグ等と呼ばれる操作であってもよい。
　図７は、左スワイプ操作時の画面遷移例を示す説明図である。左スワイプアイコン６１に従って、トップ画面を左方向（第１方向）になぞるスワイプ操作を受け付けた場合、端末２は、図７の中央に示す一覧画面（第２画面）に遷移する。一覧画面は、本システムに加盟する複数の加盟店を一覧で示す表示画面である。図７に示すように、一覧画面には、商取引サービスを提供するＥＣサイト（仮想店舗）の加盟店（第１加盟店）と、実店舗の加盟店（第２加盟店）とが一覧で表示される。
　端末２は一覧画面において、各ＥＣサイトに対応してリンクボタン７１、７１、７１…を表示する。リンクボタン７１への操作入力を受け付けた場合、端末２は、操作されたリンクボタン７１に対応するＥＣサイト（ＥＣサーバ４）にアクセスする。なお、アクセス先はＥＣサイトのホーム画面などであってもよく、あるいはリンクボタン７１から個々の商品の画面に直接遷移させてもよい。
　端末２は、ユーザからの操作入力に従い、アクセスしたＥＣサイトにおいて商品等の購入申込を行う。ユーザがＥＣサイトにて商品等を購入した場合、サーバ１は、ＥＣサーバ４から、購入された商品等を関する購入情報を取得する。購入情報は、購入された商品等、購入額、購入日時などを示すデータである。サーバ１は、取得した購入情報を購入履歴ＤＢ１４４に記憶する。
　なお、本実施の形態ではＥＣサーバ４から購入情報を取得するものとするが、サーバ１は、端末２から直接的にＥＣサイトでの購入情報を取得してもよい。あるいはサーバ１は、ＡＳＰ（Affiliate Service Provider）などを経由して購入情報を取得してもよい。サーバ１は、図７の一覧画面を経由して端末２から直接又は間接的に購入情報を取得可能であればよく、その取得経路は特に問わない。
　また、端末２は一覧画面において、実店舗である各加盟店に対応してスキャンボタン７２、７２、７２…を表示する。一覧画面でスキャンボタン７２への操作入力を受け付けた場合、又はトップ画面でカメラアイコン６３への操作入力を受け付けた場合、端末２は撮像部２６を起動し、実店舗で購入した商品等に関する情報（購入情報）を記述した媒体を撮像するための撮像モードに遷移する。
　例えば端末２は、実店舗においてユーザに配布されるレシートを撮像するための撮像モードに遷移する。端末２は、ユーザからの操作入力に従ってレシートを撮像し、撮像画像に対する文字認識を行って、購入された商品等、購入額、購入日時などの購入情報を抽出する。端末２は、抽出した購入情報をサーバ１に送信する。
　なお、本実施の形態ではレシートを読み取るものとして説明するが、対象とする媒体はレシートに限定されず、例えばＱＲコード（登録商標）等のコード情報であってもよい。すなわち、端末２は所定の媒体を撮像して購入情報を抽出可能であればよく、その対象はテキストが印刷された紙媒体に限定されない。
　また、本実施の形態では、実店舗の加盟店における購入情報を端末２から取得するものとするが、例えばサーバ１は、実店舗のＰＯＳ（Point of Sales）システムから購入情報を取得するなどしてもよい。
　端末２又はＥＣサーバ４から購入情報を取得した場合、サーバ１は、上述の如く、商品等の購入額に応じた手数料の支払いを加盟店に要求する。サーバ１は、加盟店から支払われる手数料に基づき、取引所サーバ３にトークンの購買要求を出力し、トークンを購入する。
　また、サーバ１は、商品等の購入額に応じた数量のトークンをユーザに付与する。例えばサーバ１は、トークンの時価情報を取引所サーバ３から取得し、購入額に応じて定めた手数料を、現在の時価に従ってトークンの数量に換算する。サーバ１は、換算した数量のトークンをユーザに付与する。
　この場合にサーバ１は、上述の如く、ユーザによるトークンの保有情報を取得し、取得した保有情報を参照して付与するトークンの数量を決定する。具体的には、サーバ１は、ユーザによるトークンの保有量及び保有期間に応じて重み付けを行い、トークンの付与量を決定する。
　なお、上記のトークン付与に係る処理を行う場合に、トークンが発行上限に到達し、ユーザにトークンを付与できない場合も考えられる。なお、「発行上限に到達」とは、現に発行量の上限値に到達した場合だけでなく、発行量が上限値に近い場合も含み得る。発行上限に到達し、かつ、取引所サーバ３からトークンの購入（調達）が困難な場合、サーバ１は、本システムに係るトークンに代えて、他の仮想通貨、又は法定通貨をユーザに付与する。これにより、発行上限に達する事態にも対応することができる。
　発行上限に到達しない場合、又は取引所サーバ３からトークンを購入可能である場合、サーバ１は、上記で決定した数量のトークンをユーザに付与する。この場合に、サーバ１は、付与予定のトークンの一部を所定の寄付先（外部）に寄付させると共に、トークンを寄付した旨をＳＮＳに投稿することを条件に、トークンの付与を行う。
　図８は、付与予定のトークンに関する通知画面例を示す説明図である。図７で説明したＥＣサイトでの購入申込、又はレシートの読取が完了後、端末２はサーバ１からの通知を受け、図８の画面（第４画面）に遷移する。当該画面は、ユーザに付与される予定のトークンの数量を表示すると共に、トークンの寄付、及びＳＮＳへの投稿を促す表示画面である。
　図８に示すように、端末２は、商品等を購入した加盟店の名称と、当該加盟店での商品等の購入によって付与されるトークンの数量、及び付与されるトークンを法定通貨に換算した金額とを画面上部に表示する。サーバ１は、これらの情報を端末２に通知し、図８の画面に表示させる。
　さらに端末２は、付与予定のトークンの一部を寄付し、寄付した旨をＳＮＳに投稿すべき旨を表示する。例えば図８に示すように、端末２は、寄付先ＤＢ１４３に登録（記憶）されている寄付先の画像を表示すると共に、寄付及び投稿を行うべき旨のテキストを画像下部に表示する。また、端末２は、投稿先とするＳＮＳを選択するためのトグルスイッチ８１を表示し、投稿する一又は複数のＳＮＳを選択させる。
　トグルスイッチ８１による選択が完了後、端末２は不図示の画面に遷移し、ＳＮＳに投稿するコメント（テキスト）の入力をユーザから受け付ける。そして端末２は、ユーザ自身のＳＮＳのアカウントで、ユーザが入力したテキストのほか、図８で図示した寄付先の画像を含む投稿情報をＳＮＳ上に出力する。
　サーバ１はＳＮＳのＡＰＩを呼び出して、投稿情報が出力されたか否か、すなわちＳＮＳへの投稿が完了したか否かを判定する。投稿が完了した場合、サーバ１は、端末２からＳＮＳに出力された投稿情報を、投稿日時と対応付けて投稿履歴ＤＢ１４５に記憶する。また、サーバ１は、ユーザへのトークンの付与を行う。具体的には、サーバ１は、ユーザのウォレットへトークンを送金するためのトランザクションを生成し、付与履歴ＤＢ１４６に登録（記憶）する。この場合にサーバ１は、トランザクションのステータスを「承認待ち」として登録する。その後、サーバ１は、手数料を支払う加盟店（ＥＣサーバ４等）からトークン付与の承認を受け付ける。トークン付与の承認を受け付けた場合、サーバ１はステータスを「承認」に更新する。ステータスが「承認」に更新された場合、サーバ１は端末２からの要求に応じてトランザクションをブロックチェーンに出力し、寄付分を除くトークンをユーザのウォレットへ送金する。
　また、サーバ１は、ステータスを「承認」に更新後の任意のタイミングで、寄付分のトークンを寄付先に送金する。なお、寄付はトークンではなく、現金（法定通貨）等で行ってもよい。
　なお、トークンの寄付先、及び寄付するトークンの数量（寄付額）は、ユーザが任意に指定可能としてもよいが、サーバ１が自動的に決定してもよい。例えばサーバ１は、ユーザによる商品等の購入履歴に基づいてユーザの傾向を分析し、寄付先及び寄付量を決定する。例えばサーバ１は、商品等と寄付先及び寄付量とを予め関連付けておき、ユーザが購入した商品等に応じて、コンテンツベースで寄付先及び寄付量を決定する。また、例えばサーバ１は、対象のユーザの購入履歴と他のユーザの購入履歴とを比較し、協調フィルタリングを用いて、類似する他のユーザが過去に行った寄付と同じになるように寄付先及び寄付量を決定する。
　また、サーバ１は、一度の寄付で複数の寄付先にトークンを分配して送金するようにしてもよい。この場合の寄付先及び寄付量の配分についても上記と同様に、ユーザが任意に指定可能としてもよく、サーバ１が購入履歴等に基づいて自動的に決定するようにしてもよい。
　なお、上記ではトークンの寄付及びＳＮＳへの投稿をトークン付与の条件としたが、寄付及び投稿は必須の要件ではなく、寄付及び投稿をせずともトークンを付与するように構成してもよい。
　また、上記では加盟店からの承認を待ってユーザにトークンを付与するものとしたが、加盟店からの承認を不要としてトークンを付与してもよい。
　図９は、トークン付与後のトップ画面を示す説明図である。投稿が完了した場合、端末２は、図６でも例示したトップ画面に戻る。この場合、端末２はトップ画面を更新し、付与後のトークンの保有量を表示する。すなわち、端末２は、上記で付与されたトークンの数量を従前の保有量に加算し、加算後の保有量に更新して表示する。これにより、ユーザは商品等の購入によりトークンバックを受けたことをすぐに確認することができる。
　なお、この場合に、例えば端末２は、保有量が増えたことをユーザが直感的に把握可能なように、表示色を変更するなどして、トップ画面に表示する保有量を、図６で図示した付与前の保有量とは異なる態様で表示するようにすると好適である。なお、図９では便宜上、表示色が変更されている様子を太字で図示している。
　図１０は、右スワイプ操作時の画面遷移例を示す説明図である。トップ画面において、右スワイプアイコン６２に従って左から右方向（第２方向）になぞるスワイプ操作を受け付けた場合、端末２は、図１０に示すリンク画面（第３画面）に表示する。リンク画面は、トークンを売買可能な複数の取引所を一覧で示す画面であり、各取引所のサイトにアクセスするためのリンクページである。端末２はリンク画面において、何れかの取引所を選択する選択入力を受け付け、選択された取引所のサイトにアクセスする。端末２は、アクセスした取引所のサイト（不図示）において、法定通貨、又は他の仮想通貨にトークンを換金することができる。また、端末２は、取引所においてトークンの追加購入も行うことができる。
　なお、図１０の例では取引所のサイトに遷移するのみであったが、本実施の形態はこれに限定されるものではない。例えば端末２は、図１０の画面でトークンの送金先とする取引所のアカウント、送金するトークンの数量等を指定する指定入力を受け付け、指定されたアカウント（ウォレット）にトークンを送金可能としてもよい。これにより、ユーザは簡易な操作でトークンを移動させることができる。
　また、リンク画面において取引所の選択入力を受け付けた場合、端末２は所定のアラート表示を行い、トークンの換金を再考するようユーザに促してもよい。これにより、トークンの継続保有をユーザに促すことができる。
　上述の如く、各ユーザは加盟店で商品等を購入することで、価格上昇が期待できるトークンを得ることができる。特に本実施の形態では、端末２での簡便な操作でトークンを得ることができる。
　図１１は、端末２が実行する処理手順の一例を示すフローチャートである。図１１に基づき、端末２が実行する処理内容について説明する。
　端末２の制御部２１は、ユーザが現在保有するトークン（仮想通貨）の保有量を示すトップ画面（第１画面）を表示する（ステップＳ１１）。制御部２１は、トップ画面において、左方向（第１方向）になぞる左スワイプの操作入力を受け付けたか否かを判定する（ステップＳ１２）。左スワイプの操作入力を受け付けていないと判定した場合（Ｓ１２：ＮＯ）、制御部２１は、カメラアイコン６３への操作入力を受け付けたか否かを判定する（ステップＳ１３）。カメラアイコン６３への操作入力を受け付けていないと判定した場合（Ｓ１３：ＮＯ）、制御部２１は、右方向（第２方向）になぞる右スワイプの操作入力を受け付けたか否かを判定する（ステップＳ１４）。
　左スワイプの操作入力を受け付けたと判定した場合（Ｓ１２：ＹＥＳ）、制御部２１は、加盟店を一覧で示す一覧画面（第２画面）を表示する（ステップＳ１５）。具体的には、制御部２１は、ＥＣサイト（仮想店舗）の加盟店（第１加盟店）と、実店舗の加盟店（第２加盟店）とをそれぞれ一又は複数表示する。制御部２１は、一覧画面で表示した加盟店から何れかを選択する選択入力を受け付ける（ステップＳ１６）。
　制御部２１は、ステップＳ１６において、ＥＣサイトが選択されたか否かを判定する（ステップＳ１７）。ＥＣサイトが選択されたと判定した場合（Ｓ１７：ＹＥＳ）、制御部２１は、選択されたＥＣサイトにアクセスする（ステップＳ１８）。制御部２１は、ユーザからの操作入力に基づき、ＥＣサイトにおける商品等の購入申込に係る処理を行う（ステップＳ１９）。ユーザがＥＣサイトで商品等を購入した場合、サーバ１は、ＥＣサーバ４から、ユーザが購入した商品等を関する購入情報を取得する。
　ステップＳ１３でＹＥＳ、又はステップＳ１７でＮＯの場合、制御部２１は、ユーザが実店舗での購入情報が記述されたレシート（媒体）を撮像するための撮像モードに遷移し、ユーザからの操作入力に応じてレシートの撮像を行う（ステップＳ２０）。制御部２１は、撮像画像から購入情報を抽出し、サーバ１に送信する（ステップＳ２１）。
　ステップＳ１９又はＳ２１の処理を実行後、制御部２１は、付与予定のトークンの数量に関する通知をサーバ１から取得し、トークンの寄付、及びＳＮＳへの投稿を行うための通知画面（第４画面）に遷移して、ユーザからの操作入力に基づき、ＳＮＳ上に投稿情報を出力する（ステップＳ２２）。ステップＳ２２で表示する画面は、トークンの寄付、及び寄付した旨をＳＮＳに投稿することをユーザに促す画面であり、例えば付与予定のトークンの数量のほかに、サーバ１が決定した寄付先の情報（画像など）を表示する。制御部２１は、ユーザから任意のテキストの入力を受け付けて、入力されたテキスト、寄付先の画像などを含む投稿情報をＳＮＳ上に出力する。
　サーバ１は、ユーザからの投稿情報がＳＮＳに出力された場合に、購入額等に応じた数量のトークンを付与する。また、サーバ１は、ユーザに付与するトークンの一部を寄付先に送金する。制御部２１はトップ画面に遷移し、トップ画面に表示するトークンの保有量を、付与後のトークンの保有量に更新する（ステップＳ２３）。
　トップ画面において右スワイプの操作入力を受け付けたと判定した場合（Ｓ１４：ＹＥＳ）、制御部２１は、トークンを売買可能な取引所を一覧で示すリンク画面（第３画面）を表示する（ステップＳ２４）。制御部２１は、アクセスする取引所を選択する選択入力を受け付け、選択された取引所にアクセスする（ステップＳ２５）。
　ステップＳ２３、Ｓ２５の処理を実行後、又はステップＳ１４でＮＯの場合、制御部２１は、ユーザからの操作入力に従ってログアウトするか否かを判定する（ステップＳ２６）。ログアウトしないと判定した場合（Ｓ２６：ＮＯ）、制御部２１は処理をステップＳ１２に戻す。ログアウトすると判定した場合（Ｓ２６：ＹＥＳ）、制御部２１は一連の処理を終了する。
　図１２は、サーバ１が実行する処理手順の一例を示すフローチャートである。図１２に基づき、サーバ１が実行する処理内容について説明する。
　サーバ１の制御部１１は、端末２又はＥＣサーバ４から、ユーザが購入した商品等を関する購入情報を取得する（ステップＳ４１）。制御部１１は加盟店ＤＢ１４２から加盟店の手数料率を読み出し、商品等の購入額に応じた手数料を算出して、手数料の支払いを加盟店に要求する（ステップＳ４２）。
　制御部１１は、取引市場におけるトークン（仮想通貨）の時価情報、及びユーザによるトークンの保有情報を取得する（ステップＳ４３）。時価情報は、トークンの時価（法定通貨換算額）を示すデータであり、仮想通貨の取引市場（取引所等）における市場価格を示すデータである。保有情報は、ユーザによるトークンの保有状況を示すデータであり、例えばトークンの保有量、保有期間などを示すデータである。
　制御部１１は、購入情報、時価情報、保有情報などに基づき、ユーザに付与するトークンの数量を決定する（ステップＳ４４）。具体的には、制御部１１は、商品等の購入額に加盟店の手数料率を乗算した手数料（法定通貨額）を、トークンの時価に応じてトークンの数量に換算する。また、制御部１１はユーザの保有情報に応じて重み付けを行い、保有量が多く、保有期間が長いほど多くなるように付与量を決定する。
　また、制御部１１は、ユーザに付与予定のトークンの内、一部のトークンを送金する寄付先を決定する（ステップＳ４５）。例えば制御部１１は、ユーザによる商品等の購入履歴などから寄付先を決定する。
　制御部１１は、発行サーバ５から現在のトークンの発行量に関する情報を取得し、トークンの発行上限に到達するか否かを判定する（ステップＳ４６）。発行上限に到達すると判定した場合（Ｓ４６：ＹＥＳ）、制御部１１は、本システムのトークンとは異なる他の仮想通貨、又は法定通貨をユーザに付与し（ステップＳ４７）、一連の処理を終了する。
　発行上限に到達しないと判定した場合（Ｓ４６：ＮＯ）、制御部１１は、ステップＳ４４で決定した付与予定のトークンの数量を端末２に通知する（ステップＳ４８）。具体的には、制御部１１は、付与予定のトークンの数量を端末２に通知すると共に、ステップＳ４５で決定した寄付先の情報を通知する。
　制御部１１は、ユーザによるＳＮＳへの投稿が完了したか否かを判定する（ステップＳ４９）。投稿が完了していないと判定した場合（Ｓ４９：ＮＯ）、制御部１１は処理を待機する。投稿が完了したと判定した場合（Ｓ４９：ＹＥＳ）、制御部１１は、加盟店からトークン付与の承認を受け付けたか否かを判定する（ステップＳ５０）。トークン付与の承認を受け付けていないと判定した場合（Ｓ５０：ＮＯ）、制御部１１は処理を待機する。
　トークン付与の承認を受け付けたと判定した場合（Ｓ５０：ＹＥＳ）、制御部１１は、ステップＳ４２で算出した手数料に基づくトークンの購買要求を取引所サーバ３に出力する（ステップＳ５１）。また、制御部１１は、寄付分を除くトークンをユーザに付与する（ステップＳ５２）。また、制御部１１は、ステップＳ４５で決定した寄付先に対して寄付分のトークンを送金し（ステップＳ５３）、一連の処理を終了する。
　なお、本実施の形態では、加盟店から支払われる手数料に応じてユーザに付与するトークンの数量を定めたが、手数料の高低に関係なくユーザに付与するトークンの数量を定め、トークンバックを実施してもよい。
　また、本実施の形態では取引所を通じてトークンの買い戻しを行うものとしたが、取引所を経由する構成は必須ではなく、サーバ１がトークン保有者から直接的にトークンを購入するようにしてもよい。
　また、上記ではユーザによる商品等の購入情報に応じてトークンを付与するものとしたが、本実施の形態はこれに限定されるものではない。例えばサーバ１は、ユーザによるインターネット広告へのアクセス、特定のアプリケーションの利用など、商品等の購入以外のユーザの行動をトリガにトークンを付与してもよい。すなわち、商品等の購入はトークン付与の契機の一例であり、その他のユーザの行動に応じてトークンを付与してもよい。
　以上より、本実施の形態１によれば、端末２はトップ画面での簡単なスワイプ操作により加盟店の一覧画面に遷移し、レシート読取などで購入情報を直接的に、あるいはＥＣサーバ４経由で間接的にサーバ１に出力し、トークンの付与を受けて付与後の保有量をユーザに提示する。このように、簡便な操作でトークンバックを受けることができ、消費者（ユーザ）を適切に支援することができる
　また、本実施の形態１によれば、トップ画面での簡単なスワイプ操作で取引所にアクセスし、トークンの売買も行うことができる。
　また、本実施の形態１によれば、ＥＣサイト（仮想店舗）及び実店舗の双方の加盟店に対応してトークンバックを受けることができる。
　また、本実施の形態１によれば、トークンの寄付をトークンバックの条件とすることで、本システムを社会貢献策として実施することができる。
　また、本実施の形態１によれば、ＳＮＳへの投稿をトークンバックの条件とすることで、本システムを一般消費者に周知することができる。
（実施の形態２）
　本実施の形態では、ユーザの購入履歴等を学習する機械学習を行って推定モデル１４７を生成し、生成した推定モデル１４７を用いて、加盟店を利用するユーザの購入行動を推定する形態について述べる。なお、実施の形態１と重複する内容については同一の符号を付して説明を省略する。
　図１３は、推定モデル１４７に関する説明図である。本実施の形態においてサーバ１は、ユーザによる商品等の購入履歴のほかに、ユーザによるＳＮＳへの投稿履歴、ユーザの個人情報などを学習する機械学習を行い、推定モデル１４７を生成する。そしてサーバ１は、生成した推定モデル１４７を用いてユーザの購入行動を推定し、推定結果に応じた情報をユーザに提示する。例えばサーバ１は、推定モデル１４７から出力された推定結果に基づき、図７で例示した一覧画面で表示する加盟店の表示順序を入れ替え、ユーザが利用する確率が高い加盟店を上位に表示させる。
　なお、以下の説明ではＥＣサイト（仮想店舗）について推定を行うものとして説明するが、推定モデル１４７での推定対象はＥＣサイトだけでなく、実店舗の加盟店を含めてもよい。
　推定モデル１４７は、深層学習により生成されるニューラルネットワークであり、例えばＲＮＮ（Recurrent Neural Network）である。推定モデル１４７は、データの入力を受け付ける入力層と、入力層に入力されたデータに基づく演算を行う中間層と、中間層での演算結果に基づいて出力用のデータを出力する出力層とを有する。
　入力層は、各種データの入力を受け付ける複数のニューロンを有し、入力されたデータを中間層に受け渡す。中間層は、入力層から取得したデータに基づいて演算を行う複数のニューロンを有し、入力データの特徴量を抽出する演算処理を行う。例えば推定モデル１４７がＲＮＮである場合、中間層は時系列的に並ぶ前後のニューロンの演算結果を用いて演算を行うことで、入力層の各ニューロンに入力されたデータ同士の相関を参酌しながら特徴量を抽出する。出力層は、中間層で抽出した特徴量に基づき、出力すべきデータの推定を行う。
　なお、上記では推定モデル１４７の一例としてＲＮＮを挙げたが、推定モデル１４７はその他のニューラルネットワークであってもよい。また、推定モデル１４７は深層学習に係る学習済みモデルに限定されず、例えば強化学習、決定木、ランダムフォレスト、ＳＶＭ（Support Vector Machine）等のアルゴリズムに基づくモデルであってもよい。
　本実施の形態においてサーバ１は、購入履歴ＤＢ１４４、投稿履歴ＤＢ１４５などに蓄積された情報を教師データとして用いて、各ユーザの購入履歴、投稿履歴、個人情報などに基づき、加盟店を利用するユーザの購入行動を推定する推定モデル１４７を生成する。
　具体的には、サーバ１は、購入履歴等を入力として、ユーザに推奨すべきＥＣサイト（加盟店）を出力とする推定モデル１４７を生成する。より詳細には、サーバ１は、本システムに加盟する複数のＥＣサイトについて、ユーザに推奨すべきＥＣサイトの優先順位を出力する推定モデル１４７を生成する。
　サーバ１は、各ユーザの購入履歴（購入した商品等、購入額、購入日時などのデータ）のほかに、トークンバックの条件としてＳＮＳに投稿した投稿情報の履歴（投稿したコメント、投稿日時などのデータ）、及びユーザの個人情報（年齢、性別、国籍などのデータ）を各データベースから読み出し、教師用の入力データとして推定モデル１４７に入力する。サーバ１は、各種データに基づいて推定モデル１４７での演算を行い、ユーザに推奨すべき加盟店、具体的には推奨すべき加盟店の優先順位（例えば各ＥＣサイトそれぞれに対応する確率値）を推定する。
　この場合に、例えばサーバ１は、各ユーザの購入履歴を参照して、各ＥＣサイトでユーザが購入した商品等の購入額、及び各ＥＣサイトで商品等を購入した購入頻度を評価関数として用い、学習を行う。例えばサーバ１は、各ＥＣサイトについて、購入額及び購入頻度を乗算した値を計算し、乗算値が大きいほど優先順位が高くなるように、各ＥＣサイトの優先順位の正解値を決定する。サーバ１は、入力データに基づいて推定された優先順位を、正解である優先順位と比較し、両者が近似するように、中間層で用いる各種パラメータ（重み等）を最適化する。これにより、サーバ１は、購入額及び購入頻度が高くなるＥＣサイトを推定する推定モデル１４７を生成する。
　上記の学習時に、サーバ１は購入額及び購入頻度に加えて、各ＥＣサイト（加盟店）の手数料を評価関数に加えると好適である。具体的には、サーバ１は、購入額及び購入頻度に加えて、各ＥＣサイトから支払われた手数料を乗算し、購入額、購入頻度、及び手数料の乗算値に応じて優先順位の正解値を決定する。これにより、本システムに支払う手数料が高いＥＣサイトほど優先され、トークンバックに係るサービスを好適に維持することができる。
　サーバ１は、上記で生成した推定モデル１４７に、各ユーザの購入履歴、投稿履歴、個人情報などのデータを入力し、個々のユーザに推奨すべきＥＣサイトを推定する。そしてサーバ１は、推定したＥＣサイトをユーザに提示する。
　例えばサーバ１は、図７で例示した加盟店の一覧画面を端末２が表示する場合に、推定モデル１４７を用いて各ＥＣサイトの優先順位を推定し、推定した優先順位に従って各ＥＣサイトを表示する一覧画面を出力する。なお、例えばサーバ１はバッチ処理で優先順位の推定を行っておき、一覧画面を表示する際に推定済みの優先順位に従って出力を行うようにしてもよい。端末２は、サーバ１からの出力に従い、画面の上から順に、優先順位が高いＥＣサイトを表示する。具体的には、実施の形態１と同様に、端末２は各ＥＣサイトと、各ＥＣサイトにアクセスするためのリンクボタン７１（リンク情報）とを表示する。各ＥＣサイトに対応するリンクボタン７１への操作入力を受け付けた場合、端末２はＥＣサイトにアクセスし、ユーザは商品等を購入することができる。
　上記の処理により、優先順位が高いＥＣサイト、つまりユーザがよく利用し、利用金額（購入額）も高いＥＣサイトが提示される。そしてユーザは、リンクボタン７１への操作によってＥＣサイトに簡単にアクセスすることができ、ユーザの利便性を向上させることができる。
　図１４は、推定モデル１４７の生成処理の手順を示すフローチャートである。図１４に基づき、機械学習によって推定モデル１４７を生成する処理の内容について説明する。
　サーバ１の制御部１１は、各ユーザの個人情報、商品等の購入履歴、ＳＮＳへの投稿履歴などの情報を教師データとして各データベースから読み出す（ステップＳ２０１）。購入履歴は、ユーザが購入した商品等（商品又はサービス）以外に、ユーザが商品等を購入した加盟店の加盟店ＩＤを含む。
　制御部１１は教師データを用いて、購入履歴等のデータを入力した場合に、加盟店を利用するユーザの購入行動を出力する推定モデル１４７を生成する（ステップＳ２０２）。具体的には、制御部１１は、購入履歴等を入力として、ユーザが利用すると推定される加盟店を出力とする推定モデル１４７を生成する。制御部１１は、教師用の購入履歴、投稿履歴、個人情報等のデータを推定モデル１４７に入力し、ユーザが利用する加盟店を推定する。制御部１１は、推定した加盟店と、購入額、購入頻度、手数料等に応じて推奨すべきものと定めた加盟店とを比較し、両者が近似するように中間層の各種パラメータを最適化し、推定モデル１４７を生成する。制御部１１は一連の処理を終了する。
　図１５は、実施の形態２に係るトークンバックシステムが実行する処理手順の一例を示すフローチャートである。トップ画面において左スワイプの操作入力を受け付けた場合（Ｓ１２：ＹＥＳ）、端末２は以下の処理を実行する。
　端末２の制御部２１は、加盟店の一覧画面の出力をサーバ１に要求する（ステップＳ２２１）。一覧画面の出力要求を受け付けた場合、サーバ１の制御部１１は、対象とするユーザの商品等の購入履歴、ＳＮＳへの投稿履歴、個人情報などのデータを各データベースから読み出す（ステップＳ２２２）。
　制御部１１は、読み出したデータを推定モデル１４７に入力し、対象のユーザの購入行動を推定する（ステップＳ２２３）。具体的には、制御部１１は、ユーザが利用すると推定される加盟店（ＥＣサイト）を出力として取得する。より詳細には、制御部１１は、複数の加盟店について、ユーザに推奨すべき加盟店の優先順位を取得する。制御部１１は、取得した優先順位に従って各加盟店を表示する一覧画面を端末２に出力する（ステップＳ２２４）。端末２の制御部２１は、出力された一覧画面を表示し（ステップＳ２２５）、処理をステップＳ１６に移行する。
　また、上記ではＥＣサイト（加盟店）へのリンクを提示するのみであったが、例えばサーバ１は、推定モデル１４７を用いてユーザが購入する確率が高い商品等を推定し、推定した商品等が掲載されているＥＣサイト内のページへのリンクを提示（出力）してもよい。例えばサーバ１は、各ＥＣサイトで提供する商品等と、各商品等が掲載されたＥＣサイト内のページとを対応付けて加盟店ＤＢ１４２に記憶しておき、推定モデル１４７を用いて、ユーザに推奨すべき商品等の優先順位を推定する。サーバ１は、推定した優先順位に従って、各商品等の情報を一覧画面の上から順に表示させると共に、各商品等のページにアクセスするためのリンクボタン７１（リンク情報）を表示させる。これにより、ユーザの利便性をさらに高めることができる。
　以上より、本実施の形態２によれば、推定モデル１４７を用いて加盟店を利用するユーザの購入行動を推定し、推定結果に応じた情報をユーザ宛に出力することで、消費者（ユーザ）を好適に支援することができる。
　また、本実施の形態２によれば、ユーザに推奨すべきＥＣサイト（仮想店舗）を推定し、推定したＥＣサイトにアクセスするためのリンク情報を出力する。これにより、ユーザの利便性を向上させることができる。
　また、本実施の形態２によれば、ユーザに推奨すべきＥＣサイトの優先順位を推定し、推定した優先順位に従って各ＥＣサイトを提示することで、ユーザの利便性をより向上させることができる。
　また、本実施の形態２によれば、購入額、購入頻度、及び手数料が最大化する加盟店を提示することで、より好適にユーザを支援することができる。
　また、本実施の形態２によれば、購入履歴以外にＳＮＳへの投稿履歴を入力に用いることで、加盟店におけるユーザの購入行動だけでなく、ＳＮＳ上での言動（行動）も学習することができ、購入行動の推定精度を高めることができる。
（実施の形態３）
　本実施の形態では、ユーザに付与したトークンについて、一定期間の買取保証を与える形態について説明する。
　図１６は、実施の形態３の概要を示す説明図である。図１６に基づき、本実施の形態の概要を説明する。
　実施の形態１で、本システムに係るトークンは消費を目的とせずに、加盟店からの手数料に基づいてトークンを市場から調達し、また、ユーザの保有情報に応じてトークンの付与を行うことで、長期保有を促しつつトークンの需要を創出し、価値を高める旨を説明した。本実施の形態ではさらに、付与後のトークンについて、一定の買取保証期間にある場合は、規定の買取額（交換額）でトークンを買い戻す旨の買取保証をユーザに与える。これにより、トークンの長期保有をさらに促し、相対的にトークンの価値上昇を図る。
　例えばサーバ１は、各ユーザの端末２から、付与済みのトークンについて、法定通貨への交換要求を受け付ける。具体的には、サーバ１は、交換するトークンの数量を指定する指定入力を受け付ける。なお、サーバ１はユーザの端末２ではなく、例えばユーザからの問合せを受けたオペレータから手動で交換要求の入力を受け付けるようにしてもよい。
　交換要求を受け付けた場合、サーバ１は、ユーザに付与済みのトークンの付与時点を特定する。例えばサーバ１は、付与履歴ＤＢ１４６を参照して、加盟店から承認済みであり、かつ、過去に買取保証による交換が行われていないトークンのトランザクションを特定する。そしてサーバ１は、各トランザクションによるトークンの付与時点（例えば加盟店から承認を受け付けた時点）を特定する。サーバ１は、各トランザクションによるトークンの付与時点が現時点（交換要求を受け付けた時点）から一定期間内である否かを判定する。
　例えばサーバ１は、一定期間内にあると判定したトークンのうち、付与時点が古いトークンから順に、ユーザが指定した数量のトークンを抽出する。サーバ１は、抽出したトークンを交換対象とする。なお、例えばサーバ１は、一定期間内にあると判定したトークンのトランザクションを一覧で端末２に出力し、交換対象とするトランザクションをユーザに選択させてもよい。
　サーバ１は、トークンの時価情報を取得し、トークンの交換額（買取保証額）を算出する。例えばサーバ１は、トークンを付与した時点と同じ価格になるように、トークン付与時点の時価情報を取得し、付与時点の時価に従ってトークンを法定通貨に換算した金額を算出する。
　なお、本実施の形態では、トークンの付与時点と同じ価格で買い取りを行うものとするが、交換額は付与時点の価格と同一でなくともよい。例えばサーバ１は、長期保有をさらに促すため、付与時点の価格未満の金額（例えば９０％の金額）を交換額としてもよい。また、トークンの買い取りに際して取引所での手数料などが発生するため、その手数料を減算した金額を交換額としてもよい。
　サーバ１は交換額を端末２に通知し、当該交換額での交換を承認するか否か、端末２から承認の入力を受け付ける。承認された場合、サーバ１は、トークンの送金先とするウォレットアドレスを通知し、指定したトークンの送金をユーザに促す。サーバ１は、ユーザからのトークンの送金を確認後、交換額に相当する法定通貨の送金に係る処理（例えば金融機関への送金依頼）を行う。これにより、トークンの買取を完了する。
　なお、上記で交換額を端末２に通知する場合に、単に買取保証による交換額を提示するだけでなく、現時点のトークンの市場価格、すなわち取引市場で交換した場合の交換額（第２交換額）を算出し、両者の差分をユーザに提示すると好適である。
　すなわち、サーバ１は、現時点（交換要求を受け付けた時点）のトークンの時価情報を取引所サーバ３から取得し、現時点の時価に従って、トークンを法定通貨に換算した交換額を算出する。図１６の例に則して説明すれば、付与時点が４月１日である場合に、４月１日の時価で算出した交換額とは別に、交換要求を受け付けた現時点（例えば満期の１０月１日時点）の時価で換算した金額を算出する。例えばサーバ１は、両者の金額を端末２に通知すると共に、両者の差額（差分）を通知し、ユーザに提示する。これによりユーザは、買取保証に基づく交換（買取）を行うべきか、好適に判断することができる。
　図１７は、実施の形態３に係るトークンバックシステムが実行する処理手順の一例を示すフローチャートである。
　サーバ１の制御部１１は、端末２からトークンの交換要求を受け付ける（ステップＳ３０１）。交換要求を受け付けた場合、制御部１１は、ユーザに付与済みのトークンの付与時点を特定する（ステップＳ３０２）。
　制御部１１は、ステップＳ３０１で交換要求を受け付けた時点が、ステップＳ３０２で特定したトークンの付与時点から一定期間内であるか否かを判定する（ステップＳ３０３）。一定期間内でないと判定した場合（Ｓ３０３：ＮＯ）、制御部１１は一連の処理を終了する。一定期間内であると判定した場合（Ｓ３０３：ＹＥＳ）、制御部１１は、トークンの時価情報を取得する（ステップＳ３０４）。例えば制御部１１は、トークンの付与時点と、現時点（交換要求を受け付けた時点）の時価情報を取得する。
　制御部１１は、取得した時価情報に基づき、付与時点の時価に従ったトークンの交換額を算出する（ステップＳ３０５）。また、制御部１１は、現時点の時価に従ってトークンを法定通貨に換算した交換額（第２交換額）を算出する（ステップＳ３０６）。制御部１１は、トークンの交換の承認を要求する（ステップＳ３０７）。例えば制御部１１は、付与時点の時価に基づくトークンの交換額を出力すると共に、現時点の時価に基づく交換額を出力し、両者の差分を提示する。制御部１１は、両者の金額を提示した後、最終的な承認を受け付ける。
　制御部１１は、トークンの交換が承認されたか否かを判定する（ステップＳ３０８）。承認されなかったと判定した場合（Ｓ３０８：ＮＯ）、制御部１１は一連の処理を終了する。承認されたと判定した場合（Ｓ３０８：ＹＥＳ）、制御部１１はトークンの交換に係る処理を行い（ステップＳ３０９）、一連の処理を終了する。
　なお、上記では買取保証期間が一定期間であり、買取保証額（交換額）も時価に応じた規定の金額であるものとして説明したが、例えばサーバ１は、ユーザによるトークンの保有情報に基づき、保証期間及び保証額を変動させてもよい。例えばサーバ１は、トークンをユーザに付与する場合に、ユーザによるトークンの保有量及び保有期間に応じて、保証期間及び保証額を設定し、設定内容を付与履歴ＤＢ１４６に記憶しておく。例えばサーバ１は、保有量が多く、かつ、保有期間が長いほど、保証期間を長く、かつ、保証額を多く設定する。これにより、トークンの長期保有をさらに促すことができる。交換要求を受け付けた場合、サーバ１は付与履歴ＤＢ１４６に記憶された設定内容を参照して、設定された買取保証期間内である場合、設定された買取保証額での交換を行う。
　また、上記では法定通貨との交換を行うものとして説明したが、例えば電子ポイント、又は物品など、法定通貨以外の代替物と交換を行ってもよい。すなわち、ユーザに付与したトークンを、付与時点の時価に応じた交換額と等価な代替物との交換が可能であればよく、その代替物は法定通貨に限定されない。
　また、上記ではトークンの買い取りに一定の保証期間を設けたが、保証期間を設けずともよい。すなわち、トークンの付与時点と交換要求を受け付けた時点との間の経過時間に関わらず買取保証を実施してもよい。
　また、上記では付与時点の時価に応じて交換額を定めたが、付与時点の時価に関わらず一定の交換額で交換を行ってもよい。
　以上より、本実施の形態３によれば、トークンの長期保有を促して更なる価値上昇を図ることができる。
　また、本実施の形態３によれば、買取保証額（交換額）と現時点での価格との差分を提示することで、交換を行うべきか、ユーザは好適に判断することができる。
　また、本実施の形態３によれば、保有量、保有期間等の保有情報に応じて買取保証期間及び買取額を設定することで、トークンの長期保有をより好適に促すことができる。
（変形例）
　実施の形態３では、ユーザに付与した仮想通貨の買取保証について説明した。以下では、その買取保証額を端末２に表示する際の表示例について説明する。
　図１８は、変形例に係るトップ画面の一例を示す説明図である。図１８のトップ画面は、グラフ１８１を含む。グラフ１８１は、過去の各時点でユーザが保有していたトークンを、付与時点の時価に応じて換算した買取保証額（交換額）と、各時点の時価に応じて換算した交換額（第２交換額）とを時系列で示すグラフである。例えば端末２は、過去の各時点でユーザが保有していたトークンの数量を縦棒で表示し、付与時点の時価に応じて換算した買取保証額と、各時点の時価に応じて換算した交換額とを折れ線で表示する。なお、図１８のグラフ１８１では、買取保証額を太線で、各時点の時価に応じた交換額を細線で図示している。太線は、買取保証を利用して交換した場合の金額を表す。細線は、買取保証を利用せず、一般の取引市場において交換した場合の金額を表す。
　端末２がトップ画面を表示する際に、サーバ１は、過去の各時点における両者の交換額を算出し、グラフ１８１を出力する。買取保証額を算出する場合、サーバ１は、過去の各時点について、その時点以前に付与したトークンの数量に付与時点の時価を乗算し、乗算値を積算して買取保証額を算出する。また、買取保証を利用しない場合の交換額（第２交換額）を算出する場合、サーバ１は、過去の各時点について、その時点でユーザが保有していたトークンの保有量に対し、その時点の仮想通貨の時価を乗算し、交換額を算出する。サーバ１は、過去の各時点（図１８では直近一週間の各日付）について両者の交換額を算出し、グラフ１８１として端末２に表示させる。グラフ１８１により、ユーザはトークンの買取保証が保たれていることを相場価格と比較して容易に確認することができる。
　図１９は、付与履歴画面の一例を示す説明図である。付与履歴画面は、トークンの付与履歴を表示する表示画面である。他の画面から所定のメニュー操作を受け付けた場合、端末２は図１９の付与履歴画面に遷移する。
　付与履歴画面は、付与トークン表示欄１９１、付与履歴表示欄１９２を含む。付与トークン表示欄１９１は、現在ユーザが保有するトークンの保有量、及び現在の時価を表示する表示欄である。なお、「判定中」は加盟店からの承認待ちの状態を表す。
　付与履歴表示欄１９２は、ユーザに付与したトークンの数量や付与時点の時価などを、トークン付与のトリガとなった商品等の購入情報と関連付けて表示する表示欄である。端末２は、トークン付与のトリガとなった購入情報毎に、商品等の購入額に応じて付与されたトークンの数量と、買取が保証されている付与時点の時価とを付与履歴表示欄１９２に一覧表示する。
　具体的には、端末２は、商品等を購入した加盟店の名称、購入日（利用日）等と対応付けて、付与日時（図１９では「確定日」）、付与されたトークンの数量（「還元コイン」）、付与時点の時価（「換算レート」）等を表示する。なお、「ステータス」は承認済みであるかどうかを示す。ユーザは付与履歴表示欄１９２を参照して、商品等の購入履歴と関連付けた形で、いつ付与されたトークンにどの程度の買取保証が付いているかを容易に把握することができる。
　上述の画面表示以外は実施の形態１～３と共通するため、本変形例ではフローチャートその他の詳細な説明は省略する。
　今回開示された実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、請求の範囲によって示され、請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。
　１　　　サーバ（情報処理装置）
　１１　　制御部
　１２　　主記憶部
　１３　　通信部
　１４　　補助記憶部
　Ｐ１　　プログラム
　１４１　ユーザＤＢ
　１４２　加盟店ＤＢ
　１４３　寄付先ＤＢ
　１４４　購入履歴ＤＢ
　１４５　投稿履歴ＤＢ
　１４６　付与履歴ＤＢ
　２　　　端末
　２１　　制御部
　２２　　主記憶部
　２３　　通信部
　２４　　表示部
　２５　　入力部
　２６　　撮像部
　２７　　補助記憶部
　Ｐ２　　プログラム
　３　　　取引所サーバ
　４　　　ＥＣサーバ
　５　　　発行サーバ

Claims (7)

  1. 　ユーザが保有する仮想通貨の保有量を示す第１画面を表示部に表示し、
    　前記第１画面において第１方向になぞる操作入力を受け付けた場合、複数の加盟店を一覧で示す第２画面を前記表示部に表示し、
    　前記第２画面において前記加盟店を選択する選択入力を受け付け、
    　選択された前記加盟店での商品又はサービスの購入情報を出力し、
    　前記購入情報に応じて前記ユーザに付与される前記仮想通貨の数量を取得し、
    　取得した前記仮想通貨の数量に応じて、前記第１画面に表示する前記仮想通貨の保有量を更新する
    　処理をコンピュータに実行させることを特徴とするプログラム。
  2. 　前記第１画面において、前記第１方向と異なる第２方向になぞる操作入力を受け付けた場合、前記仮想通貨を売買可能な取引所にアクセスするための第３画面を前記表示部に表示する
    　ことを特徴とする請求項１に記載のプログラム。
  3. 　前記第２画面に、電子商取引サービスを提供する仮想店舗である第１加盟店と、実店舗である第２加盟店とを一覧で表示し、
    　前記第１加盟店が選択された場合、該第１加盟店のサイトにアクセスし、
    　前記第２加盟店が選択された場合、該第２加盟店での前記購入情報を記述した媒体を撮像するための撮像モードに遷移する
    　ことを特徴とする請求項１又は２に記載のプログラム。
  4. 　前記購入情報を出力後、前記ユーザに付与される前記仮想通貨の一部の寄付を促す第４画面に遷移し、
    　前記第４画面を介した操作入力に基づき、前記仮想通貨の一部の寄付を完了後、前記第１画面に表示する前記仮想通貨の保有量を更新する
    　ことを特徴とする請求項１～３のいずれか１項に記載のプログラム。
  5. 　前記第４画面は、前記仮想通貨を寄付した旨の投稿情報をＳＮＳ（Social Networking Service）上に投稿するための画面であり、
    　前記第４画面を介した操作入力に基づき、前記投稿情報を出力し、
    　前記投稿情報の出力後、前記第１画面に表示する前記仮想通貨の保有量を更新する
    　ことを特徴とする請求項４に記載のプログラム。
  6. 　ユーザが保有する仮想通貨の保有量を示す第１画面を表示部に表示し、
    　前記第１画面において第１方向になぞる操作入力を受け付けた場合、複数の加盟店を一覧で示す第２画面を前記表示部に表示し、
    　前記第２画面において前記加盟店を選択する選択入力を受け付け、
    　選択された前記加盟店での商品又はサービスの購入情報を出力し、
    　前記購入情報に応じて前記ユーザに付与される前記仮想通貨の数量を取得し、
    　取得した前記仮想通貨の数量に応じて、前記第１画面に表示する前記仮想通貨の保有量を更新する
    　処理をコンピュータが実行することを特徴とする情報処理方法。
  7. 　ユーザが保有する仮想通貨の保有量を示す第１画面に表示する第１表示部と、
    　前記第１画面において第１方向になぞる操作入力を受け付けた場合、複数の加盟店を一覧で示す第２画面を表示する第２表示部と、
    　前記第２画面において前記加盟店を選択する選択入力を受け付ける受付部と、
    　選択された前記加盟店での商品又はサービスの購入情報を出力する出力部と、
    　前記購入情報に応じて前記ユーザに付与される前記仮想通貨の数量を取得する取得部と、
    　取得した前記仮想通貨の数量に応じて、前記第１画面に表示する前記仮想通貨の保有量を更新する更新部と
    　を備えることを特徴とする情報処理装置。
     
PCT/JP2020/009371 2019-03-05 2020-03-05 プログラム、情報処理方法及び情報処理装置 WO2020179862A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2020545377A JP6884452B2 (ja) 2019-03-05 2020-03-05 プログラム、情報処理方法及び情報処理装置

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201962813953P 2019-03-05 2019-03-05
US62/813,953 2019-03-05
JP2019132198 2019-07-17
JP2019-132198 2019-07-17

Publications (1)

Publication Number Publication Date
WO2020179862A1 true WO2020179862A1 (ja) 2020-09-10

Family

ID=72338157

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/009371 WO2020179862A1 (ja) 2019-03-05 2020-03-05 プログラム、情報処理方法及び情報処理装置

Country Status (2)

Country Link
JP (1) JP6884452B2 (ja)
WO (1) WO2020179862A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7560510B2 (ja) 2022-05-18 2024-10-02 Ｌｉｎｅヤフー株式会社 情報処理装置、情報処理方法および情報処理プログラム

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6364516B2 (ja) * 1981-03-13 1988-12-12
JP2017207938A (ja) * 2016-05-19 2017-11-24 ｏｆｆｉｃｅ ＩＳＥＡ株式会社 ポイント寄付システム
JP6475387B1 (ja) * 2018-07-17 2019-02-27 株式会社メルカリ 情報処理方法、情報処理装置、およびプログラム

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6364516B1 (ja) * 2017-03-09 2018-07-25 日本リユースシステム株式会社 情報生成システム及び情報生成方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6364516B2 (ja) * 1981-03-13 1988-12-12
JP2017207938A (ja) * 2016-05-19 2017-11-24 ｏｆｆｉｃｅ ＩＳＥＡ株式会社 ポイント寄付システム
JP6475387B1 (ja) * 2018-07-17 2019-02-27 株式会社メルカリ 情報処理方法、情報処理装置、およびプログラム

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"Financial management techniques of inevitable soaring", MAGAZINEBOX KK, KIMURA, Shigeru)", . GET FROMBITFLYER", NON-OFFICIAL TRANSLATION ("START RIGHTNOW! VIRTUAL CURRENCY., 1 February 2018 (2018-02-01), pages 56 - 59 *
ADGANG, 8 September 2017 (2017-09-08), Retrieved from the Internet <URL:https://adgang.jp/2017/09/150226.html> [retrieved on 20190000] *
VIRTUAL CURRENCY, 22 September 2017 (2017-09-22), Retrieved from the Internet <URL:https://virtual-currency.press/pluscoin_ico_plc> [retrieved on 20190000] *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7560510B2 (ja) 2022-05-18 2024-10-02 Ｌｉｎｅヤフー株式会社 情報処理装置、情報処理方法および情報処理プログラム

Also Published As

Publication number Publication date
JPWO2020179862A1 (ja) 2021-03-11
JP6884452B2 (ja) 2021-06-09

Similar Documents

Publication Publication Date Title
US20210217046A1 (en) Pos terminal(s) with free form rewards architecture
US9875469B1 (en) Bill splitting
JP6590167B2 (ja) 情報処理装置、情報処理方法、プログラム及び製造方法
JP2018060300A (ja) 購買管理システム
JP2022157746A (ja) 情報処理装置、情報処理方法、および情報処理プログラム
JP7121850B1 (ja) 情報処理装置、情報処理方法、および情報処理プログラム
JP2019128932A (ja) 情報処理装置、情報処理方法及びプログラム
JP2019139297A (ja) プログラム、情報処理装置、情報処理方法及び製造方法
WO2020179863A1 (ja) 情報処理装置、情報処理方法及びプログラム
WO2020179862A1 (ja) プログラム、情報処理方法及び情報処理装置
WO2020179861A1 (ja) 情報処理装置、情報処理方法及び学習済みモデルの生成方法
KR20200034390A (ko) 소비연동형 연금 적립 관리시스템
JP6883900B2 (ja) 情報処理装置、情報処理方法及びプログラム
JP6635536B2 (ja) 情報処理システム、情報処理方法及び情報処理装置
JP2022158810A (ja) 情報処理装置、情報処理方法、および情報処理プログラム
JP6592170B1 (ja) 情報処理方法、情報処理装置、及びプログラム
WO2023058683A1 (ja) 情報処理方法、プログラム及び情報処理装置
WO2023058685A1 (ja) 情報処理方法、プログラム及び情報処理装置
JP6999993B1 (ja) プログラム
JP7059422B2 (ja) 情報処理システム
JP6629415B1 (ja) 情報処理方法、情報処理装置、及びプログラム
JP7452946B2 (ja) 情報処理方法、情報処理装置、及びプログラム
JP6908291B2 (ja) 情報処理システム及び情報処理方法
Verma et al. To Study Effectiveness of Online Payment Modes
JP2020013583A (ja) 情報処理装置及び情報処理方法

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2020545377

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: 20767377

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: 20767377

Country of ref document: EP

Kind code of ref document: A1