Technical Field In general, the invention relates to methods of processing telephone calls. In particular, it relates to a call processing method allowing customers to define and tailor telephone services to their individual needs. More specifically, the method allows a customer to specify, within broad boundaries, the handling and ultimate disposition of calls directed to the customer based on a number of selectable call parameters, such as geographic location of the caller, time, day and additional information supplied by the caller in response to queries from the telephone system. Background of the Invention

At the present time, telephone customers, and particularly commercial telephone customers, select the types of telephone services desired from a broad, but nevertheless limited, range of services available at any given time. For example, one customer (e.g., a business) may elect to communicate between its different business locations by means of a private network and to receive calls from its customers by means of the public toll network. Another telephone customer (business) may offer toll free calling to its customers by subscribing to "SAC" IN ATS service. To ascertain what types of services should be available, typically, market analysts in the telephone industry attempt to ascertain the services the public desires and are willing to pay for and to assign developmental priorities to their determinations taking into account available resources. New services are continually being introduced by the telephone industry. Recent examples are expanded SAC INWATS, described in U.S. Patent No. 4,191,860, entitled "Data Base

Communication Cell Processing Method" which issued to R. P. Weber on March 4, 1980, automatic card calling

described in U. S. Patent No. 4,162,377, entitled "Data Base Auto Bill Calling using CCIS Direct Signaling" which issued to A. B. Mearns on July 24, 1979. Such new services are important innovations. However, these and other available services cannot be expected to meet the needs of all customers.

Perhaps equally important is the fact that there is typically a substantial delay in introducing new telephone services to the market. A lag of several years is not rare between the time a decision is made to provide a specific service and the time the service is actually available. This is due in large part to normal development time and the difficulty of integrating new features into the complicated telephone network structure. It is an object of this invention to provide a framework within which customers may tailor their telephone services to match their specific needs. It is a further objective to eliminate much of the development effort required for the introduction of new services while also providing a flexible base structure which can be quickly and easily expanded to provide additional new capabilities. Summary of the Invention

The above objectives are obtained and an advance in the telephony art is achieved in a method of controlling the operations of a telephone office in response to calls directed to telephone customers. A unique customer program, referred to herein as a customer record, is executed in response to each call to the customer. The program is defined by the customer according to the customer's requirements and contains instructions for ascertaining specified parameters of a call and instructions for generating call processing commands according to the specified parameters. The commands are received and executed by the telephone office. The execution of each command causes the office to perform one of a plurality of primitive call processing operations. Each primitive call processing operation is insufficient of

itself to completely process a call. The aggregate capabilities executed by a customer program are sufficient, however, to completely process a call according to the instructions in the customer record. The invention allows system interaction with a caller, for example, to obtain additional information which then becomes a call parameter used to control further processing of a call. For example, announcements may be played to a caller and information digits collected from the caller in response. The information digits are then interpreted by the customer program as a call parameter and the result used to determine subsequent operations of the customer program. As one illustration of this, a customer program might specify that the following announcement be played to a caller: "please dial 1 for reservations or 2 for information." The resulting digit dialed by the caller is interpreted by the customer program. The result might be, for example, the completion of the call to different locations under control of the customer program, depending on the digit dialed by the caller.

Other illustrative call parameters which may be interpreted and used to control the execution of the customer program and, therefore, call disposition include the caller's number or part of a caller's number such as the area code, the time of day, the time of week, the day of the week, the day of the year, the type of telephone (dial pulse or tone signaling) used by the caller and the call type (e.g. coin, noncoin, etc.). Brief Description of the Drawing In the drawing,

FIG. 1 is a geographical representation of the installations of a hypothetical corporate telephone customer and interconnections of the installations to the telephone network. Local telephone offices which directly service the installations in the figure are in turn connected to other switching offices called action

points (ACPs). The ACPs are connected by a signaling network to centralized data bases referred to as network control points (NCPs). The customer programs reside in and are executed by an NCP. The call processing primitives are executed by the ACPs in response to commands from an NCP. A network services complex (NSC) associated with an ACP performs announcements to and collects information digits from callers in response to commands from an NCP forwarded by the ACP: FIG. 2 shows an illustrative format of messages transmitted between an ACP and an NCP:

FIGS. 3 through 11 show illustrative formats of the message body in FIG. 2 when the message is a command to an ACP from an NCP*; FIGS. 12 through 17 show illustrative formats of the message body for messages from an ACP to an NCP: FIG. 18 shows an illustrative format of a customer program: General Description FIG. 1 is a geographical representation of a telephone system including local switching offices such as 101 and 102: Action Points (ACPs) such as 110 and 111 and a Network Control Point (NCP) 120. The ACPs are offices specially equipped to process calls in accordance with the invention. Calls so processed are called DSDC (Direct

Services Dialing Capability) calls. The ACPs also serve as access points to the Common Channel Interoffice Signaling (CCIS) network. The CCIS network is a packet data switching network which interconnects the ACPs and NCPs by data links such as 130 and 131. Packet data switching facilities are well-known and are disclosed, for example, in A. G. Fraser U.S. patents 3,749,843 of July 31 , 1973 and 3,979,733 of September 7, 1976- The structure and operations of the CCIS network are described in 67 Bell System Technical Journal, No. 2 , page 230, et seq.

An NCP is a centralized data base facility which, by way of example, may comprise a processor equipped with

disk storage and a system of programs to establish, edit and manage information stored in its data memory. In reality, there are a number of NCPs in the network, each of which in general may contain the customer programs of different customers. For simplicity, only one NCP is shown in FIG. 1 and discussed herein.

To process DSDC calls, an ACP is equipped to perform any of a plurality of primitive, independent call processing capabilities which may be linked in a desired order on demand and on a per call basis by some intelligent process to result in a proper disposition of a call. The intelligence is located in the data base of an NCP such as 120 in the form of a customer-defined program, FIG. 18, executable on a per call basis. The customer program is initially defined in a user-friendly language by interaction between an off-line computer system referred to as the User Support System (USS) 140 and users at interconnected terminals such as 141. USS 140 compiles each customer program inputted in the user-friendly language into an interpretive object language and transmits the object language to an appropriate NCP such as 120 when the customer service is activated. The user-friendly language is intended to be easily understandable and usable by telephone customers. After DSDC service is activated for a customer, the customer program at the NCP is executed in real time in response to each DSDC call to the customer. The customer program makes decisions based on certain parameters of each call specified by the customer program. The customer program generates commands which are transmitted to the associated ACP processing a call specifying call processing capabilities to be performed and the order of execution of the capabilities to dispose of the call in accordance with the customer's program. Certain decisions that must be made by the NCP require information pertaining to a caller. For this purpose, the NCP has access to a Line Number Data Base O

(LNDB) 121 which contains files addressable by the telephone numbers, or portions thereof, of callers. Illustratively, such files contain postal zip numbers of callers, time zones of callers, whether calls are made from business or residential stations and whether the callers are using dial pulse or tone signaling.

In general, it is possible to equip most recent types of toll and local offices to process DSDC calls. For purposes of this specification, it is sufficient to assume that the first offices (ACPs) to be equipped with DSDC capability will be the 4ESS (trademark of Western Electric) toll offices manufactured by Western Electric Company, Incorporated and in operation nationwide. DSDC calls will be routed via local, tandem and TSPS offices, as required, to an appropriate 4ESS office for access to the NCP via the CCIS network.

The structure arid general operation of a 4ESS " office is described in the Bell System Technical Journal, Vol. 56, No. 7, Sept. 1977. Modifications and improvements to the basic 4ESS office are described in the Bell System Technical Journal, Vol. 60, No. 6, Part 2, July-August 1981.

Some, but not all, of the 4ESS offices in operation have both CCIS and digital voice trunk access to an independently operable subsystem referred to as the

