GB2528471A

GB2528471A - A method and system for secure payment

Info

Publication number: GB2528471A
Application number: GB1412998.5A
Authority: GB
Inventors: David Sallis; Hugh Pyle; T Rob Wyatt
Original assignee: Qredo Ltd
Current assignee: Qredo Ltd
Priority date: 2014-07-22
Filing date: 2014-07-22
Publication date: 2016-01-27
Also published as: GB201412998D0

Abstract

A first user 112A sends a balance object including their account balance to an issuer 103 e.g. a bank with a balance adjustment request or to an operator 102 with a voucher request via public network 109 e.g. the internet. Where a balance adjustment request is sent the message may include e.g. card or account details to allow funds to be transferred into or from the users account. The issuer updates the balance object with the new account balance and returns it to the user. Where a payment is to be made to a second user 112B the operator 102 updates the balance object according to the voucher value and generates a new voucher for return, with the updated balance object to the first user, who provides the voucher to the second user. The second user sends the voucher and a balance object including the second users account balance to the operator for suitable account balance adjustment. The balance object and vouchers may be hashed to avoid fraud or double patenting and may include signatures. Communications are encrypted using public/private key pairs. Thus payments may be made anonymously, the first and second users not needing to share personal information.

Description

A Method and System for Secure Payment

FIELD OF THE INVENTION

The present invention relates to methods and systems for secure payments.

BACKGROUND TO TilE INVENTION

Existing electronic payment solutions require parties to a transaction, usually the payee, to divulge at least some information concerning their identity to other parties of the transaction. As such, parties to a transaction leave themselves open to the risk that their identity may be ascertained by third parties. In certain jurisdictions, a certain degree of traceability is a legal requirement. In other jurisdictions, any degree of traceability is positively undesirable.

There exists a need for an electronic payment system providing complete anonymity to all parties of a transaction whilst having the necessary transaction traceability where t5 circumstances require.

SUMMARY OF THE INVENTION

According to a first aspect of the invention there is provided a method of issuing a voucher in a system for secure payments, comprising: receiving a balance object and a voucher request from a first user device at an operator server, wherein the balance object includes a first user balance and the voucher request includes a voucher amount; the operator server updating the balance object to reflect the amount of the voucher; the operator server generating a voucher object including the voucher amount; transmitting the updated balance object and the voucher object from the operator server to the first user device.

According to a second aspect of the invention there is provided an operator server for use in a system for secure payments, the server arranged to: receive balance objects and voucher requests from a first user device, wherein the balance objects include first user balances and the voucher requests include voucher amounts; update balance objects to reflect the amounts of the vouchers, to generate voucher objects including the voucher amounts, and to transmit the updated balance objects and the voucher objects to the first user devices.

According to a third aspect of the invention there is provided a method of redeeming a voucher in a system for secure payments, comprising: receiving a balance object and a voucher object from a second user device at an operator server, wherein the balance object includes a second user balance and the voucher object includes a voucher amount; the operator sewer updating the balance object to reflect the amount of the voucher; transmitting the updated balance object from the operator server to the second user device.

According to a fourth aspect of the invention there is provided an operator server for use in a system for secure payments, the server arranged to: receive balance objects and voucher objects from a second user device, wherein the balance object includes a second user balarice and the voucher obj ect includes a voucher amount; update the balance object to reflect the amount of the voucher, and to transmit the updated balance object to the second user device.

According to a fifth aspect of the invention there is provided a method of updating a balance object in a system for secure payments, comprising: receiving a balance object and a balance change request from a user device at an issuer server, wherein the balance object includes a user balance; carrying out a predetermined action to effect the balance change request; updating the balance object to reflect a change in the user balance; transmitting the updated balance object from the issuer server to the user device.

According to a sixth aspect of the invention there is provided an issuer server for use in a system for secure payments, the server arranged to: receive balance objects arid balance change requests from a user device, wherein the balance objects include user balances; carry out a predetermined action to effect a balance change request; update the balance objects to reflect a change in user balances; and transmit updated balance objects to the user device. n j

Further features of the present invention are defined in the appended set of daims.

Advantages of these and other aspects of the present invention are recited below in the

detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention will now be described, by non-limiting example only, with reference to the accompanying drawings, in which: Figure 1 is a schematic diagram of a secure payment platform in accordance with an embodiment of the present invention; Figure 2 is a schematic diagram of a user device which forms part of the secure payment platform of the present invention; Figure 3 shows payment software for use with the user device shown in Figure 2; Figure 4 shows a balance object for storing user balance details for use on the payment platform of the present invention; Figure 5 shows a voucher object for storing transaction details for use on the payment platform of the present invention; Figure 6 shows an operator domain which forms part of the secure payment platform of Figure 1; Figure 7 shows an issuer domain which forms part of the secure payment platform of Figure 1; Figure 8 is a flowchart showing a process for enrolling a new user of the secure payment platform of Figure 1; Figure 9 is a flowchart showing a process for processing a balance change request performed by the issuer sewer which forms part of the secure payment platform showninFigurel; Figure 10 is a flowchart showing a process for verifying a balance change request; Figure 11 is a flowchart showing a process performed by an issuer for updating a balance object; Figure 12 is a flowchart showing a process for processing a voucher request performed by the operator server which forms part of the secure payment platform shown in Figure 1; Figure 13 is a flowchart showing a process for verifying a voucher request; Figure 14 is a flowchart showing a process performed by an operator for updating a balance object; Figure 15 is a flowchart showing a process for generating a voucher in response to a voucher request; Figure 16 is a flowchart showing a process performed by an operator for returning a balance object and a voucher object to a user in response to a voucher request; Figure 17 is a flowchart showing a process performed by a user for receiving and preparing a voucher object for redemption at an operator; Figure 18 is a flowchart showing a process performed by an operator for redeeming the value of a voucher object; and Figure 19 is a flowchart showing a process performed by an operator for verifying a balance object and a voucher object.

DESCRIPTION OF EMBODIMENTS OF THE INVENTION

Figure 1 is an overview of a secure payment platform 100. The secure payment platform 100 includes four primary domains. The secure payment platform 100 includes a user domain 101, an operator domain 102, an issuer domain 103 and an S optional enrolment domain 115. Users are individuals and organisations who wish to transfer money to other users using the secure database platform 100. In this context, the term "money" represents any type ofobject of verifiable record that is accepted as payment for goods and services and repayment of debts in any jurisdiction or socio-economic context. Money may be physical or virtual. Issuer organisations may, for example, be financial organisations such as banks. Operator organisations may be operable to operate the payment platform 00 and issue voucher objects 306 to users as part of a transaction, as will be described in more detail below. Operator organisations may be separate or connected to issuer organisations. In Figure 1, the operator domain 102 and the issuer domain 03 have been represented as separate domains. It will, however, be appreciated that an operator and issuer may in some circumstances be the same entity and/or share a domain. In which case, the operator domain 102 and the issuer domain 103 may be the same domain. Operators and issuers provide the central components of the secure payment platform 100, which enable users to transfer money to and from each other by securely storing and sharing data.

The operator domain 102 includes the systems hosted by the operators to enable payments between users to take place. In the present embodiment, there is a single operator. It will be appreciated, however, that there may be many operators, each providing competing service packages for access to a common set of services, The secure payment platform 100 includes operator sewer 104. The operator server 104 is hosted by the operator and is coupled to a public network 109. The public network 109 may be the Internet, The operator sewer may communicate with devices in the user domain via the public network 109. The operator server may issue voucher objects to user in response to a voucher request received from a user over the public network, Such voucher objects may be used by users to make a payment to other user(s) of the payment platform 100. The operator domain 102 also includes an operator main database 110, which is connected to the operator sewer 104. The operator main database 110 is for storing repositories related to voucher objects and balance objects (described in more detail below).

The issuer domain 103 includes the systems hosted by the issuer to enable a user to exchange finds for a balance which can be used for payment using the secure payment platform too (described in more detail below). Any funds may be exchanged for a balance in the secure payment platform 100 (regulated or otherwise), subject to limitations imposed by the issuer. The secure payment platform 100 includes issuer server 106. The issuer sever is hosted by the issuer and is coupled to to the public network 109. Like the operator server 104, the issuer server 106 may communicate with devices in the user domain 101 via the public network 109. The issuer domain 103 also includes an issuer database 07, which is connected to the issuer server 106 and is used for storing repositories of data relating to voucher objects and balance objects.

The user domain 0l includes one or more user devices LI2A, I 12B which may be controlled by users of the payment system 100. The user devices 1 12A, 1 12B are also coupled to the public network 109. The user devices II 2A, 11 2B may be cell phones, tablet computers, laptop computers, desktop computers or other computers. in the present embodiment, the user devices I 2A, I l2B are computing devices such as those described above. It will be appreciated by the skilled person that the user devices 1 12A, 1 12B may also be multiple user devices such as vending machines.

The user devices 1 12A, 1 12B may be coupled to the public network 109 via a local area network (LAN) or a wireless network. The user domain 101 also includes a user data store 114 for storing user data including balance objects and voucher objects.

The user data store may be located remotely from the user devices 112 but accessible from the user devices 112 via the public network 109 or otherwise.

