Field of Invention

[0001] This invention relates to secure electronic communications, and more particularly to a transferrable value or rights token.

Background

[0002] Tokens can be used to represent the value of an asset or a right to a service. Such value or rights may relate to a representation of any physical or digital asset including for example digital currencies, stocks, shares, coupons, bonds, options, vouchers, deeds etc.

[0003] Referring to Fig 1 , there is shown a transferable value or rights token system in accordance with Applicants patent publication GB 1417413.0, the entire content of which is hereby incorporated herein by reference. The illustrated system comprises a user access device 1 which includes a user interface 4 and an authentication component 5 which connects to a communication media 3 to obtain access to a pocket controller device 2. This pocket controller device 2 includes a memory configured to store at least two pockets 9 which store the current balance of the value or rights tokens held by a respective user. The users gain access to their pockets through the controller 6 after successful authentication by the authentication component 5. The controller 6 connects to the certification engine 8 to create one or more digital signatures or cryptographic check values that are used to protect the token. The issued tokens are stored in the Token store 7. These tokens can be stored and moved in any suitable form including for example by the use of bar codes.

[0004] The pocket controller device 2 provides at least two core functions to the users, the ability to create tokens and the ability to load tokens. Once a token is created it doesn't need to contain any reference to the source pocket from which the token was created or the pocket into which the token will eventually be loaded. In this sense the token is anonymous because it contains no reference to the users of the system.

[0005] The system of Applicants patent publication GB 1417413.0 is based on the concept of creating anonymous tokens of a user-defined value that can be readily transferred between users in a way that more closely relates to the handling of cash, but in an on-line mode.

Although the handling of tokens is assumed to be through on-line communications media it is possible to define an embodiment where only the receiver of the token needs to be on-line.

[0006] Users of the Token system may enrol in order to be assigned a pocket and receive credentials to enable their access to be authenticated. User access authentication may be the traditional user name and password or a 2-Factor authentication method using something the user owns such as a smart card and something the user knows such as a password. In some cases, the system may use the Transport Layer Security (TLS) protocol where the user is issued with a client certificate to store in devices such as mobile phones and tablets or PCs. The users may arbitrarily enhance this security by requiring further access credentials to use the client certificate such as a user PIN or password.

[0007] When a user wishes to transfer a value token to another party, the user connects to the authentication module of the pocket controller device. Based on the credentials provided by the user authentication process, the controller identifies which pocket belongs to the user making the authentication request.

[0008] Following successful authentication, the user may then request the creation of a value token. The controller will then decrement the user's pocket and create a corresponding value token. This value token may be protected by a cryptographic check sum, although a digital signature would be an alternative security technique.

[0009] In normal operation the controller would actually create two cryptographic checksums using two separate security domains. This provides a more secure approach particularly where access to the token controller takes place over the public internet. The two security domains may be located and managed by different legal entities such that, in practice, collusion to make an attack is extremely difficult to achieve and hence highly unlikely.

[0010] For the purposes of this disclosure, the term "security domain" shall be understood to refer to run-time environment in which messages may be secured by means cryptographic keys, checksums and/or digital signatures generated using of a set of one or more certificates and/or root keys that are typically provided by a trusted authority. A security domain may comprise a respective Certification Authority (CA) for keys issued within that security domain, and respective cryptographic features (including algorithms), either of which may be the same or different from those of other security domains. The term "separate security domains" refers to run-time environments in which messages may be secured on the basis of respective different sets of certificates and/or root keys, and possibly respective different CAs. In some cases, the certificates and/or root keys defining two or more separate security domains may be provided by respective different trusted authorities, but this is not essential. Typically, messages secured under one security domain cannot be validated by a process using a different security domain. Applicants' patent publication GB 1417413.0 teaches

embodiments in which each token is secured by cryptographic check sums generated using two separate security domains. This means that in order to attack the token, it would be necessary for a hacker to obtain both sets of certificates and/or root keys.

[0011] The two cryptographic checksums enable the token transfer process to consist of three steps, the creation of a token by a "sending" party, and the load of a token by a receiving party, which has twosteps. In a first step, the receiving party is given the token and just one of the two cryptographic checksums. This enables the controller to check the authenticity of the Token and to mark its destination to be that of the receiving party's pocket. In the second step, the receiving party is given the second cryptographic checksum, which they can present to the controller in order to vest the value of the token in their pocket. This certificate verification technique allows the transaction process to take place in two steps but allows the receiving party to ensure that they have received an authentic token and that it cannot be spent by anybody else.

