Language selection

Search

Patent 2190888 Summary

Third-party information liability

Some of the information on this Web page has been provided by external sources. The Government of Canada is not responsible for the accuracy, reliability or currency of the information supplied by external sources. Users wishing to rely upon this information should consult directly with the source of the information. Content provided by external sources is not subject to official languages, privacy and accessibility requirements.

Claims and Abstract availability

Any discrepancies in the text and image of the Claims and Abstract are due to differing posting times. Text of the Claims and Abstract are posted:

  • At the time the application is open to public inspection;
  • At the time of issue of the patent (grant).
(12) Patent: (11) CA 2190888
(54) English Title: SYSTEMS AND PROCESSES FOR SPECIFYING CUSTOMIZED TELECOMMUNICATION SERVICES
(54) French Title: SYSTEMES ET METHODES POUR ETABLIR DES SERVICES DE TELECOMMUNICATION PERSONNALISES
Status: Deemed expired
Bibliographic Data
(51) International Patent Classification (IPC):
  • H04M 3/42 (2006.01)
  • H04Q 3/545 (2006.01)
(72) Inventors :
  • BABSON, DAVID LEVEAU, III (United States of America)
  • BAJZATH, JAMES ANDREW (United States of America)
  • ELY, THOMAS CHAMBERS (United States of America)
(73) Owners :
  • TTI INVENTIONS B LLC (United States of America)
(71) Applicants :
  • BELL COMMUNICATIONS RESEARCH, INC. (United States of America)
(74) Agent: KIRBY EADES GALE BAKER
(74) Associate agent:
(45) Issued: 1999-06-15
(22) Filed Date: 1991-12-16
(41) Open to Public Inspection: 1992-06-19
Examination requested: 1996-11-21
Availability of licence: N/A
(25) Language of filing: English

Patent Cooperation Treaty (PCT): No

(30) Application Priority Data:
Application No. Country/Territory Date
629,373 United States of America 1990-12-18
629,389 United States of America 1990-12-18
629,371 United States of America 1990-12-18
629,447 United States of America 1990-12-18
629,390 United States of America 1990-12-18

Abstracts

English Abstract




A method for validating a procedure for providing
customized services to a customer of a telephone network, the
procedure being embodied in a data structure having data and
instructions executable by a data processor. The method
includes: converting the procedure in the data structure into
a schema for evaluation by an expert system, the step of
converting including the substep of extracting the
instructions and data for the procedure from the data
structure; inputting the schema for evaluation into the
expert system for testing the extracted procedure
instructions and data against a set of rules indicating
proper use of the instructions; identifying by the expert
system invalid ones of the instructions and data that violate
the set of rules; and finally placing an indicator by the
expert system in the data structure for the specific invalid
instructions and data.


Claims

Note: Claims are shown in the official language in which they were submitted.


-61-

Claims:
1. A method for validating a procedure for providing
customized services to a customer of a telephone network, the
procedure being embodied in a data structure having data and
instructions executable by a data processor, the method
comprising the steps, executed by a data processor, of:
converting the procedure in the data structure into
a schema for evaluation by an expert system, the step of
converting including the substep of
extracting the instructions and data for the
procedure from the data structure;
inputting said schema for evaluation into the
expert system for testing the extracted procedure
instructions and data against a set of rules indicating
proper use of the instructions;
identifying by said expert system invalid ones of
the instructions and data which violate the set of rules;
and
placing an indicator by said expert system in the
data structure for the specific invalid instructions and
data.

Description

Note: Descriptions are shown in the official language in which they were submitted.


2190888

Systems and Processes for Specifying Customized
Telecommunication Services

This is a division of copending Canadian
Patent Application Serial No. 2,098,608, filed on June 16,
5 1993, based on PCT/US91/09457 filed December 16, 1991.

Background of the Invention

The present invention relates generally to
the field of providing customized services, and more
specifically to the problem of providing customized telephone
0 services.
Implementing new telephone services has long
been a problem for telephone companies. In today's advanced
intelligent network ("AIN"), when a new service such as call
waiting is developed, the economics of developing and
15 implementing that service require that the service be
provided on a mass scale to as many customers as possible.
Often times, even if a service is desired by some customers,

- 2190888
-- 2


the service may never be implemented if that service cannct
be mass marketed, or otherwise economically justified.
Telephone functions are presently provided to a
customer by allowing that customer to select desired
functions from a limited number of available services. This
approach, which has been called programming a service, may
leave many customers without desired functionality. For
example, a customer who wants call waiting, but in a form
slightly different from what is made generally available, may
be told that his simple requests cannot be met.
Moreover, adding a new service to existing services
creates significant problems due to possible interaction
between the new and existing services. This creates
additional obstacles to implementing new telephone services.
For example, it is very possible that adding a new service,
such as call waiting, may be incompatible in certain
circumstances with an existing service, ~uch as call transfer
on busy. The usual solution to such interaction problems is
to prevent both services from being used by the customer
simultaneously. This, of course, limits the power of the new
service.
Even-when services are compatible, the conventional
approach to providing customer services often forces a
customer desiring a few limited features of several services
to subscribe to several complete services. This is both
costly and inefficient.
PCT International Application Number PCT/U.S. 84/01610
teaches a method for defining an individual service for an
individual customer. In that method, a telephone service is
performed by a customer program which a customer defines
using conventional program sequences. The program may be
executed on the customer's host computer external to the
telephone network when a call is proces~ed. Although this
method permits a new individual customer service to be
configured without modifying the telephone network switching
system software, the applic~bility of such a method is
extremely limited. For example, this method cannot implement

21gO888

-- 3


a new service on a network wide basis because each service is
specific to the customer who designed it. This method also
requires every customer who uses the service to have an
S individual host computer external to the telephone system.
Furthermore, designing a service requires a computer
programmer to write program sequences to define the service,
and a programer must make changes to the program sequences to
modify the service.
Although the attempt at customization in PCT/U.S. 84/
0160 is laudable, it highlights the problems which designers
have faced in attempting to leave the conventional philosophy
of programming a service. One problem is the hardware
limitations. The software for developing a customized
service for each user must be able to be used on different
platforms so that the capability of designing services, as
well as testing them, can be made available to as many users
as possible.
In addition, the design of services cannot require
standard programming because the cost and difficulty of
providing such customization will make it too expensive to
employ.
Accordingly, it is desirable to have a system capable
of providing multi-function, single services that can be
implemented and used economically.
Another desirable feature for such a system would be a
mech~nism for designing multi-function, single services
easily and without need for knowledge of the underlying sys-
tem.
Yet another desirable feature would be easy
transportability of the system, or of parts of the system, to
other machines or deviceq.
Additional desires of the invention will be ~et forth
in the description which follows, and in part will be
apparent from the description, or may be learned by practice
of the invention. The advantages of the invention may be
realized and obtained by means of the instrumentalities and
combinations particularly pointed out in the appended claims.

2190888



Disclosure of the Invention

To achieve the foregoing desires, and in accordance with
the purposes of the invention as embodied and broadly
described herein, this invention provides a system which has
5 different levels which provide different functions.
In accordance with one aspect of the invention there is
provided a method for validating a procedure for providing
customized services to a customer of a telephone network, the
procedure being embodied in a data structure having data and
10 instructions executable by a data processor, the method
comprising the steps, executed by a data processor, of:
converting the procedure in the data structure into a schema
for evaluation by an expert system, the step of converting
including the substep of extracting the instructions and data
15 for the procedure from the data structure; inputting said
schema for evaluation into the expert system for testing the
extracted procedure instructions and data against a set of
rules indicating proper use of the instructions; identifying
by said expert system invalid ones of the instructions and
20 data which violate the set of rules; and placing an
indicator by said expert system in the data structure for the
specific invalid instructions and data.

Brief Description of the Drawinqs

The accompanying drawings, which are incorporated in and
25 constitute a part of the specification, illustrate presently
preferred implementations of this invention and,
together with the general description given above and the
detailed description of the preferred implementations given
below, serve to explain the principles of the invention.
The present invention taken in conjunction with the
invention disclosed in copending Canadian Patent Application
Serial No. 2,098,608 filed on June 16, 1993, based on
PCT/US91/09457 filed December 16, 1991, will be described

2190888



hereinbelow with the aid of the accompanying drawings in
which:
Fig. 1 is an example of "graph" customer interface;
Fig. 2 is an example of a "form" customer interface;
Fig. 3 is a functional block diagram of the advanced
intelligent network;
Fig. 4A is a functional block diagram of a service
management system in accordance with one embodiment of the
present invention;
Fig. 4B is a functional block diagram of a service
control point in accordance with one embodiment of the
present invention;
Fig. 4C is a functional block diagram of a service
control point in accordance with another embodiment of the
15 present invention;
Fig. 4D is a functional block diagram of a personal
computer in accordance with one embodiment of the present
invention;
Fig. 5 is a schematic representation of three software
20 levels corresponding to three representations of services in
accordance with one embodiment of the present invention;
Fig. 6A is a schematic representation of program modules
corresponding to an internal data structure of services in
accordance with one embodiment of the present invention;
Fig. 6B is a schematic representation of program modules
corresponding to a binary representation of services in
accordance with one embodiment of the present invention;
Fig. 6C is a schematic representation of program modules
corresponding to a displayed representation of services in
30 "graph" form in accordance with one embodiment of the present
invention;
Fig. 6D is a schematic representation of program modules
corresponding to a displayed representation of

2190888

-- 6


services in form form in accordance with one embodiment of
the present invention;
Fig. 7 illustrates a MAIN operator interface window in
accordance with one embodiment of the present invention;
Fig. 8 illustrates a MAIN operator interface window, as
well as the options for the MAIN menu selection in accordance
with one embodiment of the present invention;
Fig. 9 illustrates a system variables dialog box in
accordance with one embodiment of the present invention;
Fig. l0 illustrates a Tcap messages dialog box in
accordance with one embodiment of the present invention;
Fig. ll illustrates a MAIN operator interface window,
as well as the options for the DATABASE menu selection in
accordance with one embodiment of the present invention;
Fig. 12 illustrates a MAIN operator interface window,
as well as the options for the TEMPLATE menu selection in
accordance with one embodiment of the present invention;
Fig. 13 illustrate~ a MAIN operator interface window,
as well as the options for the OPTIONS menu selection in
accordance with one embodiment of the present invention;
Fig. 14 illustratec a MAIN operator interface window,
as well as the options for the LIBRARY menu selection in
accordance with one embodiment of the present invention;
Fig. 15 illustrates a graph edit pad interface window
in accordance with one embodiment of the present invention;
Fig. 16 illu~trate~ a graph edit pad interface window,
as well as the options corresponding to the GRAPH menu
selection in accordance with one embodiment of the present
invention;
Fig. 17 illustrates an Open New graph dialog box in
accordance with one embodiment of the present invention;
Fig. 18 illustrates an Open graph dialog box in
accordance with one embodiment of the present invention;
Fig. l9 illustrates a Save As dialog box in accordance
with one embodiment of the present invention;
Fig. 20 illuQtrates a Warning dialog box in accordance
with one embodiment of the pre~ent invention;

2190888

-- 7


Fig. 21 illustrates an Add Node dialog box in
accordance with one embodiment of the present invention;
Fig. 22 illustrates an Enter LATA dialog box in
S accordance with one embodiment of the present invention;
Fig. 23 illustrates an Edit Carrier dialog box in
accordance with one embodiment of the present invention;
Fig. 24 illustrates a graph edit pad interface window,
as well as the options corresponding to the EDIT menu
selection in accordance with one embodiment of the present
invention;
Fig. 25 illustrates the graph edit pad interface
window, as well as the options corresponding to the VARIABLE
menu selection in accordance with one embodiment of the
present invention;
Fig. 26 illustrates a Call Variables dialog box in
accordance with one embodiment of the present invention;
Fig. 27 illustrates a Graph Variables dialog box in
accordance with one embodiment of the present invention;
Fig. 28 illustrates a Graph Variables dialog box in
accordance with another embodiment of the present invention;
Fig. 29 illustrates a graph edit pad interface window,
as well as the options corresponding to the OPTION menu
selection in accordance with one embodiment of the present
invention;
Fig. 30 illustrates a graph edit pad interface window,
as well as the options corresponding to the EXECUTE menu
selection in accordance with one embodiment of the present
invention;
Fig. 31 illu~trates a graph edit pad interface window,
as well as the options corresponding to the VALIDATE menu
selection in accordance with one embodiment of the present
invention;
Fig. 32 illustrates a graph edit pad interface window,
as well as the options corresponding to the INTERFACE menu
selection in accordance with one embodiment of the present
invention;

2190888



Fig. 33 is a flow diagram of the operation of a service
creation portion to initiate creation of a new graph in
accordance with one embodiment of the present invention;
S Fig. 34 illustrates an example of a graph using a TI.~E
node in accordance with one embodiment of the present
invention;
Fig. 3S illustrates an example of a graph using a DLN
node in accordance with one embodiment of the present
invention;
Fig. 36 illustrates an example of a graph using a
PERCENT node in accordance with one embodiment of the present
invention;
Fig. 37 illustrate~ an example of a graph using a DAY
node in accordance with one embodiment of the present
invention;
Fig. 38 illustrates an example of a graph using an ANI
node in accordance with one embodiment of the present
invention;
Fig. 39A illustrates an example of a graph using a NET
node in accordance with one embodiment of the present
invention,~
Fig. 39B illustrates an example of a graph using a NET
node in accordance with another embodiment of the present
invention;
Fig. 40 illu~trates an example of a graph using a DATE
node in accordance with one embodiment of the present
invention;
Fig. 41 illustrates an example of a graph using a LATA
node in accordance with one embodiment of the present
invention;
Fig. 42 illustrates an example of a graph using a
RESULT node in accordance with one embodiment of the present
invention;
Fig. 43 illu~trates an example of a graph using a
ROUTING NUMBER node in accordsnce with one embodiment of the
pre~ent invention;

