GB2556026A - Call filter - Google Patents

Abstract

A method of filtering telephone calls to a client system (e.g. call centre); the method comprising: receiving a telephone call intended for a client system; determining data relating to said telephone call; determining the probability of the call being a wanted telephone call based on said data; and a) accepting the call if the probability is above a first threshold;b) rejecting the call if the probability is below a second threshold; orc) intercepting the call if the probability is between said first and second threshold. The call filter 300 inspects each call and calculates an Authentication Score which is an indication of the probability of the call being a wanted call as opposed to an unwanted call. It will either: forward the call to the target (authentication score above an acceptance threshold); accept the call then immediately clear down the line (authentication score below a threshold and classified as an attack / Telephony Denial of Service (TDoS) call); intercept the call and interact with the caller to determine whether this is likely to be a legitimate call (provided when the call is scored an authentication score between the rejection threshold and acceptance threshold).

Description

(54) Title of the Invention: Call filter

Abstract Title: Call Filter for preventing TDoS attacks in inbound calls of a call centre (57) A method of filtering telephone calls to a client system (e.g. call centre); the method comprising: receiving a telephone call intended for a client system; determining data relating to said telephone call; determining the probability of the call being a wanted telephone call based on said data; and a) accepting the call if the probability is above a first threshold^) rejecting the call if the probability is below a second threshold; orc) intercepting the call if the probability is between said first and second threshold. The call filter 300 inspects each call and calculates an Authentication Score which is an indication of the probability of the call being a wanted call as opposed to an unwanted call. It will either: forward the call to the target (authentication score above an acceptance threshold); accept the call then immediately clear down the line (authentication score below a threshold and classified as an attack I Telephony Denial of Service (TDoS) call); intercept the call and interact with the caller to determine whether this is likely to be a legitimate call (provided when the call is scored an authentication score between the rejection threshold and acceptance threshold).

At least one drawing originally filed was informal and the print reproduced here is taken from a later filed formal copy.

12 17

1/5

Figure la

12 17

2/5

Figure lb

12 17

Figure lc <300

5/5

+-» CD o £? o Π3 C\l r\i ' ld co co

Call Filter 300

-1Call Filter

Field of invention

The present invention relates to a call filter.

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 inbound calls in particular, it is possible for calls centres to be flooded by calls whose only purpose is to disrupt their operation, and are therefore not authentic traffic. Such action is termed ‘Telephony Denial of Service’ (TDoS).

The present invention seeks to alleviate this problem.

According to one aspect, there is a method of filtering telephone calls to a client system; comprising the steps of: receiving a telephone call intended for a client system; determining data relating to said telephone call; determining the probability of the call being a wanted telephone call based on said data; and

a) accepting the call if the probability is above a first threshold;

b) rejecting the call if the probability is below a second threshold; or

c) intercepting the call if the probability is between said first and second threshold. Such a method allows telephone calls to be accurately filtered.

Preferably, the telephone call is forwarded to an interactive voice response system if the probability is between the first threshold and the second threshold.

-2Preferably, accepting the telephone call comprises forwarding the call to the client system.

Preferably, forwarding the telephone call in dependence on the probability comprises rejecting the call if the probability is above the second threshold.

Rejecting the telephone call may comprise placing the call on hold.

The method may further comprise monitoring telephone call traffic volume, and wherein determining a probability comprises performing a calculation based on telephone call traffic volume.

The data relating to said call may comprise: known safe or unsafe calledDs, predetermined caller classes, calledD validity, frequency of calls from specific called Ds and/or areas relative to call frequency at other times, the target phone number called, telecoms flags, and/or locally or remotely accessible data. The data related to telephone call traffic may be saved in a local database.

Preferably, the method further comprises dynamically adjusting the performed calculation based on the saved data related to telephone traffic volume; and optionally proposing adjustments to the performed calculation based on the saved data related to telephone traffic volume. This allows for the accuracy of the filter to be improved over time.

The data related to telephone call traffic may comprise data related to telephone call frequency and/or caller identity.

The method may further comprise saving audio related to telephone call content in the local database.

The local database may be adapted to interface with a software application configured to allow the local database to be queried.