[0012] This type of operation is particularly useful when the two parties engaged in a transaction do not trust each other. On the other hand, in many cases the sender and receiver would trust each other. In such a case, perhaps for example when a parent is paying value to their children, it would not be necessary to split the load and verify function. Rather, the receiving party could be given both cryptographic check sums in a single operation, so that they can present both cryptographic check sums along with the token to the controller, again as a single operation.

[0013] The token transfer system also allows an additional function for users to check the validity of the value token by providing a validate operation. In this case the receiver of the — = » I _u

- 4 - token can send it to the controller to request a validity check. The controller would check that the token is authentic and has not previously been spent. In this case the receiver may not have all the information necessary to load the token, for example the sender may not have ^* provided the second (i.e. the verification) cryptographic check sum. However, the token can still be marked as unspent and could be given to another user. The load command results in the token being marked as spent even though the value may not be vested with the receiver, who is still awaiting the verification cryptographic check sum.

[0014] It is an important to recognise that it is not necessary to include information in the Token that identifies either the sender or the receiver. Breaking the link between Tokens and users in this way means that the spending behaviour of users cannot be monitored and their activities can be truly anonymous. This may be important not only when the tokens are used for payments but also when they relate to rights, perhaps for example a vote.

[0015] How the users of the system handle the security of the tokens is arbitrarily their choice. The tokens are protected by their own integrity function and it is not possible for an attacker to modify the contents of the token without detection. However, there are occasions where the creator of a value token may want to pre-define the destination pocket so that the token's value can only be loaded into that specific pocket. This might for example be because the desired or intended destination pocket is known to the payer, and the payer wishes to reduce the risk of the token being stolen before the receiver has had chance to load the token into their pocket. Since the token does not include any information that identifies either of the payer or the payee, or their respective pockets, there is a problem to be solved, which may be described as how to ensure that a token can only be loaded into the pocket intended by the payer.

Summary

[0016] The above noted problem is solved by the combination of features defined in the appended independent claims. Further, optional features of the invention are defined in the appended dependent claims. [0017] An advantage of the present invention is that it offers the users of the system an additional security feature such that a token can only be loaded into the destination pocket intended by the payer.

[0018] When a user creates a token they may optionally provide information identifying the intended destination pocket. This information may then be recorded by the pocket controller. In the event that no destination pocket identifier is provided by the user, the pocket controller may operate to permit the token value to be loaded into any pocket.

[0019] In some embodiments, the user may provide information identifying a

predetermined group of pockets. In this case, the pocket controller may operate to permit the token value to be loaded only once, but into any pocket within the identified group of pockets.

[0020] It will be readily apparent that the identifier of a pocket may be realised in many forms, for example an index or address of the pocket record in a data base or even a hash of these. The term "pocket ID" is used in this document for ease of description but it will be recognised that the this "pocket ID" should be understood to refer to any information (in any appropriate form) that unambiguously identifies a specific pocket or a specific group of pockets.

[0021] When the creator of the token sets the token parameters, they will need to know the pocket ID of the destination pocket or they may provide no pocket ID value in which case the token value can be loaded into any pocket. When the receiver of the token attempts to load the token value into their pocket, the pocket controller will first check to determine whether or not the intended pocket ID has been set in the token store and if so will check that the intended pocket ID matches the pocket ID associated with the receiver. If the two pocket IDs match, then the pocket controller will permit e token value to be loaded to the receiver's pocket.

[0022] It is also possible for the pocket controller to allow the original creator of the token to load the token back into their own pocket. This would for example allow for situations where the token has been lost by the receiver.

[0023] As may be appreciated, the receiver of a value token protected by a pocket ID may load the token into their pocket and then create a new one protected by a different pocket ID. This removes the capability of the token sender to spend the token (or reload it to their own pocket) after sending it to another person and also ensures that the receiver has taken the value of the token.

Brief Description of Drawings

[0024] Further features and advantages of the present invention will become apparent from the following detailed description, taken in combination with the appended drawings, in which:

[0025] Figure 1 is a diagram that shows the components involved in the transfer of value tokens where Tibado represents the token and pocket controller device;

[0026] Figure 2 is a sequence diagram that shows the complete transfer of value token in accordance with an embodiment of the present invention; and

