A secure token transaction unit, payment transaction sender, receiver and system and method for providing non-repudiation of payment transactions between the participants in an electronic payment transaction system

Abstract

The present invention relates to a secure token transaction unit, for example a wallet, hosted in a service provider unit in an electronic payment transaction system, the electronic payment transaction system comprising a token reference register, the secure token transaction unit being configured to send tokens to or receive tokens from another token transaction unit within the electronic payment transaction system, the secure token transaction unit comprising a control module adapted to perform a double key control mechanism, whereby the double key control mechanism thereby enhances the security that a payment transaction cannot be tampered with, to enable a non-repudiable proof of the payment transaction.

Description

Technical Field

[0001] This invention relates to a secure token transaction unit within an electronic payment transaction system. It also relates to a service provider unit within the electronic payment transaction system, designed as a payment transaction sender and a service provider unit designed as a payment transaction receiver. Furthermore, this invention relates to a payment transaction system. Finally, this invention relates to a method for providing non-repudiable payment transactions between participants in an electronic payment transaction system. Background Technology

[0002] Tokens can represent digital assets, such as digital assets, electronic coins, coin datasets, and valuable notes, especially digital currencies, preferably central bank digital currencies, or CBDCs.

[0003] There are different technical methods for exchanging electronic tokens.

[0004] According to the first method, the token is encrypted and protected only by a central bank unit, and the encrypted tokens are exchanged directly between the token trading units (also known as secure wallets and / or secure elements) of the participants in the electronic payment system in an encrypted manner. The exchanged tokens may also be stored in an encrypted manner. The token trading units can verify the authenticity of the tokens based on cryptographic security (e.g., keys and signatures) and, for example, pre-check the validity of certificates from the central bank and / or other token trading units in the certificate hierarchy by means of online access or by following the system's offline protocols.

[0005] According to the second approach, tokens are stored in a centralized or decentralized blockchain / distributed ledger of the payment transaction system, for example, organized by a central bank unit. For a payment transaction, the ownership of the token record changes within the blockchain, requiring and / or even publishing a significant amount of information (sender / recipient / amount). The sender and receiver of the token need to access the blockchain online at the time of the transaction.

[0006] According to a favorable third method, such as that described in WO 2020 / 212 331 A1, tokens are stored in token trading units (also known as wallets, payment application units, or secure elements) for direct exchange between users of the electronic payment transaction system. For security, verification, and registration purposes, a central token reference register stores token references for all valid tokens without knowing the tokens themselves. Therefore, users can check the validity of received tokens using dedicated requests sent to the token reference register. The token reference register only stores token references for the corresponding tokens. Each user of the token trading system can further modify the tokens, for example, by switching ownership of a token from one user to another (switching modification), by splitting a token into multiple tokens, for example, to obtain a token with a reduced monetary value (split modification), and / or by merging multiple tokens into a single token, for example, to obtain a token with a higher monetary value (merging modification). Digital signatures are used to further enhance security.

[0007] In the ever-evolving world of digital finance, electronic payment systems have become increasingly central to global commerce. These systems typically involve complex orchestrations of devices and technologies capable of securely and efficiently transferring funds. Computation, data communication, and interface interaction all play crucial roles in facilitating seamless transactions. Essentially, the goal is to simplify the digital payment process while ensuring high levels of security, efficiency, and user satisfaction.

[0008] The complex yet effective communication protocols used in electronic payment systems employ advanced cryptographic techniques to ensure a high level of security. However, these protocols are not without challenges. WO 2023 / 036458 A1 describes a transaction system in which participants use a unique protocol to conduct transactions. This protocol ensures the seamless transfer of assets and / or information between the parties. It uses cryptographic techniques to verify and authenticate transactions, thereby ensuring the integrity and security of the process. However, while the system is robust, it does not address the potential problem of fraud, where participants may dispute a transaction, claiming it never occurred or was altered, and the system may lack sufficient measures to ultimately resolve such claims. Summary of the Invention

[0009] An electronic payment system is a secure digital system that facilitates the exchange of value or data between parties (i.e., participants in the electronic payment system) via a network. This can include financial systems for transferring funds, e-commerce platforms for buying and selling goods, or any other system for conducting digital transactions. These systems provide the necessary infrastructure for initiating, processing, and recording token transactions. Examples include digital wallet platforms, online banking systems, or blockchain-based payment networks.

[0010] Participants / users in an electronic payment transaction system are associated with technical entities such as secure elements, terminals, systems, or software programs involved in executing electronic transactions of tokens. Preferably, participants are users within a transaction unit, represented by a secure token transaction unit hosted at a Financial Services Provider (FSP). The FSP also includes entities serving customers and service providers. Participants interact with each other to execute token transactions, such as electronic funds transfers.

[0011] To manage tokens (such as executing token transactions and storing tokens), a secure token transaction unit, also known as a token management unit, is used.

[0012] A secure token transaction unit, also known as a wallet, is a digital container that stores information used for payments, reward redemption, or access to other services. A secure token transaction unit can also be a token transaction unit that can be used to locally manage tokens within the secure element itself, modify tokens, and register tokens in an electronic transaction system.

[0013] Secure token transaction units (also known as secure account management units) can be used to manage tokens in decentralized ledgers (such as blockchains) or centralized ledgers (such as databases) that centrally store tokens in an electronic transaction system. The management, modification, and / or registration of tokens in the electronic transaction system can be initiated by the token transaction unit. Token transactions or token storage can be performed remotely by another secure element or service provider unit.

[0014] Secure token trading units are preferably hosted at a service provider unit. Multiple wallets can exist, each hosted by the service provider unit and dedicated to one participant within the trading unit. Such secure token trading units are referred to as custodial wallets.

[0015] Secure token trading units can be hosted within terminal devices such as smartphones. One or more wallets can be hosted within the terminal device, each dedicated to a single participant within the trading unit. Such secure token trading units are referred to as device wallets. These device wallets can be software applications within an application runtime environment. Additional security features, such as trusted execution environments (hardware or software), can be used. Terminal devices can refer to computing devices that can connect to other devices or networks, such as smartphones, laptops, mobile tablets, or, where applicable, desktops or mainframes. With the aid of the terminal device, the token trading unit is in an operational state, which preferably means that the terminal provides the token trading unit with the necessary requirements for its operation, such as power supply, physical enclosure, and mechanical protection.

[0016] When the term "secure token transaction unit" is used in this article, it refers to a custodial wallet or device wallet.

[0017] Token trading units can be software-based or hardware-based and can be used to store various information, including tokens, asset values, credit card numbers, membership card numbers, boarding pass numbers, and other related data. Token trading units can be implemented as software applications or hardware devices, such as USB drives or smart cards / chip cards.

[0018] The service provider unit can be a financial services provider, such as a commercial bank or a fintech company. Alternatively, it can be an official institution or a mobile communication service provider. It can also be any other regulated or unregulated party participating in the electronic trading system, including payment transactions involving central bank digital currencies (CBDCs) authorized by token issuers.

[0019] According to one aspect of the invention, a secure token transaction unit is provided within an electronic payment transaction system. The secure token transaction unit may be, for example, a custodial wallet within a service provider unit, or a device wallet hosted in a terminal device.

[0020] A token transaction unit can be connected to or is capable of connecting to a terminal or service provider unit. In particular, a token transaction unit can be connected to another transaction unit within a payment transaction system. In this context, it can specifically be connected to a secure token transaction unit to execute payment transactions.

[0021] A secure token transaction unit is configured to send tokens to another token transaction unit within an electronic payment transaction system, for example, via a terminal device or service provider unit. This secure token transaction unit is the sender of token transactions within the payment token transaction system. A secure token transaction unit can also send tokens directly to another token transaction unit.

[0022] A secure token transaction unit may include a secure storage device for storing data such as tokens or transaction data.

[0023] The control module of the token transaction unit is suitable for implementing a dual-key control mechanism.