-3Preferably, intercepting the call comprises requesting an input from the caller; the requested input may comprise an audio CAPTCHA; and/or predetermined information for verification.

The predetermined information may comprise one or more of: a credit card number, an employee number, and/or an account number. The method may comprise comparing the predetermined information to previously used information and testing for abnormal repeated use of said predetermined information.

The method may further comprise comparing data relating to current telephone call traffic volume relative to past telephone call traffic volume, thereby to determine when an attack is in progress. The data may comprise the location of incoming calls.

Preferably, the method comprises adjusting said first and/or second thresholds in dependence on a determined capacity of said client system.

Preferably, the method comprises adjusting said first and/or second thresholds in dependence on the outcome of said interception. This allows for the accuracy of the filter to be improved over time.

The method may comprise prioritising certain categories of callers over others.

The method may comprise overriding the calculated probability for an accepted or intercepted call by rejecting the call and applying a new probability, wherein the new probability is below the second threshold; said probability override may be performed by an operator, for example by an operator pressing a key, for example, the star or hash key.

According to another aspect there is provided an apparatus for filtering telephone calls to a client system, the apparatus comprising: means for receiving a call intended for a client system; means for determining data relating to said call;

means for determining the probability of the call being a wanted telephone call

-4based on said data; and

a) means for accepting the call if the probability is above a first threshold;

b) means for rejecting the call if the probability is below a second threshold; and

c) means for intercepting the call if the probability is between said first and second threshold.

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.

-5The 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.

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

An exemplary embodiment of the present invention will now be described, with reference to the accompanying drawings, in which:Figures 1a to 1c show representative diagrams of different types of TDoS attacks; Figure 2 shows a representation of a TDoS attack on a telephony system protected by the call filter of the present invention; and

Figure 3 shows the operation of the call filter and a number of possible actions that it may take based on how the call is scored.

-6Detailed Description

As the cost of making calls drops and technology allows callers to easily generate large numbers of calls, call centres are increasingly vulnerable to what are known as Telephony Denial of Service (TDoS) attacks. An attacker who wishes to inconvenience the company makes a large enough number of phone calls to the organisation that its normal operations are disrupted because its telephony system is overloaded. This may prevent legitimate telephone calls being made and/or received.

The present system uses a number of techniques to try to identify which calls are genuine and which are attack calls, and then block the attack calls while allowing through the genuine calls.

A call filter arranged to assist in protecting an organisation’s telephony systems against a TDoS attack is described below with reference to figures 1a, 1b and 1c.

Figures 1a to 1c show representative diagrams of different types of TDoS attacks. The figures show a large volume of calls being placed to a target 200 via a trunk line 106, where the target 200 comprises a private branch exchange 108 (PBX), which may be an Internet Protocol (IP) PBX, which interfaces with an IVR system 110 and a number of extensions 112, which may be manned by human operators. In each case the ‘choke point’ - where a high volume of calls overwhelms the telecoms capacity of the target 200 - is circled.

TDoS attacks typically fall into two separate categories:1. Automated attacks - Calls are generated automatically by computer equipment, sometimes sited abroad. Such equipment can generate tens of thousands of calls in a very short period of time. Such an attack may originate from a single source 102 (as shown in Figure 1a) or may come from many distributed sources 104 (as shown in Figure 1b).

-72. Manual attacks - These attacks calls are made by a group of individuals making repeated calls to a call centre. They are typically carried out by protestors and pressure groups who contact supporters, maybe via social media, asking them to call a specific number at a particular time. This type of attack typically would not overwhelm a large call centre, but could overwhelm a branch office with a few receptionists. This kind of attack is shown in Figure 1c, with the distributed sources 100 of each attack shown.

In both cases, the problem for the recipient is that their telephony system is configured to handle the volume of calls that they receive while doing their normal business, and cannot handle the significantly larger number of calls received during an attack.

There are many possible limiting factors - the maximum number of simultaneous lines that are available, the number of switchboard operators available, the number of simultaneous calls that an IVR or auto-attendant system can accommodate, etc. It is not practical for the call centre to continually maintain the staff and telecoms infrastructure to have the capacity to handle a TDoS attack.