`- 2190888



Fig. 44 illustrates an example of a graph using a
CARRIER node in accordance with one embodiment of the present
invention;
Fig. 45 illustrates an example of a graph using a
GETlODIGITS node in accordance with one embodiment of the
present invention;
Fig. 46 illustrates an example of a graph using a STORE
node in accordance with one embodiment of the present
.10 invention;
Fig. 47 illustrates an example of a graph using a
PROCEDURE node in accordance with one embodiment of the
present invention;
Fig. 48A illustrates a DECISION node template dialog
box in accordance with one embodiment of the present
invention;
Fig. 48B illustrates a DECISION node template dialog
box in accordance with another embodiment of the present
invention;
Fig. 49A illustrateg an ASSIGNMENT node template dialog
box in accordance with one embodiment of the present
invention;~ -
Fig. 49B illustrates an ASSIGNMENT node template dialog
box in accordance with another embodiment of the present
invention;
Fig. 50A illustrates a PROCEDURE node template dialogbox in accordance with one embodiment of the pre~ent
invention;
Fig. 50B illustrates a PROCEDURE node template dialog
box in accordance with another embodiment of the present
invention;
Fig. 51A illustrates a CONVERSATIONAL node template
dialog box in accordance with one embodiment of the present
invention;
Fig. 51B illustrates a CONVERSATIONAL node template
dialog box in accordance with another embodiment of the
present invention;

` - 2190888
-- 10 --


Fig. 52 is a flow diagram illustrating a general edit
operating procedure performed by a service creation portion
to build a graph after a graph has been initiated, in
accordance with one embodiment of the present invention;
Fig. 53 is a flow diagram illustrating an operation of
a service creation portion for adding a node to a graph in
accordance with one embodiment of the present invention.
Fig. 54 is a flow diagram illustrating an operation of
a service creation portion for adding a branch to a graph in
accordance with one embodiment of the present invention;
Fig. 55 is a flow diagram illustrating an operation of
a service creation portion for editing a value in a graph in
accordance with one embodiment of the present invention;
Fig. 56 is a flow diagram illustrating an operation of
a service creation portion for connecting one node in a graph
to another node in a graph in accordance with one embodiment
of the present invention;
Fig. 57 is a flow diagram illustrating an operation of
a service creation portion to hide a portion of a displayed
graph in accordance with one embodiment of the present
invention;
Fig.-58 is a flow diagram illustrating an operation of
a service creation portion to delete a predetermined portion
of a graph in accordance with one embodiment of the present
invention;
Fig. 59 is a flow diagram illustrating an operation of
a service creation portion to delete a node from a graph in
accordance with one embodiment of the present invention;
Fig. 60 is a flow diagram illustrating an operation of
a service creation portion to open an existing stored graph
in accordance with one embodiment of the present invention;
Fig. 61 is a flow diagram illustrating an operation of
a service creation portion to save a graph to a database in
accordance with one embodiment of the present invention;
Fig. 62 i~ a functional block diagram of a call
processing portion in accordsnce with one embodiment of the
present invention;

21gO888




Figs. 63A and 63B are flow diagrams of a call
processing operation of a COMMUNICATE module in accordance
with one embodiment of the present invention;
S Figs. 64A and 64B are flow diagrams illustrating a call
processing operation of a MESSAGE HANDLER module in
accordance with one embodiment of the present invention;
Fig. 65 is a functional block diagram of a call context
in accordance with one embodiment of the present invention;
Fig. 66 is a functional block diagram of a call state
in accordance with one embodiment of the present invention;
Fig. 67 is a flow diagram of a call processing
operation performed by a CALL CONTEXT module in accordance
with one embodiment of the present invention;
Figs. 68A and 68B are flow diagrams illustrating a call
processing operation to provide visual indications of an
execution of a service as performed by a CALL CONTEXT module
in accordance with one embodiment of the present invention;
Fig. 69 is a flow diagram illustrating an operation for
setting ~'global,~ "step" and "trace" flags in accordance with
one embodiment of the present invention;
Fig.~ 70 is a flow diagram illustrating an operation to
provide a visual indication of an execution path taken during
enhanced call processing at a remote call processing
2S environment, in accordance with one embodiment of the present
invention;
Fig. 71 illustrates a dialog box for selecting services
for vi~u~l indication in accordance with one embodiment of
the present invention; and
Fig. 72 is a flow diagram illustrating an operation of
an expert system in accordance with one embodiment of the
present invention.

Best Mode for Carrvinq Out the Invention
Reference will now be made in detail to the
construction and operation of preferred implementations of
the present invention which are illustrated in the

2190888

- 12 -


accompanying drawings. In those drawings, like elements and
operations are designated with the same reference numbers.
The following description of the preferred
implementations of the present invention is only exemplary of
the invention. The present invention is not limited to these
implementations, but may be realized by other
implementations.

A. OVERVIEW
The present in~ention overcomes the disadvantages of
conventional systems by providing to telephone services
service programs customized to the desires of individual
customers requesting individualized functionality. As used
in this application, "customer" refers to the entity for
which a service is provided, and ~userl or operator~ refers
to the person using the system to create, test or modify the
service. The user and customer may be the same, but they
need not be. Although the following description focuses on
telephone services, the invention has broader uses and is not
necessarily limited to telephone services in all instances.

l. -Software Components:
The preferred embodiment of the present invention
includes a customized service~ ("CS") application to create
and, in certain circumstances, execute each customer's
service procedure or program. Each customer's service
program is stored as a record or a series of records of
customized c811 processing information (CCPI) in a database.
The CS application and the CCPI are the principal software
components of the preferred implementation.
The CS application preferably includes a programming
interface which permits an operator to use the CS application
to create various user interfaces to obtain information,
directly or indirectly, in a manner which is relatively easy
to use. The information is used to generate the CCPI records
automatically.

2190888




User interfaces can be tailored to the skill level of
an operator,-which can be the customer, using the CS
application to create customers service program~, to the
specific service to be provided, or to the specific hardware
on which the service will be created, such as bit map
graphics, terminal displays or DTMF telephones.
Fig. 1 illustrates an example of a customer interface,
shown as a graph 5, providing a graphical representation of a
CCPI record created on a graphics workstation display. The
CCPI record corresponding to this graph provide~ a service
for a customer identified via a "key' in rectangle 6. The
specific service provided by the CCPI record for graph 5 is
the screening of calls from the telephone having the phone
number (201) 699-2911. The details of how a CCPI record
provides such a service to various phone numbers having a
"976" extension will be explained in detail below.
In Fig. 1 the programming interface of the CS
application has been used to provide a graphic user interface
to allow construction of graph 5. The present invention,
however is not limited only to implementations requiring a
graphic user interface. If, for example, the interface used
-to build graph 5 is too resource intensive to allow efficient
preparation of similar graphs for every subscriber, an
alternative interface can be selected.
Fig. 2 shows a form user interface 8 which can be used
to provide the same "976" call screening servicQ as graph 5
does. Form interface 8 requires a customer or operator to
insert only a small amount of information, and thus requires
less time and skill than creating graph 5. The programming
interface for providing "976" form interface automatically
translates the information input by the operator into a CCPI
record corresponding to the desired service. Using a
different user interface, an operator can display thiq same
CCPI record or records in a different form.
In the preferred implementation of the preqent
invention, the CCPI record or records corresponding to a
service are created in a creation environment of the CS

2190888
-


- 14 -


