WO2016178076A1 - Régulation de charge d'un jeton de valeur ou de droits transférable - Google Patents

Régulation de charge d'un jeton de valeur ou de droits transférable Download PDF

Info

Publication number
WO2016178076A1
WO2016178076A1 PCT/IB2016/000584 IB2016000584W WO2016178076A1 WO 2016178076 A1 WO2016178076 A1 WO 2016178076A1 IB 2016000584 W IB2016000584 W IB 2016000584W WO 2016178076 A1 WO2016178076 A1 WO 2016178076A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
pocket
value
store
request message
Prior art date
Application number
PCT/IB2016/000584
Other languages
English (en)
Inventor
David Everett
Timothy Jones
Original Assignee
Tibado Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tibado Limited filed Critical Tibado Limited
Publication of WO2016178076A1 publication Critical patent/WO2016178076A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/223—Payment schemes or models based on the use of peer-to-peer networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/227—Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3676—Balancing accounts
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography
    • G06Q2220/10—Usage protection of distributed data files
    • G06Q2220/12—Usage or charge determination
    • G06Q2220/123—Usage or charge determination involving third party for collecting or distributing payments, e.g. clearinghouse

Definitions

  • This invention relates to secure electronic communications, and more particularly to a transferrable value or rights token.
  • Tokens can be used to represent the value of an asset or a right to a service.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • TLS Transport Layer Security
  • the user 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.
  • 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.
  • 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.
  • CA Certification Authority
  • 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.
  • 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.
  • messages secured under one security domain cannot be validated by a process using a different security domain.
  • 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.
  • 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.
  • 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.
  • 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.
  • This type of operation is particularly useful when the two parties engaged in a transaction do not trust each other.
  • 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.
  • the token transfer system also allows an additional function for users to check the validity of the value token by providing a validate operation.
  • 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.
  • 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.
  • 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.
  • 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.
  • a user 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.
  • the user may provide information identifying a
  • 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.
  • 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.
  • 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.
  • the pocket controller 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.
  • 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.
  • FIG. 1 is a diagram that shows the components involved in the transfer of value tokens where Tibado represents the token and pocket controller device;
  • Figure 2 is a sequence diagram that shows the complete transfer of value token in accordance with an embodiment of the present invention.
  • 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.
  • 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.
  • 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.
  • 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,
  • 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.
  • 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.
  • the non-volatile pocket memory 9 may include a database composed of records, wherein each record represents a respective pocket.
  • each pocket or database record
  • each pocket ID may comprise a unique index number or value, which can be generated in accordance with any suitable criteria.
  • 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.
  • predefined groups of pockets can be configured, with each group being associated with a respective "pocket ID".
  • each group 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.
  • 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.
  • the communications media 3 may include the public Internet.
  • 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.
  • each token comprises a block of data that may be stored and transmitted by any suitable means including bar code images, for example.
  • the request may include a pocket ID that identifies the intended destination pocket or group of pockets.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • the payer may choose to send only one of the two cryptographic check sums to the payee with the token.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • step S 1 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.
  • the payer establishes an authenticated connection to TIBADO using any suitable method, such as for example using TLS with a client certificate.
  • 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.
  • TIBADO 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.
  • 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.
  • the token information stored in the log 7 may also include one (or both) of the cryptographic check sums, but this is not essential.
  • at least one (and preferably both) of the cryptographic check sums includes the selected pocket ID identifying the desired destination address of the token.
  • 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.
  • 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.
  • 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.
  • 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.
  • the payer may (at step S6) end the authenticated session with TIBADO.
  • the payer sends the token to the payee.
  • the token 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.
  • 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.
  • TIBADO 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
  • 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".
  • this registered destination pocket ID may be retained for use when the token value is subsequently vested.
  • this registered destination pocket ID may be updated to indicate a specific pocket within the group.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • step SI 3 the payer sends the validation certificate to the payee.
  • the payee may then establish a new authenticated connection with TIBADO and send (at step SI 4) the validation certificate to TIBADO.
  • 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.
  • 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.
  • 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.
  • TIBADO sends a confirmation message to the payee confirming the results of the processing at step SI 5.
  • the confirmation message indicates that the token value (in this case, £5) has been added to the payee's pocket.
  • the payee may send a confirmation "thank you” message to the payer indicating that the transaction has been successfully completed.
  • 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.
  • FIG. 3 illustrates an example process for reloading a token in an event in which the payee does not successfully load their token.
  • the payee sends a message to the payer indicating that they were unable to load their token.
  • 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.
  • the payer makes a request (at step S20) to TIBADO to reload the token.
  • the reload request includes at least the token, and (optionally) the validation certificate.
  • 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.
  • the destination pocket ID is supplied to the payer by the payee at the start of the transaction (see step SI).
  • 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.
  • 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.
  • 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.
  • 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.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un jeton de valeur ou de droits transférable, la valeur ou les droits pouvant être transmis d'entité à entité selon les nécessités et étant protégés par une ID de poche de destination pour commander la poche dans laquelle le jeton peut être chargé. La valeur ou les droits transmis dans les jetons sont conservés par les utilisateurs dans des poches commandées au moyen d'un dispositif de commande. Les jetons sont anonymes mais il est nécessaire d'authentifier les utilisateurs afin qu'ils puissent accéder à leurs poches.
