WO2001049013A2

WO2001049013A2 - Method and apparatus for selective incoming call blocking based on calling line identification

Info

Publication number: WO2001049013A2
Application number: PCT/US2000/035099
Authority: WO
Inventors: Gilman R. Stevens
Original assignee: Alcatel Usa Sourcing, L.P.
Priority date: 1999-12-24
Filing date: 2000-12-22
Publication date: 2001-07-05
Also published as: AU2290101A; WO2001049013A3

Abstract

A method and apparatus for routing a call from the calling party to a called party includes determining within an SCP whether the calling party is authorized to place calls to the called party as a part of setting up the call. In the described embodiment of the invention, the disclosed method is to be implemented as a subscriber feature. In one embodiment of the invention, the SCP merely examines the calling party number to determine whether it is authorized to make the call. In a preferred embodiment of the invention, the calling party number is first mapped to a calling party name and then the calling party name is compared to a list of calling party names that are authorized to make the call. This embodiment is advantageous in that it allows for calling parties to aurally state their name into a telephone so that the SCP, with the help of the IVR, may determine what the calling party name is. This is helpful for those circumstances where an authorized calling party seeks to place a call to the called party from a phone other than his or her own. The invention further includes, in some embodiments, giving the calling party an option to pay a toll to have the call routed for those circumstances in which the calling party is not authorized to place calls to the called party. In one embodiment of the invention, the calling party is asked whether a toll charge can be charged to the calling party. In another embodiment, the calling party is asked to provide an authorization PIN.

Description

METHOD AND APPARATUS FOR A CALLING NAME BASED FILTER

TECHNICAL FIELD

The present invention relates generally to communication networks and more particularly to subscriber features for telephone networks including intelligent networks (IN), signaling system no. 7 (SS7) networks and wireless networks.

SUMMARY OF THE INVENTION

Whenever a call is being placed to a called party, a service control point (SCP) examines a call setup message to determine if the calling party is authorized to place a call to the called party if the called party is a Calling Party Name Based Filter feature subscriber. More specifically, the SCP examines a called party subscriber profile to determine that the called party is a subscriber of a calling party based message filter. Only those calling parties listed within the subscriber's profile are allowed to place calls to the subscriber in one embodiment of the invention. In an alternate embodiment of the invention, the calling party is allowed an option of paying a toll charge to complete the call. The toll is credited to the called party's account. Yet in another embodiment of the invention, the calling party is allowed to enter an access PIN (personal Id Number) to allow the call to be setup if the calling party phone is not listed on the list of authorized calling parties.

In operation, the SCP compares the identity of the calling party to the list within the subscriber profile to determine whether the call setup may be completed and the voice trunk may be routed to the called party telephone. In the preferred embodiment of the invention, a subscriber profile contains a list of authorized calling parties by calling party name. Accordingly, either the SCP or the SSP convert the calling party number to a calling party name and then compare the calling party name to the list of names that are authorized to place calls to the called party.

In one embodiment of the invention, the invention includes prompting, by way of an integrated voice response (IVR) system, the calling party to state his or her name if the calling party phone number does not translate into a calling party name that is on the authorized list. After the calling party states his name into the phone, the stated name is converted to text and then compared to the list of authorized calling parties. This allows authorized calling parties to place phone calls from phones other than their own to the called party subscriber. In yet another embodiment of the invention, once the STP or SCP has determined that the calling party is not authorized to route a call to the called party, an IVR system is used to ask the calling party whether he or she wishes to pay a toll fee to complete the call. Either the toll is charged to the phone number from which the call is being made or to a given number or a number associated with a calling party name that was given. In either case in which a number or calling party name is given to which the toll is to be charged, a calling party is asked to provide an Id, such as a pin number, to verify that the toll may be charged to the given calling party number or name.

For example, in one described embodiment, a calling party is asked to list his or her home phone number and a PIN number. If the PIN number corresponds to a PIN number stored for the calling party phone number, then a specified toll amount is charged to the calling party phone. In an alternate embodiment of the invention, the calling party is prompted to enter either a credit card number or a debit card number so that the calling party's financial phone account may be charged for the call. Once the calling party correctly identifies a calling party phone number and PIN number or a valid debit card number or credit card number, the call setup is completed and the call is routed. Accordingly, with each of the described embodiments, telemarketing organizations will be effectively blocked from pandering and disturbing consumers unless they are willing to pay for the disturbance that they cause.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGURE 1 is a functional block diagram of a modern IN according to one embodiment of the present invention;

