Patent Description:
The claimed invention is defined by independent claim <NUM>. Preferred embodiments are defined in dependent claim <NUM>. In accordance with the present disclosure, a real time analysis system analyzes communications data to detect and block fraudulent communications. The real time analysis system may automatically block fraudulent communication data and non-fraudulent communications data in real time. For example, the real time analysis system may automatically generate and transmit blocking messages for fraudulent communications and non-fraudulent communications during a communications initiation or set up process.

In accordance with one embodiment, the real time analysis system analyzes calls for fraud in real time. A telecommunications service provider's real time analysis system analyzes call termination requests and detects potentially fraudulent calls. The real time analysis system may automatically block potentially fraudulent calls and non-fraudulent calls in real time. For example, the real time analysis system may automatically block potentially fraudulent calls and non-fraudulent calls during a call initiation or set up process.

In one embodiment, the real time analysis system enables efficient correction of false positives. A false positive is a call that was incorrectly identified as potentially fraudulent and blocked, but in reality should not have been blocked. The real time analysis system enables false positives to be identified and corrected such that the real time analysis system does not continue to inappropriately block such a call in the future, as well as calls with similar attributes in the future.

In one embodiment, the telecommunications service provider's network and equipment is not within the natural call termination path for an analyzed call (e.g., the telecommunications service provider's network and equipment would not normally be used to route a call to its final destination). The telecommunications service provider's network and equipment associated with the real time analysis system is configured to send a "reject call" message back to a telecommunication network that originally routed the call to the real time analysis system for analysis when the real time analysis system determines that the call should be blocked. In another such embodiment, if the real time analysis system determines that the analyzed call should not be blocked (i.e., should be allowed to be terminated to the intended destination), the telecommunications service provider's network and equipment associated with the real time analysis system is configured to send a "reject call" message back to a telecommunication network that originally routed the call to the real time analysis system for analysis. In other words, in one such embodiment, the telecommunications service provider's network and equipment associated with the real time analysis system is configured to send a "reject call" message regardless of whether or not the call should be blocked.

In accordance with one embodiment, the call analysis system detects potentially fraudulent calls based upon one or more factors. Some of the factors include unallocated numbers, invalid number ranges, known fraudulent A-numbers, known fraudulent B-numbers, highly repeated A-numbers, highly repeated B-numbers, high cost destinations, European out-of-region surcharge calls, customer-specific requirements, etc..

While in one embodiment, the real time analysis system can be implemented in a telecommunications network (PSTN or VoIP), the invention is applicable to call analysis in any network over which calls are routed.

It should also be appreciated that the real time analysis system for communications data is not limited to call analysis. For example, the real time analysis system can be applied to other forms of communications, such as messaging or any other suitable form of communications. Certain messaging embodiments are described in more detail below.

The following drawings illustrate examples of various components of the invention disclosed herein, and are for illustrative purposes only.

The fields of Internet based communication and telephony have proven to be a viable technology and are evolving at an ever-increasing rate. It is now common to use any type of end point such as a telephone terminal, handset, cell phone, computer, smart phone, etc. to initiate or receive a voice call either over the traditional public switched telephone network (PSTN) or the Internet using Voice over Internet Protocol (VoIP). A call may be "terminated" (i.e., completed to an appropriate destination, in telephony parlance) by connecting one end point to either the Internet or PSTN, which in turn accesses at least one or more gateways to ultimately terminate the call to another endpoint. The terminated call may travel through the PSTN, the Internet, and even over private networks (or any combination of the foregoing) to reach the call's ultimate destination. The end points and networks may also be frequently used for exchanging asynchronous communications, such as messaging.

The PSTN is a circuit switched network. That is, the PSTN assigns a dedicated communication line or resource to a user with which to complete the telephone call, and the user can utilize the assigned resource of the PSTN in any chosen manner. It is understood that the user is paying for the use of the dedicated resource of the PSTN. While the circuit switched approach of the PSTN system is not necessarily the most efficient system in terms of call traffic, it is relatively easy to ensure that information destined for a particular user is delivered.

The Internet is a packet switched network in which communication is accomplished by breaking transmitted data into "packets" and interleaving the packets to best utilize the bandwidth available at any given time on the Internet. When the packets reach their intended destination, they must be reassembled into the originally transmitted data. Loss of packets, and thus data, occurs frequently in such a network, and the ability of the network to successfully transmit information from one point in the network to another determines the quality of the network.

A system of gateways located at various endpoints on the Internet can facilitate VoIP telephony by permitting the gateways to act as protocol bridges between the PSTN and the Internet. A VoIP service provider may operate a VoIP network which can route/terminate a VoIP call that traverses both PSTN networks and packet switched networks like the Internet. The originator of a call may use a standard telephone connected to a first PSTN to dial a telephone number of another person on a second PSTN. A trunk line of the first PSTN connects to an originator gateway (telephony switch or server) that connects the first PSTN to a packet switched network, such as the Internet. The initiator gateway may send its position in the network along with the telephone number of the call recipient (within the second PSTN) to a route server, which determines which of many other gateways should be used to complete the call to the telephone number in the second PSTN and transmits this information to the initiator gateway. A call connection is then established between the originator gateway and a terminator gateway serving the second PSTN, which may involve routing the call through several intermediate servers on the Internet. The terminator gateway completes the call to the called party by connecting to the second PSTN.

The connection of a call between users on PSTNs is just provided as an example. Those skilled in the art will appreciate that the users need not necessarily communicate via a PSTN. In general, a call will be considered as originating with a caller of one telephony service provider and being destined to a call recipient (regardless of the type of connection to the customer or the recipient).

The telephony service provider typically generates revenue, at least in part, by buying and reselling call completion services (also known as termination services). That is, when an originator gateway in the United States, for example, needs to complete a call to Luxembourg, for example, the originator gateway will send that call through a particular terminating gateway that can terminate the call to an end point at the final destination in Luxembourg. The telephony service provider associated with the originating gateway will pay the terminating gateway operator a fee, for example, fifty cents per minute, for such termination services. In one embodiment, if a VoIP service provider provides call termination services to the originating gateway (e.g., sits in the call path between originating service provider and the termination service provider and routes the call to the terminating gateway in Luxembourg), the VoIP service provider may charge the originating service provider (associated with the originator gateway) fifty-five cents per minute for such termination services to Luxembourg. The five-cent difference in this example is the VoIP service provider's profit.

Further details of techniques used in furtherance of the foregoing are described in commonly owned <CIT>, ("the '<NUM> patent") assigned to the same assignee as the present application. Other suitable mechanisms may be used to route and terminate calls over the PSTN and the Internet.

