BACKGROUND OF THE INVENTION

The business of providing cellular telephone service has been fraught with bad debt and cash flow problems. These problems have been so severe that they have limited profit margins for some cellular carrier companies and limited the customer base to demonstrably credit worthy, even though the demand for their service has remained high.

There are two primary reasons for the difficulties in providing cellular telephone service.

First, the cellular telephone service carrier companies must deal with a cash flow problem which is beyond their control. This is due to a billing cycle that is much too long to exercise any effective control over customer payment. The cellular telephone service carriers do not receive full account call detail and toll billing on a more frequent basis than once per month. At that point, it is possible for very high bills to have been accrued by customers, deliberately or inadvertently. In the case of the former, the bill is often never paid, which amounts to fraud. In the case of the latter, the customer is not prepared to pay the bill, which leads to a long payment cycle and suspension of service to the customer. The data is generally provided on paper and sometimes magnetic tape. The information remains unavailable until the end of a batch cycle, which prevents a minute by minute inspection of call detail. At this point the information is batch processed, usually after the billing

month is over. Generally, a cellular company received revenue from customers one month after the service was first provided. Secondly, the inability to distinguish valid from invalid cellular telephone numbers allows for cellular telephone fraud.

Without this timely account balance information or a means of determining that a cellular telephone number is a valid one, cellular telephone service carriers have no expedient means of data analysis, resulting in effective control over when a cellular telephone is operable and when it is not.

Related cellular telephone systems are disclosed in copending patent application Serial Nos. 07/603,166 and PCT US91/03583 also owned by the assignee of this application.

Summary of the Invention

This document describes the invention, a computer based system that greatly reduces the bad debt problems that frequently occur in providing cellular telephone service to a large subscriber base with a lengthy billing cycle. The real- time usage information and control system, including customer- specific credit limit control, is provided to distinguish between registered and non-registered telephone numbers and give cellular mobile telephone carriers information about the charges that their customers are incurring in substantially real time, as they happen. When a customer is registered in the control system, he or she is allotted an account balance

that, when exceeded, causes certain computer initiated action steps to be taken. Depending upon the monitoring or watch option, this account balance is either a maximum account balance per billing cycle, or in the case of having access to payment data, a running balance that incorporates payments and credits to the balance. This information is used by the control system to determine what action to take on the customer's account. If the customer exceeds the allotted maximum, the carrier has three options for action; 1) suspending service via a mechanism for controlling a standard cellular phone's ability to make calls on demand by issuing appropriate commands to a cellular telephone switch, thereby eliminating potential fraud, 2) contacting the customer to confirm payment, or 3) routing the customer originated calls to customer service/credit and collections department.

The control system is a hardware and software system designed to examine the call record and calculate charges for the call. When a cellular call is made, the routing information is passed to the Mobile Telephone Switching Office (MTSO) switch, which connects the origination # and the destination # of the call. The switch at the MTSO receives the cellular call transaction request and makes a record of it. In the preferred embodiment, the call information is recorded by an applications processor interfacing with the automatic message accounting module of the MTSO and rated for toll (long distance) charges. Then the call record passes on to a database subsystem. There, the control system stores the

data and uses it to monitor and analyze, such as by a comparison operation, the balance information of each customer account registered on the system. This information is held in a database and in memory and used by the control system (and by extension the cellular carrier) to keep a customer from exceeding a reasonable account balance without some intervention on the part of the Cellular carrier, either a suspension of service or reroute calls to a contact with customer service to confirm payment. Additionally, in the office of the cellular carrier, terminals connected to the database of the usage information and control system give office personnel real time, up-to-the-minute access to the call information, and printers generate paper copies of the reports and billing, which may include printed bills. These and further features, objects and advantages of the invention will become apparent to those skilled in the art from the following detailed description and appended drawings.

Brief Description of the Drawings

The following are descriptions of the illustrative diagrams of the control system contained in this document. Figure 1 is a pictorial diagram of a cellular telephone system. Figure 2 is a general schematic diagram of an applications processor and database processor that together interface with the MTSO switch and provide the real-time usage information and control system of the invention.