[0027] Figure 3 is a sequence diagram that shows reloading a token value to its source pocket, in accordance with an embodiment of the present invention.

[0028] In the component diagram like components use the same identification number. In the case of the sequence diagrams each step in the sequence is numbered consecutively. The following reference numbers are used:

[0029] 1 - User access device

[0030] 2 - Pocket controller device

[0031] 3 - Communications media

[0032] 4 - User Interface

[0033] 5 - Authentication module

[0034] 6 - Token controller

[0035] 7 - Token store

[0036] 8 - Certification engine [0037] 9 - Pocket stores

Detailed Description

[0038] Embodiments of the present invention and their technical advantages may be better understood by referring to the figures. For the purposes of the following description, the present invention is described by way of a representative embodiment in which users of the system create, send, receive and load tokens into their respective pockets. This example assumes that the users are natural persons. However, it will be understood that the present invention is equally capable of operation where either or both of the "users" are automated or semi-automated processes such as bots, software agents or the like.

[0039] Referring again to Figure 1, the value token system of the present invention generally comprises a user's device 1 and a pocket controller device 2 connected for communication through a communication medium 3.

[0040] The user's device 1 may be provided as any suitable combination of hardware and software capable of supporting a user's interaction with the pocket server 2 and other users, and includes a user interface 4 and an authentication module 5A. In some embodiments, the user's device 1 may be provided as any of a mobile phone, a tablet, a PC or even a special device developed, for the purpose,

[0041] The pocket controller device 2 may similarly be provided as any suitable combination of hardware and software capable of supporting interaction with multiple user's devices, and includes an authentication module 5B, a controller 6, a certification engine 8, a token store 7 for storing information about each token generated by the system and a nonvolatile pocket memory 9 for storing a plurality of pockets. In some embodiments, the pocket controller device 2 may be provided as one or more computers (including a computer cluster, a network of computers or a virtual computer running in a cloud environment) connected to the communications media 3.

[0042] In some embodiments, the non-volatile pocket memory 9 may include a database composed of records, wherein each record represents a respective pocket. Preferably, each pocket (or database record) includes a respective unique pocket ID, which can be used to reference that specific pocket (record). For example, the unique pocket ID may comprise a unique index number or value, which can be generated in accordance with any suitable criteria. Alternatively, the unique identifier may comprise a unique address of the pocket, or of the user associated with that pocket, either of which may be represented in any suitable form.

[0043] In some embodiments, predefined groups of pockets can be configured, with each group being associated with a respective "pocket ID". For example, it is possible for a user to own multiple pockets. While each of these pockets may be individually referenced by means of their respective pocket IDs, it may also be possible for the user's pockets to be collectively referenced by means of a "group" pocket ID, which in this case identifies the specific group of pockets, rather than any specific pocket within the group.

[0044] The communications media 3, may be provided as any suitable combination of communications media capable of supporting messaging between users' devices 1 and the pocket controller 2. In some embodiments, the communications media 3 may include the public Internet.

[0045] Each user who participates in the value token transfer scheme is allocated one or more pockets which store the balance of their value tokens. Each pocket can store the same or a different currency depending on how the pockets were initially configured and ascribed to the user.

[0046] Users interact with the pocket controller device 2 through their user interface 4 on their device 1 which is configured with the user's credentials in such a way that when connecting through the communications media 3 to the pocket and token controller device 6 the authentication module 5A on the user's device 1 can establish a trusted session with the authentication module 5B on the token and pocket controller device 2.

[0047] By means of this authenticated connection to the token and pocket controller device 2 the users can securely create and load tokens for the transfer of value or rights. It is understood that each token comprises a block of data that may be stored and transmitted by any suitable means including bar code images, for example. [0048] When a user wants to create a token, they send a request to the pocket controller device 2. In accordance with the present invention, the request may include a pocket ID that identifies the intended destination pocket or group of pockets. Alternatively, the pocket controller device 2 may query the user to input or otherwise select a pocket ID, for example as part of the token creation process. The controller 6 accesses the pocket memory 9 and checks the user's pocket, and as long as the balance would remain positive after the transaction it creates a token with the requested value and adds a corresponding entry in the token store 7 while debiting the balance in the user's pocket by the value of the token.