FIGURE 2 is a flowchart that illustrates a method for completing a call or for blocking a call according to one embodiment of the invention;

FIGURE 3 is a flow chart of a preferred embodiment of a method of the invention for determining whether a calling party is authorized to place a call to a called party; FIGURE 4 is a flow chart of a method for setting up a call according to an alternate preferred embodiment of the invention; FIGURE 5 is a flow chart of an alternate embodiment of the invention for completing a call from a calling party to a called party; and

FIGURE 6 is a flowchart that illustrates a method for completing a call or for blocking a call according to one embodiment of the invention.

DETAILED DESCRIPTION OF THE DRAWINGS

FIGURE 1 is a functional block diagram of a modern IN according to one embodiment of the present invention. Referring now to FIGURE 1, IN 100 is coupled to communicate with a calling party phone 104 and a called party telephone 108. More specifically, a signal switching point (SSP) 112 of IN 100 is coupled to communicate with calling party telephone 104 while SSP 116 is coupled to communicate with called party telephone 108. SSP's are telephone switches (end offices or tandems) equipped with signaling system number 7 (SS7) capable software and terminating signaling links. SS7 switches generally originate, terminate or switch calls. SSP 112 also is coupled to signal transfer point (STP) 120. STP's are the packet switches of the SS7 network. They receive and route incoming signaling messages towards the proper destination and also perform specified routing. STP 120 also is coupled to STP 124. STP 124, in turn, also is coupled to SSP 116 that serves the called party telephone 108. STP 120 also is coupled to communicate with signal control point (SCP) 128. SCP's are database systems that provide information that is necessary for advanced call-processing capabilities and for providing specific user information such as user profiles as they relate to subscriber features.

While SSP's commonly communicate with an SCP by way of STPs, the presence of the STP is largely transparent in many embodiments with respect to subscriber feature operation. Accordingly, with respect to the descriptions herein, the presence of the STP in the network will be assumed to be there even if not explicitly mentioned.

Continuing to examine FIGURE 1, SSP 112 is connected to communicate with interactive voice response (IVR) system 132. An IVR system is a computer having voice recognition software capable of taking a voice message and converting it to text for analysis and also capable of playing messages in either a recorded human voice or in a synthesized computer generated voice. IVR systems are specifically designed to instruct and receive instructions through a telephone without requiring digit activation.

SCP 128 includes computer instructions that define the logic for blocking calls for those callers that are not listed in a list of authorized callers for the called party. SCP 128 also includes the subscriber profiles for each subscriber of the inventive call-blocking feature. More specifically, SCP 128 includes a processor 128A and a store 128B. Processor 128A executes computer program instructions stored in store 128B to perform and provide subscriber features that are created through the logic defined in the computer instructions of store 128B. Moreover, store 128B includes a memory for storing operational parameters including, by way of example, subscriber profiles defining the subscriber features to which an individual or organization has subscribed. The specific logic defined by the computer instructions within store 128B that are to be performed by processor 128 A are more specifically discussed in relation to the methods illustrated in FIGURES 2-6 that relate to the operation of the calling party filter subscriber feature. As is understood by those skilled in the art, an internal communication line or bus is used to couple the store 128B to processor 128 A to enable processor 128 A to determine and execute the computer instructions stored in store 128B.

SSP 112, as may be seen, includes a processor 112A and a store 112B. Processor 112A executes computer program instructions stored in store 112B to setup calls according to whether an SCP, for example, SCP 128, indicates that the call can be set up. In addition, according to the type of network and its protocols, the SSP 112 also performs some varying degrees of decision making and control as a part of an implemented subscriber feature. By way of example, in one embodiment, it is SSP 112 that determines that a call an IVR message is to be played to the calling party for the purpose of informing it that the call cannot be completed or for the purpose of requesting information. In another embodiment, the instructions also define the logic and protocol for storing and for uploading toll charge information whenever a toll is to be charged to a calling party. The functional processes are defined in the computer instructions stored within store 112B.

