Terminal device, electronic payment transaction system and method

Abstract

A terminal device for participating in an electronic payment transaction system is provided. The terminal device includes a secure hardware unit including a token memory and a control unit configured to participate in token transactions. The terminal device includes a storage unit storing a lossy compressed list of list elements, each list element indicating a secure hardware unit within the electronic payment system that is blocked. The terminal device includes a processing unit operably coupled with the secure hardware unit. The processing unit is configured to determine, prior to or during a token transaction with a further secure hardware unit within the electronic payment system, whether the further secure hardware unit is flagged as blocked based on a list element (optionally, a hash value) within the lossy compressed list. The processing unit is further configured to, in the event that the further secure hardware unit is flagged as blocked, determine a risk value of performing the token transaction with the further secure hardware unit, and if the risk value is determined to be acceptable, perform the token transaction.

Description

Technical Field

[0001] This invention relates to a terminal device, an electronic payment transaction system, and a corresponding method for an electronic payment transaction system. Background Technology

[0002] Tokens (also known as digital assets, electronic coins, or coin datasets) can represent any digital asset, particularly digital currency, preferably a central bank digital currency, or CBDC for short. These tokens are issued and deleted by units of the trading system, such as issuing institutions, or central bank units or commercial bank units, hereinafter also referred to as secure token issuance units.

[0003] Electronic token transactions and / or the storage of tokens, as well as any associated transaction data and / or stored data, must be secure and reliable. Therefore, means must be implemented to protect the confidentiality, integrity, and availability of exchanged and / or stored token data. This applies to electronic payment transactions and associated payment transactions and payment storage, where a monetary value is associated with each token (hereinafter also referred to as token value).

[0004] For digital assets (such as digital currencies like central bank digital currencies (CBDCs) issued by central banks), there are different technical approaches.

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

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

[0007] According to a favorable third method, such as those described in WO2020 / 212331A1 or WO2023 / 036458A1, tokens are stored in a local token management unit for direct exchange between participants in the electronic payment transaction system. Transferred tokens can be effectively used upon receipt from another participant without requiring approval or verification via an online connection. Therefore, even if an online connection is unavailable, inconvenient, or inappropriate for a particular token transaction, tokens can still be transferred directly and effectively between participants in the electronic payment transaction system. For security, verification, and registration purposes, a token register stores token references for all valid tokens without knowing the tokens themselves. Thus, users can check the validity of received tokens. The token register only stores token references for the corresponding tokens. Tokens can be switched, split, or merged by each individual participant; for example, ownership of a token can be transferred from one participant to another, a token can be split into multiple tokens (e.g., for obtaining a token with a lower monetary value), and / or multiple tokens can be merged into a single token (e.g., for obtaining a token with a higher monetary value).

[0008] In the electronic payment transaction system based on the third method, each participant includes a transaction unit or token management unit assigned to them. Each of these transaction units is capable of achieving high standards of security, confidentiality, and safety regarding payment transactions, and is therefore called a secure transaction unit. A transaction unit is also referred to as a wallet or token wallet.

[0009] Wallets can be provided as hardware wallets, such as smart cards issued to participants, or as so-called custodial wallets, such as wallets hosted by various service providers. Wallets can be hosted on end devices.

[0010] Electronic token transactions and / or the storage of tokens, as well as any related transaction data and / or stored data within the electronic token transaction system, must be secure and reliable. Therefore, mechanisms must be implemented to protect the confidentiality, integrity, and availability of exchanged and / or stored token data. This is particularly true for electronic payment transactions and associated payment transactions and payment storage, where monetary value is linked to each token.

[0011] Occasionally, it is necessary to block wallets, for example, when they are lost or stolen. Each participant in an electronic payment transaction system needs at least the ability to determine whether a wallet participating in a payment transaction (partner wallet) has actually been blocked. Therefore, a blacklist of blocked wallets is established within the electronic payment transaction system, which can be invoked to check if a given wallet ID is blocked. However, this check requires an online connection (online verification) for the wallet or the terminal device containing the wallet.

[0012] To enable offline wallets to perform this verification of partner wallets, a blacklist is provided to the wallet. Due to strict memory limitations, the blacklist is typically compressed, for example, by storing the wallet IDs of the blocked wallets in a Bloom filter. This compression has the drawback of generating false positives; for example, the Bloom filter might coincidentally contain elements, such as hash values, that correspond to wallet IDs that are not actually blocked. As a result of the verification, if the check shows that the partner wallet for the payment transaction appears to be blocked, the wallet is configured to abort the payment transaction. Therefore, in offline scenarios, payment transactions may be rejected or aborted due to false positives caused by the lossy compression of the blacklist. False positives can lead to lost revenue for merchants because customers cannot make payments. Summary of the Invention

