NZ523709A - Transaction processing system and method of creating stored transaction authorisation information at a remote location - Google Patents

Abstract

A method of creating stored transaction authorisation information at a remote location, comprises commencing a secure transaction session at a secure terminal, reading user information from a user transaction card in the secure terminal and remotely securely storing the information, remotely securely storing information relating to a user terminal address attribute for an authorisation terminal to be authorised by the user to initiate financial transactions, and generating and securely storing a valid user code as a PIN offset to identify a PIN to be used from the authorised terminal type.

Description

523709 Patents Form # 5 NEW ZEALAND Patents Act 1953 COMPLETE SPECIFICATION AFTER PROVISIONAL # 523709 DATED : TITLE : 17 January 2003 Transaction processing system and method We, EFTWIRE LIMITED Address: P O Box 2313, Shortland Street, Auckland, New Zealand Nationality: A New Zealand citizen/company do hereby declare the invention for which we pray that a patent may be granted to us and the method by which it is to be performed, to be particularly described in and by the following statement: PF05.JWP 1 - FEE CODE 1050 INTELLECTUAL PROPERTY OFFICE OF N.Z- 13 JAN 20M RECEIVED 106880NZ_DPCS_999 .doc 2 TRANSACTION PROCESSING SYSTEM AND METHOD Technical Field The present invention relates to a system, method and/or apparatus used to process transactions. Preferably, the present invention may be used to process the financial transactions of a user where the user employs a portable wireless terminal device such as a cellular telephone to access the faculty provided. Reference throughout this specification will in general be made to the use of portable terminals being employed in conjunction with the present invention, but those skilled in the art should appreciate that other implementations which do not necessarily use such terminals are also envisioned.

Background Art The ability to execute financial transactions quickly and easily is of advantage to businesses. For example, in retail situations a consumer or customer is more likely to purchase goods or services on the spur of the moment if the financial transaction involved can be completed conveniently. Physical cash, credit cards or electronic point of sale (EFTPOS) access cards all allow the user or consumer to quickly and easily execute a financial transaction to pay for goods or services.

In general, the most common forms of payment used in financial transactions require a customer or user to be physically present at the point of sale. A purchaser normally has to present some form of physical token, such as cash, or a credit, debit, bank or EFTPOS card which validates the purchaser's authority to access funds available through a financial institution.

This can be inconvenient for some people as they may wish to order and pay for goods or services from a location remote from the point of sale. Furthermore, this "point of sale" approach also requires that the purchaser carry some form of token at 106880NZ_DPCS_999.doc 3 all times at which they may want to complete such transactions, where this token must be secured against theft or unauthorised access.

One alternative approach to the point of sale situation discussed above is through the use of credit cards and telecommunications or information technology networks. Credit card payment networks allow a customer to transmit the characteristic numbers and information printed onto their credit card to facilitate and authorise a credit card transaction remote from the point of sale. The credit card information is then collected by the seller or vendor and batch processed at a later time.

Although this scenario does allow users to complete a financial transaction remote from the point of sale, there are still some problems with this approach. There is limited security associated with the use of credit cards in such remote transaction scenarios. The user of the credit card does not necessarily have to present any form of authentication information or token to complete the transaction and trigger the delivery of goods or services. This allows for stolen credit cards to be used to uplift goods and services if the thief has access to a telephone or internet terminal.

Furthermore, the large number of digits and particulars of the credit card which needs to be communicated to a retailer can put some customers off completing such transactions. A customer needs to read out all the information printed on their credit card slowly and clearly and ensure that this information is correctly relayed to the retailer or seller involved.

In addition, this form of remote payment facility is not necessarily available to all potential customers of a retailer. It is sometimes common for some of a retailer's customers not to be issued with or have access to a credit card required for such remote transactions.

One attempt to address the above problems is disclosed in US Patent No. 5,991,749. This document describes the use of wireless mobile devices (such as cellular 106880NZ_DPCS_999.doc 4 telephones) to facilitate financial transactions where one of the parties of the transaction is remote from the point of sale involved. The system described also requires a user to register with the system prior to use. When employed to facilitate a financial transaction the system receives identification information from the user which authorises the completion of a transaction through the system's connections to a financial network or institution.

However, again there are some limitations with the approach described in this document.

Through limitations in the security of the system the finances or credit of a user may potentially be accessed by an unauthorised third party. A user account may be set up in conjunction with such system through information which could readily be obtained through public channels or personal documentation which is not normally considered to be of sensitive or secure nature.

For example, in some instances a bank account number or customer number for the cellular telephone network provider to register an account for use with such a service. Such accounts may be set up with insecure information and then subsequently used anonymously to access the finances or available credit of the unsuspecting owner of the information used in the registration process. Typically these accounts are set up using a paper form, giving personal details over a telephone or entering personal details into an internet registration form.

However, there is great, reluctance by users to enter this information onto any form, and all of these types of registration processes are time consuming. In addition, all of these types of registration processes can expose confidential, personal data to other sources and therefore they cannot be fully secure or trusted. These registration processes require a user to sign confirming their acceptance of the terms and conditions, and there is no guarantee that the signature upon the document is not 106880NZ_DPCS_999.doc forged.

Furthermore, established financial institutions such as banks or other major lending providers are not provided with a secure channel for transactions into their own transaction processing systems or networks. As the registration or application procedures employed in the system discussed above do not necessarily comply with the standard, secure access protocols of normal banking institutions, there is potential for these institutions to exhibit a high degree of resistance to taking up or offering transactions through such a facility.

These types of systems also store identification information that validates the user. If this information store were compromised a person would have immediate access to all the information necessary to perform fraudulent transactions.

