AU2005203599A1

AU2005203599A1 - Electronic funds transfer

Info

Publication number: AU2005203599A1
Application number: AU2005203599A
Authority: AU
Inventors: Yong Kin Ong (Michael)
Original assignee: YONG ONG
Current assignee: YONG ONG
Priority date: 2000-02-14
Filing date: 2005-08-12
Publication date: 2005-09-01
Anticipated expiration: 2021-02-14
Also published as: AU2005203599B2

Description

AUSTRALIA

Patents Act 1990 COMPLETE SPECIFICATION STANDARD PATENT Applicant: ONG, YONG KIN (MICHAEL) Invention Title: ELECTRONIC FUNDS TRANSFER The following statement is a full description of this invention, including the best method of performing it known to me/us: 2 ELECTRONIC FUNDS TRANSFER FIELD OF THE INVENTION The present invention relates to a method of increasing security in electronic transactions and apparatus for achieving the method. The method has particular application in conducting an online electronic transfer of money.

BACKGROUND OF THE INVENTION The present e-commerce environment and systems do not provide people with confidence in shopping or conducting financial transactions online. Consumers are concerned about security issues when using their credit cards/debit cards to make purchases. They are worried that by using their credit cards/debit cards to make purchases online, that it will compromise the security of their credit cards/debit cards and they will be vulnerable to fraud.

Should credit card information go into the wrong hands, credit card owners may be liable for transactions not conducted by them.

The present invention provides a process that adds security to a financial transaction to alleviate some of the risks involved.

SUMMARY OF THE PRESENT INVENTION In accordance with the present invention there is provided a method of conducting an online transaction, said method including the steps of: providing a transaction manager; identifying a registered user to the transaction manager by a login process; H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 3 receiving a transaction request from the identified user; generating a unique identifier and sending the unique identifier to the identified user; associating the unique identifier with the transaction requested; receiving the unique identifier at the transaction manager; validating the unique identifier; and performing the transaction in the event that the unique identifier is valid.

Preferably the transaction is the transfer of money. More preferably the transaction is a financial transaction to pay a merchant for the purchase of a product or service.

Alternatively the transaction is the transfer of money to a third party. In one embodiment the transaction is the transfer of money from one bank account to another.

Preferably the product or service is provided externally to the transaction process.

Preferably the method further comprises the step of registering the user with the transaction manager.

Preferably the method further comprises the step of requesting the unique identifier, which follows receiving the transaction request. Preferably a user making a transaction request comprises requesting the unique identifier from transaction manager.

Preferably the method further comprises the step of registering the merchant with the transaction manager.

Preferably the merchant receives the transaction request from the user and provides the transaction request to the transaction manager. Preferably performing the transaction H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 4 includes transaction manager causing the payment to occur.

Typically performing the transaction includes the transaction manager providing the merchant with a unique transaction receipt number. Typically the payment is made into the merchant's bank account.

Preferably the login process comprises verifying the identify of the user by providing a password to match a user name, wherein a confirmation password is stored by the transaction manager, with the password provided by the user compared to the confirmation password to verify the identity of the user.

Preferably the unique identifier is unique to the transaction. Preferably the unique identifier is sent to the user via a different communications means to the communications means over which the user engages in the login process. Preferably the communications means includes a mobile telephone. Alternatively the unique identifier is send to the user in a different session (at a different time) to the transaction request.

Preferably the step of validation of the unique identified provides a second level of verification of the user's identity, which is unique to the transaction before the transaction is performed.

Preferably the transaction is conducted via an on-line banking service, such that the transaction manager comprises an on-line banking service computer server.

Typically the transaction is provided by the on-line banking service.

In one embodiment the transaction is one session with one or more sub-transactions being provided by the on-line banking service. Preferably a fee is paid to the on-line H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc banking service provider for each transaction.

Alternatively a fee is paid to the on-line banking service provider for each session. Alternatively a fee is paid to the on-line banking service provider for the overall provision of the on-line banking service.

Preferably the provision of the product or service is triggered by the transaction.

Preferably the transaction manager comprises an user identification component. Preferably the transaction manager comprises a transaction control component.

Preferably the transaction manager comprises a unique identifier generation component and unique identifier validation component.

Preferably the transaction manager deducts money from a user's account to cover the money paid to the merchant.