[0024] The dual-key control mechanism preferably involves generating a unique cryptographic key pair, including a private key and a public key, using a random number generator. The private key is a secret and unique cryptographic key kept by the secure token transaction unit, preferably stored in secure storage. The public key is not kept secret but is exchanged between the parties involved in the communication.

[0025] The dual-key control mechanism involves receiving a public key from another token trading unit. This enables the implementation of the dual-key control mechanism and allows for the sharing of its benefits. Data transfer can be performed via a communication interface between the token trading unit and the terminal device / service provider unit.

[0026] The dual-key control mechanism includes generating a replacement request, which comprises an input token reference uniquely assigned to the secure token transaction unit and a composite token reference serving as the output token reference. The composite token reference includes a composite public key. The composite public key is a combination of the transaction unit's public key and the public key of another transaction unit.

[0027] Using this replacement request, a transaction unit can request to switch the input token reference to the composite token reference at the token reference register. Switching means replacing the input token reference with the composite token reference without changing the currency value of the token (reference). Through this switch, ownership of the (token's) currency value changes from one participant to another within the payment transaction system.

[0028] Using this replacement request, a trading unit can request that an input token reference be split into a composite token reference at the token reference register. Here, splitting means replacing the input token reference with the composite token reference without changing the token's (reference's) monetary value. Through splitting, ownership of the (token's) monetary value is transferred to another participant.

[0029] Using this replacement request, the transaction unit can be used in a switch / split variant where payments are based on two token references. Therefore, instead of switching the sum of the token references, it switches a pair of token references, each producing a combined token reference.

[0030] A combined public key is the result of combining two public keys, in this case, the public key of one transaction unit and the public key of another token transaction unit. This combination can be any logical link, such as addition, concatenation, or logical operation.

[0031] Within the dual-key control mechanism, replacement requests are provided to the token reference register.

[0032] Each public key has a corresponding private key, and both the public and private keys are cryptographic key pairs.

[0033] The selected combination used to create the combined public key can be the same as the combination used to combine the corresponding private key (here, the private key of the secure token transaction unit and the private key of another token transaction unit).

[0034] Each transaction unit or escrow transaction unit's service provider unit or escrow transaction unit's device terminal may also include a transport key pair as a signing key pair, which has a transport public key and a transport private key. Each transfer (transfer) between the participants can be signed by the transport private key from the sender or receiver. This ensures that all direct transfer messages between the participants are digitally signed, which provides additional security guarantees (e.g., if an attacker gains access to the transport layer certificate and can alter the information), and it provides a more robust implementation of the transfer protocol (unconditional checks (if / else) at the code level, since the signature can now be checked).

[0035] Therefore, a dual-key control mechanism can help provide enhanced security, ensuring that transactions cannot be tampered with to provide non-repudiable transaction proof. By replacing the input token reference with a composite token reference, neither the transaction unit nor the other transaction unit can spend the tokens allocated to that composite token reference. This stems from the dual-key control mechanism, where, when registering a composite token reference, neither transaction unit knows the corresponding composite private key—although each of them knows a portion of the private key, no transaction unit can prove ownership of the tokens allocated to the corresponding composite token reference registered in the token reference register.

[0036] The dual-key control mechanism can also include receiving confirmation from the token reference register if the combined token reference is successfully registered in the token reference register.

[0037] The dual-key control mechanism may also include storing the confirmation. This confirmation can be used as proof of a non-repudiable transaction.

[0038] The public key received from another transaction unit is digitally signed using the private key of that other transaction unit or the private key of the service provider unit. This signature provides proof of the origin of the public key from the (received) other transaction unit.

[0039] According to one aspect, a secure token transaction unit (e.g., a wallet) within a service provider unit or device terminal hosted in an electronic payment transaction system (including a token reference register) is configured to receive tokens from another token transaction unit within the electronic payment transaction system. This secure token transaction unit is the recipient of token transactions within the payment token transaction system. The secure token transaction unit can receive tokens directly from another token transaction unit.

[0040] The secure token transaction unit includes a control module adapted to execute another part of a dual-key control mechanism, including preferably generating a unique cryptographic key pair consisting of a private key and a public key via a random number generator, sending the public key to another transaction unit, and receiving a token reference register confirmation from the other secure token transaction unit to determine that the token reference register i) has verified the authenticity and correctness of the combined token reference, and ii) has replaced the input token reference with the combined token reference in its records, the confirmation serving as non-repudiable proof of the transaction.

[0041] The dual-key control mechanism (used for this transaction unit) also includes receiving a private key from another transaction unit to generate a composite private key. This composite private key is a combination of the private key generated by the secure token transaction unit and the private key received from the other token transaction unit, used to control the monetary value associated with the composite token reference. This combination can be any logical chain, such as addition, concatenation, or logical operation. The selected combination used to create the composite private key can be the same for the corresponding public key, which is here, the public key of the transaction unit and the public key of the other token transaction unit.

[0042] Before sending the public key, the public key is digitally signed using the private key of another transaction unit or the private key of the service provider unit.

[0043] The dual-key control mechanism may further include: receiving a payment certificate from another transaction unit, the payment certificate including an acknowledgment of a token reference register and an acknowledgment signature, the acknowledgment signature preferably being a digital signature using the private key of the token transaction unit, and more preferably including at least one of i) transaction data and ii) a combined token reference; and preferably verifying the authenticity and integrity of the acknowledgment of the token reference register by verifying the acknowledgment signature using the public key of the other secure transaction unit.

[0044] According to one aspect of the invention, a service provider unit is provided, which is configured to host a plurality of second security token transaction units.

[0045] The service provider unit may also include secure storage for storing data, a control module such as a processor, microprocessor or microcontroller (preferably for performing its own operation or controlling the operation of other hardware or software components within the transaction unit), a communication module, and secure storage.

[0046] This confirmation helps to implement a two-key control mechanism, serving as proof of a non-repudiable transaction.

[0047] The dual-key control mechanism also includes receiving confirmation from the token reference register upon successful registration of the combined token reference in the token reference register. This confirmation preferably includes i) transaction data, such as at least one of transaction ID, reference number, and timestamp, and / or ii) a digital signature on the combined token reference and / or replacement request.

[0048] The confirmation of the token reference register is used to confirm that the token reference register i) has verified the authenticity and correctness of the composite token reference, and ii) has replaced the input token reference with the composite token reference in its records, thereby providing irrefutable evidence of the transaction.

[0049] The dual-key control mechanism may also include: providing a private key to another token trading unit, thereby enabling the other token trading unit to generate a combined private key to control the monetary value associated with the combined public key through a combined token reference.

[0050] The dual-key control mechanism may also include: generating a digital signature for the composite token reference using the private key of the secure token transaction unit, and / or providing a digital signature for the composite token reference.

[0051] The dual-key control mechanism may also include receiving transaction data, which includes at least one of a transfer ID, a sender wallet ID, a receiver wallet ID, and a timestamp.

[0052] The dual-key control mechanism may also include generating a composite token reference, which preferably includes a currency value, a composite public key, and optional transaction data.

[0053] Preferably, the token reference is a publicly available reference to the token and is described at least by a public key corresponding to the private key, where v is the face value, monetary value, or quantity of the token. The public key can be determined using cryptographic functions, specifically generation points within elliptic curve cryptography. The token reference serves as public proof of the existence and value of a particular token without revealing the private key required to spend it.

[0054] A token reference can be understood as a public cryptographic representation or identifier of a specific value or asset (i.e., a specific amount of digital currency).

[0055] Preferably, the token comprises a monetary value and a private key known only to the owner. The private key grants ownership / control over the associated monetary value.

[0056] According to one aspect of the present invention, an electronic payment transaction system is provided. The system includes at least one terminal or service provider unit designed as a sender of a payment transaction as described above, and at least one terminal or service provider unit designed as a receiver of a payment transaction as described above.