[0013] Therefore, there is a need for a terminal device for electronic payment transactions configured to reduce the number of payments canceled due to blocked wallets caused by false positives. Furthermore, there is a need for a corresponding payment transaction method.

[0014] The aforementioned objective is achieved through the features of the independent patent claims. Further advantageous embodiments are described in the dependent patent claims.

[0015] In one independent aspect of the invention, a terminal device for participating in an electronic payment transaction system is provided. The terminal device includes a secure hardware unit comprising a token memory and a control unit configured to participate in token transactions. The terminal device includes a storage unit for storing a lossy compressed list comprising list elements. Each list element represents or indicates one or more blocked secure hardware units within the electronic payment system. The terminal device includes a processing unit operatively coupled to the secure hardware unit. The processing unit is configured to determine, before or during a token transaction with another secure hardware unit within the electronic payment system, whether an additional secure hardware unit is marked as blocked based on list elements in the lossy compressed list. The processing unit is further configured to, if the additional secure hardware unit is marked as blocked, determine a risk value for performing a token transaction with the additional secure hardware unit, and if the risk value is determined to be acceptable, perform the token transaction.

[0016] In another independent aspect of the invention, an electronic payment transaction system is provided. The electronic payment transaction system includes a plurality of terminal devices, wherein at least one terminal device is configured according to one aspect of the invention. The electronic payment transaction system includes a security loading unit configured to provide a lossy compressed list including list elements. Each list element indicates one or more blocked security hardware units. The electronic payment transaction system may include a token reference register for storing references to token transactions between two of the plurality of terminal devices.

[0017] In another independent aspect of the invention, a method for protecting token transactions in an electronic payment transaction system is provided. The method is executed in a processing unit of a terminal device, optionally acting as a payee. The method includes: receiving an identifier, for example, the ID of an additional security hardware unit; determining whether the additional security hardware unit is marked as blocked based on comparing the identifier with list elements of a lossy compressed list; if the additional security hardware unit is marked as blocked, determining a risk value for performing a token transaction with the additional security hardware unit; and if the risk value is determined to be acceptable, executing the token transaction, otherwise aborting the token transaction.

[0018] In another independent aspect of the invention, a method for protecting token transactions in an electronic payment transaction system is provided. The method is executed in a processing unit of a terminal device, optionally acting as a payee. The method includes: receiving a token or token reference of an additional security hardware unit hosted by another terminal device; determining, based on list elements within a lossy compression list, whether the additional security hardware unit is marked as blocked; if the additional security hardware unit is marked as blocked, determining, based on the received token or token reference, a risk value for executing the token transaction with the additional security hardware unit; and if the risk value is determined to be acceptable, executing the token transaction, otherwise aborting the token transaction.

[0019] In another independent aspect of the invention, a non-transitory computer-readable storage medium is provided for tangibly storing computer program instructions executable by a processing unit. The computer program instructions implement the steps of a method according to any aspect of the invention. The term "non-transitory computer-readable storage medium" includes, but is not limited to, magnetic or optical media, such as magnetic disks, hard disk drives, volatile or non-volatile media such as RAM.

[0020] The key point of this invention is that if another security hardware unit of another terminal device, although (potentially incorrectly) marked as blocked, is still trustworthy, the terminal device is authorized to continue payment transactions with that other terminal device. In other words, the terminal device is configured to handle exceptions, where determining whether another security hardware unit is marked as blocked based on list elements within a lossy compression list results in a positive outcome. By handling positive outcomes, the terminal device can weigh the risks of continuing payment transactions with another security hardware unit that has been marked as blocked.

[0021] A risk value can be understood as a value reflecting the credibility of another security hardware unit on another terminal device. A risk value can indicate the acceptance rate or percentage of payment transactions with another terminal device. For example, a risk value can be or include a measure of the probability that the definitive result of another security hardware unit being blocked is false. A risk value can be or include a confidence value that reflects the confidence that another security hardware unit, despite being marked as blocked, has not actually been blocked.

[0022] Terminal equipment, electronic payment transaction systems and / or methods may also include one or more of the following features.

[0023] Terminal devices and other terminal devices may consist of or include the same hardware, however, they provide complementary functions to collaboratively conduct electronic payment transactions.

[0024] The processing unit can be configured to instruct or request the security hardware unit, particularly the control module of the security hardware unit, to initiate an electronic payment transaction, also known as a hardware payment transaction.

[0025] A secure hardware unit can also be referred to as a secure token transaction unit. A secure hardware unit may include a memory for storing multiple tokens, each of which is a monetary value token, such as a central bank digital currency token. The secure hardware unit may also include a control module configured to negotiate a secure payment channel with a secure element of another terminal device. The control module may be further configured to receive tokens transferred from another secure hardware unit of another terminal device acting as a payer to a secure hardware unit of a terminal device acting as a payee.

