Interaction of Routing Features in a Telephone System

1. Field of the Invention

The invention concerns telephone systems generally and more specifically concerns routing features employed in telephone systems.

2. Description of the Prior Art

In telephony, the term feature is used for a function of the telephone system which goes beyond the ordinary telephone system functions of providing a dial tone in a first telephone, responding to a telephone number dialed in the first telephone by setting up a call to a second telephone specified in the telephone number, returning a busy signal if the second telephone is busy, and otherwise ringing the second telephone and connecting the first and second telephones if the second telephone is answered. The above ordinary telephone system functions are often denoted herein by the acronym POTS (Plain Old Telephone Service).

One general class of features is routing features: the telephone system automatically does something with a call directed to a given telephone other than simply setting up the call to the given telephone. One example of a routing feature is call forwarding: the user of a given telephone specifies another telephone to the telephone system and the telephone system automatically reroutes a call to the given telephone to the other telephone. In telephone parlance, the telephone system automatically reroutes the call from the directory number (DN) of the given telephone to the DN of the other telephone. Another example is call blocking: the user of a given telephone specifies another telephone from which the given telephone is not to receive calls and the telephone system does not set up calls from the other telephone to the given telephone.

Call routing features are both useful and popular; a continuing problem with them, however, has been defining how they interact with each other. For example:

Example 1: Directory number (DN) d.sub.1 is forwarded to DN d.sub.2, and d.sub.2 is forwarded to d.sub.3. Should a call to d.sub.1 be routed to d.sub.2 or d.sub.3 ?

Example 2: d.sub.1 is forwarded to d.sub.2. What happens to calls to d.sub.1 when Do Not Disturb (DND) applies to d.sub.1 and not to d.sub.2 ? When DND applies to d.sub.2 and not to d.sub.1 ?

Example 3: The subscriber of d.sub.1 subscribes to Originating Call Screening (OCS, also known as Outgoing Call Barring and Can Restriction) and has used it to block calls to d.sub.2. His child's friend at d.sub.3 sets up forwarding from d.sub.3 to d.sub.2, and his child calls d.sub.3. Should the call go through?

Example 4: The subscriber of d.sub.1 subscribes to OCS and has used it to block calls to d.sub.2. Calls from d.sub.2 are forwarded to d.sub.3. Should a call from d.sub.1 to d.sub.2 go through?

These and other questions about the interaction of routing features have yet to be answered in any consistent manner. In the absence of answers, the following solutions have been suggested:

1. The open questions about routing behavior can be left open as options, and subscribers can make their own choices. See in this regard Jacques Muller, "Service and service feature interaction: Service creation, service management, and service execution aspects," ETSI/NA6 Working Document, March, 1994. It seems unfair to ask subscribers to understand and answer questions that telecommunications experts cannot.

2. The behavior can be determined by negotiation at the time of call setup. See Nancy Griffeth and Hugo Velthuijsen, "The negotiating agent model for rapid feature development", in: Proceedings of the Eighth International Conference on Software Engineering for Telecommunications Systems and Services, pp. 67-71, Institution of Electrical Engineers, London, 1992. If the negotiating agent is the subscriber, this would seem to add greatly to setup overhead and to the intellectual burden on the subscriber, as well as establishing a number of new covert signalling channels. If the negotiating agent is a program, then this proposal is just a new way of implementing features, and brings no new insight to the question of how features should behave.

3. The behavior can be determined by arbitrary and subjective choices. This is intellectually unsatisfying and the arbitrary and subjective nature of the choices will necessarily complicate system behavior and implementation.

It is an object of the present invention to solve the above and other problems of call routing features by providing call routing features which are defined in such a fashion that detailed questions concerning the behavior of the features and their interactions with other features can be easily and predictably answered.

The solution to the above problems of call routing features is to base the analysis of call routing features on the human situations which motivate the users of the features to purchase and activate them. When this is done, it turns out that the interaction of call routing features depends on whether the feature is one of a class of telephone features or one of a class of subscriber features. In features which belong to the first class, the feature is applied to a telephone number which represents a telephone for purposes of the feature; in those which belong to the second class the feature is applied to a telephone number which represents a subscriber for purposes of the feature.

For example, if a first user expects to be at a different telephone number, and activates a feature to forward his calls to that different telephone number, the first user wants his telephone calls to reach him at that telephone number. The usual user of the telephone number may have activated forwarding features for that telephone number, but these forwarding features are simply not relevant to the call forwarding operation.

The feature which behaves the way the first user wants is a telephone feature which is activated for the first user's usual number and applies to the different telephone number. Here, the different telephone number represents the telephone at which the first user wants to be reached, not the subscriber to whom the different telephone belongs. Because the feature is a telephone feature instead of a subscriber feature, the telephone system forwards calls from the user's usual telephone number to the telephone number to which the feature applies, but does not take the features activated for the different telephone number into account in further forwarding operations for the call.

