HK1132864A - Automatic complaint registration for violations of telephonic communication regulations with call rejection - Google Patents

Abstract

A method and system for registering complaints regarding unsolicited and unwanted telephonic communication more commonly known as SPIT or SPAM over internet telephony. It is not specific to any type of telephonic network and lists: VoIP, wireless, SS7, IN, AIN, private networks. The complaints can be registered during or after the caller has received an unwanted call using basic DTMF signalling using a service code e.g. *60 designated by the carrier.

Description

Automatic complaint registration for violations of telephonic communication regulations with call rejection

RELATED APPLICATIONS

This application is a continuation-in-part of U.S. application No. 11/550,496 filed on 18.10.2006. The entire teachings of the above application are incorporated herein by reference.

Background

Complaints about unsolicited and unwanted telephone communications, such as telemarketing telephone calls, faxes, and prerecorded messages, have resulted in a large number of new federal and state laws and regulations to protect consumers and businesses from such abusive marketing practices. Similar laws and regulations exist or have been proposed in other countries, including canada, australia, and each of the european union.

Certain regulations, such as the telemarketing sales regulations of the Federal Trade Commission (FTC), require that businesses maintain a list of telephone numbers expressing consumers who wish not to be telephonically requested, referred to as a "no call" (DNC) list, and take appropriate action to ensure that outgoing calls to telephone numbers on the DNC list are prevented. The DNC lists may include one or more lists specific to a particular enterprise, as well as state-wide, domestic, and industry lists, such as direct marketing organization telephone option service lists. Other DNC regulations may dictate how, when, to whom, and under what circumstances consumers and businesses may be contacted. A single violation of federal or state DNC regulations may result in a substantial fine.

Despite such laws and regulations, many violations still occur daily and are not reported, as it is often complicated and laborious to submit complaints to the appropriate regulatory bodies. In most cases, the complaint party must submit the complaint via the website by identifying the offender, the complaint party, and the date and time of the violation. In practice, this process of having to know where to submit a complaint, efficiently collecting the required information, and spending time actually submitting the complaint precludes nearly all but a small percentage of the complaints that are feasible and actionable. For example, the federal trade commission typically waits to accumulate fifty complaints before initiating a survey. Given that it is estimated that only 0.2% of less than all complaints are reported, more than 25,000 violations will occur before the survey is initiated.

Disclosure of Invention

In one embodiment, a method comprises: receiving call information to record complaints from the called party regarding call reception to the calling party; adding call information to a complaint database; and forwarding the call information to a call rejection database configured to indicate that further calls from the calling party to the called party are blocked. In addition to this, the complaint information may include directory numbers of both the called party and the calling party.

In one embodiment, a signaling (position) may be sent to the calling party based on the received complaint volume exceeding a threshold. The advantages of this method are: the signaling may help to make the caller more compliant with regulations and regulations for unsolicited telephone communications. By notifying the caller of complaints about such violations, the caller may be able to more quickly identify and correct these problems that may cause complaints.

In another embodiment, a method includes: a request is received for a status change for an identifier entry on a user call rejection list, such as a directory number. The status of the identifier entry on the user call rejection list may be changed based on a comparison of the current status of the identifier entry with the request. The change may be the addition or deletion of a particular directory number to or from the user's call rejection list. The identifier entry and corresponding status may be sent to the gateway. The user call rejection list may be a list of directory numbers from which the consumer wishes to block incoming communications. In some embodiments, the state change may be prompted by the user from a telephone, a cellular telephone, a voice over internet protocol (VoIP) terminal, or a web interface.

Drawings

The foregoing and other features and advantages of the invention will be apparent from the following, more particular description of preferred embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention.

Fig. 1A-1E illustrate embodiments of a communication system.

Fig. 2A-2E illustrate example call flows for the communication systems of fig. 1A-1E, respectively.

FIG. 3A illustrates an example record of a DNC complaint database that stores and manages DNC complaint data.

Fig. 3B illustrates an example call rejection record.

FIG. 4 illustrates a first process of the system of FIGS. 1A-1E.

FIG. 5 illustrates a second process of the system of FIGS. 1A-1E.

FIG. 6A illustrates a third process of the system of FIGS. 1A-1E.

FIG. 6B illustrates a fourth process of the system of FIGS. 1A-1E.

FIG. 7 illustrates a fifth process of the system of FIGS. 1A-1E.