The specific logic defined by the computer instructions within store 112B that are to be performed by processor 112A are more specifically discussed in relation to the methods illustrated in FIGURES 2-6 that relate to the operation of the network to provide the calling party filter subscriber feature. As is understood by those skilled in the art, an internal communication line or bus is used to couple the store 112B to processor 112 A to enable processor 112A to determine and execute the computer instructions stored in store 112B. IVR 132 includes a processor 132A and a store 132B. Processor 132A executes computer program instructions stored in store 132B to perform and provide messages to a called party and to interpret called party responses. The logic for playing the appropriate message or for interpreting a response is defined in the computer instructions of store 132B. Moreover, store 132B includes a memory for storing operating instructions, including, by way of example, instructions for determining whether a pin entered by the calling party matches the calling party pin stored within the SCP.

The specific logic defined by the computer instructions within store 132B that are to be performed by processor 132A are more specifically discussed in relation to the methods illustrated in FIGURES 2-6 that relate to the operation of the calling party filter subscriber feature. As is understood by those skilled in the art, an internal communication line or bus is used to couple the store 132B to processor 132A to enable processor 132 A to determine and execute the computer instructions stored in store 132B.

In operation, IN 100 is operable to set up calls between calling parties, by way of example calling party 104, to called parties by way of example called party 108, that are subscribers of the inventive call blocking subscriber feature. More specifically, as a part of setting up a call, SCP 128 analyzes a list of subscribers of the disclosed call-blocking feature to determine that called party 108 is a subscriber. Once SCP 128 determines that called party 108 is a subscriber, it examines the calling party phone number of calling party 104 to determine whether the calling party is authorized to place a call to the called party.

In a preferred embodiment, the calling party number is examined to determine a calling party name. For example, SCP 128 includes a database that maps calling party numbers to calling party names. Once SCP 128 has determined the calling party name for calling party 104, it then compares that calling party name to the subscriber profile of called party 108 to determine if the calling party of calling party telephone 104 is authorized to place calls to called party 108. If calling party 104 is authorized to place a call, SCP 128 generates a signal to SSP 112 to inform it that the calling party is allowed to place the call to the called party. SSP 112, in turn, transmits data packets to SSP 116 to set up the call. Thereafter, the call is connected. On the other hand, if the calling party is not authorized to place calls to called party

108, then SCP 128 sends the corresponding signaling to SSP 112 to inform it of the same. SSP 112, in the described embodiment, prompts IVR 132 to generate a voice message to inform the calling party that the call cannot be routed. A more detailed explanation of the operation of IN 100 will follow in the discussion of the subsequent FIGURES herein. It is understood that there are a significant number of different types of telephone networks in which the distribution of logic varies from network to network. Thus, functions that are reserved for an SCP in one network may be reserved for the SSP or the STP in another network. Additionally, some functions, such as storing billing records may even be performed in an external intelligent peripheral such as intelligent peripheral 136 of FIGURE 1.

FIGURE 2 is a flowchart that illustrates a method for completing a call or for blocking a call according to one embodiment of the invention. In the described embodiment, the method of FIGURE 2 is a method performed within IN 100. First, after an IN 100 receives an indication that a calling party telephone is off hook, it receives and temporarily stores the digits that were dialed by the calling party and it determines the calling party number as well as the called party number (step 202). Thereafter, an SSP, by way of example, SSP 112, analyzes the dialed digits and forwards a packet (query) to an SCP to determine if the called party is a call block feature subscriber (step 204). For example, in FIGURE 1, SSP 112 would forward a packet to SCP 128. Thereafter, the SCP that received the packet, e.g., SCP 128, determines called party is a subscriber of the call blocking subscriber feature of the present invention and, if so, whether the calling party is on an authorized list to call the called party (step 206).

If the calling party is not authorized to place a call to the called party, SSP 112, in the described embodiment, prompts IVR 132 to play an IVR message to the calling party. The message is played to inform the calling party through SSP 112 that he or she is not authorized to make a call to the called party (step 208). Thereafter, SSP 112 disconnects the call (step 210). If the calling party is authorized to place the call, one the other hand, call setup is completed and the call is connected (step 212).