Preferably the transaction manager deducts money at the time of the request of the unique transaction identifier.

Alternatively the transaction manager deducts money at the time of the transfer of money to the merchant.

Alternatively the transaction is delayed to specified time/date.

Preferably the user's account is with a financial institution. Alternatively the user's account is with the transaction manger, the account may be a credit account or a charge account. Preferably the transaction manager issues a new account that corresponds to an existing account with a financial institution, whereby the new account details are used by the user and merchant in place of the existing account details. Preferably the transaction manager uses the new account details to look up the existing account details and the existing account details are used by the transaction manager with the financial institution.

H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 6 Preferably the user requests the unique transaction identifier by an Internet connection. Preferably the user's registration details are stored in a database of the transaction manager. Preferably the merchant's registration details are stored in the database including a unique merchant identification.

Preferably the user's request for the unique transaction identifier is validated by checking the user's details stored in the database of the transaction manager.

Preferably when the merchant forwards the unique identification number to the transaction manager, the merchants unique identifier is sent to the transaction manager, whereby validating the merchants identification is checked by the transaction manager before sending the identification number.

Preferably the transaction manager checks if sufficient funds are available to cover the transaction and the transaction number is only provided to the merchant if sufficient funds are available.

Preferably the merchant links to the transaction manager by the Internet or a dedicated secure line to request the transaction number and the transfer of funds. Preferably the link between the user and the transaction manager, and the merchant and the transaction manager are secured by encryption.

In one embodiment the financial institution and the transaction manager are one common entity. In another embodiment the financial institution and a merchant are one common entity. In a further embodiment the financial institution, the transaction manager and the merchant are one common entity.

H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 7 In one embodiment the unique transaction identifier is received at the transaction manager at a time distinct fro the request for the transaction.

In one embodiment the unique transaction identifier is received at the transaction manager by a different means by which the transaction identifier is requested.

In another embodiment the unique transaction identifier is received at the transaction manager by a different means by which the transaction identifier is released by the user.

Also in accordance with the present invention there is a method of identifying a user comprising the steps of: providing an identification means; providing facilitation means for conducting a transaction; identifying the user to the identification means; issuing an identity authenticated code to the identified user; receiving a request from the user to access an on-line service or purchase of a product by electronic transaction; requesting the user supply the identity authenticated code to the facilitation means; receiving the identity authenticated code at the facilitation means; transferring the identity authenticated code from the facilitation means to the identification means; validating the identity authenticated code as being that provided to the identified user by the user identification means; and facilitating the electronic transaction.

Preferably sending the identity authenticated code to the user is via a different mode of communication.

H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 8 Also in accordance with the present invention there is a transaction manager comprising: means for identifying a registered user to the transaction manager by a login process; means for generating a unique identifier and sending the unique identifier to the identified user when a transaction request is made by the registered user; means for recording an association of the unique identifier with the transaction; means for receiving the unique identifier from the registered user; means for validating the unique identifier; and means for facilitating performance of the transaction in the event that the unique identifier is valid.

Also in accordance with the present invention there is a transaction manager comprising: means for identifying a registered user to the transaction manager by a login process; means generating a unique identifier and sending the unique identifier to the identified user when a transaction request if made by the registered user; means for recording an association of the unique identifier with the transaction; means for receiving the unique identifier from the registered user; means for validating the unique identifier; and means for allowing performance of the transaction in the event that the unique identifier is valid.

Also in accordance with the present invention there is a system for conducting an online transaction comprising: means for providing a transaction manager; means for identifying a registered user to the transaction manager by a login process; H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 9 means for receiving a transaction request from the identified user; means for generating a unique identifier and sending the unique identifier to the identified user; means for associating the unique identifier with the transaction; means for receiving the unique identifier at the transaction manager; means for validating the unique identifier; and means for performing the transaction in the event that the unique identifier is valid.

DETAILED DESCRIPTION OF THE INVENTION In order to provide a better understanding a preferred embodiment of the present invention will now be described in detail, by way of example only, with reference to the accompanying drawings, in which: Figure 1 is a diagrammatic view of the relationship between entities using a preferred embodiment of the method of the present invention; Figure 2 is a diagrammatic view of the relationship between modules of the entities of Figure 1; Figure 3 is a diagrammatic flow chart representing an example of a transaction process in accordance with the present invention; Figure 4 is a block diagram of a system architecture of the transaction manager of the present invention; Figure 5 is a block diagram of a database structure of the transaction manager; Figure 6 is a block diagram of a data validation process conducted by the transaction manager; Figure 7 is a diagrammatic flow chart representing another example of a transaction process according to the present invention; and Figure 8 is another diagrammatic flow chart representing a H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 10 further example of a transaction process according to the present invention.