[0026] The secure hardware unit (as described herein) may be or include a secure element, also known as a secure wallet, secure token management unit; token wallet; and / or the wallet may be used to locally manage tokens in the storage itself and / or convert tokens and register tokens in an electronic token trading system. Tokens may be stored in a token storage that is also managed by the token wallet.

[0027] Each secure hardware unit may include a secure token transaction unit identifier, also known as an identifier, ID, wallet ID, or wallet identification data. The secure token transaction unit identifier is assigned to a specific secure token transaction unit to uniquely identify the secure token transaction unit within the electronic token trading system. The secure token transaction unit identifier may optionally be stored in a specific secure wallet.

[0028] The secure token transaction unit identifier can be generated at the unit that issues the secure hardware unit (such as a financial service provider unit or a central entity in a transaction system).

[0029] Alternatively, the secure token transaction unit identifier can be generated by an official institution or a secure token issuing unit (such as a central bank unit). In this case, the secure token transaction unit identifier can be received by the control device of the secure hardware unit issuing unit or the secure register unit.

[0030] In one embodiment, the secure token transaction unit identifier is mandatory data to be transmitted between various users in an electronic transaction system to directly exchange tokens. This can be a system requirement to ensure a high standard of security, and in this case, the secure token transaction unit identifier not only uniquely identifies the secure token transaction unit, but can also ultimately identify the "real" user by resolving user information using an additional secure register unit.

[0031] In one embodiment, the secure hardware unit may be or include a secure encryption device, such as that specified in ISO 13491-1. The secure hardware unit may be or include a device that provides encryption services and storage for physical and logical protection, and it may be integrated into a larger system, such as an automated teller machine (ATM) or point-of-sale (POS) terminal.

[0032] In one embodiment, the secure hardware unit can be a simple element, such as that specified in EP23020212.9. The secure hardware unit can have a lower security level than a secure element, particularly due to the lack of security components such as a Trusted Execution Environment (TEE), a Hardware Security Module (HSM), a secure or tamper-proof storage unit, or secure program code. In offline scenarios, a secure hardware unit configured as a simple element can therefore only receive tokens without sending them, i.e., act as a recipient.

[0033] Each list element in the lossy compression list can represent one or more identifiers of a security hardware unit included in a blacklist of blocked security hardware units. The processing unit can be configured to compare each list element of the lossy compression list with an identifier of another security hardware unit, which the end device may know during token transaction initialization. Each list element can be or includes a hash value. The processing unit can be configured to generate a hash value of the identifier of another security hardware unit, and then directly compare the generated hash value with the list element of the lossy compression list, which is particularly useful when the list element is a hash value.

[0034] If the identifier of another security hardware unit matches the identifier of a list element represented in a lossy compressed list, the other security hardware unit is identified as blocked. However, due to the possibility of false positives within lossy compressed lists, the other security hardware unit may not actually be blocked. In online token transactions, the terminal device or its security hardware unit can request a security instance in the electronic payment transaction system to verify whether the other security hardware unit has indeed been blocked based on a complete blacklist.

[0035] Token transactions can be offline. The terminal device can be offline when determining the risk value. In this case, the terminal device cannot obtain the complete blacklist in its original state; that is, it does not have the complete value instead of multiple list elements, each indicating one or more blocked security hardware units within the electronic payment system. Therefore, there is no option to verify or double-check whether additional security hardware units are indeed blocked.

[0036] The processing unit may be referred to as a Rich Execution Environment (REE), which provides a highly scalable and versatile operating environment. The processing unit may be embedded within a Trusted Execution Environment (TEE), for example, certified by a global platform. The processing unit may include toolkits adapted to interact with and / or communicate with secure hardware units.

[0037] According to some embodiments, a terminal device can act as a recipient, that is, expecting payment from another terminal device, which can act as the corresponding payer. (Electronic) payments or token transactions can be initiated via a payment request from the terminal device to another secure hardware unit of the other terminal device through a secure hardware unit.

[0038] According to some embodiments, the processing unit can be configured to receive an identifier of another secure hardware unit of another terminal device. The processing unit can configure the communication unit or interface of the terminal device to open / route a communication channel to the communication unit or interface of the other terminal device. During the negotiation of a secure (wallet) channel for subsequent token transfers via the communication channel between participating terminal devices, the identifier can be transferred from the secure hardware unit of the other terminal device to the secure hardware unit of the other terminal device. The identifier can be stored in the memory of the secure hardware unit. The processing unit can be configured to access the received identifier stored in the secure hardware unit to receive the identifier of the secure hardware unit of the other terminal device. When determining whether the other secure hardware unit is marked as blocked based on a comparison of the received identifier with a lossy compression list, the processing unit can actively influence or intervene in the channel negotiation. Alternatively, the processing unit can determine whether the other secure hardware unit is marked as blocked after the channel negotiation, based on a comparison of the received identifier with a lossy compression list. The ability of the processing unit to retrieve the identifiers of other security hardware units and / or check whether the identifiers of other security hardware units are included in the lossy compression list can be provided in the dedicated application data protocol unit (APDU).

