CA2100846C - Intelligent call screening in a virtual communications network - Google Patents

Abstract

A unified and systematic approach is taken both to design of a virtual communications network within a carrier's telecommunications network, and to design the screening filters provided in the VCN data base which control the admission of calls to the network. For this purpose, telecommunications traffic information that is relevant for both the design of the VCN architecture as well as for development of the screening filters is aggregated and applied both to a networkdesign tool that is used to generate the customer's virtual network configuration, as well as to a screening filter generator (SFG). The traffic information may include, for example, traffic data contained in network and customer premises equipment call detail records and billing data. In one embodiment, the SFG also receives outputinformation from the network design tool, indicative of the on-net and off-net locations in the VCN, and information from a carrier data base that provides a weighting factor indicative of the incidence of fraudulent calling to different domestic and international destinations. The SFG is arranged to jointly process the traffic information as well as the fraudulent calling information (together withinformation relating to VCN design parameters, if desired) in order to generate screening filters that can be installed, and thereafter used, in the VCN to determine, on a call by call basis, whether a call made using the VCN is allowed or denied.Advantageously, the screening filters are designed so that they will minimize orreduce the possibility that the VCN will be used to make fraudulent calls.

Description

INTELLIGENT CALL
SCREENING IN A VIRTUAL COMMUNICATIONS NETWORK
Field of the Invention This invention relates generally to viltual: networks 5 (VCN's) which are arranged to provide "private", custom designed features and services to customers using a public switched ; ~ network and, in particular, to a system for providing intelligent call screening in the context of a VCN that will ' "~, reduce the incidence of fraudulent calls.
10 ~ L~ i of the Invention A virtual ~ network (VCN) is a custom designed "private" . ~L network typically offered by an; '- o- ~ 6'' carrier such as AT&T (or by local exchange carriers or ' carriers) to large business customers who require inter-premises voice and data 15 Customers can directly access the VCN from customor premises equipment such as terminals connected to the customers' PBX. via private lines or switched using local exchange carriers. They can also remotely access the VCN, e.g., from stations that originate a call to the PBX from an "off-net" location and then are connected to the VCN via a second connection originated in the PBX. Each 20 customer is allocated virtual resources within the carrier's network, based upon the customer's expected calling patterns and historical, needs.
A VCN typicaUy includes one or more data bases that associate ;.. r,.. ;.,,. provided by the caller (such as the caller's telephone number) with stored '( in the data base, in order to determine how the call is to be routed 25 and treated. Ones of these data bases can also serve as "screening filters" in order to aUow or deny each call based on IJ~ screening jnch~ rif.nc Filtering may include various fraud prevention schemes, requiring entry of personal ' ~ numbers (PlNs), passwords or other identifiers, so as to eliminate or reduce the occæions when the VCN is used as a gateway into the 30 network by hackers or other I ' ~ callers. Additionally, filtering may restrict access through the VCN to particular ~ c under particular even if the calls originate from on-net (as opposed to off-net) locations.
While secure and effective access control .,.. ~ are cridcal to the operation of VCN's, numerous instances of entry into a VCN by l ' I
35 individuals have been reported. This may occur, for example, when a hacker breaks into a PBX via its remote access capability and then dials out to various ~

2- 2l O0846 or when an lln~lthor;7~d individual obtains the PIN of an authorized user by trial and error guessing, by obtaining the PIN througll unintended disclosure by an authorized user (e g., by overhearing verbal entry of the PIN into the access control system) or by outright tllefl of a record (such as a credit card) bearing the PIN. In such events, the compromised PIN
5 may be disabled, and the characteristics of the screening filters can be updated to prevent furtller losses. However, the losses that already occurred cannot usually be remedied. The milk that has been spilled cannot easily be returned to the bottle.
Summ~ of the I~ventiQ~
In general, a unified and systematic approach is taken both to design of a 0 virtual cnmmllni~Afions net~vork within a carrier's telecommunications net~vork, and to design the screening filters provided in the VCN data base which control the admission of calls to the networl;. For this purpose, t~lecomml~ni~ Ations traffic information that is relevant for both the design of the VCN architecture as well as for development of the screening filters is aggregated and applied both to a network design tool that is used to 5 generate the customer's virtual net-vork configuration, as well as to a screening filter generator (SFG). The traffic information may include, for example, traffic data contained in network and customer premises equiplnent call detail records and billing data.
According to one aspect of the invention there is provided a processor for generating screening information used to control the admission of calls to a customer's 2 o virtual private communications network, said processor including means for receiving (a) first information relating to historical communications traffic patterns for said customer, and (b) second information relating to fraudulent calls applied to said network, and means for generating said screening information as a joint function of said first and second -information.
2 5 According to another aspect of tlle invention there is provided a system for generating screening filters used in processing calls placed by users of a virtual communications network (VCN), said system including means for storing L~ <uionstrafficinformation~meansresponsivetosaidtelecommunicationstrafflc information for generating a design for said VCN, and means for generating said screening 3 o filters, said generating means being jointly responsive to (a) said tel~ u~ dlions traffic information, and (b) information derived from said design for said VCN.
According to yet another aspect of the invention there is provided a system for controlling tclc~ "~ icAtions traffic in a virtual commllnicAtioni net-vork arranged to route calls from a p~urality of originating locations to a p~urality of destination locations, 3 5 said system including first means for storing data indicative of historical calling patterlls for r:' '.,~
_ .. . ...... ... _ _ _ ~ - -2a- 21 oo846 calls made between said originating and destination locations, said data being aggregated by originating locations and destination locations, second means for storing data indicative of the expected incidence of fraudulent calls placed to said destination locations, means responsive to the aggregated data for configuring said VCN, the configuration of said VCN
5 including information defining the on-net status of said originating locations and said destination locations, and means for generating a p~urality of screening tables, each of said screening tables indicative of the extent to which a user of said virtual ~ommllni~ti~nc network is allo-~ed to place a call from one of said originating locations to each one of said destination locations, ~vherein the information in said screening tab~es is generated as ajoint lO function of information in said first and second storing means.
According to yet another aspect of the invention there is provided an apparatus for generating flters used to determine the eligibility of users of a soft~vare defined network to place calls between originating locations and destination locations, said apparatus including frst means for storing data indicative of historical patterns of calls 15 placed between said originating locations and said destination locations, second means responsive to said data for designing characteristics of said software defined network, said ch~rA~tPricti(~c inc~uding information relating to said originating and destination locations, and means for generating said filters jointly in response to said stored data and said 2 o According to yet another aspect of the invention there is provided a virtual cu~ lu~ aLions network, comprising at least one switch for controlling the connection of calls from originating locations to destination locations, and means for controlling the operation of said switch, said controlling means including means for riPtPrminin~ in response to ~ 1r~ P~ call screening information t11e eligibility of a call originated at 25 a particular one of said originating locations to be connected to a particular one of said destination locations through said network, characterized in that said call screening information is a joint function of (a) first information relating to llistorical communications traffic patterns for a user of said network, and (b) second information relating to fraudulent calls applied to said network.
3 o According to yet another aspect of the invention there is provided a method of generating screening information used to control the admission of calls to a customer's virtual communications network, said method including the steps of receiving (a) first infommation relating to historical communications traffic patterns for said customer, and (b) second information relating to fraudulent calls applied to said network, and generating said 35 screcning information as a joint function of said first and second information.
.. ...... ..

-2b- 2~0846 According to yet another aspect of the invention there is provided a method for generating screening flters used in processing calls placed by users of a virtual communications network (VCN), said method including storing tclc~ollllllull;~ations traffic information, responsive to said tcl~cv~ ullications traftic information, generating a design 5 for said VCN, and generating said screening filters, said generating step being jointly responsive to (a) said telecommllnir~tinn~ traffic information and (b) information derived from said design for said VCN.
According to yet another aspect of the invention there is provided a method for use in virtual communications network (VCN) ~hich comprises at least one switch for 10 controlling the connection of calls from originating locations to destination locations, said VCN having a design generated in response to a body of ~ - "",."~ ions traffic information, said method comprising the steps of making a dPt~rmin~tion, in response to a call initiated from a particular one of said originating locations to a particular one of said destination locations through said net-vork and further in response to predetrmined call 15 screening information, as to whether said call should be completed or denied, and controlling the operation of said switch in accordance with said dPt~ rmin~tinn characterized in that said call screening information is a joint function of (a) said telecommunications traffic information and (b) said design.
In preferred embodiments, the SFG also receives output information from 20 the net-~ork design tool, indicative of the on-net and off-net locations in the VCN, and i~lr~lllla~iJII from a carrier data base that provides a ~veighting factor indicativc of the incidence of fraudulent calling to different domestic and international destinations. The SFG is arranged to jointly process the traftic information as ~vell as the fraudulcnt calling - information (together with information relating to VCN design parameters, if desired) in 25 order to generate screening filters that can be installed, and thereafter used, in t~le VCN to determine, on a call by call basis, whether a call made using the VCN is allowed or denied.
Advantageously, tlle screening f Iters are designed so that they will minimize or reduce the possibility that the VCN will be used to make fraudulent calls.
Brief Descrilltion of the Drawin~
3 o The present invention will be morc fully understood by consideration of the following detailed description, ~hich should be read in light of the accompanying drawings in which:
~ .

- ~3~ 2 1 00846 FIG. 1 is an overaU block diagram of a system which includes a screening filter generalor arranged in accordance with the principles of the present invention;
FIG. 2 is a block diagram of front-end data aggregator 100 of FIG. 1;
S FIG. 3 is a flow diagram illustrating the ~ ;... process performed in aggregator 100;
FIG. 4 is a block diagraTn of network design tool 110 of FIG. l;
FIG. 5 is a diagrarn illustratung the format of records stored in fraudulent call data base 130 of FIG. l;
FIG. 6 is a diagrarn illustrating the format of records stored in design parameter data base 140 of FIG. l;
F~GS. 7 and 8 are flow diagrarns that describe the process performed in screening filter processor 121 for generating the screening filters stored in screening filterdatabase 1220fFlG. l;
F~G. 9 is a diagrarn iUustrating the format of a typical screening filter stored in screening filter data base 122;
FIG. 10 is a block diagram illustrating the ' ', between a screening filter update processor 940 arranged in accordance with the principles of the present invendon and various data bases that provide r " needed to 20 update the screening filters stored in screening filter data base læ which are then provided to VCN 160 via OSS 150;
FTGS. 11 and 12 are flow diagrams that describe the process performed in screendng filter update processor 940 for updadng screening filters that havepreviously been stored in screening fi ter data base 122; and F~G. 13 is a block diagram illustradng some of the network elements in a typical virtual network such as VCN 160, and the ~
betwoen the VCN and on-net and off-net caU destinadon and originadon locadons.
Dehiled Description Referring first to FIG. 1, there is shown an overaU block diagrarn of a 30 system arranged in accordance with the principles of the present invendon to design screening filters using customer trle~ I;" Q traffic data that is also used to design the customer's virtual . - network. r~he system includes a front end data aggregator 100, described more fuUy in connecdon with F~G. 2, which is of .,...iollal design. Aggregator 100 receives traffic r ' that is relevant for 35 both tbe design of the VCN ~,-h;f ~ , as well as, in accordance with the present invention, for design of screening filters, and processes the ;..r~ ;.. to provide a _ _ _, ..... ..

consistent view thereof that may be easily processed. The traffic ;,.r..,."A,i,~.. can include any data describing recent use of existing . networks by the customer in question, such as network switch call detail records, customer premises equipment (e.g., PBX) call detail reports, if the customer is presently using a PBX, S and billing records. As will bc seen below, data relating to the probablo calling patterns that will be observed when the VCN is designed and used as intended mayalso be supplied to aggregator 100.
The aggregated data compiled in front end data aggtegator 100 is applied to a network design tool 110, also of ~ul~v~ -' design. Network design 10 tool 110 is a~ranged to generate an optimized design for the customer's VCN, designated generally as VCN 160 in F~G. 1. Generally speaking, .~ i.... of a VCN includes processing of tariff and t~affic r '- as well as other ;. f.~ in order to select (a) access type, e.g., dedicated or switched; (b) access facilities and size; (c) switches, both network and premises based; (d) on-net 15 locations; and (e) routing logic _ A more complete description of networlc design tool 110 is provided in connection with F~G. 3.
The optimized network design generated in network dçsign tool 110 includes r ' which identifies on-net locations and off-net locations. As used here, an on-net location is a customer ttaffic generating location that is part of the 20 VCN, and that is connected to the VCN by switched or dedicated facilities, while an off-net location is a location outside of the VCN. This ~ as well as the aggregated data output from ftont end data aggtegator 100 is applied to screening filter generator (SFG) 120, which includes a screening filter processor 121 and a screening filter data base 122. Generally speaking, the function of screening filter 25 ptocessor 121 is to utilijce ttaffic; r.~ .. describing the customer's calling patterns, as cxtracted from the aggregated data received from front end data aggregator 100, and ;,.r~..,..-~;..., describing the customer's on-net and off-net locations, as extracted from thG optimized network design generated in network design tool 110, to generate screening filters that enable the VCN to allow access to 30 the customer's network by persons seeking to make valid calls, but to block calls likely to be invalid, fraudulent or otherwise I ' ' Screening filter generator120 is ad~ u~ly arranged to also receive inputs from a fraudulent call data base 130, which contains historical ;"r.~ ;.... indicative of.1. ,~ to which a high proportion of fraudulent calls are made~ and an input from a design patameter 35 data base 140, which contains ;r.~ -;used in the design of a VCN, such as design p~ n~rr~, operating ~ and ~. r.. ",. ., limitatiûns applicable -5~ Zf 00846 to tne different elements (e.g., switches) in the networlc. The details of the process performed iQ screening filter generator 120 are described below in coMection with FIG. 7. The format fo} records stored in fraudulent call data base 130 and design parameter data base 140 are described in FIGS. 5 and 6, ~ .l.y.
FIG. I also illustrates a customer override data base 170 which is designed to allow updadng of the screening filters generated in screening filterprocessor 121 and stored in screening filter data base 122, based upon input describing the customer's anticipated future t~ t~affic patterns. For example, while tne customer may be making few calls to a certain 10 destination at the present time, the customer may wish to design the screening filters to take account of the customer's plan to establish an of fice or factory in that location in the near future.
Referring now to FIG. 2, there is shown a block diagram of ~.UII~ '' ' I
front end data aggregator 100 of FIG. 1. ~ data input module, designated generally 15 as 200, which irlcludes various well known data entry means, including, for example, a scanner 201, a tape reader 202 and a data feed 203, is arranged to receive ~ c~ ;,, describing the customer's historical calling patterrls. Such r ~
may be obtained from customer billing records, as well as from caAI det~il ; ~....~-~;.... from customer switches (PBX's) and i' network 20 switches that serve the customer. This r ' can be supplied in the form of magnetic or paper tape, electronic data files, or other media.
Tl-C.. -'i--.. applied to front end data aggregator 100 via data input module 200 is applied to a forrnatter æo, which is arr~Anged to reformat individual data elements to provide a consistent view thereo plr ~ which can be 25 perforrned using any of several presently available data processing software i. A~ such as the Informix database system, may include, for example, processing to insure Cu~ ,.l.,y of the , (i.e., format) of dates (e.g., "month-day-year", rather than "day- ' ~ u") that are obtained from several sources. The data output from formatter 220 comprises a series of call detail records 30 that are stored in a customer ;..r.,.... ~ data base 230 before being applied, one at a time, to aggregator 240. The r '- in each call detail record may include data describing a single call, including, for example, the originating station number, destination station number, .---1..; ~ code or personal i.l~ ;.... number (PIN) uscd to make the call, the time at which the call was made, and the call 35 duration. This r '' may also include connect date, toll switch ID numbers, etc. Database 230 may also be arr nged, if desired, to store sample formats and =
~ . -- ~ -6- 2f 00846 processing used by formatter æo duting its processing CaU detail records in data base 230 are applied to aggregator 240 for the purpose of combining vat~ious elements of customer traffic ...r~ in each caU
detail record into a form useful in designimg a, netwo}l~ for that 5 customer. GeneraUy speaking, aggt~gated data output from aggregator 240 is in summary form, gtouped in accordance with origination elements (defined below), and sorted, within each gtoup, by origination element and then ~- For the purposes of ,' . an "origination element" is a c~ ;.... useful to the customer, such as (a~ a location, (b) a station group, or (c) an ~ code/PIN
10 group. The output from aggregator 240 is applied to net vork design tool 110 and to SFG 120.
As used herein, a "location" can refer to a rj. - .L. ~ or c,~ l;O - ~
location having one or more originating telephone stations, For example, a location can be a particular group of offices, all offices in a particular building or on a 15 campus, or groups of several offices in a city that have an afLinity with each other that is r ~ to the customer for whom the VCN is being designed. Each of the origination station numbers contained in each call detail can be mapped to one location. A "station group" refers a l..~ I group of originating station numbers that have an affinity with each other that is _r ~ to the customer for 20 whom the VCN is being designed. For example, one station group may serve the personnel ~,~i of a company, one may serve the accounting ~IPpr-lrn~nt and another may serve the parts ~lep~rm~nt Each of the origination station numbers contained in each caU detail record can be mapped to one station group. A "code group" refers a ~ i group of callers that originate calls using an 25 ~ ;.. code or PIN. Members of the caller group have an affinity with each other that is _r to the customer for whom the VCN is being designed. For example. one group may be key corporate executives, another may be sales people with ' territories, and another may be lower levd clerical personnel. As with locations and station groups, each ~ l l ,, ..;, - l ;. . code or PIN used to make a call 30 can be mapped to one code group. T r " defining the ' ', between origination station numbers, on the one hand, and locations and station groups, on the other hand, and between ~.. ~I....I,rl;.--- codes/PINs on the one hand, and code groups, on the other hand, is stored in data base 230.
The operation of aggregator 240 of FIG. 2 will be better understood by 35 reference to FIG. 3, which illustrates the steps foUowed in carrying out the rct'~rj~';''" process. The process begins in step 300, wherein a caU detail record - . -7- Z ~ 00846 stored in data base 230 is retrieved. In step 310, ;, f ~ in the call detail record is mapped, so that (l) the location(s) and station group(s) ~ e to the origination stadon number and (2) the code group: ~- r , to the ,...ll..,.;,-li~...
code/PlN are - l and available. In step 320, traffic r ' from the call 5 detail record is then grouped with r ' from other "like" call detail records, by storing the ;.. r.. -~ .. in (1) a location file, (2) a station group file, and/or (3) a code group file, all within data base 230, ~ ly indexed so that sorting may thereafter occur. In the lofation file, records are stored using location as a key. In the station group file, records are stored using station group as a key. Similarly, in 10 the code group file, individual records are stored using the code group as a key. If it is ~1f~f ~ninrd in step 330 that more call detail records exist tbat require processing, steps 300-320 are repeated.
When all call detail records in data base 230 have been processed, all of the records in each of the three files (location file, station group file, and code group 15 file) within data base 230 are sorted in step 340. Specifically, the records in the location file are sorted, first by location and then by ~lf ~ the records in thestation group file are sorted, first by station group and then by destination station number; and the records in the code group file are sorted, first by code group and then by destination station number. (As used herein, "destination" can refer to a 20 destination country, a desdnation area code, a destination telephone exchange, a destination telephone number, or some other indicia of where the caU is to be routed.) ~fhen the sorting performed by step 340 is completed, data in each of the three files is again grouped in step 345, this time by combining records based on the ~1~.ch'n~.h~n Grouping is separately performed for each of the three files. For 25 example, in the location files, records for each originating location are exarnined to select all calls going to individual foreign countries (as ~' ' by the country code portion of the destination telephone number) or going to individual geographic regions in this country, based upon the area code por~ion of the destination telephone number. The same can be done, separately, for records in the station group file. For 30 the records thus selected, other traffic data containGd in the rGcords is aggregatGd or combined in step 350. Thus, for exarnple, the number of calls from an originating location (e.g., a parlicular building) to each foreign country, as a function of time of day when the call was o~iginated, can bG flr-rrrninrA ~n the code group files, similar illr.~ .dfi~.l is grouped in step 345, so that, for example, the number of calls from 35 each code group to each destination (e.g., a country), as a function of day of the week, can be ~': ' Thus, during ~LL~ Lr;;'~'' Of records in step 350, -8- 2~ PfO~6 ; ,r~..". ; -., is assembled describing the . - traffic pattcrns bet~veen each originating location, station group and code group, and each group of 'if .i; ~.i.\
Following ~r~ f~ in step 350, the aggregated; r "",--;,... is output 5 to network design tcol 110 and to SFG 120 in step 360.
Referfing now to FIG. 4, there is sho~vn a block diagram of one ,' of a network design tool 110 of FIG. 1. Aggregated traffic i r, ...., ~ ;.... is received from front end data aggregator 100 in an interface circuit 410 and applied to a processor 400, which operates in accordance 10 with control program 460 stored in a data base indicated generally as 490. Database 490 has four other data storage elements: traffic analysis r - , stored in data base element 430; tariffing ;..r...,.. -~;...., stored in data base elernent 440; optimizer ~ - . stored in data base element 450; and on-net location ~ . stored in data base element 470. The latter i~ is one output, or result, of the 15 design process. Network design tool 110' takes aggregated data as input and designs an optimized VCN, i.e., it produces a network design that is most efficient for the customer in terms of vafious generally accepted i' network ~,.. r.. ~ p ~-Prflp~ rg~ such as queuing time for inbound and outbound calls, call set up time, blocked calls, ~ quality, and, of course, cost. As stated 20 previously, stations that are part of the VCN designed using the optimized network design are called "on-net" locations. T r " identifying these stations, which isstored in on-net location data element 470, is output from network design tool 110 and applied to screening filter generator 120 via line 115. Examples of currently available network design t~ols that perform this function are the Hybrid Network25 Design System available from J.B.A. ;fnc. and the Q, ~ l system available from Q ' Inc.
In addition to receiving; r"", ~ " defining "on-net" locations from network design tool 110, screening filter generator (SFG) 120, as previously noted, also receives ~ from fraudulent call data base 130. This ~
30 includes a weighting factor "F" indicative of the incidence of fraudulent calling with respect to calls placed to different domestic and; ~, ..;" _l ~l~ l; ~;....- FIG. 5 illustrates the typical format of records stored in fraudulent call data base 130 of FIG. 1. As shown, a series of entries in column 500 represent call ' either in terms of geographic location, area code, country code, or other similar 35 indicia ~r~f~;~ lf by screening filter generator 120. A . , ' ~ series of entries in column 510 represent the value of the weighting factor "F" indicative of -9- 210~8~6 the probability (1 is greatest, 0 is least) that a call to a particular destination is fraudulent. '~he ;~r~ ' by the records of FIG. 5 is not customer specific, but rather is g~n~rqli7~-d ' obtSIined from the car~ier's experience with fraudulent calls. For example, it is known that the incidence of fraudulentS calling to certain "third world" or under-developed countries is generally higher than calls to ;. i~ countries in western Europe.
FIG. 6 is a diagram illustrating the typical format of records stored in design parameter data base 140 of FIG. 1. Generally speaking, the stored in data base 140 contains, for different network elements (such as 10 switches and data bases), applicable design rr-rstm. tt-rg, operating ~ b ~ and ' limiiations. '~hus,; f............. ~ which may be included in data base 140can describe, for example, capabilities of customer premises switches (PBX's), speci~ic ttunk ~ for network switches, and between switches and data bases. Column 610 in each record indicates, for a given 15 network element, individual ~ I -- ,- t ~ applicable to that element. For example, r. . ;~ , for a switch may include maximum number of destination locations that can be stored in each screening filter; maximum number of station groups that can be .-~ maximum number of code groups that can be configured; and time of day CIOD) and day of week (DOW) screening limitations for the network 20 element. Column 620 indicates the value of the particular . l~ t, ;~ in column 610, e.g., no more than 250 locations may be stored in a screening Iter, no morethan 200 statiQn groups can be configured; and no more than 200 code groups can be c~ nfi~
Referring now to F~G. 7, there is shown a flow diagram that describes 25 the prccess performed in screening filter processor 121 for generating screening filters that are stored in screening filter data base 122 of FIG. 1. As stated previously, the overall function of screening filter generator 120 is to process historic customer specific traffic ;.. r.. - ;.. together with generic r -' relating to fraudulent call locations and VCN design parameters in Qrder to generate screening 30 filters that are stored in screening filter data base læ.
'~he prQcess of FIG. 7 begins in step 700, wherein a first origination element is selected for which a screening Iter is to be ~,O..~ u-,h~. As stated previously, an origination element can be a particular location, a station group or a code group. Next, in step 705, a record is retrieved from data base 122 indicating the 35 tra~ffic ~ for calls originating from the selected location, station group orcode group, to a first particular ~ jnq~ n In step 710, the destination is compared ~1 0~846 witb r " retrieved from network design tool 110 via line 115, so that a f' can be made in step 715 as to whether or not the destination is "on-net" or "off-net". This ~' is ad~ ~ because different treatment can be provided for calls directed to different ~.~ thereby taking account of S the fact that fraudulent or I ' ' calls are more likely to be made to off-net locations.
For records pertaining to off-net ~ ., a ~' is next made in step 720 (l;IG. 8) as to whether the t~affic volume per unit time to that destination exceeds a first threshold value Tl, which value is chosen so as to "'r between Gkely ~ , on the one hand, and unlikely ~
on the other hand. If the result of the test in step 720 is negative, the traffic for calls to this destination are next modified in step 722 in r ~ withcustomeroverride; rr..~ ';.. containedindat~base170. Thisis done so that anticipated traffic to a particular destination can be accounted for in the 15 screening filter being prepared. For exarnple, if the customer plans to do business in a new territory, calls to that destination would be expected, even though historical data would include little or no traffic to that flf~s~in~tm~ Following ,...~1;f;. ~I;rtn in step 722, a test is again made in step 724 to determine if the traffic volume is greater than the threshold value Tl. If a negative result is obtained, it can be fairly 20 concluded that litde traffic has been carried to the destination in question, and litde traffic to that destination is , ' A~ ~Iy~ a denial indication (a "DENY") for that destination may be entered in step 726 in the screening filter contained in screening filter data base 122. On thc other hand, if the traffic level in steps 720 or 724 exceeds the threshold value Tl, a different prccedure is followed.
In the events mentioned above, the "fraudulent location weight"
applicable to the destination currently being processed is next retneved from data base 130 in step 73Q This weight is used to modify the traffic ;"r.. ~;.. for the destination in step 740. The purpose of this . . .r~ l; f;- ~ is to adjust the traffic value downward, . ' ~ traffic to the particular destination that is likely to be ' -' For example, if the traffic to a first destination is generaUy valid, the weight associated with fraudulent traffic to that destination is generally low, say 0.1.
The remaining traffc, given by the value (I - weight), is therefore generally high, in this exarnple 0.9. This factor is appGed to the traffic value contained in the record being processed by simple ...,.~ .lif~ thereby yielding a mofGfied traffic value35 which is reduced from the previous value by 10'~. This mofGfied value is, in turn, compared with a second threshold value T2, in step 750. Note here that the second -- -11- 21~08~6 threshold value may, but need not, be the sarne as the fust tbreshold value Tl. If the result of the c~ ... in step 750 indicates a modified traffic value in excess ofT2, it can again be assumed that a large amount of authorized traffic can be expected to the destination in question. ~ , for that ~i~stiA ~inn, an "ALLOW" entry 5 is placed in the screening filter stored in data base 122 in step 755. If the result of the . , in step 750 indicates a modified traffic value less than T2, it can be concluded that the amount of authorized traffic to the destination in question is likely to be low. However, it is gene}ally desirable not to block all traffic in this instAAnce, since some amount of traffic is to be expected. Under these Cll. various 10 ''l " can be applied to the entry in the screening filter. These constraints can determine if certain conditions have been satisfied and aUow or deny a particular caU
as a function of the results of such .l~ The conditions can relate to the number of caUs made per unit of time, the time of day or day of week at which the calls are originated, or other similar factors chosen during the screening filter design 15 process. The constraints applied in step 760 must be consistent widh the ~AqF ~ iril-c of dhe network element contqining dhe screening filter, as ~' ' by the A ~ stored in design parameter data base 140. After the d~
constraints have been i~ t~rmin~7~ the entry for the presendy processed destination is stored in screening filter data base 122 in step 7O5.
If it is i~ in~d in step 715 that dhe destination contained in the retrieved record is for an on-net location, it may generally be assumed dhat the call is authorized, since there is a, ~J of interest between persons originating and receiving calls on dhe same VCN. Accordingly, an "ALLOW" entry is made in the screening filter in step 770. It is to be noted, however, dhat in some, - ~ it 25 may be desirable to apply constraints to, or totaUy block, caUs to certain ~J~
even though the ~ - are "on-net". In such event, the process beginning in step 720 may be applied to records pertaining to calls made to those ~7 -~
After processing of a record is completed either in step 726, 755, 765 or770, a 1 - is made in step 775 as to whedher there are additional 30 .l -~ to be processed for the selected origination element. If so, dhe process of FIG. 7 is repeated, beginning with step 705.
When all .~ have been processed, steps 780 and 785 are performed, in order to account for the possibility that, for the selected origination element, no traffic ;..r~.... A;i~... will be available for certain ~' indicating 35 that caUs to dhese locations should be blocked. In step 780, aU ~ with weighting factor "F" greater than a threshold value T3 are identified. A "DENY"

- 12 ~ 8 ~ ~
entry for these ~ ;r~ - is then added to the screening filter for the selected origination element irl step 785, thereby ,, ' entered in step 726.
The process of FIG. 7 then continues with step 790, in which a S ~1. ~... - .-i~,A is made as to whether additional records remain to be processed in data base 122. If so, the process of FIG. 7 beginning in step 700 is repeated. When all records have been processed, the process of FIG. 7 is completed in step 795.Referring now to FIG. 9, there is shown a typical format for a screening filter stored in screening filter data base 122. A scrcening filter can be thought of as 10 a logical table pertaining to one origination element, such as a particular location, station group or code group. For that origination dement, the screening filter contains either allow (denoted by entry "ALLOW"), deny (denoted by entry "DENY") or . ' status (denoted by entry "CONSTRAINED") for calls going from that originating element to various .' - ~r~nc~Ain~ status can 15 indicate that calls are allowed based upon factors such as number of calls made per unit time, or time of day and day of week when call origination occurs. Thus, inFIG. 9, for an originating location X, column 901 represents destination ;.. r,.. ~,;
which, as explained previously, may be arranged by geographic location (e.g., country code); code group (e.g.. area code); or station group (e.g., telephone 20 exchange). Column 902 ropresents the status of calls to that ~ c in~ ir~n either ALLOW, DENY or CONSTRAINED. If an entry "CONSTRAINED" is contained in column 902, then various logical conditions that may be associated with an access decision are set forth in column 903. The following example will illustrate. If the ;,.r~..... ~;;.. ,, processed in data aggregator 100 shows that the customer makes only 2S two calls to England during a typical businoss day from a location in New Jersey, the entry in column 903 may be denoted "ALLOW(N)", indicating allowance fo} up to N calls, and disallowance for subsequent calls during a business day.
Screening filters generated in screening filter processor 121 are stored in screening filter data base 122 prior to being applied to the switching elements in 30 VCN 160. Transfer of the; F.. ~IIA~ 1(1.1 in the screening filters is made via operations support system (OSS) 150, which is a front end to the network elements in VCN 160 in which the screening filter is stored and processed. OSS 150 is arranged to verify the i r ....... -~ ;. in the screening filters and then to download the screening filters into the network elements that control admission and denial of calls in VCN 160, e.g., 35 switches and data bases.

- -13- 21~084 The pwcess c~ , ;I by the present invention is not static, in that calling patterns are apt to change even after initial 5~ of the VCN and subsequent to initial loading of screening filters in the network elements within the VCN. For this reason, after the screening filters have been activated, there should be 5 ongoing monitoring of calls made by the customer using the VCN to identify anyfraudulent attempts and a feedback ' to make; .. " .~-l changes to the screening filters based on that; r.., . " -~ ;.... This updating amounts to a self-learning process that updates the screening filters based on data collected in the virtual network. To understand the updating process, reference to FIG. 10 10 will be instructive. This figure is a block diagram illustrating the c' , bet~veen a screening filter update processor 940 arranged in accordance with theprinciples of the present invention and various data bases that provide r .
thereto:
As shown in FIG. 10, screening filter update processor 940 receives 15 inputs from t vo data bases not previously described, namely, real tune call detail records data base 900 and fraud monitor data base 92Q Data base 900 contains records of calls that are made by users of VCN 160, and typically includes ;,~rr",llr~ describing, for each call, its point of origin and ' . as well as the call result, i.e., completed or blocked. If a call is blocked, records in data base 20 900 also include ;"r... ,.. ~ .. indicative of the reason for the non-rr mrl~hr~n such as that the call was blocked in the screening process using the screening filters just described, or for other reasons. Data base 920 includes records for blocked calls, which are formulated using ;..r..",. ;.,.. obtained from the VCN customer. The infrrm ~irn in these records includes r " indicating if a given call was 25 indeed found to be, or thought to be, fraudulent. This; r.."I.A~;.... may be compiled by analyzing customer payment records to indicate which calls were disputed, which calls were paid without protest, and which calls were segregated for further analysis.
Screening filter update processor 940 also receives ,i~ ' inputs stored in customer ;..r.,.,.. ~;.. data base 230, so that call detail recows from data 30 base 900 can be analyzed and segregated in terms of code groups and station groups, if necessary. Screening filters are presented to processor 940 from screening filter data base 122, and returned to that data base after the updating rwcess is completed.
Referring now to FIGS. 11 and 12, the process for updating screening filters stored in screening filter data base 122 is i11ush ated. Basically, the pwcess has 35 two parts: (a) examining call detail records to determine if the screening filters are operating properly or, if not, to determine if the screening filters should be relaxed or 21~Q8~

tightened, and (b) actually upddting the screening filters rr ~ /. Du}ing the first part of the process, blocked calls are examined to isolate calls blocked due to the screening process (as opposed to being blocked for other reasons, such as network cr~n~ctinn called party ~ ~Idb;L~y, etc). If calls were blocked due to screening, a 5 ,~ ;.. . is made as to whether the screening filter operated properly. If so, no change is necessary; if not, an adjustment is made. Conversely, calls that are not blocked are also examined to determine if they should have been blocked during the screening process, so that the screening filter can be a~ , upddted. The update process can be performed on a periodic basis, or at any time when a 10 significant change in calling patterns has been detected.
The screening filter upddte process described above begins in step 1101, in which a call detail record is retrieved f~om real time call records data base 900.
The record is examined in step 1102, to extract r~ -- defining the call origination point, and this r ' is compared with stored r - in 15 customer ;~r~ ddta base 230 to determine the originadon element (stdtion group, code group, etc.) associated with the call. In step 1103, a ,l ~ i,... ismade, again by examining ...r.., . " ;.... in the call detail record, as to whether the call was blocked. If a positive result is obtdined in this step, ~ defining the cause of the blocking is extracted from the call detail record in step 1104. As stated 20 previously, the cauæ can be from use of the screening filter, or from other reasons associated with the network, the calling party, or other factors not pertinent to this invention.
If it is rlPtPrrninp 1 that the call was blocked (step 1103), and the cause of the blocking was due to the action of the screening filter (step 1104), a ~- -25 is mdde in step 1105 as to whether the block~d call was in fact (or is likely to be)fraudulent. If a call was blocked due to screening, and was in fact frdudulent, the system is operating properly. In that event, the record is discarded in step 1107. On the other hand, if a call was blocked due to screening, and was not in fact fraudulent, the system is not operating properly. In that event, the record is stored for furlher 30 processing in step 1106. Storage may be in data base 122, or a separdte data base, not shown.
If it is ~t~rninP~1 that the call was not blocked (step 1103), a ~' is made in step 1108 as to whether the completed call was in fact fraudulent. If so, the system is not operating properly, and the record is stored for 35 further processing in step 1109. On the other hand, if a negdtive result is obtained in step 1108, the record may also be discarded in step 1107. Note that calls that were -15- 21008~B
blocked for reasons not related to screening are also discarded in step 1107.
When a particular call detail record retrieved in step 1101 has been processed, a ~' is ma~e in step 1110 as to whother there are more records for processing. If so, the process beginning in step 1101 is repeated. If not, the first S part of the process is complete, and the second part, beginning witb step 1111 of FIG. 12, is performed. As stated previously, screening filters that contain restrictions which need to be relaxed or tightened are identified and ~ , modified.
In step 1111, a screening filter stored in data base 122 is selected. For this screening filter, a particular destination location is selected in step 1112. Next, 10 the records stored in steps 1106 and 1109 are examined in step 1113, to retrieve all of those records that pertain to the origination element of the selected screening filter and to the destination selected in step 1112. These records are ~ , ' in step 1114, such that retrieved records pertaining to "good calls blocked" that were stored in step 1106 are treated differently from "fraudulent calls completed" that werelS stored in step 1109. With respect to the former calls, a .' is made in step 1115 as to whether or not the number of such calls exceeds a ~
threshold T3. If so, the restriction placed on these calls by the screening filter are too stringent, and must be relaxed in step 1116. This is done, for example, by changing the constraints shown in column 903 of FIG. 9. On the other hand, if a negative 20 result is obtained irl step 1114, indicating that "fraudulent calls c~u,~l~,tLd that were stored in step 1109 are being processed, a ~f ~ is made in step 1117 as to whether or not the number of completed fraudulent calls exceeds another threshold T4. If so, the restriction placed on these calls by the screening filter is too lenient, and must bc tightened in step 1119. After . .. r. ,,,, . ~ i. . .
25 in the screening filter pertaining to the current destination is updated in either step 1116 or 1119, a ~ is made in step 1118 as to whether there are more ' in the selected screening filter that must be processed. If so, the process is repeated, beginning with step 1112. When there are no more d for the selected screening filter, a ~' is made in step 1120 as to whether there are 30 more screening filters in data base 122 that require updating. If so, the process beginning with step 1111 is repeated. When all processing has been completed, the modified screening filters are updated in data base 122 and may be applied to VCN
160 via OSS 150, in step 1121.
FIG. 13 is a block diagram illustrating some of the network elements in 35 a typical virtual c~ network such as VCN 160, and the between the VCN and on-net and off-net call destination and origination locations.

At the heart of the network are several ~ ' network switehes, which maybe software controlled eleetronic switehing systems such as the 4ESSTM eleetronie switeh available from AT&T. Two such switches 1301 and 1302 are shown in FIG.
13 and are used to calry both ordinary long distance t'~ traffie as 5 well as traffie originated by VCN customers who have a~ranged with the network provider to have calls completed via VCN 160 in a w..~. t, ~ and otherwise ad~ O..,~ manner. The switches in the VCN are supported by ono or more data bases, such as 1350 and 1351.
A call initiated by a VCN customcr may originate from an "on-net"
10 loeation, such as telephone stations 1310 or 1311, which are connected to network switeh 1301 via a first customer owned PBX 1320, which is linked to switeh 1301 via dedicated access facilities. Other "on-net" dedicated loeations are telephone stations 1314 and 1315 conneeted to a different networl~ switch 1302 via a second customer owned PBX 1322. The call may also originate from an "on-net" switched 15 loeation, which could be another station 1312 coMeeted to switeh 1301 via switched loeal aecess provided by a loeal exchange carrier (IEC) network designated generally as 1330. Station 1312 is served by another PBX 1321.
Stations 1310 and 1311 are "on-net" dedicated loeations because they are connected to the VCN via dedicated access, and ~ regarding these 20 stations is known, in advance, by the elements in VCN 160. On the other hand,station 1312 is an "on-net" switehed loeation, because it is conneeted to the VCN via switehed aecess, and r ' regarding this station is also known in advance by the elements in VCN 160.
Additionally, VCN 160 is typically arranged to allow calls originated 25 from off-net loeations at least some access to the services provided by switch 1301.
These ealls are generally referred to as VCN Remote Access Calls. Staion 1313 iscoMeeted to the switch 1301 via switched local access provided via a loeal exchange carrier (LEC) network 1330. T.. r, ...., - '. ,.. about this station is not known in advance by the eloments in VCN 160. Access to the VCN service is gained when the user 30 dials a ~..fA~ 7 l ~1 number recognized by switeh 1301 as a request for access. At that point, the user typically also provides other ' ~ (such as a password) needed to detenrLne if access should be allowed or denie(i. In addition, as provided in the present invendon, access for both on-net and off-net originated calls must be permitted by the screening filter which contains an ALLOW, DENY or 35 CONSTRAINED indication for each VCN call. For the purposes of FIG. 13 also shows off-net locations 1340 connected to switch 1302.

. ~ 21~3~

When a call is recGived in network switch 1301 or 1302 and identified as a VCN call, i.c., originating either (a) in an on-net location or (b) by a VCN
customer in an off-net location, a query is rouKd to an associated data base (data base 1350 or 1351, depending on the customer) so that stored; r " ", . ;,~.. relating to 5 the call can be retrieved. This ~ enables d~ , ' call treatment. such as dl,l,.~,v ' dialing, special billing, and predefined routing, to be provided.However, before the call is allowed access to routing via switch 1301 or 1302, the screening filKr 1360 or 1361 stored in the network data base 1350 or 1351, ~ .ly, is also retrieved. Within the ~ in the retrieved 10 screening filKr, the entry, ~ " ~ to the origination element and the caU
destinaion for the call being processed is IOCaKd, to determine the status for that call. Based upon the call status contained in the screening filter, the call is either allowed or denied, or constraints are imposed. If the call is allowed, switch 1301 or 1302 completes the call with the ~r ~ ' ' call Ireatment; if the call is denied,15 switch 1301 or 1302 may be instructed to play an to advise the caller that the call cannot be completed.
The above invention, when properly designed, can provide significant protection against fraudulent calls in a virtual network Many . ,n~ ;n-- and r.l~ -l;n.~- are also possible, so that the invention is to be limited only by the 20 appended claims.

Claims (25)

1. A processor for generating screening information used to control the admission of calls to a customer's virtual private communications network, said processor including means for receiving (a) first information relating to historical communications traffic patterns for said customer, and (b) second information relating to fraudulent calls applied to said network, and means for generating said screening information as a joint function of said first and second information.

2. The invention defined in claim 1 wherein said processor further includes means for aggregating said first information based upon originating locations and destination locations for said traffic, and means for designing said communications network and for designating said originating and destination locations as on-net locations or off-net locations, the designing and designating each being a function of the aggregated information.

3. The invention defined in claim 2 wherein said processor further includes means for storing information indicative of fraudulent calls placed through said communications network to individual ones of said off-net locations, and wherein said generating means is responsive to information stored in said last mentioned storing means for generating admit or deny indicators for calls placed to said individual locations.

4. A system for generating screening filters used in processing calls placed by users of a virtual communications network (VCN), said system includingmeans for storing telecommunications traffic information that is relevant for both the design of said VCN as well as for generation of said screening filters, means for aggregating said telecommunications traffic information in accordance with the locations at which said traffic originated, means for applying said aggregated traffic information both to a network design tool arranged to design said VCN as well as to a screening filter generator (SFG), means for applying, to said SFG, information from said network design tool indicative of the on-net and off-net locations in the VCN, and information from a data base that provides information indicative of the incidence of fraudulent calling to different destinations, and means in said SFG arranged to process said information together with information relating to VCN design parameters in order to generate screening filters that can determine, on a call by call basis, whether a call made using the VCN should be allowed or denied.

5. The invention defined in claim 4 wherein said telecommunications traffic information includes traffic data contained in network and customer premises equipment call detail records and billing data.

6. The invention defined in claim 4 wherein said VCN includes a plurality of origination elements grouped by station groups, code groups and ID
groups, and each of said screening filters pertains to calls originating from one of said origination elements.

7. A system for generating screening filters used in processing calls placed by users of a virtual communications network (VCN), said system including means for storing telecommunications traffic information, means responsive to said telecommunications traffic information for generating a design for said VCN, and means for generating said screening filters, said generating means being jointly responsive to (a) said telecommunications traffic information, and (b) information derived from said design for said VCN.

8. The invention defined in claim 7 wherein said generating means is further responsive to information indicative of the incidence of fraudulent calling to different destinations.

9. The invention defined in claim 8 wherein said information derived from said design includes information indicative of the on-net and off-net locations in said VCN.

10. A system for controlling telecommunications traffic in a virtual communications network arranged to route calls from a plurality of originating locations to a plurality of destination locations, said system including first means for storing data indicative of historical calling patterns for calls made between said originating and destination locations, said data being aggregated by originating locations and destination locations, second means for storing data indicative of the expected incidence of fraudulent calls placed to said destination locations, means responsive to the aggregated data for configuring said VCN, the configuration of said VCN including information defining the on-net status of said originating locations and said destination locations, and means for generating a plurality of screening tables, each of said screening tables indicative of the extent to which a user of said virtual communications network is allowed to place a call from one of said originating locations to each one of said destination locations, wherein the information in said screening tables is generated as a joint function of information in said first and second storing means.

11. Apparatus for generating filters used to determine the eligibility of users of a software defined network to place calls between originating locations and destination locations, said apparatus including first means for storing data indicative of historical patterns of calls placed between said originating locations and said destination locations, second means responsive to said data for designing characteristics of said software defined network, said characteristics including information relating to said originating and destination locations, and means for generating said filters jointly in response to said stored data and said characteristics.

12. A virtual communications network comprising at least one switch for controlling the connection of calls from originating locations to destination locations, and means for controlling the operation of said switch, said controlling means including means for determining in response to predetermined call screening information the eligibility of a call originated at a particular one of said originating locations to be connected to a particular one of said destination locations through said network, CHARACTERIZED IN THAT said call screening information is a joint function of (a) first information relating to historical communications traffic patterns for a user of said network, and (b) second information relating to fraudulent calls applied to said network.

13. A call screening filter generator for use in a software defined network, said network including (a) switching means for connecting call origination locations to call destination locations, and (b) control means for supervising the completion of calls connected via said switching means, wherein said screening filter generator includes (1) means for aggregating call detail records indicative of calling patterns for users of said software defined network, (2) means responsive to information describing calling patterns between said origination locations and said destination locations output from said aggregating means for generating configuration information used in the design of said network, and (3) means responsive jointly to said calling pattern information and said configuration information for generating screening filters which supervise the completion of calls in said control means.

14. A method of generating screening information used to control the admission of calls to a customer's virtual communications network, said method including the steps of receiving (a) first information relating to historical communications traffic patterns for said customer, and (b) second information relating to fraudulent calls applied to said network, and generating said screening information as a joint function of said first and second information.

15. The method defined in claim 14 wherein said method further includes the steps of aggregating said first information based upon originating locations and destination locations for said traffic, and designing said communications network and designating said originating and destination locations as on-net locations or off-net locations, said designing and designating each being a function of the aggregated information.

16. The method defined in claim 15 wherein said method further includes the step of storing information indicative of fraudulent calls placed through said communications network to individual ones of said off-net locations, and whereinsaid generating step is performed responsive to information stored in said last mentioned storing step for generating admit or deny indicators for calls placed to said individual locations.

17. A method for generating screening filters used in processing calls placed by users of a virtual communications network (VCN), said method includingthe steps of storing telecommunications traffic information that is relevant for both the design of said VCN as well as for generation of said screening filters, aggregating said telecommunications traffic information in accordance with the locations at which said traffic originated, applying said aggregated traffic information both to a network design tool arranged to design said VCN as well as to a screening filter generator (SFG), applying to sad SFG information from said network design tool indicative of the on-net and off-net locations in the VCN, and information from a data base that provides information indicative of the incidence of fraudulent calling to different destinations, and processing information in said SFG together with information relating to VCN design parameters in order to generate screening filters that can determine, on a call by call basis, whether a call made using the VCN should be allowed or denied.

18. The method defined in claim 17 wherein said telecommunications traffic information includes traffic data contained in network and customer premises equipment call detail records and billing data.

19. The method defined in claim 17 wherein said VCN includes a plurality of origination elements grouped by station groups, code groups and ID
groups, and each of said screening filters pertains to calls originating from one of said origination elements.

20. A method for generating screening filters used in processing calls placed by users of a virtual communications network (VCN), said method includingstoring telecommunications traffic information, responsive to said telecommunications traffic information, generating a design for said VCN, and generating said screening filters, said generating step being jointly responsive to (a) said telecommunications traffic information and (b) information derived from said design for said VCN.

21. The method defined in claim 20 wherein said generating step further includes the step of generating a weighting factor indicative of the incidence of fraudulent calling to different domestic and international destinations.

22. The method defined in claim 21 wherein said information derived from said design includes information indicative of the on-net and off-net locations in said VCN.

23. A method for controlling telecommunications traffic in a virtual communications network arranged to route calls from a plurality of originating locations to a plurality of destination locations, said method including the steps of storing data indicative of historical calling patterns for calls made between said originating locations and said destination location, said data being aggregated by originating locations and destination locations, storing data indicative of the expected incidence of fraudulent calls placed to said destination locations, configuring said VCN, using said aggregated data, the configuration of said VCN including information defining the on-net status of said originating locations and said destination locations, and generating a plurality of screening tables, each of said screening tables indicative of the extent to which a user of said virtual communications network is allowed to place a call from one of said originating locations to each one of said destination locations, wherein the information in said screening tables is generated as a function of information in said first and second storing means.

24. A method for generating filters used to determine the eligibility of users of a software defined network to place calls between originating locations and destination locations, said method including the steps of storing data indicative of historical patterns of calls placed between said originating locations and said destination locations, responsive to data stored in said storing step, designing characteristics of said software defined network, said characteristics including information relating to said originating and destination locations, and generating said filters jointly in response to both said stored data and said characteristics.

25. A method for use in virtual communications network (VCN) which comprises at least one switch for controlling the connection of calls from originating locations to destination locations, said VCN having a design generated in response to a body of telecommunications traffic information, said method comprising the steps of making a determination, in response to a call initiated from a particular one of said originating locations to a particular one of said destination locations through said network and further in response to predetermined call screening information, as to whether said call should be completed or denied, and controlling the operation of said switch in accordance with said determination, CHARACTERIZED IN THAT said call screening information is a joint function of (a) said telecommunications traffic information and (b) said design.