Network Services Complex (NSC) . In FIG. 1 , it is assumed that ACP 111 is associated with NSC 150, whereas ACP 110 is not associated with an NSC. The NSC is used, as will be described in detail herein, to provide certain DSDC capabilities, such as the capability to make announcements to callers and to collect information digits from callers. ACP 111 communicates with NSC 150 via CCIS data link 151 for control signaling purposes and via digital voice trunks 152 for -announcements and digit collection. As will be explained in detail, the primitive, independent call processing capabilities at an ACP include the capabilities to:

- ^* gUκE I

1. establish billing records for calls,

2. perform various announcements to callers,

3. prompt callers with instructions for inputting information digits from telephone keypads and to collect the information digits,

4. route calls to telephone numbers supplied by the NCP,

5. perform various types of final call disposition specified by the NCP other than routing to a call destination, and

6. perform service assists and handoffs of a DSDC call from an ACP serving the call to another ACP to obtain the performance of a required capability not available in the serving ACP.

The ACPs and NCPs communicate with each other by means of data messages transmitted via the CCIS network. The general format of such messages is shown in FIG. 2. A message contains two fundamental parts, a message header 200 and a message body 201. The format of the message body is discussed below for each of the individual types of messages pertaining to DSDC service. Since the CCIS network is used for applications other than DSDC, the header contains an application field APPL to identify the application for which the message pertains. For DSDC messages, a message type field MSG TYPE identifies the message contents as being either a command message from an NCP, or a message from an ACP to an NCP.

When a DSDC call is first received at an ACP, the ACP recognizes the call as a DSDC call as a result of a special access code, for example SAC, prefixed to a DSDC number identifying the customer. The ACP therefore knows that it must communicate with an NCP to obtain instructions for processing the call. At this point, the ACP does not know which NCP contains the customer program for controlling disposition of this call. Two CCIS routing domains are provided to solve this problem. The domain of

O

a message is indicated in a DOMAIN field of the message header. The first DSDC message transmitted by an ACP to the CCIS network in response to a DSDC call is referred to as an initial inquiry, or QRY(1), FIG. 12, and is transmitted in domain 1. Domain 1 uses the dialed DSDC customer number as an NCP address. Routing nodes (not shown) in the CCIS network translate the DSDC number in domain 1 to direct the QRY(1) to the appropriate NCP. The DSDC number is contained in an addressing field 202 of the header. The initial QRY(1) message from an ACP also contains a unique number identifying the ACP in a return address field 203. Each message between ACPs and NCPs also contains an indication of the length of the message in field LENGTH and a conversation number in field 204 to identify the call to which the message pertains. The conversation number is illustratively the trunk number on which the DSDC call arrived at the ACP.-

The first message returned- from an NCP to an ACP in response to a QRY(1) contains in field 203 of the header a number identifying the specific NCP in control of the call. All messages between the ACPs and the NCPs after the QRY(1) pertaining to the call are routed in domain 2. In this domain, the number identifying either the specific ACP or NCP to which the message is addressed is contained in field 202 and the return address number identifying the transmitting ACP or NCP is contained in field 203.

The general ACP call processing capabilities mentioned above may be invoked on any call by an NCP in a number of ways by commands to an ACP which include various options depending on the parameters of the call. The commands are contained in the message body 201 of FIG. 2. The formats of the message body for each command are shown in FIGS. 3 through 11. As seen in these figures, each command has a TYPE field containing an identification of the specific type of command. Since the TYPE field is common to all the commands, it will not be discussed further. The commands required to process a given call may

be sent to the ACP in one or more blocks. If more than one block is required, the NCP sends the first block to the ACPs. The ACP executes the commands in that block as described below and sends a RDY message to the NCP indicating that it has successfully completed the commands and is ready for more. The NCP continues sending commands to the ACP until all the commands have been sent. When the ACP completes the last command, it sends a DONE message to the NCP. The messages that may be sent from an ACP to the

NCP in response to commands include an exception (EXC) message shown in FIG. 15 to report various types of failures or abnormalities encountered. The message includes a failure type field and a pointer to the specific command in a block on which the failure or abnormality occurred. The specific, commands as they relate to the above-mentioned capabilities are now discussed. Billing Record