[0057] According to one aspect of the present invention, a method is provided for providing non-repudiable payment transactions between participants in an electronic payment transaction system. The participants include at least one sender of the payment transaction (preferably a transaction unit, service provider unit, or terminal device) and at least one receiver (preferably a transaction unit, service provider unit, or terminal device).

[0058] This method defines a transaction protocol and includes one or more steps as described below.

[0059] Sender executes:

[0060] - Generate a sender key pair that includes the sender's private key and the sender's public key.

[0061] Receiver execution:

[0062] - Generate a receiver key pair including the receiver's private key and the receiver's public key.

[0063] - Optionally, the receiver's public key is digitally signed using the receiver's private key, and

[0064] - Send the (signed) public key of the recipient to the sender.

[0065] Sender executes:

[0066] - By generating a replacement request, the input token reference is switched to a composite token reference that includes a currency value and a composite public key, which includes the sender's public key and the receiver's public key.

[0067] - Send a replacement request, including a combined token reference, to the token reference register.

[0068] Token reference register execution:

[0069] -Verify the combination token reference.

[0070] - If the verification result is positive, replace the input token reference in the register with the combined token reference.

[0071] - Generate confirmation, preferably including a replacement request, and

[0072] - Send the confirmation to the sender.

[0073] Optionally, the sender performs:

[0074] - Receive confirmation from the token reference register

[0075] - Store the confirmation.

[0076] - Send token reference register confirmation to the recipient.

[0077] - Send the sender's private key and confirmation to the recipient, the confirmation including at least the currency value (v), and preferably including confirmation from the token reference register (including a replacement request), more preferably, the confirmation from the token reference register is a proof of payment, preferably including confirmation from the token reference register, confirmation signature (preferably a digital signature using the sender's transmission private key), and at least one of i) transaction data and ii) currency value;

[0078] - Send a payment certificate to the recipient, the payment certificate specifically including the confirmation, a confirmation signature (which is preferably a digital signature using the sender's transmission private key), and at least one of i) transaction data and ii) currency value, and at least one of i) transaction data and ii) combined token reference, and verify the authenticity and integrity of the confirmation in the token reference register.

[0079] This method ensures that transactions cannot be tampered with, thus achieving non-repudiable proof of transactions.

[0080] A token reference register can act as a trusted entity to verify the legitimacy of tokens within the system. By embedding it into the transaction protocol, it ensures that the tokens used in a transaction are genuine and not counterfeit or double-used. This centralized verification mechanism adds integrity and credibility to the entire transaction process.

[0081] Confirmation and payment verification serve as proof of the legitimacy and validity of tokens in a transaction. For the parties involved in the transaction agreement, confirmation / verification acts as a guarantee of the authenticity of the tokens, thereby allowing them to trust the transaction.

[0082] According to one aspect of the present invention, a non-transitory computer-readable storage medium is provided for tangibly storing computer program instructions executable by a processor. The computer program instructions implement / execute the steps of the above-described method.

[0083] Some effects and advantages related to secure token transaction units, terminals designed as receivers, terminals designed as senders, electronic payment token transaction systems, methods for providing non-repudiable payment transactions, and non-transitory computer-readable storage media are described below.

[0084] The entity of this invention is a secure entity. The term "secure" can be explained through some examples.

[0085] - The Secure Token Transaction Unit is designed to securely store tokens and execute secure transactions. It includes security features, such as secure storage for secure data storage, which contribute to the overall security of the system.

[0086] The electronic payment system is secure based on a combination of security measures across all its components, including secure token transaction units, terminals, and secure communication interfaces. It also includes security protocols to ensure transaction integrity and user privacy.

[0087] Terminals such as smartphones, laptops, or fixed-line computers enhance system security through secure communication interfaces and encrypted storage to reduce the risks associated with data manipulation or unauthorized access.

[0088] - The secure communication interface provides bidirectional data communication between the secure token transaction unit and the terminal. It can use secure communication protocols, such as Transport Layer Security (TLS), to ensure the secure transmission of sensitive data, thereby minimizing the risk of data leakage.

[0089] - The secure storage of token trading units or terminals stores data in encrypted form, thereby preventing unauthorized access or modification. The secure storage and retrieval of token denominations and their corresponding values ​​ensures the system's security.

[0090] A secure communication interface for a trading unit is adapted to provide data from the trading unit to a terminal and to receive data from the terminal. In this context, "receive" and "provide" can refer to enabling data transfer from the terminal to the trading unit (receive) and vice versa (provide). From the perspectives of both the trading unit and the terminal, the secure communication interface is suitable for facilitating data exchange between them. The terms "receive" and "provide" are used for data transfer via the communication interface, while the terms "send" and "receive" are used for data transfer via the communication module. Typically, the control module is adapted to control the data transfer performed via both the communication interface and the communication module.

[0091] Preferably, the secure communication interface of the transaction unit is connected to or can be connected to the secure communication interface of the sender / receiver, thereby establishing a data connection between the transaction unit and the sender / receiver via the corresponding communication interface.

[0092] Preferably, data transmitted to a service provider unit is either processed within the service provider unit and then further transmitted from the service provider unit to another service provider unit, or transmitted directly. Service provider units may be communicatively connectable to or connected to another token trading unit having similar and / or complementary features to the token trading units described herein. In particular, communication between service provider units may be provided via the Internet and / or wireless (mobile) communications.

[0093] Specifically, secure communication interfaces enable secure token transaction units to interact securely with service provider units, thereby enhancing data security during transactions. The advantage is enhanced system security, minimizing potential vulnerabilities during data exchange. In particular, secure storage maintains data integrity by protecting it from unauthorized access or modification. The advantage is a robust system that reliably stores and retrieves data, increasing confidence in the system.

[0094] The concept of the invention based on the described aspects includes several features, such as a dual-key control mechanism, a token reference, verification of the token reference register, and proof of validity. These features are common to the particular aspects and are responsible for the effects and advantages of the concept. At least one of these features, described in more detail below, is common to all aspects of the invention, thereby linking the particular aspects to form a single overall inventive concept.

[0095] The dual-key control mechanism involves the generation and use of specific cryptographic tools. The generation process involves the creation of a unique cryptographic key pair and the formation of a combined public key, where the public keys of the recipient and sender are combined. This combined public key serves as a unique identifier for the dual-key control mechanism, ensuring the security and uniqueness of each transaction. Transactions can be securely executed and verified using the tools provided by the dual-key control mechanism. For example, once the combined public key is generated, the input token reference can be switched or updated to the combined token reference within the token reference register. This switching process ensures that the transaction is associated with both parties involved and provides non-repudiable proof of the transaction. The combined token reference, along with confirmations or digital signatures, provides a secure and verifiable record of the transaction, ensuring its integrity and authenticity.

[0096] A dual-key control mechanism allows for a shared understanding that cooperation between the two parties is necessary for the successful completion of secure electronic payments. This mechanism involves creating a combined public key by combining the public keys of two different entities. This establishes control over the relevant monetary value between the two parties. Transactions can only be conducted with the active participation of both entities, thereby enhancing security, reducing the risk of unauthorized access, and ensuring that transactions are tamper-proof and verifiable.

[0097] The use of token references means generating a unique token for each transaction, which includes a combination of the public key and key transaction data. Token references allow for a unique identifier for each transaction, ensuring that each operation is traceable and distinguishable from others. Token references make tracking and referencing specific transactions easier, thus promoting efficient record keeping and reducing ambiguity.

[0098] The token reference undergoes a verification process conducted by an independent entity (the token reference register). Upon receiving a verification request from the sender, this entity verifies the authenticity of the token reference. On one hand, this adds an extra layer of security to the legitimacy and non-repudiation of the transaction. On the other hand, by confirming the transaction only after successful verification, it acts as a barrier against fraudulent activities or potential tampering.

[0099] After verification, both the sender and receiver receive proof of the transaction's validity, which is then stored by both parties. This creates a permanent, verifiable record of the transaction. This record acts as a barrier against potential disputes and ensures that both parties have an undeniable reference to the transaction, contributing to its non-repudiation and / or promoting accountability and transparency in the transactional relationship.

[0100] Advantageous embodiments of the invention are then described. Any embodiment or feature thereof may be combined with any aspect and / or other embodiment of the invention, provided that this is technically useful and / or permissible. For example, a feature shown or described as part of an embodiment may be used in another embodiment or in combination with another embodiment to provide further embodiments.

[0101] In one embodiment, the dual-key control mechanism may include generating an acknowledgment regarding the combined token reference, which preferably includes i) transaction data, such as at least one of a transaction ID, reference number, and timestamp, and / or ii) a digital signature on the initial token reference and / or replacement request. This provides enhanced security and traceability for transactions and ensures that both parties have irrefutable proof of the occurrence and details of the transaction, thereby reducing the risk of fraud or disputes.

