GB2511279A - Automated multi-factor identity and transaction authentication by telephone - Google Patents

Abstract

A system that obtains multi-factor identity and transaction authentication securely through the Public Switched Telephone Network from persons on their telephone, whose telephone number has been registered on the system. Registration is achieved by the person calling the system from the phone number to be registered and following system generated instructions to register an accompanying PIN. Thereafter the system can be utilised to obtain identity and transaction authentication from such persons, comprising: calling the registered phone number of the person from whom authentication is required, on answering the call, transaction details requiring authentication are delivered by the system to the call recipient by automated spoken means, correct entry by the call recipient of the registered PIN for that phone number authenticates the identity of the call recipient and authenticates the transaction details that were delivered. The PIN entry may be via Dial Tone Multi-Frequency (DTMF) or Asynchronous Speech Recognition (ASR).

Description

Automated multi-factor identity and transaction authentication by telephone.

This invention relates to obtaining Multi-factor Authentication of a persons identity or of details of a transaction made by person, by using any ordinary telephone connccted to the PSTN (Public Switched Telephone NeLwork) registered with the system of this invention in the manner provided as described herein.

There is an ongoing need for enterprises and persons who transact business to rapidly obtain reliable authentication as to the identity of any person they have or intend to transact business with or to rapidly authenticate transaction details in whole or in part. Transactions include not only sale or purchase transactions, they include granting persons access to an enterprises public or private internet or intranet site. Such persons include prospective customers, existing customers and the enterprises own employees.

A multiplicity of methods of authenticating the identity of such users is currently employed.

Under the present art all terms of authentication, obtained by whatever means, can he generally classified into one of three authentication factor categories. These 3 categories are: Category 1: something the user is known to know (e.g. a password, PTN); Category 2: something the user is known to havc (e.g. a hardware device, an ATM card, smart card, such items collectively referred hereinafter to as "tokens"); and Category 3: something the user is known to be (e.g. a biometric characteristic, such as thc users fingerprint, retinal form or the uscrs DNA).