[0039] According to some embodiments, the processing unit can also be configured to determine a risk value based on parameter values ​​associated with the token transaction. The risk value may be acceptable if the parameter value is below or equal to a predefined threshold. Optionally, the parameter value is or includes the monetary value of the token received during the token transaction. In other words, if the parameter value is below or equal to the predefined threshold, the token transaction can always be accepted, regardless of whether additional security hardware units are blocked based on list elements within the lossy compression list. This acceptance rule includes the risk that additional security hardware units may be blocked, making the received tokens transferred during the token transaction potentially invalid.

[0040] According to some embodiments, the processing unit may also be configured to receive confirmation of a token reference to another secure hardware unit. The confirmation may be generated when the token reference is verified at the token reference register of the electronic payment transaction system. The confirmation may include a timestamp. The confirmation and / or the timestamp of the confirmation may be signed by an authoritative body, such as the (secure) token reference register and / or a financial service provider, to prevent the provision of false confirmations and timestamps via malicious wallets. The processing unit may be configured to determine a risk value based on the confirmation. If the timestamp of the confirmation includes a date and / or time after a predetermined point in time, the risk value may be acceptable. The token reference may correspond to a token transferred during a token transaction. In some embodiments, the token reference may correspond to another token not transferred during a token transaction.

[0041] The confirmation can correspond to the token included in the token transaction. In other words, the secure hardware unit can first receive the token and its confirmation, and then determine the risk value based on the confirmation corresponding to the received token.

[0042] According to some embodiments, the token reference may be a token reference of another security hardware unit's token, which participates in token transactions.

[0043] In one embodiment, the processing unit may be configured to access and / or analyze confirmation.

[0044] The processing unit can determine the risk value based on the information included in the confirmation. Specifically, the processing unit can determine the point in time when the replacement request involving a token or token reference has been signed by the security register of the electronic payment transaction system (e.g., a security token reference register). This point in time can be determined based on the timestamp included in the confirmation.

[0045] In one embodiment, confirmation may include the proof history of the corresponding token or token reference. The processing unit may be configured to determine a risk value based on the length of the proof history and / or the gaps in the proof history preceding the timestamp included in the confirmation. The length of the proof history and / or the gaps in the proof history preceding the (latest) timestamp included in the confirmation may correspond to parameter values ​​associated with token transactions, for which predetermined thresholds may be set.

[0046] According to some embodiments, the terminal device may further include a user interface operatively coupled to the processing unit. The processing unit may be configured to receive predefined thresholds and / or predetermined time points via a user interface. The user interface may be configured as a touch display of the terminal device.

[0047] According to some embodiments, the control unit of the secure hardware unit may also be configured to obtain a certificate from another secure hardware unit during the negotiation of a secure channel for token transmission. The processing unit may also be configured to: request a certificate from the secure hardware unit; and determine a risk value based on the certificate. If the certificate is valid, the risk value may be acceptable.

[0048] The processing unit can be configured to receive certificates from the security hardware unit of another terminal device. During the negotiation of a secure (wallet) channel for subsequent token transfer via a communication channel between participating terminal devices, the certificate can be transferred from the security hardware unit of the other terminal device to the security hardware unit of the terminal device. The certificate can be stored in the memory of the security hardware unit. The processing unit can be configured to access the received certificate stored in the security hardware unit, thereby receiving the certificate from the security hardware unit of the other terminal device. Therefore, the processing unit can actively influence or intervene in channel negotiation. This functionality of the processing unit can be provided within a dedicated Application Data Protocol Unit (APDU).

[0049] Certificates may include an Online Certificate State Protocol (OCSP) envelope, which may optionally be signed by a financial service provider for security reasons. The processing unit can also be configured to determine a risk value based on the OCSP envelope, i.e., to determine the validity of the certificate based on the OCSP envelope. This functionality allows for faster verification of the validity of certificates from other secure hardware units; however, embedding an OCSP envelope into token transactions is not straightforward, as it requires both generating and signing the OCSP envelope.

[0050] According to some embodiments, the processing unit can also be configured to mark received tokens from additional security hardware components as risky if the risk value is unacceptable. Marking a received token as risky can indicate that the received token cannot be used for (any) subsequent token transactions. Marking a received token as risky can be a measure of tampering evidence, i.e., providing a measure of evidence that an invalid token has been attempted to participate in an electronic payment transaction. The processing unit can also be configured to cancel token transactions.

[0051] According to some embodiments, at least one of a Bloom filter, a quotient filter, and a Cockoo filter can be used to generate a lossy compressed list of hash values ​​indicating blocked security hardware units within an electronic payment system.

[0052] According to some embodiments, the terminal device may be or include a point-of-sale (POS) terminal, an automated teller machine (ATM), or an unattended payment terminal (UPT).

