CA1228659A - Method for customer definable telephone capability - Google Patents

Abstract

METHOD FOR CUSTOMER DEFINABLE
TELEPHONE CAPABILITY

Abstract A method allowing a customer to define its telephone service within flexible boundaries for calls directed to the customer. Within constraints imposed by the selected embodiment, the method reduces software development traditionally associated with the provision of new services. A plurality of independent call processing capabilities, such as announcement, digit collection, billing, etc., are provided at a switching office. A
program defined by a customer is executed in response to each call to the customer. The program makes decisions based on the parameters of the call, such as time, ANI, information digits requested and received from the caller, etc., and links together the appropriate ones of the capabilities in the proper order to dispose of the call based on the call parameters as specified in the program.
A customer service may be modified by changing the customer program.

Description

METHOD FOR CUSTOMER DEFINABLY
TELEPHONE CAPABILITY

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 inform motion 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"
INWATS 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 . .

l'~Z~365~

into account available resources. New services are continually being introduced by the telephone industry.
Recent examples are expanded SAC INWATS, described in US. 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. Means 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. 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 ~L22~

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 preferred embodiment of 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, in the preferred embodiment, 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 informational 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 in the preferred embodiment 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, non coin, etc.).
Brief Description of the Drawing lX2B6S9 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 (Asps). The ASPS are connected by a signaling network to centralized data bases referred to as network control points Nips The customer programs reside in and are executed by an NCPo The call processing primitives are executed by the Asps in response to commands from an NIP.
A network services complex (NSC) associated with an ASP
performs announcements to and collects information digits from callers in response to commands from an NIP forwarded by the ASP;
FIG. 2 shows an illustrative format of messages transmitted between an ASP and an NIP;
FIGS. 3 through 11 show illustrative formats of the message body in FIG. 2 when the message is a command to an ASP from an NIP;
FIGS. 12 through 17 show illustrative formats of the message body for messages from an ASP to an NIP, FIG. 18 shows an illustrative format of a customer program;
FIGS. 19 through 30 show illustrative formats of the different types of instructions (also called nodes) that might exist in a customer program;
FIG. 31 shows illustrative formats of parameter expressions specified in a customer program instruction (node) to be evaluated;
FIG. 32 is a flow graph depicting the nodes of an illustrative customer program that might be specified by the hypothetical customer of FIG. 1;
FIGS. 33 through 36 show the customer program of the flow graph in FIG. 32 as the program would exist in an NIP;

l~X~365~

