GB2415318A

GB2415318A - Electronic transfer of funds

Info

Publication number: GB2415318A
Application number: GB0413495A
Authority: GB
Inventors: Roger Salisbury Smith; Andrew Carl Johnson; Clement George Burford
Original assignee: CARDFREE Ltd
Current assignee: CARDFREE Ltd
Priority date: 2004-06-16
Filing date: 2004-06-16
Publication date: 2005-12-21
Also published as: GB0413495D0

Abstract

A computer or computer system which electronically receives incoming data packets and electronically transmits outgoing data packets via one or more networks to which the computer or system is connected so as to receive and transmit data packets; comprising: a receiver (10) which receives incoming data packets; a transmitter (18) which transmits outgoing data packets; an identifier (12) which identifies the type of each incoming data packet and which accepts for processing data packets of a first type (A), containing an identification of their origin, a reference code and an identification of an amount to be paid, and data packets of a second type (C, F), containing the said reference code and amount identification together with an indicator signifying whether or not the payment has been accepted; a memory (20) having stored therein a plurality of records; a recorder (14) which records as a record in the memory (20) at least the identification of origin and reference code from a data packet of the first type accepted by the identifier; a processor (16) which receives data packets from the identifier (12) and processes them using records from the memory (20) to form outgoing data packets and pass them to the transmitter (18) for transmission; with data packets of the first type being processed to form an outgoing data packet (B) with a content corresponding to the content of the received first type data packet for transmission to a bank identified from the records in the memory, and with data packets of the second type being processed to form an outgoing data packet (D) with a content corresponding to the content of the received second type data packet for transmission to the said origin as identified from the records in the memory (20).

Description

Electronic Transfer of Funds The present invention relates to the

electronic transfer of funds and is applicable generally as well as to the specific field of on-line payments.

Large financial institutions, especially the so-called Clearing Banks, have of-course been transferring funds electronically for many years. Necessarily there have been developed ever more sophisticated security measures to protect not only against fraudulent interference with such transfers but also to protect the privacy thereof, etc. More recently there has been a rapidly growing use of the Internet for on-line trading. The most often used method of payment for on-line trading is the use of credit/debit cards. This is very attractive to the customer; 24 hours a day seven days a week they can log-on, find the product they wish to purchase, enter their credit card details and complete the transaction there and then. However, fraudulent use of credit cards on-line is a substantial and serious problem. In an attempt to reduce this problem not only have on-line traders attempted to establish their own security measures but specialist agencies have been established to vet proposed online card payments.

Typically an on-line customer will select a product and indicate that payment is to be made by credit card; at that time electronically transmitting the credit card details to the on- line trader. As already noted, most online traders will have in place some form of security to protect the credit card information. Having received the credit card information the on-line trader electronically transmits the information, usually together with a note of the amount to be debited and the trader's own unique identifier for the transaction, to a specialist vetting agency. The specialist agency performs various security checks. For example, the credit card information is checked against a database of cards reported missing or stolen. Other checks are also made, such as comparing the recorded address of the credit card holder against a requested delivery address for the product being purchased. Recommended acceptance or refusal of the proposed credit card transaction is transmitted electronically back to the on-line trader (together with the unique identifier etc), who then accepts the customer's order or declines to do so, as appropriate. The whole process is completed while the customer is still logged on to the trader's web site, usually without any appreciable delay. Although the checking undertaken by the specialist agency is sophisticated, and no doubt constantly being improved upon, it is not foolproof and it is fact that with current systems some element of fraud will always prevail.

Further, the use of credit cards generally is of increasing concern; it being relatively easy even for people with low incomes to accumulate tens of thousands of pounds of debt by the use of credit cards.

Fraud and growing levels of debt are not the only problems, and of course debit cards and the like are used for on-line transactions as well as credit cards. In particular, even with debit card transactions there is still usually at least a three working day delay in the on-line trader actually receiving funds from the customer's account. Additionally, there is an on- going desire for a reduction in the fees incurred by the trader in accepting on-line payments (including the fees charged by credit card companies and specialist vetting agencies).

Some of the above mentioned problems are not unique to online payments; made via the Internet or otherwise. For example, many if not most employees are currently paid their salary by their employer, each month, initiating an electronic transfer of funds from the employer's bank account to the respective employee's bank account. The 'at least three days' delay is incurred (with weekends and Bank Holidays causing problems) and again there is a desire for a reduction of fees and time.

Against this background, the present invention has been made with a view to providing technical means for the electronic transfer of funds so as to mitigate one or more of the above mention problems.

Thus, in a first aspect the present invention provides a computer or computer system which electronically receives incoming data packets and electronically transmits outgoing data packets via one or more networks to which the computer or system is connected so as to receive and transmit data packets; comprising: a receiver which receives incoming data packets; a transmitter which transmits outgoing data packets; an identifier which identifies the type of each incoming data packet and which accepts for processing data packets of a first type, containing an identification of their origin, a reference code and an identification of an amount to be paid, and data packets of a second type, containing the said reference code and amount identification together with an indicator signifying whether or not the payment has been accepted; a memory having stored therein a plurality of records; a recorder which records as a record in the memory at least the identification of origin and reference code from a data packet of the first type accepted by the identifier; a processor which receives data packets from the identifier and processes them using records from the memory to form outgoing data packets and pass them to the transmitter for transmission; with data packets of the first type being processed to form an outgoing data packet with a content corresponding to the content of the received first type data packet for transmission to a bank identified from the records in the memory, and with data packets of the second type being processed to form an outgoing data packet with a content corresponding to the content of the received second type data packet for transmission to the said origin as identified from the records in the memory.

From the above it will be appreciated that whereas conventionally the electronic transfer of funds has been subject to the continual addition of further levels of security, the present invention can be seen as being predicated on the concept of actually removing at least one level of security. For example, in relation to the processing of on-line payments: instead of introducing the overhead of a specialist card vetting agency the present invention enables use to be made of the, generally more sophisticated and insured, security systems of the account holding banks.

The present invention enables credit card transactions to be avoided, thus helping to avoid increased levels of debt.