Fig. 8 illustrates an example configuration of the PSTN network of fig. 1A.

Detailed Description

Fig. 1A-1E illustrate an example communication system showing the principles of the present method. Calling device 102 and called device 104 are connected to telecommunications network 110 through respective switching nodes 106, 108. In the example shown in fig. 1A, the network 110 is a Public Switched Telephone Network (PSTN) and may be understood to include switching nodes 106, 108. It should also be understood that: the method may be applied to any network capable of providing a communication connection between an origin and a destination. In other embodiments, the network 110 may include wireless, wired, private, or public network elements, virtual private networks within the internet, wide area networks, local area networks, voice over internet protocol networks, and the like, or any combination thereof. Network 110 may be implemented using any suitable transport, switching, and routing techniques, including but not limited to Internet Protocol (IP), Asynchronous Transfer Mode (ATM), and signaling system 7 (SS 7).

The communication system further comprises: database server 112, complaint database 114, web/application server 136, regulation database 138, third party database 140, personal computer 116, and internet 118.

Calling device 102 and called device 104 are communication devices such as wired telephones, wireless telephones, fax machines, and answering machines. For purposes of illustration, device 102 is referred to as a "calling device," indicating that it is a device that initiates a telemarketing call. Likewise, device 104 is referred to as a "called device," indicating that it is a device that receives telemarketing calls.

The calling device 102 and the called device 104 are connected to the switching nodes 106, 108 via links 120, 122, respectively. The switching node may be a dedicated branch switch or a local processing switch, commonly referred to as a central office switch. Switching nodes 106, 108 are connected to PSTN 110 via links 124, 126, respectively. The central office switch may comprise any class 5 switch, for example, including a memory and processor for storing and executing software routines for call processing, including providing access to the network 110 and various call functions. In one embodiment, the central office switch includes a dual tone multi-frequency (DTMF) receiver for receiving and processing DTMF signals transmitted from the devices 102, 104.

In the example communication system shown in fig. 1A-1C, the switching nodes 106, 108 are shown as a single entity. It should be understood, however: such a switching node may comprise a plurality of physical switches. For example, as shown in fig. 1D-1E, communication devices such as called devices 104a and 104b may be connected to PSTN 110 through intermediate networks 170 and 180, respectively. It should also be understood that: the switching nodes 106, 108 may be one and the same switching node depending on the relative location of the calling and called parties.

Referring back to fig. 1A, the links 124, 126 may be one or more links that communicate payload information and signaling information over the same link or over different links. The payload information may include voice information and additional information such as video, data, commands, and text. Data link 128 connects network 110 to database server 112.

Fig. 8 illustrates an example configuration of a portion of PSTN 110 of fig. 1A. PSTN 110 includes a Switch Transfer Point (STP)810 operable to receive and transfer signals from switching nodes 106, 108. STP 810 also provides communications to a Service Control Point (SCP)830 and a Line Information Database (LIDB) 820. The SCP is a standard component of an intelligent network telephony system, which is used to control services and is connected to the database server 112 through a gateway 835. The SCP may be deployed using SS7, signaling transport protocol (Sigtran), or Session Initiation Protocol (SIP) IP technology. The SCP may query a database, such as LIDB 820, to identify the number to which the call is routed. The SCP may also query the call rejection database 155 for call rejection processing, as described further herein. The SCP may also communicate IPe with the media server 850 through the switching node, and the IPe media server 850 may accept and process information from the user, such as an account code, using DTMF receivers and implementing feature codes or Vertical Service Codes (VSCs) provided by the local switching bearer.

1B-1E illustrate various network configurations that provide communication to database server 112 according to other embodiments of the invention.

In the embodiment illustrated with respect to fig. 1B, data link 154 connects switching node 106 to switching gateway 150. The data link 154 interface between switching node 106 and switching gateway 150 may be a generic data interface provided on a class 5 switch. Switching gateway 150 may send the call information over data link 156 to private network 152, which is connected to database server 112 over data link 158.

In another embodiment shown with respect to fig. 1C, a data link 164 connects switching node 106 to an Automatic Message Accounting (AMA) gateway 160. AMA gateway 160 may send the call information over data link 166 to private network 152, which is connected to database server 112 over data link 158. AMA gateway 160 is a particular type of switching gateway 150 because it is typically configured to provide detailed billing information directly from switching node 106 in various formats. Further differences in processing details are discussed below with respect to fig. 2B and 2C.