FIG. 37 shows a Elowgraph of a subprogram used to select an assisting ASP or a Han doff ASP when it is determined that a serving ASP lacks one or more primitive capabilities required to completely process a call according to the requirements of a customer program. A
subprogram is similar to a customer program except that it can be executed during and as part of the execution of any customer program;
FIGS. 38 through 41 show illustrative flowcharts of the program at an ASP, FIG. 42 shows illustrative formats and interrelationships of trunk registers, call registers, billing blocks and an assist table at an ASP which associates commands from an NIP with a specific call involved in a service assist or Han doff:
FIGS. 43 through 46 show illustrative flowcharts of the program at an NSC~
FIGS. 47 through 74 show illustrative flowcharts of the program at an NIP and FIG. 75 shows an illustrative format of per call memory at an NIP used as scratch memory during the execution of a customer program for each call.
General Description The first digit of three digit designation numbers and the first two digits of four digit designation numbers refer to the drawing in which the designated item or step appears. Thus, item 120 appears in FIG. 1 and step 3802 appears in FIG. 38. FIG. 1 is a geographical representation of a telephone system including local switching offices such as 101 and 102; Action Points (Asps) such as 110 and 111; and a Network Control Point (NIP) 120.
The Asps are offices specially equipped to process calls in accordance with the invention. Calls so processed are called DSDC (Direct Services Dialing Capability) calls.
The Asps also serve as access points to the Common Channel Interoffice Signaling (CCIS) network. The CCIS network is ~22~3~S9 a packet data switching network which interconnects the Asps and Nips by data links such as 130 and 131. Packet data switching facilities are well-known and are disclosed, for example, in A. G. Fraser US. 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 NIP is a centralized data base facility which, by way of example, may comprise a Western Electric Company, Incorporated 3B20D 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 Nips in the network, each of which in general may contain the customer programs of different customers. For simplicity, only one NIP is shown in FIG. 1 and discussed herein.
To process DSDC calls, an ASP 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. In accordance with the preferred embodiment of the invention, the intelligence is located in the data base of an NIP such as 120 in the form of a customer-defined program 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 (US) 140 and users at interconnected terminals such as 141. US 140 compiles each customer program inputted in the user-friendly language into an interpretive object language and transmits the object language to an appropriate NIP 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, 12~8659 the customer program at the NIP 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 ASP 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 NIP
require information pertaining to a caller. For this purpose, the NIP has access to a Line Number Data Base (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 (Asps) to be equipped with DSDC
capability will be the TESS (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 TOPS offices, as required, to an appropriate TESS office for access to the NIP via the CCIS network.
The structure and general operation of a TESS
office is described in the Bell System Technical Journal, Vol. 56, No. 7, Sept. 1977. Modifications and improvements to the basic TESS office are described in the Bell System Technical Journal, Vol. 60, No. 6, Part 2, July-August 1981.
Some, but not all, of the TESS offices in operation have both CCIS and digital voice trunk access to an independently operable subsystem referred to as the lx2a6ss Network Services Complex (NSC). In FIG. 1, it is assumed that ASP 111 is associated with NSC 150, whereas ASP 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.
ASP 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. the NSC is described in US. Patent No. 4,475,189 which issued on October 2, 1984 to Herr et at.
As will be explained in detail, the primitive, independent call processing capabilities at an ASP include the capabilities to:
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 NIP,

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

6. perform service assists and Han doffs of a DSDC call from an ASP serving the call to another ASP to obtain the performance of a required capability not available in the serving ASP.
The Asps and Nips 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 122~65~
g 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 APPLY to identify the application for which the message pertains. For DSDC
messages, a message type field MUG TYPE identifies the message contents as being either a command message from an NIP, or a message from an ASP to an NIP.
When a DSDC call is first received at an ASP, the ASP 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 ASP therefore knows that it must communicate with an NIP to obtain instructions for processing the call At this point, the ASP does not know which NIP contains the customer program for controlling disposition of this call. Two CCIS routing domains are provided to solve this problem. The domain of a message is indicated in a DOMAIN field of the message header. The first DSDC message transmitted by an ASP to the CCIS network in response to a DSDC call is referred to as an initial inquiry, or WRY, and is transmitted in domain 1. Domain 1 uses the dialed DSDC customer number as an NIP address. Routing nodes (not shown) in the CCIS
network translate the DSDC number in domain 1 to direct the WRY to the appropriate NIP. The DSDC number is contained in an addressing field 202 of the header. The initial WRY message from an ASP also contains a unique number identifying the ASP in a return address field 203.
Each message between Asps and Nips 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 ASP.
The first message returned from an NIP to an ASP
in response to a WRY contains in field 203 of the header ~2~3659 -- 1 o --a number identifying the specific NIP in control of the call. All messages between the Asps and the Nips after the WRY pertaining to the call are routed in domain 2. In this domain, the number identifying either the specific ASP
or NIP to which the message is addressed is contained in field 202 and the return address number identifying the transmitting ASP or NIP is contained in field 203.
The general ASP call processing capabilities mentioned above may be invoked on any call by an NIP in a number of ways by commands to an ASP 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 ASP in one or more blocks. If more than one block is required, the NIP sends the first block to the Asps. The ASP executes the commands in that block as described below and sends a RAY message to the NIP
indicating that it has successfully completed the commands and is ready for more. The NIP continues sending commands to the ASP until all the commands have been sent. When the ASP completes the last command, it sends a DONE message to the NIP.
The messages that may be sent from an ASP to the NIP 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 "

ASP by a BOIL (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 BOIL command. The billing option parameter (BOY) 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 OPT (overtime period charges to caller) in the GIL command each contain appropriate numbers indicating the maximum charge for each 0 type of period that is to be billed to the caller.
The items CFA (customer features available), CUPS
(call progress stopped) and AIR (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 65~

given call to the customer. AIR contains a number indicating a charge for announcements made to a caller on a given call. CUPS 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 BOIL command includes an identification of a regional accounting office (RHO) responsible for processing the billing records of a given customer.
In response to a BOIL command, the ASP assigns a billing record from memory to the associated call and records the billing information contained in the BOIL
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 RHO for later evaluation by the RHO. The RHO 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 RHO for billing purposes. Therefore, the billing record capability at an ASP 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 number(s) for accounting purposes. This can be accomplished on a call selective basis in accordance with the customer program by the generation of a SET (Set Billing Number) command subsequent to a BOIL command. A
SET command contains a special billing number specified by a customer as shown in ERG. 4. The SET command transmits the special billing number to an ASP where it is stored in the billing record in place of the DISC number.
Announcements and Digit Collection In the illustrative embodiment, the capabilities to perform announcements and to collect information digits 1;~28659 from callers are provided by a network services complex such as NSC 150 in FIG. 1. Since an NIP communicates with an ASP, commands to accomplish announcements and digit collect actions are routed by the ASP to an NSC if the ASP
is associated with an NSC. Otherwise, a service assist or Han doff must be performed under the control of the NIP as will be discussed below. Each NIP is provided with information describing which Asps are associated with NSCs and which are not. Assuming that an ASP is associated with an NSC, the routing of announcement and digit collect commands to the NSC is accomplished by means of envelope (EN) messages to the ASP. An EN message is identified as such by the SO TYPE field in FIG. 2. An ASP recognizes an EN message by means of the MUG TYPE field, reformats the header 200 information to a format expected by the NSC
and retransmits the EN on a CCIS data link such as 151 in FIG. 1 to the NSC. The ASP waits for appropriate responses from the NSC in the form of return envelope (REV) messages and, then retransmits the REV to the NIP.
The above-mentioned US. Patent No. 4,475,189 describes an NSC including a data store referred to as 125 in the patent and used to generate announcements to callers and tone receiving apparatus 138 used to collect inform motion 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 prescored into an NSC. Each announcement is identified by an announcement number. In addition, a vocabulary consisting of commonly used words ~'~Z~36~9 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 NIP 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 (COY) 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 COY 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 (voice back) and one or more announcement numbers.
In response to a COY 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 COY command from the caller. When the digits are collected, they are returned to the NIP in an REV message where they are used ~;~X~659 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 NIP must tell the ASP how to dispose of the call. Two commands, RYE (Route The Call) and FIN (Final Treatment) shown in FIGS. 9 and 10 serve this purpose.
RYE and FIN are concluding commands. One of them will always be the last command to be received by an ASP
from an NIP on a call. However, there may be subsequent RYE commands sent in connection with a service Han doff.
Normally, a call will be routed to some customer-chosen destination number in accordance with the parameters of the call as determined by the NIP. The ASP
is informed of this destination number by a Set Routing Number (SET) command ! shown in FIG. 4, from the NIP. The SET command has the same format as the SET command and is sent prior to the RYE command. The RYE command tells the ASP to route the call to the number supplied in a previous SET 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 ASP. 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 r etc. In response to a FIN command, the ASP performs the action specified in the command and then takes steps to terminate communications with the NIP
for this call.
A DONE message, shown in FIG. 17, is transmitted by a serving ASP to a controlling NIP as a final action aye after the execution of an RYE 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 NIP
that the ASP has completed the call as commanded.
Service Assist and Han doff Every ASP will not necessarily be capable of performing the same set of capabilities discussed herein at any given time As was mentioned earlier, some Asps 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 NIP.
Other Asps may not be associated with an NSC. An ASP
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 ASP as a result of equipment outages or as a result of ASP equipment and software modifications that are not introduced into all Asps at the same time. Some Asps 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 ASP. A service assist is a temporary transfer of the call from the serving ASP to another ASP which can perform the required capability.
In other cases, a complete transfer of the call to another ASP for completion is necessary or desirable.
This is called a service Han doff. For example, calls to a foreign destination must be completed via an international gateway office. Assuming that the international gateway office is an ASP, this would be an example of when a Han doff from a serving ASP to the gateway ASP would be both necessary and desirable.
-I; The assist (AT) command and the clear assist (COLA) command, shown in FIG. 11, are used to perform a ~81~59 service assist operation. The AT command directs an ASP
to route a call to a number previously sent in an STARR
command. In addition, since the service assist is a temporary operation, the serving ASP remains ready to reaccept processing of the call at a later time in response to a COLA command from the NIP.
The assist destination number sent to a serving ASP in an SET command informs the ASP, through destination number translation, of the identity of an ASP selected for the service assist. When an assist (or Han doff) call is initially received by a handoff/assist ASP, it queries the NIP for instructions. However, the NIP must have some means of associating (identifying) the query from a handoff/assist ASP with the call for which it issued an assist or Han doff command. To perform this identification, a pool of 2-digit numbers is maintained at the NIP for each ASP. 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 NAP (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 ASP when it receives the call.
The AA digits identify the controlling NCPo The BY digits are the call identifying digits mentioned above assigned by the controlling NIP. The NPA-OXX combined with the BY
digits uniquely identify the particular call so that an NIP
may control up to 100 assisted calls simultaneously at any given assisting ASP.
In response to an AT command, the serving ASP
sends a RAY (ready) message, whose format is shown in FIG. 14, to the NIP before executing the assist. The serving ASP then seizes an appropriate outgoing trunk and routes the call via the telephone network to the ASP
identified in the assist destination number by out pulsing the destination number on the seized trunk to the assisting ASP. The assisting ASP recognizes the call as an assist request and, in response transmits an inquiry message, referred to as a WRY, whose format is shown in FIG. 13, to the NIP identified in the AA digits of the assist destination number. The WRY informs the NIP that the assisting ASP has received the call and requests instructions from the NIP. As shown in FIG. 13, the WRY ( 2 ) message contains the conversation number (the incoming trunk identification) of this call in the assisting ASP
and the NPA-OXX and BY digits. The NPA-OXX-BB digits identify for the NIP which call among all the calls currently in progress at the NIP to which the WRY ( 2 ) pertains.
At this point, the BY digits are made available by the NIP for assignment to another call which is to be subjected to a service assist or Han doff. After the NIP
receives the WRY, it transmits commands to the assisting ASP to have performed the capability not available at the 20 serving ASP. The service assist will be maintained for as long as possible so that the assisting ASP will receive and perform most subsequent commands on the call. However, at some point call processing is restored to the original serving ASP because a billing record is maintained at the original serving ASP. The NIP sends a COLA (clear assist) command to the original serving ASP to restore processing to that ASP. The conversation number in item 204 of the message header COLA command identifies the call to be cleared to the serving ASP. In response to the COLA
command, the serving ASP releases the trunk connection to the assisting ASP and prepares itself to receive further commands from the NIP pertaining to the call.
A service Han doff is effected by transmitting the NPA-OXX-AABB Han doff routing number from a controlling NIP
to the serving ASP in a SET command. An RYE ( route the call) command is then sent to the ASP, in contrast to an AT command, to cause the call to be routed by the serving ~2~8659 ASP to the selected Han doff ASP. The Han doff ASP
recognizes the call as a Han doff call by virtue of the NAP-OX digits. In response, it sends a WRY message to the controlling NIP and then stands ready to receive commands to process the call further.
Detailed Description With reference to FIG. 1, we have chosen to illustrate our invention in detail by means of a hypothetical corporate customer and an illustrative customer program which might be suitable for such a customer. It is assumed that the customer has corporate locations 160, 161 and 162 on the west coast and a single location 163 on the east coast. For simplicity, it is further assumed that the corporate locations are served by private branch exchanges or automatic call distributors (not shown). The corporate telephone numbers at the locations 160, 161, 162 and 163 are assumed to be, respectively. 916-477-1000, 916-477-2000, 916-477-3000, and 212-594-3200. We will describe the invention by assuming that a call is placed from an individual station 170 on the west coast whose number is assumed to be 916-564-2520 to the DSDC number of the corporate customer. Before beginning the description, however, it is desirable to first discuss the details of customer programs at an NIP in general and the assumed program for the hypothetical corporation in particular.
FIG. 18 shows the general organization of a customer program as it would be stored in memory at an NIP. The program contains a header 1800, a section 1801 containing the program instructions (or nodes), and a translation vector table 1802. Mach header contains information specifying the length of the program, the DSDC
number of the customer, the address of the first instruction (node) of the program contained in section 1801~ a feature set describing specific features selected by the customer which might be used on any given call to the customer, an identification of a regional accounting pa office (RHO) responsible for billing the customer and an address pointer to the translation vector table 1802.
Section 1801 contains the actual instructions of the customer program. Each instruction is referred to as a node. The first instruction of a program is referred to as the root node. The nodes are further classified as action nodes and decision nodes. The nodes are generally of variable length. The beginning of each node is located by means of the translation vector table 1802 which contains the addresses of the nodes.
The different types of nodes are shown in FIGS. 19 through 30. It is understood that these node types are illustrative only and that different and additional types could be defined to achieve purposes all within the spirit and scope of the invention. Each node type contains an initial item identifying the node type.
This item will not be mentioned further in the description of the various node types.
Decision nodes control the flow through a customer program on any given call. A decision is made among other ways by an evaluation of a parameter expression contained in a decision node. The parameter expression may be classified as an integer expression or as a string expression.
Integer/String Decision Node This type of node is illustrated in FIG. 19. A
parameter expression to be evaluated is contained in item 1901. The formats of illustrative types of parameter expressions chosen for this embodiment of the invention are shown in FIG. 31. The ID item in each of the expressions in FIG. 31 identifies the type of parameter expression with which it is associated. FIG. aye shows an integer constant type of parameter expression in which is stored a constant numerical value. FIG. 31b shows a striny/constant type of expression. Encoded information representing a constant string of characters is stored in items CHAR-1 through CHAR-N. The length of the string is arbitrary and variable. Item NICKER specifies the number of characters in the string.
The remaining parameter expressions in FIGS. 31c through eye are used to specify variable decision arguments. The VARIABLE 1 expression in FIG. 31c is used to specify the evaluation of certain call parameters identified by the item TYPE. Decisions are made on the basis of the evaluation of the variable as will be explained below. Illustrative types have been selected for the preferred embodiment as follows:
TYPE MEANING

1 Determine call class 2 Determine AN
3 Determine time of day-observe daylight savings time 4 Determine time of day-do not observe daylight savings time 205 Determine time of week-observe daylight savings time 6 Determine time of week-do not observe daylight savings time

7 Determine day of week-observe daylight savings time

8 Determine day of week-do not observe daylight savings time

9 Determine day of year-observe daylight savings time 3010 Determine day of year-do not observe daylight savings time 11 Fetch argument _ 12 Generate character string CCDDE
where CC = fixed billing charge 35DD = per minute billing charge E = BOY (billing option parameter) 13 Determine type of calling station 122~36~9 14 Test the billing option parameter The ART field of VARIABLE 1 in FIG. 31c is meaningful only for the above variable types 3 through 11.
For types 3 through 10 ART contains an indication of the time zone (Atlantic, Eastern, Central, Mountain, Pacific and Alaska/Hawaii) to be applied in making the specified time evaluation.
For type 11, ART contains an integer identifying a stored value to be passed to a subprogram.

10 The class of call r as specified by type 1 above, is illustratively partitioned into the following classifications:
CLASS MEANING
01+ non coin without automatic charge quotation

11~ coin 20+
30- non coin without automatic charge quotations 40- coin 51-~ with automatic charge quotation 60- with automatic charge quotation 0 in the call classes above means that the initial digit dialed by a caller is 0 to request either operator handling or special billing, such as in Automatic Calling Card Service discussed in the aforementioned Means patent. 0- means that only the digit 0 is dialed. 0+
means that the 0 digit is followed by the dialing of all digits of a called number. Automatic charge quotation refers to a Traffic Service Position Subsystem arrangement for automatically quoting call charges to coin station callers and to other callers on request.
Parameter type 13 specifies that a decision is to be made based on the type of the calling station, i.e., dial pulse or pushbutton tone signaling. This type of - decision is also referred to as OUT (Originating Station aye Treatment).
Finally, type 14 specifies that a decision is to be made on the state of billing options pertinent to this call.
The format of a VARIABLE 2 parameter expression used to identify string or integer variables is shown in FIG. 31d. Item TYPE identifies whether the variable is a per call, per customer, or per NIP variable. In addition, TYPE identifies whether or not it is a string or integer variable. A per call variable is relevant only with respect to a specific call and may not be accessed on another cello In other words, if a customer program is actively controlling two calls at the same time, different but associated per call variables will be generated for each call. At the beginning of a call, a per call variable is empty (string) or 0 (integer). Information is loaded into the variable and used in accordance with the instructions of the customer program during the processing of the call.
Per customer variables are redefined variables accessible with respect to any call in progress under control of the customer program. Per NIP variables are redefined variables which are accessible with respect to any call being processed by the NIP. The variable argument item VAR_ARG of FIG. 31d contains an indication of the address of the variable in cohesion. The contents at that address may be the variable itself or an address which points to the variable. Which of these latter two cases applies is determined by the contents of item ID of FIG. 31d.
FIG. eye illustrates the format of a parameter expression which specifies the evaluation of a predeEined function. A function returns a value of a specified function based on the attributes included in the function call. The evaluation of a function yields a value which is either an integer or string. By way of example, the following are redefined functions which may be called on 1'~2~36~9 demand by a customer program in the illustrative embodiment 1. ZIP [ART]
ZIP returns a postal zip code associated with a calling number. The calling number is specified in the function argument field ART as a string valued expression. The postal zip number is obtained from the line number base (LNDB) shown in FIG. 1.
2. BUSINESS/RESIDENCE [ART]
This function determines if a calling station is a business or residence station. The LNDB is addressed with the calling station number expressed as a string parameter. An integer value is returned to differentiate between business and residence stations.
3. OUT [ART]
The OUT (originating station treatment) function determines the type of signaling used by a calling station. The LNDB is addressed with the calling station number expressed as a string parameter. The possible query results are pulse signaling, pushbutton tone signaling, and cannot be determined.
4. TIME ZONE [ART]
This function returns an integer identification of the time zone in which a calling station is located. The identification is obtained from the LNDB and represents one of the world time zones.
5. WIRE CENTER [ART]
A wire center is an arbitrarily defined geographic area within a given numbering plan area. This function returns an arbitrarily assigned integer which identifies a defined wire center. The NIP determines the wire center number from the calling station number using data stored in the LNDB.
6. SUM [ART]
This function calculates the sum of two integers specified in the argument field.

~228659 7. DIFFERENCE [ART]
This function calculates the difference between integers specified in the argument field.
8. PRODUCT [ART]
This function calculates the product of two integers specified in the argument field.
9. QUOTIENT [ART]
This function returns the largest integer less than or equal to the quotient of a dividend and a divisor specified in the argument field.
10. CONCATENATE [ART]
This function concatenates two string variables specified in the argument field.
11. SUB STRING [ART]
This function returns a sub string of a string parameter specified in the argument field in which the sub string begins and ends at string characters whose positions are also specified in the argument field.

12. STRING LENGTH [ART]
This function determines the number of characters in a string specified in the argument field.

13. STRING TO INTEGER [ART]
N

This function returns the value of Zoo** x (10**) (n-i)), where I is the ilk character of a string specified in the ART field.
This function is used to convert a string of numerical characters to an integer equivalent.
We now return to our discussion of the integer/string decision node shown in FIG. 19. Each possible outcome or range of outcomes of the evaluation of the parameter expression in 1901 is stored in 1906.
Assuming that there are N possible outcomes, then the addresses of N associated children nodes are stored in 1905. The appropriate outcome value corresponding to the evaluation of the parameter expression is located and the corresponding child node is obtained from 1905. This child node will be the next node to be executed in the customer program. Word 1902 contains the maximum number of outcomes that are possible as a result of the evaluation of the parameter expression. Word 1904 contains the identity of a default node which will become the output node in the event evaluation of the parameter expression of 1901 does not match any of the outcome values in words 1906. After a child node is executed, it returns a status value to its parent node which, in turn, returns the status value to its parent.
sequence Decision Node FIG. 20 shows the format of a sequence node. A
sequence node is used to execute sequentially separate branches of the sequence node. A branch consists of one or more nodes arranged to accomplish a specific function.
Specifically, the beginning node of the first branch to be executed is specified by the child 1 node address in words 2003. The result of execution of a branch returns a status value to the sequence node depending upon the results of execution of that branch. The returned status value is compared to the status value contained in word 2001 of the sequence node. If the returned value and the status value do not match, or the child node requested in the last node of a significance node, the sequence node returns to its parent the status value of the last child node executed.
The last branch (beginning with child node N in words 2003) is immediately executed, thereby skipping execution of all the remaining intermediate branches (if any).
While Decision Node This type of node is illustrated in FIG. 21.
This node provides a general looping ability by repeatedly executing a program branch beginning with the child node specified in word 2103 until either the maximum number of attempts specified in word 2102 is reached or until the child node returns a status value other than that specified in word 2101. When either occurs, the status value last ~X28659 returned by the child node is returned to the node's parent.
Announcement Node The format of an announcement node is shown in FIG. 22. This type of node causes the generation of ANN, SAN or DAN commands in accordance with the information stored in the node. Word 2203 contains one or more announcement numbers identifying announcement segments and/or specific digits to be announced to a caller.
Word 2202 contains information identifying each number in word 2203 as an announcement number or a digit string in the form of a string parameter expression. The number of announcement numbers and digits contained in word 2203 is contained in word 2201.
Collect Node A collect node, shown in FIG. 23, causes the generation of a COY command which in turn results in the performing of specified announcements to and the collection of information digits from a caller.
Set Billing Option (SO) Node The format of this node is shown in FIG. 24. Its purpose is to cause the generation of a BOIL command which, it is recalled, causes an ASP to assign a billing record for a call.
items 2401 and 2402 contain the BOY (billing opt lion) and the OPT (operator handling) parameters, respect-lively, mentioned above with respect to the BOIL command.
Items 2403 and 2404 contain, respectively an indication (IPC) of the fixed initial period charger, if any, and an indication (OPT) of the overtime charges, if any, to be billed to a caller.
Set Billing Number (SKI) Action Node This node, shown in FIG. 25, causes the generation of a SET (set billing number) command It is recalled that the SET command instructs an ASP to enter the specified billing number into a billing record created as a result of a BOIL command. The billing number is specified in item 2501 of the node.

~ZZ~3659 Connect Node This novel shown in FIG. 26, causes the goner-anion of SET (set destination number) and RYE (route the call) commands. The destination telephone number to which the call is to be routed and which is placed in the SET
command is specified in item 2601 of the node as a string constant parameter expression. A domain item 2602 of the node contains an indication as to whether an ASP should route domestically or internationally.
Set Required Capability Node This node, shown in FIG. 27, is used to establish early in the initial processing of a call a list of capabilities which may be required to process the call according to the customer program. Item 2701 of the node contains a bit string in which each bit represents a capability and the state of each bit represents whether or not that capability may be required. The bit states are established by the US at the time the customer program is compiled.
Set Variable Value Node This node, shown in FIG. 28, instructs an NO to insert a specified value into a per call, per customer or per NIP variable. The variable type (per call, per customer or per NIP) is specified in item 2801. The value of the variable is specified by a parameter expression in item 2803. The identity (address) of the variable into which the evaluated parameter expression is to be placed is contained in item 2802.
Return Status Node The results of execution of any node in a customer program is specified by the return of a status value from that node to the parent node. The use of returned status values will become clear during the discussion of a detailed illustrative example below. For the time being, it suffices to say that the Return Status Node, shown in FIG. 29, is used to force the return of a particular status value to a parent node to control the 2136~9 flow through a customer record in a particular way. The status value is specified in item 2901 of the node.
Handoff/Service Assist Action Node This node type is illustrated in FIG. 30. The handoff/service assist node may be found in a customer program or a common subprogram. A common subprogram is a program which is available for execution as part of any other customer program as dictated by the circumstances of a call. A handoff/service assist subprogram is executed at an appropriate time as part of a customer program, if, for example, an action node is encountered in the execution of the customer program which requires the performance of an ASP capability not available at the processing ASP. In this case, an appropriate handoff/assist subprogram is executed. A handoff/service assist node in such a subprogram contains a parameter expression in item 3002 specifying whether the action to be performed is a Han doff or service assist. In addition, an item 3001 specifies the NPA-OXX of an appropriate assisting ASP to perform the capability not available in the processing ASP. The NAP-OX is used to address a pool of BY numbers for the assisting ASP. The next available BY number is assigned to this call for identification purposes and the resulting NPA-OXX-AABB number (where AA identifies this NIP) is sent to the processing ASP in a SET command followed by an AT
command for a service assist, or a RYE command for a service Han doff, as priorly discussed.
Required Capability Decision Node The format of this type of node is identical -to the format of an integer/string decision node shown in FIG. 19 without, however, the parameter expression in item 1901. The purpose of the required capability decision node is to locate an ASP having all the capabilities listed in the required capability register (RCR) of FIG. 75.
With the above as introductory background, we return now to the discussion of our hypothetical corporate customer. For purposes of illustrating the operation of Lucy our invention, we have assumed that the corporate customer wishes its incoming calls to be processed as follows.
Since interactive dialing is not convenient be-tweet an NSC and a customer calling from a pulse signaling telephone, such callers are to be given toll free service and their calls are to be routed to the west coast office 162 in FIG. 1 at the number 916-477-3000. Callers at push-button tone stations who have requested either operator handling or special billing (i.e., all calls preceded by the dialing of the digit 0) are treated as if they were dialing from rotary dial stations. Callers at pushbutton tone stations not requesting operator handling or special billing (i.e., call types 0, 1 and 5 mentioned above), are given more tailored interactive treatment. Specifically, callers wishing to speak to the Reservations Department are given toll free service and connected to the west coast no-servations office 160 at number 916-477-1000. Callers who wish to speak to the Information Department are to share with the corporation a fixed charge of 50 cents for each such call. The corporation's share of the charge for each of these calls is to be billed to the west coast informal lion office 161 at number 916-477-2000 for accounting pun-poses. However, to minimize transport charges, information calls are routed to either a west coast or an east coast office, depending on the time and place of call origination.
In this hypothetical example, the east coast office 163 is open only during weekdays from 9:00 arm. to 5:00 p.m. Therefore the corporation has decided to route all calls from area codes east of the Mississippi River and occurring during OWE arm. and 5:00 p.m. Monday through Friday to the east coast office 163 at number 212-594-3200.
All other information calls are to be routed to the west coast office 161 which is open 24 hours every day.
An illustrative customer program to provide the above desired service for the hypothetical corporation is shown in state diagram form in Fig 32. The corresponding program as it would exist in memory at an NIP is shown in assay FIGS. 33 through 36.
Assume now that a caller at station 170 in FIG. 1 places a call to the corporate customer. The purpose of the call will be discussed at the appropriate times in the discussion below. The caller begins by dialing 0 or 1 +
SAC + NIX + YO-YO. "SAC" is the special access code which identifies this call as a DSDC call. The digits "NIX +
YO-YO" identify the corporate customer. With reference to FIG. 38, ASP 110 recognizes the "SAC" prefix as a DSDC call in a digit analysis step 3802 and generates and transmits a WRY message in step 3804 to the appropriate NIP via a path 130 (FIG. 1) of the CCIS network. This transmittal is indicated in FIG. 1 by the encircled step 1. Path 130 leading to the appropriate NIP is identified and selected by a translation of the DSDC number NXX-YYYY.
As shown in FIG. 12, the WRY message identi-lies the ASP type, the call type and the originating station treatment (OUT), and contains a unique conversation identifier, which is illustratively the trunk number on which the call arrives, and the number of calling station 170 (AN). The ASP type is a number that identifies the switching office type, e.g., a Traffic Service Position System (TOPS) ! together with the capabilities the office is equipped to perform. The call type was discussed earlier and will not be repeated here. For specificity, we assume that the call is a type 0 call, illustratively meaning a 1+
non coin call. We assume further that the ASP type for ASP 110 indicates a TESS office not associated with an NSC
and therefore not able to perform announcements and digit collect operations. The OUT field of the WRY message illustratively contains, respectively, 0, 1 or 2 if the signaling used by the calling station is respectively unknown, pulse or pushbutton tone. We assume that station 170 has pushbutton tone signaling YOST type 2).
Returning to FIG. 38, after the WRY message is transmitted, ASP 110 in step 3806 then seizes and initializes a billing block for recording billing details lzza6s~

of this call. The block is linked to the trunk register assigned for this call. The use of trunk and call registers to maintain temporary storage of call related data is well understood in the telephony art and will not be discussed in detail here. Typically, every call in an office is assigned a call register for the duration of the call. Calls associated with an incoming or outgoing trunk are also assigned a trunk register. The call and trunk registers are linked to each other. FIG. 42 shows the linking of a call register, a trunk register and a billing block in this preferred embodiment. FIG. 42 also shows information stored in these registers which is relevant to the invention and which will be discussed at the appropriate time. For now, a trunk register pointer 4210 in the call register points to the beginning of the trunk register which is assigned to this call. A call register pointer 4220 in the trunk register points to the beginning of the assigned call register. The trunk register also contains a billing block pointer 4222 which points to the beginning of the assigned billing block. The billing block is, in turn, linked back to the trunk by the trunk register pointer 4230.
After the WRY transmittal and initialization of the billing block performed by the program in FIG. 38, the ASP proceeds to perform work related to other calls and functions while it waits for instructions from the NIP
pertaining to this call.
At the NIP, a message processing routine (not shown) identifies the types of incoming messages and places WRY messages into a new call queue and other types of messages into a response queue. Query processing is begun by the routine shown in FIG. 47 which is entered periodically. At steps 4702 and 4704, if both the response and new call queues are empty, the query processing program exits so that the NIP may perform other work.
Assume now that the WRY message for our example is next in the new call queue and that the response ~ZZ8659 queue is empty. Steps 4706 and 4708 retrieve the dialed DSDC number of the hypothetical customer in this example and use it to identify the address of the customer program (CUP). A call progress mark (CAM) identifying a new call is pushed onto a new call stack (not shown) along with a customer node identification (CNID). Normally, the stack CNID contains an identification of the next node to be executed. At this initial point of NIP processing, the stack CNID is set to a state "unknown" by step 4710. Next, steps 4712, 4714 and 4716 remove the entry from the stack and place the present CNID and CAM into the appropriate fields of per call memory shown in FIG. 75. Step 4718 then generates the address of an appropriate routine from the CAM and transfers control to this routine. For new call Cams, control is transferred to NIKOLAI in FIG. 50.
Step 5002 of NIKOLAI obtains the ASP type from the WRY message and stores it in APT of the per call memory. The capabilities of ASP 110 are obtained from a mapping table (not shown) addressed by the ASP type indication and stored in ASPIC of per call memory by step 5004. Step 5006 loads an end-of-call CAM and CNID set to an "unknown" indication onto the stack to mark a final stack entry for this call. Other stack entries will be placed on top of this entry, as will be seen, so that when the final stack entry is unloaded, NIP processing will be terminated.
Steps 5008 through 5012 set up to execute the CUP. The CUP is examined to determine the type of the first, or root node. The root node type is placed in CAM and the number of the root node is placed in CNID. Processing is then continued at CUP in FIG. 47. CUP uses the node type in CAM to determine the address of the routine to be executed next and transfers control to that address.
Node 1 of the CUP in this example is an integer decision node as shown in FIGS. 32 and 33. CUP therefore transfers to INTDEC in FIG. 51 to execute this node. As shown in FIG. 33, the parameter expression PEP contains an OUT function. The OUT function asks for a determination of whether the calling station has rotary, pushbutton or unknown type of signaling. This information is obtained from the WRY. If the signaling method is unknown signaling LNDB 121 is queried using the calling station number contained in the WRY message. The evaluation of OUT results in a tone signaling indication 2 in this example, since the calling station is assumed to have pushbutton signaling. Step 5122 searches the child node values of node 1 for a match of the result of the OUT
function evaluation. In FIG. 33, this is found in outcome 2. Therefore, step 5124 sets CNID equal to node 5 corresponding to the matched outcome value. Had no match been found by step 5122, step 5128 would have set CNID to the default node 2 specified in instruction 1. In either event, step 5126 examines the node type in the CUP of the node now in CNID and sets CAM accordingly to cause CUP in FIG. 47 to next execute that node.
Had the calling station above used rotary dial or an unknown type of signaling, nodes 2, 3 and 4 would have been executed as shown by the flow graph in FIG. 32 and the CUP in FIG. 33. Each of these nodes are types that will be discussed at other points of the flow graph in this illustrative example.
Node 5 is an integer decision node. The parameter expression in FIG. 33 for node 5 specifies an evaluation of the call type. We have assumed that the call type in this example is 0 (1+ non coin). Reference to FIG. 32 shows that call types 0, 1 and 5 should cause a progression to node 6 and that any other type causes a progression to node 2. Referring to the outcome values in node 5 of FIG. 33, it is seen that call type 1 is associated with outcome 2 which, in turn, is associated with node 6. Accordingly, INTDEC in executing node 5 causes a progression to node 6.
Node 6 is a sequence node executed by routine SEX
in FIG. 54. It is recalled that a sequence node merely ~2Z865~

executes a sequence of specified nodes. To initiate this process, step 5402 pushes an entry onto the stack with the stack CAM set to the routine CONTSEQ in FIG. 55 and the stack CNID set to node 6 so that eventually control will return to CONTSEQ. Next, steps 5404 and 5406 set the present state of CAM in FIG. 75 to the node type of the first child node contained in the sequence node and CNID in FIG. 75 to the node number of that node. CUP is then entered to execute the first child node.
FIG. 32 shows that the first child node of node 6 is node 7. This node is a set capability node that is executed by routine SET CAP in FIG. 60. As shown by node 7 in FIG. 34, a set capability node contains a number that reflects the capabilities that may be required in the execution of the CUP. Step 6002 of SET CAP merely places that number in the required capability register (RCR) of per call memory in FIG. 75 for later use. Step 6004 sets the return status item REV of per call memory to 0. SET CAP
then enters routine UNLDSTK in FIG. 47. UNLDSTK removes the top entry from the stack and transfers control to the routine specified by the CAM stored there. In this case, this routine is CONTSEQ which was specified by node 6 when it set up control to execute its first child node.
CONTSEQ in FIG. 55 continues the execution of sequence node 6. Every node either generates a status value in REV of per call memory or returns the status value generated by a child of the node indicating the result of execution. In the case of a sequence node, the status value returned by each child node is used to determine whether or not to continue execution of the sequence. The expected status value is stored as part of the data in a node. The expected status stored in node 6 is 0. Step 5512 of CONTSEQ checks REV for this value and discontinues execution of node 6 by transferring to UNLDSTK
if the expected value is not present.
The expected value 0 was stored in REV by step 6004. Therefore, execution of the sequence node is so 9 continued unless terminated by step 5514 in the event the child node just executed was the last child node in the sequence. Node 8 yet to be executed is the last child node of node 6. Therefore, step 5516 sets up to return to 5 CONTSEQ by pushing an entry onto the stack. Steps 5518 and 5520 then setup to transfer control to node 8 by setting CNID to 8 and CAM to the node type of node 8 and entering CUP.
Node 8 is also a sequence node with an expected 10 status return value of 3. Its purpose in this example is to control the performance of an announcement to the caller and the resulting collection of information digits from the caller. It also provides for a repeat of the announcement and digit collection if the first attempt is unsuccessful.
15 The first child node of node 8 is node 9. Node 9 is also a sequence node with an expected return status value of 0.
The first child node of node 9 is node 10 which performs the announcement and digit collection. The second child node 11 of node 9 begins a sequence of nodes to evaluate 20 information dialed by a caller in response to the collect node 10 and to complete the call accordingly.
The data in node 10 of FIG. I specifies that one digit is to be collected from the caller. The announcement ID in node 10 is one or more numbers each 25 identifying an utterance to be performed by an NSC. When the announcement numbers are concatenated and performed, a verbal message such as "At the tone please dial 1 for reservations or 2 for information" is produced. The data in node 10 also specifies that the information digit when 30 returned from the ASP to the NIP is to be placed in per call register 1 for access by subsequent nodes. "Per call"
means that this register is reserved for this call while the NIP is associated with it. This prevents mutilation of the information by the processing of other calls at the NIP
35 after the information is received. The data to be stored in register 1 is also specified as a string variable in node 10.

~Z8~59 Routine COLLECT in FIG. 64 executes the collect node 10. Step 6402 determines if ASP 110 has all the capabilities that might be required to process this call.
This is done by using the ASP type indication from the WRY message to consult a table (not shown) maintained at the NIP containing the capabilities of each ASP. If the answer is no, step 6404 pushes an entry onto the stack to eventually return to CONTROL in FIG. 65. Step 6406 prepares to enter a routine E~aAFSUB by storing a "service assist" argument for the routine.
EXHAFSUB, as shown in FIG. 69, executes a subprogram FIND-ACP to identify an ASP for a Han doff or service assist. A subprogram is an executable program similar to a CUP, but which is available for use during the execution of any CUP. Step 6902 of EXHAFSUB pushes an entry onto the stack to eventually enter EXITHAFSUB in FIG. 70.
Then steps 6904 and 6906 set the present CAM and CNID to reflect the first node in subprogram FIND_ACP. EXHAFSUB
then transfers to CUP to begin execution of the subprogram.
A f'Lowgraph for one illustrative subprogram FIND-ASP is shown in FIG. 37. It is emphasized that this is only one example of a subprogram which might be used to identify an appropriate assisting or Han doff ASP. Numerous such subprograms could be designed depending on the specific design requirements of a system.
Node 3702 of FIND-ACP is a string decision node which tests the first three digits of the calling station number. This is indicated by the notation (ANN) in node 3702 which means test 3 digits of the calling number beginning with digit 1. The purpose of this test is to select a handoff/assist ASP in the same relative half of the country (east or west) as the calling station to avoid excessive routing costs. In this example, we have assumed that there are four Asps, AESOP through AESOP, across the country that are used as handoff/assist Asps. AESOP and AESOP are assumed to be in the eastern United States and 122~3659 AESOP and AESOP are assumed to be in the western United States. Asps 1, 2 and 4 are assumed to be have full capability, whereas AESOP has a known subset of the full capabilities. If the calling station were in the eastern united States, sequence node 3712 would select AESOP or AESOP
as the handoff/assist ASP. A detailed discussion of how a geographic determination is made, such as "east" or "west", will be given in our discussion of node 19. The manner of selection will become apparent in the remaining discussion.
In this example, the calling station is on the west coast. Therefore, node 3702 causes the execution of node 3704. Node 3704 is a required capability decision that is executed by routine CAPDEC in FIG. 53. The child node outcome values in item 1906 of the node each contain a set of bit indications in the same format as that of the required capabilities register (RCR) in FIG. 75 which describe the capabilities of a potential assist/handoff ASP. Step 5302 of CAPDEC searches these outcome values for an ASP which has all the required capabilities stored in RCR. If the search is successful, the present CNID is set to the child node in item 1905 corresponding to the outcome value in 1906 that satisfied the search. If the search is unsuccessful, step 5306 sets CNID to the default node in item 1904. Step 5308 sets the present CAM to reflect the node type of the selected child node and CUP is entered to continue processing.
In the present example, CAPDEC compares the required capabilities for this call as stored in RCR of per call memory in FIG. 75 to the subset of capabilities present in ASP 3 stored as part of the data of node 3704.
Let's assume that ASP 3 is ASP 111 in FIG. 1 and that it ordinarily has sufficient capability for this call.
Sequence node 3706 is therefore executed. Sequence node 3706 first executes handoff/assist (HESS) node 3708. This node is executed by the HESS routine in FIG. 73. Node 7302 determines if an assist is already in progress on this call. This is possible as will seen below. At the present 1;22~3659 time no assist is in progress. Step 7306 generates a number for routing this call to ASP 111 by selecting the next available pair of digits "BY" from an assignment pool as discussed earlier and forming the destination number NPA-OXX-AABB. It is recalled that the digits "BY" identify this call and that "NPA-0XX" identifies ASP 111. Step 7308 generates a SET command with the destination number just generated. Step 7310 determines from the HA argument if this is a Han doff or assist request. Since an assist is requested, step 7312 generates an AT command. Otherwise, step 7314 generates an RYE command. The SET and AT
commands are transmitted to ASP 110 by step 7316. This is symbolically illustrated by the encircled 2 on the CCIS
link 131 in FIG. 1. Step 7318 then pushes an entry onto the per call stack to enter ENDUES in FIG. 74 when a response to the above commands is received from ASP 110.
Control is now given to UP in FIG. 47 to suspend NIP
operations on this call.
The RYE and AT commands are received by the message dispenser in ASP 110. This routine is shown in FIG. 39. Steps 3902, 3904 and 3906 decode the SET command and transfer control to routine SET in FIG. 40. Steps 4012 and 4014 load the ASP call register for this call with the destination number NPA-0XX-AABB from the SET command.
Step 4016 loads the billing block with the destination number. Next, steps 3908, 3904 and 3906 decode the AT
command and transfer control to the AT routine in FIG. 39.
Step 4108 selects a trunk to route this call to the assist ASP 111 and loads the call register address into the assist list shown in FIG. 42 using the BY digits of the assist number as an index. Step 4110 loads a call state vector in the call register with a "dialing complete" call state. The assist number is also written into the call register. Finally, the trunk register is updated to return control to software address B in FIG. 39 after a call routing attempt is complete. Control is then given up temporarily. Conventional software in the ASP now attempts lx2a~ss to route the call from ASP 110 to assist ASP 111 in accordance with information in the call and trunk registers. This is encircled step 3 on trunk 112 in FIG. 1. Assuming that a call is successfully routed, control eventually returns to address B in FIG. 41 where an RAY message is returned from assisting ASP 111 to NIP 120 by step 3924. This message is represented by the encircled 4 on link 131 in FIG. 1.
If call routing to the assist ASP fails, a software timing function (not shown) at NIP 120 will eventually timeout and cause the generation of COLA and FIN
commands to clear the call out of the system.
ASP 111 recognizes the incoming call as an assist call from the received destination number as discussed. In response, it formulates and transmits a WRY message to NIP 120 via CCIS link 130. This is encircled step 5 on link 130 in FIG. 1.
The WRY message is placed in the response queue of NIP l20 upon arrival. Steps 4702 and 4720 of FIG.
47 remove the WRY message from the response queue on a subsequent entry to routine UP. Step 4722 tests to see if the last command sent to an ASP on this call was a FIN
command. Since this is not the case in this example, step 4712 next removes the top entry from the per call stack to determine what to do next. The top entry contains an ENDUES CAM put there by step 7318. Therefore, step 4718 causes a transfer to routine ENDUES in FIG. 74. Step 7420 translates the ASP type received from the assist ASP
111 in the WRY message into a set of capabilities. A
representation of these capabilities is then stored in ASPIC
of the per call memory of FIG. 75. Next, step 7422 determines from the required capabilities stored in RCR of per call memory if the assist ASP 111 has all the required capabilities. If so, step 7424 sets the return status value REV to 0. Otherwise, step 7426 sets REV to the failure value 20 ENDUES now transfers to UNLDSTK in FIG. 47 to ~22865~

process the next stack entry. This is a CONTSEQ entry placed in the stack by the execution of sequence node 3706 in the FIND-ACP subprogram. Processing of this entry by CONTSEQ in FIG. 55 results in a return to UNLDSTK to process the next stack entry. This entry is an EXITHAFSUB
CAM put onto the stack by step 6902. Step 7008 of EXITHAFSUB tests REV and returns to UNLDSTK if the return value 0 is present. This means that the assist ASP 111 is capable of processing remaining commands issued by NIP 120 on this call. On the other hand, if an REV other than 0 is present, efforts to find an assisting ASP have failed and step 7010 determines if a service assist is in progress.
If so, step 7012 generates a COLA command. In either event, step 7014 generates a FIN command. These commands are transmitted to the control ASP 110 to terminate the call.
In this event, the COLA command causes ASP 110 to release the call connection to assist ASP 111. The FIN command specifies an appropriate final treatment such as give reorder tone to the caller.
If we assume that the REV is 0, UNLDSTK reads the stack entry to continue processing of the call. The next stack entry is a CONTROL CAM stored by step 6404 in the COLLECT routine. CONTROL is in FIG. 65. Steps 6508 and 6510 generate and transmit a COY command to the assist ASP 111. Because the digit collect function is performed by an NSC specifically NSC 150 in this case), the COY
command is transmitted as an envelope message This is encircled step 6 on link 130 in FIG. 1. Step 6512 pushes an ENDCOL CAM entry onto the stack and enters UP in FIG. 47 to wait for execution of the envelope.
With reference to the ASP flow diagrams in FIG. 39, step 3902 recognizes the envelope command and transfers control to EN in FIG. 39. Since this is the first envelope command on this call, step 3910 seizes a trunk to SKYE 150 in a conventional manner. Steps 3912, 3914 and 3916 perform bookkeeping operations such as storing the NIP 120 number in the ASP call register for this call and ~22~sj9 setting the call state in the call register to "waiting for a start of envelope (SUE) response" from the NSC. Step 3916 transmits the envelope message to NSC 150 and ASP call processing is then temporarily suspended to await NSC
action on the envelope. The envelope transmittal to NSC 150 is encircled step 7 on link 152 in FIG. 1.
Receipt of the envelope command at NSC 150 causes the execution of routine NSCSTART in FIG. 43. Before calling NSCSTART, a preprocessing program (not shown) seizes and initializes a call register at the NSC in a conventional manner. Step 4304 reads the call register to determine the call state. Initially the call state reflects an inactive state and the arrival of the envelope message. Step 4304 determines that this is the first envelope message to arrive on this call. It assigns switching time slots in a conventional manner for communication between the incoming trunk and a tone receiver and announcement machine at the NSC. Step 4308 sends an SUE message to CUP 111. This is encircled step 8 on link 152 in FIG 1. Step 3917 of routine SUE in the ASP
flowcharts of FIG. 39 sets an appropriate call state into the call register in response to the SUE message. At step 4310 subroutine COMMAND EXECUTOR in FIG. 44 is called.
A mode parameter set to START is passed by the subroutine call. Step 4402 tests the mode parameter and, as a result, step 4404 calls another subroutine COMMAND TRANSLATOR
(FIG. 45). Step 4502 of COMMAND TRANSLATOR interprets the first command of the envelope message as a COY and transfers to step 4504 to generate action blocks for execution of the COY command. An action block is a template of instructions for execution into which parameters are inserted by step 4504 before execution in response to a command for an NIP. One of three action blocks A, B and C may be generated by step 4504 according to the parameters of the COY command from NIP 120. An A
block requests voice back. It may be recalled that voice back means a playback of any information digits dialed lXZ8659 by the caller. A block and B block specifies no voice back with some type of error treatment in case the caller incorrectly dials information digits. A block and C block specifies no voice back and no error treatment.
The templates for the action blocks A, B and C
are as follows-Action Block A
1. PLAY COLLECT go to instruction 5 on success, instruction 2 on failure 2. SEND DIGITS
3. SYNDICS
4. EXIT
5. SAVE DIGITS
6. PLAY COLLECT go to instruction 9 for " digit, instruction 7 for any other digit 7. SEND SAVED
8. EXIT
9. PLAY COLLECT
10. SEND DIGITS
Action Block B
1. PLAY COLLECT go to instruction 5 on success, instruction 2 on failure 2. SEND DIGITS
3. SYNDICS
4. EXIT
5. SEND DIGITS
Action Block C
1. PLAY COLLECT; go to instruction 5 on success, instruction 2 on failure 2. SEND DIGITS
Each of the above-numbered statements in the action blocks is an instruction which is interpreted and executed at the appropriate time by the NSC. The discussion below will provide a clear understanding of the action blocks.
Reference to collect node 10 of the CUP in FIG. 34 shows that a collect message with voice back and no error lZ286S9 treatment is requested in this example. Therefore, an action block A is generated by step 4504. Step 4506 determines if the last command executed by the NSC was an announcement. If so, steps 4508 and 4510 add announcement numbers to the action block for any following and consecutive announcement or collect commands. This allows virtually any number of announcement numbers to be specified in consecutive NIP commands and to be performed by the NSC as one announcement. In the present case, the COY command was the first command encountered by the NSC.
Therefore step 4512 is executed which sets a return parameter to "not dowel' and returns to the calling routine at step 4406.
Step 4406 determines from the return parameter that command execution is not complete and calls an action block interpreter subroutine at step 4410.
The interpreter is shown in FIG. 46. It is no-called that an action block A is being executed. Step 4602 of the interpreter merely fetches instructions sequentially from the action block as they are executed. The first instruction of action block A is PLAY COLLECT In step 4604, this instruction causes the interpreter to initialize the NSC to play the prompt message and collect the number of digits specified in the COY command. Step 4606 sets a return parameter to "wait" and exits to the calling routine to await the completion of digit collection. As a result of this return parameter, step 4412 returns a "not done"
return parameter to its calling routine which takes execution to step 4312 in FIG. 43. Since the envelope is not completed, step 4314 sets the call register call state to "active" and exits to the main program.
When digit collection is complete, an interaction report is generated by the software (not shown) which controls the prompting and digit collection hardware. This causes an entry to NSCSTART in FIG. 43 and execution of COMMAND EXECUTOR at step 4318. The mode parameter is not set to "start" at this time. Therefore, step 4402 in ~ZZ8659 COMMAND EXECUTOR transfers control to step 4410 which calls the action block interpreter. Step 4602 now reads instruction 1 again and, at this point in the execution of the action block, determines the result of the prompt and digit collection. If the NSC hardware successfully played the prompt and collected one digit as requested, step 4602 goes to instruction 5 of the action block as specified in instruction 1. Otherwise, control is passed to SEND DIGITS
instruction 2. In response to instruction 2, step 4610 would send whatever digits, if any, were collected to ASP 111 in a REV message. Next, instruction 3 would send an exception report (EXC) to the ASP to mark a failure.
If we assume that the prompt and digit collection are successful, instruction 5 is executed. Instruction 5 is a SAVE DIGITS instruction. Step 4620 of the interpreter stores the collected digit in response to this instruction and the next instruction 6 is executed. Instruction 6 is a PLAY COLLECT Stored within this particular PLAY COLLECT
instruction is a preset announcement number which is used to perform a voice back to the caller. The voice back announcement might illustratively be "You have dialed the digit 2. If this is what you intended, at the tone depress the number key. Otherwise, depress the asterisk key and then input the correct digit or digits again."
This PLAY COLLECT operates as the one discussed above. Step 4604 initializes the NSC hardware to perform the voice back and to collect one digit. If the caller inputs an * signal in response to the voice back, control will be given to instruction 9 otherwise, control is given to instruction 7. The original PLAY COLLECT is repeated at instruction 9 and whatever information digit(s) are collected in response are transmitted by step 4610 in response to instruction 10.
For this discussion, we assume that the caller sends information digit 2 in response to the prompt and depresses the # key after receiving the voice back. This causes the PLAY COLLECT instruction 6 to transfer to ~28659 instruction 7. Instruction 7 is SEND SAVED In response to this type of instruction, step 4616 builds a return envelope (REV) message with the caller inputted information digit 2 stored by the SAVE DIGITS instruction 5 and transmits the REV to ASP 111. This is encircled step 9 in FIG. 1. The next instruction in action block A
is then executed. This is EXIT instruction 8. In response to this instruction, step 4622 returns a "done" parameter to its calling routine at step 4410 in FIG. 44. As a result, the COMMAND TRANSLATOR subroutine is called at step 4404. The COMMAND TRANSLATOR finds that all commands in the EN have been executed. Step 4514 therefore returns a "done" parameter to its calling routine at step 4404. Step 4406 determines that the EN is complete and returns a "done" parameter at step 4408 to its calling routine. The next step executed is 4320 which advances to step 4322 where an "end of envelope" (HOE) signal is generated and transmitted to ASP 111. This is encircled step 10 in FIG. 1. Step 4324 sets the call register to an inactive state and exits. Eventually, step 4302 will find a disconnect/inactive call state in the call register on a subsequent entry to NSC START at which time steps 4426, 4428 and 4430 idle service circuits and remove the call from the NSC.
The REV message generated at step 4616 of the NSC program is received and decoded at step 3918 of the ASP
program in FIG. 39. As a result, routine REV in FIG. 39 is entered. Steps 3920 and 3922 add an appropriate header to the REV message and transmit it to NIP 120. This is shown as encircled step 11 in FIG. 1.
The REV message is placed in the response queue when it is received at NIP 120. When it is unloaded from the queue, step 4718 of UP in FIG. 47 transfers control to ENDCOL in FIG. 66 using the CAM placed onto the stack by step 6512. Step 6614 stores the collected digit returned in the REV message in register 1 as specified in collect node 10 of the CUP. Step 6616 sets the REV to a return value of 0 and goes to UNLDSTK.
The next stack entry contains a CAM to enter CONTSEQ in FIG. OWE It may be recalled that this CAM was pushed onto the stack at step 5402 in connection with the start of execution of sequence node 9. The REV value 0 returned by node 10 is compared against the value stored in sequence node 9 by step 5512 of CONTSEQ. The values match in this case as seen in node 9 of FIG. 34.
Therefore, step 5512 continues with execution of sequence node 9. Steps 5516, 5518 and 5520 setup to return to CONTSEQ after execution of the next child node 11 as shown in FIG. 32. Node 11 performs a string decision on the contents of register 1 which now contains the digit 2 inputted by the caller. String decision nodes are executed by routine STRING in FIG. 52. FIG. 52 shows STRING as transferring to INTDEC for execution. This is for simplicity, it being understood that the same logical steps performed by INTDEC are performed by STRING with the obvious modifications necessary for processing string data.
We will discuss briefly at this point the actions that would be taken had the caller inputted an information digit other than 2. Assume first that a digit other than 1 or 2 was inputted. FIG. 32 shows that return status node 12 would be executed. This type of node is executed by routine 25 STATUS in FIG. 62. Step 6202 sets the REV to the value specified in the node. In node 12, the REV value is 3.
This is a fail value because it is not the value 0 stored in sequence node 9. Since this leg of the CUP represents the last child leg of node 9, node 9 returns control to sequence node 8 (its parent) with REV still set to 3 from return status node 12. An REV of 3 is the value stored in node 8.
Therefore, node 8 executes its next child node. FIG. 32 shows that the next child node of 8 returns to sequence node 9. Thus, a second attempt to get the caller to input a valid information digit 1 or 2 is performed If an incorrect digit is inputted again by the caller, the REV of 3 returned to node 8 will cause it to execute its last ~.2Z8659 child node 23. Node 23 is an announce node executed by routine ANN in FIG. 68 r ANN first determines if the present serving ASP has the capability to perform announcements and particularly the announcement number specified in the node If not, a service assist ASP is located in the same manner as already discussed. Control eventually reaches CONTAIN in FIG. 67 where the appropriate ANN and/or DAN commands are generated and transmitted to the serving ASP to perform a desired announcement. In this example, an appropriate announcement might be "Sorry, your call cannot be completed as dialed.
Please call the operator for assistance."
If it is assumed that the caller inputted information digit 1 at node 11, sequence node 13 would be executed. The first child node of node 13 is set billing option node 14. In response to a set billing option node, step 5902 of routine SO in FIG. 59 reads values for specified fields of the per call memory from the node and stores the values in the specified field. Node 14 specifies a BOY value of 1 which means "toll free" to the caller. Step 5904 sets the REV to 0. This causes sequence node 13 to advance to its next child node 15 which is a connect node. This type of node is discussed in detail at a more appropriate time below.
Since in our actual example, the caller dialed a 2 information digit at collect node 10l string decision node 11 actually advances to sequence node 16. The first child node 17 of sequence node 16 sets the billing option parameter in per call memory to the value 4 specified in the node (see FIG. 35). This specifies that fixed charges are billed to the caller and the remaining charges are to be billed to the customer. The node also specifies a value for IPC equal to 10. This specifies the caller fixed charges to be 5 cents x 10 for a total of 50 cents.
The next node executed is set billing number node 18. This is an instance of a situation in which the ~228659 customer wishes to bill to a number other than its DSDC
number. Routine SET in FIG. 63 executes this type of node. Step 6304 sets the billing number record (BAR) of per call memory to the number specified in the node, which in this instance is 916-477-2000 corresponding to office 161 in FIG. 1.
The final child of node 16 is string decision node 19. As shown in FIG. 35, the parameter expression specified in node 19 is a sub string function consisting of the first three characters of the calling station number.
The purpose is to find the area code of the calling station All outcome values specified in node 19 of FIG.
35 are area codes considered by the customer to be located in the "eastern half" of the country. If the evaluation of the parameter expression results in one of these outcome values; node 20 will be executed. Otherwise, the default node 22 will be executed.
In the present example, the caller is located on the west coast. Therefore, connect node 22 is executed by routine CONNECT in FIG. 61. Step 6102 evaluates the parameter expression stored in the node to obtain the telephone number to which the call is to be routed. This is 916-477-2000 in this example. A service assist is presently in progress to ASP 111 in this example.
Therefore, steps 6103 and 6104 generate a COLA command to release the assist ASP 111.
Since a BOIL command has not yet been sent during execution of the CUP (step 6106) in this example, step 6110 generates a BOIL command with CUPS (call progress stopped) =
1. A value of 1 in CUPS means that this call is routed to a destination number rather than to some type of final treatment. Ultimately the value of CUPS is included in the billing record at the ASP and used to price the billing for this call.
If the billing number record (BAR) in per call memory contains a billing number, steps 6112 and 6114 generate a SET command to transmit the billing number to lZ2B6S9 ASP 110. This occurs in our example, because BAR was set to a nonzeros value by node 17.
If a Han doff has occurred on this call, the Han doff ASP requires the calling station number and the customer SAC number. SET and SET commands are generated at step 6120 to accomplish this. This does not occur in our example.
Step 6122 generates a SET command to give the destination number to the ASP. Step 6124 generates an RYE
command to instruct the ASP to route the call to the destination number. The last step 6126 in the execution of the connect node 22 sets REV to 0. At this time UP in FIG.
47 is entered to perform work on this and other calls.
To summarize, CLAY BILL SET, SET and RYE
commands are generated by the connect action above. This block of commands is sent to ASP 110 as encircled step 12 on link 131 in FIG. 1.
In response to the COLA command, step 4112 of routine COLA (FIG. 41) at ASP 110 obtains the call register address for the assist call to ASP 111 by using the convert station number in item 204 (FIG. 2) of the command block to locate the trunk register. It is recalled that the convert station number is the trunk number on which the call arrived at ASP 110. The trunk register is used to locate the call register. An assist number in item 420~ of the call register points to the correct address in the assist list.
Step 4114 writes the call state vector in the call register to a "disconnect" state. Step 4116 clears the entry in the assist list. Step 411~ loads the trunk register to return control to address C in FIG. 39 after the assist call has been disconnected. Conventional call processing software then disconnects the assist call to ASP 111. This is encircled step 13 on trunk 112 in FIG. 1. When control is returned to address C, the remaining commands are executed.
In response to the BOIL command, step 4004 of routine BOIL in FIG. 40 loads the appropriate items of a billing block with the data included in the BOIL command lZZ~36~i~

(see FIG. 3). Step 4006 sets a billing block activation indicator in the call register for this call. This activator causes the billing block to be copied into an automatic message accounting (AMA) record when a disconnect is detected. Step 4010 in FIG. 40 loads the billing number in the SET command into the billing block in response to the SET command. Steps 4014 and 4016 load the call register and billing block with the destination number from the SET command. In response to the RYE command, step 4020 of routine RYE loads the call state vector in the call register to "dialing complete." Step 4022 loads the trunk register with a trunk state vector to cause the conventional call processing software at ASP 110 to return control to address point D in FIG. 40 after routing the call. RYE then enters the main ASP program where the conventional software routes the call to the destination number placed in the call register. This is encircled step 14 on trunk 113 in FIG. 1. When control is returned to address D, step 4024 transmits a DONE message to NIP 120 to indicate completion of the commands. This is encircled step 15 on link 131 in FIG. 1.
When the DONE message is received from ASP 110, UNLDSTK unloads the top entry for this call and transfers to CONTSEQ in FIG. 55. At this point, the stack contains CONTSEQ entries placed there in connection with sequence nodes 16, 9, 8 and 6. For the first, CONTSEQ entry, step 5512 checks the returned value of REV against the value stored in node 16. Since 0 is the REV returned which is also the value stored in node 16, step 551~ is next executed. This step determines that the last child node of node 16 has been executed and ceases execution of node 15 by transferring to UNLDSTK. The next stack entry returns to CONTSEQ in connection with the execution of node 9.
Since the last child node of node 9 has been executed, CONTSEQ goes to UNLDSTK to process the CONTSEQ entry from node 8. REV is still set to 0 from node 22. The REV value stored in node 8 is 3. Therefore, step 5512 of CONTSEQ

mismatches and terminates node 8 by transferring to UNLDSTK. The CONTSEQ stack entry from sequence node 6 is next processed. The end of call CAM stored in the stack by step 5006 is encountered by UNLDSTK and control is transferred to EON in FIG. 48. Steps 4826 and 4828 determine that this call has been routed to a destination number and performs bookkeeping operations to remove this call from the NIP system.
If we assume that the caller was located on the east coast for discussion purposes, then integer decision node 20 would have been executed. The parameter expression in node 20 of FIG. 36 is an evaluation of the time of the week when a call is originated. Arguments of the expression specify that evaluation of the time of week should be in terms of eastern time zone and daylight savings time. The numbers in the outcome values, such as 1979 for outcome value 1, represent elapsed minutes to the present time, measured from 12 o'clock midnight of the previous Saturday. Thus, the value 1979 in outcome 1 represents one minute before nine arm. on Monday. A range flag is set in node 20. This means that all values of the parameter expression from 1979 up to but not including the next outcome value are to be considered as outcome 1. It will be seen by examining the outcome values of node 20 in FIG. 36 that call originations occurring during the hours of nine to five p.m. will result in the execution of node 21. All other outcomes result in the execution of node 22.
When an end-of-call CAM is encountered in the stack, it is possible that the call has not been routed to a destination. Execution of node 23 would be an example of this in the present example. In such a case, checks must be made to insure that the ASP has or will receive certain commands to properly terminate the call. It is also possible in some circumstances that an assisting ASP is still associated with the call at this time. In this event, steps 4830 and 4832 generate a COLA command to release the assisting ASP. If a BOIL command has already been generated on this call (step 4902), then a FIN command is generated at step 4914 with a prescribed default final treatment such as reorder tone specified by the FIN
command. If a BOIL command has not been priorly generated, step 4904 generates such a command with CUPS (call progress stopped) set to 2 for billing purposes to indicate that the call was not completed.
If the BAR contains a special billing number, 10 steps 4906 and 4908 generate a SET command including the special billing number to insure that call billing is made to this number in accordance with the customer's requirements.
If a Han doff to another ASP was priorly 15 performed, for billing purposes steps 4910 and 4912 generate a SET command to insure that the Han doff ASP has the calling station number, and a SET command to insure that the Han doff ASP has the original dialed customer number.
The commands generated immediately above are always succeeded by a FIN command generated at step 4914 and the block of commands are transmitted to the ASP at step 4916. At this point, NIP operations are complete with respect to this call.
An exception (EXC) that might be received by NIP
120 during control of a call is processed at steps 4726 and 4728. If the EXC message indicates that the failure or abnormality occurring on the call is fatal, meaning that command cannot be executed for some reason, steps 4728 and 4724 remove the call from the NIP system. If the failure or abnormality is nonfatal, then control is given to EON in FIG. 48 to terminate the call in an orderly fashion as described above.
It is to be understood that the above-described arrangement is merely illustrative of the application of the principles of the invention and that other arrangements may be devised by those skilled in the art ~L2X~36~9 without departing from the spirit and scope of the invention.

Claims (24)

Claims

1. A method of controlling the operations of a telephone switching office to provide call processing operations for the disposition of calls directed to telephone customers, comprising the steps of executing different customer-definable programs specific to each of the customers in response to originations of calls to the customers, said programs containing instructions for ascertaining specified parameters of the individual calls and instructions for generating call processing commands according to the specified parameters, and sequentially executing at the office individual ones of a plurality of independent and discrete call processing capabilities specified by the commands, each said capability performing a primitive call processing function inadequate of itself completely to process a call and the aggregate of the capabilities linked by a given customer program on any call being sufficient to completely process the call in accordance with the instructions of the customer program.

2. The invention of claim 1 further comprising a control program responsive to the receipt of an identification of a called customer, for executing the customer program pertaining to the called customer.

3. The invention of claim 2 wherein a customer program comprises decision instructions for controlling the flow through the program in accordance with the state of prescribed call parameters specified by the decision instructions, and action instructions each specifying the performance of at least one of the discrete and independent call processing capabilities.

4. The invention of claim 3 wherein each discrete and independent capability is selected from the following list of process steps:

a) create a billing record for a call;
b) store a billing number in a billing record;
c) perform a specified announcement to a caller;
d) prompt a customer to input information digits and collect the inputted digits;
e) specify a telephone number for call routing;
f) route a call to a specified telephone number, and g) terminate a call to a specified type of final treatment other than routing to a telephone number.

