Method and product for managing electronic vouchers through a public blockchain contract

Abstract

The invention name of the present disclosure is "Method and product for managing electronic coupons through public blockchain contract". The present disclosure provides a method and product for managing electronic coupons through a smart contract deployed on a public blockchain. The method comprises: receiving a request for performing an operation related to managing the electronic coupons; verifying the request; and in the case where the verification is positive, performing the requested operation and returning the result of the operation as a response to the request. The scheme of the present disclosure has the advantages of high availability, high security, high liquidity, high flexibility and the like for electronic coupon management.

Description

Technical Field

[0001] The non-limiting and exemplary embodiments of this disclosure generally relate to blockchain-based e-commerce, and more specifically to methods and products for managing electronic coupons through smart contracts deployed on a public blockchain. Background Technology

[0002] With the rapid development of information technology, the e-commerce sector is undergoing unprecedented changes. For example, electronic coupons, as the electronic form of traditional paper coupons, can be stored and used online, and are widely used in retail, catering, entertainment, and other industries, greatly promoting the flexibility and convenience of marketing activities. Specifically, users can easily receive and display electronic coupons to enjoy shopping discounts, service offers, or gift redemptions without carrying physical coupons. For merchants, electronic coupons facilitate the customization of diverse promotional strategies, flexibly setting validity periods, discount levels, and usage conditions, while leveraging the internet for rapid dissemination, effectively enhancing brand exposure and customer loyalty. Their environmentally friendly, efficient, and traceable characteristics are gradually becoming the new normal in marketing. The term "electronic coupon" in this article refers to various electronic cards, electronic vouchers, and / or any equivalents thereof.

[0003] Traditional electronic voucher systems face problems such as security vulnerabilities and inefficient circulation. The rise of blockchain technology offers new ideas and possibilities for solving these challenges. The following is an introduction to blockchain and its related programs and platforms.

[0004] 1. Blockchain

[0005] Blockchain is a distributed ledger technology that securely stores data using cryptography, forming an immutable and traceable data blockchain. As a decentralized technology, it eliminates the need for third-party intermediaries, ensuring the secure and transparent transfer of information and value among participants. Each block contains the hash value of the previous block, forming a chain structure that guarantees the integrity of data history. Blockchain technology includes core components such as cryptographic algorithms, consensus mechanisms, and smart contracts, thereby achieving data immutability, transparency, and a decentralized trust mechanism.

[0006] 2. Smart Contracts

[0007] A smart contract is an executable software program based on blockchain technology. It allows a smart contract to function as a software program running on the blockchain without third-party intervention. It is a series of code (functions) and data (state) located at a specific address on the blockchain. These are deployed on the network and run as programs. Users can interact with smart contracts by submitting transactions to execute specific functions within the smart contract. Smart contracts can define rules like regular contracts and are automatically enforced through code. By default, smart contracts cannot be deleted, and interactions with them are irreversible.

[0008] 3. Ethereum

[0009] Ethereum is an open-source blockchain platform that allows anyone to build and use programs based on blockchain technology. Ethereum's blockchain technology enables developers to create decentralized applications. These applications are not controlled by a single entity and their data interaction with users is transparent. One of Ethereum's most well-known features is the ability to invoke smart contracts. As mentioned above, a smart contract can be viewed as automatically executed contract terms written directly into the code. When specific conditions are met, the smart contract automatically executes the terms of the agreement.

[0010] Currently, there are technical solutions that utilize blockchain to manage electronic coupons, such as those described below.

[0011] Patent application CN201911185065.7 proposes a blockchain-based electronic coupon issuance method, device, and medium. The solution includes: deploying a blockchain platform; receiving coupon information sent by the coupon issuance platform; encrypting a random verification code to obtain an encrypted verification code; hashing the random verification code to obtain a hash verification code; writing the coupon information carrying the encrypted verification code and the hash verification code into the blockchain platform; decrypting the encrypted verification code to obtain a confirmation verification code; if the hash value obtained by hashing the confirmation verification code matches the hash verification code, the electronic coupon is issued to the user. Because the data in the blockchain platform is public and transparent, users can trace the issuance of electronic coupons at any time through appropriate channels. Furthermore, because the blockchain platform uses distributed storage, data tampering by a single node will not take effect, thus ensuring the authenticity and reliability of the data on the blockchain platform.