Referring to Figure 1, notional entities 10 using the method of the present invention are shown. The operations provided by these notional entities 10 may be combined or conducted separately. The notional entities 10 include a transaction manager 12 which is an overseeing entity for managing fund transfers according to the present invention, a user 14 who requests the funds transfer, an e-commerce merchant 16 who provides goods or services in an on-line environment, and a financial institution 18 that transfers the funds according to a funds transfer request. It is noted that the entities are notional in that a real entity can perform the role of one or more notional entities Referring to Figure 2, each of the entities 10 will have a corresponding module 20 for electronically interfacing with the other modules. The transaction manager 12 has a corresponding transaction manager module (TMM) 22 for implementing the actions/procedures that the transaction manager 12 is responsible for. The user 14 has a user interface module (UIM) 24 for interfacing with the other of the modules 20. The merchant 16 has a merchant interface module (MIM) 26 for interfacing with the UIM 24 and TMM 22.

The financial institution 18 has a financial institution interface module (FIIM) 28 for interfacing with the TMM 22 and the UIM 24. The FIIM 28 usually includes an electronic funds transfer system which debits and/or credits money from the user's account with the financial institution.

The modules 20 take the form of a device capable of performing the roles/actions of the respective entity. This is usually implemented by respective computer programs which each run on one or more computers. Typically the modules will be distributed at different locations and will H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 11 interface by electronic communications either internally within the device or over a computer network. Some of the modules may operate on the same computer or on computers within a local network, particularly if one real entity is performing the role of more than one notional entity For example a bank may perform the role of the financial institution 18, and the merchant 16. The bank may even perform the role of the transaction manager 12.

A user 14 uses the method of the present invention to conduct an electronic fund transfer transaction. Of course many users can be use the method of the present invention to conduct an electronic funds transfer. Each user 14 must register with the transaction manager 12 and have an account with the transaction manager 12 in order to use the facility. Each user account is specific to each registered user 14. Information held by the transaction manager 12 in relation to each user 14 is held in confidence and in compliance with privacy laws.

An e-commerce merchant 16 is an entity that uses an Internet site to do business with users 14. The type of business can take many forms. For example the merchant 16 may sell goods through an on-line website. The merchant 16 may sell services and/or provide services on-line. Those skilled in the art will realise that almost any good or service can be traded on-line and many services can be provided on-line.

One or more merchants 16 can use the method of the present invention. E-commerce merchants 16 register with the transaction manager 12 to use the facility provided by the present invention. The registration process ensures that the e-commerce merchant 16 provides a secure site and Internet users 14 are aware of and can trust the merchant because of this certification by the transaction manager 12.

A financial institution 18, such as a bank, credit union, H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 12 building society etc., has accounts which hold money. The financial institution 18 can transfer money between accounts of the same or another financial institution. The financial institution 18 provides an approved level of funds that each user 14 has available. This may be, for example, via a charge account or a credit card. One or more financial institutions 18 may participate in the method of the present invention. By the same token a financial institution 18 provides each user 14 access to their account or accounts which could be used for the payment or payments of services and/or goods or a transfer of money from a user 14 to another user 14. This may be, for example, via a savings account, a cheque account, a home loan account or other account as specified by the financial institution 18 or user 14.

Each e-commerce merchant 16 requires an account with a financial institution 18 in order to receive payments. The transaction manager 12 is responsible for authorising payments for transactions into an account of a nominated financial institution 18. Typically the transaction will relate to an on-line purchase, in which case the funds transfer will be a payment for the purchase. Here the funds transfer will be from an account of the user 14 to an account of the e-commerce merchant 16. Another example would be a bill payment. Again the funds transfer will be from an account of the user 14 to an account of the ecommerce merchant 16 (payee of the bill). A further example would be an on-line bank transfer. Here the funds transfer will be between an account of the user 14 and other account (which may be the user's or another person's held with the same or another financial institution).