In some embodiments, the secure payment platform 00 may include the enrolment domain 115 mentioned above. The enrolment domain 115 includes an enrolment interface 113. Tt will be appreciated that the enrolment domain 03 may include multiple enrolment centres. The enrolment interface 113 is typically run and hosted by an operator or issuer, It is where new users may sign up to use the secure payment platform 100. The enrolment interface 113 may be in the form of a webpage which new users can access via the public network 109 to which the enrolment terminal 114 is coupled. The enrolment interface may be accessible via a user device 112. The enrolment domain fl5 is shown separately to the issuer domain 03 and the operator S domain 102 in Figure 1. However, it will be appreciated that the enrolment domain may be integrated into either of the operator or issuer domains 102, 103.

When a user is set up to use the secure database platform 100, a user repository is established on user data store 114. This is where user data is securely stored. The user repository may be encrypted with a user encryption key, and located by a user repository identifier. The user encryption key and the user repository identifier may stored only in a user keychain on a user device 12 and accessible only to the user.

Accordingly, only the user is able access or locate their secure user repository.

Further details of these aspects of the invention will now be described.

Figure 2 is a schematic diagram of a user device 112. In this embodiment, the user device 112 is a cell phone 112A. The user device 112 includes a processor 200, memory 201, data storage 202, a bus 203, a display 204, an input device 205, such as a touchscreen or a keyboard, and a communications interface 206. These components operate in the manner familiar to a person skilled in the art, The user device 112 includes secure payment software 300. This is shown in Figure 3. The payment software 300 is stored in data storage 202, md is configured to run on processor 200 when the user device 112 is in use. The access software 300 includes a control panel 301. The control panel 301 is a user interface which a user uses to operate the payment software 300. The payment software also includes a store 302. The store 302 is used to store user keychains (public and private keys) and, temporarily, balance objects and voucher objects. More permanent storage of balance object and voucher objects is achieved using the user data store 114, In this example, the store includes a single user keychain 303, a single balance object 305 and a single voucher object 306.

Each of the user keychain 303, the balance object 305 and voucher object 306 may themselves be encrypted using a passphrase or otherwise protected, for example using biometric authentication. Both the voucher object 306 and the balance object 305 contain several other elements, as will be described in more detail below, As mentioned above, balance objects and voucher objects (if in existence) are stored in the user data store 114 during their lifetime. However, when the payment software 300 manipulates balance objects and voucher objects, they may be stored on the user device, for example in the store 302.

Figure 4 shows a balance object 305 in accordance with an embodiment of the present invention. The balance object includes a balance amount 401. The balance amount 401 represents the amount of money that a user has available for payment using the payment system 100, i.e. a user's balance. The balance may be positive or negative.

The balance object 305 can only be modified by the operator server 104 or the issuer server 106. The operator server 104 may modify the balance object 305 when issuing a voucher object 306 to reflect the transfer of funds to another user via the issued voucher object 306. The issuer server 106 may modify the balance object 305, e.g. to update the balance amount 401, when funds are transferred to or from the related issuer organisation. The balance object 305 may further comprise a timestamp 402.

The timestamp 402 is updated each time the balance object 305 is modified in the operator domain 102 or the issuer domain 103. For example, the timestamp 402 may be updated to reflect the time of modification of the balance object 305 by the operator server 104 or the issuer server 106. The balance object may further include a digital signature 403. The digital signature 403 may be used to verify the origin of the balance object 305 and ensure it has not been tampered with when being sent between parties of the payment system 100, The digital signature may only be modified by the operator server 104 or the issuer server 106 when signing the balance object 305.

Finally, the balance object may include a currency identifier 404. The currency identifier 404 may represent the denominated currency that the balance amount represents. Monetary currencies may include fiat (e.g. regulated) currencies such as United States dollars (USD) or pounds sterling (GBP), or virtual currencies such as bitcoins, Figure 5 shows a voucher object 306 in accordance with an embodiment of the present invention. Voucher objects represent a sum of money which can be transferred between users of the secure payments system 100. They are issued by the operator in response to a voucher request from a user of the secure payment system 100. They can also be amended or cancelled by the operator in various circumstances, as will be described in more detail below. The voucher object 306 includes a voucher amount 501. The voucher amount represents the value of the voucher obj ect 306. The voucher amount 501 may be positive or negative. The voucher amount 50] can only be updated by the operator, for example, when the operator generates, amends, cancels or disposes of the voucher object 306. The voucher object 306 may thrther comprise a timestamp 502 which, like the timestamp 402 of the balance object, is updated each time the voucher object 306 is modified. The voucher object 306 may further include a digital signature 503 equivalent to that of the balance object, and a currency identifier 504 which indicates the currency that the voucher object 306 represents.