With respect to step 206, there are several embodiments of the invention that are possible. In one embodiment, the SCP merely examines the calling party number and compares that to a calling party number within a subscriber profile for the called party. In a preferred embodiment of the invention, the SCP converts the calling party number to a calling party name by looking up the calling party name in a table that maps calling party numbers to calling party names. The SCP then compares the calling party name associated with the calling party number to a list of calling party names that are authorized to call the called party. This embodiment is preferred because it creates other capabilities as will be described below.

With respect to steps 208 and 210, an in an alternate embodiment of the invention, the IVR prompts the calling party to leave a message after informing him that the call cannot be completed. If the calling party chooses to leave a message, IVR 132 stores the message in a voice mailbox for the called party.

For embodiments in which the called party number is merely the number of a voice mailbox, the invention is adapted to only allow authorized calling parties to leave messages in the voice mailbox. Similarly, the invention herein may be used to restrict the delivery of text pages to called parties or to restrict the delivery of e-mail messages in those embodiments in which the IVR converts the message to text and then, perhaps by working with an intelligent peripheral, generates an e-mail message to the called party according to a subscriber profile.

FIGURE 3 is a flow chart of a preferred embodiment of a method of the invention for determining whether a calling party is authorized to place a call to a called party. First, an SCP that serves a geographic area in which the calling party is located, by way of example, SCP 128 of FIGURE 1, analyzes the contents of a query generated by an SSP that identify the called party number. Thereafter, the SCP examines the numbers to determine if the called party is a subscriber of the inventive call block subscriber feature (step 302). After determining that the called party is a subscriber of the call block subscriber feature, the SCP determines the calling party name for the calling party number by looking at a table or database that maps calling party names with calling party numbers (step 304). Typically, a store within the SCP, by way of example, store 128B of FIGURE 1, is used to maintain a database that maps calling party names and numbers. Thereafter, SCP 128 examines a subscriber profile for the called party to determine if the calling party name is authorized to place a call to the called party (step 306).

If the calling party is authorized to place the call, then the SCP 128 generates a response to the SSP that serves the calling party, e.g., SSP 112, to indicate that the call setup may be completed and that the call may be routed (step 308). If the calling party name is not authorized to place the call, then the SCP, e.g., SCP 128 informs the SSP, e.g., SSP 112 of the same. SSP 112, in turn, prompts IVR 132 to play a specified toll request message to the calling party 104 (step 310). After receiving the request, the IVR plays the message by way of the SSP to ask the calling party if he is willing to approve a toll charge to the calling party number for completing the call (step 312). After the calling party states his approval, the call setup is completed and the call is connected to the called party phone (step 308). If the calling party does not authorized the charge, however, the call is dropped/blocked (step 314).

FIGURE 4 is a flow chart of a method for setting up a call according to an alternate preferred embodiment of the invention. If an SCP, by way of example, SCP 128, determines that the calling party is not on the list of authorized callers for the subscriber of the call block subscriber feature disclosed herein, it transmits a signal to an IVR, e.g., IVR 132, to play a specified message (step 400). IVR 132 then plays a message to the calling party through the SSP that serves the calling party phone, e.g., SSP 112, to request an authorization number to which the call may be charged (step 404). For example, the IVR may request that the calling party provide a telephone number to which a toll may be charged for completing the call. If the calling party provides an authorization number by voice, the IVR converts the voice response to text so that it may be analyzed and so that the corresponding account information may be ascertained (step 408).

Thereafter, IVR 132 prompts the calling party to state his or her access code or PIN number (step 412). As before, that PIN number is translated to text if it is given aurally. After the IVR has received both the phone number to which the toll is to be charged and a PIN or access number to verify that the calling party is authorized to charge calls to the given number, IVR 132 compares the received phone number and PIN to its internal records to determine validity (step 420). Alternatively, the SCP or the SSP may perform this comparison.

If the PIN number is correct, the call is completed and the charging information is stored for uploading at a later time. In the preferred embodiment, the charge information is stored by the SSP, e.g., SSP 112 of FIGURE 1. Alternatively, the SCP sends a signal to an intelligent peripheral, e.g., intelligent peripheral 136 of FIGURE 1, so that the corresponding calling party may be charged the proper toll. In yet another alternate embodiment of the invention, the SCP stores the charge information itself.

