DE102021004023A1 - PROCEDURE FOR DIRECT TOKEN TRANSFER - Google Patents

Abstract

The invention relates to a method (100) for the direct transmission of tokens (T) in a token system (TS) between a subscriber unit (TE) and a machine unit (ME) for paying for use of a machine, each token (T) having at least one token value (v) as a token element, with the method steps: Splitting a token (T) of the subscriber unit (TE) into a first token part (T1) and a second token part (T2) by the subscriber unit (TE), with a token value (v ) of the token (T) is divided into a first token part value (v1) of the first token part (T1) and a second token part value (v2) of the second token part (T2); wherein the first token part (T1) comprises a plurality of minimum tokens (T _min ), each minimum token (T _min ) having a token minimum value (v _min ), a first minimum token (T _{min_1} ) from the subscriber unit (TE) to the machine unit ( ME) is sent; or wherein the first token part value (v1) is a multiple of a minimum token value (v _min ) and wherein the first token part (T1) is sent from the subscriber unit (TE) to the machine unit (ME). The method also includes a machine unit and a token system.

Description

TECHNICAL FIELD OF THE INVENTION

The invention relates to a method for directly transferring tokens from a subscriber unit to a machine unit for payment in a token system. The invention also relates to a token system. The invention also relates to a machine unit of a token system. The invention can be used in man-machine payment methods.

TECHNICAL BACKGROUND