[0102] In one embodiment, the dual-key control mechanism may include generating a digital signature on the composite token reference using the sender's private key and / or providing the digital signature of the composite token reference via a communication interface. This provides a robust verification mechanism to confirm the authenticity and integrity of a transaction.

[0103] In one embodiment, the dual-key control mechanism may include obtaining transaction data via a communication interface, the transaction data including at least one of a transfer ID, a sender's wallet ID, a receiver's wallet ID, and a timestamp. This allows participants in the transaction system to track and verify the order and parties involved in a transaction, thereby increasing transparency.

[0104] In one embodiment, the dual-key control mechanism may include generating a composite token reference, preferably including a currency value, a composite public key, and optionally transaction data, and digitally signing the composite token reference using the sender's private key or the private key of the transmitting sender. This allows for a complete tamper-proof record, thereby ensuring the integrity and verifiability of the entire transaction.

[0105] In one embodiment, the receiver's control module may be adapted to receive payment proof from the sender for each payment transaction made via the communication module, preferably including confirmation of a token reference register, confirmation signature, and at least one of i) transaction data and ii) combined token references, and to verify the authenticity and integrity of the confirmation of the token reference register. This ensures that each transaction is supported by verifiable proof and that all payment details are authentic, thereby minimizing potential disputes.

[0106] In one embodiment, the authenticity and integrity of the confirmation signature can be verified by using the public key of the token reference register, which is pre-distributed to the participants and / or senders and / or receivers of the electronic payment transaction system. This enhances the security and credibility of the transaction because it ensures consistent verification of confirmations from known and trusted sources.

[0107] In one embodiment, for each payment transaction, the confirmation may include i) a combination of token references and / or transaction data including one of a transaction ID and a timestamp. This provides a transaction record for both parties, thereby enhancing transparency and mutual assurance in the process.

[0108] In one embodiment, the sender and receiver can integrate with the transaction system's PKI system to verify the certificates associated with them by verifying the issuer ID in the certificate chain and certificate serial number, thereby enhancing transaction security by ensuring the legitimacy of the sender's certificate in the payment protocol. A robust external authentication system is used to ensure the sender's certificate is valid and traceable.

[0109] In one embodiment, for each payment transaction, a confirmation is received from the token reference register via a communication module to determine that the token reference register has replaced the input token reference in its records with a combined token reference (as the output token reference of the replacement request), and this confirmation (e.g., including the replacement request) is sent to the recipient and / or stored via the communication module. This ensures a consistent record between the sender and the token reference register, which increases transparency and trust between the transacting parties and allows for the establishment of an auditable trail.

[0110] In one embodiment, for each payment transaction, a payment certificate is sent, preferably including confirmation of a token reference register, a confirmation signature, and at least one of i) transaction data and ii) a currency value. This certificate, including the confirmation and transaction data, assures the recipient of the sender's true intent and the legitimacy of the transaction, thereby minimizing misunderstandings or potential disputes.

[0111] In one embodiment, for each payment transaction, the sender's private key is obtained via a communication interface. This ensures joint participation in the completion of the transaction, thereby increasing transaction security and enhancing the collaborative aspects of the transaction process.

[0112] Other advantages and features of this disclosure will be apparent from the dependent claims, the description and the drawings. Attached Figure Description

[0113] To gain a more detailed understanding of the features described above in this disclosure, a more specific description of the disclosure, which has been briefly summarized above, can be obtained by referring to typical embodiments. The accompanying drawings relate to embodiments of this disclosure and are described below:

[0114] Figure 1 A secure electronic payment transaction system for token transactions using secure transaction units based on existing technologies is demonstrated.

[0115] Figure 2 A symbolic diagram of a secure token transaction unit within an electronic payment transaction system according to the present invention is shown;

[0116] Figure 3a , 3b Symbol diagrams are shown for service provider units designed as payment transaction recipients or senders within the electronic payment transaction system according to the present invention;

[0117] Figure 4a , 4b Each figure shows a symbolic diagram of an electronic payment transaction system according to the present invention;

[0118] Figure 4c A symbolic diagram of the token reference register according to the present invention is shown;

[0119] Figure 5 A symbolic diagram illustrating a method for providing non-repudiable payment transactions between participants in an electronic payment transaction system according to the present invention. Detailed Implementation

[0120] Reference will now be made in detail to various embodiments, one or more examples of which are illustrated in each of the accompanying drawings. Any embodiment may be combined with any other embodiment where technically reasonable and / or permissible. Each example is provided by way of explanation and is not intended to be limiting. For example, a feature shown or described as part of an embodiment may be used on or in combination with any other embodiment to produce yet another embodiment. This disclosure is intended to include such modifications and variations.

[0121] In the following description of the accompanying drawings, the same reference numerals refer to the same or similar parts. Generally, only differences with respect to individual embodiments are described.

[0122] The reference numerals in the accompanying drawings are for illustrative purposes only. Aspects of the invention are not limited to any particular embodiment. Rather, unless otherwise stated, any aspect or embodiment described herein may be combined with any other aspect or embodiment described herein.

[0123] Figure 1 An example of a secure electronic token trading system TS with a secure transaction unit TU, based on existing technology, is shown. Figure 1 A secure electronic token transaction system TS, such as a payment transaction system, corresponds to the third method described above. The transaction system TS includes a register layer Reg-LAY, in which a token reference register T-Reg is located. TS also includes a direct transaction layer TU-LAY, which can provide multiple transaction units TU. For example, Figure 1 Two transaction units, TU1 and TU2, are shown. TU1 and TU2 have control devices configured to generate a replacement request RR (also known as a registration request RR), which includes a modification command CO regarding the modification of the token, including the T of the secure transaction unit TU1. a and the T of the secure transaction unit TU2 c .