On the other hand, if a first user simply wants a second user to handle his calls and activates a feature to forward his calls to the telephone normally used by the second user, the first user does not care what telephone number the second user receives the calls at. Consequently, the forwarding features which the second user may have activated for his telephone are relevant to the call forwarding operation.

In this case, the feature which behaves the way the first user wants is a subscriber feature which is activated for the first user's telephone number and applies to the second user's normal telephone number. Here, the second user's telephone number represents the subscriber whom the first user wants to handle the first user's telephone, not the telephone to which the different telephone number belongs. Because the feature is a subscriber feature, the telephone system not only forwards the first user's call to the second user's telephone number, but also forwards it from the second user's telephone number as indicated by the forwarding features activated for that telephone number.

When call routing is implemented according to the above principles, each routing step is performed by determining whether each feature which is relevant to the routing step is a telephone feature or a subscriber feature and determining how to route the call according to how the features are classified.

The call routing features which can be implemented according to the above principles include several varieties of call blocking. A call blocking feature may be a telephone feature or a subscriber feature and how the blocking is done depends upon which class the blocking feature belongs to.

For example, if a user wants a call blocking feature which simply blocks all calls to the user's telephone, the desired blocking feature is a telephone feature which is activated for and applies to the user's telephone. On the other hand, if the user wants a feature which blocks all calls intended for him but permits calls that his housesitter has forwarded to his telephone number from the housesitter's phone by means of a telephone feature, the desired blocking feature is a subscriber feature, i.e., one which blocks all calls except those which were routed in the previous step by a telephone feature.

The foregoing and other objects and advantages of the invention will be apparent to one of ordinary skill in the art who peruses the following Drawing and Detailed Description, wherein:

FIG. 1: FIG. 1 is a first example of call forwarding;

FIG. 2: FIG. 2 is a second example of call forwarding;

FIG. 3: FIG. 3 is a block diagram of the techniques disclosed herein;

FIG. 4: FIG. 4 is a partial diagram of a finite state automaton for call processing;

FIG. 5: FIG. 5 is a tabular representation of a preferred embodiment of call forwarding;

FIG. 6: FIG. 6 is a third example of call forwarding;

FIG. 7: FIG. 7 is a first example of call forwarding with call blocking;

FIG. 8: FIG. 8 is a second example of call forwarding with call blocking; and

FIG. 9: FIG. 9 is a tabular representation of a preferred embodiment of call forwarding with call blocking.

The reference numbers employed in the Drawing and the Detailed Description have three or more digits. The two least significant digits are a number within a figure; the remaining digits are the figure number. Thus, the element with the reference number "305" is first shown in FIG. 3.

The following Detailed Description will first discuss how the principle of designing call routing features from the point of view of the situation of the forwarder when he or she activates the feature can be applied to call forwarding features and then will discuss how it can be applied to call blocking features. Each discussion will begin with an informal description of the novel features and will then provide a formal specification of them in the well-known Z notation described in J. M. Spivey, The Z Notation: A Reference Manual (Second Edition), Prentice-Hall International, 1992.

With the novel call forwarding features, the observation upon which their specification is based is that a user who activates a call forwarding feature (the forwarder) is in one of two situations:

He or she wants to delegate the handling of the forwarded calls to another entity, for example, a colleague, a secretary, or an answering service.

He or she wants the forwarded calls to follow him or her to a different telephone.

From this observation emerge two classes of call forwarding features, delegate call forwarding features, in which the forwarder who activates the feature intends to delegate the handling of the forwarded call, and follow me call forwarding features, in which the forwarder intends to have the calls follow the forwarder to a different telephone. All the usual varieties of call forwarding, for example Call Forwarding Unconditional, Call Forwarding on Busy, and Call Forwarding on No Answer, can be understood as belonging to one or the other of these classes, and an understanding of the two classes leads to new kinds of call forwarding features.

Within the telephone system, both the person and the telephone are represented by telephone numbers and the difference between delegate forwarding and follow me forwarding comes down to whether the telephone number to which the call is to be forwarded (the forwarded to) represents a person or a telephone. In the case of delegate forwarding, the forwarded-to telephone number is a key or pointer to the person who normally receives calls at the forwarded-to telephone number. This person is termed herein the subscriber for the telephone number. In the case of delegate forwarding, the forwarded-to telephone number is a key or pointer to a specific telephone.

A call forwarding feature may thus be described in terms of two telephone numbers: the telephone number for which the feature is activated and the forwarded-to telephone number. In call forwarding features, the forwarded-to telephone number is the telephone number to which the feature applies.