In the embodiment shown with respect to fig. 1D, PSTN 110 communicates with cellular network 170 which is routed to called device 104a through a series of switches. A Switch Transfer Point (STP)175 in cellular network 170 communicates with called device 104a through a Mobile Switching Center (MSC)176 and a base transceiver site 177. As described further herein, an STP may query call rejection database 155 for call rejection processing.

MSC 176 provides services for circuit switched calls, mobility management, and roaming of mobile phones within the area it serves. The MSC 176 may also feature IPe a media server 179 that provides services to users. The MSC communicates with a Home Location Register (HLR)178 that contains the service profile and checks the identity of the local subscriber. In a cellular network, the HLR stores details of each Subscriber Identity Module (SIM) card issued by the mobile phone bearer. Each SIM has a unique identifier called an International Mobile Subscriber Identity (IMSI) which forms part of each HLR record. The HLR 178 is connected to the database server 112 through the HLR gateway 172.

In the embodiment shown with respect to fig. 1E, PSTN 110 communicates with a voice over internet protocol (VoIP) network 180 that is routed to called device 104b through a series of switches. VoIP gateway 185 communicates through an application server to provide VoIP access to called device 104 b. Here, access to IPe media server 830 may be provided in PSTN 110 through STP 810. As described further herein, an STP may query call rejection database 155 for call rejection processing. Data link 128 connects network 110 to database server 112.

Database server 112 is connected to complaint database 114 by data link 130. As further described herein with respect to fig. 2A-2C and 3-6, database server 112 and web/application server 136 manage the storage and retrieval of information related to complaints related to violations of telephonic communication regulations, such as violations of non-call regulations.

In some embodiments, data link 132 connects complaint database 114, regulation database 138, and third party database 140 to web/application server 136. As described with respect to FIG. 6A, web/application server 136 manages access to complaint database 144 by entities such as telemarketing companies, consumers, consumer protection organizations, and regulatory bodies. Such entities may access the database 114 over a global data network (e.g., the internet 118) using PCs 116A, 116B, and 116C configured with appropriate browsers (e.g., secure web ports) or other application software.

The secure web portal provides access to regulatory bodies, businesses, and consumers to review any complaint logs associated with their promotions and other telephone activities or individual complaints. Access to the information may be provided after the enrollment process (e.g., as described below in the example flow of fig. 6A) to ensure that access is restricted to the appropriate information and to maintain security to avoid any unauthorized access. This functionality would provide great value to regulatory bodies, consumers, and businesses alike, as it would provide them with access to up-to-date information about complaints on demand. Enterprises benefit from excellent self-tuning tools to assist them in managing their risks throughout their organization and identifying vulnerabilities in their systems and processes. Consumers benefit by having the ability to track and access complaints they submit to provide additional information to the regulatory body to support any potential violations. Regulatory bodies may also benefit by accessing complaint information to monitor compliance of companies with various telephone communication regulations. Additionally, call statistics, email notifications, alerts, messages, and thresholds may be generated for duplicate telemarketers or called directory numbers.

Regulation database 138 may include forbidden directory numbers derived from any one or combination of federal no-call lists, state no-call lists, industry specific no-call lists, customer internal lists, and other defined lists. These lists may be periodically synchronized with other lists remotely located at another facility, such as a local management facility, a local exchange carrier, a central management facility, or another facility. The regulation database 138 may be associated with an automated call compliance management system (e.g., a call advisor product available from Gryphon network corporation of norwood, massachusetts).

Third party database 140 may be any commercially available or custom database or database service that includes reverse number query data, such as business or personal name and address information.

As should be appreciated, the servers 112, 136 and databases 114, 138, 140 may reside within the premises of a client, a local exchange carrier, a local management facility, a central management facility, or other remote facility. Servers 112, 136 and databases 114, 138, 140 may also be replicated to reside at any or all referenced locations simultaneously for different telecommunications carrier implementations and process load balancing.

Fig. 2A-2E illustrate an example call flow associated with a method that may be implemented in the communication system of fig. 1A-1E to provide automatic complaint registration for violations of telephonic communication regulations. In fig. 2A-2C, the call flow illustrates the interaction between the consumer associated with called device 104 (fig. 1A-1C), PSTN network 110, the telemarketer associated with calling device 102, and database server 112. Fig. 2D-2E illustrate a call flow in which a call leaves the PSTN 110 and communicates with a called device 102a or 102b in a cellular network or VoIP network, respectively. The customer in these example call flows is also referred to as the called party and the telemarketer is referred to as the calling party.