The present invention enables the same day transfer of funds between two parties (e.g. customers and on-line traders, or an employer and an employee) who do not have accounts with the same bank; without requiring any change in existing banking procedures. The conventional delay problem can thus be mitigated. Further, with the present invention a reduction in costs can readily be envisaged.

Embodiments of the present invention will now be described by way of further example only and with reference to the accompanying drawings; in which: Figure 1 illustrates a first web page as seen when using a first embodiment of the present invention; Figure 2 illustrates a second web page as seen when using the first embodiment; Figure 3 illustrates a third web page, and a variation thereof, as seen when using the first embodiment; Figure 4 illustrates a fourth web page as seen when using the first embodiment; Figure 5 illustrates a fifth web page as seen when using the first embodiment; Figure 6 illustrates the electronic transfer of data according to the first embodiment; Figures 7 A to F illustrate data packets transmitted as shown in figure 6; Figure 8 is an outline block diagram of one of the components shown in figure 6.

Figure 9 illustrates the electronic transfer of data according to a second embodiment; Figure 10 illustrates a web page as seen when using the second embodiment; Figures 11 G to K illustrate data packets transmitted as shown in figure 9; and Figure 12 illustrates the electronic transfer of data according to a third embodiment.

A first, and preferred, embodiment of the invention will be described with reference to an implementation of the invention for the processing of on-line payments; first essentially in terms of the effects of the invention and then in terms of the technical implementation which provides those effects.

As at present, and probably as part of a product selection process, a customer logs-on to a trader's web site and locates the product or products (or service) which they wish to purchase; followed by clicking a button to indicate that payment is to be made - for example, on a web page of the type illustrated in figure 1. Conventionally the customer is directed to a credit card payment page or the like; on which details of the credit card or the like are entered.

In contrast, with the present invention the customer is presented with a page which includes the logo and/or name of all of the major banks - such as the web page illustrated in figure 2.

The customer is invited to click on the logo/name of the bank which holds the account from which the customer requires payment to be made. The customer is then taken electronically to a log-in screen for that bank such as the web page illustrated in figure 3. The log-in screen presents the standard log-in verification procedures of the bank; as used for the conventional on-line banking now used by many people. Having complied with the bank's security verification the customer is then simply requested to click a button to confirm the transaction, details of which are displayed to the customer at that time - such as by the web page illustrated in figure 4. Thereafter the customer is directly returned to a page on the trader's web site which re-confirms that the transaction has been completed and that the product(s) will be dispatched accordingly- such as by the web page illustrated in figure 5. Of course, if the bank considers that the account contains insufficient funds an appropriate message will be displayed to the customer and the transaction declined.

Without the customer necessarily being aware of the detail, the above described transaction will have been processed as follows. When the payment button is clicked (figure 1) an application program associated with the trader's web site prepares a data packet which includes: details of the trader, a unique identifier by which the trader records the transaction, and the amount of the payment required. Details of the transaction are recorded in a transactions database maintained in association with the trader's web site. The data packet is transmitted and the customer linked, via the Internet, to the web site of an independent payment organization. The independent payment organization presents the web page illustrated in figure 2. When the customer clicks the logo of one of the banks, an application program associated with the web site of the independent payment organization supplements the data packet with further information and records the data packet in a database. The s supplemented data packet is transmitted and the customer linked, via the Internet, to a special log-in page at the web site of the selected bank (figure 3). As described above, the log-in page takes the customer through the standard security verification procedures of the bank.

The web page is special in that it processes the supplemented data package so as to pre-fill the subsequently displayed page, namely the page as illustrated in figure 4. When the customer clicks the button to confirm the payment, an application program associated with the bank's web page appends a payment approved (or not approved, as the case may be) flag to the data packet and transmits the data packet, with flag, to the web site of the independent payment organisation. The web site of the payment organisation records the data packet, including the flag, and retransmits the data packet to the trader's web site. The data packet and the customer arrive simultaneously (at least as perceived by the customer) back at the traders web site, where the data packet with flag triggers an application program which displays the web page shown in figure 5 and records the data packet, including the flag, in the said database associated with the trader's web site.

In terms of the transfer of funds, the payment has been made in the following manner.