Figure 3a and 3b are general functional block and flow diagrams, respectively, of the system interface with the MTSO. Figure 4a, 4b and 4c are functional block and flow diagrams of the interface of the system of Figure 2 with the MTSO. Figure 5 is a detailed block diagram of the applications processor and database processor subsystems of the system of Figure 2. Figures 6a, 6b, and 6c are the program flowchart for the database processor of Figure 5.

Figures 7a and 7b are the program flowchart for a program called WATCHDOG, a portion of the system of Figure 5. Figure 8 is the program flowchart for a program called DOGMASTER, a portion of the system of Figure 5. Figure 9 is the program flowchart for the BILLCYCLE program, a portion of the system of Figure 5. Figure 10 is the program flowchart for a CLOSER program, a portion of the system of Figure 5. Figure 11 is the flowchart for an alternative to the Figure 9 BILLCYLE program.

Description of the Preferred Embodiments

The real-time usage information and control system (400) is a combination of hardware and software information systems shown in Figures 2 and 5 for cooperating with a cellular system shown in Figure 1. The hardware of the system is comprised of one or more high speed computers running the UNIX

operating system. There may be more than one computer if desired, but the least number of computers required is one. Information and control system (400) must be able to run at very high speeds, so as to avoid backlog of records; this allows the control system to be a real-time processor. "Real¬ time" as used herein means substantially real time in a range of not greater than 5 minutes, and is measured from the instant a raw data call record is generated and available from the automated message accounting module of the MTSO or other switch. A "real time" information and control system (400) operating in accordance with this invention is available to the cellular industry under the trademark "HOTWATCH", owned by the assignee of this application. Cellular System The Federal Communications Commission (FCC), which controls and regulates the cellular communication industry, is responsible for granting licenses required to operate cellular systems. The FCC has divided the country into a number of geographical areas. To encourage competition the FCC has decreed that there be two cellular telephone carriers in each geographical area. The FCC has further specified that one carrier must be a wire line, or standard phone service provider, and the other must be a non-wireline provider. Cellular carriers provide cellular system for each geographical area licensed. The cellular system serves to interconnect a cellular telephone subscriber with other cellular subscribers or with standard telephones.

The cellular system. Figure 1 (prior art) schematically illustrates a typical system installed and maintained by a cellular carrier. These are three major parts to a cellular telephone system: cellular subscriber stations (101); cellular base stations (or cell sites) (102); and a Mobile Telephone Switching Office (MTSO) (103).

The subscriber stations (101) are standard portable or mobile telephones, each consisting of a standard transceiver, handset and antenna. Cellular base stations (102) are arranged adjacent areas called cells. The base stations are responsible for setting up and maintaining calls placed to and from subscriber stations in their respective cells, "handing off" calls to neighboring cell sites as subscribers move and communicating call progress with the MTSO (103).

The MTSO consists of a telephone Switching System (103) with network connections to cellular base stations (102) and trunk lines (107) to and from the Public Switched Telephone Network (PSTN) (105) that in turn connect to standard phones (106). Examples of known cellular telephone switches are the Autoplex 1000 from AT&T and the Motorola 2500. It is the function of the MTSO to maintain a database of subscribers and subscriber features, track the progress of calls made to or from subscribers and record call detail for billing purposes. The telephone switching system (103) is a computer which has three general programs: a switch network program (108),

system control program (109) and an automatic message accounting program (110) .

The switch network management program (108) manages the inter-connection of subscriber stations (101) and the PSTN (105).

The system control program (109) provides functions to maintain the database of subscriber stations (101). Access to the maintenance functions is provided through asynchronous terminal connections in a know manner. The automatic message accounting program (110) delivers the call record having data for billing purposes. The method of delivery for the call detail varies from switch to switch. Some switches (103) only provide the data by storing it on magnetic tape drives. Others provide a synchronous connection utilizing some layers of the known CCITT X.25 protocol in addition to magnetic tape drives) . Still others provide asynchronous ASCII connections.

Real-Ti e Usage Information and Control System The interfaces for the real-time useage information and control system of the present invention include switch interface (104) which is a specialized hardware adapter from ports on the system hardware to any of the ATT, Ericson, Motorola or compatible switches and operates in conjunction with applications processor (200). This allows the control system (400) the capability of communicating with practically every hardware switching system that cellular carriers use,

through a link that can communicate over any other LAN or WAN system (TCP, Novell, async. or synchronous).