[0049] The controller 6 also interacts with the certification engine 8 that creates the cryptographic check sums necessary to protect the token. The token is preferably protected by two cryptographic check sums created in different security domains. In some embodiments, each cryptographic check sum may be created by a respective different certification engine 8 (for simplicity of illustration, only one Certification Engine 8 is shown in the drawings). In some embodiments, each certification engine 8 may be operated by respective different legal entities. This arrangement improves the security of the system by making it very difficult for a single entity (e.g. a hacker) to be able to create tokens or load value into any pockets. It is anticipated that in many cases the pocket controller device 2 will comprise one or more servers in the cloud, and these servers may be managed by a third party. The use of the dual cryptographic check sum avoids the obvious collusion attacks associated with multiple cloud server systems.

[0050] In some embodiments, the token can be further protected by the inclusion of the destination pocket ID into either or both of the cryptographic check sum values. This is to improve the security and to make it very difficult for a third party who gains a copy of the token to be able to create or load value into their own pockets because they won't have knowledge of the destination pocket ID.

[0051] Having created the protected token the controller 6 passes it back to the user by means of the secure channel between the token and pocket controller device 2 and the user's device 1. [0052] The user may choose to store this token for an arbitrary period of time at which point they may pass the token to another user (a payee) by any suitable communications means such as email or a messenger application for example. It should be clear that at this point the sending user (the payer) may be off-line from the pocket controller device 2 and might pass the token to the payee by some local communication path such as Bluetooth to the receiver.

[0053] Depending on the situation and the degree of trust between the participants of the transaction, the payer may choose to send only one of the two cryptographic check sums to the payee with the token. With this information the payee can validate the token and associate it with their pocket by connecting to the pocket and token controller device 2 using an authenticated channel through the communications media 3, and then interacting with the controller 6 to execute a load operation.

[0054] Upon receipt of the token and (one) check sum, the controller 6 can use the check sum to confirm the validity of the token, and check the destination pocket ID stored in the token store 7 (if any) to confirm that it matches the pocket ID of a pocket (or group of pockets) associated with the payee. If these checks are successful, the controller 6 will change the token's status in the token store 7 to mark it as being assigned to the payee's pocket, but will not actually vest the value of the token in the pocket. The token value is not yet available to the payee, and cannot be spent by the payee, until it has been vested in the pocket by the controller 6. Once the controller 6 has successfully confirmed the validity of the token, the payee now knows the token is valid and can complete the transaction with the payer by, for example, the supply of goods and/or services. When the necessary conditions have been met, the payer may send the Verification Certificate (i.e. the second cryptographic check sum) to the payee by any suitable communications method including for example email.

[0055] Once the payee has received the Verification Certificate, the payee can now complete the load process by connecting to the pocket server 2 by means of the authenticated channel over the communications media 3, and supplying the s Verification Certificate to the controller 6. [0056] The controller 6 can then check the validity of the Verification Certificate, and if it is valid the controller 6 can update the balance of the payee's pocket and mark the token as spent in the token store 7.

[0057] The transaction flow described above can be understood in more detail by referring to the sequence diagram of Fig 2, in which the term "TIB ADO" is an expression used in the drawings that represents the token and pocket controller device 2. In this respect, it will be appreciated that most of the operations attributed to the token and pocket controller device 2 involve the cooperative operation of multiple components including, but not limited to, the authentication module 5B, controller 6, certification engine(s) 8 and memories 7 and 9.

[0058] The process of Figure 2 begins at step S 1 , in which the payee makes a request of the payer for the transfer of a value token for, in this example, £5. The payee may also provide the payer with a pocket ID identifying the pocket that the payee wants to use to receive the token value.

[0059] At step S2, the payer establishes an authenticated connection to TIBADO using any suitable method, such as for example using TLS with a client certificate. When the authenticated connection is established the payer makes a request (at step S3) to TIBADO to create a token with a value of £5 and the pocket ID identifying the desired destination address of the token.