If the PIN or access code is not correct, meaning that it does not correspond to a stored PIN entered by the registered owner of the calling party number, the call is blocked and dropped (step 428). While the described embodiment is that of a system and method for charging the toll charge to a calling party number, the toll charge may also be charged to a bank or credit account. For the call to be so charged, the IVR includes computer instructions that prompt a calling party to enter all of the required information including name as it appears on the account, data of expiration of an issued card for the account, and account or card number. As before, the IVR converts the calling party responses where they can be examined for validity and stored for charging purposes. For this embodiment, the information is preferably transmitted to an external intelligent node.

In each of the embodiments for which a toll is charged, different system implementations may be had. In the preferred embodiment, the charged tolls are credit to the account of the called party subscriber less, perhaps, a handling charge or Telephone Company fee.

FIGURE 5 is a flow chart of an alternate embodiment of the invention for completing a call from a calling party to a called party. First, an SCP that serves a geographic area in which the calling party is located, by way of example, SCP 128 of FIGURE 1, analyzes the contents of a query generated by an SSP that identify the called party number (step 500). Thereafter, the SCP examines the numbers to determine if the called party is a subscriber of the inventive call block subscriber feature (step 502).

After determining that the called party is a subscriber of the call block subscriber feature, the SCP determines the calling party name for the calling party number by looking at a table or database that maps calling party names with calling party numbers (step 504). Typically, a store within the SCP, by way of example, store 128B of FIGURE 1, is used to maintain a database that maps calling party names and numbers. Thereafter, SCP 128 examines a subscriber profile for the called party to determine if the calling party name is authorized to place a call to the called party (step 506). If the calling party is authorized to place the call, then the SCP 128 generates a response to the SSP that serves the calling party, e.g., SSP 112, to indicate that the call setup may be completed and that the call may be routed (step 508). If the calling party name is not authorized to place the call, then the SCP 128 informs the SSP, e.g., SSP 112 of the same. SSP 112, in turn, sends a request to IVR 132 to play a specified message to the calling party 104 to ask the calling party to state his or her name.

After receiving the calling party name aurally and converting it to text, the invention included determining whether the stated calling party name is on the subscriber's list of authorized calling parties (step 512). If the stated calling party name is on the list of calling party names, then the call is completed (step 508). Otherwise, the call is dropped (step 514).

FIGURE 6 is a flowchart that illustrates a method for completing a call or for blocking a call according to one embodiment of the invention. In the described embodiment, the method of FIGURE 6 is a method performed within IN 100. First, after an IN 100 receives an indication that a calling party telephone is off hook, it receives and temporarily stores the digits that were dialed by the calling party and it determines the calling party number as well as the called party number (step 602). Thereafter, an SSP, by way of example, SSP 112 of FIGURE 1, analyzes the dialed digits and forwards a packet (query) to an SCP to determine if the called party is a call block feature subscriber (step 604). For example, in FIGURE 1, SSP 112 would forward a packet to SCP 128. Thereafter, the SCP that received the packet, e.g., SCP 128, determines whether the called party is a subscriber of the call blocking subscriber feature of the present invention and, if so, whether the calling party is on an authorized list to call the called party (step 606).

If the calling party is not authorized to place a call to the called party, SSP 112, in the described embodiment, prompts IVR 132 to play an IVR message to the calling party to request an access pin code from the calling party (step 608). The message is played to inform the calling party through SSP 112 that he or she is not authorized to make a call to the called party and that the calling party must enter a correct access pin (or authorization code) to gain access and to have the call set up completed.

If the calling party provides a pin number by voice, the IVR converts the voice response to text so that it may be analyzed and so that the corresponding account information may be ascertained (step 610).

After the IVR has received the PIN number to verify that the calling party is authorized to place calls to the given number, IVR 132 compares the received PIN to its internal records to determine validity (step 612). Alternatively, the SCP or the SSP may perform this comparison.

If the PIN number is correct, the call setup is completed (step 616). If the pin is not correct, meaning that it does not correspond to a stored PIN entered by the registered owner of the calling party number, the call is blocked and dropped (step 614).