In an old-fashioned man-machine payment system, a participant started a machine (e.g. a washing machine or a hot water shower in a common room, self-service salon or campsite, a children's ride, etc.) and paid for the use of a function/service of the machine with specially shaped tokens or with coins. These systems are inflexible, difficult to maintain, space-consuming (token or coin boxes) and usually the tokens that are specially purchased cannot be used anywhere else. If the token is lost/stolen, the participant is at a disadvantage.

In newer electronic man-machine payment systems, a participant acquires payment tokens in order to start machines offline, i.e. without a connection to the Internet, and to pay for the use of their performance (services).

As an "electronic purse", the money card, for example, enables a cashless electronic man-machine payment system without user identification, i.e. without PIN verification and without signature. The payment is made with a prepaid credit, which is stored on a chip card (the "money card"). A disadvantage of the money card is the lack of transparency, such as the lack of an overview of the expenses made and no knowledge of the remaining balance on the money card. The desired transparency can only be achieved with additional equipment such as a pocket card reader. Another disadvantage of the money card is the free (unconditional) transferability of the credit. The money card owner (=participant) is liable in the event of loss or damage, and dishonest finders can use up the credit on the money card without any obstacles. The operational area is limited to the territory of Germany. In addition, the money card is contact-based, making it more susceptible to wear and tear/malfunctions/vandalism and space-consuming (card reader with slot).

In the registration DE 10 2018 009 949 A1 Electronically independent coin elements of a digital strip card are provided as independent means of payment. In particular, when a partial strip is further reduced, the resulting data records grow enormously and the verification of authenticity becomes extensive.

In the WO 2020/212 337 A1 proposes a method for directly transmitting electronic coin data sets, eMD, in a payment method, in which a decentralized or central monitoring layer is provided to anonymously but securely register the coin data sets and the modifications thereof. Participants in this process can thus check the authenticity of the coin data sets. This method is computationally intensive and complex due to the central or decentralized monitoring authority and the necessary masking of the coin data records.

There are now a large number of different payment systems in human/machine communication, which are based on different technologies (blockchain, central data management, PKI structures) and with different system requirements (pay-per-use, micropayment, different denominations, different minimum payments). .

SUMMARY OF THE INVENTION

The invention is based on the object of creating a method for payment to a machine, in particular in the form of so-called small change payments (micropayments). Payment should be easy and cashless. A participant should remain anonymous, but the function or service used should be reliably paid for. Payment should be flexible across systems.

The object is achieved by the features described in the independent patent claims. Advantageous developments of the invention are specified in the dependent claims.

According to the invention, a method for the direct transmission of tokens in a token system between a subscriber unit and a machine unit for paying for use of the machine, each token having at least one token value as a token element, with the method steps: dividing a token of the subscriber unit into a first token part and in a second token part by the subscriber unit, for which purpose a token value of the token is divided into a first token part value of the first token part and a second token part value of the second token part; wherein the first token portion comprises a plurality of minimum tokens, each minimum token having a minimum token value, a first minimum token being sent from the subscriber unit to the machine unit; or wherein the first token portion value is a multiple of a minimum token value and wherein the first token portion is sent from the subscriber unit to the machine unit.

With this method, the flexibility in the transfer of tokens to machine units to pay for use of the machine is significantly increased.

The division of the token into the first token part, which includes a large number of minimum tokens, leads to memory and resource-saving payment for the use of the machine that is assigned to the machine unit. A large number of minimum tokens can thus be generated in reserve, regardless of a number of minimum tokens required for the actual use of the machine. From a token with a token value that is many times higher than the minimum token value in advance in the subscriber unit, many minimum tokens are divided during a continuous (uninterrupted) compartment process. The computing effort is lower than with a classic approach, in which a another minimum token would be split to pay for the use of the machine for a subsequent period of time.
Alternatively, dividing the token into the first token part, the first token value part of which is many times greater than a minimum token value, leads to overpayment (at first, more token value is paid than for the use of the machine (possibly per time unit, possibly per consumption unit, or per action) is necessary). A subscriber unit-machine unit communication is thus proposed which always maps a valid payment for the use of the machine for different token minimum values—which the subscriber unit now does not necessarily have to know. This alternative may require a response from the machine unit, for example to return change (change) to the subscriber unit.

In addition, it is no longer a system requirement to pay correctly right at the beginning, but the machine unit can compare the received token value with a minimum token value or a token value required for using the machine and send back the change. This system is therefore more flexible and user-friendly.

Direct transmission means a transmission process that can be operated completely offline. Neither the subscriber unit nor the machine unit requires a communication connection, for example the Internet, to an external server or service provider for the transmission of the token(s). In this token system, tokens can be transferred offline.

Modifications (offline) can be made to the tokens and/or the token parts and/or the minimum tokens of the token system. For example, splitting (SPLIT) to reduce a token value or connecting (MERGE) to increase a token value or switching (SWITCH) of token values to change the owner should be possible offline and without further control instances of the token system.

The token system can be self-contained. Thus only machine units of a certain type and/or a certain manufacturer and/or at a certain location and/or from a certain service provider could receive the tokens from a large number of subscriber units (number undetermined and unlimited). The tokens would only be transferrable within this closed token system.

The token system can be an open system. Thus machine units of different types and/or different manufacturers and/or different locations and/or different services could be offered ter receive the tokens from a large number of subscriber units (number indefinite and unlimited). The tokens can thus be used more flexibly.

According to the invention, before the token is transmitted, the token of the subscriber unit is modified, here in particular the splitting (SPLIT) of a token (or its token value). This modification to the token is described in detail below. This splitting of the token allows a token value present on the subscriber unit to be reduced. This secures the payment for use by not transmitting token values that are too large to the machine unit. With the division, the token value of the token is reduced to an approximately estimable range of token value to be paid.

This splitting is particularly advantageous if the subscriber unit—possibly presuming a token system—only has a single token whose token value is always to be updated with a splitting/connecting modification directly before/after a token is sent/received. Thus, the subscriber unit's token may have an immensely large token value for the planned payment for the use of the machine. A possibly unknown machine unit should not receive this immensely large token value, so splitting the token value increases security.

A minimum token is a token that has a minimum token value.

The minimum token value may be the lowest token value that can be received or accepted by a machine unit. This minimum token value represents a monetary hurdle for using the machine. Tokens with a token value below the minimum token value cannot be received by the machine unit or are not accepted by the machine unit. A token minimum value as the smallest transferrable token value between subscriber unit and machine unit reduces the number of tokens to be transferred and thus makes payment for the use of the machine more efficient.

Preferably, the minimum token value represents a token value required by the machine unit to start usage and/or to continue usage

The minimum token value may be machine unit type specific. Thus, a first type of machine unit may have a first minimum token value and a second type of machine unit may have a second minimum token value. The first minimum token value is different from the second minimum token value. There can be many different minimum token values in a token system.

The first partial token value can be a multiple of the minimum token value. A multiple can be an integer or a rational multiple. The multiple can be two, four, ten, twenty, fifty or a hundred times or more. With this token value, which is significantly higher than the minimum token value, the subscriber unit signals its trust in the machine unit. It also allows the subscriber unit to generously share the token value without knowledge of a minimum token value or multiples thereof and still pay for the use of the machine. Time-consuming querying of a minimum token value before payment can be dispensed with. There is no need for time-consuming testing of different minimum token values.

In this case (the token part value can be many times greater than the minimum token value), the method preferably comprises the further steps: Splitting the first token part into a third token part and a fourth token part by the machine unit, with the first token part value of the first token part being divided into one third token part value of the third token part and a fourth token part value of the fourth token part; and sending, from the machine unit to the subscriber unit, the third token portion, the third token portion value of the third token portion being the difference between the first token portion value and a token value necessary to pay for usage. The third token value is thus the change on the (too large) token value, the responsibility for correct payment processing is thus shifted from the subscriber unit to the machine unit.

In one embodiment, after the third token part has been received in the subscriber unit, the third token part is combined with the second token part to form a fifth token part. Thus, when a token is received from the machine unit, the received token is linked (=modified) with the token remaining in the subscriber unit in order to combine the two token values. As a result, only the fifth token part is stored and used in the subscriber unit. This fifth token part is suitable for further payments at the machine unit or another machine unit (of the token system) promptly and without further verification/validation.

In one embodiment, the first token part in the machine unit is connected to the fourth token part to form a machine token. This machine token is suitable for further (re)payments from the machine unit promptly and without further verification/validation.

Prior to the splitting step, a mode of splitting may be selected at the subscriber unit, a first mode specifying that the first token part value is a multiple greater than the minimum token value and a second mode specifying that the first token part value is the plurality covered by minimum tokens. The selection may be subscriber-driven by presenting a selection menu to the subscriber to select overpay (first mode) or pay with minimum tokens (second mode).

The first mode or the second mode can also be selected automatically by the subscriber unit based on the token value required for payment and/or based on a machine unit property or based on a subscriber unit property.

The mode can be selected if a predefined token value limit or a number of tokens to be transmitted is exceeded.

A subscriber unit property may be a data link property (data transmission speed), or a data storage size, or the property of not providing minimum tokens.

A machine unit property may be a data link property (data transmission speed), or a data storage size, or the property of not providing change.

With this, the subscriber unit can specify a mode, whether overpayment or payment with minimum tokens should be selected.

Before the splitting step, a machine-readable code of the machine unit can be read by the subscriber unit. The code is, for example, a barcode, a QR code, an RFID tag or an NFC tag. The subscriber unit includes a relevant reading device, for example a camera, a scanner, or an RFID/NFC reader.

The code of the machine unit can include identification data, for example an identifier, an ID, a type designation. The identification data can be machine-unit-specific and, for example, have only been assigned once in the token system. Before the sending step, this read out identification data can be linked to the first token part (concatenation). After the sending step, the received identification data can be compared with identification data of the machine unit, with the first token part being validated if the identification data match. In this way, the transmission is machine-unit-personalized and it is made more difficult for a fraudster to use the machine-unit service without payment.

In addition or as an alternative, the code of the machine unit can be used to obtain a public part of a key pair that is preferably machine unit-specific. The key pair is, for example, a PK1 key pair of an asymmetric cryptosystem. Before the sending step, the first token part can be encrypted with the public part of the key pair from the subscriber unit. After the sending step, the received encrypted first token part can be decrypted with a private key part of the key pair. In this way, the transmission is cryptographically secured and it is made more difficult for a fraudster to use the service of the machine unit without corresponding payment.

The code of the machine can also be used to initially start the machine (separated from the payment process) by the subscriber unit.

In any case, the code (as an ID, key or certificate) increases the effort for a fraudster who would have to change both the code and the machine unit.

In the splitting step, the token of the subscriber unit can also be split at least into a sixth token part. The first partial token value is, for example, a multiple of the required token value. A sixth token part value of the sixth token part can be many times smaller than the required token value, with the sixth token part first being sent from the subscriber unit to the machine unit before the sending step.

A multiple can be an integer or a rational multiple. The multiple can be two, four, ten, twenty, fifty or a hundred times or more. With this token value (micropayment=micropayment), which is significantly lower than the required token value, the subscriber unit tests the operability (and correct selection) of the machine unit before the (too large) first partial token value is sent.

In the splitting step, the token can at least also be split into a seventh token part, with a seventh token part value of the seventh token part also being many times smaller than the required token value, whereby before the sending of the first token part but after the sending of the sixth token part, the seventh token part is sent from the subscriber unit to the machine unit. In this way, two micropayments with a comparatively small monetary value would be transmitted to the machine unit in order to test the operability (and correct selection) of the machine unit.

In one embodiment, after sending the first minimum token, the method can further include: sending, from the machine unit, to the subscriber unit, an acknowledgment of the receipt of the first minimum token and preferably sending a request to send another minimum token. The machine unit would then confirm receipt of the first minimum token (as an indication that the transmission has worked) and, if necessary, request further minimum tokens from the subscriber unit to pay for the (further) use of the machine. In that case, the subscriber unit would not have to split any further minimum tokens and uses the number of minimum tokens generated in the splitting step.

The first token part value of the first token part preferably corresponds to an integer multiple of a minimum token value. In order to avoid the need for a separate splitting step for each micropayment, an integer multiple (e.g. 20, 50 or 100) of a smallest payment unit (the minimum token value) would now be split up in the splitting step. By choosing an integer multiple, no residual token is generated that could be unusable for the payment process (because the machine unit would not accept this residual token because the token value was too low (less than the minimum token value). In one embodiment, only one minimum token can be sent per micropayment.

In at least one second transmission step immediately following the transmission step, in the machine unit, a second minimum token can be received by the subscriber unit. Thus, one micro-payment (at the level of the minimum token value) would be made after the other as long as the machine was used (pay-per-use) and the service would end when the token transmission was stopped.

Preferably, a number of minimum tokens of the first token part value that have not been sent are connected to form a residual token value of a residual token part, with this residual token part being more preferably connected to the second token part value in the subscriber unit.
A modification to the token can be carried out offline, in particular the splitting (SPLIT) of a token (or its token value) or the connection (MERGE) of at least two tokens (or their token values) or the switching (SWITCH) of the token from a subscriber unit to another subscriber unit or to a machine unit. These modifications to the tokens are described in detail below.

Before the splitting step, the machine-readable code of the machine unit can be read out by the subscriber unit in order to obtain minimum token value information that is preferably typical of machine units. This minimum token value information can be used in the subscriber unit to obtain the number of minimum tokens.

A minimum denomination of a token value can be a tenth, a hundredth or a thousandth of a minimum denomination (1 cent, 1 euro, 1 dollar) of a (physical, real) currency. This sub-coding of the minimum denomination may allow for more meaningful micropayment settlements, in particular if electricity or water usage is to be paid for and the machine unit is, for example, part of an electricity or water meter etc.

A token is an electronic record of the token system that can be directly exchanged between the subscriber unit and the machine unit. Knowing the token, the receiving machine entity is in possession of the token value that the token represents. With the exchange, the token automatically changes hands. A token - a record of data that is transferrable independently of a transaction topology, such as "Bitcoin", "Ethereum" or "Neo" blockchain topologies - can be transmitted directly from the participant unit to the machine unit without any intervening units.

Each token in the token system is a data record comprising at least one token element. A first token element of each token of the transaction system is a token value, for example an asset, an asset, an economic good and/or an amount of money.

In addition, a second token element can be provided in each token. The second token element is a private part of a token-specific key pair. This private part is a secret in the token system and is not published anywhere and must not be used more than once. The generation of the private part must not be predictable. This private part can be a random number. The random number is preferably the result of a real random number generator.

The token can be formed from the token value (first token element) and the private part. This formation is preferably the concatenation of these two token elements. Any other type of linking of these two token elements is not ruled out according to the invention and includes, for example, adding them one after the other, incorporating them into a TLV data structure and/or logically linking them.

The token differs from a data record for classic data exchange or data transfer because, for example, a classic data exchange takes place on the basis of a question-and-answer principle or on intercommunication between the data exchange partners. A token, on the other hand, is unique and unique in the transaction system. The token is part of a security concept that includes signatures or cryptographic encryption, for example. A token contains all data elements that are required for a receiving machine unit with regard to verification, authentication and forwarding of the token to another subscriber unit or a token collection unit.

The owner (subscriber unit or machine unit) of a token can transfer this token. So owning the token is tantamount to owning the value that the token represents.

Each token in the token system can have a token reference associated with it. This assignment is one-to-one, that is, exactly one token reference is assigned to a token and exactly one token is assigned to each token reference. The token reference is a public data record that is stored in a memory unit of a token reference register of the transaction system so that it can be checked for each subscriber unit. This complicates the token system in the case of micropayments, so it is preferable to register only tokens from completed payment transactions in the token reference register (if at all).

Both the token and the token reference are unique. Due to the one-to-one assignment, there is a 1-to-1 relationship between the token and the token reference. Each token reference in the token system is a record comprising at least two token reference elements.

A first token reference element of each token reference is the token value of the token uniquely associated with the token reference. The token value of the token is therefore identical to the token value of the assigned token reference. For example, the token value of the token reference is a copy of the token value of the associated token. A second token element of each token reference of the token system is a public part of the token-specific key pair. Together with the private part of the token, this public part of the token reference forms the token-specific key pair. The public part is obtained by applying a cryptographic function to the private part.

This cryptographic function is a one-way function. This cryptographic function is therefore a mathematical function that is “easily” calculable in terms of complexity theory, but “difficult” to practically impossible to reverse. Here, a one-way function is also referred to as a function to which hitherto no reversal that can be carried out in a reasonable time and with reasonable effort is known. Preferably, a one-way function is used that operates on a group where the discrete logarithm problem is difficult to solve, such as B. a cryptographic method analogous to an elliptic curve encryption, ECC for short, from a private key of a corresponding cryptographic method. The reverse function, ie the generation of a token (or part of the electronic coin data record) from a token reference, is very time-consuming.

The (mere) knowledge or possession of a token reference does not entitle to use/transfer/issue the token value (token reference element). This represents an essential difference between the token reference and the token and is a core of the present invention.

After applying the cryptographic function to the private part of the token-specific key pair, the public part of the token-specific key pair is obtained as the second token reference element.

The token reference is formed from the token value (first token reference element) and the public part. This formation is preferably the concatenation of these two token reference elements. Any other type of linking of these two token reference elements is not ruled out according to the invention and includes, for example, adding them one after the other, incorporating them into a TLV data structure and/or logically linking them.

A token reference can preferably be generated by an electronic purse (=wallet) of a subscriber unit. To do this, the subscriber unit must have knowledge of the token with its token elements. The token reference can be generated by an electronic purse of a subscriber unit wishing to send the token. Alternatively, the token reference can be generated by an electronic purse of a subscriber unit that has received the token.

The use of a token reference is not comparable to the use of subscriber unit addresses in a blockchain-based transaction system, since no subscriber unit addresses are used in the token reference register according to the invention in order to prevent the tokens from being traced.

The received token reference is stored in a storage unit of the token reference register. With the storage, the token uniquely assigned to the received token reference is registered in the token system.

To generate the token reference, each further token reference element can be added by a concatenation with the first and/or second token reference element.

In one embodiment, the registration request relates to a splitting of a token and the registration request preferably has a token reference for the token to be split and a token reference for each of the (at least two) split tokens. The token references contained in the registration request can be linked together (concatenation). The division (= split) is a modification option on a token, with which a token value of a token can be divided into at least two (smaller) token values. This makes it possible to reduce the token value and to react to a transaction request with a more precise token value. This invalidates the split token and the (at least two) split tokens are registered in the token reference register to become verifiable in the token system.

As an alternative or in addition, it is provided for the splitting that the token value of the token to be split is split into at least a first token value and a second token value. The split can be done symmetrically, so the split token values are equal. The splitting can be done asymmetrically, so that the split token values are of different sizes.

Alternatively or additionally, the splitting step provides: generation of a new private part of a token-specific key pair for the first token part; applying a cryptographic function to obtain a corresponding public part of the token-specific key pair for the first token part; generating a new private part of a token-specific key pair for the second token part; applying a cryptographic function to obtain a corresponding public part of the token-specific key pair for the second token part; dividing the token value into the first part token value and the second part token value, noting that the sum of the first part token value and the second token split value corresponds to the token value of the token to be split; generating a token reference for the first token part, comprising the first token part value and the public part of the token-specific key pair of the first token part; generating a token reference for the second token part, comprising the second token part value and the public part of the token-specific key pair of the second token part; and creating the registration request using the token reference of the token, the token reference for the first token part, and the token reference for the second token part.

In one embodiment, the registration request relates to switching a token, and the registration request preferably has a token reference for the token to be switched. Token switching is a modification of the token. The token references contained in the registration request can be linked together (concatenation). If a token is transmitted directly, the receiving unit can have the received token (partial) value re-registered. This registers the switchover in the token reference register.

When transferring a token between two subscriber units or between a subscriber unit and the machine unit, these two units have knowledge of the token at the same time. In order to prevent the sending subscriber unit from also using the token in another (third) unit (so-called multiple issuance of the token), the transmitted token is preferably switched over from the subscriber unit to the second unit. The switching can preferably take place automatically upon receipt of a token in the unit.

As an alternative or in addition, the following is provided when switching over: generating a new private part of a token-specific key pair; applying a cryptographic function to obtain a corresponding public part of the token-specific key pair; Creation of the registration request using the token reference for the token to be switched and the public part of the token-specific key pair for the switched token. The token value of the token to be toggled is the same as the token value of the toggled token. Accordingly, when switching over, a token with the same token value but a new private part is registered in the token reference register.

In one embodiment, the registration request relates to the connection of at least two tokens, and the registration request preferably has a token reference for the connected token and a token reference for each token to be connected. The token references contained in the registration request can be linked together (concatenation). The connection (= MERGE) is a modification of the token, with which two token values are connected to each other, i.e. linked. This makes it possible to merge two token values into one token value in order to react to a transaction request with an exact token value. The tokens to be linked become invalid and the linked token is registered in the token reference register in order to be verifiable in the transaction system.

As an alternative or in addition, the following is provided during the connection: generation of a new private part of a token-specific key pair; applying a cryptographic function to obtain a corresponding public portion of the token-unique key pair for the associated token; calculating the token value for the connected token by forming the sum of the respective token values of the at least two tokens to be connected; generating a token reference for the linked token comprising the calculated token value and the public part of the token individual key pair for the linked token; and creating the registration request using each token reference of the tokens to be connected and the token reference for the connected token.

A participant's registration request only replaces one (or more) already registered token reference(s) with one (or more) token reference(s) to be registered in the token reference register without affecting the value. The total of the token values (valid token) in the token reference register remains unchanged.

In one embodiment, a first registration or deregistration request is sent by a token issuer, the first registration request relating to the creation of a token or the deletion of a token. Only the token issuer can thus change the total value of the tokens registered in the token reference register.

A token issuer, in contrast to a subscriber unit, is a privileged entity in the transaction system through which tokens can be created and deleted. A subscriber unit cannot create or delete a token, it can modify tokens (switch, split, connect).

The token is stored in a token store that the subscriber unit has exclusive access to. This token memory can have a large number of tokens, for example the large number of tokens can be stored in a data memory of the subscriber unit. For example, the data store can be internal, external, or virtual. In one embodiment, a “connection” can take place automatically when a token is received, so that preferably only one (or a specific number of) tokens are stored in the subscriber unit.

The subscriber unit can be, for example, a mobile terminal such as a smartphone, a tablet computer, a computer or a machine. The subscriber unit can be a smart card, which in particular is also installed ready for operation in a terminal.

The data memory is, for example, a wallet memory of an electronic purse (wallet). The electronic purse is, for example, a software application that is stored in an executable manner on a subscriber unit. The electronic purse (wallet) can enable the subscriber unit to participate in the transaction system. Thus, the electronic purse can generate a registration request to register a token in a token reference register. In addition, the electronic purse can make modifications (switching, connecting, splitting) to a token and generate any registration requests that may be necessary and send them to the token reference register. In addition, the electronic purse can transfer tokens to another purse (in a different subscriber unit).

In addition, the subscriber unit has means of access to a token memory and/or the subscriber unit has a token memory, at least one token of the subscriber unit with the sequence of registration requests being stored in the token memory.

In addition, the subscriber unit has a computing unit that is set up to carry out the method described above. The modification of tokens includes in particular the splitting of tokens, the joining of tokens and/or the switching of tokens according to the type described above.

The subscriber unit can be set up in such a way that only one token is stored in its token memory. This token is split (SPLIT) for direct transactions to produce a token value corresponding to the desired token transfer to the machine unit. When tokens are received in the subscriber unit, the received token is promptly merged (MERGE) with the token of the token memory.

In order to transmit a token/token part to the machine unit, this token of the token memory can accordingly be divided (SPLIT), in which case a registration request can also be generated for this purpose.

Upon receiving a token/token part from the machine unit, the received token is linked to the token in the token memory by the subscriber unit, for which purpose a registration request can also be generated. The registration request preferably has a token reference for the linked token and a token reference for each token to be linked.

The machine unit advantageously includes a certificate which confirms the ID of the machine unit, the public key (of the key pair) of the machine unit and/or an attribute, in particular group membership, of the machine unit. The subscriber unit can use the certificate to check the ID of the machine unit, the public key of the machine unit and/or the attribute, in particular the group membership, of the machine unit (before the token is transmitted).

In the present case, a subscriber unit can be a secure element that has secured access to tokens in a token memory. The secure element is installed ready for operation in a mobile terminal, for example. The secure element and/or the terminal have a special computer program product (electronic purse, wallet), in particular in the form of a secure runtime environment within an operating system of a terminal, English Trusted Execution Environments, TEE, stored on a data memory, for example a mobile terminal such as a smartphone, Laptop, etc. Alternatively, the secure element is designed, for example, as special hardware, in particular in the form of a secure hardware platform module, English Trusted Platform Module, TPM, or as an embedded security module, eUICC, eSIM. The secure element provides a trusted environment.

The advantage of such subscriber units is that a subscriber usually authenticates and identifies himself before operating the subscriber unit. This means that if the subscriber unit is lost - in contrast to a money card or a token - the finder cannot use the token. The token system is therefore more secure per se than conventional methods.

The token transfer is contactless, so that no additional space for a card reader/token slot needs to be provided in the machine unit. Contactless interfaces can be easily integrated on the circuit boards of the machine unit and reduce the space required for use in the token system.

A machine unit is a unit or component of a machine. The machine unit can be an integral part of the machine. The machine unit can be connected or linked to the machine mechanically and/or physically and/or electrically.

In the present case, a machine unit can be a secure element that has secure access to tokens in a token memory and that is installed in the machine ready for operation, for example. The secure element and/or the machine have a special computer program product (electronic purse, wallet), in particular in the form of a secure runtime environment within an operating system of a terminal device, English Trusted Execution Environments, TEE, stored on a data memory, for example the machine.

A machine unit is preferably assigned to a machine, so that there is an unambiguous or even unambiguous association from machine to machine unit.

Alternatively, it is possible for more than one machine unit to be assigned to a machine, for example in order to be able to pay for different uses of the machine (for example electricity consumption and water consumption) separately from one another.

The machine can be used by a participant in the token system or offers a service. To use the machine, tokens must be transferred between the subscriber unit and the machine unit, thereby paying for use of the machine.

The machine can be a vending machine or household appliance, such as a washing machine, dishwasher, hair dryer, coffee maker, parking meter, etc. The machine can be used before, after and/or during the transmission of tokens to the machine unit(s) connected to the machine.

The machine may be an Internet of Things, IOT, device. The IOT device can be a switch, socket, plug, relay board and/or valve. The invention enables usage-based payments for electrical devices or resources such as electricity, water and gas connected to the IOT device. A cost-effective and time-efficient purchase of even small amounts of electricity, water or gas can thus take place before, after and/or during the transmission of tokens to the machine unit(s) connected to the IOT device.

The machine can be a vehicle, such as an e-bike, electric scooter, car, e-car, or a ride (kids' ride). The use of the vehicle or the amusement ride before, after and/or during the transfer of tokens to the machine unit(s) connected to the vehicle or amusement ride can take place in this way.

The machine can be an industrial application, such as a robot, robotic arm, production line, sorting machine, packaging machine, etc. The industrial application can be used before, after and/or during the transmission of tokens to the machine unit(s) connected to the industrial application.

The machine can be an access barrier, such as a barrier, locker, barrier, lock, etc. The one-off or time-dependent opening/closing of the access block (access to a building or site, opening a locker, access to toilets, access to workplaces, access to accommodation (holiday apartment, hotel)) before, after and/or during the transfer of tokens a machine unit connected to the access barrier can be done in this way.

The machine can be a supply system, such as a gas station, e-charging station, gas filling system. The supply good can be obtained as a use (petrol, diesel, electricity, natural gas, hydrogen, liquid gas) before, after and/or during the transfer of tokens to the machine unit connected to the supply system.

Using the machine can also include activating or starting the machine before, after and/or during the transfer of tokens.

Machine usage can be time-based (paying for machine or resource usage in time units, such as second, minute, hour, day, week, month), consumption-based (paying for machine or resource usage in quantity units, such as liters, kilowatt hours, etc.) and /or action-based (paying for machine or resource use by number of uses) and payment can then be time-based, consumption-based and/or action-based.

The machine may already have been used before the tokens were transferred (subsequent payment).

The use of the machine can be paid for in advance by transferring the tokens (advance payment).

The tokens can be transferred to pay for use of the machine that has not yet ended.

The tokens can be transferred for one-time use of the machine. Alternatively, the tokens can be transferred for the continuous use of the machine.

In a further aspect, a machine unit in a token system is set up to be used in a previously described method. The machine unit comprises an interface arranged to receive tokens from subscriber units and to send tokens to subscriber units; an access means for accessing a token memory or a token memory, wherein at least one token from a subscriber unit can be stored in the token memory; and a computing unit configured to split and combine received tokens.

The machine unit preferably further comprises a machine-readable code. The code includes identity data of the machine unit; and/or a public key part of a machine-specific key pair, the private key part being stored in a memory unit of the machine unit; and/or minimum token value information.

The machine unit can be set up to transfer all tokens from the token memory to a token collection unit. The token collecting unit has, for example, a cloud memory or a memory element in which all tokens from the token memory of the machine unit are transferred at once. This corresponds to the service provider collecting the tokens. This collection can take place automatically in predefined periods of time or when a maximum token value is reached (when the sum of all token values in the machine unit) or when a transmission number is reached (e.g. one hundred token transmissions to the machine unit). Cryptographic keys can be provided for this collection and an identification/authentication of the token collection unit at the machine unit and/or vice versa.

In particularly preferred configurations, the token system is a central bank token system. The Central Bank is the issuer of the tokens and the Token Reference Registry is a Central Bank token reference registry. Preferably, the token reference register is an anonymous token reference register. A separate transaction register is optionally provided, in which executed transactions are registered, in particular at least with the transaction amount and the two transaction partners per transaction.

In one aspect, a token system comprises: at least one machine unit, preferably a plurality of machine units of the same type; a plurality of subscriber units each arranged to transmit tokens directly with a machine unit according to the method described above; a token collection unit configured to receive tokens from a token store of the at least one machine unit; and preferably an (anonymous) token reference register set up for Registration of unique token references to the tokens, and optionally a trade repository for registering executed transactions.

character list

• 1 zeigt ein Ausführungsbeispiel eines Tokensystems TS;
• 2a-c zeigen Ausführungsbeispiele für Maschineneinheiten;
• 3 zeigt ein Ausführungsbeispiel eines erfindungsgemäßen Verfahrens 100;
• 4 zeigt ein Ausführungsbeispiel eines Aufteilen-Schritts 104;
• 5 zeigt ein Ausführungsbeispiel eines Verbinden-Schritts 107; und
• 6 zeigt ein Ausführungsbeispiel eines Umschalten-Schritts.

The invention and further embodiments and advantages of the invention are explained in more detail below with reference to figures, with the figures merely describing exemplary embodiments of the invention. Identical components in the figures are provided with the same reference symbols. The figures are not to be regarded as true to scale; individual elements of the figures may be exaggerated in size or exaggeratedly simplified.

• 1 shows an embodiment of a token system TS;
• 2a-c show exemplary embodiments of machine units;
• 3 shows an embodiment of a method 100 according to the invention;
• 4 Figure 10 shows one embodiment of a splitting step 104;
• 5 Figure 10 shows an embodiment of a connect step 107; and
• 6 Figure 12 shows an embodiment of a switching step.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

1 shows an embodiment of a token system TS according to the invention. The token system TS includes a direct transaction layer in which a large number of subscriber units TE and machine units ME can be provided, a subscriber unit TE and a machine unit ME are shown as representatives. The token system TS can be part of a payment system BS, in which a token reference register TRR and a token issuer TH are also provided. A token issuer TH can be a central bank, for example, the token reference register TRR is then a token reference register of the central bank and the token system is a central bank token system. The token system TS can be equipped without a token reference register TRR and without a token issuer TH; the tokens T of one of the units TE, ME are possibly introduced into the token system TS.

The subscriber unit TE and the machine unit ME are set up to exchange tokens T or token parts T1, T3 or minimum token T _min directly with one another. In the case of 1 are the tokens payment tokens, also known as digital coins. A token T may have been generated by the token issuer TH. Each token T can be modified by each subscriber unit TE and each machine unit ME, i.e. divided, connected or switched (see 4 until 6 ).

A token T can be uniquely represented in the token system TS by a token value v and a random number r as token elements. The token value v can be specified in a value range from 1 to 2 ³¹ -1. The random number r can be a number in the range from 0 to 2 ²⁵⁶ -1, ie the order of an elliptic curve, for example secp256r1.

The random number r is a private part of a token-specific key pair. The random number r is unique and secret in the transaction system TS and must not be published or reused. The generation of the random number r must be unpredictable.

For example, the token value v is a 32-bit token element of type integer. For example, the random number r is a 32-byte integer token element. A subscriber unit TE has exclusive access to this token memory or includes this token memory in a data memory of the subscriber unit TE.

A token can be stored as a TLV-encoded data record in a token memory and then has a unique tag and length information, for example in the following format. Surname day (hex) length token value v random number r TLV encoded token 42 1 byte 4 bytes 32 bytes

• 42 24 00 00 40 00 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E
• 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F

und wird wie folgt interpretiert:

• „42“ ist der Tag zur Identifizierung des TLV-kodierten Tokens T;
• „24“ zeigt die Länge an, hier also, dass es sich um einen 36 Byte großen Datensatz handelt;
• „00 00 40 00“ ist der Tokenwert (integer) v = 16384 und beträgt demnach € 163,84;
• „00 01 02 03 04 05 06 07 08 09 ... 1D 1E 1F“ ist die Zufallszahl r als integer.

An example of a TLV encoded token T in hexadecimal form is shown below:

• 42 24 00 00 40 00 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E
• 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F

and is interpreted as follows:

• "42" is the tag identifying the TLV-encoded token T;
• "24" indicates the length, in this case a 36-byte data record;
• "00 00 40 00" is the token value (integer) v = 16384 and is therefore € 163.84;
• "00 01 02 03 04 05 06 07 08 09 ... 1D 1E 1F" is the random number r as an integer.

A token reference TR can be stored for each token T in the token reference register TRR. However, this is not absolutely necessary for this invention, but is nevertheless mentioned here for compatibility with the payment system BS. The token reference TR includes the token value v of the assigned token T and a public part R of the token-specific key pair. The token reference TR of the token T can be viewed at any time in the register TRR of the transaction system TS. The token value v of a token T is thus revealed by the token reference register TRR.

The public part R of the token-specific key pair is generated by applying a cryptographic function to the private part r of the token-specific key pair. This function is difficult to reverse and thus gives the TS transaction system the necessary security. R=r*G applies, where G can be, for example, a global parameter of the transaction system TS, for example a generator point of an elliptical curve, here the secp256r1 curve.

The token reference TR is then formed by the token value v of the token and the public part R of the key pair. The token reference TR is therefore the link or concatenation of the token value v and the public part R.

This token reference TR can be sent to the token reference register TRR as a registration request RA, possibly together with a command relating to the token T.

In addition, the registration request RA can be signed with the private part r of the token-specific key pair. Signing makes it possible to verify whether the sender of the token reference TR was in possession of the token T, which further increases security in the transaction system TS.

The signed registration request RA _sig is stored in the subscriber unit as a so-called PROOF, for example in the following format: Type day (hex) length Data PROOF 4A N bytes

• 4A 81 8F 03 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21
• 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36
• 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B
• 4C 4D 4E 4F 50 51 52 53 54 55 56 30 46 11 12 13 14 15 16 17 18
• 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D
• 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42
• 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56

und wird wie folgt interpretiert (siehe auch 8 zur Struktur einer Umschalte-Registrieranfrage):

• „4A“ ist der Tag zur Identifizierung des TLV-Proof RA_{sig_Th};
• „81 8F“ zeigt die Länge an;
• „03“ zeig an, dass es sich um eine Umschalte (=SWITCH) Registrieranfrage handelt;
• „11 12 13 14“ ist der Tokenwert v_g;
• „15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35“ ist der öffentliche Teil R_g;
• „36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56“ ist der öffentliche Teil R_h;
• „30 46 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56“ ist die Signatur als X690-Sequenz.

An example of a PROOF (=RA _sig ) in hexadecimal form is shown below:

• 4A 81 8F 03 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21
• 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36
• 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B
• 4C 4D 4E 4F 50 51 52 53 54 55 56 30 46 11 12 13 14 15 16 17 18
• 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D
• 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42
• 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56

and is interpreted as follows (see also 8th on the structure of a switch registration request):

• "4A" is the tag identifying the TLV proof RA _{sig_Th} ;
• "81 8F" indicates the length;
• "03" indicates that it is a switch (=SWITCH) registration request;
• "11 12 13 14" is the token value v _g ;
• "15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35" is the public part R _g ;
• "36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56" is the public part R _h ;
• "30 46 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 3B 393 3C 38 3E 3F 393 3C 38 3E 3D 393 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56" is the signature as X690 sequence.

This registration request RA can be sent to the token reference register TRR. This registration request RA is received in the token reference register TRR. After the registration request RA has been checked by the token reference register TRR, the token reference TR is stored in the token reference register TRR, as a result of which the token T is registered in the transaction system TS.

The token reference TR is uniquely assigned to the token T and is used to register the token T in the payment system BS. The token reference TR is therefore the public representation of the token T. Mere knowledge or possession of the token reference TR does not allow the token T to be transmitted and does not mean that the TE is in possession of the token T. The token reference TR is used to prevent multiple attempts to issue the token T and checks whether token values v were generated in an impermissible manner. Therefore, the token reference TR and possibly the history of the token T and the corresponding registration requests RA from subscriber units TE are stored in the token reference register TRR.

The tokens T are stored, for example, in token memories or electronic purses, so-called wallets, of a subscriber unit TE. These wallets are, for example, software applications within the subscriber units TE or a terminal device in which the TE is installed ready for operation. These wallets can also be software applications within the machine units ME or a machine in which the ME are installed ready for operation. A wallet can be set up as an application on a smartphone, a smart card or a payment terminal. The wallet is used to securely manage tokens T of the subscriber unit TE, to generate token references TR, to modify tokens T and/or to exchange tokens T. Wallets are used to communicate with the token reference register TRR, to generate registration requests RA to the token reference register TRR and/or to carry out transactions from token T to a subscriber unit TE.

The token reference register TRR is a unit of the transaction system TS. It is preferably a central register or a central database of the transaction system TS or a decentralized register or a decentralized database (DLT) of the transaction system TS.

In order to transfer the token from the subscriber unit TE to the machine unit ME, it is not necessary for a communication connection to the payment system BS or any other entity (Internet, server, etc.) to exist, exist or will exist. The token system TS is set up to carry out a transaction offline, ie without a communication link to the token reference register TRR. A corresponding registration of token T can therefore follow a transmission of the token T to a subscriber unit TE.

2a until c FIG.

In 2a the machine is my washing machine (or another household appliance such as a dishwasher, vacuum cleaner, hair dryer, iron, etc.) and the machine unit is installed in it ready for operation. The ME can be arranged as an integral component on a control circuit board of the washing machine M. This washing machine M is available for self-service, for example, in a laundromat, a common room in shared accommodation, a campsite or a holiday home. This washing machine M has a machine-readable QR code with which an ID of the machine, a public key, a certificate and/or a minimum token value v _min of the machine M can be queried. The The certificate can confirm the data elements contained in the machine-readable QR code, such as ID, public key, minimum token value or a group membership, such as "machine type washing machine". The minimum token value v _min is 50 cents, for example.

In 2 B the ME is placed in a charging station (for electric cars or combustion engines) as machine M. The ME can be arranged as an integral component on a control board of the charging station. This charging station can be found, for example, on the side of the road or in a public parking lot. This charging station has a machine-readable QR code with which an ID of the charging station, a public key, a certificate and/or a minimum token value v _min of the charging station can be queried. The certificate can confirm the data elements contained in the machine-readable QR code, such as ID, public key, minimum token value or a group membership, such as "machine type charging station". The minimum token value v _min is 0.10 ct, for example.

In 2c the ME is brought into a shower as a machine. The ME can be arranged as an integral component on a control board of a water heater or an electronic valve. This shower can be found, for example, in a fitness studio, a campsite, a holiday home or a sauna. This shower has a machine-readable QR code that can be used to request an ID of the shower, a public key, a certificate and/or a minimum token value v _min of the shower. The certificate can confirm the data elements contained in the machine-readable QR code, such as ID, public key, minimum token value or a group membership, such as "Machine type hot water". The minimum token value v _min is 10 cents, for example.

A machine M can also be an IOT device, for example a switch, plug, socket, counting device such as an electricity meter, water meter, etc., in which an ME is introduced or assigned.

In 3 a flowchart of a method 100 according to the invention is shown. Optional features or steps are shown in dashed lines, while steps that correspond functionally are provided with the same reference symbols.

In step 101 the QR code of the machine unit ME ( 2a-c ) read out by a camera (or scanner) of a subscriber unit TE. Alternatively, an RFID/NFC tag of the ME is read out. With the code, the TE receives an ID and minimum token value information. In addition, a machine type code can be obtained or other machine unit properties such as data memory size, data transfer rate, encryption type, change return, etc.

Reading the code increases the effort for a cheater/attacker as they would have to manipulate both the code and the ME.

In step 102 a mode can then be selected in the subscriber unit TE. The mode can be obtained through subscriber input. The mode can be selected automatically. The mode can be set based on machine unit properties or a subscriber unit property, such as data storage size, data transmission rate, encryption type, change return, etc. or a token value size, or it can also be set automatically. In one embodiment, the mode is set based on the information received in step 101 .

In mode 1 (overpayment), it is decided in optional step 112 whether one or more test micropayments should be carried out first.

If step 112 is no, in step 104 the token T of the TE is divided into a first partial token T1 and a second partial token T2. For this purpose, the token value v of the token T is divided into a first partial token value v1 and a second partial token value v2. Here the partial token value v1 has a greater value than the token value required by the ME to pay for the use. Further steps can be provided in the splitting step 104, it will be on 4 referred. In the following step 105, the token part T1 is sent to the ME with the token part value v1. The ME recognizes that the token part value v1 of the token part T1 is greater than the token value _vg required to pay for the use. A further splitting step is then carried out in the ME (not in 3 shown) to make a third token part T3 and a fourth token part T4 from the first token part T1. The token part T3 has a token part value v3, which consists of the difference between the required token value v _g and the first token part value v1, ie is the appropriate change. In optional step 107, the third token part T3 is combined with the second token part T2 in the TE, adding the token part values v3 and v2.

A concrete example for mode 1 with no case in step 112: In step 104 an asymmetrical splitting takes place for a payment of a token that is too large to the ME. The token T with a token value v = 4300 (= 43.00 e€) is divided into a first token part T1 with a first token part value v1 = 200 (= 2.00 e€) and in a second token part T2 with a second token part value v2 = 4100 (= 41.00 e€) divided. In step 105, the first token part T1 with the first token part value v1=200 (= 2.00 e€) is sent to the ME. The ME's demand amounts to v _g =0.73e€, so that in step 106 change is received as token part T3 with a third token part value v3=1.27e€. (For this purpose, T1 is divided into the ME and the third token part T3 and the fourth token part T4 has received a fourth token part value v4 = 0.73 e€. Optionally, the return money is combined (MERGE) with the second token part T2, with a fifth Token part T5 with a fifth token part value v5 = €41.00 + €1.27 = €42.27.

If step 112 is yes, in step 104 the token T of the TE is divided into a first partial token T1, a second partial token T2, a sixth token part T6 and a seventh token part T7. For this purpose, the token value v of the token T is divided into a first partial token value v1, a second partial token value v2, a sixth partial token value v6 and a seventh partial token value v7. These partitions are obtained as a result of modifications or obtained in one step. The token fractional value v1 has a much larger value than the token value v _g required by the ME. The token part value v6 and also the token part value v7 each have a minimum token value v _min . Further steps can be provided in the splitting step 104, it will be on 4 referred. In step 107 the token part value T6 is sent. In optional step 108, an acknowledgment of receipt is obtained from the ME. In the following step 105, the token part T1 is sent to the ME with the token part value v1. The ME recognizes that the token part value v1 of the token part T1 is greater than the token value required to pay for the use. A further splitting step is then carried out in the ME (not in 3 shown) to make a third token part T3 and a fourth token part T4 from the first token part T1. The token part T3 has a token part value v3, which consists of the difference between the token value required to pay for the use and the first token part value v1, ie is the appropriate change. In optional step 107, the third token part T3 is combined with the second token part T2 in the TE, adding the token part values v3 and v2.

The specific example for mode 1 with a no case from above now relates to the yes case in step 112 . In step 104, an asymmetrical split occurs for a payment of a token that is too large to the ME. The token T with a token value v = 4300 (= 43.00 e€) is divided into a first token part T1 with a first token part value v1 = 200 (= 2.00 e€), in a second token part T2 with a second token part value v2 = 4098 (= 40.98 e€) into a sixth token part T6 with a sixth token part value v6 = 1 (= 00.01 e€) and into a seventh token part T7 with a seventh token part value v7 = 1 (= 00.01 e€) divided .. In step 107, the sixth token part T6 with the sixth token part value v6 = 1 (= 0.01 e€) and then the seventh token part T7 with the seventh token part value v7 = 1 (= 0.01 e€) to the ME is sent and at step 108 receipt (either by both or each) is acknowledged. In step 105, the first token part T1 with the first token part value v1=200 (= 2.00 e€) is sent to the ME. The demand of the ME amounts to v _g = 0.73 e€, so that in step 106 change is received as token part T3 with a third token part value v3 = 1.29e€ (v3 = (v1 + v6 + v7) - v _g ). becomes. (For this purpose, T1 is divided into the ME and the third token part T3 and the fourth token part T4 has received a fourth token part value v4 = 0.71 e€. Optionally, the return money is combined (MERGE) with the second token part T2, with a fifth Token part T5 with a fifth token part value v5 = €40.98 + €1.29 = €42.27.

With the yes case in step 112, the comparatively high first payment from T1 to possibly insecure ME is secured by a test transmission. The further division of 1 or 2 tokens T6, T7 with a comparatively very low partial token value v6, v7 with a preferred minimum token value v _min makes it possible for initially only small amounts of money to be sent from TE to ME. This shows whether the ME also starts (offers the service) and whether the correct ME has been selected.

In mode 2 (payment with minimum token), minimum token value information is first evaluated in step 101a. This can have already been received in step 101 or be preset in the TE or be queried in step 101a by the ME or a background system (possibly payment system entity). A token minimum value dependency of the ME is thus queried, so that the TS for different MEs with different token minimum values v _min (see information in 2a-c ) can be used. The token is then split up in step 104. A multiplicity of minimum tokens T _min are obtained in a coherent splitting step, the sum of minimum token values v _min of which then contain the first token value v1. Different: v1 is an integer multiple A of v _min . In step 110 a first minimum token T _min with a minimum token value v _min is sent and in step 108 an acknowledgment is received (optional). In step 111 it is checked whether the sending of the previous parts of v1 the required token value v has already been reached or no further minimum token is required to use the machine. If step 111 is yes (v reached or no further v _min required), the remaining T _min are connected to T2 (MERGE) and the process is ended. If step 111 is no, a further minimum token T _min from the plurality A of minimum tokens from step 109 is sent in step 110 . This loop (step 111, optionally 108, step 111) is run through until the yes case occurs in step 111.

In this mode 2 (payment with minimum token), in splitting step 104, the number of T _min is performed. You may only need one proof PR for the last split, since the T _min are always sent to the same ME.

It is envisaged that both TE and ME will support both modes and by appropriate selection depending on token value size or ME properties or TE property.

After using a service for the first time with a previously unknown v _min (received with QR code in step 101 or 101a), this can be included in a standard selection of the TE. This standard selection can be reloaded and adjusted online (background system). If the machine is not used (e.g. for a specified period of time, e.g. X months), the previously unknown v _min is deleted from the standard selection.

In 4 an embodiment of a flowchart of a method according to the invention for splitting a token T _a and optionally registering the split tokens T _b T _c in the token reference register TRR is shown. In addition, the optionally required signed registration request RA _{Sig_Ta} and the command structure are shown in tabular form both from the point of view of the TE layer and the TR layer.

In the TS, a first random number r _b and a second random number r _c are generated by the TE. Based on this, a public part R _b and R _c is then generated in each case. The token T _a to be divided is available as an input parameter in the TS. The token value v _a is divided into a first partial token value v _b and a second partial token value v _c . The sum of the token value _vb and the token value _vc must result in the token value _va . This ensures that no new token value v is created or a token value v is destroyed.

The token references TR _b and TR _c can then be generated by the TE (not necessary in the present case). The registration request RA then contains the command “SPLIT”, the input token reference TR _a and the output token references TR _b and TR _c . This registration request RA is signed with the random number r _a of the token T _a . The signed registration request RA _{sig_Ta} can be sent from the TE to the token reference register TRR.

There the signature is checked and the sum of _vb and _vc is formed and compared with the token value _va . If v _a =v _b +v _c applies and the signature check is successful, then the token reference TR _a is deleted in the token reference register TRR or marked as deleted and the token references TR _b and TR _c are entered in the token reference register TRR.

The split token _Tb (or Tc) (which has since been transferred from TE to ME) can now be validated by ME in the TRR.

In 5 1 shows an embodiment of a flowchart of a method according to the invention for connecting a token T _d to a token T _e and registering the connected token T _f in the TRR. In addition, the signed registration requests RA _{sig_Td} and RA _{sig_Te} required for this, as well as the command structure, are shown in tabular form both from the point of view of the TE layer and the TR layer.

A random number _rf is generated in a TE1 of the TE layer. A public part R _f is then generated based on this. In addition, a sum is formed from the token values v _d and v _e to form the token value v _f based on the input tokens T _d and T _e .

Then the output token reference TR _f is generated. A registration request RA then contains the “MERGE” command, the two input token references TR _d and TR _e and the output token reference TR _f . This registration request RA is signed once with the random number r _d of the token T _d in order to obtain a first signed registration request RA _{sig_Td} . This registration request is also signed with the random number r _e of the token T _e in order to obtain a second signed registration request RA _{sig_Te} . Both signed register Requests RA _{sig_Td} and RA _{sig_Te} are sent from the subscriber unit TE1 to the token reference register TRR. The signatures of the registration requests RA _{sig_Td} and RA _{sig_Te} are checked there. In addition, the sum of the token values v _d and v _e is formed and compared with the token value v _f . If _vf = _vd + _ve and both signature checks are successful, then _TRd and _TRe are deleted or marked as deleted in the token reference register TRR and the token reference _TRf is entered in the token reference register TRR. The connected token T _f (which has meanwhile been transmitted from TE1 to TE2) can now be checked for validity by the subscriber unit TE2 in the TRR.

In 6 an exemplary embodiment of a flow chart of a method according to the invention for switching a token T _g to a token T _h and registering the switched token T _h in the token reference register TRR is shown. In addition, the signed registration requests RA _{sig_Tg} required for this and the command structure are shown in tabular form both from the point of view of the TE layer and the TR layer.

A random number r _h is generated in a TE1. A public part R _h is then generated based on this. In addition, the token value _vh, which is identical to the token value vg of the input token _{Tg ,} is formed.

Then the token reference TR _h is generated. A registration request RA then contains the command “SWITCH” or a corresponding command code 3a , the input token reference TR _g and the formed public part R _h (or the output token reference TR _h ). This registration request RA is signed with the random number r _g of the token T _g . The signed registration request RA _{sig_Tg} is sent from the subscriber unit TE1 to the token reference register TRR. The signature is checked there. In addition, the token value v _g is compared to the token value v _h . If v _g =v _h applies and the signature check is successful, then the token reference TR _g is deleted in the token reference register TRR or marked as deleted and the token reference TR _h is entered in the token reference register TRR.

Within the scope of the invention, all of the elements described and/or drawn and/or claimed can be combined with one another as desired.

QUOTES INCLUDED IN DESCRIPTION

This list of documents cited by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Patent Literature Cited

• DE 102018009949 A1 [0005]
• WO 2020212337 A1 [0006]

Claims (21)

A method (100) for directly transferring tokens (T) in a token system (TS) between a subscriber unit (TE) and a machine unit (ME) for paying for use of a machine, each token (T) having at least one token value (v) as a token element, with the method steps: - Splitting a token (T) of the subscriber unit (TE) into a first token part (T1) and a second token part (T2) by the subscriber unit (TE), with a token value (v) of the token (T) is divided into a first token part value (v1) of the first token part (T1) and a second token part value (v2) of the second token part (T2); wherein the first token part (T1) comprises a plurality of minimum tokens (T _min ), each minimum token (T _min ) having a token minimum value (v _min ), a first minimum token (T _{min_1} ) being transmitted from the subscriber unit (TE) to the machine unit ( ME) is sent; or wherein the first token part value (v1) is a multiple of a minimum token value (v _min ) and wherein the first token part (T1) is sent from the subscriber unit (TE) to the machine unit (ME). The procedure after claim 1 , wherein the minimum token value (v _min ) represents a token value (v) required by the machine unit (ME) to start use and/or to continue use, with the minimum token value (v _min ) preferably being machine unit type-specific. The procedure after claim 1 or 2 , wherein the first token part value (v1) is many times greater than the token minimum value (v _min ) and having the further steps: - dividing the first token part (T1) into a third token part (T3) and into a fourth token part (T4). the machine unit (ME), the first token part value (v1) of the first token part (T1) being divided into a third token part value (v3) of the third token part (T3) and a fourth token part value (v4) of the fourth token part (T4); and - sending from the machine unit (ME) to the subscriber unit (TE) the third token part (T3), the third token part value (v3) of the third token part (T3) being the difference between the first token part value (v1) and a payment corresponds to the usage required token value (v _g ); preferably after receiving the third token part (T3), in the subscriber unit (TE), the third token part (T3) is connected to the second token part (T2) to form a fifth token part (T5). The procedure after claim 3 , wherein prior to the splitting step, a mode of splitting in the subscriber unit (TE) is selected, with a first mode specifying that the first token split value (v1) is a multiple greater than the token minimum value (v _min ) and with a second mode it is determined that the first partial token value (v1) comprises the plurality of minimum tokens (T _min ). The procedure after claim 4 wherein the first mode or the second mode is selected automatically by the subscriber unit (TE) based on a subscriber unit property and/or based on a machine unit property. The method according to any one of the preceding claims, - wherein before the splitting step, a machine-readable code of the machine unit (ME) for obtaining identification data, preferably machine-unit-specific, is read out from the subscriber unit (TE); and - Wherein before the sending step, the identification data read out are linked to the first token part (T1); and - wherein after the sending step, the received identification data are compared with the identification data of the machine unit, wherein if the identification data match, the first token part (T1) is considered validated. The method according to any one of the preceding claims, - wherein before the splitting step, a machine-readable code of the machine unit (ME) for obtaining a public part of a key pair, preferably machine unit-specific, is read out from the subscriber unit (TE); and - wherein before the sending step, the first token part (T1) is encrypted with the public part of the key pair from the subscriber unit (TE); and - wherein after the sending step, the received encrypted first token part (T1) is decrypted with a private key part of the key pair. The method according to any one of the preceding claims, - wherein in the dividing step the token (T) is also divided at least into a sixth token part (T6), preferably also a seventh token part (T6), - wherein the first token part value (v1) is um is a multiple greater than the required token value (v _g ); and - where a sixth token part value (v6) of the sixth token part (T6), preferably also a seventh token part value (v7) of the seventh token part (T7), corresponds to the token minimum value (v _min ), - where before the sending step, first the sixth token part (T6), preferably then the seventh token part (T7) is sent from the subscriber unit (TE) to the machine unit (ME). The method according to any one of the preceding claims, wherein after sending the first minimum token (T _{min_1} ), the method further comprises: - sending from the machine unit (ME) to the subscriber unit (TE) an acknowledgment of the receipt of the first minimum token (T _{min_1} ) and preferably sending a request to send another minimum token (T _min ). The method according to any one of the preceding claims, wherein the first token part value (v1) of the first token part (T1) corresponds to an integer multiple of a token minimum value (v _min ). The method according to any one of claims 1, 2 or 10, wherein in at least one second transmission step immediately following the transmission step, in the machine unit (ME), a second minimum token (T _min ) is received from the subscriber unit (TE). The procedure according to one of the Claims 1 , 2 , 10 or 11 , - wherein after the sending step, another minimum token (T _min ) is automatically received from the subscriber unit (TE) in the machine unit (ME) after a predefined period of time has elapsed, - wherein a number of minimum tokens (T _min ) not sent of the first token part value (v1) are connected to a remainder token value of a remainder token part; and - wherein further preferably, this remainder token part is connected to the second token part value (v2) in the subscriber unit (TE). The procedure according to one of the Claims 1 , 2 or 10 until 12 , where the minimum token value (v _min ) varies between different machine unit types. The procedure according to one of the Claims 1 , 2 , or 10 to 13, wherein the minimum token value (v _min ) is preselected in the subscriber unit (TE), the preselection being updatable and preferred by remote management of the subscriber unit, the preselection depending on a use of the service from the subscriber unit (TE). the machine unit (ME) can be updated by the subscriber unit within a predefined period of time. The method according to any one of the preceding claims, - wherein before the splitting step, a machine-readable code of the machine unit (ME) is read out from the subscriber unit (TE) in order to obtain, preferably machine-unit-typical, token minimum value information, and - wherein the token minimum value information is used in the subscriber unit (TE) to obtain the first token part value (v1) of the first token part (T1). The method according to any one of the preceding claims, wherein a minimum denomination of a token value (v) is one tenth, one hundredth or one thousandth of a minimum denomination of a currency. The method according to any one of the preceding claims, wherein each token (T) as a token element also has a private part of a token-part-individual key pair, wherein the token value can be registered together with a public part of the token-part-individual key pair as a token reference in a token reference register (TRR). A machine unit (ME) in a token system (TS), set up for use in a method according to one of Claims 1 until 17 , comprising: - an interface which is set up for receiving tokens (T) from subscriber units (TE) and for sending tokens (T) to subscriber units (TE); - A means of access to a token memory or token memory, wherein in the token memory at least one Token (T) can be stored by a subscriber unit (TE); and - a computing unit set up for splitting and connecting received tokens (T). The machine unit (ME) after Claim 18 further comprising a machine-readable code, comprising: - identity data of the machine unit (ME); and/or - a public key part of a machine-specific key pair, the private key part being stored in a memory unit of the machine unit (ME); and/or - minimum token value information; and/or - a group membership of the machine unit (ME), the machine unit preferably storing a certificate or providing it in the machine-readable code, which confirms the identity data of the machine unit (ME), the public key, the minimum token information and/or a group membership of the machine unit. The machine unit (ME) after Claim 18 or 19 , set up to transfer all tokens from the token memory to a token collection unit. A token system (TS) comprising: - at least one machine unit (ME), preferably a multiplicity of machine units (ME) of the same type; - A plurality of subscriber units (TE), each set up for direct transmission of tokens (T) with a machine unit (ME) according to claims 1 until 17 ; - A token collection unit, set up to receive tokens (T) of a token memory of the at least one machine unit (ME); and - preferably a token reference register (TRR), set up for registering unique token references to the tokens (T).

Images