Figure 6 shows various elements of the operator domain 102. In particular, as mentioned above, the operator domain includes operator main database 110 having one or more repositories. The operator main database 110 includes, in particular at least one operator hash heap 600. The hash heap 600 contains data pertaining to balance objects or voucher objects which the operator handled previously or within a historic time frame, The operator hash heap 600 may, for example, contain hashes of such balance objects and voucher objects. Hash functions will be within the knowledge of the skilled person. Hashed data stored in the hash heap 600 may be hashed with hashing algorithms such as SHA-] or any other suitable functions known in the art.

Figure 7 shows various elements of the issuer domain 103. In particular, the issuer domain includes issuer database 107 having one or more repositories. The issuer database 107 includes, in particular at least one issuer hash heap 700. The issuer hash heap 700 contains data pertaining to balance objects which the issuer has handled previously, e.g. within a historic time frame. Like the operator hash heap 600, the issuer hash heap 700 may contain hashes of the previously handled balance objects.

Hash functions will be within the knowledge of the skilled person. The issuer database 107 has one or more additional repositories 701 to temporarily record data pertaining to withdrawal or deposit requests from users (described in more detail below). The issuer domain 103 may provide a portal to allow users to communicate with the issuer domain 103 for the purpose of depositing or withdrawing funds which will affect their balance object. This portal may be in the form of a website hosted by the issuer domain 103. In which case data pertaining to the website may be stored in a further, portal repository 702 on the issuer database 107.

In order to maintain the security of the secure payment platform 100, data sent over the public network 109 between the user domain 101 and both the operator domain 102 must be encrypted. The skilled person will be aware of various suitable encryption techniques. Techniques described herein use public-private key pair encryption to send data across the public network 109. As such, each user or the payment platform 100 together with the operator and the issuer may make available on the public network 109 a public key which the other parties may use to encrypt data before it is sent across the public network 109. Corresponding private keys are then held within the security of the parties' respective domains, for example in respective databases of those domains. Alternatively, public keys may be sent between parties as and when they are required to return information to the initiator of a conversation, Public keys generated by the parties, particularly users, may be permanent keys or one off (nonce keys. Where nonce keys are used, parties may send a nonce public key each time it is required or may such keys permanently available on the network 109. It will be appreciated that alternative encryption techniques could be used without departing from the scope of the present invention.

The process by which the user enrols with the secure payment platform 100 will now be described with reference to Figure 8. A user enrols with the secure payment platform 100 using the enrolment centre 113. Firstly, the user may request to enrol with the secure payment platform 100 using a device 112 in the user domain 101 (S800). At this step the user generates a user public key of a user key pair and sends this public key to the enrolment centre 113 via the public network 109. The enrolment centre 113 then generates a new balance object (S801). The new balance object has the structure of the balance object described with reference to Figure 4. The new balance object is issued with a balance 401 of zero, the timestamp 402 is updated to reflect the time of issue, the currency 404 is set and the new balance object is digitally signed by the operator (S802). The new balance object is then encrypted by the enrolment centre 113 using the user public key (S803) and the encrypted balance ii object is returned to the user via the public network 109 (S804). It will be appreciated that once the new balance object is returned to the user, no private information associated with the user has been shared with the enrolment centre; only an address for the user which is required to send the balance object to the user. It will also be appreciated that the enrolment centre maybe integrated into the issuer server, or the functions of the enrolment centre may in alternative embodiments be entirely performed by the issuer server 106 or the operator server 104 during or before depositing or withdrawal of fUnds, described below.

An overview of the process by which a balance object 305 is updated by the issuer to reflect a withdrawal or deposit of funds from an ahernative money source for use on the secure payment platform 100 will now be described with referenced to Figure 9.

At any time, during or separate from the following process, the user may transfer funds to or from the issuer. The deposit or withdrawal of funds may be performed by balance transfer, credit or debit card payment or any other suitable method for transferring physical or virtual money to or from the issuer, The deposit or withdrawal may be performed via the user device 112 over the public network 109. For example, the payment software 300 running on the user device I U may interact with the portal of the issuer domain 103 to send, for example, credit card details or bank account details to the issuer, In this respect, withdrawal and deposit of fUnds into and out of the payment system 100 are the only transactions which require a user to provide his identity. A user may wish to update the balance amount 401 of his balance object 305, either by transferring funds to the issuer such that the balance amount 401 of the balance object 305 increases, or by receiving funds from the issuer, such that the balance amount 401 decreases, A user may deposit funds held in his balance object 305 to an alternative monetary system, e.g. into a bank account, after a payment has been made to his balance object 305 using the secure payment platform 100 using one or more voucher objects (described in more detail below). A user may also transfer funds to the issuer and as such increase the balance amount 401 held by his balance object 305 when he wishes to make a payment using the payment platform 100.