application and are executed during call processing in a call
processing environment of the CS application. As used
herein, ~call procesqing~ refers to the acts of responding to
a message or query from a switch or switch simulator. A
switch is a piece of telephone equipment which receives and
routes telephone calls. As explained below, CCPI records may
be executed in either the creation environment or the call
processing environment.
2. Hardware Alternatives
In a preferred embodiment, the present invention is
implemented in the advanced intelligent network (AIN). Fig.
3 is a block diagram of the AIN. The AIN comprises ASC AIN
switching capabilities switch ("ASC switch~') 12, ad~unct 14,
service node (SN) 16, service control point (SCP) 18 and
service management system (SMS) 20. The present invention
can al~o be implemented on a personal computer (PC) 22
connected to SMS 20, SCP 18, ad~unct 14, or SN 16 via modems
24.
In a preferred embodiment, the CS application can be
executed on SMS 20, SCP 18, ad~unct 14, SN 16 or PC 22. As
will be ex-plsined below in the discussion of the different
implementations, the functionality of the CS application may
differ depending upon which component executes the CS
application.
In the preferred embodiment of the present invention,
the CS application provides for both the creation of a CCPI
record (ser~ice creation) through an operator interface, and
for the execution of CCPI records during call processing.
However, the CS application can provide only the creation or
the execution of CCPI records.
Figs. 4A-4D illustrate different network elements which
can execute the CS application~.
Fig. 4A is a functional block diagram of SMS 20. SMS
20 comprises CPU 40, database 42, operator interface 44 and
CS application 46. Operator interface 44 preferably
compriseq display 48, keyboard 50 and mouse 52, each

2190888

- 15 -


connected to CPU 40. CS application 46 includes service
creation portion 54 and call processing portion 56. A CCPI
record can be created at SMS 20 via operator in~erface 44 and
can also be used by SMS 20 to process calls input to CPU 40
via any number of sources such as a network switch simulator
or a dedicated testing switch (not shown).
CS application 46 could contain only service creation
portion 54 for creating a CCPI record at SMS 20. In such a
configuration, a CCPI record created at SMS 20 would be
transferred to SCP 18 (Fig. 4B) for execution during real
time call processing.
Alternatively, CS application 46 in Fig. 4A may
comprise only call processing portion 56 for processing calls
in a simulated environment using CCPI records created
elsewhere and stored in database 42. In thi~ arrangement,
SMS 20 would only be used for testing, not service creation.
Further, as discussed in greater detail below, call
processing portion S6 provided in SMS 20 is preferably an
enhanced version which permits a visual indication of the
execution of a CCPI record on a graph di~played to an
operator.
Fig. 4B is a preferred embodiment of a functional block
diagram implementing CS application 46 in SCP 18. SCP 18
comprises CPU 58, d~taba~e 60, and CS application 46. In
Fig. 4B, CS application 46 comprise~ only call processing
portion 56. This i9 because SCP 18 typically provides no
operator interface 44 (Fig. 4A), therefore, creation of a
CCPI record is not ususlly performed at SCP 18.
If, as in Fig. 4C, operator interface 44 is provided at
SCP 18, CS application 46 may include service creation
portion 54 to permit creation of a CCPI record at SCP 18. In
Figs. 4B and 4C, call processing portion 56 processes
messages provided by ASC switch 12 (Fig. 2) by executing the
CCPI records stored in database 60.
If operator interface 44 i~ provided in SCP 18, call
procecsing portion 56 would be an enhanced ver~ion of call
processing portion 56 to permit a visual indication of the

2190888
-


- 16 -


execution of the CCPI record at SCP 18. As described in more
detail below, if an enhanced version of call processing
portion 56 is used in SCP 18 without interface 44, a visual
indication of the execution of the CCPI record can be
transferred to another environment which provides operator
interface 44 and service creation portion 54 for displaying
the execution path of a CCPI record on the graph
corresponding to the CCPI record.
Implementation of CS application 46 in either ad~unct
14 or SN 16 is provided in a manner similar to implementation
of CS application 46 in SCP 18.
As shown in Fig. 4D, implementation of CS application
in PC 22 is similar to that for SMS 20 in Fig. 4A. CS
application 46 in PC 22 preferably includes service creation
portion 54 and call proces-~ing portion 56. Alternatively, CS
application 46 may include either service creation portion 54
or call processing portion 56 to perform either of the
associated functions, with the functions which are not being
performed being provided in an alternative environment. Call
processing portion 56 may be an enhanced version to permit a
visual indication of the execution of a CCPI record as PC 22.

B. Architecture of the Software
The displayed representation of a CCPI record is
extremely useful in that it permits an operator or a customer
to customize, create and understand the desired telephone
service. The displayed representation is merely an aid to
the understanding of the design of the corresponding service;
however, the displayed representation cannot be interpreted
directly by the call processing environment. The displayed
representation of the CCPI record must therefore be
translated into a binary representation which can be stored
and used to process calls in a call processing environment.
In the preferred implementation of the present
invention, the displayed representation of the CCPI record is
first translated into an internal representation comprising
data structures and pointers representing the CCPI record,

2190888




and eventually into the binary representation. Fig. 5 shows
this schematically.
Software 51 has three levels corresponding to three
representations of the CCPI record. Display level 53 is used
to provide the displayed representation of a CCPI record,
such as that shown in Figs. 1 and 2. Level 53 preferably
contains two sublevels: sublevel 55 and level 57. Sublevel
55 is used to form the actual display for the corresponding
display terminal. Sublevel 57 contains information on
~objects" used to form the displayed representation. For
example, in the display shown in Fig. 1, the ob~ects may
refer to the diamonds and rectangles used to form graph 5.
The division of level 53 into sublevels aids in porting
software 51 to different platforms. Preferably, the software
at level 53 is written in the IBM C-2 1.1. language, designed
according to an ob~ect-oriented design methodology. The
program is also preferably written to the ANSI C standard so
that it will compile under C++.
Data structure level 59 contains an internal
representation of the service preferably stored in data
structures., Detail~ of the data structures are not necessary
to the understanding of this invention, however, it should be
noted`that the software at level 59 is less machine dependent
than that at level 53 because the software at level 59 can be
used with many different types of displays, e.g., forms or
graphs, and many different types of hardware.
The actual binary representation of the service is at
binary code level 61. Level 61 is the only representation
stored for execution in the preferred embodiment. The binary
representation is the most machine independent.
When a CCPI record is stored to a database, such as
database 42 in Fig. 4A, or retrieved from a database, modules
corresponding to the binary representation of the CCPI record
translate the internal graphical repre~entation of the CCPI
record into the binary representation of the CCPI record.
Each representstion of a CCPI record is manipulated by a set
of modules in the software. A ~module~ consists of a set of

~190888


- 18 -


subroutines which are used to manipulate some physical or
conceptual object.
The ~'module~' concept is at the heart of the
object-oriented de~ign in the preferred implementation of
this invention, although the module is not necessary to carry
out the invention in all of the implementations. A set of
modules is associated with each representation of a CCPI
record. The set of modules associated with the binary
representation of a CCPI record (level 61 in Fig. 5) is
responsible for storing and retrieving the CCPI record to and
from the database. This set of modules also executes the
instructions of the CCPI record.
A set of modules associated with the internal data
structure representation of a CCPI record (level 59 in Fig.
5) is responsible for manipulating the instructions and
structure of the CCPI record. These modules are also
responsible for translating the binary representation of
level 61 into the internal data structure representation of
level 59.
A set of modules associated with the displayed
representation of the CCPI record (level 53 in Fig. 5) is
responsible for translating the internal data structure
representation into the displayed representation and
pre~enting and collecting information to and from an
operator. These modules would generally be written by an
individual (such as a programmer) and use the programming
interface (i.e., the interface between level~ 53 and 59) of
the modules corresponding to the internal data structure
representation of the CCPI record to create new interfaces
for customer services.

l. Modules CorresPondina to Internal
Data Structure Representation Level
Fig. 6A show~ the preferred modules for level 59.
GRAPH module 62 organizes snd maintain~ a ~et of node~ in a
graph. Important oper~tions of thi~ module include
translating the intern~l d~ta structure repre~entation into

219~888

-- 19 --


the binary representation and visa versa, as well a~ adding
and deleting nodes from the graph in the internal data
structure representation.
NODE module 64 manages a single CCPI record
instruction, and modifies the parameters of a node.
Included in NODE module 64 is BRANCH module 66. Branch
module 66 manages each branch of a DECISION node. DECISION
nodes are explained in greater detail below.
Included in each BRANCH module 66 is BRANCH VALUE
module 68. BRANCH VALUE module 68 manages every value in
each branch of a DECISION node.
GRAPH AND NODE CONTROL module 70 represents a higher
level abstraction of nodes and graphs, and provides
mechanisms for adding, editing and deleting nodes from a
graph.
TEMPLATE module 72 provides a template for creating new
nodes. TEMPLATE module 72 evaluates a template to determine
what information is needed to create a node, and to generate
a node once the information is complete.
LABEL module 74 provides the mechanisms for parsing and
generating string ob~ects.
EXPE~T-module 76 manages an expert system, translates
the internal data structure representation of a CCPI record
into schema~ used by an expert system (explained below), and
help~ evaluate responses received from the expert system.

2. Modules CorresPondinq to Binary
RePresentation Level
Fig. 6B shows the preferred modules for level 61 shown
in Fig. 5.
GRAPH BUFFER module 78 manage~ the binary
representation of the CCPI records as ~hown in Fig. 5. GRAPH
BUFFER module 78 also orchestrates the execution of the CCPI
records.
NODE BUFFER module 80 manages the binary representation
of a single in~truction in a CCPI record.

2190888

- 20 -


KEY module 82 manages the data structures that stores
~'keys" for the CCPI records. Keys are used to access the
records directly. Important operations include comparing the
records to externally provided keys.
COMMUNICATION module 84 manages communication ports
which transfer query messages and CCPI records between AIN
network elements. COMMUNICATION module 84 facilitates
reading from and writing to the ports.
MESSAGE HANDLER module 86 represents a device for
passing messages into and out of call processing routines.
In particular, MESSAGE HANDLER modules 86 converts messages
into call contexts and converts call contexts into message~.
Call contexts are the data structures for managing the calls.
CALL CONTEXT module 88 manages the execution of CCPI
records. Included in CALL CONTEXT module 88 is CALL STATE
module 90 which manages the information as~ociated with each
CCPI record being executed during call proce~ing.
VARIABLE module 92 manages call variables associated
with the execution of a CCPI record.
STACK module 94 provides conventional ~tack functions,
such as push and pop operstions.
LINK module 96 provides conventional linked list
functions.
DATABASE module 98 manages a database, and provides
mechanism~ for reading, writing, opening, closing and
updating a dstaba~e.
MAIL module 100 send~ and retrieve~ CCPI records
between the AIN network element~ identified in Fig. 3. The
sending and receiving of records preferably u~es conventional
data transfer techniques.

3. Modules for DisPlaved RePresentation Level
As explained above, the modules corre~ponding to the
displayed representation of CCPI record~ will generslly be
written by an individual (~uch as a progr~mmer) and use the
programming interface of the module~ corresponding to the
internal repre~entation of the CCPI record~ to create new

2190888




services. These modules generate the displayed interface on
the display screen and present information to and collect
information from an operator creating a new service.
Fig. 6C illustrates a preferred set of modules
corresponding to the displayed representation of a CCPI
record for providing the flow chart styled interface (~graph
interface") such as graph 5 shown in Fig. l.
Fig. 6D illustrates a preferred set of modules
corresponding to the displayed representation a CCPI record
for providing a form interface such as the "976" call
screening form interface shown in Fig. 2. In both displayed
representations, the modulec are preferably divided to
correspond to an applied displayed representation of the CCPI
record and an abstract displayed representation of the CCPI
record. An applied displayed representation is the visual
image displayed on the screen, while the abstract displayed
representation defines the images to be displayed and
coordinates them onto an abstract plane.
The modules corresponding to the applied displayed
representation of a CCPI record are identical for both the
graph interface and the form interface.
SCREEN module 102 draws the displayed interface onto
the screen and clears the screen.
DIALOG module 104 manages the dialog boxes which can be
displayed to the operator. Important operations for this
module include clearing, presenting and retrieving
information from the operator via dialog boxes.
CONTROL module 106 manages the state of the interface,
including mouse clicks and menu selections made by the
operator. The CONTROL module also handles events generated
from external communication port~.
WINDOW TABLE module 108 manages information about each
graph editing pad window, including which windows are open or
closed and which CCPI records are displayed in which windows.
Important operations for this module include correlating a
call context with a window and setting and storing parameters
for each graph editing pad window.

2190888

- 22 -


Fig. 6C illustrates the OBJECT TABLE module 110 and
OBJECT module 112. OBJECT TABLF. module 110 manages the
collection of objects used in the abstract displayed
representation of a CCPI record. Important operations of th~
OBJECT TABLE module 110 include translating the internal data
structure representation into the abstract displayed
representation, and adding an object to, as well as deleting
an object from, an ob~ect table (not shown).
OBJECT module 112 manages information corresponding to
an object or figure to be drawn on a display screen. OBJECT
module 112 sets parameters, such as location, size and shape
for each ob~ect or figure to be drawn on the screen.
Fig. 6D illustrates a preferred module corresponding to
the abstract displayed representation of a CCPI record for
providing a form interface, such as the "976" call screening
interface shown in Fig. 2.
PROVISION module 114 translates the internal data
structure representation of a CCPI record into an abstract
representation corresponding to the form interface, and
interfaces with the program interface at the modules
corresponding to the internal data structure of a CCPI record
to provide for the form interface.
In an alternative embodiment, module 114 may be
included in with the graph interface modules of Fig. 6C.
This would allow CCPI records to be displayed as either the
~976" call screening form shown in Fig. 2, or the graph
corresponding to thi~ service shown in Fig. 1.
A~ explained above, each display interface creates and
displays a set of CCPI records. Thi~ set corresponds to a
service concept which the interface is designed to support.
If a CCPI record is created by one interface and falls within
the set of CCPI records that can be created by a different
interface, that CCPI records can be displayed by both
interfaces.

2190888
-




C. Service Creation Usinq GraPh Interface
Prior to discussing the creation of a service, an
explanation of the operation of a service will be given as
S background. Reference will be made to graph 5 in Fig. 1 for
the explanation.
In Fig. 1, rectangle 6 contains the name' or "key' for
graph 5. This "key" identifies whether the graph controls
calls made from the phone number identified in the rectangle
6 (identified by the ~'.eO4" suffix) or calls being made to
the phone number identified in rectangle 6 (identified by the
".eO5 suffix).
The remainder of graph 5 comprises a plurality of nodes
25, decision boxes 30, and branches (not labelled) between
the nodes 25 and decision boxes 30. Each node 25 represents
a high level instruction in the CCPI record corresponding to
the graph. Decision boxes 30 correspond to decision nodes
(nodes 25a and 25i) and identify alternative execution paths
depending on the result provided by the corresponding
decision node.
Graph 5 corresponds to a CCPI record used to call
process a phone call being made from phone number (201) 699-
2911. The CCPI record corre~ponding to graph 5 screens from
the phone number (201) 699-2911 all calls which the customer
does not wish to be completed. For example, telephone calls
made to the phone number "976-1212" are routed between the
hour~ of 7:00 p.m. to 9:00 p.m., as are any phone calls made
to the number "976-1234" during the hours of 6:00 p.m. to
8:00 a.m. and any phone calls made to the number "976-1224"
at any time. Calls to any other number with the "976"
exchange, calls to "976-1234" between 8:00 a.m. and 6:00
p.m., and calls to ~976-1212~ between 9:00 p.m. and 7:00 a.m.
are sub~ect to PIN (Personal Identification Number) override.
If the caller cupplies the PIN of 2558, the call i~ routed.
Otherwise, a busy signal is produced.
This service is provided for by graph 5 as follows.
Initially, decision node 25a checks the NXX (i.e., fourth,
fifth and sixth digit~ of the phone number)(the exchange).

2190888

- 24 -


Decision boxes 30a and 30b identify the two decision
possibilities which require separate attention. If the call
is not a 976" exchange (other) the call is routed by node
5 25b.
If the call is a "976" exchange, node 25c checks the
last four digits (the extension) at node 25c. If the last
four digits are "1212" (decision box 30c) node 251 checks the
time of day. If the call is placed between the hours of 7:00
p.m. and 9:00 p.m., the call is routed (decision box 30g and
node 25d).
If the call is placed any other time of the day
(decision box 30h), the call is to be prevented unless the
proper PIN is pro~ided. Node 25e prompts the caller to input
a PIN. Node 25f checks the result. If the caller inputs PIN
~2558" (decision box 30e), the call is routed by node 2Sg.
If the caller inputs any other PIN (decision box 30k), node
25h provides the caller with a busy signal.
If the last four digit~ of the phone number being
called are "1234" (decision box 301) node 25i checks the
time. If the call is being placed between the hours of 8:00
a.m. and 6~00 p.m. (deci~ion box 30i), the PIN operation is
again performed beginning at node 25e. This i~ illustrated
in Fig. 1 by the circle 26a which contain~ a numeral 1. Note
that the PIN node 25e has a ~number 1:" next to it. This
indicates that the graph continues execution starting with
that node. If the call i~ being placed at any other time of
day (deci~ion box 30~), the call i~ routed by node 25~.
If the last four digits of the phone number being
called are ~1224~ (decision box 30e), the call i~ routed by
node 25k.
If the last four digits of the phone number being
called are something other than "1212," "1234," "1224"
(decision box 30f), the PIN operation i~ repeated, as
indicated by the circle 26b.
With this explanation of graph S, the steps of graph
creation and editing can be addressed. Creation and editin.g

2190888



of a graph, such as graph 5, preferably involve~ windows a~d
menus.

S 1. Menus
Fig. 7 represents operator interface window 120. Main
window 120 comprises a menu bar 122 identifying seven menus:
MAIN, DATABASE, TEMPLATE, DATA, OPTIONS, LIBRARY and EXIT.
An operator clicks~ on any of the menu options to select a
desired menu. The 'remote' window 121 shown inside 120 is
optional and will be described in detail below.
Fig. 8 is a display of the main operator interface
window 120 showing the options 124 for the MAIN menu. These
options include: GRAPH EDIT PAD, SYSTEM VARIABLES, TCAP
MESSAGES, MAIL MESSAGES and SWITCH SIMULATOR. The GRAPH EDIT
PAD option opens a GRAPH EDIT PAD window which i~ used to
create, edit and save graphs.
The SYSTEM VARIABLES option opens a system variable
window, as shown in Fig. 9, which displays the call variables
of the operating environment, such as time, day and date.
From this window, the operator can change the values of the
system call--variables.
The TCAP MESSAGE option opens the TCAP MESSAGE window
as shown in Fig. 10. This window di~plays the query mescages
from a switch or switch simulator, not shown in Fig. 10.
The MAIL MESSAGES option open~ a MAIL MESSAGE window
(similar to the TCAP message window, therefore, not shown)
which displays the me~sages a~qociated with the exchange of
CCPI records to other devices in the AIN network. The S~ITCH
SIMULATOR option opens a S~ITCH SIMULATOR window (not shown)
so that the operator can generate queries into the
application for te~ting CCPI record~.
Figure 11 is a di~play of the main interface window 120
showing the options 126 for the DATABASE menu. These options
include: NEW, OPEN, COPY and DELETE. The NEW option
displays a dialog box to prompt the operator for 8 database
name and creates the new databa~e. The OPEN option displays
a dialog box to prompt the operator for a database name to

21gO888
' -

_ 26 -


open an existing database. The COPY option displays a dialog
box to prompt the operator for two database names and copies
the first database into the second database. The DELETE
option displays a dialog box to prompt the operator for a
database name to delete that database.
Figure 12 is a display of the main interface window 120
showing the option~ 128 to the TEMPLATE menu. These options
include: NEW DECISION, NEW ASSIGNMENT, NEW CONVERSATION, NEW
PROCEDURE, EDIT and DELETE. Templates, as explained below in
greater detail, are used to create graph elements, called
nodes, which the system does not record a~ standard.
The NEW DECISION option di~plays a dialog box for the
operator to create a NEW DECISION node template. The NEW
ASSIGNMENT option displays a dialog box for the operator to
create a NEW ASSIGNMENT node template. The NEW CONVERSATION
option displays a dialog box for the operator to create a NEW
CONVERSATION node template. The NEW PROCEDURE option
displays a dialog box for the operator to create a NEW
PROCEDURE node template.
The EDIT option displays a list of node templates (not
shown). The operator selectq the node template to be edited,
and a dialog box with the template information is presented
to the operator. The operator can make de~ired changes to
the template information.
The DELETE option also presents the operator with a
list of node templates from which the operator can select
templates to delete.
Fig. 13 i8 a display of the main interface window 120
showing the options 130 for the OPTIONS menu. ThesQ options
include: EXECUTION and EDIT.
The EXECUTION option displays a dialog box allowing the
operator to set the global "step" and "trace" flags. As
explained below in more detail, the step flag is set to allow
an operator to step through the graph during call processing.
The trace flag is used to highlight the execution path taken
through a graph during c~ll proces~ing.

2190888



The EDIT option displays a dialog box allowing the
operator to select the information to be displayed in the
graph nodes. The two types of information generally selecte~
S are the node title and the node value. Examples of these
dialog boxes are described below.
Fig. 14 is a display of the main interface window 120
showing the options 132 for the LIBRARY menu. These options
include: CHECKOUT, RETURN, ADD and DELETE. The CHECKOUT
option displays a dialog box which the operator completes
with the name of a record desired to be checked out from a
remote database. The RETURN option displays a dialog box
prompting the operator for the name of the CCPI record to be
returned to a remote database. The operator can also add a
record to the remote database or delete a record from the
remote database using the ADD and DELETE options,
respectively.
Fig. 15 illustrates a "graph edit pad" window 134 which
is used to create, edit and store CCPI records. This window
includes a menu bar 136 including eight menu options: GRAPH,
EDIT, VARIABLE, OPTIONS, EXECUTE, VALIDATE, INTERFACE and
EXIT.
Fig. 16 illustrates the llgraph edit pad" window 134
with options 138 of the GRAPH menu displayed. These options
include: NEW, OPEN, SAVE, SAVE AS, CLOSE, DELETE, FORWARD,
BACR and ITERATE. The NEW option displays a dialog box (Fig.
17) prompting the operator for a name or ~key" for the record
that the operator wishes to create. The OPEN option displays
- a dialog box (see Fig. 18) prompting the operator for the
name or "key" of the graph the operator wishes to open.
The SAVE option ~aves to permanent storage the binary
representation of CCPI records corresponding to the graph.
The SAVE AS option displays a dialog box (Fig. 19)
prompting the operator for the name or ~keyll for a CCPI
records to be saved, then saves the binary representation of
the CCPI records corresponding to the graph to permanent
storage.

219~888
- 28 -


The CLOSE option displays a warning dialog box (see
Fig. 20) requesting the operator for verification to complete
this option. If the request is verified, all representatio-.s
of the CCPI records corresponding to the graph that ls
currently being displayed are cleared.
The DELETE option deletec the CCPI records
corresponding to the graph that is currently being displayed
is deleted from the database. Again, a warning dialog box is
presented to the operator.
The FORWARD option displays the CCPI record in the
database following the CCPI record that is currently
displayed. The BACR option displays the CCPI record in the
database that precedes the CCPI record currently being
displayed. The ITERATE option displays the CCPI records in
the database consecutively at a predetermined interval.
Fig. 24 illustrates the ~'graph edit pad~ window 134
with options 140 at the EDIT menu displayed. These options
include: ADD NODE, ADD BRANCH, EDIT, HIDE, CONNECT,
TEMPLATE, DELETE SUBTREE and DELETE NODE. The ADD NODE
option displays a dialog box with a list of the nodes the
operator can add (see Fig. 21). The ADD BRANCH option
displays a-dialog box (see Figs. 22 and 23) corresponding to
the DECISION node to which the branch is being added. The
operator enters the correct branch information for the
selected DECISION node.
The EDIT option displays a dialog box (see Fig. 23)
with information corresponding to the selected node which
allows the operator to edit a node. The CONNECT option
connects one portion of a graph to another portion of the
graph. The TEMPLATE option displays the template for the
selected node.
The HIDE option removes from the screen all nodes that
are children of the selected node unless the child nodes also
have a parent different from the selected node. The DELETE
SUBTREE option deletes the selected node and all its children
nodes from the screen and the corresponding CCPI record,
unless a child node alqo ha~ a parent that i~ different fro~

2190888
-


- 29 -


the selected node. The DELETE node deletes a node from the
graph. These last two options change the graph's
functionality. The HIDE option does not.
Fig. 25 illustrates the graph edit pad window 134 with
the options 142 for the VARIABLE menu being displayed. These
options include CALL VARIABLES and GRAPH VARIABLES. The CALL
VARIABLES option displays a window containing the variables
of the call context for the graph being displayed (see Fig.
26). The GRAPH VARIABLES option displays a window containing
the variables of the CCPI record being displayed (see Figs.
27 and 28).
Fig. 29 illustrates th~ graph edit pad window 134 with
the options 144 for the OPTION menu being displayed. These
options include EDIT and EXECUTION. The EDIT option displays
a dialog box (not shown) with two options: TITLE and VALUE.
These options are similar to the TITLE and VALUE options in
the GRAPH menu, but correspond to each node separately. The
EXECUTION option displays a dialog box (not shown) which
allows an operator to select the ~step~ and ~trace" flags for
the CCPI record corresponding to the graph being displayed.
Fig. 30 illustrates the graph edit pad window with the
options 1~6-of the EXECUTE menu being displayed. These
options include: COMPLETE, STEP and CLEAR. The COMPLETE
option completes a call processing of a CCPI record
corresponding to the graph. The STEP option executes the
next node of a CCPI record of the displayed grsph. The CLEAR
option removes a visual indication of the execution of a CCPI
record corresponding to the displayed graph.
Fig. 31 illustrates the graph edit pad window 134 with
the options 148 for the VALIDATE menu displayed. These
options include VALIDATE, DISPLAY and CLEAR. The VALIDATE
option invokes an expert system which flag~ any errors in the
structure of the CCPI record of the displayed graph. The
DISPLAY option displays a list of errorR associated with the
selected node. The CLEAR option clears all flagged errors
from the graph.

2190888

- 30 -


Fig. 32 illustrates the graph edit pad window 134 with
the options 150 for the INTERFACE menu displayed. These
options include GRAPH and FORM. The FORM option represents
CCPI record as a form for a "976" call screening service (as
shown in Fig. 2). The GRAPH option represents the same CC
reccrd as a graph (as shown in Fig. 1).

2. Operation
The creation of a service will now be described with
reference to certain of the windows explained above. Fig. 33
is a flow diagram of the operation of the service creation
portion 54 to initiate creation of a new a graph. Initially,
the operator manipulate~ the windows to display the main
interface window shown in Fig. 7 (step 200). The operator
~elects the "MAIN" menu (step 202) to di~play the "MAIN" menu
options to the operator (~ee Fig. 8) (step 204). The
operator selects the "GRAPH" option, and CONTROL module 106
displays the ~graph editing pad'l window (~ee Fig. 15) (step
206).
The operator then ~elects the "GRAPH" menu (~tep 208)
to display the "GRAPH" option~ (see Fig. 16) (step 210). The
operator select~ the "NEW" option (step 212), and CONTROL
module 106 calls DIALOG module 104 to di~play the
corre~ponding dialog box (Fig. 17) (~tep 214).
Next, the operator inputs the "key" of the graph (step
216), and CONTROL module 106 responds by calling GRAPH module
62 to allocate memory for the internal data ~tructure repre-
sentation of the graph being created (step 218). CONTROL
module 106 al~o calls OBJECT TABLE module 110 to allocate
memory for the ab~tract displayed representation of the graph
to be created (step 220). GRAPH module 62 then calls GRAPH
BUFFER module 78 to allocate memory for a binary
representation of the graph being created (step 222). Next,
35 CONTROL module 106 calls GRAPH module 62 to add the ~key~ to
the internal representation of the graph being created (~tep
224).

2190888

- 31 -


CONTROL module 106 then calls OBJECT TABLE module 110
to translate the internal graphical representation to an
abstract displayed representation (step 226). CONTROL module
106 then calls SCREEN module 102 to translate the abstract
displayed representation into the applied displayed
representation ~key~ ob~ect (step 228), which is shown as a
rectangular box containing the "key~' on the graph.
The result of the steps in Fig. 33 is the initiation of
a new graph. At this point, only the box with the "key~ is
displayed. Using the operations of the "EDIT" menu and a
plurality of nodes, an operator can now build a graph to
define a desired service.

a. Nodes
Preferably, graphc are comprised of four types of
nodes: DECISION nodes, ASSIGNMENT nodes, PROCEDURE nodes and
CONVERSATION nodes. DECISION nodes control the path of
execution of a graph during call processing depending
according to values of call variables. ASSIGNMENT nodes
assign "values" and "variables" to other "call variables."
The concep~s of variables and call variables are explained
below. PROCEDURE nodes switch control to a different graph
or to a subroutine. CONVERSATION nodes provide information
to a caller or derive information from a caller in the course
of processing a call.
DECISION nodes are used to branch the execution through
a graph and have several important attributes. The fir~t of
these attribute~ is the ~call vsriable~ attribute which
indicate~ which variable i~ used in determining the correct
branch. Another important attribute is the "type" of the
call variable which determines how the br~nch information
will be stored and displayed, for example, as sn integer or
as an ASCII string. The preferred predefined DECISION node
templates generate the following nodes:
TIME DAY DATE
DLN ANI LATA
PERCENT NET RESULT

2190888
-




TIME Node - The TIME node is a DECISION node which tests ~ r
time of day when traversing a graph. The TIME node s decision
branches may specify a single time, a range of time, multiple
5 times or time ranges. The TIME node makes its decision based u?on
the current time of day for the call. The value of the system
clock is used to determine the branch.
Fig. 34 illustrates a graph using the TIME node. In this
graph, if the call placed to the 800 number shown in the rectangle
10 is made between the hours of 8:00 a.m. and 6:00 p.m., the call is
routed using a first carrier. For any other time, the call is
routed using a different carrier.
DLN Node - The DLN (Dialed Line Number) is a DECISION node
which represents the number to which the call is placed. The DLN
15 node decisions are based upon one or more of the digits in the
number dialed by THE calling party. The positions 0-9 of the
digits of the dialed line number can be used to indicate which
portion of the dialed line number the decision should be made.
Fig. 35 illustrates an example of a graph using the DLN node.
20 In this graph, is a call being made from the number identified in
the rectangle is placed to an exchange of 976, an announcement is
played to the~ caller, and the call processing is blocked. Any
call to any other exchange is routed.
PERCENT Node - The PERCENT node i9 a DECISION node which
25 randomly chooses a path ba~ed on predetermined percentages. An
example of ~ graph u~ing the PERCENT node is shown in Fig. 36
where, the first 25 percent of phone callq made to the 800 number
identified in the rectangle are routed via a first carrier; the
second 25 percent of these calls are routed via second carrier;
30 the third 25 percent are routed via a third carrier; and the
fourth 25 percent are routed via a fourth carrier.
DAY Node - The DAY node is a DECISION node which allows a
graph to branch based upon day of week criteria. Branches for a
DAY node indicate the path of call proces~ing when the value for
35 the day call variable matches the branch criteria. Each branch
out of a day node may contain one or more dayc or ranges of days.
Fig. 37 illustrates a graph u~ing a DAY node. In this g~a~.
if the number in the rectangle is called on Saturday or Sunday,

2190888



the call is forwarded to a different telephone number. If the ~ay
of the week is Monday-Friday (other), the call is routed to the
number in the rectangle.
S ANI - In an ANI (Automated Num~er Identification) node, a
decision is made based upon one or more of the digits in the ANI
string. The ANI string (a series of ASCII characters) represents
the phone number of the calling party.
Fig. 38 shows an example of a graph utilizing an ANI node.
The graph in Fig. 38 tests the first three digits (the area code)
of the number from which the call is made. If these three digits
are 303 or 719, the call is routed. If these three digits are
some other three numbers, an announcement is played to the caller
and the phone call is blocked.
NET Node - The NET node is a DECISION node which determines
whether a call is on a private network or off of a private
network. The NET nodes' decision branches have the values ON for
an ON network call and other (or OFF). Typically, the NET
DECISION node is to determine if the call is over a private
telephone network. The incoming TCAP message contains the value
assigned to the NET variable. Figs. 39A and 39B each illustrate a
graph including a NET node.
DATE Node - The DATE DECISION node allows a graph to branch
based upon day and month criteria. The branches for a date node
indicate the path the call processing should take when the value
for the dste csll vsriable matches the brsnch criteria.
An example of a graph using the DATE deci~ion node is shown
in Fig. 40. In this graph, if the date on which the call is
placed to the number identified in the rectsngle is January 1,
July 4 or December 25, sn announcement i8 played to the caller,
and the call proce~sing i~ blocked.
LATA Node - The LATA (Local Access and Transport Area) node
is a DECISION node which teqts the LATA of the originating number.
Multiple LATA values or ranges of LATA values may be specified for
a single branch.
Fig. 41 illustrates a greph uging the LATA DECISION node. Tn
the graph, if a call placed to the 800 number identified in the
rectangle originates in the 252 LATA, the call i3 routed.

2190888

- 34 -


Otherwise, an announcement is played, and the call processing is
~locked.
RESULT Node - The RESULT node is as DECISION node which tests
the DIGITS call variable identifying dialed digits. The cal
variable is assigned from the information collected by a
conversational message Fig. 42 illustrates a graph using the
RESULT node.
ASSIGNMENT nodes assign values or call variables to other
call variables. The preferred predefined ASSIGNMENT node nodes
are as follows:
ROUTING NUMBER (RN) CARRIER BILLED NUMBER
FINAL TREATMENT
ROUTING NUMBER (RN~ - The RN node is an ASSIGNMENT node that
assigns a final routing number. When a telephone number is
specified, the syntax is l0 digits that represent the valid
telephone number. Fig. 43 illustrates a graph using the RN node.
In Fig. 43, the telephone number for the routing i8 displayed in
the node. A call made to the 800 number identified in the
rectangle is actually routed to the phone number identified in the
RN node.
FINAL TREATMENT Node - This is an ASSIGNMENT node to assign a
final treatment code to the final treatment variable. The final
treatment code tells the switch what to do with the call, for
example, route, block, busy (see, for example, Fig. 42).
CARRIER Node - The CARRIER node is an ASSIGNMENT node which
allows an operator to specify which long distance carrier will
route the call. When an operator adds a CARRIER node to a graph,
he is requested to enter a carrier mnemonic, for example, "MCI,
30 ATT.
Fig. 44 -~hows an ex~mple of a graph using the carrier node.
BILLED NUMBER - The Billed Number (BN) node is an ASSIGNMENT
node which specifies a l0-digit number for the telephone number
that is to be billed for the call. To create the node, an
operator preferably specifie~ a l0-digit number in the NPANXXXXXX
format described above if the node is to contain the value.

2190~88
.



Fig. 44 is an example of graph utilizing the BN node. The
graph in Fig. 44 assigns a carrier, BN and RN for the "800~ number
identified as the key.
CONVERSATION nodes are used to request and receive
information from the calling party through the switch. They
assign the call variables that represent the message to played at
the switch and the number of digits to be collected from the
calling party. The predefined CONVERSATION node templates
10 generate the following nodes:
PIN GETlODIGITS PLAYANNC
PIN Node - The PIN (Perconal Identification Number) node is a
CONVERSATION node which reque~ts that an announcement, "Please
enter your Personal Identification Number," be played to a caller,
requesting that a four-digit code be entered by the caller. After
the caller enters the PIN number, the four digits become the value
for the "DIGITS" call variable in the incoming conversational TCAP
message that is returned to the application for further
processing.
A result decision node is used to branch the execution based
on the digits received.
Fig. 42 illustrates a graph using the PIN node. In the
graph, which-as' shown i8 a handover graph, the caller is requested
to input a four-digit PIN. If the result is 1234, the call is
25 routed, any other PIN an announcement is played, and the call
processing i 8 blocked.
GETlODIGITS Node - The GETlODIGITS node is a CONVERSATION
node that requests that an announcement be played to a caller to
request that the caller input a 10-digit telephone number. The
30 value for the GETlODIGITS node is a message number which becomes
the value for the announce call variable in an outgoing
conversational TCAP me~age. The digits entered by the operator
become the value for the DIGITS call variable in the incoming
conversational TCAP message that is returned to the application
35 for further processing.
An example of a graph including a GETlODIGITS node is shown,
for example, in Fig. 45. This service collects a ten-digit phor.e

219~888
.



number from the calling party and routes the call to that phone
number.
PLAYANNC - The PLAYANNC node allows an operator to specify an
S announcement message (that requests information from an operator
to be played to the caller when the call processing software
encounters this node (Fig. 38).
PROCEDURE nodes allow the execution to invoke a routine on
behalf of the graph being evaluated. For example, if an operator
10 wanted to log some information about the execution, he could call
a routine that he has written and invoke that through the
PROCEDURE node. The preferred predefined PROCEDURE nodes are as
follows:
HANDOVER PROCEDURE LOAD
STORE
HANDOVER Node - The HANDOVER node (HND) is a procedure node
which instructs the call processing software to leave the current
graph and move to another graph to continue the call processing.
The value for a HANDOVER node is the key (up to l0 characters) for
20 the HANDOVER graph. If an operator wishes to add a HANDOVER node
to a graph, he i~ requested to input the key for the HANDOVER
graph. ~ -
The contents of a HANDOVER graph may be as complex asnecessary to provide the requested service. The HANDOVER graph
25 may contain any of the nodes, including one or more HANDOVER
nodes. When finished processing a HANDOVER graph, control is
returned to the calling graph.
Fig. 39A illustrates a graph including a HANDOVER node. This
graph determines whether the call is ~ON~ or ~OFF~ the network
(NET). If ON, the call is routed. If OFF, exe~ution is
transferred to the graph having key ~offnet.hnd.~ Although the
HANDOVER node displays the syntax "HANDOVER" to the operator,
through graph manipulations (as described herein), the operator
can display the values of the HANDOVER node, which is ~offnet.hnd~
35 as shown in Fig. 39B.
STORE Node - The STORE node is a PROCEDURE node which allows
an operator to store values to the graph variables of a differe.r.;

21gO888
-



graph. The value for the STORE node is the key of another vali~
graph in the system database.
The STORE node is often used in conjunction with the LOAD
node when exchanging or updating call variable values from one
graph to another. Fig. 46 illustrates a graph using the STORE
node.
PROCEDURE Node - The PROCEDURE node is a PROCEDURE node which
allows an operator to select from a group of programming language
10 routines to perform certain call processing tasks. The value for
the PROCEDURE node is the name of the routine to be invoked. The
customer may want to call a special C routine to log data while
executing a graph. This would be facilitated through the
PROCEDURE node.
Fig. 47 illustrates a graph using the PROCEDURE node. In
this graph, the PROCEDURE node involves a routine to log
information about the call into a file. A routing number is then
assigned by the RN node.
LOAD Node - The LOAD node is a PROCEDURE node which allows an
20 operator to load all of the call variable values stored with a
different graph. Once the variables are loaded (e.g. after the
execution of~the LOAD node), the call processing software can then
use these variables. The LOAD node value is the graph key name
from which you are loading the variables.
To add a LOAD node to a graph, an operator is requested to
input a graph key name of another valid graph contained within the
system database. Fig. 46 illustrates a graph using the LOAD node.
This graph update~ a call forwarding number.

b. Templates
A template is a data structure containing some or all
information needed to specify and instantiate a node in a graph.
A node is instantiated when it is added to the internal data
structure representation. There are four types of templates; one
for each type of node. Thus, the preferred templates include a
DECISION node template, an ASSIGNMENT node template, a PROCEDURE
node template and a CONVERSATION node template. These templates

2190888



can be used to create any of the specific nodes identified a~ove,
or any other desired node.
A DECISION node template includes a title and a call
variable. When an operator desires to generate a DECISION node,
he selects the ~NEW DECISION" option in the template menu (see
Fig. 12), which prompts display of a dialog box 300, as
illustrated in Fig. 48A. The dialog box 300 includes a title
field 302 and a call variable field 304. The title field
identifies the title or name of the DECISION node template to be
created, and the call variable field 304 identifies either a ~wild
card~ or a call variable used by an instantiated node to perform
branch comparisons. A 'wild card" mar~s the call variable field
as unspecified. This unspecified field is subsequently specified
15 by an operator when the operator selects the template to
instantiate a node in a graph.
Every field in any template can be a wild card" which is
determined by the operator when instantiating a node. For
example, to create a time decision node, as shown in Fig. 48B, an
20 operator enters the title (time) into the title field 302, and the
call variable name (~time') into the call variable field 304. The
title and value are then used by the TEMPLATE module to generate a
TIME DECISION node template. Once the TIME DECISION node template
exists, an operator can add time decision nodes to a graph. In a
25 similar manner, an operator can build a l~date,l' "day," "ANI" or
any other DECISION node template and use the~e templates to add
nodes to a graph.
An ASSIGNMENT node template includes a title, a first call
variable (which i~ assigned a value), and a second c811 variable
30 or value (which is assigned to the first call variable). An
operator desiring to generate an ASSIGNMENT node template selects
the "NEW ASSIGNMENT" option in the template menu (see Fig. 12)
which prompts display of a dialog box 306, as illustrated in Fig.
49A. The dialog box 306 includes a title field 308, a first call
35 variable field 310 and a second call variable or value field 312.
The title field 308 identifies the title or name of the ASSIGNMENT
node template to be created, the first call varisble field 310
identifies a ~wild card~ call variable which i~ assigned a value,

21gO888

- 39 -


and the second call variable or value field 312 identifies a ~i
cardl' or a call variable or value which is assigned to the fl-s~
call variable.
S For example, to create a CARRIER assignment node template, as
shown in Fig. 49B, an operator enters the title (carrier) in the
title field 308, enters the call variable (carrier) into the fl-st
call variable field 308 and enters the "wild card~ "? carrier
into the second call variable or value field 312. For example,
the operator may input a three digit acronym corresponding to any
long distance carrier company as the value for this "wild card.
This information is used by the TEMPLATE node to generate a
CARRIER assignment node template, which can be selected by an
operator to add CARRIER nodes to a graph.
A PROCEDURE node template includes a title and the name of a
routine called by this node to execute an identifiable
functionality. When an operator desires to generate a PROCEDURE
node template, he selects the " NEW PROCEDURE" option in the
template menu (see Fig. 12) which prompts display of a dialog box
314, as shown in Fig. 50A. This dialog box 314 includes a title
field 316 and a routine field 318. The title field 316 indicates
the title of the procedure node template to be created, and the
routine field 318 identifies a program routine to be called when
this node is generated. For example, as~ume sn operator has a
program routine n~med "log data~- which records information about
call processing to a file. To create a PROCEDURE node template
which calls this routine, as shown in Fig. 50B, the operator
inserts the title tlog data) and routine (log data) into fields
316 and 318 of the dialog box 314. The operator can then use this
node template to insert this node into a graph to call the
routine.
A CONVERSATION node template includes a title, an
announcement to be played to a caller and a field representing the
number of digits to be collected from the caller. ~hen an
operator desires to generate a PROCEDURE node template, he selects
the NEW CONVERSATIONAL" option in the template menu (see Fig. :2)
which prompt~ display of a display box 320, as ~hown in Fig. 5 lA.
This dialog box 320 include~ a title field 322, an announcemen~

2190888

- 40 -


field 324 and a digits field 326. The title field indicates the
title of the CONvERSATION node to be created, the announcement
field identifies the announcement to be played to the caller and
the digits field 326 specifies the number of digits the calle~
should input in response to the announcement.
For example, to create a CONVERSATION node template which
prompts the caller to enter a four digit personal identification
number (PIN), as shown in Fig. 51B, the operator enters ~PIN~ into
the title field 322, enters an index number to a message set to be
announced or displayed in announcement field 324, and enters the
number of digits comprising the PIN into the digitq field 326.
This PIN node template can be inserted into a graph to prompt a
caller to input a PIN during execution of the graph.

c. Editin~
Fig. 52 is a flow diagram illustrating a general editing
operating procedure performed by service creation portion 54 to
build a graph after the graph has been initiated. This flow
20 diagram is generic to each of the "EDIT" menu options 140 shown in
Fig. 24. Specific flow diagrams for each of the "EDIT" menu
options are described below.
Initially, the operator selects an ob~ect on the screen to be
edited ~step 700). CONTROL module 106 responds by calling SCREEN
25 module 102 to highlight the selected ob~ect (step 702). In a
preferred embodiment, this highlighting i8 done by changing the
color of the selected ob~ect. The operator then selects the
"EDIT" menu (step 704) to display the "EDIT" menu options as shown
in Fig. 24 (step 705). From thoqe options the operator selects
30 the desired "EDIT" menu option (step 708), and CONTROL module 106
responds by calling a routine or module that controls the selected
"EDIT" option (step 710). The called routine or module then edits
the internal data structure representation according to the
selected EDIT option (step 712).
CONTROL module 106 then calls OBJECT TABLE module 110 to
translate the edited internal data structure representation into
the abstract display representation (step 714), and finally c21 â
the SCREEN module 102 to translate the abstract di~play

2190888

- 41 -


representation into the display representation of the graph (s~ep
716).
Fig. 53 is a flow diagram illustrating the operation of
S service creation portion 54 for adding a node to a graph. Steps
700-708 of Fig. 7A are repeated, except that the operator selects
the ADD NODE option in the "EDIT" menu. CONTROL module 106
responds by calling GRAPH AND NODE CONTROL module 70 to
orchestrate the ADD procedure (step 718). GRAPH AND NODE CONTROL
10 module 70 calls OBJECT module 112 to determine which node
corresponds to the selected ob~ect (step 720). GRAPH AND NODE
CONTROL module 70 then calls DIALOG module 104 to display a list
of available nodes (step 722). The operator selects the desires
node, and TEMPLATE module 72 calls DIALOG module 104 to prompt the
operator for information to complete the template corresponding to
the selected node (step 724). CONTROL module 106 then calls NODE
module 64 to allocate memory for the new node (step 726).
Next, GRAPH AND NODE CONTROL module 70 calls TEMPLATE module
72 to make a node data structure from the completed template
information (step 728). GRAPH AND NODE CONTROL module then calls
GRAPH module 62 to add the node data structure to the internal
data structure-representation (step 730). GRAPH AND NODE CONTROL
module 70 then calls NODE module 64 to link the new node to its
parent and child nodes (if any) (step 732). Steps 714 and 716 are
then performed to translate the internal data structure
representation into the abstract displayed representation and to
display the graph.
Fig. 54 is a flow diagram illustrating the operation of
service creation portion 54 for adding a branch to a graph.
Initially, steps 700-708 and 718 are performed, except that the
operator selects the ~ADD BRANCH" option. GRAPH AND NODE CONTROL
module 70 calls TEMPLATE module 72 to determine which template
corresponds to the selected node (step 734). To do thiC, the
fields of the node are matched to each field of each template.
The template which mo~t completely matcheg the node is selected as
the corresponding template.
TEMPLATE module 72 then calls DIALOG module 104 to prompt the
operator for a branch value or values (step 736). Next, GRAPH AND

2190888


- 42 -


NODE CONTROL module 70 calls NODE module 64 to create a branch
data structure with the associated parameters (step 738). Steps
714 and 716 are then repeated to translate the internal data
5 structure representation into an abstract displayed representation
and into the displayed graph.
Fig. 55 is a flow diagram illustrating the operation of
service creation portion 54 for editing a value in the graph.
Initially steps 700-708 and 718 are performed except that the
10 operator selects the 'EDIT" option. Then, step 734 from Fig. 54
is performed. Next, GRAPH AND NODE module 70 determines if a
branch or node is being edited (step 740). If a node is being
edited, TEMPLATE module 72 calls DIALOG module 104 to prompt the
operator for information to modify the template for the selected
node (step 742). Subsequently, steps 728-732, shown in Fig. 53,
are performed, and steps 714-716 are performed to translate the
internal data structure representation into an abstract displayed
representation and to display the graph on the screen. If in step
740 it is determined that a branch is being edited, step 736 shown
in Fig. 54 is performed. GRAPH AND NODE module 70 then calls NODE
module 64 to edit the branch data structure with associated
parameters (~step 744). Steps 714-716 are then performed.
Fig. 56 is a flow diagram illustrating the operation of
service creation portion 54 for connecting one node of a graph to
another node in the graph. This is a convenience feature which
allows an operator to refer to a first portions of the completed
graph to complete another portion of the graph without duplicating
the first portion of the graph.
Initially, steps 700-704 are performed except that the
30 operator selects the "CONNECT option. CONTROL module 106 then
determines whether the selected ob~ect represents a node (step
744). If the selected ob~ect does not represent a branch or non-
DECISION node, processing is done (step 746). If the selected
object represents a node, CONTROL module 106 sets a connect flag
(not shown) for the displayed window (step 748). The operator
then selects an existing node in the graph to which to connect ~.e
selected ob~ect ~step 750). Step 702 is then performed. CONTRO_
module 106 then determines whether the connect flag is set (ste?

21gOg88

- 43 -


752). If the connect flag is not set, the ~clicked-on object
becomes the selected object (step 754). If the connect flag is
set, CONTROL module 106 calls G~APH AND NODE CONTROL module 70 and
passes graph, first-selected ob~ect and selected-node information
to GRAPH AND NODE CONTROL module 70 (step 756). GRAPH AND NODE
CONTROL module 70 calls NODE module 64 to link the selected object
and the selected node together (~tep 758). Once this is done,
steps 714-716 are performed to display the graph.
Fig. 57 is a flow diagram illustrating the operation of
service creation portion 54 to llhide" a portion of the displayed
graph. To "hide" a portion of the graph means to delete it from
the displayed graph without deleting it from the other
representations of the graph.
Initially, steps 700-708 and 718 are performed except that
the operator selects the "HIDE" option. GRAPH AND NODE module 70
then calls NODE module 64 to set the ~'hide~ flag for the selected
object in the data structure graphical representation. Steps 714-
716 are then performed to display the graph. However, in this
embodiment during step 714, O~JECT TABLE module 110 determines if
the hide" flag has been set for each node. Since, in our
example, thé.~lhide~' flag has been ~et, OBJECT TABLE module 110
does not translate any of the children nodes of the node for which
the hide flag has been set into the abstract displayed
representation of the graph. This prevents its further
translation onto the screen such that this portion of the graph
appear~ hidden. This is advantageous if the CCPI records is large
and has many branches.
Fig. 58 is a flow diagram illustrating the operation of
service creation portion 54 for deleting a predetermined portion
of a graph. Initially, steps 700-708 and 718 are performed except
that the operator selects the ~' DELETE SUBTREE " option. GRAPH AND
NODE CONTROL module 70 then calls GRAPH module 62 to delete the
selected node and all its children from the graph (step 762).
GRAPH AND NODE CONTROL 70 module calls NODE module 64 to break the
links between the nodes which are to be deleted and the nodes
which remain in the graph in the internal data structure

2190~88

- 44 -


representation (step 764). Steps 714-716 are then repeated to
display the graph.
Fig. 59 is a flow diagram illustrating the operation of
5 service creation portion 54 to delete one node from a graph.
Initially, steps 700-708 and 718 are repeated except that the
operator selects the " DELETE NODE " option. GRAPH AND NODE module
70 determines whether or not the selected node has more than one
parent or more than one child. If yes, this operation is not
10 completed and processing is finished (step 767). If not, CONTROL
module 106 calls GRAPH module 62 to remove the node from the
internal data structure representation (step 768). CONTROL module
106 then calls NODE module 64 to link the selected node'~ parent
to its child (step 770). Steps 714 and 716 are then repeated to
15 display the graph.
Using the foregoing operations, an operator can create a
graph to provide any desired service. If instead of creating a
new graph an operator desires to open an exi~ting stored graph,
the operation of ~ervice creation portion 54 is as shown by the
20 flow diagram in Fig. 60.
Initially, the operator displays the GRAPH menu options and
selects the "OPEN" option (step 500). CONTROL module 106 responds
by calling DIALOG module 104 to display the corresponding dialog
box shown in Fig. 18 (~tep 502). The operator then inputs the
"key" of the graph he desireY to open (step 504) and CONTROL
module 106 calls GRAPH module 62 to allocate memory for the
internal data structure representation of the graph to be
displayed (step 506). GRAPH BUFFER module 78 then calls DATABASE
module 98 to read the binary information corresponding to the
30 graph from the database (such as database 42 in Fig. 4A) (step
510 ) . ` GRAPH module 62 calls GRAPH BUFFER module 78 to tranclate
the binary representation of the graph into the internal data
structure representation of the graph (step 512). Next, CONTROL
module 106 calls OBJECT TABLE module 110 to translate the internal
35 data structure representation of the graph into the abstract
displayed representation (ctep 514), and calls SCREEN module 102
to translate the abstract displayed representation of the graph
into the displayed graph format (step 516).

- 2190888

- 45 -


Fig. 6l is a flow diagram illustrating the operation of
service creation portion 54 to save a graph to a database.
Initially, the operator displays the graph menu options shown n
S Fig. 16 (step 600), and selects the "SAVE" option (step 602). In
response, CONTROL module 106 calls GRAPH module 62 to 'unlo2d the
internal data structure representation of the graph (step 604).
GRAPH module 62 calls GRAPH BUFFER module 78 to "unload~' the
binary representation of the graph (step 606). GRAPH BUFFER
module 78 calls DATABASE module 98 to write the binary representa-
tion of the graph to the database 42 (step 608).
If a graph is to be saved according to a new name (such as
when a graph has been changed and is to be correspondingly renamed
(a new "key")), step 602 in Fig. 61 is changed in that the
operator instead selects the "SAVE AS" option and an additional
step (not shown) is added between steps 602 and 604 in which
CONTROL module 106 calls DIALOG module 104 to display a dialog box
(not shown) prompting the operator to input the new "key" for the
graph.
D. Service Creation Usinq "976 Call Screeninq" Interface
Operation of service creation portion 54 for creating a 976
form interface will now be discussed with regard to Fig. 2. To
create a "976" call screening service, an operator selects the 976
form option of the INTERFACE menu as shown in Fig. 32. A blank
"976" call screening form similar to that illustrated in Fig. 2,
but excluding the completed information, then appears on the
screen. The "976" call screening form 8 includes a cUctomer ~ey
70, a general extension menu 72, comprising screen option 74,
30 permit option 76 and time of day parameter 78, and a plurality of
special menus 80 including phone parameter 82, screen option 74,
permit option 76 and time parameters 78. The "976" call screening
form 8 also includes a PIN override option 86, as well as a PIN
parameter 88, and "save "load' "new" and exit" options 90, 92,
94 and 96, respectively.
An operator simply inputs the appropriate information and
selects the appropriate options to provide the desired ~976' C2'
screening service. Once the operator has input the informat~on s

2190888

- 46 -


complete the '976' call screening form, PROVISION module 114
analyzes the information and calls the appropriate modules in t~e
internal data structure representation to translate the
S information into the internal data structure representation. This
internal data structure representation can be translated into the
binary representation just as in the case with the corresponding
graphs as shown in Fig. 1. To display the 976" call screening
form, PROVISION module 114 translates the internal data structure
10 representation into the abstract displayed representation, and
then SCREEN module 102 translates the abstract displayed
representation into the displayed 976" call screening form 8.

E. Call Processinq
Call processing portion 56 shown in Figs. 4A-4D preferably
comprises all the modules corresponding to the binary
representation of a CCPI record as shown in Fig. 6B, although
preferably, calls are predominately processed by COMMUNICATE
module 84, MESSAGE HANDLER module 86 and CALL CONTEXT module 88.
Fig. 62 is a functional block diagram of call processing
portion 56. Preferably, call processing portion 56 includes
COMMUNICATE module 84, MESSAGE HANDLER module 86, CALL CONTEXT
module 88, message handler input queue 906, message handler output
queue 908, call input queue 910, call output queue 912 and
conversational calls queue 914. COMMUNICATE module 84 is
connected to message handler input queue 906 and message handler
output queue 908, and receives and outputs messages to a remote
device, such as a switch or switch simulator. MESSAGE HANDLER
module 86 is connected to message handler input queue 906, message
30 handler output queue 908, call input queue 910, call output queue
912 and conversational calls queue 914. CALL CONTEXT module 88 is
connected to call input queue 910, call output queue 912 and
database 60. A description of the operation of the call
processing application will now be provided in con~unction with
Fig. 62 and the flow diagramQ of Figs. 63A-67.
Figs. 63A and 63B are flow diagram~ of the call processing
operations of COMMUNICATE module 84. COMMUNICATE module 84 con-
tinuously monitor~ an input port (not shown) for messages from z

2190~88

- 47 -


remote device. In one embodiment, COMMUNICATE module responds to
.eO4, .eO5. and .eO2 messages in accordance with AIN release 0.
In another embodiment, COMMUNICATE module 84 responds to other
messages input from the remote device, including those messages
provided for in future AIN releases such as AIN releases 1 and 2.
In Fig. 6 3A, COMMUNICATE module 84 determines whether any
messages are available for processing (step 1000). If not, CO.~U-
NICATE module 84 continues to look for a message to be processed.
If a message is available for processing, COMMUNICATE module 84
reads the message (step 1002) and places the message onto message
handler input queue 906 (step 1004). COMMUNICATE module 84 then
continues to look for a new message to be processed.
In Fig. 63B, COMMUNICATE module 84 loo~s for any messages on
message handler output queue 908 (step 1006). If no message
exists, COMMUNICATE module 84 continues to look for messages. If
a message is on message handler output queue 908, COMMUNICATE
module 84 gets the message (step 1008) and sends the message to
the remote device (step 1010). COMMUNICATE module 84 then
continues to look for messages on message handler output ~ueue
908.
Fig. 64A illustrates the call processing operation of MESSAGE
HANDLER moduie 86. MESSAGE HANDLER module 86 looks for messages
on message handler input ~ueue 906 (step 1100). If no message is
available, MESSAGE HANDLER module 86 continues to loo~ for
messageR. If a message is on message handler input queue 906,
MESSAGE HANDLER module 86 gets the message (step 1102) and
determines whether the message is a conversational response (step
1104). If the mes~age is not a conver~ational response, MESSAGE
30 HANDLER module 86 determines the appropriate CCPI record needed to
respond to the message (step 1108) and generates a call context
corresponding to the message (step 1110).
As shown in Fig. 6S, call context 160 maintains information
corresponding to the execution of a call during call processing.
This information includes message identification number 162, call
status 164, (e.g. active, wait, new or conversational), stack
index 166, number of node~ processed 168, a list of call varia~ e

2190888

- 48 -


170 and call state stack 172. Call stack 172 may contain one o-
more call states 174.
A call state 174 maintains information corresponding to the
execution of an individual CCPI record during call processing. As
shown in Fig. 66, The information maintained by call state 174
includes the "key" of the CCPI record 176, the CCPI record 178 and
the execution offset 180 which corresponds to the current location
of the execution in the CCPI record.
Once a call context 160 has been generated, MESSAGE HANDLER
module 86 place~ call context 160 onto call input queue 910 (step
1112) and the call processing operation of MESSAGE HANDLER 86
module shown in Fig. 64A is repeated. If in step 1104 it is
determined that the message is a conversational response, MESSAGE
HANDLER module 86 gets the corresponding call context from
conversational calls queue 914 (step 1106) and places call context
160 onto call input queue 910 (step 1112).
Fig. 64B illustrates another call processing operation per-
formed by MESSAGE HANDLER module 86. MESSAGE HANDLER module 86
determines whether a call context 160 is on call output queue 912
(step 1114). If not, MESSAGE HANDLER module 86 continues to look
for a call context 160. If a call context 160 is on call output
queue 912, MESSAGE HANDLER module 86 gets the call context 160
(step 1116) and determines whether call context 160 is
conversational (step 1118).
If call context 160 is conversational, call context 160 is
placed on conversational calls queue 914 (step 1124) until, as
described with regard to Fig. 64A, an input message corresponding
to call context 160 is again processed by MESSAGE HANDLER module
86. If call context 160 is not conversational, MESSAGE HANDLER
module 86 generates a message from call context 160 ( step 1120)
and places the message on message handler output queue 908 (step
1122). The call processing operation shown in Fig. 643 is then
repeated by MESSAGE HANDLER module 86.
Fig. 67 illustrates a flow diagram of the call processing
operation performed by C~LL CONTEXT module 88. CALL CONTEXT
module 88 monitors call input queue 910 for a call context 160
(step 1200). If no call context 160 is on call input queue 910,

2190888
-



- 49 -


CALL CONTEXT module 88 continues to look for a call context 160
If a call context 160 is on call input queue 910, CALL CONTEXT
module 88 gets call context 160 (step 1202) and determines whethe~
call context 160 has been processed previously (step 1204). If
not, CALL CONTEXT module 86 calls GRAPH BUFFER module 78 (not
shown in Fig. 67) to get the corresponding CCPI record from
database 60 (step 1206). CALL CONTEXT module 86 then creates a
call state 174 to manage the execution of that CCPI record and
pushes the call state 174 onto call state stack 172 of call
context 160 (step 1207).
If in step 1204 call context 160 has previously been
processed, CALL CONTEXT module 88 determines whether execution of
the CCPI record is complete (~tep 1208). This is done by checking
the execution offset 180 in call state 174.
After creating and pushing a call state 174 onto call state
stack 172 in step 1207, CALL CONTEXT module 914 also determines
whether execution of the CCPI record is complete (step 1208). If
the CCPI record has not been completely executed, call MODULE 88
executes one node of the CCPI record (step 1210). After executing
a node, CALL CONTEXT module 88 determines whether the node is a
CONVERSATION node (step 1212). If so, CALL CONTEXT module 88
places the call context 160 onto call output queue 912 (step
1214), which halts the execution of the CCPI record.
If the node i8 not a CONVERSATION node, CALL CONTEXT module
88 determine~ whether the node processed is a "handover node"
(step 1213). As explained above, a '~handover node" temporarily
hands the call processing over to another graph identified as the
value in the ~handover node.~ If the executed node is a
"handover" node, CALL CONTEXT module 901 repeats step 1206 to get
the CCPI record corresponding to the ~key~ value identified in the
~'handover node,~ and ~tep 1207 to create a new call state and push
this new call state onto the call ~tate stack 172. Since CALL
CONTEXT module 88 executes the CCPI record on top of the call
state stack 172, if in step 1213 it is determined that the
executed node is a "handover node1~ when the call processing
routine returnC to step 1208, it i~ executing the new CCPI recor~
However, if in ctep 1213 it is determined that the node execute~

2190888
.
- 50 -


is not a l~handover node," when the call processing routine
returns to step 1208, it continues executing the origlnal CC
record.
If in step 1208, CALL CONTEXT module 88 determines ~hat the
CCPI record has been completely executed, CALL CONTEXT module 88
then determines whether there is more than one call state 174 on
the call state stack 172 (step 1215). If not, CALL CONTEXT module
88 puts the call context 160 onto call output queue 912 (step
1214), and the call processing routine returns to step 1200.
If, in step 1215, it is determined that more than one call
state 174 is on call state stack 172, CALL CONTEXT module 88
'pops" the top call state from call state stack 172 (step 1216)
and executes the CCPI record corresponding to that call state
(step 1208). This allows one CCPI record to "hand over~ to
another CCPI record and then return to execution of the original
CCPI record.
The complete call processing operation for a single call will
now be described with regard to Fig. 62. In this example, it is
assumed, for sake of description, that the CCPI record contains a
CONVERSATION node requesting the caller to input a personal
identification number (PIN) (as shown in the graph of Fig. 42).
Also, in this example, it is assumed that the graph "key~ is
3151234567.eO4. The remainder of the graph is as shown in Fig.
42.
~ he graph shown in Fig. 42, with the above change, has been
created and stored as a CCPI record in database 60 at SCP 18.
When ASC switch 12 receives a phone cAll from a phone having a
phone number (315)123-4567, it sends a TCAP message to SCP 18.
30 COMMUNICATE module 84 reads the me~sage and places it onto message
handler input queue 906. MESSAGE HANDLER module 86 gets the
message from message handler input queus 906 and initially
determines whether the message is a conversational respon~e. In
this example, the message is not a conversational response, so
35 MESSAGE HANDLER module 86 identifies the CCPI record needed to
respond to the message based on the key 31S1234567.eO5, and
generates a call context corresponding to thiq message. ~.ESSAG_

2190888




HANDLER module 86 then places the generated call context onto cal
input queue 910.
CALL CONTEXT module 88 is looking for a call context on call
5 input queue 910. When the call context is placed onto call input
queue 910, it is read by CALL CONTEXT module 88 which initially
determines whether this call context has been processed
previously. Since, in this example, this call context has not
been previou~ly processed, CALL CONTEXT module 88 calls GRAPH
10 BUFFER module 78 to get the corresponding CCPI record from
database 60 and creates a call state which is pushed on to the
call state stack. CALL CONTEXT module 88 then executes the first
node of the CCPI record. As shown in Fig. 42, the first node is a
CONVERSATION node. Therefore, when CALL CONTEXT module 88
15 inquires whether this node is a CONVERSATION node, execution of
the CCPI record is halted and the CALL CONTEXT module places the
call context onto call outp~t queue 912.
MESSAGE HANDLER module 86, which i8 looking for a call
context on call output queue 912, reads the call context once it
20 has been placed on call output queue 912. MESSAGE HANDLER module
86 then inquires whether the call context is conversational.
Since the call context is conversational in this example, MESSAGE
HANDLER moduLe-86 places the call context onto conversational
calls queue 914, and generates a message from the call context to
25 prompt the operator to input a PIN. This message is placed onto
message handler output queue 908.
COMMUNICATE module 84 gets the message from message handler
queue 908 and sends the message back to ASC switch 12. The call
processing operation then continues to process other messages from
30 SCp 18
In response to the PIN input by the operator, ASC switch 12
again sends a message to SCP 18. COMMUNICATE module 84 reads this
message and places it onto message handler input queue 906.
MESSAGE HANDLER module 86 gets this message from queue 906 and
35 determines whether the message is a conversational response. In
this example, the PIN input by the caller is a conversational
response, and therefore, MESSAGE HANDLER module 86 gets the
corresponding call context from conversational calls queue 914.

2190888

- 52 -


This call context is placed onto call input queue 910 for further
processing by CALL CONTEXT module 88.
CALL CONTEXT module 88 reads the call context from call 1nput
queue 910 and determines whether this call context has been
previously processed. Since this call context has previously been
processed in this example, the CCPI record is not retrieved from
database 60. Instead, CALL CONTEXT module 88 determines whether
execution of the CCPI record is complete. Since, in this example,
the CCPI record has not been completely executed, the next node of
the CCPI record is executed. Each of the nodes of the CCPI record
is then executed.
In this example, it is assumed that the operator input PIN
1234. As illustrated by the graph of Fig. ~2, CALL CONTEXT module
lS 88 determines from the execution of the CCPI record that the call
from phone number (315)123-4567 should be routed, adds this
information to the call context and places the call context onto
call output queue 912. MESSAGE HANDLER module 86 reads the call
context and, determining that the call context is not
conversational, generate~ a message from the call context to
inform ASC switch 12 to route the call. MESSAGE HANDLER module 86
places this message onto message handler output queue 908.
COMMUNICATE module 84 then reads the message from queue 908 and
sends it to ASC switch 12.

F. Enhanced Call Proce~sinq For Visual
IndicAtion of Executed GraPh
Having created a graph, an operator can test the graph by
processing a call generated by a switch or switch simulator prior
to deploying the CCPI record into the AIN network 10. This
testing can be done on SMS 20, PC 22, SCP 18, SN 16 or adjunct 1~,
provided these device~ contain a CS application 46 comprising call
processing portion 56 and a switch or switch simulator.
Although such a test indicates which call processing was
performed correctly, if the call processing was performed
incorrectly, the test does not indicate the reason that the c211
processing failed. Accordingly, another embodiment of the prese-.
invention provides for a visual indication of the execution p2; -


2190888

- 53 -


taken through a graph while processing a call. This embodiment
preferably uses an application comprising an enhanced call
prdcessing portion and can be implemented on the SMS 20, PC 22,
5 SCP 18, SN 16 or ad~unct 14.
The visual indication can be provided at any of these devices
provided a CS application 46 comprises service creation portion 54
and an operator interface 44 are provided at that device. Thus,
the visual indication of the execution path on the graph can be
10 provided at the device performing the call proce~sing (local
visual indication) or at a device remote from the device
performing the call processing (remote visual indication). The
visual indication can be provided for call processing in a testing
mode or in the AIN network 10.
In a preferred embodiment, the visual indication comprises
highlighting the execution path as taken during call processing
directly on the graph, preferably as a red line connecting the
graph nodes executed to process the call (referred to herein as a
~trace"). However, any other type of highlighting can be used to
20 identify the execution path on the graph. Alternatively, the
execution path taken through a CCPI record may be visually
indicated by displaying the execution path one node at a time
(referred to herein as the "step" indication). Preferably, when a
~step' indication is performed, the "trace~ is also provided.
In a preferred embodiment, the present invention provides for
the '~trace~ and "step~ visual indications by enhancing the call
processing operstion performed by CALL CONTEXT module 88 as shown
in Figs. 68A and 68B. However, the processing operations of
COMMUNICATE module 84 and MESSAGE HANDLER module 86 remain the
30 same as described above. For the enhanced call processing of
Figs. 68A and 68B, steps 1200-1216 are identical to those shown
for the call processing of Fig. 67. However, for enhanced call
processing, after creating a call state for the CCPI record and
pushing the call state into the call state stack, CALL CONTEXT
35 module 88 determines whether any of the "global" or "record,"
step" or trace" flags are set (step 1300).
~ Global~ flags refer to flags corre~ponding to a plurality o~
CCPI records. If a "global' flag is set, the execution path ta~e-.

219~888




through the CCPI record is stepped through or traced for every
CCPI record executed depending on the flag selection. "Recordl~
flags refer to flags corresponding to each individual CCPI record.
5 If a ~record" flag is set for a CCPI record, the corresponding
graph is displayed and the execution path taken through the graph
is stepped through or traced depending on the flag selection when
a call is executed by enhanced call processing portion 56 in
either a creation environment (local) or a call processing
10 environment (which includes an application comprising only
enhanced call processing portion 56 and no operator interface;
remote).
'IGlobal,~' "step" and ~'trace~' flags are preferably set by the
operator in accordance with the flow diagram shown in Fig. 69.
15 Initially, the operator displays the main interface window and
selects the "OPTIONS" menu (step 1400). In response, CONTROL
module 106 displays the "OPTIONS~' menu options, as shown in Fig.
13 (step 1402). The operator then selects the "EXECUTION" option
(step 1404), and CONTROL module 106 then calls DIALOG module 104
20 to display a dialog box (not shown) prompting the operator to
select either the "step" or "trace" option (step 1406). The
operator then selects the "trace" or "step" option (step 1408).
The corresponding "global'~ flags are set by CONTROL module 106
(step 1410).
"Record" flag~ are preferably set by the operator in
accordance with the flow diagram illustrated in Fig. 69 except
that in step 1400 the "OPTIONS" menu 144 is selected from the
graph edit pad window as chown in Fig. 29. In addition, after the
flags are set, the operator performs a "SAVE" operation a~
30 described above, to set the record," trace or step flag. If the
CCPI record corresponding to the graph is to be call processed at
a remote call processing environment, MAIL module 100 transfers
the CCPI record from the creation environment to the remote call
processing environment.
Referring back to step 1300 in Fig. 68A, if none of the
'~global~ or "record,' "~tep" or trace~ flag~ is qet, CALL CONTEXT
module 88 determines whether the CCPI record has been completely
executed (step 1208). If either the 'global' or record," trace

` ~ 2190888



or ~step flag is set CALL CONTEXT module 88 determines whether
the enhanced call processing operation is being performed in a
creation environment (step 1301). This determination is made
based on an environment flag.
As explained above, a creation environment includes a display
48 and service creation portion 54. Therefore, for viewing the
graph when call processing in the creation environment, the visual
indication is provided at the creation environment.
If, for example, the call processing environment may not
include a display 48, the execution results of the call processing
are preferably sent to a creation environment for display. Thus,
different actions are taken by the enhanced call processing
portion 56 depending on the environment in which the enhanced call
processing i~ being performed.
If, in step 1301, the enhanced call processing is performed
in a creation environment, CALL CONTEXT module 88 displays the
graph edit pad window and associates the call context with the
graph edit pad window (step 1302). If, in step 1301, the enhanced
20 call processing is performed in a call processing environment, the
CALL CONTEXT module 88 opens a file for the call context (step
1304) to record execution information.
CALL CONTEXT module 88 then determines whether the CCPI
record has been completely executed (step 1208). If so, CALL
25 CONTEXT module 88 performs step~ 1215, 1214 and 1216, as discussed
with regard to Fig. 67. If not, the next node is executed (step
1210).
After executing a node, CALL CONTEXT module 88 again
determines whether the ~globall~ "record" trace or step flags are
30 set (step 1306). If not, CALL CONTEXT module 88 repeats step
1208. If one of these flags is set, however, the determination of
step 1301 is repeated.
If the call processing is being performed in a creation
environment, CALL CONTEXT module 88 calls NODE module 64 to set a
35 flag in the internal data structure representation of the graph
indicating that node has been processed (step 1308). As described
above, changes to the internal data structure representation 2~_
reflected up through the abstract displayed representation, anc

2190888

- S6 -


displayed on the screen. Thus, when performing enhanced call
processing at a creation environment, the setting of a flag in the
internal data structure representation after processing a node is
reflected as a highlighting between the processed nodes on the
displayed graph. If the enhanced call processing is instead being
performed at a call processing environment without a display or
service creation portion 54, CALL CONTEXT module 88 updates the
file to indicate that the node has been executed (step 1310).
CALL CONTEXT module 88 then determines whether the processed
node is a CONVERSATION node (step 1212). If so, CALL CONTEXT
module 88 outputs the call context onto the call output queue 912
(step 1214). If not, steps 1213, 1206 and 1207 shown in Fig. 67
are performed.
After creating a call state and pushing the call state into
the call state stack, or if the processed node is not a handover
node, the enhanced call processing performs step 1301. If the
enhanced call processing is being performed in a call processing
environment, CALL CONTEXT module 88 returns to step 1208. If the
20 enhanced call processing i~ being performed in a creation
environment, CALL CONTEXT module 88 determines the "global"
~record~' step flags set (step 1312). If not, CALL CONTEXT module
88 repeats stép 1208. If so, CALL CONTEXT module 88 sets the
status flag of the call context to wait (step 1314) and returns
25 to step 1200.
Step 1314 cau~es execution of the CCPI record being call
processed to stop. Thus, if the call is being processed in a
creation environment, the execution path taken through the CCPI
record is visually indicated by di~playing one node at a time and
30 tracing the execution path between the nodes. The operator can
select the "STEP" option of the EXECUTE menu, shown in Fig. 30, to
execute the next node. When the operator selects the STEP option,
the call context for the corregponding CCPI record is placed on
the call input queue.
For enhanced call procescing~ after a call context has been
output to the call output queue g12 (gtep 1214), CALL CONTEXT
module 88 determinec whether either the ~global" or ~record~ trace

2190888




flags is set (step 1316). If not, CALL CONTEXT module 88 returns
to step 1200. If so, step 1301 is repeated.
If it is determined that enhanced call processing is bein~
5 performed in a creation environment, CALL CONTEXT module 88
returns to step 1200. If, however, it is determined that call
processing is being performed in a call processing environment
without a display 48 and service creation portion 54, the file is
sent to a creation environment (step 1318), and the processing of
10 CALL CONTEXT module 88 returns to step 1200.
Sending the file to a creation environment in step 1318
preferably causes a telephone window 121 to appear on the display,
as shown, for example, in Fig. 7. Window 121 indicates to the
operator that files corresponding to CCPI records executed at a
15 remote call processing environment have been sent to the creation
environment.
Fig. 70 is a flow diagram illustrating an operation to
provide a visual indication of the execution paths taken during
enhanced call processing at a remote call processing environment.
Initially, CONTROL module 106 receives the file (step 1600) and
calls GRAPH module 62 to update the internal data structure
representation of the graph with the information in the file (step
1602). The operator select~ the telephone window 121 on the
display (step 1604) and CONTROL module 106 calls DIALOG module 104
25 to display a corresponding dialog box shown in Fig. 71 (step
1606). The operAtor then selects the "key~ of the grsph to be
displayed (~tep 1608). Next, CONTROL module 106 calls OBJECT
TABLE module 110 to translate the internal dsta structure
representation of the graph into the abstract displayed
30 representation (atep 1610), CONTROL module 106 al~o call~ SCREEN
module 102 to draw the graph onto the display with a trace"
visual indication of the execution path in the grsph (step 1612).




21gO888

- 58 -


G. Validation
Validation is considered a separate operation from testing.
In testing, a visual indication of the processing is created so
that the operator can ensure that the procedure corresponding t~
the graph is proceeding as desired. Validation, on the other
hand, is intended to determine whether the necessary connections
have been allowed in creating the graph. In the preferred
embodiment, validation involvec use of an expert system.
Expert systems are available for detecting logical
infractions in a processing routine and generating a list of these
infractions based on a set of rules and a knowledge base
understood by the expert system. The pre~ent invention employs an
expert system to identify logical infractions in displayed graph
5.
Preferably, there are two types of infractions: "severe and
~warning. Severe infractionc are identified by the expert system
as problems that will produce erroneous call processing. Warning
infractions are identified by the expert system as problems that
may cause erroneous call processing.
The following is an exemplary list of rules utilized by an
expert system to identify in an embodiment of the invention
~severe and ~"warning" infractions in a graph.
l. Must have "other" branch for TIME, DATE, LATA nodes
(severe);
2. Must have all branch values for DAY node (severe);
3. DECISION node~ need more than one branch (severe);
4. Every cycle in the graph must have at least one DECISION
node (severe);
5. No DLN[x,y] node can precede a DLN~p,q] if x<p and y>q
(warning);
6. No ANI[x,y] node can precede an ANI~p,q] if x<p and y>q
(warning);
7. No duplication of ASSIGNMENT nodes on a single path
through the graph (warning);

~190888

.
- 59 -


8. SERVICE SPECIFIC RULES
800
a. no CONVERSATIONAL nodes allowed (warning);
Outqoinq call screeninq
b. no ROUTING NUMBER nodes allowed
Fig. 72 is a flow diagram, illustrating a preferred operation
of an expert system in accordance with the invention. Initially,
the operator selects an expert system menu (not shown in the
10 figures) (step 800). In response, CONTROL module 106 calls EXPERT
module 76 to translate the internal data structure representation
of the graph being displayed into a set of "schemas'~ corresponding
to the nodes of the graph and insert these schemas" into a
knowledge base understood by the expert sy~tem (step 802).
Using these "schemas," and rules, the expert system tests the
schemas according to a set of rules previously input to the expert
system, such as the rules specified above, and generates a list of
errors in the graph. The expert system also flags each node and
branch containing an error (step 804). Flagging the nodes and
20 branches changes the data ctructures of the internal data
structure representation of the graph.
CONTROL module 106 then calls OBJECT TABLE module 110 to
translate the~internal data structure representation into the
abstract displayed representation (step 806), and calls SCREEN
25 module 102 to translate the abstract di~played representation into
the displayed graph (step 808). The flagged nodes are highlighted
on the screen to identify the error nodes. Thu~, the operator can
readily identify errors in the graph and correct these errors if
necessary. In a preferred embodiment, the operator may also
30 select the highlighted node (step 810) to display a list of errors
for the highlighted node (step 812).
Examples of known expert systemg which can be used in accor-
dance with the present invention include the Automated
Reasoning Tool (ART) produced by Inference Corporation and the
35 Laser Expert System produced by Bell Atlantic Knowledge System
Corporation. Other expert systems are available and can be used
in accordance with the pre~ent in~ention.

2190g88
-
- 60 -


H. Summar~
While there has been illustrated and described what are at
present considered to be preferred embodiments and methods of the
5 present invention, it will be understood by those skilled in the
art that various changes and modifications may be made, and equiv-
alence may be substituted for elements thereof without departing
from the true scope of the invention.
In addition, many modifications may be made to adapt a par-
10 ticular element, technique or implementation to the teachings ofthe present invention without departing from the central scope of
the invention. Therefore, it is intended that this invention not
be limited to the particular embodiments and methods disclosed
herein, but that the invention include all embodiments falling
15 within the scope of the appended claims.





Representative Drawing
A single figure which represents the drawing illustrating the invention.
Administrative Status

For a clearer understanding of the status of the application/patent presented on this page, the site Disclaimer , as well as the definitions for Patent , Administrative Status , Maintenance Fee  and Payment History  should be consulted.

Administrative Status

Title Date
Forecasted Issue Date 1999-06-15
(22) Filed 1991-12-16
(41) Open to Public Inspection 1992-06-19
Examination Requested 1996-11-21
(45) Issued 1999-06-15
Deemed Expired 2011-12-16
Correction of Expired 2012-12-11

Abandonment History

There is no abandonment history.

Payment History

Fee Type Anniversary Year Due Date Amount Paid Paid Date
Application Fee $0.00 1991-12-16
Maintenance Fee - Application - New Act 2 1993-12-16 $100.00 1996-11-21
Maintenance Fee - Application - New Act 3 1994-12-16 $100.00 1996-11-21
Maintenance Fee - Application - New Act 4 1995-12-18 $100.00 1996-11-21
Maintenance Fee - Application - New Act 5 1996-12-16 $150.00 1996-11-21
Maintenance Fee - Application - New Act 6 1997-12-16 $150.00 1997-09-18
Registration of a document - section 124 $0.00 1998-09-11
Registration of a document - section 124 $0.00 1998-09-11
Maintenance Fee - Application - New Act 7 1998-12-16 $150.00 1998-09-16
Final Fee $300.00 1999-03-11
Maintenance Fee - Patent - New Act 8 1999-12-16 $150.00 1999-12-02
Maintenance Fee - Patent - New Act 9 2000-12-18 $150.00 2000-12-01
Maintenance Fee - Patent - New Act 10 2001-12-17 $200.00 2001-12-03
Maintenance Fee - Patent - New Act 11 2002-12-16 $400.00 2002-12-19
Maintenance Fee - Patent - New Act 12 2003-12-16 $200.00 2003-11-04
Maintenance Fee - Patent - New Act 13 2004-12-16 $250.00 2004-11-03
Maintenance Fee - Patent - New Act 14 2005-12-16 $250.00 2005-11-24
Maintenance Fee - Patent - New Act 15 2006-12-18 $450.00 2006-11-23
Maintenance Fee - Patent - New Act 16 2007-12-17 $450.00 2007-10-23
Maintenance Fee - Patent - New Act 17 2008-12-16 $450.00 2008-12-01
Registration of a document - section 124 $100.00 2009-02-26
Maintenance Fee - Patent - New Act 18 2009-12-16 $450.00 2009-11-10
Registration of a document - section 124 $100.00 2010-06-22
Registration of a document - section 124 $100.00 2010-12-01
Owners on Record

Note: Records showing the ownership history in alphabetical order.

Current Owners on Record
TTI INVENTIONS B LLC
Past Owners on Record
BABSON, DAVID LEVEAU, III
BABSON,DAVID LEVEAU, III
BAJZATH, JAMES ANDREW
BELL COMMUNICATIONS RESEARCH, INC.
ELY, THOMAS CHAMBERS
TELCORDIA LICENSING COMPANY LLC
TELCORDIA TECHNOLOGIES, INC.
Past Owners that do not appear in the "Owners on Record" listing will appear in other documentation within the application.
Documents

To view selected files, please enter reCAPTCHA code :



To view images, click a link in the Document Description column. To download the documents, select one or more checkboxes in the first column and then click the "Download Selected in PDF format (Zip Archive)" or the "Download Selected as Single PDF" button.

List of published and non-published patent-specific documents on the CPD .

If you have any difficulty accessing content, you can call the Client Service Centre at 1-866-997-1936 or send them an e-mail at CIPO Client Service Centre.


Document
Description 
Date
(yyyy-mm-dd) 
Number of pages   Size of Image (KB) 
Description 1992-06-19 60 2,923
Cover Page 1997-03-20 1 21
Abstract 1992-06-19 1 24
Drawings 1992-06-19 59 986
Cover Page 1999-06-08 1 45
Claims 1992-06-19 1 25
Representative Drawing 1999-06-08 1 8
Correspondence 1999-03-11 1 40
Assignment 2009-02-26 5 137
Assignment 2010-06-22 12 574
Assignment 2010-12-01 17 721
Assignment 1996-11-21 2 75
Prosecution-Amendment 1996-11-21 1 60
Prosecution-Amendment 1998-04-09 1 51