The applications processor (200) is here a multi-purpose processor and is programmed uniquely for the present invention to serve as an interface and to perform certain preprocessing of call records from the switch and to send commands to the switch. The applications processor identifies customers to be watched and does the first portion of the call rating, assigning the toll (long distance) charges to the call record. It has two types of interfaces to the switch.

The call record interface is provided by one or more switch monitors (106) that are switch specific hardware and software modules, as shown in Figure 3a, which receive call records from the switch at call termination. For certain types of calls intermediate records may be received during the call. The switch specific module converts these records to a generic call record format. These generic records are then sent via message queues to a call filter (108) program. The call filter joins the various pieces of a multi-record call together. It also determines if the call record is for a client of interest. If not, the record(s) is/are dropped. Checks are made for duplicate records, and if any, they are dropped. The call filter then passes the call, via the message queues, to a Pcall (109) process for rating. The process rates toll based on industry standard toll rating tables as well as checking locally defined rating rules and

local calling plan definitions. The rated calls then are sent to the control system application.

Figures 3A and 3B show, respectively, a functional block diagram of the interface for passing call records between the switch and the MTSO (103) and the control system for processing the call records generated at the switch. As indicated in Figure 3A, in certain applications, multiple switch monitors are provided, each being switch specific depending upon the MTSO equipment, which has some industry variation as known per se, are used to feed call record messages through a call filter which extracts only the customer records registered on the control system and feeds those records to a toll and local area rating processor called Pcall. As more specifically shown in Figure 3B, the applications processor (200) includes a program for performing the functions of Figure 3A and, as indicated, input call records are fed through a series of blocks beginning with a test for valid call record followed by a conversion process to convert switch specific call records to a generic or uniform format, a process known per se. This completes the function of the switch monitors as indicated in Figure 3A. Next the preprocessed call records are fed through a filtering process referred to as a call filter in which a decision block determines whether the call records belong to a registered customer of the cellular service which will include those certain customers registered on the control system. Those that are stored in a register have their call records passed

to a check for duplicate call records such as those produced when a customer passes between cells generating what appear to be two separate call records that are, in fact, one call. The record parts are joined in a merge multi-part call block again as known per se, and the now filtered and merged call records for the customers are fed to a call rating preprocessor referred to as Pcall. In the Pcall call rating, a first block sets the rating information such as rate plan and also adds a final destination flag to the call record thereby identifying those call records that are destined for the control system

(400). It is at this step that another register stores a list of customers registered in the control system, thereby distinguising the control system customers from among all customers of the cellular service which, for example, may also include rental customers. The customer call records flagged for usage control by system (400) are then passed through a decision block called local plan processor to determine whether any special or local rating process is required. If yes, the record is diverted to a special processor, known per se, for rating calls according to a local billing plan of which there a number of plans known per se. If no local or special rating process is required, then the decision block passes the control system tagged call record down through the standard toll billing for rating the call record and then passes the call record on to a decision block which looks for the control system flag. If the call record has not been flagged as a control system customer, then the call records

return to the main data path at the no output. Those records flagged for the control system then pass to the block entitled send rated message of the call record to the control system database portion of the system. At this stage, the control system record has been rated but the total charges, based on air time, have not been computed.

The preprocessed rated control system call records then leave the preprocessing portion (400a) of the control system performed in this embodiment by programs in a multi-purpose applications processor (200) and enter the control system database processing portion of the system shown in Figure 5 as 400b.

Figures 4a, 4b and 4c show the command interface by which system (400) commands to the MTSO to change a customer's service. When the system (400) wants to control the routing of a customer's phone it sends a message via message queues to the applications processor (200). A process on the applications processor determines in switch split (112) via a table lookup in file (114) which of multiple switch control process (116) to use and then uses a control to send switch specific commands to the MTSO switch and verify that they were received and processed correctly. If the command fails or cannot be processed at that time, they will be retried sometime later. The number of retries is configurable on a site by site basis. The configuration file allows this program to support widely different switch types. The message from the control system may specify one of many possible

actions, which is translated by the switch-control-process to the appropriate switch commands.