[0012] Patent application CN201910966491.8 discloses a method, apparatus, device, and storage medium for redeeming coupons. The method includes: receiving a coupon redemption instruction, which includes a user identifier of the user to be redeemed and coupon information of the coupon to be redeemed; obtaining the coupon information corresponding to the user to be redeemed from a user coupon blockchain based on the user identifier, the user coupon blockchain storing coupon information already owned by each user; updating the coupon information corresponding to the user to be redeemed based on the coupon information of the coupon to be redeemed; generating a first user coupon block based on the updated coupon information of the user to be redeemed; and adding the first user coupon block to the user coupon blockchain. In this application's solution, each user's coupon redemption record is stored in the blockchain, making coupon redemption public and resistant to tampering, thus improving the security of coupon redemption and subsequent use.

[0013] Patent application CN202311269650.1 discloses a digital rights SaaS system supporting multi-merchant collaborative marketing. It possesses basic functions including digital rights issuance, operation management, and rights confirmation and verification, enabling the construction of business scenarios that meet the demands of a virtual-real integrated commercial ecosystem. Its technical solution is as follows: The system, through SaaS technology, allows brand enterprises to quickly launch their own digital rights functions by paying only a small access fee, thereby rapidly reaching users. Utilizing the HRC721 protocol, it executes the issuance, confirmation, and verification of rights through smart contracts, achieving full lifecycle on-chain recording of rights. Based on blockchain, it ensures trustworthy rights data, verifiable verification, and executable synthesis mechanisms, innovatively realizing collaborative marketing functions and promoting the development of the entire commercial ecosystem. Summary of the Invention

[0014] The inventors of this disclosure have discovered that most existing technical solutions are based on the structure of consortium blockchains, and only use the blockchain for data recording, playing a role similar to log recording. The actual business logic is not implemented through smart contracts in the blockchain. The general process is as follows:

[0015] 1. Centralized institutions generate electronic coupons and record them in data tables, while simultaneously recording the electronic coupon generation data on the blockchain.

[0016] 2. Users receive corresponding electronic coupons from a centralized institution. The institution maintains a table that maps users to the coupons they receive and records the data on the blockchain.

[0017] 3. User use of electronic coupons. Users display electronic coupon information via QR code on their mobile phones. A centralized institution scans the code to obtain the corresponding coupon data. Simultaneously, the user's electronic coupon usage data is recorded on the blockchain.

[0018] The inventors of this disclosure have also discovered the following technical problems with the existing technical solutions:

[0019] 1. Low availability: The main business logic of the coupon system is still controlled by a centralized institution. If the centralized institution becomes unavailable, the entire system will become unavailable.

[0020] 2. Low Security: The existing electronic coupon system's business logic for issuing and redeeming coupons still operates within a centralized institution, with the blockchain merely recording the corresponding operation logs. Such a system is vulnerable to attacks. Once attackers obtain the data, they can illegally redeem user coupons, leading to user data leaks and financial losses.

[0021] 3. Low liquidity: Existing technical solutions are based on consortium blockchains, which have low liquidity compared to implementations based on public blockchains such as Ethereum.

[0022] One objective of this disclosure is to eliminate or mitigate the aforementioned technical problems. To achieve this objective, the inventors of this disclosure have conceived of a scheme for managing electronic vouchers using smart contracts deployed on a public blockchain (e.g., the Ethereum blockchain) that does not rely on a specific centralized institution. This scheme includes core functions such as minting, distribution, redemption, listing, and purchasing. Furthermore, the smart contracts in this scheme can conform to the token standard (e.g., the ERC-1155 standard) on the aforementioned public blockchain, thereby allowing users to freely trade electronic vouchers on mainstream trading platforms (e.g., OpenSea).

[0023] According to a first aspect of this disclosure, the present disclosure provides a method for managing electronic vouchers executed by a smart contract deployed on a public blockchain, the method comprising: receiving a request for performing an operation relating to managing the electronic vouchers; verifying the request; and, if the verification is positive, performing the requested operation and returning the result of the operation as a response to the request.

[0024] According to a second aspect of this disclosure, a solution of this disclosure provides a non-transitory computer-readable medium with stored instructions, wherein the instructions, when executed by a processor of a computing device, cause the computing device to perform the method of the first aspect described above.

[0025] According to a third aspect of this disclosure, a solution of this disclosure provides a computer program product comprising instructions, wherein the instructions, when executed by a processor of a computing device, cause the computing device to perform the method of the first aspect described above.

[0026] According to a fourth aspect of this disclosure, a computing device is provided. The computing device includes: a memory storing instructions; and a processor, wherein the instructions, when executed by the processor, cause the computing device to perform the method of the first aspect described above.

