WO2018046945A1

WO2018046945A1 - Providing a trusted telephone number

Info

Publication number: WO2018046945A1
Application number: PCT/GB2017/052636
Authority: WO
Inventors: Steve Smith; Simon Slater-Thomas
Original assignee: Truecall Group Limited
Priority date: 2016-09-09
Filing date: 2017-09-08
Publication date: 2018-03-15
Also published as: GB201615363D0; GB2555777A

Abstract

A method for authenticating a first party to a second party is disclosed, the method comprising: initiating an audio communication between said first and second parties; and playing an audio message comprising a recording of a voice known to the second party; wherein the recording has previously been supplied to the first party by the second party; thereby allowing the second party to authenticate the first party.

Description

PROVIDING A TRUSTED TELEPHONE NUMBER

Field of invention

The present invention relates to an authentication system.

Background

Many organisations rely on the use of centralised call centres to handle a high volume of phone calls with potential or existing customers, suppliers and other stakeholders in the organisation. Call centres may be entirely manned by human operators or, increasingly, an automated Interactive Voice Response (IVR) system may be used for incoming and outgoing calls to reduce call centre running costs.

Call centres commonly experience problems with authentication on both incoming (inbound) and outgoing (outbound) calls. Both parties to the call need to be sure that the other party is legitimate.

For outbound calls in particular, it is difficult to assure the called party that the call is genuinely from the organisation that it claims to be from.

The present invention seeks to alleviate this problem.

According to one aspect of the present invention there is provided a method for authenticating a first party to a second party, the method comprising: assigning a short code telephone number for a communication between said first and second parties; initiating said communication; and providing said short code telephone number to said first party in said communication, thereby allowing the second party to authenticate the first party. For ease of use, the communication may comprise a text message or email.

For security, the method may comprise assigning a passcode for said communication; and providing said passcode to said first party in said communication, thereby allowing the second party to authenticate the first party. For security, the step of assigning a short code telephone number for a communication with said first party may be at a telecommunications provider (telco) associated with said second party.

Preferably, the method may comprise the step of providing details relating to the communication party to said telecommunications provider. The details relating to the communication may comprise a phone number and/or passcode associated with the second party.

For security said details relating to the communication may comprise an expiry time.

Preferably, the communication comprises an audio communication.

The method may further comprise: playing an audio message comprising a recording of a voice known to the second party; wherein the recording has previously been supplied to the first party by the second party. The recording of a voice known to the second party may comprise spoken digits of the short code telephone number. Voices are easy to recognise, so the second party would be able to determine very easily whether the first party is legitimate.

According to another aspect there is provided a method for authenticating a first party to a second party, the method comprising: initiating an audio communication between said first and second parties; and playing an audio message comprising a recording of a voice known to the second party; wherein the recording has previously been supplied to the first party by the second party; thereby allowing the second party to authenticate the first party. Preferably the audio communication is a telephone call.

The audio message may comprise a recording of the second party's voice; for example the recording may comprise the second party's name, and/or the recording may comprise spoken numbers. Voices are easy to recognise, so the second party would be able to determine very easily whether the first party is legitimate.

The method may further comprise receiving and recognising an input from said second party and determining the content of the audio message in response to said input. Recognising said input may comprise decoding DTMF tones. Recognising said input may comprise voice recognition.

In one example, the input comprises said one or more numbers, the method further comprising determining the content of the audio message in dependence on said input numbers. The input may be provided in real-time.

Optionally, recognising said input comprises decoding DTMF tones. Optionally, recognising said input comprises voice recognition.

Preferably, the input comprises one or more numbers, the method further comprising determining the content of the audio message in dependence on said input numbers.

Preferably, the input numbers comprise a sequence of numbers corresponding to a personal identification number, and wherein the personal identification number is known to the first and second parties. Preferably, the input numbers further comprise a predetermined favourite number, wherein the favourite number is known to the first and second parties.

In one example, the audio message comprises a sequence of numbers based on said the input numbers. The sequence of numbers in said audio message may be the same as that entered by the user.

The audio message may comprise a result of a mathematical operation performed on the input numbers. In one example, the mathematical operation is performed on a selection of said input numbers, wherein said selected numbers are selected based on the order of the one or more input numbers. The mathematical operation may comprise addition.