The above business model is viable in large part due to the fact that the various carriers that operate around the world often do not have individual contractual relationships with each other. Without such relationships, it is difficult to terminate calls to every location in the world. A VoIP service provider may perform, in a loose sense, a matching service that matches those seeking to send calls to specific destinations, with those seeking to earn money by terminating (completing) such calls in those destinations. The contractual relationships required however, are typically between the various carriers that operate the originating and terminating gateways, and the VoIP service provider.

Take for example, a VoIP service provider contracts for termination services with a particular terminating gateway operator. An operator of an originating gateway also contracts with the VoIP service provider to send/terminate call traffic to appropriate destinations for the operator of the originating gateway. If the originating gateway sends the VoIP service provider a call to terminate with the terminating gateway, but the operator of the originating gateway does not pay the VoIP service provider for such call termination services, the VoIP service provider will still be contractually bound to pay the terminating gateway operator for terminating the call. This potentially results in a loss of revenue for the VoIP service provider. This often happens in the case of fraud or hacking. For example, if someone hacks into the local network connected to an originating gateway, the hacker can cause the originating gateway to send fraudulent calls to the VoIP service provider. The VoIP service provider may send the fraudulent calls to a terminating gateway operator to terminate (e.g., complete) the fraudulent calls. The operator of the originating gateway may not pay for those calls, while the VoIP service provider may have contracted with the terminating gateway operator to pay for calls that the terminating gateway operator terminates to a destination (including fraudulent calls). Hence, a loss of revenue to the VoIP service provider may result.

Further, an originating gateway operator may be a small carrier without a sophisticated security system. It is thus often possible for a malicious source to breach a system and relay malicious traffic to the VoIP service provider, which appears to be legitimate customer traffic, without the customer (i.e., the originating gateway operator) even being aware. The VoIP service provider is ultimately responsible to remunerate the downstream service providers, and often the defrauded customer is too small to assume the financial losses, or is not contractually or legally responsible. It should be appreciated that the VoIP service provider could be any suitable telecommunication service provider that routes or terminates calls.

One more serious problem is that the fraudulent traffic may not be discovered until days or weeks later, when call detail records ("CDR") show an unusually high amount of traffic and unusually high charges to a specific destination, for example. Another problem is that the fraud that results in loss to the VoIP service provider is often fraud committed against one of the carriers' networks, not directly against the VoIP service provider. Hence, it is difficult for the VoIP service provider to manage the fraud, even though the resulting loss may largely be borne by the VoIP service provider.

The VoIP service provider must play a delicate balancing act between catching enough fraudulent call traffic and allowing legitimate call traffic to be terminated. For example, allowing legitimate traffic from to flow between customers and destinations even when the call volume increases. And even being exposed to significant financial losses if the VoIP service provider does not properly and quickly react to situations that do, in fact, involve fraudulent traffic from trusted customers.

The VoIP service provider may also desire to sell real time fraud monitoring service to other telecom carriers without terminating a call for such other carriers. The VoIP service provider may also desire to sell a real time fraud monitoring services to other telecom carriers by utilizing existing telecommunications infrastructure equipment.

<FIG> is a diagrammatic view of one embodiment of a network system adapted to perform real time analysis of voice calls and to minimize fraudulent calls.

End point <NUM> is a device that enables a user to transmit and receive data, such as making and receiving telephone calls. End point <NUM> may include a telephone terminal, handset, cell phone, computer, smart phone, etc. Other suitable devices are described below. End point <NUM> is in communication with at least carrier network <NUM>. Carrier network <NUM> may be a PSTN or an IP network that enables end point <NUM> to make and receive calls. Carrier network <NUM> includes at least one network element <NUM> that can transmit and receive telephone calls from devices such as end point <NUM> and other network elements (from within the carrier network <NUM> or outside of carrier network <NUM>). In some embodiments, carrier network <NUM> may include any number of network elements necessary to operate a carrier network. Network element <NUM> may be a telephony switch or telephony gateway or other suitable network device or server (as is further described below). Network element <NUM> may be configured to transmit and receive telephone calls over either the PSTN or an IP network (e.g., for VoIP calls), or both. As shown in <FIG>, carrier network <NUM> may be in communication with many other networks such as carrier network <NUM>, carrier network <NUM>, network <NUM>, and carrier network <NUM>. It should be appreciated that carrier network <NUM> may communicate with any suitable number of other networks and devices.

In one embodiment, carrier network <NUM> includes several network elements. Carrier network <NUM> includes at least one network element <NUM> that can transmit and receive telephone calls. In some embodiments, carrier network <NUM> may include any number of network elements necessary to operate a carrier network. Network element <NUM> may be a telephony switch or telephony gateway or other suitable network device or server (as is further described below). Network element <NUM> may be configured to transmit and receive telephone calls over either the PSTN (e.g., for TDM calls) or an IP network (e.g., for VoIP calls), or both. Network element <NUM> may include an SMS or MMS server or other messaging service that permits end points (e.g., <NUM>, <NUM>, <NUM>, <NUM>) to communicate with asynchronous communications. Network element <NUM> may be a stand alone messaging server. Where multiple network elements <NUM> are present in carrier network <NUM>, network elements <NUM> may be any suitable combinations of telephony or messaging switches, gateways, servers, etc. As shown in <FIG>, carrier network <NUM> may be in communication with many other networks such as carrier network <NUM>, carrier network <NUM>, and network <NUM>. It should be appreciated that carrier network <NUM> may communicate with any suitable number of other networks and devices. While not shown, carrier network <NUM> may be configured to communicate with any number of end points (e.g., to receive or terminal calls to these end points).

In one embodiment carrier network <NUM> further includes a routing system. The routing system may include specially programmed servers or network elements such as network element <NUM> and network element <NUM>. The specially programmed network elements <NUM> and <NUM> may perform operations such as network policy and routing management. Network elements <NUM> and <NUM> may perform decision analysis for network policy and route management such as toll-free routing, least-cost routing, number portability, voice VPN, SIP trunking, centralized dial plans, emergency services, etc. In some embodiments (not shown), the routing system may divide the work of network policy and route management over more than two network elements. Alternatively, in some embodiments (not shown), the routing system may rely on one network element to perform such operations.

In one embodiment, network <NUM> may be a PSTN network. In an alternative embodiment, network <NUM> may be an IP network such as the Internet. As shown in <FIG>, network <NUM> is in communication with carrier network <NUM>, carrier network <NUM>, carrier network <NUM>. However, it should be appreciated that network <NUM> may be in communication with any suitable number of networks.