FIGS. 1 and 2 show how the classification of call forwarding features into follow-me and delegate features solves the problem posed in example 1 of the Description of the Prior Art. FIG. 1 shows call forwarding arrangement 101. In the arrangement, delegate forwarding has been activated for telephone 103(1) and applied to telephone 103(2), as indicated by DEL(2). For telephone 103(2), either delegate forwarding (DEL(3)) or follow-me forwarding (FM(3)) has been activated and applied to telephone 103(3). Telephone 103(3) has no call forwarding activated (N.sub.0 F). FIG. 2 shows call forwarding arrangement 201. In the arrangement, follow-me forwarding FM(2) has been activated for telephone 203(1) and applied to telephone 203(2). For telephone 203(2), either delegate forwarding (DEL(3)) or follow-me forwarding (FM(3)) has been activated and applied to telephone 203(3).

In activating delegate forwarding in telephone 103(1) of FIG. 1, the subscriber for telephone 103(1) is indicating that he or she wants the subscriber for telephone 103(2) to take the subscriber's telephone calls; consequently, if the subscriber for telephone 103(2) has activated either follow-me forwarding or delegate forwarding, the call will be forwarded, in this case to telephone 103(3), as shown in the figure.

In activating follow me forwarding in telephone 203(1) of FIG. 2, on the other hand, the subscriber for telephone 203(1) is indicating that he or she wishes to personally take his or her calls at telephone 203(2); consequently, the fact that the subscriber of telephone 203(2) has activated a call forwarding feature is not relevant and telephone 203(2) will not forward the call to 203(3), again as shown in the figure.

Call forwarding which works as shown in FIGS. 1 and 2 can be achieved by maintaining two pieces of information for the call: a directory number which serves as a pointer to a subscriber (the subscriber pointer) and a directory number which serves as a pointer to a telephone (the telephone pointer). As will be explained in more detail below, the call forwarding algorithm updates these pointers in such fashion that at each telephone number (the current telephone number) in the chain of numbers through which the call is being forwarded, the pointers contain the telephone numbers needed to determine what forwarding features are activated for the current telephone number and where relevant for the next step, what forwarding features apply to the current telephone number. The forwarding algorithm then uses this information, together with the current POTS state of the current telephone number, to route the call. For example, if the current telephone number has delegate forwarding activated but has follow-me forwarding applied to it, the forwarding algorithm will ignore the delegate forwarding.

As will also be explained in more detail in the following, call forwarding that works as described above can be implemented by means of a set of recursive functions. Each invocation of a function in the set corresponds to a forwarding of the call to another telephone and the recursion permits a forwarding chain of any length.

FIG. 3 is a schematic representation of a call forwarding system using the principles explained above. Call forwarding system 301 is implemented in call forwarding software 307 executing on a processor in a switch or a customer premises device. In the Figure, data is represented by boxes, with single arrows indicating the flow between the data and the software. Code is represented by an oval, with double arrows indicating invocations of other code components.

Call forwarding software 307 employs three variables: CSUBS 303's value is the subscriber pointer; CTEL 305's value is the telephone pointer; and CTELSTAT 313's value indicates whether the telephone line identified by the current value of CTEL 305 is busy. Data on the features is contained in a features activation data base 311 which has an entry 313 for each telephone number 315 that contains a feature list 317 which indicates what features, if any, are activated for the telephone number 315.

Execution of call forwarding software 307 results in forwarding outcome 309. Software 307 has two main components: subscriber function (SUBSFUNC) 319, which does call forwarding for features applied to subscribers, and telephone function (TELFUNC) 321, which does call forwarding for features applied to telephones. As shown by the single arrows, both function 319 and 321 read feature data base 311 and read and write CSUBS 303; additionally, function 319 writes CTEL 305, which is read by function 321. Function 321 also reads CTELSTAT 313. As shown by the double arrows, function 319 recursively invokes itself (arrow 323) and also invokes function 321 (arrow 325), while function 321 invokes function 319 (arrow 327).

When a call is made to any telephone, subscriber function 319 is invoked for that telephone number; if that telephone number has a forwarding feature active, subscriber function 319 invokes itself recursively or invokes telephone function 321. Which is invoked depends on whether the forwarding feature applies to the telephone or the subscriber. Both invocations are made using the forwarded-to telephone number and the invocation is executed for that telephone number. Thus, if a number of telephone numbers are chained by call forwarding from one number to the next, there is a sequence of invocations of function 319 or 321, with each invocation corresponding to one forwarding step.