With further reference to Figures 4A, 4B and 4C, the command interface to the MTSO switch for acting on control system commands such as hotlining or otherwise changing the customer's service, is shown in the form of a functional block diagram in Figure 4A, the preferred processing performed in a program of the applications processor as shown in Figure 4B for implementing the functions of Figure 4A and finally, a block diagram of the subsystems in a typical MTSO switch that respond to the control system commands passed through the applications processor interface. Thus, in Figure 4A command messages output by the control system go to a processor commonly called a switch split augmented by a location register, all know per se for determining which of several switches within the MTSO contain that particular customer line. The switch split processor then distributes the control system change commands to the appropriate one of a plurality of switch controls, one for each of multiple switches, again as know per se. The selected switch control is then linked over a LAN (local area network) or WAN (wide area network), such as here provided by an RS 232 port to the appropriate switch in the MTSO for effecting the control system command. As shown in Figure 4B, this process of interfacing commands to the switch is performed by a program in the applications processor (200) which includes receiving the command message from the control system database portion and first determining

whether it is a valid command message. If yes, the applications processor makes a determination by a lookup table which of several switch processors control that customer, and then sends the valid message to the appropriate switch process. This completes the switch split functions. Then, the control system command is interpreted by the selected switch control process and checked for validity in a decision block. If valid, a control system command is sent over the network to the switch of the MTSO to cause a change in service as described above such as hotlining or otherwise changing the service. This all occurs as a result of the control system exercising real time usage monitoring and control.

As shown in Figure 4c, a representative functional block diagram is shown of the MTSO which, as known per se, contains a pre-existing module usually called a customer data block.

Each customer has such a data block which includes the switch identification, MIN (mobile identification number or phone number) , ESN (electronic serial number) , a hotline number (number to which the customer line can be directed such as to a credit and collection administrative office) , and a class of service (lookup table for routing calls in a manner other than the above hotline number) . This module is under the control of the control system output by the interface shown in Figures 4a and 4b. For example, should a customer exceed the usage limit, then the control system command can either, in this case, send a command to select the hotline number which may be the credit and collection department of the administrative

office, or, as another example, the class of service register may be selected, which is a program to send the call to another administative phone line having a prerecorded announcement advising the customer that his or her credit limit has been exceeded. This customer data block is, as indicated, known per se, and pre-existing in the MTSO and is implemented typically by a series of registers or blocks of memory in the MTSO processor.

As shown in Figure 5, the database subsystem (400b) of control 400 here uses a separate processor from the applications processor (400a) and consists of a group of interactive software programs and a database on which customers are registered and usage data is stored. They are an AHOT database (408a), AHOT user interface (408b), the WATCHDOG (402), the DOGSMASTER (406), BILLCYCLE (407), and CLOSER (409) programs.

All programs operate in the UNIX operating system. The data retrieval components of the database subsystem (400b) consist of three databases, written in UNIFY's ACCEL fourth generation (ACCEL 4GL) language, a report writer defined with UNIFY's Report Writer (RPT), and SQL/DA. All other software components of the system are written in the "C" programming language.

There are three types of messages sent and received by programs in the subsystem (400b); control system messages, call records, and hotlining commands. All of the internal interactive programs communicate with each other via a

messaging system (401) of a type known per se using a message queue. The messaging system (401) is a 'C programming language interface that allows programs to communicate with each other irrespective of whether they exist on the same computer or not. For communication between different processors, the messaging system can use known networking technology available and appropriate for a specific installation. The messaging system (401) isolates the application from the actual interface hardware used, as well as providing protection features to preserve data across computer system shutdowns and restarts, as known per se. Messages system (401) causes messages sent from one program to another in control system (400) to be placed into an area of memory commonly accessible to all programs, with header information encoded such that only the right program picks up the information; the system (401) operates such that it will wait for the first message to be received and acted upon before the next one will be sent.

Database subsystem (400b) stores the bulk of its data in a master database (408a) , having a list of all customers registered in the system, their names and billing addresses, stored in a UNIFY 2000 (-a tradename) relational database. The UNIFY 2000 relational database (408a) consists of customer data files including at least customer name, account #, and balance information that is updated frequently. The user interface to the UNIFY database (408a) is through AHOT (408b), such as ACCEL (-a tradename) database manager product, which