Carrier network <NUM> may be a PSTN or an IP network that enables end points to make and receive calls. Carrier network <NUM> includes at least one network element <NUM> that can transmit and receive telephone calls from end points and other network elements (from within the carrier network <NUM> or outside of carrier network <NUM>). In some embodiments, carrier network <NUM> may include any number of network elements necessary to operate a carrier network. Network element <NUM> may be a telephony switch or telephony gateway or other suitable network device or server (as is further described below). Network element <NUM> may be configured to transmit and receive telephone calls over either the PSTN (e.g., for TDM calls) or an IP network (e.g., for VoIP calls), or both. As shown in <FIG>, carrier network <NUM> may be in communication with many other networks such as carrier network <NUM>, and network <NUM>. It should be appreciated that carrier network <NUM> may communicate with any suitable number of other networks and devices. As shown in <FIG>, carrier network <NUM> is in communication with at least end point <NUM> and end point <NUM>. End points <NUM> and <NUM> are devices that enables a user to transmit and receive data, such as making and receiving telephone calls. End points <NUM> and <NUM> may include a telephone terminal, handset, cell phone, computer, smart phone, etc. Other suitable devices are described below for end points <NUM> and <NUM>.

Carrier network <NUM> may be a PSTN or an IP network that enables end points to make and receive calls. Carrier network <NUM> includes at least one network element <NUM> that can transmit and receive telephone calls from end points and other network elements (from within the carrier network <NUM> or outside of carrier network <NUM>). In some embodiments, carrier network <NUM> may include any number of network elements necessary to operate a carrier network. Network element <NUM> may be a telephony switch or telephony gateway or other suitable network device or server (as is further described below). Network element <NUM> may be configured to transmit and receive telephone calls over either the PSTN (e.g., for TDM calls) or an IP network (e.g., for VoIP calls), or both. As shown in <FIG>, carrier network <NUM> may be in communication with many other networks such as carrier network <NUM>. It should be appreciated that carrier network <NUM> may communicate with any suitable number of other networks and devices. As shown in <FIG>, carrier network <NUM> is in communication with at least end point <NUM>. End point <NUM> is a device that enables a user to transmit and receive data, such as making and receiving telephone calls. End point <NUM> may include a telephone terminal, handset, cell phone, computer, smart phone, etc. Other suitable devices are described below for end point <NUM>.

One embodiment of an operation of the real time analysis system is disclosed below. End point <NUM> makes a call to end point <NUM>. In this embodiment, end point <NUM> is in communication with carrier network <NUM>. Thus, carrier network <NUM> handles the call from end point <NUM>. The call may be handled by network element <NUM>. As part of the call setup request, network element <NUM> receives at least end point <NUM>'s information (e.g., an A-number) as well as the end point <NUM> or the called party's number (e.g., a B-number). In one embodiment, network element <NUM> is a telephony switch that determines that end point <NUM> is attempting to place a call to end point <NUM>. In an alternative embodiment, network element <NUM> works with other network elements in carrier network <NUM> to determine how and where to route the call to end point <NUM>. Based on the B-number associated with end point <NUM>, network element <NUM> determines that the best path for the call is through network <NUM> to carrier network <NUM> (where end point <NUM> is located). Network element <NUM> routes the call through network <NUM> and terminates the call with carrier network <NUM>. Network element <NUM> may handle incoming calls from network <NUM>. Network element <NUM> may determine where to next route the call to reach end point <NUM>. In one such embodiment using the real time analysis system, network element <NUM> determines that carrier network <NUM> should receive the call.

In one embodiment network element <NUM> does not realize that carrier network <NUM> is not in the typical call termination path and may only be in the call termination path for fraud analysis. That is, in one such embodiment, carrier network <NUM> is not used to actually route the call to a different carrier network for termination. In one embodiment, carrier network <NUM> will always send the call back to carrier network <NUM> for termination whether to an end point on the network of carrier network <NUM> or to another carrier network. In one embodiment, network element <NUM> receives the call for carrier network <NUM>. In one embodiment, where network element <NUM> relies on a routing system (e.g., network elements <NUM> and <NUM>) to make determinations about how to route a call, network element <NUM> may route the call to network element <NUM> for processing. Network element <NUM> may analyze the call and determine that the call was routed from carrier network <NUM>. Network element <NUM> may be configured to further route the call to network element <NUM> for further analysis.

In one embodiment, network element <NUM> may be specially programmed or configured to store and maintain a blacklist of known problematic attributes associated with a phone call. For example, the blacklist may cause network element to analyze the call to determine if the phone number (e.g., the A-number) associated with end point <NUM> is an unallocated number, from invalid number ranges, known fraudulent A-numbers, highly repeated A-numbers, high cost destinations, European out-of-region surcharge area, customer-specific requirements, etc. Any single one of these factors may be used alone in any suitable combination to determine potential fraud.

Similarly, network element <NUM> may be specially programed or configured to use its blacklist to analyze the phone number (e.g., the B-number) associated with the destination of end point <NUM> for similar problems. For example, the blacklist may cause network element <NUM> to analyze the call to determine if the phone number (e.g., the B-number) associated with end point <NUM> is an unallocated number, an invalid number range, known fraudulent B-numbers, highly repeated B-numbers, high cost destinations, European out-of-region surcharge, customer-specific requirements, etc. Any single one of these factors may be used alone in any suitable combination to determine potential fraud.

In one embodiment, if network element <NUM> analyzes the call and at least one call attribute can be matched against the blacklist, the network element <NUM> flags the call as a potentially fraudulent call. For example, if the calling party (end point <NUM>) is calling from a high cost destination, network element <NUM> flags the call as a potentially fraudulent call. In one embodiment, after network element <NUM> flags the call as potentially fraudulent, network element <NUM> further analyzes the call and the call attributes against a stored and maintained whitelist. If network element <NUM> determines that nothing stored in the whitelist provides a reason to remove the flag on the call from end point <NUM>, network element <NUM> determines that the call from end point <NUM> should be blocked. Network element <NUM> may transmit a rejection message to network element <NUM>. Network element <NUM> may transmit the rejection message to network element <NUM>. Network element <NUM> may generate and transmit a rejection message to network element <NUM> of carrier network <NUM>. The rejection message may be in the form of a standard Session Initiation Protocol (SIP) rejection message used between telephony switches. The SIP message may be in a predefined format that carrier network <NUM> and carrier network <NUM> agreed upon to indicate that a fraudulent call was suspected. It should be appreciated that the SIP rejection message may be in a form that would not normally convey to the recipient telephony switch that the call was rejected for suspected fraud. It should also be appreciated that the rejection message may be in the form of rejection "cause codes" for ITU or SS7 compliant systems. In either case, if network element <NUM> received a rejection message from network element <NUM> where the rejection message typically indicated that the B-number associated with the call could not be found, carrier network <NUM> may determine that such a rejection message from network element <NUM> means that carrier network <NUM> rejected the call due to suspected fraud. Upon receiving such a rejection from carrier network <NUM>, carrier network <NUM> may block the call and send a message back to carrier network <NUM> indicating that the call could not be completed.