Each financial institution 18 may provide to the transaction manager 12 access to a client's financial information including approved funds availability. This will enable a H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 13 funds transfer aspect of the TMM 22 to confirm a user's 14 financial standing. A financial account can be issued to a user 14 on the basis of an understanding between the transaction manager 12 and a financial institution 18. The understanding being that the account will be operated according to the present invention.

The transaction manager 12 is a trusted intermediary that provides the services between users 14, e-commerce merchants 16 and financial institutions 18. In particular, the transaction manager 12 is an intermediary that a user 14 can trust to provide the TMM 22 to interact between the merchant's MIM 26 and the financial institution's FIIM 28.

TMM 22 comprises an user identification component for identifying the user; a transaction control component for controlling the processing of the transaction; a unique identifier generation component for generating unique transaction identifiers; and a unique identifier validation component for validating the transaction identifiers.

Before the TMM 22 authorises the FIIM 28 to transfer money, the merchant 16 is required to obtain a unique transaction identifier from the user 14. The transaction identifier is generated by the TMM 22 and given to the user 14, as will be described further below. The transaction identifier is provided by the merchant 16 via the MIM 26 to the TMM 22.

The transaction identifier serves to confirm the fund transfer is authorised by the user 14. The TMM 22 will only authorise the FIIM 28 to make the transfer when the authenticity of the transaction identifier is confirmed by the TMM 22.

Following confirming the authenticity of the transaction identifier, the TMM 22 provides the merchant via MIM 26 with an approved transaction number. The TMM 22 also provides H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 14 FIIM 28 with approval to perform the funds transfer.

Preferably the transaction manager uses a newly generated account number to replace the original credit card number and/or debit card number account for account transaction processing. The replacement of the original account number is applicable to savings account, cheque account, home loan account or other account as stipulated by the financial institution or the user 14. This adds another level of security to the process. Thus for purposes of this invention the new account number is used to refer to the account as far as the user is concerned, however the true account number is used between the transaction manager 12 and the financial institution 18.

Transfer of information between the modules is secured by use of encryption technology. The TMM 22 is responsible for the security for Internet users 14 carrying out their transactions. This is possible through the use of proprietary software, accounting systems, design methodology, data definition and control processes. The transaction manager also has network security access controls.

For security purposes, the unique transaction identifier may be sent to the user 14 in a different connection session to the time the user 14 hands over the transaction identifier for validation or the transaction identifier is sent to the user 14 via a different communications means to the communications means over which the user 14 engages in the login process. For example, the transaction identifier may be sent to the user 14 via a mobile telephone, and entered by the user 14 into their computer.

The user 14 is usually assessing the facility of the present invention using a computer. The computer can simply have H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 15 Internet access and the browser acts as the UIM 24, or additional plug-ins or software can be installed on the user's computer to act as the UIM 24.

Referring to Figure 3 the processing of a transaction according to a preferred embodiment of the present invention is shown. The process starts at 32. A user 14 connects to the Internet at 34 and accesses the TMM 22 of the transaction manager 12 via the Internet. It is assumed the user is registered with the TMM 22. The registration process is described further below. As part of the registration process the user is provided with a login name and password. The user 14 needs a transaction identifier to complete a transaction and in this embodiment requests one at 36. To access the facility of the present invention the user connects the UIM 24 to the TMM 22, such as by dialling the user's computer in or by going to/being sent to a website or a particular webpage of the transaction manager 12. The user 14 enters their login and password to the UIM 24 in the usual manner. These are transferred to the TMM 22 and checked in the usual manner 40. If the identity of the user is verified by the login process the TMM 22 can provide the user with a number of options. If the identity of the user is not verified the connection to the TMM 22 is rejected at 42.

At this stage it is assumed the user wishes to use the transaction manager 12 to obtain a transaction identifier for future use to use with an e-commerce merchant. There are alternatives to the transaction being for a payment to a merchant which will be described further below.

In this example the user 14 has already requested at 36 a transaction identifier for his or her shopping needs. The user may request additional transaction identifiers be provided. Alternatively by requesting to make a fund H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 16 transfer or by requesting something (eg a purchase) that will require a fund transfer an implicit request is made for a transaction identifier to be provided.

In addition to the transaction identifier being provided to the merchant 16 other information may also be given to the merchant, which is then given to the transaction manager 12.