PCT/IB2016/000584 2015-05-05 2016-05-06 Régulation de charge d'un jeton de valeur ou de droits transférable WO2016178076A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GBGB1507645.8A GB201507645D0 (en) 2015-05-05 2015-05-05 Load control of a transferable value or rights token
GB1507645.8 2015-05-05

Publications (1)

Publication Number Publication Date
WO2016178076A1 true WO2016178076A1 (fr) 2016-11-10

Family

ID=53489129

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2016/000584 WO2016178076A1 (fr) 2015-05-05 2016-05-06 Régulation de charge d'un jeton de valeur ou de droits transférable

Country Status (2)

Country Link
GB (1) GB201507645D0 (fr)
WO (1) WO2016178076A1 (fr)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB1417413A (en) 1971-12-09 1975-12-10 Celanese Corp Process for preparing aromatic polyamides
US20100235882A1 (en) * 2009-03-13 2010-09-16 Gidah, Inc. Method and system for using tokens in a transaction handling system
US20140337235A1 (en) * 2013-05-08 2014-11-13 The Toronto-Dominion Bank Person-to-person electronic payment processing
US20140337206A1 (en) * 2013-05-10 2014-11-13 Albert Talker Electronic Currency System
US20140358786A1 (en) * 2013-05-28 2014-12-04 The Toronto-Dominion Bank Virtual certified financial instrument system
US20150120536A1 (en) * 2013-10-31 2015-04-30 Albert Talker Electronic payment and authentication system
WO2016051259A1 (fr) * 2014-10-02 2016-04-07 Tibado Limited Jeton de valeur ou de droits transférable

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB1417413A (en) 1971-12-09 1975-12-10 Celanese Corp Process for preparing aromatic polyamides
US20100235882A1 (en) * 2009-03-13 2010-09-16 Gidah, Inc. Method and system for using tokens in a transaction handling system
US20140337235A1 (en) * 2013-05-08 2014-11-13 The Toronto-Dominion Bank Person-to-person electronic payment processing
US20140337206A1 (en) * 2013-05-10 2014-11-13 Albert Talker Electronic Currency System
US20140358786A1 (en) * 2013-05-28 2014-12-04 The Toronto-Dominion Bank Virtual certified financial instrument system
US20150120536A1 (en) * 2013-10-31 2015-04-30 Albert Talker Electronic payment and authentication system
WO2016051259A1 (fr) * 2014-10-02 2016-04-07 Tibado Limited Jeton de valeur ou de droits transférable

Also Published As

Publication number Publication date
GB201507645D0 (en) 2015-06-17

Similar Documents

Publication Publication Date Title
US11423399B2 (en) Telecommunication system and method for settling session transactions
US20220277307A1 (en) Systems and methods for personal identification and verification
CN108492180B (zh) 资产管理方法及装置、电子设备
KR102636102B1 (ko) 블록체인 기반의 암호화폐를 위한 토큰을 검증하는 컴퓨터로 구현된 방법 및 시스템
EP3913890B1 (fr) Système et procédé d'authentification basée sur une chaîne de blocs
US20200145373A1 (en) System for blockchain based domain name and ip number register
CN111164594A (zh) 用于将去中心化标识映射到真实实体的系统和方法
CN111164935A (zh) 在基于区块链的私有交易中提供隐私和安全保护的系统和方法
CN111095865A (zh) 用于发布可验证声明的系统和方法
US20180287790A1 (en) Authentication of a transferable value or rights token
US20170243202A1 (en) Transferable value or rights token
US10867326B2 (en) Reputation system and method
US20240121230A1 (en) Systems and methods for generating and using secure sharded onboarding user interfaces
WO2016178074A1 (fr) Contrôle de stockage de jeton de valeur ou de droits transférable
CN117396866A (zh) 授权交易托管服务
WO2016178076A1 (fr) Régulation de charge d'un jeton de valeur ou de droits transférable
EP4432191A1 (fr) Unité émettrice de jeton sécurisé, unité fournisseur de services sécurisés, système de transaction de paiement électronique, procédé de fourniture de nouveaux jetons
EP4336776A1 (fr) Procédé et système pour faciliter un transfert d'actifs sécurisé
CN118586906A (zh) 安全服务提供商、安全钱包、发行一个或多个安全钱包的方法
Rubasinghe Transaction Verification Model for Peer-to-Peer Service-Oriented Digital Currency Transactions Based on the Foundation of Blockchain Architecture

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16728366

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16728366

Country of ref document: EP

Kind code of ref document: A1