In one embodiment, carrier network <NUM> may determine that calls from end point <NUM> destined for end point <NUM> are not fraudulent. For example, end point <NUM> may be associated with a satellite office of a company associated with end point <NUM>. Thus, despite the concern about the call from end point <NUM> originating from a high cost destination, the call should be completed. Carrier network <NUM> may transmit a message to network element <NUM> (or the network element performing the real time analysis in carrier network <NUM>) to indicate that the whitelist should include an entry for calls originating from end point <NUM> and destined for end point <NUM> and should not be flagged as fraudulent. In one embodiment, if carrier network <NUM> provided a reason why network element <NUM> should include end point <NUM> on the whitelist, network element <NUM> may modify the whitelist to add additional entries based on applying a similar rational to other similar calls. For example, network element <NUM> may identify that the phone number associated with end point <NUM> is associated with a block of phone numbers assigned to the same company. Thus, network element <NUM> may update its whitelist automatically such that calls from the identified block of phone numbers destined for end point <NUM> should not be blocked in the future. It should be appreciated if network element <NUM> is provided reasons for modifying the whitelist, network element <NUM> may be configured to apply these reasons to other calls to prevent other future calls from being improperly blocked. These improperly blocked calls are considered false positives.

In another embodiment, network element <NUM> may not receive any reason why end point <NUM> should be included on the whitelist. Carrier network <NUM> may transmit a message to network element <NUM> (or the network element performing the real time analysis in carrier network <NUM>) to indicate that the call originating from end point <NUM> and destined for end point <NUM> should not have been flagged as fraudulent. In one embodiment, network element <NUM> may store the message from carrier network <NUM>, but not take further action. If another end point <NUM> on carrier network <NUM> attempts to call end point <NUM>, network element <NUM> may again determine that such a call should be flagged as fraudulent and blocked for the same or similar reasons as the call from end point <NUM> to end point <NUM> was blocked. Carrier network <NUM> may transmit a message to network element <NUM> to indicate that that the call originating from end point <NUM> and destined for end point <NUM> should not have been flagged as fraudulent. In one embodiment, network element <NUM> may store the message from carrier network <NUM>, but not take further action.

In one embodiment, based on receiving messages indicating that calls from end points <NUM> and <NUM> to end point <NUM> were not fraudulent, network element <NUM> may compare attributes between the calls from end point <NUM> and <NUM> to determine if there is a common attribute that is a subset of the blacklist attribute associated with the first call (the call from end point <NUM>) and the second call (the call from end point <NUM>). For example, if the blacklist attribute associated with the calls from end points <NUM> and <NUM> is that both calls originate from a high cost destination (determined by examining, for instance, the country code associated with phone numbers of both end points), network element <NUM> may examine other common subset attributes associated with both phone numbers.

In one embodiment, network element <NUM> may determine that both phone numbers associated with end points <NUM> and <NUM> are from the same area code (e.g., where phone numbers include a country code + an area code + a line number). As the area code is a subset of the county code in an example phone number, network element <NUM> may determine that the shared subset attribute of the area code combined with the message indicating that such calls should not be flagged means that calls from end points <NUM> and <NUM> to end point <NUM> should not be blocked. In one embodiment, network element <NUM> may update the whitelist to permit calls from end points <NUM> and <NUM> to end point <NUM> to be completed.

In another embodiment, network element <NUM> may determine that calls from the same area code shared by end points <NUM> and <NUM> should be added to the whitelist as a result of receiving a message that both calls should not be flagged as fraudulent (e.g., calls from the same country code and area code). In some embodiments, a network element <NUM> must receive a certain threshold quantity of messages indicating that calls should not be flagged where such calls also have at least one common attribute or subset attribute before network element <NUM> updates the whitelist to permit such calls.

It should be appreciated that any attribute commonality may be used to determine what additional whitelist changes to make to avoid improperly flagging calls in the future. For example, in another embodiment, network element <NUM> may determine that both phone numbers associated with end points <NUM> and <NUM> are assigned to a company that is named the same or similar to the company assigned the phone number associated with end point <NUM>. In another embodiment, network element <NUM> may determine that both phone numbers associated with end points <NUM> and <NUM> are from the same block of numbers (e.g., the last <NUM> digits or some other suitable number of n digits of both phone numbers are from the block of phone numbers assigned to a single company).

Continuing the above example, where network element <NUM> has modified its whitelist to remove the flag on calls from end point <NUM> to end point <NUM>. In one such embodiment, end point <NUM> attempts to call end point <NUM> again. The call is routed in the same manner as described above. However, once network element <NUM> determines that an entry in the whitelist provides a reason to remove the flag on the call from end point <NUM>, network element <NUM> determines that the call from end point <NUM> should be allowed. As with the scenario where the call was flagged as potentially fraudulent, network element <NUM> may again transmit a rejection message to network element <NUM>. Network element <NUM> may transmit the rejection message to network element <NUM>. Network element <NUM> may generate and transmit a rejection message to network element <NUM> of carrier network <NUM>. The rejection message may be in the form of a standard Session Initiation Protocol (SIP) rejection message used between telephony switches. However, in this embodiment, the SIP rejection message may be in a predefined format that carrier network <NUM> and carrier network <NUM> agreed upon to indicate that the call is a normal call and should not be blocked. It should be appreciated that the SIP rejection message may be in a form that would not normally convey to the recipient telephony switch that the call is normal and should be allowed. It should also be appreciated that the rejection message may be in the form of rejection "cause codes" for ITU or SS7 compliant systems. In either case, in one embodiment, if network element <NUM> received a rejection message from network element <NUM> where the rejection message indicated that the call was rejected because no circuits were available or the service was unavailable, carrier network <NUM> may determine that such a rejection message from network element <NUM> actually means that carrier network <NUM> determined that the call should be allowed to proceed/terminated to the intended destination. Upon receiving such a rejection from carrier network <NUM>, carrier network <NUM> may terminate/route the call to the intended destination of end point <NUM>. Thus, end point <NUM> and end point <NUM> would be allowed to hold a voice call.

It should be appreciated that when calls are routed to the real time analysis system for analysis, in one embodiment, all such calls result in a rejection of the call by the carrier network associated with the real time analysis system regardless of whether the call should be completed or the call is flagged as potentially fraudulent. Whereas, in a typical call routing scenario, if a carrier network is in a call path, the carrier network would normally attempt to route/terminate a call. By utilizing the rejection messages (rejection "cause codes" for ITU or SS7 compliant system or SIP rejections for IP based networks) for both normal and suspected fraudulent calls, the real time analysis system is specially programmed or configured to interact with standard telephony equipment and can be inserted into any call path for analysis without requiring the real time analysis system to actually route the call to completion (and incur call termination/completion costs). This is advantageous for a telephony carrier network (e.g., carrier network <NUM>, <NUM>, <NUM>, etc.) that wishes to use the real time analysis of another party, but does not wish to use the other carrier network associated with the real time analysis system (e.g., carrier network <NUM>) to terminate/complete calls. This is also advantageous to the carrier network associated with the real time analysis system because the such a carrier network can provide a new service without requiring customers to incur extra expenses to interoperate with a previously unavailable real time analysis system.