[0027] The solution disclosed herein has the following advantages for electronic coupon management:

[0028] 1. High availability: Since all business steps are executed through smart contracts on a public blockchain, the solution disclosed herein can be implemented using blockchain network nodes in any region of the world on a public blockchain, and does not depend on any centralized institution.

[0029] 2. High security: Multiple copies of electronic voucher management data are stored on multiple nodes on the blockchain. Therefore, even if a single node is attacked, the entire system will not lose data and crash. Furthermore, various permissions (such as the minting, distribution, and redemption permissions of electronic vouchers) can be easily set in smart contracts, further improving the security of specific business operations.

[0030] 3. High liquidity: Since the smart contract can conform to the token standard (e.g., ERC-1155 standard) on the public blockchain, users can display and freely trade electronic vouchers on mainstream trading platforms (e.g., OpenSea), which helps their circulation.

[0031] 4. High flexibility: For example, various permissions for the minting, distribution, and redemption of electronic coupons can be dynamically added, specified, or revoked in smart contracts, which increases the flexibility of specific business operations. Attached Figure Description

[0032] The above and other aspects, features, and benefits of this disclosure will become more apparent from the following detailed description with reference to the accompanying drawings. In the drawings, the same reference numerals or letters are used to denote the same or equivalent elements. The drawings are shown to facilitate a better understanding of embodiments of this disclosure and are not necessarily drawn to scale, wherein:

[0033] Figure 1 This is a flowchart of a method for managing electronic coupons according to this disclosure;

[0034] Figure 2 An example business sequence for managing electronic coupons is shown according to this disclosure;

[0035] Figure 3 An example business process for managing electronic coupons is shown in accordance with this disclosure;

[0036] Figure 4 It is a schematic block diagram of a computing device according to the present disclosure. Detailed Implementation

[0037] The embodiments described herein will be described more fully below with reference to the accompanying drawings. However, the embodiments herein may be implemented in many different forms and should not be construed as limiting the scope of the appended claims.

[0038] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, nouns indicating objects may refer to a singular or a plural of objects unless the context clearly indicates otherwise. It will be further understood that the terms “comprising,” “including,” and / or “containing” as used herein specify the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof.

[0039] Furthermore, the use of ordinal numbers such as “first,” “second,” and “third” to modify objects in this article does not imply any priority, precedence, or order of one object relative to another, nor does it imply the chronological order in which the actions of methods are executed. Rather, it serves only as a label to distinguish one object with a specific name from another object with the same name.

[0040] Unless otherwise defined, all terms used herein (including technical and scientific terms) shall have the same meaning as generally understood. It will be further understood that terms used herein should be interpreted as having the same meaning as they have in the context of this specification and the relevant technical field, and should not be construed in a restrictive sense unless expressly defined herein.

[0041] Figure 1 This is a flowchart of a method 100 for managing electronic vouchers executed via a smart contract deployed on a public blockchain, according to this disclosure. The method includes: step 101, receiving a request to perform an operation related to managing the electronic vouchers; step 102, verifying the request; and step 103, if the verification is positive, performing the requested operation and returning the result of the operation as a response to the request. Those skilled in the art will understand that if the verification is negative, a response rejecting the request may be returned, or no response may be returned. The scheme of this disclosure is not limited in this respect.

[0042] Next, method 100 and its various embodiments will be combined Figure 2 and Figure 3 It was described further. Understandably, although Figure 2 and Figure 3The example electronic coupon management business sequence and process are shown separately, but as the teachings of this disclosure deepen, those skilled in the art will fully understand that... Figure 2 and Figure 3 Some operations in the above may be optional operations in one or more embodiments of method 100, that is, these operations are not necessary for method 100 (regardless of whether these operations are explicitly stated as "optional" below). Furthermore, Figure 2 and Figure 3 The order of operations shown is merely an example and does not constitute a specific limitation on the order of steps in method 100. Furthermore, for the sake of brevity, Figure 2 Some operations in the process were not included. Figure 3 As shown in the middle, Figure 3 Some operations were not performed in Figure 2 As shown in the diagram. In summary, this disclosure provides... Figure 2 and Figure 3 This is merely intended to enable those skilled in the art to understand the solutions of this disclosure from the examples, and is not intended to be a specific limitation on the solutions of this disclosure.