A system, method and/or apparatus which addressed any or all of the above problems would be of advantage. A system which allows the user to remotely register for its use without having to enter personal details onto a paper form, reveal personal details over a telephone or enter personal details into an internet registration form and that such registration occurs within existing, secure banking standards would be of advantage. A system which allows the user to easily and simply participate in a range of financial transactions using a number of different access terminals from a wide variety of locations would also be of advantage. A system which allowed access to a financial processing network where the security of the access rights is on a par with existing banking or financial institutions security standards, and which preferably allowed wireless or mobile electrical devices to access such financial networks or services would also be of advantage. A system which has its own payment authorisation process but also uses the financial institutions accepted, secure payment authorisation process would be of advantage. A system which stores information in such a way that if the information store was compromised, a person could not use the gained information for fraudulent purposes would also be of 106880NZ_DPCS_999.doc 6 advantage. A system that creates a virtual EFTPOS or ATM machine that is exclusive for the user and allows the user to pay for goods would also be of advantage.

All references, including any patents or patent applications cited in this specification are hereby incorporated by reference. No admission is made that any reference constitutes prior art. The discussion of the references states what their authors assert, and the applicants reserve the right to challenge the accuracy and pertinency of the cited documents. It will be clearly understood that, although a number of prior art publications are referred to herein, this reference does not constitute an admission that any of these documents form part of the common general knowledge in the art, in New Zealand or in any other country.

It is acknowledged that the term 'comprise' may, under varying jurisdictions, be attributed with either an exclusive or an inclusive meaning. For the purpose of this specification, and unless otherwise noted, the term 'comprise' shall have an inclusive meaning - i.e. that it will be taken to mean an inclusion of not only the listed components it directly references, but also other non-specified components or elements. This rationale will also be used when the term 'comprised' or 'comprising' is used in relation to one or more steps in a method or process.

It is an object of the present invention to address the foregoing problems or at least to provide the public with a useful choice.

Further aspects and advantages of the present invention will become apparent from the ensuing description which is given by way of example only.

Disclosure of invention Accordingly in one aspect the invention relates to creating stored transaction authorisation information at a remote location comprising commencing a secure transaction session at a secure terminal, reading user information from a user 106880NZ_DPCS_999 .doc 7 transaction card in the secure terminal and remotely securely storing the information, remotely securely storing information relating to a user terminal address attribute for an authorisation terminal to be authorised by the user to initiate financial transactions, and generating and securely storing a valid user code as a PIN offset to identify a PIN to be used from the authorised terminal type.

Preferably the secure terminal is an ATM or EFTPOS terminal.

Alternatively the invention relates to a method of authorising a financial transaction from a financial account comprising storing in a secure database information sufficient to authorise a transaction, this information including a Personal Identification Number (PIN) and a PIN offset differing from other PIN offsets of that account holder, storing in said database information identifying a terminal device usable by an initiator of a financial transaction, receiving from that terminal device a transaction authorisation which authorisation contains a PIN, detecting whether the received PIN is offset the specified amount from the stored PIN , and authorising the transaction when the PIN is offset by the correct amount.

In yet another embodiment the invention relates to a financial transaction processing system accessible by a remote user terminal, said terminal having at least one associated address attribute, the system including an information store adapted to secure financial information sourced from a plurality of remote users, the financial transaction processing system being characterised in that a user's financial information is released by the information store to process a financial transaction upon receipt by the information store of a valid user terminal address attribute and a valid user access code.

Preferably the terminal is a telephone and the terminal address attribute is the telephone number of the terminal, and the user access code is a PIN.

In a further alternative embodiment the invention relates to a method of processing a financial transaction using the financial transaction processing system substantially as described above, said method being characterised by execution of the steps of: receiving a user terminal address and user access code, receiving transaction information, determining a transaction type from the received transaction information, and releasing a user's stored financial information to process a financial 106880NZ_DPCS__999.doc 8 transaction if a valid user terminal address attribute and valid user access code are received and if the transaction type determined is allowed for the terminal type of the remote user terminal.

Preferably the allowable transaction types differ for differing terminal types.

Preferably the allowable transaction limits differ for differing terminal types.

Preferably the user terminal address is a mobile telephone number and the user access code is a user PIN.

Preferably the user terminal address is a network card address and the user access code is a PIN.

Preferablythe authorised transaction may be a transaction which repeats at specified intervals, the repetition being instigated by scheduled procedures which again release the user stored financial information.

According to another aspect of the present invention there is provided a financial transaction processing system accessible by a remote user terminal, said terminal having at least one associated address attribute, the system including an information store adapted to secure financial information sourced from a plurality of remote users, the financial transaction processing system being characterised in that a user's financial information is released by the information store to process a financial transaction upon receipt by the information store of a valid user terminal address attribute.

According to another aspect of the present invention there is provided a financial transaction processing system substantially as described above wherein the system stores financial information which is transmitted to a financial institution to process the financial transaction required. 106880NZ_DPCS_999.doc 9 Preferably the present invention is adapted to provide a financial transaction processing system. Furthermore, the present invention may also encompass a method of processing financial transactions using such a system in addition to any apparatus, components or physical hardware employed within such a method to implement the system required. The present invention may also encompass financial transaction processing software adapted to be run or executed using computer hardware forming the apparatus of the system. Reference throughout this specification will in general be made to the present invention providing a financial transaction processing system, but those skilled in the art should appreciate that various other components or aspects of the present invention are also encompassed by such terminology.

A financial transaction as processed in accordance with the present invention may facilitate the transfer of funds or credit between (preferably) two parties. The channels or facilities employed to transfer such funds may preferably be implemented through standard or existing banking channels, used for example for credit card transactions or preferably electronic funds transfer point of sale (EFTPOS) transactions.

According to a further aspect of the present invention there is provided a method of processing a financial transaction using the financial transaction processing system substantially as described above, said method being characterised by execution of the steps of: receiving a user terminal address and user access code, and receiving transaction information, and determining a transaction type from the receiver transaction information, and releasing a user's stored financial information to process a financial transaction if a valid user terminal address attribute and valid user access code are received and if the 106880NZ_DPCS_999 .doc 10 transaction type determined is allowed for the terminal type of the remote user terminal.

