WO2012150491A1

WO2012150491A1 - Method and system for funds transfer bill payment, and purchasing using drag and drop

Info

Publication number: WO2012150491A1
Application number: PCT/IB2012/000829
Authority: WO
Inventors: Oreste PANAIA
Original assignee: NIEMEYER, Alice
Priority date: 2011-05-04
Filing date: 2012-04-27
Publication date: 2012-11-08

Abstract

The invention relates to a system of transferring money, encoding data within data tokens and a method for utilising such data tokens to effect funds transfer, bill payments and purchases and a method and system allowing the transfer of funds, payment of bills, and purchase of products on the Internet and other communication networks using drag and drop.

Description

METHOD AND SYSTEM FOR FUNDS TRANSFER BILL PAYMENT, AND

PURCHASING USING DRAG AND DROP

FIELD OF THE INVENTION

[01 ] This invention relates to a method and a system of transferring money, encoding data within data tokens and in a particular method to utilise such data tokens to effect funds transfer, bill payments and purchases and a method and a system allowing the transfer of funds, payment of bills, and purchase of product on the Internet or other communication network using drag and drop.

BACKGROUND OF THE INVENTION [02] The Internet and other communications networks are being used more and more for funds transfer, bill payments and purchasing. There are however, many problems with the way in which funds are transferred for the purpose of bill payments and purchases using the internet. Issues of privacy and security are central to using the internet. A need for a funds transfer system which provides good privacy and good security is the background of the invention. [03] A funds transfer can be directed to a particular bank account, person or entity, for example a payment by credit card for a product, bank cheque, travellers cheques. Alternatively a funds transfer can be undirected, for example, bank cheque made out to cash, actual cash and various forms of digital cash.

[04] A funds transfer can also be public or private. For example, a merchant advertising their BPay number or bank account number to receive payment is an example of public funds transfer where the merchant's details are (directly or indirectly) revealed. Further, a customer paying by credit card, or EFTPOS is an example of where the customer's details are (directly or indirectly) revealed. Most funds transfer contain some information about the customer and/or merchant which can be accessed by a party not being the receiving bank or the issuing bank. In contrast, digital cash (with privacy protection measures), actual cash and bank cheques made out to cash are examples of private funds transfer. [05] A funds transfer may be initiated by a request for funds for a payment of a bill or payment of a purchase. This can be considered as a Request for Funds, while the actual funds transfer, for example, bank transfer, credit card, or cash can be considered the Funds Transfer Instrument.

[06] The problem of performing e-commerce has been solved (in its more general implementation) by allowing a customer to (in one form or another) provide either their credit card details and/or their bank account details. The disadvantage here is that a customer must provide a merchant their personal details and their bank details. In addition, if a merchant' s storage medium (where the bank details are stored) are compromised, then the customer is put at risk due to the possibility of fraudulent transactions.

[07] Digital Cash (or digital coins) can only achieve privacy using a complicated process of digitally signing the coins (and may require the customer and/or merchant to have public/private keys). Digital Cash attempts to achieve security by enveloping the coins within a "wallet" a piece of hardware. This complicates the process of allowing a customer to "spend" their coins. Further, additional hardware and software is required if the coins are to be spend over the internet. It is also difficult to share the digital coins with another person. The process of "cashing in" or "redeeming" the digital coins can also be complicated and may require the customer to return to the issuing bank. Digital Coins do have a double spending problem and this is usually solved by having the coins directly or indirectly returned to the issuing bank, which again complicates the use of Digital Coins.

[08] In a broad sense the following problems arise in existing e-commerce funds transfers:

(i) Privacy. Most methods for funds transfer or purchase provide limited (if any) privacy between the parties involved (here the parties could be the banks, the merchant and the customer). In particular, funds transfer often involves the exchange of some form of banking details and identity information. This is a serious problem in terms of fraud, identity theft, and just personal privacy.

(ii) Security. Most methods for funds transfer or purchase are not secure often because of (i) above, in the sense that information can leak from the transaction. Also funds can be lost (or stolen) in many current approaches to funds transfer or purchase. This is a serious problem on the Internet because most traffic is not encrypted.

(iii) Control. Most methods for funds transfer or purchase are controlled by the requestor of the funds or the merchant, e.g. when shopping the payment process is controlled by the merchant. The merchant determines the process and what information is required. This is a problem because the control should be in the hands of the payee or customer.

(iv) Custom Hardware and/or Software. A number of other proposed e-commerce solutions involve the use of custom hardware or software (e.g. digital wallets). This is generally to protect the digital cash from theft and/or double spending. The use of custom hardware and/or software is a problem because it can add additional cost and complexity.

(v) Third-Party Involvement. A number of other solutions involve a third-party in the funds transfer or purchase process, often in the form of a centralised co-ordinating party (e.g. PayPal). This is a problem because it often requires the sharing of bank account details and transaction information with this third-party (as well as the banks).

[09] In addition to these problems with transferring funds, paying bills, and making purchases on the Internet or other communication networks, there are problems with the way users accomplish such tasks.

[ 10] The processes involved in performing such operations are often long and involve many steps. These steps can involve entering information and clicking through a number of Web pages on one or more Web sites. The user can also be shunted to a payment Web site involving a third- party without the user's approval or even knowing it is occurring.

[ 1 1 ] These processes also vary across different sites so there is no consistency in the process for the user. Many online Web stores and bill payment sites operate in different ways and with a different set of steps and required information. This can make the whole process confusing and unclear for the user.

[ 12] The processes also often involve entering a large amount of information at the request of, often demanded by, the other party (e.g. the online store). Some of this information may not even be required for the transaction but is required by the other party to complete the transaction. Often the user cannot proceed without providing this information.

[ 13] In these transactions often the details of what is happening behind the scenes, with regards to the transfer of funds, the payment of a bill, or the purchase of goods or services, is often opaque (and sometimes it would seem intentionally so). It is often not clear to the user when the actual funds are transferred or the goods or services purchased. [ 14] If the user wishes to pay via their Internet Banking site this is often not well integrated with the other processes (e.g. purchasing and bill payment). The user has to interact separately with the two sites (billing or purchasing site and their Internet Banking site) and transcribe information from one site to the other. [ 151 In general, with most of the current approaches there is a lack of user control (i.e. the seller or biller is in the dominant position), and there is a lack of transparency as to what is happening and when (i.e. a lack of clear, intuitive, and natural indication that the funds are actually being transferred). In summary, there is a lack of ownership by the user.

[ 16] As well, it is not the user (i.e. the party transferring the funds, paying the bill, or purchas- ing, on the Internet) who owns the process, is in charge of the process, or clearly dictates what is happening and when it will happen in the process. On the contrary, ownership and control currently rests almost entirely with the other party or parties.

[ 17] Further, emails with offers for sale, or printed advertisements with URLs (i.e. Web addresses), require the user to go to a Web site to purchase (and give the merchant their credit card details) or to take the merchant's bank account details and then going to the their own Internet Banking Web site to initiate a funds transfer to the specified account.

[ 18] Both of these are unsatisfactory because they expose private information to the other party. In the first case, the user has to give their credit card details to a third-party Web site they may not know or trust. In the second case, the merchant has to give details of their bank account to the user, which is equally problematic from a security perspective.

[ 19] Prior art relating to funds transfer generally involve the user having to obtain the bank account details to which they wish to transfer funds from a Web page, email, or by other means, and manually entering those details into their Internet Banking Web site or application (or choosing pre-entered details) and initiating a funds transfer. There is little assistance in this process for the user.

[20] Prior art relating to bill payment includes regular funds transfer (as mentioned above), using a third-party bill payment service, or entering credit card details on the biller's Web site or application. This is usually done by clicking through a number of Web pages and entering infor- mation as necessary (or choosing from pre-entered information). Such Web payments are varied and often confusing.

[21 ] Prior art relating to purchasing includes completing a checkout process on a seller's Web site or application and entering credit card details (or choosing a previously entered credit card), or using a third-party payment service and choosing a previously entered source of funds, or paying subsequent to the checkout process using regular funds transfer. Again, clicking through many Web pages at the direction of the vendor.

[22] Amazon 1 -Click is another example of a purchasing system on the Web. It does not involve clicking through a checkout process. In this case, with pre-configured credit card details and use of an Internet browser cookie, the system can initiate a purchase with one click of the mouse. Behind the scenes, the pre-configured credit card is used to make the purchase. This is perhaps the ultimate example of an opaque process.

[23] These examples of prior art suffer from some or all of the problems mentioned earlier. SUMMARY - DESCRIPTION [24] The invention is a new system and method of enabling the transfer of funds. In one implementation of the invention this can be achieved by using two data tokens, some data of which is encrypted for the purpose of transferring funds between bank accounts, or more generally from one entity to another entity with the assistance of one or more banks. In the more general case to support e-commerce, two or more data tokens can be used. In the case of funds transfer from one bank to another it is possible to effectively use one data token. To support a means of where a customer wishes to redeem at least one further token will be required.

[25] While the invention allows a general transfer of funds from one entity to another, it is useful to describe the process in terms of a purchase involving a customer, merchant (or recipient), customer's bank and merchant' s bank. The end result is that funds are able to be transferred from the customer's bank to the merchant's or recipient's bank,

[26] The first non-intuitive step in this invention is that the identity of the merchant's bank and the identity of the merchant^'s bank account (or the identity of the merchant) is encrypted in the digital funds transfer instrument and that this encrypted data can only be decrypted by the merchant's bank. Any funds transfer instrument that uses this approach is called Directed Cash. [27] This may be realised using a digital data token that may be electronic or may use some other physical storage medium (e.g. bar codes printed on paper). This digital data token represents a form of digital cash or money transfer and will be referred to herein as a Directed Cash token. The digital cash (or money transfer) so represented is unique in that it can only be ac- cepted by the targeted bank. The targeted bank has provided for inclusion within the Directed Cash token encrypted data which only the targeted bank can decrypt. Examples of such encrypted data include the targeted bank identifier and the targeted bank account (for example, the merchant's bank account).

[28] The second non-intuitive step in this invention is that the target or recipient of the funds can share their request for funds or offer to sell a product or service with their target details (their bank data as explained above) encrypted inside, and thus keep this information private whilst not necessarily keeping the other data private. Any request for funds or offer to sell a product or service that uses this approach is called a Directed Request.

[29] This is also realised using a digital data token that may be electronic or may use some other physical storage medium (e.g. bar codes printed on paper). This digital data token may represent a product or service (or more generally a request for funds) which is encoded so that the product or service can easily be purchased and paid for using the Directed Cash token (referred to above). This token is referred to as the Directed Request token. Again, the targeted bank has provided for inclusion within the Directed Request token encrypted data which only the Target Bank can decrypt. Examples of such encrypted data include the targeted bank identifier and the targeted bank account.

[30] These two tokens can then be used together to facilitate an easy way to make secure funds transfer, bill payments, or purchases over the Internet or via other mediums. The process of making a funds transfer using these two tokens may be referred to as a Direct Transfer and, in the case where it is used for a purchase, more specifically as a Direct Purchase. The key step in this process is that the encrypted target data is transferred from the Directed Request token into the Directed Cash token and allows the funds to be transferred privately to the targeted bank, without the customer knowing banking details of the recipient or vice-versa.