Similar to the embodiments described above, in another example embodiment, carrier network <NUM> may utilize the real time analysis system of carrier network <NUM> to analyze whether to complete calls coming from carrier network <NUM> (such as from end point <NUM>) to end point <NUM> (or some other destination on carrier network <NUM>). The same blacklist and whitelist analysis could be performed for the call. Carrier network <NUM> may issue the same call rejection messages to carrier network <NUM> (which may indicate either that carrier network <NUM> should terminate the call or block the call) regardless of whether carrier network <NUM> will route or terminate the call to carrier network <NUM> for carrier network <NUM> (which carrier network <NUM> could if requested, as shown in <FIG>). It should be appreciated that carrier network <NUM>, <NUM>, and any other communications provider (not shown) may use the real time analysis system.

It should be appreciated that a carrier network providing the real time analysis system may also route/terminate calls that have been analyzed by the real time analysis system. In one such embodiment, the system to reject all calls transmitted to carrier network <NUM> for real time fraud is still employed. Once carrier network <NUM> provides the appropriate rejection notice as discussed above, then the carrier network receiving the rejection may decide to send the analyzed call back to carrier network <NUM> for termination. It should also be appreciated that the above analysis can be applied to other forms of electronic communication, such as, but not limited to the messaging scenarios discussed herein.

is a diagrammatic view of one embodiment of a network system adapted to analyze communication data in real time.

End point <NUM> is a device that enables a user to transmit and receive communications data, such as making and receiving telephone calls, sending and receiving messages, holding interactive multimedia conference calls, or some combination of the forgoing. End point <NUM> may include a telephone terminal, handset, cell phone, computer, smart phone, etc. Other suitable devices are described below. End point <NUM> is in communication with at least carrier network <NUM>. Carrier network <NUM> may be a PSTN or an IP network that enables end point <NUM> to make and receive calls, send and receive messages, or other forms of communication. Carrier network <NUM> includes at least one network element <NUM> that can transmit and receive communications from devices such as end point <NUM> and other network elements (from within the carrier network <NUM> or outside of carrier network <NUM>). In some embodiments, carrier network <NUM> may include any number of network elements necessary to operate a carrier network. Network element <NUM> may be a telephony switch or telephony gateway or other suitable network device or server (as is further described below). Network element <NUM> may be configured to transmit and receive telephone calls or messages (e.g., short message service (SMS), multimedia messaging service (MMS) messages) over either the PSTN or an IP network, or both. As shown in <FIG>, carrier network <NUM> may be in communication with many other networks such as network <NUM> and network <NUM>. It should be appreciated that carrier network <NUM> may communicate with any suitable number of other networks and devices.

In one embodiment, network <NUM> includes several network elements. Network <NUM> includes at least one network element <NUM> that can transmit and receive telephone calls. In some embodiments, network <NUM> may include any number of network elements <NUM> and other network elements necessary to operate a carrier network. Network element <NUM> may be a telephony switch or telephony gateway or other suitable network device or server (as is further described below). Network element <NUM> may be configured to transmit and receive telephone calls over either the PSTN (e.g., for TDM calls) or an IP network (e.g., for VoIP calls), or both. Network element <NUM> may include an SMS or MMS server or other messaging service that permits end points (e.g., <NUM>, <NUM>, etc.) to communicate with synchronous or asynchronous communications. Network element <NUM> may be a stand-alone messaging server. Where multiple network elements <NUM> are present in network <NUM>, network elements <NUM> may be any suitable combinations of telephony or messaging switches, gateways, servers, etc. As shown in <FIG>, network <NUM> may be in communication with another network such as carrier network <NUM>. It should be appreciated that network <NUM> may communicate with any suitable number of other networks and devices (not shown). While also not shown, network <NUM> may also be configured to communication with any number of end points (e.g., to receive or terminate calls or send and receive messages to and from these end points).

In one embodiment carrier network <NUM> further includes a routing system. The routing system may include specially programmed servers or network elements such as network element <NUM> and network element <NUM>. The specially programmed network elements <NUM> and <NUM> may perform operations such as network policy and routing management. Network elements <NUM> and <NUM> may perform decision analysis for network policy and route management such as fraud monitoring/detection, voice call routing, toll-free routing, least-cost routing, number portability, voice VPN, SIP trunking, centralized dial plans, emergency services, SMS routing, MMS routing, etc. In some embodiments (not shown), the routing system may divide the work of network policy and route management over more than two network elements and operate in parallel or using parallel processing. Alternatively, in some embodiments (not shown), the routing system may rely on one network element to perform all such operations, depending on the scale required to handle incoming analysis requests.

Carrier network <NUM> may be a PSTN or an IP network that enables end points to make and receive calls, send and receive messages, or other forms of communication. Carrier network <NUM> includes at least one network element <NUM> that can transmit and receive telephone calls from end points and other network elements (from within the carrier network <NUM> or outside of carrier network <NUM>). In some embodiments, carrier network <NUM> may include any number of network elements necessary to operate a carrier network. Network element <NUM> may be a telephony switch or telephony gateway or other suitable network device or server (as is further described below). Network element <NUM> may be configured to transmit and receive telephone calls or messages (e.g., short message service (SMS), multimedia messaging service (MMS) messages) over either the PSTN or an IP network (e.g., for VoIP calls), or both. As shown in <FIG>, carrier network <NUM> may be in communication with other networks such as network <NUM>. As shown in <FIG>, carrier network <NUM> may be in communication with end points such as end point <NUM>. End point <NUM> may be an end point such as described above in connection with end point <NUM>. It should be appreciated that carrier network <NUM> may communicate with any suitable number of other networks and devices.

While not shown, networks <NUM>, <NUM>, <NUM> may be in communication via any suitable type of network such as a PSTN network or an IP network such as the Internet. It should also be appreciated that the limited number of networks and end points shown in <FIG> are merely to simplify illustration of how the real time analysis system works and in no way limit the quantity of networks and end points that can work with the real time analysis system. The number of networks and end points that can take advantage of the real time analysis system is limited only to the computing resources available relative to the quantity of specifically configured servers and connections devoted to the real time analysis.

<FIG> below are diagrammatic views of communication signaling flows of various embodiments of the network system for real time analysis of fraudulent communications based on the system illustrated in <FIG>. It should be appreciated that the signaling flows of <FIG> may be applied to systems that differ from that illustrated in <FIG>. It should also be appreciated that that although the call and message routing illustrated throughout this disclosure show only a limited number of hops and networks used to complete calls and other communications data transmissions between end points, it should be appreciated that additional hops, networks, etc. may be used between communicating end points, whether for calls or message transmissions.