5. The invention of claim 4 wherein a decision instruction comprises an indication of a call parameter to be evaluated, a plurality of possible values of the call parameter to be evaluated, and an associated like plurality of customer program addresses and the method further comprises the steps of executing each instruction in the customer program sequentially beginning with an initial instruction of the customer program until a decision instruction is encountered, in response to the encountering of a decision instruction, evaluating the call parameter indicated by the decision instruction, and directing the flow through the customer program to an instruction whose address is stored in the decision instruction in association with the evaluated value of the call parameter.

6. The invention of claim 5 wherein a first type of call parameter to be evaluated is selected from the following list of parameters:
a) the telephone number of a calling station;
b) the time at which a call is originated; and c) the type of call.

7. The invention of claim 5 wherein a second type of call parameter to be evaluated is selected from one of the following list of call parameters:

a) the geographic location of a calling station:
b) the type of digit signaling used by a calling station:
c) the time zone in which a calling station is located.

8. The invention of claim 5 wherein a third type of call parameter to be evaluated is one or more information digits supplied by a calling station.

9. The invention of claim 7 wherein the step of evaluating one of the second type of call parameters further comprises the step of translating a caller's station number into the value of the indicated call parameter.

10. The invention of claim 9 wherein the translating steps further comprises the step addressing a translation table by a caller's telephone number for each of the second types of call parameters.