uses the compiled ACCEL 4GL and form files to define data structure for the data in the database, and controls the input and output to and from the database to the user at customer service (500). Simultaneously, there are 4GL hooks to 'C programming language functions. These hooks are used to provide AHOT (408b) with interface to both the ISAM cycle files (405) as well as the messaging system (401) . Through the interface to the messaging system (401), AHOT (408b) can communicate with the other internal 'C programs including WATCHDOG (402) and DOGSMASTER (406). The UNIFY database

(408A) also provides a 'C language interface which is used by DOGSMASTER (406) to communicate with and modify the database directly.

The current balance information for each account tracked by control system (400) is stored in the internal memory of the WATCHDOG (402) program. The "detail" information on the customer's calls, such as the length of the call, toll charges, number called, number calling from, type of call, etc., is stored on a series of ISAM "Cycle" files (405) (ISAM means Index Sequential Access Method) , one such file for each cycle. The ISAM cycle files (405) are the permanent call records for the customer base on a watch-by-watch, billing- cycle-by-billing-cycle basis.

WATCHDOG (402) also has two transaction based record files that WATCHDOG (402) stores in its memory for fact access. One file, the CHECKPOINT file (403) memory is a full backup record of the states in WATCHDOG'S (402) memory; this

file is recreated every few hours and stored to storage media. In order to safeguard the record changes to this information, the second file, the CHANGE LOG file (404) is made and the old is archived and deleted. As described previously, the monitoring, filtering and call rating preprocessor (400a) within the applications processor (200) reads the phone call record, translates it into a message format (message header and organization of data compatible with system (400b) ) and rates the call. This is based upon standard toll and/or a special charge schedule that the telephone company has assigned to that account, usually a variant on flat, stepped, or recursive charge rates. This is important, as it allows the cellular carrier to assign multiple plans to any variety of accounts. This rated call record is handed off to the database processor (400b) .

The overall processing operations of database processor (400b) are shown in the flow chart of Figures 6a, 6b and 6c, and as indicated in Figure 6a, WATCHDOG (402) processes the incoming call data received from the applications processor (200). It stores call records in the ISAM files (405). It calculates air time charges for all rated call records of all active customer accounts registered with the system (400). It also issues warning and alerts as the condition of accounts warrant. The WATCHDOG (402) program is more specifically shown in

Figures 7a and 7b and receives system messages sent by all of the other programs including the monitoring, filtering and

rating programs of the applications processor (200), the DOGSMASTER program (406), the BILLCYCLE program (407), and the CLOSER program (409) from the messaging system (401). When WATCHDOG (402) receives a message from a program in the applications processor (200), WATCHDOG (402) first sets a

CHECKPOINT (403) of its internal memory, a full backup record of all of the values and states in its memory. It then proceeds to decode the message, and split the message string into its component parts. It then checks its memory to determine whether or not the account is registered with the system by looking at database (408a) and gets account number, rate plan, phone number, balance and phone history information on the account. Then it calculates the air rate (duration of the call multiplied by the rate plan variable) and adds the appropriate amount of tax. WATCHDOG (402) then adds the computed charges to the balance of the account and compares this resulting value with the value that was set for it as a prewarning alert. If the resulting balance is less than the value set for the prewarning alert, then the predetermined conditions or relationship of usage to stored limits are all right and WATCHDOG (402) looks for the next message in the queue of messaging system (401).

If the resulting value is equal to or greater than the value set for the prewarning alert, namely a predetermined or set percentage of the total allocation for that account, then the resulting balance goes to zero or negative and action is required. The WATCHDOG (402) then sends a message to

DOGSMASTER (406), advising it of a status change. At this point, WATCHDOG (402) sends a message to DOGSMASTER (406), informing DOGSMASTER (406) that the account has a negative balance. As shown in the flowchart of Figure 8, DOGSMASTER (406) looks at the database (408a) to determine the limits on the cellular subscriber's account, based on the cellular carriers predefined plan. If the message from WATCHDOG (402) is a warning, DOGSMASTER (406) will solve the ALERT by releasing the remainder of the billing cycle credit limit to the cellular subscriber's working balance, bringing the account back to a positive value and allowing service to continue. DOGSMASTER (406) will also post the warning on the account in the database, which will be seen by customer service. WATCHDOG (402) updates the state flag on the account to the status of PRE-ALERT,