Preferably, the audio message is a combination of said input from said second party and previously supplied information relating to the second party.

The method may further comprise testing for any repeated user inputs and rejecting said repeated user inputs.

The method may further comprise playing background audio simultaneously with the audio message. Preferably, the background audio comprises music or a changing tone. Preferably, the background audio is selected randomly or pseudo- randomly.

In one example, the audio message comprises a third party's voice, and wherein the third party's voice is supplied by the second party. In another example the audio message comprises a third party's voice, and wherein the third party's voice is assigned to the second party. Preferably, said third party's voice comprises an actor's voice. The actor's voice may be used in an interactive voice response system. Preferably, the first party is the initiator of the audio communication.

According to another aspect of the invention there is provided a method for securely connecting a first party to a second party in a telecommunications environment, the method comprising: assigning a short code telephone number for a communication with said first party, or to a category of similar communication; receiving a communication directed to said short code telephone number from a second party; determining an identity of the second party; and routing the communication to said first party in dependence on said identity. For security, the method may further comprise assigning a passcode for said communication.

Preferably, the method further comprises receiving and storing details about said second party from said first party. The details relating to the communication may comprise a phone number associated with the second party.

Preferably, determining an identity of the second party comprises determining the caller ID of the second party and checking this with said stored phone number.

For security, the details relating to the communication may comprise a passcode associated with the second party.

Preferably, determining an identity of the second party comprises checking the passcode entered by the second party with said stored passcode.

For security, the details relating to the communication comprise an expiry time.

Preferably, the method comprises looking up said second party identity in a database and routing the communication to a number corresponding to identity of said first party. Preferably, said database or data within said database is provided by the first party.

Preferably, the step of assigning a short code telephone number for a communication with said first party is at a telecommunications provider associated with said second party. This is a secure method as a telecommunications provider's system is unlikely to be compromised by a third party (e.g. a hacker or scammer). According to another aspect there is provided an apparatus for authenticating a first party to a second party, comprising: a database for storing audio files, the database comprising a recording of a voice known to the second party; and a module configured to play one or more of said audio files to said second party; thereby allowing the second party to authenticate the first party. The module configured to play one or more of said audio files to said second party may comprise an interactive voice response system. The invention extends to any novel aspects or features described and/or illustrated herein. Further features of the invention are characterised by the other independent and dependent claims.

Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus aspects, and vice versa.

Furthermore, features implemented in hardware may be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly.

Any apparatus feature as described herein may also be provided as a method feature, and vice versa. As used herein, means plus function features may be expressed alternatively in terms of their corresponding structure.

Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus aspects, and vice versa. Furthermore, any, some and/or all features in one aspect can be applied to any, some and/or all features in any other aspect, in any appropriate combination.

It should also be appreciated that particular combinations of the various features described and defined in any aspects of the invention can be implemented and/or supplied and/or used independently.

The invention also provides a computer program and a computer program product comprising software code adapted, when executed on a data processing apparatus, to perform any of the methods described herein, including any or all of their component steps. The invention also provides a computer program and a computer program product comprising software code which, when executed on a data processing apparatus, comprises any of the apparatus features described herein.

The invention also provides a computer program and a computer program product having an operating system which supports a computer program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein.

The invention also provides a computer readable medium having stored thereon the computer program as aforesaid.

The invention also provides a signal carrying the computer program as aforesaid, and a method of transmitting such a signal.

The invention extends to methods and/or apparatus substantially as herein described with reference to the accompanying drawings. Where an example audio message is shown, the use of angled brackets should be taken to mean that this word or phrase is a recording of the user.

As used herein, the term 'customer' should be understood to be interchangeable with the term 'user'.

As used herein, the term 'scammer' should be understood to refer to a third party seeking to obtain information related to the user of the present system or the organisation providing the present system, where it is desired that this party should not have access to this information.

An exemplary embodiment of the present invention will now be described, with reference to the accompanying drawings, in which:-

Figure 1 shows a flow diagram showing a call including an authentication process;

Figure 2a shows the structure of the system as it is used to register customers; Figure 2b shows the structure of the system as it is used to authenticate customers; and

Figure 3 shows a method of securely connecting a first party to a second party in a telecommunications environment.