[0053] Terminal equipment can be a financial terminal and can include multiple components such as: PIN input device (PED), printer, communication equipment, customer / merchant interface, acquiring application, IC card reader and / or magnetic stripe reader. These components can be combined and configured in various ways as needed.

[0054] In one embodiment, an electronic payment transaction system may include a token register, particularly a token reference register, for storing tokens, token transactions, or references to token transactions between two of a plurality of terminal devices. The token register or token reference register provides further security for token transactions within the electronic payment transaction system, particularly due to the online verification service of (received) tokens. Using a token reference instead of a token has the further advantage of reducing the communication of sensitive information, such as the private key associated with the corresponding token.

[0055] In an electronic payment system, different types of terminal devices can coexist. Terminal devices in the first group can be configured to be always online, thus enabling them to constantly check the identifiers of other security hardware units against a complete blacklist hosted by a dedicated system service (e.g., a secure loading unit). These terminal devices may not suffer false positive detections of blocked other security hardware units. Terminal devices in the second group can include sufficient memory to always download the complete blacklist without hashing the identifiers of blocked security hardware units. Terminal devices in the second group may not encounter false positive detections of blocked other security hardware units. Terminal devices in the third group can correspond to terminal devices according to aspects of the invention, which may encounter false positive detections of blocked other security hardware units. Since the processing of positive detection results in terminal devices in the third group is performed locally, i.e., within the processing unit of the terminal device, no interference is expected between terminal devices in different groups. Therefore, terminal devices in the first, second, and third groups can coexist in an electronic payment transaction system, i.e., participate in public token transactions.

[0056] The method steps for determining the risk value may further include determining the risk value based on parameter values ​​associated with the token transaction. The risk value may be acceptable if the parameter value is less than or equal to a predefined threshold. Optionally, the parameter value is or includes the monetary value of the token received during the token transaction.

[0057] The method steps for determining the risk value may further include receiving confirmation of a token reference from an additional secure hardware unit. This confirmation may be generated when the token reference is verified at the token reference register of the electronic payment transaction system. The confirmation may include a timestamp. The confirmation and / or timestamp may be signed by an authoritative body, such as the (secure) token reference register and / or a financial service provider. The method steps for determining the risk value may also include determining the risk value based on the confirmation. If the timestamp of the confirmation includes a date and / or time after a predetermined point in time, the risk value may be acceptable. The date and / or time may be encoded as a timestamp.

[0058] The method steps for determining the risk value may further include: during the negotiation of a secure channel for token transmission, the secure hardware unit obtains a certificate from another secure hardware unit. The method steps for determining the risk value may further include: the processing unit requesting a certificate from the secure hardware unit; and determining the risk value based on the certificate. If the certificate is valid, the risk value may be acceptable.

[0059] Additional security hardware units can be embodied in hardware wallets, such as cards, especially smart cards, and / or custodial wallets (e.g., custodied by another terminal device). Attached Figure Description

[0060] The invention, or other embodiments and advantages thereof, are explained in more detail below with reference to the accompanying drawings, which illustrate only embodiments of the invention. The same parts in the drawings are given the same reference numerals. Elements drawn with dashed lines are considered optional.

[0061] The accompanying drawings should not be considered to be of true scale, and the various elements of the drawings may be shown in exaggerated or exaggeratedly simplified forms.

[0062] Figure 1 A schematic timing diagram for conducting electronic payment transactions according to existing technology is shown.

[0063] Figure 2 An exemplary embodiment of a terminal device according to one aspect of the present invention is shown.

[0064] Figure 3 An exemplary embodiment of a terminal device that communicates directly with another terminal device according to one aspect of the present invention is shown.

[0065] Figure 4 An exemplary embodiment of an electronic payment transaction system comprising at least one terminal device according to one aspect of the present invention is shown.

[0066] Figure 5 A schematic timing diagram for making a payment transaction according to one aspect of the present invention is shown. Detailed Implementation

[0067] exist Figure 1 The diagram depicts a simplified sequence of a payment transaction according to existing technology. In the payment transaction, a (first) terminal device TD1 includes a secure hardware unit SH (or a first wallet) and additional secure hardware units. Another (second) terminal device TD2 (or second wallet) participates. Structurally, the security hardware unit SH and other security hardware units... They can overlap or be identical. However, unlike the security hardware unit SH, other security hardware units can be configured based on a lossy compressed list that includes list elements. Marked as blocked, each list element represents an identifier for one or more blocked security hardware units. Figure 1 In the example, the terminal device TD1 acts as the recipient, meaning it expects payment from a separate, hosted security hardware unit. Payment can also be made via token by the other terminal device TD2. In another scenario, terminal device TD1 can also act as the payer, i.e., hosting another secure hardware unit. The other terminal device, TD2, can act as the payee.