Where the user has more than one account available (eg credit card, savings account, cheque account) the additional information may be a selection of the type of account to be used in the funds transfer.

Coupled to that request can be a record of the limit the user allows to be authorised. The user's account will usually have a credit limit associated with it and the transaction limit must be less than the available credit.

This allows the user 14 to put an additional limitation on the transaction that can be conducted using transaction identifier. This gives the user control over the maximum value of transaction that may be authorised, which is different a maximum total value of all transactions. The limit can be set specific to a defined account. For example a limit of $100 may be set to a savings account while a limit of $200 may be set to a cheque account. This parameter is defined by the user 14. However, this invention allows the user 14 to also override the limit via a password and/or PIN (personal identification number) for one or more transaction request(s) as the user 14 desires.

After that course of action following the override authorisation made by the user 14, the system resets to its default limit as originally instituted by user 14.

The TMM 22 checks 38 the Internet user to ensure that he or she is a valid user. The transaction manager confirms the validation process at H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 17 If the user is valid, then at 44 the TMM 22 generates and sends the UIM 24 the transaction identifier. The transaction identifier is usually in the form of a number or alphanumeric string. This can be displayed for immediate use, printed on a voucher or stored electronically for later use.

The Internet user is then able to go shopping on-line, such as by selecting an item at e-commerce merchant's site at 46 or (if the purchase is already selected) the user proceeds with payment for the purchase. The merchant's website will have an interface to, include or be included in the MIM 26.

Upon deciding to purchase the item the user 14 is asked to provide a transaction identifier to use the facility of the present invention. The user 14 provides 48 the transaction identifier to the MIM 26, via the UIM 24.

The MIM 26 forwards 50 the transaction identifier to the TMM 22 for validation. The TMM 22 then confirms 52 the validity of the transaction identifier. Usually the MIM 26 will need to provide a login and password to the TMM 22 for checking before the TMM 22 will accept the transaction identifier validity request from the MIM 26. Further network security access controls such as encryption of the communication to and from the TMM 22 is provided.

If the transaction identifier is not valid at 54 the transaction is rejected. If the identifier is rejected the e-commerce merchant is advised via the MIM 26 along with the reason for the rejection. If the transaction identifier is valid the TMM 22 allows the transaction to proceed. Thus the transaction identifier has acted as an authorisation code which is unique to the transaction, unlike a credit card number or password/PIN and it is not able to be reused.

It also serves as a second form of identification of the user, which will not be used again. Additionally the H:\mcamnp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 18 transaction identifier can be associated with other parameters, eg a transaction limit, which if not met can result in rejection of the transaction.

The TMM 22 issues an approved transaction number at 56 to the MIM 26 and disables further use of that transaction identifier. Forwarding of the transaction approved number to the merchant confirms to the merchant 16 that the transaction identifier was accepted. At 58 the TMM 22 interfaces with the FIIM 28 to transfer the funds from the user's bank account to the merchant's bank account according to the value of the purchase.

The TMM 22 undergoes a required security check including a password check before access to the financial institution is approved. Further network security access controls are also provided including encryption of communication. The process then ends at The registration process of the user involves the user supplying their details to the TMM 22, which are stored in a database as described below. The details will include the user's financial institution account details (eg BSB and account number/s) sufficient for the financial institution to access the user's account(s) to transfer money therefrom or thereto. The user is then given a user login and password.

In Figure 4, one form of system architecture 70 of the TMM 22 is shown. An operating system 72 is installed on a computer functioning as the TMM 22. Sitting on top of the operating system 72 is a relational database management system 74. This is the data collection centre of the system. The relational database management system 74 interacts with an application system 76. The application system 76 interacts with an Internet base system 78 that H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 19 links the TMM 22 to the other of the modules Referring to Figure 5, a database structure is shown relating a user's profile to a financial institution profile and an e-commerce merchant's profile to a financial institution profile. An Internet user's profile is a repository of information concerning a particular user.

This is used for validation with a financial institution profile. An e-commerce merchant profile is a repository of information concerning a particular e-commerce merchant.

This is used for validation with financial institution profile. Profiles for Internet users will be different to those of e-commerce merchant profiles.

Referring to Figure 6, data validation structure and processes are shown. In relation to the Internet user's profile personal details are checked with the relational database management system for accuracy and if accepted account details are then checked with the relational database management system validity. If accepted, credit details are checked with the relational database management system for validity and if accepted transaction details are stored. Audit trials of each check are also recorded.