Detailed Description The present invention provides a method for an organisation to properly authenticate itself when it calls someone. It doesn't require the called party to remember anything, or have a dongle or other device in their possession.

The following description primarily describes a 'bank-customer' scenario, but the examples apply to any other pairings or groups of people. The terms 'bank' and 'customer' used throughout this part of the description should therefore be construed accordingly.

Banks and other organisations have difficulty when they want to phone their customers. Such organisations typically have well-established protocols for authenticating the identity of the customer, but when a customer is called by their bank, there is typically no standard protocol for the customer to ensure that it really is their bank calling them. This leads to two separate problems:-

1. Many customers are fooled into revealing personal information by scammers who call them posing as their bank.

2. Many customers refuse to deal with their bank over the phone because they cannot be completely sure that the contact is authentic.

The bank's communication is often urgent - they may believe that the customer's credit card has been cloned, for example - so getting through to the customer quickly is important. This system provides the benefit that the customer is confident that they are talking to the bank. In addition, the initial contact may be made by IVR, so if the customer is not home or is not prepared to speak to the bank, this has not involved a call centre operative. The use of IVR is preferred as it is considerably cheaper than call centre staff. The system is arranged such that no personal information is directly revealed during the authentication process.

Figure 1 shows a flow diagram showing a call including an authentication process. The authentication process of a call is a two stage process. Firstly, the bank calls the customer (S1 ) and provides sufficient information to allow the customer to be sure that it is the bank calling them (S2). If the customer is not satisfied that they are genuinely talking to the bank, they may terminate the call (S3). If they are satisfied, the call may continue. The bank then authenticates the customer to ensure that it is the customer they are speaking to, and not someone else who has access to the customer's phone line (S4). This stage (S4) can be done using one or more of a variety of well-known procedures, which are not the focus of the present invention. If the customer does not authenticate themselves correctly, the bank may terminate the call (S5); otherwise, the call proceeds with both parties authenticated (S6).

An advantageous feature of the system is an authentication system using voice recordings. This feature allows the bank to authenticate themselves to a customer based on recordings of the customer's voice supplied to the bank when the customer registers for the service. When the bank initiates a phone call to a customer it may be difficult to persuade the customer that they are genuinely being contacted by the bank, rather than someone impersonating the bank. By playing back recordings of the customer's own voice to the customer the customer will have more confidence that it genuinely is the bank calling them because no other party would have access to these recordings.

It will of course be appreciated that the system could also be used by a human operator rather than by an IVR, with the operator playing the appropriate voice file when required. The primary method of defeating the system would be for an attacker to monitor genuine calls from the bank to the customer they wish to attack by posing as their bank, in order to make appropriate recordings to allow them to successfully impersonate the system used by the bank. The invention includes various measures to make it difficult for this to be achieved.

A number of examples of the system will now be described.

Registration

Figure 2a shows the structure of the system as it is used to register customers. The system comprises an IVR system 10 which interfaces with a database 20 for recordings of a customer's voice and a database 30 for recording of an actor's voice, as will be described later on.

The customer first registers themselves for the service - the bank could send them a letter asking them to do this, or they could be invited to come in to a branch office. To register, the customer must provide a number of voice recordings. These recordings act as audio 'tokens' that are held by the bank in the database 20. The bank can then play back these recording (via the IVR system 10) to the customer in a variety of ways when they call them to authenticate themselves. The customer may supply these recordings by calling a phone number given to them by the bank. They may be answered by an IVR system (such as the IVR system 10) that asks them to key in their account number and a numeric code that is given in the letter.

During the registration process the customer may be asked to say their name, the numbers zero through to nine, and other numbers or words or phrases. In another embodiment the customer can ask a third party - such as their partner or a friend - to supply these recordings.

Optionally, the customer is then asked to press a key on their telephone keypad corresponding to their favourite single digit number. This favourite number could be based on personal information, and an alternative request could be made to reflect this (for example, "please press the key corresponding to the last digit of the day of the month that your mother was born on"). This has the advantage that this may be more memorable, at the cost that this number may be more easily found out or guessed by scammers.

Initial Authentication

Figure 2b shows the structure of the system as it is used to authenticate customers. When the bank needs to call the customer, the call is preferably placed via the IVR 10. The IVR 10 dials the customer and, when they answer, plays a message contained in which is one of the customer's recordings that was collected during the registration process and stored in the database 20. For example, the IVR 10 could play the announcement:- "This is an important call from Acme Bank for "<customer's name>". Please press '1 ' and I will authenticate myself"