In an alternate embodiment of the invention, a code word or phrase is used in place of the pin number. Thus, the calling party may enter the code word on the keypad (effectively the code word is still a pin but has a sequence of digits that can be remembered by a code word). Additionally, the calling party may merely state the code word or phrase to gain access. IVR 132, for example, would then convert the spoken code to text and compare it to internal records within the call block feature subscriber profile. The inventive method and apparatus disclosed herein are particularly advantageous in that they provide a capability for truly filtering calls from unwanted parties. In the case of a telemarketer, the telemarketer, for one embodiment, would have to pay a toll to complete the call. As many telemarketer calls that are made on a daily basis, some people may possibly become very wealthy should the telemarketers decide to pay the toll. If they should decide to not pay the toll, then the secondary advantage of this invention is still great. Mainly, the evening dinner may be enjoyed in peace. While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and detailed description. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the invention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present invention as defined by the claims. As may be seen, the described embodiments may be modified in many different ways without departing from the scope or teachings of the invention. For example, any combination of the described methods may be combined to create an inventive system that reduces the amount of unwanted calls. To illustrate, the method of FIGURE 5 may be combined with the methods of FIGURES 3 and 4 wherein a calling party is allowed to specifically defined the account to which a toll is charged.

Claims

WHAT IS CLAIMED IS:

1. A service control point (SCP), comprising: a processor; and a store coupled to the processor by an internal bus wherein the store includes computer instructions that define operational logic to determine if a calling party is an authorized caller for the called party according to a called party subscriber profile.

2. The SCP of claim 1, wherein the store includes computer instructions that define operational logic that causes the SCP to determine a calling party name based upon the calling party number.

3. The SCP of claim 2, wherein the computer instructions include logic to cause the processor to compare the calling party name to a list of names stored in a subscriber profile for the called party.

4. The SCP of claim 3, wherein the computer instructions define logic to prompt an external IVR to generate a message to the calling party to advise the calling party that it is not an authorized caller for the called party.

5. The SCP of claim 4, wherein the computer instructions further include logic that prompts the IVR to request approval to charge the calling party for the call.

6. The SCP of claim 4, wherein the computer instructions further include logic that prompts the calling party to state one of a calling party name or number for charging purposes.

7. The SCP of claim 6, wherein the computer instructions define logic to prompt the IVR to generate a message to the calling party to request one of a pin or an authorization code as verification that the toll charge may properly be charged to the stated number.

8. The SCP of claim 4, wherein the computer instructions further include logic that prompts the calling party to provide one of credit or bank account information to which the call is to be charged.

9. The SCP of claim 3, wherein the computer instructions define logic to prompt an external IVR to generate a message to the calling party to advise the calling party that it is not an authorized caller for the called party.

10. A method for routing a call, comprising: receiving and analyzing dialed digits to determine a calling destination; and determining if the calling party identified as an authorized calling party for the called party in a called party subscriber profile.

11. The method of claim 10 further including the step of playing an IVR message to inform the calling party that it is not authorized to make a call to the called party.

12. The method of claim 11 further including the step of playing an IVR message to ask the calling party to enter or state an access PIN.

13. The method of claim 10 further including the step of determining a calling party name.

14. The method of claim 13 wherein the step of determining includes the step of examining a subscriber profile for the called party and of comparing a list calling party names within the profile to the calling party name of the calling party.

15. The method of claim 10, further including the step of playing an IVR message to the calling party to request that the calling party state his name.

16. A method for routing a call, comprising: determining that a calling party is not authorized to make calls to the called party; playing a message to request that the called party provide a charge number; verifying the accuracy of the charge number; and connecting or rejecting a call setup request according to whether the supplied charge number was valid.

17. The method of claim 16 wherein the step of playing a message includes playing a message to request a calling party number to which the call is to be charged.

18. The method of claim 16 wherein the step of playing a message includes playing a message to request one of a bank account or credit card account number to which the call is to be charged.

19. A method for routing a call, comprising: determining that a calling party is not authorized to make calls to the called party; playing a message to request approval to charge the call to the calling party phone; and connecting the call.

20. The method of claim 19 wherein the step of playing a message includes playing a message to request a calling party number to which the call is to be charged.