The result is that a TDoS attack can severely limit a company’s ability to serve legitimate callers, and in some instances may also inhibit its ability to make outgoing calls if the same circuits are used for both making and receiving calls.

The problem of TDoS attacks is now particularly acute because Voice-overInternet Protocol (VoIP) technology makes it significantly easier to launch an attack:• The cost of making even an international phone call has reduced significantly • No phone lines need to be purchased or call centres set up. VoIP TDoS attacks can be launched from a server rented from a web hosting company.

• The framework software required to launch an attack is freely available and easily configured (e.g. Asterisk).

-8• A VoIP system can be configured up to almost completely mask the originator of the call. This allows the attacker to operate with almost no risk of identification, capture or prosecution • With VoIP technology it trivially easy to manipulate the caller ID of each call • There is evidence that hackers specialising in this area are offering their services for a price. For a fee they will launch an attack of a specific number of calls, over a specific time period against a specific phone number.

Figure 2 shows a representation of a TDoS attack on a telephony system protected by a call filter 300.

The call filter 300 may comprise means for receiving and forwarding a telephone call, such as a digital telephone exchange, together with a processor configured to gather and analyse data related to incoming calls and to use this data to classify the calls.

The call filter 300 may be established in a telecoms network which has a greater call handling capacity than each of the locations that it is defending. Depending upon the type of attack that is anticipated, this may have many orders of magnitude more capacity.

Alternatively, if sufficient trunk lines are available, the call filter 300 can be established within the companies own telephone network.

This call filter 300 may be left ‘in circuit’ all the time, or calls may just be diverted through it during an attack. The call filter 300 will not allow more calls to be routed to the customer’s target phone number than a specified capacity. For example, if a branch office has 100 trunks 106, the service node may limit the number of simultaneous calls routed to the office to 70 so that 30 trunks are available for outgoing calls.

While an attack is in progress audio recordings of all incoming calls are stored in

-9a database (not shown) linked to the system.

The call filter 300 is arranged to:

• Allow through all valid voice traffic, if possible. If it is not possible to allow all valid voice traffic through, then callers are told that the organisation is experiencing a high level of calls and asked to call back later if their call is not urgent.

• Identify attack traffic and block it before it hits any PBX 108 or Automated Attendant, if present in the telephony system • Clear down attack calls as quickly as possible • Increase the costs and complexity for the attacker of mounting an attack

Call Classification

Figure 3 shows the operation of the call filter 300 and a number of possible actions that it may take based on how the call is scored. When an attack is in progress, telephone calls to the target phone number are routed to the call filter 300.

The call filter 300 inspects each call and calculates an Authentication Score (S1). This score is an indication of the probability of the call being a wanted call as opposed to an unwanted call. Depending on the score and thresholds specified by the system manager it will either: • S2: forward the call through to the target (because it has been scored an authentication score above an acceptance threshold and thus has been classified as legitimate), or • S3: accept the call then immediately clear down the line (because it has been scored an authentication score below a rejection threshold and thus has been classified as an attack call), or • S4: intercept the call and interact with the caller to determine whether this is likely to be a legitimate call (referred to as interactive caller verification, as will be described later on). This step is provided when the call is scored an authentication score between the rejection threshold and acceptance threshold.

-10It is assumed that attackers can send whatever caller-ID they want with each of their calls, so attack patterns may not be obvious. However, a large amount of data is available to the defender about the normal traffic patterns that it expects to receive - logs of the caller-IDs that have called the call centre during normal periods of operation. This data includes caller ID information, low level network routing information, the type of caller (customer, supplier, bank employee, bank executive) and the timing, frequency of calling, and duration of their calls. The defender also has access to the phone numbers stored in its customer, supplier and personnel database.

The scoring system scores the call on the basis of a number of factors (data / metadata relating to the call) that may include:• Specific caller-IDs that are likely to be safe (because they are associated with a particular class of caller - bank employees; bank senior management; customers; suppliers; previous callers; etc.).

• Class of caller (determined as described above) • Specific caller-IDs or caller-ID patterns that are known to be used by attackers.

• Caller-IDs that are not valid phone numbers (for example area codes that don’t exist). This may include caller-IDs that are not valid because they are too long or too short or clearly malformed (e.g. Ό003531234567’).