In a first interaction, the telemarketer (calling party) places a call to the consumer (called party) via the PSTN network by dialing the called party's directory number (e.g., 617-555-XXXXXX). Next, the PSTN delivers the call to the customer using call number delivery or caller ID information. In fig. 2D and 2E, the PSTN delivers the call to a cellular network or VoIP network, respectively. Caller ID typically allows the called device to receive the directory number of the calling party and the date and time of the call during the first four second silence interval of the ringing cycle. In this example, the calling party directory number is 508 and 555-XXXX. In a third interaction, one of three actions may occur: the consumer may answer the call; the call may ring without answering; or the call may be directed to an answering machine or voicemail service. Next, upon call termination, call resources associated with the customer are released from the PSTN, cellular network, or VoIP network. In addition, the PSTN returns control to enable the telemarketer to place another call to the network.

In the example shown in fig. 2A-2E, the customer dials an x-code number, e.g., 38, to effect registration of the complaint after the call is ended. In other embodiments, the consumer may choose to register a complaint concerning the calling party during the call, after reviewing recorded messages for the call, or after reviewing captured caller ID information at the called device. The complaint may be based on the consumer having determined that the call was received from a telemarketer who has previously requested no call processing by the consumer. Another basis for complaints may be: the consumer may have previously entered the consumer's directory number into the no-call registry, for example, via the FTC operated "no-call" registry website.

In the embodiment shown in fig. 2A, the PSTN receives the incoming signal as a DTMF signal. After processing the DTMF signal, an advanced intelligent network trigger (AIN) of the SS7 network within the PSTN (shown in fig. 8 as service control point 830) delivers the nearest calling party's directory number (e.g., 508 and 555-XXXX) to database server 112. In addition, AIN/SS7 may deliver the directory number of the called party (e.g., 617-555-XXXXXX) and the time and date of the call. The database server receives the call information and stores the information in complaint database 114.

In an alternative embodiment shown with respect to fig. 2B, after the customer dials the # number, the local switch delivers the customer's nearest caller ID automatic identification number (ANI) (e.g., 508 and 555-XXXX) and the customer number information (e.g., 617 and 555-XXXX) to the switching gateway for real-time querying. The switching gateway delivers the customer's nearest caller IDANI and the customer number information to the database server 112. The database server receives the call information and stores the information in complaint database 114.