Funds have been transferred from the customer's bank account to a bank account, with the same bank, in the name of the independent payment organisation (a receipts account). Funds have been transferred from a bank account in the name of the independent payment organisation (a payments account) to the bank account of the trader. The payments account is selected to be an account, in the name of the independent payment organisation, held at the same bank as that which holds the trader's bank account. That is, the independent payment organisation holds at least one bank account with all banks (that is, all of the banks listed on the web page illustrated in figure 2). Thus, because the transfer from the customer to the independent payment organisation is between accounts held by the same bank - even according to conventional banking arrangements the transfer takes place on a 'same day' basis. Similarly, because the transfer from the independent payment organisation to the trader is between accounts held by the same bank (which, for a high percentage of cases, will not be the same as the customer's bank) - even according to conventional banking arrangements - the transfer takes place on a 'same day' basis. The traditional 'three working days' delay can obviously be avoided according to the present invention. Moreover, the problem of fraud can be mitigated to a significant extent; because a complete customer-to-trader transaction takes place effectively simultaneously (compared with the long wait to be paid and potential claw back from credit card companies) and use is made of the bank's security verification rather than using, for example, a specialist credit card vetting agency. The transactions do not involve the use of credit cards, which helps to mitigate the general problem of growth of debt.

Essentially the effects of the first embodiment of the invention have been described above. Now the technical implementation which provides those effects will be described.

Figure 6 illustrates, in broad outline, the electronic transfer of data according to the first embodiment. That is, figure 6 depicts what can be considered as various computers, web sites and the data flow there between. The data flow, in this embodiment, takes place across the Internet. For simplicity figure 6 indicates direct transfers between the different computers and web sites, and omits the detail of the actual data transmission paths which would be involved between the computers which make up the Internet. Connected to the Intemet are the web sites of various banks (Bank 1 to Bank n in figure 6), the web sites of various online traders (Trader 1 to Trader t in figure 6) and th'e web site of the independent payment organization. Customers (Customer 1 to Customer x in figure 6) log-on to the Internet and locate the trader which has for sale the product they wish to purchase. As described above, the customer clicks the 'pay' button as shown in figure 1 and this initiates an application program which records the transaction in the trader's database and which prepares and transmits a data packet to the web site of the payment organization. The data packet and it's transmission is indicated in figure 6 by reference (A) and the content of the data packet is shown in figure 7A. The data packet (A) has four fields. The first field, label 'T', identifies the data packet as one sent by a trader. The second field, label 'T.ID', contains a code which uniquely identifies the trader (trader t in figure 6). The third field, label 'Trans.No.', is a transaction number allocated by the trader and which uniquely identifies, for the trader, the details of the transaction with the customer. The fourth field, label 'Amt', records the amount of the payment required. Of course, the first three fields could be concatenated to form a single field containing one code, provided that the code unambiguously fulfils the described

function of each of the three fields.

The data packet, (A), from the trader is received by the web site of the independent payment organization. The processing carried out by the payment organization web site is illustrated in outline form by the block diagram of figure 8. The incoming data packet is passed from a receiving unit 10 to an identification unit 12. The identification unit 12 determines from the content of the first field that the data packet has been sent by a trader.

Consequently the data packet is passed to a recorder 14 and to a processor 16. The processor 16 performs a number of operations. Firstly the processor 16 displays to the customer, now linked-in via the trader's web site, the web page shown in figure 2. When the customer clicks on one of the bank logos (in figure 6, that of Bank n) the processor 16 prepares an outgoing data packet and sends it to a transmitter 18 to be transmitted to the selected bank (Bank n). At the same time, the recorder stores a copy of data packet (A) together with a note of the bank selected. The outgoing data packet and it's transmission path are indicated in figure 6 by reference (B) and the content of data packet (B) is illustrated in figure 7B. Data packet (B) is prepared from data packet (A) using records stored in a database associated with the payment organization web site. The database is indicated by reference 20 in figure 8. Processor 16 uses the trader ID from field 2 of data packet (A) to obtain the trader's name from database 20 and uses that name to form the first field of data packet (B). The second, third and fourth fields of data packet (B) are simply copies of the respective fields from data packet (A). It will be apparent that the just described processing could be avoided if the trader's name were included, by the trader, when data packet (A) was first prepared and that the name could replace both of the previously described first and second fields of data packet (A). However, the described and illustrated preferred form is useful as it enables additional processing, such as security checks, to be undertaken at various stages.

Data packet (B) is received by Bank n and the web page of figure 3A displayed to the customer, who has now been linked-in to the bank's web site. As described above, the customer is taken through the bank's normal on-line banking security verification process and at some stage (by clicking the 'Cardless Co.' button, according to figure 3A) the input is identified as coming from or being associated with the independent payment organisation.

This identification is used to take the customer to the pre-filled web page illustrated in figure 4. It is of course equally possible for an application program on the bank's web site to identify automatically that the data packet, (B), has been received from the independent payment organization, Cardless Co., (perhaps entailing the inclusion of a further identifier or flag in data packet B) and thus eliminate the need for the 'Cardless Co.' button shown in figure 3A. Another alternative is for the connection to be made to a separate URL established by the Bank for connections from the payment organization. In this case the 'Cardless Co.' button shown in figure 3A is not required and the web page will be as illustrated in figure 3B.

As will be appreciated from figures 4 and 7B, the content of the first and last fields of data packet (B) are respectively used to present the traders name in the 'Pay' box and the payment amount in the 'Amount' box of the pre-filled web page. If the customer has only one appropriate account (current account) with Bank n then the account number displayed in the 'From account' box can be pre-filled automatically, otherwise the customer may need to select an account for example from a pull-down list of accounts. When the customer clicks the 'OK' button, the bank processes the transaction and sends a data packet back to the web site of the independent payment organization. This data packet and it's transmission path are indicated in figure 6 by reference (C) and the content of the data packet is illustrated in figure 7C.

When the 'OK' button has been clicked, Bank n transfers the agreed amount from the customer account (123456) to the account, at Bank n, of the independent payment organization (Cardless Co.). Since the pre-filled page is only displayed when the transaction has been identified as being associated with the independent payment organization, the account number of the organization for receipt of the funds is readily known to the bank.

Alternatively, the relevant account number could be stored in database 20 and included in data packet (B).

According to the particular rules and priocedures of Bank n, it may well be that the display of the web page illustrated in figure 4 is varied somewhat. For example the pre-filled message may read something like "pay Cardless Co. the amount of 400. DO for the benefit t of ABC Trader Ltd".

The data packet, (C), sent by the bank back to the payment organization can be, as illustrated in figure 7C, simply data packet (B) supplemented with a Y/N flag which is set to indicate whether the payment has been made (flag set to 'Y') or declined (flag set to 'N').

Variation in the content of data packet (C) is readily envisaged, for example the 'T.Name'

field could be omitted.

Data packet (C) is received by the receiving unit 10 at the payment organisation's web site and passed to the identification unit 12. The identification unit 12 detects the presence of the Y/N flag and thus identifies the data packet as having been received from a bank. In practice it is expected that a more sophisticated verification would be employed, but such is readily envisaged and implemented. For example, bank identifying and security verification

fields can be added to data packet (C).

Having been identified as having been received from a bank, data packet (C) is passed to recorder 14 and processor 16. Recorder 14 uses the 'T. ID' and 'Trans.No.' fields to locate the corresponding entry in memory 20 and updates that entry with the Y/N flag. Processor 16 uses the 'T.ID' field to instruct the transmitter 18 to send a data packet (D) to the web site of the trader, Trader t; perhaps after having verified that the 'Amt' field of data packet (C) matches that of the stored copy of data packet (A). The data packet (D) and it's transmission path are indicated in figure 6 by reference (D) and the content thereof is illustrated in figure 7D. As indicated in figure 7D, data packet (D) includes the Y/N flag, the 'Trans.No.' field

and (optionally) the 'Amt' field.

Data packet (D) and the customer arrive simultaneously (at least as perceived by the customer) back at the trader's web site. The trader's web site is provided with means for receiving and scanning incoming data packets, thus being able to identify data packets of the kind illustrated in figure 7D. Identification of such a data packet triggers an application program which, if the flag is set to "Y", displays the web page shown in figure 5 and records the data packet, including the flag, in the said database associated with the trader's web site.

The content of the "Trans.No." and "Amt" fields are used to verify the transaction before the figure 5 web page is displayed.

Back at the web site of the independent payment organization, further actions are performed by processor 16 after it has sent data packet (D) to be transmitted to the trader's web site. In particular, processor 16 uses the content of the "T. ID" field from data packet (C) and/or (B) stored in memory 20 to access a database, D1, to obtain the trader's full name and, more importantly, the sort code and account number for the trader's bank. The processor uses the trader's sort code to access another database, D2, so as to obtain the account number of the payment organization with the bank identified by that sort code. With this information processor 16 assembles a data packet (E), which has the form illustrated in figure 7E, and instructs the transmitter 18 to transmit the data packet to the bank (Bank 2 in figure 6) identified by the sort code. Transmission of the data packet (E) is identified by reference (E) in figure 6. Databases D1 and D2 may form part of memory 20, or may be separate therefrom.

As illustrated in figure 7E, the first field in data packet (E) is labelled "P.O.Acct.No." and this field stores the account number of the independent payment organization with Bank 2. The next field, labelled "T.Name" contains the full name of the trader (Trader t) and the third field, labelled "T.Act.No.", contains the account number of Trader t with Bank 2. The fourth field, labelled "Trans. No." contains the unique transaction number originally allocated by the trader. The final field, labelled "Amt", contains the amount of the customer's purchase - which is now the amount to be transferred from the independent payment organization to the trader. Upon receipt of data packet (E), the web site of Bank 2 carries out a transfer of funds between the two bank accounts in accordance with the content of the data packet; i.e. from the account identified by "P.O.Act.No." pay the company identified "T.Name" in to the account identified by "T.Act.No." under the reference identified by "Trans.No." the amount identified by "Arnt". Preferably an acknowledgement that the transaction has been completed is sent by the bank back to the payment organization. The acknowledgement may be in the form of data packet (F) illustrated in figure 7F, with it's transmission path indicated in figure 6 by reference (F).

At the web site of the independent payment organization data packet (F) is received by receiver 10 and passed to identifier 12. Identifier 12 verifies the data packet as having the form illustrated in figure 7F, thus identifying it as being an acknowledgement from a bank of a transfer made to a trader's account. Identifier 12 thus passes data packet (F) to recorder 14 which records the data packet in memory 20 and thereby completes the payment organisation's record of the full transaction from the trader and the banks.

A description is given above of the trader's web site preparing and transmitting data packet (A) and receiving and processing data packet (D). The technical means for performing the tasks can be arranged on essentially the same basis as shown in figure 8 in relation to the payment organisation's web site. That is, the trader's web site has a receiver 10 which on the pay button (Fig. 1) being clicked, receives information provided by the customer. This information will be the customer's name and address and details of the product(s) selected for purchase. The identifier 12 identifies the information from the receiver as being a new purchase order and passes the information to the processor 16. At the same time the information is sent to the recorder 14 to be stored in the memory 20. The processor 16 generates the unique transaction number and ensures that this is stored in the memory 20 together with the other information. Processor 16 then assembles data packet (A), commencing with the trader identifier "T", followed by the trader's ID, the unique transaction number and the total amount of the purchase (as illustrated in figure 7A). Data packet (A) is then passed by processor 16 to transmitter 18 for transmission to the web site of the independent payment organization. Similarly, the incoming data packet (D) is received by the receiver 10 and passed to the identifier 12 where it is identified as a data packet of the kind illustrated in figure 7D. Identifier 12 passes data packet (D) to recorder 14 and to processor 16. Recorder 14 records data packet (D) in memory 20. Processor 16 checks whether or not the content of the "YIN" field (Figure 7D) is set to "Y". Processor 16 also verifies the contentof the "Trans.No." and "Amt" fields against the corresponding fields in the copy of data packet (A) stored in memory 20. If the verification is positive and the flag is set to "Y" then processor 16 causes the web page shown in figure 5 to be displayed.

A description is given above of the various actions performed by the web sites of the banks. These actions can be performed by an arrangement of a type similar to that illustrated in figure 8. In relation to a bank receiving a data packet (B), such as Bank n in figure 6, the arrangement would be as follows. Receiver 10 receives the data packet and passes it to identifier 12. Identifier 12 verifies that the data packet has the form illustrated in figure 7B, thus identifying the data packet as one sent by the independent payment organisation in relation to a transfer of funds to be authorised by a customer. Data packet (B) is thus passed by the identifier 12 to a recorder 14 which records the content of the data packet in a memory 20, for future reference by the bank, if required. The data packet is also passed to a processor 16. Processor 16 uses the content of the data packet to pre-fill the web page (figure 4) on which the customer authorises the payment to be made to the payment organisation.

Subsequently, processor 16 prepares data packet (C) and passes it to a transmitter 18 for transmission to the web site of the independent payment organisation. In relation to a bank receiving data packet (E), such as Bank 2 in figure 6, the arrangement would be as follows.

Receiver 10 receives the data packet and passes'it to identifier 12. Identifier 12 verifies that the data packet has the form illustrated in figure 7E, thus identifying the data packet as one sent by the independent payment organisation in relation to a transfer of funds to be made to the account of a trader. Data packet (E) is thus passed by the identifier 12 to a recorder 14 which records the content of the data packet in a memory 20, for future reference by the bank, if required. The data packet is also passed to a processor 16. Processor 16 uses the content of the data packet to carry out the transfer of funds from the account of the payment organisation to the account of the trader. Subsequently, processor 16 prepares data packet (F) and passes it to a transmitter 18 for transmission to the web site of the independent payment organisation.

It is apparent from the above that the required functions can be carried out at the respective web sites of the traders, the banks and the independent payment organisation with a system as illustrated in figure 8. Such a system can be described as a computer or computer system which electronically receives incoming data packets and electronically transmits outgoing data packets via one or more networks to which the computer or system is connected so as to receive and transmit data packets; comprising: a receiver which receives incoming data packets; a transmitter which transmits outgoing data packets; an identifier which identifies the type of each incoming data packet and which accepts for processing data packets of a first type and data packets of a second type; a memory having stored therein a plurality of records; a recorder which records as a record in the memory at least the identification of origin and reference code from a data packet of the first type accepted by the identifier; a processor which receives data packets from the identifier and processes them using records from the memory to form outgoing data packets which are passed to the transmitter for transmission. In the system as implemented at any of the traders web sites the first type of data packet is that containing the customer information as described above (not illustrated) and the second type of data packet is one having the form illustrated in figure 7D.

The system as implemented at the web site of the independent payment organisation is distinguished by the first and second data packets having the form illustrated respectively in figures 7A and 7C and also by the identifier 12 accepting data packets of a third type namely those of the form illustrated in figure 7F. In the above described first embodiment of the invention; in the system as implemented at the web site of any of the banks the first and second data packets have the form illustrated respectively in figures 7B and 7E. In the system as implemented at any of the traders web sites the processor forms outgoing data packets having the form illustrated in figure 7A. In the system as implemented at the web site of the independent payment organisation the processor forms outgoing data packets having the forms illustrated in figures 7B, 7D and 7E. In the system as implemented at any of the banks web sites the processor forms outgoing data packets having the forms illustrated in figures 7C and 7F.

A second embodiment of the invention will now be described, with reference to figures 9 to 11 of the accompanying drawings; first essentially in terms of the effects of the invention and then in terms of the technical implementation which provides those effects. In this embodiment the electronic transfer of funds is for the purpose of an employer paying the regular salary to each member of staff.

An employer logs on to the web site of the independent payment organization and is presented with a page which includes the logo and/or name of all of the major banks - such as the web page illustrated in figure 2. The employer is invited to click on the logo/name of the bank which holds the account from which the employer requires payment to be made. The employer is then taken electronically to a log-in screen for that bank - such as the web page illustrated in figure 3. The log-in screen presents the standard log-in verification procedures of the bank; as used for the conventional on-line banking now used by many people. Having complied with the bank's security verification the employer is then simply requested to click a button to confirm the transaction, details of which are displayed to the employer at that time - such as by the web page illustrated in figure 10. The transaction is confirmed and the employer logs-out. Confirmation of the transfer is sent by the bank to the independent payment organization. Of course, if the bank considers that the account contains insufficient funds an appropriate message will be displayed to the employer and the transaction declined.

The above described transaction will have been processed as follows. When the employer logs-on to the web site of the independent payment organization, the employer's web site transmits a pre-prepared data packet which contains the details of the payments to be made to the members of staff. The data packet includes: details of the employer, a unique identifier by which the employer records the transaction, and the details of the salary payments to be made. Upon recognition of the data packet, the independent payment organisation presents the web page illustrated in figure 2. When the employer clicks the logo of one of the banks, an application program associated with the web site of the independent payment organisation supplements the data packet with further information and records the data packet in a database. The supplemented data packet is transmitted and the employer linked, via the Internet, to a special log-in page at the web site of the selected bank (figure 3).

As described above, the log-in page takes the employer through the standard security verification procedures of the bank. The web page is special in that it processes the supplemented data package so as to prefill the subsequently displayed page, namely the page as illustrated in figure 10. When the employer clicks the button to confirm the payment, an application program associated with the bank's web page appends a payment approved (or not approved, as the case may be) flag to the data packet and transmits the data packet, with flag, to the web site of the independent payment organisation. The web site of the payment organisation records the data packet, including the flag, and retransmits the data packet to the employer's web site so as to confirm the transaction as complete.

Funds have been transferred from the employer's bank account to a bank account, with the same bank, in the name of the independent payment organisation (a receipts account). Funds have been transferred from various bank accounts in the name of the independent payment organisation (payments accounts) to the bank account of each of the employees. In each case, the payments account is selected to be an account, in the name of the independent payment organisation, held at the same bank as that which holds the relevant employee's bank account.

That is, the independent payment organisation holds at least one bank account with all banks (that is, all of the banks used by any of the employees as well as the bank used by the employer). Thus, because the transfer from the employer to the independent payment organisation is between accounts held by the same bank - even according to conventional banking arrangements - the transfer takes place on a 'same day' basis. Similarly, because the transfer from the independent payment organisation to each employee is between accounts held by the same bank (which, for a high percentage of cases, will not be the same as the employer's bank) even according to conventional banking arrangements - the transfer takes place on a 'same day' basis. The traditional 'three working days' delay can obviously be avoided according to the present invention.

Essentially the effects of the second embodiment of the invention have been described above. Now the technical implementation which provides those effects will be described.

Figure 9 illustrates, in broad outline, the electronic transfer of data according to the second embodiment. That is, figure 9 depicts what can be considered as various computers, web sites and the data flow there between. The data flow, in this embodiment, takes place across the Internet. For simplicity figure 9 indicates direct transfers between the different computers and web sites, and omits the detail of the actual data transmission paths which would be involved between the computers which make up the Internet. Connected to the Internet are the web sites of various banks (Bank 1 to Bank n in figure 9), the web sites of various employers (Employer 1 to Employer m in figure 9) and the web site of the independent payment organization. An employer, 'Employer m' in figure 9, logs on to the web site of the independent payment organization and transmits a data packet to the web site of the payment organization. The data packet and it's transmission is indicated in figure 9 by reference (G) and the content of the data packet is shown in figure 1 1 G. The data packet (G) has three header fields followed by a number of employee data fields. The first field, label E.ID', identifies the data packet as one sent by an employer and contains a code which uniquely identifies the employer (Employer m in figure 9). The second field, label Trans.No.', is a transaction number allocated by the employer and which uniquely identifies, for the employer, the details of the payments to be made. The third field, label 'Total', records the batch total amount of the payments to be made. The subsequent fields are grouped in fours, each group relating to a particular employee. The first group has a first field, label 'El.Name', which contains the name of an employee. The second field, label E1.Sort', contains the sort code of the employee's bank. The third field, label 'El.Act', contains the employee's bank account number. The fourth field, label 'Amt', records the amount of the payment (net salary) to be paid to the employee. Subsequent groups have essentially the same structure, but with the labels becoming E2, E3 etc for the second, third etc employees. That is, there are as many groups in the data packet as there are employees to be paid.

The data packet, (G), from the employer is received by the web site of the independent payment organization. The processing carried out by the payment organization web site is illustrated in outline form by the block diagram of figure 8. The incoming data packet is passed from a receiving unit 10 to an identification unit 12. The identification unit 12 determines from the content of the first field that the data packet has been sent by an employer. Consequently the data packet is passed to a recorder 14 and to a processor 16. The processor 16 performs a number of operations. Firstly the processor 16 displays to the employer the web page shown in figure 2. When the employer clicks on one of the bank logos (in figure 9, that of Bank n) the processor 16 prepares an outgoing data packet and sends it to a transmitter 18 to be transmitted to the selected bank (Bank n). At the same time, the recorder stores a copy of data packet (G) together with a note of the bank selected. The outgoing data packet and it's transmission path are indicated in figure 9 by reference (H) and the content of data packet (H) is illustrated in figure 11H. Data packet (H) is prepared from data packet (G) using records stored in a database associated with the payment organization web site. The database is indicated by reference 20 in figure 8. Processor 16 uses the employer ID from field 1 of data packet (G) to2obtain the employer's name from database 20 and uses that name to form the first field of data packet (H). The second, third and subsequent fields of data packet (H) are simply copies of the first and subsequent fields from data packet (G). It will be apparent that the just described processing could be avoided if the employer's name were included, by the employer, when data packet (G) was first prepared and that the name could replace the previously described first field of data packet (G).

However, the described and illustrated preferred form is useful as it enables additional processing, such as security checks, to be undertaken at various stages.

Data packet (H) is received by Bank n and the web page of figure 3 displayed to the employer, who has now been linked-in to the bank's web site. As described above, the employer is taken through the bank's normal on-line banking security verification process and at some stage (by clicking the 'Cardless Co.' button, according to figure 3) the input is identified as coming from or being associated with the independent payment organization.

This identification is used to take the employer to the pre-filled web page illustrated in figure 10. It is of course equally possible for an application program on the bank's web site to identify automatically that the data packet, (H), has been received from the independent payment organization, Cardless Co., (perhaps entailing the inclusion of a further identifier or flag in data packet H) and thus eliminate the need for the 'Cardless Co.' button shown in figure 3.

As will be appreciated from figures 10 and 11H: the name of the independent payment organization, 'Cardless Co.', appears automatically in the 'Pay' box and the content of the fourth field of data packet (H) is used to present the batch total payment amount in the Amount' box of the pre-filled web page. Further, the groups are used to pre-fill the list of ultimate beneficiaries. If the employer has only one appropriate account (current account) with Bank n then the account number displayed in the 'From account' box can be pre-filled automatically, otherwise the employer may need to select an account for example from a pull- down list of accounts. When the employer clicks the 'OK' button, the bank processes the transaction and sends a data packet back to the web site of the independent payment organization. This data packet and it's transmission path are indicated in figure 9 by reference (I) and the content of the data packet is illustrated in figure 111.

When the 'OK' button has been clicked, Bank n transfers the agreed amount from the employer account (654321) to the account, at Bank n, of the independent payment organization (Cardless Co.). Since the pre-filled page is only displayed when the transaction has been identified as being associated with the independent payment organization, the account number of the organization for receipt of the funds is readily known to the bank.

Alternatively, the relevant account number could be stored in database 20 and included in data packet (H).

The data packet, (I), sent by the bank back to the payment organization can be, as illustrated in figure 111, simply the second, third and fourth fields of data packet (H) preceded by a Y/N flag which is set to indicate whether the payment has been made (flag set to 'Y') or declined (flag set to 'N'). Variation in the content of data packet (I) is readily envisaged, for example it could include all of the employee field groups.

Data packet (I) is received by the receiving unit 10 at the payment organisation's web site and passed to the identification unit 12. The identification unit 12 detects the presence of the Y/N flag and thus identifies the data packet as having been received from a bank. In practice it is expected that a more sophisticated verification would be employed, but such is readily envisaged and implemented. For example, bank identifying and security verification

fields can be added to data packet (I).

Having been identified as having been received from a bank, data packet (I) is passed to recorder 14 and processor 16. Recorder 14 uses the 'E. ID' and 'Trans.No.' fields to locate the corresponding entry in store 20 and updates that entry with the Y/N flag. Processor 16 verifies that the 'Total' field of data packet (I) matches that of the stored copy of data packet (I).

Further actions are performed by processor 16. In particular, processor 16 uses the content of each group of employee fields to effect, in turn, the respective payment to each employee. For the sake of avoiding repetition, the processing of only one such payment will now be described. The processor uses the employee's sort code to access a database, D3, so as to obtain the account number of the payment organisation with the bank identified by that sort code. With this information processor 16 assembles a data packet (I), which has the form illustrated in figure 11J, and instructs the transmitter 18 to transmit the data packet to the bank (Bank 3 in figure 9) identified by the sort code. Transmission of the data packet (J) is identified by reference (I) in figure 9. Database D3 may form part of memory 20, or may be separate therefrom.

As illustrated in figure 11J, the first field in data packet (J) is labelled "P.O.Act.No." and this field stores the account number of the independent payment organisation with Bank 3. The next field, labelled "E l.Name" contains the full name of the employee and the third field, labelled "El.Act.No.", contains the account number of employee with Bank 3. The fourth field, labelled "Trans.No." contains the unique transaction number originally allocated by the employer. The final field, labelled "El.Amt", contains the amount of the salary to be paid to the employee which is now the amount to be transferred from the independent payment organisation to the employee. Upon receipt of data packet (I), the web site of Bank 3 carries out a transfer of funds between the two bank accounts in accordance with the content of the data packet; i.e. from the account identified by "P.O.Act.No." pay the person identified "El.Name" in to the account identified by "El.Act.No." the amount identified by "El.Arnt".

Preferably an acknowledgement that the transaction has been completed is sent by the bank back to the payment organization. The acknowledgement may be in the form of data packet (K) illustrated in figure 11K, with it's transmission path indicated in figure 9 by reference (K).

At the web site of the independent payment organization data packet (K) is received by receiver 10 and passed to identifier 12. Identifier 12 verifies the data packet as having the form illustrated in figure 11K, thus identifying it as being an acknowledgement from a bank of a transfer made to an employee's account. Identifier 12 thus passes data packet (K) to recorder 14 which records the data packet in memory 20 and thereby completes the payment organisation's record of the full transaction from the employer to the employee.

A description is given above of the employer's web site preparing and transmitting data packet (G) and receiving and processing data packet (D). The technical means for performing the task is straight forward and will be readily understood by persons skilled in the art, particularly having read the foregoing description.

A description is given above of the various actions performed by the web sites of the banks. These actions can be performed by an arrangement of a type similar to that illustrated in figure 8. In relation to a bank receiving a data packet (H), such as Bank n in figure 9, the arrangement would be as follows. Receiver 10 receives the data packet and passes it to identifier 12. Identifier 12 verifies that the data packet has the form illustrated in figure 11H, thus identifying the data packet as one sent by the independent payment organisation in relation to a transfer of funds to be authorised by an employer. Data packet (H) is thus passed by the identifier 12 to a recorder 14 which records the content of the data packet in a memory 20, for future reference by the bank, if required. The data packet is also passed to a processor 16. Processor 16 uses the content of the data packet to prebill the web page (figure 10) on which the employer authorises the payment to be made to the payment organisation.

Subsequently, processor 16 prepares data packet (I) and passes it to a transmitter 18 for transmission to the web site of the independent payment organisation. In relation to a bank receiving data packet (J), such as Bank 3 in figure 9, the arrangement would be as follows.

Receiver 10 receives the data packet and passes it to identifier 12. Identifier 12 verifies that the data packet has the form illustrated in figure 11J, thus identifying the data packet as one sent by the independent payment organisation in relation to a transfer of funds to be made to the account of an employee. Data packet (I) is thus passed by the identifier 12 to a recorder 14 which records the content of the data packet in a memory 20, for future reference by the bank, if required. The data packet is also passed to a processor 16. Processor 16 uses the content of the data packet to carry out the transfer of funds from the account of the payment organisation to the account of the employee. Subsequently, processor 16 prepares data packet (K) and passes it to a transmitter 18 for transmission to the web site of the independent payment organisation.

It is apparent from the above that the required functions can be carried out at the respective web sites of the banks and the independent payment organisation with a system as illustrated in figure 8. Such a system can be described as a computer or computer system which electronically receives incoming data packets and electronically transmits outgoing data packets via one or more networks to which the computer or system is connected so as to receive and transmit data packets; comprising: a receiver which receives incoming data packets; a transmitter which transmits outgoing data packets; an identifier which identifies the type of each incoming data packet and which accepts for processing data packets of a first type and data packets of a second type; a memory having stored therein a plurality of records; a recorder which records as a record in the memory at least the identification of origin and reference code from a data packet of the first type accepted by the identifier; a processor which receives data packets from the identifier and processes them using records from the memory to form outgoing data packets which are passed to the transmitter for transmission.

The system as implemented at the web site of the independent payment organisation is distinguished by the first and second data packets having the form illustrated respectively in figures 1 1 G and 1 1 I and also by the identifier 12 accepting data packets of a third type namely those of the form illustrated in figure 11K. In the above described second embodiment of the invention; in the system as implemented at the web site of any of the banks the first and second data packets have the form illustrated respectively in figures 11H and 11J. In the system as implemented at the web site of the independent payment organization the processor forms outgoing data packets having the forms illustrated in figures 11H and 11J. In the system as implemented at any of the banks web sites the processor forms outgoing data packets having the forms illustrated in figures 11I and 11K.

First and second embodiments of the invention have been described. However, it should be understood that these embodiments are not mutually exclusive. That is an independent payment organization can be established so as to carry out the electronic funds transfer of the first embodiment and also to carry out the electronic funds transfer of the second embodiment. Furthermore, it will be readily appreciated by persons skilled in the art that many variations can be made in the precise detail of the form of the data packets and of the circuit arrangement illustrated in figure 8. For example in the data packets certain ID numbers and transaction numbers could be amalgamated.

Examples of certain electronic transfers of funds are described in relation to the first and second embodiments of the invention. The invention is not limited to these specific types of transfers and is equally applicable, for example, to transfers required for the immediate completion of financial transactions. The conveyancing of residential property is one example of a financial transaction for which an immediate transfer of funds is often required.

As a further example, the present invention may be used to effect government payments such as the payment of family allowance, tax credit and pension payments.

In the first embodiment the independent payment organization has a central role in the electronic communications between the customers/traders and the banks. In the second embodiment the independent payment organization has a somewhat similar role in the electronic communications between the employers and the banks. However, with the sacrifice of a certain amount of efficiency in the overall transaction process, the independent payment organization could have a different role. An example of this will be briefly described by way of a third embodiment of the invention. The third embodiment will be explained with reference to figure 12.

Figure 12 illustrates the computers/web sites of a customer, a trader, an independent payment organization and two banks, Bank 10 and Bank 20. The communications between these are indicated by the arrows and the sequence thereof is indicated by the reference numerals 1 to 8. The effect of the system is as follows. The customer logs-on to the web site of the trader and indicates that it is desired to purchase a particular product at a given price (communication [1]). The trader supplies the customer with a unique transaction number (indicated by T.No. in figure 12) for this purchase (communication [2]). The customer logs- on to his bank, Bank 10 in figure 12, and authorises a payment in the required amount to be made to an account with Bank 10 in the name of the independent payment organisation, using a reference equal to T.No. (communication [3]). Bank 10 sends notification to the payment organisation that the relevant amount has been deposited to it's account under the given reference number (communication [4]). Using the reference number and an internal database, the payment organisation identifies the trader involved and the trader's bank sort code and account number. The payment organisation then connects to the trader's bank and instructs that bank, Bank 20, to debit thepayment organisation's account with Bank 20 and to credit the trader's account with the relevant amount (communication [5]). Bank 20 confirms to the payment organisation that the transaction has been completed (communication [6]).

Subsequently the payment organisation notifies the trader that the relevant amount has been credited to the trader's account under the given reference number (communication [7]).

Finally, the trader notifies the customer that payment has been received and that the product is being despatched (communication [8]).

As in the first embodiment; in the third embodiment because the transfer from the customer to the independent payment organisation is between accounts held by the same bank, Bank 10, the transfer takes place on a 'same day' basis (even according to conventional banking arrangements). Similarly, because the transfer from the independent payment organisation to the trader is between accounts held by the same bank, Bank 20, (which, for a high percentage of cases, will not be the same as the customer's bank) the transfer takes place on a 'same day' basis (even according to conventional banking arrangements). The traditional 'three working days' delay can obviously be avoided according to the present invention. Moreover, the problem of fraud can be mitigated to a significant extent; because a complete customer-to-trader transaction takes place on the same day (compared with the long wait to be paid and potential claw back from credit card companies) and use is made of the bank's security verification rather than using, for example, a specialist credit card vetting agency. The transactions do not involve the use of credit cards, which helps to mitigate the general problem of growth of debt.

The technical implementation of the third embodiment has many components in common with the technical implementation of the first embodiment. The initial selection process and indication by the customer that a purchase is desired is the same in both embodiments (communication [1]). Data packet (A) of the first embodiment (see figure 7A) can be used by the trader in the third embodiment to send the reference number, or transaction code, to the customer (communication [2]). The additional information in data packet (A) compared with the initial description above of the third embodiment may indeed be preferable, as enabling certain levels of verification to be undertaken during the transaction.

When the customer logs-on to Bank 10 in the third embodiment, a web page essentially the same as that illustrated in figure 3 is displayed. Moreover the data packet sent by the customer to Bank 10 (communication [3]) can be the same as data packet (B) of the first embodiment (see figure 7B). Similarly, the data packet sent by Bank 10 to the payment organisation (communication [4]) can be the same as data packet (C) of the first embodiment (see figure 7C). The transactions between the payment organisation and Bank 20 in the third embodiment are the same as the transactions between the payment organization and Bank 2 in the first embodiment. Thus, communication [5] uses data packet (E) and communication [6] uses data packet (F). In the third embodiment the notification from the payment organization to the trader and from the trader to the customer can both use a data packet similar to data packet (D) of the first embodiment. In the third embodiment, since the same data packets can be used, it thus follows that essentially the same circuit arrangements as in the first embodiment can be used for receiving and identifying incoming data packets and for preparing and transmitting outgoing data packets; mutatis mutandis as to which data packets are received and transmitted by which computers.

Claims

Claims 1. A computer or computer system which electronically receives

incoming data packets and electronically transmits outgoing data packets via one or more networks to which the computer or system is connected so as to receive and transmit data packets; comprising: a receiver which receives incoming data packets; a transmitter which transmits outgoing data packets; an identifier which identifies the type of each incoming data packet and which accepts for processing data packets of a first type, containing an identification of their origin, a reference code and an identification of an amount to be paid, and data packets of a second type, containing the said reference code and amount identification together with an indicator signifying whether or not the payment has been'accepted; a memory having stored therein a plurality of records; a recorder which records as a record in the memory at least the identification of origin and reference code from a data packet of the first type accepted by the identifier; a processor which receives data packets from the identifier and processes them using records from the memory to form outgoing data packets and pass them to the transmitter for transmission; with data packets of the first type being processed to form an outgoing data packet with a content corresponding to the content of the received first type data packet for transmission to a bank identified from the records in the memory, and with data packets of the second type being processed to form an outgoing data packet with a content corresponding to the content of the received second type data packet for transmission to the said origin as identified from the records in the memory.
2. A computer or computer system as claimed in claim 1, wherein the processor forms outgoing data packets containing a debit account number, a credit account number, the said reference code and amount identification for transmission to a bank.
3. A computer or computer system as claimed in claim 1, wherein the computer or system is a payment organisation computer or system and the first type of data packets are trader data packets in which the identification of origin identifies a trader; the identifier identifying and accepting for processing data packets of sub-types of the second type, one sub-type which additionally contains an identifier which identifies the data packet as a trader sub-type and another sub-type which additionally contains an identifier which identifies the data packet as a payment organization sub-type.
4. A computer or computer system as claimed in claim 1, wherein the computer or system is a payment organization computer or system and the first type of data packets are employer data packets in which the identification of origin identifies an employer; the identifier identifying and accepting for processing data packets of sub-types of the second type, one sub-type which additionally contains an identifier which identifies the data packet as an employer sub-type and another sub-type which additionally contains an identifier which identifies the data packet as a payment organization sub-type.
5. A computer or computer system as claimed in claim 4, wherein the first type of data packets contains a plurality of field groups each group relating to a respective employee of the employer and identifying details of a bank account of the employee together with an identification of an amount to be paid to the employee.
6. A computer or computer system as claimed in claim 5, wherein the processor forms a plurality of outgoing data packets each containing a debit account number, a respective employee's account number, the said reference code and the respective identification of the amount to be paid to the employee, for transmission to the respective employee's bank.
7. A computer or computer system as claimed in claim 1, wherein the identifier identifies data packets of the first type as being received from a bank and identifies data packets of the second type as being received from a different bank.
8. A computer or computer system as claimed in claim 7, wherein the said origin is a trader and the said reference code is a code provided by the trader to a customer who uses the reference code when instructing the customer's bank to make a payment and send a data packet of the first type for reception by the said receiver. r
9. A computer or computer system which electronically receives incoming data packets and electronically transmits outgoing data packets via one or more networks to which the computer or system is connected so as to receive and transmit data packets; comprising: a receiver which receives incoming data packets; a transmitter which transmits outgoing data packets; an identifier which identifies the type of each incoming data packet and which accepts for processing data packets of a first type, containing an identification of their origin, a reference code and an identification of an amount to be paid, and data packets of a second type, containing a code by which the said reference code can be identified together with an indicator signifying whether or not the payment has been accepted; a memory having stored therein a plurality of records; a recorder which records as a record in the memory at least the identification of origin and reference code from a data packet of the first type accepted by the identifier; a processor which receives data packets from the identifier and processes them using records from the memory to form outgoing data packets and pass them to the transmitter for transmission; with data packets of the first type being processed to form an outgoing data packet with a content corresponding to the content of the received first type data packet for transmission to a bank, and with data packets of the second type being processed to form an outgoing data packet with a content corresponding to the content of the received second type data packet for transmission to the said origin.