RELATED APPLICATION This application is related to U.S. Provisional Patent Application No.

61/950,945 filed March 11, 2014, the contents of which are incorporated herein by reference in their entirety.

FIELD AND BACKGROUND OF THE INVENTION

The present invention, in some embodiments thereof, relates to an electronic wallet and use thereof for payments both online and offline.

A physical wallet that holds cash is able to receive funds from any source and can be used to make payments to any recipient. Payments can be in any amount and in a transaction involving the giving of change, fund transfer is in fact bidirectional. Furthermore cash is anonymous. The physical wallet has the security that physical cash is very difficult to forge, but also has the advantage that cash is anonymous. A challenge for the electronic wallet has been to somehow provide both conditions of cash having a real world presence, and also requiring considerable effort to forge and being anonymous.

A successful electronic wallet may be a replacement for a physical wallet. The electronic wallet has the challenge of making cash both unforgeable and anonymous at the same time.

In the presently known art, electronic wallets or digital wallets can be electronic devices or virtual accounts. That is to say there may be devices, and there may be accounts which are virtual in nature i.e. a bank account. The devices and/or accounts may allow an individual to make electronic commerce transactions. This can include purchasing items on-line with a computer or using a Smartphone to purchase something at a store. Increasingly, digital wallets are being made not just for basic financial transactions but to also authenticate the holder's credentials. For example, a digital- wallet could potentially verify the age of the buyer to the store while purchasing alcohol. It is useful to approach the term "digital wallet" not as a singular technology but as three major parts: the system, that is the electronic infrastructure including supporting servers and communication, the application, that is the software that operates within the infrastructure, and the device, the cellular telephone which serves as the terminal equipment held by the individual and allows the individual to make or receive payments. It is noted, however, that solutions involving paying via one's mobile telephone require the mobile service provider as an intermediary.

An individual's bank account can also be linked to the digital wallet. Furthermore, the individual may also have documents such as the driver's license, health card, loyalty card(s) and other ID documents stored on the phone. The credentials can be passed to a merchant's terminal wirelessly via near field communication (NFC). The system has already gained popularity in Japan, where digital wallets are known as Osaifu-Keitai or "wallet mobiles".

The digital wallet as outlined above allows for payment using existing online payment systems. As such it suffers from certain disadvantages common to such payment systems, in particular a lack of flexibility. Credit cards and other online payment solutions allow anyone to make a payment but only certain entities are trusted to receive payments.

Many payment systems have a minimum amount, so that the smallest payments cannot be included. These small payments, known as micropayments, are financial transactions involving a very small sum of money, and may occur on-line or off-line, although the term is more commonly used for the on-line case, where automation of the payment is involved. The off-line case usually involves exchange of cash between two parties, and automated examples are use of credit cards for small payments to machines, say to pay for parking. There are other examples of automated payment systems such as mobile payment applications, web based payment systems and SIM based payment applications.

There is no general agreement as to the upper threshold for a micropayment, although sums such as 12 US Dollars and 20 Australian Dollars have been cited. At the lower end, micropayments were originally envisioned to involve much smaller sums of money, however practical systems to allow transactions of less than 1 USD have seen little success, and one problem that has prevented the emergence of micropayment systems is a need to keep costs for individual transactions low, which is impractical when transacting such small sums' even if the transaction fee is just a few cents. Nevertheless, many real-world transactions are at the lower end of the range, and any attempt to envision a cashless society must cater for low end micropayments. Only when the electronic wallet can be used for low end micropayments can it ever become a replacement for the physical wallet.

In the on-line sector, there has been considerable work on micropayments, and two generations of micropayment products can be identified. A first generation of micropayment products began in the mid-1980s and continued to be pursued up to the end of the 20 ^th century, and included both token based and account based products. The token based products used concepts such as e-cash, e-coins, digital cash and tokens, and considerable effort was invested in ways of generating the coins etc, making these products as anonymous and untraceable yet as fraud-proof as the notes and coins they were supposed to replace. Other first generation approaches were account based and depended on transferring numbers between customer accounts and merchant accounts. The first generation is generally considered to have been difficult for end users without technical knowledge of the systems used, and often the underlying technology, such as RSA, stretched the available computer hardware.

The second generation systems have generally, although not exclusively, been account based, and user interfaces have been much easier. The systems have generally relied on on-line validation and thus automatically exclude themselves from the world of off-line micropayments. Both pre-paid systems, which need to be charged with cash in advance, and post-paid, where users receive a bill afterwards, are represented.

Some systems are offered only in a limited range of currencies. Other systems, such as Bitcoin™ define their own currency and thus have a fluctuating exchange rate.

Any electronic wallet system may at a minimum be expected to allow an end user to carry out all the functions allowed to him by a physical wallet containing cash.

SUMMARY OF THE INVENTION

The present embodiments provide an electronic wallet device that may be linked to multiple bank accounts or other cash sources. Online and direct payments may be made via the device, and in the online case there is provided a system in which a website works with servers and with the device. The different accounts or other cash sources may be linked to user accounts and then user identities link the user account to the device. However the user identification only indirectly identifies the user. The user identification may be linked to the device via the device IMEI number and can be used to link the different accounts. Encryption and authentication protocols may be used throughout the payment system - for device self-authenticating, for exchange of information and for information storage. Devices authenticating with the servers may also use encryption. Furthermore, the device circuitry is fabricated in such a way as to prevent tampering.

As a result of the above, the cash is anonymous from the points of view of the payer and payee, and it may be noted that the aspect of anonymity stems from the fact the devices self-authenticate, as opposed to direct authentication of the parties to the transaction. The device itself is secured against forgery since transactions cannot exceed the amount recorded on the device.

The device may use separate internal clients for contactless payments, person-to- person fund remittances, remote payments, online payments, credit or even remote insurance policy subscription. The device may be remotely disabled or may self- destruct in defined circumstances indicating misuse. The device can also self-disable itself when certain parameters are attained i.e. after a predetermined number of transactions or after elapse of a predetermined time or after reaching a cumulative threshold amount of float transacted without synchronization of the transaction logs with the payment servers.

According to an aspect of some embodiments of the present invention there is provided a system for electronic wallets, comprising:

a plurality of communication - equipped terminal devices respectively having client software, a communication unit and a user identity associated with the communication unit; and

a payment server having a user account for each one of a plurality of users, each account associated with a respective terminal device via the user identity, wherein the payment server is configured to associate respective user accounts with any number of bank accounts and/or digital wallets associated with a corresponding user.

Alternatively, multiple user accounts may be associated with a terminal device. For example, a user may access their business user account and their personal user account hosted on the payment server from the same terminal device. In this instance, the different user accounts are associated with a single user identity. Also, multiple terminal devices may be associated with a single user account. For example, a group of terminal devices acting as POS terminals, which receive payments only, may collect funds into a single user account. In this instance, the different user identities pertaining to each of the different terminal devices are associated with a single user account.

In an embodiment, the plurality of user identities are associated with respective device identities as long as a respective user retains a given device, the user identities being retained by a user and reassociated with a new device identity when a given user obtains a new device.

In an embodiment, the device identities are IMS I number in a case of a cellular device and MAC addresses in a case of Wi-Fi.

In an embodiment, the client software comprises one or more members of the group consisting of a person-to-person money transfer client, an online client, an online credit client, a credit client and an insurance client.

In an embodiment, the client software comprises a micropayment client, the micropayment client comprising one or more members of the group consisting of a contactless micropayment client, and a remote micropayment client.

The system may remotely disable the communication-equipped terminal devices, or remotely disable specified functions of the communication-equipped terminal devices.

The system may provide identification ability during a fund transfer procedure to allow a user to key in, at a respective device, initial identification information of an individual to receive the funds, the system in response displaying on the respective device, additional identification information of the individual to allow the user to ascertain the identity of the individual as the owner of the device to receive payment, the remotely disabling comprising suspending the identification ability for a predetermined suspension time in response to a predetermined misuse condition.

In an embodiment, the predetermined misuse condition comprises obtaining respective additional identification information of a predetermined minimum number of successive individuals without completing the fund transfer procedure. In an embodiment, the predetermined suspension time is at least two hours, or alternatively four, six twelve or twenty four hours.

In an embodiment, the predetermined suspension time is increased after a plurality of occurrences of the predetermined misuse condition at the respective terminal device, or wherein the remote disabling becomes permanent after a predetermined number of the occurrences.

In an embodiment, the communication-equipped terminal devices are configured with memory to store transactions and with a synchronization unit to synchronize transaction data with a remote server, transaction data being kept in respective memory at least until synchronized with the remote server.

The system may allow a user to make an online payment at a website, the payment server configured to receive user-entered identification information from the website, to match up the user information with the user identity or the user account , and further to match the user identity or the user account with a respective terminal device, the payment server configured to send token data to a first member of the group consisting of the website and the terminal device and to use receipt of the token data from the second member of the group to complete the transaction.

Alternatively, after the payment server has matched the user identity or the user account with a respective terminal device, the payment server may be configured to send a request to the terminal device requesting the user to confirm the online transaction. Upon confirmation, by simply pressing a key for example, the terminal device sends a response to the server. Once the server receives the response from the terminal device, the online transaction is effected or completed. This method is more intuitive and faster for the user than the token based method explained above as it does not involve keying in of any data.

In an embodiment, the user identities may be respective device identities, the user identities being changed when a respective user obtains a new device.

According to a second aspect of the present invention there is provided a method of making payment at a website using an electronic wallet terminal device with communication ability, the method comprising:

entering user identification data at the website;

at a payment server receiving the user identification data from the website; identifying an electronic wallet terminal device corresponding to the user identification data;

sending token data to the website for display to a user of the electronic wallet terminal device to enable the user to relay the token data back to the payment server via the electronic wallet terminal device; or sending the token to the electronic wallet terminal device to enable the user to relay the token data back to the payment server via the website; and

comparing the relayed token data with the sent token data and completing the transaction if the relayed token data corresponds with the sent token data.

According to a third aspect of the present invention there is provided a method for providing an electronic wallet, comprising:

associating a communication-equipped terminal device having client software, a communication unit and a user identity with a respective user;

associating a user account with the user and the respective terminal device via the user identity; and

associating the respective user account with any number of bank accounts and/or digital wallets belonging to the user using the user identity. The user identity may be used either directly or indirectly through a user account to link to the one or more bank accounts, and references herein to associations made using the user identity are to be construed accordingly. That is to say, in some cases, a user identity links a particular device with a particular user account. The user account in turn links to the multiple bank accounts or other store of funds.

Unless otherwise defined, all technical and/or scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the invention pertains. Although methods and materials similar or equivalent to those described herein can be used in the practice or testing of embodiments of the invention, exemplary methods and/or materials are described below. In case of conflict, the patent specification, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and are not intended to be necessarily limiting.

Implementation of the method and/or system of embodiments of the invention can involve performing or completing selected tasks manually, automatically, or a combination thereof. Moreover, according to actual instrumentation and equipment of embodiments of the method and/or system of the invention, several selected tasks could be implemented by hardware, by software or by firmware or by a combination thereof using an operating system.

For example, hardware for performing selected tasks according to embodiments of the invention could be implemented as a chip or a circuit. As software, selected tasks according to embodiments of the invention could be implemented as a plurality of software instructions being executed by a computer using any suitable operating system. In an exemplary embodiment of the invention, one or more tasks according to exemplary embodiments of method and/or system as described herein are performed by a data processor, such as a computing platform for executing a plurality of instructions. Optionally, the data processor includes a volatile memory for storing instructions and/or data and/or a non-volatile storage, for example, a magnetic hard-disk, flash memory and/or removable media, for storing instructions and/or data. Optionally, a network connection is provided as well. A display and/or a user input device such as a keyboard or mouse are optionally provided as well.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

Some embodiments of the invention are herein described, by way of example only, with reference to the accompanying drawings. With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of embodiments of the invention. In this regard, the description taken with the drawings makes apparent to those skilled in the art how embodiments of the invention may be practiced.

In the drawings:

Fig. 1A is a simplified diagram illustrating use of an electronic wallet able to use multiple bank accounts according to a first embodiment of the present invention;

Fig. IB is a simplified diagram illustrating use of an electronic wallet to make a payment to a website in accordance with embodiments of the present invention;

Fig. 2 is a simplified block diagram showing certain features of the payment device of Fig. 1;

Fig. 3 is a block diagram showing the device of Fig. 2 in greater detail; Fig. 4 is a system chart showing relationships between different levels of the system of Fig. 1;

Fig. 5 is a chart showing the different entities participating in the relationships of

Fig. 4;

Figs. 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20 and 21A are a series of screens of the device of Fig. 1 when carrying out a contactless payment;

Figs. 2 IB and 21C show respectively a conventional keypad and screen embodiment of the device and a touch screen embodiment of the device;

Fig. 21D shows the placement of the finger print reader of the device;

Fig. 22 is a simplified flow chart illustrating registration of the device of the present embodiments to a new bank account and the case of linking the device to an additional bank account, according to embodiments of the present invention;

Fig. 23 is a simplified flow chart illustrating a procedure for withdrawing funds from a bank account to use as float on the device, according to an embodiment of the present invention;

Fig. 24 is a simplified flow chart illustrating a procedure for depositing funds from the device into a bank account, according to an embodiment of the present invention;

Fig. 25 is a simplified flow chart illustrating a procedure for making a payment to another device in close proximity, according to embodiments of the present invention;

Fig. 26 is a simplified flow chart illustrating a procedure for making payment to another device which is remotely located from the payer, according to embodiments of the present invention;

Fig. 27 is a simplified flow chart illustrating a procedure for synchronization according to embodiments of the present invention;

Fig. 28 is a simplified flow chart illustrating a procedure for making online payments according to embodiments of the present invention;

Fig. 29 is a simplified flow chart illustrating a procedure for making remote payments according to embodiments of the present invention; and

Fig. 30 is a simplified flow chart illustrating a further procedure for making remote payments according to embodiments of the present invention. DESCRIPTION OF SPECIFIC EMBODIMENTS OF THE INVENTION

The present invention, in some embodiments thereof, relates to an electronic wallet and, more particularly, but not exclusively, to the use of such a wallet for online and offline payments.

A successful electronic wallet may be a replacement for a physical wallet. A physical wallet can obtain cash from any source and pay the cash to any payee in an anonymous way. The present embodiments provide an electronic wallet which can be associated with any number of different sources of cash, say different bank accounts which may be from different banks. The physical wallet has the security that physical cash is very difficult to forge. Furthermore the cash is anonymous. The electronic wallet has the challenge of making cash both unforgeable and anonymous at the same time. The present embodiments address the issue by providing identification that is associated with the device and only indirectly with the user. The device itself keeps the current balance in an encrypted format, and stores an ending float balance after every transaction. A user cannot therefore make transactions whose amount and fee surpass the current ending float balance, as is discussed at length below.

Furthermore, the electronic wallet ensures unforgeability through use of software i.e. encryption, authentication and hardware i.e. fabrication of circuitry to prevent tampering.

Before explaining at least one embodiment of the invention in detail, it is to be understood that the invention is not necessarily limited in its application to the details of construction and the arrangement of the components and/or methods set forth in the following description and/or illustrated in the drawings and/or the examples. The invention is capable of other embodiments or of being practiced or carried out in various ways.

Reference is now made to Fig. 1A, which is a simplified diagram illustrating a system for electronic wallets. Electronic wallet devices 2.1, 2.2 and 2.3 are cellular- equipped terminal devices and each one has client software CLT, a communication unit COM and a user identity ID. As will be discussed below the user identity may be the mobile cellular identification EVISI, IMEI etc and in such a case these identities, which remain with the device, are referred to as device identities. The identity may alternatively be an identification given to the user and separately associated with the cellular identification number. The latter has the advantage that the user can replace the wallet device when needed without changing identity for the different accounts that may be involved.

A payment server 4 hosts a user account A/C 5 for each user, and each account is associated with a respective terminal device via the specific user identity ID. The specific user identity ID is preferably known only to the payment server and is not used as external identification of the user. The payment server 4 is in contact with banks and like financial institutions and allows each user to obtain an amount for use via his/her electronic wallet. The electronic wallets may be synchronized with the payment server over a one or a combination of electronic networks, including the Internet, the cellular telephony network, the cellular Internet, the conventional telephone network, a satellite or cable network or any other available communication system. In the case of the Internet, connections may be via Wi-Fi or like access points. The payment server 4 associates the user accounts 5 with any number of bank accounts associated with the corresponding user, so here the Bank 1 account 7 and the Bank 2 account 8 are both associated with server account 5 using the user account 5.

Alternatively, multiple user accounts may be associated with a terminal device. For example, a user can access their business user account and their personal user account hosted on the payment server from the same terminal device. In this instance, the different user accounts are associated with a single user identity. Also, multiple terminal devices can be associated with a single user account. For example, a group of terminal devices acting as POS terminals, which receive payments only, may collect funds into a single user account. In this instance, the different user identities pertaining to each of the different terminal devices are associated with a single user account.

The different user identities may be associated with specific users, rather than specific device identities. In such a case the device identities may be those identities provided by particular devices, for example cellular devices may have IMSI numbers or like cellular identities and Wi-Fi devices may have MAC addresses or other kinds of network addressing including IP addressing. So the user identities may be associated with respective device identities as long as a respective user retains that given device. If the user exchanges the device, then the user identity is retained and is associated with the device identify of the new device. Alternatively, the device identities may be associated directly with the user account held at the payment server. Thus if a user replaces a device, one may simply associate the device identity of the new device with the users existing user account. In this case, the said user identity is the same as the device identity.

Electronic wallet device 2 may carry out a payment transaction with another electronic wallet which can be proximate or remote, or with a website or server.

Referring now to the client software, and the overall client software may include one or more of the following components whose use will be discussed in greater detail below, a credit client, an on-line transaction client, an online credit client an insurance client, a person-to-person money transfer client and a micropayment client. The micropayment client may include one or both of a contactless payment client, and a bill/remote micropayment client.

It is noted that the online credit client allows a user to sell to other users remotely and receive float accordingly, or to receive refunds from vendors, or can be used by vendors to receive payments for sales made at their websites.

The combination of the multiple accounts and the multiple clients contributes to the effectiveness of the electronic wallet device as a replacement for a physical wallet since it is able to both accept and dispense cash in multiple ways and therefore support a wide range of transaction types.

In embodiments, the cellular-equipped terminal devices can be remotely disabled.

One of the circumstances in which disabling may be considered is that in which the user appears to be searching for information about other users. In the case of transferring cash remotely to another user the device operates to provide confirmation identity information of the other user so as to be sure that cash is being sent to the correct receiving device. The user sending the cash enters identification information of the other user at their device and in response receives on the screen additional identification information of the target individual to confirm the identity of the individual as the owner of the device to receive payment. If the operation is repeated more than a certain number of times without completing the transaction then a preset misuse condition may be entered. The result of the misuse condition is that the device is disabled for a certain amount of time, either overall or just for the remote transfer function. An example of what might constitute a predetermined misuse condition comprises obtaining respective additional identification information of three successive individuals without completing the payment transfer procedure. The resulting disablement may be for a certain amount of time, such as at least two hours, at least four hours, at least six hours, at least twelve hours and at least twenty four hours. In one example the suspension time may be increased after successive violation events. Alternatively, the resulting disablement may be permanent after a certain number of violation events.

The device may have a memory or storage that holds the transaction logs, payment mounts and other data and may synchronize the transaction logs and other information at regular intervals with the payment server. Data may be kept in the device until after synchronization is completed. In an embodiment, data is retained in the device for two synchronizations and then deleted. Alternatively, as the memory is used up, old transaction logs are deleted during each synchronization event to create storage space for more transaction logs. The synchronization with the main server may ensure that the servers have a record of all transactions done at the devices for storage and processing i.e. revenue calculations.

Reference is now made to Fig. IB which is a simplified diagram illustrating the interaction between a web server 9, the payment server 4 and a wallet device 2 in the event of an online transaction at a website according to an embodiment of the present invention.

The website is hosted at web server 9 and device 2 is required to make a payment via the website for online goods or services. As will be explained in greater detail below, the user identifies themselves with real world user identification information at the website -S I. The payment server 4 receives the real world user- entered identification information from the website or web server 9 and other transaction information such as the transaction amount in S2, and matches up the real world user information with the user identity associated with the device. The user identity is now matched with the web server 9. At this point, the payment server 4 sends token data to the website - S3. In an embodiment, the token may have an expiry date before which it must be used or else it will be invalid. The web server displays the token - S4 which the user enters onto his device at the website. The user then sends the token to the payment server 4 -S5 via the user's device. The payment server uses receipt of the token data from the device and compares it with the token that was initially sent by the payment server. If the tokens sent and received match, the then the transaction is completed - S6. An alternative method is where the token is sent to the device and the user inputs that token to the website. The web server sends the token to the payment server which then checks that the token sent to the device is the same as the one keyed in the web browser. The token may be given a lifetime, so that the transaction is only validated if completed during the token lifetime.

Another alternative is that once the payment server matches real world user information from the web server with the user identity associated with a particular device, the payment server sends an authorizing request to the device. The user presses a key authorizing the online transaction, and the device sends a response to the payment server which includes the user identity of the device. The payment server checks whether the response came from the expected device if so, the online transaction is completed. There is a time period within which the user expects to receive a response from the device server after sending an authorizing request. The online transaction may only be completed if the response from the device is sent and received within this time period.

Reference is now made to Fig. 2, which is a simplified block diagram illustrating the internal structure of Fig. 1.

The terminal device includes a memory 20 which stores a payment amount, being an amount available for transactions. The payment amount is money obtained, for example money withdrawn from a bank account, or obtained from another payment device, or any like electronic store of funds, together with any money paid to the device in the course of payment or other transactions such as cashing in at an agent outlet. The payment amount on the device may be the same as a payment amount stored for the same user in the server, except that the server is updated by the device periodically to inform regarding any payment transactions that have taken place in the meantime, as will be discussed in greater detail below. The payment transactions may be synchronized to the server in real time if a connection is available, but if not then the synchronization may take place as soon as a connection is available. A local communication unit 22 carries out an authentication handshake with a second device located nearby, to carry out a contactless payment by altering the stored payment amount in a complementary manner at the electronic wallet 2.1 and the second device 2.2 respectively (See Fig. 1A). Thus if a transaction is for an amount X, then the payment device ensures that the amount X is deducted from the payee and is added to the payer. In addition, transaction fees may be charged to one or both parties.

A synchronization unit 24 synchronizes the stored payment amount with the central server over the first electronic network following alteration due to the payment or any other transactions done by the device. As mentioned, the local communication unit may carry out the authentication handshake irrespective of electronic network connectivity. In the event that the authentication handshake is carried out in the absence of electronic network connectivity, the synchronization unit 24 waits until network connectivity is regained. The synchronization unit may additionally carry out synchronization with the server on detection of a low power condition, so as to ensure that the device and server are fully synchronized prior to device shutdown. The synchronization unit may insist on carrying out a synchronization with the server after a certain number of transactions, and/or after a certain cumulative threshold amount transacted and/or after a certain time period has elapsed to ensure that the server does not get too far behind and or minimize the risk that a large amount of transactions will not end up at the server in the case the device is damaged.

The local authentication unit may be implemented using a near-field communication (NFC) unit. Near field communication (NFC) is a set of standards for Smartphones and similar devices to establish two way radio communication with each other by touching them together or bringing them into proximity, usually over distances not exceeding tens of centimeters. Also, the local communication unit may also be implemented using Bluetooth technology.

The local communication unit may only be open for authentication for a predetermined amount of time following initiation of the payment and the authorization of the payment by a user. Thus after defining the transaction at the device, the device may shut down the transaction after a certain number of seconds if the transaction partner is not found. The payment recipient may also have to activate their device so that they can receive a payment and their device once activated likewise has a window period of a certain number of seconds to authenticate and accept a payment.

Authentication between the two devices involves authentication of the devices themselves, not authentication of the user or of an account, thus retaining anonymity of the users. The authentication may use a device identification number, authentication protocol i.e. zero knowledge authentication and encryption. Hash functions or public key encryption or zero knowledge encryption may be used to positively identify the devices as genuine.

On the other hand, in authenticating with the server, the synchronization unit 24 may use a SIM card, or alternatively device-level or other appropriate authentication protocol may be used or a device identification number may also be used. The server needs to know, not just that the device is genuine but to which account/user the device belongs. Remote communication unit 26, discussed further below, may facilitate the authentication by enabling the connection with the server.

Information exchanged between the electronic wallets to carry out the payment may be encrypted, and the use of encryption provides further certainty as to whether the device with which the transaction is made is genuine or not.

The device may further comprise a remote communication unit 26. The remote unit may carry out an authentication handshake in which the terminal device authenticates with the server, and the server then authenticates with a third device so as to facilitate the remote payment or money transfer with the third device. The terminal device and the third device do not directly authenticate each other in this case. The third device may be located remotely over the cellular network or the Internet or any other network. As mentioned above and discussed in greater detail below, the synchronization process may use the remote communication unit. Likewise, device updates and remote disablement also use the remote communication unit.

The electronic wallet may fit in a wallet and may incorporate mobile communication technology, memory and Near Field Communication (NFC) technology. An embodiment has the dimensions of a credit card (85.60 x 53.98mm) but slightly thicker. The terminal device may also have a finger print reader which is useful to authenticate the owner of the device. Another embodiment of this payment system is having the system within a special NFC enabled SIM card. SIM cards have been developed with NFC capabilities. Thus a user may take any phone, whether a feature phone or smart phone, and upon fixing an NFC SIM card on the SIM slot, enables the phone to make contactless payments. SIM cards have storage capabilities and applications can be pre-installed within the SIM, so that the payment system functions may be inserted within a SIM.

Hence, two phones with NFC enabled SIM cards can exchange payment information after interaction using a suitable client application pre-installed within the SIM. The payment information alters the float stored within the memory of the SIM and the phone then facilitates the synchronization of the payment data stored within the SIM with the payment servers. Also, the user can interact with the pre-installed SIM application to transfer float from their account into their SIM card. Furthermore, different applications can be stored within the SIM to facilitate person-to-person money transfer, remote payments, online payments, credit requisition and insurance policy subscription. Thus a user will not need to carry an extra device but can simply use their phone, which will have the special NFC SIM card.

Reference is now made to Fig. 3, which is an internal block diagram of the device of Fig. 2. A user interface includes a display unit 32, a keypad 34, a push button 36 (PBNO- Push Button Normally Open) and a vibrator motor 37. The push button facilitates quick access of information for example allowing users to access their float balance. The vibrator motor enables users to receive a physical stimulus when an important event has occurred for example when a transaction is successfully done. The keypad and display unit may be combined as soft keys and a touchscreen in one embodiment intended for familiarity to smartphone users.

The synchronization unit referred to above communicates using an RF antennae

38, modulator 40, the wireless communication module 42, which may be a dual, quad or penta-band GSM module, a CDMA module or even a Bluetooth or WiFi module, and the SIM card module 44. The wireless communication module may provide a GPRS, or any other communication protocol, connection to the mobile service provider's network. Thus in this regard, the device may mimic a GPRS modem transferring data— transaction logs and other forms of data and instructions to and from the servers. The device may connect to the servers through a Virtual Private Network (VPN) for the purpose of synchronizing transaction logs held in its secure element with those held in the servers. The VPN connection may also be used to send security updates, firmware patches and other module updates so as to make the device more secure or increase its functionality or efficiency.

The Near Field Communication (NFC) unit 46 enables the transfer of transactional information between the devices, within close proximity as discussed above, affecting contactless -payments. The information exchanged by the NFC unit 46 is typically encrypted.

Processor 50 provides overall control and SRAM 52 provides additional memory functions for the processor. Data may be temporarily stored in the SRAM for immediate access by the processor during processing. The microprocessor 50 is the core processing brain of the device. All calculations, interrupt handling, error and exception handling are coordinated by the microprocessor. The flash memory 48 may also holds the operating system, the various software modules, updates and patches.

The secure element 54 holds sensitive information such as transaction logs, float balance, user identification number, device identification number, security keys and also performs cryptographic operations. When information is received by the NFC unit from a second payment device, the data is transferred to the microprocessor. The microprocessor performs the necessary decryption to extract the command from the received data. This command is then transmitted to the secure memory element, which is programmed to only accept specific commands executing a challenge-response protocol before releasing or accepting information. If the information provided from the microprocessor is correct, then the secure element releases the requested information to the processor or accepts the requested information for the processor. The microprocessor then applies another encryption protocol to the data, which data after encryption is then forwarded to the NFC module for further transmission to the second payment device.

The key features of the communication are as summarized below:

• The NFC receives information that is already encrypted and as such, any sniffing by hacking devices may only retrieve data that is encrypted and hence useless • The microprocessor can decrypt the information received but cannot use it unless it receives the correct data from the secure memory element

• The secure memory element can only release information based on the provision of a correct request code from the microprocessor · Information transferred among the microprocessor, secure memory element and NFC device is partitioned such that any compromise of one part of the system may not affect security of the stored information. The microprocessor is the only unit in the system that can communicate with the wireless communication module. Information transferred between the microprocessor and the wireless communication module may also be encrypted before transmission. Credentials to connect to the network may be stored in the secure element.

The finger print module 56 is used to authenticate a user before they can use the payment device. For fingerprint authentication, images of the authorized fingerprint may be stored in the fingerprint module. The microprocessor need not be involved with the relatively complex fingerprint matching activities and thus avoids introducing any additional time lag into the system.

The device may contain a battery 58 which powers all the electronic components.

Reference is now made to Fig. 4 which is a process diagram illustrating how the different parts of the device work together. Electronic funds can be withdrawn or deposited from a bank account or from any electronic store of fund and loaded or uploaded into the device via the system servers. The wireless communication module which may be a GSM module, updates the device with the amount from the servers. The device is designed so that the amount held in the device can only be set from the servers via a valid SIM identification and preferably through a VPN connection, or changed through a payment transaction. The amount is securely stored in the secure element. For a payment, the device interface is used to define the transaction and then the two parties to the transaction authenticate their devices to each other via the NFC unit. The transaction leads to changes in the amounts held in the secure element at the two devices, which are then updated at the servers during synchronization. Surpluses on the device can subsequently be credited to the corresponding user's bank account. Devices in disparate geographical locations can send each other float via the device provider's servers using their remote communications abilities, for example GPRS, Bluetooth or WiFi radio modules.

Different users are able to make monetary transactions between themselves despite the fact they bank with different banks, and despite the fact that neither of them have a POS system or like setup. Furthermore, the device is not limited to a single bank account but rather, in the event of a user having multiple bank accounts, each can be accessed via the same device.

As well as withdrawing from bank accounts, transaction amounts on the device may be obtained as credit from credit issuing institutions. Furthermore, the device can also function as a credit card, with an allowed spending limit and payment after the fact to the bank. In this case, transaction data can be used to determine a user's credit limit.

Reference is now made to Fig. 5, which illustrates the payment system topology in which the device operates. The devices are able to encounter each other at a first level 60. The devices connect to the mobile network at a second level 62. The server provides a third level 64 and these are managed by a control system which forms a fourth level 66. The banks form a fifth level 68. Firewalls 70 protect the servers and the control center.

The above-described device has several advantages. NFC capabilities are provided without requiring an expensive smart phone, thus making the device suitable for developing countries. Given the device can facilitate contactless payments without the need of a POS terminal, the solution is suitable for regions where POS terminal infrastructure is under-developed and where most retail transactions resemble the person-to-person use case. The balances, or electronic account entries reflecting the transactions that occur, are stored on the device so that a connection to the server is not required at the time the transaction is carried out. Thus the device can be used in places where or when mobile signals are not available. Also neither party gets to know the details of the other party, since the devices carry out their authentication with each other automatically and only identify genuine devices, as opposed to identifying the user. It is noted that a device identification number which is unique to each device may be linked to a user's account and thus each device can be traced to a specific user.

The device may include some or all of the following security features: Sensitive data such as device identification number, user identification number, transaction logs and encryption keys may be stored in a secure element. The secure element may also execute cryptographic operations.

The device may have a finger print reader which a user uses to unlock the device for use.

No user may alter or install any software in the device thus the risk of hacking the device is minimized. The only port the device has is for charging.

The device may detect disassembly and or tampering and in doing so, the memory, for example a flash memory or EEPROM, may self-destruct or self-delete. Alternatively, the memory can be fabricated in such a way that accessing or altering its data except via the interfaces provided is physically impossible. The device may also self-destruct or lock itself when it detects disassembly or tampering.

When the NFC facility is not called for, the NFC module may be powered OFF. This is to prevent remote readers from accessing information from the device and also this extends battery life. The NFC module in the device powers ON once a user confirms a contactless payment transaction or when a user activates their device so as to receive a contactless payment. When the NFC module is activated, it is only active for a predetermined time, say five seconds, within which the two devices may be tapped together. If within the period the devices are not tapped, the NFC module switches off and the user is required to repeat the keying in sequence necessary to make the contactless payment transaction. If a user repeats the above process a certain number of times for example five times without tapping another device, the user's device may be deactivated for a certain time period. This is because this behavior is an anomaly and may signify a user trying to hack the device by collecting information emitted by the NFC unit.

Transactional data transmitted by the devices are encrypted, as mentioned above.

If a user is in an area without a mobile network the device can accept a specified number of contactless payment transactions, transact a set threshold cumulative amount or after a certain time period has elapsed after the last successful synchronization, prompt the user to go to a place where there is a network so that the transaction logs already stored in the device can be synchronized with those stored in the servers. Once the parameters described above are met, the user cannot do any transactions until the synchronization process is complete. This ensures the server does not get too far behind and or minimize the risk that a large amount of transactions will not end up at the server in the case the device is damaged. Money transfers or remote payments can only be affected when the user's device is online or within network coverage.

If the device gets lost, it can be disabled through one or more of the following ways:

o Going to any bank and upon producing identification documentation, the bank staff will be able to deactivate the user's device.

o When a user is first issued with a device, they may be issued with a device deactivation code. If their device is lost, they may simply use any other device, key in the device deactivation code and their user identification number and their device will be deactivated.

o A user can also log into their profile in a web portal and using the device deactivation code and their user identification number, deactivate the device.

Once the servers receive instructions to deactivate a device, the servers may send instructions to the device to be deactivated. The device to be deactivated may deactivate itself such that it cannot make any transactions. Before it deactivates itself, the device may send the transaction logs stored in its secure element to the servers. After that, the secure element may format or self-destruct and the device will be unusable.

Other circumstances demanding deactivation may have to do with say phishing, illicitly obtaining information about other users for spamming and the like, including fraud. The device allows users to confirm identities of other users to whom they are sending cash. Thus the user transferring cash to a remote user may use some minimal identification to indicate another user. The device of the user transferring the cash contacts the payment server and confirmation identification information then appears on the screen so that the transferor can be sure they have the correct John Smith. Now if the case is legitimate then the current user will find the correct transferee after a short number of queries and complete the transaction by transferring cash. However if numerous queries are entered without any completion of the transaction then it may be assumed that some kind of data mining expedition is underway. In this case a limit may be placed on the number of uncompleted transactions that are allowed before the device is disabled, a violation condition. Disablement may be total, or may be limited to the particular type of transaction and may be permanent or may be limited to a preset amount of time following the violation condition. In an embodiment the penalty period for which the device is disabled may increase with repeated violations. Penalty periods may vary from a few minutes to multiple numbers of hours, or whole days or whole weeks and in serious cases may tend towards permanent exclusion from any activities that provide information.

The server may have extensive data analytics capabilities which help in detecting fraud, money laundering and other anomalies.

Following manufacture, each device may have a SIM card pre-installed at the factory, which enables it to connect to a mobile service provider's network. The IMEI numbers and the phone numbers or IMS I numbers may then be uploaded into the payment server. Other cryptographic codes may also be provided and uploaded.

An end user then orders a device. The financial institution associates the user's bank account with the device IMEI number issued to the user. The device provider servers may then be provided by the bank servers the account information of the user together with the device IMEI number issued to the user.

If the user has a second bank account at a second bank then the same device may be linked to the second bank account. This may be done by the device IMEI number being associated or linked with the user's second bank account at the second bank. The procedure is illustrated in greater detail below in respect of Fig. 22.

Once the user has been issued with the device, the device provider server may send the IMSI number associated with the user device's IMEI number to the partner mobile operator servers so as to activate the SIM in the user's device. Once the SIM is registered in the mobile service provider's network, the user can begin to use their device. This setup ensures the bank only has the IMEI number associated with the user's device and the mobile operator has the IMSI number associated with the user's device. The device provider is the only entity with both the user's device IMEI and IMSI number. During registration, the device provider server(s) may generate a device identification number (UDID-Unique Device Identification) which it sends to the device and is stored in the device's secure element. The device identification number provides a more secure way of uniquely identifying each device in addition to the IMEI number (just in case the mobile operator will require the IMEI number in addition to the IMEI number for regulatory or policy purposes).

Once a user first receives their device, the first thing that they need to do is to access their bank account so as to pull or withdraw their funds electronically from their bank account to their device. The user can also receive funds from another device or cash in at an agent outlet.

From a technical view point, when a user withdraws money from their bank account to their device, funds are in essence transferred from their bank account to a trust account. The trust account holds all the funds held in all the devices. Fig. 23, discussed below, shows a procedure for carrying out such a withdrawal.

In the above, reference has been made to payments made between two nearby devices using local communication which we refer to as contactless payments. These contactless payments cater for those everyday retail payments between individuals who are in close proximity, for example buying vegetables in a shop or a market stall and the payment is done within the confines of the grocery shop, between the buyer and the shop keeper.

The steps and processes for affecting contactless payments are as follows:

Two individuals enter into an agreement that will result in a monetary payment. The individual paying the outstanding amount (debtor) gets out their device, unlocks it using the finger print reader, opens the required application module to make contactless payments, and keys in the outstanding amount. The device then checks if the debtor has enough efloat balance i.e. the efloat balance within the secure element may be greater than or equal to the amount to be paid by the debtor plus the transaction fee. If the balance is not sufficient, the debtor is notified and the transaction is disallowed. If the balance is sufficient, the NFC module within the device may be activated for five seconds, ready to send and receive the required transaction information.

The creditor then activates their device so as to receive the payment. On activating, the creditor's device NFC module may also be activated for five seconds. The debtor then taps the upper portion of their device against the upper portion of the creditor's device. The debtor's device sends the following information to the creditor's device: transaction amount, identification code, and time stamp. All the information shared between the two devices is encrypted.

The creditor's device receives the transaction information sent from the debtor's device and upon successfully decrypting the information, sends to the debtor's device its encrypted identification code.

If the creditor's device cannot decrypt what the debtor's device has sent, then the creditor's device does not vibrate therefore notifying the creditor that the transaction is not complete, and the conclusion being that the debtor has not successfully made the payment. Likewise, if the debtor's device cannot decrypt the identification code sent to it by the creditors' device it will not vibrate, thus prompting the debtor that the transaction is incomplete.

Fake devices are in this way unable to participate in transactions, since they are unable to cause the other device to vibrate and complete the transaction. From time to time, the encryption keys in all devices may be changed during device software updates for added security.

Both devices may then vibrate, or produce another type of stimuli e.g. a beep, to notify the users that the transaction is successful. Also a message may be displayed on the screen that notifies the creditor and debtor that the transaction is successful.

The debtor's device then debits the efloat balance stored within its secure element with the transaction amount and any transaction fee, while the creditor's device credits the efloat balance stored within its secure element with the transaction amount the debtor sent and debits any transaction fee due from the creditor.

Transaction logs, may contain the debtor's and creditor's identification codes, the transaction amount, type of transaction, a time stamp, and the efloat ending balance, and are kept in each of the creditor's and debtor's device. The time stamp, together with the debtor's and creditor's identification codes, may be used as the transaction ID which identifies the unique transaction. Note that for each transaction made, the debtor and creditor devices may have the same transaction log for that particular transaction, the only difference being that in one device the amount is a credit and in the other device, the amount is a debit. The procedure is discussed below in greater detail in respect of Fig. 25. From time-to-time, the cellular module within the devices sends the transaction logs via the General Packet Radio Service or any other communication protocol of the mobile service provider, to the device provider servers as in the synchronization process discussed above. Thus the servers have a record of all transactions by the devices from time to time. Upon synchronization, the revenues due to the different banks and the device provider may then be calculated.

Considering the synchronization process in more detail, when the user switches off the device and synchronization has not been done, the device may go into sleep mode but the modules involved in synchronization may remain ON and may complete the synchronization of the transaction logs at the first available opportunity. Once the synchronization process is complete the device may then shut down completely. Thus, before a device is completely switched off, the synchronization process should have been completed i.e. synchronization is part of the shutdown sequence.

If a user is in an area without a mobile network and the user switches off their device, the device may then go into sleep mode as described. From time to time it may attempt to connect with the servers in order to synchronize. If after a day the device is unable to contact the servers, it may keep trying twice every day to synchronize. This may continue until the battery runs out of charge.

If a device is not charged and its power reaches a certain threshold, the device may stop accepting any transactions and may automatically synchronize with the servers before initiating shutdown sub-routines.

The algorithm which controls the synchronization process is dependent on the following factors (in order of importance):

1. Value of transactions— if a user carries out large value transactions, their device may synchronize more often with the servers.

2. Number of transactions— if a user carries out many transactions, their device may synchronize more often with the payment servers.

3. Duration— if a user carries out neither of the above, that is both the size and number of the transactions is small, then the device may be synchronized as per a set time frame i.e. all devices need to be synchronized after every 12 hours.

Thus a user who does one or two transactions may have their device synchronizing once in 12 hours. However if the user does a large number of transactions or transactions that are of large amounts, the synchronization process may be more frequent. This provides a safeguard in that it ensures that if a device is damaged the loss is minimized i.e. the chance of having a device with a large unsynchronized balance is minimized. The synchronization procedure is described in greater detail in respect of Fig. 27 herein below.

Device-to-Device Remote Fund Transfer

If the user wants to send efloat balances to another user via the payment server, the steps and processes are as follows:

1. The sender opens the application module concerned with sending money.

2. The sender keys in the amount to send to the recipient.

3. The device then sends the amount to the payment server. The server then determines the fee associated with sending the amount and sends the fee to the device.

4. If the amount to be sent and the transaction fees are greater than the efloat balance held in the sender's device, then the sender will be prompted that they cannot affect the money transfer. Otherwise, the sender will be prompted to continue with the transaction.

5. The sender keys in the recipient's national identity or passport number. The number sent may be any ID used on a national level to identify citizens i.e. in the United States users may use their social security number. The sender may key any type of user identify number that uniquely identifies a recipient i.e. a phone number.

If the sender is sending electronic funds to a recipient for the first time, they will have to key that person's national identity or passport number. The device will then save the recipient's name and national identity or passport number so that in future the sender simply selects the name of the recipient if they would like to re- send funds to them.

This recipient's national identity or passport number is sent by the sender's device to the payment server which searches its database and then sends the full names of the recipient to the sender's device. Given people recognize names easily rather than numbers, the sender can easily verify beforehand whom they are sending money to. Also, the recipient's device identification code is sent by the server to the sender's device. Alternatively, the device can wait for the user to enter the recipient's national identity number or passport number and the amount to be sent. The device then sends this information to the server and the server sends to the device the full names of the recipient and the fee associated with sending the entered amount.

If a user keys in a national identity or passport number, the names of that person appear on the screen. If this process is repeated a set number of times i.e. three times in a row without proceeding to the next step which is to verify if that is the person the user wants to send money to, the device will not allow fund transfer transactions for a set period e.g. 12 hours. This will ensure individuals do not use their device to mine for other people's names using their national identity or passport numbers.

6. The sender confirms the transaction.

7. The cellular module within the device sends the transaction information in encrypted format (transaction amount, identification code of the sender's device, and time stamp), to the server for onward transmission to the recipient device.

8. The efloat balance in the sender's device is debited with the amount sent and transaction fee. The sender gets a confirmation message that funds have been sent to the recipient and awaiting receipt by the recipient.

9. The payment server then connects with the recipient device with encrypted instructions to credit its efloat balance with the amount sent by the sender. The servers also send to the recipient's device the identification code of the sender's device and the time stamp that was initially generated in the sender's device. The recipient's device confirms the successful credit of its balance with the servers. Afterwards, the sender gets another confirmation message that the amount sent has successfully been received by the recipient. A confirmation message is then received by the recipient that funds have been received. If the payment server cannot get in touch with the recipient's device after a certain time frame i.e. 24 hours, the server may send instructions to the sender's device that may cancel and reverse the transaction, entailing crediting the sender's balance with the amount that was sent and the transaction fee that was debited. The sender's device may then show a notification which notifies the sender the transaction was not successful.

10. The server keeps a record of this transaction. However the transaction logs (which may consist of sender's and receiver's identification codes, transaction amount, efloat ending balance and time stamp, and type of transaction) maintained in the sender and receiver devices may need to be synchronized together with the transaction logs of other transactions. Upon synchronization, the revenues due to the different banks and the device provider may then be calculated. The process is discussed in greater detail below in respect of Fig. 26.

Reference is now made to Figs. 6 to 17, which illustrate successive screens of the device while carrying out a contactless payment transaction. Fig. 6 shows the screen upon removing the device from one's wallet and pressing any key. Pressing any key causes the device to exit from hibernation mode. After 10 seconds or like predetermined period, of no activity, the device returns to hibernation mode.

Fig. 7 shows the screen as the pin number is entered.

Fig. 8 shows how the device prompts the user to initiate a payment or acceptance of a payment by selecting either a 1 or 2 respectively, using the keypad.

In Fig. 9 the device invites the user to key in the amount to pay. If the user wants to make a calculation then the left navigation key summons a calculator. Otherwise the user simply keys in the amount to pay.

If the calculator key is pressed then the screen shown in Fig. 10 is reached.

Repeatedly pressing the left navigation key enables the selection of various mathematical functions.

Fig. 11 shows the screen format once a calculation is about to be completed.

On pressing the equal key, the calculation is performed and the answer is displayed as shown in Fig. 12. On making a calculation the user can easily use the total directly to make a payment.

On pressing the pay total key, the screen changes to the one shown in Fig. 13, showing a single amount that needs to be paid.

On pressing the OK key, the present screen prompts the user to cancel the transaction by pressing the NO key, as shown in Fig. 14. Pressing the OK key activates the NFC module in the device. A transaction then needs to be done within a set period of time e.g. 5 seconds or else the NFC module will be deactivated and the home screen will be displayed.

If the user does not want to cancel, they can then simply tap the top end of their device with the top end of another user's device, as per Fig. 15, and the contactless transaction may be carried out. It is noted that in an embodiment, the top end of the device holds the Near Field Communication unit antenna which carries out the contact with the other device.

As per Fig. 16, on tapping the top end of the recipient's device, the user's device vibrates when the transaction is confirmed and the user can easily see their new balance.

As shown in Fig. 17, on pressing cancel, the device is ready to accept or receive a new payment.

Fig. 18 shows the screen obtained by the recipient after inputting and verifying the PIN as in Fig. 6 and Fig. 7. The screen prompts the recipient as to whether he wants to make a payment or receive a payment. Upon pressing the number 2 on the device keypad, the recipient sees the screen as shown on Fig. 19. The screen of Fig. 19 shows that the device is ready to accept a payment and the Near Field Communication module in the recipient's device is activated for a preset number of seconds as above to receive a payment from the user. Upon the recipient tapping the top end of their device with the top end of the user's device, the transaction is affected and the recipient's device vibrates and shows the confirmation screen as shown in Fig. 20. On pressing the right navigation key which is the cancel key, the user sees the screen shown on Fig. 21A, prompting the user to make another like transaction.

Fig. 21B is a view of a device according to the present embodiments with a keypad 72 and a conventional screen 74.

Fig. 21C is a view of a device according to the present embodiments wherein the screen may be a touch-screen 76, with soft keys 78 appearing and disappearing as and when they are required for processing.

Reference is now made to Fig 21D, which is a simplified schematic diagram showing the back of a device as shown in Figs 6 - 21C. On the back of the device may be seen finger print reader 79 which is located to be conveniently used by an operator by intuitively and easily moving their index finger.

Reference is now made to Fig. 22, which is a simplified flow chart illustrating the process of registering a new device and linking an extra bank account to an existing device. Bank details, or details of any other institution where the user has an account is provided in box 80. Other details include the bank name, the account number, and a user identification number or the like, such as an official national identity number, social security number etc. In box 82 the details are checked to see whether the user has already been assigned a device. If the user already has a device then flow goes through the yes branch to box 84 and the account details are appended to the user's record of bank accounts for the pre-existing device. If the registration is successful - checked in box 86 - then in box 88 the bank account is appended to the device providers' database. In box 90 an acknowledgement of successful registration is provided.

If registration is found to be unsuccessful at box 86 then an error message is shown in box 92 and the registration process starts again.

If the user does not have a pre-existing device, then the IMEI number of a new device is entered in box 94. Validity of the number is checked in box 96. If valid then account details for the new user are registered in the device provider servers. After that, the SIM in the device is registered in the MNO (Mobile Network Operator) network and the device is activated. A device database is then activated 98.

If the IMEI number is not valid then an error message is shown - 100- and a valid IMEI number may be entered.

Upon successful initialization of the device then in box 88 the bank account is appended to the device providers' database. In box 90 an acknowledgement of successful registration is provided.

Reference is now made to Fig. 23, which is a simplified diagram that illustrates the process of withdrawing funds from a bank account and loading them as float into the device.

In box 110 the user is able to select which bank and account to withdraw from, assuming the device is connected to more than one account. The amount to withdraw is entered. The account is checked in 112 to make sure that the account has sufficient funds, and if so then in box 114 the amount selected is withdrawn from the customer's account to a trust account that holds float for all the devices. Box 116 checks whether the withdrawal was successful. If not then an error message is shown in 118 and the user has the opportunity to try again.

If the withdrawal was successful then the new float on the device is calculated and displayed on the device in box 120, and the transaction is recorded as a transaction log in the device database - box 122.

Fig. 24 is a simplified flow chart illustrating how the device can be used to deposit float as funds into a bank account. In box 130 the user selects the bank account - if there is more than one bank account - and the amount to deposit. In box 132 the amount is checked against the current float to ascertain that there is enough to cover the deposit plus any associated fee. If not then an error message is shown - box 133. In box 134 a deposit is made from the trust account to the bank account. In box 138 the device ascertains whether the transaction was successful. If unsuccessful then in box 136, error information is displayed. If successful then, in box 140, the device reports the successful transaction and displays the new float balance. In box 142 the transaction is recorded as a log in the device database.

Reference is now made to Fig. 25, which is a simplified flow chart illustrating the process of making a payment to a nearby device. As discussed, network connection is not required for this process at the time of making the payment, although the transaction details do have to be synchronized eventually. In box 150, the payer enters the amount to be paid while the payee prepares their device to accept the payment amount. In box 152 the amount entered by the payer is checked to make sure that the device has enough float to cover both the payment and any transaction fee. If not the process starts again.

In box 154, the near field communication unit is activated together with a timer. The payer's device is tapped with the payee's device and this is detected in box 156 as long as the timer in both devices have not timed out - box 158. In box 160 the amount is paid and the balances are adjusted accordingly in each device, including any fees. In box 162 the devices check whether the transaction was successful. If not then an error message is displayed 164 and the process may be started again. If successful, then the details are shown on the screen - box 166, the devices then vibrate and the transaction is recorded as a transaction log in the device database for both the devices - box 168, which can be synchronized with the servers either now or at a later time when a network connection is available.

Reference is now made to Fig. 26, which is a simplified flow chart diagram illustrating a remote transaction between two private individuals.

The sender enters the amount to be sent 180. The device checks in box 182 that the float balance in the device is sufficient for the remittance and any associated fee. If not the sender has an opportunity to start again- 183. In box 184 the recipient's identification code is entered and in box 186 the code is checked for validity. If not then the sender is given a further opportunity to enter the code. In box 192 the floats in the sender and recipient devices are adjusted accordingly. Box 190 checks that the transaction is successful. If not an error message is displayed - box 192. If the transaction is successful then the sender's device indicates that the amount has been sent to the recipient and the new balance is displayed, box 194. Also the recipient's device indicates the amount has been received from the sender and its new balance is displayed. Box 196 shows that the transaction is recorded as a log in both the sender's and receiver's device database.

Reference is now made to Fig. 27, which is a simplified diagram illustrating the synchronization process. In general synchronization is carried out at the next available opportunity that a network connection is available after a transaction is carried out. However under certain conditions, the device refuses to carry out further transactions if synchronization is not carried out. In box 200 the device determines that it has a logged but unsynchronized transaction. If yes, then in box 202 the device checks whether there is a network connection. If there is no network connection then the flow moves to box 204 where the number of unsynchronized transactions, the transacted amount and the time of last synchronization are obtained. In boxes 206, 208 and 210, each of these values is respectively tested and if any of them exceeds a threshold then flow proceeds to box 212 where transaction activity is locked until the next synchronization. In box 214 the device displays the locked status and no further transactions are carried out until the network is found to be available in box 216.

At this point, box 218 - device request synchronization - is reached. Box 218 may also be reached directly from box 202 if the network was available at that time. As the synchronization is requested, the device provider's server acknowledges the device requests and the logs are transmitted to the server, as shown in box 220. In box 222 there is a test for successful transmission. If the transmission is not successful then error information is shown - box 224 and a retry may be attempted 226. A 'no' branch is also provided from box 226 if a retry is not to be attempted (and the synchronization process may be started all over again from the beginning).

If the transmission is successful in box 220 then the flow continues from box

222 to box 228, in which all but the last n transaction logs are deleted in the device. The transaction logs of current interest are added to the device provider's server in box 230. In box 232 information about the successful synchronization of the transaction log(s) is displayed. If the device has been locked prior to the current synchronization then this is detected in box 234 and the device is unlocked in box 236. In box 238 a latest time for a next synchronization is updated.

Online Payment with a Website

Referring again to Fig. IB, when users want to carry out an online payment at a website the following steps and processes may occur:

The user enters a website hosted at web server 9. When a user wants to pay for a good or service online, the user will be prompted to enter their identification details i.e. their name and ID or passport number - S I. The details entered are real world identification details and not the ID associated with the device. The web server has no knowledge of the secure device associated ID, and such information is not shared with the web server.

The website 9 sends to the payment server 4 the real world identification information and the amount to be transacted, in S2.

The payment server then checks whether the buyer's device 2 has the required balance to cover the transaction amount and fee. The payment server may also send to the device 2 an indication of the company which is to accept the online payment. The information identifying the company may be sent to the device at any time during the transaction provided that, when the user opens the online client, the client indicates for which company the token is meant for.

On verification of sufficient funds, the payment server 4 generates a token which is sent to the website - S3, and displayed or otherwise made available to the user - S4. Alternatively, the payment server can send the token to the device so that the user inputs the token into the website. The token generated has a time limit after which it cannot be used as it becomes invalid.

The user opens the online payment module in his device 2 and inputs the token as it is displayed to him on the website.

The device 2 then sends the token to the payment server 4, S5. In the alternative embodiment, in which the token was sent to the device for the user to key the token in the website, the website sends the keyed to the payment server. In either case, the server 4 then matches the token sent with the one which was generated and displayed, whether it was displayed on the website or on the device.

On verification, the payment server generates a time stamp, which time stamp is sent to the buyer's device 2. Further, the payment server sends instructions for the transaction amount and fees to be debited from the buyer's device - S6.

The user obtains a confirmation via their device and the website that the transaction has been successful.

The transaction amount is then credited directly to the business 's bank account which receives the online payment.

The transaction log, which consists of the transaction amount, identification code of the buyers device, time stamp, type of transaction, closing efloat balance and identification ID of the company accepting online payments for the current transaction may be synchronized as described above, along with other transactions currently stored in the device. Upon synchronization, the revenues due to the different banks and to the service provider may be calculated at the payment server 2.

Another approach is whereby once the payment server matches real world user information with the user identity associated with a particular device, the payment server sends an authorizing request to the device. The user presses a key authorizing the online transaction, and the device sends a response to the payment server which includes the user identity of the device. The payment server checks whether the response came from the expected device and if so, the online transaction is completed. There is a time period within which the server expects a response from the device after sending an authorizing request. The online transaction may only be completed if the response from the device is sent and received within this time period.

In greater detail, the online payment procedure is as shown in the flow chart of

Fig. 28. When users want to affect an online payment the following steps and processes occur:

The user enters a website and finds goods or services of interest. When a user wants to pay for a good or service online, the user may be prompted to enter their real world identification details i.e. their name and ID or passport number - 250.

In box 252, the website sends to the payment servers the identification information and the amount to be transacted. In box 254 the payment servers determine whether the identification information provided in fact corresponds to an existing payment device.

In box 256, the payment servers then check whether the buyer's device has the required balance to cover the transaction amount and fee. If the amount is insufficient then flow proceeds to box 258, and the user is notified of the insufficient funds.

On verification of sufficient funds, flow continues to box 260 and the payment servers generate a token which is sent to the website, and displayed. The token can alternatively be sent to the device instead of being displayed in the website. At this point a timer may be started. Once the timer expires the generated token becomes invalid.

Flow proceeds to box 262, in which the user opens the online payment module in the payment device and inputs the token that he/she sees displayed on the website. In the case of the token being sent to the device, the user keys in the token appearing on the device into the appropriate box on the website.

In box 264 the timer is checked to ensure that the token is still valid. If the token is invalid because it has expired then the transaction fails, and flow continues to box 266 where error information is displayed.

If the transaction has not been timed out then flow continues to box 268, where the device (or the website as appropriate) then sends the token to the payment server. The server then matches the token sent with the one that was generated.

If the token fails to match then flow proceeds to box 270. An error message is displayed and the transaction fails. On verification, box 272 is entered and the transaction is indicated as successful. If for some reason the transaction is not successful, an error message is displayed, box 270. The payment server generates a time stamp and the time stamp is sent to the buyer's payment device. Also, the payment servers send instructions for the transaction amount and fees to be debited from the buyer's payment device. The payment servers also send to the buyer's device the identification ID for the company which is accepting online payments.

At the same time, the user gets a confirmation via their device and the website that the transaction has been successful. The transaction amount is then credited directly to the bank account of the business receiving the online payment. In box 274, a transaction log is made at the device. The transaction log may consist of the transaction amount, identification code of the buyer's device, time stamp, type of transaction, ending efloat balance and identification ID of the company accepting online payments. The transaction log is synchronized, along with others stored in the device, with the payment servers. Upon synchronization, the revenues due to the different banks and the other entities may then be calculated in the payment servers.

In box 276, a display is provided to indicate that the transaction is complete, and the device vibrates. The notification may include any of the information mentioned above which is included in the transaction log.

Bill/Remote payments

Referring now to Fig. 29, remote payments are payments that occur between individuals and a business entity which are not in close proximity. The remote payments method is particularly suitable for institution-type entities. For example, the device can enable users to pay for utility bills, such as water and electricity, and other bills such as monthly internet bills, cable TV subscriptions etc. without physically going to these institutions.

The payer opens the application module concerned with remote micropayments, and keys in the amount to be paid remotely - box 300. The device checks it has sufficient funds in box 302. If not the transaction is failed and a suitable notification is displayed to the payer.

Each institution i.e. utility company, university, cable TV Company etc, may be provided with a unique pay-bill number that it may provide to its customers who want to pay for bills remotely. The institution may also provide to each of their customer a unique number i.e. account number or user ID. The account number or identification number is a number issued by the institution which allows it to identify which of its customers have made a remote payment.

The pay-bill number is then entered in box 304 and is sent in encrypted format by the payer's device to the payment servers. The payment server then determines if the keyed pay-bill number is valid, box 306. If the pay-bill number is not valid the user is prompted to re-enter the valid pay-bill number. If the pay-bill number is valid, the user is prompted to enter the account number, box 308. The server then searches its database and then sends the full names of the institution to the sender's device, which information is displayed on the sender's device in box 310. Given people recognize easily names/text rather than numbers, the payer can easily verify to which institution they are sending money to.

If the payer is paying remotely to an institution for the first time, they may be required to key the institution's pay-bill number and their account number or identification number. The device may then save the information so that in future if the user wants to make a remote payment to the institution, the payer simply selects the name of the institution, instead of having to re-key all the details.

Returning to the figure and the payer confirms the transaction in box 312.

The wireless communication module within the device then sends the transaction information, such as transaction amount, identification code of the payer's device, the payers account number or identification number and the pay-bill number of the institution the payment is due, to the payment servers.

Once the payment servers confirm the receipt of the transaction information, a time stamp is generated at the payment servers and sent to the payer's device. The payer's device balance is then debited with the transaction amount and transaction fee. The payer receives a confirmation that the transaction is complete.

The payment servers then automatically credit the bank account of the institution with the amount sent by the payer-box 314. A list is later sent to the institution of the customers who have made remote payments.

In the event that the transaction is successful, box 316, the transaction log, which records transaction amount, time stamp, type of transaction, ending efloat balance, identification code of the payers device, the payers account number or identification number and the pay-bill number of the institution the payment is due for the present transaction, is recorded— box 317, and is synchronized with the payment server, along with any other outstanding logs stored in the device. Upon synchronization, the revenues due to the different banks and other entities may be calculated in the payment servers.

If the transaction is not successful for any reason, an error message is displayed

- box 318. If the transaction is successful, an appropriate display is shown on the device and the device vibrates, box 320. Reference is now made to Fig. 30 which illustrates a further alternative for use of the electronic wallet device of the present embodiments. The user is initially provided with a user ID - 340 and then requests a transaction, 342. The user ID is used to associate the user, the terminal device and the bank accounts, 344. As discussed above, the user ID may associate indirectly using an intermediate stage such as a user account. A server or like on-line location managing the transaction then sends a confirmation request to the terminal device asking the user to confirm the transaction 346. Typically the confirmation request includes details of the transaction, and the user confirms with a button press or using speech or in any other suitable way 348.

At this point the terminal device has the user's confirmation but the server does not, so the terminal device sends an indicator of the confirmation to the server, 350. Once the indicator is received at the server the transaction may be completed 352. In an embodiment, a time limit may be set for completion of the transaction, so that the transaction is only completed if the indication is received within the time limit.

Credit Issuance and Insurance Subscription

The payment device can be used to offer credit or even enable users to subscribe to insurance policies or pay for insurance premiums. In particular, the payment device can be used for the issuance of micro-credit and subscription to micro-insurance products.

In such an embodiment, the payment device may be used to issue credit. Over time, the payment servers may collect and store payment data of users. Algorithms may be used to automatically analyze the data collected for a particular user and determine the user's credit limit. The algorithms may consider other sources of data to determine credit limits i.e. data from the credit reference bureau, government databases and banking records. Thus users may be able to quickly access credit on the go without human interaction, involvement or the need for collateral.

The payment device may additionally be used by users to subscribe to insurance policies. The device is particularly suited for the issuance of micro-credit. Users may be able to subscribe to one day travel insurance for example. Also, users may use the device to pay on a daily or weekly basis their insurance premiums. These payments may be deducted automatically or the user may be prompted to make a payment within a certain time frame i.e. within 12 hours. This enables users who are unable to pay for the insurance premium upfront to pay in small regular installments.

It is expected that during the life of a patent maturing from this application many relevant communication networks and possibilities will be developed and the scopes of the corresponding terms are intended to include all such new technologies a priori.

The terms "comprises", "comprising", "includes", "including", "having" and their conjugates mean "including but not limited to".

The term "consisting of means "including and limited to".

As used herein, the singular form "a", "an" and "the" include plural references unless the context clearly dictates otherwise.

It is appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment, and the above description is to be construed as if this combination were explicitly written. Conversely, various features of the invention, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or as suitable in any other described embodiment of the invention, and the above description is to be construed as if these separate embodiments were explicitly written. Certain features described in the context of various embodiments are not to be considered essential features of those embodiments, unless the embodiment is inoperative without those elements.

Although the invention has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications and variations that fall within the spirit and broad scope of the appended claims.

All publications, patents and patent applications mentioned in this specification are herein incorporated in their entirety by reference into the specification, to the same extent as if each individual publication, patent or patent application was specifically and individually indicated to be incorporated herein by reference. In addition, citation or identification of any reference in this application shall not be construed as an admission that such reference is available as prior art to the present invention. To the extent that section headings are used, they should not be construed as necessarily limiting.