WO2016178074A1 - Contrôle de stockage de jeton de valeur ou de droits transférable - Google Patents

Contrôle de stockage de jeton de valeur ou de droits transférable Download PDF

Info

Publication number
WO2016178074A1
WO2016178074A1 PCT/IB2016/000579 IB2016000579W WO2016178074A1 WO 2016178074 A1 WO2016178074 A1 WO 2016178074A1 IB 2016000579 W IB2016000579 W IB 2016000579W WO 2016178074 A1 WO2016178074 A1 WO 2016178074A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
value
pocket
pin
request message
Prior art date
Application number
PCT/IB2016/000579
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 WO2016178074A1 publication Critical patent/WO2016178074A1/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 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 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.
  • the intended receiving party of the token can successfully load the token to their pocket.
  • An aspect of the present invention is that it offers the users of the system an additional security feature such that loss or theft of the token is not a concern. It is always possible for a token to be duplicated, but a token can only be loaded once by the pocket controller.
  • the pocket controller is provided with an additional feature which may be optionally applied by the users to enforce the use of a secret PIN necessary for loading the token into the pocket by the pocket controller. The use of this PIN allows the users to ensure that the token value can only be loaded to a pocket associated with the intended recipient.
  • a user may optionally provide a secret PIN of arbitrary length but typically 4 or 6 digits.
  • the pocket controller may allocate a default value defined by the system which might be a null value or perhaps a value of 4 zeros but other values including alphanumeric sequences are possible.
  • the user-defined or default PIN value is included in the cryptographic check sums that are used to protect the integrity of the token. It is not necessary or desirable to include the PIN within the token itself unless protected for confidentiality.
  • the sender makes the recipient aware of the secret PIN value by some independent means, such as, for example, by means of a phone call or a text message or any other viable communications channel.
  • some independent means such as, for example, by means of a phone call or a text message or any other viable communications channel.
  • the receiver of the token loads the token into the pocket controller it will be necessary for them to also provide the secret PIN, which the pocket controller will include in the validation of the cryptographic check sums. In the event that no PIN is provided by the recipient, the pocket controller will assume the default value is to be used when checking the cryptographic check sums.
  • the pocket controller will allow a predefined number of attempts typically 4 although other values are possible. Alternatively, it is possible to allow an undefined number of attempts at entering the PIN.
  • the receiver of the token may exceed the number of allowed attempts at entering the PIN when loading the token into the pocket controller.
  • embodiments of the present invention may allow for the creator of the token to load it back into their own pocket.
  • the token database may store a reference code associated with the pocket from which the coin was created.
  • the pocket controller may allow the user authorised to access the original pocket from which the token was created to load it back into their pocket. This authority would allow the token to be reloaded into the source pocket even if the number of PIN attempts (by either the sending or receiving users) has been exceeded. It is clear that in these circumstances the token database also needs to store the value of the chosen secret PIN in order to be able to check the cryptographic checksums that are used to protect the token.
  • the receiver of a value token protected by a PIN may load the token into their pocket and then create a new one protected by a PIN that only they know. 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 valueof 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.
  • FIG. 3 is a sequence diagram that shows a process for reloading a token value to a 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 5 A.
  • 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 log 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 communications media 3 may be provided as any suitable combination of communications media capable of supporting messaging between user's devices 1 and the pocket controller 2.
  • the communications media 3 may include the public Internet.
  • Each person 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 Personal Identification Number (PIN) value that is either selected by the user, a default value or a null value.
  • PIN Personal Identification Number
  • the pocket controller device 2 may query the user to input or otherwise select a PIN value, for example as part of the token creation process.
  • the controller 6 accesses the pocket memory 9 and checks the appropriate pocket relating to the
  • 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.
  • 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.
  • the token can be further protected by the inclusion of the PIN value which is incorporated 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 PIN.
  • 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 a potential receiver of the token (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 load the value of the token into 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 the load operation.
  • the payee must also provide the correct PIN value, either with the token or subsequently during the load operation.
  • the controller 6 can use the check sum and the PIN to confirm the validity of the token and will change the token's status in the token log 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 available to the payee, and cannot be spent by the payee, until it has been vested in the pocket by the controller 6.
  • 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 can then send the second verification 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 second token to the controller 6.
  • the controller 6 can then check the validity of the second verification checksum 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 log 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 [0054]
  • step S2 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 with a chosen PIN value.
  • this PIN value may be a value selected by the payer, a default value, or a null value.
  • TIBADO may generate a new PIN value for 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 log 7.
  • the token information stored in the log 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") and the PIN.
  • 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 cheek-sum-forms-a Validation Certificate associated- with the token.
  • 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 all of these cases, at least one (and preferably both) of the cryptographic check sums includes the selected PIN.
  • TIBADO will store a hash of the PIN in the token log 7, rather than the PIN itself. This allows subsequent verification of the PIN by TIBADO, but prevents a hacker from discovering the PIN by attacking the token log 7.
  • 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 PIN value to the payer across the authenticated channel. Sending the PIN to the payer may be appropriate in cases in which the token is created using a PIN selected by TIBADO, rather than the payer.
  • the payer may (at step S6) end the Authenticated session with TIBADO.
  • the payer sends the token to the payee.
  • the token may be sent to the payee without the cryptographic check sum.
  • the PIN can be sent to the Payee by any agreed method such as text message, email, or the like. If desired, the PIN can be transmitted separately from the Token, for example at a different time or via a different mode of communication.
  • the payer and payee may previously agree upon a PIN value to be used for one or more subsequently-generated tokens. In this case, it is not necessary for the payer to send the PIN to the payee with the token.
  • 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.
  • the request may also include the ⁇ .
  • TIBADO may request he PIN from the payee following receipt of the token and check sum.
  • TIB ADO (at step S 10) checks the token log 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) and that the cryptographic check sum is valid which must include the PIN.
  • the first of these checks prevents the problems of "double spending” or duplication of tokens. If either of these checks fails, TIB ADO may reject the load request, and send a corresponding failure message to the payee.
  • TIBADO changes the state of the token in the token memory 7 to show the status as "loaded”, and also updates the token information in the log 7 to indicate the payee's pocket as the intended destination.
  • the controller 6 may also ensure the integrity of the pocket and token memories 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.
  • TIBADO 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.
  • the payer sends the validation certificate to the payee.
  • the validation certificate may take the form of a cryptographic check sum generated by TIBADO for the token.
  • 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 S 15) to check the previously received token, and, if the validation check is successful, TIBADO vests the token in the payee's pocket by marking the appropriate entry in the token log 7 as showing the token's new state of "spent", and updating the balance of the payee's pocket by the value of the token. If the validation check fails, TIB ADO may reject the load request, and send a corresponding failure message to the payee.
  • 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.
  • TIB ADO 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. In this case, the PIN is not required.
  • TIBADO 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 use the token ID to check the token log 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 of the token to the source pocket, then incrementing the destination pocket by the token value and resetting the token status to "spent".
  • This operation has advantages 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 log 7.

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)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (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 un code PIN afin de protéger leur propriété. 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 les utilisateurs ont besoin d'être authentifiés afin d'accéder à leurs poches et le code PIN doit être fourni avant que la valeur puisse être chargée dans une poche.
PCT/IB2016/000579 2015-05-05 2016-05-06 Contrôle de stockage de jeton de valeur ou de droits transférable WO2016178074A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GBGB1507643.3A GB201507643D0 (en) 2015-05-05 2015-05-05 Storage control of a transferable value or rights token
GB1507643.3 2015-05-05

Publications (1)

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

Family

ID=53489128

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2016/000579 WO2016178074A1 (fr) 2015-05-05 2016-05-06 Contrôle de stockage de jeton de valeur ou de droits transférable

Country Status (2)

Country Link
GB (1) GB201507643D0 (fr)
WO (1) WO2016178074A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3364363A1 (fr) * 2017-02-21 2018-08-22 Mastercard International Incorporated Cryptogramme de transaction

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2026266A1 (fr) * 2007-07-27 2009-02-18 NTT DoCoMo, Inc. Procédé et appareil pour effectuer des transactions déléguées
US20090261158A1 (en) * 2006-02-06 2009-10-22 Marcus Maxwell Lawson Authentication of cheques and the like
US20140006273A1 (en) * 2012-06-29 2014-01-02 Infosys Limited System and method for bank-hosted payments
WO2016051259A1 (fr) * 2014-10-02 2016-04-07 Tibado Limited Jeton de valeur ou de droits transférable

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090261158A1 (en) * 2006-02-06 2009-10-22 Marcus Maxwell Lawson Authentication of cheques and the like
EP2026266A1 (fr) * 2007-07-27 2009-02-18 NTT DoCoMo, Inc. Procédé et appareil pour effectuer des transactions déléguées
US20140006273A1 (en) * 2012-06-29 2014-01-02 Infosys Limited System and method for bank-hosted payments
WO2016051259A1 (fr) * 2014-10-02 2016-04-07 Tibado Limited Jeton de valeur ou de droits transférable

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
PILIOURA T: "Electronic Payment Systems on Open Computer Networks: a Survey", INTERNET CITATION, July 1998 (1998-07-01), XP002321091, Retrieved from the Internet <URL:http://citeseer.ist.psu.edu/349790.html> [retrieved on 20050314] *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3364363A1 (fr) * 2017-02-21 2018-08-22 Mastercard International Incorporated Cryptogramme de transaction
WO2018156333A1 (fr) * 2017-02-21 2018-08-30 Mastercard International Incorporated Cryptogramme de transaction
US11176547B2 (en) 2017-02-21 2021-11-16 Mastercard International Incorporated Transaction cryptogram

Also Published As

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

Similar Documents

Publication Publication Date Title
US20220277307A1 (en) Systems and methods for personal identification and verification
US11423399B2 (en) Telecommunication system and method for settling session transactions
US20170344983A1 (en) BIXCoin: A Secure Peer-to-Peer Payment System Based on the Public Payments Ledger
KR20180128968A (ko) 블록체인 기반의 암호화폐를 위한 토큰을 검증하는 컴퓨터로 구현된 방법 및 시스템
CN111164935A (zh) 在基于区块链的私有交易中提供隐私和安全保护的系统和方法
WO2018213880A1 (fr) Système pour registre de noms de domaine et de numéros ip basé sur une chaîne de blocs
KR20210040078A (ko) 안전한 보관 서비스를 위한 시스템 및 방법
EP3903267A1 (fr) Procédés, dispositifs et systèmes de sécurisation de paiements
CN109791660A (zh) 数据保护系统和方法
US20180287790A1 (en) Authentication of a transferable value or rights token
US20170243202A1 (en) Transferable value or rights token
CN115119531A (zh) 使用区块链事务的多因素认证
WO2016178074A1 (fr) Contrôle de stockage de jeton de valeur ou de droits transférable
Akbar et al. E-Voucher System Development for Social Assistance with Blockchain Technology
WO2016178076A1 (fr) Régulation de charge d&#39;un jeton de valeur ou de droits transférable
US11902266B1 (en) Systems and methods for generating and using secure sharded onboarding user interfaces
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: 16728365

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: 16728365

Country of ref document: EP

Kind code of ref document: A1