Authentication of any such factor occurs whcn an authenticating factor of a bone fide user which is also known to the authcnticating party, is requested by thc authenticating party from thc person purporting to be thc bonc fide user. The factor requested is presented by somc means to the authenticating party and if the factor presented by the person matches that known by the authenticating party to he that of the bone [ide user, authentication of that factor is deemed to have occurred.

Under the present art authentication can also he generally classified as weak or strong: weak authcntication occurs whcn authentication has been obtained from only onc catcgory of factor whereas strong authentication of a user requires authentication from two or more factor categories. Strong authentication is also refcrred to as Multiple (or multi) Factor Authentication.

II is universally acknowledged that strong auLhenticaLion is always preferable.

Multiple instances of one category of fader only provides weak authentication by Ibis definition, regardless of however inherently difficult the particular instances of the factor may he to falsify or obtain by a third party. For example, requesting a password, a PIN and the answer to a secret question would only constitute weak authentication, as these are all merely multiple instances of one factor category i.e. authentication fader Category 1.

The present art has concerned itself with ways and means of both improving the inherent validity and security of individual categories of factor (for example by requesting some but not all of a PIN or password to make it more difficult for the entire PIN or password to be obtained by &audsters) and more particularly within the context of the present invention, in attempting to devise innovative means whereby two or more factor categories can he authenticated at the same time, typically using a special system or device designed for that purpose.

Thc problem is that such systems and devices that havc attempted to do this have proven to bc prohibitively expensive and are often slow sincc the user is typically required to perform a scries of tasks, somctimcs involving complex proccdures or remcmbering multiple passwords ctc., which can have the added side cffect of antagonizing the user. LJnlcss thc user is highly motivated, these systems can be therefore be commercially counterproductive in that they may be time consuming and arduous, unintcntionally creating psychological entry barricrs to actual and prospective bone fide users. In every instance where authentication is desirable therefore, a balance has to he struck between risks, time delays, financial costs and benefits.

Inventions that purport to provide such strong (multi-factor) authentication in a timely manner typically involve the provision of innovative devices that attempt to combine two or more categories of authentication factors. This has been attempted fbr example by inventions that involve thc provision of a tokcn (providing Category 2 authentication) which generates access codes that require the input of a PIN or password from the user (providing Category I authentication). Access tokens may also only function after they obtain known user biomctric information from the user, such as a fingerprint (providing Category 3 authentication) or devices that require both a PIN or password and biometric information or a multiplicity of such factor combinations. In general, the stronger the authenticity required, the greater the complexity and cost of the authentication device.

As the frequency of instances where authentication is needed from ordinary persons increases, primarily as a result of more business being Iransacted online, individuals are becoming required to present a plethora of differing PIN's, passwords and hardware tokens. This raises the problem as to how any such individual memoriies passwords and PIN's, which often have to be changed periodically and how individuals remember how to use hardware tokens that they may need to use only infrequently. Furthermore the loss, theft or damage of said tokens raises further logistical and administrative problems.

The use of hardware or software tokens as an authentication means has fallen into question. For example, when a persons idcntity is authcnticated with refcrcnce to a fingerprint or PiN by cntry onto a device which is also acting as a token, unless at that precise instancc thc token is authenticated as being in the posscssion of the bone fide user, thc token has merely acted as a fingerprint or PIN input device, not as an authenticating token. in effect, such tokens providc falsc multi-factor authcntication.

For any tokcn to act as a bonc fide Category 2 authentication means, it is gencrally acknowledged that authentication that the token is in the actual possession of the bone fide user at the precise moment the token is employed, must he obtained, as the token itself may have been stolen or replicated. Achieving this has proven to he highly problematic. Virtually all such devices can he stolen without the users know-ledge, since the users typically only employ these devices infrequently.

Many tokens arc also susceptible to Man-In-the-Middle (Ml'I'M) attacks. MITM attacks arc usually achieved by the fraudsters misrepresenting themselves as a hone fide authenticating parties and the user unwittingly provides the fraudsters with their entire authentication means.

Jior example, a fraudster may provide a fake AUM into which the bone fide user presents their ATM card to obtain cash. The fraudster now-has physical possession of the users card. The user is then asked to enter their PIN and in so doing, has now also unwittingly provided the fraudsier with the card's PIN. The cards entire security authentication has now been wholly compromised.

MITM attacks are also easy to achieve on the internet often by a means known as phishing whereby for instance, a fraudster creates a fake web site that is a copy of a hone [ide site to which the user has been directed. The user may unwittingly provide payment card details, site passwords or access codes etc. just as they would he required to give at the bone fide site, unaware that a fraudster is acquiring these details using a fake site for this purpose.

Inventions in the present art have attempted to strengthen the inherent security of the factors derived from such tokens. For example credit and debit cards have employed an embedded microchip that stores an encrypted PIN in preference to the PIN being encoded on a magnetic strip: this innovation is called Chip and PiN and has made it harder to clone such cards.

Ilowever, the inherent weakness of the card payment system remains its susceptibility to MlIM: so unless the possession of the card by the user is determined the instant it is used, Chip and PiN provides only weak authentication, even though the PiN derived from it is arguably inherently more secure.

Individual category factors have inherent strengths that can be utilized and weaknesses that have to be overcome. Category 1 factors such as PIN's or passwords are simple and inexpensive to obtain and verify, but are also relatively easy for fraudsters to obtain.

The provision of tokens that constitute a Category 2 authenticating factor raise cost and logistical problems that can prove prohibitive to their deployment: the devices have to be designed, produced, distributed and the means to read or accept them provided and supported.

Detcrmining proof of possession of the token by thc bonc fidc user at the instant it is uscd is highly problematic and there is the issue of fraudsters heing able to create copies of said tokens.

If a token can bc copied, unless the authenticating party can instantly recognize that thc token in use is a copy and not a bone fide teken, the authenticity of any derived factor from Lhe Loken must he called into question.

The use of Category 3 -biometric -factors is now considered questionable and even inadvisable in some instances as an authentication means. Some biometric information is relatively easy to copy, including fingerprints and voice patterns. however, other biometric data -such as retinal scans or even bodily fluids -carry the sinister potential risk of actual bodily harm from determined thieves and fraudsters intent on acquiring the necessary bodily component.

Biometric authentication systems are also costly. The combination of their high cost and the physical risk of harm they engender have cafled this authentication facter as a viable authentication means into question.

Tt can he seen therefore, that a means of obtaining strong authentication from users that would not require the production, distribution and support of any form of token by enterprises for whom such authentication is desirable, would be highly commercially advantageous.

The cellular phone is potentially a highly robust Category 2 authenticating factor but no viable way to take advantage of its inherent capabilities has been utilized under the present art. Cellular phones have a number of built in security measures that make them resistant to copying since, for example, the Subscriber identity Module (SIM) Card would have to be cloned. Furthermore, should a S1M Card be cloned, if 2 identical S1M Cards are presented onto a subscriber's network, the network operator can he immediately alerted to this and service to that number terminated.

Since the user's phone is entirely their personal property and phones are used frequently, its loss or theft is usually quickly acknowledged. The owners of cellular phones are highly motivated to maintain the serviceability of their personal phone and so they are constantly vigilant as to its whereabouts: this is in stark contrast to using special tokens to enable users to access online locations, when these are frequently misplaced due to infrequent use.

Smart phones -cellular phones that have computing capabilities have been proposed as Category 2 Lokens. however, if the phone itself is used as a Loken, loss or theft of Lhe phone can invalidate any security and any authentication obtained using it in the exact same way as any conventional hardware token such as a credit card. Smart phones are becoming highly sophisticated and valuable and are frequently the target of theft.

Use of cellular phones for authentication purposes under the present art has been achieved principally by utilizing the built in ability of cellular phones to send and receive Short Message System (SMS or "text") messages. however, the SMS system is inherently insecure and wholly inappropriate for strong authentication purposes. It is a simple task to both intercept SMS messages and fraudulently present an SMS message onto subscriber networks.

The telephone has however, been used to authenticate users' identities since telephones have been in existence: the simp'e, long proven, most secure and robust way to obtain strong authentication is for a person acting on behalf of the party seeking to authenticate a users identity to call the user on their known phone number, ask them for personal information and/or a password to authenticate their identity as the user and then ask them if they are performing the transaction under question. However, this is commercially non-feasible except in exceptional circumstances, given the excessive numbers of such instances where this could usefully be applied and the high human cost of this process. it would therefore be desirable for there to be an automated means of achieving this, whereby strong authentication could be achieved with a high degree of security and through a separate channel to that used to perform the transaction, rendering M1'IM attack implausible.

There is provided, in accordance with embodiments of the present invention, a system and method that enables a users telephone to act as a means for enterprises to obtain strong authentication from that user tbr transactions purportedly made hy that user with the enterprises system.

The user registers their phone number and associates a PIN to that number by calling a telcphone number provided by the system of this invention for this purpose from their phone and interacting wilh an IVR system provided by this syslem thai enables the user lo effect registration of their phone number and to create a PIN.

In the subsequeni course of entering into a transaction with the enterprises system, said system determines thai strong authenlication be obtained of the users idenlity or for strong authenticalion he obtained for said users transaction, in whole or in part. The enterprise system transmits a requesi for an authenlication call in a predetermined aulcmaied manner and formal to the syslem of this invention. Said request provides inter alia, sufficient information Lo enable Ihe system of Ihis invention to identify the phone number of the user as previously regislered and as a result, retrieve from the sysiem Ihe PIN registered by the user. Said request also provides all the information needed by the system of this invention to generate an automated phone call to the users phone and by automated spoken means, interact with the user on their phone and in said interaction, inthrm the user what is being authenticated by the call and to request the user authenticate same by entry of the PIN known to be that previously registered by the user. the user affects the input of said PIN by input means on their phone and the system of the invention can determine from same whether the PiN input by the user is the same as that known by the system to be associated with said users phone number and known by thc bone fidc user. the success or failurc of this determination is communicated by automated means back to the enterprise systcm, which can then determine the appropriate next action.

With the advent of the global cellular phone nelwork, personal ownership of a mobile or cellular phone has proliferated worldwide. This invention advanlageously provides for any phone of any kind on any nelwork to function as a slrong authenticalion means at the delerminalion of any enterprise syslem. The phone number provides an authenticalion loken that costs nothing for said enierprise to physically deploy, support or maintain. By separating the transaction entry or request channel (typically the internet) from the channel through which authentication is obtained (typically thc PSUN), this invcntion provides a strong authentication means that is highly resistant to man in the middle attacks; provides that the users telephone device thnction as a secure PiN entry token that is inherently resistant to being compromised by being copied; an authenlicaLion Loken thaL by virLue of the phones conslani use and the high level of user awareness as to said phones' physical localion is a loken that is less likely V he losi or stolen without the users knowledge and which provides a simple and convenient means for the user lo provide said authenlicalion.

It can be seen that the invenlion ulilizes the user's phone number and not Ihe users phone as an authenticaling factor, by associaling the phones number -nol the phone -with a PIN known only to the phones user. A phone number is not a Langible enlity unlike a hardware loken: ii only assumes a presence when the subscriber accouni associaled wilh it is active and the phone number is connecled V the PSTN through a physical fixed line or mobile lelephone device.

Every phone number has the inherent advanlage of being unique. This innovaLive use of the phone number and not the phone device as a token by this invention resolves a number of highly problematic issues associated with the provision of tokens as authenticating factors: a phone numher cannot be lost or stolen in the way a phone device can, as the phone number is separate to the phone device. Loss or theft of the user's phone does not compromise the inherent security of this invention since the PiN is both stored and validated remotely from the users phone on the system of this invention and is not recorded, validated or stored on the phone device.

Ibis invention works for any phone number connected to the PSIN on any kind of telephone device and does not require a cellular phone with storage or computing capabilities. the phone number as a "token" is not device specific whereas all other forms of token are actual physical devices.

The phone number as a "loken" only comes into exisience at the precise instance when the phone number is called by the inveniion of this sysLem which simulianeously solves the fundamenial problem of authenticaling thai ihe bone fide user has actual possession of the token at the instant authentication is being obtained because only when the PIN is correctly entered has the phone number been authenticated as being uscd by thc bone fide uscr. Both factors arc therefore mutually validating: each validates the other, which resolves the problem of determining that both factors arc valid thc instant authcntication is rcquircd.

This invention has therefore found a unique an innovative way to simultaneously authenticate 2 wholly independent factors in an inler-dependani manner at the exact instant authentication is requested: these 2 faclcrs being the users phone number and the users PIN.

The public telephone system has a number of built in security measures that further enhance the utility of this invention. Cellular phones are inhereniJy resistant to cloning. however, shoukl a users cellular phone he cloned, service provider systems can identify that 2 cellular devices with the same phone number are active on the network and service to the phone number suspended, thus rendering both phones redundant as authentication devices using this invention.

Since the users phone is typically their personal property the user is highly motivated to maintain the serviceability of their phone. There is therefore no need for the authenticating party to provision or maintain tokens specifically for the purpose of acquiring strong authentication from the user, sincc the uscrs own phone fits that purpose undcr this invcntion.

It can therefore be seen that this invcntion providcs a means whereby thc samc user phonc number can bc uscd by many unrelated cnterprise systems as a strong authentication mcans for their individual systems, thus climinating the nccd for thc user to have multiplc individual security dcviccs for cach systcm they use that requires strong authentication of their identity.

A more complete understanding of the present invention may he derived by referring to the detailed description of the invention and to the claims, when considered in connection with the Figures.

FIG 1. Describes the pre-existing transactional relationship between a User and an Enterprises Business information System (ElliS) with which the User transacts from timc to timc and the pre-existing relationship between said EBTS and the Telephone and PIN Authentication (TAPA) System in accordance with one embodiment of the present invention.

FIG 2. Describes the process whereby the User affects TAPA Registration with the TAPA System in accordance with one embodiment of the present invention.

FIG 3. describes the complete User Transaction Authentication process from start to finish in accordance with one embodiment of the present invention.

There are various embodiments and configurations for implementing the present Invention. One such embodiment is described fully in FiG's 110 3.

FIG 1. schematically represents one embodiment of this invention where a User 101 engages in User Transactions I 12 from time to time with an Enterprise Business information System (EBIS) through an Enterprise User Tnterface (EUI) 113 provided by the EBTS 1 1 5 for that purpose.

Examples of EBIS 5 115 include banking and payment systems, email systems, employer intranets, internet retailer, service and information provider internet sites, corporate intranets and remote systems and so forth. It can be seen that a multiplicity of such relationships may exist between any one Ii ser 101 and any number of such EBIS s 115 and as commerce online proliferates, the number and variety of these relationships continue to increase.

Examples of Enterprise User interfaces (FIJI's) 113 employed to facilitate the interaction of Users 101 with the ElliS 115 include web pages, client applications resident on the users personal computer or smart phone, online card payments gateways, electronic locks on a door to a physical location with some manner of data entry device, electronic point of sale (ePOS) terminals that may incorporate payment means such as card readers or Near Field Communications (NFC) input terminals or the like and also actual persons employed by the enterprise to interact with Users I UI either face to face, by telephone or by online interaction or thc like. It can bc sccn thcrcforc that a plurality of such Liii's 113 may bc providcd by thc same FilLS 115 and that many different kinds of User Transactions 112 maybe affected by any User 101 with any EBIS 115. This invcntion providcs that any EBIS 115 can obtain strong authenticaLion for any such User Transaction 112 in whole or in part.

Under some embodiments, details of said Transactions 112 are encapsulated by the EUI 113 ink Transaction Requesi (TR) Data 118. This is information specifically associated with the Transaction 112 and may include the User 101 name, password, purchase/sales prices, payer or payee information, access permission requests to unlock an actual door to gain physical access to a physical location as well as access to online systems through secure servers or the like. In one embodiment, this TR Data 118 is delivered to the EBIS 115 via a Network 114. Examples of such Networks 114 include the internet, a wireless network, a Wide Area Network (WAN) or Local Area Network (LAN) or an electronic payments network such as that employed by credit and debit card payment providers.

On completion of the processing of said TR Data 1 IS, the EBTS 115 typically passes hack pertinent inthrmation to the hUT 113 in the form of Transaction Outcome (TO) Data 117 via said Nctwork 114 or directly. Examples of 10 Data 117 include granting acccss to a wcb sitc, displaying information that has been rcqucstcd, confirmation of acccptancc of data input, confirmation that a funds paymcnt has bccn madc, an clectronic rclcasc signal to a lock or whatcver response is pertinent to the User I'ransaction 112 the User 101 has entered or attempted, which may also include denial of or refusal to process the User l'ransaction 112 in whole or in part.

Under one embodiment the EBIS 115 includes an information storage means, the EBIS Database 116 which will contain User Data 121 pertinent to the identity of the User 101 and of particular relevance to this invention, TAPA Data 140, being information pertinent to enable the EBIS 115 to utilise the TAPA System 120 to obtain authentication from a User 101 when the EBIS 115 has determined that such a need arises and logs of interactions between the Ff15 115 and the TAPA System 120.

As shall be seen, in one embodiment the ElliS 115 -in order to utilise this invention -refercnees data stored by Lhe TAPA System 120 itself, including Call Scripts 150 as well as referencing the Users 101 Lelephone number sLored on the TAPA System Database 122 in the TAPA Register 206, this being a register of all the Lelephone numbers that have been registered by all Users 101 on the TAPA SysLem 120 and the associated PIN's. PIN's recorded on the TAPA Register 206 under embodiments where the TAPA System 120 is provided to the EllIS as a service, are typically noL accessible to the EBIS 115 as part of the security of the system.

Call Scripts 150 control the automated interactions between the TAPA System 120 and the User 101. This invention provides for the ElliS 115 to be able to create such Call Scripts 150 or for these to be created by the TAPA System 120 and for the ElliS 115 to reference these scripts when it requests that the TAPA System 120 call the User 101 to obtain authentication as will he more thily described hdow. By this means the Ff15 115 can determine the specific content of the interaction is between the TAPA System 1 20 and the User 1 0 I on its hehalil Under onc embodiment, the ElliS 115 is able to conncct to the I'APA System 120, typically via a secure Network 119, examples of which include the internct, WAN or LAN or the like.

Under some embodiments the TAPA System 120 is owned by the ElliS 115 and in another the TAPA System 120 is provided as a service or the like to the ElliS 115 by a third party. The manner in which the ElliS 115 communicates with the I'APA System 120 and the nature of the Network 119 through which they are connected will logically reflect the commercial relationship between the ElliS 115 and the lAPA SysLem 120: this invention provides for when the I'APA SysLem 120 and EBIS 115 are owned by the same entity and when they are not, when for example the TAPA System 120 is used by the EBIS 115 as a third party service: the exact form the architecture in all instances and all variations of same as will he obvious to any person of ordinary skill in the an.

In thosc instances where the EBIS 115 uses thc TAPA System 120 by way of a third party service, the TAPA System I 20 will have stored on the TAPA Database I 22, Enterprise Data 123 to enable the TAPA System 121) to reciprocally identify and interact with said EBIS 115 when it connects to and communicates with the I'APA System 120, whereas where the LBIS 115 and the TAPA System 120 are owned by the same enlity all the data stored on the TAPA System Database 122 would typicafly beheld on the EBIS Database 116.

FIG 2. is a figurative representation, under one embodiment, of an architecture that facilitates TAPA Registration Process. This registration having been already affected is a necessary precondition for the authentication of any User Transaction 112 utilising this invention. Said registration associates a PIN known by the User 101 with the Users Phone 201 number. The User Phone 201 number as referred to herein therefore refers to a specific phone number that can he so uniquely identified by the PSTN 202 and not the particular User Phone 201 device through which said number presents itself or connects to the PSTN 202 since SIM Cards are portable across multiple cellular phone devices.

Under one embodiment, lhr the User 101 to affect this registration, the User 101 calls the phone number of the I'APA System Interactive Voice Response (IVR) System 204 which is connected to the PSTN, from a phone using the Users Phone 201 number.

Under one embodiment said IVR System 204 has a number of capabilities that facilitate the operation of TAPA System 120 which includes but is not limited to the following: the 1VR System 204 is typically able to recognise the inbound phone number of a caller using CLI (Calling Line identification) detection technology; it can detect and recognise all forms of standard phone key pad entries including Dual lone Multi li-equency (DIMI) entries; it is able to deliver spoken messages thai have been pre-recorded; is able to generate speech from text presented (i.e. Text To Speech or TTS), it may have human speech detection, recording and recognition (Asynchronous Speech Recognition or ASR) capabilities; it is able to execute pre-designed Call Scripts 150 in whole or in part that manage, execute and determine the liming of said capabilities; it can both receive inbound calls and generate outhound calls hy automated means; it can obtain, proccss, storc and communicate such responses or inputs it rcccivcs back from call recipients and from calls from persons calling into it; it can receive Call Scripts iSO that arc passcd to it by thc I'APA Systcm 120 which it can cxccute; it has thc means to qucuc and schedule TAPA AuthenLication Calls 315 (see Figure 3) and it has the means to feed back such information pertaining to any calls it has made or received as may be required by the TAPA System 120 as more specifically determined by any Call Script 150 it has received. By said means the IYR System 204 can interact with the User 101 via the Users Phone 201 device for the purpose of registering User Phone 201 numbers with a PIN; generate Authentication Calls 315: process, manage and feed back data obtained from all inbound and outbound calls received and made by the TAPA System 120.

To affect registration the User 101 calls the TAPA System 120 telephone number from the Users Phone 201 device, with said device using the Users Phone 201 number to connect to the PSTN.

When the User 101 calls into the IVR System 204, said system first identifies the User Phone 20! number from the CIA. If this CT J presentation has been blocked by the caller -which blocking capability is a standard feature available on most networks on the PSTN -the IYR Systcm 204 cannot identify thc tJscr Phone 201 number by this means and so I'APA Rcgistration of the User Phone 201 number cannot proceed. message may be generated by thc IVR System 204, to the caller, to that effect.

If the IVR Systcm 204 succcssfully detects thc Jscr Phone 201 number from the CLI, thc IVR Systcm 204 passes said number to the 1APA Systcm 120 which chccks if the phone number so detected has aircady been rcgistcrcd on thc I'APA Register 206.

If the User Phone 201 number has already been validly registered the IYR System 204 is prompted by the TAPA System 120 with a Call Script 150 as deemed appropriate to said condition by the TAPA System 120. Under one embodiment this Call Script 150 will provide the caller with a menu option that enaffles tbr examp'e, the already registered caller to access sundry managcmcnt functions, such as thc ability to changc thcir rcgistcrcd PiN.

If thc LJscr Phonc 201 numbcr is not listcd on thc TAPA Register 206, thc IAPA System 120 prompts Lhe IVR System 204 with a Call Script 150 which will enable the Registration Process to he completed, which will include a request for the User 101 to enter a PIN through their phone device. The IVR System 204 may request the PIN is entered by whatever entry means as is compatible with capabilities of the IVR System 204 itself or as may be determined to he appropriate. In one embodiment the IVR System 204 will confirm said PIN entry after it has been made by the User 101, by automated spoken means and the User 101 given the option to change the PIN. The TAPA System 120 records the PIN confirmed by the User 101 and associates this PIN with the User Phone 201 number and stores this on the TAPA Register 206.

This in principle, completes the TAPA Registration Process.

The TAPA System 120 may provide whatever additional means it sees fit to confirm said registration to the User 1 01, including and not fimited to sending the User 1 0! an email, by an automated call possibly using the IVR System 204 or by written confirmation by ordinary mail.

Under some embodiments confirmation that said registration of the User Phone 201 number has bccn affcctcd may bc scnt to an ElliS 115 so that it is madc awarc that thc spccified II Jscr 101's User Iransactions 112 can now bc authcnticatcd by thc EBIS 115 by mcans of this invcntion.

LJndcr somc embodiments of this invention, thc EB1S 115 may bc ablc to rcgister telcphonc numbcrs and/or PiN's associatcd with thosc numbcrs, with thc IAPA Systcm 120. tinder such cmbodimcnts thc EBIS 115 may providc thc TAPA Systcm 120 with thc known phonc numbcr of a known tJscr 101 and a PIN that has typically already bccn communicated to thc tJscr 101 by the EllIS 115. By this means the EllIS 115 can affect registration of a User Phone 201 Number and a PIN known to he known by the User 101 on the TAPA Register 206 or by similar process, create a PIN to be associated with a particular telephone number. This capability facilitates the creation by the EBIS 115 of a Users Phone 201 PIN's, which may he a commercial as well as a security consideration for the EBIS 115.

The registration of a telephone number and/or PIN by the EBIS 115 onto the TAPA Register 206 may he validated hy the TAPA System 120 hy such means as it may determine, which may include calling so registered Users Phone 201 numbers recorded in the I'APA Register 206 via the auLomated calling and interactive communicaLion means provided by the IVR System 204, to request the User 101 enter the known PIN for the Users Phone 201 number or to confirm that the PIN is known to the User 101 or for any purpose the EBIS 115 or TAPA System 120 may determine. Under some emhodiments the aforementioned capability can facilitate the immediate registration of a User Phone 201 number by the EBIS 115 to facilitate rapid authentication of a User Transaction 112 or for one-off or ad hoc User Transaction 112 authentication.

Under some embodiments a Validation Call 315 may be made to ensure the Registration Process has been validly completed. This involves the User Phone 201 number in question being called to request the registered PIN be correctly entered by the call recipient. Such a Validation Call may he under some emhodiments he made by the TAPA System 120 at the request of an EBIS that intends using this system to authenticate User Transactions 112. Under other embodiments such a Validation Call 315 maybe a precondition of said Users Phone 201 number being used hy an FillS 115 as an authentication means as provided for in this invention with the outcome of said Validation Call 315 communicated to the ILBIS 115 by the TAPA System 120.

FIG 3. under one embodiment, schematically demonstrates the complete operation of the system and method of the invention to obtain authentication, which process can now be fully described.

The I Jscr 101 presents a Transaction 112 to an EBIS 115 as described earlier and illustrated in FIG 1. The FR Data 118 collated by the EI.Tl 113 associated with said User Transaction 112 having been passed to the EBIS 115 for processing, it is determined by the EBIS 115 to be desirable to authenticate any or all of the individual constituents of said TR Data 118 in whole or in part with reference to the User 101, to prevent or detect fraud, to authenticate the identity of the User 101 purporting to have presented said User Transaction 112 or for such purposes as the EBIS 115 may determine. This invention provides that the EBIS 115 may determine the precise nature of any event or transaction that will activate -Le. trigger -a request by the EBIS 115 to the TAPA System 120 to authenticatc a User Transaction 112 by mcans of an Authentication Call 315.

This invention provides that the processes the EBIS 115 has to perform and the communicaLions it has to make with the TAPA System 120 to affect an Authentication Call 315 can he performed automatically and in accordance with the methodology here prescribed. Most industry standard databases and systems include the ability to determine the conditions for such triggers to occur and enable the database administrator to proscribe any such triggering events wiLhin any EBIS 115. The trigger may arise as a matter of normal routine, where the veracity, authenticity, accuracy or completeness of said TR Data 118 in part or whole is called into question by the EBIS 115 for any reason as the EBIS 115 may determine or where there are doubts as to the identity of the person purporting to he the User 101 have arisen.

having made the determination to obtain authentication by means of this invention, the EBIS 1 iS compiles an Authentication Call Request 3 12 in accordance with instructions concerning the thrmat and content of said request, typically stored as procedures in the TAPA Data I 40. The FilLS Ii S passes said Call Request 312 to the TAPA System 120 via the Network i 19 or by such means has bccn dctcrmined. Thc Call Rcqucst 312 is essentially a data packct known by thc EBIS 115 to bc required by thc I'APA Systcm 120 to cxccutc a TAPA Authcntication Call 315 to the known User Phonc 201 number on behalf of the EBIS 115.

In ordcr for any Authcntication Call 315 to be made on behalf of any EBIS 115, the I'APA Systcm 120 must bc provided with all the requisite information from thc EBIS 115 in said Call Rcqucst 312 including but not limited to, data enabling the I'APA Systcm 120 to identify the User Phone 201 number and the associated PIN stored on the I'APA Register 206; data identifying the Call Script 150 to he used which may be an actual Call Script 150 or a reference to a Call Script 150 stored on the TAPA System Database 122 to be applied to the Authentication Call 315 and all Variable Call Data elements required by any Call Dialogues 301 associated with the Call Script 150 to be used.

Call Dialogues 301 are the discrete elements of thc spoken statcmcnts and questions that are combined into thIly formed scripted interactions that constitute the Call Scripts 1 50 that are executed by the IVR System 204 when thc I'APA Authentication Call 315 is made. The mcans to creaLe Call Dialogues 301 and Call Scripts 150 maybe provided by this invention in Lhe form of a Call Builder 320. The Call Builder 320 in one embodiment is a client application or in others is an online application typically providing a Graphical User Interface (GUI) to facilitate the creation, Lesting, editing and sLorage of Call Scripts 150. Call Scripts 150 may he creaLed in a plurality of other ways as may he determined by the TAPA System 120 provider or owner and stored on the TAPA System 120 or under other embodiments, stored on the EBIS Database 116 or Call Scripts 150 may be generated on a need to use or ad hoc basis as required, in accordance with such scripting parameters, methodology and rules as the TAPA System 120 may determine.

Under some embodiments the Call Builder 320 may also enable the ad-hoc creation of Call Scripts 150 by the EBIS 115 as a result of the receipt of any TR DaLa 118 pertaining to any User Transaction I I 2. Under other embodiments it may enable the TAPA System 1 20 to generate ad-hoc Call Scripts ISO as a result of any Authentication Call Request 312, as the TAPA System 1 20 may determine. Under another embodiment said CaB Builder 320 may not he provided or if it is, may not be made acccssiblc to the EBIS 115 at thc determination of the I'APA System 120 to ensurc all Call Scripts 150 are created solely by thc operators of thc lAPA System 120.

ihe Call Builder 320 also facilitates the determination of the data required from the EBIS 115 by the IAPA System 120 and the form and contcnt of the Authentication Call Request 312; determining thc timing and frequency of thc TAPA Authcntication Calls 315 made using said Call Scripts 150; dctcrmining thc timing, nature and format of Response Data 313 fcd back to the EBIS 115 after the Authentication Call Request 312 is received by the lAPA System 120 and any other aspect of any Call Script 150 creation and management as may he deLermined to he desirable to ensure all the above capabilities can he achieved and coordinaLed in a secure manner.

Provided all such Call Scripts 1 50 contbrm to the format proscribed hy the TAPA System 1 20, thcrc is considerabic flcxibility rcgarding not only thc content to such Call Scripts 150, but also how and when they are created and whether or not they are stored and act as templates or created "on the fly" as rcquircd.

Typically, in most embodiments Call Dialogues 301 are standard and predetermined and are in practice logically derived from the nature of the purposes for which the TAPA System 120 is being employed by the EBIS 115. For example, where the TAPA System 120 is employed to verify financial transactions, the Call Dialogues 301 maybe entirely composed of predetermined statements such as "the amount of X is being paid to Y", with X being the amount to be paid and Y being the name of the Payee: X and Y are typically derived from the Transaction Request Data 118 that form a part of or which constitute in whole of the User Transaction 112 to he authenticated. In some embodiments, such Call Dialogues 301 may be created in real lime in accordance with predetermined logic or they may be completely predetermined or be a combination of both.

For example, part of the Call Dialogue 30! as determined by a Call Script 150 may inv&ve the TVR System 204 informing the User I UI as to the amount of a payment purportedly being made by them, thc amount of said payment forming part of thc IJscr Transaction 112 to be authenticated by this invention. this amount would be part of the Transaction Rcquest Data 118 and would be a Variable Call Data elcment that must be inserted into thc Call Dialogue 301.

Since thc amount is bcing authenticated in this example, it must therefore be included in the Authentication Call Request 312 data sent to the lAPA System 120 by the EBIS, the absence of which would prohibit authentication of the I'ransaction 112 by this invention.

Call Dialogues 301 may be stored as templates. [his method serves to simplify and minimise the contents of the Call Request 312 data. Such Call Dialogue 301 templates have fixed and variable elements. So for example to ask a User 101 to confirm the value of a transaction the system might say " you wish to pay 100 dollars to Mr Smith. Is this correct?" In this case, "$100" (variable element X) and "Mr Smith" (variable element Y) are variable elements whereas the statements "you wish to pay"(flxed element A) and "is this correetT'(flxed element B) arc fixcd elements in this template, which can therefore be represented as "Template 1 AXYB". In referring to this template, the EBTS 1 I 5 can in principle invoke the aforementioned statement by simply identifying lemplate 1 and including the Variable Element X = $100 and Variable Element Y = Mr Smith.

In one embodiment, the Fixed Data Elements of a spoken Call Dialogue 301 template are stored with the TAPA System 120 and the Variable Data Elements are delivered as purL of the Authentication Request 312. The Call Dialogues 301 that form all the discrete components of the interactive spoken dialogue between the IVR System and User 101, once composed, can he delivered as discrete spoken statements using TTS technology, within the Call Script 150 as part of the Authentication Call 315 to the User 101, which anyone with ordinary skill in the art can do.

Some Call Dialogues 301 may also be in the form of pre-recorded statements. Whatever their content or term, the Call Dialogues 30 I can he combined to form an iterative process whereby the User I 0 I in the course of the Authentication Call 3 IS may he asked to authenticate any part of or all of any Transaction I I 2 and as part of a logical process, the Users 101 responses can invoke differing Call Dialogues 301 in the course of any Call Script 150.

Other examples of Variable Call Data may include an account number, the name of a web site or an address or any item of information pertinent to any User I'ransaetion 112 that may require authentication using this invention. It can seen therefore, that by the aforementioned means, virtually any transaction of any kind can be authenticated by this invention.

Prior to executing any Call Script 150 as dicLated by the Call Request 312 the 1'APA System 120 may perform such checks for the completeness, logic and validity of any or all elements of the Authentication Call Request 312 data as deemed necessary, including whether or not the request is from a bone fide EBIS 115 known to the TAPA System -with reference to Enterprise Data 123 -whether a valid Call Script 150 has been validly identified or included, that the User Phone 20! has been identified and that said number is registered on the TAPA Register 206, that all the Variable Call Data elements required to execute any Call Script 150 and required by its associated C/all Dialogues 301 are both present and valid.

If the AuthenLicaLion Call Request 312 data fails such checks, failure to execute the I'APA Authentication Call 315 requested is reported back the EBIS 120 as the Response Data 313. The EBIS 115 can determine from this Response Data 313 what further action to take which may include reporting said outcome in the TO Data 117 reported Lo the User 101 through the EUI 118 or to re-present a modified Call Request 312.

If the Call Request 312 is determined as being valid by the TAPA System 120, the Call Script is compiled by the TAPAS 120 and executed through the IVR System 204. The Call ScripL embodies and contains all the Call Dialogues 301, such IYR System 204 commands, conLrols and checks of whatever nature, that are required by the TAPAS 120 to ensure the Authentication Call 315 is executed, recorded and reported satisfactorily using the IVR System 204.

Under one embodiment the TAPA System 120 can provide for a multiplicity of said Ca!l Scripts some of which are generic and useable by a multiplicity of EB1S 5 115 and others that arc specifically fit for specific transaction types and -where the TAPA System 120 is provisioned as a service to the EBIS 120-Call Scripts 150 that are specific to a particular EBIS 115. It is seen therefore that thc EBIS 115 must determine prior to presentation of the Call Request 312, which Call Script 150 is to be executed and what Variable Call Data elements any Call Script 150 must be provided with in order to be executed satisfactorily. the form and content of these details arc stored as the I'APA Data 140 in the EBIS 115 Database. the TAPA Data 140 is a record of all the daLa that has been embedded into any Call Request 312 made by the EBIS 115 and is also a record of the outcomes of these requests such that the EBIS 115 has a full log of all Call Requests 312 and their outcomes and a record of all interactions with the TAPA System 120.

The means of provisioning and updating said TAPA Data 140 is provided for in this Invention.

The Call Script 150 prompts the IVR System I 20 to call the User Phone 20! number. When the LJscr 101 answers said call, the Call Dialogue 301 specified by the Call Script 150 is cxccuted.

Typically, the User 101 is asked to authenticate all or part of the User Transaction 112 that has prompted thc call, with spccific details pertinent to thc iransaction 112 being authenticated, in whole or in part, being communicated by auLomated spoken means to the User 101. [he User 101 authenticates same by entering on the User Phone 201, by key pad, DTMF or spoken entry means, the PIN known to be associated with said User Phone 201 number and known to he recorded on the TAPA Register 206. Typically, the User 101 is given the option to discontinue the call if they cannot or do not wish to authenticate the transaction.

On entry of their PIN, the IVR System 204 performs a logical check, comparing the PIN so entered by the User 101 with that known to have been associated with the User Phone 201 number on the TAPA Register 206. Said check may he performed by the IVR System 204 or by any other component of the TAPA System 120. The User 101 may he permitted to make any number of attempts to enter said PIN as determined by the TAPA System 120 in accordance with the Call Script ISO for said call. The success or failure by the User 101 to enter the PIN known to he on the TAPA Register 206 may he fed back to the User I 01 by spoken means, which, if proven to he a mis-match, may give the User 1 0! the opportunity to re-enter their PIN correctly.

The outcome of the Authentication Call 315 is recorded and stored by the TAPA System 120. In accordance with the predetermined instructions relating to the call as communicated by the EBIS 115, the outcome of the call is compiled into Response Data 313, which is then passed from the TAPA System 120 to the EBIS 115. tInder one embodiment the Response Data 313 in this instance includes whether authentication of the User Iiransaetion 112 as provided for by this invention, was achieved or not, as well as such details of the interaction the EBIS 115 may require such as the time and duration of the call and a log of any other responses by the User 101 as determined by the particular Call Script 150. This Response Data 313 is typically stored as TAPA Data 140.

The P1315 115 can determine from this Response Data 313 what further appropriate action to take. tinder some embodiments this includes reporting said outcome in the 10 Data 117, which is typically feedback to the User I UI through the RUT 1 I 8 as to the outcome of their Transaction 112 such as "transaction I access approved" or "transaction / access declined / dcnied" as appropriale.

The EBIS 115 can determine from the Response Daia 313 whether Lo accepi and process the User Tnmsaction 112 in whole or in part or whether io decline accepiance or processing of said User Tnmsaction 112 in whole or in part.

It is further provided in this invention for Users 101 to change the PIN associaied with said User Phone 201 number as siored on the TAPA Regisier 206. Under one embodimeni this is achieved by the User 101 calling the IVR Sysiem 204 telephone number provided by the TAPA Sysiem for this purpose. When connecied to the IVR Sysiem 204 the User Phone 201 CLI must be presented and noi blocked. Provided said CLI is recogniied and confirmed as being thai of a validly registered User Phone 201 number on the TAPA Register 206, the User I UI is presented with a Call Dialogue ISO by the IYR System 204 that enables the User 101 to change the PIN associated with the User Phone 201 number. This may he desirahle where for instance, the User 101 has had a PIN allocated to them by the EllIS 115 making a provisional entry of the User Phone 201 number on the TAPA Register 206 and the User 101 wishes to create a PIN of their choosing or for when the User 101 simply wishes to change their PIN as a matter of security or convenience. It is further provided under one embodiment of this invention that the change of PIN be validated in whatever way is deemed appropriate, which may include requesting the User 101 enter the existing PIN prior to a new PIN being accepted or by the lAPA System 120 generating an automated call to the User Phone 201 number by the IVR System 204, the purpose of which is io requesi conlirmaiion of the new PIN by the User 101 eniering the old PIN then by the User eniering the new-PIN by eniry means on the Users Phone 201 device.

While ihe foregoing description includes many delails and specificiiies, it is io be undersiood thai these have been included for purposes of explanaiion only, and are nol io be inierpreied as limitations of the present invention. It will he apparent to those skilled in the art that other modifications to thc cmbodimcnts dcscribcd abovc can bc madc without dcparting from thc spirit and scope of the invention. Accordingly, such modifications are considered within the scope of thc invcntion as intcndcd to bc cncompasscd by thc following claims and thcir legal cquivalcnts.

Claims (5)

1. Claims A method for providing mulii-factcr authentication for transactions, made by a person with an enterprise system by the entry by the person of a registered PTN (Personal Identity Number) on a telephone device wilh a regislered telephone number connected to the PSIN (Public Switched Telephone Network), the method comprising receiving from an enterprise system a request to make a transaction authentication call to a specified telephone number, the request including transaction information to be authenticated, determining that the telephone number is a registered phone number, determining that a registered PiN exists for the registered telephone number, establishing a voice connection over the PSIN with the registered telephone number, communicating to the call recipient the transaction information to be authenticated, requesting the call recipient enter on their telephone device by Dial lone Multi-Jirequency (DIME) or Asynchronous Speech Recognition (ASR) the registered PIN for the registered telephone number as proof of authenticity of this information, comparing the PiN entered by the call recipient with the registered PIN, generating a transaction information authentication report indicating whether or not the correct PIN was entered by the call recipient and the transmission of the report back to the enterprise system.
2. 2. The method of claim I whereby the enterprise system can formulate and deliver requests to make a transaction authentication call to a specified telephone number.
3. 3. The method of claim I wherein the enterprise can receive the transaction inthrmation authentication report.
4. 4. A system and method of claim 1 for the registration of a phone number connected to the PS'I'N, the registration of the PiN to be associated with that phone number and the subsequent validation of a registered PIN, the method comprising the receipt of a call from a telephone device using the telephone phone number to be registered connected to the PS'I'N, the CLI is detected and the telephone number so detected recorded as a registered telephone number, the caller requested to enter through the telephone phone device a PIN by DTMF or ASR, the PIN entered and confirmed to the caller and recorded as the un-validated registered PIN for the registered telephone number, the registered PIN is validated when, the first time the registered phone number is called to obtain transaction authenlicalion and lhc un-validaled rcgislered PIN is con-cctly entered by the call recipient.
5. 5. A system and method of claim 1 whereby a validated or un-validated registered PiN for a registered telephone number can be changed, the method comprising receipt of a voice call from a telephone, the CLI detected and the telephone number so detected confirmed as being a registered telephone number, the caller given the option to change the registered PIN for that telephone number, the caller required to correctly enter the currently registered PIN for that telephone number whether the currently registered PiN has been validated or not, the determination that the PIN entered by the caller is the currently registered PIN for that telephone number, entry by the caller of the replacement PIN and the replacement PIN recorded as an un-validated registered PIN.