<FIG> is a diagrammatic view of a call signaling flow of one embodiment of a network system that rejects a call while still allowing the call to be completed to its intended destination. A legitimate caller associated with end point <NUM> attempts to make a call to a callee associated with end point <NUM>. To initiate the call, the end point <NUM> sends an IAM or an Invite message <NUM> to carrier network <NUM>. The type of message depends on the type of network and equipment used by the callee at end point <NUM> and carrier network <NUM>. The message <NUM> may be received at a network element <NUM> of carrier network <NUM>. Upon receiving the message <NUM>, carrier network <NUM> may be configured to send a message <NUM> (routing the call setup signaling) to network <NUM> (hereinafter referred to as the real time analysis system <NUM> or RTAS <NUM>) for fraud detection processing by the RTAS <NUM>. The RTAS <NUM> may send a message <NUM> to carrier network <NUM>. The message <NUM> may include a trying message that indicates an acknowledgment of receipt of message <NUM>.

Upon receipt of the message <NUM>, the RTAS <NUM> may also perform real time analysis on the message <NUM>, as discussed above, to determine whether or not fraud is detected in connection with the call from end point <NUM>. In this embodiment, RTAS <NUM> determined that the call from end point <NUM> was not fraudulent (using the methods described above). Even though the RTAS <NUM> determined that the call from end point <NUM> was not fraudulent or associated with fraud, RTAS <NUM> sends a call rejection message <NUM> back to carrier network <NUM>. The call rejection message <NUM> may be in the form of a <NUM> service unavailable message (for SIP based calls), a REL (<NUM>) message (for an SS7 based call), or some other suitable rejection message. Upon receiving the rejection message <NUM> from RTAS <NUM>, carrier network <NUM> determines that the rejection message is associated with a determination that the call from end point <NUM> is not fraudulent and should be terminated (e.g., completed) to the intended destination. Carrier network <NUM> determines the next appropriate hop or route to send the call from end point <NUM>. In the embodiment illustrated in <FIG>, carrier network <NUM> determines carrier network <NUM> is the destination network where end point <NUM> is located. Thus, carrier network <NUM> sends a call setup signaling message <NUM> to carrier network <NUM>. The message <NUM> may include an IAM or Invite message. When carrier network <NUM> receives the message <NUM>, carrier network <NUM> may send message <NUM> to end point <NUM>. The message <NUM> may include an IAM or Invite message.

The flow diagram of <FIG> does not show the remainder of the call setup signaling, media transmission between end point <NUM> and end point <NUM>, and the call teardown. However, these aspects follow the standards used for SS7 and VoIP systems and should be apparent to one of ordinary skill in the art.

It should also be appreciated that the rejection message <NUM> from the RTAS <NUM> may prevent the call from being routed back to the RTAS <NUM> once the carrier network <NUM> determines that the rejection message <NUM> means the call should be completed. However, it should also be appreciated that in some alternative embodiments, the RTAS <NUM> may be used to route the call from end point <NUM> to the next appropriate hop in a call route to the end point <NUM>. That is, after sending the rejection message <NUM>, in some embodiments, carrier network <NUM> may route the call setup signaling back to RTAS <NUM> for termination/completion.

<FIG> is a diagrammatic view of a call signaling flow of one embodiment of a network system that rejects a call and blocks the call from being completed to its intended destination. An illegitimate caller associated with end point <NUM> attempts to make a call to a callee associated with end point <NUM>. To initiate the call, the end point <NUM> sends an IAM or an Invite message <NUM> to carrier network <NUM>. The type of message depends on the type of network and equipment used by the callee at end point <NUM> and carrier network <NUM>. The message <NUM> may be received at a network element <NUM> of carrier network <NUM>.

Upon receiving the message <NUM>, carrier network <NUM> may be configured to send a message <NUM> (routing the call setup signaling) to RTAS <NUM> for fraud detection processing. The RTAS <NUM> may send a message <NUM> to carrier network <NUM>. The message <NUM> may include a trying message that indicates an acknowledgment of receipt of message <NUM>. Upon receipt of the message <NUM>, the RTAS <NUM> may also perform real time analysis on the message <NUM>, as discussed above, to determine whether or not fraud is detected in connection with the call from end point <NUM>. In this embodiment, RTAS <NUM> determined that the call from end point <NUM> is fraudulent or potentially fraudulent (using the methods described above). Because the RTAS <NUM> determined that the call from end point <NUM> is fraudulent or associated with fraud, RTAS <NUM> sends a call rejection message <NUM> back to carrier network <NUM>. The call rejection message <NUM> may be in the form of a <NUM> service unavailable message (for SIP based calls), a REL (<NUM>) message (for an SS7 based call), or some other suitable rejection message. Upon receiving the rejection message <NUM> from RTAS <NUM>, carrier network <NUM> determines that the rejection message is actually associated with a determination that the call from end point <NUM> is fraudulent and should be blocked. Carrier network <NUM> sends a message <NUM> back to end point <NUM> to end the call. The message <NUM> may be in the form of a <NUM> service unavailable message (for SIP based calls), a REL (<NUM>) message (for an SS7 based call), or some other suitable rejection message.

The flow diagram of <FIG> does not show all of the call setup and tear down signaling between end point <NUM> and end point <NUM>. However, these aspects follow the standards used for SS7 and VoIP systems and should be apparent to one of ordinary skill in the art.

<FIG> is a diagrammatic view of a message signaling flow of one embodiment of a network system that rejects a message while still allowing the message to be sent to its intended destination. A legitimate message sender associated with end point <NUM> attempts to send a message to a recipient associated with end point <NUM>. To initiate the message transmission, the end point <NUM> send a message <NUM> to carrier network <NUM>. The type of message depends on the type of message, network, and equipment used by the callee at end point <NUM> and carrier network <NUM>. The message <NUM> may be in the form of an SMS, MMS, or other suitable message. The message <NUM> may be received at a network element <NUM> of carrier network <NUM>. Upon receiving the message <NUM>, carrier network <NUM> may be configured to send a message <NUM> to RTAS <NUM> for fraud detection processing by the real time analysis system. The message <NUM> may include a Submit or Deliver SM message.

Upon receipt of the message <NUM>, the RTAS <NUM> may perform real time analysis on the message <NUM>, as discussed above (e.g., apply an analysis of attributes associated with the message similar analyzing the attributes associated with a call), to determine whether or not fraud is detected in connection with the message from end point <NUM>. In this embodiment, RTAS <NUM> determined that the message from end point <NUM> was not fraudulent (using the methods described above). Even though the RTAS <NUM> determined that the message from end point <NUM> was not fraudulent or associated with fraud, RTAS <NUM> send a rejection message <NUM> back to carrier network <NUM>. The rejection message <NUM> may be in the form of a Resp Status: P_APPN (0x65) or some other suitable rejection message. Upon receiving the rejection message <NUM> from RTAS <NUM>, carrier network <NUM> determines that the rejection message is actually associated with a determination that the message from end point <NUM> is not fraudulent and should be sent to the intended destination. Carrier network <NUM> determines the next appropriate hop or route to send the message from end point <NUM>. In the embodiment illustrated in <FIG>, carrier network <NUM> determines carrier network <NUM> is the destination network where end point <NUM> is located. Thus, carrier network <NUM> sends a message <NUM> to carrier network <NUM>. The message <NUM> may include a Submit or Deliver SM message. When carrier network <NUM> receives the message <NUM>, carrier network <NUM> may send message <NUM> to end point <NUM>. The message <NUM> may include a Submit or Deliver SM message.