The system relies on the fact that we can each recognise our own voice, and that this is extremely difficult to copy. Not only do we recognise our voice, but we can distinguish between different recordings of our own voice saying the same thing that were made at different times. We also recognise other people's voices.

In this example, the customer recognises their own name in their own voice played back by the IVR 10, and that this is the recording they made for the bank. Given that only their bank has access to this recording, the customer will gain confidence that it is their bank calling them.

If a scammer managed to get another recording of the customer saying their own name and tried to impersonate them bank by using this, the customer would most likely recognise that this was different from the one use by the bank (tone, inflexion, background noise, etc.). A number of further authentication steps are provided later to ensure that a scammer could not imitate the system.

Note that multiple versions of the introductory IVR announcements may be used selected from a pool of recordings made by different actors with distinctive voices, stored in the database 30. When the customer registers for the service they are randomly allocated to one of these actors, and every time they call in they will hear the announcements spoken by that specific actor. The actor voices are sufficiently different that the customer would realise if the wrong one were being used, so any crude attempt to scam a customer would fail if the wrong actor's voice were used.

Optionally, audio effects may be applied to the voice used to increase the distinctiveness of the voice, although it must be ensured that the voice is still easily understood. Similarly, some background noise, tone or music could be added to increase distinctiveness.

The human brain is good at recognising voices and sounds, but finds it difficult to accurately describe them. For example, unless Sarah's voice has some very unusual characteristic, Andrew can't describe her voice to Bob sufficiently well for Bob to be able to recognise it accurately. The system uses this principle both in the voice recording of the customer held by the bank, and by the unique voice assigned to the customer's announcements.

When the bank calls the customer if someone else in the household (or someone in possession of the customer's phone) picks up the phone they will likely hang up, recognising that the call is not for them. They will be prevented from impersonating the customer, should they wish to do so, by the bank's existing protocols for authenticating the identity of a customer. If the customer answers but does not want to accept the call at this time, or are not comfortable that it is their bank calling them they can just hang up. If the customer picks up and they do want to proceed they may press '1 ' and go through a further authentication process.

Further authentication

If additional authentication is required the system may play back a number of requested voice samples to the customer. This interaction could, for example, proceed as follows. The customer may hear the message:- "Thank you. Now can you please press three different random keys on your telephone keypad and we will authenticate ourselves by saying them back to you" The customer may press any three numeric keys on their phone's keypad (e.g. , '9' and '3').

Note that this part of the dialogue may be carried out by the customer pressing keys, or by using voice recognition, with the customer saying numbers.

The IVR 10 may then play a short piece of music or a changing tone and on top of this the voice recordings of the numbers T, '9' and '3' that the customer made during registration. A range of different music samples or changing tones may be randomly (or pseudo-randomly) used.

The customer will be reassured that they are talking to their bank because they recognise their own voice, and only their bank would have these recordings.

Note that if the customer doesn't randomise the three digits that they use, i.e. they always enter the same digits (e.g. , '2', '3') the IVR 10 can preferably detect this and can prompt them to enter a different set of digits.

If the playback they hear of themselves speaking the three numbers is delayed, or there is a music or tone that seems 'chopped up,' indicating that a scammer may be attempting to produce the audio recordings of the numbers in the correct order using recordings of a previous authentication process, the customer can hang up and refuse to complete the call.

In another example of the system this further authentication may be carried out using numbers that are known to the bank and the customer, but not to an attacker or eavesdropper. The customer is asked to randomly select a number of digits within a certain range and the system calculates a sum of the specified digits of the customer's personal identification number (PIN). Because the customer is randomly deciding which digits of their PIN are used each time, a scammer cannot force through a previously intercepted response.

This interaction could, for example, proceed as follows. The customer may hear the message:-

"Thank you. Please press two keys between 1 and 4 on your phone"

The customer may then press any two numeric keys on their phone's keypad (e.g. Ί ', '3').

The IVR 10 system takes digits 1 and 3 from the customer's PIN and adds them together and plays the message to the customer. :-

"Thank you. When I add numbers <1 > and <3> of your PIN it comes to 7."