For example, in call forwarding arrangement 101, the call to telephone 103(1) invokes subscriber function 319 for that telephone's telephone number 1; CSUBS 303 is set to 1. Subscriber function 319 uses CSUBS 303 in feature data base 311 and determines that telephone number 1 has delegate forwarding to telephone 103(2) active. This type of forwarding is applied to subscribers, so subscriber function 319 recursively invokes itself with the telephone number 2. For this invocation, CSUBS 303 has that value. Continuing on the assumption that telephone 103(2) has a follow-me forwarding feature active which specifies telephone 103(3) as the forwarded-to telephone, that feature is applied to telephones, so subscriber function 319 invokes telephone function 321. In that invocation, CSUBS 303 has the value 3, which is the number of telephone 103(3), while CTEL 305 is set to the value 2, which is the number of telephone 103(2). As will be explained in more detail later, the result of this invocation, and thus forwarding outcome 309, is that telephone 103(3) is alerted.

In terms of actual implementation, when call forwarding software 307 is implemented in a system in which switches have access to a data base which indicates the kind of call forwarding feature (if any) which is currently associated with a given telephone number, call forwarding software 307 can use the current values of CSUBS 303 and CTEL 305 to query the data base and determine what call forwarding features are activated for the values of the variables.

In a more distributed environment, i.e., where the information about the telephone numbers and their associated call forwarding features is distributed throughout the telephone system, the device from which the call is being forwarded must send a message to the device to which the call is being forwarded which includes the kinds of call forwarding features currently associated with the device's telephone number. The device to which the call is being forwarded can then use the message, the kinds of call forwarding features which it itself currently has, and its own state to determine how to handle the forwarded call.

The starting point for the following discussion of call forwarding which is based on the situation for which the user activated call forwarding is finite state automaton 401 shown in FIG. 4. Automaton 401 shows some of the states, external events, and state transitions involved in call processing.

Although FIG. 4 is incomplete in many respects, it does include all out-transitions from the three large states, dialed 403, alerting 405, and timed.sub.-- out 407. These states are what their names imply: in dialed, a telephone number (DN) has been dialed; in alerting, the telephone at the dialed number is alerting the user (e.g., the telephone is ringing); in timed-out, the user at the dialed telephone number has not responded within a set period of time. The smaller states are also what their names imply; in "blocked" 409, calls to the dialed telephone number have been blocked; in "busy" 411, the dialed telephone number is busy; in "abandoned" 413, the call has been abandoned by either of the parties or the system; and in "connected" 415, a connection has been established between the dialing telephone and the dialed telephone.

The arrows connecting the states indicate transitions between them. The dashed arrows 421 represent state transitions stimulated by computation in a switching system, while the solid arrows 417, 419, and 420 represent state transitions stimulated by external events. The external events include an abandon event 417, which occurs when either the caller, the callee, or the telephone system abandons the call, a timeout event 420, which occurs when a timer which controls the maximum length of time that the called number is in the alerting state runs out, and an answer event 419, which occurs when the user of the called telephone answers the telephone.

Which telephone numbers are placed in the states of FIG. 4 is determined by four relevant state variables, each of which represents a telephone number (DN): origin, dialed, tel, and subs.

origin contains the DN of the caller;

dialed contains the DN dialed by the caller;

Whenever the value of tel is defined, it is the DN whose telephone is the current target of routing; and

Whenever the value of subs is defined, it is the DN whose subscriber is the current target of routing.

The first two values are defined by the call to which the routing function is being applied; they thus always exist and remain unchanged throughout the routing process. tel and subs are set and updated by subscriber function 319 and telephone function 321, and their values will thus depend on the stage of the routing process and the kinds of forwarding which have been applied to the call.

Transitions from dialed 403 are described by a function defined as

and transitions from timed-out 407 are described by a function defined as

Both of these are total functions from their arguments to value triples. The last two components of each value triple must be DNs and the first component must be a call state, where call-state denotes the enumerated type

Using these functions, we can describe what the system does in the dialed, alerting, and timed-out states, as follows.

In dialed state: Execute this pseudocode.

In alerting state: Alert the telephone whose DN is in tel. Transition to the next state is strictly based on external events, as shown in FIG. 1.

In timed-out state: Execute this pseudocode.

Finite state automata such as automaton 401 are particularly adapted to describing the temporal aspects of call processing. However, most of the complexity of routing is nontemporal--it concerns static data and relationships. It is easier to understand routing features if their specification is separated from the temporal aspects of call processing and uses a syntax that is appropriate for managing static complexity. Accordingly, the following formal specification of call forwarding uses a form suitable for routing features.

The specification of call processing in automaton 401 and the following specification of call forwarding are both partial-neither one is complete in itself. The two partial specifications can be composed formally using multiparadigm specification techniques, as explained in Pamela Zave and Michael Jackson, "Conjunction as composition" ACM Transactions on Software Engineering and Methodology II (4):379-411, October 1993. For present purposes, however, an informal description of how the two specifications fit together will be sufficient.