In another alternative embodiment shown with respect to fig. 2C, after the customer dials the number, the local exchange delivers the customer call detail record, including incoming and outgoing calls, to an Automatic Message Accounting (AMA) gateway. The call detail record also includes the most recent caller ID automatic identification number (ANI) (e.g., 508-. Incoming and outgoing calls to the AMA gateway may be marked with a number. These number labels indicate consumer post call events. The AMA gateway delivers only the customer's most recent caller ID ANI (e.g., 508-. The database server receives the call information and stores the information in complaint database 114.

In the embodiment illustrated with respect to fig. 2D, after the customer dials the number, an advanced intelligent network trigger (AIN) of the cellular network (shown as MSC 176 in fig. 1D) delivers the directory number of the nearest caller (e.g., 508 and 555-XXXX) to database server 112 through the home location register of the cellular network. In addition, the cellular network may deliver the directory number of the called party (e.g., 617 + 555-XXXX) and the time and date of the call. The database server receives the call information and stores the information in complaint database 114.

In the embodiment illustrated with respect to fig. 2E, after the customer dials the number, the application server of the VoIP network delivers the directory number of the nearest caller (e.g., 508 and 555-XXXX) to the database server 112 over the PSTN. The VoIP network may also deliver the directory number of the called party (e.g., 617-555-XXXX) and the time and date of the call. The database server receives the call information and stores the information in complaint database 114. Those skilled in the art will also appreciate that: the VoIP gateway may also communicate with database server 112 through many different communication networks, such as the internet.

In addition to delivering the most recent caller ID ANI and customer number information to database server 112, the system shown in fig. 1A-1E may also be configured to automatically activate selective "call rejection" consistent with typical Vertical Service Codes (VSCs) provided by local switching bearers. Typically, the consumer may activate the VSC for selective "call rejection" by entering a number (e.g., preselected VSC number 60) after the consumer wants the destination telephone number placed on the call rejection list.

In the embodiment shown in fig. 2A, the PSTN receives the incoming signal as a DTMF signal. After processing the DTMF signal, an advanced intelligent network trigger (AIN) of an SS7 network within the PSTN (e.g., shown as service control point 830 in fig. 8) delivers the nearest caller's directory number (e.g., 508-555-XXXX) to database server 112. Additionally, as shown in FIG. 7, the AIN/SS7 and SCP gateway 835 may deliver the directory number of the called party (e.g., 617 + 555-XXXXX) and the directory number of the calling party (e.g., 508 + 555-XXXXX) to the call rejection database 155. Further calls originating from the target telephone number will be prevented from being placed to the consumer. Because the most recent caller IDANI and customer number information is already accessible to the system, in addition to forwarding this information to the complaint database, embodiments of the present invention further allow the most recent caller ID to be dynamically placed in the call rejection database without requiring the customer to manually enter the target telephone number.

While the call examples described in connection with fig. 1A-1E and 2A-2E show the consumer as the called party, it should be understood that: the called party may also be another enterprise or other entity. Also, a calling party described herein as a telemarketer for illustrative purposes may also be some other entity, such as a non-telemarketer.

An example data record 300 for storing complaint information is shown in FIG. 3A. Record 300 includes several fields for calling party directory number 302, called party directory number 304, call date 306, call time 308, reverse direction query information for the calling party 310, reverse direction query information for the called party 312, called party complaint notes 314, violation regulation database number 316, and other information 318. For example, based on the entry 144 found in the third party database 140 (fig. 1A-1C), the reverse query information 310, 312 may include a name and address associated with the respective directory numbers of the calling party and the called party. Called party complaint notes 314 may include notes entered by the called party through a secure web portal for accessing complaint database 114 (FIGS. 1A-1C). The violation regulation database number 316 may indicate a particular regulation database entry or index (e.g., entry 142 in regulation database 138, fig. 1A-1C) associated with the type of violation (e.g., federal, state, or other non-call list). Other information field 318 may include other identifying information associated with the call, such as PSTN trunk and line equipment information.

Referring now to fig. 4, a process corresponding to the call flow of fig. 2A-2E is shown. At 402, an originating office (e.g., switching node 106, fig. 1A) receives a call from a calling party associated with device 102 directed to a called party associated with device 104. At 404, the call is routed to an end office (e.g., switching node 108). At 406, the called party may answer the call, not answer the call, or allow the call to proceed to an answering machine or voicemail service. The called party may determine that the call is undesirable and that the calling party has violated regulations such as no call regulations. To automatically register a complaint for such a violation, at 408, the called party enters a specific number to indicate that the calling party directory number is to be added to complaint database 114. At 410, network 110 forwards the calling party directory number and optionally other relevant call information to database server 112. As discussed with respect to fig. 1A-1E and 2A-2E, the calling party directory number and other related call information may be forwarded to the database server in a variety of ways. At 412, the database server stores the call information in a complaint database.

FIG. 5 illustrates a process by which application server 136 (FIGS. 1A-1E) manages updates to complaint information stored on database 114. At 502, the application server polls complaint database 114 for the new entry. If, at 504, the server determines that the complaint database has a new entry, then, at 506, the server checks regulation database 138 (FIGS. 1A-1E) for a match based on the called party's directory number. This may include forbidden directory numbers derived from any one or combination of federal no-call lists, state no-call lists, industry specific no-call lists, caller specific customer internal lists, and other defined lists. If, at 508, the server determines that there is no hit in the regulation database, then, at 510, the server updates the complaint record entry with such status: the status indicates that no regulatory hit (hit) was found. If there is a hit in the regulation database, then at 512, the server updates the complaint record entry with the status: the status indicates that a regulatory hit is found. The status may include an indication of the type of violation, such as an entry on a federal not call list.

The process continues at 514 with the application server requesting reverse query information from one or more third party databases 140 based on the respective directory numbers of the calling and called parties. If at 516 the server determines that legitimate reverse query information is not available, at 518 the server updates the complaint record entry with a status indicating that no information was found. If legitimate information is available, the server updates the complaint record entry with the reverse query information retrieved from the third party database 140 at 520.

FIG. 6A illustrates a process for application server 136 (FIGS. 1A-1E) to manage access to complaint information stored on database 114. At 602, the application server receives a login request from an entity, such as a telemarketing company, a consumer protection organization, or a regulatory body, through a PC 116A, 116B, 116C (fig. 1A-1E). As noted above, the application server may include a web service that provides web access, such as a secure web portal as known in the art. If the entity is not authorized to access the database at 604, the application server denies the request at 606. Otherwise, processing continues at 608 with receiving a request for complaint information from the entity. The request for complaint information can be in the form of a database query using conventional database software. Based on the different levels of user access, the entity may be limited to a particular portion of the stored complaint data records. For example, the data may be limited based on the name of the business entity associated with each individual complaint. If the query is authorized, the application server retrieves the requested information at 610 and delivers the information to the entity at 612.

The process illustrated in FIG. 6A involves delivering complaint information based on requests made by the entity. In other embodiments, the complaint information or a complaint based thereon can be forwarded to the entity without a request for the information on a periodic basis (e.g., instantaneous, daily, or monthly) or based on the occurrence of a violation event, a set threshold, or a determination of multiple violations. For example, FIG. 6B illustrates a process for database server 112 or application server 136 (FIGS. 1A-1E) to manage delivery of complaint information stored on complaint database 114. At 620, the application server receives the item of complaint information from the called party. At 622, the complaint information is entered into complaint database 114. If the amount of complaint based on the current entry for the particular caller exceeds the threshold at 624, an advisory is delivered to the caller at 626.

In other embodiments, individuals (e.g., users) may control and manage their own call barring lists in order to provide individualized communication control applied by their carriers at a mobile switching center or at a control point such as a switching control point. Rather than relying solely on the calling party to place their number on the no call list, individuals may maintain their own call rejection list or block list using the call rejection database 155 accessed through the switching control point 830, as shown in fig. 7. In addition, by blocking calls at the switching control point, the bearer can avoid contributing call setup resources at an earlier point in the process.

Fig. 3B is an example data record 350 for storing call rejection information that may be used in connection with such control. The record 350 may be stored in a database or server accessible by the SCP or MSC. The record includes several fields for the called party directory number 352, the calling party directory number 354, the call request date 356, the request time 358, whether the calling party directory number is on the blocked list 360, the source identification 362 (e.g., whether the record is from the switch or from the web interface), and other information 364. Other information field 364 may include other identifying information associated with the call, such as PSTN trunk and line equipment information. When the calling device attempts to place a call, the SCP or MSC may block the call or allow the call based on information contained in a look-up table or a block table corresponding to the called number and the calling number.

Fig. 7 illustrates a process of maintaining and changing the status of a directory identifier (or identifier entry) on a user call rejection list. The system may poll the deny queue 702 for new entries. The new entry may come from the switch or from the web interface 704. If the entry is from the switch, the requested entry is automatically logged into the user's call rejection list 706. The system then determines whether the directory identifier is already in the user's call rejection list 710. If so, the process ends. If not, the directory identifiers and status are sent to the SCP gateway for SCP processing, allowing the SCPs to update any blocklists in their respective databases. For a web interface, the user may add numbers to or delete numbers from their call rejection list 708. If they want to add a number to the list, the process is similar to an entry from a switch interface. The system determines whether the directory identifier is already on the user's call reject list 710 and accordingly sends the directory identifier and status to the SCP gateway for SCP processing. If the subscriber wants to ensure that the number is not on their call reject list, to allow future contact, the system determines if the directory identifier is on the subscriber's call reject list 714 and if so, the directory identifier and status is sent to the SCP gateway for SCP processing, allowing the SCP to delete the directory identifier from any blocklist in their respective database. If the directory identifier is not on the list, no further action is required.

It will be apparent to those of ordinary skill in the art that the methods involved in the present invention may be embodied in a computer program product that includes a computer usable medium. For example, such a computer usable medium may include a read only memory device, such as a CD ROM disk or a conventional ROM device, or a random access memory, such as a hard disk drive device or a computer diskette, having computer readable program code stored thereon.

While the invention has been particularly shown and described with reference to preferred embodiments thereof, it will be understood by those skilled in the art that: various changes in form and detail may be made therein without departing from the scope of the invention encompassed by the appended claims.

Claims (33)

1. A method, comprising:

receiving call information to record complaints from the called party regarding call reception to the calling party; and

adding a call complaint to a complaint database based on the call information.

2. The method of claim 1, further comprising: forwarding call rejection information based on the call information to a call rejection database configured to indicate that further calls from the calling party to the called party are blocked.

3. The method of claim 1, wherein: the call information includes a calling party directory number, a called party directory number, a time and date of the call.

4. The method of claim 1, wherein: the call information is received through an SS7/AIN network, a cellular communication network, a voice over internet protocol network, a private network, a switching gateway, an automatic message billing gateway, or any combination thereof.

5. The method of claim 1, further comprising: sending a message to the calling party based on the received complaint exceeding the complaint threshold.

6. The method of claim 1, wherein: receiving the call information includes receiving a DTMF signal from the called party.

7. The method of claim 6, wherein: receiving the DTMF signal comprises receiving the DTMF signal during the call.

8. The method of claim 6, wherein: receiving the DTMF signal comprises: receiving the DTMF signal after the call ends but before the called party receives another call.

9. The method of claim 1, further comprising: a request for complaint information is received from an entity.

10. The method of claim 9, further comprising: retrieving the requested complaint information from the complaint database and delivering the retrieved complaint information to the entity.

11. The method of claim 1, further comprising: forwarding the complaint information to an entity.

12. The method of claim 1, further comprising: checking for a match between called party information in a regulation database and call information in the complaint database, and updating the call information in the complaint database based on the result of the match check.

13. The method of claim 12, further comprising: the updated complaint information is retrieved from the complaint database and the retrieved complaint information is delivered to an entity.

14. The method of claim 1, further comprising: requesting reverse query information in a third party database, and updating the call information in the complaint database based on the results of the request.

15. The method of claim 14, further comprising: the method further includes retrieving updated complaint information from the complaint database, and delivering the retrieved complaint information to an entity.

16. A method, comprising:

retrieving call information from a complaints database, the call information being associated with a complaint from a called party regarding receipt of a call by a calling party;

checking a regulation database for a match between called party information and the call information; and

updating the call information in the complaint database based on the results of the match check.

17. The method of claim 16, further comprising: requesting reverse query information in a third party database and updating the call information in the complaint database based on the results of the request.

18. The method of claim 17, further comprising: the method further includes retrieving updated complaint information from the complaint database, and delivering the retrieved complaint information to an entity.

19. An apparatus, comprising:

a complaint database; and

a database server configured to receive call information to record complaints from called parties about call reception to calling parties; and adding a call complaint to the complaint database based on the call information.

20. The apparatus of claim 19, further comprising:

a regulation database, and

an application server configured to retrieve call information from the complaint database, check a match between called party information in the regulation database and the call information, and update the call information in the complaint database based on a result of the match check.

21. The apparatus of claim 20, further comprising:

a third party database;

wherein the application server is further configured to request reverse query information in the third party database and update the call information in the complaint database based on the results of the request.

22. The apparatus of claim 19, further comprising:

a call rejection database; and

wherein the database server is further configured to forward call rejection information to the call rejection database based on the call information to indicate that further calls from the calling party to the called party are blocked.

23. An apparatus, comprising:

means for receiving call information to record a complaint from the called party regarding call receipt to the calling party; and

means for adding a call complaint to a complaint database based on the call information.

24. The apparatus of claim 23, further comprising: means for forwarding call rejection information based on the call information to a call rejection database configured to indicate that further calls from the calling party to the called party are blocked.

25. A method, comprising:

receiving a request for a status change for an identifier entry on a user call rejection list;

changing the status of the identifier entry on the user call rejection list based on a comparison of the current status of the identifier entry with the request; and

based on the identifier entry and the status, the identifier entry and the corresponding status are sent to a gateway for call rejection processing.

26. The method of claim 25, wherein: the identifier entry is a telephone number.

27. The method of claim 25, wherein: changing the state includes adding or deleting an identifier entry on the list.

28. The method of claim 25, wherein: receiving the request includes receiving a DTMF signal.

29. The method of claim 25, wherein: receiving the request includes receiving the request through a web interface.

30. The method of claim 25, wherein: the gateway is a service control point gateway or a computer network gateway.

31. The method of claim 25, wherein: changing the state includes marking a field in the call record.

32. The method of claim 31, wherein: sending the identifier entry and status includes forwarding the call record to the gateway.

33. An apparatus, comprising:

means for receiving a request for a status change for an identifier entry on a user call rejection list;

means for changing the status of the identifier entry on the user call rejection list based on a comparison of the current status of the identifier entry with the request; and

means for sending the identifier entry and corresponding status to a gateway for call rejection processing based on the identifier entry and status.