Patent Application
20250014022
The invention relates to a secure transaction unit. The invention also relates to a service provider unit. The invention also relates to an electronic transaction system in particular an electronic payment transaction system.
Tokens—also referred to as digital assets, electronic coins, coin data sets—may represent any digital asset, in particular a digital currency, preferably a central bank digital currency, short CBDC. These tokens are issued and deleted by an issuing unit of the payment transaction system, such as an issuing authority, or a central bank unit or a commercial bank unit, hereinafter also referred to as secure token issuing unit.
Electronic token transactions and/or storage of tokens and any associated transaction data and/or storage data in an electronic payment transaction system must be safe and secure and so, means for protecting confidentiality, integrity, and availability of exchanged and/or stored token data must be implemented. This is especially true for electronic payment transactions and associated payment transactions and payment storages in which a monetary value is linked with each token.
Secure transaction units may be stolen or may be lost. Tokens that are hosted by such lost or stolen secure transaction unit, e.g. tokens that locally reside in such a secure transaction unit, remain valid in the electronic transaction system. Since the owner of the token is unable to access the tokens, he may suffer a significant monetary (financial) damage, because the (monetary) value represented by the tokens is blocked due to inaccessibility. In addition, in case the transaction unit is stolen, a thief may use the tokens to perform transactions as a fraud.
It is known that transaction units may for the purpose of data redundancy store copies of the token from their storage unit in another storage unit, such as an external USB flash drive or an online storage (cloud storage). Since copies of tokens would be a security risk in the transaction system, complex encryption schemes are necessary to secure the copies and complex system management steps are required to support the use of copies in such cases.
So, there is a need that valid tokens can be accessed in cases where the transaction unit is stolen or is lost. It is important that token elements of the tokens are not revealed to the public to ensure data protection and data integrity as well as security within the transaction system. In addition, a fraud should be detectable when a payment is performed with a stolen transaction unit. However, anonymity in the transaction system must be always ensured and must not be reduced. It should also be possible that tokens of a stolen or lost transaction unit are recovered without reducing anonymity to avoid a financial damage to the participant to whom the transaction unit is assigned.
The above-identified objectives are solved with the features of the independent patent claims. Further advantageous embodiments are described in the dependent patent claims.
In an aspect of the present invention there is provided a secure transaction unit in an electronic transaction system, e.g., in an electronic payment transaction system. The secure transaction unit may be referred to as secure wallet. The secure transaction unit may be a hardware transaction unit, such as a secure element, a smartcard, a local electronic wallet, a hardware security module or a software application hosted at a terminal device of a participant. In an embodiment, the secure transaction unit is a secure element that is operatively connected to an electronic terminal device of a participant in the electronic transaction system. It is built in hardware to enable tamperproof and secure access to tokens residing therein.
The secure transaction unit comprises storage means for storing one or more token. So, the one or more tokens locally reside in the secure transaction unit which means that the tokens are physically stored in the secure transaction unit. The storage means may be referred to as token storage and is a physical entity. The token storage may be a token vault of this secure transaction unit. Each secure transaction unit in the transaction system may comprise its own token storage. From such token storage accessible by control means of the secure transaction unit, each token can be transferred to any other secure transaction unit, e.g., owned by a customer of the secure transaction unit.
The tokens are managed by the secure transaction unit, which may be seen as tokens that reside in a storage unit of that secure transaction unit, or that are owned (possessed) by a participant to which that secure transaction is uniquely assigned. The token may be an asset token. The token may be a currency token. The token may be a central bank issued token, such as a CBDC. The token may be a digital currency token from other commercial issuers.
The secure transaction unit further comprises control means that is configured to establish an online communication with a central unit of the electronic payment transaction system. This establishing of the online communication may be initiated by an online transaction in which tokens of the secure transaction unit should be transferred to another secure transaction unit within the transaction system or to request registration data from the central unit or to forward protocol data related to transactions to the central unit.
An online communication may be defined as a communication via classical internet or mobile communication means or any other suitable online communication protocol. Online communication comprises any sort of communication connection with an entity that is remote from the transaction unit, for instance via an internet link using TCP, IP, HTTP, HTTPS or any comparable sort of communication. It excludes short range offline communication, such as near field communication, Bluetooth, etc.
The control means is further configured to receive a blacklist-status in response to the established online communication. This blacklist-status-response should be received immediately after establishing the communication with the central unit. It may be the first response after establishing the communication link. This response should be provided before another request, such as a registration request or a protocol data report (for instance a request to enter protocol data) from that transaction unit is finally proceeded within the transaction system.
A secure transaction unit identifier that is also referred to as wallet-ID that may be unique in the electronic payment system may be provided with the blacklist-status-response.
A blacklist within this disclosure is a list of transaction units that are reported as being stolen or as being lost. The transaction unit having a blacklist-status “fulfilled” is also referred to as a backlisted secure transaction unit. Such a blacklisted secure transaction unit is flagged or indicated as not being a partner in a payment transaction. In other words, a backlisted secure transaction unit should not be used for payment transactions.
A blacklist-status represents a status of the transaction unit within the blacklist. The blacklist-status can either be fulfilled, which means that the transaction unit has been reported as being stolen or lost. Alternatively, the blacklist-status can be not-fulfilled, which means that the transaction unit has not been reported as being stolen or lost.
The report whether a transaction unit is stolen or lost may be provided by the participant that is assigned to the transaction unit. The request may be initiated by that participant to which the transaction unit is (uniquely) assigned. The request may indicate the loss of the transaction unit. The report whether a transaction unit is stolen or lost may alternatively be provided by a third person that found the transaction unit.
Each transaction unit within the transaction unit may comprise a blacklist-status. This blacklist-status may be initiated with “not-fulfilled” status as long as no report whether the transaction unit is stolen or lost is received in the transaction system.
To enter a transaction unit into the blacklist and/or to change a blacklist-status for a particular transaction unit from “not-fulfilled” to “fulfilled”, a unique identifier of the transaction unit, such as a wallet-ID, or a chip-ID, or a card-ID, or a serial-number or any other suitable data for uniquely identifying the transaction unit may be used. Preferably, this unique identifier is also reported when reporting the lost or stolen transaction unit.
A secure transaction unit identifier may be used that is also referred to as wallet-ID that may be unique in the electronic payment system.
When changing the blacklist-status, a timestamp may also be entered in the blacklist. So, it may be protocolled the time at which the transaction unit is considered as stolen/lost and so, token that are transferred after that timestamp-data may be recovered.
So, a blacklist may comprise a unique identifier, a blacklist-status and preferably a timestamp at which the blacklist-status was changed last time.
Additionally the blacklist may contain a blacklisting secret, such as a secret number or a key or a PIN. This secret may only known by the owner of the transaction unit. To prevent any fraud with intentionally blacklisting transaction units, which are not stolen or lost, the reporter of the request to insert a transaction device into the blacklist also needs to provide this secret. The blacklisting secret may be checked in the secure transaction unit and/or a central unit. The transaction unit and/or the central unit only initiates subsequent actions, if it verifies the secret.
The control means is further configured to automatically transmit all tokens that are currently stored in the storage means to an online hosted target secure transaction unit if the blacklist-status is fulfilled. The blacklist-status is fulfilled in a case in which this transaction unit is entered in the blacklist which means that this transaction unit is reported as being stolen or as being lost.
Currently stored tokens are all tokens that reside in the storage means at the time of receipt of the blacklist-status. Alternatively, currently stored tokens may be all tokens that—since the time of reporting that the transaction unit is lost or stolen—are owned by the transaction unit.
The transmitting occurs automatically. This means that it may occur without any user-interaction or user-input or user-acceptance. This may also mean that the transmitting of all the tokens occurs without undue delay, e.g. in case a theft recognizes that all tokens will be transferred from the transaction unit.
The automatic transmitting is also referred to as homecoming mechanism.
After transmitting all the tokens to the online hosted target secure transaction unit, the locally stored tokens are physically deleted from the storage unit.
An online hosted target secure transaction unit may be a software secure transaction unit, e.g. a secure wallet, that is hosted as a software application in the central unit, e.g. at a service provider unit. The service provider unit may be the issuer of the hardware secure transaction unit. The service provider unit may be the manager of the hardware secure transaction unit.
The online hosted target secure transaction unit may be an online representation of the hardware secure transaction unit, e.g. it may be owned by the same participant to which the hardware secure transaction unit is uniquely assigned.
The online hosted target secure transaction unit may be a secure transaction unit of the service provider unit itself, e.g. the manager and/or the issuer of the hardware secure transaction unit. The online hosted target secure transaction unit may be operated as an escrow transaction unit, which transfers the tokens to a (new) transaction unit of the owner of the blacklisted transaction unit.
With this aspect it is now possible that a lost or stolen secure hardware transaction unit does not necessarily mean that a financial damage occurs. Tokens that are stored in the secure hardware transaction unit.
The secure hardware transaction unit is now blacklisted—meaning it has the blacklist-status “fulfilled”. If a lost and blacklisted transaction unit eventually establishes an online communication, it transfers all tokens to an online secure transaction unit. This transfer will proceed automatically and without user approval.
In other words: If the transaction unit is lost or stolen (not destroyed), the transaction unit might eventually get online. In this case, the transaction unit is informed that it was put on a blacklist. This information triggers the transaction unit to send all the token (money) to a predefined transaction unit.
In a preferred embodiment, the blacklist-status is received as a command from the central unit, wherein based on the received command, the automatically transmitting is directly initiated. In such a case, the central unit already checked the blacklist and identified the blacklist-status and the transaction unit immediately starts the token transfer based on a dedicated command.
In an embodiment, the command further comprises information about the online target secure transaction unit to which all tokens are automatically transmitted. So, the central unit knows the address of the target online transaction unit and it triggers the transaction unit to send all the token (money) to this predefined transaction unit. Preferably however, the online target secure transaction unit is (pre-) stored in the transaction unit, e.g. as a data element predefined by the issuer or the owner of the transaction unit.
In a preferred embodiment, the blacklist-status is received as an information (e.g. as a data) from the central unit. In this case, the control means is further configured to check the information whether the blacklist-status is fulfilled. If the blacklist-status is fulfilled, the control means is further configured to generate a command to initiate the automatically transmitting. Upon receipt of the information at the transaction unit, the transaction unit initiate the transfer of token (homecoming mechanism) in case the secure transaction unit has a fulfilled blacklist-status.
Each transaction unit may automatically—upon online communication establishing—request the information about the blacklist-status.
This may be implemented as an additional security-step in the token transaction process. Upon online communication establishing, the transaction unit will immediately and always receive the information about its blacklist-status and/or it will look up the blacklist and initiate the automatic token transmittal in case this secure transaction unit identifies (checks) itself on the blacklist or the blacklist-status “fulfilled”.
The secure transaction unit further comprising information about the online target secure transaction unit to which all tokens are automatically transmitted, wherein prior the automatically transmitting, the control means is further configured to retrieving this information. E.g. the information is included as a predefined address within the secure transaction unit. Due to the high security level of the secure transaction unit, any manipulation to transfer the tokens can be avoided.
In a preferred embodiment, the secure transaction unit is uniquely assigned to a participant of the electronic transaction system. The online target secure transaction unit is a transaction unit that is assigned to the same participant. The online target secure transaction unit is preferably hosted at a service provider unit (e.g. as the central unit) within the electronic transaction system.
In a preferred embodiment, the secure transaction unit further comprises transceiver means for directly transferring of tokens with other secure transaction units of the electronic transaction system to cause an exchange of the one or more tokens between secure transaction units in the electronic transaction system. The transceiver means may be local communication means for short-range communication, such as NFC or Bluetooth. So, direct offline token transaction between two secure wallets (e.g. residing in secure elements), e.g. the secure wallet that initiates the token transfer (payer) and/or the secure wallet that receives a token (payee), is possible. There is no access needed or it is not possible to communicate with remote instances of the transaction system, such as a token register, a transaction register, a token issuing unit and/or a service provider unit, such as financial service provider (FSP) via classical internet or mobile communication means. The token transfer may then take place by local wireless communication means, such as Bluetooth, NFC, or any other suitable wireless communication protocol. The token transfer may also take place by contact-based communication means, such as USB, ISO 7816, or any other suitable contact-based communication protocol.
In a preferred embodiment, the secure transaction unit further comprises means for transmitting one or more registration requests to a token reference register of the electronic transaction system as the central unit, wherein each registration request comprises one or more token references, each token reference being uniquely assigned to a token in the electronic payment transaction system. Here, each token may comprise a monetary value and a private key of the token-individual key pair as token-individual token elements. One or more token references may comprise the monetary value of the assigned token and a public key corresponding to a private key of the token-individual key pair. So, the unique assignment between token and token reference is the token-individual key pair.
The control means of the secure transaction unit is further configured to generate one or more token references of a registration request based on modification commands (replacement requests) being processed by the secure transaction unit, the modification commands being preferably one or more of a switch-command, a merge-command and a split-command, wherein the modification commands are only performed for tokens having the same token-type information. For further details related to these modification commands it is referred to WO 2020/212 331 A1 and WO 2020/212 331 A1.
In a preferred embodiment, the control means are further configured to generate protocol data related to payment transactions performed between the secure transaction unit and other secure transaction units. The protocol data being sent to a protocol data register in the electronic payment transaction system as the central unit. The protocol data may be used for a surveillance of (payment) transactions within the electronic transaction system, wherein the protocol data and/or the registration requests are used for fraud detection. A comparison between protocol data and registration requests is made and based on a data reduction scheme, fraud may be detected. So, an efficient and anonymous payment system surveillance system can be achieved.
The protocol data is per se independent on the registration requests. This means, offline and online transaction may lead to a token reference register status that is not following the status of the payment system. Using the protocol data with the transaction unit group identifier enables to receive additional information that is more accurate than the token reference register status.
In another aspect there is provided a service provider unit as a central unit in an electronic transaction system.
The service provider may be a financial service provider unit. The financial service provider unit may be configured to issue and/or manage at least the one of a plurality of secure transaction units.
The service provider unit comprises one or more online hosted target transaction units (as described above) that comprise a storage means for storing one or more token, preferably upon receipt from a secure transaction unit as previously described.
The service provider unit comprises a service provider transaction unit that is configured to receive all tokens that are stored in a storage means of a secure transaction unit as discussed above.
In a preferred embodiment, the service provider unit may further comprise a blacklist-register for registering a blacklist-status of respective transaction units. The blacklist register may be a storage unit in which the blacklist resides. Here, the blacklist-register may be a part of the service provider unit.
In a preferred embodiment, the transaction units are registered based on a unique identifier of the transaction unit. The transaction units are preferably managed and/or issued by the service provider unit.
In another aspect there is provided an electronic transaction system that comprises a plurality of secure (hardware) transaction units as described above.
The electronic transaction system further comprises one or more service provider units as described above.
The electronic transaction system further comprises a central unit. In a preferred implementation, the central unit is one of the service provider units. The central unit is configured to establish an (the) online communication with one of the plurality of transaction units. The central unit is further configured to transmit a blacklist-status in response to the established online communication to the one of the plurality of transaction units.
In a preferred embodiment, the central unit is further configured to request the blacklist-status from a blacklist register of the electronic transaction system.
The blacklist register may be a centralized blacklist register within the electronic transaction system. So, each blacklist-status of transaction units is reported and protocolled in one register within the transaction system. Each entity of the transaction system should have access to the blacklist register to read out blacklist-status of individual transaction units.
The blacklist register may be a blacklist register of one or more service provider units issuing and/or managing the one of the plurality the secure transaction unit. In one implementation, each service provider unit hosts its own blacklist register in which only blacklist-status of transaction units are registered that are issued or managed by the service provider unit.
The central unit is further configured to upon receiving the blacklist-status from the blacklist register, generating, by means of a command-generator, a command for automatically transmitting all tokens that are currently stored in a storage means of the one of the plurality of transaction units to an online hosted target secure transaction unit, if the blacklist-status is fulfilled
Preferably, the command further comprises information about the online target secure transaction unit to which all tokens are automatically transmitted.
The central unit of the transaction unit is for instance a service provider unit providing one or more services for the one of the plurality of transaction units. The service(s) may be a payment transaction service or a digital asset management service or the like.
The central unit of the transaction unit is for instance a service provider unit issuing the one of the plurality of transaction units.
The central unit of the transaction unit is for instance a token issuer unit. This may be a central bank with a payment transaction system. The secure token issuer unit may comprise a minting unit configured to generate a new token to be issued in the electronic transaction system; and a melting unit configured to delete tokens to be deleted from the electronic transaction system.
The central unit of the transaction unit is for instance a blacklist-register. So, each online communication initiated by a transaction unit may be with a blacklist-register (first).
The central unit of the transaction unit is for instance a certificate revocation register. Here, certificates of transaction units that are revoked—e.g. due to a blacklist-status “fulfilled”—are registered and can be reviewed. It may be a second instance which verifies the blacklist-status of a transaction unit.
The central unit of the transaction unit is for instance one or more token registers for registering tokens in the electronic transaction system. The token reference register may comprise one or more storage units for storing token references for registering tokens in the electronic payment transaction system. Each stored token reference in the token reference register may comprise the monetary value of the token and a public key corresponding to the private key of the token-individual key pair. The token reference register may further comprise one or more verification units for verifying whether the token reference of a receive registration request is stored in the token reference register. Each token reference may be uniquely assigned to a token.
The central unit of the transaction unit is for instance one or more protocol data registers for storing protocol data of transactions performed between secure transaction units.
A blacklist-status may be changed upon request from a participant to which the one of the plurality of transaction units is uniquely assigned, wherein the blacklist-status is fulfilled, if the one of the plurality of transaction units is stolen or is lost.
In a further aspect there is provided a method for automatically transmitting of all token from a blacklisted secure transaction unit to an online hosted transaction unit by means as described above.
In the following, the invention or further embodiments and advantages of the invention are explained in more detail based on drawings, wherein the drawings describe only embodiments of the invention. Identical components in the drawings are given the same reference signs. Elements drawn with dashed lines are considered as optional elements.
The drawings are not to be regarded as true to scale, and individual elements of the drawings may be shown in exaggeratedly large or exaggeratedly simplified form.
The TU comprises a storage unit TSU. The TSU comprises one or more token. The tokens are stored in the TSU. The TU also comprises a control means CPU.
The system TS also comprises a central unit CU. The CU can be reached by the TU via online communication 30. Here, the online communication is an internet communication using TCP, IP, UDP, HTTP or HTTPS protocols. Any other suitable protocol can be used, too.
The system TS also comprises a blacklist register BL. In the BL, a blacklist is stored. The blacklist comprises a blacklist-status of each TU in the TS and so, the BL in this embodiment is a central BL of the TS. The BL is shown as an individual part of the TS. In other implementations, the BL is part of the CU.
The system TS also comprises a service provider unit SPU. The SPU may be a financial service provider FSP. The SPU may be the manager and/or issuer of the TU. The SPU comprises a target online transaction unit SPU-TU.
As shown with dashed lines, the CU, BL and SPU-TU may all be part of the SPU that then may represent the CU.
It is assumed that a participant lost the TU. In the TU, some token are physically stored. The token represent money and so, the participant reports the loss of TU at the BL in step 10. With the reporting 10, the participant provided the unique identifier wID.
In an alternative scenario, the participant reports the loss of TU at the SPU in step 10. The SPU as an issuer of the TU knows the participant. With the “know-your-costumer” approach, the SPU is able to register the loss in the BL in step 110.
The reporting 10 may be done via a web-portal. Upon reporting, the BL changes a blacklist-status to “fulfilled” which means that the TU is now blacklisted (considered as a stolen TU or lost TU).
In the following, a method for automatically transmitting tokens T is described according to
The TU establishes an online communication 30. This may be caused by a theft of the TU that wants to make an online transaction or wants to register tokens at a token reference register or wants to protocol a transaction. The TU may have to provide a unique identifier, such as wID, to establish the online communication 30.
The CU recognized the online communication in step 30 and immediately requests 40 a blacklist-status for the TU at the BL. The BL responses 50 the blacklist-status “fulfilled” to the CU.
In a first implementation, the CU receives the response in step 50 and provides it to a command-generator CO in step 51. The CO recognizes the blacklist-status “fulfilled” for that TU and generates a command for automatically transmitting all tokens from the TU to the online target SPU-TU. The address of the SPU-TU may be provided at the CU or the BL. In step 52, this command is provided to the TU. The TU receives the blacklist-status as the command in step 33. In this first implementation, upon receipt of the blacklist-status (as the command CO), the CPU automatically and directly initiates 151 the transfers all tokens from the TSU to the SPU-TU. The transfer is made in follow-up step 150. In an alternative of the first implementation, the Target-TU information is stored in the TU and upon receipt of the command in step 33, the CPU retrieves the information of the SPU-TU in step 153.
In a second implementation, the CU receives the blacklist-status-response in step 50 directly forwards it to the CPU of TU in step 33. The CPU checks the blacklist-status-response and provides it to a command-generator CO in step 152. The CO recognizes the blacklist-status “fulfilled” for that TU and generates a command for automatically transmitting all tokens from the TU to the online target SPU-TU. The address of the SPU-TU may be provided from the CU or the BL. Alternatively, the address of the SPU-TU is retrieved in step 153 from the TU itself. In this second implementation, the CPU initiates 151 the transfers all tokens from the TSU to the SPU-TU. The transfer is made in follow-up step 150.
As a result of both implementations, all tokens stored in the TSU are transferred to the SPU-TU.
In other words: If the participant loses his TU or it is stolen from him, tokens in the TSU are lost as well. In step 10, the TU is blacklisted, preferably at the SPU directly. If the
lost and blacklisted TU goes online in step 30, it receives in step 33 a “transfer all tokens to SPU-TU” command from the CU (or the SPU) that has checked the blacklist-status. Alternatively, the TU itself checks the blacklist and starts this transfer in step 150.
The SPU-TU is an online wallet and this is predefined in the TU or the CU for that participant. The respective online-wallet-ID may be prestored in the TU or the CU. The transfer 150 will proceed automatically without any user approval or user interaction.
The TU is blacklisted, e.g. entered in a list (“blacklist”) centrally at the BL or CU by means of the SPU or the CU. Alternatively, the blacklisting of the TU is made only at the SPU that issued the TU.
The SPU-TU-ID (online-wallet ID) is stored in the TU OR in the BL. The SPU-TU is the target to which all tokens T from the TSU of the TU are to be transferred (forcibly/automatically) as soon as the TU goes online in step 30.
If the blacklisted TU contacts a system component (i.e., CU or SPU or T-Reg or P-Reg), i.e., if the theft (participant) wants to execute an online transaction, retrieve (registry) data TR from the TS, or save (PROT) data to the TS.
The TS OR the TU checks the blacklist-status. If the blacklist-status is “not fulfilled”, everything remains in normal operation. If the blacklist-status is “fulfilled”, the automatic token transfer will be made in step 150 and the token are stored in the SPU-TU (target online wallet).
The SPU-TU is preferably an online wallet of the owner of the TU.
THE SPU-TU may alternatively be a TU of the TS, like the SPU or TU issuer. Tokens are received in step 150 and cached in a waiting period and only later credited/transferred to the participants (new) wallet.
The transaction system TS comprises a central unit layer CU-LAY in which a central unit CU is arranged. The TS further comprises a direct transaction layer TU-LAY in which a plurality of transaction units TU may be provided, as an example, two transaction units TU1 and TU2 are shown in
The transaction units TU of the transaction system TS are arranged to exchange 15 tokens T directly with each other. In the case of
Each token T can be modified, such as split, merged or switched, by applying modification-commands by each transaction unit TU. Each token T can be generated by a transaction unit TUI of a token issuer and can also be deleted. Each modification can be registered in a T-Reg (as part of the CU) by replacement requests (registration commands) RR.
A transaction unit TU comprises a storage means (vault) TSU as a token memory.
For each token T, a token reference TR can be stored in the token reference register T-Reg. The token reference TR of the token T can be viewed at any time in the register T-Reg of the transaction system TS.
This token reference TR can be sent to the token reference register T-Reg in form of a registration request RR (being generated in step 22), if necessary, together with a modification command regarding the token T.
This registration request RR is received in the token reference register T-Reg. After the registration request RR has been checked by the token reference register T-Reg, the token reference TR is stored in the token reference register T-Reg, whereby the token T is registered in the transaction system TS and an old token reference TR is deleted from the token reference register T-Reg.
This token reference TR are uniquely assigned to the token T. The TR is used to register the token T in the transaction system TS. The token reference TR are therefore the public representation of the token T from the transaction layer TU-LAY. Sole knowledge or possession of the token reference TR alone does not allow the token T to be transferred and is not equivalent to the TU1 being in possession of the token T. The token reference TR is used to prevent multiple spending attempts and checks whether token values have been generated in an improper manner. Therefore, the token reference TR and, if applicable, the history about the tokens T and the corresponding registration requests RR from TU(s) are stored in the token reference register T-Reg.
The tokens T are stored, for example, in a secure wallet, as the TU. A wallet may be set up as an application on a smartphone, smart card or payment terminal. The wallet is used to securely manage tokens T of the TU, generate token references TR, modify tokens T, and/or exchange tokens T. Wallets are used to communicate with the token reference register T-Reg, generate registration requests RR to the token reference register T-Reg, modify tokens T (switch, merge, split) and/or perform transaction of token T to another TU.
A transaction with a TU does not require a communication link to the token reference register T-Reg of the transaction system TS. The transaction system TS is set up to perform a transaction offline, i.e., without a communication link to the token reference register T-Reg. A corresponding registration of token T may therefore be temporally downstream of a transfer of token T to a TU.
The token reference register T-Reg is a unit of the transaction system TS and is either a central register or database of the transaction system TS or a decentralized register or database (DLT) of the transaction system TS.
The TU1 may be issued or operated by a service provider unit SPU. TU1 may generate 21 the TR by its CPU. The CPU generates the RR in step 22.
The token T may be transferred 15 from TU2 during a payment transaction. TU1 now generates a TR in step 21 as known from WO 2020/212 331 A1 and WO 2020/212 331 A1 and it is not further repeated here.
The payment transaction between TU1 and TU2 may also be protocolled with protocol data PROT. The PROT may include a wID of the TU1 and/or a wID of the TU2 and this PROT may be provided as PR (generated in step 24) to the P-Reg of the CU and may be stored there. The PROT may include a timestamp of the transaction of T between TU1 and TU2 and respective TR.
In the following, a method for automatically transmitting tokens T is described according to
The TU1 establishes an online communication 30. This may be caused by the TU1 that wants to register 31 tokens at the T-Reg or wants to protocol 32 the PR at the P-Reg.
The CU recognized the online communication in step 30 and immediately requests a blacklist-status for the TU at the BL in step 41 (if a RR is sent) or 42 (if a PR is sent). The BL responds the blacklist-status “fulfilled”.
The TU1 receives the blacklist-status-response in step 33. The CPU of TU1 checks the blacklist-status-response and generates a command for automatically transmitting all tokens from the TU1 to the online target SPU-TU. The address of the SPU-TU is prestored in the TU1 or may be provided by the BL. The CPU initiates the transfer of all tokens from the TSU to the SPU-TU in step 150 via the transceiver means M.
As a result of both implementations, all tokens stored in the TSU are transferred to the SPU-TU.
Optionally, a certificate of the TU is also revoked and entered in certificate revocation list, CRL, of a certificate revocation register CRR. The CRL entry at the CRR prevents transactions with other TU which need to check the CRR for an CRL-entry of that TU.
The online target wallet SPU-TU will ignore the CRL entry in the CRR, so deliberately executes this token transfer in step 150 despite of it.
In
In
These new tokens may be issued to the intermediate issuers, such as commercial banks SPU-TU. These tokens may be used in direct token exchange 15 with costumers of the intermediate issuers SPU. The token exchange 15 is also performed between TUs, e.g. between TU1 and TU2 as shown and described in
In
In
The PROT may be generated per each payment transaction in which T is transferred in the TU-LAY. The PROT may include one or more data fields. PROT are provided in one of the following formats:
The wID1 is a unique TU identifier of the TU1. The wID2 is a unique identifier of the TU2.
Instead of the wID, a hash function may be applied on the wID and only the resulting hash value may be inserted into the PROT.
In addition, a transaction number may be inserted in the PROT as well. One or more of the data fields of the PROT may be encrypted to increase the security within the TS.
Furthermore, T-Reg manages the storage location for the token references TR, shown here as database 1 as an example of a storage unit 1 in the token reference register T-Reg. As a representative example, the TR for the token T of the SPU-TU is entered in the database 1 upon replacement request 31.
If a token reference TR is not yet known in the token reference register T-Reg, it is added.
The commands CO used for RR can be modifications of an existing token T, for example “switch”, “split” or “merge” that are used in replacement requests 31. The commands “switch”, “merge” and “split” can be integrated into replacement requests (registration requests RR) to register a modification of a token T at the T-Reg.
The evaluation result of PR or PR and RR may be that certain TRs are TRs of the TU.
The evaluation result of PR or PR and RR may also be that there are no TRs or that TRs cannot be determined. In this case, P-Reg and/or a T-Reg would have to have suitable data for the evaluation, e.g. a TR specification and wallet ID in the PROT and/or the PROT and RR data set. P-Reg and/or a T-Reg optionally filter internally its data and then evaluates whether there are TRs using its data.
| Number | Date | Country | Kind |
|---|---|---|---|
| 23020336.6 | Jul 2023 | EP | regional |