The formal specification of call forwarding which follows is written in Z. The first step in specifying call forwarding is to set forth in Z which features apply to which telephone numbers. The features are the following:

POTS: plain old telephone service, which every telephone number has;

Del: unconditional delegate forwarding: all calls to the telephone number having the feature will be delegate forwarded;

FM: unconditional follow-me forwarding: all calls to the telephone number having the feature will be follow-me forwarded;

DelB: delegate on busy forwarding: calls to the telephone number having the feature will be delegate forwarded when the telephone number is busy;

DelNA: delegate on no answer forwarding: calls to the telephone number having the feature will be delegate forwarded when there is no answer; and

FMNA: follow-me on no answer forwarding: calls to the telephone number having the feature will be follow-me forwarded when there is no answer.

The foregoing is expressed in Z as follows:

›DN, telephone!

POTS: DN.fwdarw.telephone

Del: DNDN

FM: DNDN

DelB: DNDN

DelNA: DNDN

FMNA: DNDN

The first line says that DN and telephone are primitive types of the specification. POTS, Del, FM, DelB, DelNA, and FMNA are all binary relations, or, in other words, sets of ordered pairs. The two different arrow symbols denote different constraints on these sets: a plain arrow is a total function, and a crossed arrow is a partial function. dom R denotes the domain of relation R. Thus (d.sub.1,d.sub.2).di-elect cons.R if and only if the ordered pair (d.sub.1,d.sub.2) is a member of the relation R, and its membership implies that d.sub.1 .di-elect cons.dom R. For example, in POTS, all telephone numbers specify a telephone, while in unconditional delegate forwarding, only those telephone numbers which belong to the unconditional delegate forwarding domain specify another telephone number to which the call is to be unconditionally delegate forwarded.

If (d.sub.1,d.sub.2) is a member of some forwarding relation R.sub.f, then d.sub.1 is forwarded to d.sub.2 by means of the feature corresponding to R.sub.f. The fact that R.sub.f is a function means that a DN d.sub.1 can only be forwarded to one DN at a time by means of that feature. The fact that R.sub.f is a partial function means that a DN d.sub.1 need not be forwarded; only those DNs in the domain of R.sub.f are being forwarded by means of that feature. As an extreme case of this, if a forwarding feature is not being offered to subscribers, then its corresponding relation is always empty.

The content of these relations changes over time, as a result of provisioning operations and control commands from telephones. There are only two restrictions on the updating of these relations: (1) Queries and updates must be synchronized in the usual way, so that they appear atomic and are actually serializable. (2) Integrity constraints on the relations must be preserved at all times.

There are relatively few integrity constraints in this specification. The functional nature of functional relations must be preserved. Also, the following constraint prevents a subscriber from forwarding calls to himself. The first line defines an aggregate relation, while the second line says that it must contain no pairs from the identity relation on DNs.

Another integrity constraint will be mentioned when it becomes relevant.

The call forwarding specification requires four functions. Two of these are the dialing-outcome and timeout-outcome functions defined above. As employed in this specification, those two functions use the other two functions: The other two functions are:

subscriber-outcome is an implementation of subscriber function 319 and telephone-outcome is an implementation of telephone function 321. The definitions of subscriber-outcome and telephone-outcome use themselves and each other in a highly recursive manner.

The definition of dialing-outcome in this specification is simply:

The definitions of the other three functions have several cases, so they are presented in tables 501, 503 and 505 of FIG. 5. These tables make case analysis more readable. They are not part of Z, but can be translated automatically into Z, and so can be regarded as a shorthand.

The top row of each table supplies names for all the formal parameters of the function, both incoming and outgoing. Each subsequent row of the table covers another numbered case, the second column giving the condition under which the case applies, and the third column giving the value of the function in that case. The cases in each table are meant to be read from top to bottom. Thus each condition should be understood as including, implicitly, the negations of all previous conditions in the table. The order of the conditions in the table therefore also determines priorities among call forwarding features when more than one feature is activated for a telephone number. For instance, if both unconditional delegate forwarding and unconditional follow-me forwarding are activated, table 501 says that the call will be forwarded according to unconditional delegate forwarding, since case 1 will be true and will be executed, and that will preclude the execution of case 2.

The following line of Z means that Busy is specified as a set of telephones :

At any time, the set Busy contains all the telephones that are currently busy. (This is typical of the Z specification style.)

Each recursive evaluation of subscriber-outcome or telephone-outcome in the tables of FIG. 5 corresponds to a forwarding step, and the argument substitutions have the effect of updating the routing destination at each step. It is important to note, however, that the function definitions maintain two separate routing destinations, the telephone being routed to (tel) and the subscriber being routed to (subs). Follow-me forwarding distinguishes these two, so manipulating them separately is the only way to do follow-me forwarding correctly.