When the customer presses two keys on their phone they immediately hear their own voice speaking these two numbers played back to them. They also hear the sum of the two digits of their PIN which is something that a scammer would not know.

For the case where the organisation using the system is a bank, the use of the normal PIN that is associated with the customer's debit or credit card is convenient because it is likely to have been remembered and kept secret by the customer. It will be appreciated that any other code or account number may be used with this system. This could be an application-specific PIN that was set-up at the registration stage, in addition to the previously described steps. Due to the importance of keeping this PIN secret, it may be necessary for a user to register the PIN via another communication channel, or in person. When digits of a PIN are added together the task of deriving the full PIN is made much more difficult for anyone who taps the phone line. In a traditional exchange (which might take the form: "Give me digits 1 and 3 of your PIN") the scammer immediately becomes aware of these two digits of the PIN. They may learn the whole PIN in as few as two intercepts. Using the proposed approach the scammer listening in only knows the sum of the two digits - not the individual digits of the PIN, or their order. The actual value of each digit cannot be immediately derived except in the case where both digits are 0 or 9. In order to derive a complete 4 digit PIN (for a conventional credit or debit card PIN) the scammer needs to hear at least four calls from the bank to the customer. The scammer would have to monitor the customer's line for a very long time to derive the full PIN. In another example of the system, the customer's favourite number may be used in the calculation as described above - for example, the favourite number may also be added to the sum of the digits of the customer's PIN.

The customer's 'favourite number' is of course not known to the scammer. This makes it even more difficult for the scammer to determine the customer's PIN (a minimum of 5 calls have to be recorded). Additionally, this feature obscures the value of the specified digits where both of the specified digits are either 0 or 9.

"Thank you. Please press two keys between 1 and 4 on your phone"

The customer may press any two numeric keys between 1 and 4 on their phone's keypad (e.g. , '3'). The IVR system 10 then adds these two digits from the customer's PIN together with the customer's favourite number. The customer may then hear the message:-

"Thank you. When I add digits <1 > and <3> of your PIN to your favourite number it comes to 14"

In all of the embodiments described, the bank may then offer to connect the customer to a call centre agent following the conclusion of the authentication process. For example, the bank's IVR system 10 may say:-

"If you are happy to be connected to one of our agents please press 1 , if not then please contact us by another method."

If the customer presses '1 ' they are then connected to a call centre agent at the bank. This procedure only authenticates the bank to the customer - the bank then goes through its own authentication procedures with the customer to ensure that they are talking to the right person.

Defeating the system

Potential weaknesses of the system identified below, and further features may be incorporated to mitigate them:-

If a scammer intercepted the registration letter and registered for the service themselves this would serve them no purpose as this is a process for the bank to authenticate themselves to the customer, not for the customer to authenticate themselves to the bank. When the bank called the real customer, they would be presented with recordings that were clearly inauthentic. Anyone trying to perpetrate a scam would require recordings of the customer's voice saying the numbers zero through nine, and would need equipment and software to recognise DTMF tones, assemble these voice files and then immediately play them back (possibly over a piece of music or a tone). This would create a significant technological barrier for all but the most sophisticated scammers.

Over time, a scammer could collect all the voice files they needed by bugging the customers phone and recording the customer's voice tokens when their bank called them. If voice files were played back mixed in with music or a changing tone it would be difficult for a scammer to isolate the voice saying each number sufficiently well from the music or tone to be able to then dynamically assemble them and play them over a different piece of music or changing tone in response to the user's random selection of numbers.

The scammer could conceivably bug the customer's phone line and record a number of authentic dialogues between the bank and the customer to collect voice recordings of the customer. They could then call the customer posing as the bank - they would be able to play the customer's name back to them, but in order to fool the customer on the three random digits they would require:- a. 'Clean' recordings of the customer saying the numbers zero through nine.

Any intercepted recording will have music or a tone playing in the background. If three of these files were assembled by the scammer they would not sound right because the music or tone wouldn't match.

b. The ability to decode DTMF tones and rapidly assemble the three required voice files to playback