Reference throughout this specification will also be made to the financial transaction processed being EFTPOS transactions between a retailer or vendor of goods or services and a customer of such a vendor. However, those skilled in the art should appreciate that other relationships and other types of transactions or protocols may also be employed in conjunction with the present invention and reference to the above only throughout this specification should in no way be seen as limiting. For example, in some embodiments the present invention may be adapted to set up bill payment or bill payment authorisation facility which triggers the payment of a regular charge or bill between a customer and a particular vendor of goods or services (such as for example, a utilities company).

Preferably the system provided may also service the needs of a plurality of users or the customers of one or more vendors of goods or services. Such a system may facilitate financial transactions preferably between a large number of customers and vendors, with the system, apparatus, or components employed to implement the present invention providing secure access to financial information associated with each of the users or customers involved. Preferably the present invention may also provide customers or users remote access to such transactions where the user need not necessarily be present at the point of sale involved for a particular transaction.

Preferably the present invention may include an information store. Such an information store may be accessed by a user employing a remote user terminal to facilitate the release of a user's stored and secured financial information from the information store. The information store provided may be connected to or in communication with a financial institution's transaction processing network to allow the present invention to release sensitive, secure financial information associated with a particular user to implement a required financial transaction. Preferably the 106880NZ_DPCS_999.doc 11 financial information involved may be stored in electronic form or format thereby allowing computerised information technology systems to be employed to both manage, secure and also transmit and communicate said information on demand.

Preferably the financial information secured and stored in conjunction with the present invention may be transmitted or supplied to a further financial institution to process the financial transaction required. The present invention may act to facilitate the release of such information and in turn allow the financial institution involved to process the transaction required.

Reference throughout this specification will also be made to the present invention being used in this application, but those skilled in the art should also appreciate that in an alternative embodiment the actual processing of the transaction may also be completed by a systems or apparatus employed in conjunction with the present invention if required.

In a further preferred embodiment the information store provided may be implemented through use of at least one computer system loaded with software adapted to provide a database or other similar type of data storage and retrieval facility. Database technology is well known in the art and may be used effectively to store the financial information associated with a plurality of users in a secure yet easily and quickly accessible facility. Furthermore, the information store provided may also include security software and/or hardware used to validate information or communications from a user wishing to access secured financial information. Such components can be employed to determine whether the user involved has the authority to execute a particular financial transaction using the secured financial information involved.

Preferably the present invention may allow a user or customer to employ a remote user terminal to communicate with the information store and subsequently trigger the 106880NZ_DPCS_999.doc 12 release of secured financial information to execute a required transaction. Preferably the remote user terminal employed may communicate with the information store using existing communications infrastructure procedures, protocols or facilities which are secured against authorised interception.

In a further preferred embodiment a mobile remote user terminal may be employed to access or use the present invention. A mobile terminal, such as for example, a cellular telephone or cellular enabled personal digital assistant (PDA), or laptop computer may be employed in conjunction with the present invention. These types of terminals can allow convenient and secure access to the financial transaction facility provided. Reference throughout this specification will also be made to the remote user terminal employed being a cellular telephone or other type of wireless or radio frequency based transceiver. However, those skilled in the art should appreciate that other types of terminals may also be used in conjunction with the present invention and reference to the above only throughout this specification should in no way be seen as limiting. For example, in one alternative embodiment land line telephones may also be employed as a user terminal if required.

Preferably a terminal used to access or communicate with the information store may include or have associated at least one address attribute. An address attribute may uniquely identify the specific user terminal involved and preferably may provide a communication routing address normally used to facilitate communications with the terminal involved. For example, in a preferred embodiment a cellular telephone may be employed as a remote user terminal, where the telephone number of the cellular phone makes up the address attribute required or used.

Those skilled in the art should appreciate that the address attribute associated with terminal employed will be determined by the type of terminal in addition to communications channels or protocols used by the terminal. For example, in other alternative embodiments internet protocol addresses for computer systems, network 106880NZ_DPCS_999 .doc 13 card MAC addresses or remote access point addresses for wireless computer networks may also provide address attributes to be employed in conjunction with the present invention.

Preferably a prior user registration procedure may be implemented in conjunction with the present invention before a user is allowed to access the facilities provided in accordance with the present invention. This prior user registration process may be employed to secure access to the financial information held by the information store. This procedure may be implemented to prevent an unauthorised user from gaining access to such information and subsequently completing an unauthorised financial transaction.

Preferably as part of this registration process, a user may provide or supply details of the address attribute of a remote terminal they wish to employ to access the facilities provided in accordance with the present invention. For example, in a further preferred embodiment where the remote user terminal employed is a cellular telephone, the telephone number of the cellular phone involved may be supplied as part of this registration process. Preferably the prospective user of the present invention may provide an address attribute which uniquely identifies their terminal, and where the terminal involved preferably is only accessible to the user wishing to execute financial transactions in accordance with the present invention.

Reference throughout this specification will also be made to the user terminal employed being a cellular telephone. The address attribute provided may in such instances be the telephone number of such as cellular 'terminal', which can uniquely identify the terminal involved. Furthermore, reference throughout this specification will also be made to a user communicating with the financial transaction processing system using a single terminal only which has a single address attribute. However, those skilled in the art should appreciate that more than one terminal may be employed by a single user, as may more than one address attribute for a single 106880NZ_DPCS_999.doc 14 terminal if required. Those skilled in the art should appreciate that other configurations and arrangements of the present invention are envisioned and reference to the above only throughout this specification should in no way be seen as limiting.

In a preferred embodiment as part of this user registration process, a user may also be supplied with an access code or the user may choose a specific code. Such an access code can, in combination with a received valid user terminal address attribute, authorise a user's access to the financial information which is secured in the information store and hence provide the ability to complete financial transactions using said information.

In a further preferred embodiment the access code provided may take the form of a password or a sequence of alphanumeric characters. Most users of the present invention would be familiar with personal identification numbers (PINs) used to access EFTPOS based transactions. A distinct alphanumeric access code may preferably take the form of a number of digits that may be lesser than, equal to or greater than the format of standard banking PIN numbers where this access code should only be known to the user registering to employ the facilities provided in accordance with the present invention.