[0043] As described above, the smart contract disclosed herein is deployed on a public blockchain (e.g., the Ethereum blockchain). This deployment can be accomplished, for example, by a coupon alliance (which may be an alliance organization composed of numerous merchants) or a smart contract program development entity commissioned by the coupon alliance. After deployment, the smart contract can conditionally execute certain business operations when invoked. Operations 1-8 described below correspond to... Figure 2 Operations 1-8 are shown in the example business timing diagram, and can be combined with Figure 3 The example business process is explained together, where electronic vouchers and smart contracts are sometimes referred to as "vouchers" and "contracts," respectively. Those skilled in the art will understand that the names of software program methods, variables, and modifiers appearing in the following description are merely examples to facilitate understanding and are not intended to limit the scope of this disclosure. This disclosure does not restrict the programming language used in developing smart contracts or the various naming conventions within that language.

[0044] As described below, the entity developing the smart contract configures it to perform operations related to managing the electronic vouchers, including, for example, the following operations: voucher minting, setting a whitelist of minters, voucher distribution, authorized redemption, voucher redemption, setting a whitelist for voucher redemption, voucher transfer, setting contract ownership, and listing and purchasing vouchers. This can be achieved, for example, by defining corresponding program methods for these operations in the smart contract, and in this case, sending a request to the smart contract to perform an operation is achieved by invoking the smart contract to request the execution of the program method corresponding to that operation. It is understood that the request can also be sent by sending an explicit request message to the smart contract or by other means. The solution disclosed herein is not limited in this respect.

[0045] 1. Set smart contract ownership

[0046] Contract ownership can be set when the smart contract is initialized. For example, a contract owner variable, contractOwner, can be maintained inside the smart contract, and the address of the entity deploying the smart contract on the public blockchain can be assigned to this variable in the contract initialization method. Figure 2 and Figure 3 This demonstrates the initial setup for smart contract ownership.

[0047] Smart contract ownership can also be further set after it is initially established, i.e., transferring ownership of the contract to another entity. Therefore, in one embodiment, the request is a transfer request for ownership of the smart contract, and the verification may include verifying whether the entity sending the transfer request is the owner of the smart contract (if the transfer of contract ownership is not within the scope of the request). Figure 2 and Figure 3 (As shown in the diagram). A specific implementation related to this operation can be implemented in the following way: A `transferOwnership` procedure method can be defined in the smart contract, which can, for example, transfer ownership of the contract to a specified entity by modifying the aforementioned contract owner variable `contractOwner`; then, an `onlyOwner` modifier can be defined, which allows the operation to continue if the contract caller is determined to be the contract owner, otherwise prohibits the operation from continuing; the `onlyOwner` modifier can then be used to modify the `transferOwnership` procedure method, making it so that it can only be executed by the contract owner.

[0048] By transferring contract ownership, the current contract owner can transfer ownership of the smart contract to another entity. In one example, the current contract owner is the program development entity commissioned by a coupon alliance to develop and deploy the smart contract, and the other entity is the coupon alliance itself. In another example, the current contract owner is a coupon alliance, and the other entity is another coupon alliance. Clearly, the transfer of smart contract ownership is optional. When implementing the scheme of this disclosure, those skilled in the art can transfer or not transfer ownership of the smart contract to another entity as needed.

[0049] 2. Set a whitelist for foundries

[0050] To prevent any entity from minting (i.e., issuing) coupons, the authority to mint coupons can be restricted by setting a whitelist of minters. Therefore, in one embodiment, the request is a setting request for setting the whitelist of minters, and the verification may include verifying whether the entity sending the setting request is the owner of the smart contract.

[0051] The forger whitelist can be initially set in the smart contract when it is deployed. Figure 2 and Figure 3 The initial settings of the minter whitelist are shown, and it can be further configured (i.e., modified) after the initial settings. A specific implementation related to this configuration operation can take the following form: maintaining a minter whitelist (allowMinters) within the contract, which stores a list of entities permitted to mint electronic vouchers, and providing procedural methods within the contract for modifying the minter whitelist, such as the method addToMintWhitelist for adding entities to the whitelist and the method removeFromMintWhitelist for removing entities from the whitelist; these two methods can be further modified with the aforementioned onlyOwner modifier so that they can only be executed by the contract owner.

[0052] It is understood that setting a whitelist of minters is merely an example of restricting minting permissions. Those skilled in the art can employ other methods to restrict the permission to mint electronic vouchers as needed, such as based on the geographical location of the entity wishing to mint vouchers or the password or token provided by that entity, or by using a blacklist of minters to determine whether to allow that entity to mint electronic vouchers. The solution disclosed herein is not limited in this respect. Furthermore, it is understood that the whitelist of minters can also be hard-coded into the smart contract before deployment and cannot be modified after deployment (e.g., neither of the two procedural methods described above for modifying the whitelist of minters is provided). The solution disclosed herein is not limited in this respect.