[0060] Upon receipt of the request from the payer, TIBADO checks (at step S4) the balance of the payer's pocket and, if the requested withdrawal would leave a positive (or zero) balance in the payer's pocket, decrements the pocket balance by £5, creates the value token and stores information about the token in the token store 7. The token information stored in the token store 7 preferably includes at least the token ID and its value as well as the state of the token, (which at this time is "created"). TIBADO then generates a at least one (and preferably two) cryptographic check sums. In embodiments in which only one cryptographic check sum is generated, the cryptographic check sum may form a Validation Certificate that is associated with the token. In embodiments in which two cryptographic check sum are generated, one of the cryptographic check sums may be embedded within (or attached to) the token, while the other cryptographic check sum forms the Validation Certificate and is normally stored and transmitted separately from the token itself. In some embodiments, the token information stored in the log 7 may also include one (or both) of the cryptographic check sums, but this is not essential. In some embodiments, at least one (and preferably both) of the cryptographic check sums includes the selected pocket ID identifying the desired destination address of the token.

[0061] In some embodiments, TIBADO will store a hash of the destination pocket ID in the token store 7, rather than the destination pocket ID itself. This allows subsequent verification of the destination pocket ID by TIBADO, but prevents a hacker from discovering the destination pocket ID by attacking the token store 7.

[0062] It is important to note that, while the destination pocket ID is included in at least one of the cryptographic check sums, it is not included in the data forming the token itself. This means that while the destination pocket ID is necessary for validation of the token (via the cryptographic check sums), there is no practical means by which the destination pocket ID can be discovered by analysis of the token.

[0063] Preferably the process of generating the Token at step S4 is executed as an atomic database operation, in that it cannot be divided or interrupted during execution. This implies that the process is isolated from other processor function, which offers protection against some potential hacker attacks.

[0064] At step S5, TIBADO returns the token, its cryptographic check sums and, optionally, the destination pocket ID to the payer across the authenticated channel. Returning the destination pocket ID to the payer may be appropriate in order to provide the payer with confirmation that the token has be properly generated.

[0065] If desired, once the payer has received the token from TIBADO, the payer may (at step S6) end the authenticated session with TIBADO.

[0066] At step S7, the payer sends the token to the payee. In embodiments in which the token is protected by two cryptographic check sums, only one of the cryptographic cheek sums may be sent to the payee at this time. In other embodiments in which the token is protected by only one cryptographic check sum, then the token may be sent to the payee without the cryptographic check sum.

[0067] At step S8, the payee establishes an authenticated connection to TIBADO, for example using TLS with a client certificate, and at step S9 requests the controller to load the token to the payee's pocket. The request will normally include the token and any check sum supplied by the payer.

[0068] Upon receipt of the payee's request, TIBADO (at step S10) checks the token store 7 to determine whether or not: the status of the received token is still "created" (that is, it has not already been "loaded" or "spent" to another destination pocket); that the cryptographic check sum is valid; and that the destination pocket ID registered in the token store 7 matches the pocket ID of a pocket or group of pockets associated with the payee. For this purpose, TIBADO may use authentication information obtained during establishment of the

authenticated connection to identify pockets and/or pocket groups associated with the payee. If any of these checks fails, TIBADO may reject the load request, and send a corresponding failure message to the payee. Otherwise, TIBADO changes the state of the token in the token memory 7 to show the status as "loaded".

[0069] In embodiments in which the destination pocket ID registered in the token store 7 (at the time the token was created) identifies a specific pocket, then this registered destination pocket ID may be retained for use when the token value is subsequently vested. In

embodiments in which the destination pocket ID registered in the token store 7 at the time the token was created identifies a group of pockets, then this registered destination pocket ID may be updated to indicate a specific pocket within the group. Alternatively, the pocket ID of the specific pocket in which the token value is to be vested may be added to the token store 7. The payee may be queried by TIBADO to identify the specific pocket within the identified pocket group into which the token value is to be vested. This arrangement is beneficial in that it ensures that the token value can be loaded only once, and into only one pocket, but can be loaded into any pocket of the identified pocket group at the option of the payee.

[0070] The controller 6 may also ensure the integrity of the pocket and token memories 7 and 9 by the use of additional cryptographic checksums as necessary and appropriate. [0071] Preferably the process of loading the token at step S10 is executed as an atomic database operation, in that it cannot be divided or interrupted during execution.

[0072] At step SI 1, TIB ADO sends a reply to the payee confirming that the token is valid and loaded to the payee's pocket, but the value is not yet vested. The confirmation message may also request the payee to provide the Validation Certificate. If desired, the payee may end the authenticated session with TIBADO following receipt of confirmation that the token is valid.

[0073] At step SI 2, the payee communicates with the payer to request the Validation Certificate for the token that will validate or certify the transaction so that the token value can be vested in the payee's pocket.