Preferably the information store provided may be adapted to release the stored and secured financial information of a particular user upon receipt of a valid user terminal address and valid access code for the owner of the information involved. Preferably the owner of such information may be the only person or party with access to both the remote user terminal (which has the associated received address attribute) and who is the only person or party in possession of the access code employed. Upon receipt of a valid terminal address attribute and access code associated with a particular user, the user's secured financial information may then be released and used to implement or execute a financial transaction. 106880NZ_DPCS_999.doc 15 In a further preferred embodiment the terminal address attribute employed to validate or authorise access to such financial information may preferably be extracted from communications made directly between the information store and remote user terminal. The information store may query or receive such address attribute information from the remote terminal, and may authorise or subsequently refuse access to the financial information stores depending on whether the correct address attribute for an identified user's terminal is received. For example, in one embodiment caller line identification technology can be employed to obtain or extract the telephone number address attribute of a calling user's telephone.

In a further preferred embodiment the level of security that the remote user terminal supports and the level of security on the communication lines employed determine the range of financial services that the user of the remote terminal may expect to gain access to.

For example, in one preferred embodiment the progress of a transaction may be allowed or refused in conjunction with the present invention depending on the particular type of terminal employed by a user. Different types of terminals and communications equipment have differing levels of security facilities some of which can allow unauthorised persons to receive and interpret communications, giving them the potential to fraudulently execute a transaction with a user's financial details.

In a preferred embodiment each financial transaction which may be executed or processed in conjunction with the present invention may be assigned a particular type. The type of transaction will preferably be determined by the significance or liability involved to a user if the transaction could be completed by an authorised person. For example, one-off bill payments to an assigned payee associated with the user may be provided with a different transaction type to direct electronic transfers of funds to any indiscriminant third party bank account. Different transaction types may be allowed for more secure types of terminal (such as for example WAP enabled 106880NZ_DPCS_999.doc 16 cellular telephones), while the same transaction can be disabled for the more basic forms of terminals (such as voice only cellular telephones or land lines).

In a further preferred embodiment each financial transaction that occurs within the system may be matched against limits or regulated in some way so as to monitor and prevent fraudulent use of the system.

In yet another embodiment of the present invention monitoring software or processes may also track historical transaction activity for a particular user. Such monitoring algorithms (also known as "scoring engines") can monitor transactions processed in association with a particular user to detect irregular usage patterns or patterns that indicate the potential for fraud or unauthorised use of financial details has occurred. Such monitoring algorithms may disable further transactions being made in association with a particular user if such potential fraudulent activities are detected.

According to a further aspect of the present invention there is provided a method of registering a user with a financial transaction processing system, said user having been issued with a token by a financial institute, said token being used to facilitate financial transactions the method of registering a user being characterised by the steps of: i) receiving token information associated with the token issued to the user requesting registration, and ii) receiving an institution authorisation code from said user, said authorisation code being used to make a valid identification of said user, and iii) receiving at least one address attribute associated with a remote user terminal to be used by the user to access the financial transaction processing system, and iv) generating and/or receiving an access code to the user to allow access to the 106880NZ_DPCS_999.doc 1 7 financial transaction processing system.

According to a further aspect of the present invention there is provided a method of registering a user with a financial transaction processing system, said user having been issued with a token by a financial institute, said token being used to facilitate financial transactions the method of registering a user being characterised by the steps of: i) receiving token, information associated with the token issued to the user requesting registration, said token normally being used by said financial institute to identify financial details of said user, and ii) receiving an institution authorisation code from said user, said authorisation code being used to make a valid identification of said user, and iii) receiving at least one address attribute associated with a remote user terminal to be used by the user to access the financial transaction processing system, and iv) assigning or receiving an access code to the user to allow access to the financial transaction processing system.

According to a further aspect of the present invention there is provided a method of registering a user substantially as described above wherein said registration method occurs without the user having to communicate or disclose any financial details identified by the financial institution using the token information associated with the token issued to the user.

According to yet another aspect of the present invention there is provided a method of registering a user substantially as described above wherein the assigned access code is generated for and communicated to the user.

According to yet another aspect of the present invention there is provided a method 106880NZ_DPCS_999.doc 18 of registering a user substantially as described above wherein the assigned access code is generated by the user and communicated to the system employed to implement the present invention.

According to a further aspect of the present invention there is provided a method of registering a user with a financial transaction processing system substantially as described above, wherein said institution authorisation code is adapted to authorise transactions to be completed in conjunction with the token issued to the user.

According to a further aspect of the present invention there is provided a method of registering a user with a financial transaction processing system substantially as described above wherein an automatic teller machine is used to receive the token information and institution authorisation code.

According to yet another aspect of the present invention there is provided a method of registering a user with a financial transaction processing system substantially as described above wherein the institution authorisation code is adapted to facilitate point of sale financial transactions in conjunction with the token issued to the user.

Preferably the present invention may employ tokens issued by existing or established financial institutions, where these tokens are used by the customers of such institutions to facilitate financial transactions. Preferably the transactions involved may be point of sale transactions where the token provides the financial information required to execute a transaction between the customer or user involved and vendor of goods or services.

Those skilled in the art should appreciate that a financial institution as referred to throughout this specification may be defined as any entity, group, or association which provides financial services. Such institutions may provide standard banking facilities and/or additional credit or loan facilities to customers or members - and hence will be issuing tokens to users or customers which allow access to or which can 106880NZ_DPCS_999.doc 19 facilitate the execution of financial transaction. Furthermore, a financial institution as discussed in accordance with the present invention may also employ, implement or run the financial transaction processing system provided in accordance with the present invention if required.

