WO2020144872A1 - クーポン発行装置、クーポン発行システム、クーポン発行方法およびクーポン発行プログラム - Google Patents

クーポン発行装置、クーポン発行システム、クーポン発行方法およびクーポン発行プログラム Download PDF

Info

Publication number
WO2020144872A1
WO2020144872A1 PCT/JP2019/000804 JP2019000804W WO2020144872A1 WO 2020144872 A1 WO2020144872 A1 WO 2020144872A1 JP 2019000804 W JP2019000804 W JP 2019000804W WO 2020144872 A1 WO2020144872 A1 WO 2020144872A1
Authority
WO
WIPO (PCT)
Prior art keywords
coupon
definition
point
instance
user
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/JP2019/000804
Other languages
English (en)
French (fr)
Inventor
アニス アリア アフィフィ
郁弥 小林
健祐 戸子田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
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 Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to PCT/JP2019/000804 priority Critical patent/WO2020144872A1/ja
Publication of WO2020144872A1 publication Critical patent/WO2020144872A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 coupon issuing device, a coupon issuing system, a coupon issuing method, and a coupon issuing program.
  • the present invention aims to provide a technology that streamlines the operation of a coupon issuing service.
  • the point definition regarding the point given to the predetermined action of the user based on the definition information, and the user according to the point.
  • a coupon definition for a provided coupon is created
  • the created point definition and the created coupon definition are recorded in a blockchain
  • the behavior history of the user is accepted
  • the value of the point instance of the user is based on the point definition.
  • the value of the updated point instance is recorded in the block chain, and the value of the updated point instance satisfies the condition defined in the coupon definition, the value of the coupon instance of the user is updated
  • a coupon issuing device having a control unit, which records the updated value of the coupon instance in the block chain.
  • FIG. 1 is an explanatory diagram illustrating an example of an outline of a coupon issuing device, a coupon issuing system, a coupon issuing method, and a coupon issuing program according to an embodiment.
  • FIG. 2 is an explanatory diagram showing an example of the system configuration of the hyperledger fabric.
  • FIG. 3 is an explanatory diagram showing an example of the data structure of the smart wallet chain code.
  • FIG. 4 is a block diagram showing an example of the hardware configuration of a node.
  • FIG. 5 is an explanatory diagram showing an example of the relationship of each data.
  • FIG. 6 is an explanatory diagram showing an example of a coupon definition creation sequence.
  • FIG. 7A is a flowchart (No. 1) showing an example of a procedure of processing for creating a coupon definition.
  • FIG. 1 is an explanatory diagram illustrating an example of an outline of a coupon issuing device, a coupon issuing system, a coupon issuing method, and a coupon issuing program according to an embodiment.
  • FIG. 7B is a flowchart (No. 2) showing an example of a procedure of processing for creating a coupon definition.
  • FIG. 8 is an explanatory diagram showing an example of a coupon definition update sequence.
  • FIG. 9 is a flowchart showing an example of the procedure of a coupon definition update process.
  • FIG. 10 is an explanatory diagram showing an example of a sequence of stopping the coupon new issue.
  • FIG. 11A is a flowchart (No. 1) illustrating an example of a procedure of a process of stopping the new issue of a coupon.
  • FIG. 11B is a flowchart (No. 2) showing an example of the procedure of the process of stopping the coupon new issue.
  • FIG. 12 is an explanatory diagram showing an example of the sequence of deleting the coupon definition.
  • FIG. 1 is a flowchart (No. 1) illustrating an example of a procedure of a process of stopping the new issue of a coupon.
  • FIG. 11B is a flowchart (No. 2) showing an example of the
  • FIG. 13 is a flowchart illustrating an example of a procedure of a process of deleting a coupon definition.
  • FIG. 14A is a flowchart (No. 1) showing an example of a procedure of a series of processes for issuing a coupon.
  • FIG. 14B is a flowchart (No. 2) showing an example of a procedure of a series of processing for issuing a coupon.
  • FIG. 14C is a flowchart (No. 3) showing an example of a procedure of a series of processes for issuing a coupon.
  • FIG. 15 is a flowchart showing an example of the visit API sequence.
  • FIG. 16 is a flowchart showing an example of the sequence of getCoupons API.
  • FIG. 17 is a flowchart showing an example of the sequence of the useCoupon API.
  • FIG. 1 is an explanatory diagram illustrating an example of an outline of a coupon issuing device, a coupon issuing system, a coupon issuing method, and a coupon issuing program according to an embodiment.
  • the coupon issuing system 100 is configured by a block chain (Blockchain (BC)) that is a so-called “non-centralized” distributed ledger management technology that is not operated by centralized authority.
  • BC Blockchain
  • the coupon issuing system 100 allows a code in a programming language to be added to the transaction information in the block chain, and a process called a smart contract that makes a more complex decision based on the information described in the distributed ledger. To perform.
  • the coupon issuing system 100 includes a blockchain data store 101, an administrator interface 102, a user application 103, a coupon definition creation processing unit 104, a facility usage record registration processing unit 105, and a coupon.
  • the list acquisition processing unit 106, the coupon usage processing unit 107, and the block chain API 108 are provided.
  • This system is a system that provides a coupon issuing service, and issues a coupon that the user enjoys in conjunction with the points given to the user's prescribed action.
  • the user acquires points by using the facility as a user of the facility and can acquire a coupon according to the total number of the acquired points (the number of times the facility has been used, etc.). ..
  • the acquired coupon is a mechanism that once used, one coupon is lost.
  • the contents of the coupon issuing system 100 will be described below based on this mechanism.
  • the various conditions such as the condition for acquiring points, the condition for acquiring coupons, the condition for using points, etc. are not limited to the above, and the coupon provider can arbitrarily set these conditions.
  • the blockchain data store 101 has data on two types of users, a facility user 111 and a user user 117.
  • the issue of the coupon is based on the use of the facility as described above, the provider of the coupon issuing service, that is, the issuer who issues the coupon is referred to as a “facility”.
  • a person who receives the provision of the coupon issuing service, that is, a person who enjoys the coupon by using the facility is referred to as a “user”.
  • the facility user 111 is a user for managing the definition of the coupon associated with (associated with) the “facility”.
  • the facility user 111 associates the facility coupon instance 112 of the coupon defined for the facility. Create 1 user for 1 facility. Therefore, as many facility users 111 (data) as there are facilities providing the coupon issuing service.
  • the facility coupon instance 112 is an instance for managing the coupon definition for the facility.
  • the facility coupon instance 112 is used for recognizing the combination of the point instance 118 and the coupon instance 119 that the facility usage record registration processing unit 105 should add.
  • the specific definition contents of the coupon issue are stored in the “point contract definition” 113 and the “point asset definition” 114, which are the point definitions, and the “coupon contract definition” 115 and the “coupon asset definition” 116, which are the coupon definitions. ..
  • a “point contract definition (pointContractDefinition)” 113 is a contract definition for acquiring points, and is a template for defining the coupon associated with the point instance 118.
  • the point contract definition 113 defines whether a coupon can be issued.
  • point asset definition (pointAssetDefinition)” 114 is a template for defining the coupon associated with the point instance 118.
  • the point asset definition 114 defines whether the point instance 118 is valid or invalid.
  • “coupon contract definition (couponContractDefinition)” 115 is a coupon issue contract definition, and is a template of the coupon definition associated with the coupon instance 119.
  • the coupon contract definition 115 stores the point conditions (number of facilities used, etc.) necessary for issuing a coupon.
  • Coupled asset definition (couponAssetDefinition)” 116 is a template of the definition of the coupon associated with the coupon instance 119.
  • the coupon asset definition 116 stores detailed information of the coupon such as coupon ID and expiration date.
  • the user user 117 is a user created to associate the block application instance (point instance 118, (user) coupon instance 119) with the user of the user application 103. It is created during the operation process of the user application 103. The user user 117 creates one user for one user. Therefore, there are as many user users 117 as there are users who enjoy the coupon issuing service by using the facility.
  • the point instance 118 stores the number of times the facility has been used since the coupon definition process was performed. When the value added to the point instance 118 (the number of facilities used) reaches the condition defined in the coupon contract definition 115, the value of the point instance 118 is subtracted from the value of the point instance 118 by the conversion process.
  • the (user) coupon instance 119 stores the number of coupons issued.
  • the state of the point contract definition 113/point asset definition 114 is valid and the value added to the point instance 118 (the number of facilities used) reaches the condition defined in the coupon contract definition 115, the coupon instance 119 is converted by the conversion process. 1 is added.
  • the “coupon instance 119” is also referred to as a “user coupon instance 119” in order to distinguish it from the “facility coupon instance 112”.
  • the blockchain data store 101 has such a configuration. The relationship of each data will be described in detail in FIG. 5 described later.
  • the administrator interface 102 is an interface of an administrator who manages the coupon issuing service.
  • the terminal device 150 is connected to the administrator interface 102.
  • the terminal device 150 is an information processing device operated by an administrator, and specifically, for example, the terminal device 150 is connected to a network such as the Internet such as a personal computer, a smartphone, and a tablet terminal device by wire or wirelessly. It is a possible information processing device.
  • the user application 103 is an application (upper application) used by a user who receives the coupon issuing service.
  • the user application 103 is specifically executed by the terminal device 160.
  • the terminal device 160 is an information processing device operated by a user.
  • the terminal device 160 is, for example, a smartphone, a tablet terminal device, a personal computer or the like wired or wirelessly connected to a network such as the Internet. It is an information processing device that can be connected by.
  • the terminal device 160 also includes a display that displays various screens, operation keys and buttons, and a camera that reads a QR code (registered trademark).
  • Various screens such as a QR code reading screen, a usable coupon list screen, an unused coupon detail screen, a used coupon detail screen, and a used coupon list screen are displayed on the screen displayed on the display.
  • the coupon definition creation processing unit 104 creates a facility user 111, a facility coupon instance 112, a point contract definition 113, a point asset definition 114, a coupon contract definition 115, and a coupon asset definition 116.
  • the facility user 111 creates it when the coupon definition of the facility is the first. Others are created for each type of coupon.
  • the facility usage record registration processing unit 105 adds 1 to the value of the point instance 118 for the coupon of the facility of the user user 117.
  • the point instance 118 and the coupon instance 119 of the coupon of the facility concerned do not exist for the user user 117 (the user user 117 is the first concerned after the processing by the coupon definition creation processing unit 104 of the coupon is executed). (Timing of using the facility), a point instance 118 and a coupon instance 119 of the coupon of the facility are created.
  • the facility usage record registration processing unit 105 can realize the function by, for example, a “visit API” shown in FIG. 15 and a “getCoupons API” shown in FIG. 16 described later.
  • the coupon list acquisition processing unit 106 returns all the coupons given to all the coupon instances 119 of the user user 117 to the user application 103 as a list.
  • the coupon list acquisition processing unit 106 can realize its function by, for example, “visit API” shown in FIG. 15 described later.
  • the coupon usage processing unit 107 decrements the specified coupon from the coupon instance 119 by 1. Thereby, the user can receive the privilege by the coupon, and the user who once received the privilege by the coupon can prevent the privilege by the same coupon again.
  • the coupon use processing unit 107 can realize its function by, for example, “useCoupon API” shown in FIG. 17 described later.
  • the blockchain API 108 is an API that creates, updates, and refers to the following data with respect to the distributed ledger of the blockchain.
  • the blockchain API 108 includes a user creation (API) 121, a contract definition creation (API) 122, an asset definition creation (API) 123, an instance creation (API) 124, an instance update (API) 125, and an instance reference (API) 126. It is configured to include the API.
  • the user creation (API) 121 can create the facility user 111 and the user user 117.
  • the contract definition creation (API) 122 can create the point contract definition 113 and the coupon contract definition 115.
  • the asset definition creation (API) 123 can create the point asset definition 114 and the coupon asset definition 116.
  • the instance creation (API) 124 can create the facility coupon instance 112, the point instance 118, and the coupon instance 119.
  • the instance update (API) 125 can update the facility coupon instance 112, the point instance 118, and the coupon instance 119.
  • the instance reference (API) 126 can refer to the facility coupon instance 112, the point instance 118, and the coupon instance 119.
  • Hyperledger Fabric is a distributed ledger platform and an open source blockchain platform.
  • Hyperledger Fabric is a permissioned blockchain that allows only the nodes specified by the public key to join the network and uses container technology to provide enterprise-grade security, scalability and confidentiality. Realization of a network.
  • FIG. 2 is an explanatory diagram showing an example of the system configuration of the hyperledger fabric.
  • Hyperledger Member Organizations (HMO) 200 (200 a, 200 b,...) are connected by an Orderer peer 201.
  • the orderer peer 201 is a node that collects transactions, creates a block, and sends the block to each peer.
  • the orderer peer 201 can deliver blocks to all peers in the same order.
  • the HMO 200a includes a client (Client) peer 202, endorser (Endorser) peer 203, general (General) peers 204 and 205, and anchor (Anchor) peer 206.
  • the client peer 202 is a node that sends a transaction call, that is, execution of the installed smart wallet chaincode 213, which will be described later, to the peer and makes a transaction proposal to the orderer peer 201.
  • the endorser peer 203 manages a ledger that stores two of a world state (World State (WS)) 211 and a transaction database (Transaction Database (TD)) 212.
  • the smart wallet chain code (SmartWalletChainCode) 213 is installed in the endorser peer 203. With the smart wallet chain code 213, the status of the distributed ledger can be read or updated.
  • the world state 211 is this state.
  • Each instance of the smart wallet chain code 213 has a key-value format data structure.
  • Hyperledger Fabric The processing procedure in Hyperledger Fabric is as follows (1) to (6).
  • the request is started when the application user 207 visits the facility and reads the QR code.
  • the client peer 202 selects the endorser peer 203 so as to satisfy the endorsing policy.
  • the client peer 202 creates a smart wallet chaincode execution request, sends a transaction proposal message to the endother peer 203, and requests endors (approval of the transaction execution result). Then, the created transaction is transferred to the endoser peer 203.
  • the endoser peer 203 determines the validity of the transaction and executes the smart wallet chain code 213. Then, the result message is returned to the client peer 202.
  • the client peer 202 sends the ordered transaction to the orderer peer 201, assuming that the approved transaction is legally requested and registered for the block.
  • the orderer peer 201 registers the transaction in a block and sends the block to the anchor peer 206 of the HMO 200.
  • the anchor peer 206 delivers the block to other peers 203, 204, 205 in the HMO 200a.
  • Each peer updates its ledger with the latest block.
  • the key ID of the transaction is sent, created in the block, and stored in the TD 212 of each peer.
  • the latest point balance is updated in the WS 211 of each peer. In this way, distributed ledgers can be synchronized across the network.
  • the function of the coupon issuing system in the present embodiment can be realized by using this hyperledger fabric system, for example.
  • the implementation is not limited to the hyperledger fabric system.
  • the coupon issuing system in the present embodiment may be realized using another blockchain technology, specifically, a non-centralized application execution platform such as Ethereum.
  • FIG. 3 is an explanatory diagram showing an example of the data structure of the smart wallet chain code.
  • a smart wallet chain code 213 includes a user table (userTable) 301, a wallet table (walletTable) 302, a history table (historyTable) 303, an asset definition table (assetDefinitionTable) 304, and a contract definition table (contractDefinitionTable 305). It consists of two tables.
  • the smart wallet chaincode 213 When the client peer 202 submits a transaction request to the endorser peer 203, the smart wallet chaincode 213 first retrieves user information from the business logic data store, not shown, and also the smart wallet chain code 213. The facility user is acquired from the user table 301 of the chain code 213.
  • User information is stored in the user table 301.
  • the latest point balance of each user based on the facility is stored in the wallet table 302.
  • the history table 303 stores information on transactions that have been agreed upon and their details.
  • the asset definition table 304 stores a definition relating to addition of points to a user's action (use of facilities). Points are added based on the definition defined in the asset definition table 304.
  • the contract definition table 305 stores definitions for converting points into coupons.
  • the conditions defined in the contract definition table 305 are referred to, and when the points reach the conditions, they are converted into coupons.
  • FIG. 4 is a block diagram showing an example of the hardware configuration of a node.
  • nodes (peers) 202 to 206 each have a CPU (Central Processing Unit) 401, a memory 402, a network I/F (Interface) 403, a recording medium I/F 404, and a recording medium 405. .. Further, the constituent units 401 to 404 are connected by a bus 400.
  • the CPU 401 controls the entire node.
  • the memory 402 has, for example, a ROM (Read Only Memory), a RAM (Random Access Memory), and a flash ROM.
  • a flash ROM or a ROM stores various programs, and a RAM is used as a work area of the CPU 401.
  • the program stored in the memory 402 is loaded into the CPU 401 to cause the CPU 401 to execute the coded process.
  • the network I/F 403 is connected to the network through a communication line, and is connected to other devices (for example, other nodes 201 to 206 and client terminal devices 150 and 160) via the network.
  • the network I/F 403 administers an interface between the network and the inside of the device itself, and controls the input/output of data from/to another device.
  • a modem or LAN adapter can be adopted for the network I/F 403, for example, a modem or LAN adapter can be adopted.
  • the recording medium I/F 404 controls data read/write with respect to the recording medium 405 according to the control of the CPU 401.
  • the recording medium 405 stores the data written under the control of the recording medium I/F 404. Examples of the recording medium 405 include a magnetic disk and an optical disk.
  • nodes 202 to 207 may have, for example, not shown, SSDs (Solid State Drives), keyboards, pointing devices, displays, etc., in addition to the above-described configuration units 401 to 405.
  • SSDs Solid State Drives
  • keyboards keyboards
  • pointing devices displays
  • etc. in addition to the above-described configuration units 401 to 405.
  • FIG. 5 is an explanatory diagram showing an example of the relationship of each data.
  • each data shown in FIG. 5 is data used for realizing the coupon issuing function.
  • the facility user 111 and the facility coupon instance 112 are linked (associated).
  • the facility user 111 is created when creating the initial coupon definition.
  • the facility coupon instance 112 is created for each facility.
  • a set of coupon/point definitions including a point contract definition 113, a point asset definition 114, a coupon contract definition 115, and a coupon asset definition 116 is created for each facility coupon instance 112. Therefore, a set of coupon/point definitions will be created for each facility.
  • the user user 117 is created in advance.
  • the point instance 118 and the user coupon instance 119 are associated (associated) with the user user 117. Further, the point instance 118 and the user coupon instance 119 are created for each coupon.
  • the contents of the point instance 118 are defined by the point asset definition 114, and the point instance 118 is updated by the point contract definition 113. Further, the content of the user coupon instance 119 is defined by the coupon asset definition 116, and the point contract 118 is converted to the user coupon instance 119 by the coupon contract definition 115.
  • each definition and instance is created and stored for each facility and coupon.
  • coupon issue processing can be performed.
  • FIG. 6 is an explanatory diagram showing an example of a coupon definition creation sequence. 6 the coupon definition creation is performed by "getUser” 601, "createAssetDefinition” 602, “addInstance” 603, “createAssetDefinition” 604, "createContractDefinition”60", and "createContractDefinition60" execution "60".
  • the facility user 111 is acquired, the coupon asset definition 116 is created, the facility coupon instance 112 is added (the status is “unavailable”), the point asset definition 114 is created, and the point contract definition 113 is created. Is created and the coupon contract definition 115 is created, and after the creation, the facility coupon instance 112 is updated (the status is changed from “unavailable” (making) to “available”).
  • coupon definition in the coupon issuing service can be created by creating the four definitions of the coupon asset definition 116, the point asset definition 114, the point contract definition 113, and the coupon contract definition 115.
  • step S701 it is determined whether the facility user 111 exists.
  • step S701 it is determined whether the facility user 111 exists (step S701).
  • step S702 the facility coupon instance 112 of the facility user 111 is acquired (step S702). This is the "getUser" 601.
  • step S703 it is determined whether acquisition of the facility coupon instance 112 has been successful (step S703).
  • step S703: Yes If the acquisition of the facility coupon instance 112 is successful (step S703: Yes), the process proceeds to step S710. On the other hand, if acquisition of the facility coupon instance 112 fails (step S703: No), it is determined that an error has occurred, the process is interrupted (step S704), and the series of processes is ended.
  • step S701 if the facility user 111 does not exist (step S701: No), it is determined whether or not the acquisition of the user has succeeded (step S705). Here, if the acquisition of the user has failed (step S705: No), it is determined that an error has occurred, the processing is interrupted (step S706), and the series of processing ends.
  • step S705 when the acquisition of the user is successful (step S705: Yes), the facility user 111 is created (step S707), and it is determined whether the facility user 111 has been created successfully (step S708). If the facility user 111 has been successfully created (step S708: Yes), the process proceeds to step S710. On the other hand, if the creation of the facility user 111 fails (step S708: No), it is determined that an error has occurred, the processing is interrupted (step S709), and the series of processing ends.
  • step S710 the coupon asset definition 116 is created (step S710).
  • the status is set to "available”. This is “createAssetDefinition” 602.
  • step S711 it is determined whether or not the creation of the coupon asset definition 116 has succeeded (step S711).
  • step S711: No it is determined that an error has occurred, the processing is interrupted (step S712), and the series of processing ends.
  • step S711: Yes if the creation of the coupon asset definition 116 is successful (step S711: Yes), then the facility coupon instance 112 is created (added) (step S713).
  • the status is set to "unavailable”. This is the "addInstance” 603.
  • step S714: Yes when the facility coupon instance 112 is successfully created (step S714: Yes), the process proceeds to step S716 in the flowchart of FIG. 7B.
  • step S714: No it is determined that an error has occurred, the processing is interrupted (step S715), and the series of processing ends.
  • the point asset definition 114 is created (step S716). This is “createAssetDefinition” 604. Then, it is determined whether or not the point asset definition 114 has been successfully created (step S717). If the point asset definition 114 fails to be created (step S717: No), it is determined that an error has occurred and the process is interrupted (step S718), and the series of processes is terminated.
  • step S717 if the point asset definition 114 is successfully created (step S717: Yes), then the point contract definition 113 is created (step S719).
  • the facility ID, the coupon ID, etc. are input.
  • the status is set to "available”. This is the “createContractDefinition” 605.
  • step S720 it is determined whether or not the point contract definition 113 has been successfully created (step S720). If the point contract definition 113 fails to be created (step S720: No), it is determined that an error has occurred and the processing is interrupted (step S721) and the series of processing is ended.
  • step S720: Yes if the point contract definition 113 is successfully created (step S720: Yes), then the coupon contract definition 115 is created (step S722).
  • the facility ID, the coupon ID, the condition necessary for issuing the coupon for example, the number of visits to the facility), etc. are input.
  • the status is set to "available”. This is the “createContractDefinition” 606.
  • step S723 it is determined whether or not the coupon contract definition 115 has been successfully created.
  • step S723: No it is determined that an error has occurred, the processing is interrupted (step S724), and the series of processing ends.
  • step S723: Yes if the coupon contract definition 115 is successfully created (step S723: Yes), then the facility coupon instance 112 is created (updated) (step S725).
  • the facility ID, the coupon ID, etc. are input.
  • the status is changed from "unavailable” (currently being created) to "available (currently being issued)”. This is the "updateInstance” 607.
  • step S726 it is determined whether the facility coupon instance 112 has been successfully created.
  • step S726: Yes if the creation of the facility coupon instance 112 has succeeded (step S726: Yes), a series of processing ends.
  • the coupon definition can be created and reflected in the distributed ledger (TD212). That is, the created coupon definition can be recorded in the block chain.
  • reflecting on the distributed ledger has the same meaning as recording on the blockchain.
  • step S726 No
  • step S727 the processing is interrupted (step S727), and the series of processing is ended.
  • FIG. 8 is an explanatory diagram showing an example of a coupon definition update sequence.
  • the coupon definition update is executed in the sequence of “getlnstance” 801 ⁇ “updateInstance” 802 ⁇ “updateContractDefinition” 803 ⁇ “updateInstance” 804.
  • the facility coupon instance 112 is acquired, the facility coupon instance 112 is updated (the status is changed from “issuing” to “processing”), the coupon contract definition 115 is updated, and the facility coupon instance 112 is updated after the update. Update (change the status from "Processing” to "Issuing”).
  • coupon contract definition 115 it is possible to update the coupon definition, which is a change in the service content of the coupon issuing service. Specifically, for example, when changing the conventional coupon definition "acquire 1 coupon with 3 points" to "coupon definition with 5 points", the content of the coupon contract definition 115 is simply updated. You can easily update the coupon definition.
  • point definition is desired to be updated, it can be done by updating the point contract definition 113.
  • the point definition is desired to be updated, it can be done by updating the point contract definition 113.
  • the contents of the point contract definition 113 You can easily update the point definition simply by updating.
  • the point contract definition 113 and the coupon contract definition 115 can be updated.
  • the conventional coupon definition of "acquiring 1 point with one use of facility” was changed to the point definition of "acquiring 2 points with one use of facility”
  • the conventional "3 points with When changing the coupon definition "acquiring 1 coupon” to the coupon definition "acquiring 1 coupon with 5 points” simply updating the contents of the point contract definition 113 and the coupon contract definition 115 makes it easy to obtain the point definition/coupon.
  • the definition can be updated at the same time.
  • FIG. 9 is a flowchart showing an example of the procedure of the coupon definition update processing.
  • the facility coupon instance 112 of the facility user is acquired (step S901). This is "getInstance” 801. Then, it is determined whether or not the facility coupon instance 112 exists (step S902).
  • step S902 if the facility coupon instance 112 does not exist (step S902: No), it is determined that an error has occurred, the processing is interrupted (step S903), and the series of processing ends.
  • step S902 when the facility coupon instance 112 exists (step S902: Yes), it is determined whether or not the status of the facility coupon instance 112 is “available (issued)” (step S904).
  • step S904 if the status is not "available” (step S904: No), it is determined that an error has occurred, the processing is interrupted (step S905), and the series of processing ends.
  • step S904 when the status is “available” (step S904: Yes), the facility coupon instance 112 is updated (step S906).
  • the facility ID, the coupon ID, etc. are input.
  • the status is changed from "available (issuing)” to "processing (processing)". This is the "updateInstance” 802.
  • step S907 it is determined whether or not the facility coupon instance 112 has been updated successfully (step S907).
  • step S907: No if the update of the facility coupon instance 112 has failed (step S907: No), it is determined that an error has occurred, the processing is interrupted (step S908), and the series of processing ends.
  • step S909 the coupon contract definition 115 is updated (step S909).
  • the facility ID, the coupon ID, the number of facility visits necessary for issuing the coupon, etc. are input. This is the “updateContractDefinition” 803.
  • step S910 it is determined whether or not the coupon contract definition 115 has been updated successfully.
  • step S910 if the coupon contract definition 115 has been updated successfully (step S910: Yes), then the facility coupon instance 112 is updated (step S912).
  • the facility ID, the coupon ID, etc. are input.
  • the status is changed from "processing (processing)" to "available (issuing)”. This is the “updateInstance” 804.
  • step S913 it is determined whether or not the facility coupon instance 112 has been updated successfully (step S913).
  • step S913 if the facility coupon instance 112 has been successfully updated (step S913: Yes), the series of processes ends. In this way, the coupon definition can be updated and reflected in the distributed ledger (TD212).
  • step S913 if the updating of the facility coupon instance 112 has failed (step S913: No), it is determined that an error has occurred and the processing is interrupted (step S914). However, in this case, the status of the facility coupon instance 112 remains “processing (processing)” and does not return to “available (issuing)”, and the status of the facility coupon instance 112 is “processing (processing)”. Since the state of “” is maintained, a result to that effect is output, and a series of processing is ended. In this case, the issue of the coupon is not resumed, and therefore some extra allowance is required.
  • FIG. 10 is an explanatory diagram showing an example of a sequence for stopping the new issue of a coupon.
  • the coupon definition update is executed in the sequence of “getlnstance” 1001 ⁇ “updatelnstance” 1002 ⁇ “updateContractDefinition” 1003 ⁇ “updateContractDefinition” 1004 ⁇ “updateInstance” 1005.
  • the facility coupon instance 112 is acquired, the facility coupon instance 112 is updated (the status is changed to "processing"), and then the coupon contract definition 115 is updated (the number of digits of facility visits is set to a fixed value, The status is changed from “Issuing” to “Issued stopped”, and the point contract definition 113 is updated (The status is changed from “Issuing” to “Issued stopped”). Then, after updating them, the status of the facility coupon instance 112 is updated (changed from “in process” to “issue stopped”).
  • FIG. 11A and FIG. 11B are flowcharts showing an example of a procedure of a process for stopping the new issue of a coupon.
  • the facility coupon instance 112 of the facility user is acquired (step S1101). This is "getInstance” 1001. Then, it is determined whether or not the facility coupon instance 112 exists (step S1102).
  • step S1102 if the facility coupon instance 112 does not exist (step S1102: No), it is determined that an error has occurred, the processing is interrupted (step S1103), and the series of processing ends.
  • step S1102 when the facility coupon instance 112 exists (step S1102: Yes), it is determined whether the facility coupon instance 112 has been acquired (step S1104).
  • step S1104: No when the facility coupon instance 112 cannot be acquired (step S1104: No), it is determined that an error has occurred, the processing is interrupted (step S1105), and the series of processing ends.
  • step S1104 the facility coupon instance 112 is updated (step S1106).
  • the facility ID, the coupon ID, etc. are input.
  • the status is set to “processing”. This is the "updateInstance” 1002.
  • step S1107 it is determined whether or not the facility coupon instance 112 has been updated successfully.
  • step S1107: No it is determined that an error has occurred, the processing is interrupted (step S1108), and the series of processing ends.
  • step S1107 YES
  • the coupon contract definition 115 is updated (step S1109).
  • a facility ID, a coupon ID, a fixed value with a large number of digits, etc. are input as the number of facility visits required for issuing a coupon. Further, the status is set to "stopped (issue stopped)”. This is “updateContractDefinition” 1003. After that, the process proceeds to step S1110 of the flowchart in FIG. 11B.
  • step S1110 it is determined whether or not the coupon contract definition 115 has been updated successfully.
  • step S1110: No when the update of the coupon contract definition 115 fails (step S1110: No), the process proceeds to step S1115.
  • step S1110: Yes if the coupon contract definition 115 has been updated successfully (step S1110: Yes), then the point contract definition 113 is updated (step S1111).
  • the facility ID, the coupon ID, etc. are input. Further, the status is set to "stopped (issue stopped)". This is the “updateContractDefinition” 1004. Then, it is determined whether or not the point contract definition 113 has been updated successfully (step S1112).
  • step S1112: No If the point contract definition 113 fails to be updated in step S1112 (step S1112: No), the process proceeds to step S1115.
  • step S1112: Yes when the point contract definition 113 is updated successfully (step S1112: Yes), the facility coupon instance 112 is updated next (step S1113).
  • the facility ID, the coupon ID, etc. are input. Further, the status is changed from "processing (processing)" to "stopped (issue stopped)”. This is “updateInstance” 1005. Then, it is determined whether or not the facility coupon instance 112 has been updated successfully (step S1114).
  • step S1114: Yes if the facility coupon instance 112 has been successfully updated (step S1114: Yes), the series of processes is terminated. In this way, the coupon definition can be updated and reflected in the distributed ledger (TD212). On the other hand, if the update of the facility coupon instance 112 has failed (step S1114: No), the process proceeds to step S1118.
  • step S1110 If the update fails in step S1110 (step S1110: No), or if the update fails in step S1112 (step S1112: No), it is determined that an error has occurred in step S1115 and the processing is interrupted ( Step S1115). However, in this case, since the status of the facility coupon instance 112 is still “processing (processing)”, the facility coupon instance 112 is updated and the status is changed from “processing (processing)” to “available (issuing). To “” (step S1116).
  • step S1117 it is determined whether or not the facility coupon instance 112 has been updated successfully. If the facility coupon instance 112 has been successfully updated (step S1117: Yes), the series of processes ends. As a result, it is possible to avoid that the status of the facility coupon instance 112 remains "processing (processing)", although the stop of the new coupon issue has failed.
  • step S1118 if the facility coupon instance 112 has failed to be updated (step S1117: No), it is determined that an error has occurred, and the result is output (step S1118). However, in this case, the status of the facility coupon instance 112 remains “processing (processing)” and does not return to “available (issuing)”, and the status of the facility coupon instance 112 is “processing (processing)”. As it is maintained as it is, some extra allowance is required.
  • FIG. 12 is an explanatory diagram showing an example of the sequence of deleting the coupon definition.
  • the deletion of the coupon definition is executed in the sequence of “getInstance” 1201 ⁇ “updateInstance” 1202 ⁇ “updateContractDefinition” 1203 ⁇ “updateAssetDefinition” 1204.
  • the facility coupon instance 112 is updated (the status is changed to "deleted")
  • the coupon contract definition 115 is updated (the number of digits with a large number of facility visits is set to a fixed value, and the status is changed from “issued” to " Deleted”) and the point contract definition 113 is updated (the status is changed from “issuing” to “deleted”).
  • the coupon asset definition 116 is updated (the status is changed from “issued” to “deleted”), and the point asset definition 114 is updated (status is changed from “issued” to “deleted”).
  • FIG. 13 is a flowchart showing an example of a procedure of a process of deleting a coupon definition.
  • the facility coupon instance 112 is acquired and updated (step S1301).
  • the facility ID, the coupon ID, etc. are input.
  • the status is set to “deleted”. These are "getInstance” 1201 and "updateInstance” 1202.
  • step S1302 it is determined whether or not the facility coupon instance 112 has been updated successfully (step S1302).
  • step S1302 if the updating of the facility coupon instance 112 has failed (step S1302: No), it is determined that an error has occurred, the processing is interrupted (step S1303), and the series of processing ends.
  • step S1304 if the facility coupon instance 112 has been successfully updated (step S1302: Yes), then the coupon contract definition 115 is updated (step S1304).
  • a facility ID, a coupon ID, a fixed value with a large number of digits, etc. are input as the number of facility visits required for issuing a coupon.
  • the status is set to “deleted”. This is the "updateContractDefinition" 1203. Then, it is determined whether or not the coupon contract definition 115 has been updated successfully (step S1305).
  • step S1305 if the update of the coupon contract definition 115 fails (step S1305: No), an error is output and the process continues (step S1306). Then, it transfers to step S1307. This is because if the processing is interrupted when an error occurs, the subsequent processing does not operate and the definition remains undeleted.
  • step S1305 if the coupon contract definition 115 is updated successfully (step S1305: Yes), the point contract definition 113 is updated next (step S1307).
  • the facility ID, the coupon ID, etc. are input.
  • the status is set to “deleted”. This is also the “updateContractDefinition” 1203. Then, it is determined whether or not the point contract definition 113 has been updated successfully (step S1308).
  • step S1308: No if the update of the point contract definition 113 fails (step S1308: No), an error is output and the process continues (step S1309). Then, it transfers to step S1310. If the point contract definition 113 has been updated successfully (step S1308: Yes), the process proceeds to step S1310.
  • coupon asset definition 116 is updated (step S1310).
  • the facility ID, the coupon ID, etc. are input.
  • the status is set to “deleted”. This is the “updateAssetDefinition” 1204.
  • step S1311: No if the update of the coupon asset definition 116 has failed (step S1311: No), an error is output and the process continues (step S1312). Then, it transfers to step S1313.
  • step S1311: Yes When the update of the coupon asset definition 116 is successful (step S1311: Yes), the process proceeds to step S1313.
  • the point asset definition 114 is updated (step S1313).
  • the facility ID, the coupon ID, etc. are input.
  • the status is set to “deleted”. This is also “updateAssetDefinition” 1204.
  • it is determined whether or not the point asset definition 114 has been updated successfully step S1314.
  • the update of the point asset definition 114 has failed (step S1314: No)
  • it is output that an error has occurred the processing continues (step S1315), and the series of processing ends.
  • the point asset definition 114 is updated successfully (step S1314: Yes)
  • the series of processes is ended.
  • the user coupon instance 119 of the user may be deleted.
  • FIG. 14A to 14C are flowcharts showing an example of a procedure of a series of processes for issuing a coupon.
  • the user scans the displayed QR code with a smartphone or the like owned by the user (step S1401).
  • step S1402 Record the scanned QR code in a predetermined storage area (step S1402).
  • This process can be executed by business logic (for example, a business logic API (not shown)). After that, the processing is performed in the block chain.
  • step S1403 the visitAPI is activated when the QR code is stored (step S1403). Details of the processing in the visitAPI will be described later with reference to FIG. After that, the processing is performed by the coupon issuing function in the block chain.
  • the client peer 202 generates a transaction request and distributes it to the endother peer 203 (step S1404). After that, the process is performed by the endoser peer 203.
  • the endorser peer 203 executes the smart wallet chain code 213 (step S1405), and then moves to step S1411 in the flowchart of FIG. 14B. After that, the processing is performed by the smart wallet chain code 213.
  • the endorser peer 203 confirms the user information in the world state (WS) 211 (step S1406). Then, it is determined whether or not there is the latest user information in the WS 211 (step S1407), and if there is the latest user information (step S1407: Yes), the latest user information is acquired (step S1408). If there is no latest user information (step S1407: No), nothing is done. After that, the process proceeds to step S1413 of the flowchart in FIG. 14B, and the process by the smart wallet chain code 213 is performed.
  • the flowchart of FIG. 14B shows the contents of processing in the smart wallet chain code.
  • the facility user information is acquired from the user table 301 (step S1411). Then, it is determined whether there is a facility user (step S1412).
  • step S1412 if the facility user does not exist (step S1412: No), the series of processes ends. On the other hand, when the facility user exists (step S1412: YES), it is next determined whether or not the user ID and the facility ID are recorded in the wallet table 302 (step S1413).
  • step S1413: Yes the latest user information is acquired (step S1414), and the process proceeds to step S1417.
  • step S1413: No the process proceeds to step S1417 without doing anything.
  • step S1415 the point contract definition 113 is acquired from the contract definition table 305 (step S1415). Then, the point asset definition 114 is created in the asset definition table 304 based on the acquired point contract definition 113 (step S1416), and the process proceeds to step S1417. In step S1417, the point asset definition 114 is confirmed (step S1417). Here, check how many points are required to get the coupon. Then, it transfers to step S1420.
  • the smart wallet chain code 213 acquires the coupon contract definition 115 from the contract definition table 305 (step S1418). Then, based on the acquired coupon contract definition 115, the coupon asset definition 116 is created in the asset definition table 304 (step S1419), and the process proceeds to step S1420.
  • step S1420 the coupon asset definition 116 is confirmed (step S1420).
  • the list of the coupon asset definitions 116 whose status is “available” is being confirmed.
  • step S1421 if there is one that has reached the predetermined number of points (step S1421: Yes), the number of points is subtracted from the wallet (point instance 118) (step S1422), and instead, the wallet (user A coupon is added to the coupon instance 119) (step S1423). Then, the history table 303 is updated (step S1424), and the response is returned to the endoser peer 203 (step S1425). The processing up to this point is the processing in the smart wallet chain code 213. Then, it transfers to step S1431 and S1432 of the flowchart of FIG. 14C.
  • the endoser peer 203 updates the TD 212 based on the temporary execution result of updating the history table 303 performed in step S1424 of FIG. 14B (step S1431). Then, the process proceeds to steps S1437 and S1438.
  • the endoser peer 203 also sends a response to the client peer 202 (step S1432) and moves to step S1433.
  • the processing up to here is the processing in the endoser peer 203.
  • step S1433 when the client peer 202 receives the response from the endother peer 203, the client peer 202 sends the response to the orderer peer 201 (step S1433).
  • the agreed temporary execution result is described in the block (step S1434). Then, the new block is distributed to all HMOs 200 (step S1435). Next, the anchor peer 206 delivers the new block to all peers (step S1436).
  • the TD 212 is updated to the latest valid block in all peers (step S1437). Also, the key ID is confirmed, the user information in the WS is updated to the latest state (step S1438), and the series of processes is ended.
  • FIG. 15 is a flowchart showing an example of the visit API sequence.
  • the visit API is an API that is activated when a QR code is recorded as shown in FIG. 14A described above.
  • step S1501 a user ID and a facility ID are input (step S1501). Then, it is determined whether or not the user ID exists (step S1502). Here, when the user ID does not exist (step S1502: No), the output type: “user not found” is output (step S1503), and a series of processing ends.
  • step S1502 if the user ID exists (step S1502: Yes), it is determined whether or not there is a facility corresponding to the input facility ID (step S1504).
  • step S1504 if the facility does not exist (step S1504: No), the output type: “normally completed” is output (step S1505), and the series of processes ends.
  • step S1504 when the facility exists (step S1504: Yes), the coupon definition list is acquired (step S1506). Then, it is determined whether or not the status of the coupon is "available (issued)" (step S1507). If the status is not “available” (step S1507: NO), the procedure goes to step S1514.
  • step S1507: Yes it is determined whether the user has created the point instance 118 (step S1508). If the point instance 118 has been created (step S1508: Yes), the point instance 118 is updated (step S1509). When the point instance 118 has not been created (step S1508: No), the point instance 118 is created (step S1510).
  • step S1511 it is determined whether the user has created the coupon instance 119 (step S1511).
  • step S1511: Yes when the coupon instance 119 has been created (step S1511: Yes), the process proceeds to step S1513. If the coupon instance 119 has not been created (step S1511: No), the coupon instance 119 is created (step S1512) and the process proceeds to step S1513.
  • step S1514 it is determined whether there is a coupon (step S1514). If there is a coupon (step S1514: Yes), the process returns to step S1507, and the processes of steps S1507 to S1514 are performed until the coupon is exhausted. Repeat. After that, when all the coupons are exhausted (step S1514: No), the output type: “normally completed” is output (step S1515), and the series of processes is ended.
  • FIG. 16 is a flowchart showing an example of the sequence of getCoupons API.
  • getCoupons API is an API that is activated when a coupon is acquired.
  • step S1601 a user ID and a facility ID are input (step S1601). Then, it is determined whether or not the user ID exists (step S1602). Here, when the user ID does not exist (step S1602: No), the output type: “user not found” is output (step S1603), and the series of processes is ended. On the other hand, when the user ID exists (step S1602: Yes), the instance list is acquired (step S1604).
  • step S1605 one instance is extracted from the instance list, and it is determined whether the instance is the coupon instance 119 (step S1605).
  • step S1605: No the process proceeds to step S1608.
  • step S1605: Yes it is determined whether the quantity (quantity) is 1 or more (step S1606).
  • step S1606: Yes If it is 1 or more (step S1606: Yes), the coupon is added to the return array (step S1607), and the process proceeds to step S1608. On the other hand, if it is not 1 or more (step S1606: NO), the process proceeds to step S1608 without doing anything.
  • step S1608 it is determined whether or not there is an unprocessed instance in the instance list (step S1608), and if there is still an instance (step S1608: Yes), the procedure returns to step S1605 and until there are no more instances.
  • the processing of steps S1605 to S1608 is repeated. After that, when all the instances have disappeared (step S1608: No), the output type: “return array” is output (step S1609), and the series of processes ends. Thereby, the coupon existing in the user's coupon instance 119 can be extracted.
  • FIG. 17 is a flowchart showing an example of the sequence of the useCoupon API.
  • the useCoupon API is an API that is activated when the user uses a coupon.
  • a user ID, a facility ID and a coupon ID are input (step S1701). Then, it is determined whether or not the user ID exists (step S1702). Here, when the user ID does not exist (step S1702: No), the output type: “user not found” is output (step S1703), and the series of processes is ended. On the other hand, when the user ID exists (step S1702: Yes), it is determined whether the facility ID exists (step S1704).
  • step S1704 determines whether the coupon contract definition 115 exists (step S1706).
  • step S1706 determines whether the coupon contract definition 115 exists (step S1706).
  • step S1707 the output type: “Coupon not found” is output (step S1707), and the series of processes ends.
  • step S1706 when the coupon contract definition 115 exists (step S1706: Yes), it is determined whether or not the status of the coupon contract definition 115 is “deleted” (step S1708).
  • step S1708 when the status is "deleted” (step S1708: Yes), the output type: "Coupon has been deleted” is output (step S1709), and the series of processes is ended.
  • step S1708 when the status of the coupon contract definition 115 is not "deleted" (step S1708: No), the acquisition of the coupon instance 119 is tried (step S1710). Then, it is determined whether or not the acquisition of the coupon instance 119 has succeeded (step S1711).
  • step S1711 when acquisition of the coupon instance 119 fails (step S1711: No), the output type: “I do not have a coupon” is output (step S1712), and a series of processing ends.
  • step S1711 Yes
  • step S1713 the quantity (quantity) is 1 or more
  • step S1714 the output type: “I do not have a coupon” is output (step S1714), and a series of processing is ended.
  • step S1713: Yes the coupon instance 119 is updated (step S1715), and it is determined whether the update is successful (step S1716).
  • step S1716: No the update has failed (step S1716: No)
  • step S1717: Yes the update has failed (step S1716: No)
  • step S1718 the output type: “normally completed” is output (step S1718) and the series of processes is ended. Thereby, the user can use the acquired coupon.
  • the point definition (point contract definition 113, point asset definition 114) and the points regarding the points given to the predetermined action of the user and the points.
  • An instance 118, a coupon definition (coupon contract definition 115, coupon asset definition 116) and a coupon instance 119 related to a coupon that the user enjoys in conjunction with points are created and reflected in a distributed ledger (TD212), and
  • TD212 distributed ledger
  • the value of the point instance 118 is updated based on the point contract definition 113 and reflected in the distributed ledger (TD212), and the value of the point instance 118 is based on the coupon contract definition 115.
  • the condition defined in the contract definition 115 is reached, the value of the coupon instance 119 is updated and reflected in the distributed ledger (TD212), that is, recorded in the block chain. Have.
  • the coupon issuing service is realized by the block chain, it is possible to have the effects such as security, scalability, and confidentiality that the block chain has.
  • the block chain (TD212) includes a first script that creates a point instance 118 according to the point definition and a second script that creates a coupon instance 119 according to the coupon definition.
  • the control unit (endor peer 203) detects that a new user has been registered, it executes the first script and the second script, thereby creating a new one according to the point definition.
  • a new point instance 118 and a new coupon instance 119 corresponding to the coupon definition can be created in association with a new user, and the created point instance 118 and coupon instance 119 can be recorded in the block chain (TD212). ..
  • the coupon issuing service is created by creating the point asset definition 114, the point contract definition 113, the coupon asset definition 116, and the coupon contract definition 115 and reflecting them in the distributed ledger (TD212). Since it is registered in, the coupon issue service can be easily registered.
  • the contents of the coupon issuing service are changed by updating at least one of the point contract definition 113 and the coupon contract definition 115 and reflecting them in the distributed ledger (TD212). It is possible to easily change the content of the issuing service.
  • the coupon issuing service Since the new issue of the coupon is stopped, the new issue of the coupon in the coupon issuing service can be easily stopped.
  • the point asset definition 114, the point contract definition 113, the coupon asset definition 116, and the coupon contract definition 115 are updated and reflected in the distributed ledger (TD212), so that the coupon issuing service Since it is deleted, it is possible to easily delete (discontinue) the coupon issuing service.
  • control unit endor peer 203 uses the smart wallet chain code 213 of the block chain, so that the management of each definition can be automated.
  • the coupon issuing method described in the present embodiment can be realized by executing a program prepared in advance on a computer such as a personal computer or a workstation.
  • the coupon issuing program can be read by a computer such as a hard disk, a flexible disk, a CD (Compact Disc)-ROM, an MO (Magneto-Optical Disk), a DVD (Digital Versatile Disk), a flash memory, or a USB (Universal Serial Bus) memory. It is recorded on a recording medium and executed by being read from the recording medium by a computer. Further, the coupon issuing program may be distributed via a network such as the Internet.
  • Coupon Issuing System 101 Block Chain Data Store 102 Administrator Interface 103 User Application 104 Coupon Definition Creation Processing Unit 105 Facility Usage Result Registration Processing Unit 106 Coupon List Acquisition Processing Unit 107 Coupon Usage Processing Unit 108 Block Chain API 111 Facility User 112 Facility Coupon Instance 113 Point Contract Definition 114 Point Asset Definition 115 Coupon Contract Definition 116 Coupon Asset Definition 117 User User 118 Point Instance 119 (User) Coupon Instance 200a, 200b Hyperledger Member Organization (Hyperledger Member Organization) (HMO)) 201 Orderer Peer 202 Client Peer 203 Endorser Peer 204, 205 General Peer 206 Anchor Peer 211 World State (WS) 212 Transaction Database (TD) 213 Smart Wallet Chain Code 301 User table (userTable) 302 Wallet Table 303 history table (historyTable) 304 Asset definition table (assetDefinitionTable) 305 Contract definition table (contractDefinitionTable)

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Development Economics (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Game Theory and Decision Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

クーポン発行サービスに関する定義情報の入力を受け付けると、定義情報に基づき、ユーザの所定の行動に対して付与されるポイントに関するポイント定義（１１３、１１４）、および、ポイントに応じてユーザに提供されるクーポンに関するクーポン定義（１１５、１１６）を作成して、ブロックチェーン（分散台帳）に記録させ、ユーザの行動履歴を受け付けた場合、ポイント定義（１１３）に基づき、ユーザのポイントインスタンス（１１８）の値を更新して、ブロックチェーンに記録させ、更新したポイントインスタンスの値がクーポン定義（１１５）に定められた条件を満たす場合、ユーザのクーポンインスタンス（１１９）の値を更新して、ブロックチェーンに記録させることで、ブロックチェーンによる、クーポン発行サービスの運営を効率化する技術を提供することができる。

Description

クーポン発行装置、クーポン発行システム、クーポン発行方法およびクーポン発行プログラム
　本発明は、クーポン発行装置、クーポン発行システム、クーポン発行方法およびクーポン発行プログラムに関する。
　従来、ユーザの所定の行動に対して、当該ユーザに対して電子クーポンがネットワークを介して提供されるクーポン発行サービスが存在する。
　関連する先行技術としては、投票者から移動要求があった場合に、被投票者用のウォレットから投票者の投票者用のウォレットへの仮想資産を移動する取引を記録するブロックチェーンから、仮想資産を移動する取引の総数を、被投票者ごとに算出する技術がある。
特開２０１８－０５５４７３号公報
　しかしながら、従来技術にあっては、そのクーポン発行サービスに参加するユーザが新規に発生する都度、なんらかの設定作業が必要になるとすれば、サービスの運用者にとって大変な手間になるという問題点がある。また、ユーザによるサービス利用の申し込みからサービスの開始までの時間もかかってしまい、ユーザの満足度が低下してしまうという問題点がある。特に、ユーザ数やクーポンの種類が大幅に増加した場合には、これらの問題は顕著になり、クーポン発行サービスの運営に支障を来す虞れがある。
　一つの側面では、本発明は、クーポン発行サービスの運営を効率化する技術を提供することを目的とする。
　一つの実施態様では、クーポン発行サービスに関する定義情報の入力を受け付けると、前記定義情報に基づき、ユーザの所定の行動に対して付与されるポイントに関するポイント定義、および、前記ポイントに応じて前記ユーザに提供されるクーポンに関するクーポン定義を作成し、作成した前記ポイント定義および前記クーポン定義をブロックチェーンに記録させ、前記ユーザの行動履歴を受け付けた場合、前記ポイント定義に基づき、前記ユーザのポイントインスタンスの値を更新し、更新した前記ポイントインスタンスの値を前記ブロックチェーンに記録させ、更新した前記ポイントインスタンスの値が前記クーポン定義に定められた条件を満たす場合、前記ユーザのクーポンインスタンスの値を更新し、更新した前記クーポンインスタンスの値を前記ブロックチェーンに記録させる、制御部を有するクーポン発行装置が提供される。
　本発明の一側面によれば、クーポン発行サービスの運営を効率化する技術を提供することができる。
図１は、実施の形態にかかるクーポン発行装置、クーポン発行システム、クーポン発行方法およびクーポン発行プログラムの概要の一例を示す説明図である。 図２は、ハイパーレッジャー・ファブリックのシステム構成の一例を示す説明図である。 図３は、スマートウォレット・チェーンコードのデータ構成の一例を示す説明図である。 図４は、ノードのハードウェア構成の一例を示すブロック図である。 図５は、各データの関係性の一例を示す説明図である。 図６は、クーポン定義作成のシーケンスの一例を示す説明図である。 図７Ａは、クーポン定義作成の処理の手順の一例を示すフローチャート（その１）である。 図７Ｂは、クーポン定義作成の処理の手順の一例を示すフローチャート（その２）である。 図８は、クーポン定義更新のシーケンスの一例を示す説明図である。 図９は、クーポン定義更新の処理の手順の一例を示すフローチャートである。 図１０は、クーポン新規発行の停止のシーケンスの一例を示す説明図である。 図１１Ａは、クーポン新規発行の停止の処理の手順の一例を示すフローチャート（その１）である。 図１１Ｂは、クーポン新規発行の停止の処理の手順の一例を示すフローチャート（その２）である。 図１２は、クーポン定義の削除のシーケンスの一例を示す説明図である。 図１３は、クーポン定義の削除の処理の手順の一例を示すフローチャートである。 図１４Ａは、クーポン発行の一連の処理の手順の一例を示すフローチャート（その１）である。 図１４Ｂは、クーポン発行の一連の処理の手順の一例を示すフローチャート（その２）である。 図１４Ｃは、クーポン発行の一連の処理の手順の一例を示すフローチャート（その３）である。 図１５は、ｖｉｓｉｔ　ＡＰＩのシーケンスの一例を示すフローチャートである。 図１６は、ｇｅｔＣｏｕｐｏｎｓ　ＡＰＩのシーケンスの一例を示すフローチャートである。 図１７は、ｕｓｅＣｏｕｐｏｎ　ＡＰＩのシーケンスの一例を示すフローチャートである。
　以下に図面を参照して、本発明にかかるクーポン発行装置、クーポン発行システム、クーポン発行方法およびクーポン発行プログラムの実施の形態を詳細に説明する。
（実施の形態）
（クーポン発行処理の概要）
　図１は、実施の形態にかかるクーポン発行装置、クーポン発行システム、クーポン発行方法およびクーポン発行プログラムの概要の一例を示す説明図である。図１においては、クーポン発行システム１００は、中央集権による運用ではない、いわゆる「非中央集権的な」分散台帳管理技術であるブロックチェーン（Ｂｌｏｃｋｃｈａｉｎ（ＢＣ））によって構成される。
　そして、クーポン発行システム１００は、そのブロックチェーンにおいて、取引情報にプログラミング言語によるコードも追加できるようにし、分散台帳に記載された情報に基づいて、より複雑な判断をするスマートコントラクトと呼ばれる機能による処理をおこなう。
　図１に示すように、クーポン発行システム１００は、ブロックチェーン・データストア１０１と、管理者インタフェース１０２と、ユーザアプリケーション１０３と、クーポン定義作成処理部１０４と、施設利用実績登録処理部１０５と、クーポン一覧取得処理部１０６と、クーポン利用処理部１０７と、ブロックチェーンＡＰＩ１０８と、を備えている。
　このシステムは、クーポン発行サービスを提供するシステムであり、ユーザの所定の行動に対して付与されるポイントに連動して当該ユーザが享受するクーポンを発行する。その一例として、ユーザが施設の利用者として当該施設を利用することによってポイントを取得し、取得したポイント（当該施設の利用回数など）の合計数に応じてクーポンを獲得できるシステムを想定している。
　より具体的には、たとえば、ユーザが、当該施設を１回利用するごとに１ポイントを取得し、３ポイントすなわち施設を３回利用すると、その３ポイントと引き替えに、クーポンを一つ獲得できるシステムである。
　このシステムによれば、施設を１回利用すると１ポイントでクーポンはなし（０クーポン）、２回利用すると２ポイントでクーポンはなし（０クーポン）、３回利用すると１クーポンおよび０ポイント、４回利用すると１クーポンおよび１ポイント、５回利用すると１クーポンおよび２ポイント、６回利用すると２クーポンおよび０ポイント、・・・というように、施設の利用回数に応じて、ユーザのポイントあるいはクーポンが増える仕組みである。
　また、クーポンにより特典が受けられるので、ポイントのみで、クーポンを獲得していなければ特典は受けられない。また、獲得したクーポンは、１度使用すると１クーポンがなくなる仕組みである。
　以下、この仕組みに基づいて、クーポン発行システム１００の内容を説明する。なお、ポイント取得やクーポン獲得の条件、ポイント使用の条件などの各種条件については、上記に限定されるものではなく、クーポン提供者が、それらの条件を任意に設定することができる。
　ブロックチェーン・データストア１０１は、施設ユーザ１１１と、利用者ユーザ１１７の２種類のユーザに関するデータを有する。ここで、クーポンの発行は、上述のように、施設の利用に基づくものであることから、クーポン発行サービスの提供者、すなわち、クーポンを発行する発行元を「施設」と称する。また、クーポン発行サービスの提供を受ける者、すなわち、当該施設を利用して、当該クーポンを享受する者を「利用者」と称する。
　施設ユーザ１１１は、「施設」に紐付いた（関連付けされた）クーポンの定義を管理するためのユーザである。施設ユーザ１１１は、施設に対して定義したクーポンの施設クーポンインスタンス１１２を紐づける。１施設に対して１ユーザを作成する。したがって、クーポン発行サービスを提供する施設の数だけ、施設ユーザ１１１（というデータ）が存在する。
　施設クーポンインスタンス１１２は、施設に対するクーポン定義を管理するためのインスタンスである。施設クーポンインスタンス１１２は、施設利用実績登録処理部１０５が追加すべきポイントインスタンス１１８とクーポンインスタンス１１９の組合せを認識するために使用される。具体的なクーポン発行の定義内容は、ポイント定義である「ポイント契約定義」１１３および「ポイント資産定義」１１４と、クーポン定義である「クーポン契約定義」１１５および「クーポン資産定義」１１６に格納される。
　ポイント定義のうち、「ポイント契約定義（ｐｏｉｎｔＣｏｎｔｒａｃｔＤｅｆｉｎｉｔｉｏｎ）」１１３は、ポイント獲得の契約定義であり、ポイントインスタンス１１８に紐づける当該クーポンの定義のテンプレートである。ポイント契約定義１１３は、クーポンの発行可否を定義する。
　ポイント定義のうち、「ポイント資産定義（ｐｏｉｎｔＡｓｓｅｔＤｅｆｉｎｉｔｉｏｎ）」１１４は、ポイントインスタンス１１８に紐づける当該クーポンの定義のテンプレートである。ポイント資産定義１１４は、ポイントインスタンス１１８の有効・無効を定義する。
　クーポン定義のうち、「クーポン契約定義（ｃｏｕｐｏｎＣｏｎｔｒａｃｔＤｅｆｉｎｉｔｉｏｎ）」１１５は、クーポン発行の契約定義であり、クーポンインスタンス１１９に紐づける当該クーポンの定義のテンプレートである。クーポン契約定義１１５は、クーポン発行に必要なポイント条件（施設利用数など）を格納する。
　クーポン定義のうち、「クーポン資産定義（ｃｏｕｐｏｎＡｓｓｅｔＤｅｆｉｎｉｔｉｏｎ）」１１６は、クーポンインスタンス１１９に紐づける当該クーポンの定義のテンプレートである。クーポン資産定義１１６は、クーポンＩＤや有効期限などクーポンの詳細情報を格納する。
　また、利用者ユーザ１１７は、ユーザアプリケーション１０３のユーザに対してブロックチェーンのインスタンス（ポイントインスタンス１１８、（利用者）クーポンインスタンス１１９）を紐づけるために作成されるユーザである。ユーザアプリケーション１０３の運用過程で作成される。利用者ユーザ１１７は、１利用者に対して１ユーザを作成する。したがって、当該施設を利用して、当該クーポン発行サービスを享受する利用者の数だけ、利用者ユーザ１１７が存在する。
　ポイントインスタンス１１８は、クーポン定義処理がおこなわれて以降に当該施設を利用した回数を格納する。ポイントインスタンス１１８に追加された値（施設利用数）がクーポン契約定義１１５に定義された条件に達した時、コンバート（ｃｏｎｖｅｒｔ）処理によってポイントインスタンス１１８の値から条件値分減算される。
　（利用者）クーポンインスタンス１１９は、クーポン当該クーポンの発行数を格納する。ポイント契約定義１１３・ポイント資産定義１１４の状態が有効であり、ポイントインスタンス１１８に追加された値（施設利用数）がクーポン契約定義１１５に定義された条件に達した時、コンバート処理によってクーポンインスタンス１１９の値が１追加される。「クーポンインスタンス１１９」は、「施設クーポンインスタンス１１２」と区別するため、「利用者クーポンインスタンス１１９」ともいう。
　ブロックチェーン・データストア１０１は、このような構成となっている。各データの関係性については、後述する図５において詳細に説明する。
　管理者インタフェース１０２は、クーポン発行サービスを管理する管理者のインタフェースであり、管理者インタフェース１０２には、具体的には、端末装置１５０が接続される。端末装置１５０は、管理者が操作する情報処理装置であり、この端末装置１５０には、具体的には、たとえば、パーソナルコンピュータ、スマートフォン、タブレット端末装置などのインターネットなどのネットワークに有線または無線で接続可能な情報処理装置である。
　ユーザアプリケーション１０３は、クーポン発行サービスの提供を受ける利用者が使用するアプリケーション（上位アプリ）である。ユーザアプリケーション１０３は、具体的には、端末装置１６０によって実行される。端末装置１６０は、利用者が操作する情報処理装置であり、この端末装置１６０には、具体的には、たとえば、スマートフォンのほか、タブレット端末装置、パーソナルコンピュータなどのインターネットなどのネットワークに有線または無線で接続可能な情報処理装置である。
　また、端末装置１６０は、各種画面を表示したり、操作キーやボタンなどを表示するディスプレイ、ＱＲコード（登録商標）を読み取るカメラなどを備える。ディスプレイに表示する画面には、たとえば、ＱＲコード読み取り画面、使用可能クーポン一覧画面、未使用クーポン詳細画面、使用済みクーポン詳細画面、使用済みクーポン一覧画面などの各種画面が表示される。
　クーポン定義作成処理部１０４は、施設ユーザ１１１、施設クーポンインスタンス１１２、ポイント契約定義１１３、ポイント資産定義１１４、クーポン契約定義１１５、クーポン資産定義１１６を作成する。ここで、施設ユーザ１１１は、当該施設のクーポン定義が一つ目の場合に作成する。その他はクーポン１種類に対して、それぞれ一つずつ作成する。
　施設利用実績登録処理部１０５は、利用者ユーザ１１７の当該施設の当該クーポンに対するポイントインスタンス１１８の値を１追加する。利用者ユーザ１１７に対して当該施設の当該クーポンのポイントインスタンス１１８とクーポンインスタンス１１９が存在しない場合（当該クーポンのクーポン定義作成処理部１０４による処理が実施されてから、利用者ユーザ１１７が最初に当該施設を利用したタイミング）、当該施設の当該クーポンのポイントインスタンス１１８とクーポンインスタンス１１９とを作成する。
　施設利用実績登録処理部１０５は、具体的には、たとえば、後述する図１５に示す「ｖｉｓｉｔ　ＡＰＩ」や、図１６に示す「ｇｅｔＣｏｕｐｏｎｓ　ＡＰＩ」などによって、その機能を実現することができる。
　クーポン一覧取得処理部１０６は、利用者ユーザ１１７の全クーポンインスタンス１１９に付与された全クーポンを一覧としてユーザアプリケーション１０３に返却する。クーポン一覧取得処理部１０６は、具体的には、たとえば、後述する図１５に示す「ｖｉｓｉｔ　ＡＰＩ」などによって、その機能を実現することができる。
　クーポン利用処理部１０７は、指定したクーポンをクーポンインスタンス１１９から１減少させる。これにより、利用者は、クーポンによる特典を受けることができ、当該クーポンによる特典を一度受けた利用者が同じクーポンで再び特典を受けないようにすることができる。クーポン利用処理部１０７は、具体的には、たとえば、後述する図１７に示す「ｕｓｅＣｏｕｐｏｎ　ＡＰＩ」などによって、その機能を実現することができる。
　ブロックチェーンＡＰＩ１０８は、ブロックチェーンの分散台帳に対して、以下のデータ作成、更新および参照をするＡＰＩである。ブロックチェーンＡＰＩ１０８は、ユーザ作成（ＡＰＩ）１２１、契約定義作成（ＡＰＩ）１２２、資産定義作成（ＡＰＩ）１２３、インスタンス作成（ＡＰＩ）１２４、インスタンス更新（ＡＰＩ）１２５、インスタンス参照（ＡＰＩ）１２６の各ＡＰＩを含む構成となっている。
　ユーザ作成（ＡＰＩ）１２１は、施設ユーザ１１１および利用者ユーザ１１７を作成することができる。契約定義作成（ＡＰＩ）１２２は、ポイント契約定義１１３およびクーポン契約定義１１５を作成することができる。資産定義作成（ＡＰＩ）１２３は、ポイント資産定義１１４およびクーポン資産定義１１６を作成することができる。インスタンス作成（ＡＰＩ）１２４は、施設クーポンインスタンス１１２、ポイントインスタンス１１８、クーポンインスタンス１１９を作成することができる。
　インスタンス更新（ＡＰＩ）１２５は、施設クーポンインスタンス１１２、ポイントインスタンス１１８、クーポンインスタンス１１９を更新することができる。インスタンス参照（ＡＰＩ）１２６は、施設クーポンインスタンス１１２、ポイントインスタンス１１８、クーポンインスタンス１１９を参照することができる。
（ハイパーレッジャー・ファブリックのシステム構成）
　つぎに、本実施の形態にかかるクーポン発行システムが用いる分散台帳技術の一例であるハイパーレッジャー・ファブリック（Ｈｙｐｅｒｌｅｄｇｅｒ　Ｆａｂｒｉｃ）のシステム構成について説明する。
　ハイパーレッジャー・ファブリックは、分散台帳プラットフォームであり、オープンソースのブロックチェーン基盤である。ハイパーレッジャー・ファブリックは、公開鍵で指定されたノードのみがネットワークに参加できる、パーミッションドブロックチェーンの一つであり、コンテナー・テクノロジーを利用して、エンタープライズ対応のセキュリティー、スケーラビリティー、機密性を備えたネットワークを実現する。
　図２は、ハイパーレッジャー・ファブリックのシステム構成の一例を示す説明図である。図２において、ハイパーレッジャー・メンバー・オーガニゼーション（Ｈｙｐｅｒｌｅｄｇｅｒ　Ｍｅｍｂｅｒ　Ｏｒｇａｎｉｚａｔｉｏｎ（ＨＭＯ））２００（２００ａ、２００ｂ、・・・）は、オーダラー（Ｏｒｄｅｒｅｒ）ピア２０１によって、接続されている。
　オーダラーピア２０１は、トランザクションを集めてブロックを作成し、各ピアに送信するノードである。オーダラーピア２０１は、すべてのピアに同じ順番でブロックを配信することができる。
　ＨＭＯ２００ａは、クライアント（Ｃｌｉｅｎｔ）ピア２０２と、エンドーザー（Ｅｎｄｏｒｓｅｒ）ピア２０３、ゼネラル（Ｇｅｎｅｒａｌ）ピア２０４、２０５と、アンカー（Ａｎｃｈｏｒ）ピア２０６の各ノードを備えている。
　クライアントピア２０２は、トランザクション呼び出し、すなわち、インストールされた、後述するスマートウォレット・チェーンコード２１３の実行をピアへ送信し、トランザクション提案をオーダラーピア２０１におこなうノードである。
　エンドーザーピア２０３は、ワールドステート（Ｗｏｒｌｄ　Ｓｔａｔｅ（ＷＳ））２１１とトランザクション・データベース（Ｔｒａｎｓａｃｔｉｏｎ　Ｄａｔａｂａｓｅ（ＴＤ））２１２の２つを格納している台帳を管理する。また、エンドーザーピア２０３は、スマートウォレット・チェーンコード（ＳｍａｒｔＷａｌｌｅｔＣｈａｉｎＣｏｄｅ）２１３がインストールされている。スマートウォレット・チェーンコード２１３によって分散台帳が持つ状態を読み出したり、更新したりすることができる。ワールドステート２１１とは、この状態のことである。スマートウォレット・チェーンコード２１３のインスタンスごとに、キーバリュー形式のデータ構造になっている。
　ハイパーレッジャー・ファブリックにおける処理の手順は以下の（１）～（６）のとおりである。
　（１）アプリ利用者２０７が、施設を訪れてＱＲコードを読み取ることを契機として、要求が開始される。
　（２）クライアントピア２０２は、エンドーズポリシーを満たすようにエンドーザーピア２０３を選択する。クライアントピア２０２が、スマートウォレット・チェーンコード実行リクエストを作成し、エンドーザーピア２０３に、トランザクション提案メッセージを送付して、エンドーズ（トランザクション実行結果に対する承認）を依頼する。そして、作成したトランザクションをエンドーザーピア２０３へ転送する。
　（３）エンドーザーピア２０３は、トランザクションの有効性を判断し、スマートウォレット・チェーンコード２１３を実行する。そして、結果メッセージをクライアントピア２０２に返却する。
　（４）クライアントピア２０２は、承認されたトランザクションが、正規に要求され、ブロックに対して登録されるものであるとして、オーダラーピア２０１へ送信する。
　（５）オーダラーピア２０１は、そのトランザクションをブロックに登録し、そのブロックをすべてＨＭＯ２００のアンカーピア２０６へ送信する。
　（６）アンカーピア２０６は、ＨＭＯ２００ａ内の他のピア２０３、２０４、２０５に対してブロックを配信する。それぞれのピアは、最新のブロックによって、各々の台帳を更新する。このとき、トランザクションのキーＩＤが送られ、ブロック内に作成され、各ピアのＴＤ２１２に蓄積される。また、各ピアのＷＳ２１１において、最新のポイント収支が更新されている。このようにして、ネットワークのすべてにおいて、分散台帳を同期させることができる。
　本実施の形態におけるクーポン発行システムは、その機能を、たとえば、このハイパーレッジャー・ファブリックのシステムを用いて実現することができる。しかしながら、このハイパーレッジャー・ファブリックのシステムを用いて実現することには限定されない。本実施の形態におけるクーポン発行システムは、他のブロックチェーンの技術、具体的には、たとえば、イーサリアム（Ｅｔｈｅｒｅｕｍ）などの非中央集権アプリケーション実行プラットフォームを用いて、実現するようにしてもよい。
（スマートウォレット・チェーンコードのデータ構成）
　図３は、スマートウォレット・チェーンコードのデータ構成の一例を示す説明図である。図３において、スマートウォレット・チェーンコード２１３は、ユーザテーブル（ｕｓｅｒＴａｂｌｅ）３０１、ウォレットテーブル（ｗａｌｌｅｔＴａｂｌｅ）３０２、履歴テーブル（ｈｉｓｔｏｒｙＴａｂｌｅ）３０３、資産定義テーブル（ａｓｓｅｔＤｅｆｉｎｉｔｉｏｎＴａｂｌｅ）３０４、契約定義テーブル（ｃｏｎｔｒａｃｔＤｅｆｉｎｉｔｉｏｎＴａｂｌｅ）３０５の５つのテーブルから構成されている。
　クライアントピア２０２が、トランザクション・リクエストをエンドーザーピア２０３に提出すると、スマートウォレット・チェーンコード２１３は、最初に、図示を省略する、ビジネスロジックデータストアからユーザ情報を取得し、また、このスマートウォレット・チェーンコード２１３のユーザテーブル３０１から施設ユーザを取得する。
　ユーザテーブル３０１には、ユーザの情報が記憶されている。ウォレットテーブル３０２には、施設に基づく各ユーザの最新のポイント収支が記憶されている。
　履歴テーブル３０３には、合意形成されたトランザクションとその詳細に関する情報が記憶されている。
　資産定義テーブル３０４には、ユーザの行動（施設の利用）に対するポイントの加算に関する定義が記憶されている。ポイントは、資産定義テーブル３０４において定められた定義に基づいて加算される。
　契約定義テーブル３０５には、ポイントをクーポンにコンバートする定義が記憶されている。契約定義テーブル３０５に定められた条件を参照し、ポイントが条件に達したときは、クーポンにコンバートされる。
　このように、スマートウォレット・チェーンコード２１３の５つのテーブルを用いて、クーポン発行の一連の処理を実行することができる。
（ノードのハードウェア構成）
　図４は、ノードのハードウェア構成の一例を示すブロック図である。図４において、ノード（ピア）２０２～２０６は、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）４０１と、メモリ４０２と、ネットワークＩ／Ｆ（Ｉｎｔｅｒｆａｃｅ）４０３と、記録媒体Ｉ／Ｆ４０４と、記録媒体４０５と、を有する。また、各構成部４０１～４０４は、バス４００によってそれぞれ接続される。
　ここで、ＣＰＵ４０１は、ノードの全体の制御を司る。メモリ４０２は、たとえば、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）およびフラッシュＲＯＭなどを有する。具体的には、たとえば、フラッシュＲＯＭやＲＯＭが各種プログラムを記憶し、ＲＡＭがＣＰＵ４０１のワークエリアとして使用される。メモリ４０２に記憶されるプログラムは、ＣＰＵ４０１にロードされることで、コーディングされている処理をＣＰＵ４０１に実行させる。
　ネットワークＩ／Ｆ４０３は、通信回線を通じてネットワークに接続され、ネットワークを介して他の装置（たとえば、他のノード２０１～２０６やクライアント端末装置１５０、１６０など）に接続される。そして、ネットワークＩ／Ｆ４０３は、ネットワークと自装置内部とのインタフェースを司り、他の装置からのデータの入出力を制御する。ネットワークＩ／Ｆ４０３には、たとえば、モデムやＬＡＮアダプタなどを採用することができる。
　記録媒体Ｉ／Ｆ４０４は、ＣＰＵ４０１の制御にしたがって記録媒体４０５に対するデータのリード／ライトを制御する。記録媒体４０５は、記録媒体Ｉ／Ｆ４０４の制御で書き込まれたデータを記憶する。記録媒体４０５としては、たとえば、磁気ディスク、光ディスクなどが挙げられる。
　なお、ノード２０２～２０７は、上述した構成部４０１～４０５のほかに、たとえば、図示を省略する、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）、キーボード、ポインティングデバイス、ディスプレイなどを有することにしてもよい。
（データの関係性について）
　図５は、各データの関係性の一例を示す説明図である。スマートウォレットにおいて、図５において示した各データは、クーポン発行機能を実現するにあたって用いられるデータである。
　図５に示すように、施設ユーザ１１１と施設クーポンインスタンス１１２が紐付け（関連付け）されている。施設ユーザ１１１は、初回クーポン定義作成時に作成される。施設クーポンインスタンス１１２は、施設ごとに作成される。
　また、施設クーポンインスタンス１１２ごとに、ポイント契約定義１１３、ポイント資産定義１１４、クーポン契約定義１１５、クーポン資産定義１１６からなるクーポン／ポイント定義一式がそれぞれ作成される。したがって、クーポン／ポイント定義一式は施設単位で作成されることになる。
　また、利用者ユーザ１１７は、事前に作成しておく。そして、ポイントインスタンス１１８と利用者クーポンインスタンス１１９が、利用者ユーザ１１７と紐付け（関連付け）されている。また、ポイントインスタンス１１８と利用者クーポンインスタンス１１９は、クーポン単位で作成される。
　ポイントインスタンス１１８は、ポイント資産定義１１４によってその内容が定義づけされ、ポイント契約定義１１３によって、ポイントインスタンス１１８の更新がなされる。また、利用者クーポンインスタンス１１９は、クーポン資産定義１１６によって、その内容が定義づけされ、クーポン契約定義１１５によって、ポイントインスタンス１１８から利用者クーポンインスタンス１１９へのコンバートがおこなわれる。
　このようにして、各定義とインスタンスが、それぞれ施設単位、クーポン単位で作成され、記憶される。これらの定義と、インスタンスによって、クーポン発行処理をおこなうことができる。
（クーポン定義作成のシーケンス）
　つぎに、クーポン定義作成のシーケンスについて説明する。図６は、クーポン定義作成のシーケンスの一例を示す説明図である。図６において、クーポン定義作成は、「ｇｅｔＵｓｅｒ」６０１→「ｃｒｅａｔｅＡｓｓｅｔＤｅｆｉｎｉｔｉｏｎ」６０２→「ａｄｄＩｎｓｔａｎｃｅ」６０３→「ｃｒｅａｔｅＡｓｓｅｔＤｅｆｉｎｉｔｉｏｎ」６０４→「ｃｒｅａｔｅＣｏｎｔｒａｃｔＤｅｆｉｎｉｔｉｏｎ」６０５→「ｃｒｅａｔｅＣｏｎｔｒａｃｔＤｅｆｉｎｉｔｉｏｎ」６０６→「ｕｐｄａｔｅＩｎｓｔａｎｃｅ」６０７というシーケンスにより実行される。
　それによって、施設ユーザ１１１を取得し、クーポン資産定義１１６を作成し、施設クーポンインスタンス１１２を追加し（ステータスを“ｕｎａｖａｉｌａｂｌｅ（作成中）”とし）、ポイント資産定義１１４を作成し、ポイント契約定義１１３を作成し、クーポン契約定義１１５を作成し、作成後に、施設クーポンインスタンス１１２を更新する（ステータスを“ｕｎａｖａｉｌａｂｌｅ（作成中）”から“ａｖａｉｌａｂｌｅ（発行中）”に変更する）。
　すなわち、クーポン資産定義１１６、ポイント資産定義１１４、ポイント契約定義１１３、クーポン契約定義１１５の４つの定義を作成することによって、クーポン発行サービスにおけるクーポン定義の作成をおこなうことができる。
　図７Ａおよび図７Ｂは、クーポン定義作成の処理の手順の一例を示すフローチャートである。図７Ａのフローチャートにおいて、まず、施設ユーザ１１１が存在するか否かを判断する（ステップＳ７０１）。ここで、施設ユーザ１１１が存在する場合（ステップＳ７０１：Ｙｅｓ）は、当該施設ユーザ１１１の施設クーポンインスタンス１１２を取得する（ステップＳ７０２）。これが、「ｇｅｔＵｓｅｒ」６０１である。そして、当該施設クーポンインスタンス１１２の取得に成功したか否かを判断する（ステップＳ７０３）。
　ここで、当該施設クーポンインスタンス１１２の取得に成功した場合（ステップＳ７０３：Ｙｅｓ）は、ステップＳ７１０へ移行する。一方、当該施設クーポンインスタンス１１２の取得に失敗した場合（ステップＳ７０３：Ｎｏ）は、エラーが発生したとして、処理を中断し（ステップＳ７０４）、一連の処理を終了する。
　ステップＳ７０１において、施設ユーザ１１１が存在しない場合（ステップＳ７０１：Ｎｏ）は、ユーザの取得に成功したか否かを判断する（ステップＳ７０５）。ここで、ユーザの取得に失敗した場合（ステップＳ７０５：Ｎｏ）は、エラーが発生したとして、処理を中断し（ステップＳ７０６）、一連の処理を終了する。
　一方、ユーザの取得に成功した場合（ステップＳ７０５：Ｙｅｓ）は、施設ユーザ１１１を作成し（ステップＳ７０７）、当該施設ユーザ１１１の作成に成功したか否かを判断する（ステップＳ７０８）。ここで、施設ユーザ１１１の作成に成功した場合（ステップＳ７０８：Ｙｅｓ）は、ステップＳ７１０へ移行する。一方、施設ユーザ１１１の作成に失敗した場合（ステップＳ７０８：Ｎｏ）は、エラーが発生したとして、処理を中断し（ステップＳ７０９）、一連の処理を終了する。
　つぎに、ステップＳ７１０において、クーポン資産定義１１６を作成する（ステップＳ７１０）。ここでは、施設ＩＤ、クーポンＩＤのほか、有効期限などを入力する。また、ステータスを“ａｖａｉｌａｂｌｅ（発行中）”とする。これが、「ｃｒｅａｔｅＡｓｓｅｔＤｅｆｉｎｉｔｉｏｎ」６０２である。そして、クーポン資産定義１１６の作成に成功したか否かを判断する（ステップＳ７１１）。ここで、クーポン資産定義１１６の作成に失敗した場合（ステップＳ７１１：Ｎｏ）は、エラーが発生したとして、処理を中断し（ステップＳ７１２）、一連の処理を終了する。
　一方、クーポン資産定義１１６の作成に成功した場合（ステップＳ７１１：Ｙｅｓ）は、つぎに、施設クーポンインスタンス１１２を作成（追加）する（ステップＳ７１３）。ここでは、施設ＩＤ、クーポンＩＤのほか、有効期限などを入力する。また、ステータスを“ｕｎａｖａｉｌａｂｌｅ（作成中）”とする。これが、「ａｄｄＩｎｓｔａｎｃｅ」６０３である。ここで、施設クーポンインスタンス１１２の作成に成功した場合（ステップＳ７１４：Ｙｅｓ）は、図７ＢのフローチャートのステップＳ７１６へ移行する。一方、施設クーポンインスタンス１１２の作成に失敗した場合（ステップＳ７１４：Ｎｏ）は、エラーが発生したとして、処理を中断し（ステップＳ７１５）、一連の処理を終了する。
　図７Ｂのフローチャートにおいて、ポイント資産定義１１４を作成する（ステップＳ７１６）。これが、「ｃｒｅａｔｅＡｓｓｅｔＤｅｆｉｎｉｔｉｏｎ」６０４である。そして、ポイント資産定義１１４の作成に成功したか否かを判断する（ステップＳ７１７）。ここで、ポイント資産定義１１４の作成に失敗した場合（ステップＳ７１７：Ｎｏ）は、エラーが発生したとして、処理を中断し（ステップＳ７１８）、一連の処理を終了する。
　一方、ポイント資産定義１１４の作成に成功した場合（ステップＳ７１７：Ｙｅｓ）は、つぎに、ポイント契約定義１１３を作成する（ステップＳ７１９）。ここでは、施設ＩＤ、クーポンＩＤなどを入力する。また、ステータスを“ａｖａｉｌａｂｌｅ（発行中）”とする。これが、「ｃｒｅａｔｅＣｏｎｔｒａｃｔＤｅｆｉｎｉｔｉｏｎ」６０５である。そして、ポイント契約定義１１３の作成に成功したか否かを判断する（ステップＳ７２０）。ここで、ポイント契約定義１１３の作成に失敗した場合（ステップＳ７２０：Ｎｏ）は、エラーが発生したとして、処理を中断し（ステップＳ７２１）、一連の処理を終了する。
　一方、ポイント契約定義１１３の作成に成功した場合（ステップＳ７２０：Ｙｅｓ）は、つぎに、クーポン契約定義１１５を作成する（ステップＳ７２２）。ここでは、施設ＩＤ、クーポンＩＤ、クーポン発行に必要な条件（たとえば施設訪問回数）などを入力する。また、ステータスを“ａｖａｉｌａｂｌｅ（発行中）”とする。これが、「ｃｒｅａｔｅＣｏｎｔｒａｃｔＤｅｆｉｎｉｔｉｏｎ」６０６である。そして、クーポン契約定義１１５の作成に成功したか否かを判断する（ステップＳ７２３）。ここで、クーポン契約定義１１５の作成に失敗した場合（ステップＳ７２３：Ｎｏ）は、エラーが発生したとして、処理を中断し（ステップＳ７２４）、一連の処理を終了する。
　一方、クーポン契約定義１１５の作成に成功した場合（ステップＳ７２３：Ｙｅｓ）は、つぎに、施設クーポンインスタンス１１２を作成（更新）する（ステップＳ７２５）。ここでは、施設ＩＤ、クーポンＩＤなどを入力する。また、ステータスを“ｕｎａｖａｉｌａｂｌｅ（作成中）”から“ａｖａｉｌａｂｌｅ（発行中）”に変更する。これが、「ｕｐｄａｔｅＩｎｓｔａｎｃｅ」６０７である。そして、施設クーポンインスタンス１１２の作成に成功したか否かを判断する（ステップＳ７２６）。ここで、施設クーポンインスタンス１１２の作成に成功した場合（ステップＳ７２６：Ｙｅｓ）は、一連の処理を終了する。このようにして、クーポン定義を作成し、分散台帳（ＴＤ２１２）に反映させることができる。すなわち、作成したクーポン定義をブロックチェーンに記録させることができる。以下、分散台帳に反映させるとは、ブロックチェーンに記録させることと同じ意味である。
　一方、施設クーポンインスタンス１１２の作成に失敗した場合（ステップＳ７２６：Ｎｏ）は、エラーが発生したとして、処理を中断し（ステップＳ７２７）、一連の処理を終了する。
（クーポン定義更新のシーケンス）
　つぎに、クーポン定義更新のシーケンスについて説明する。図８は、クーポン定義更新のシーケンスの一例を示す説明図である。図８において、クーポン定義更新は、「ｇｅｔＩｎｓｔａｎｃｅ」８０１→「ｕｐｄａｔｅＩｎｓｔａｎｃｅ」８０２→「ｕｐｄａｔｅＣｏｎｔｒａｃｔＤｅｆｉｎｉｔｉｏｎ」８０３→「ｕｐｄａｔｅＩｎｓｔａｎｃｅ」８０４というシーケンスにより実行される。
　それによって、施設クーポンインスタンス１１２を取得し、施設クーポンインスタンス１１２を更新（ステータスを「発行中」から「処理中」に変更）し、クーポン契約定義１１５を更新し、更新後に、施設クーポンインスタンス１１２を更新（ステータスを「処理中」から「発行中」に変更）する。
　すなわち、クーポン契約定義１１５を更新することによって、クーポン発行サービスにおけるサービス内容の変更であるクーポン定義の更新をおこなうことができる。具体的には、たとえば、従来の『３ポイントで１クーポンを獲得』というクーポン定義を『５ポイントで１クーポンを獲得』というクーポン定義に変更する際に、クーポン契約定義１１５の内容を更新するだけで、容易にクーポン定義の更新をすることができる。
　また、図示を省略するが、ポイント定義を更新したい場合は、ポイント契約定義１１３を更新することによっておこなうことができる。具体的には、たとえば、従来の『１回の施設利用で１ポイント取得』というクーポン定義を『１回の施設利用で２ポイント取得』というポイント定義に変更する際に、ポイント契約定義１１３の内容を更新するだけで、容易にポイント定義の更新をすることができる。
　また、図示を省略するが、ポイント定義とクーポン定義の両方を同時に更新したい場合は、ポイント契約定義１１３およびクーポン契約定義１１５を更新することによっておこなうことができる。具体的には、たとえば、従来の『１回の施設利用で１ポイント取得』というクーポン定義を『１回の施設利用で２ポイント取得』というポイント定義に変更し、かつ、従来の『３ポイントで１クーポンを獲得』というクーポン定義を『５ポイントで１クーポンを獲得』というクーポン定義に変更する際に、ポイント契約定義１１３およびクーポン契約定義１１５の内容を更新するだけで、容易にポイント定義・クーポン定義の更新を同時におこなうことができる。
　図９は、クーポン定義更新の処理の手順の一例を示すフローチャートである。図９のフローチャートにおいて、施設ユーザの施設クーポンインスタンス１１２を取得する（ステップＳ９０１）。これが、「ｇｅｔＩｎｓｔａｎｃｅ」８０１である。そして、当該施設クーポンインスタンス１１２が存在するか否かを判断する（ステップＳ９０２）。
　ここで、当該施設クーポンインスタンス１１２が存在しない場合（ステップＳ９０２：Ｎｏ）は、エラーが発生したとして、処理を中断し（ステップＳ９０３）、一連の処理を終了する。一方、当該施設クーポンインスタンス１１２が存在する場合（ステップＳ９０２：Ｙｅｓ）は、当該施設クーポンインスタンス１１２のステータスが、“ａｖａｉｌａｂｌｅ（発行中）”であるか否かを判断する（ステップＳ９０４）。ここで、ステータスが、“ａｖａｉｌａｂｌｅ”ではない場合（ステップＳ９０４：Ｎｏ）は、エラーが発生したとして、処理を中断し（ステップＳ９０５）、一連の処理を終了する。
　一方、ステータスが、“ａｖａｉｌａｂｌｅ”である場合（ステップＳ９０４：Ｙｅｓ）は、当該施設クーポンインスタンス１１２を更新する（ステップＳ９０６）。ここでは、施設ＩＤ、クーポンＩＤなどを入力する。また、ステータスを、“ａｖａｉｌａｂｌｅ（発行中）”から“ｐｒｏｃｅｓｓｉｎｇ（処理中）”とする。これが、「ｕｐｄａｔｅＩｎｓｔａｎｃｅ」８０２である。そして、当該施設クーポンインスタンス１１２の更新に成功したか否かを判断する（ステップＳ９０７）。ここで、施設クーポンインスタンス１１２の更新に失敗した場合（ステップＳ９０７：Ｎｏ）は、エラーが発生したとして、処理を中断し（ステップＳ９０８）、一連の処理を終了する。
　一方、施設クーポンインスタンス１１２の更新に成功した場合（ステップＳ９０７：Ｙｅｓ）は、つぎに、クーポン契約定義１１５を更新する（ステップＳ９０９）。ここでは、施設ＩＤ、クーポンＩＤ、クーポン発行に必要な施設訪問回数などを入力する。これが、「ｕｐｄａｔｅＣｏｎｔｒａｃｔＤｅｆｉｎｉｔｉｏｎ」８０３である。そして、クーポン契約定義１１５の更新に成功したか否かを判断する（ステップＳ９１０）。ここで、クーポン契約定義１１５の更新に失敗した場合（ステップＳ９１０：Ｎｏ）は、エラーが発生したとして、処理を中断し（ステップＳ９１１）、一連の処理を終了する。
　一方、クーポン契約定義１１５の更新に成功した場合（ステップＳ９１０：Ｙｅｓ）は、つぎに、施設クーポンインスタンス１１２を更新する（ステップＳ９１２）。ここでは、施設ＩＤ、クーポンＩＤなどを入力する。また、ステータスを、“ｐｒｏｃｅｓｓｉｎｇ（処理中）”から“ａｖａｉｌａｂｌｅ（発行中）”に変更する。これが、「ｕｐｄａｔｅＩｎｓｔａｎｃｅ」８０４である。そして、施設クーポンインスタンス１１２の更新に成功したか否かを判断する（ステップＳ９１３）。ここで、施設クーポンインスタンス１１２の更新に成功した場合（ステップＳ９１３：Ｙｅｓ）は、一連の処理を終了する。このようにして、クーポン定義を更新し、分散台帳（ＴＤ２１２）に反映させることができる。
　一方、施設クーポンインスタンス１１２の更新に失敗した場合（ステップＳ９１３：Ｎｏ）は、エラーが発生したとして、処理を中断する（ステップＳ９１４）。ただし、この場合は、施設クーポンインスタンス１１２のステータスが、“ｐｒｏｃｅｓｓｉｎｇ（処理中）”のままで、“ａｖａｉｌａｂｌｅ（発行中）”に戻らず、その施設クーポンインスタンス１１２のステータスが“ｐｒｏｃｅｓｓｉｎｇ（処理中）”のままの状態が維持されているため、その旨の結果を出力してから、一連の処理を終了する。この場合、クーポンの発行が再開されない状態となっているため、別途、なんらかの手当が必要となる。
（クーポン新規発行の停止のシーケンス）
　つぎに、クーポン新規発行の停止のシーケンスについて説明する。図１０は、クーポン新規発行の停止のシーケンスの一例を示す説明図である。図１０において、クーポン定義更新は、「ｇｅｔＩｎｓｔａｎｃｅ」１００１→「ｕｐｄａｔｅＩｎｓｔａｎｃｅ」１００２→「ｕｐｄａｔｅＣｏｎｔｒａｃｔＤｅｆｉｎｉｔｉｏｎ」１００３→「ｕｐｄａｔｅＣｏｎｔｒａｃｔＤｅｆｉｎｉｔｉｏｎ」１００４→「ｕｐｄａｔｅＩｎｓｔａｎｃｅ」１００５というシーケンスにより実行される。
　それによって、施設クーポンインスタンス１１２を取得し、施設クーポンインスタンス１１２を更新（ステータスを「処理中」に変更）し、その後、クーポン契約定義１１５を更新（施設訪問回数の多い桁数を固定値とし、ステータスを「発行中」から「発行停止済み」に変更）し、ポイント契約定義１１３を更新（ステータスを「発行中」から「発行停止済み」に変更）する。そして、それらの更新後に、施設クーポンインスタンス１１２のステータスを更新（「処理中」から「発行停止済み」に変更）する。
　すなわち、クーポン契約定義１１５およびポイント契約定義１１３の２つの定義のステータスを更新することによって、クーポン発行サービスにおけるクーポン新規発行を停止することができる。
　図１１Ａおよび図１１Ｂは、クーポン新規発行の停止の処理の手順の一例を示すフローチャートである。図１１Ａのフローチャートにおいて、施設ユーザの施設クーポンインスタンス１１２を取得する（ステップＳ１１０１）。これが、「ｇｅｔＩｎｓｔａｎｃｅ」１００１である。そして、施設クーポンインスタンス１１２が存在するか否かを判断する（ステップＳ１１０２）。
　ここで、施設クーポンインスタンス１１２が存在しない場合（ステップＳ１１０２：Ｎｏ）は、エラーが発生したとして、処理を中断し（ステップＳ１１０３）、一連の処理を終了する。一方、施設クーポンインスタンス１１２が存在する場合（ステップＳ１１０２：Ｙｅｓ）は、施設クーポンインスタンス１１２を取得できたか否かを判断する（ステップＳ１１０４）。ここで、施設クーポンインスタンス１１２を取得できなかった場合（ステップＳ１１０４：Ｎｏ）は、エラーが発生したとして、処理を中断し（ステップＳ１１０５）、一連の処理を終了する。
　ステップＳ１１０４において、施設クーポンインスタンス１１２を取得できた場合（ステップＳ１１０４：Ｙｅｓ）は、当該施設クーポンインスタンス１１２を更新する（ステップＳ１１０６）。ここでは、施設ＩＤ、クーポンＩＤなどを入力する。また、ステータスを“ｐｒｏｃｅｓｓｉｎｇ（処理中）”とする。これが、「ｕｐｄａｔｅＩｎｓｔａｎｃｅ」１００２である。そして、施設クーポンインスタンス１１２の更新に成功したか否かを判断する（ステップＳ１１０７）。ここで、施設クーポンインスタンス１１２の更新に失敗した場合（ステップＳ１１０７：Ｎｏ）は、エラーが発生したとして、処理を中断し（ステップＳ１１０８）、一連の処理を終了する。
　一方、施設クーポンインスタンス１１２の更新に成功した場合（ステップＳ１１０７：Ｙｅｓ）は、つぎに、クーポン契約定義１１５を更新する（ステップＳ１１０９）。ここでは、施設ＩＤ、クーポンＩＤ、クーポン発行に必要な施設訪問回数として桁数の多い固定値などを入力する。また、ステータスを“ｓｔｏｐｐｅｄ（発行停止済み）”とする。これが、「ｕｐｄａｔｅＣｏｎｔｒａｃｔＤｅｆｉｎｉｔｉｏｎ」１００３である。その後、図１１ＢのフローチャートのステップＳ１１１０へ移行する。
　図１１Ｂのフローチャートにおいて、クーポン契約定義１１５の更新に成功したか否かを判断する（ステップＳ１１１０）。ここで、クーポン契約定義１１５の更新に失敗した場合（ステップＳ１１１０：Ｎｏ）は、ステップＳ１１１５へ移行する。一方、クーポン契約定義１１５の更新に成功した場合（ステップＳ１１１０：Ｙｅｓ）は、つぎに、ポイント契約定義１１３を更新する（ステップＳ１１１１）。ここでは、施設ＩＤ、クーポンＩＤなどを入力する。また、ステータスを“ｓｔｏｐｐｅｄ（発行停止済み）”とする。これが、「ｕｐｄａｔｅＣｏｎｔｒａｃｔＤｅｆｉｎｉｔｉｏｎ」１００４である。そして、ポイント契約定義１１３の更新に成功したか否かを判断する（ステップＳ１１１２）。
　ステップＳ１１１２において、ポイント契約定義１１３の更新に失敗した場合（ステップＳ１１１２：Ｎｏ）は、ステップＳ１１１５へ移行する。一方、ポイント契約定義１１３の更新に成功した場合（ステップＳ１１１２：Ｙｅｓ）は、つぎに、施設クーポンインスタンス１１２を更新する（ステップＳ１１１３）。ここでは、施設ＩＤ、クーポンＩＤなどを入力する。また、ステータスを、“ｐｒｏｃｅｓｓｉｎｇ（処理中）”から“ｓｔｏｐｐｅｄ（発行停止済み）”に変更する。これが、「ｕｐｄａｔｅＩｎｓｔａｎｃｅ」１００５である。そして、施設クーポンインスタンス１１２の更新に成功したか否かを判断する（ステップＳ１１１４）。
　ここで、施設クーポンインスタンス１１２の更新に成功した場合（ステップＳ１１１４：Ｙｅｓ）は、一連の処理を終了する。このようにして、クーポン定義を更新し、分散台帳（ＴＤ２１２）に反映させることができる。一方、施設クーポンインスタンス１１２の更新に失敗した場合（ステップＳ１１１４：Ｎｏ）は、ステップＳ１１１８へ移行する。
　ステップＳ１１１０において、更新に失敗した場合（ステップＳ１１１０：Ｎｏ）、あるいは、ステップＳ１１１２において、更新に失敗した場合（ステップＳ１１１２：Ｎｏ）は、ステップＳ１１１５において、エラーが発生したとして、処理を中断する（ステップＳ１１１５）。ただし、この場合は、施設クーポンインスタンス１１２のステータスが、“ｐｒｏｃｅｓｓｉｎｇ（処理中）”のままなので、施設クーポンインスタンス１１２を更新し、ステータスを、“ｐｒｏｃｅｓｓｉｎｇ（処理中）”から“ａｖａｉｌａｂｌｅ（発行中）”に変更する（ステップＳ１１１６）。
　そして、施設クーポンインスタンス１１２の更新に成功したか否かを判断する（ステップＳ１１１７）。ここで、施設クーポンインスタンス１１２の更新に成功した場合（ステップＳ１１１７：Ｙｅｓ）は、一連の処理を終了する。これにより、クーポン新規発行の停止には失敗したが、施設クーポンインスタンス１１２のステータスが“ｐｒｏｃｅｓｓｉｎｇ（処理中）”のままの状態が維持されることは回避することができる。
　一方、施設クーポンインスタンス１１２の更新に失敗した場合（ステップＳ１１１７：Ｎｏ）は、エラーが発生したとして、結果を出力する（ステップＳ１１１８）。ただし、この場合は、施設クーポンインスタンス１１２のステータスが、“ｐｒｏｃｅｓｓｉｎｇ（処理中）”のままで、“ａｖａｉｌａｂｌｅ（発行中）”に戻らず、その施設クーポンインスタンス１１２のステータスが“ｐｒｏｃｅｓｓｉｎｇ（処理中）”のままの状態が維持されているため、別途、なんらかの手当が必要となる。
（クーポン定義の削除のシーケンス）
　つぎに、クーポン定義の削除のシーケンスについて説明する。図１２は、クーポン定義の削除のシーケンスの一例を示す説明図である。図１２において、クーポン定義の削除は、「ｇｅｔＩｎｓｔａｎｃｅ」１２０１→「ｕｐｄａｔｅＩｎｓｔａｎｃｅ」１２０２→「ｕｐｄａｔｅＣｏｎｔｒａｃｔＤｅｆｉｎｉｔｉｏｎ」１２０３→「ｕｐｄａｔｅＡｓｓｅｔＤｅｆｉｎｉｔｉｏｎ」１２０４というシーケンスにより実行される。
　それによって、施設クーポンインスタンス１１２を更新（ステータスを「削除済み」に変更）し、その後、クーポン契約定義１１５を更新（施設訪問回数の多い桁数を固定値とし、ステータスを「発行中」から「削除済み」に変更）し、ポイント契約定義１１３を更新（ステータスを「発行中」から「削除済み」に変更）する。そして、クーポン資産定義１１６を、更新（ステータスを「発行中」から「削除済み」に変更）、ポイント資産定義１１４を、更新（ステータスを「発行中」から「削除済み」に変更）する。
　すなわち、クーポン契約定義１１５、ポイント契約定義１１３、クーポン資産定義１１６およびポイント資産定義１１４の４つの定義のステータスを更新することによって、クーポン発行サービスの廃止であるクーポン定義の削除をおこなうことができる。
　図１３は、クーポン定義の削除の処理の手順の一例を示すフローチャートである。図１３のフローチャートにおいて、施設クーポンインスタンス１１２を取得し、更新する（ステップＳ１３０１）。ここでは、施設ＩＤ、クーポンＩＤなどを入力する。また、ステータスを“ｄｅｌｅｔｅｄ（削除済み）”とする。これが、「ｇｅｔＩｎｓｔａｎｃｅ」１２０１および「ｕｐｄａｔｅＩｎｓｔａｎｃｅ」１２０２である。
　そして、施設クーポンインスタンス１１２の更新に成功したか否かを判断する（ステップＳ１３０２）。ここで、施設クーポンインスタンス１１２の更新に失敗した場合（ステップＳ１３０２：Ｎｏ）は、エラーが発生したとして、処理を中断し（ステップＳ１３０３）、一連の処理を終了する。
　一方、施設クーポンインスタンス１１２の更新に成功した場合（ステップＳ１３０２：Ｙｅｓ）は、つぎに、クーポン契約定義１１５を更新する（ステップＳ１３０４）。ここでは、施設ＩＤ、クーポンＩＤ、クーポン発行に必要な施設訪問回数として桁数の多い固定値などを入力する。また、ステータスを“ｄｅｌｅｔｅｄ（削除済み）”とする。これが、「ｕｐｄａｔｅＣｏｎｔｒａｃｔＤｅｆｉｎｉｔｉｏｎ」１２０３である。そして、クーポン契約定義１１５の更新に成功したか否かを判断する（ステップＳ１３０５）。
　ここで、クーポン契約定義１１５の更新に失敗した場合（ステップＳ１３０５：Ｎｏ）は、エラーが発生したことを出力し、処理は継続する（ステップＳ１３０６）。その後、ステップＳ１３０７へ移行する。エラー発生時に処理を中断すると、その後の処理が動作せず、定義が削除されないままとなってしまうことを回避するためである。
　一方、クーポン契約定義１１５の更新に成功した場合（ステップＳ１３０５：Ｙｅｓ）は、つぎに、ポイント契約定義１１３を更新する（ステップＳ１３０７）。ここでは、施設ＩＤ、クーポンＩＤなどを入力する。また、ステータスを“ｄｅｌｅｔｅｄ（削除済み）”とする。これも、「ｕｐｄａｔｅＣｏｎｔｒａｃｔＤｅｆｉｎｉｔｉｏｎ」１２０３である。そして、ポイント契約定義１１３の更新に成功したか否かを判断する（ステップＳ１３０８）。
　ここで、ポイント契約定義１１３の更新に失敗した場合（ステップＳ１３０８：Ｎｏ）は、エラーが発生したことを出力し、処理は継続する（ステップＳ１３０９）。その後、ステップＳ１３１０へ移行する。ポイント契約定義１１３の更新に成功した場合（ステップＳ１３０８：Ｙｅｓ）も、ステップＳ１３１０へ移行する。
　つぎに、クーポン資産定義１１６を更新する（ステップＳ１３１０）。ここでは、施設ＩＤ、クーポンＩＤなどを入力する。また、ステータスを“ｄｅｌｅｔｅｄ（削除済み）”とする。これが、「ｕｐｄａｔｅＡｓｓｅｔＤｅｆｉｎｉｔｉｏｎ」１２０４である。そして、クーポン資産定義１１６の更新に成功したか否かを判断する（ステップＳ１３１１）。
　ここで、クーポン資産定義１１６の更新に失敗した場合（ステップＳ１３１１：Ｎｏ）は、エラーが発生したことを出力し、処理は継続する（ステップＳ１３１２）。その後、ステップＳ１３１３へ移行する。クーポン資産定義１１６の更新に成功した場合（ステップＳ１３１１：Ｙｅｓ）も、ステップＳ１３１３へ移行する。
　つぎに、ポイント資産定義１１４を更新する（ステップＳ１３１３）。ここでは、施設ＩＤ、クーポンＩＤなどを入力する。また、ステータスを“ｄｅｌｅｔｅｄ（削除済み）”とする。これも、「ｕｐｄａｔｅＡｓｓｅｔＤｅｆｉｎｉｔｉｏｎ」１２０４である。そして、ポイント資産定義１１４の更新に成功したか否かを判断する（ステップＳ１３１４）。ここで、ポイント資産定義１１４の更新に失敗した場合（ステップＳ１３１４：Ｎｏ）は、エラーが発生したことを出力し、処理は継続し（ステップＳ１３１５）、一連の処理を終了する。ポイント資産定義１１４の更新に成功した場合（ステップＳ１３１４：Ｙｅｓ）も、一連の処理を終了する。
　また、未処理のユーザＩＤが存在する場合には、当該ユーザの利用者クーポンインスタンス１１９を削除する処理をおこなうようにしてもよい。
（クーポン発行の一連の処理）
　つぎに、クーポン発行の一連の処理の手順について説明する。図１４Ａ～図１４Ｃは、クーポン発行の一連の処理の手順の一例を示すフローチャートである。図１４Ａのフローチャートにおいて、ユーザは、表示されたＱＲコードをユーザが所有するスマートフォンなどでスキャンする（ステップＳ１４０１）。
　スキャンされたＱＲコードを所定の記憶領域に記録する（ステップＳ１４０２）。この処理は、ビジネスロジック（たとえば、図示を省略するビジネスロジックＡＰＩなど）によって実行することができる。その後は、ブロックチェーン内における処理となる。
　ステップＳ１４０３において、ＱＲコードが記憶されたことを契機に、ｖｉｓｉｔＡＰＩを起動する（ステップＳ１４０３）。ｖｉｓｉｔＡＰＩにおける処理の詳細については、後述する図１５において説明する。その後は、ブロックチェーン内におけるクーポン発行機能による処理となる。
　クライアントピア２０２は、トランザクション・リクエストを生成し、エンドーザーピア２０３へ配信する（ステップＳ１４０４）。その後は、エンドーザーピア２０３による処理となる。
　エンドーザーピア２０３は、スマートウォレット・チェーンコード２１３を実行し（ステップＳ１４０５）、その後、図１４ＢのフローチャートのステップＳ１４１１へ移行する。その後は、スマートウォレット・チェーンコード２１３による処理となる。
　また、エンドーザーピア２０３は、ワールドステート（ＷＳ）２１１内のユーザ情報を確認する（ステップＳ１４０６）。そして、ＷＳ２１１内に最新のユーザ情報があるか否かを判断し（ステップＳ１４０７）、最新のユーザ情報がある場合（ステップＳ１４０７：Ｙｅｓ）は、当該最新のユーザ情報を取得する（ステップＳ１４０８）。最新のユーザ情報がない場合（ステップＳ１４０７：Ｎｏ）は何もしない。その後、図１４ＢのフローチャートのステップＳ１４１３へ移行し、スマートウォレット・チェーンコード２１３による処理をおこなう。
　図１４Ｂのフローチャートは、スマートウォレット・チェーンコードにおける処理の内容である。スマートウォレット・チェーンコード２１３において、ユーザテーブル３０１から施設ユーザ情報を取得する（ステップＳ１４１１）。そして、施設ユーザが存在するか否かを判断する（ステップＳ１４１２）。
　ここで、施設ユーザが存在しない場合（ステップＳ１４１２：Ｎｏ）は、一連の処理を終了する。一方、施設ユーザが存在する場合（ステップＳ１４１２：Ｙｅｓ）は、つぎに、ウォレットテーブル３０２にユーザＩＤと施設ＩＤが記録されているか否かを判断する（ステップＳ１４１３）。
　ここで、ウォレットテーブル３０２にユーザＩＤと施設ＩＤが記録されている場合（ステップＳ１４１３：Ｙｅｓ）は、最新のユーザ情報を取得し（ステップＳ１４１４）、ステップＳ１４１７へ移行する。一方、ウォレットテーブル３０２にユーザＩＤと施設ＩＤが記録されていない場合（ステップＳ１４１３：Ｎｏ）は、何もせずに、ステップＳ１４１７へ移行する。
　また、スマートウォレット・チェーンコード２１３において、契約定義テーブル３０５からポイント契約定義１１３を取得する（ステップＳ１４１５）。そして、取得したポイント契約定義１１３に基づいて、資産定義テーブル３０４内にポイント資産定義１１４を作成し（ステップＳ１４１６）、ステップＳ１４１７へ移行する。ステップＳ１４１７においては、ポイント資産定義１１４を確認する（ステップＳ１４１７）。ここでは、クーポンを取得するのに何ポイント必要であるとされているのかについて確認する。その後、ステップＳ１４２０へ移行する。
　また、スマートウォレット・チェーンコード２１３において、契約定義テーブル３０５からクーポン契約定義１１５を取得する（ステップＳ１４１８）。そして、取得したクーポン契約定義１１５に基づいて、資産定義テーブル３０４内にクーポン資産定義１１６を作成し（ステップＳ１４１９）、ステップＳ１４２０へ移行する。
　その後、ステップＳ１４２０においては、クーポン資産定義１１６を確認する（ステップＳ１４２０）。ここでは、ステータスが“ａｖａｉｌａｂｌｅ（発行中）”になっているクーポン資産定義１１６の一覧を確認する。そして、当該ユーザのポイント資産定義１１４におけるポイント数がクーポンの交換できる所定ポイント数に達しているか否かを判断する（ステップＳ１４２１）。ここで、いずれも所定のポイント数に達していない場合（ステップＳ１４２１：Ｎｏ）は、ステップＳ１４２０へ戻る。
　一方、所定のポイント数に達しているものがある場合（ステップＳ１４２１：Ｙｅｓ）は、そのウォレット（ポイントインスタンス１１８）からそのポイント数を減算し（ステップＳ１４２２）、その代わりに、そのウォレット（利用者クーポンインスタンス１１９）へクーポンを追加する（ステップＳ１４２３）。そして、履歴テーブル３０３を更新し（ステップＳ１４２４）、レスポンスをエンドーザーピア２０３へ返却する（ステップＳ１４２５）。ここまでが、スマートウォレット・チェーンコード２１３における処理である。その後、図１４ＣのフローチャートのステップＳ１４３１、Ｓ１４３２へ移行する。
　図１４Ｃのフローチャートにおいて、エンドーザーピア２０３は、図１４ＢのステップＳ１４２４においておこなわれた履歴テーブル３０３の更新の仮実行結果に基づいて、ＴＤ２１２を更新する（ステップＳ１４３１）。そして、ステップＳ１４３７、Ｓ１４３８へ移行する。また、エンドーザーピア２０３は、クライアントピア２０２へレスポンスを送り（ステップＳ１４３２）、ステップＳ１４３３へ移行する。ここまでが、エンドーザーピア２０３における処理である。
　ステップＳ１４３３において、クライアントピア２０２は、エンドーザーピア２０３からのレスポンスを受けると、オーダラーピア２０１へレスポンスを送る（ステップＳ１４３３）。
　オーダラーピア２０１では、合意がなされた仮実行結果をブロックに記載する（ステップＳ１４３４）。そして、新しいブロックをすべてのＨＭＯ２００へ配信する（ステップＳ１４３５）。つぎに、アンカーピア２０６が、新しいブロックをすべてのピアへ配信する（ステップＳ１４３６）。
　その後、すべてのピアにおいて、ＴＤ２１２を最新の有効ブロックに更新する（ステップＳ１４３７）。また、キーＩＤを確認し、ＷＳ内のユーザ情報を最新の状態に更新し（ステップＳ１４３８）、一連の処理を終了する。
（ＡＰＩのシーケンス）
　つぎに、３つのＡＰＩのシーケンスの内容について、図１５～図１７を用いて説明する。図１５は、ｖｉｓｉｔ　ＡＰＩのシーケンスの一例を示すフローチャートである。ｖｉｓｉｔ　ＡＰＩは、上述した図１４Ａに示したように、ＱＲコードが記録された場合に、起動するＡＰＩである。
　図１５のフローチャートにおいて、まず、ユーザＩＤおよび施設ＩＤを入力する（ステップＳ１５０１）。そして、ユーザＩＤが存在するか否かを判断する（ステップＳ１５０２）。ここで、ユーザＩＤが存在しない場合（ステップＳ１５０２：Ｎｏ）は、出力種別：「ユーザが見つからない」を出力し（ステップＳ１５０３）、一連の処理を終了する。
　一方、ユーザＩＤが存在する場合（ステップＳ１５０２：Ｙｅｓ）は、入力された施設ＩＤに該当する施設が存在するか否かを判断する（ステップＳ１５０４）。ここで、施設が存在しない場合（ステップＳ１５０４：Ｎｏ）は、出力種別：「正常終了しました」を出力し（ステップＳ１５０５）、一連の処理を終了する。
　一方、施設が存在する場合（ステップＳ１５０４：Ｙｅｓ）は、クーポン定義一覧を取得する（ステップＳ１５０６）。そして、そのクーポンは、ステータスが“ａｖａｉｌａｂｌｅ（発行中）”か否かを判断する（ステップＳ１５０７）。ここで、ステータスが“ａｖａｉｌａｂｌｅ”でない場合（ステップＳ１５０７：Ｎｏ）は、ステップＳ１５１４へ移行する。
　一方、ステータスが“ａｖａｉｌａｂｌｅ”である場合（ステップＳ１５０７：Ｙｅｓ）は、ユーザがポイントインスタンス１１８を作成済みか否かを判断する（ステップＳ１５０８）。ここで、ポイントインスタンス１１８を作成済みの場合（ステップＳ１５０８：Ｙｅｓ）は、ポイントインスタンス１１８を更新する（ステップＳ１５０９）。ポイントインスタンス１１８を作成済みでない場合（ステップＳ１５０８：Ｎｏ）は、ポイントインスタンス１１８を作成する（ステップＳ１５１０）。
　つぎに、ユーザがクーポンインスタンス１１９を作成済みか否かを判断する（ステップＳ１５１１）。ここで、クーポンインスタンス１１９を作成済みの場合（ステップＳ１５１１：Ｙｅｓ）は、ステップＳ１５１３へ移行する。クーポンインスタンス１１９を作成済みでない場合（ステップＳ１５１１：Ｎｏ）は、クーポンインスタンス１１９を作成し（ステップＳ１５１２）、ステップＳ１５１３へ移行する。
　そして、クーポン発行を試行する（ステップＳ１５１３）。つぎに、まだクーポンがあるかを判断し（ステップＳ１５１４）、まだ、クーポンがある場合（ステップＳ１５１４：Ｙｅｓ）は、ステップＳ１５０７へ戻って、クーポンがなくなるまで、ステップＳ１５０７～ステップＳ１５１４の各処理を繰り返しおこなう。その後、クーポンがすべてなくなった場合（ステップＳ１５１４：Ｎｏ）は、出力種別：「正常終了しました」を出力し（ステップＳ１５１５）、一連の処理を終了する。
　図１６は、ｇｅｔＣｏｕｐｏｎｓ　ＡＰＩのシーケンスの一例を示すフローチャートである。ｇｅｔＣｏｕｐｏｎｓ　ＡＰＩは、クーポンを取得する場合に、起動するＡＰＩである。
　図１６のフローチャートにおいて、まず、ユーザＩＤおよび施設ＩＤを入力する（ステップＳ１６０１）。そして、ユーザＩＤが存在するか否かを判断する（ステップＳ１６０２）。ここで、ユーザＩＤが存在しない場合（ステップＳ１６０２：Ｎｏ）は、出力種別：「ユーザが見つからない」を出力し（ステップＳ１６０３）、一連の処理を終了する。一方、ユーザＩＤが存在する場合（ステップＳ１６０２：Ｙｅｓ）は、インスタンス一覧を取得する（ステップＳ１６０４）。
　つぎに、インスタンス一覧の中から一つのインスタンスを抽出し、そのインスタンスがクーポンインスタンス１１９であるか否かを判断する（ステップＳ１６０５）。ここで、クーポンインスタンス１１９でない場合（ステップＳ１６０５：Ｎｏ）は、ステップＳ１６０８へ移行する。一方、クーポンインスタンス１１９である場合（ステップＳ１６０５：Ｙｅｓ）は、ｑｕａｎｔｉｔｙ（数量）が１以上であるか否かを判断する（ステップＳ１６０６）。
　ここで、１以上である場合（ステップＳ１６０６：Ｙｅｓ）は、そのクーポンを返却用配列に追加し（ステップＳ１６０７）、ステップＳ１６０８へ移行する。一方、１以上でない場合（ステップＳ１６０６：Ｎｏ）は、何もせずに、ステップＳ１６０８へ移行する。
　つぎに、まだ、インスタンス一覧の中に、未処理のインスタンスがあるかを判断し（ステップＳ１６０８）、まだ、インスタンスがある場合（ステップＳ１６０８：Ｙｅｓ）は、ステップＳ１６０５へ戻って、インスタンスがなくなるまで、ステップＳ１６０５～ステップＳ１６０８の各処理を繰り返しおこなう。その後、インスタンスがすべてなくなった場合（ステップＳ１６０８：Ｎｏ）は、出力種別：「返却用配列」を出力し（ステップＳ１６０９）、一連の処理を終了する。これにより、ユーザのクーポンインスタンス１１９に存在するクーポンを抽出することができる。
　図１７は、ｕｓｅＣｏｕｐｏｎ　ＡＰＩのシーケンスの一例を示すフローチャートである。ｕｓｅＣｏｕｐｏｎ　ＡＰＩは、ユーザがクーポンを使用する場合に、起動するＡＰＩである。
　図１７のフローチャートにおいて、まず、ユーザＩＤ、施設ＩＤおよびクーポンＩＤを入力する（ステップＳ１７０１）。そして、ユーザＩＤが存在するか否かを判断する（ステップＳ１７０２）。ここで、ユーザＩＤが存在しない場合（ステップＳ１７０２：Ｎｏ）は、出力種別：「ユーザが見つからない」を出力し（ステップＳ１７０３）、一連の処理を終了する。一方、ユーザＩＤが存在する場合（ステップＳ１７０２：Ｙｅｓ）は、施設ＩＤが存在するか否かを判断する（ステップＳ１７０４）。
　ここで、施設ＩＤが存在しない場合（ステップＳ１７０４：Ｎｏ）は、出力種別：「クーポンが見つからない」を出力し（ステップＳ１７０５）、一連の処理を終了する。一方、施設ＩＤが存在する場合（ステップＳ１７０４：Ｙｅｓ）は、クーポン契約定義１１５が存在するか否かを判断する（ステップＳ１７０６）。ここで、クーポン契約定義１１５が存在しない場合（ステップＳ１７０６：Ｎｏ）は、出力種別：「クーポンが見つからない」を出力し（ステップＳ１７０７）、一連の処理を終了する。
　一方、クーポン契約定義１１５が存在する場合（ステップＳ１７０６：Ｙｅｓ）は、クーポン契約定義１１５のステータスが、“ｄｅｌｅｔｅｄ（削除済み）”か否かを判断する（ステップＳ１７０８）。ここで、ステータスが、“ｄｅｌｅｔｅｄ”である場合（ステップＳ１７０８：Ｙｅｓ）は、出力種別：「クーポンは削除済み」を出力し（ステップＳ１７０９）、一連の処理を終了する。
　一方、クーポン契約定義１１５のステータスが、“ｄｅｌｅｔｅｄ”でない場合（ステップＳ１７０８：Ｎｏ）は、クーポンインスタンス１１９の取得を試行する（ステップＳ１７１０）。そして、クーポンインスタンス１１９の取得に成功したか否かを判断する（ステップＳ１７１１）。ここで、クーポンインスタンス１１９の取得に失敗した場合（ステップＳ１７１１：Ｎｏ）は、出力種別：「クーポンを持っていない」を出力し（ステップＳ１７１２）、一連の処理を終了する。
　一方、クーポンインスタンス１１９の取得に成功した場合（ステップＳ１７１１：Ｙｅｓ）は、ｑｕａｎｔｉｔｙ（数量）が１以上であるか否かを判断する（ステップＳ１７１３）。ここで、１以上でない場合（ステップＳ１７１３：Ｎｏ）は、出力種別：「クーポンを持っていない」を出力し（ステップＳ１７１４）、一連の処理を終了する。
　一方、１以上である場合（ステップＳ１７１３：Ｙｅｓ）は、クーポンインスタンス１１９を更新し（ステップＳ１７１５）、更新に成功したか否かを判断する（ステップＳ１７１６）。ここで、更新に失敗した場合（ステップＳ１７１６：Ｎｏ）は、出力種別：「内部エラー」を出力し（ステップＳ１７１７）、一連の処理を終了する。一方、更新に成功した場合（ステップＳ１７１６：Ｙｅｓ）は、出力種別：「正常終了しました」を出力し（ステップＳ１７１８）、一連の処理を終了する。これにより、ユーザは、取得したクーポンを利用することができる。
　以上説明したように、本実施の形態によれば、クーポン発行サービスを提供するに当たり、ユーザの所定の行動に対して付与されるポイントに関するポイント定義（ポイント契約定義１１３、ポイント資産定義１１４）およびポイントインスタンス１１８と、ポイントに連動してユーザが享受するクーポンに関するクーポン定義（クーポン契約定義１１５、クーポン資産定義１１６）およびクーポンインスタンス１１９と、を作成して、分散台帳（ＴＤ２１２）に反映させ、ユーザの行動履歴を受け付けた場合に、ポイント契約定義１１３に基づいて、ポイントインスタンス１１８の値を更新して、分散台帳（ＴＤ２１２）に反映させ、クーポン契約定義１１５に基づいて、ポイントインスタンス１１８の値がクーポン契約定義１１５に定められた条件に達した場合に、クーポンインスタンス１１９の値を更新して、分散台帳（ＴＤ２１２）に反映させる、すなわち、ブロックチェーンに記録させる、制御部（エンドーザーピア２０３）を有する。
　これにより、どのようなイベントのどのような状態に対してどのようなインセンティブを発行するかを定義したスクリプトを登録でき、行動履歴をカウントしてクーポンを発行する、サーバサイドの処理部を自動生成することができる。このようなことから、ユーザ数が増えるたびにサーバサイドの設定処理が発生することを抑制することができる。
　また、処理部の生成が自動化されるため、人手による設定ミスの発生も防止することができる。また、ユーザによるサービス利用の申し込みから実際のサービス開始までの時間を短縮することができる。このように、ブロックチェーンによる、クーポン発行サービスの運営を効率化する技術を提供することができる。
　また、クーポン発行サービスを、ブロックチェーンにより実現することから、ブロックチェーンが有するセキュリティー、スケーラビリティー、機密性などの効果を有することができる。
　また、本実施の形態によれば、ブロックチェーン（ＴＤ２１２）は、ポイント定義に応じたポイントインスタンス１１８を作成する第１のスクリプトと、クーポン定義に応じたクーポンインスタンス１１９を作成する第２のスクリプトと、を格納しており、制御部（エンドーザーピア２０３）は、新たなユーザが登録されたことを検出すると、第１のスクリプトおよび第２のスクリプトを実行することにより、ポイント定義に応じた新たなポイントインスタンス１１８と、クーポン定義に応じた新たなクーポンインスタンス１１９と、を新たなユーザに対応付けて作成し、作成したポイントインスタンス１１８およびクーポンインスタンス１１９をブロックチェーン（ＴＤ２１２）に記録させることができる。
　また、本実施の形態によれば、ポイント資産定義１１４、ポイント契約定義１１３、クーポン資産定義１１６およびクーポン契約定義１１５を作成して、分散台帳（ＴＤ２１２）に反映させることによって、クーポン発行サービスをあらたに登録するので、クーポン発行サービスの登録を簡易におこなうことができる。
　また、本実施の形態によれば、ポイント契約定義１１３およびクーポン契約定義１１５の少なくともいずれかを更新して、分散台帳（ＴＤ２１２）に反映させることによって、クーポン発行サービスの内容を変更するので、クーポン発行サービスの内容の変更を簡易におこなうことができる。
　また、本実施の形態によれば、ポイント契約定義１１３およびクーポン契約定義１１５の更新、たとえば、定義のステータスを変更する更新をして、分散台帳（ＴＤ２１２）に反映させることによって、クーポン発行サービスにおけるクーポンの新規発行の停止をするので、クーポン発行サービスにおけるクーポンの新規発行の停止を簡易にすることができる。
　また、本実施の形態によれば、ポイント資産定義１１４、ポイント契約定義１１３、クーポン資産定義１１６およびクーポン契約定義１１５の更新をして、分散台帳（ＴＤ２１２）に反映させることによって、クーポン発行サービスの削除をするので、クーポン発行サービスの削除（廃止）を簡易にすることができる。
　また、本実施の形態によれば、制御部（エンドーザーピア２０３）は、ブロックチェーンのスマートウォレット・チェーンコード２１３を用いるので、各定義の管理を自動化することができる。
　なお、本実施の形態で説明したクーポン発行方法は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することにより実現することができる。クーポン発行プログラムは、ハードディスク、フレキシブルディスク、ＣＤ（Ｃｏｍｐａｃｔ　Ｄｉｓｃ）－ＲＯＭ、ＭＯ（Ｍａｇｎｅｔｏ－Ｏｐｔｉｃａｌ　Ｄｉｓｋ）、ＤＶＤ（Ｄｉｇｉｔａｌ　Ｖｅｒｓａｔｉｌｅ　Ｄｉｓｋ）、フラッシュメモリ、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ　Ｓｅｒｉａｌ　Ｂｕｓ）メモリなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、クーポン発行プログラムは、インターネットなどのネットワークを介して配布してもよい。
　１００　クーポン発行システム
　１０１　ブロックチェーン・データストア
　１０２　管理者インタフェース
　１０３　ユーザアプリケーション
　１０４　クーポン定義作成処理部
　１０５　施設利用実績登録処理部
　１０６　クーポン一覧取得処理部
　１０７　クーポン利用処理部
　１０８　ブロックチェーンＡＰＩ
　１１１　施設ユーザ
　１１２　施設クーポンインスタンス
　１１３　ポイント契約定義
　１１４　ポイント資産定義
　１１５　クーポン契約定義
　１１６　クーポン資産定義
　１１７　利用者ユーザ
　１１８　ポイントインスタンス
　１１９　（利用者）クーポンインスタンス
　２００ａ、２００ｂ　ハイパーレッジャー・メンバー・オーガニゼーション（Ｈｙｐｅｒｌｅｄｇｅｒ　Ｍｅｍｂｅｒ　Ｏｒｇａｎｉｚａｔｉｏｎ（ＨＭＯ））
　２０１　オーダラー（Ｏｒｄｅｒｅｒ）ピア
　２０２　クライアント（Ｃｌｉｅｎｔ）ピア
　２０３　エンドーザー（Ｅｎｄｏｒｓｅｒ）ピア
　２０４、２０５　ゼネラル（Ｇｅｎｅｒａｌ）ピア
　２０６　アンカー（Ａｎｃｈｏｒ）ピア
　２１１　ワールドステート（Ｗｏｒｌｄ　Ｓｔａｔｅ（ＷＳ））
　２１２　トランザクション・データベース（Ｔｒａｎｓａｃｔｉｏｎ　Ｄａｔａｂａｓｅ（ＴＤ））
　２１３　スマートウォレット・チェーンコード（ＳｍａｒｔＷａｌｌｅｔ　ＣｈａｉｎＣｏｄｅ）
　３０１　ユーザテーブル（ｕｓｅｒＴａｂｌｅ）
　３０２　ウォレットテーブル（ｗａｌｌｅｔＴａｂｌｅ）
　３０３　履歴テーブル（ｈｉｓｔｏｒｙＴａｂｌｅ）
　３０４　資産定義テーブル（ａｓｓｅｔＤｅｆｉｎｉｔｉｏｎＴａｂｌｅ）
　３０５　契約定義テーブル（ｃｏｎｔｒａｃｔＤｅｆｉｎｉｔｉｏｎＴａｂｌｅ）

Claims (13)

  1. 　クーポン発行サービスに関する定義情報の入力を受け付けると、前記定義情報に基づき、ユーザの所定の行動に対して付与されるポイントに関するポイント定義、および、前記ポイントに応じて前記ユーザに提供されるクーポンに関するクーポン定義を作成し、作成した前記ポイント定義および前記クーポン定義をブロックチェーンに記録させ、
    　前記ユーザの行動履歴を受け付けた場合、前記ポイント定義に基づき、前記ユーザのポイントインスタンスの値を更新し、更新した前記ポイントインスタンスの値を前記ブロックチェーンに記録させ、
    　更新した前記ポイントインスタンスの値が前記クーポン定義に定められた条件を満たす場合、前記ユーザのクーポンインスタンスの値を更新し、更新した前記クーポンインスタンスの値を前記ブロックチェーンに記録させる、
    　制御部を有することを特徴とするクーポン発行装置。
  2. 　前記ブロックチェーンは、前記ポイント定義に応じたポイントインスタンスを作成する第１のスクリプトと、前記クーポン定義に応じたクーポンインスタンスを作成する第２のスクリプトと、を格納しており、
    　前記制御部は、新たなユーザが登録されたことを検出すると、前記第１のスクリプトおよび前記第２のスクリプトを実行することにより、前記ポイント定義に応じた新たなポイントインスタンスと、前記クーポン定義に応じた新たなクーポンインスタンスと、を前記新たな前記ユーザに対応付けて作成し、作成した前記ポイントインスタンスおよび前記クーポンインスタンスを前記ブロックチェーンに記録させることを特徴とする請求項１に記載のクーポン発行装置。
  3. 　前記ポイント定義は、前記クーポンの発行可否を定義するポイント契約定義と、前記ポイントインスタンスの有効・無効を定義するポイント資産定義と、からなり、
    　前記クーポン定義は、前記クーポンの発行に必要なポイント条件を定義するクーポン契約定義と、前記クーポンの詳細情報を定義するクーポン資産定義と、からなることを特徴とする請求項１または２に記載のクーポン発行装置。
  4. 　前記ポイント資産定義、前記ポイント契約定義、前記クーポン資産定義および前記クーポン契約定義を作成し、作成した前記ポイント資産定義、前記ポイント契約定義、前記クーポン資産定義および前記クーポン契約定義を前記ブロックチェーンに記録させることによって、クーポン発行サービスをあらたに登録することを特徴とする請求項３に記載のクーポン発行装置。
  5. 　前記ポイント契約定義および前記クーポン契約定義の少なくともいずれかを更新し、更新した前記ポイント契約定義および前記クーポン契約定義の少なくともいずれかを前記ブロックチェーンに記録させることによって、クーポン発行サービスの内容を変更することを特徴とする請求項３に記載のクーポン発行装置。
  6. 　前記ポイント契約定義および前記クーポン契約定義を更新し、更新した前記ポイント契約定義および前記クーポン契約定義を前記ブロックチェーンに記録させることによって、クーポン発行サービスにおけるクーポンの新規発行を停止することを特徴とする請求項３に記載のクーポン発行装置。
  7. 　前記ポイント契約定義および前記クーポン契約定義の更新は、定義のステータスを変更する更新であることを特徴とする請求項６に記載のクーポン発行装置。
  8. 　前記ポイント資産定義、前記ポイント契約定義、前記クーポン資産定義および前記クーポン契約定義を更新し、更新した前記ポイント資産定義、前記ポイント契約定義、前記クーポン資産定義および前記クーポン契約定義を前記ブロックチェーンに記録させることによって、クーポン発行サービスを削除することを特徴とする請求項３に記載のクーポン発行装置。
  9. 　前記ポイント資産定義、前記ポイント契約定義、前記クーポン資産定義および前記クーポン契約定義の更新は、定義のステータスを変更する更新であることを特徴とする請求項８に記載のクーポン発行装置。
  10. 　前記制御部は、前記ブロックチェーンのスマートウォレット・チェーンコードを用いることを特徴とする請求項１に記載のクーポン発行装置。
  11. 　クーポン発行サービスに関する定義情報の入力を受け付けると、前記定義情報に基づき、ユーザの所定の行動に対して付与されるポイントに関するポイント定義、および、前記ポイントに応じて前記ユーザに提供されるクーポンに関するクーポン定義を作成し、作成した前記ポイント定義および前記クーポン定義をブロックチェーンに記録させ、
    　前記ユーザの行動履歴を受け付けた場合、前記ポイント定義に基づき、前記ユーザのポイントインスタンスの値を更新し、更新した前記ポイントインスタンスの値を前記ブロックチェーンに記録させ、
    　更新した前記ポイントインスタンスの値が前記クーポン定義に定められた条件を満たす場合、前記ユーザのクーポンインスタンスの値を更新し、更新した前記クーポンインスタンスの値を前記ブロックチェーンに記録させることを特徴とするクーポン発行システム。
  12. 　クーポン発行サービスに関する定義情報の入力を受け付けると、前記定義情報に基づき、ユーザの所定の行動に対して付与されるポイントに関するポイント定義、および、前記ポイントに応じて前記ユーザに提供されるクーポンに関するクーポン定義を作成し、作成した前記ポイント定義および前記クーポン定義をブロックチェーンに記録させ、
    　前記ユーザの行動履歴を受け付けた場合、前記ポイント定義に基づき、前記ユーザのポイントインスタンスの値を更新し、更新した前記ポイントインスタンスの値を前記ブロックチェーンに記録させ、
    　更新した前記ポイントインスタンスの値が前記クーポン定義に定められた条件を満たす場合、前記ユーザのクーポンインスタンスの値を更新し、更新した前記クーポンインスタンスの値を前記ブロックチェーンに記録させる処理を、コンピュータが実行することを特徴とするクーポン発行方法。
  13. 　クーポン発行サービスに関する定義情報の入力を受け付けると、前記定義情報に基づき、ユーザの所定の行動に対して付与されるポイントに関するポイント定義、および、前記ポイントに応じて前記ユーザに提供されるクーポンに関するクーポン定義を作成し、作成した前記ポイント定義および前記クーポン定義をブロックチェーンに記録させ、
    　前記ユーザの行動履歴を受け付けた場合、前記ポイント定義に基づき、前記ユーザのポイントインスタンスの値を更新し、更新した前記ポイントインスタンスの値を前記ブロックチェーンに記録させ、
    　更新した前記ポイントインスタンスの値が前記クーポン定義に定められた条件を満たす場合、前記ユーザのクーポンインスタンスの値を更新し、更新した前記クーポンインスタンスの値を前記ブロックチェーンに記録させる処理を、コンピュータに実行させることを特徴とするクーポン発行プログラム。
PCT/JP2019/000804 2019-01-11 2019-01-11 クーポン発行装置、クーポン発行システム、クーポン発行方法およびクーポン発行プログラム Ceased WO2020144872A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2019/000804 WO2020144872A1 (ja) 2019-01-11 2019-01-11 クーポン発行装置、クーポン発行システム、クーポン発行方法およびクーポン発行プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2019/000804 WO2020144872A1 (ja) 2019-01-11 2019-01-11 クーポン発行装置、クーポン発行システム、クーポン発行方法およびクーポン発行プログラム

Publications (1)

Publication Number Publication Date
WO2020144872A1 true WO2020144872A1 (ja) 2020-07-16

Family

ID=71521069

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/000804 Ceased WO2020144872A1 (ja) 2019-01-11 2019-01-11 クーポン発行装置、クーポン発行システム、クーポン発行方法およびクーポン発行プログラム

Country Status (1)

Country Link
WO (1) WO2020144872A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2023007937A (ja) * 2021-07-02 2023-01-19 ｂａｃｏｏｒ ｄＡｐｐｓ株式会社 管理システム及びノンファンジブルトークンの管理方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008310554A (ja) * 2007-06-14 2008-12-25 Seikatsu Kyodo Kumiai Coop Sapporo 商品情報管理サーバ
US20170236143A1 (en) * 2016-02-15 2017-08-17 Shannon Code System and process for electronic tokenization of product brand loyalty and incentives
JP2018028762A (ja) * 2016-08-16 2018-02-22 株式会社Ｓｏｕｎｄ−Ｆ クーポン管理システムおよび方法
US20180315072A1 (en) * 2017-05-01 2018-11-01 Greg Rubin Method and system of facilitating management of cryptocurrency based loyalty points associated with one or more of a product and a service

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008310554A (ja) * 2007-06-14 2008-12-25 Seikatsu Kyodo Kumiai Coop Sapporo 商品情報管理サーバ
US20170236143A1 (en) * 2016-02-15 2017-08-17 Shannon Code System and process for electronic tokenization of product brand loyalty and incentives
JP2018028762A (ja) * 2016-08-16 2018-02-22 株式会社Ｓｏｕｎｄ−Ｆ クーポン管理システムおよび方法
US20180315072A1 (en) * 2017-05-01 2018-11-01 Greg Rubin Method and system of facilitating management of cryptocurrency based loyalty points associated with one or more of a product and a service

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2023007937A (ja) * 2021-07-02 2023-01-19 ｂａｃｏｏｒ ｄＡｐｐｓ株式会社 管理システム及びノンファンジブルトークンの管理方法
JP7773724B2 (ja) 2021-07-02 2025-11-20 ｂａｃｏｏｒ ｄＡｐｐｓ株式会社 管理システム及びノンファンジブルトークンの管理方法

Similar Documents

Publication Publication Date Title
US20190034395A1 (en) Combining modalities for collaborating while editing and annotating files
CN106779613A (zh) 一种用于审批配置的方法与装置
CA2999572A1 (en) Systems and methods for converting emails to chat conversations
KR20200049817A (ko) 신뢰된 트랜잭션 배송을 지원하기 위한 용적측정 데이터의 인코딩
JP2021149869A (ja) 印刷システム、印刷装置、制御方法及びプログラム
JP2011138225A (ja) クラスタシステム、情報処理装置、制御方法、及びプログラム
JP2017094692A (ja) 制御装置、管理システム、制御方法、およびプログラム
CN120407296A (zh) 数据备份方法和设备
JPWO2013031101A1 (ja) コンテンツ管理装置及びコンテンツ管理方法
WO2020144872A1 (ja) クーポン発行装置、クーポン発行システム、クーポン発行方法およびクーポン発行プログラム
JP6194965B2 (ja) 情報処理装置、制御方法、及びコンピュータプログラム
JP5350026B2 (ja) ワークフロー処理システム、ワークフロー処理装置、及びワークフロー処理方法
JP6298288B2 (ja) 情報処理装置、情報処理方法、及びプログラム
JP2004133598A (ja) 複数データベースの二重化制御プログラム
KR20100104453A (ko) 멀티미디어 컨텐츠 제작 장치 및 방법
CN109074403A (zh) 运用管理装置、运用管理方法以及运用管理系统
US20070005811A1 (en) Computer-implemented method, system, and interface for managing commands for a terminal session
JP6526274B2 (ja) 情報処理装置とその制御方法、及びプログラム
CN114168820A (zh) 一种模型驱动的数据服务可视化编排方法及系统
JP2018088128A (ja) サーバ、その処理方法及びプログラム
KR102545266B1 (ko) 복수의 포맷 변환 서버들의 상태를 기초로 문서 파일의 포맷 변환 작업을 할당하기 위한 스케줄링을 수행하는 스케줄링 장치 및 그 동작 방법
JP2011134267A (ja) 情報処理装置、情報処理方法、情報処理システム、プログラム、記録媒体
Liu Multi-modal generative AI with foundation models
JP7777834B2 (ja) 人工知能ベースの務め推薦装置及び方法
JP7840079B2 (ja) 債権管理装置、債権管理方法、およびプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19908908

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP