AU2015337839B2

AU2015337839B2 - Electronic money, method of producing electronic money and transaction method using electronic money

Info

Publication number: AU2015337839B2
Application number: AU2015337839A
Authority: AU
Inventors: Bashar Mahmoud Sadi Hasan
Original assignee: In4ma Pty Ltd
Current assignee: In4ma Pty Ltd
Priority date: 2014-10-31
Filing date: 2015-10-15
Publication date: 2020-07-30
Anticipated expiration: 2035-10-15
Also published as: WO2016065390A1; AU2015337839A1

Abstract

The present invention is directed to a computer readable medium comprising a monetary value indication and a device unique ID (DU-ID) identifying a personal mobile device. The electronic cash token may be generated by receiving an electronic cash-in request comprising a monetary value, a user identification and a DU-ID; generating an electronic cash-in token comprising the monetary value, the user identification and the DU-ID and sending the electronic cash-in token to the personal computing device associated with the DU-ID; receiving a cash-in confirmation comprising the monetary value received, the user identification, the DU-ID and a payee identifier; encoding the monetary value, user ID and the DU-ID as an electronic cash token; and sending the electronic cash token to the personal computing device associated with the DU-ID.

Description

TITLE

ELECTRONIC MONEY, METHOD OF PRODUCING ELECTRONIC MONEY AND

TRANSACTION METHOD USING ELECTRONIC MONEY FIELD OF THE INVENTION

[1 ] The present invention relates to electronic money and methods of producing electronic money and transacting with the electronic money. More particularly, the invention relates to electronic money and methods utilising a Unique Device Identifier (DU-ID) which identifies a personal mobile computing device.

BACKGROUND TO THE INVENTION

[2] An increasingly large number of transactions are being conducted electronically. Despite this, some transactions still require cash or cash-like monetary instruments that have some kind of guarantee such as, negotiable instruments like, cheques and money orders.

[3] Electronic money and a method of producing and transacting with electronic money is highly desirable. Crypto currencies, like Bitcoin, have a sole issuer and are open to any user. To make a payment with a cryptocurrency, a sender is able to send cash via a bitcoin agent paid in their local currency, then the amount is translated to the bitcoin equivalent and transferred digitally in real-time to a bitcoin agent on the other end. The receiving agent will translate the bitcoin back into the local currency and pay the receiving party the equivalent amount as cash. In this instance, the cryptocurrency is being utilized as the remittance medium for the transfer. Cryptocurrencies are susceptible to abuse by unscrupulous users.

SUMMARY OF THE INVENTION

[4] The present invention is broadly directed to a form of electronic money and a method of producing electronic money and a method of transacting with electronic money.

[5] In a broad form, the invention relates to electronic money, a method for producing electronic money and a method of transacting with electronic money in which the electronic money comprises a device unique ID (DU-ID) identifying a personal mobile device.

[6] A preferred advantage of the method and medium of the present invention is that the electronic money can be treated as essentially equivalent to cash. [7] In a first aspect, the present invention provides a computer readable medium comprising a monetary value indication and a device unique ID (DU-ID) identifying a personal mobile device.

[8] The DU-ID may comprise an international mobile subscriber identity (IMSI).

[9] The monetary value indication may comprise one or more of a numerical value and a currency.

[ 10] The computer readable medium is preferably non-transitory.

[1 1 ] In a second aspect, the present invention provides a method for generating an electronic cash token comprising:

receiving an electronic cash-in request comprising a monetary value, a user identification and a DU-ID;

generating an electronic cash-in token comprising the monetary value, the user identification and the DU-ID and sending the electronic cash-in token to the personal computing device associated with the DU-ID;

receiving a cash-in confirmation comprising the monetary value received, the user identification, the DU-ID and a payee identifier;

encoding the monetary value, user ID and the DU-ID as an electronic cash token; and

sending the electronic cash token to the personal computing device associated with the DU-ID.

[12] In one embodiment of the second aspect, the encoding comprises encoding as an electronic bar code, such as a QR code.

[13] In another embodiment of the second aspect, the encoded electronic cash token may be stored in a database.

[14] In yet another embodiment of the second aspect, the electronic cash in request further comprises a currency.

[15] In a third aspect the present invention provides a method for transferring an electronic cash token comprising:

receiving a cash-to request comprising an electronic cash token or a unique token identification associated with the electronic cash token, a DU-ID associated with a current owner of the electronic cash token and a recipient mobile telephone number or recipient unique alias and or tag;

validating cash token ownership by matching the electronic cash token or the unique token identification with an electronic database;

sending a cash-to token and a cash-to confirmation code to the mobile computing device associated with the current owner;

receiving a cash-to confinnation comprising the cash-to confinnation code and the cash-to token;

matching the received cash-to confirmation code with the received cash-to token; and

transfening the electronic cash token by updating the electronic database to associate the electronic cash token with an account linked to the recipient mobile telephone number or recipient unique alias and/or tag.

[16] In one embodiment of the third aspect, the recipient mobile number may be received at a different time to the cash-to request.

[17] In another embodiment of the third aspect, the method may further comprise recoding a computer readable medium associated with the electronic cash token. The computer readable medium may be associated with the cunent owner and/or the recipient.

[18] In yet another embodiment of the third aspect, the cash-to request may further comprise a condition.

[19] In a fourth aspect the invention provides a method of authorising cash dispensing comprising:

receiving a cash-out request comprising a cash token or a unique token identification associated with the electronic cash token from a cash dispenser;

sending a cash-out confirmation code to an owner of the cash token and storing the cash-out confirmation code in an electronic database;

receiving from the cash dispenser a cash-out confirmation comprising the cash- out confirmation code;

matching the received cash-out confinnation code with the stored cash-out confirmation code; and

sending a cash-out authorisation to the cash dispenser authorising the dispensing of cash.

[20] The method of the fourth aspect may further comprise a step of the cash dispenser obtaining the cash token or the unique token identification from the cash token owner. The obtaining may comprise scanning for example an electronic barcode displayed on the owner's personal computing device.

[21] The method of the fourth aspect may further comprise sending an electronic cash- out token to the dispenser.

[22] In one embodiment of the fourth aspect, the receiving from the cash dispenser a cash-out confirmation further comprises receiving a cash-out token.

[23] In a fifth aspect the invention provides a method for conditionally transferring an electronic cash token comprising:

receiving a conditional cash-to request comprising the electronic cash token or a token unique ID (TU-ID) associated with the electronic cash token, a device unique ID (DU-ID) associated with a current owner unique ID of the electronic cash token (OU- ID), a recipient mobile telephone number or recipient unique alias and/or tag and one or more conditions;

validating cash token ownership by matching the electronic cash token or the TU- ID with an electronic database;

sending a cash-to token and a cash-to confirmation code to the current owner; receiving a cash-to confirmation comprising the cash-to confirmation code and the cash-to token;

matching the received cash-to confirmation code with the received cash-to token; receiving confirmation that the one or more conditions have been met; and transferring the electronic cash token by updating the electronic database to associate the electronic cash token with an account linked to the recipient mobile telephone number or recipient unique alias and/or tag.

[24] In one embodiment of the fifth aspect, the recipient mobile telephone number or recipient unique alias and/or tag may be received at a different time to the cash-to request.

[25] In another embodiment of the fifth aspect, the method may further comprise recoding a computer readable medium associated with the electronic cash token. The computer readable medium may be associated with the current owner and/or the recipient.

[26] In another embodiment of the fifth aspect, the transfer of the electronic cash token is performed before confirmation is received and the transferred electronic cash token comprises a bar to use. The bar to use may be removed when confirmation is received.

[27] According to one embodiment of the fifth aspect, the confirmation may be received from one or more of the current owner, the recipient and a third party. Preferably, the confirmation must be received from one or both of the current owner and/or a third party.

[28] In a sixth aspect, the invention provides a method for generating and transferring an electronic cash token, the method comprising:

receiving an electronic cash-to request comprising a monetary value, a user unique ID (UU-ID), a device unique ID (DU-ID) and recipient details;

generating an electronic cash-in token comprising the monetary value, the UU-ID and the DU-ID and sending the electronic cash-in token to the personal computing device associated with the DU-ID;

receiving a cash-in confirmation comprising the monetary value, the UU-ID, the DU-ID and a payee identifier;

encoding the monetary value, UU-ID and the DU-ID as an electronic cash token; and

sending the electronic cash token to the recipient using the recipient details.

[29] The recipient may comprise a currency exchange. The currency exchange may exchange the electronic cash token for funds in a different currency and transfer the funds in a different currency to a vendor. The vendor may be identified by vendor details comprised in the recipient details. The different currency may be designated in the recipient details.

[30] In one embodiment of the sixth aspect, the recipient details may comprise a recipient mobile telephone number or recipient unique alias/tag. The recipient details may comprise contact details for the currency exchange. The recipient details may comprise contact details for the vendor.

[31 ] The recipient details may be obtained by inputting them into a user or remitter's personal computing device. The input may comprise scanning, photographing or otherwise reading or inputting a barcode or other code displayed by the vendor.

[32] In one embodiment of the sixth aspect, the encoding comprises encoding as an electronic bar code, such as a QR code.

[33] In yet another embodiment of the sixth aspect, the cash-to request may further comprise a condition.

[34] According to any above aspect, any request, token, confirmation, confirmation code or unique token identification may be encrypted. The encryption may comprise Public IU-Key or a Public OU-Key. Any received encoded request, token or confirmation may be decrypted using Private IU-Key or Private OU-Key.

[35] The electronic cash-in computer token, may comprise an electronic bar code such as a Quick Response (QR) code.

[36] The sending and receiving may be performed through an application stored on the mobile computing device or through a mobile communications system such as, SMS (short messaging service).

[37] The methods of the invention may further include a step of sending a confirmation message. The confirmation message may be sent by SMS.

[38] According to any above aspect, a new user registration form comprising an Owner Name, Owner Mobile Number, encrypted Owner DU-ID may be submitted.

[39] According to any above aspect, the server computer may decrypt the Owner DU- ID and checks if against a database to complete device registration.

[40] According to any above aspect, the server computer may also do one or more of the following: generate Unique Public/Private Keys for personal mobile computing device, store the Public OU-Key in the database and store the Private Owner OU-Key in database or a Trust-base.

[41 ] Where the terms "comprise", comprises", "comprising", "include", "includes", "included" or "including" are used in this specification, they are to be interpreted as specifying the presence of the stated features, integers, steps or components referred to, but not to preclude the presence or addition of one or more other feature, integer, step, component or group thereof.

[42] Further, any prior art reference or statement provided in the specification is not to be taken as an admission that such art constitutes, or is to be understood as constituting, part of the common general knowledge.

BRIEF DESCRIPTION OF THE FIGURES

[43] In order that the present invention may be readily understood and put into practical effect, reference will now be made to the accompanying illustrations, wherein like reference numerals refer to like features and wherein:

[44] Figure 1A and Figure I B:, show one embodiment of a personal mobile computing device suitable for use with the invention.

[45] Figure 2: show the structure of the cash tokens according to one embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

[46] The present invention relates to electronic money and methods of producing electronic money and transacting with the electronic money.

[47] The present invention is at least partly predicated on the inventor's application of a DU-1D to electronic money to allow the integration of a personal mobile computing device with electronic cash.

[48] The following description refers to specific embodiments of the present invention and is in no way intended to limit the scope of the present invention to those specific embodiments.

[49] One embodiment of a personal mobile computing device 200 suitable for use in the present invention is shown in Figs. 1A and IB. In the embodiment shown personal mobile computing device 200 comprises a computer module 201 comprising input devices such as a keyboard 202, a mouse pointer device 203, a scanner 226, an external hard drive 227, a touchscreen video display 214 and a microphone 280; and output devices including a printer 215, the touchscreen video display device 214 and loudspeakers 217. In some embodiments video display 214 may comprise a touchscreen.

[50] A Modulator-Demodulator (Modem) transceiver device 216 may be used by the computer module 201 for communicating to and from a communications network 220 via a connection 221. The network 220 may be a wide-area network (WAN), such as the Internet, a cellular telecommunications network, or a private WAN. Through the network 220, computer module 201 may be connected to; and may have system interaction 293 with; other similar personal mobile computing devices 290 or server computers 291 and may have user interaction 294 with user 295. Where the connection 221 is a telephone line, the modem 216 may be a traditional "dial-up" modem. Alternatively, where the connection 221 is a high capacity (e.g.: cable) connection, the modem 216 may be a broadband modem. A wireless modem may also be used for wireless connection to network 220.

[51 ] The computer module 201 typically includes at least one processor 205, and a memory 206 for example formed from semiconductor random access memory (RAM) and semiconductor read only memory (ROM). The module 201 also includes a number of input/output (I/O) interfaces including: an audio-video interface 207 that couples to the touchscreen video display 214, loudspeakers 217 and microphone 280; an I/O interface 213 for the keyboard 202, mouse 203, scanner 226 and external hard drive 227; and an interface 208 for the external modem 216 and printer 215. In some implementations, modem 216 may be incorporated within the computer module 201 , for example within the interface 208. The computer module 201 also has a local network interface 21 1 which, via a connection 223, permits coupling of the personal mobile computing device 200 to a local computer network 222, known as a Local Area Network (LAN).

[52] As also illustrated, the local network 222 may also couple to the wide network 220 via a connection 224, which would typically include a so-called "firewall" device or device of similar functionality. The interface 211 may be formed by an Ethernet circuit card, a Bluetooth wireless arrangement or an IEEE 802.1 1 wireless arrangement, a Near Field Communication, NFC, arrangement or other suitable interface.

[53] The I/O interfaces 208 and 213 may afford either or both of serial and parallel connectivity, the former typically being implemented according to the Universal Serial Bus (USB) standards and having corresponding USB connectors (not illustrated).

[54] Storage devices 209 are provided and typically include a hard disk drive (HDD) 210. Other storage devices such as, an external HD 227, a disk drive (not shown) and a magnetic tape drive (not shown) may also be used. An optical disk drive 212 is typically provided to act as a non-volatile source of data. Portable memory devices, such optical disks (e.g.: CD-ROM, DVD, Blu-Ray Disc), USB-RAM, external hard drives and floppy disks for example may be used as appropriate sources of data to the personal mobile computing device 200. Another source of data to personal mobile computing device 200 is provided by the at least one server computer 291 through network 220.

[55] The components 205 to 213 of the computer module 201 typically communicate via an interconnected bus 204 in a manner which results in a conventional mode of operation of personal mobile computing device 200. In the embodiment shown in FIGS. 1A and I B, processor 205 is coupled to system bus 204 through connections 218. Similarly, memory 206 and optical disk drive 212 are coupled to the system bus 204 by connections 219. Examples of personal mobile computing device 200 on which the described arrangements can be practiced include smart phones; tablet computers, gaming consoles, media players, TVs, wearable devices such as watches and glasses or a like device comprising a computer module like computer module 201. It is to be understood that when personal mobile computing device 200 comprises a smart phone or a tablet computer some illustrated input and output devices may not be included such as, mouse pointer device 201 ; keyboard 202; scanner 226; and printer 215.

[56] Fig. I B is a detailed schematic block diagram of processor 205 and a memory 234. The memory 234 represents a logical aggregation of all the memory modules, including the storage device 209 and semiconductor memory 206, which can be accessed by the computer module 201 in Fig. 1 A.

[57] The methods of the invention may be implemented using personal mobile computing device 200 wherein the methods may be implemented as one or more software application programs 233 executable within computer module 201. In particular, the steps of the methods of the invention may be effected by instructions 231 in the software carried out within the computer module 201

[58] The software instructions 231 may be formed as one or more code modules, each for performing one or more particular tasks. The software 233 may also be divided into two separate parts, in which a first part and the corresponding code modules performs the method of the invention and a second part and the corresponding code modules manage a graphical user interface between the first part and the user.

[59] The software 233 may be stored in a computer readable medium, including in a storage device of a type described herein. The software is loaded into the personal mobile computing device 200 from the computer readable medium or through network 221 or 223, and then executed by personal mobile computing device 200. In one example the software 233 is stored on storage medium 225 that is read by optical disk drive 212. Software 233 is typically stored in the HDD 210 or the memory 206.

[60] A computer readable medium having such software 233 or computer program recorded on it is a computer program product. The use of the computer program product in the personal mobile computing device 200 preferably effects a device or apparatus for implementing the methods of the invention.

[61] In some instances, the software application programs 233 may be supplied to the user encoded on one or more disk storage medium 225 such as a CD-ROM, DVD or Blu- Ray disc, and read via the corresponding drive 212, or alternatively may be read by the user from the networks 220 or 222. Still further, the software can also be loaded into the personal mobile computing device 200 from other computer readable media. Computer readable storage media refers to any non-transitory tangible storage medium that provides recorded instructions and/or data to the computer module 201 or personal mobile computing device 200 for execution and/or processing. Examples of such storage media include floppy disks, magnetic tape, CD-ROM, DVD, Blu-ray Disc, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computer module 201. Examples of transitory or non -tangible computer readable transmission media that may also participate in the provision of software application programs 233, instructions 231 and/or data to the computer module 201 include radio or infra-red transmission channels as well as a network connection 221, 223, 234, to another computer or networked device 290, 291 and the Internet or an Intranet including email transmissions and information recorded on Websites and the like.

[62] The second part of the application programs 233 and the corresponding code modules mentioned above may be executed to implement one or more graphical user interfaces (GUIs) to be rendered or otherwise represented upon display 214. Through manipulation of, typically, touchscreen 214 a user of personal mobile computing device 200 and the methods of the invention may manipulate the interface in a functionally adaptable manner to provide controlling commands and/or input to the applications associated with the GUI(s). Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilising speech prompts output via loudspeakers 217 and user voice commands input via microphone 280. The manipulations including screen touches, speech prompts, device movement gestures and/or user voice commands may be transmitted via network 220 or 222.

[63] When the computer module 201 is initially powered up, a power-on self-test (POST) program 250 may execute. The POST program 250 is typically stored in a ROM

249 of the semiconductor memory 206. A hardware device such as the ROM 249 is sometimes referred to as firmware. The POST program 250 examines hardware within the computer module 201 to ensure proper functioning, and typically checks processor 205, memory 234 (209, 206), and a basic input-output systems software (BIOS) module 251 , also typically stored in ROM 249, for correct operation. Once the POST program

250 has run successfully, BIOS 251 activates hard disk drive 210. Activation of hard disk drive 210 causes a bootstrap loader program 252 that is resident on hard disk drive 210 to execute via processor 205. This loads an operating system 253 into RAM memory 206 upon which operating system 253 commences operation. Operating system 253 is a system level application, executable by processor 205, to fulfil various high level functions, including processor management, memory management, device management, storage management, software application interface, and generic user interface.

[64] Operating system 253 manages memory 234 (209, 206) in order to ensure that each process or application running on computer module 201 has sufficient memory in which to execute without colliding with memory allocated to another process. Furthermore, the different types of memory available in the personal mobile computing device 200 must be used properly so that each process can run effectively. Accordingly, the aggregated memory 234 is not intended to illustrate how particular segments of memory are allocated, but rather to provide a general view of the memory accessible by computer module 201 and how such is used.

[65] Processor 205 includes a number of functional modules including a control unit 239, an arithmetic logic unit (ALU) 240, and a local or internal memory 248, sometimes called a cache memory. The cache memory 248 typically includes a number of storage registers 244, 245, 246 in a register section storing data 247. One or more internal busses 241 functionally interconnect these functional modules. The processor 205 typically also has one or more interfaces 242 for communicating with external devices via the system bus 204, using a connection 218. The memory 234 is connected to the bus 204 by connection 219.

[66] Application program 233 includes a sequence of instructions 231 that may include conditional branch and loop instructions. Program 233 may also include data 232 which is used in execution of the program 233. The instructions 231 and the data 232 are stored in memory locations 228, 229, 230 and 235, 236, 237, respectively. Depending upon the relative size of the instructions 231 and the memory locations 228-230, a particular instruction may be stored in a single memory location as depicted by the instruction shown in the memory location 230. Alternately, an instruction may be segmented into a number of parts each of which is stored in a separate memory location, as depicted by the instruction segments shown in the memory locations 228 and 229.

[67] In general, processor 205 is given a set of instructions 243 which are executed therein. The processor 205 then waits for a subsequent input, to which processor 205 reacts by executing another set of instructions. Each input may be provided from one or more of a number of sources, including data generated by one or more of the input devices 202, 203, or 214 when comprising a touchscreen, data received from an external source across one of the networks 220, 222, data retrieved from one of the storage devices 206, 209 or data retrieved from a storage medium 225 inserted into the corresponding reader 212. The execution of a set of the instructions may in some cases result in output of data. Execution may also involve storing data or variables to the memory 234.

[68] The disclosed arrangements use input variables 254 that are stored in the memory 234 in corresponding memory locations 255, 256, 257, 258. The described arrangements produce output variables 261 that are stored in the memory 234 in corresponding memory locations 262, 263, 264, 265. Intermediate variables 268 may be stored in memory locations 259, 260, 266 and 267.

[69] The register section 244, 245, 246, the arithmetic logic unit (ALU) 240, and the control unit 239 of the processor 205 work together to perform sequences of micro- operations needed to perform "fetch, decode, and execute" cycles for every instruction in the instruction set making up the program 233. Each fetch, decode, and execute cycle comprises:

(a) a fetch operation, which fetches or reads an instruction 231 from memory location 228, 229, 230;

(b) a decode operation in which control unit 239 determines which instruction has been fetched; and (c) an execute operation in which the control unit 239 and/or the ALU 240 execute the instruction.

[70] Thereafter, a further fetch, decode, and execute cycle for the next instruction may be executed. Similarly, a store cycle may be performed by which the control unit 239 stores or writes a value to a memoiy location 232.

[71] Each step or sub-process in the methods of the invention may be associated with one or more segments of the program 233, and may be performed by register section 244-246, the ALU 240, and the control unit 239 in the processor 205 working together to perform the fetch, decode, and execute cycles for every instruction in the instruction set for the noted segments of program 233.

[72] One or more other personal mobile computer device 290 may be connected to the communications network 220 as seen in Fig. 1A. Each such personal mobile computer device 290 may have a similar configuration to personal mobile computer device 200 comprising a computer module 201 and corresponding peripherals.

[73] One or more other server computer 291 may be connected to the communications network 220. These server computers 291 respond to requests from personal mobile computing device 200, 290 or other server computers to provide infonnation. Each server computer 291 may comprise or be associated with one or more database 292.

[74] The one or more server computer 291 and one or more other personal mobile computer device are connected through network 293 which may be a wide-area network (WAN), such as the Internet, a cellular telecommunications network, or a private LAN/WAN such a local wireless LAN connected to the Internet.

[75] The methods of the invention may alternatively be implemented in dedicated hardware such as one or more integrated circuits performing the functions or sub functions of the described methods. Such dedicated hardware may include graphic processors, digital signal processors, or one or more microprocessors and associated memories.

[76] With reference to the following embodiments, the below definitions may be relevant, depending on the context.

[77] Issuer: an organisation, such as a financial institution, who uses the method and device of the invention to generate and transact with electronic cash tokens according to the invention. [78] Cashier: a party who works for an issuer who receives and dispenses physical cash.

[79] Owner: a party registered with the issuer who can own an electronic cash token and transact with other entities such as, senders, receivers, buyers and merchants.

[80] Sender: a party registered with the issuer who owns an electronic cash token and intends to send it to another party.

[81 ] Receiver: a party registered with the issuer who will receive an electronic cash- token sent by another party.

[82] Buyer: a party registered with the issuer who intends to buy a product or service from a merchant.

[83] Merchant: a party registered with issuer who intends to sell products or services to buyers.

Composition of Cash Token

[84] FIGS. 2A, 2B and 2C show the composition of the cash tokens according to one embodiment of the invention.

[85] FIG. 2A shows the illustrative components of a readable public cash token 100 as comprised on personal mobile computer device 200 and stored within software application program 233. The readable public cash token 100 is stored in cash box 108 of a user account 1 10. In the embodiment shown in FIG. 2 A, token 100 comprises a Token Unique ID (TU-ID) 102, which is generated on issue of the token 100 and a token amount 104 which defines the cash amount. The token amount may also comprise a currency. One device may store and one owner may have more than one token 100 at any one time, and these various tokens may be in different currencies. As indicated in FIG. 2A the token 100 is readable by device 200.

[86] As shown in FIG. 2A, as well as comprising cash box 108, user account 110 also comprises the UU-ID 106. The UU-TD may be generated on user registration 294.

[87] The cash box 108 is comprised in user account 1 10 along with the issuer unique ID 1 12. The IU ID may be embedded in distributed software 233. Software 233 may be distributed to device 200 through network 220.

[88] The DU-ID 269 may be stored on HDD 210 within device 200. The DU-ID 269 may be generated on registration 293 of device 200. [89] FIG. 2B shows part of the composition of database 292, illustrating one example of a private cash token 120 according to the invention. Token 120 comprises a private cash token 120 that matches public cash token 100. Token 120 comprises TU-ID 102; token amount 104; UU1D 6; IUID 1 12 and DU-ID 269. The token amount 104 may also comprise a currency.

[90] FIG. 2C shows one embodiment of an unreadable public cash token 140 comprising TU-ID 102 and token amount 104. As indicated in FIG. 2C, token 140 is unreadable. The unreadability is achieved via encryption and/or other time/location/user- control read-locking mechanism, and allows token 140 to be transferred between, for example, personal mobile computer device 200, server computer 291 and other similar personal mobile computing devices 290.

Operation Use Cases

Cash- In Use Case

[91 ] In one embodiment the present invention is directed to generation of an electronic cash token 100. The Owner 295 of personal mobile computer device 200 may specify 294 the (Cash-ln-Amount), and optionally currency, and press the (Submit-Button) 294 on touchscreen 214. The Owner software application program 233 then encrypts the (Owner DU-ID) 269 associated with the personal mobile computer device 200 using (Public IU-Key) 1 12 and submits 293 the (Cash-In Request) to the server computer 291 and waits for the server computer 291 response.

[92] The server computer 291 receives the (Cash-In-Request), decrypts the (Owner DU-ID) 269 using Private IU-Key 1 12, generates the (Cash- In-Token- ID), and encrypts it using (Public IU-Key), decodes the (Cash-In-Token-ID) as a (QR-lmage) and stores it in database 292.

[93] The server computer 291 then responds to personal mobile computer device 200 request by sending 293 the (QR-URL) encrypted using (Public OU-Key) 106.

[94] The personal mobile computer device 200 receives and decrypts the (QR-URL) using (Private OU-Key) 106 and fetches 293 the (QR-lmage) from server computer 291 and displays it on touch screen 214.

[95] A user 295 can then view 294 (QR-lmage) of the (Cash-In-Token-ID), present it on touchscreen 214 to the Cashier for scanning, press done 294 and wait for a notification. [96] The Cashier 295 scans 294 (QR-lmage) (not shown) of the (Cash-In-Token-ID), decrypts it using (Private IU-Key) 1 12, fetches 293 the (Cash- In- Amount) form the server computer 291, receives the cash and sends 293 (Cash-Token-Generation-Request) to the server 291 with (Cash-In-Token-ID) specified.

[97] The server computer 291 , generates (Cash-Token-ID) 102 and associates it with (Owner DU -ID) 269, encrypts (Cash-Token-ID) 102 using (Public IU-Key) 1 12, encodes it as (QR-lmage) and store it in Database 292.

[98] The server computer 291 sends 293 to the personal mobile computer device 200 the (QR-URL) encrypted using (Public OU-Key) 106.

[99] The personal mobile computer device 200 receives notification from the server computer 291 , the user 295 refreshes 294 the (Cash-Box) 108 to view (Cash-Token) List, clicks 294 on a (Cash-Token) 100 displayed on touchscreen 214 to view it.

[100] The personal mobile computer device 200 decrypts the (QR-URL) using (Private OUKey) 106, fetches 293 the (QR-lmage) from the server computer 291 and display it on the touchscreen 214.

Cash-To Use Case

[101] In another embodiment the invention provides a method for transferring an electronic cash token 100.

[102] The Owner 295 of personal mobile computer device 200, or using the above definitions, the sender, selects 294 a (Cash-Token) 100 displayed on touchscreen 214 and presses 294 (Cash-To-Button) also displayed on touchscreen 214.

[103] The personal mobile computer device 200 encrypts (Cash-Token-ID) and the sender (Owner DU -ID) 269 using (Public IU-Key) 112 and includes them to request 293 a (Cash-To-Token-ID) from the server computer 291.

[104] The server computer 291 decrypts the (Cash-Token-ID) 102 and the sender (Owner DU-ID) 269 using (Private IU-Key) 1 12, generates (Cash-To-Token-ID) , associates it with (Cash-Token-ID) 102 and the sender (Owner DU-ID) 269, stores it in Database 292, encrypts (Cash-To-Token-ID) using (Public OU-Key) 106 and sends 293 it as a response to the sender software application program 233 (Sender App) on personal mobile computer device 200.

[105] The sender personal mobile computer device 200 decrypts the (Cash-To-Token- ID) using Sender (Private OUKey) 106 and displays the (Cash-To-Form) on touchscreen 214.

[106] The Owner 295 then specifies 294 the (Receiver-Mobile-Number) and presses 294 the (Send-Button). The personal mobile computer device 200 encrypts the (Cash- Token-ID) 100, (Cash-To-Token-ID) and the sender (Sender DU-ID) 269 using (Public IU-Key) 1 12 and submits 293 the (Cash-to-Request) to the server computer 291 , and waits for the (Cash-To-Confirmation-Code).

[107] The server computer 291 decrypts the (Cash-Token-ID) 100, (Cash-To-Token-ID) and the sender (Owner DU-ID) 269, validate the ownership and the intention to send a specific (Cash-Token) 100, fetches the receiver (Receiver DU-ID) 269 associated with the (Receiver-Mobile-Number), associates it with the (Cash-To-Token-ID), saves to the Database 292, then sends 293 a (Cash-To-Confirmation-Code) to (Sender-Mobile- Number) by SMS.

[108] The owner 295 of sender personal mobile computer device 200 receives and enters 294 (Cash-To-Confirmation-Code) and presses 294 on the (Submit-Button) on touchscreen 214.

[109] The personal mobile computer device 200 encrypts the (Cash-To-Token-ID) using (Public IU-Key) 1 12, includes it in the (Cash-To-Confinnation-Form) and submits

293 them all to the server computer 291.

[1 10] The server computer 291 matches (Cash-To-Token-ID) with (Cash-To- Confirmation-Code), authorises (Cash-To-Transaction) and completes it by associating the (Cash-Token-ID) 102 with the receiver (Receiver DU-ID) 269, encrypts (Cash- Token-ID) 102 using (Public IU-Key) 1 12, encodes it as (QR-Image) and store it in the Database 292.

[I l l] The server computer 291 then encrypts the (QR-URL) using receiver (Public OUKey) 106 and sends 293 it to the receiver device 290.

[112] The owner 295 of the receiver device 290 receives 294 notification from the server computer 291 , refreshes 294 the (Cash-Box) 108 to view (Cash-Token) List, clicks

294 on a (Cash-Token) 100 on the associated touchscreen 214 to view it.

[1 13] The receiver device 290 may decrypt the (QR-URL) using (Private OU-Key) 106, fetches the (QR-Image) from the server computer 291 and may display it on the associated touch screen 214. Cash- Out Use Case

[114] In another embodiment the invention also provides a method of authorising cash dispensing.

[1 15] The owner 295 of personal mobile computing device 200 displays 294 the (QR Image) of the (Cash-Token) 100 on touchscreen 214 and presents it to a Cashier 295.

[1 16] The Cashier 295 scans 294 the (QR Image) of the (Cash-Token-ID) 102 using a cashier personal mobile computer device 200, reads the (Cash-Token-Amount) 104 to the Owner, presses 294 the (Confirm-Button) and waits for (Cash-Out-Confirmation-Code).

[1 17] The cashier personal mobile computing device 200 encrypts the (Cash-Token-ID) 102 and (Cashier DU-ID) 269 using (Public IU-Key) 1 12 and includes them to request 293 (Cash-Out-Token-ID) from the server 291.

[1 18] The server 291 decrypts the (Cash-Token-ID) 102 and the (Cashier DU-ID) 269 using (Private IU-Key) 112, generates (Cash-Out-Token-ID), associates it with (Cash- Token-ID) 102 and (Cashier DU-ID) 269, stores in Database 292, encrypts (Cash-Out- Token-ID) using (Public IU-Key) 1 12 and sends 293 it as a response to the Cashier software application program 233 and send 293 (Cash-Out-Confirmation-Code) to (Owner-Mobile-Number) by SMS.

[1 19] Cashier personal mobile computing device 200 decrypts the (Cash-Out-Token- ID) using (Private IU-Key) and displays the (Cash-Out-Form) on screen 214 and the cashier 295 asks the owner 295 for the (Cash-Out-Confirmation-Code).

[120] The owner 295 of personal mobile computing device 200 receives and reads 294 (Cash-Out-Confirmation-Code) to the Cashier 295.

[121 ] The Cashier 295 enters 294 (Cash-Out-Confirmation-Code) and presses 294 (Submit-button).

[122] The Cashier software application program 233 encrypts (Cash-Out-Token-ID) and (Cashier DU-ID) 269 using (Public IU-Key) 1 12 and includes them with the (Cash- Out-Confirmation-Code) and requests 293 (Cash-Out-Authorisation-ID) from the server 291.

[123] The server 291 matches (Cash-Out-Token-ID) with (Cash-Out-Confirmation- Code), generates (Cash-Out- Authorisation-ID), associates it with (Cash-Token-ID) 102 and (Cashier DU-ID) 269 and stores it in the Database 292. [124] The server 291 encrypts (Cash-Out-Token-ID), (Cash-Out- Authorisation-ID) and (Cashier DU-ID) 269 using (Public UI-Key) 1 12 and sends 293 it as a response to cashier personal mobile computer device 200.

[125] The Cashier personal mobile computer device 200 decrypts (Cash-Out- Authorisation-ID) and (Cashier DU-ID) 269 using (Private IU-Key) 1 12, checks if received (Cashier DU-ID) 269 matches with locally stored (Cashier DU-ID) 269 then displays the (Cash-Dispensing-Form) which includes (Cash-Out-Authorisation-ID).

[126] The Cashier 294 reviews 294 the (Cash-Dispensing-Form), presses 294 (Redeem- Cash-Token-Button) and waits for (Cash-Token-Redemption-Confirmation). The Cashier personal mobile computer device 200 encrypts (Cash-Out-Token-ID), (Cash-Out- Authorisation-ID) and (Cashier DU-ID) 269 using (Public IU-Key) 1 12 and sends 293 (Cash-Token-Redemption-Advice) to the server 291.

[127] The server 291 decrypts (Cash-Out-Token-ID), (Cash-Out-Authorisation-ID) and (Cashier DU-ID) 269 using (Private IU-Key) 1 12, if all match, then the (Cash-Token) 100 may be redeemed and the Database 292 updated and (Redemption-Completion- Advice) sent 293 as a response to the cashier personal mobile computer device 200.

[128] The Cashier 295 dispenses Cash to the Owner 295 and closes 294 transaction.

Cash For Use Case

[129] The invention also provides a method for conditionally transferring an electronic cash token 100. The conditional method comprises receiving a conditional cash-to request comprising the electronic cash token 100 or a token unique ID (TU-ID) associated with the electronic cash token 100, a DU-ID associated with a current owner of the electronic cash token, a recipient mobile telephone number or recipient unique alias/tag and one or more conditions.

[130] The cash token ownership may then be validated by matching the electronic cash token 100 or the token unique ID (TU-ID) with electronic database 292.

[131] The cash-to token and a cash-to confirmation code is then sent to the current owner. Server computer 291 then receives a cash-to confirmation comprising the cash -to confirmation code and the cash-to token. The received cash-to confirmation code is matched with the received cash-to token.

[132] The conditional method requires that confirmation is received that the one or more conditions have been met. For example, a buyer may make payment to a provider of goods or services but payment may be conditional upon good(s) being received or service(s) being completed. The confirmation may be received from one or more of the current owner, the recipient and a third party. Preferably, the confirmation must be received from one or both of the current owner and a third party. For example, where payment is conditional upon receipt of a good, confirmation may be received from a courier company delivering the good and may be sent to server 291 automatically once delivery is confirmed by signature of the buyer upon delivery.

[133] The electronic cash token 100 is transferred by updating the electronic database 292 to associate the electronic cash token 100 with an account linked to the recipient mobile telephone number or recipient unique alias and/or tag.

[134] The transfer of the electronic cash token 100 may be performed before confirmation is received and the transferred electronic cash token 100 comprises a bar to use. The bar to use may be removed when confirmation is received.

[135] In one embodiment of the Cash For Use case, a buyer selects a (Cash-Token) 100 and presses a (Cash-For-Button) on display 1 14 of buyer computing device 200.

[136] The buyer software application program 233 (Buyer App) then encrypts the (Cash-Token-ID) and the (Buyer DU-ID) using (Public IU-Key) and includes them to request a (Cash-For-Token-ID) from the platform or server 291.

[137] The platform or server 291 decrypts the (Cash-Token-ID), (Service-UID) and the (Buyer DU-ID) using (Private IU-Key), generates a (Cash-For-Token-ID), associates it with the (Cash-Token-ID) and the (Buyer DU-ID), stores it in database 292, encrypts (Cash-For-Token-ID) using Buyer (Public OU-Key) and sends it as a response to the buyer software application program 233 (Buyer App).

[138] The buyer software application program 233 (Buyer App) decrypts the (Cash- For-Token-ID) using Buyer (Private OU-Key) and displays the (Cash-For-Form) on screen 114 of buyer device 200.

[139] The Buyer specifies the (Merchant-Mobile-Number), (Service-Request-ID) and presses the (Send-Button).

[140] The buyer software application programme 233 (Buyer App) encrypts the (Cash- Token-ID), (Cash-For-Token-ID), (Service-Request-ID) and the (Buyer DU-ID) using (Public IU-Key) and submits the (Cash-For Request) to the platform, and waits for the (Cash-For-Confirmation-Code) .

[141] The platform or server decrypts the (Cash-Token-ID), (Cash-For-Token-ID), (Service-Request-ID) and the (Buyer DU-ID), validates the Ownership and the intention to send a specific (Cash-Token), fetches the (Merchant DU-ID) associated with the (Merchant-Mobile-Number), associates it with the (Cash-For-Token-ID), save to the Database 292, then sends a (Cash-For-Confirmation-Code) to (Merchant-Mobile- Number) by for example, SMS.

[142] The buyer device 200 receives and enters (Cash-For-Confirmation-Code) and presses on the (Submit-Button).

[143] The buyer software application program 233 (Buyer App) encrypts the (Cash- For-Token-ID) using (Public IU-Key), includes it in the (Cash-For-Confirmation-Form) and submits them all to the platform or server 291 .

[144] The platform or server 291 matches the (Cash-For-Token-ID) with the (Cash-For- Confirmation-Code), authorises the (Cash-For-Transaction) and completes it by associating the (Cash-Token-ID) with the (Merchant DU-ID), sets the (Cash-Token- Status) to "On-Hold", encrypts the (Cash-Token-ID) using the (Public IU-Key), encodes it as (QR-Image) and stores it in the Database 292.

[145] The platform or server encrypts the (QR-URL) using the merchant (Public OU- Key) and sends to the merchant device 200.

[146] The merchant device 200 receives notification from the platform or server 291 , refreshes the (Cash-Box) to view the (Cash-Token) List, and when a (Cash-Token) is clicked on it is displayed on screen 1 14.

[147] The merchant application software 233 (Merchant App) decrypts the (QR-URL) using the Merchant (Private OU-Key), fetches the (QR-Image) from the platform and displays it on the screen with an "On-Hold" status water mark clearly displayed on it and the (QR-Image) is in a read lock mode.

[148] The Delivery Service sends a (Cash-Release-Request) with (Service-Request-ID) to platform or server 291 when the relevant service is delivered.

[149] The platform or server 291 fetches the (Cash-Token-ID) associated with the received (Service-Request-ID), validates the (Cash-Release-Request) then sets the (Cash- Token-Status) to "Released". [150] The merchant device 200 receives notification from the platform or server, refreshes the (Cash-Box) to view the (Cash-Token) List, and when a (Cash-Token) is clicked on it may be viewed on screen 1 14.

[151] The merchant application software 233 (Merchant App) then decrypts the (QR- URL) using the Merchant (Private OU-Key), fetches the (QR-lmage) from the platform and displays it on the screen 1 14.

Cash In and To Use Case

[152] The invention also provides a method for generating and transferring an electronic cash token 100. According to this Cash In and To method, electronic cash-to request comprising a monetary value, a user unique ID (UU-ID) a DU-ID and recipient details are received by server 291. In response an electronic cash-in token comprising the monetary value, the UU-ID and the DU-ID is generated and the electronic cash-in token is sent to the personal computing device 200 associated with the DU-ID.

[153] Then a cash-in confirmation comprising the monetary value, the UU-ID, the DU- ID and a payee identifier is received by server 291. In response the monetary value, UU- ID and the DU-ID is encoded as an electronic cash token. The electronic cash token is then sent to the recipient using the recipient details.

[154] In one particularly advantageous embodiment of the present invention, the recipient may comprise a currency exchange. The currency exchange may then swap the electronic cash token for funds in a different currency and transfer the funds in a different currency to a vendor. The vendor may be identified by vendor details comprised in the recipient details. Also, the different currency may be designated in the recipient details.

[155] As with above embodiments, the recipient details may comprise a recipient mobile telephone number or recipient unique alias/tag. In this embodiment, the recipient details may also comprise contact details for the currency exchange and/or contact details for the vendor.

[156] To aid the ease of use of the present invention, the recipient details may be obtained by inputting them into a user or remitter's personal computing device. The input may comprise scanning, photographing or otherwise reading or inputting a barcode or other code displayed by the vendor.

[157] In one embodiment of a Cash-In-Cash-To Use case, a buyer specifies the (Cash- In-Cash-To-Amount) in a currency (Base-Currency), scans or otherwise enters a (Merchant-UID) then presses (Next- Button), follows payment instructions and presses a (Pay-Button) on buyer device 200.

[158] The buyer software application program 233 (Buyer App) receives (Payment- Confirmation-ID), encrypts it with the (Buyer DU-ID) using a Buyer (Public IU-Key) and submits the (Cash-In-Cash-To-Order) to the platform and waits for the platform or server 291 response.

[159] The platform or server 291 receives the (Cash-In-Cash-To-Order), decrypts (Buyer DU-ID), generates (Cash-In-Cash-To-Token-ID), and encrypts it using Buyer (Public OU-Key), decodes (Cash-In-Cash-To-Token-ID) as (QR-lmage) and stores it in the database 292.

[160] The platform or server 291 responds to the buyer request by sending the (QR- URL) encrypted using Buyer (Public OU-Key).

[161] The buyer software application program 233 (Buyer App) receives and decrypts (QR-URL) using Buyer (Private OU-Key) and fetches the (QR-lmage) from platform or server 291 and displays it on screen 214.

[162] The buyer views the (QR-lmage) of the (Cash-In-Cash-To-Token-ID), presents it to the Merchant for scanning, then presses the (Transfer-Button).

[163] The merchant scans the (QR-lmage) of the (Cash- In-Cash-To-Token-ID), decrypts it using the Merchant (Private OU-Key), fetches the (Cash-In-Cash-To-Amount) from the platform or server 291 and sends (Cash-From-Request) to the platform or server 291 with the (Cash-In-Cash-To-Token-ID) specified.

[164] The platform or server 291 matches the received (Merchant-UID) with (Merchant-UID) associated with the (Cash-In-Cash-To-Token-ID) stored in the platform or server 291 and, authorises a (Cash-In-Cash-To-Transaction and completes it by associating the (Cash-Token-ID) with the Merchant (Owner DU-ID), encrypts the (Cash- Token-ID) using Merchant (Public OU-Key), encodes it as (QR-lmage) and stores it in the database 292.

[165] The platform or server 291 encrypts the (QR-URL) using Merchant (Public OU- Key) and sends to the merchant device.

[166] The merchant receives notification from the platform, refreshes the (Cash-Box) to view the (Cash-Token) List and clicks on a (Cash-Token) to view it. [167] The merchant software application program 233 (Merchant App) decrypts the (QR-URL) using Merchant (Private OU-Key), fetches the (QR-lmage) from the platfonn or server 291 and display it on the screen 214.

Cash-Exchange-Out Case

[168] The merchant displays th e (QR Image) of the (Cash-Token) 100 and presents it to Cashier.

[169] The cashier scans the (QR Image) of the (Cash-Token-ID), reads the (Cash- Token-Amount) to the Merchant, specifies the (Exchange-Currency), negotiates the exchange rate, specifies the (Exchange-Rate), presses the (Confirm-Button) and waits for the (Cash-Ex-Out-Confirmation-Code).

[170] The cashier software application program 233 (Cashier App) encrypts the (Cash- Token-ID) and (Cashier DU-ID) using (Public IU-Key) and includes them to request (Cash-Out-Token-ID) from the platfonn or server 291.

[171] The platfonn or server 291 decrypts the (Cash-Token-ID) and the (Cashier DU- ID) using (Private IU-Key), generates (Cash-Ex-Out-Token-ID), associates it with (Cash- Token-ID) and the (Cashier DU-ID), stores in Database 292, encrypts (Cash-Ex-Out- Token-ID) using (Public IU-Key) and sends it as a response to the (Cashier App) and sends (Cash-Ex-Out-Confinnation-Code) to (Merchant-Mobile-Number) by SMS.

[172] The cashier software application program 233 (Cashier App on cashier computing device 200 decrypts the (Cash-Ex-Out-Token-ID) using (Private IU-Key) and displays the (Cash- Ex-Out-Form) on screen 114 and asks the Merchant for (Cash-Ex-Out- Confirmation-Code) .

[173] The Merchant computing device 200 Receives and reads the (Cash-Ex-Out- Confirmation-Code) to the Cashier.

[174] The Cashier enters (Cash- Ex -Out-Confirmation-Code) into cashier computing device 200 and presses the (Submit-button).

[175] The cashier software application program 233 (Cashier App) encrypts the (Cash- Ex-Out-Token-ID) and (Cashier DU-ID) using (Public IU-Key) and includes them with the (Cash-Ex-Out-Confinnation-Code) and requests (Cash-Ex-Out-Authorisation-ID) from the platform.

[176] The platform or server 291 matches the (Cash-Ex-Out-Token-ID) with (Cash-Ex- Out-Confirmation-Code), generates (Cash-Ex-Out-Authorisation-ID), associates it with (Cash-Token-ID) and (Cashier DU-ID) and store it in the Database 292.

[177] The platform or server 291 encrypts the (Cash-Ex-Out-Token-ID), (Cash- Ex-Out- Authorisation-ID) and (Cashier DU-ID) using (Public IU-Key) and sends it as a response to cashier software application 233.

[178] The cashier software application 233 (Cashier App) decrypts the (Cash-Ex-Out- Authorisation-ID) and (Cashier DU-ID) using (Private IU-Key), and if received (Cashier DU-ID) is matched with locally stored (Cashier DU-ID) then displays the (Cash- Exchange-Form) which includes (Cash-Ex-Out-Authorisation-ID).

[179] The Cashier reviews the (Cash- Exchange-Form), presses (Exchange-Button) and waist for (Cash-Token-Exchange-Confirmation).

[180] The cashier software application program 233 (Cashier App) encrypts the (Cash- Ex-Out-Token-ID), (Cash-Ex-Out-Authorisation-ID) and (Cashier DU-ID) using (Public IU-Key) and sends (Cash-Token- Exchange Advise) to the platform or server 291.

[181] The platform or server 291 decrypts (Cash-Ex-Out-Token-ID), (Cash-Ex-Out- Authorisation-ID) and (Cashier DU-ID) using (Private IU-Key), if all match then redeems the (Cash-Token) and updates the Database and sends (Redemption- Completion-Advice) as a response to the (Cashier-Application).

[182] The cashier may then dispense Exchanged Cash to the Merchant and close the transaction.

Issuer Registration Use Case

[183] An Issuer registers 294 Domain on server 291 specifying a selected domain name, and where required enters a currency to be used, and activates the Register Domain option provided, by for example, clicking a displayed button. The platform or server 291 creates Domain and generate Unique Public/Private Keys for Issuer (Public IU-Key / Private IU-Key) 112 and stores them in Database 292.

[184] A Developer embeds (Public IU-Key) 1 12 and currency in Buyer software application program 233 (Buyer App) and compiles a distribution copy of the customer software application program 233 (Buyer App).

[185] The Developer embeds (Public IU-Key) 112 and currency in Merchant software application program 233 (Merchant App) and compiles a distribution copy of the cashier software application program 233 (Merchant App).

[186] The Developer embeds (Public IU-Key) 1 12 in Cashier software application program 233 (Cashier App) and compiles a distribution copy of the cashier software application program 233 (Cashier App).

Device & Cashier Registration Use Case

[187] The issuer maintains one or more cashier user accounts as active on the platform or server 291 of the invention. Server 291 sends notification to the owner or cashier with account credentials.

[188] The owner or cashier 295 operating personal mobile computing device 200 installs the software application program 233 on personal mobile computing device 200 and initiates 294 the software application program 233 for the first time.

[189] The personal mobile computing device 200 generate Unique Device ID (Owner DU-ID) 269, stores it locally on the personal mobile computing device 200, encrypts it using (Public IU-Key) 1 12 and sends 293 it to the server 291 for device registration and awaits a (Registration-Confirmation-Code).

[190] The server 291 decrypts the (Owner DU-ID) 269 using (Private IU-Key) 1 12 and checks if it is not associated with a mobile number then creates a temporary device entry in the database 292 and store in it the decrypted (Owner or Cashier DU-ID) 269.

[191 ] Optionally, the owner 295 of personal mobile computing device 200 enters 294 and submits 293 a new user registration form with (Owner Name) and (Owner Mobile Number) specified, encrypts the (Owner DU-ID) 269 using (Public IU-Key) 112 and includes it in the submission, then waits for (Registration-Confirmation-Code).

[192] Optionally, the server computer 291 decrypts the (Owner DU-ID) 269 using (Private IU-Key) 1 12 and checks if it exists in the temporary device list database 292 then complete device registration and associate (Owner DU-ID) 269 with (Owner or Cashier Mobile Number).

[193] Optionally, the server computer 291 also generates Unique Public/Private Keys (Public IU-Key / Private IU-Key) 106 for personal mobile computing device 200 stores the (Public IU-Key) 106 in database 292, keeps the (Private IU-Key) 106 in Trust-base 292.

[194] The server computer 291 sends 294 (Registration-Confirmation-Code) to the Owner or Cashier Mobile Number).

[195] The owner 295 of personal mobile computing device 200 receives (Registration- Confirmation-Code) by SMS, enters 294 it in the software application program 233 using touchscreen 214 and sends 294 to the server 291 (Account-Activation-Request).

[196] The server 291 validates (Account- Activation-Request) and responds by sending 293 a secured URL to download the (Private IU-Key) 106 to the personal mobile computing device 200.

[197] The personal mobile computing device 200 downloads 293 the (Private IU-Key) 106 and store it in the personal mobile computing device 200 and then send 293 (Activate- Account) command to the server 291.

[198] Optionally, on activation of account the server 291 deletes the (Private OU-Key) 106 from the Trust-base 292.

Device & Buyer (Sender) Registration Use Case

[199] The buyer 295 installs 294 the cashier software application program 233 on new personal mobile computer device 200 and initiates 294 the software application program 233 for the first time.

[200] The software application program 233 generates Device Unique ID (Owner DU- ID) 269, stores it locally on the personal mobile computer device 200, encrypts it using (Public IU-Key) 1 11 and sends 293 it to the server 291 and waits for (Registration- Confirmation-Code).

[201] The server 291 decrypts the (Owner DU -ID) 269 using (Private UI-Key) 112 and checks if it is not associated with (Buyer-Mobile-Number) then creates a temporary buyer device entry in the database 292 and stores in it the (Owner DU-ID) 269.

[202] The Buyer submits a new buyer registration form with (Buyer Name) and (Buyer Mobile Number) specified, the (Owner DU-ID) is encrypted using (Public IU-Key) and include it in the submittal, then waits for (Registration-Confirmation-Code).

[203] The Server 291 decrypts the (Owner DU-ID) using (Private IU-Key) and checks if it exists in the temporary device list database 292 then completes device registration and associates (Owner DU-ID) with (Owner Mobile Number).

[204] The Server 291 generates Unique Public/Private Keys for Owner (Public OU-Key / Private OU-Key), stores the (Public OU-Key) in database 292, stores the (Private OU- Key) in Trust-base (not shown) and sends (Registration-Confirmation-Code) to (Owner Mobile Number). The Trust-base is a highly restricted access database that temporary stores the Owner's generated Private keys till they are downloaded by their associated devices and then deleted from the Trust-base. The Trust-base may be comprised in database 292.

[205] The Buyer 295 receives 294 (Registration-Confirmation-Code) by SMS, enters 294 it in the buyer software application program 233 and sends 294 an (Account- Activation-Request) to server 291.

[206] The server 291 validates activation request and responds by sending 293 a secured URL to download the (Private OU-Key) 1 12 to the buyer device 200.

[207] The buyer software application program 233 downloads 293 the (Private OU- Key) 1 12 and stores it in the buyer personal mobile computer device 200 and then activates the user account by sending and (Activate- Account) command to server 291 .

[208] Upon activation of the account, server 291 may delete the (Private OU-Key) from the Trust-base.

Device & Merchant (Receiver) Registration Use Case

[209] The Merchant installs the application on device 200 and initiates the application for the first time. The software application program 233 (Merchant App) generates Device-Unique-ID (Owner DU-ID) 269 and stores it locally on device 200, encrypts it using (Public IU-Key) and send it to the platform or server 291 for device registration.

[210] The platfonn or server 291 decrypts the (Owner DU-ID) using (Private IU-Key) and checks if it is not associated with a mobile number then creates a temporary device entry in the database 292 and store in it the (Owner DU-ID).

[21 1 ] The merchant device 200 submits a new merchant registration form with (Merchant Name) and (Merchant Mobile Number) specified, encrypts the (Owner DU- ID) using (Public IU-Key) and includes it in the submission, then waits for (Registration- Confirmation-Code).

[212] The platform or server 291 decrypts the (Owner DU-ID) using (Private IU-Key) and checks if it exists in the temporary device list database 292 then completes device registration and associates (Owner DU-ID) with (Owner Mobile Number).

[213] The platform or server 291 generates Unique Public/Private Keys for Owner (Public OU-Key / Private OU-Key) stores the (Public OU-Key) in database 292, stores the (Private OU-Key) in a Trust-base and sends (Registration-Confirmation-Code) to (Owner Mobile Number).

[214] The merchant device 200 receives (Registration-Confirmation-Code) by SMS, enters it in the software application program 233 and sends to the platform or server 291 (Account- Activation-Request) .

[215] The platform or server 291 validates the (Account-Activation-Request) and responds by sending a secured URL for downloading the (Private OU-Key) to the device 200.

[216] The device 200 downloads the (Private OU-Key) and stores it in the device 200 and then sends (Activate-Account) command to the platform or server 291 .

[217] On activation of the account, the platform or server 291 deletes the (Pri vate OU- Key) from the Trust-base.

[218] The sending and receiving steps described herein may be performed through an application stored on the mobile computing device 200 or through a mobile communications system such as, SMS (short messaging service).

[219] The methods of the invention may further include a step of sending a confirmation message. The confirmation message may be sent by SMS.

[220] Unlike cryptocurrencies, the present invention allows many different entities to issue electronic funds. Each of these entities can restrict the dealing to be only between their registered participants. Accordingly, the present invention limits the susceptibility to misuse or at least makes any misuse identifiable.

[221] Throughout the specification the aim has been to describe the preferred embodiments of the invention without limiting the invention to any one embodiment or specific collection of features. It will therefore be appreciated by those of skill in the art that, in light of the instant disclosure, various modifications and changes can be made in the particular embodiments exemplified without departing from the scope of the present invention.

Claims

1. A method for generating and transferring an electronic cash token, the method comprising:

sending the electronic cash token to the recipient using the recipient details.

2. The method of Claim 1 wherein the recipient comprises a currency exchange and the currency exchange exchanges the electronic cash token for funds in a different currency.

3. The method of Claim 1 or Claim 2 wherein the recipient details comprise a recipient mobile telephone number or recipient unique alias and/or tag.

4. The method of any one of Claims 1 to 3 wherein the recipient details are obtained by inputting them into a user or remitter's personal computing device.

5. A method for conditionally transferring an electronic cash token comprising: receiving a conditional cash-to request comprising the electronic cash token or a token unique ID (TU-ID) associated with the electronic cash token, a device unique ID (DU-ID) associated with a current owner unique ID of the electronic cash token (OU- ID), a recipient mobile telephone number or recipient unique alias/tag and one or more conditions;

sending a cash-to token and a cash-to confirmation code to the current owner; receiving a cash-to confirmation comprising the cash-to confirmation code and the cash-to token; matching the received cash-to confirmation code with the received cash-to token; receiving confirmation that the one or more conditions have been met; and transferring the electronic cash token by updating the electronic database to associate the electronic cash token with an account linked to the recipient mobile telephone number or recipient unique alias and/or tag.

6. The method of Claim 5 wherein the transfer of the electronic cash token is performed before confirmation is received and the transferred electronic cash token comprises a bar to use.

7. The method of Claim 5 or Claim 6 wherein confirmation may be received from one or more of the current owner, the recipient and a third party.

8. A computer readable medium comprising a monetary value indication and a device unique ID (DU-ID) identifying a personal mobile device.

9. The computer readable medium of Claim 8 wherein the DU-ID may comprise an international mobile subscriber identity (IMSI).

10. The computer readable medium of Claim 8 or Claim 9 wherein the medium is non-transitory.

1 1. A method for generating an electronic cash token comprising:

12. The method of Claim 11 wherein the encoding comprises encoding as an electronic bar code, such as a Q code.

13. The method of Claim 1 1 or Claim 12 wherein the encoded electronic cash token is stored in a database.

14. A method for transferring an electronic cash token comprising:

receiving a cash-to request comprising the electronic cash token or a unique token identification associated with the electronic cash token, a DU-ID associated with a current owner of the electronic cash token and a recipient mobile telephone number or recipient unique alias/tag;

receiving a cash-to confirmation comprising the cash-to confirmation code and the cash -to token;

transferring the electronic cash token by updating the electronic database to associate the electronic cash token with an account linked to the recipient mobile telephone number or recipient unique alias/tag.

15. The method of Claim 14 wherein the recipient mobile number is received at a different time to the cash-to request.

16. The method of Claim 14 or Claim 15 wherein the method further comprises recoding a computer readable medium associated with the electronic cash token.

17. The method of Claim 16 wherein the computer readable medium is associated with the current owner and/or the recipient.

18. A method of authorising cash dispensing comprising:

receiving from the cash dispenser a cash-out confirmation comprising the cash- out confirmation code; and matching the received cash-out confirmation code with the stored cash-out confirmation code;

19. The method of Claim 18 further comprising a step of the cash dispenser obtaining the cash token or the unique token identification from the cash token owner.

20. The method of Claim 19 wherein the obtaining comprises scanning an electronic barcode displayed on the owner's personal computing device.

21. The method of any one of Claims 18 to 20 further comprising sending an electronic cash-out token to the dispenser.

22. The method of any one of Claims 18 to 21 wherein the receiving from the cash dispenser of a cash-out confirmation further comprises receiving a cash-out token.

23. The medium or method of any one of the previous Claims wherein one or more request, token, confirmation, confirmation code or unique token identification is encrypted.

23. The medium or method of Claim 23 wherein the encryption comprises a Public IU-Key or a Public OU-Key.

24. The medium or method of any one of the preceding Claims wherein one or more received encoded request, token or confirmation is decrypted using Private IU-Key or Private OU-Key.

25. The medium or method of any one of the preceding Claims wherein the electronic cash-in computer token comprises an electronic bar code such as a Quick Response (QR) code.

26. The method of any one of Claims 1 to 7 or Claims 11 to 22 wherein one or more of the sending and receiving steps is performed through an application stored on the mobile computing device or through a mobile communications system such as, SMS (short messaging service).