[0124] The trading units TU in the TS trading system are configured to directly exchange 15 tokens of T with each other. Figure 1 In the case of T old T a and T c It is a payment token, also known as a digital currency, preferably a CBDC. Each token T in TS is issued by a specific token issuer ( Figure 1 The transaction unit TU-I (not shown in the image) is generated.

[0125] Each token T can be modified, such as by splitting, merging, or switching, by applying the modification command CO to each trading unit TU.

[0126] Each token T can be generated by the token issuer's trading unit TUI, and can also be deleted. The token issuer's trading unit TU-I is, for example, a commercial bank or financial services provider unit FSP.

[0127] Modifying command CO conforms to the third method described above, and these modifications are avoided here. Each modification can be registered in T-Reg via a replacement request (= registration request) RR.

[0128] Token T (also known as a negotiable instrument) is uniquely represented by a monetary value v and a random number r. Therefore, each token T in this TS has at least two token elements.

[0129] The monetary value v, which is the first mandatory token element, can range from 1 to 2. 31 The value range of -1 is specified. The random number r can be between 0 and 2. 256 Numbers in the range of -1, i.e., the order of the elliptic curve, such as secp256r1. For example, the token value v is a 32-bit token element of integer type.

[0130] The random number r, which serves as the second mandatory token element, is the private key of the token-individual key pair. The random number r is unique and secret within the transaction system (TS) and cannot be disclosed or reused. The generation of the random number r must be unpredictable. For example, the random number r can be a 32-byte token element of integer type.

[0131] The transaction unit TU has exclusive access to the storage unit (vault), or the data storage of the transaction unit TU includes a token storage.

[0132] For each token T, a token reference TR can be stored in the token reference register T-Reg. The token reference TR includes the currency value v (of token T) and the public key R corresponding to the private key r of the token-individual key pair. The token reference TR of token T can be viewed at any time in the register T-Reg of the transaction system TS.

[0133] TU1 possesses currency value v a and random number r old T old In step 16a, TU1 uses a switch-modify technique to change T... old Switch to T a T a Including (T) old (of) currency value v a And the newly generated random number r a In step 21, TU1 generates a unique assignment to T. a TR a .

[0134] If needed, the token references TR a The TU1 can send the registration request RR (generated in step 22a) along with the command CO to the token reference register T-Reg.

[0135] Additionally, use the private key r old Sign the registration request RR. Signing allows verification that TU1 owns / knows the token T. old This further enhances the security of the transaction system TS.

[0136] In Figure 1The registration request RR generated in TU1 during the switch-modification process includes the modification command CO and the token T to be registered. a Output Token Reference TR a And the token T to be removed from the token reference register T-Reg old Input token reference TR old The registration request RR also includes a signed registration request RR. sig_old It uses the token T old private part r old The signature of RR.

[0137] In step 31, the RR can be sent to T-Reg to register the TR in T-Reg. a TS receives token T from TU1 a Each TU can now verify T a Is it a valid token T in TS?

[0138] For example, when executing token transactions (such as payment transactions), token T a (It can also be TR) a And / or RR (e.g., as proof) can be transferred from TU1 to TU2. TU2 now performs a switch-modification to transfer token T. a The token T switched from TU1 to TU2. c Therefore, in step 16a, a new random number r is generated in TU2. c However, v a New T c The same token elements are also maintained. In step 21, TU2 is based on T c Generate Token Reference TR c Because of v a Nothing changed, therefore no currency was created or deleted.

[0139] This token references TR c It can be sent to T-Reg as another registration request RR by TU2 (generated in step 22a) along with command CO.

[0140] Additionally, RR uses the private key r a Signature. Signature allows verification that TU2 owns the (old) token T. a This further enhances the security of TS.

[0141] In TU2, the registration request RR related to the switch-modification is generated as 22a, including the switch-modification command CO and the token T to be registered. c An output token reference TR c And the token T to be removed from the token reference register T-Rega An input token reference TR a Registration Request RR s It also includes the registration request RR with a signature. sig_a It uses the token T a private part r a The signature of RR.

[0142] In cases where a data connection to the T-Reg is unavailable or undesirable, such as in offline token transactions, each TU can store the RR as a so-called proof of interest (PROOF).

[0143] RR is sent to T-Reg at step 31. RR is received in T-Reg. After RR is checked by T-Reg, TR is removed from T-Reg in step 41. a And will TR c Stored in T-Reg. Therefore, TR c Replace TR a RR can also be called a replacement request. Through storing TRc, the token T c It is registered in TS.

[0144] Each TR is uniquely assigned to T in TS, and TR is used to register T in TS. Therefore, TR is the public representation of T from the direct transaction layer TU-LAY. Knowing or owning TR alone does not allow the transfer of T, and is not equivalent to TU owning T. TR is used to prevent multiple spending attempts and to check if the token value v is generated incorrectly. Therefore, TR, along with (if applicable) the history (proof) of RR from token T and TU(s), is stored in T-Reg.

[0145] T can be stored, for example, in a secure wallet that serves as the TU. These wallets are, for example, software applications within a terminal device, in which the TU is operatively embedded. The wallet can be configured as an application on a smartphone, smart card, or payment terminal. The wallet is used to securely manage the TU's token T, generate token references TR, modify token T, and / or exchange token T. The wallet is used to communicate with the token reference register T-Reg, generate registration requests RR to the token reference register T-Reg, modify token T (switching, merging, splitting), and / or execute transactions involving token T to another TU.

[0146] As mentioned earlier, transactions within TU-LAY do not require a communication link to the T-Reg of TS. TS is configured to execute transactions offline, meaning there is no communication link to the T-Reg. Therefore, the corresponding registration of token T can be downstream in time from the transfer of token T to TU.

[0147] T-Reg is a unit within the trading system TS, and is either the central register or database of the trading system TS, or a distributed register or database (DLT) of the trading system TS.

[0148] The public part R of the token-individual key pair (as part of TR) is generated by applying a cryptographic function to the private part r of the token-individual key pair. This function is irreversible, thus providing the required security for the transaction system TS. R = R G holds, where G can be, for example, a global parameter of the trading system TS, or a generator point of an elliptic curve (here, the secp256r1 curve). Any other suitable cryptographic function can also be applied to receive the value of R.

[0149] Hardware TU (Smart Card) and Managed TU (In Service Provider Unit) Figure 1 The subject name (not shown in the image) can be a TU-ID. A TU-ID may need to meet some or all of the following criteria:

[0150] The TU-ID may need to convey whether it is a wallet certificate, a CA certificate, or an admin-CA terminal entity certificate. The TU-ID may need to be small enough to be transmitted and stored in a hardware wallet (e.g., a smart card). The TU-ID may need to fit the subject field of the certificate; for example, it should not exceed 16 bytes in length. The TU-ID may need to remain stable when the certificate changes. The TU-ID may need to contain information about the SPU that issued the TU (e.g., a Financial Services Provider Unit, FSP) so that token trading processors can use it to route data to other token trading processors, for example, to find the IP address of the token trading processor.

[0151] TU-ID should include the central bank ( Figure 1 The TU-ID (not shown) may require an identifier within the FSP to allow cross-currency transfers (i.e., multi-currency transactions or multi-currency transaction systems).

[0152] TU1 includes the Secure Token Transaction Unit Identifier TU1-ID. TU1-ID uniquely assigns a user's TU1 within the TS. TU2 includes the Secure Token Transaction Unit Identifier TU2-ID. TU2-ID uniquely assigns a user's TU2 within the TS.

[0153] In the transaction system TS, a protocol data register P-Reg may also exist. This P-Reg stores the protocol data PROT generated by each transaction unit TU in step 23 after a transaction has been completed. PROT may include TU1-ID, TU2-ID, and one or more token elements of token T as part of token transfer 15. It can be defined that the sender (TU1) or receiver (TU2), or both, generates PROT in the corresponding step 23 and provides it to P-Reg in step 32a. This P-Reg is considered a pure protocol unit and should not contain any token elements of token T; on this basis, P-Reg will be in the position of token T. In other words, the random number r (or private key r) of each token T is not part of PROT. However, the monetary value v of each token T may be part of PROT, representing the amount of monetary value v transferred between TU1 and TU2 according to the protocol.

[0154] This prior art concept has a conceptual flaw, in which a malicious recipient of the token (here, TU2) disputes the receipt of the token transfer in step 15, and a bona fide sender (here, TU1) cannot otherwise prove it.

[0155] This situation may occur when the token receiver TU2 is able to interrupt communication between the token sender TU1 and the token reference register T-Reg. For example, the following scenarios are possible:

[0156] 1. Malicious token recipient TU2 requests token T for receiving monetary value v from bona fide token sender TU1. TU1 creates T(r, v), generates the corresponding TR(r, v) in step 22a, and sends TR to TU2.

[0157] 2. TU1 performs all necessary steps and prepares the replacement request RR, such as using the command CO, such as SWITCH modification or SPLIT modification to obtain ownership of T, that is, to transfer ownership of the token from TU1 to TU2 by registering TR.

[0158] 3. Therefore, TU1 creates and signs the RR in step 22a and sends it to T-Reg in step 31. T-Reg executes the RR and registers the TR in T-Reg, but before sending confirmation that the TR has been successfully registered in T-Reg, communication between TU1 and T-Reg is interrupted by TU2 (as an attack scenario) or a random network connection failure occurs.

[0159] 4. TU2 now knows (or at least can infer) that TU1 has correctly published the RR in step 22a and sent it in step 31, meaning that TU2 is the new owner of the active token (r, v) with monetary value v. Since the T-Reg confirmation has not yet reached TU1, TU1 cannot prove the successful execution of the RR.

[0160] 5. TU2 (quickly) performs further modifications, such as from the active token T(r,v) to the new token T. new (r) new The splitting command for (v). Then, in step 31, TU2 will split the corresponding new token reference TR. new Send to T-Reg.

[0161] 6. At some point, TU1 will reconnect to T-Reg and repeat the registration of the previous TR by sending the RR to T-Reg again in step 31. T-Reg will now reject the RR because TU2 has already registered the TR during this period. new Furthermore, TR (and its corresponding T) are no longer valid.

[0162] Note that this situation also occurs due to random network failures, but it does require TU2 to switch token T prematurely, without giving TU1 T-Reg a chance to confirm the switch.

[0163] Even in non-malicious circumstances, this can still cause the payment processor to enter an erroneous state. Therefore, TU2 has already spent the (correctly) received T. However, TU2 can simultaneously claim that it never received T, and TU1 cannot convince anyone that they have followed the protocol.

[0164] The concept of this invention addresses a problem related to non-repudiation in interbank transfers (transfers). Non-repudiation refers to the sender's ability to provide undisputed proof of payment in the event of a dispute. The current problem is that, in known protocols, there is no provision for the sender to retain proof of payment when currency is transferred between two participants within a TS. This is due to an oversight in the design of known protocols and their failure to account for garbage collection on the token reference register.

[0165] This concept proposes a solution where the recipient of the transfer signs a token reference, allowing the sender to subsequently prove the correct destination of the transfer. It also addresses the risk of a malicious recipient exploiting funds before the sender stores the proof by dividing the process of verifying the target token reference into two parts, generated separately by the sender and the recipient. The sender transfers currency to a token reference with a combined public key, and only shares half of their private key after the proof is stored.

[0166] This concept also protects the privacy of payment proofs and does not reveal the sender's wallet balance. To achieve this, a mechanism is provided to generate a proof for one of the split targets without revealing information about the other values ​​used in the split.

[0167] To ensure security, the messages exchanged during this process are signed, providing an additional guarantee against unauthorized alteration. The recipient needs to sign the public key with a private key that identifies itself and can be verified by the sender.

[0168] This concept also provides access to proof of payment. This proof includes various data points such as transfer ID, transaction amount, sender wallet ID, receiver wallet ID, the public portion of the generated key pair, a signature of the data using the corresponding transfer private key, and proof of the validity of the negotiable instrument from the token reference register.

[0169] The cryptographic operations used in this method are robust and secure against potential attacks. For example, even if an attacker intercepts the connection and steals one key, they will not be able to find the other key.

[0170] To resolve the above issue, follow these steps:

[0171] - The sender TU1 generates a private key r1 and a public key R1.

[0172] - The receiver TU2 generates a private key r2 and a public key R2.

[0173] -TU1 executes replacement requests, such as using a switch or split operation on the combined public key R1+R2.

[0174] A one-way function can be used to compute the public key R without knowing the value of r1.

[0175] R = R1 + R2 = R1 + G r2

[0176] in

[0177] -R is the combined public key.

[0178] -R1 and R2 are the public keys of TU1 and TU2,

[0179] -r1 and r2 are the private keys of TU1 or TU2, and

[0180] -G is the elliptic curve generator point in elliptic curve cryptography (ECC) used to obtain the public key R from the private key r. A generator point can be a predefined point on the curve used to generate other points on the curve. Multiplying the generator point G by an integer produces another point on the curve.

[0181] Therefore, without the other party's consent, neither party can access the combined token reference TR(R, v), because the final combined private key R is the sum (addition or concatenation) of the contributions of both parties R1 and R2, and neither party knows the private key r of the other transmitting party (participant).

[0182] The sender, TU1, can prove that he has correctly executed the transaction by disclosing his private key r1 and an acknowledgment from the token reference register T-Reg. This means that the proof can be verified by calculating the combined public key R and verifying it with the acknowledgment from the token reference register. The acknowledgment can also be digitally signed using the private key from the token reference register.

[0183] Receiver TU1 can calculate the combined token reference TR comb The combined private key r' = r1 + r2 is used to access and use funds. The above formula allows TU1 to create a combined private key r' for token T only after TU2 receives confirmation from T-Reg, by adding private key r1 to private key r2 obtained from TU2.

[0184] This solution ensures non-repudiation by generating a composite key and integrating a token reference register into the verification and authentication process. The composite private key can only be used when both parties (sender and receiver) are involved, thus ensuring that neither party can act maliciously if the other party cannot prove the transaction.

[0185] Figure 2 An exemplary embodiment of a secure token transaction unit TU1 within an electronic payment transaction system TS (not shown in the figure) is illustrated. The secure token transaction unit TU1 may be a custodian wallet.

[0186] The token transaction unit TU1 can be hosted within service provider units (or terminals) 20 and 30. Through service provider units (or terminals) 20 and 30, the token transaction unit TU1 is in an operational state, that is, the token transaction unit TU1 is configured to send tokens directly to another token transaction unit TU2 (also referred to as the second transaction unit TU2) of the electronic payment transaction system TS. The secure token transaction unit TU1 may include a secure memory 12 for storing data; a secure communication interface 16 adapted to provide data to and receive data from service provider units (or terminals) 20 and 30; and an optional control module 14, such as a processor, microprocessor, or microcontroller.

[0187] If TU1 is a software application executable in the runtime environment of service provider units (or terminals) 20, 30, then the security memory 12, communication interface 16, and control module 14 are omitted.

[0188] TU1 is suitable for implementing a dual-key control mechanism, including:

[0189] a) Preferably, a unique encryption key pair (r1, R1) including a private key (r1) and a public key (R1) is generated using a random number generator.

[0190] b) Receive the public key (R2) from the second transaction unit TU2.