11. The invention of claim 1 further comprising the steps of activating a per call memory block for each call origination;
sequentially executing instructions in the appropriate customer program, and maintaining indications of the state of execution of a customer program in the per call memory block for a given call, thereby providing for the control of contemporaneous calls by the same customer program.

12. The invention of claim 1 wherein a telephone system comprises a plurality of call processing offices, a centralized data base, and a data communications network interconnecting the call processing offices and the data base, said method further comprising the steps of transmitting an initial message including a customer's service number from one of the offices to the data base responsive to a call identifying the customer's service number at said one office, activating a customer program identified by the customer service number at the data base in response to the initial message, and transmitting said commands generated by the customer program for specific call processing capabilities to said one call processing office for execution.

13. The invention of claim 12 further comprising the steps of transmitting one or more commands with an indication of the order of execution of plural commands in a single transmittal to the call processing office, and ceasing execution of the customer program until a response to the single transmittal has been received from the call processing office.

14. The invention of claim 13 further comprising the steps of transmitting a first type of command to the call processing office responsive to a first type of instruction in the customer program, and assigning a billing block at the call processing office responsive to the first type of command for the storage of billing information pertaining to the call.

15. The invention of claim 14 further comprising the steps of transmitting to the call processing office a second type of command containing a billing number responsive to a second type of instruction in the customer program, and storing the billing number in the billing block.