A billing record for a call is established at an ACP by a BIL (Make Billing Record) command whose format is shown in FIG. 3. In accordance with a feature of the invention, the cost of a DSDC call may be borne by the DSDC customer or shared between the customer and a caller. By way of example, billing charges for a call are partitioned into transport charges and value-added charges. The value- added component is billed to the customer. The transport component may be shared or borne entirely by the caller or customer, as the customer desires. To provide for this illustrative flexibility, a number of indicators are provided in the BIL command. The billing option parameter (BOP) specifies the allocation of transport charges between the caller and the customer. In the illustrative embodiment, any one of the following options may apply on any given call (depending on the call parameters) to a customer in accordance with the program defined by the customer: a) all transport charges are billed to the

customer or to a special customer billing number, b) all transport charges are billed to the caller, c) a fixed transport charge is billed to the caller and the remainder to the customer or to a special customer billing number. When transport charges are to be shared, items IPC (initial period charges to caller) and OPC (overtime period charges to caller) in the BIL command each contain appropriate numbers indicating the maximum charge for each type of period that is to be billed to the caller.

The items CFA (customer features available), CPS (call progress stopped) and ABR (announcements performed) relate to value-added charges. CFA contains a number that reflects the total number of a prescribed set of features, such as route the call according to the time of day or geographic location of the caller, that are contained in a customer program, but which may or may not be used on any given call to the customer. ABR contains a number indicating a charge for announcements made to a caller on a given call. CPS contains an indication that the corresponding call has been routed to a destination number or that the call has been intentionally terminated and not allowed to proceed. In addition, the BIL command includes an identification of a regional accounting office (RAO) responsible for processing the billing records of a given customer.

In response to a BIL command, the ACP assigns a billing record from memory to the associated call and records the billing information contained in the BIL command in the billing record. Program linkages are activated to cause other information, such as answer and disconnect times, to be entered into the billing record at appropriate points of a call. The billing record is subsequently transferred to the RAO for later evaluation by the RAO. The RAO determines the charge for the call and

the allocation of the charge between caller and customer, if any.

Ordinarily, the DSDC number of a called customer will be stored in a billing record and used by the RAO for billing purposes. Therefore, the billing record capability at an ACP automatically stores a customer's DSDC number in the billing record when it is established. Occasionally, however, a customer desires that billing be made to special numbe (s) for accounting purposes. This can be accomplished on a call selective basis in accordance with the customer program by the generation of a SETB (Set Billing Number) command subsequent to a BIL command. A SETB command contains a special billing number specified by a customer as shown in FIG. 4. The SETB command transmits the special billing number to an ACP where it is stored in the billing record in place of the DSDC number. Announcements and Digit Collection

In the illustrative embodiment, the capabilities to perform announcements and to collect information digits from callers are provided by a network services complex such as NSC 150 in FIG. 1. Since an NCP communicates with an ACP, commands to accomplish announcements and digit collect actions are routed by the ACP to an NSC if the ACP is associated with an NSC. Otherwise, a service assist or handoff must be performed under the control of the NCP as will be discussed below. Each NCP is provided with information describing which ACPs are associated with NSCs and which are not. Assuming that an ACP is associated with an NSC, the routing of announcement and digit collect commands to the NSC is accomplished by means of envelope

(ENV) messages to the ACP. An ENV message is identified as such by the MSG TYPE field in FIG. 2. An ACP recognizes an ENV message by means of the MSG TYPE field, reformats the header 200 information to a format expected by the NSC and retransmits the ENV on a CCIS data link such as 151 in

FIG. 1 to the NSC. The ACP waits for appropriate responses from the NSC in the form of return envelope (RENV) messages

OM

and, then retransmits the RENV to the NCP.

NSC 150 may include a data store to generate announcements to callers and tone receiving apparatus to collect information digits from callers. Informational announcements that a customer may wish to have performed to a caller at certain points in the processing of a call, or prompts for soliciting information digits from a caller for selective call processing or routing may be performed to callers in accordance with a customer program in several ways. When designing its program, a customer may select from a variety of complete announcements prestored into an NSC. Each announcement is identified by an announcement number. In addition, a vocabulary consisting of commonly used words and short meaningful phrases, such as "Thank you" or