The flow diagram of <FIG> does not show all of the message transmissions between end point <NUM> and end point <NUM>. However, these aspects follow the standards used for message transmission based on the type of messaging system used and should be apparent to one of ordinary skill in the art.

It should also be appreciated that the rejection message <NUM> from the RTAS <NUM> may prevent the message from being routed back to the RTAS <NUM> once the carrier network <NUM> determines that the rejection message <NUM> means the message should be completed. However, it should also be appreciated that in some alternative embodiments, the RTAS <NUM> may be used to route the message from end point <NUM> to the next appropriate hop in a message route to the end point <NUM>. That is, after sending the rejection message <NUM>, in some embodiments, carrier network <NUM> may route the message transmission back to RTAS <NUM> for further routing/completion.

<FIG> is a diagrammatic view of a message signaling flow of one embodiment of a network system that rejects a message and blocks the message from being sent to its intended destination. An illegitimate message sender associated with end point <NUM> attempts to send a message to a recipient associated with end point <NUM>. To initiate the message transmission, the end point <NUM> sends a message <NUM> to carrier network <NUM>. The type of message depends on the type of message, network, and equipment used by the callee at end point <NUM> and carrier network <NUM>. The message <NUM> may be in the form of an SMS, MMS, or other suitable message. The message <NUM> may be received at a network element <NUM> of carrier network <NUM>. Upon receiving the message <NUM>, carrier network <NUM> may be configured to send a message <NUM> to RTAS <NUM> for fraud detection processing by the real time analysis system. The message <NUM> may include a Submit or Deliver SM message.

Upon receipt of the message <NUM>, the RTAS <NUM> may perform real time analysis on the message <NUM>, as discussed above, to determine whether or not fraud is detected in connection with the message from end point <NUM>. In this embodiment, RTAS <NUM> determined that the message <NUM> from end point <NUM> is fraudulent (using the methods described above). Because the RTAS <NUM> determined that the message from end point <NUM> is fraudulent or associated with fraud, RTAS <NUM> sends a rejection message <NUM> back to carrier network <NUM>. The rejection message <NUM> may be in the form of a Resp Status: P_APPN (0x66) or some other suitable rejection message. Upon receiving the rejection message <NUM> from RTAS <NUM>, carrier network <NUM> determines that the rejection message is actually associated with a determination that the message from end point <NUM> is fraudulent and should be blocked from being sent to the intended destination. Thus, carrier network <NUM> sends a rejection message <NUM> to end point <NUM>. The rejection message <NUM> may be in the form of a Resp Status: P_APPN (0x66) or some other suitable rejection message.

The flow diagram of <FIG> does not show all of the message transmissions between end point <NUM> and the other network elements. However, these aspects follow the standards used for message transmission based on the type of messaging system used and should be apparent to one of ordinary skill in the art.

Using the architecture described herein to perform real time analysis on communication data transmissions results in technological improvements over existing systems for a cheaper, more efficient, and more secure system.

The above described real time analysis system (RTAS) architecture is cheaper than preexisting systems for several reasons. One reason is that the RTAS architecture saves network operators from high costs associated with paying for transmitting fraudulent communications data traffic. As noted above, network operators generally must pay other network operators to send communications traffic to networks and end points run by the other network operators. If fraudulent communications data traffic is sent to another network to reach the intended destination of the communications traffic, the sending network may be required to pay for the communications data traffic whether it was legitimate or not. Under preexisting systems, communications traffic was reviewed after the communications were already completed. Data identifying that particular communications traffic was fraudulent was not detected until weeks or months after the fraudulent communications traffic was sent to another network and the costs for the fraudulent traffic were already incurred. This is because it was not previously possible to analyze communications data traffic in real time before the communications traffic was provided to the intended destination. Preexisting systems to detect fraud in communications data traffic analyzed records created after communications data reached their intended destination. For example, when a call is made and completed, a call data record (CDR) is generated. Network operators would use the millions of CDR records to prepare invoices and audit billing/invoicing records. Analysis of the CDR records were also used to detect and determine whether call traffic was fraudulent. On the other hand, using the RTAS architecture enables the communications data traffic to be analyzed for fraud in real time before the communications data traffic is sent to its intended destination. The RTAS architecture prevents network operators from incurring costs associated with fraudulent communications data traffic by blocking the traffic before the communications data traffic is sent to the intended destination. Blocking fraudulent communications traffic in real time also creates a more secure communications system.

Another reason that the RTAS architecture is cheaper and more efficient than preexisting systems is that network operators create less records of communications traffic. When communications data traffic is sent (and completed) to the intended destination, records of the communication are generated and stored. These records may be used, as noted above, for billing/invoicing and auditing purposes. When fraudulent traffic is blocked, less records of the communication data traffic are generated because there is less communications data traffic. Communications data results in extremely large quantities of records. By reducing the amount of records generated, less system server resources are used to create the records and less server and memory resources are used to store the records. Moreover, when the quantity of records are reduced, this also reduces the amount of analysis that must be performed on the generated records. A reduction in the amount of analysis required results in less processor and memory intensive operations. A reduction in the amount of analysis required also results fewer disputes with other network operators over fees owed for communications data traffic passed to the other network operators to handle.

Another reason that the RTAS architecture is cheaper and more efficient than preexisting systems is that less network resources are used when fraudulent communications data traffic is blocked in real time. For example, if a fraudulent communications data is sent to an intended destination, many different system resources are used on one or more networks to deliver the communication data. Many communication devices will be used to transmit the communications data, which requires unnecessary use of processors, memory, and power. Physical ports of the telecommunication devices and network bandwidth are also used to unnecessarily deliver the communications data. All of the above are generally limited resources. When these limited resources are heavily used, network operators are forced to add additional capacity in terms of additional communications devices and bandwidth. If the network operators do not add additional resources in a timely manner, the existing communication devices may drop portions of the communications data or cause the communication devices to even fail. The RTAS architecture prevents unnecessary use of limited resources and prevents the need to purchase additional resources to meet a false demand generated by fraudulent communications data traffic.