[0191] c) Generate a replacement request RR, which includes the input token reference TR0(v, R0) uniquely assigned to the token T0 of TU1 and the output token reference TR0(v, R0). out Combination token reference TR comb (v, R'), where TR comb This includes a combined public key R' = R1 + R2, where public key R' is a combination of public key R1 from TU1 and public key R2 from TU2. Preferably, the public key R2 received from the second transaction unit TU2 is digitally signed using the transmission private key of the second transaction unit TU2.

[0192] d) Having the TR comb The RR of (v, R') is provided to T-Reg.

[0193] Therefore, the dual-key control mechanism enhances the security of transactions so that they cannot be tampered with, thereby achieving non-repudiable transaction proof.

[0194] Therefore, the mechanism implemented by TU1 can facilitate the implementation of a dual-key control mechanism and provide enhanced security by using strong signature verification based on this mechanism, making transactions tamper-proof and thus providing non-repudiable proof of transactions.

[0195] Figure 3a An exemplary embodiment of a service provider unit (or terminal) 20 is shown, which is designed to host a TU2 as a payment transaction recipient within an electronic payment transaction system TS (not shown in the figure). The electronic payment transaction system TS includes a token reference register T-Reg and at least one transaction unit TU2, and 20 is connected to or can be connected to the transaction unit TU2. Figure 3a Also shown is a service provider unit (or terminal) 30, which is designed to host a TU1 as the sender of a payment transaction for a payment transaction.

[0196] The service provider unit (or terminal) 20, designed to host the TU2 as a payment transaction recipient, may include: a secure communication interface 26, which is connected to or can be connected to the transaction unit TU2 and, in the connected state, is adapted to provide data to and receive data from the transaction unit TU2; a communication module 28, which is communicatively connected to or can be connected to the sender 30; a secure memory 22; and a control module 24, such as a processor, microprocessor, or microcontroller.

[0197] If TU2 is a software application executable in the runtime environment of service provider units (or terminals) 20, 30, then the secure memory communication interface 26 can be omitted.

[0198] Figure 3b An exemplary embodiment of a service provider unit (or terminal) 30 is shown, which is designed to host a TU1 as a payment transaction sender within an electronic payment transaction system TS (not shown in the figure). The electronic payment transaction system TS includes a token reference register T-Reg and at least one secure token transaction unit TU1, and the service provider unit (or terminal) 30 is connected to or can be connected to the secure token transaction unit TU1.

[0199] The service provider unit (or terminal) 30 may include a secure communication interface 36 that is connected to or can be connected to the transaction unit TU1 and, in the connected state, is adapted to provide data to and receive data from the transaction unit TU1; a communication module 38 that is connected to or can be connected to the receiver 20; a secure memory 32; and a control module 34, such as a processor, microprocessor, or microcontroller.

[0200] If TU1 is a software application executable in the runtime environment of service provider units (or terminals) 20, 30, then the secure memory communication interface 36 may be omitted.

[0201] Figure 4a An exemplary embodiment of an electronic payment transaction system TS is illustrated. The electronic payment transaction system TS may include:

[0202] - At least one terminal 20, which is designed to be the sender of a payment transaction, and

[0203] - At least one terminal 30, which is designed to be the recipient of a payment transaction.

[0204] Figure 4b An exemplary embodiment of an electronic payment transaction system TS including a token reference register T-Reg is shown, and Figure 4cThe token reference register T-Reg of the electronic payment transaction system TS is shown. The token reference register T-Reg can be communicatively connected to at least one sender 30 and at least one receiver 20 of the payment transaction system TS.

[0205] The token reference register T-Reg may include a secure memory 42, a communication module 48, and a control module 44 (e.g., a processor, microprocessor, or microcontroller).

[0206] Control module 44 may be adapted to perform via communication module 48: receiving from sender 30 a combined token reference TR comb Replacement request RR for (v, R'), storage combination token reference TR comb (v, R'), and via communication module 48, sending confirmation input token reference TR0 (v, R0) to sender 30 that it has been combined with token reference TR comb The confirmation of (v, R') substitution enhances the security of transactions that cannot be tampered with, thereby achieving non-repudiable transaction proof.

[0207] Figure 5 A symbolic diagram is shown of a method 100 for providing non-repudiable payment transactions between participants in an electronic payment transaction system TS according to the present invention. The participants include at least one sender 30 and at least one receiver 20 for the payment transaction.

[0208] Method 100 may include:

[0209] Sender 30:

[0210] - Generate a 102 sender key pair r1, R1, which includes the sender's private key r1 and the sender's public key R1;

[0211] Receiver 20:

[0212] - Generate a 104-bit receiver key pair r2, R2, which includes the receiver's private key r2 and the receiver's public key R2, and

[0213] - Send the receiver's public key R2 (106) to sender 30;

[0214] Sender 30:

[0215] - Generate a 108 replacement request RR, which includes the input token reference TR0(v, R0) uniquely assigned to TU1 token T0 and the combined token reference TR as the output token reference. comb (v, R'), where the combined token references TR comb (v, R') includes the monetary value (v) and the combined public key R' = R1 + R2, and

[0216] - Send the combined token reference (v, R') to the token reference register T-Reg;

[0217] Token Reference Register T-Reg:

[0218] - Verify input token reference TR0(v, R0) for 112, and if the verification result is positive...

[0219] -Use combined tokens as a reference TR comb (v, R') replaces the input token reference TR0(v, R0) in 114 T-reg.

[0220] - Generate 116 confirmation, preferably including a replacement request (RR), and

[0221] - Send a 118 confirmation to the sender.

[0222] This ensures that transactions cannot be tampered with, thus achieving non-repudiable proof of transactions.

[0223] In this document, the terms “sender” and “terminal designed as a sender” and the terms “receiver” and “terminal designed as a receiver” are used interchangeably / synonymously.

[0224] Figure Labels

[0225] TS Electronic (Payment) Transaction System

[0226] Transaction units in TUTS, wallet

[0227] SPU (Financial) Service Provider Unit

[0228] S Delayed Token Storage

[0229] TU-E Trading Unit Expansion

[0230] TU-E-ID Extended Identifier for Transaction Units

[0231] SPU-IDSPU identifier

[0232] LUS Search Service

[0233] TU-ID is the identifier for TU, and is also known as the wallet ID.

[0234] Key-S Key Store

[0235] TSP Trusted Service Provider Unit

[0236] TSP-IDTSP identifier

[0237] TSP-STSP-Storage

[0238] TU-I root Root Token Issuer Unit

[0239] T-Reg Token Reference Register

[0240] 1 storage unit

[0241] P-Reg Protocol Data Register

[0242] PROT protocol data

[0243] Reg-LAY registration layer

[0244] TU-LAY Token Transfer Layer

[0245] RR registration request, replacement request

[0246] T token

[0247] encT encrypted T

[0248] TR Token Reference

[0249] vT's monetary value

[0250] R-Token - Public Key of Individual Key Pair

[0251] CO command

[0252] sig signature

[0253] The public key of the R key pair

[0254] r token - the secret private key of an individual key pair

[0255] Transfer of 15 tokens

[0256] 16a Modified Tokens

[0257] 21 Generate Token Reference

[0258] 22a generates RR

[0259] 23 Generate PROT

[0260] 31 Registration Request, Replacement Request RR

[0261] 32a Protocol Data Transfer

[0262] 12-Transaction Unit Security Storage

[0263] 14. Control module of the trading unit

[0264] 16 Secure communication interface for trading units

[0265] 20 Service Provider Units of Hosted Receiving TU

[0266] 22 20 secure storage

[0267] 24 20 control module

[0268] 26 20 secure communication interface

[0269] 28 20 communication module

[0270] 30 Terminals designed as payment transaction senders

[0271] 32. Sender's secure storage

[0272] 34. Control module of the sender

[0273] 36. Secure communication interface of the sender

[0274] 38. Sender's communication module

[0275] 42. Secure storage for the token reference register

[0276] 44. Control module for the token reference register

[0277] 46. ​​Secure communication interface for the token reference register

[0278] 48. Control module of the token reference register

[0279] 100 provides a method for non-repudiable payment transactions.

[0280] 102 Sender: Generate sender key pair (r2, R2)

[0281] 104 Receiver: Generate receiver key pair (r1, R1)

[0282] 106 Receiver: Sends the receiver's public key (R1) to the sender.

[0283] 108 Sender: Switch the initial token reference (v, R0) to the composite token reference (v, R')

[0284] 110 Sender: Sends the combined token reference (v, R') to the token reference register.

[0285] 112 Token Reference Register: Verify Initial Token Reference (v, R0)

[0286] 114 Token Reference Register: Replace the initial value with a combined token reference.

[0287] 116 Token Reference Register: Generation Confirmation

[0288] 118 Token Reference Register: Sends confirmation to the sender

Claims

1. A secure token transaction unit (TU1), such as a wallet, hosted within a service provider unit (SPU) in an electronic payment transaction system (TS), the electronic payment transaction system including a token reference register (T-Reg), the secure token transaction unit (TU1) being configured to send a token (T) to another token transaction unit (TU2) within the electronic payment transaction system (TS), the secure token transaction unit (TU1) being adapted to perform a dual-key control mechanism, the dual-key control mechanism comprising: a) Preferably, a unique encryption key pair (r1, R1) including a private key (r1) and a public key (R1) is generated using a random number generator. b) Receive the public key (R2) from the other token transaction unit (TU2). c) Generate a replacement request (RR), which includes an input token reference (v, R0) and a combined token reference (v, R') as an output token reference (TR) for a token (T0) uniquely assigned to the security token transaction unit (TU1). The combined token reference (v, R') includes a public key (R'), which is a combination of a public key (R1) generated by the security token transaction unit (TU1) and a public key (R2) received from the other token transaction unit (TU2). d) Provide the replacement request (RR) to the token reference register (T-Reg). The dual-key control mechanism enhances security because the payment transaction cannot be tampered with, thus enabling non-repudiation of the payment transaction.

2. The secure token transaction unit (TU1) according to claim 1, wherein, The public key (R2) received from the other token transaction unit (TU2) is digitally signed using the transmission private key of the other token transaction unit (TU2) or the transmission private key of the service provider unit (SPU).

3. The secure token transaction unit (TU1) according to claim 1 or 2, wherein, The dual-key control mechanism also includes: - If the combined token reference (v, R') is successfully registered in the token reference register (T-Reg), an acknowledgment is received from the token reference register (T-Reg), the acknowledgment preferably including i) transaction data, such as at least one of transaction ID, reference number, and timestamp, and / or ii) a digital signature of the combined token reference (v, R') and / or the replacement request (RR).

4. The secure token trading unit (TU1) according to any one of the preceding claims, wherein, The dual-key control mechanism also includes: - Provide the private key (r1) to the other token transaction unit (TU2), thereby enabling the other token transaction unit (TU2) to generate a combined private key (r'=r1+r2) to control the currency value (v) associated with the combined public key (R') via the combined token reference (v, R'); and / or - Generate a digital signature of the combined token reference (v, R') using the transmission private key of the secure token transaction unit (TU1), and / or provide the digital signature of the combined token reference (v, R').

5. The secure token trading unit (TU1) according to any one of the preceding claims, wherein, The dual-key control mechanism also includes: - Receive transaction data, said transaction data including at least one of transfer ID, sender wallet ID, receiver wallet ID, and timestamp; and / or - Generate the combined token reference (v, R'), preferably including a currency value (v), a combined public key (R1, R2), and optionally transaction data.

6. A secure token transaction unit (TU2), such as a wallet, hosted within a service provider unit (SPU) in an electronic payment transaction system (TS), the electronic payment transaction system including a token reference register (T-Reg), the secure token transaction unit (TU2) being configured to receive tokens (T) from another token transaction unit (TU1) within the electronic payment transaction system (TS), the secure token transaction unit (TU2) including a control module (14) adapted to perform a dual-key control mechanism, the dual-key control mechanism including: a) Preferably, a unique encryption key pair (r2, R2) including a private key (r2) and a public key (R2) is generated using a random number generator. b) Send the public key (R2) to the other transaction unit (TU1). c) Receive a token reference register confirmation from the other secure token transaction unit (TU1), the token reference register confirmation confirming that the token reference register (T-Reg) i) has verified the authenticity and correctness of the combined token reference (v, R'), and ii) has replaced the input token reference (v, R0) with the combined token reference (v, R') in its record, the confirmation serving as non-repudiable proof of the transaction.

7. The secure token transaction unit (TU2) according to claim 6, wherein the dual-key control mechanism further includes: d) Receive a private key (r1) from the other transaction unit (TU1) to generate a combined private key (r'), wherein the combined private key (r') is a combination of the private key (r2) generated by the secure token transaction unit (TU2) and the private key (r1) received from the other token transaction unit (TU1) to control the currency value (v) associated with the combined token reference (v, R').

8. The secure token transaction unit (TU2) according to claim 6 or 7, wherein, Before sending the public key (R2), the public key (R2) is digitally signed using the transmission private key of the other transaction unit (TU2) or the transmission private key of the service provider unit (SPU).

9. The secure token transaction unit (TU2) according to any one of claims 6 to 8, wherein, The dual-key control mechanism also includes: Payment proof is received from the other transaction unit (TU1), the payment proof including confirmation of the token reference register (T-Reg), confirmation signature, and more preferably including at least one of i) transaction data and ii) the combined token reference (v, R'), the confirmation signature preferably being a digital signature using the transmission private key of the token transaction unit (TU1); and preferably verifying the authenticity and integrity of the confirmation of the token reference register (T-Reg) by means of the transmission public key of the other secure transaction unit (TU1).

10. A service provider unit (20) within an electronic payment transaction system (TS), the electronic payment transaction system (TS) being configured to host a plurality of secure token transaction units (TU1, TU2) according to any one of the preceding claims, the service provider unit (20) comprising: - Communication module (28), which is communicatively connected to or able to connect to another service provider unit (30); -Secure storage (22); and - A control module (24), such as a processor, microprocessor, or microcontroller, is adapted to execute the dual-key control mechanism for each payment transaction.

11. An electronic payment transaction system (TS), comprising: - At least one service provider unit (SPU) according to claim 10, which is designed as the sender of a payment transaction (30), and - At least one service provider unit (SPU) according to claim 10 is designed as a recipient of a payment transaction (20).

12. The electronic payment transaction system (TS) according to claim 11, wherein, The transaction system (TS) also includes a token reference register (T-Reg) communicatively connected to or capable of being connected to the sender (30) and / or the receiver (20), the token reference register (T-Reg) including: -Secure storage (42); - Communication module (48); and - A control module (44), such as a processor, microprocessor, or microcontroller, is connected to the secure memory (42) and the communication module (48) and is adapted to perform: The communication module (48) receives a replacement request (RR) including a combined token reference (v,R') from the sender (30), stores the combined token reference (v,R'), and sends an acknowledgment to the sender (30) via the communication module (48) to confirm that the input token reference (v,R0) has been replaced by the combined token reference (v,R'). This enhances the security of transactions, ensuring they cannot be tampered with, and thus provides irrefutable proof of transactions.

13. The electronic payment transaction system (TS) according to claim 12, wherein, The control module (44) of the token reference register (T-Reg) is adapted to further perform the following: for each transaction, receive a signing public key from the sender (30) and the receiver via the communication module (48) for verifying the digital signature of the replacement request (RR) and / or the combined public key.

14. A method (100) for providing non-repudiable payment transactions between participants in an electronic payment transaction system (TS) including a token reference register (T-Reg), said participants including at least one sender (30), preferably a transaction unit (TU1) according to any one of claims 1 to 8 or a service provider unit (SPU) according to claim 10, and at least one receiver (20) including the payment transaction, preferably a transaction unit (TU2) according to any one of claims 6 to 9 or a service provider unit (SPU) according to claim 10, said method (100) comprising: -Sender (30): Generate (102) a sender key pair (r1, R1) including the sender's private key (r1) and the sender's public key (R1); - Receiver (20): Generates (104) a receiver key pair (r2, R2), which includes the receiver private key (r2), preferably digitally signed by the public key (R2) using the receiver's (30) transmission private key; and includes the receiver public key (R2) and sends (106) the receiver public key (R2) to the sender (30). - Sender (30): Generates (108) a replacement request (RR), the replacement request (RR) comprising an input token reference (v, R0) uniquely assigned to the token transaction unit (TU1) for the token (T0) and a combined token reference (v, R') as an output token reference (TR), wherein the combined token reference (v, R') comprises a combined public key (R' = R1 + R2), and sends (110) the replacement request (RR) to the token reference register (T-Reg); and - Token Reference Register (T-Reg): Verify (112) the input token reference (v, R0), and if the verification result is positive, replace (114) the input token reference (v, R0) in the token reference register (T-Reg) with the combined token reference (v, R'); generate (116) an acknowledgment, preferably including the replacement request; and send (118) the acknowledgment to the sender (30). This ensures that transactions cannot be tampered with, thus achieving non-repudiable proof of transactions. Preferably, the method further includes: - Sender (30): Receives confirmation from the token reference register (T-Reg); stores the confirmation; sends the token reference register confirmation to the receiver (20); sends the sender's private key (r1) and confirmation including at least a currency value (v) to the receiver (20), preferably, the token reference register confirmation is a payment proof, preferably including: the confirmation of the token reference register (T-Reg), preferably a confirmation signature using a digital signature of the sender's (20) transmission private key, and at least one of i) transaction data and ii) currency value (v).

15. A non-transitory computer-readable storage medium for tangibly storing computer program instructions executable by a processor, the computer program instructions implementing the steps of the preceding method claim.

Images