If a scammer monitors a large number calls from the bank to the customer it might be possible for them to eventually derive the customers full PIN and collect sufficient customer recording files to impersonate the bank's process. However this must be put into context. It is likely that the information that the scammer collects from the rest of the phone call that they are monitoring will be much more valuable - for example, when the bank then authenticates the customer they will ask for information such as date of birth, city of birth, mother's maiden name, father's middle name, specific digits of the PIN, etc. During the call the customer will reveal account numbers, payment amounts and dates, etc.

Short codes

An alternative (and/or complementary) method for a user to authenticate a party (such as their bank) is described below. If a bank wants a customer to contact them urgently - perhaps because the bank believes that there has been a fraudulent transaction on the customer's account - they can try to contact them by phone, but if they are unsuccessful they have two un-satisfactory options. a) They could send the customer a message (email; text message; instant message; voicemail; recorded message call) asking them to call the bank back on a certain phone number. A customer receiving this message has no way of being sure that the message really is from their bank, and not from a scammer.

b) They could send the customer a message (email; text message; instant message; voicemail; recorded message call) asking them to call the bank back on the phone number on the back of their credit/debit card. This puts the onus on the customer to go to the trouble of finding the phone number (they may not have a credit/debit card, or they may not have it with them when they receive the message). If and when they do call this number they will then have to navigate through voice menus, or speak to call centre agents to direct their call to the correct department. This imposes a cost on both the customer and the bank.

An improved method is therefore required. Such an improved method comprises the bank sending their customer a message asking them to call a telecoms 'short code'. Since telecoms short codes are allocated directly by telecoms operators (and in a limited distribution) it is very unlikely that a fraudster could gain control of a short code.

Short codes are telephone numbers consisting of fewer numbers than a normal number, typically between 3 and 8 digits. The telco for the user dialling the number typically redirects calls from these short numbers to an actual (i.e. 'long') number, thus providing the user an easier number to remember (such a mechanism may be termed 'abbreviated dialling'). Alternatively, telecoms operators allocate short codes as a simple way of accessing services (e.g. 999 for emergency services). However, short codes in the method as described herein are used as a method of authentication. The telecommunications operator (telco) allocates a 'short code' telephone number to be used for a particular category of communication - for example, when a bank needs to flag a potentially fraudulent transaction to a customer. This short code may be specific to the telco or preferably may be common across telcos for ease of customer recognition. When, say, a bank wants a particular customer to call them they send a message to the telco(s) giving them the phone numbers that the customer normally uses to call the bank (e.g. home number landline, mobile number) and the telephone number within the bank where the customer's call is to be directed. The telco stores this in a database. The customer is sent a message (email; text message; instant message; voicemail; recorded message call) saying that the bank wants to contact them, and asking them to call the short code and giving them the short code to dial. The customer can be confident that they are calling the bank when they call the short code because the use of short codes is tightly controlled by telephone companies - the security of the call between the customer and their bank is inherited from the intrinsic security of the telco short code system. When the customer dials the short code, the customer's telco looks up the identity of the caller (e.g. by using the calling line identity (CLI) of the caller) in its database, and if it finds a match redirects the call to the telephone number at the customer's bank supplied by the bank to the telco. It may be that the customer is calling from a telephone which they have not registered with the bank. To cater for this, the system can be extended to include a passcode. If the customer is calling from an unfamiliar phone - i.e. a caller-ID that isn't recognised - they are greeted by an interactive voice message. This asks them to key in a passcode. When leaving the message for the customer, the first party (i.e. the bank) also provides a passcode which has been assigned to that customer. The passcode may be specific to the call in question, or may be constant for a particular customer (the latter being potentially more convenient for the user, but less secure). The passcode is also provided to the telco and is used to reference the customer record on the telco database and find the correct telephone number at the customer's bank to direct the call to.

The linkage between the short code, the callers identity (e.g. their CLI), the passcode, and the identity of the bank or other secured caller is dynamic and is initiated by the bank contacting the telco requesting a call back request be made to the customer. For additional security such records on the telco database expire after a period of time so that if the customer responds to the message after, say, 24 hours, their call won't be forwarded. An example secure communication between a first party (e.g. a bank) and a second party (e.g. a customer) is described with reference to Figure 3 below.

The process is initiated by the bank contacting the telco 250, sending them the customer's caller ID and a phone number at the bank to direct any call to. There may also be a passcode generated for the record. The telco stores these details received from the bank in a database 260. The passcode may be generated by either the bank or the telco. The telco then assigns a short code for the communication and transmits this to the bank 270. Whilst a telco may dynamically choose to assign one of a pool of short codes to this transaction, it is more likely that a single short code will be used for all communications of this category.