When the user wishes to update his balance object 305, the user device 112 sends a balance change request to the issuer sever 106 over the public network 109 (S901).

The balance change request includes the user's balance object 305 encrypted with an issuer public key provided by the issuer, a user public key and an amount and currency to be deposited or withdrawn from the secure payment platform 100, The amount of the balance change request may be positive, indicating a request to add to S the balance amount 401 represented by the balance object 305, or negative indicating a request to reduce the balance amount 401 represented by the balance object 305.

The request may also include bank account, debit/credit card details or other details which enable a transfer of ftinds to or from the issuer, which may or may not be equivalent to the amount specified in the balance change request. On receipt by the issuer server 106, the balance change request is verified by the issuer server 106 (S902). Once verified, the issuer server 106 then updates the balance object 305 using information contained in the change request (S903) and returns the updated balance object 305 to the user device 112.

The process of verifying the balance obj ect 305 is shown in detail in Figure 10. The issuer server 106 decrypts the balance object using an issuer private key corresponding to the issuer public key (SlOOl). The issuer server 106 then verifies that the signature on the balance object matches that of the party that most recently modified the balance object 305 (S 1002). This might be the enrolment sewer 113, the operator sewer 104 or the issuer sewer 106. If the signature is not authenticated, then the process ends (S 1003). If the signature is authentic, the issuer sewer 106 then generates a hash of the balance object (S 1004) and checks to see whether an identical hash exists on the issuer hash heap 700 (S 1005). If an identical hash is already present on the issuer hash heap 700, the process ends (S 1006) since this indicates that an identical balance object has already been handled by the issuer server 106. This suggests that the balance object being presented to the issuer sewer 106 is not genuine or is a duplicate. If the hash of the balance object 305 is not present on the issuer hash heap 700, the issuer server 106 then checks whether or not the amount of funds deposited by the user is greater than or equal to the amount of the balance change request (S 1007). If the quantity of deposited funds is less than that of the balance change request amount, the process ends since insufficient thnds have been transferred to thifil the user's balance change request (S1008). If on the other hand the quantity of deposited funds is sufficient to flulfil the balance change request, the issuer 106 moves onto the next step of updating the balance object 305 (S903).

Whilst in the above embodiment the process ends where it is found that insufficient funds are available to underwrite the balance change request, in other embodiments the issuer sewer 106 may update the balance object 305 to reflect the change request even if the amount exceeds the amount of deposited funds. For example, the user may agree an overdraft facility on his or her account with the issuer such and the process will not end at all or will not end unless the deficit between the deposited fhnds and the amount of the balance change request exceeds a predetermined value, The process of updating the balance object 305 is shown in detail in Figure 1. Once the issuer hash heap 700 has been checked for duplicate balance object hashes as described with reference to Figure 10, the balance object hash is placed on the issuer hash heap 600 such that future balance change requests queried by the issuer sewer and comprising an identical balance object will fail (SI 101). The balance amount 401 is then updated to reflect the amount of the balance change request and the timestamp 402 of the balance object is updated to reflect the current date and time (S 1102). The balance object 305 is then digitally signed by the issuer server 106 so that other parties may verify the origin of the balance object 305 (S1103). The issuer sever 106 may sign the balance object using the issuer private key. Finally, the issuer sewer 106 encrypts the balance object 305 using the user public key (S1104) before the balance object is returned to the user via the public network 109 (S904).

The secure payment platform 100 operates to securely transfer funds in the way of voucher objects between users, For example, when one user (referred to herein as a first user) wishes to transfer money to another user (referred to herein as a second user), the first user may do so by way of a voucher object 306 designating an amount and denominated currency to be transferred to the second user using the payment platform 100. As mentioned above, voucher objects 306 are generated by the operator sever 1 04 in response to a voucher request from a user.

Figure 12 shows an overview of the process for generating a voucher object 306. The first user (the user who wishes to implement a transaction) sends a voucher request together with his balance object 305 to the operator server 104 using a user device 112 (S 1201). Additionally, a first user public key, which may be a nonce key, is generated by the first user using a device 112 or otherwise and is either sent directly to the operator server 104 or made available to the operator server 104 over the public network 109. Equally, a second user public key, which may also be a nonce key, is generated by the second user in a similar manner. The balance object 305 is encrypted using the operator public key. The voucher request includes information concerning the amount and currency of the voucher object 106 requested. The voucher request may also be encrypted using the operator public key. Upon receipt of the voucher request and balance object 305 from the first user, the operator server 104 verifies the authenticity of the voucher request (S 1202) as will be described in more detail below.