"Please dial" are preprogrammed into an NSC and are also identified by announcement numbers.

An announce (ANN) command, shown in FIG. 5, from an NCP contains a single announcement number and requests an NSC to perform the specified announcement to a caller. However, a customer may tailor its own announcement by linking together selected ones of the preprogrammed words and phrases. A sequence announcement (SAN) command, shown in FIG. 6, provides this capability. It contains a plurality of announcement numbers and requests an NSC to perform all the specified announcements without hesitation between the individual announcements. In addition, arbitrary numerical verbal sequences may be performed by use of a digital announcement (DAN) command, shown in FIG. 7. The DAN command contains a plurality of digit identifiers arranged in the intended order of utterance. ANN, SAN and DAN commands may, of course, be generated in clusters in any desired order to allow great flexibility in announcement selection. A collect (COL) command is used to collect information digits from a caller. The collection of information digits requires an initial prompting

announcement to a caller, such as for example, "Please dial 0 if you wish the service department or 1 if you wish the sales department." The format of the COL command is shown in FIG. 8 and contains items specifying the number of digits to be collected, what action to take in the event of a caller dialing error, whether a verbal statement of the information digits received by the NSC should be given (voiceback) and one or more announcement numbers.

In response to a COL command, an NSC performs a single announcement or links the specified announcements in the same way as the ANN, DAN and SAN commands and then collects the number of digits specified in the COL command from the caller. When the digits are collected, they are returned to the NCP in an RENV message where they are used by the customer program to control the ultimate disposition of the call as will be seen. Call Routing and Termination

After all caller interaction is done, announcements have been given, and billing has been designated, the NCP must tell the ACP how to dispose of the call. Two commands, RTE (Route The Call) and FIN (Final Treatment) shown in FIGS. 9 and 10 serve this purpose.

RTE and FIN are concluding commands. One of them will always be the last command to be received by an ACP from an NCP on a call. However, there may be subsequent RTE commands sent in connection with a service handoff.

Normally, a call will be routed to some customer- chosen destination number in accordance with the parameters of the call as determined by the NCP. The ACP is informed of this destination number by a Set Routing

Number (SETR) command, shown in FIG. 4, from the NCP. The SETR command has the same format as the SETB command and is sent prior to the RTE command. The RTE command tells the ACP to route the call to the number supplied in a previous SETR command.

The FIN command terminates a call by some treatment other than by routing to a destination number.

For example, a problem such as network congestion or a caller or system error, might occur in the processing of a call and make call routing impossible. The FIN command is shown in FIG. 10 and contains a field specifying the specific final treatment to be applied by the ACP. By way of example, the final treatments might be the application of different types of tones to a calling station to distinguish between conditions such as all circuits busy, vacant code, reorder, etc. In response to a FIN command, the ACP performs the action specified in the command and then takes steps to terminate communications with the NCP for this call.

A DONE message, shown in FIG. 17, is transmitted by a serving ACP to a controlling NCP as a final action after the execution of an RTE or FIN command. As shown in FIG. 17, there is no other information in the body of the DONE message. The message is used merely to inform the NCP that the ACP has completed the call as commanded. Service Assist and Handoff Every ACP will not necessarily be capable of performing the same set of capabilities discussed herein at any given time. As was mentioned earlier, some ACPs are associated with a network services complex (NSC) which is used to perform announcements and to collect information digits from callers in response to commands from the NCP. Other ACPs may not be associated with an NSC. An ACP unassociated with an NSC is incapable of performing an announcement or a digit collection action in the illustrative embodiment. In other cases, the unavailability of a call processing capability may occur at an ACP as a result of equipment outages or as a result of ACP equipment and software modifications that are not introduced into all ACPs at the same time. Some ACPs may not have a specific announcement required by a customer program.