The bank then initiates a communication with a customer 300, by communicating with the telco. The telco retains the knowledge of the communicating parties and the time for which a responding communication from the second party will be considered to be valid. The bank then communicates directly with the customer - this communication may be a pre-recorded message saying that their bank would like to speak to them with an instruction to dial a short code. The message may include pre-recorded voices and sounds as described above with reference to Figures 1 and 2, for example:

"Hello, this is Acme Bank. We would like to speak to <customer's name in their own voice>, using our secure calling system. If this is you then can you please hang up and call us back on this phone using the short code 1479"

In another example, the digits of the short code may be read out in a recognisable voice.

The message may also include the passcode that the customer should use if they are asked for one. Including the passcode when the bank contacts the customer by email would be beneficial as it would not necessarily be known which phone the customer will use to call back.

Alternatively this initial communication could be via text message, instant messaging, or any other communications mode.

The customer receives the communication 302 and dials the short code provided in the communication 304. Being a short code, this call goes directly to the customer's telco which receives the communication 306. The telco checks the caller ID 308 of the incoming call against their database and determines the call back number 310 that the bank has requested be used. Alternatively, at this point, if the CLI is not recognised, the telco may use an IVR to request the customer to enter a passcode and use this to look up the correct record. The telco then routes the call 312 to the bank using the call back telephone number provided by the bank 300 so that the two parties can communicate with one- another 314. Alternatively, rather than a call back telephone number, the telco may have a dedicated connection the first party that bypasses the public switched network and is therefore more secure.

A key reason why this method is secure is that the short code phone call cannot be tampered with. If the user dials this number their call will definitely go to their telco, and cannot go anywhere else.

The same short code would advantageously be used by all networks so that customers will remember the number.

It will be appreciated that elements of these described embodiments may be combined so that, for example, mathematical operations may be performed on the numeric keys entered in the third example of the system, which optionally may also involve the user's PIN or favourite number. It will be understood that the present invention has been described above purely by way of example, and modifications of detail can be made within the scope of the invention.

Each feature disclosed in the description, and (where appropriate) the claims and drawings may be provided independently or in any appropriate combination.

Reference numerals appearing in the claims are by way of illustration only and shall have no limiting effect on the scope of the claims.

Claims

1. A method for authenticating a first party to a second party, the method comprising:

assigning a short code telephone number for a communication between said first and second parties;

initiating said communication; and

providing said short code telephone number to said first party in said communication,

thereby allowing the second party to authenticate the first party.

2. A method according to claim 1 wherein the communication comprises a text message or email.

3. A method according to any preceding claim further comprising assigning a passcode for said communication; and

providing said passcode to said first party in said communication,

thereby allowing the second party to authenticate the first party.

4. A method according to any preceding claim wherein the step of assigning a short code telephone number for a communication with said first party is at a telecommunications provider associated with said second party.

5. A method according to claim 4 further comprising the step of providing details relating to the communication party to said telecommunications provider.

6. A method according to claim 5 wherein said details relating to the communication comprise a phone number and/or passcode associated with the second party.

7. A method according to claim 5 or 6 wherein said details relating to the communication comprise an expiry time.

8. A method according to any preceding claim wherein the communication comprises an audio communication.

9. A method according to claim 8 wherein the method further comprises:

playing an audio message comprising a recording of a voice known to the second party;

wherein the recording has previously been supplied to the first party by the second party.

10. A method according to claim 9 wherein the recording of a voice known to the second party comprises spoken digits of the short code telephone number.

1 1 . A method for authenticating a first party to a second party, the method comprising:

initiating an audio communication between said first and second parties; and

wherein the recording has previously been supplied to the first party by the second party;

thereby allowing the second party to authenticate the first party.

12. A method according any of claims 9 to 1 1 wherein the audio communication is a telephone call.

13. A method according to any of claims 9 to 12, wherein the audio message comprises a recording of the second party's voice.

14. A method according to any of claims 9 to 13, wherein the recording comprises the second party's name.

15. A method according to any of claims 9 to 14, wherein the recording comprises spoken numbers.