[31 ] Merchants can offer (by various means) Directed Request tokens (e.g. within advertising material). Customers can choose offers they wish to pursue and use their bank to create a Di- rected Cash token which they forward to the merchant. The fact that the customer controls the purchase process (as opposed to the merchant) is an advantageous result of this invention.

[32] The funds transfer can be implemented as an "immediate transfer" without requiring clearing or settlement by the banks. However, the invention can also be used in a context that requires clearing and settlement by the banks.

[33] The method and system provides a secure means of funds transfer as the Directed Cash token is digitally signed and the funds only represent value to the intended target, the Target Bank. As such no secure transport mechanism is needed for the transmission of the tokens as the funds can only be used for one purpose and ideally only once (so duplication of the token for safety is fine).

[34] The method and system also allows a high level of privacy between the customer and the recipient when making these purchases. This security, privacy and customer control could reduce the effort required to make a purchase (achieve a sale) from an advertisement (offer).

[35] An independently i nventive method and system encapsulates a particular user interaction and experience for transferring funds, paying a bill, or making a purchase on a computer. One embodiment of the interaction involves dragging and dropping items that contain embedded data between two applications or locations within a single application (e.g. two pages within a Web browser or two windows within other applications). The first drag and drop involves acquisition of the request for funds, a bill to be paid, or products and/or services for sale and transferring it to the user's Internet bank. The second drag and drop involves moving of the required funds, payment for a bill, or purchase of products and/or services from the user's Internet bank to the party requesting the funds, payment or offering the products and/or services for sale. Various options may be set preceding the drag and drop operations to determine what information is transferred (or not). [36] In accordance with one embodiment, the user drags an image, an image of a product or service or an entire shopping cart, which contains embedded data about the goods and/or services, from a seller's Web site to a drop zone on their Internet banking site. The Internet banking site reads the embedded data and informs the user of what items they are considering purchasing, e.g. from whom, and for how much. The user can then choose to proceed with the purchase or not (and set other options, e.g. regarding privacy). If the user chooses to proceed, the Internet banking site produces an image that contains embedded data for the funds necessary to purchase and pay for the goods and/or services. The user then drags the image from the Internet banking site to a drop zone on a Web site (usually the seller's Web site) to complete the purchase.

[37] In these embodiments, the dragging and dropping of the request for funds, bill to pay, or purchase offer from their source to the user's Internet bank enables the user to consider the details of the request within a trusted environment (i.e. their Internet bank). Similarly, the dragging and dropping of the funds, bill payment, or purchase and payment from their Internet bank to the required destination enables the user to complete the funds transfer, bill payment, or purchase and payment. The user is in control and owns the process. It is also clear what is being done in each of these steps, particularly that the funds are being transferred and transaction completed in the final drag and drop.

DRAWINGS

[38] Figure 1 shows a possible representation of how a merchant's bank computer server may arrange in a block of computer memory, or a file on a computer disk, or as a file on some elec- tronic storage device, or a printed digital representation of the data such as a 2D barcode, details about the merchant' s bank, some of which are optional, which are to be included as part of a Directed Request token (and subsequently as part of a Directed Cash token) data structure. The order of the blocks of memory is arbitrary.

[39] Figure 2 shows a possible representation of how the identity of a merchant and a data detailing a merchant's products (or services) on a merchant' s computer server may be arranged in a block of computer memory, or a file on a computer disk, or as a file on some electronic storage device, or a printed digital representation of the data such as a 2D barcode. These details, some of which are optional, are included as part of a Directed Request token (and subsequently some, all, or none of which are included as part of a Directed Cash token) data structure. The order of the blocks of memory is arbitrary.

[40] Figure 3 shows a possible representation of how merchant data (as illustrated in Figure 2) and merchant's bank data (as illustrated in Figure 1 ) can be amalgamated into a data segment on a merchant's computer server. This data segment may be stored in a block of computer memory, or a file on a computer disk, or as a file on some electronic storage device, or a printed digital representation of the data such as a 2D barcode. The order of the blocks of memory is arbitrary. The amalgamated data is referred to as a Directed Request token.

[41 ] Figure 4 shows a possible representation of how a customer^'s bank computer server may arrange in a block of computer memory, or a file on a computer disk, or as a file on some elec- tronic storage device, or a printed digital representation of the data such as a 2D barcode, which contains the funds transfer details which are included as part of a Directed Cash token data structure. The order of the blocks of memory is arbitrary.

[42] Figure 5 shows a possible representation of how data (as illustrated in Figure 4) can be amalgamated into a data segment on a customer's bank computer server. This data segment may be stored in a block of computer memory, or a file on a computer disk, or as a file on some electronic storage device, or a printed digital representation of the data such as a 2D barcode. The order of the blocks of memory is arbitrary. The amalgamated data is referred to as a Directed Cash token.

[43] Figure 6 illustrates a possible process in which a Directed Request token is generated, transmitted to a customer^'s bank computer server, processed by these servers which in turn generate a Directed Cash token. This Directed Cash token is then returned to the merchant's bank via the merchant's computer server.

[44] Figure 7 provides a simple illustration of an exchange via funds transfer method and system as described in Figure 6. [45] Figure 8 illustrates a possible process in which a Directed Cash token is transmitted to a Target Bank and deposited to that bank and validated by that bank.

[46] Figure 9 illustrates a possible process in which a Directed Cash token is "redeemed^" so that a customer who no longer wishes to proceed with a funds transfer effectively returns the value of the Directed Cash token to their original customer bank and customer bank account. [47] Figure 10 shows a preferred arrangement for the purchase of goods in accordance with one embodiment of the present invention that involves dragging and dropping between two Web sites / applications. [48] Figure 1 1 shows a preferred arrangement for the purchase of goods in accordance with another embodiment of the present invention that involves dragging and dropping between two client applications.

[49] Figure 12 shows a preferred arrangement for the purchase of goods in accordance with another embodiment of the present invention that involves printed details as well as dragging and dropping between applications.

[50] It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements.

DETAILED DESCRIPTION

[51 ] In broad terms the Funds Transfer method and system consists defining a structure for the digital data tokens and of the exchange of two or more such digital data tokens. The bank (or financial institution) to which the funds are to be transferred to is referred to as the Target Bank. The bank (or financial institution) from which the funds are to be transferred from is referred to as the Source Bank

[52] A first token, which is referred to as a Directed Request token essentially contains a request for funds. The request for funds can result in response to a purchase from an online store, a purchase from an advertisement (such as a billboard), a bill payment or simply a transfer of funds from one bank account to another. A second token, which is referred to as a Directed Cash token essentially contains the value of the funds to be transferred.

[53] An essential property that a Directed Cash token has, is that the digital data which identifies the Target Bank and the Target Bank Account to which the funds are to be transferred to, is encrypted. Moreover, only the Target Bank can decrypt this encrypted digital data. Thus the Source Bank or anyone else intercepting the Directed Cash token cannot determine the identity of the Target Bank or the Target Bank Account. [54] One essential function that a Directed Request token has, is that of communicating the encrypted digital Target Bank and Target Bank Account data (contained within the Directed Request token) from the Target Bank to the Source Bank.

[55] Various embodiments of the method and system using drag and drop involve the move- ment of digital data between applications on a user's computer and, as a result, effectively between remote computers. The style of the interaction involves a drag and drop of items containing digital data to complete the process of funds transfer, bill payment, or purchase and payment whereby the user is in control and has ownership of the process of funds transfer, bill payment, and purchasing.

[56] The items being moved in the embodiments contain, either explicitly or implicitly, digital data. The item is a container for the digital data. The digital data may be explicitly represented as digital data in the container or it may be implicit in other data, for example, represented in an image whose data is within the container. The digital data referred to should have some predefined structure so that the use of "drag and drop" provides the additional advantages of privacy and security. As such the digital data which is exchanged in the "drag and drop" preferably would involve the exchange of data tokens referred to as Directed Request tokens and Directed Cash tokens.

[57] The use of "drag and drop" in the embodiments to move an item from one panel to another generally corresponds to a "click and hold" (mouse-down) operation whilst pointing to the item, followed by a movement of pointing device, followed by a release of the click whilst over the target location in the target panel (mouse-up).

[58] The item for sale could be a product or plurality of products or a service or plurality of services, or combination of products and services. In particular, the offer for sale could be the sale of a shopping cart of previously selected items, rather than just one product or service listed on a page.

[59] The purchase and payment instrument could be a funds transfer instrument or a bill payment instrument. The data constituting the purchase, payment, or funds transfer could be directly represented (e.g. as data in a file) or implicit in other data within the container (e.g. within an image whose data is in a file). Preferably, the funds transfer would operate using the exchange of data tokens referred to as Directed Request and Directed Cash tokens. In addition, these data tokens lend themselves to the drag-and-drop user action.

[60] The visual representation of the container containing the digital data could be generic, e.g. like a file icon, or be specific and represent the digital data in the container, e.g. what is being offered for sale and how much. The size of the representation for the funds transfer, bill payment, or purchase could also correspond to the amount of funds involved.

[61 ] The new method and system has many advantages, including (but not limited to):

[62] The user is generally in control of the funds transfer, payment or purchase transaction, since they explicitly drag and drop items between applications as a part of the process. [63] What is happening is generally transparent to the user, since it is clear what they are doing in each step, particularly what they are moving around and when the actions occur.

[64] In general, with the new method and system, the user has full ownership of the process for funds transfer, bill payment, and purchasing unlike the prior art. It is a more intuitive and natural process for the user. [65] The user never has to enter their banking details into a third party Web site. All of the significant interaction happens on the user's Internet banking site, a site they would generally trust much more than a third party Web site.

[66] While the above description contains many specificities, these should not be construed as limitations on the scope of any embodiment, but as exemplifications of the presently preferred embodiments thereof. Many other ramifications and variations are possible within the teachings of the various embodiments.

[67] Thus the scope of the invention should be determined by the appended claims and their legal equivalents, and not by the examples given.