Every time a version of delegate forwarding is applied, the function subscriber-outcome is evaluated with the DN of the newly delegated subscriber as its argument. This function checks for further unconditional delegate or follow-me forwarding.

Whenever routing reaches a phase in which the status of a particular telephone is relevant, the function telephone-outcome is evaluated with the current telephone destination and subscriber destination as its arguments. This function checks the telephone for unavailability. If available then the telephone will be alerted; if no-answer forwarding could apply then the alerting must be quick.

timeout-outcome is only evaluated after quick alerting and a timeout. Because of this history, it would be reasonable to assume that Cases 1 and 2 of Table 505 are exhaustive. However, it is important to realize that the same atomic queries of the relations DelNA and FMNA before and after quick alerting might conceivably yield different results, because the relations might have changed during that interval of time| This situation will be rare, but formal specifications cannot ignore any possibilities. Case 3 in Table 505 takes care of it.

We might impose on the forwarding relations the following integrity constraint:

This constraint in Z says that it is impossible, beginning with a DN and transforming it successively by means of delegation steps, to get back to the original DN.

The examples of FIGS. 1 and 2 can serve to show how the tables of FIG. 5 work. Beginning with FIG. 1, the telephone system receives a call for telephone 1 103(1), which has delegate forwarding to telephone 2 103(2). The call was initiated using dialing-outcome(1), i.e., dialed's value is the telephone number of telephone 1. The telephone system responds by invoking the function subscriber-outcome(1). Table 501 is the table for that function. What happens depends on the domain of the value of (old-subs), which is the function's formal parameter. in this case, (old-subs) is equal to 1. We know from FIG. 1 that phone number 1 has unconditional delegate forwarding activated, so case 1 applies. In that case, subscriber-outcome(2) is invoked, since 2 is the telephone number to which the unconditional delegate forwarding is to forward the call. As a result of the invocation, the call is forwarded to telephone 2.

We will first presume that telephone 2 has unconditional delegate forwarding. Thus, old-subs belongs to the domain of delegate forwarding and case 1 of table 501 applies. Accordingly, the call is forwarded to telephone 3 103(3), using subscriber-outcome(3). Telephone 3 has no call forwarding, so for that telephone, case 3 of subscriber-outcome holds. In that case, telephone-outcome(3,3) is executed. Table 503 shows the various possibilities. In this execution, old-subs has no call forwarding feature associated with it and telephone 3 is not busy. Consequently, the only case which applies is case 5 and the telephone system places telephone 3 in the alerting state.

Now we will presume that telephone 2 has unconditional follow-me forwarding to telephone 3. This time, old-subs belongs to the domain of follow-me forwarding and the call is forwarded to telephone 3 by means of an execution of telephone-outcome(3,2). Again, the only case of table 503 which applies is case 5 and the telephone system places telephone 3 in the alerting state.

FIG. 6 provides an example of a more complicated situation. In call forwarding arrangement 601, telephone 603(1) has follow me forwarding (FM(2)) activated to telephone 603(2) and delegate-busy forwarding (Del B(3)) activated to telephone 3. Telephone 603(2) is busy. The forwarding begins with the invocation subscriber-outcome(1), old-subs equals 1, which belongs to the FM domain, so case 2 of table 501 is executed. That results in the invocation telephone-outcome(2,1), since telephone 2 is specified as the target for follow-me forwarding. With this invocation, old-tel equals 2 and old-subs equals 1, which also belongs to the DelB domain. An attempt to route to telephone 603(2) is represented by dashed line 605. Since telephone 2 is busy, the conditions of case 1 of table 503 are satisfied. The invocation subscriber-outcome(3) results. With this invocation, old-subs is equal to 3 and belongs neither to the Del domain nor to the FM domain, so case 3 of table 501 is executed, resulting in the invocation telephone-outcome(3,3). Telephone number 3 is not busy and has no call forwarding features activated, so it case 5 of table 503 is satisfied and the phone call is transferred to telephone 603(3) as shown by line 607.

Analysis like that used above to simplify and rationalize call forwarding features can also be applied to call blocking features. These features are routing features that prevent the completion of calls when they are considered undesirable by one of the people involved. An example of a call blocking feature is one which when activated bars users of a telephone from making calls to certain other telephone numbers. Call blocking features and their interactions with call forwarding features become understandable when the call blocking features are analyzed from the point of view of whether the person who activates the feature intends it to block calls to a given subscriber or to a given telephone.

The following table provides a representative sample of call blocking features. All of the features in the table will be specified formally below.

Each of the above blocking feature can be defined in terms of a relation recording which DNs it applies to. In Z the relations are declared as follows:

OCS: DN.rarw..fwdarw.DN

TCS: DN.rarw..fwdarw.DN

DNR: DN