[0068] Payment transactions are typically initiated by step P1, in which terminal device TD1 (specifically its processing unit) receives payment details such as the origin number, for example, the identifier of another security hardware unit SH of another terminal device TD2, and the transaction amount.

[0069] In the second step P2, terminal device TD1 can forward the payment details to its secure hardware unit SH, i.e., the secure hardware unit SH, which is internal to the terminal device. Alternatively, the secure hardware unit SH can receive the payment details in the first step P1, where in the second step P2, terminal device TD1 retrieves or requests some payment details from the secure hardware unit SH.

[0070] In the subsequent third step P3, the first terminal device TD1 enables its secure hardware unit SH to establish a connection with the secure hardware unit SH corresponding to the origin number, for example using Bluetooth, Wi-Fi, or Internet protocols. The established connection or channel can also be referred to as a wallet channel. The wallet channel can be linked via the corresponding communication interfaces of the involved terminal devices TD1 and TD2.

[0071] exist Figure 1 In the example, after the connection has been established in step P3, terminal device TD1 can be configured to check whether the origin number corresponds to a blocked security hardware unit. Assuming an offline scenario, terminal device TD1 can check the origin number against a lossy compressed list containing multiple list elements, which is prone to false alarms, as described above. Figure 1 In the example, based on the lossy compression list, additional security hardware units It may be marked as blocked. Therefore, even in other security hardware units... Even though it was not actually blocked, the TD1 terminal device also canceled the token transaction.

[0072] exist Figure 2 The exemplary embodiment of a terminal device according to one aspect of the present invention is schematically depicted.

[0073] according to Figure 2 The example terminal device TD includes a security hardware unit SH, a processing unit PU, and an optional communication interface CI. The processing unit PU is operatively coupled to the security hardware unit SH and the communication interface CI.

[0074] according to Figure 2The example terminal device TD's security hardware unit SH includes a control unit CU and a storage unit SU. The storage unit may include a token storage unit T. The processing unit PU may be operatively coupled to the control unit CU of the security hardware unit SH, that is, to send data and / or commands to the control unit CU of the security hardware unit SH and / or to receive data and / or commands from the control unit CU of the security hardware unit SH.

[0075] In the storage unit SU, a lossy compressed list LI comprising multiple list elements can be stored. Each list element represents or indicates one or more blocked security hardware units. Each list element may be or include a hash value that can indicate one or more blocked security hardware units. However, list elements (e.g., hash values) may include false positives, i.e., indicating a security hardware unit as blocked when it is not actually blocked.

[0076] The processing unit (PU) is configured as an additional secure hardware unit within the electronic payment system (TS). Before or during token transactions, additional security hardware units are determined based on list elements within the lossy compressed list LI. Whether it is marked as blocked.

[0077] To reduce the number of (unnecessary) cancellations of payment transactions, the processing unit (PU) is configured to operate within a separate secure hardware unit. If marked as blocked, determine the connection with another security hardware unit. The risk value for executing a token transaction is determined, and if the risk value is determined to be acceptable, the token transaction is executed.

[0078] about Figure 5 Various possibilities for determining whether a risk value is acceptable are discussed.

[0079] exist Figure 3 The present invention describes an exemplary embodiment of a terminal device that communicates directly with another terminal device according to one aspect of the present invention.

[0080] The TD1 terminal device can act as a payee. The TD1 terminal device can correspond to... Figure 2 An exemplary embodiment of the terminal device TD is described. The terminal device TD1 may be, for example, a POS terminal, an ATM, or a UPT.

[0081] exist Figure 3 In the example, the additional terminal device TD2 can act as a payer. More specifically, it can function independently or as... Figure 3 The example shows an additional security hardware unit managed by another terminal device, TD2. It can act as a payer. Based on a lossy compressed list LI containing multiple list elements, additional secure hardware units can be identified. It was blocked. However, using a rule-based approach, the terminal device TD1 can identify additional secure hardware transaction units. It was not blocked and continued in the security hardware unit SH and other security hardware units. Negotiate / establish a wallet channel between them. Figure 3 In the diagram, the wallet channel is depicted by a dashed double arrow. Alternatively, the terminal device TD1 can determine additional secure hardware transaction units after the wallet channel has been established. Whether it is blocked, for example, based on another security hardware unit. The received token determines this.

[0082] In the payer role, storing the lossy compressed list LI is optional but recommended. If available, the additional terminal device TD2 can also determine whether the security hardware unit SH of terminal device TD1 (i.e., its trading partner) has been marked as blocked.

[0083] exist Figure 4 The present invention describes an exemplary embodiment of an electronic payment transaction system comprising at least one terminal device according to one aspect of the present invention.