In the event that the customer exceeds the predetermined account credit limit, WATCHDOG (402) again notifies DOGSMASTER (406) that the account has dropped into a negative balance state and the state flag is set to a POST-ALERT state. In the event of the condition where the customer's charges exceed the allotted account for the month, resulting in an alarm condition, WATCHDOG (402) sends a message to DOGSMASTER and an ALERT message is sent through AHOT interface (408b) to the terminals and printer in the customer service center. The alarm messages are preferably real time or may be batched at determinable intervals. DOGSMASTER (406) looks at the database for carrier predefined action or actions to take in

this event. These actions could be to (a) hotline the account, which would either be the suspension of cellular account service, or the routing of all cellular outgoing service to the credit and collection department which incoming cellular calls would receive a no-working number message, or (b) the posting of an alert to the database, which will require a customer service decision, whether to set a temporarily higher account maximum and attempt to contact the customer, or to suspend service. At this point, the customer service officials have alternative courses of action other than to just let the customer build up large unpayable bills.

With reference to Figures 7 through 8, DOGSMASTER (406) performs all the database input and output for WATCHDOG (402). The DOGSMASTER (406) program checks the message queues of system (401) for modifying database messages from WATCHDOG (402); when the DOGSMASTER (406) receives a message from WATCHDOG (402) to update the UNIFY database (408a); DOGSMASTER (406) performs the specified update.

As shown in Figure 9, BILLCYCLE (407) performs the processing necessary at the end of each billing and watch cycle. The BILLCYCLE (407) program carries out the accounting functions at the end of the billing cycle, running every night at midnight. BILLCYCLE (407) first sends a message through the queue of messaging system (401) to the WATCHDOG (402), instructing the WATCHDOG (402) to create a new CHECKPOINT file (403). Then BILLCYCLE(407) examines the old CHECKPOINT file (403) and retrieves the transaction information from

WATCHDOG'S (402) memory. When BILLCYCLE (407) determines that a statement cycle has ended it instructs WATCHDOG (402) to archive that particular (ISAM) cycle (405). When BILLCYCLE (407) determines that any customer's watch cycle has ended, it sends a message through the message queues (401) to WATCHDOG (402), instructing WATCHDOG (402) to reset that customer's balance to reflect the beginning of a new watch cycle. In the case of a running balance option, there will be no cycle closings. BILLCYCLE (407) also updates the UNIFY database (408a) to bring any open alerts or warnings for the customers to resolution. BILLCYCLE (407) may then also generate a report at the end of the cycle, which it may send to a file that the cellular subscriber may use to generate invoices or billing. After the BILLCYCLE (407) program has run, the CLOSER

(Figure 10) program is run to look for any customer telephones or accounts which have been closed for any reason. The CLOSER (Figure 10) program then sends messages through the message queue (401), instructing both the applications processor (200) and WATCHDOG (402) that these customers are no longer registered in the system. The Applications Processor (200) will then no longer pass call information for the customer through the message queue (401), and WATCHDOG (402) will delete the customer's balance information from the memory. The Customer's matter information remains on the database but is set to "cancel", to prevent unauthorized use.

Real Time Monitoring and Control

The primary feature of this invention is that it enables the real-time collection of data from the cellular switch (103) and real-time control of the database that determines current service for subscriber stations or customers (101).

Real-time data collection is accomplished by establishing a direct connection between the switch's automatic message accounting program (110) and the control system (400) (Figures 2 and 5) including a database (408a) of customer specific accounts and having usage analysis processing to control credit limits.

On switches where the manufacturer has no provision for real time data collection, a direct interface to magnetic tapes drives where call data is logged is required. In this case, real-time data collection is still accomplished through the installation of passive tape taps installed in a manner known per se, between the switch's automatic message accounting program 110 and the switch's tape drives (not shown) .

Alternative Embodiments

As shown in Figure 11, the database processor of Figure 5 may have a modified bill cycle program (407') that generates bill reports in conjunction with database (408a) and interface (408b) using printers at customer service (500) to print customer bills.

While only particular embodiments have been disclosed herein, it will be readily apparent to persons skilled in the art that numerous changes and modifications can be made thereto, including the use of equivalent devices and method steps, without departing from the spirit of the invention.