VP: DN

CNDB: DN

ACR: DN

A double-headed arrow indicates an unconstrained binary relation. If (d.sub.1,d.sub.2) is a member of some call screening relation R.sub.s, then calls from d.sub.1 to d.sub.2 are prohibited by means of the feature corresponding to R.sub.s. For example, if OCS is activated for a given telephone number d.sub.1, there will be a pair (d.sub.1,d.sub.i) for each d.sub.i to which outgoing calls from d.sub.1 are prohibited.

DN indicates a unary relation, that is, a set of DNs. Thus, DNR, VP, CNDB, and ACR are all unary relations or sets of DNs. If a DN d is a member of one of these sets, then the corresponding feature applies to d. Thus, a telephone whose number belongs to the set of telephone numbers for DNR should not be alerted.

The formal specification of blocking relies on three aggregate relations, defined as follows:

(DN.times.DNR) is a binary relation containing all ordered pairs of DNs in which the first element belongs to DN and the second element belongs to DNR. (CNDB.times.ACR) is a binary relation containing all ordered pairs of DNs in which the first element belongs to CNDB and the second element belongs to ACR.

Block-Telephone contains all pairs (d.sub.1,d.sub.2) such that a call from d.sub.1 should be blocked if it is routed to the telephone of d.sub.2. Block-Subscriber contains all pairs (d.sub.1,d.sub.2) such that a call from d.sub.1 should be blocked if it is routed to the subscriber of d.sub.2. Block-Route-Through contains all pairs (d.sub.1,d.sub.2) such that a call from d.sub.1 should be blocked if the telephone or subscriber of d.sub.2 appears anywhere in its routing path. If a pair (d.sub.1,d.sub.2) is in Block-Route-Through, then its presence or absence in Block-Telephone has no effect, because any call blocked by the presence of the pair in Block-Telephone or Block-Subscriber is also blocked by its presence in Block-Route-Through

FIG. 7 shows how the Block-Telephone, Block-Subscriber and Block-Route-Through aggregate relations can be used to solve example 2 of the Description of the Prior Art, in which a customer has activated both call forwarding and do not ring. In call routing arrangement 701 of FIG. 7, telephone 703(1) has an unconditional delegate feature activated which forwards calls to telephone 703(2) and also has DNR activated. In the case of DNR, the feature also applies to telephone 703(1). In the call to telephone 703(1), the originating number and the number of telephone 703(1) form a pair that belongs to (DN.times.DNR), which in turn belongs to Block-Telephone. However, the unconditional delegate feature is a subscriber feature, not a telephone feature, and so the call to telephone 703(1) will not ring telephone 703(1), but will be forwarded to telephone 703(2).

FIG. 8 shows how Block-Telephone, Block-Subscriber, and Block-Route-Through can be used to solve example 3 of the Description of the Prior Art, in which a customer has activated outward call screening, the customer's child has a friend activate call forwarding from the friend's telephone to one of the forbidden telephone numbers, and the child then calls the friend's telephone. In routing arrangement 801, telephone 803(1) has OCS screening which applies to telephone 803(2) and so forbids calls to telephone 803(2). For this reason, the pair (1,2) belongs to the relation OCS. In telephone 803(3), unconditional delegate forwarding to telephone 2 has been activated. Since the call to telephone 3 comes from telephone 1 and forwarding it to telephone 2 would establish a connection between the pair (1,2), the telephone system does not forward the call.

The problem posed in Example 2 of the Description of the Prior Art is properly solved if it is understood that DNR is a telephone feature, not a subscriber feature. That being the case, Block-Telephone contains (DN.times.DNR), which is a binary relation containing all ordered pairs of DNs in which the second element belongs to DNR. Thus, any call which is made or forwarded to a telephone number for which DNR has been activated will be blocked.

The VP feature is new. It is a subscriber feature, not a telephone feature. (DN.times.VP) is therefore part of Block-Subscriber rather than Block-Telephone. When VP is activated for a telephone number the feature applies to the telephone number. Calls to the telephone will therefore be blocked if they are directed to the subscriber, but will not be blocked if they are directed to the telephone. VP might be used by a person who is going on vacation and does not want to return to a huge accumulation of messages. If VP applies to his DN, then no calls routed to him as a subscriber (for example, via delegate forwarding) will be connected. At the same time, his housesitter will receive calls at his telephone which have been routed from the housesitter's own telephone number by follow-me forwarding activated at that number.

Block-Telephone also contains (CNDB.times.ACR), which is a binary relation containing all ordered pairs of DNs in which the first element belongs to CNDB and the second element belongs to ACR. This ensures that anonymous calls to DNs to which ACR applies will be blocked. The relation is part of Block-Telephone because both the ACR feature and the Calling Number Delivery (CND) features are necessarily applied to particular telephones. It makes no sense to subscribe to CND if you do not own a telephone capable of displaying the caller identification, and it makes no sense to subscribe to ACR if you do not subscribe to CND.