[0084] Figure 4 In an example electronic payment transaction system TS, some terminal devices TD can store a lossy compression list LI and use this list to determine whether their respective transaction partners include security hardware units marked as blocked. These terminal devices TD can use information about... Figure 5 The rule-based approach discussed further determines whether the corresponding security hardware unit remains trustworthy, allowing the payment transaction to proceed rather than be cancelled. The more terminal devices configured according to one aspect of the invention, the fewer payments are unnecessarily cancelled within the electronic payment transaction system TS. Therefore, the communication overhead associated with unnecessarily cancelled payment transactions can be reduced.

[0085] Figure 4 The example electronic payment transaction system TS may also include a token reference register T-Reg, which is configured to verify the validity of tokens, specifically by registering corresponding token transactions based on the token references included therein. The token reference register T-Reg can enhance the security of token transactions within the electronic payment transaction system TS.

[0086] Figure 4The example electronic payment transaction system TS also includes a Security Loading Unit (SOB). The SOB can be configured to manage (i.e., update and / or maintain) a blacklist of blocked security hardware units. The SOB can be configured to generate a lossy compressed list LI comprising multiple list elements, where each list element represents one or more blocked security hardware units, for example, by storing representations of the blocked security hardware units in one of a Bloom filter, a Merchant filter, or a Cuckoo filter. The SOB can be configured to update the lossy compressed list LI and / or provide updates to the lossy compressed list LI to the terminal device TD in the electronic payment transaction system TS. For example, the SOB can provide incremental updates to the lossy compressed list LI. Each list element of the lossy compressed list LI can be a hash value or include hash values.

[0087] exist Figure 5 The diagram depicts a schematic sequence for initiating a payment transaction according to one aspect of the present invention.

[0088] Figure 5 The sequence diagram is Figure 1 The sequence diagram is extended. Step P3 can correspond to the first step S1 according to the present invention. That is, in the first step S1, additional security hardware units can be received. The identifier. In Figure 5 In the example, another security hardware unit It can be hosted by another terminal device (TD2), for example, implemented as a hosted wallet. Similarly, additional security hardware units... It can be implemented as a hardware wallet (not shown), that is, not hosted by the terminal device.

[0089] In the second step S2, the terminal device TD1 determines the other secure hardware units involved in the payment transaction by comparing the identifier with the list elements of the lossy compressed list LI. Whether it is marked as blocked. However, the list LI inherently includes false positives, so not every security hardware unit identified as blocked is actually blocked within the electronic trading system TS.

[0090] The method also includes a third step S3, which includes: in an additional security hardware unit If the device is identified as blocked, the processing unit PU of the terminal device TD1 determines the necessary security hardware unit to communicate with. Risk value of executing token transactions.

[0091] In the first example, a risk value can be determined based on parameter values ​​associated with the token transaction, where the risk value is acceptable if the parameter value is below or equal to a predefined threshold. For example, the parameter value is or includes the monetary value of the token received during the token transaction. That is, until a certain threshold of the monetary value is reached, even if additional security hardware units are used based on a lossy compressed list LI. Even if it is marked as blocked, token transactions can still be executed.

[0092] In the second example, it can be based on another security hardware unit. The risk value is determined by confirming the received token reference. Confirmation can be generated when verifying the token reference in the token reference register T-Reg of the electronic payment transaction system TS. This method may include determining that the risk value is acceptable if the confirmation's timestamp includes a date and / or time after a predetermined time point.

[0093] In the third example, it can be based on additional secure hardware units during the negotiation of a secure channel used for token transmission. The obtained certificate is used to determine the risk value. This method may include the processing unit PU of the terminal device TD1 requesting the certificate from the security hardware unit SH. If the certificate is valid, the risk value can be considered acceptable.

[0094] In step S4, if the risk value is determined to be acceptable, the payment transaction can continue with secure (encrypted) token transfer. Otherwise, the payment transaction can be stopped, canceled, aborted, or optionally reported. In one embodiment, step S4 may include adding additional security hardware components if the risk value becomes unacceptable. Received tokens are marked as risky. Marking received tokens as risky indicates that the received tokens cannot be used for subsequent token transactions.

[0095] Figure Labels

[0096] TD and TD1 terminal equipment

[0097] Other TD2 terminal devices

[0098] PU processing unit

[0099] SU storage unit

[0100] CI Communication Interface

[0101] LI is a lossy compressed list containing multiple list elements.

[0102] SH Security Hardware Unit

[0103] Additional security hardware units

[0104] CU control unit

[0105] T token storage

[0106] TS Electronic Payment Transaction System

[0107] SOB Secure Load Unit

[0108] T-Reg Token Reference Register

Claims

1. A terminal device for participating in an electronic payment transaction system, the terminal device comprising: A secure hardware unit, comprising a token storage and a control unit, the control unit being configured to participate in token transactions; A storage unit for storing a lossy compressed list comprising multiple list elements, wherein each list element represents one or more blocked security hardware units within the electronic payment system; and A processing unit, operatively coupled to the security hardware unit, is configured to: Before or during a token transaction with another secure hardware unit within the electronic payment system, determine whether the other secure hardware unit is marked as blocked based on list elements in the lossy compression list. If the additional security hardware unit is marked as blocked, a risk value for executing the token transaction with the additional security hardware unit is determined, and if the risk value is determined to be acceptable, the token transaction is executed.