16. A method according to any of claims 9 to 15, further comprising receiving and recognising an input from said second party and determining the content of the audio message in response to said input.

17. A method according to claim 16, wherein the input is provided in real-time.

18. A method according to claim 16 or 17, wherein recognising said input comprises decoding DTMF tones.

19. A method according to claim 16 or 17, wherein recognising said input comprises voice recognition.

20. A method according to any of claims 16 to 19, wherein the input comprises one or more numbers, the method further comprising determining the content of the audio message in dependence on said input numbers.

21 . A method according to claim 20, wherein the input numbers comprise a sequence of numbers corresponding to a personal identification number, and wherein the personal identification number is known to the first and second parties.

22. A method according to claim 20 or 21 , wherein the input numbers further comprise a predetermined favourite number, wherein the favourite number is known to the first and second parties.

23. A method according to any of claims 20 to 22, wherein the audio message comprises a sequence of numbers based on the said input numbers.

24. A method according to claim 23, wherein the sequence of numbers in said audio message is the same as that entered by the user.

25. A method according to any of claims 20 to 24, wherein the audio message comprises a result of a mathematical operation performed on the input numbers.

26. A method according to claim 25, wherein the mathematical operation is performed on a selection of said input numbers, wherein said selected numbers are selected based on the order of the one or more input numbers.

27. A method according to claim 25 or 26, wherein the mathematical operation comprises addition.

28. A method according to any of claims 16 to 27 wherein the audio message is a combination of said input from said second party and previously supplied information relating to the second party.

29. A method according to any of claims 16 to 28, further comprising testing for any repeated user inputs and rejecting said repeated user inputs.

30. A method according to any of claims 9 to 29, further comprising playing background audio simultaneously with the audio message.

31 . A method according to claim 30 wherein the background audio comprises music or a changing tone.

32. A method according to claim 30 or 31 , wherein the background audio is selected randomly or pseudo-randomly.

33. A method according to any of claims 9 to 32, wherein the audio message comprises a third party's voice, and wherein the third party's voice is supplied by the second party.

34. A method according to any of claims 9 to 33, wherein the audio message comprises a third party's voice, and wherein the third party's voice is assigned to the second party.

35. A method according to claim 33 or 34 wherein said third party's voice comprises an actor's voice.

36. A method according to claim 35 wherein said actor's voice is used in an interactive voice response system.

37. A method according to any preceding claim, wherein the first party is the initiator of the communication.

38. A method for securely connecting a first party to a second party in a telecommunications environment, the method comprising:

assigning a short code telephone number for a communication with said first party, or to a category of similar communication;

receiving a communication directed to said short code telephone number from a second party;

determining an identity of the second party; and

routing the communication to said first party in dependence on said identity.

39. A method according to claim 38 further comprising assigning a passcode for said communication.

40. A method according to claim 38 or 39 further comprising receiving and storing details about said second party from said first party.

41 . A method according to claim 40 wherein said details relating to the communication comprise a phone number associated with the second party.

42. A method according to claim 41 wherein determining an identity of the second party comprises determining the caller ID of the second party and checking this with said stored phone number.

43. A method according to claim 40 wherein said details relating to the communication comprise a passcode associated with the second party.

44. A method according to claim 43 wherein determining an identity of the second party comprises checking the passcode entered by the second party with said stored passcode.

45. A method according to any of claims 40 to 43 wherein said details relating to the communication comprise an expiry time.

46. A method according to any of claims 38 to 45 comprising looking up said second party identity in a database and routing the communication to a number corresponding to identity of said first party.

47. A method according to claim 46 wherein said database or data within said database is provided by the first party.

48. A method according to any of claims 38 to 47 wherein the step of assigning a short code telephone number for a communication with said first party is at a telecommunications provider associated with said second party.

49. An apparatus for authenticating a first party to a second party, comprising: a database for storing audio files, the database comprising a recording of a voice known to the second party; and

a module configured to play one or more of said audio files to said second party; thereby allowing the second party to authenticate the first party.

50. An apparatus according to claim 49, wherein the module configured to play one or more of said audio files to said second party comprises an interactive voice response system.

51 . A method substantially as herein described and/or as illustrated with reference to the accompanying figures.

52. An apparatus substantially as herein described and/or as illustrated with reference to the accompanying figures.