• The frequency of calls from each caller-ID during the attack vs the frequency of calls from this caller-ID during normal operation.

• The frequency of calls from each area code/country during the attack vs the frequency of calls from this area code/country during normal operation.

• Repeat calls from the same Caller-ID during normal operation • Repeat calls from the same Caller-ID while the attack is underway (through social engineering the attacker may learn the phone numbers of legitimate customers, suppliers or bank employees) • Phone number called (calls made to many different phone numbers may end up at the same call centre - a sales number, a customer services number, etc.)

-11• Low level telecoms flags and routing information that is received with the call or which can be determined via further queries from the telecoms system • Data from other databases that are accessible locally or over the internet • Caller-IDs associated with previous calls that were blocked, allowed or intercepted during this attack, and any data collected or derived on these previous calls

Using this data, the system can assess each incoming call and score it using weightings for each factor. Two thresholds are established, an acceptance threshold and a rejection threshold. Calls with a score higher than the acceptance threshold are accepted, calls with a score lower than the rejection threshold are rejected and all other calls are intercepted.

The system is preset with default scoring weights for each of these factors, and for the thresholds. The manager is able to amend these to meet their own specific needs, and adjust them over time in the light of their experience.

If, despite the filtering, the number of accepted incoming calls exceeds the capacity of the call centre, then an additional process is carried out on accepted calls - these are scored for importance (based upon a similar list of factors). A threshold is automatically and dynamically established by the system so that the most important legitimate calls are put through, and the less important legitimate callers are sent to the system’s voicemail (or if that reaches capacity, are asked to call back later). For example, sales calls may be prioritised over customer services calls. The thresholds may also be dynamically adjusted if, for example, intercepted calls are consistently being deemed to be either legitimate callers, or consistently malicious callers.

It will be appreciated that the system is designed to reject attack calls as quickly as possible to free up telecoms network resources.

Interactive caller verification

If a call’s Authentication Score isn’t above the acceptance threshold, or below the

-12rejection threshold then it is answered, and the call filter establishes a dialogue with the caller.

If the attack is an automated attack then it is sufficient to determine whether the caller is human or a machine. This can be done with a one, two, three or four digit audio CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart).

The caller may, for example, hear a short message asking them to enter a series of random digits (“Hello this is Acme Bank - all calls are recorded. As a temporary added security measure can you please press ‘4 5 T on your handset”). If the correct keys are pressed the call is classified as a legitimate call and is routed to the target, if not, then the call is terminated. Simple automated systems won’t be able to defeat this other than by brute force (i.e. each call plays a random series of DTMF tones), but in this case only one attack call in 10, 100, 1,000 or 10,000 calls would get through (depending on the number of digits requested).

It is believed that a simple audio CAPTCHA as described would be sufficient to block most current attacks. However it must be expected that the attackers will modify their tactics over time to try to overcome any defences that are in place. For example, once they know that a simple two digit audio CAPTCHA system is being used they could address this by brute force (each call sends two random DTMF keys so that 1% of them will get through), or by using voice recognition software to determine which key has been requested. Note that overcoming even these simple barriers will require significantly more investment by the attacker in mounting an attack.

If the attack is a manual attack the attackers are human, and would be able to enter the requested codes, so in this case the caller is requested to enter the digits that comprise a piece of information known to a legitimate caller, but not an attacker - for example a credit card number, an employee number, or an account number. The system would determine whether the number entered was valid for that organisation.

-13Further checks on the effectiveness of this function may be made - if the same account number is being used repeatedly then it would suggest that the attackers all knew one or a number of valid account numbers and were using them repeatedly. The system has the ability to restrict the re-use of each code within a particular timescale. For example, in normal operation it would be extremely unusual for any one customer to call the call centre 5 times in one hour, so if a particular account number were used more often than this during an attack, then further calls using this account number could be rejected during the attack period.

Additionally, a test could be carried out to see whether the caller-ID that arrived with the call matched any of the caller IDs previously used by that particular account holder.

The results of these investigations may be added to the Authentication Score and if it is higher than a given threshold the call would be put through (S5 in Figure 3), otherwise the caller may be given a polite message via the system IVR saying that all lines were busy, and be asked them to call back later (S6 in Figure 3).