[68] Figure 7 provides a simple illustration of an exchange via a funds transfer method and system. The Target Bank (701 ) creates the encrypted Target Bank and Target Bank Account digital data. This data is sent to a merchant (710) whose bank account is part of the encrypted Target Bank data. (In this illustration the merchant's bank is the Target Bank). The encrypted data is sent to the merchant (710) via some data exchange communication channel (702), which can be a private network, or public network, or postal mail, or delivery in some other form. The merchant (710) uses the encrypted data sent by the Target Bank (701 ) and a computer to create a Directed Request token. The Directed Request token generated at the merchant's site may contain addi- tional data, some, all, or none of which may be encrypted and all, some, or none of which may be digitally signed by the merchant. A customer of the merchant collects the Directed Request token (704) via some data exchange communication channel (703). Generally such a communication channel (703) could be the public internet without any security, however any method which allows a customer to collect the Directed Request token can be used. The customer now delivers the Directed Request token to the Source Bank (706) (which could be the customer's bank) via some not necessarily secure communication channel (705) such as the Internet. The Source Bank (706) using the data contained within the Directed Request token and additional data added by the source Bank and a computer, generates a Directed Cash token which is digitally signed by the Source Bank. The customer transfers the Directed Cash token (708) from the Source Bank (706) via some not necessarily secured communication channel such as the internet (707, 709) to the merchant (710). The merchant may wish to perform some initial validation of the Directed Cash token and then transfers the Directed Cash token to the Target Bank (701 ) using some not necessarily secured communication channel such as the internet (702). The Target Bank (701 ) now validates the Directed Cash token by performing at least three validation tests. First, the Target Bank attempts to determine that the Directed Cash token has not been tampered with by verifying the digital signature contained within the Directed Cash token. Second, the Target Bank determines that the Directed Cash token is actually targeted at the Target Bank by attempting to decrypt the Target Bank and Target Bank Account details originally issued by the Target Bank itself. Failure to decrypt this information may imply that the directed Cash token is directed at some other financial institution. Third, the Target Bank determines that the Directed Cash token has not been previously deposited at the Target Bank by performing a database lookup of the Globally Unique Identifier (GUID) contained within the Directed Cash token. The Target Bank would be required to keep a computerised list of all Directed Cash tokens deposited. If the validation is successful, then the funds whose value is contained within the Directed Cash token will be transferred to the bank account of the merchant. The Target Bank (701 ) communicates the success or failure of the validation process back to the merchant (710) via some communication channel. [69] To ensure that the exchange of a Directed Request token with that of a Directed Cash token effects the transfer of funds from the Source Bank to the Target Bank, various digital data elements are to be stored in each of these tokens. Depending on the data stored in these two tokens, various levels of privacy and security can be achieved. Thus for example, leaving out one element of data may imply that additional privacy is achieved, while simultaneously reducing the level of confidence (or security) a customer has in the exchange process. Figures 1 , 2, 3, 4 and 5 provide an illustration of a possible arrangement of digital data eventually comprising a Directed Request and Directed Cash token.

[70] In the description above, the following should be noted:

(i) That the customer' s role was that of facilitating the transfer of the Directed Request token from the merchant to the Source Bank, and then facilitating the transfer of the Directed Cash token from the Source Bank to the merchant. The process as illustrated can be automated without the requirement of a customer.

(ii) The merchant need not use their own computer servers. For example, a merchant can use a Target Bank^'s computer and other resources to process online purchases or bill payments.

(iii) The token exchange as detailed above, need not occur synchronously. Thus for example, it is possible that a customer store a Directed Request token (e.g. on their personal computer) and at some later time use this token to generate a Directed Cash token at the Source Bank. Similarly, once a Directed Cash token has been generated it is not a requirement that the Directed Cash token must be immediately transferred to the Target Bank (via the merchant).

(iv) A merchant need not obtain encrypted Target Bank every time a Directed Request token needs to be created. A merchant need only periodically update this information. In fact, using a Target Bank' s public key (for encryption) a merchant may be able to encrypt Target Bank data.

[71 ] Figure 1 provides a representation of Target Bank Data ( 108), some of which will be encrypted. This data could be generated on a Target Bank's computer servers and stored as a file on some physical storage device or within a block of computer memory. We describe the data ele- ments within block of memory, remembering that some of the data described may be optional and some data described may be dependent upon the manner a Target Bank implements the invention. A first requirement is that the Target Bank data must contain a Bank Identifier ( 101 ). This Bank Identifier ( 101 ) should be encrypted in such a manner that only the Target Bank can decrypt the data segment. Further, the encryption algorithm used for the data segment should allow a unique encrypted output for each merchant (or entity). That is, two different merchant's using the same Target Bank would have, after encryption, two different data segments. Further, the method used for encryption should be varied so that it is difficult to determine the identity of Target Bank by correlating the encrypted data with a particular bank. (The variation could be the periodic changing of the encryption algorithm. The period would be implementation dependent and possibly also dependent upon the merchant (or entity) requesting the Target Bank data.) In Figure 1 various dates and times may be added. For example, ( 102) represents the date and time that the data was generated by the Target Bank. This could be useful for the Target Bank. The Target Bank would most likely encrypt this information if it is only for their use. In ( 103), the date (and if required) the time that the Target Bank data expires. That is, the date (and if required) the time after which the Target Bank no longer accepts as valid a Directed Cash token containing that Target Bank data. In ( 104), the currency which the Target Bank requires the Directed Cash token to have value. For example, if the currency data element indicates US dollars, then the expectation is that the corresponding Directed Cash token will be valued in US dollars. In ( 105), the merchant's bank account details would be encrypted here. The encryption used should ensure that it would be difficult for someone intercepting a Directed Cash or Directed Request token to correlate a merchant with their encrypted bank account details. Data contained in ( 106) contains unencrypted details of how a customer can redeem their Directed Cash token without the necessity of completing a bill payment or purchase. Data contained in ( 107) would generally be specific to a particular Target Bank and the manner in which they have implemented the Directed Request and Directed Cash exchange. For example, (107) could contain a Unique Identifier which the Target Bank wishes to match with records stored on their computer database servers.

(i) The Directed Request token may be transmitted over a public communication channel such as the Internet and as such, the Directed Request token and hence the Target Bank data could be modified. The Target Bank identifier and Target Bank Account can not be modified since these are encrypted. One manner in which to ensure that unencrypted dates (and times if required), currency and other unencrypted data can not be modified, is for the Target Bank to create a duplicate of these data elements, one encrypted and one unencrypted. Thus for example, the Target Bank would encrypt the currency required and would also store the currency required as unencrypted. The encrypted data can not be modified without revealing this tampering to the Target Bank.

[72] Figure 2 provides a representation of Merchant Data (208) which is amalgamated with the Target Bank data ( 108) for the purpose of producing a Directed Request token. The data segment (201 ) provides provision for the merchant to list details regarding the products, services, or bill payment. Data segment (202) provides the total value of the products, services, or bill payment, while (203) provides the currency of the total value (202). Item (202) need not be text data, it could incorporate an image of the item to be purchased or a copy of a bill statement. Data segment (204) provides dates (and possibly times) which are relevant to the funds transfer. For example, it could represent the expiration date of a sale item, the last date on which a bill can paid. Item (204) need not appear separate here it could be incorporated within (202). A merchant may wish to record customer details (205), such as name, and delivery address and contact phone number. Depending on the purpose, these details can be encrypted by the merchant so that they are not visible to anyone intercepting the Directed Request token. Data segment (206) provides for the inclusion of merchant details, such as the name of the merchant and contact details of the merchant. Part of the data which (206) represents could be redemption details. That is, details on how a customer can redeem their Directed Cash token without necessarily proceeding with a funds transfer, purchase, or bill payment. Additional data (207) could be for example, some internal (to the merchant) reference code to track the purchase or bill payment could be stored here.

(i) The amount of data which is generated by the merchant depends upon the level of privacy and security that a customer and merchant wish to achieve. For example, if product details are not stored or if product details are encrypted (thus only the merchant can determine the product details), this provides additional privacy, since anyone intercepting the Directed Request token can not determine the purpose of the funds transfer. However, this increase in privacy may result in reduced security and confidence that a customer has in the Directed Request token. In an extreme case, the Merchant Data can be empty so that no details about the customer, merchant and products (including the value of the products) is visible. In the other extreme, the Merchant Data can contain details of the merchant, details of the customer and details of the products all of which are unencrypted and visible to anyone intercepting the Directed Request token. This relationship between security, privacy and the data stored in the token provides a feature whereby a customer may choose the level of privacy and security. (ii) Redemption details can be provided by a Target Bank. However, redemption details can be provided by a merchant instead of, or in addition to those provided by the Target Bank.

[73] Figure 3 provides a representation of a Directed Request token (304). Essentially such a token is composed of the data segments ( 108) in Figure 1 , and (208) in Figure 2. The data segment (301 ) is an identical copy of the data provided by the Target Bank. The data segment (302) is the data which a merchant requires as part of the Directed Request token. The data segment (303) provides provision for additional data which does not play a role on the token exchange. For example, data segment (303) could be a place holder for a customer to add their own comments. It could represent a web site which contains details of the products. It could represent digital data which are images of the products which are to be purchased. The Directed Request token (304) may be digitally signed by the merchant for authenticity and to ensure that tampering of the token does not take place prior to being received by the Source Bank. A merchant digitally signing a Directed Request token provides additional security and confidence to a customer, however it may reduce the level of privacy that both the merchant and customer have. Alternatively, a merchant may wish to use a trusted third party to digitally sign a Directed Request token, thereby retaining privacy while providing the security and confidence offered by a digital signing of the token.

[74] Figure 4 provides a representation of the Source Bank Data (406), some of which will be encrypted. This data could be generated on a Source Bank' s computer servers and stored as a file on some physical storage device or within a block of computer memory. We describe the data elements within such a block of memory. Item (401 ) is an identical copy of the data generated by the Target Bank. That is, item (401 ) is the data illustrated in Figure 1 ( 108). Item (402) represents the value of the funds transfer, while (403) determines the currency used in the funds transfer. Item (404) provides provision for dates (and if required times). For example, contained in this data segment could be the date (and possibly time) that the Directed Cash token was generated by the Source Bank. Item (405) refers to a Globally Unique Identifier (GUID), which is a sequence of computer bits that, with very high probability is determined to be unique within the context for which it is used. In this case, the context in which it is used is to ensure that a Directed Cash token can not be "double spent" at the Target Bank. That is, the GUID ensures that only one Directed Cash token can be accepted by the Target Bank.

(i) The currency in which the Directed Cash token will be issued in (403) would, in most cases, be determined by the data contained within a Directed Request token Figure 1 (304). Thus if a Target Bank provides the preferred currency, then the Source Bank would use this information to provide the funds transfer in that currency. However, it is also possible that a customer determines the currency to be used in the funds transfer.

(ii) There is no requirement that a Directed Cash token have an expiration date (and possibly time). Expiration dates (and possibly times) may be implementation dependent. Thus it is conceivable that one Source Bank provide Directed Cash tokens without an expiration date (and possibly time), while another provides such tokens with. an expiration date (and possibly time).

[75] Figure 5 provides a representation of a Directed Cash token (506). Essentially such a token is an amalgamation of the Source Bank Data as illustrated in Figure 4, merchant and product data as illustrated in Figure 3 (302) and additional data generated by the Source Bank. The data segment (501 ) is the Source Bank Data as illustrated in Figure 4. Item (502) provides a means in which a customer can redeem their Directed Cash token, in the event a customer no longer wishes to proceed with a purchase or bill payment. Essentially data segment (502) is structured in a similar manner as the data given in Figure 1. The difference being that the Source Bank, in the event of a redemption by the customer, becomes the Target Bank. Thus (502) contains encrypted Bank Identifiers and encrypted Customer Bank Account Identifiers. Data segment (503) contains details about the products, purchases, or bill payments indicating the purpose of the funds transfer. In additional, this data segment (503) can contain details about the merchant, such as contact address and contact telephone number. Data segment (504) provides for a Customer or Source Bank to store contact details regarding a customer, For example this could be a contact address or delivery address. Item (505) provides for a Source Bank to store other data such as a reference to the Directed Cash token which can be used to retrieve a previously stored copy of the Directed Cash token on the Source Bank' s computer servers.

[76] Advantages of this token exchange funds transfer method. (i) Privacy. The exchange of the two tokens (Directed Request and Directed Cash) allows for a high level of privacy for both a customer transferring funds and a merchant providing products or services. Customer details need not appear in any of the tokens for a funds transfer to succeed. Merchant and product details need not appear in any of the tokens for a funds transfer to succeed. A merchant can have a third party digitally sign a Directed Request token, thereby providing customer confidence (by ensuring that the Directed Request token has not been tampered with) without necessarily revealing details about the merchant. Bank and Bank Account details are not publicly visible. The only publicly available bank detail is the digital signature which identifies the Source Bank. However, this to could be signed by a third party, for example, a central bank.

(ii) Security. No bank account details are publicly visible. A Directed Cash token can be copied and stored on a customer's Personal Computer for further security in the event that a Directed Cash token has been lost in the process of transmission. A Directed Cash token which is intercepted by a third party may not (unless the customer has chosen to forgo this security) redeem the token and deposit the funds transfer into the third party's bank account. A Directed Cash token can not be tampered with, including the monetary value of the token.

(iii) Control. A customer would initiate the funds transfer by the receipt of a Directed Request token. That is. a customer would decide the currency, value and when to transfer the funds (unless the customer has chosen to forgo this control).

(iv) Custom Hardware and/or Software. Custom Hardware is not required to facilitate the funds transfer. Nor is Custom Software. Software may be required to provide a user experience and user interface as part of the token exchange, for example, on a Source Bank's internet banking site, and a Merchant' s online checkout process.

(v) Third-Party Involvement. For the funds transfer via token exchange to occur, it is not necessary that any third party be involved. That is, the relevant parties could be: customer, customer's bank, merchant and merchant's bank. No third party needs to be involved requiring the customer to divulge their banking details.

Depositing a Directed Cash Token Figure 8 provides an illustration of how a Directed Cash token is deposited to a Target Bank (801 ). A merchant or customer transmits the Directed Cash token (802) via some (not necessarily secured) communication channel (803). This Directed Cash token is received by the Target Bank (801 ) and stored on the Target Bank Computer Servers (804) for processing. The CPU (806) processes the token in memory (805). The following processing takes place:

* The CPU attempts to decrypt the encrypted Target Bank Identifier stored in the Directed Cash token. If this decryption fails, then the token is deemed not to be directed to the Target Bank. The funds transfer will not proceed. The Target Bank will communicate this failure back to the merchant or customer. * The CPU attempts, if present, to decrypt the encrypted Target Bank Account Identifier stored in the Directed Cash token. If this decryption fails, the token is not deemed to be directed to a particular Bank Account. The funds transfer will not proceed. The Target Bank will communicate this failure back to the merchant or customer. In this case, the customer can still redeem their token as detailed below.

The CPU attempts to verify that the Directed Cash token has been digitally signed by an authorised entity (for example, the Source Bank). Failure to verify the digital signature of a Directed Cash token implies that the token is invalid and no funds transfers takes place. In this case, the customer may not redeem the value of the Directed Cash token. Part of the verification process of the digital signature includes identifying whether or not the Directed Cash token has been tampered with or modified.

The CPU attempts to determine if the expiration date of the Directed Cash token, if present, has elapsed. An elapsed Directed Cash token cannot take part in a funds transfer can cannot be redeemed. In a realisation of the funds transfer, a Directed Cash token without an expiration date may imply that it does not expire.

The CPU attempts to determine the currency of the Directed Cash token. If the currency can not be determined, then the Directed Cash token may be deemed to be valueless. However, currency considerations occur only when performing funds transfers across international borders. Therefore, if an implementation of the tokens occurs within one country, then part of the specifications of the implementation may imply that all Directed Cash tokens are in the local currency. * The CPU extracts the GUID contained within the Directed Cash token and attempts to locate a previous token with the same GUDD which may be stored within the Target Bank's computer servers. If a previous token with the same GUID is located, then this may imply that the token has been previously deposited (presented) to the Target Bank and as such the token is no longer valid. This in effect solves the double spending problem which arises in all forms of digital cash.

* The rejection or acceptance of a Directed Cash token is communicated back to the entity which deposited the token. (For example, it could be a merchant, a customer, or a third party which is attempting to redeem a Directed Cash token on behalf of a customer. Redeeming a Directed Cash Token

[77] A Directed Cash token which has contained within it, Source Bank Identifiers and optionally, Source Bank Account Identifiers can be redeemed. Redeeming a Directed Cash token is taken to mean that a customer which has instructed a Source Bank to generate a Directed Cash token can exchange this token for a new Directed Cash token this time however the Target Bank (of the new Directed Cash token) is the Source Bank of the original Directed Cash token. The Source Bank of the new token will be the Target Bank of the original token. That is, the functions of the Source and Target Banks are essentially reversed during the process of redeeming a Directed Cash token.

[78] Figure 9 provides an illustration of the various steps a customer may take to redeem their Directed Cash token. A customer (901) communicates via some communication medium (908) (not necessarily secure) to a third party (902) whose task is to assist in the redemption of the Directed Cash token provided by the customer. The third party entity may be accessible via some web address, where this web address is stored (unencrypted) within the original Directed Cash token. The third party (902) may not necessarily be able to decrypt any of the Target Bank Identi- fiers (unless this has been authorised by the Target Bank). However, the third party determines (using some predefined method, between the third party (902) and the Target Bank (904)) the identity of the Target Bank. The third party transmits the customer's Directed Cash token and waits for validation of that token from the Target Bank (904). If the token is valid, either the third party (if authorised or arranged by the Target Bank) or the Target Bank itself, will, using the en- crypted Source Bank identifiers contained within that token, generate a new Directed Cash token this time targeting the Source Bank. The new Directed Cash token is sent back to the customer (901 ) via the third party using communication channel (908). The customer deposits the new Directed Cash token at their original Source Bank (906) and the funds are redeemed by crediting the customers bank account. The Source Bank goes through essentially the same process to vali- date that the new Directed Cash token can be deposited, for example, ensures that the new Directed Cash token has been digitally signed by the issuing bank (in this example, the original Target Bank), that the new token has not expired (if an expiration date is present) and that the new token has not been modified or tampered with during transmission from the original Target Bank back to the original Source Bank over possibly unsecured communication channels. [79] For a redemption to succeed, ideally the original Directed Cash token should contain a Target Bank Identifier. Whether or not the original Directed token contains a Target Bank Account Identifier does not affect the process of redemption. In the case of a Directed Cash token deposited at the Target Bank as part of a redemption, with Target Bank Account Identifiers, the funds would not be credited to the Target Bank Account, rather the Target Bank uses the funds transferred in the original Directed Cash token to create the necessary funds for the new Directed Cash token.

[80] It should be noted that once a Target Bank receives a Directed Cash token for redemption and has validated it such (and has deducted any fees and charges from its value, if such fees and charges apply), then the Target Bank can send the new Directed Cash token directly to the cus- tomer^'s bank (for example, using email) without the intervention of a customer. This is illustrated by alternative communication channel (909).

[81 ] It should be noted that if a third party provides a service for the redemption of a Directed Cash token, then that third party may apply fees and charges which may reduce the value of the new Directed Cash token. [82] It should be noted that if a third party is used as part of the redemption of a Directed Cash token, then that third party may bypass the customer and transmit the new Directed Cash token directly to the Source Bank as in (910).

[83] A third party need not be involved in a redemption process. A customer may, if the customer has been provided with the Target Bank web address (for example, this may reside in the Directed Cash token to be redeemed), or if the customer has knowledge of the Target Bank web address, directly communicate (905) with the Target Bank to obtain the new Directed Cash token containing the value (less fess and charges if they apply) of the original Directed Cash token.

[84] It should be noted that a third party may in fact be the same merchant from which the customer was in the process of making a purchase or making a bill payment. That is, a merchant as part of a service offered to a customer may facilitate the redemption of a Directed Cash token.

[85] If a Directed Cash token contains Source Bank Identifiers, this allows the token to be redeemed (for example, in the event that customer no longer wishes to proceed with a purchase). Allowing a Directed Cash token to be redeemable provides additional security and confidence to the customer, while not necessarily reducing the privacy of the customer. [86] One embodiment of the present invention is an example of a Directed Request token and a Directed Cash token which is used to make a purchase of goods or services using a public communication channel such as the Internet. The system can be illustrated using Figure 6. In this embodiment for example, a Directed Request token ideally comprises the following data elements: * An encrypted Target Bank Identifier which can only be decrypted by the Target Bank.

This data element is required in this embodiment of the funds transfer. The encrypted Target Bank Identifier serves to target a particular bank, since it cannot be decrypted by any other entity save for the Target Bank (or some entity authorised by the Target Bank). The encryption also serves as a means to ensure that the Target Bank Identifier has not been tampered with during transmission and exchange of the Directed Request and Directed Cash tokens.

* An encrypted Target Bank Account Identifier (for example, the merchant's bank account details associated with the Target Bank) which can only be decrypted by the Target Bank. This data element is required in this embodiment of the funds transfer. This encrypted bank account data serves a dual purpose of first, identifying the bank account of the merchant, and secondly ensures that the target details have not been tampered with during the transmission and exchange of the Directed Request and Directed Cash tokens.

* A Target Bank expiration date stored both as encrypted and unencrypted. An expiration date is prudent, in that, if circumstances change, then the Target Bank may decline to validate a Directed Cash token based upon an expired Directed Request token. For example, encryption algorithms may at some future date become compromised, bank account details may change. Storing the unencrypted expiration date allows the Source Bank to acknowledge that the Target Bank details will expire and may decline to generated a Directed Cash token based upon an expired Directed Request token. Storing the expiration date encrypted ensures that any tampering of the expiration date by a third party is revealed to the Target Bank.

A Target Bank creation date (and possibly a creation time) stored as encrypted data. While this data is not necessary to complete a funds transfer via the token exchange, it may be data that, first assists the Target Bank in locating a reference to the Target Bank data, and second assists in ensuring that the tokens have not be tampered with. It should be noted that a Target Bank can store any information within a reasonable size and then encrypt this information for their own purposes. A creation date is just one such example.

A Target Bank preferred or required currency in which a Directed Cash token must have value. Again, the currency (or list of currencies) should be stored both as encrypted and unencrypted data. The unencrypted currency allows the Source Bank to read this data and generate the Directed Cash token whose monetary value is in the indicated currency. The encrypted currency data allows the Target Bank to determine if any modification of the unencrypted currency data has occurred.

Unencrypted redemption details data. Such details could, for example, be a Uniform Resource Locator (URL) that essentially is an address to a resource on the web. It could be a web address operated directly or indirectly by the Target Bank or it could be a merchant's web site, or it could be a third party entity whose service is to assist with the redemption of Directed Cash tokens. This unencrypted data could be inserted into the Directed Request token by the Target Bank or by the merchant.

An unencrypted data element which indicates the monetary value of funds which are requested. This data may therefore represent the value of goods or services purchased, or may represent the value of a bill which is to be paid. Note that, this is the amount requested which is present in the Directed Request token and may not be the actual value of any subsequent Directed Cash token generated using such a Directed Request token. A merchant expiration date and time encrypted or unencrypted. This data, while not required for a successful funds transfer, facilitates purchases. For example, a merchant may have a "sale" item for a limited time. Such a limited time may be the basis for the inclusion of a merchant expiration date (and if required expiration time).

A merchant creation date and time and an expiration date and time encrypted. This may assist the merchant in tracking orders or determining the age of a generated Directed Request token. It is not required for a successful funds transfer.

The currency preferred by the merchant stored as unencrypted data. This is not essential to the funds transfer using the exchange of tokens. The Target Bank has already provided this information and will be present in the Directed Request token. However, the merchant may wish to emphasise the currency required.

Details of all products and or services purchased by a customer which may include images of the products or services and other product or services specifications, some, all or none of which details are encrypted. This is not essential to the funds transfer mechanism, however it does provide confidence to the customer in determining the purpose of the funds transfer.

Customer details which are entered by the customer or by the merchant and are encrypted. For example, a customer may wish to leave their contact name and their delivery address with the merchant. This data can be stored as part of the Directed Request token and returned to the merchant when the Directed Request token is exchanged for a Directed Cash token. Encrypting the data gives the customer a high level of privacy while allowing the merchant to determine the customer details. This data is not required for the funds transfer to be effective.

A merchant digital signature. In this embodiment the merchant digitally signs the Directed Request token generated by the merchant. A digital signature provides the following advantages: first, the Directed Request token can not be tampered with and gives confidence to the customer that the details in the Directed Request have not been modified. In addition, it allows the Source Bank to validate the digital signature and advise the customer the result of the validation. It should be remarked that the digital signature need not be that of the merchant, it may be possible that a third party is used to protect the identity of the merchant (if this is what is required by the customer and or merchant). The confidence and security is still provided by a third party signing the Directed Request token. While a digital signature is not required for a successful funds transfer, it does provide the customer with additional security and confidence in both the merchant and products (or services) purchased.

[87] A Directed Cash token created in response to the Directed Request token contains a copy of all data elements generated by the Target Bank. That is, it contains the encrypted Target Bank Identifier and Target Bank Account Identifiers. In addition the Directed Cash token preferably contains the following data components:

* A copy of the redemption data elements contained in the Directed Request token. This assists the customer in redeeming the Directed Cash token, if the customer chooses not to proceed with the purchase, or bill payment as described in the Directed Request token. This data is not essential for a successful funds transfers, however, it provides confidence to the customer since it provides an address to which the Directed Cash token can be transmitted and exchanged for another Directed Cash token, this time directed back to the customer^'s bank.

* An unencrypted Directed Cash token value which may differ from any value specified in the Directed Request token. This is the monetary value of the funds transfer and is unencrypted so that it is visible to the customer, merchant and Target Bank. This is essential for a successful funds transfer.

* An unencrypted expiration date. The Source Bank may have taken the expiration date (and possibly time) from the information, if available, contained within the Directed Request token, or the Source Bank may have generated their own expiration date (and possibly time). The value of this data, if present, would generally depend on the Source Bank requirements and those of the Target Bank, For example, it may be prudent that an expiration date is stored in the Directed Cash token created by the Source Bank so that future advances in cryptology do no comprise the Directed Cash token. The inclusion or exclusion of an expiration date (and possibly time) is not essential for a successful funds transfer. An unencrypted globally unique identifier (GUID). This provides a means of both the Source Bank and Target Bank to identify the Directed Cash token. In particular a Target Bank requires the GUID to ensure that a Directed Cash token is not deposited ("spent") at the Target Bank more than once. The Target Bank achieves this by searching their database for a previous Directed Cash token using the GUID. Once the Target Bank records the deposit of a Directed Cash token using the GUID any further attempts to deposit the same Directed Cash token (same as in the same GUID) will fail. The Source Bank may also use GUID to provide a history of tokens issued for a customer, or to store a copy of Directed Cash tokens for the customer's convenience. The inclusion of a GUID is necessary for a successful funds transfer.

A digital signature which signs the Directed Cash token produced by the Source Bank. The digital signature provides a method so that the tampering of modification of a Directed Cash token can be identified. Thus if the value of a Directed Cash token is modified, the digital signature provides a means to identify this. In addition, the digital signa- ture ensures that the financial institution which has generated the Directed Cash token is authorised to do so. (That is, only regulated and authorised financial institutions can generate Directed Cash tokens.) A Target Bank requires the digital signature to authenticate the token and to ensure that it has not be tampered with. The inclusion of a digital signature is necessary for a successful funds transfer,

* Encrypted Source Bank identifier and encrypted Source Bank customer bank account.

This data is necessary so that a customer can redeem the value of a Directed Cash token without necessarily completing a purchase, or bill payment, or funds transfer. This data element is not necessary to complete a funds transfer, however without this data, the customer may not be able to retrieve their funds in the event that a Directed Cash token was not used to complete the funds transfer, or in the event that the Directed Cash token has been lost or misplaced.

[88] The token exchange operation for transferring funds is illustrated in Figure 6. A Target Bank (601 ) which is a merchant' s (603) bank generates a data structure which contains the target bank details and other details as described. A merchant (603) receives this data segment from a target bank, the data segment and the contents of are periodically updated, the period of update is implementation dependent. The merchant receives these data elements via some communication channel which is secured in some manner (for example, these data elements can actually be delivered via post, electronic post, via secured internet connection). Alternatively, a merchant can use the Target Bank' s public key (in a Public Key Encryption system) to encrypt the data themselves. Each merchant would have a tailored merchant bank data segment. The merchant creates a token with the merchant, customer and other details as described above. The customer uses an interface (604) to the merchant (for example, the merchant's online website). Using this interface, the customer receives a Directed Request token generated by the merchant in response from a customer purchase. The customer uses a communication channel (605) to possibly store a copy of the Directed Request token in their local PC. The customer uses a communication channel (605) to interface with a Source Bank (607) using the bank's customer interface (609). The Source Bank (607) receives the Directed Request token. The Source Bank informs the customer of some or all unencrypted details contained in the Directed Request token. For example, the Source Bank may provide detai ls of the products and the merchant and also provide verification of the merchant if the Directed Request token has been digitally signed by the merchant (or digi- tally signed by a trusted third party). The Source Bank asks customer if the customer wishes to proceed with the generation of a Directed Cash token. If the customer's proceeds, then the customer' s bank generates a Directed Cash token containing data as described above. The customer receives the Directed Cash token from the Source Bank using the customer interface (609). The customer transfers the Directed Cash token to the merchant (603) using the customer interface (604) and the communication channel (605). In addition, the customer may wish to store a copy of the Directed Cash token on their own PC (606). Once the merchant receives the Directed Cash token from the customer, this token is forwarded onto the Target Bank (601 ) using a communication channel (61 1 ). The merchant's bank (Target Bank) receives the Directed Cash token from the merchant. The Target Bank proceeds to validate the Directed Cash token, and the merchant receives verification of the funds transfer from the merchant's bank and the purchase is complete.

[89] The communication channels between the merchant and Target Bank (602, 61 1 ) can be identical. For example, it could be secured email or a secured web server. Alternatively, (602) could be a highly secured communication which is only periodically used to transfer Target Bank data and (61 1 ) is an unsecured internet connection. The communication channel (605) between a customer^'s PC and the Source Bank would preferably be secured since the customer may be required to validate their identity to the Source Bank using the customer interface (609). It is con- ceivable that the process can be automated and bypass the customer entirely using the alternative communication channels (608, 610).

[90] Since the Directed Request token contains the encrypted target bank details it provides privacy to the merchant since no merchant bank details are visible to anyone who intercepts this token. Since the Directed Request token is digitally signed by the merchant (or other trusted third party) it provides confidence to the customer that the Directed Request token has not been tampered with during transmission to the customer's bank. Since the Directed Cash token is digitally signed and contains a globally unique identifier and is targeted to a specific target bank and target bank account, it provides security in the event that the Directed Cash token is lost during trans- mission, since the source bank may with the permission of the customer store a copy of the Directed Cash token on the bank' s server, and or the source bank may email a copy of the Directed Cash token to the customer's email address, and or the customer may transmit a copy of the Directed Cash token to their own PC prior to transmitting the Directed Cash token to the merchant. Since the Directed Request and Directed Cash tokens contain redemption data, the customer is protected against the accidental loss of value. This embodiment provides good privacy and excellent security. No customer personal information is publicly visible and no merchant or customer bank details are publicly visible.

[91 ] In an additional embodiment, a Directed Cash token is generated by the Source Bank to transfer funds. A Directed Cash token is created by a Source Bank in response to a bank cus- tomer who wishes to transfer funds to a Target Bank. The Directed Cash token contains the following data elements:

* An encrypted Target Bank Identifier which can only be decrypted by the Target Bank.

This data element is required in this embodiment of the funds transfer. The encrypted Target Bank Identifier serves to target a particular bank, since it cannot be decrypted by any other entity save for the Target Bank (or some entity authorised by the Target Bank).

The encryption also serves as a means to ensure that the Target Bank Identifier has not been tampered with during transmission and exchange of the Directed Request and Directed Cash tokens. In this embodiment, no Target Bank Account Identifier details are stored as part of the encrypted data. That is, in this embodiment the funds transfer is tar- geted to a financial institution rather than a customer of the financial institution. Encrypted Source Bank identifier and encrypted Source Bank customer bank account. This data is necessary so that a customer can redeem the value of a Directed Cash token without necessarily completing the funds transfer. This data element is not necessary to complete a funds transfer, however without this data, the customer may not be able to retrieve their funds in the event that a Directed Cash token was not used to complete the funds transfer, or in the event that the Directed Cash token has been lost of misplaced. In this embodiment the customer has knowledge of the Target Bank and can use this knowledge to redeem their Directed Cash token.

An unencrypted Directed Cash token monetary value and currency. This is the value of the funds transfer and is unencrypted so that it is visible to the customer and Target Bank. This is essential for a successful funds transfer.

An unencrypted expiration date. The value of this data, if present, would generally depend on the Source Bank requirements and those of the Target Bank. For example, it may be prudent that an expiration date is stored in the Directed Cash token created by the Source Bank so that future advances in cryptology do no comprise the Directed Cash token. The inclusion or exclusion of an expiration date (and possibly time) is not essential for a successful funds transfer.

An unencrypted globally unique identifier (GUID). This provides a means of both the Source Bank and Target Bank to identify the Directed Cash token. In particular a Target Bank requires the GUID to ensure that a Directed Cash token is not deposited ("spent") at the Target Bank more than once. The Target Bank achieves this by searching their database for a previous Directed Cash token using the GUID. Once the Target Bank records the deposit of a Directed Cash token using the GUID any further attempts to deposit the same Directed Cash token (same as in the same GUID) will fail. The Source Bank may also use GUID to provide a history of tokens issued for a customer, or to store a copy of Directed Cash tokens for the customer' s convenience. The inclusion of a GUID is necessary for a successful funds transfer.

A digital signature which signs the Directed Cash token produced by the Source Bank. The digital signature provides a method so that the tampering or modification of a Directed Cash token can be identified. Thus if the value of a Directed Cash token is modi- fied, the digital signature provides a means to identify this. In addition, the digital signature ensures that the financial institution which has generated the Directed Cash token is authorised to do so. (That is, only regulated and authorised financial institutions can generate Directed Cash tokens.) A Target Bank requires the digital signature to authenticate the token and to ensure that it has not be tampered with. The inclusion of a digital signature is necessary for a successful funds transfer.

[92] Operation of the funds transfer. A customer approaches a Source Bank, for example, using an internet connection or by simply walking into the Source Bank. The customer indicates (or selects) the Target Bank to which they wish to transfer funds. The customer indicates a value and currency in which a Directed Cash token is to be generated with. The Source Bank generates a Directed Token which the customer can store on some portable electronic device such as a memory stick, mobile phone or digital camera.

[93] The customer presents the Directed Cash token to the Target Bank. In return the Target Bank, after validation of the digital signature, exchanges the Directed Cash token for cash notes in the currency which was indicated in the Directed Cash token if the Directed Cash token does not need to be cleared. If the Directed Cash token requires clearing, then the customer can have the funds transferred into any account within the Target Bank pending clearing.

[94] Since the Directed Request token contains the encrypted target bank details it provides high privacy to customer. There is a loss of security, since anyone intercepting the Directed Cash token prior to it being deposited by the customer, can they themselves deposit the Directed Cash token, if the Target Bank can be identified. Since the Directed Cash token is digitally signed and contains a globally unique identifier and is targeted to a specific target bank, it still provides protection to the customer in the event that the Directed Cash token is lost during transmission to the Target bank. Additional protection can be achieved by the customer, for example, by personally encrypting the Directed Cash token so that only the customer can decrypt the data, e.g. using a PIN.

[95] Since the Directed Cash tokens contain redemption data, that is, since the Directed Cash token contains the Source Bank Identifier and (possibly) the Source Bank Account Identifier, the customer is protected against the accidental loss of value in the event that the funds transfer is not completed. [96] This embodiment provides excellent privacy and good security. No customer personal information is publicly available. The Target Bank is not readily identifiable and no customer bank details (apart from the identity of Source Bank) are publicly available.

[97] The following variations and ramifications of the method and system for transferring money are possible:

[98] If when making a purchase, paying a bill or transferring funds, and the Target Bank Identifier and or the Target Bank Account details are not encrypted within a generated Directed Request token, then this provides minimal privacy and the corresponding Directed Cash token generated from such an unencrypted Directed Request token, while still directed will operate in a similar manner as some of the existing financial transactions described as prior art.

[99] If no currency details are stored within a Directed Request token, then the funds transfer using the exchange of tokens can be implemented so that it is implicit that the Directed Cash token generated by the source bank will be in the currency used by that bank. Alternatively, the Directed Cash token can be generated in any valid currency when the source bank prompts a cus- tomer in the currency in which the customer wishes to have the Directed Cash token issued. By not specifying the currency in a Directed Request token, then this provides additional privacy for both a merchant and customer while not compromising security.

[ 100] If no expiration dates and times are stored within a Directed Request token, then it should be implicit that the Directed Request token is valid without any expiration date and time. The Directed Cash token may have an expiration date and time, the same, different or without, irrespective of what is stored in the Directed Request token. Expiration dates and times are generally implementation dependent.

[ 101 ] Having an expiration date and time in a Directed Request token implies that the source bank would not create a Directed Cash token using an expired Directed Request token. Depend- ing on the implementation of the technology, this may imply that a merchant and or customer has a limited time to use such a Directed Request token. This would not impact on the privacy nor the security of the process.

[ 102] If a Directed Request token does not store redemption details (such as an URL where the owner of a Directed Cash token can redeem the Directed Cash to obtain a new Directed Cash so a customer can re-deposit the value back into their bank account), then it is anticipated that it would be difficult for the owner of the Directed Cash token generated from such a Directed Request token to obtain the value of the Directed Cash token back into their bank account. It is possible that thirds parties can set up "general redemption websites" (or other businesses) which provide a service (effectively contacting as many target banks as possible with a view that one of these will validate the Directed Cash token). Not having redemption details stored in a Directed Request token provides additional privacy since the Target Bank can not be identified, while reduci ng the level of security of a Directed Cash token since it would be difficult to redeem such a token. It is possible that third parties can offer a service whereby redemption details are en- crypted and only visible to that third party. This provides security for the Directed Cash token since it can be redeemed, while at the same time provides additional privacy to the merchant and or customer.

[ 103] Irrespective of whether or not a Directed Request token contains redemption details data, a customer may choose not to store redemption data within their Directed Cash token. This could possibly be implemented as an option on a Source Bank' s website or communicated to a Source Bank in some form prior to the generation of a Directed Cash token.

[ 104] To redeem a Directed Cash token it is necessary that the Source Bank store their (the Source Bank' s) encrypted Bank data within the Directed Cash token. This makes it possible to create a new Directed Cash token from the old Directed Cash token, directed to the Source Bank this time (in effect the Source Bank becomes the Target bank). To obtain a higher level of security, a customer could choose to store some encrypted customer bank account identifier such as their name or bank account number within the original Directed Cash token as well as any redemption URL present. To provide a higher level of privacy, it is possible that a customer not store encrypted customer identifier within the Directed Cash token, however this will reduce the level of security to customer, since if the token is intercepted, it is possible that the interceptor redeems the token bank to the source bank and is created with the value of Directed Cash token.

[ 105] If a Directed Request token is not digitally signed by a merchant, then this provides additional privacy to both a customer and the merchant.

[ 106] A merchant need not generate a Directed Request token using their computer servers. A merchant can use a third party or can use the Target Bank. This allows small businesses who do not have the necessary computer hardware and software resources to use this funds transfer system.

[ 107] A merchant need not digitally sign a Directed Request token using their digital signature which would identify the merchant. A merchant can use a trusted third party if required to digi- tally sign a token on their behalf. This allows a merchant to keep their identity private while at the same time providing additional confidence for the customer in the authenticity of the Directed Request token.

[ 108] A merchant need not store any product or merchant details in a Directed Request token. Not storing such details provides additional privacy since anyone intercepting the Directed Re- quest and or the Directed Cash token will not be able to determine the purpose of the funds transfer, nor the products that were purchased.

[ J 09] It is possible that a Target Bank and Source Bank are the same entity. In this case, it is possible to apply various digital signature methods and other digital procedures to reduce the risk that such an entity (which is both the Target and Source) could identify customers with mer- chants. This would be implementation dependent and it is possible that different banks would implement different procedures to reduce the risk of this "cross-referencing" of merchants and customers.

[ 1 10] Directed Cash tokens can be copied and stored as electronic data or in printed format such as a 2D barcode. This storage provides a backup in the event that a Directed Cash token is lost in transmission or is misplaced or stolen. For example, a customer may store a copy of a Directed Cash token on their personal computer. Alternatively, a Source Bank may provide this as a customer service.

[ I l l ] Nothing mentioned so far restricts the Source Bank from adding Source Bank redemption details with redemption details which target a third bank. Thus it is possible that a Directed Cash token generated by a Source Bank can only been redeemed at a third bank. This provides additional privacy to a customer and flexibility.

[ 1 12] Nothing mentioned so far restricts the funds transfer from being carried out over fully public networks, fully private networks or a mixture of both types of networks. This provides additional flexibility and possibly additional security which is implementation dependent. [ 1 13] Nothing mentioned so far restricts the value of a Directed Cash token to have immediate value as soon as it is generated. That is, the funds transfer can occur without the use of funds clearing.

[ 1 14] Nothing mentioned so far should imply that the funds transfer method described operates with the exchange of only two tokens. For example, it is possible two or more Directed Cash tokens are generated for one funds transfer, one bill payment, or one purchase. As a further example, two Directed Request tokens could be combined into one Directed Cash token.

[ 1 15] Target Bank details such as Target Bank identifiers and Target Bank account identifiers can be encrypted in such a manner that periodically the actual encrypted data will change for a specified merchant. The period with which the encrypted data is modified is such as to make it impractical to determine the identification of the Target Bank.

[ 1 16] Target Banks can use a Public Key Encryption system whereby a Source Bank can encrypt the Target Bank Identifiers as an alternative to the Target Bank providing these. Alternatively, a merchant can encrypt the Target Bank Identifiers as an alternative to the Target Bank providing these, and thus dispensing with the requirement that these encrypted Identifiers are to be transmitted to the merchant.

[ 1 17] In one embodiment of the independently inventive method using drag and drop, as exemplified in Figure 10, a user's computer ( 1 102) is running a Web browser application ( 1 132). The user's computer has a pointing device ( 1 103), a display ( 1 1 10), and is connected to a communica- tions network ( 1 108), e.g. the Internet. Also connected to the communication network are a shopping server ( 1 104) running a shopping web application ( 1 128) and an Internet banking server ( 1 130) running an Internet banking Web application ( 1 106).

[ 1 18] On the display of the user's computer is a shopping Web page ( 1 1 12) containing a product offer ( 1 1 14) and an "options for offer" area ( 1 126) where the user can set option for the offer, and a purchase order and payment target location ( 1 1 17) where the user can drop purchase order and payment items.

[ 1 19] Also on the display is another Web page, the user's Internet banking Web page (1 1 18), containing a product offer target location where the user can drop product offers, like the one found on the shopping Web page. It also contains a purchase order and payment item ( 1 120) that can be used to purchase the product offer dropped on the target.

[ 120] A confirmation and options panel ( 1 126) is used to inform the user of the details of any product offer dropped on the product offer target location. It is where the user can specify whether they wish to proceed or not with the purchase. The panel also provides an options facility whereby the user can configure options relating to the purchase and payment.

[ 121 ] In the first embodiment, the user arrives at an Internet shopping Web site ( 1 1 12) that has a product for sale and on the Web page there is a product offer item ( 1 1 14) that contains data about the offer for sale of the product. In some embodiments before the user chooses to proceed with the offer they can change the options for the offer ( 1 126) using the interface provided (e.g. whether to include details of the product or not).

[ 122] If not already open, the user then navigates to their Internet banking web site on another Web browser page ( 1 1 18). When at the correct page the user can, if they wish to consider the offer further, drag and drop ( 1 122) the product offer item from the Internet shopping web page onto the product offer target location ( 1 1 16) on the Internet banking web site. It is the user who initiates this action to consider the offer.

[ 123] This action initiates a dialog with the user in a confirmation and options panel ( 1 126) or similar. In this the Web application informs the user of the details of the product offer (obtained from the item dropped on the page). It asks the user if they wish to proceed with the purchase (or not). It also allows the user to set any options regarding the purchase (e.g. to provide a delivery address or not to provide any customer details).

[ 124] If the user confirms that they wish to proceed the Internet banking site produces a purchase order and payment item ( 1 120) and displays that on the Internet banking site. The user can then proceed to drag and drop ( 1 124) the purchase order and payment item from the Internet banking Web site to the Internet shopping Web site to initiate the purchase. It is the user who is in control of this process.

[ 125] The user can arrive at the Internet shopping Web site in many different ways, e.g. they could be directed there from a link in an email or an advertisement online (or offline), and they could be searching the Internet shopping site themselves and come across the particular item and offer for sale.

[ 126] The user could drag and drop the items from Web page to Web page or, alternatively copy and paste the items from one page to another, or alternatively drag the items from the Web page to some intermediate location (e.g. the computer desktop) and then, subsequently, from there to their intended drop location.

[ 127] The Internet shopping Web site can respond to receipt of the purchase order and payment item in a number of different ways, including doing nothing, informing the user immediately of receipt of the payment and progress of the purchase, or perhaps email the user details of the pur- chase (if the user' s information is available).

[ 128] Options for the offer include settings like hiding details of the product or not and hiding details of the Internet shopping Web site or not. Options within the purchase order and payment include settings like hiding any details about the user or including details of the user (e.g. the desired delivery address for the user). [ 129] The Web pages of the Web sites could be running on two different Web browsers on the user's computer. The user's computer could be any type of computer, including a desktop computer, a laptop computer, a netbook computer, a tablet computer, a PDA or smart phone computer, or similar.

[ 130] The product offer and purchase order and payment items could be displayed as file icons or as generic images or as images representing the role these items play in the process, e.g. the offer for sale item could be represented as an image of the item for sale with the sale price. Similarly the purchase order and payment could be represented as cash paid for the item.

[ 13 1 ] The two servers could be the same server. The drop locations could be particular parts of the Web pages or they could be anywhere on the Web pages. The pointing device could be a mouse, a trackball, a track pad, a touch sensitive screen, or any input device that could facilitate a drag and drop action.

[ 132] Rather than being an offer for sale the product offer could be a request for funds, i.e. someone or some entity is requesting that the user transfer some funds to them, or a bill to be paid, i.e. someone or some entity is requesting that the user pays a bill. The same interaction, two drag and drops with optional setting of details, is involved.

[ 133] In another embodiment, shown in Figure 1 1 , a user's computer ( 1202) is running a client email application ( 1232) as well as a client Internet banking application ( 1234). These are custom applications for email and Internet banking respectively, rather than Web sites accessed via a Web browser.

[ 134] The client applications communicate with remote servers. In the first instance, the client email application receives emails from many different server email applications, like ( 1258) running on an email server like ( 1204). In the second instance, the Internet banking application communicates with a server Internet banking application ( 1230).

[ 135] The user's computer has a pointing device ( 1203), a display ( 1210), and is connected to a communications network ( 1208), e.g. the Internet. On the display of the user's computer is a client email application window ( 1212) containing a product offer ( 1214) either as an attachment to an email or included directly in the email, received from a server email application ( 1258). [ 136] Also on the display is another window ( 1218), for a client Internet banking application ( 1234). The window contains a product offer drop location ( 1216) where the user can drop product offers, like the one in the email application. It also contains (subsequent to certain steps) a purchase and payment item ( 1220) that can be used to purchase the product offer dropped on the location. [ 137] An interface ( 1226) is used to inform the user of the details of any product offer dropped on the product offer target location. The panel also provides an options facility whereby the user can configure options relating to the purchase and payment and an interface for the user to choose to proceed (or not) with the purchase.

[ 138] In this embodiment the user receives an email with a product offer attached and views the email in a client email application window. The user sees the product offer attached to email and may wish to consider purchasing it.

[ 139] The user opens their client Internet banking application if it is not already open. The user drags and drops the product offer ( 1222) to a purchase offer drop location in the client Internet banking application to consider the offer further. [ 140] The client Internet banking application analyses the product offer and display any details it can about it to the user. It asks the user if they wish to proceed with the purchase and payment for the product. It also enables the user to set specific options regarding the payment, e.g. to include a delivery address or to hide or details of the user. [ 141 ] If the user confirms that they wish to proceed with the purchase the client Internet banking application communicates with the server Internet banking application and arranges for a purchase and payment instrument to be produced and displayed in the client Internet banking application.

[ 142] The user can then proceed to drag and drop ( 1224) the purchase and payment instrument from the client Internet banking application to the client email application attachment drop location ( 1217), or more specifically to an email to be sent to the party making the offer for sale. This is the second drag and drop.

[ 143] The user can then use the client email application to forward the purchase and payment instrument to a specific email address or reply to the original message containing the product offer with the purchase and payment instrument.

[ 144] This embodiment primarily differs from the first embodiment in that two separate applications are used (rather than one Web browser with two different Web sites) and the client applications are custom client applications rather than Web applications. Also the user may be receiving an unsolicited product offer. [ 145] This embodiment describes the scenario where an offer for sale of a product is sent by email to one or more users. The email could be solicited or unsolicited email and directed specifically to the user or not.

[ 146] The email could contain the digital data for the purchase offer explicitly in an attachment, directly in the email body, or it could contain implicitly in an attachment, e.g. the subject matter of an image. In the latter case, pre-processing would be required to extract the digital data for the purchase offer from the image.

[ 147] The product offer could be dragged and dropped directly from the client email application to the client Internet banking application, copied and pasted, or it could be dropped somewhere else, e.g. the desktop, and then subsequently dragged and dropped to the client Internet banking application.

[ 148] Similarly the purchase and payment could be dragged and dropped directly from the client Internet banking application to the client email application, copied and pasted, or it could be dropped somewhere else. e.g. on the desktop, and then subsequently dragged an dropped to the client email application or another application.

[ 149] Rather than being an offer for sale the product offer could be a request for funds, i.e. someone or some entity requesting that the user transfer some funds to them, or a bill to be paid, i.e. someone is requesting that the user pays a bill. The process and interaction will be the same. [ 150] Rather than dragging and dropping the email could be forwarded by the user or by the entity offering the product for sale to the user's server Internet banking directly. Similarly, rather than the user having to drag and drop the purchase and payment back to the email application the client or server Internet banking application could email it directly for them.

[ 151 ] The client email application could be a remote file system browser having access to a source of product offers. When a party puts a product offer in the required location it becomes available for drag and drop (i .e. consideration by the user). Similarly, the purchase and payment could be dragged into a browser for a remote file system as a method for delivery of the item to the required party.

[ 152] The client and server email application could be other applications that can perform simi- lar tasks and provide similar functionality.

[ 153] In another embodiment, shown in Figure 12, a user's computer ( 1302) is running a scanning application ( 1338) as well as a Web browser application ( 1334). The scanning application is local to the user's computer whereas the Web Internet banking application communicates using a communication network ( 1336), e.g. the Internet, with an Internet Banking Server ( 1328) running a Server Internet banking application ( 1330).

[ 154] In this embodiment there is a printed product offer ( 1332) that contains the product offer data in a visual format (e.g. 2-D barcode) as well as possibly some human readable details. Also, at the end there is a printed purchase and payment order ( 1338) that contains the purchase and payment data in a visual format (e.g. 2-D barcode) as well as possibly some human readable details.

[ 155] The user's computer has a pointing device ( 1304), a display ( 1310), and is connected to a communications network ( 1336), e.g. the Internet. On the display of the user's computer is a scanner application containing a product offer ( 1314) that has been extracted by the scanner application from the image of the printed product offer ( 1305).

[ 156] Also on the display is another window ( 1318), which is a window for a Web Internet banking site displayed by the Web browser application ( 1334). The window contains a product offer drop location ( 13 16) where the user can drop product offers, like the one in the previous embodiments. It also contains a purchase order and payment item ( 1320), created within the process, which can be used to purchase the product offer dropped on the location (if the user desires).

[ 157] An interface ( 1326) is used to inform the user of the details of any product offer dropped on the product offer target location. The panel also provides an options facility whereby the user can configure options relating to the purchase and payment and choose to proceed (or not) with the purchase.

[ 158] In this embodiment the user starts with a printed product offer ( 1305) that contains the product offer data in a visual format (e.g. 2-D barcode) as well as possibly some human readable details. The user employs the scanner application to scan the printed product offer into the user's computer and to extracts the product offer data from it (e.g. from the 2-D barcode).

[ 159] The method then proceeds as described in the previous embodiments. The user can set any options with regards to the regular product offer using the interface for that (1340). When ready to consider the offer the user then drags and drops the product offer ( 1322) onto the Web Internet banking site window ( 13 18), particularly onto a purchase offer drop location ( 1316). [ 160] The Web Internet banking site then offer an interface for the user to contemplate the details of the request (as extracted by the Internet banking application, to set any options with regards to the creations of the purchase and payment item ( 1320), and to confirm whether they wish to proceed with the purchase or not ( 1326). [ 161 ] Lf the user does choose to proceed then the Web Internet Banking application produces a purchase order and payment item that contains details about the purchase and payment. The user can then print out the purchase order and payment item to get a printed version ( 1342) using the attached printer ( 1308) and deliver that physical item (or a representation of that item). [ 162] The printed product offer could come from a variety of different places, e.g. a newspaper or magazine (or any other publication), a billboard (small or large), an advertising flyer, or even on the product itself. The details about the product offer may be encoded in other machine readable ways (besides a 2-D barcode).

[ 163] The purchase and payment order does not have to be printed it could be dragged and dropped to another application (e.g. a Web store or an email as in the other embodiments, or to the desktop). If the purchase and payment order is printed it can be delivered to the target in many ways (including but not limited to post, physical delivery, or fax).

[ 164] The printed product offer may not actually be printed it may just be displayed on a visual display device (e.g. a screen) and the user scans or take a photo of the product offer whilst it is displayed. Similarly, it may not be necessary to print the purchase and payment order, it could just be displayed and scanned by another device (e.g. at an actual bricks-and-mortar store).

[ 165] The user could see a visual product offer somewhere and take a photo or scan the image with a mobile phone or similar device (e.g. a digital camera). An application on the mobile phone could be used to extract the purchase and payment order and send that to the user's Internet bank- ing application. Alternatively, the user could transfer the image or scan to their computer and then proceed with the drag and drop process.

[ 166] On the payment side the user could have a purchase and payment order sent or downloaded to their mobile phone via an Internet banking application on the phone or otherwise. An application on the phone could then produce a visual purchase and payment order and display that on the phone's screen for scanning by another device. GLOSSARY

Bank Identifier - any digital data that can be used by a bank to identify itself. Such data may include an identifier of a particular branch of the bank.

Bank Account Identifier - any digital data which can be used by a bank to identify a cus- tomer of that bank or an account which is operated by that bank.

Bank Source Data - data which is generated by the Source Bank for the purpose of including this in a Directed Cash token.

Bank Target Data - data which is generated by the Target Bank for the purpose of including this in a Directed Request token and subsequently in a Directed Cash token generated from the Directed Request token.

Deposit token - refers to the act of an entity (for example a merchant) transmitting a Directed Cash token to a Target Financial Institution.

Globally Unique Identifier - refers to a sequence of computer bits that with very high probability is determined to be unique within the context for which it is used. Merchant Data - data which is generated by a merchant or other party on behalf of a merchant for purpose of including this in a Directed Request token and subsequently all, some or none of which is included a Directed Cash token generated from the Directed Request token.

Redeem token - refers to the act of an entity (for example a customer) transmitting a Di- rected Cash token to either the Target Financial Institution or an authorised third party or an unauthorised third party. After which a new Directed Cash token will be generated which can then be deposited in the customer's bank or other bank as determined by the information stored in the Directed Cash token.

Redemption - refers to the act of the person (or entity) which "owns" a Directed Cash to- ken transmitting the said Directed Cash token either directly or indirectly (via a third party) to a to Target Financial Institution to transform the said Directed Cash token into a new Directed Cash token whose target is now an entity of the Source Financial Institution or other entity as determined by the encrypted information stored by the Source Bank in the original Directed Cash token. Redemption details - any identifier which can be used to locate a place to deposit a Directed Cash token with a view to exchanging said token with another Directed Cash token which will be used to transfer the funds back to the original Source Bank or to another bank. For example, a web address such as an URL or other physical address where an entity (for example a customer) can redeem their token. The details can be a website address which could be simply the target bank's website.

Source charges - refers to a Source Bank placing a charge on a customer for creating a Directed Cash token.

Source Bank - means the same as Source Financial Institution.

Source Bank Details - means the inclusion of a Bank Identifier for the Source Bank and optionally additional identification such as Bank Branch, Country, Region etc.

Source Bank Server - means a hardware system comprising one or more CPUs (computer Central Processing Units) and one or more storage devices operated by a Source Bank.

Source Financial Institution - the financial institution, for example a bank, from which the funds will be transferred from. Target Bank - means the same as Target Financial Institution.

Target Bank Details - means the inclusion of a Bank Identifier for the Target Bank and optionally additional identification such as Bank Branch, Country, Region etc.

Target Bank Server - means a hardware system comprising one or more CPUs (computer Central Processing Units) and one or more storage devices operated by a Target Bank. Target Charges - refers to a target bank placing a charge for using their bank to create a Directed Request token or provide assistance to create a Directed Request.

Target Financial Institution - the financial institution, for example a bank, to which the funds will be transferred or deposited to.

Token - a token (for the purposes of this documentation) consists of two parts. Part 1: some digital data (some, all, or none of which may be encrypted data, some, all, or no parts which may be digitally signed) arranged in some usable format. Part 2: a container in which the digital data of Part 1 resides. Some examples of tokens (data and their containers) are:

* An icon (image) which has associated data - the image provides a graphical representation of the container which may be a computer file stored on some sort of storage device.

* A two-dimensional barcode which can be placed on a billboard, magazine or other item - the item, page or billboard represents the container in this case. The barcode is the actual data token.

* A simple file on some electronic device (digital memory, hard drive) - the electronic device (such as a USB memory stick) represents the container, the file represents the data.

* Data on a magnetic strip or "smart chip" - the magnetic strip represents the container.

* Data sent via email as an attachment, or data sent via SMS on a mobile phone. Token Redemption - means the same as Redeem token.

URL - an acronym for Uniform Resource Locator that essentially is an address to a resource on the web.

Claims

Claims:

1. A method of encoding digital data comprising a block of computer memory , a file on a computer disk, or other electronic data stored on electronic devices, an image or other printed material such that, the encoded digital data when used as a funds transfer instrument is targeted to a specific Target Financial Institution, whose identity may not be determined from the encoded digital data, which when used as a funds transfer instrument is referred to as a directed cash token.

2. The method according to Claim 1 , whereby the Directed Cash Token is created with an expiration date, encrypted or unencrypted, after the elapse of which the Directed Cash Token is no longer valid.

3. The method according to Claim 2, whereby the expiration date can be determined either by the Target Bank or the Source Bank.

4. The method according to one of the preceding Claims, whereby the Directed Cash Token is created with additional encoded digital data which allows the Directed Cash Token to be exchanged across multiple currencies.

5. The method according to one of the preceding Claims, whereby the Directed Cash Token is created with additional encoded digital data which allows the Directed Cash Token to be redeemed immediately upon creation or at some later time.

6. A method of encoding data in particular according to one of the preceding Claims and comprising, a block of computer memory, a file on a computer disk, or other electronic data stored on electronic devices, an image or other printed material such that, the encoded digital data when used as a funds request instrument provides a method of transferring Target Bank Details to a Source Financial Institution for the purpose of the Source Financial Institution creating a Directed Cash Token for a specific Target Financial Institution, with this encoded data structure being referred to as a Directed Request Token.

7. The method according to Claim 6, whereby the Directed Request Token is created by an entity other than the Target Financial Institution.

8. The method according to one of the Claims 6 or 7, whereby the Directed Request Token is created by the Target Financial Institution.

9. The method according to one of the Claims 6 to 8, whereby the Target Bank's Bank Identifiers and Target Bank' s Bank Account Identifiers are transmitted to another entity for the purpose of that entity amalgamating the said Bank Identifiers and Bank Account Identifiers in a Directed Request Token.

10. The method according to one of the Claims 6 to 9, whereby product, services, bill payment details, special offers or other information are encoded digitally and amalgamated into a Directed Request Token.

1 1. The method according to one of the Claims 6 to 10, whereby the Directed Request Token is targeted to a specific product, bill or service.

12. The method according to one of the Claims 6 to 1 1 , whereby the Directed Request Token is encoded with Target Bank details to provide sufficient details to enable the Source Bank Server or other agency to identify the said Target Bank.

13. The method according to one of the Claims 6 to 12, whereby the Directed Request Token is encoded to provide sufficient details to enable the Source Bank Server or other agency to identify the entity or entities which have generated the Directed Request Token and or communicated the Directed Request Token.

14. A method of encoding digital data in particular according to one of the preceding claims comprising a block of computer memory, a file on a computer disk, other electronic data stored on electronic devices, an image or other printed material which when inserted within or amalgamated with the Directed Cash Token can be used to reverse funds transfer between financial institutions, without the necessity of completing the original funds transfer, this encoded digital data for the reverse funds transfer being referred to as a Redeem Token.

A system for performing a method according to one of the Claims 1 to 13 comprising a. a module that can communicate a Directed Request Token from one entity to a Source Bank Server, b. a module that allows the Source Bank Server to create a Directed Cash Token, c. a module that can communicate the generated Directed Cash Token back to the said entity from which it received the Directed Request Token, d. a module that can communicate the said Directed Cash Token received by the entity from the said Source Bank Server to the entity' s Target Bank Server, e. a module that allows the said entity's Target Bank Server to validate the received Directed Cash Token, f. a module that allows Target Bank Server to communicate with said entity and indicate success or failure of validation attempt, g. a module that allows Target Bank Server to transfer funds whose value is digitally encoded in the Directed Cash Token into said entity's bank account if Target Bank Server's validation attempt was successful.

A system according to Claim 15 and comprising a. a module that can communicate the Directed Request Token from one entity to a Source Bank's customer rather than the Source Bank, b. a module that allows the Source Bank's customer to communicate the Directed Request Token to the Source Bank to create a Directed Cash Token.

A system according to one of the Claims 15 or 16 comprising a. a module that can communicate the generated Directed Cash Token to the Source Bank's customer, b. a module that can communicate the said Directed Cash Token from the Source Bank^'s customer to the entity from which the Directed Request Token originated.

18. A system for performing a method according to Claim 14 comprising a. a module that can communicate a Directed Cash Token from Source Bank Server to an entity, b. a module that allows the entity to communicate the Directed Cash Token to Target Bank Server, c. a module that can use the Redeem Token encoded data embedded within the Directed Cash Token to allow a second Directed Cash Token to be generated by Target Bank Server, d. a module that can communicate the second generated Directed Cash Token from Target Bank Server to entity, e. a module that allows the said entity to communicate the second generated Directed Cash Token to Source Bank Server, f. a module that allows Source Bank Server to communicate with Source Bank customer and/or entity to indicate success or failure of validation attempt, g. a module that allows Source Bank Server to transfer funds whose value is digitally encoded in the second generated Directed Cash Token into said Source Bank customer's bank account if Source Bank Server's validation attempt was successful.

19. A system according to Claim 18 and comprising a. a module that can communicate a Directed Cash Token from Source Bank Server to Target Bank Server, b. a module that can use the Redeem Token encoded data embedded within the Directed Cash Token to allow a second Directed Cash Token to be generated by Target Bank Server, c. a module that can communicate the second generated Directed Cash Token from Target Bank Server to either Source Bank's customer or Source Bank Server or other entity, d. a module that allows Source Bank Server to communicate with Source Bank customer and indicate success or failure of validation attempt, e. a module that allows Source Bank Server to transfer funds whose value is digitally encoded in the second generated Directed Cash token into said Source Bank customer's bank account if Source Bank Server's validation attempt was successful.

A system according to one of the Claims 18 or 1 comprising a. a module that can communicate a Directed Cash Token from Source Bank Server to a third party for the purpose of redeeming the said Directed Cash Token generated by the Source Bank Server, the communication can take place immediately or after a period of time as long as this elapse of time does not invalidate the Directed Cash Token, b. a module that allows the third party to locate and identify the Target Bank either directly from the Directed Cash Token, or indirectly by querying potential Target Bank Servers or via some other means such as a predetermined arrangement between the third party and one or more Target Banks, c. a module that allows the third party to communicate the Directed Cash Token to the identified Target Bank Server, d. a module that can use the Redeem Token encoded data embedded within the Directed Cash Token to allow a second Directed Cash Token to be generated by Target Bank Server, e. a module that can communicate the second generated Directed Cash Token from Target Bank Server to the third party, f. a module that allows the said third party to communicate the second generated Directed Cash Token to Source Bank Server, g. a module that allows Source Bank Server to communicate with Source Bank customer and indicate success or failure of validation attempt, h. a module that allows Source Bank Sever to transfer funds whose value is digitally encoded in the second generated Directed Cash Token into said Source Bank customer' s bank account if Source bank Server's validation attempt was successful.

21 . A method for funds transfer in particular according to one of the Claims 1 to 14 comprising a. providing details of the funds transfer to an Internet banking application, and b. dragging and dropping a funds transfer instrument created by the Internet banking application from the Internet banking application to another application.

22. The method according to Claim 21 wherein details of the funds transfer are provided to the Internet banking application by dragging and dropping a request for funds from a source application to the Internet banking application, whereby the interaction required to consider the request for funds.

23. The method according to Claim 22 wherein options are provided that the user can set to change the contents of the request for funds and regenerate it whereby they can adjust what is private within the transaction with regards to the request for funds.

24. The method according to one of the Claims 22 or 23 wherein the request for funds is determined from a visual representation of the details of the request for funds.

25. The method according to one of the Claims 22 to 24 wherein options are provided that the user can set to change the contents of the funds transfer instrument before it is generated whereby the user can adjust what is private with regards to the funds transfer.

26. The method according to one of the Claims 22 to 25 wherein the funds transfer is a bill payment, and the request for funds is a bill and the funds transfer instrument is a bill payment instrument.

27. The method according to one of the Claims 22 to 27 wherein the funds transfer is a purchase, and the request for funds is an offer for sale and the funds transfer instrument is a purchase and payment instrument.

28. The method according to Claim 21 wherein the funds transfer is a bill payment.

29. The method according to Claim 21 wherein the funds transfer is a purchase.

30. A system to perform a method according to one of the claims 21 to 29 comprising a. computer memory that holds instructions and data in modules, b. graphics memory whose content determines what appears on the display, c. a CPU that follows instruction in the computer memory, stores and fetches data from and to the computer memory, and writes to graphics memory to make images appear on the display, d. a mouse or other pointing device that sends data to the CPU about button events and its relative motions along a 2D surface as controlled by the user, e. a computer network that allows the computer system to communicate with other server computers, in particular to send digital data to them and to receive digital data from them, f. an interface that allows the user to enter details about a funds transfer, bill payment, or purchase into the computer and transmits them to a system supporting the user's Internet banking, g. a module that displays a graphical representation of the item, that is the funds to be transferred, payment to be made, or purchase and payment to be made, received from the remote user's Internet banking server. h. a module that display a location that can accept the funds transfer, bill payment, or purchase and payment items and transmits the data to a remote server, i . a module that tracks the movement and button events of the pointing de- vice as the user drags and drops the item to the location that can accept the item, and visually represents this motion,

31. A system as in Claim 30 and comprising a. a module that receives a product offer, request for funds, or bill to pay, from a remote server for an online Internet store, b. a module that displays the product offer item on the screen by writing to the graphics memory of the computer, c. a module that displays a location that can accept the request for funds, bill to pay, or product offer and extract the relevant data, d. a module that tracks the movement and button events of the pointing de- vice as the user drags and drops the product offer to Internet banking site drop location, e. a module that can communicate the details of the product offer, request for funds, or bill to pay, to the remote Internet banking server,

32. A system as in Claim 31 and comprising an interface and module to enable the user to set various options regarding the product offer, bill to pay, or request for funds before dragging and dropping them.

33. A system as in Claim 30 and comprising an interface and module to enable the user to set various options regarding the funds transfer, bill payment, or purchase and payment order.