In a further preferred embodiment, a token used in the registration process may be an electronic funds transfer point of sale (EFTPOS) card. EFTPOS cards are well known in the art and commonly employed by the customers of financial institutions to execute financial transactions using an EFTPOS transaction network. EFTPOS cards can also be used with automatic teller machines (ATM's) which are provided by financial and banking institutions to allow customers to have access to financial services or transactions outside of the normal operating hours of the institution or bank.

Reference throughout this specification will also be made to the token employed in the registration process being an EFTPOS card. EFTPOS cards are commonly used by a wide number and variety of customers of financial institutions to obtain access to debit balance, funds or credit facilities available through such institutions with these cards also being known as ATM cards, debit cards, EFTPOS cards or bank cards. However, those skilled in the art should appreciate that other types of tokens issued by financial institutions may also be used in conjunction with the present invention and references to EFTPOS cards only in isolation throughout this specification should in no way be seen as limiting. Furthermore, references will also be made to an EFTPOS card being composed of a small plastic sheet or token with a strip of magnetised material being applied to the surface of same or a smart chip imbedded in or applied to the surface of same. This magnetised strip or smart chip may have encoded specific information in relation to the particulars of the card where this information can be extracted to execute or implement a financial transaction. Again those skilled in the art should appreciate that alternative types of cards or 106880NZ_DPCS_999.doc tokens may also be employed in conjunction with the present invention and reference to the above only throughout this specification should in no way be seen as limiting.

Preferably in the primary or first stage of the registration process, token information may be received relating to the specific EFTPOS card or other type of transaction based token issued to a specific user. The token information received can be similar to that extracted from an EFTPOS card to facilitate a transaction using the EFTPOS network. In a further preferred embodiment, the token information received or extracted may include information encoded onto a magnetic stripe or smart chip mounted on the card. This magnetic strip or smart chip can provide specific information in relation to the card or token issued by a particular financial institution.

Preferably the token information received may encompass all information required to facilitate an EFTPOS transaction in addition to any information required to authenticate or validate a particular user's rights to access or implement such transaction.

For example in a preferred embodiment, token information may be supplied which consists of any number or combination of a unique card or token number, an account or customer number for the user or customer issued the token, a PIN block associated with a personal identification number or institution authorisation code, as well as ownership or user validation information either printed or stamped into the material of the token or card, or alternatively encoded into a magnetic stripe portion or smart chip of the card.

In a further preferred embodiment, an institution authorisation code may also be received as part of the registration process executed. This authorisation code may be used to make a valid identification of the specific user who wishes to register to gain access to the facilities or functions provided by the financial transaction processing system involved. In a further preferred embodiment, the institution authorisation 106&80NZJDPCS_999 .doc 21 code received may be the same code which authorises transactions to be implemented in relation to the token or EFTPOS card issued to the user. This institution authorisation code may preferably be used in conjunction with the card or token issued to authorise point of sale transactions.

In a preferred embodiment, where an EFTPOS card is employed as the user token involved, the institution authorisation code may be formed from or composed of the personal identification or PIN number issued to a user to authorise point of sale transactions. The level of security of information afforded by the use of an EFTPOS card and a PIN number as an access code meets the same standards, criteria's and protocols commonly accepted as secure by the existing financial institution which issued the card or token involved. These standards and protocols follow 3 basic rules: i) something the user has (EFTPOS card), ii) something the user knows (their PIN number), iii) something the user wants (to register).

By employing the EFTPOS card and associated PIN number as part of a user registration process, the financial institution issuing the card to their customer (who is registering to use the present invention) can be assured that security standards on a par with or equivalent to their own are being used to control the registration process.

Preferably as part of the user registration process executed, at least one address attribute of a remote user terminal may also be received. An address attribute can uniquely identify a specific terminal device to be employed by the user registering to access the financial transaction processing system, as discussed above. After details of a user's EFTPOS card have been received and the identity of a user has been confirmed through receipt of a correct PIN number, the address attribute or attributes 106880NZ_DPCS_999.doc 22 of a user's terminal may then be recorded. As discussed above, a cellular telephone number for a user's cellular phone can be employed as an address attribute where this phone number in combination with an authentic or valid access code will allow a user to execute transactions in accordance with the present invention.

Preferably once the above information has been received and the identity of the user wishing to register has been validated or confirmed, an access code may be generated and released to the newly registered user. This access code can be used in conjunction with the address attribute of the user's terminal to gain access to and facilitate the execution of financial transactions using the present invention. In a further preferred embodiment, the access code provided may be generated or chosen by the user and subsequently supplied to the components, equipment or personnel employed to complete the registration process. Alternatively and in other embodiments a random or secure access code may be generated and supplied to the user.

Preferably once the access code has been generated or received, the registration terminal will then calculate an access code offset. The access code offset is the numeric difference between the user's access code and the PIN number entered by the user to validate the token. By using this access offset code, it ensures that the system does not store the user's access code or the user's EFTPOS PIN number within its information store and therefore this protects the data within the information store from fraudulent use.

In this embodiment the provision of an access code offset avoids the need for the present invention to store a user's EFTPOS card PIN number or financial institution authorisation code, thereby eliminating the chance of unauthorised persons obtaining access to a user's card PIN number from the information store. Furthermore, financial transactions may be processed or forwarded to a financial institution for processing without validation of the access code supplied by a user. The access code 106880NZ_DPCS_999 .doc 23 supplied will in turn be used to generate an EFTPOS card PIN number which is in turn incorporated into a transaction quest forwarded to a financial institution. If the supplied access code is incorrect then the associated EFTPOS card PIN number generated will be incorrect and the transaction involved will be refused by the financial institution.

Reference throughout this specification will also be made to the present invention employing or storing an access code offset in relation to a particular user to in turn avoid storing the user's EFTPOS card PIN number or financial institution authorisation code. However, those skilled in the art should appreciate that other configurations of the present invention are envisioned and reference to the above only throughout this specification should in no way be seen as limiting.

Preferably once this registration process procedure has been completed, the token or card information received and the access code offset assigned to the user may be stored within the information store provided as part of the financial transaction processing system. The token or card information received may therefore form at least a portion of the financial information to be recorded and secured within the information store. Furthermore, the information store may also retain or associate as part of the financial information of a user both the supplied address attributed or attributes for a user terminal in addition to the access code offset generated from the access code assigned to the user. Upon receipt of a transmission or connection with the user's terminal, the information store may release financial information incorporating or including the token information received when a valid access code is supplied, and when the information store can determine that the communicating terminal has the same address attribute as that stored or recorded.

Preferably, the financial information secured by the information store may be used to allow the information store and associated hardware or software to emulate the functions of an EFTPOS terminal normally used to complete an EFTPOS financial 106880NZ_DPCS_999.doc 24 transaction. The information store can retain a 'virtual' record of the EFTPOS card which can be accessed by an authorised remote user to complete financial transactions. The virtual card recorded in the information store can allow the information store to act substantially the same as an EFTPOS terminal after an EFTPOS card's magnetic strip has been swiped and read.

Furthermore, in an additional preferred embodiment the user supplied access code and the stored access code offset can be used to generate or calculate the banking PIN number or institution authorisation code to be used to authorise the execution of an EFTPOS based transaction. The PIN number or institution authorisation code required can be calculated from the difference between the stored access code offset and the access code supplied by a user. A calculated card PIN number can then be used as part of the payload of a financial transaction to be processed by a financial institution.

In a preferred embodiment an automatic teller machine or ATM may be used to receive token information from a user wishing to register to use the financial transaction processing system discussed above. An ATM machine normally includes a magnetic swipe or stripe card reader or smart chip card reader which can be employed to extract or retrieve the token information required as part of the registration process. Furthermore ATM machines are generally housed or located within relatively secure locations to prevent tampering with same.

In a further preferred embodiment an ATM machine may also be employed to receive the institution authorisation code or PIN number from a user associated with the particular EFTPOS card or token read by the ATM. Again existing banking or financial institution infrastructure already employed by the ATM machine may be used to check the received PIN number against records held by the financial institute to make valid identification of the user wishing to register. Existing hardware or components employed in the design and construction of an ATM machine (such as a 106880NZ_DPCS_999.doc 25 key pad) may be employed by a user to supply a PIN number or institution authorisation code required as part of the registration process.

In a further preferred embodiment an ATM machine may also be adapted to receive the address information or attribute associated with the particular terminal device a user wishes to employ. Again a keypad or other similar type of hardware or components may be employed in conjunction with the ATM machine to receive such an address attribute or attributes as part of the registration process.

In a further preferred embodiment an ATM machine may also be adapted to generate or receive the access code a user wishes to employ. Again a screen or keypad or other similar type of hardware or components may be employed in conjunction with the ATM machine to receive, deliver or assign such access code as part of the registration process.

In a further preferred embodiment an ATM machine may also be adapted to generate an access code offset. For example, and as discussed above, the access code offset may be calculated from the difference between the entered card PIN or institution authorisation code and the access code assigned to the user, where the access code is either generated by the ATM machine or alternatively by the user.

Reference throughout this specification will also be made to an automatic teller machine or ATM being employed by a prospective user to register for access to the financial transaction processing system provided. An existing ATM machine may be employed to read card or token information, receive a institution assigned PIN number to validate the identity of the user and to subsequently receive an address attribute of a user's terminal and to issue or receive an access code to a user and to calculate an access code offset.

However, those skilled in the art should appreciate that other components, hardware or systems may also be employed and reference to the above only throughout this 106880NZ_DPCS__999 .doc 26 specification should in no way be seen as limiting. For example, standard car readers or keypads available to the counter or branch staff of a financial institute or bank may be employed, as potentially could existing EFTPOS terminals used by merchants or vendors of goods and services.

The present invention may provide many potential advantages over the prior art.

The present invention may enable a user to execute point of sale transactions from a remote location. A number of convenient remote terminal devices such as cellphones or PDA's may be employed by the user to participate in a remote EFTPOS transaction for example, with the user being provided with secure and convenient access to these types of transactions.

Furthermore, the registration system discussed above improves a security of access to these transactions, as existing financial institution and banking security procedures are implemented to ensure only authorised users have access to the present invention.

In addition the registration system discussed above allows a user to be registered without the user having to disclose or provide confidential financial details or information. The card or token issued to a user may be employed to access such sensitive information without said information needing to be written down, transmitted or otherwise disclosed as part of the registration process.

The present invention may also provide a financial transaction processing system which can be configured in such a way that if the stored information was compromised, an unauthorised person could not use the gained information for fraudulent purposes through the availability of only user access codes offsets as opposed to institution authorisation codes.

The system implemented in conjunction with the present invention may also provide significant advantages and improve facilities over the existing prior art. The present 106880NZ_DPCS_999.doc 27 invention may allow remote EFTPOS based transactions to be executed in real time to allow the user with convenient mechanism for completing a transaction, similar to that currently available widely for credit cards. Furthermore, in one instance, the present invention may be applied to allow a user to execute a financial transaction to purchase the rights to use a credit card or credit card number assigned a specific credit value. The credit card number and associated credit purchase may be used (for example) with on-line internet based commerce websites known to accept only credit card numbers as a payment option.

Furthermore the present invention may also allow remote EFTPOS transactions to be executed in real time. The system, apparatus and software employed in conjunction with the present invention may resemble or build an EFTPOS transaction and forward same to a financial institute for processing while the user waits. An immediate answer as to the availability of said transaction can then be supplied back to the user again in real time while in turn the transaction required is processed.

Brief Description of Drawings Further aspects of the present invention will become apparent from the following description which is given by way of example only and with reference to the accompanying drawings in which: Figure 1 illustrates a block schematic diagram of components employed to provide a financial transaction processing system in accordance with a preferred embodiment, with these components being distributed over a number of remote locations, and Figure 2 shows a sequence diagram for communication and information flows executed by a financial transaction processing system provided in accordance with an alternative embodiment, where the system is used to facilitate an EFTPOS transaction, and 106880NZ DPCS 999.doc 28 Figure 3 shows a sequence diagram for communications and information flows executed by a financial transaction processing system provided in accordance with an alternative embodiment where the system is used to register a new user to use the system.

Figure 4 shows generally the components required to securely register a user to enable them to make use of the access code system.

Best Modes for Carrying out the Invention Figure 1 illustrates a block schematic diagram of components employed to provide a financial transaction processing system in accordance with a preferred embodiment. These components include a users telephone 101, connected via an interface server 102 to an EFTPOS terminal server 103. This latter detects that the call is from a specified telephone and in conjunction with an access code supplied by the user queries a virtual card provider 104 and track 2 database 105. The track 2 database stores all the information on track 2 of a standard card and releases this information for a financial transaction process to occur on EFTPOS transaction processor 106 only if the user is calling on a specified telephone with an access code which is approved for that telephone.

The majority of the components of the financial transaction processing system provided are located within a secure hosting environment with physical access to same being restricted to authorised persons only. The system provided includes an EFTPOS transaction server (ETS), a track-2 database (T2DB), and a virtual card data provider (VCD) all located within the secure hosting environment provided. The transaction processing system also includes an interface server (EIS) located outside of the secure hosting environment which is associated with a telecommunication service providers network. The interface server provides a link or connection between the infrastructure of a telecommunications network and the EFTPOS 106880NZ_DPCS_999.doc 29 terminal server located within the secure hosting environment.

The transaction processing system also includes links to an EFTPOS transaction processing system or network (ETSL) within the secure hosting environment, where the ETSL also normally receives and processes EFTPOS transactions from other sources.

The telecommunications network provides a communications channel between the transaction processing system and a remote user terminal, shown in this embodiment as a cellular telephone. The cellular telephone is employed by a user to execute EFTPOS based financial transactions.

The track-2 database (T2DB) is adapted to form the main portion of the information store employed in conjunction with the present invention. The IS and ETS facilitate the management of communications with other external elements systems while the VCD employs decryption and security algorithms to generate an institution authorisation code or an institution PIN number for a particular user. This code is used to implement a standard EFTPOS transaction within the secure hosting environment.

Figures 2 and 3 show in more detail both the use of the system to execute EFTPOS based financial transaction and also the registration of a new user with the system to authorise such a user to execute EFTPOS based transactions.

As shown with respect to figure 2, the first steps used to implement a financial transaction occur at stages 1 and 2 where a user creates a session with the system by dialling a specific number with their cellular phone or remote terminal. At stage 2 the telecommunications network sets up the call required, and at stage 3 connects the call to the interface server employed.

At stage 4 the Interface Server obtains the telephone number of the calling cellphone 106880NZ_DPCS_999 .doc 30 (being the terminal's address attribute) using caller line identification technology. At this stage the interface server then requests that the user key in an access code where this access code, when keyed in is transmitted through the network to the interface server. At this stage the user is also prompted to enter in details of the transaction they wish to implement, such as an account number or designated payee to which funds are being transferred in addition to the amount to be transferred and the date of transfer. Lastly, once all the information required to implement the transaction has been received, this information "payload" from the interface server is encrypted and at stage 5, transmitted to the EFTPOS transaction (ETS) located within the secure hosting environment.

At stage 6 the ETS decrypts the received payload from the IS and applies an alternative encryption (known as 3DES to those skilled in the art) to this information and subsequently transmits same to the track-2 database (T2DB). At stage 7 T2DB receives encrypted information from the ETS and decrypts same using the 3DES encryption scheme employed by the ETS. The decrypted information is then used to address and access financial information stored by the track-2 database with respect to the specific user contact in the system. The T2DB then returns the stored financial information associated with the particular user identified by both the calling cellphone number and access code provided. In the embodiment discussed information from the second track of the magnetic stripe card provided in the identified user's EFTPOS card is returned encrypted to the ETS, again using the same encryption scheme originally employed by the ETS.

At stage 8 of this process, the information returned from the T2DB is then decrypted by the ETS, thereby providing the ETS with essentially the same information available to a standard merchant EFTPOS terminal after a customer's EFTPOS card has been read and the customer has entered the secure EFTPOS card PIN number.

The secure EFTPOS card PIN is calculated at stage 9 in conjunction with the virtual 106880NZ_DPCS_999.doc 31 card data provider (VCD) discussed with respect to figure 1. The track-2 data retrieved from T2DB includes access code offset data which indicates a value by which the user's access code is offset from the user's EFTPOS card PIN number or financial institution authorisation code. This allows a user's EFTPOS card PIN number to be calculated in real time for use in a transaction without the need to have this PIN number stored and potentially available for compromise and use by an unauthorised person.

The calculated card PIN can then, in combination with received details of the EFTPOS card number and a PIN offset coded into said card, be used to construct a standard EFTPOS transaction. This transaction payload can then at stage 9 be transmitted to the standard EFTPOS transaction processing system (ETSL).

The ETSL then processes the EFTPOS transaction and forwards the transaction to the user's financial institution and returns a response from the financial institution at stage 10 indicating that the transaction proposed was accepted and processed, or declined. Subsequently at stage 11 the ETS system returns the results of the transaction submission to the interface server including any particulars of the transaction processed.

At stage 12 a utility database (UDB) of, in this instance, the payee involved with the transaction is then updated to indicate that a transaction is being processed for the user identified.

At stage 13 the interface server subsequently generates a response message to be transmitted back to the user's cellular phone, which at stage 14 gives the user feedback regarding the success or otherwise of the transaction proposed.

Figure 3 shows in a similar form to figure 2, a sequence of communications or information transmissions implemented in conjunction with the present invention to register a new user and authorise same to use the financial transaction processing 106880NZ_DPCS_999 .doc 32 system discussed above.

In a first stage of this process the terminal shown or discussed is an automatic teller machine which includes a swipe card or magnetic strip card reader or smart chip reader. This reader is used at stage 1 shown to read information encoded to a magnetic stripe or smart chip of a user's ATM card. At stage 1 the ATM is also used to receive via keypad a mobile telephone number for the user in addition to an access code selected by the user to be employed to use the financial transaction processing system. At this stage the ATM is also used to receive the ATM card PIN number, normally used by the user to implement a transaction using their own ATM card.

This information is then transmitted from the ATM machine to the standard ATM transaction processing network which is connected to ETSL or direct to the financial institution that issued the ATM card. The ETSL component in turn at stage 2 contacts the financial institution which issued the ATM card to the registering user and supplies the received ATM card PIN number to obtain a valid identification and authorisation for the user. At stage 3 the results of this identification or authorisation based on the PIN number supplied are returned by the bank systems, and an indication of the success or otherwise of the authorisation process is returned from the ETSL to the terminal ATM machine at stage 4.

Provided that the correct ATM card PIN number has been supplied by the registering user, stage 5 is then executed where the PIN offset is calculated by the ATM and the magnetic track-2 card data or smart chip data extracted from the user's ATM card by the ATM is transmitted to the ETSL system in the form of a pre-authorisation transaction request. In turn the ETSL system forwards this track-2 based "payload" information onto the visual card data (VCD) system and associated track-2 database (T2DB) employed in conjunction with the present invention. This payload information consisting of the financial information to be recorded in association with the registering user, which is processed by the VCD and T2DB at stages 5 and 6. 106880NZ_DPCS_999.doc 33 Once this required financial information has been successfully stored, the ETSL will be advised at stage 7 of this successful result and the ETSL will in turn return a result message at stage 8 to the terminal ATM machine to indicate to the user that they have been successfully registered for use with the financial processing system provided.

Figure 4 shows a block diagram of a terminal allowing the registration of user data in this way with a circuit board 120. A card read by magnetic stripe or chip reader 128 triggers presentation of a menu on screen 121, one of the menu options being registration of the user for remote transaction via an insecure link. Choice of this option allows the user to enter the required information under control of the software embedded in chips 123 (the standard base software) and 123a (the software for eliciting the telephone number and associated access code) into keyboard 122. This information is then transmitted in encrypted form, preferably DES encrypted, to the EFTPOS Terminal Server by communications chip 127 together with the track 2 information from the users card and the users bank PIN. The track 2 data is recorded in the track 2 database (T2DB). The information recorded includes a telephone PIN (TPIN) which is recorded in the form of an offset from the bank PIN. This offset PIN should differ from both the actual calculated PIN and from the PIN which is normally used by the user and which is also stored as an offset. Typically this TPIN would be entered twice to allow validation at entry.

Calculation of the offset may be carried out by the terminal at which the entry is done or at the destination. Any transmission of the PIN offset is required to be encrypted.

A single user may have several associated telephone numbers and TPINs, and the facilities associated with each may vary depending upon the inherent security of the telephone.type.

Aspects of the present invention have been described by way of example only and it should be appreciated that modifications and additions may be made thereto without 106880NZ_DPCS_999.doc departing from the scope thereof.

Claims (11)

WHAT WE CLAIM IS:

1. A method of creating stored transaction authorisation information at a remote location comprising commencing a secure transaction session at a secure terminal, reading user information from a user transaction card in the secure terminal and remotely securel y storing the information, remotely securely storing information relating to a user terminal address attribute for an authorisation terminal to be authorised by the user to initiate financial transactions, and generating and securely storing a valid user code as a PIN offset to identify a PIN to be used from the authorised terminal type.

2. A method as claimed in claim 1 wherein the secure terminal is an ATM or EFTPOS terminal.

3. A method of authorising a financial transaction from a financial account comprising storing in a secure database information sufficient to authorise a transaction, this information including information allowing the calculation of a Personal Identification Number (PIN) and a PIN offset differing from other PIN offsets of that account holder, storing in said database information identifying a terminal device usable by an initiator of a financial transaction, receiving from that terminal device a transaction authorisation which authorisation contains a PIN, detecting whether the received PIN is offset the specified amount from the calculated PIN , and authorising the transaction when the PIN is offset by the correct amount.

4. A financial transaction processing system accessible by a remote user terminal, said terminal having at least one associated address attribute, the system including an information store adapted to secure financial information sourced from a plurality of remote users, the financial transaction processing system being characterised in that a user's financial information is released by the information store to allow a remote financial transaction authority to process a financial transaction upon receipt by the information store of a valid user terminal address attribute and a valid user access code.

5. A financial transaction processing system as claimed in claim 4 wherein the terminal is a telephone and the terminal address attribute is the telephone number ^ INTELLECTUAL PROPERTY | OFPICF OF N.Z 10 MAY 2004 106880NZ_TIER_20040507.doc / pc RECEIVED -36- of the terminal, and the user access code is a PIN.

6. A method of processing a financial transaction using the financial transaction processing system substantially as claimed in claim 4, said method being characterised by execution of the steps of: receiving a user terminal address and user access code, receiving transaction information, determining a transaction type from the received transaction information, and releasing a user's stored financial information to allow a remote financial transaction authority to process a financial transaction if a valid user terminal address attribute and valid user access code are received and if the transaction type determined is allowed for the terminal type of the remote user terminal.

7. A method as claimed in claim 6 wherein the allowable transaction types differ for differing terminal types.

8. A method as claimed in claim 6 wherein the allowable transaction limits differ for differing terminal types.

9. A method as claimed in claim 6 wherein the user terminal address is a mobile telephone number and the user access code is a user PIN.

10. A method as claimed in claim 6 wherein the user terminal address is a network card address and the user access code is a PIN.

11. A method as claimed in claim 6 wherein the authorised transaction may be a transaction which repeats at specified intervals, the repetition being instigated by scheduled procedures which again release the user stored financial information. Pipers Attorneys for EFT WIRE LIMITED 10S880NZ TIER 20040507.doc Page36 INTELLECTUAL PROPERTY GFRCF OF NJ.Z 10 MAY 2004 RECEIVED 106880NZ_DPCS_999.doc 37 ABSTRACT Financial transactions are authorised over a mobile phone or similar remote unit by recording the data required for a transaction in a secure database, registering the users phone number, and registering a PIN differing from the users other PINs to authorise a transaction only from the registered phone number. Limitations may be placed on the type of transactions available from various phone systems. INTELLECTUAL PROPERTY OFFICE OF N.Z. 1 3 JAN 2004 RECEIVED