16. The invention of claim 13 further comprising the steps of transmitting to the call processing office a first type of command containing a destination telephone number responsive to a first type of instruction in the customer program.

17. The invention of claim 14 further comprising the steps of transmitting to the call processing office a second type of command containing a destination telephone number responsive to a second type of instruction in the customer record, and storing the destination telephone number in the billing block.

18. The invention of claim 13 further comprising the steps of transmitting to the call processing office a first type of command containing an identification of an announcement responsive to a first type of instruction in the customer record, and performing the identified announcement to the calling station.

19. The invention of claim 13 further comprising the steps of transmitting to the call processing office a first type of command containing an identification of a prompting announcement for instructing the inputting of a prescribed number of information digits from the calling station, performing the announcement to the calling station, collecting the information digits from the calling station, and transmitting the collected digits to the data base.

20. The invention of claim 19 further comprising the step of controlling the flow through the customer program in accordance with the value of the information digits inputted from the calling station.

21. The invention of claim 16 further comprising the steps of transmitting to the call processing office a second type of command responsive to a second type of instruction in the customer record, and completing the call to the destination telephone number responsive to the second type of command.

22. The invention of claim 13 further comprising the steps of transmitting to the call processing office a first type of command responsive to a first type of instruction in the customer record, and terminating the call in a manner specified by the first type of command.

23. A method of controlling the processing of telephone calls so as to provide individualized service for each of a plurality of customers, comprising the steps of storing a separate customer program for each of a plurality of customers served by a telephone office, each program comprising a plurality of instructions defining an individualized telephone service for the customer based on selected ones of a prescribed set of defined call parameters set forth in the program instructions, executing the instructions of an appropriate customer program in response to the origination of a call to one of the customers, ascertaining the value of the call parameters specified by the execution of the customer program, generating a sequence of ordered call processing steps required to process the call in accordance with the instructions of the customer program in view of the value of the selected call parameters, and sequentially performing the ordered steps.

24. The invention of claim 23 wherein a customer program comprises decision instructions including identifications of call parameters to be evaluated for controlling the execution path through the program in accordance with the values of the call parameters and action instructions identifying the call processing steps to be performed, and wherein the customer program execution step further comprises the step of sequentially interpreting each instruction encountered in the execution path through the program in real time.