Upon verification the operator server 104 updates the balance object to reflect a transfer of funds from the balance object 305 to the new voucher object (51203), This may include adding the amount of the new voucher object 306 to the balance amount stored in the balance object 305. Additionally and not necessarily after updating the balance (step S 1202), at step S 204 the operator server 104 generates a voucher object 306. This voucher object is then encrypted and returned along with the balance object to the first user at step S1205.

The process of verifying the balance obj ect 305 is shown in detail in Figure 13. The issuer server 106 decrypts the balance object using an operator private key corresponding to the operator public key (S1301). The operator server 104 then verifies that the signature on the balance object matches that of the party that most recently modified the balance object 305 (S 1302). This might be the operator or the issuer. If the signature is not authenticated, then the process ends (S1303). If the signature is found to be authentic, the operator server 104 then generates a hash of the balance object (SH04) and checks to see whether an identical hash exists on the operator hash heap 600 (S 1305). If an identical hash is already present on the operator hash heap 600, the process ends (S 1306) since this indicates that an identical balance object has already been handled by the operator server 104. This suggests that the balance object being presented to the operator server 104 is not genuine. If the hash is of the balance object 305 is not present on the operator hash heap 600, the operator server 104 then checks whether or not the balance amount 401 represented by the balance object 305 are greater than or equal to the amount of the voucher request (S 1307). If the balance amount is less than that of the voucher request amount, the process ends since the balance obj ect contains an insufficient balance amount to fUlfil the first user's voucher request (S1308). If on the other hand the balance amount 401 is sufficient to fulfil the voucher request, the operator server 104 moves onto the next steps of generating a voucher request (S 1204) and updating the balance object (S 1203). I0

The process of updating the balance object 305 is equivalent to that described with reference to Figure II in relation to the issuer server 106. Figure 14 describes the process of updating the balance object 305 performed by the operator server 104. The balance object hash is placed on the operator hash heap 600 such that future balance objects queried by the operator server 104 which are identical to the present balance object will cause the process to fail (S40l), The balance amount 401 is then updated to reflect the amount of the voucher request and the timestamp 402 of the balance object is updated to reflect the current date and time (S1402). The balance object 305 is then digitally signed by the operator server 104 so that other parties may verify the origin of the balance object 305 (S1403). The operator sever 104 may sign the balance object using the operator private key. Finally, the operator server 104 encrypts the balance object 305 using the user public key (S 1404) before the balance object 305 is returned to the user via the public network 109 at step S 1205 of Figure 12.

The process of generating a voucher object will now be described in detail with reference to Figure 15. The operator sewer 104 generates a voucher object 306 having a voucher amount and a currency equal to that of the voucher request together with a timestamp (S1501). The timestamp is set to the current date and time. The operator sewer 104 then generates a hash of the voucher object 306 (S1502) which is placed on the operator hash heap 600 (S1503). Placing the voucher hash on the operator hash heap 600 before issuing the voucher prevents the multiple redemption of the voucher object 306, also referred to herein as "double dipping".

Referring again to Figure 12, the step of returning the updated balance object and voucher object back to the first user (step S 1205) will now be described with reference to Figure 16. The updated balance object is signed by the operator server 06 so that the first user can verify that origin of the balance object upon receipt (S 1601). In some embodiments, the balance object is signed using the operator private key. The balance object is then encrypted using the first user public key at step (S 1602). The newly generated voucher is also signed by the operator sever 106 using, for example, the operator private key, and subsequently encrypted using the second user public key (S 1604). Both the updated balance object and the voucher object are then returned to the first user via the public network 109.

Upon receipt of the voucher object encrypted with the second user public key, the first user may send the voucher object in any suitable manner to the second user. For example, the first user may send the voucher object using a user device 112 to the second user, also using a user device 112. Both devices may or may not be within the user domain. The voucher object may be sent using Secure Socket Layer (SSL) file transfer or using methods described in the applicant's International patent application The process of voucher redemption will now be described in relation to the second user, with reference to Figures 17 and 18. Having successfully received a voucher object encrypted with the second user public key from the first user, using a user device 112 the second user decrypts the voucher object with a corresponding second user private key (S1701), The second user then validates the signature on the voucher object (S702), If the voucher object is signed by the operator using the operator private key, then the validation will involve using the operator public key to check the authenticity of the voucher, and whether or not the voucher has been tampered with during transfer from the operator server 104 to the second user's device via the first user's device. Provided the signature is authenticated at step S1702, the second user then encrypts the unencrypted voucher object and his personal balance object using the operator public key (S 1704, S 1704) and the encrypted balance and voucher objects are sent using the second user's device 112 to the operator sewer 104 over the public network 109 (S 1705).

Referring now to Figure 18, the operator server 04 receives the balance and voucher objects 305, 306 from the second user (S 1801) and verifies the authenticity of the balance and voucher objects (51802) which will be described in more detail below.