In most cases, a service assist is used to obtain a feature capability required to process a given call, but

which is not available at the serving ACP. A service assist is a temporary transfer of the call from the serving ACP to another ACP which can perform the required capability. In other cases, a complete transfer of the call to another ACP for completion is necessary or desirable. This is called a service handoff. For example, calls to a foreign destination must be completed via an international gateway office. Assuming that the international gateway office is an ACP, this would be an example of when a handoff from a serving ACP to the gateway ACP would be both necessary and desirable.

The assist (AST) command and the clear assist (CLA) command, shown in FIG. 11, are used to perform a service assist operation. The AST command directs an ACP to route a call to a number previously sent in an SETR command. In addition, since the service assist is a temporary operation, the serving ACP remains ready to reaccept processing of the call at a later time in response to a CLA command from the NCP.

The assist destination number sent to a serving ACP in an SETR command informs the ACP, through destination number translation, of the identity of an ACP selected for the service assist. When an assist (or handoff) call is initially received by a handoff/assist ACP, it queries the NCP for instructions. However, the NCP must have some means of associating (identifying) the query from a handoff/assist ACP with the call for which it issued an assist or handoff command. To perform this identification, a pool of 2-digit numbers is maintained at the NCP for each ACP. The 2-digit numbers are assigned individually to calls that are subjected to a service assist. The call identifying digits are concatenated with other digits to form a service assist destination number of the form NPA-OXX-AABB, where NPA (numbering plan area) refers to area code digits as in the current nationwide numbering plan. The X, A and B digits can be any value

from 0 to 9. The NPA-OXX identifies the call as a service assist call to an assisting ACP when it receives the call. The AA digits identify the controlling NCP. The BB digits are the call identifying digits mentioned above assigned by the controlling NCP. The NPA-OXX combined with the BB digits uniquely identify the particular call so that an NCP may control up to 100 assisted calls simultaneously at any given assisting ACP.

In response to an AST command, the serving ACP sends a RDY (ready) message, whose format is shown in FIG. 14, to the NCP before executing the assist. The serving ACP then seizes an appropriate outgoing trunk and routes the call via the telephone network to the ACP identified in the assist destination number by outpulsing the destination number on the seized trunk to the assisting ACP. The assisting ACP recognizes the call as an assist request and, in response transmits an inquiry message, referred to as a QRY(2), whose format is shown in FIG. 13, to the NCP identified in the AA digits of the assist destination number. The QRY(2) informs the NCP that the assisting ACP has received the call and requests instructions from the NCP. As shown in FIG. 13, the QRY(2) message contains the conversation number (the incoming trunk identification) of this call in the assisting ACP and the NPA-OXX and BB digits. The NPA-OXX-BB digits identify for the NCP which call among all the calls currently in progress at the NCP to which the QRY(2) pertains.

At this point, the BB digits are made available by the NCP for assignment to another call which is to be subjected to a service assist or handoff. ^" After the NCP receives the QRY(2), it transmits commands to the assisting ACP to have performed the capability not available at the serving ACP. The service assist will be maintained for as long as possible so that the assisting ACP will receive and perform most subsequent commands on the call. However, at some point call processing is restored to the original

serving ACP because a billing record is maintained at the original serving ACP. The NCP sends a CLA (clear assist) command to the original serving ACP to restore processing to that ACP. The conversation number in item 204 of the message header CLA command identifies the call to be cleared to the serving ACP. In response to the CLA command, the serving ACP releases the trunk connection to the assisting ACP and prepares itself to receive further commands from the NCP pertaining to the call. A service handoff is effected by transmitting the

NPA-OXX-AABB handoff routing number from a controlling NCP to the serving ACP in a SETR command. An RTE (route the call) command is then sent to the ACP, in contrast to an AST command, to cause the call to be routed by the serving ACP to the selected handoff ACP. The handoff ACP recognizes the call as a handoff call by virtue of the NPA- OXX digits. In response, it sends a QRY(2) message to the controlling NCP and then stands ready to receive commands to process the call further.