The key to implementing blocking based on the relations in Block-Telephone and Block-Subscriber is again the tel and subs DNs. As employed in call forwarding, these variables are updated at every routing step and thus always indicate which telephone numbers are currently filling the roles of destination telephone and destination subscriber, respectively. By using that information, it is possible to specify blocking features that are, like the forwarding features, tailored precisely to meet human needs.

It is in fact possible to implement the call blocking features described above by simply adding lines to tables 501 and tables 503 of FIG. 5. The new tables are shown in FIG. 9. Table 901 is table 501 with new cases 905 and 907 added 1 to handle call blocking in the context of the subscriber-outcome function. Similarly, table 903 is table 503 with new cases 909 and 911 added to handle call blocking in the context of the telephone-outcome function.

When a call is processed in arrangement 701 of FIG. 7 according to the tables of FIG. 9, processing proceeds as follows: The call to telephone 703(1) sets the origin variable to the telephone number n of the telephone used to call telephone 1 and results in the invocation subscriber-outcome(1). In the execution of subscriber-outcome(1), the relevant case in table 901 is 2, so the result is the recursive invocation subscriber-outcome(2), which forwards the call to telephone 703(2). In the execution of that invocation, no features are activated, so case 5 of table 901 applies, which in turn resolves to case 7 of table 903, in which telephone 703(2) is alerted.

Processing the call in arrangement 801 of FIG. 8 according to the tables of FIG. 9 proceeds as follows: the call from telephone 803(1) to telephone 803(3) sets the origin variable to 1 and results in the invocation subscriber-outcome(3). Since telephone 803(3) has unconditional delegate call forwarding to telephone 803(2) activated, case 2 of table 901 applies and the result is the invocation subscriber-outcome(2). In the execution of this invocation, the pair (origin, old.sub.-- subs) has the value (1,2) and because OCS was activated for telephone 803(1) and applied to the number of telephone 803(2), the pair belongs to Block-Route-Through, case 1 of table 901 applies, and the call is blocked.

It should be noted here that because the tables define their blocking conditions in terms of the aggregate blocking relations Block-Route-Through, Block-Subscriber,, and Block-Telephone, the specification is more extensible than it would be if the tables used the feature relations directly. When a new blocking feature is proposed, there is a good chance that it can be added by modifying the aggregate relations alone, without touching the tables.

To implement routing in finite state automata for call processing like automaton 401 of FIG. 4, one need simply embed evaluations of the routing functions in the transitions of the finite-state automaton for call processing. The feature relations are used by the routing view and updated as required for provisioning and management of subscriber data. The routing functions update the variables tel and subs and the variables can be used by feature specifications that need to know which DNs are playing the roles of destination telephone and destination subscriber.

For example, in the case of a collect call, the destination subscriber--not destination telephone--should be billed. If a subscriber receives a call at someone else's telephone by means of follow-me forwarding, and accepts the charges, it seems only fair to bill the responsible subscriber rather than his helpless host. In the case of automatic retry (of a call to a busy telephone), the destination telephone should be monitored and retried, because that is the telephone whose busy state invoked the feature.

The foregoing Detailed Description has disclosed to those skilled in telephony a new technique for analyzing call routing features from the point of view of the situation of the person activating the feature and has disclosed results of such analysis including

A new class of follow-me call forwarding features which includes the unconditional follow me feature and the follow me no answer feature;

A new class of call blocking features which block calls to subscribers, including the vacation protection feature; and

An improved understanding of the manner in which call routing features ought to interact.

The Detailed Description has also disclosed the best mode known to the inventor of implementing call forwarding based on situational analysis. Features of the implementation include

The use of the telephone number originating the call, the telephone number representing the subscriber who is the current target of the routing, and the telephone number representing the telephone which is the current target of the routing to control the routing computation;

The use of a first subscriber function to perform routing when the feature is one which is applied to a subscriber and a second telephone function to perform routing when the feature is one which is applied to a telephone; and

The use of recursive invocations of the subscriber function and the telephone function to compute routing, with each invocation of one of the functions being the next step in a chain of forwarded calls.

As pointed out in the Specification, the kind of analysis disclosed herein can be used to develop new features whose behavior is governed by the concepts disclosed herein. Moreover, it will be apparent to those skilled in telephony that other versions of the disclosed features are possible and that many other implementations of the disclosed features are possible.

That being the case, the Derailed Description is to be regarded as being in all respects exemplary but not restrictive and the scope of the invention is not to be determined from the Detailed Description but rather from the appended claims as interpreted with the full breadth permitted by the patent laws.