In relation to the e-commerce merchant profile, corporation details are checked with the relational database management system for accuracy. If accepted, account details are then checked with the relational database management system for validity. If accepted the credit details are checked with the relational database management system for validity. If accepted the transaction details are stored. An audit trail is recorded for each check and changed to the profile.

Referring to Figure 7, a method 100 of conducting internet banking according to the present invention is shown. The user 102 accesses the Internet at 102 and goes to the bank's H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 20 website at 104. The user selects internet banking at 106 and enters 108 their details into the internet banking login window. The user selects a financial function at 110, such as for example an account enquiry or a bill payment.

Another option (not shown) would be a bank transfer from the user's account to another person's account.

At 112 an enquiry on accounts is selected. The TMM 22 releases a one time unique transaction identifier to the UIM 24 at 114, which must be given to the bank Internet banking service. This is then passed from the Internet banking service back to the TMM 22 for validation at 116. If validated the transaction is accepted and an account information screen is displayed at 118. The user 14 may then perform a financial transaction, such as a transfer between the user's accounts. Again the TMM 22 releases a one time unique transaction identifier at 120, which must be given to the bank Internet banking service. This is then passed back to the TMM 22 for validation at 122. If validated the transaction is accepted and an approval reference number is issued at 124.

At 126 a pay bills option is selected. The bill information is entered at 128. If the user does not have a one use unique transaction identifier, the user must first request one from the transaction manager 12, in which case the TMM 22 sends it to the UIM 24. Once the user has the transaction identifier held by the UIM 24, then the UIM 24 releases the transaction identifier to the TMM 22 at 130, which must be given to the bank Internet banking service.

This is then passed back to the TMM 22 for validation at 132. If validated the transaction is accepted, the payment is processed at 134 and an approval reference number is issued at 124.

In this embodiment the transaction is conducted via an on- H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 21 line banking service. In this embodiment the transaction manager may also be the financial institution which operates the TMM 22 and the FIIM 28 comprises an on-line banking service computer server. Typically the transaction is provided by the on-line banking service.

The online banking service is provided in one session in one embodiment the session may constitute one transaction for purposes of the authorisation process of this invention. The transaction is then divided into one or more sub-transactions being provided by the on-line banking service. Usually a fee is paid to the on-line banking service provider for each transaction. Alternatively a fee is paid to the on-line banking service provider for each session. Alternatively a fee is paid to the on-line banking service provider for the overall provision of the on-line banking service.

Referring to Figure 8, a batch payment process 150 is shown.

The user 14 accesses the Internet at 152 and goes to the transaction manager's website at 154. The user enters a user and transaction ID at 156 and enters at 158 their account type. If the user does not have a one use unique transaction identifier, the user must first request one from the transaction manager 12, in which case the TMM 22 sends it to the UIM 24. Once the user has the transaction identifier held by the UIM 24, then the UIM 24 releases the transaction identifier to the TMM 22 at 160, which must be given validated by the TMM 22 at 162. If validated the user 14 is given a choice of paying immediately or delaying payment. If immediately is selected the TMM 22 processes the payment at 164.

If delay is selected the user defines 166 the date of the payment and payment type. Every night a batch process is run to process payment to be actioned on that given date at H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 22 168. If the payment date is reached the payment is processed at 170 otherwise the processes waits for the next night to process back at 168.

The present invention provides the following functionality to support e-commerce: it provides a true online system, that is a process where all transactions are online; it provides a purchasing system where all users are able to make purchases online; it provides a payment system that supports other suppliers (merchant and/or financial institution) payment system; the system provides password control to validate processes within the system; it provides debit and credit card support enable usage of other suppliers (merchant and/or financial institution credit card/debit card as well as an alternative credit card/debit card facility to make purchases and payments); it provides support for all financial institution accounts allowing a transaction to be processed by all types of bank accounts (for example, savings and cheques).

Internet users can use all types of bank accounts to make online purchases and payments provided they are valid users; it provides a controlled purchase amount through usage of transaction identifiers with all users able to control the amount of funds for each transaction; it provides a user validation system with the system validating the users identification; it provides a merchant validation system with a system validating the merchants identification; it provides protection system through encryption and decryption system and proprietary system architecture.