[0053] 3. Casting coupons

[0054] When a merchant wants to issue coupons, they can, for example, send a request for the minting to a smart contract by invoking a smart contract to request the execution of a programmatic method therein for minting electronic coupons, in order to generate one or more coupons. Therefore, in one embodiment, the request is a minting request for the electronic coupons (e.g., Figure 2 The verification process includes verifying whether the entity sending the casting request belongs to the whitelist of casting entities set in the smart contract. If the verification is positive (see example...), the verification will then proceed as follows: Figure 3 If the "Yes" branch of the "Determine if in the foundry whitelist" checkbox is selected, the smart contract executes the foundry and returns the result of the operation as a response to the request (e.g., ...). Figure 2 The smart contract returns a "forging successful" response to the forger. In the case where the verification is negative (see, for example...),... Figure 3 If the "No" branch of the "Determine if it is in the foundry whitelist" checkbox is selected, then the foundry operation is prohibited.

[0055] For each coupon, the smart contract can internally maintain information such as: couponId (unique identifier), creator, list of redeemers (allowRedeemers), couponOwner, couponName, description, rule, redeemAuthInfo (redeemer authorization), redeemState (redeemer status), and redeemer.

[0056] 4. Set up a whitelist of redeemers

[0057] After a merchant issues a coupon, a whitelist of redeemers can be set up to prevent any entity from redeeming the electronic coupon and to prevent collusion between merchants and users. Therefore, in one embodiment, the request is a request to set up the whitelist of redeemers (e.g., Figure 2 The "Set Verifier Whitelist" request sent by the minter to the smart contract, and the verification may include verifying whether the entity sending the setting request is the entity that minted the electronic voucher. If the verification is positive, the smart contract executes the setting and returns the result of the operation as a response to the request (e.g., ...). Figure 2 The smart contract sends a "setup successful" response to the minter.

[0058] The redeemer whitelist can be initially set in the smart contract when the voucher is minted, or it can be further set (i.e., modified) after the initial setting. Specific implementations related to this setting operation can take the following forms: Maintaining a redeemer whitelist `allowRedeemers` within the contract, which stores a list of entities allowed to redeem electronic vouchers, and providing programmatic methods within the contract for modifying the whitelist, such as the programmatic method `addToRedeemWhitelist` to add entities to the whitelist and the programmatic method `removeFromRedeemWhitelist` to remove entities from the whitelist; Furthermore, the smart contract program can restrict the setting of the redeemer whitelist to only the entity that minted the electronic voucher, for example, by modifying the above two programmatic methods with a modifier so that they can only be executed by the voucher minter.

[0059] It is understood that setting a whitelist of redeemers is merely an example of restricting redemption permissions. Those skilled in the art can employ other methods to restrict redemption permissions for electronic vouchers as needed, such as based on the geographical location of the entity wishing to redeem the voucher or the password or token provided, or by using a blacklist of redeemers to determine whether to allow the entity to redeem electronic vouchers. The solution disclosed herein is not limited in this respect. Furthermore, it is understood that the whitelist of redeemers can also be hard-coded into the smart contract before deployment and cannot be modified after deployment (e.g., neither of the two procedural methods described above for modifying the whitelist of redeemers is provided). The solution disclosed herein is not limited in this respect.

[0060] 5. Distribute coupons

[0061] After minting a batch of coupons, merchants need to distribute them to end users. In one embodiment, merchants can send a request to a smart contract on the public blockchain to distribute electronic coupons (e.g., Figure 2 The minter sends a request to the smart contract to "distribute coupons to users," for example, by calling the smart contract to request the execution of a programmatic method therein for distributing electronic coupons; the smart contract then verifies the request; and if the verification is positive, executes the requested distribution operation (e.g., ...). Figure 2 The smart contract performs the operation of "transferring the specified coupon to the user's name" and returns the result of the operation as a response to the request (e.g., Figure 2 The smart contract sends a "distribution successful" response to the creator. In this embodiment, the verification may include verifying whether the entity sending the request is the entity that created the electronic voucher. For example, the smart contract determines whether the caller of the contract is the creator, and if not (see example...). Figure 3 If the "No" branch of the "Determine if the distributor is the card minter" decision box is selected, the distribution request is rejected; if the distributor is the minter (see example...), the distribution request is rejected. Figure 3 If the "Yes" branch of the "Determine if the distributor is the coupon issuer" decision box is selected, then the coupon owner is changed to the specified user, completing the coupon distribution to the specified user (e.g., Figure 3 (Complete the distribution of coupons to users).

[0062] 6. Authorization for cancellation

[0063] This operation, along with the authorization verification in operation 7 below, is an additional optional operation for the electronic coupon redemption operation. Its purpose is to prevent merchants from arbitrarily redeeming user coupons without the user's permission. For example, the following business rule can be formulated: when a user wants to use an electronic coupon at a merchant, they need to first send an authorization request to the smart contract to authorize the merchant to redeem the electronic coupon, wherein the authorization request contains authorization information; only after the verification based on the authorization information passes can the smart contract accept the merchant's request to redeem the electronic coupon. Therefore, in one embodiment, the request is an authorization request to authorize the merchant to redeem the electronic coupon, wherein the authorization request contains authorization information, and the authorization information includes at least the ID of the electronic coupon and the merchant's information (e.g., the merchant's address on the public blockchain) and carries the user's digital signature, and the verification may include verifying whether the entity sending the authorization request is the user who owns the electronic coupon.

[0064] A specific implementation related to this operation can be as follows: The user digitally signs the authorization information with their private key. The authorization information may include, for example, the following: couponId, authorization duration (e.g., 5 minutes), the merchant's address on the public blockchain, and a random number. The user sends an authorization request containing the authorization information with their digital signature to a smart contract (e.g., by calling a program method in the smart contract to perform the authorization operation). The smart contract then determines whether the entity sending the authorization request is the user who owns the electronic coupon, for example, by determining whether the user currently calling the smart contract is the user indicated by the couponOwner field of the corresponding coupon. If the smart contract determines that the entity sending the authorization request is the user who owns the electronic coupon (see, for example...), the user then... Figure 3 In the "Determine if the user possesses the coupon" judgment box, the "Yes" branch will internally store the authorization information (see example). Figure 3The "Save Authorization Information" function (e.g., saving it to the redeemAuthInfo data structure for revocation authorization) returns the result of this operation as a response (e.g., ...). Figure 2 The smart contract sends a "successful authorization" response to the user; otherwise, the authorization request is rejected (see example...). Figure 3 (The "No" branch of the "Determine if the user has the coupon" decision box).

[0065] In a further embodiment, the request is a redemption request for the electronic voucher, and the verification may include: verifying, using the authorization information, whether the entity sending the redemption request is the merchant, whether the user's digital signature is correct, and whether the entity belongs to the redeemer whitelist set in the smart contract. This further embodiment will be described in conjunction with operations 7 and 8 below.

[0066] 7. Authorization Verification. After completing the user's authorization verification operation, the smart contract needs to verify the authorization's correctness before the merchant verifies the e-coupon. A specific implementation related to this operation can be as follows: the merchant sends a verification request for the e-coupon to the smart contract (see example...). Figure 3 (For example, in the context of "merchant issuing a redemption request"), by calling a smart contract to request the execution of its program method for redeeming electronic vouchers, the smart contract first obtains the information of the entity sending the redemption request, then retrieves the information of the authorized merchant for that electronic voucher from the stored redemption authorization data structure redeemAuthInfo; it then determines whether the entity and the merchant are consistent; if they are inconsistent, subsequent operations are prohibited; if they are consistent, the public key of the user requesting authorization can be derived from the signature value and message in redeemAuthInfo, and then the user's digital signature is verified for correctness using the public key. If correct (see example...), Figure 3 If the "Merchant authorization information and user signature are correct" checkbox shows "Yes", it means that the authorization is correct and not an authorization from someone impersonating another person. Only then will the smart contract continue to execute the voucher redemption operation (Operation 8, as described below); if it is incorrect (see example...), the smart contract will proceed to execute the voucher redemption operation. Figure 3 If the "No" branch of the "Merchant authorization information and user signature are correct" judgment box is selected, then subsequent operations are prohibited.

[0067] 8. Voucher Redemption. After the above authorization verification is passed, the user's voucher can be redeemed. A specific implementation can be achieved, for example, by defining a program method `redeem` for redeeming electronic vouchers in the smart contract, and modifying it with the `onlyAllowRedeemer` modifier. This modifier allows the operation to continue if the caller of the program method for redeeming electronic vouchers belongs to the whitelist of redeemers (see example...). Figure 3 If the "Check if in the whitelist of resellers" checkbox is "Yes", the operation will not be allowed to continue (see example). Figure 3 (The "No" branch of the "Determine if it is in the whitelist of redeemers" decision box); If redemption is successful, the smart contract changes the redeemState of the electronic voucher to the redeemed state, assigns the redeemer field of the record of the redeemer subject to the subject, and returns the result of the redemption operation to the subject as a response to the redemption request (e.g., Figure 2 (The "Reverse Completion" response returned by the smart contract to the reverser).

[0068] Regarding the reversal operation, it is understood that the smart contract may only verify whether the entity sending the reversal request belongs to the reverser whitelist set in the smart contract; that is, it may not perform the reversal authorization in operation 6 or the verification authorization in operation 7. Those skilled in the art can choose the verification method to be used for the reversal operation as needed. The solution disclosed herein is not limited in this respect.

[0069] Furthermore, users can freely trade the electronic vouchers they own. For example, in one embodiment, a user can send a request to sell electronic vouchers to a smart contract on a public blockchain, for example, by calling the smart contract to request the execution of a program method therein for selling electronic vouchers; upon receiving the request, the smart contract verifies it, and if the verification is positive, executes the electronic voucher selling operation and returns the result of the selling operation as a response to the request. In this embodiment, the verification may include verifying whether the entity sending the selling request is the user who owns the electronic voucher. A specific implementation related to the selling operation may take the following form: the smart contract transfers the electronic vouchers under the user's name to a contract address and sets the price at which the user requests to sell.

[0070] In another embodiment, other users wishing to purchase electronic vouchers can send a purchase request to a smart contract on a public blockchain, for example, by invoking the smart contract to request the execution of a program method therein for purchasing electronic vouchers. Upon receiving the request, the smart contract verifies it, and if the verification is positive, executes the electronic voucher purchase operation and returns the result of the purchase operation as a response to the request. In this embodiment, the verification may include verifying whether the purchase price in the purchase request is equal to or higher than the listed price of the electronic voucher. A specific implementation related to the purchase operation may be as follows: the smart contract determines whether the amount proposed by the other user sending the purchase request is equal to or higher than the listed price of the user acting as the seller; if so, it transfers the funds corresponding to the price to the user acting as the seller and transfers the listed electronic voucher to the other user's address to complete the transaction.

[0071] In one embodiment, the smart contract conforms to the token standard of the public blockchain, such as the ERC-1155 standard of the Ethereum blockchain. In this case, the aforementioned listing and purchase requests can be sent to the smart contract disclosed herein for processing (provided that the entity developing the smart contract configures the smart contract to execute the listing and purchase of coupons), or they can be sent to other conventional smart contracts on the public blockchain specifically used for market transactions (hereinafter referred to as trading contracts) for processing. The aforementioned user acting as the seller (hereinafter referred to as the "seller") and other users acting as the buyer (hereinafter referred to as the "buyer") can send their requests to the public blockchain through a public digital asset trading platform (e.g., OpenSea). For example, the seller can publish coupons for sale on OpenSea (including, for example, calling the smart contract disclosed herein or the aforementioned trading contract to request the execution of the listing operation), and the buyer, after seeing the coupons listed by the seller on OpenSea, can enter the purchase amount and authorize the call to the smart contract disclosed herein or the aforementioned trading contract using their own digital wallet to request the execution of the purchase operation.

[0072] Furthermore, it is understood that the solution disclosed herein does not mandate that the smart contract conform to the token standard of the public blockchain. The solution disclosed herein has no limitations in this regard. Even if the smart contract does not conform to the token standard of the public blockchain, the aforementioned sellers and buyers can still freely complete the transaction of electronic vouchers by directly sending their requests on the public blockchain.

[0073] In one embodiment, the public blockchain is the Ethereum blockchain, as described above.

[0074] It should be understood that the boxes in the block diagrams and / or flowcharts, and combinations of boxes in the block diagrams and / or flowcharts, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, and / or other programmable data processing apparatus, such that the instructions, executed via the processor of said computer and / or said other programmable data processing apparatus, create components for implementing the functions / actions specified in the boxes of the block diagrams and / or flowcharts.

[0075] It should also be understood that the functions / actions shown in the boxes of a flowchart may not occur in the order shown in the diagram. For example, depending on the functions / actions involved, two boxes shown consecutively may actually be executed substantially simultaneously, or these boxes may sometimes be executed in reverse order. Although some diagrams may include arrows on communication paths to indicate the main direction of communication, it should be understood that communication may occur in the opposite direction to the arrows depicted.

[0076] Furthermore, the solutions disclosed herein can take the form of a computer program on memory having computer-usable or computer-readable program code implemented in a medium for use by or in conjunction with an instruction execution system. In the context of this document, memory can be any medium that can contain, store, or is adapted to transfer programs for use by or in conjunction with an instruction execution system, device, or apparatus.

[0077] Therefore, this disclosure also provides a computing device 400 including a processor 401 and a memory 402, such as Figure 4 As shown. In device 400, memory 402 stores instructions that, when executed by processor 401, cause computing device 400 to perform the above-described method for managing electronic coupons.

[0078] This disclosure also provides a non-transitory computer-readable storage medium (not shown) on which instructions are stored, which, when executed by a processor of a computing device, cause the computing device to perform the above-described method for managing electronic coupons.

[0079] This disclosure also provides a computer program product (not shown) containing instructions that, when executed by a processor of a computing device, cause the computing device to perform the above-described method for managing electronic coupons.

[0080] While this specification contains numerous specific implementation details, these details should not be construed as limiting the scope of any implementation or what may be claimed, but rather as descriptions of features of specific embodiments that may be specific to a particular implementation. Certain features described in the context of various embodiments in this specification may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments. Furthermore, although features may be described above as functioning in certain combinations, even at the time of initial claim, in some cases one or more features from a claimed combination may be removed from that combination, and the claimed combination may be directed to sub-combinations or variations thereof.

[0081] It will be apparent to those skilled in the art that the inventive concept can be implemented in various ways as technology advances. The above embodiments are given for illustrative purposes and not for limiting the scope of this disclosure, and it should be understood that modifications and variations can be made without departing from the spirit and scope of this disclosure, as will be readily apparent to those skilled in the art. Such modifications and variations are considered to be within the scope of this disclosure and the appended claims. The scope of protection of this disclosure is defined by the appended claims.

Claims

1. A method for managing electronic vouchers executed via a smart contract deployed on a public blockchain, the method comprising: Receive requests for operations related to performing and managing the electronic coupons; Verify the request; as well as If the verification is positive, the requested operation is performed and the result of the operation is returned as a response to the request.

2. The method of claim 1, wherein the request is a transfer request for the transfer of ownership of the smart contract, and the verification includes verifying whether the entity sending the transfer request is the owner of the smart contract.

3. The method of claim 1, wherein the request is a minting request for minting the electronic voucher, and the verification includes verifying whether the entity sending the minting request belongs to the minter whitelist set in the smart contract.

4. The method of claim 2, wherein the request is a setting request for setting the foundry whitelist, and the verification includes verifying whether the entity sending the setting request is the owner of the smart contract.

5. The method of claim 1, wherein the request is an authorization request for an authorized merchant to redeem the electronic voucher, wherein the authorization request includes authorization information and the authorization information includes at least the ID of the electronic voucher and the information of the merchant and carries the digital signature of the user, and the verification includes verifying whether the subject sending the authorization request is a user who owns the electronic voucher.

6. The method of claim 5, wherein the request is a verification request for the electronic voucher, and the verification includes: The authorization information is used to verify whether the entity sending the revocation request is the merchant, whether the user's digital signature is correct, and whether the entity belongs to the revoker whitelist set in the smart contract.

7. The method of claim 6, wherein the request is a setting request for setting the whitelist of redeemers, and the verification includes verifying whether the entity sending the setting request is the entity that created the electronic voucher.

8. The method of claim 1, wherein the request is a distribution request for the electronic voucher, and the verification includes verifying whether the entity sending the distribution request is the entity that minted the electronic voucher.

9. The method of claim 1, wherein the request is a listing request for the electronic voucher, and the verification includes verifying whether the entity sending the listing request is a user who owns the electronic voucher.

10. The method of claim 1, wherein the request is a purchase request for the electronic voucher, and the verification includes verifying whether the purchase price in the purchase request is equal to or higher than the listed price of the electronic voucher.

11. The method of any one of claims 1-10, wherein the smart contract conforms to the token standard of the public blockchain.

12. The method of any one of claims 1-10, wherein the public blockchain is the Ethereum blockchain.

13. A non-transitory computer-readable medium containing stored instructions that, when executed by a processor of a computing device, cause the computing device to perform the method as described in any one of claims 1-12.

14. A computer program product comprising instructions that, when executed by a processor of a computing device, cause the computing device to perform the method as described in any one of claims 1-12.

15. A computing device comprising: Memory, which has stored instructions; processor, in, When executed by the processor, the instructions cause the computing device to perform the method as described in any one of claims 1-12.

Images