2. The terminal device according to claim 1, wherein, The token transaction mentioned is an offline token transaction.

3. The terminal device according to claim 1, wherein, The terminal device was offline when the risk value was determined.

4. The terminal device according to claim 1, wherein, The processing unit is further configured to: The risk value is determined based on parameter values ​​associated with the token transaction, wherein the risk value is acceptable if the parameter value is less than or equal to a predefined threshold, wherein the parameter value is preferably or includes the monetary value of the token received during the token transaction.

5. The terminal device according to claim 1, wherein, The processing unit is further configured to: The confirmation of receiving the token reference of the additional security hardware unit is generated when the token reference is verified at the token reference register of the electronic payment transaction system. and The risk value is determined based on the confirmation, wherein the risk value is acceptable if the timestamp of the confirmation includes a date and / or time after a predetermined time point.

6. The terminal device according to claim 5, wherein, The token reference is a token reference of the token of the other security hardware unit, and the token participates in the token transaction.

7. The terminal device according to claim 4, further comprising: A user interface operatively coupled to the processing unit, wherein the processing unit is configured to receive the predefined threshold.

8. The terminal device according to claim 4, further comprising: A user interface operatively coupled to the processing unit, wherein the processing unit is configured to receive the predetermined time point via the user interface.

9. The terminal device of claim 1, wherein the control unit of the security hardware unit is further configured to obtain a certificate of the additional security hardware unit during negotiation of a secure channel for token transmission; and wherein, The processing unit is further configured to: Request the certificate from the security hardware unit; and The risk value is determined based on the certificate, wherein if the certificate is valid, the risk value is acceptable.

10. The terminal device according to claim 9, wherein, The certificate includes an Online Certificate Status Protocol (OCSP) envelope optionally signed by a financial service provider, wherein the processing unit is further configured to determine the risk value based on the OCSP envelope.

11. The terminal device according to claim 1, wherein, The processing unit is further configured to: If the risk value is unacceptable, the received tokens of the additional security hardware element are marked as risky, wherein the received tokens marked as risky indicate that the received tokens cannot be used for subsequent token transactions; and Cancel the token transaction.

12. The terminal device according to claim 1, wherein, The lossy compressed list of blocked security hardware units within the electronic payment system is generated using at least one of a Bloom filter, a Commercial filter, and a Cockoo filter.

13. The terminal device according to claim 1, wherein, Each of the plurality of list elements is a hash value or includes a hash value.

14. The terminal device according to claim 1, wherein, The terminal device is at least one of a point-of-sale terminal and an automated teller machine, or includes at least one of a point-of-sale terminal and an automated teller machine.

15. An electronic payment transaction system, comprising: Multiple terminal devices, at least one of which is configured according to claim 1; and A secure loading unit is configured to provide a lossy compressed list comprising multiple list elements, where each list element represents one or more blocked secure hardware units.

16. The electronic payment transaction system according to claim 15 further includes: A token reference register is used to store a reference for token transactions between two of the plurality of terminal devices.

17. A method for protecting token transactions in an electronic payment transaction system, the method being executed in a processing unit of a terminal device, the terminal device optionally acting as a payee, the method comprising: Receive identifiers from other security hardware units; The determination of whether the additional security hardware unit is marked as blocked is based on comparing the identifier with the list elements of the lossy compression list; In the event that the additional security hardware unit is marked as blocked, a risk value is determined for executing the token transaction with the additional security hardware unit; and If the risk value is determined to be acceptable, the token transaction is executed; otherwise, the token transaction is aborted.

18. The method according to claim 17, wherein, Determining the risk value further includes: The risk value is determined based on parameter values ​​associated with the token transaction, wherein the risk value is acceptable if the parameter value is less than or equal to a predefined threshold, wherein the parameter value is optionally the currency value of the token received during the token transaction, or includes the currency value of the token received during the token transaction.

19. The method of claim 17, wherein, Determining the risk value further includes: The system receives confirmation of a token reference from the additional security hardware unit, wherein the confirmation is generated when the token reference is verified at the token reference register of the electronic payment transaction system; and determines a risk value based on the confirmation, wherein the risk value is acceptable if the timestamp of the confirmation includes a date and / or time after a predetermined time point.

20. The method of claim 17, wherein, Determining the risk value further includes: During the negotiation of a secure channel for token transmission, the secure hardware unit obtains the certificate from the other secure hardware unit; and The processing unit requests the certificate from the security hardware unit; and determines the risk value based on the certificate, wherein the risk value is acceptable if the certificate is valid.

Images