The operator sever 104 then updates the balance object to reflect the voucher amount of the voucher object 306 (S 1803), in other words adding the voucher amount 501 to the balance amount 401 in the balance object 305. The general process is identical to tO the balance update process described above with reference to Figure 14. The operator server 104 then disposes of the used voucher object (1804), and returns the updated balance object to the second user (S 1805).

The step of verifying the balance and voucher objects 305, 306 (51802) will now be tS described with reference to Figure 19. Having received the balance and voucher objects 305, 306, the operator server 104 decrypts both using the operator private key.

The operator sewer 104 then verifies that the signature on the balance object 305 matches that of the party that most recently modified the balance object 305 (S1902).

This might be the operator or the issuer, if the signature is not authenticated, then the process ends (S 1903). If the signature is authentic, the operator server 104 then generates a hash of the balance object (S 1904) and checks to see whether an identical hash exists on the operator hash heap 600 (S 1905). If an identical hash is already present on the issuer hash heap 600, the process ends (S1903) since this indicates that an identical balance object has already been handled by the operator sewer 104. If the hash of the balance object 305 is not present on the operator hash heap 600, the operator sewer 04 then repeats this verification process for the voucher obj ect 306.

The operator sewer 104 verifies that the signature on the voucher object 306 matches that of the party that most recently modified the voucher object 306 (SI 906), in this case the operator sewer 104. If the signature is not authenticated, then the process ends (S1903). If the signature is authentic, the operator sewer 104 then generates a hash of the voucher object (S 1907) and checks to see how many identical hashes exists on the operator hash heap 600 (S 1908). A hash of the voucher object 306 was placed on the hash heap upon generation of the voucher object 306 (see Figure 15 and accompanying description). Accordingly, provided that the voucher object has not previously been used, the number of identical hashes should be equal to 1. If the number of identical hashes present on the operator hash heap 600 is not equal to 1, the process ends (S903) since this indicates that an identical voucher object has already been processed ("cashed in") by the operator server 104. If the number of identical hashes present on the operator hash heap 600 is equal to 1, the operator server 104 moves onto the next step of updating the balance object 305 (S 1803).

The process described with reference to Figures 12 to 16 generates a voucher which can only be redeemed by the second user, since the voucher object is encrypted by the second user's public key. In some circumstances, however, the first user may wish to issue himself with one or more voucher objects which he is able to redeem at a later date. Accordingly, in another embodiment, the first user, when sending a voucher request, may identify himself as the recipient of the voucher. In which case, the step of Figure 16 of encryptingthevoucherobjectwiththe second user public key (51604) is replaced with the step of encrypting the voucher object with the first user public key. The result is a voucher object which the first user can store and use at a later date. A user of the secure payment system 100 is then able to carve off voucher objects of arbitrary value from his or her balance which he or she can then redeem, combine or refresh at any time in the future, The process of redeeming the voucher object 306 at the operator server 104 performed by the first user is identical to that described above in relation to the second user (Figures 17 to 19 and accompanying description), apart from that the balance and voucher objects 305, 306 must of course be decrypted using the first user public key.

There may be circumstances in which a user has multiple vouchers, It will be appreciated that multiple iterations of the above described voucher redemption process can integrate any number of voucher objects into a single balance object.

The issuer hash heap 700 and the operator hash heap 600 have been described above as separate hash heaps. However, it some embodiments these hash heaps 600, 700 may combined as one. Equally, whilst in embodiments described above balance object hashes and voucher object hashes are placed on the same hash heap, in other embodiments balance object hashes may be placed on a separate hash heap to that upon which voucher objects are placed. It will, however, be appreciated that cryptographically strong hashes are sufficiently unlikely to collide that the system can operate with a single hash heap for all hashes generated by all parties.

It will also be appreciated that as the secure payment platform 100 gains more users the number of entries in the hash heap will continue to increase without limit.

Accordingly a scalability problem exists in that a hash heap may become too large to effectively search when veri,'ing authenticity of a voucher or balance object.

Techniques such as Bloom filtering may be used in some circumstances to quickly search through multiple entries for matching hashes, However, even using such techniques there are working limits to the size of any one hash heap.

One solution to this problem is to configure each voucher object such that it expires after a predetermined amount of time or when a predetermined condition is met.

Accordingly, in some embodiments, vouchers may be issued in blocks, each block having, for example, a start and end time, Voucher objects can then be grouped into issue blocks depending upon which block they were issued in, Additionally or alternatively, voucher objects may be grouped using other metrics, such as a limit on the number of voucher objects issued within each block, i.e, when a threshold amount of voucher objects have been issued in the current block, a new block is started.