Dynamic monitoring of an attack while it is in progress

The user of the system may access a computer program that shows them a detailed call-by-call log of the incoming calls that have been received by the call filter. This shows the date and time of the call, the call duration, identifying markings from the call (caller-ID, electric caller-ID, caller-ID text, caller-ID flags, routing details, authentication codes, operator flags and comments, etc.) and details of how the call was handled by the call filter. This information may be available to view real-time as the attack is in progress, and also in a summary form. The manager may click on a particular call to hear the audio of the call this will help to identify the techniques used by the attacker.

The system monitors this traffic and can identify traffic patterns that indicate which calls are likely to be legitimate and which are not - for example, specific caller-ID patterns that are common to the attackers. It either automatically invokes rules to block these calls, or advises the manager which rules it

-14recommends should be invoked, the reasons for this, and the potential impact.

The manager may decide to invoke some or all of these suggested rules, or set up their own rules, and get the system to assess the likely impact of the rule - the number of attack calls that would be blocked vs the number of legitimate calls blocked.

For example, if the system identifies that 25% of the attack calls have a caller-ID with area code 01856 (Orkney Islands), but that under normal traffic conditions only 0.1% of calls are from this area code then the operator can decide whether to block all calls from 01856. The benefit would be that 25% of the attack traffic would be blocked; the downside would be that 0.1% of legitimate calls would be blocked.

If any attack calls do get through to the call centre agents they can classify the call as an attack call, for example, by pressing the hash button (“#’ on their telephone keypad), or clicking on a button on their computer screen (either a separate application, or a button on one of the existing applications that they use). They preferably also have an application on their PCs that allow them to add any relevant details about the call - both check boxes and radio buttons to classify the call, and a free text area to make any notes. This data can be used in real time by the manager to improve the scoring parameters.

System managers 114 (Figure 3) can monitor in real time details of the calls received, how they have been handled by the system and how callers and called parties have responded.

Managers can changes the settings that the system uses to classify incoming calls - adjust thresholds, apply new filtering rules, change rules, accept or reject new rules suggested by the system. This monitoring and adjustment may occur via a wired or wireless link to the databases.

Identifying when an attack is in progress

If the call filter is kept ‘in circuit’ it will constantly monitor traffic to identify any

-15unusual activity, and can advise if it believes that intervention is necessary. Data about valid traffic patterns and behaviours during normal operation is collected to help in the identification of an attack. Note that some attacks are not always evident - attacks can tie up trunks by dwelling in the IVR system to degrade the capacity of the office’s telecoms rather than drawing attention to themselves by completely flooding the system. These attacks can be identified by an ‘in circuit’ call filter.

If the call filter is not ‘in circuit’, then when the target organisation believes that it is under TDoS attack it just needs to change the routing of its calls so that they are directed via the call filter. This is normally straightforward and can be done immediately by the network operator.

Flexible response

The design of the call filter software is extremely flexible so that it can respond to different attacks, and can be continually developed to keep one step ahead ofthe techniques used by the attacker.

After an attack, the call recordings of the attackers failed and successful attempts at circumvention can be analysed to determine the techniques that they are using and further develop defences.

For example, if it is believed that the attacker is using a voice recognition system to interpret the instructions, and is then generating the desired DTMF tones, the invention allows for a range of possible responses:• Use multiple different announcements recorded by different voices maybe with regional accents - and randomly rotate them • Use a distorted recording of the voice - echo, frequency shift, clipping, the addition of background noise, ‘Dalek’ voice, etc. These would be recognised by a human caller, but not necessarily by a voice recognition system.

• Change the format of the announcement - “Please press the keys Two One Three”; “Two One Three - Please press these keys”; “On your

-16handset please press the Two One Three keys” • Use techniques that require an understanding of the announcement “Spell out the word ‘CAT’ on your phone keypad”

Given that people will always be better at interpreting the spoken word than a machine, the invention is flexible enough encompass a multitude of similar approaches.

Keeping the line open

One option to deter attackers is to cost them money. If the victim of a TDoS attack has tens of lines then the attacker launches thousands of calls over a period of time, and may expect a few hundred of them to be terminated over the course of the attack. If the attack is in progress but it is not flooding the victim’s telecoms capacity then the system can be configured to keep the calls open for the duration of the attack - i.e. the attacker’s telecoms costs may be two orders of magnitude greater than planned.

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. For example, the scoring system may be the inverse, where calls with a low probability of being legitimate are given a low score, as opposed to a high score.

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 (29)

Claims

1. A method of filtering telephone calls to a client system; comprising the steps of:

receiving a telephone call intended for a client system; determining data relating to said telephone call;

determining the probability of the call being a wanted telephone call based on said data; and

a) accepting the call if the probability is above a first threshold;