[0074] At step SI 3, the payer sends the validation certificate to the payee.

[0075] The payee may then establish a new authenticated connection with TIBADO and send (at step SI 4) the validation certificate to TIBADO. Upon receipt of the validation certificate, TIBADO uses the validation certificate (at step SI 5) to check the previously received token. If the validation check fails, TIBADO may reject the load request, and send a corresponding failure message to the payee. On the other hand, if the validation check is successful, TIBADO vests the token in the payee's pocket by marking the appropriate entry in the token store 7 as showing the token's new state of "spent", and updating the balance of the payee's pocket (as identified by the destination pocket ID registered in the token store 7) by the value of the token. Preferably the process of vesting the Token at step S 15 is executed as an atomic database operation, in that it cannot be divided or interrupted during execution.

[0076] At step S 16, TIBADO sends a confirmation message to the payee confirming the results of the processing at step SI 5. In the event that the processing was successful, the confirmation message indicates that the token value (in this case, £5) has been added to the payee's pocket. At step SI 7, the payee may send a confirmation "thank you" message to the payer indicating that the transaction has been successfully completed.

[0077] The token controller may allow the payee a predefined number of attempts to load the token to their pocket, or alternatively may permit an unlimited of attempts. If the number of attempts to load the token is limited, then the token controller 6 must keep a counter to record these events.

[0078] It is also possible to allow the original creator of the token to be able to reload the token back into their own pocket. This operation may be used to override a situation in which where the payee cannot successfully load their token into their pocket (for example, the maximum number of load attempts by the payee has been reached). For this purpose, the token controller 6 may keep a record of which pocket was used to create the token.

[0079] FIG. 3 illustrates an example process for reloading a token in an event in which the payee does not successfully load their token. Referring to FIG. 3, at step SI 8, the payee sends a message to the payer indicating that they were unable to load their token. Following receipt of the message, the payer may (at step SI 9), establish an authenticated connection to TIB ADO using any suitable method, such as for example using TLS with a client certificate.

[0080] When the authenticated connection is established the payer makes a request (at step S20) to TIBADO to reload the token. In some embodiments, the reload request includes at least the token, and (optionally) the validation certificate. Upon receipt of the request, TIBADO checks the status of the token. If the token status is either "created" or "loaded" (that is, the token status is not "spent"), and if the token checksum is valid, then TIBADO can check the token store 7 and identify the source pocket from which the token was created. TIBADO can then operate to reload the token into the source pocket. One method by which this can be done is by resetting the destination pocket ID registered in the token store 7 to the pocket ID of the source pocket, then incrementing the destination pocket by the token value and resetting the token status to "spent". This operation has an advantage in that it uses the normal process for vesting token value in a pocket. This ensures that reloaded tokens can be audited using the same auditing and verification algorithms used to ensure integrity of all records in the token store 7.

[0081] In the example of FIG. 2, the destination pocket ID is supplied to the payer by the payee at the start of the transaction (see step SI). However, it will be appreciated that this is not essential. For example, the payer and payee may enter into an arrangement in which the pocket ID is provided to the payer, who uses that same pocket ID for a number of subsequent transfers. An example of such an arrangement may be one in which the payee agrees to perform some on-going service, for which the payer makes payment by transferring value amounts to the designated pocket ID of payee. In a further alternative embodiment, the payer may request the creation of one or more pockets, which may subsequently be reassigned to the payee. In this case, the payer knows the pocket IDs for each of the involved pockets, and can subsequently make value transfers to these pockets without requiring the payee to provide the pocket ID information to the payer.

[0082] In the example of FIG. 2, the destination pocket ID is known to the payer at the time that the token is created, and therefore can be used by the payer to control the pocket into which the created token can be loaded. As noted above, however, it is also possible that the may not know the destination pocket ID at the time that the token is created. In this case, the destination pocket ID cannot be registered in the pocket store 7 when the token is created. In some cases, the applicable field in the pocket store record for the token may contain a default or null value, or indeed may be left empty. This means that, when the payee attempts to load the token, the controller 6 will determine that the pocket store record for the token does not contain a registered destination pocket ID. In this case, the controller 6 may operate to insert the pocket ID of the pocket associated with the authenticated load request into the token store 7, so that the pocket value can be loaded (and vested) to the payee's pocket in a normal manner, albeit with the payer asserting no control over the destination pocket into which the token value is loaded.