To implement voucher expiry, the operator may create an individual signature key for each "issue block", herein referred to as an issue block key. Each issue block may represent a time frame, such as a calendar month, All voucher objects generated within that time frame are then issued and signed with the issue block key associated with the corresponding issue block. Additionally, when a balance object is updated, it is signed using the current issue block key, The operator and issuer may then, individually or in partnership, operate hash heaps each only containing hashes of voucher and balance objects issued or updated in the current issue block, i.e. those signed with the current issue block key. By doing so, the size of the hash heap is limited to amount of voucher and balance objects issued or updated in the issue block time frame.

The use of issue blocks and voucher expiry provides several advantages. By keeping a count of the number of voucher objects issued in a block, an operator or issuer can see that all voucher objects in an issue-block have been redeemed, so that the corresponding hash heap can be discarded. Additionally, an operator or issuer can track the value of each issued voucher object which has yet been redeemed and so is able to report the outstanding assets for each issue block. Voucher expiry also provides protection against data loss by reducing the amount of outstanding currency that might be lost in a service catastrophe and enables the issuer to report the value of outstanding vouchers by age, or by other metrics if each block is determined by other metrics.

The payment software 300 operating on user devices is preferably configured to always redeem older voucher obj ects first in the case that a user's data contains multiple vouchers.

A variation of the process described above for managing hash heap size using voucher object expiry may be used to change the denominated currency of a voucher, This may be required, for example, where a user has received a voucher object having one currency, and wishes to update a balance object having another currency. The process differs from that described above in that instead of, or in addition to signing voucher objects using an issue block key related to a time frame associated with voucher object generation, the operator signs each voucher object with a different signature key (herein referred to as a currency key) which depends on the currency they represent.

Accordingly, when a user wishes to change the denominated currency of a voucher object, the operator or issuer may convert the voucher amount into the currency into which the voucher object is to be converted and resign the voucher object using the new currency key, It will be appreciated that each voucher object may be signed using multiple signatures for different dimensions (time frame, currency etc). The operator or issuer can then build several reporting metrics, at the expense of maintaining a hash heap for each dimension, In some embodiments, voucher objects may be issued by different operators. For example, a first user may wish to deal with a first operator, e.g. Acme Corp and a second user may wish to deal with a second operator, e.g. Bright Corp. In such circumstances the first user may forward a voucher obj ect generated by the Acme Corp to the second user who then wishes to redeem this voucher object using the second operator, Bright Corp. However, in embodiments described above, each operator has a separate hash heap. In this circumstance, the second operator would not be able to veri,' the voucher object issued by the first operator without access to the information in the first operator's hash heap. Accordingly, there exists a requirement for Acme Corp and Bright Corp to share data concerning the voucher objects they create with each other, Such data may include the entire voucher.

Alternatively only the hash of the voucher may be shared between Acme Corp and Bright Corp (e.g. for the purpose of checking for its existence only). This may be realised using a direct trust exchange between multiple operators or using direct communication channels between operators for verifying vouchers.

The payment system described above offers complete anonymity between parties of to a transaction. The first and second users need not transfer any personal information to one another, Additionally, because user balance objects are held in an independent user data store 114, neither the operator nor the issuer have knowledge of the user's balance or of his transactions, Whilst the issuer may have some knowledge of a user's identity from withdrawal and deposit of funds, the issuer has no knowledge of the origin of payments received and the destination of payments made. Accordingly, the system offers complete anonymity to both the payee and the payer, It will be appreciated that in order for transaction anonymity to be maintained, service isolation between issuers and operators must also be maintained, This is the case, provided each operator and issuer operate in separate environment with distinct keys, and policies preventing logging of the recipient of each voucher. However, as mentioned previously, in some legislative environments there exists a requirement for traceability of payments between parties in certain circumstances. In such circumstances, the above described payment system may not be acceptable. As such, if required, policies may allow the operator and issuer to coflude to trace payments between users and identify the participants and the amounts they transferred to each other. In other jurisdictions, a stronger set of anonymity guarantees is possible arid generally desirable. For example, stronger guarantees of anonymity can be delivered in which neither the operator, issuer nor users know the identity of each other.

Accordingly a major advantage of the payment system 100 described herein is that it offers both total anonymity, in which none of the operator/issuer or users have knowledge of each other's identity, and interpersonal anonymity in which the operators can trace payments between the users but the users have no knowledge of tO each other's identity.

The decision upon the level on anonymity to implement may depend, for example, on jurisdictional requirements. For example, a jurisdiction may require that a transaction over a threshold voucher is traceable by a financial authority. However, at the same time, parties of the transaction may not want the other party to have knowledge of their identity. In which case an interpersonal anonymity may be implemented on the balance object or voucher object in question. An issuer or operator may decide which type of balance object or voucher object to implement based on the regulatory environment in force.