Yet another reason that the RTAS architecture is cheaper and more efficient than preexisting systems is that network operators using the RTAS system (or communications networks such as telephony carriers) do not need to purchase new hardware to use the RTAS for fraud detection. The RTAS architecture discussed herein works with existing communications and telephony systems to leverage/recycle certain communications or telecom principals and processes for new purposes. The RTAS architecture allows the fraud detection to be placed in the path of a communications transmission and analyze the communications transmission for fraud before the communications transmission incurs substantial costs. Specifically, the RTAS architecture uses and repurposes rejection messages to communicate a determination of fraud or no fraud, whether or not a communications transmission is determined to be fraudulent.

Accordingly, using the RTAS architecture described herein to perform real time analysis on communication data transmissions results in technological improvements over existing systems for a cheaper, more efficient, and more secure system.

<FIG> is a diagram of example components of computing devices <NUM> which may be used to implement various computer devices of the network system adapted to analyze communications data in real time described herein. For example, computer devices <NUM> may be used to describe devices such as network elements <NUM>, <NUM>, <NUM> in carrier network <NUM> and network elements <NUM>, <NUM>, and <NUM> of RTAS <NUM> as well as other devices described herein.

Various computing devices may be used to implement the systems and methods described in this document, as either a client or as a server or plurality of servers. Computing devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. Other computing devices may include various forms of mobile devices, such as personal digital assistants, cellular telephones, smartphones, and other similar computing devices. The components shown here, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit embodiments of the inventions described and/or claimed in this document.

In one embodiment, a computing device used herein may include a specially configured processor <NUM>, memory <NUM>, a storage device <NUM>, a high and low speed interfaces and buses <NUM> connecting to the memory. Each of the components of the computing devices are interconnected using various busses, and may be mounted on a common board or in other manners as appropriate. The processor can process instructions for execution within the computing device, including instructions stored in the memory or on the storage device to display graphical information for a graphic user interface on an external input/output device <NUM> such as a display. In other embodiments, multiple processors and/or multiple buses may be used, as appropriate, along with multiple memories and types of memory. Also, multiple computing devices may be interconnected, with each device providing portions of the necessary operations (e.g., as a server bank, a group of blade servers, or a multi-processor system).

Additionally, the processor may be implemented using any of several architectures. For example, the processor may be an x86 processor, RISC (Reduced Instruction Set Computers) processor. The processor may coordinate with the other components of the device, such as control of user interfaces, applications run by the device, and wireless communication. Multiple processors or processors with multiple cores may also be used.

The processor may communicate with a user through a control interface and display interface coupled to a display. The display may be, for example, an LED (Liquid Crystal Display) display, or other appropriate display technology. The display interface may comprise suitable circuitry for driving the display to present graphical and other information to a user. The control interface may receive commands from a user and convert them for submission to the processor. In addition, an external interface may be provided in communication with processor to enable near field communication with other devices. An external interface may provide, for example, for wireless and/or wired communication. Multiple interfaces may also be used.

The memory <NUM> may store information within the computing device. In one embodiment, the memory is a volatile memory unit or units. In another embodiment, the memory is a non-volatile memory unit or units. The memory may also be another form of computer-readable medium, such as a magnetic or optical disk.

The storage device <NUM> is capable of providing mass storage for the computing device. In one embodiment, the storage device may contain a computer-readable medium, such as a hard disk device, an optical disk device, or a tape device, a flash memory or other solid state memory device, or an array of devices, including devices in a storage area network or other configurations. The storage device may be anyone of the foregoing and be located remotely, such as in a cloud infrastructure. The information carrier is a computer or machine readable medium, such as the memory <NUM>, the storage device <NUM>, or memory on processor <NUM>.

The computing device may be implemented in several different forms. For example, it may be implemented as a standard server, or multiple times in a group of such servers. It may also be implemented as part of a rack server system. In addition, it may be implemented in a desktop computer or a laptop computer. Alternatively, components from the computing device may be combined with other components in a mobile device. Each of such devices may contain one or more computing devices. An entire system may be made up of multiple computing devices that communicate with each other and also may execute functions in a parallel processing environment.

The computing devices may communicate wirelessly through communication interfaces <NUM>, which may include digital signal processing circuitry. Communication interfaces may provide for communications under various modes or protocols, such as GSM, SMS, MMS, CDMA, among others. Such communication may occur, for example, through a radio-frequency transceiver. In addition, short-range communication may occur, such as using a Bluetooth, Wi-Fi, or other such transceiver. A GPS (Global Positioning System) receiver module may provide additional navigation and location related wireless data to the computing devices.

The computing devices may communicate audibly using an audio codec, which may receive spoken information from a user and convert it to usable digital information. The audio codec may likewise generate audible sound for a user, such as through a speaker. Such sound may include sound from voice telephone calls and may include recorded sound.

Various embodiments of the systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, and combinations thereof. These various embodiments can include embodiments that are executable and interpretable on a programmable system including at least one programmable processor, which are special purpose computers for performing the functions of the RTAS <NUM>, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having any suitable display device for displaying information to the user and an input device <NUM> (e.g., a keyboard, a touchpad, touchscreen, a mouse, or a trackball) by which the user can provide input to the computer. Feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback). Input from the user can be received in any form, including acoustic, speech, or tactile input.

The relationship of client and server arises through computer programs running on the respective computers and having a client-server relationship to each other.

The illustrative block diagrams and flowcharts depict process steps or blocks that may represent modules, segments, or portions of code that include one or more executable instructions for implementing specific logical functions or steps in the process. Although the particular examples illustrate specific process steps or procedures, many alternative implementations are possible. Some process steps may be executed in different order from the specific description herein based on, for example, considerations of function, purpose, conformance to standard, legacy structure, user interface design, and the like.

Claim 1:
A telecommunications system comprising:
a processor; and
a memory device that stores:
a plurality of blacklist attributes;
a plurality of whitelist attributes, each of the plurality of whitelist attributes is a subset of one of the plurality of blacklist attributes;
a plurality of instructions, which when executed by the processor, causes the processor to:
receive a first request from a telephony switch to terminate a first call, the first call includes a plurality of call attributes;
if one of the plurality of call attributes associated with the first call matches one of the plurality of blacklist attributes and the one of the plurality of call attributes does not match one of the plurality of whitelist attributes, generate a first rejection message;
receive a first message indicating that generation of the first rejection message was incorrect;
receive a second request from a telephony switch to terminate a second call, the second call includes a second plurality of call attributes;
if one of the second plurality of call attributes associated with the second call matches one of the plurality of blacklist attributes and the one of the second plurality of call attributes does not match one of the plurality of whitelist attributes, generate a second rejection message;
receive a message indicating that generation of the second rejection message was incorrect;
if the matching blacklist attribute associated with the first call is the same as the matching blacklist attribute associated with the second call, analyze the first call and the second call to determine if there is a common attribute that is a subset of the blacklist attributes associated with the first call and the second call;
add the subset of the matching blacklist attribute associated with the first call and second call to the plurality of whitelist attributes.