b) rejecting the call if the probability is below a second threshold; or

c) intercepting the call if the probability is between said first and second threshold.

2. A method according to claim 1, wherein the telephone call is forwarded to an interactive voice response system if the probability is between the first threshold and the second threshold.

3. A method according to claim 1 or 2, wherein accepting the telephone call comprises forwarding the call to the client system.

4. A method according to any of claims 1 to 3, wherein forwarding the telephone call in dependence on the probability comprises rejecting the call if the probability is above the second threshold.

5. A method according to any preceding claim, wherein rejecting the telephone call comprises placing the call on hold.

6. A method according to any preceding claim, further comprising monitoring telephone call traffic volume, and wherein determining a probability comprises performing a calculation based on telephone call traffic volume.

7. A method according to any preceding claim, wherein said data relating to said call comprises: known safe or unsafe calledDs, predetermined caller classes, called D validity, frequency of calls from specific called Ds and/or areas relative

-18to call frequency at other times, the target phone number called, telecoms flags, and/or locally or remotely accessible data.

8. A method according to any preceding claim, further comprising saving data related to telephone call traffic in a local database.

9. A method according to claim 8, further comprising dynamically adjusting the performed calculation based on the saved data related to telephone traffic volume.

10. A method according to claim 8, further comprising proposing adjustments to the performed calculation based on the saved data related to telephone traffic volume.

11. A method according to any of claims 8 to 10, wherein the data related to telephone call traffic comprises data related to telephone call frequency and/or caller identity.

12. A method according to any of claims 8 to 11, further comprising saving audio related to telephone call content in the local database.

13. A method according to any of claims 8 to 12, wherein the local database is adapted to interface with a software application configured to allow the local database to be queried.

14. A method according to any preceding claim, wherein intercepting the call comprises requesting an input from the caller.

15. A method according to claim 14 wherein the requested input comprises an audio CAPTCHA.

16. A method according to claim 14, wherein the requested input comprises predetermined information for verification.

-1917. A method according to claim 16, wherein the predetermined information comprises one or more of: a credit card number, an employee number, and/or an account number.

18. A method according to claim 16 or claim 17, further comprising comparing the predetermined information to previously used information and testing for abnormal repeated use of said predetermined information.

19. A method according to any preceding claim, further comprising comparing data relating to current telephone call traffic volume relative to past telephone call traffic volume, thereby to determine when an attack is in progress.

20. A method according to claim 19 wherein said data comprises the location of incoming calls.

21. A method according to any preceding claim comprising adjusting said first and/or second thresholds in dependence on a determined capacity of said client system.

22. A method according to any preceding claim comprising adjusting said first and/or second thresholds in dependence on the outcome of said interception.

23. A method according to any preceding claim comprising prioritising certain categories of callers over others.

24. A method according to any preceding claim, comprising overriding the calculated probability for an accepted or intercepted call by rejecting the call and applying a new probability, wherein the new probability is below the second threshold.

25. A method according to claim 24 wherein said probability override is performed by an operator.

26. A method according to claim 25 wherein said probability override is performed

-20by an operator pressing a key, for example, the star or hash key.

27. An apparatus for filtering telephone calls to a client system, the apparatus comprising:

5 means for receiving a call intended for a client system; means for determining data relating to said call;

means for determining the probability of the call being a wanted telephone call based on said data; and

a) means for accepting the call if the probability is above a first threshold; 10 b) means for rejecting the call if the probability is below a second threshold; and

c) means for intercepting the call if the probability is between said first and second threshold.

15

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

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

Intellectual

Property

Office

Application No: GB1615357.9 Examiner: Mr Euros Morris