Modifications and variations may be made to the present invention without departing from the basic inventive H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 23 concepts. The nature of such modifications and variations are to be determined within the scope of the present invention as defined by the foregoing description and appended claims.

In the claims of this application and in the description of the invention, except where the context requires otherwise due to express language or necessary implication, the words "comprise" or variations such as "comprises" or "comprising" are used in an inclusive sense, i.e. to specify the presence of the stated features but not to preclude the presence or addition of further features in various embodiments of the invention.

H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc

Claims

2. A method according to claim 1, wherein the transaction is the transfer of money.
3. A method according to either claim 1 or 2, wherein the transaction is a financial transaction to pay a merchant for the purchase of a product or service.
4. A method according to claim 3, wherein the product or service is provided externally to the transaction process. A method according to either claim 3 or 4, wherein the provision of the product or service is triggered by the transaction.
6. A method according to any one of claims 3 to further comprising the step of registering the merchant with the transaction manager, wherein the H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 25 merchant receives the transaction request from the user and provides the transaction request to the transaction manager.
7. A method according to any one of claims 3 to further comprising the step of providing the unique identifier to the merchant, wherein the merchant provides the unique identifier to the transaction manager.
8. A method according to claim 1, wherein the transaction is the transfer of money to a third party.
9. A method according to any one of claims 1 to 8, wherein the transaction is the transfer of money from one bank account to another. A method according to any one of claims 1 to 9, further comprising the step of registering the user with the transaction manager.
11. A method according to any one of claims 1 to further comprising the step of requesting the unique identifier, which follows receipting of the transaction request.
12. A method according to any one of claims 1 to 11, wherein a user making a transaction request comprises requesting the unique identifier from the transaction member.
13. A method according to any one of claims 1 to 12, wherein the unique identifier is unique to the transaction.
14. A method according to any one of claims 1 to 13, wherein the login process comprises verifying the H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 26 identity of the user by providing a password to match a user name, wherein a confirmation password being stored by the transaction manager, wherein the password provided by the user is compared with the confirmation password. A method according to claim 14, wherein performing the transaction includes the transaction manager providing the merchant with a unique transaction receipt number.
16. A method according to any one of claims 1 to wherein the unique identifier is send to the user via a different communications means to the communications means over which the user engages in the login process.
17. A method according to claim 16, wherein the communications means includes a mobile telephone and other telephone devices including VOIP (Voice Over Internet Protocol) and landline telephone.
18. A method according to any one of claims 1 to 17, wherein the unique identifier is send to the user in a different session (at a different time) to the transaction request.
19. A method according to claim 3, wherein performing the transaction includes transaction manager causing the payment to occur. A method according to claim 19, wherein the payment is made into the merchant's bank account.
21. A method according to any one of claims 1 to wherein the transaction is conducted via an on-line banking service, such that the transaction manager comprises an on-line banking service computer server. H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 27
22. A method according to claim 21, wherein the transaction is provided by the on-line banking service.
23. A method according to claim 21, wherein the transaction is one session with one or more sub- transactions being provided by the on-line banking service.
24. A method according to claim 22, wherein a fee is paid to the on-line banking service provider for each transaction.
25. A method according to claim 22, wherein a fee is paid to the on-line banking service provider for each session.
26. A method according to claim 21, wherein a fee is paid to the on-line banking service provider for the overall provision of the on-line banking service.
27. A method according to any one of claims 1 to 26, wherein the transaction manager comprises an user identification component.
28. A method according to claim 1, wherein the transaction manager comprises a transaction control component.
29. A method according to any one of claims 1 to 28, wherein the transaction manager comprises a unique identifier generation component and unique identifier validation component.
30. A method according to any one of claims 1 to 29, wherein the step of validation of the unique identifiers occurs before the transaction is H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 28 performed, whereby a second level of verification of the user's identity, which is unique to the transaction, is performed.
31. A method of conducting an online transaction in accordance with any one of claims 3 to 7, wherein the transaction manager deducts money from a user's account to cover the money paid to the merchant.
32. A method of conducting an online transaction in accordance with claim 31, wherein the transaction manager deducts money at the time of the request of the unique transaction identifier.
33. A method of conducting an online transaction in accordance with claim 31, wherein the transaction manager deducts money at the time of the transfer of money to the merchant.
34. A method of conducting an online transaction in accordance with claim 31, wherein the user's account is with a financial institution. A method of conducting an online transaction in accordance with claim 31, wherein the user's account is with the transaction manger.
36. A method of conducting an online transaction in accordance with any one of claims 3 to 7, wherein the transaction manager issues a new account that corresponds to an existing account with a financial institution, whereby the new account details are used by the user and merchant in place of the existing account details.
37. A method of conducting an online transaction in accordance with claim 36, wherein the transaction H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 29 manager uses the new account details to look up the existing account details and the existing account details are used by the transaction manager with the financial institution.
38. A method of conducting an online transaction in accordance with any one of claims 1 to 37, wherein the user requests the unique transaction identifier by an Internet connection.
39. A method of conducting an online transaction in accordance with claim 10, wherein the user's registration details are stored in a database of the transaction manager. A method of conducting an online transaction in accordance with claim 39, wherein the user's request for the unique transaction identifier is validated by checking the user's details stored in the database of the transaction manager.
41. A method of conducting an online transaction in accordance with claim 15, wherein the merchant's registration details are stored in the database including a unique merchant identification.
42. A method of conducting an online transaction in accordance with claim 41, wherein when the merchant forwards the unique identification number to the transfer manager, and the merchant's unique identifier is sent to the transaction manager, wherein the merchant's identification is validated by the transaction manager before sending the transaction receipt number.
43. A method of conducting an online transaction in accordance with any one of claims 33 to 35, wherein H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 30 the transaction manager checks if sufficient funds are available to cover the transaction and the transaction number is only provided to the merchant if sufficient funds are available.
44. A method of conducting an online transaction in accordance with any one of claims 33 to 35, wherein the merchant links to the transaction manager by the Internet or a dedicated secure line to provide the unique identifier and receiving the transaction receipt number. A method of conducting an online transaction according to claim 34, wherein in one embodiment a financial institution and a transaction manager can be one common entity.
46. A method of conducting an online transaction according to claim 3, wherein in one embodiment a financial institution and a merchant can be one common entity.
47. A method of conducting an online transaction according to claim 34, wherein in one embodiment a financial institution, a transaction manager and a merchant can be one common entity.
48. A method of identifying a user comprising the steps of: providing an identification means; providing facilitation means for conducting a transaction; identifying the user to the identification means; issuing an identity authenticated code to the identified user; receiving a request from the user to access an H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 31 on-line service or purchase of a product by electronic transaction; requesting the user supply the identity authenticated code to the facilitation means; receiving the identity authenticated code at the facilitation means; transferring the identity authenticated code from the facilitation means to the identification means; validating the identity authenticated code as being that provided to the identified user by the user identification means; and facilitating the electronic transaction.
49. A method according to claim 48, wherein the identity authenticated code is sent to the user via a different mode of communication. A transaction manager comprising: means for identifying a registered user to the transaction manager by a login process; means generating a unique identifier and sending the unique identifier to the identified user when a transaction request if made by the registered user; means for recording an association of the unique identifier with the transaction; means for receiving the unique identifier from the registered user; means for validating the unique identifier; and means for allowing performance of the transaction in the event that the unique identifier is valid.
51. A system for conducting an online transaction comprising: means for providing a transaction manager; means for identifying a registered user to the transaction manager by a login process; H:\mcamp\keep\speci\P56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc 32 means for receiving a transaction request from the identified user; means for generating a unique identifier and sending the unique identifier to the identified user; means for associating the unique identifier with the transaction; means for receiving the unique identifier at the transaction manager; means for validating the unique identifier; and means for performing the transaction in the event that the unique identifier is valid.
52. A transaction manager comprising: means for identifying a registered user to the transaction manager by a login process; means for generating a unique identifier and sending the unique identifier to the identified user when a transaction request is made by the registered user; means for recording an association of the unique identifier with the transaction; means for receiving the unique identifier from the registered user; means for validating the unique identifier; and means for facilitating performance of the transaction in the event that the unique identifier is valid. Dated this 12 th day of August 2005 ONG, YONG KIN (MICHAEL) By his Patent Attorneys GRIFFITH HACK Fellows Institute of Patent and Trade Mark Attorneys of Australia H:\mcamp\keep\speci\56306 ELECTRONIC FUNDS TRANSFER ZIPFUND DIV.doc