Note: Descriptions are shown in the official language in which they were submitted.
~WO 92/11603 2 0 9 8 ~ 0 8 PCr~US91/09457
Systems and Proccsses for Specifying Customized
Telecommunication Services
Background of thc Invention
The present invention relates generally to the field of
5 providing customized services, and more specifically to the problem of
providing customized telephone 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 developcd, the
10 economics of developing and implementing that service require that the
service be provided on a mass scale to as many customers as possible.
Oftentimes, even if a service is desired by some customers,
WO 92/11603 2 0 9 8 ~ 0 8 PCr/US9t/09457
-- 2 --
. -~ .' ': --
f;~
the servicQ may nevQr be i ~ ted if that service cannot
be mass marketed, or otherwise e. ~cal ly ~ustified.
T~l~phnn~ functions are presently provided to a
S customer by allowing that customer to select desiredfunctions from a limited number of available services. This
approach, which has been called p~ ng a service, may
leave many customers without desired functionality. For
~xample, a customer who wants c~ll waiting, but in a form
10 slightly different from what is made 3 - 1 ly f~vailable, may
be told that his simple requests cannot be met.
~ If~e vve5 ~ fldding a new service to existing services
cre_tQs significant problems due to possible interaction
between the new and existinq services. This creates
5 ~dditional ob~tacles to ~ ting new tQl e~honQ services .
For example, it is very possible that adding fl new service,
such as call waiting, may be incompatible in certain
circumstances with an existing ~ervice, such as call transfer
on busy. The usual solution to such interaction problems is
20 to prevent both aervices from being used by the cu~tomer
3imultaneously. This, of cour~e, limits the power of the new
servic~ .
Even when services are compatible, the conventional
approach to providing u ,~ - serviCQ~ often forces a
25 customer ~a-~r~n~f a fQw limited featurQ~ of several services
to -3uh~ ri he to ~everal complete servico~ . Thi~ is both
coYtly and inef f iciont .
PCT IntQrnational Application NumbQr PCT/U.S. 84/01610
teaches a method for ~l~f~ning an individu~ ervice for f~n
30 individual cu~tomer. In that method, a telQph~nQ s~rvice is
performed by a usi - program which a customer defines
using conventional program f~ ~. The program may be
executed on the custom~3r's host .L~L eYternal to the
teleFhrne network when a call is ~,Loc~ f,~d. Although this
35 method permits a new individual ~.uaL service to be
configured without modifyLng the tQlsFhone network switching
~ystem software, the ~rpl;c~hil~ty of 8uch a method is
~,..L-~ -ly limited. For example, this method cannot implement
, . _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ . . .
~o 92/ 11603 2 ~ 9 ~ ~ ~ 8 Pcr/us9 I/094S7
-- 3 --
. .
a new service on a network wide basis because each service is
specific to the ~.:uoL who designed it. This m2thod also
requires every customer who uses the service to have an
5 individual host computer external to the t~ ~rhrm~ system.
Furth.~ re, designing a servlce requires a computer
~. u~ to write progr~m sequences to define the service,
and a p c", must make chang~s to the progrOm sequences to
modify the service.
Although the attempt at customization in PCTJU.S. 84
0160 is 1~ Ahle, it hiyhlights the problemg which ~ SitJn~?r~
have faced in attempting to leave the conventional rhi lt ~^t}'Y
of proy_ n~ a service . One problem is the hardware
limitations. The software for developing ~ ...0~ 7e~
service for each user must be able to be usQd on different
platforms 80 that the rArt~hility of ~t~titJn~n~ servic~s, as
well as testing them, can be n~dQ available to as ~any users
as possible.
In addition, the design of services cannot require
standard p G., nq becaulse the coOt and difficul~y of
providing such cust ~tion will make it too expensive to
employ .
At~co~ ngly, it is d~-ir~hle to have a ~ystem capable
of provlding multl-functlon, single Oervice~ that can be
i 1 t lad and used ~ A 1 1 y.
Another dt~irJ~h~e featurQ for ouch a Oystem would be a
-'-ni~- for de~itr~n~ multl-function, single servlces
~asily ~nd without need for knowledge of the underlying sys-
tem.
Yet another ~-i rAhle feature would b~ e~Oy
transportability of the Oystem, or of parts of the system, to
other r~ - rh ~ ~ ~ I? or devices .
Additional desireO of the invention will be s~t f orth
in the description which follows, ~nd in part will ~e
app~rent from the deOcription, or may bQ learned by practice
oi the invention. The advantages of the invention ~ay be
realized and obtained by mean~ of the in~,L, talitieO and
combLn~tions partLcularly pointed out in the a~ nd claims.
. , ~
2098~08
--4--
Disclosure of the r~ventiQn
To achieve the foregoing desires, and in accordance with
the purposes of . the invention as embodied and broadly
5 described herein, this invention provides a system which has
differe t levels which provide different functions.
In accordance with one aspect of the invention there is
provlded a method of designing a procedure to direct a
telecommunication network to provide réquested services to an
10 individual customer of the network, the method comprising the
steps, executed by a data processor, of: presenting the
customer with a plurality of types of nodes, the nodes
indicating the determinations and actions allowable from the
procedure; receiving from the customer indications of desired
15 nodes; receiving =from the customer indications of desired
relationships between the desired nodes; and constructing
graphical representations of the desired nodes, the customer
values, and the indicated relationships among the nodes
depicting a customized telecommunications service; creating a
20 customized call processing information record from said
graphical repre-sentation of said nodes, said customer values,
and said indicated relationships, with said creating step
comprising ~he substeps of: using a display level software
process for conve~ting said graphical representation of the
25 procedure into a data structure representation of said
procedure; and using a data structure level sof tware process
for converting said data structure rep~esentation of said
procedure into a binarv representation of said procedure
capable of being stored in a database and capable of being
~ ,
.~
20986~8
-4a-
executed by a call processing process for providing t h e
telecommunications service; and storing said customized call
processing information record for recall and real-time
5 execution by said call processing process when the customer~ s
customized service is requested.
In particular, a data processing system for designing a
procedure to direct a telephone network to provide requested
services to a customer of the network, preLerably comprises a
10 display terminal for displaying a visual representation o~ the
procedure; and a control device, coupled to the display
terminal, for causing the display terminal to display the
visual represen'c;ation based upon multilevel data, the
multilevel data i~cluding a graphical repres~ntat; nn level
15 ,nnt~in~ng display in~ormation for the~visual representation;
a data structure level containing data, organized in data
structures, which correspond to t~e display in~ormation; and
a code level to implement the requested services, the code
level corresponidng to the data in the data structures
Briçf ~escri~tion of th~ :Drawin~Ts
The accompanying drawings, which are incorporated in and
constitute a part of the specif ication, illustrate presently
pre~erred implementations ,f this invention and,
,, ,
~0 92/1 1603 2 ~ 9 8 6 0 8 PCr~US9t~09457
-- 5 --
. .
together with the general description given above and the
detailed description of the preferred imrl~ ~ations given
below, serve to explain the ~rinc ~ples of the invention.
In the drawings:
Fig. l i8 an example of a ~graph~ customer interface;
Fig. 2 is an example of a ~'form~1 customer interface;
Fig. 3 is a functional block diagram of the Llvv.~ced
int~11 i g~nt network;
Fig. 4A is a functional block diagram of a service
management system in accordanca with one 1~ t of the
present invention;
Fig. 4B is a functional block diagram of a service
control point in ~ccorriAnce with one ' '; - L of the
present invention;
Fig . 4C is a f unctional block diagram of a service
control point in accordance with another ~ of the
present invention;
Fig . 4D is a functional block diagram of a per~nA 1
computer in Accnr~iAnre with one ~ ~ ~1 t of the present
invention;
Fig. S is a schematic .eyL~,E~nLation of three software
levels ~,L._yonding to three 6yL~ ..Lations of services in
accordance with one: - i L of thQ present invention;
25 Flg. 6A Ls a schematic ~yL.. ne.. Lation of program
modules OoLL~y~ - Ain~ to an internal data structure of
servic~vs in ~ or~l~nl~e with one ~ '~ C of the present
invention;
Fig. 6~ is ~ schematic L~r_ - tation of program
30 modules cGLL..~y~ding to an binary L~L.- Lv-tion of ^vervices
in accordance with one : ' ' ~ t of the present invention;
Fig. 6C i5 a schematic L6yL~ t_tiOn of program
modules ~LL~ n~ to a displayed LG~L. ~tion of
serYices in ~grv-ph~ form in accordance with one . '--'i -t of
35 the present invention;
Fig. 6D is a schematic L~yLe- t~tion of program
modules c~LL.,vy.,..ding to a displayed L.,yL___..Cation of
WO 92/11603 2 ~ 9 ~ ~ ~ 8 PCI/US9t/09457 ~1~
-
services in '~form" form in accordance with one _ ` ~'i L of
the present invention;
Fig. 7 illustrates a MAIN opeL.,t~L interface window in
accordance with one ~ t of the present invention;
Fig . 8 illustrates a MAIN operator interf ace window, as
well as the options for the NAIN menu selection in ~ccordance
with one: ' '~ t of the present invention;
Fig. 9 illustrates a ~ystem v~ri~h1ss dialog box in
accordance with one ~ t of the present invention;
Fig. l0 illustrates a Tcap ?~ 5~ dialog box in
accordance with one _ ' '1 L of the present invention;
Fig. ll Lllustrates a MAIN operator interface window,
as well as the options for the n~P~cR menu selection in
IS accordance with one ~ t of the present invention;
Fig. 12 illustrates a NAIN operator interface window,
as well as the options for the TBMPLATB menu selection in
accordance with one . ' 'i ~ of the present invention;
Fig. 13 illustrates a MAIN operator interface window,
a~ well as the options for the OPTIONS menu selection in
~ccordance with one ~ '1 t of the present invention;
Fig. 14 illustrates a r~aIN operator interface window,
a~ well as the options f or the LIBRARY menu selection in
accor-i~nce with one ~ L of the present invention;
Fig. 15 illustrates a graph edit pad interface window
in a~ ~nr~nre with one : ' ~ i L of the present invention;
Fig. 16 illustrate~ a graph edit pad interface window,
as well as the options .~ .v..ding to the GRAPEt menu
sQlection in ac~or-1Anne with one .. ' 'i t of the present
invention;
Pig. 17 illustrates an Open New graph dialog box in
accordance with one ~ of the present invention;
Fig. 18 illustrates an Open graph di~log box in
accordancQ with one c ' ' i - - t of the present invention;
3S Fig. l9 illustrates a Save As dialog box in accordance
with on~ omho~i- t of the pre~ent invention;
Fig. 20 illustrates a Warning dialog box in accord~nce
with one -'i t of the pre~ent invention;
~WO 92~11603 2 ~ 9 8 6 ~ 8 pcr/us9lJo9457
-- 7 --
. .
Fig. 21 illustrates an Add Node dialog box in
accordance with one ' i t of the present invention;
Fig. 22 illustrates an Enter I-ATA dialog bo~ in
S accordance with one: '~ t of the present invention;
Fig. 23 illustrates an Edit Carrier dialog box in
accordance with one -'i t of the present invention;
Fig. 24 illustrates a graph edit pad interface window,
as well as the options coLL~r~vnding to the EDIT menu
selection in accor~lAnre with one ~i L of the present
invention;
Fig. 25 illustrates the graph edit pad interface
window, as well as the options CVLL~ i n~ to the VARIABLE
menu selection in ~c~r~nee with one: ' - ' i t of the
pre8ent invention;
Pig. 26 illustrate~ a Call V~r~hl~ dialog box in
ccordance with one ~ 'i t of the present invention;
Fig. 27 illusL~e~tG~ a Graph Variables dialog box in
accordance with one : ' i t of the present invention;
Fig. 28 illustrates a Graph V~ri Ahl~ dialog box in
accordance with another - 'i t of the present invention;
Fig. 2~ illh~LLclt~ a graph edit pad interfAlce window,
as well as the options CVL, ~ Ai n~ to the OPTION menu
selection in ~ccrr~l~nre with one ~ ~i -t of the present
invention;
Fig. 30 illu~tratels a graph ~adit pad interface window,
as well as the options cuLL._~v..ding to the EXECVTE menu
selection in ~eor~l~nre with one -~1 t of the present
invention;
Fig. 31 illu~traten a graph edit pad interfAlce window,
as well as the options cv.L~ u--ding to the VALIDATE menu
selection in ~ccor~ nce with one: -'~ L of th~ present
invention;
Fig. 32 illustrates a graph edit pad int~rf~re window,
35 as well as the options ~ VL _~v.~ding to the INTERFACE menu
selection in accord~nee wlth one: ;'l- L of the present
invention;
_ _ _ _ _ _ _ . . , , . .. _ . . _ _ .. _ . .. _ _ _ _ .
WO 92/11603 2 0 9 8 6 0 8 PCI/US91/094~7
-- 8 --
Fig. 33 i8 a flow diagram of the operation of a ~ervice
creation portion to Lnitiate creation of a new graph in
accordance with one ~ t of the present inventLon;
S Fig. 34 illustrates an example of a gr~ph using a TID~E
node in accordance with one: ' ~i t of the present
invention;
Fig. 35 illustrates an example of a graph using a DLN
node in ~CCOr~Anre with one ~ ' ~ t. of the present
invention;
Pig. 36 illustrates an example of a graph using a
PERCENT node in accordance with one ' ' i t of the present
invention;
Fig. 37 illustrates an example of a graph using a DAY
1S node in accordance with one ~ ' ' i L of the present
in~ention;
Fig. 38 illustrates an example of a graph using an ANI
node in accordance with one: ' ~t t of the present
invention;
Fig. 39A illustrates an example of a grnph using a NET
node in accnrrl~n~ with one ~ i t of the present
invention;
Fig. 398 illustrates an example of a graph using a NET
node in accor~nre with another ~ of the present
invention;
Fig. 40 illustrates an example of a graph using a DATE
node in ~Ccor~n~e with one . '~ of the present
invention;
Fig. 41 illustrate~ ~n example of a gr~ph using a LATA
node in accord~n~e with one: '-'i t of the present
invention;
Fig. 42 illustrates ~n e~cample of a graph using a
R.ESULT node in accordance with one ~ of the present
invention;
Fig. 43 illustrate~ An example of a graph u~Lng a
ROUTING NUNBER node Ln ~ocor~l~nce wLth one: '-'i t of the
present Lnvention;
~WO 92/llC03 2 0 9 8 6 08 PCr/US91/09457
g
. . .
Fig. 44 illustrates an example of a graph using a
- CARRIER node in accordance with one ` 'i- L of the present
invention;
- 5 Fig. 45 illustrates an example of a graph using a
GETlODIGITS node in accordance with one: ' `i t of the
present invention;
Fig. 46 illustrates an example of a graph using a STORE
node in accordance with one ' 'i- t of the present
inventiOn;
Fig. 47 illustrates an example of a graph using a
p~r~r~nT~ node in accordance with one: 'i t of the
present invention;
Fig. 48A illustrates a D~ClS node template dialog
lS box in acc~r~lAnre with one . ' -'i t of the present
invention;
Fig. 48B illustrates a DECISION node template dialog
box in accordance with another: ' ~ of the pr sent
invention;
Fig. 49A illustrates an ASSl_. ~n. node template dialog
box in accordancQ with onQ - ' '1 L of the present
invention;
Fig. 49B illustrate~ an A~S_ . node templ~te dialog
box in arrnrtiAnre with another: ' 'i t of the present
25 invention;
Fig. 50A illustrates a ~ u~ nodu template dialog
box in Arcr,r~lAnre with one: ' ' ~ L of the pre~Qnt
invention;
Fig. 50B illustrates a ~vr~ u~P node tQmplate dialog
30 box in accordance with another: ' ' 1 t of the present
invention;
Fig. 51A illustrate~ a CONVERSATIONAI node template
dialog box in accnr~iAnre with one ' - ' i t of the present
invention;
Fig. 51B illustrates a CONV~CA-- r node template
dialog box in accordance with another ~ t of the
pre3ent invention;
WO 92/11603 2 ~ 9 8 6 0 8 PCr/US91/09457
-- 10 --
. .
Fig. 52 is a flow diagram illystratLng a seneral edit
operr~ting ~L.ac6s.1l~Le~ pQrformQd by a ~rvice creation portion
to build a gr~ph after a graph has bQen initiated, in
5 accordance with one : ` _ ' i L of the present invention;
Fig. 53 i8 a flow diagram illustrating an operation of
a service creation portion f or adding a node to a graph in
accordance with onQ . ' - ' i t of the present invention .
Fig. 54 is a flow diagram illustrating an oper~tion of
10 a service creation portion for adding a branch to a graph in
accordance with one '1 t of the pre~ent 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 : ' ' i t 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 ~/r~or~i~nre with one: '-'i- t
of the present invention;
Fig. 57 is a flow diagram illustrating an operation of
a service creation portion to hidQ a portion of a displ~yed
graph in accnrri^nre with one; ' 'i t of the present
lnvention;
Fig. 58 is a flow diagram illustrating an operation of
a service creation portion to delete a prede~rmi n~d portLon
of a graph in ~orA^n~e with on~ t of the present
invention;
Fig. 59 is a flow diaqram illustrating an opQration of
a servlce creatlon portlon to deletQ a nodQ from a graph in
ac~LIA~ with on~ of the prQsQnt invention;
Fig. 60 is a flow diagram lllustrating an opQratlon of
a service creatlon portlon to open an Qxlstlng storQd sraph
in acror iAn~e wlth on~: ' -'i- t of thQ prQsent invention;
Fig. 61 la a flow diagram lllustratlng an opQratlon of
a fiervlce crea-tlon portion to save a graph to a database in
3S accordance with OnQ: '.'i t of thQ pre~ent invention;
Fig. 62 is a iunctional block diagram of a call
proc~60ing portion in ~corci^n~e with one I ' 'i- t of the
presQnt invention;
-.
~0 g2/11603 2 0 9 8 6 0 8 PCI/US9l/094~7
-- 11 --
. .
Figs. 63A and 63B are flow ~ rAm~ of a call
processing operation of a ~ rA~E module in accordance
with one: ' 'i t of the pretient invention;
Figs. 64A and 64B are flow ti;/~7r~ illustrating a call
processing operation of a MESSAGE HAND~ER module in
nce with one . ~i t of the pregent invention;
Fig. 65 i9 a functional block diagram of a call context
in accordance with one : ' i t of the pre~ent invention;
Fig. 66 is a functional block diagram of a call state
in accbrdance with one . '_'1 t of the present invention;
Fig. 67 is a flow diagram of a call pror-9~in~
operAtion performed by a CALL CO~ITEXT module in accor~ nce
with one: '1 L of the present invention;
lS Figs. 68A and 68B are flow ~lir l illustrating a call
processing operation to provide visual indication~ of an
execution of a service as performed by a CALL CONTEXT module
in accordance with one : ' i t of the present invention;
Fig. 6g i8 a flow dLagram illustrating an operation for
setting "global, n step" and "trace" flags in accordance with
one: _'i t of the present invention;
Fig. 70 is a flow diagram illustrating an operation to
provide a visual indication of an execution path taken during
F-nh~nred C~ll proc~lsinq at a remote call proce~sing
environment, in ~rrri~nre with one ~i t of the present
invention;
Fig. 71 Lllustrate3 a dialog box for selecting services
for visual indication in ~cc~r~i~nce with one = i t of
the present invention; ~nd
Fig. 72 is a flow diagram illustrating an operation of
an expert system in accor i~nre with one ~i t of the
present invention.
i3est Mode for Carrvina Out the Invention
Reference will now be made in det~il to the
construction and operation of preferred i 1- Lations of
the present invention which are illustrat~d in the
WO 92/11603 2 0 9 8 ~ ~ ~ PCr/US91/09457
?` ~ . 12
ac, ying dr~wings. In those drawLnga, like elements and
operAtions are designated with the same reference numbers.
The following description of the preferred
5 implementatlons of the present invention is only exemplary of
the invention. The present invention is not limited to these
implementations, but may be re~lLzed by other
implementations .
A. uvJ~;~vll;n ~ j
The present invention UV~L~ - Y the dLsadvantage~ of
conventional systems by providing to t~1erhnn~ services
service yL~JyL~3 customized to the desire~ of individual
customers requesting indiv~d~A~ functionOlity. As used
lS in this Opplication, "customer" refer~ to the entity for
which a service is provided, and "user" or "opQrator" refers
to the person using the system to crQOtQ, test Qr modify the
service. The user and customQr may bQ thQ same, but they
nQed not be. Although thQ following dQscription focuses on
20 telephone servic~s, the invQntion hOs broader U8Q8 and~ is not
r-~c~sJtrily limited to tel~rh~nt~ services in all instancQs.
l. SoftwOre C ~~:
The yLef~LL~d i ~'~ t of thQ prQsent invention
25 1nrll~d~- a ,u8L ' ~ services ("CS~) application to crQate
and, in cQrtOin circumstOnces, Qxecute each customQr~s
servicQ ,~L~ dUL~ît or program. Each customQr's servicQ
program is stored as a record or O sQri~ of rQcords of
~u~ call E~roce~n~ information (CCPI) in O databa~e.
0 The CS appllcation and the CCPI are thQ rr~nrirAl ~oftware
~8 of the preferred i 1 tation.
The CS application preferably i nrl I - a ~L~ ,, ' n~
interfOce which permit~ On ûy~Lo~ OL to u~e the CS application
to create v~lrious uDer interfA~c~ to obtain information,
3S directly or indirectly, in a m_nner which i8 relatlVQly ea8y
to u~e. The information i3 u~ed to "~ otO the CCPI record~
automatic_lly .
~WO92/ll603 2 ~ 9 8 ~ 0 8 Pcr/us9l/o9~s7
-- 13 --
. .
User int~f~r~s can be tailored to the skill level of
an operator, whLch can be the customer, using the CS
application to create customers service ULUyL~_, to the
5 specific service to be provided, or to the specif ic hardware
on which the service will be created, such as bit map
graphics, t~rmi nA 1 displays or DTNF t~lerhonc~ .
Fig. l illustrates an ex~mple of a customer interface,
shown aY a graph 5, providing a graphical Le~Le~-ntation of z
10 CCPI record created on a graphics workstation di~play. The
CCPI record cuLL~_yù..ding to this graph proYides a service
for a customer identified via a "key~' in rectangle 6. The
specific ~ervLce provided by the CCPI record for graph 5 is
the screening of calls from the telerhnns having the phone
15 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 ~YrlAin~d in detail below.
In Fig. 1 the pLU 'nlJ interface of the CS
application has been used to provide a graphic user interface
20 to allow construction of graph S. The present invention,
however is not limited only to i l~ tations requiring a
graphic user interface. If, for example, the interface used
to build graph 5 is too L~uLct. intensive to allow effiri~nt
preparation of similar graphs for every subscriber, an
25 alternative interface can be selected.
Fig. 2 shows a form user interface 8 which c~n be used
to provide the same "976" call scrQening service as graph 5
does. Form interface 8 requires a ~ D' - or operator to
insert only ~ Dsmall amount of information, and thus requires
30 les6 time and skill than creating graph 5. The ~L~ n7
interface for providing ~976~' form interface automatically
translate6 the information input by the up~.Lc,tor into a CCPI
record cuLLO~lpo~ding to the de~lired servic~. Using a
diferent user interface, an u~al..tû~ can display this same
5 CCPI record or records in a diff~rent form.
In the preferred i, l~ Lation of the pre~ent
invention, the CCPI record or record~ ~ULL~Vp~ n~ to a
service are created in a creation environment of the CS
_ _ _ _ _ _
W092/11603 209860g PCr/ussl/os457 ~
g
appLication and are executed durins~ call proc~ n~l in a call
processing environment of the CS application. As used
herein, ~call proc~ssin~" refer~ to the acts of responding to
S a me88age or query from a switch or switch simulator. A
YWitch is a piece of t~l erhnn~ equipment which receives and
routes ~slerhnne calls . As ~IYrlA i ned below, CCPI records may
be executed in either the creatLon environment or the call
processing environment.
2. HardwarQ Alternative~i
In a p~e:feL~ ~d ~ L, the present invention is
1~ ted in the advanced intelligent network (AIN). Fig.
3 is a block diagrant of the AIN. The AIN ~ ' ~ ASC AIN
switching r~r~hi 1 {ties switch ( ~ASC switch") 12, ad~unct 14,
~ervice nodQ (SN) 16, service control point (SCP) 18 and
service mana~entent ~ystem ( SMS ) 20 . The present invention
can also be i 1~ t ed on a per~onal computer (pc) 22
connected to SNS 20, SCP 18, ad~unct 14, or SN 16 vi_ modems
-20 24.
In a preferred ~ t, the CS application can be
~Y~c~tted on SMS 20, SCP 18, ad~unct 14, SN 16 or PC 22. As
will be eYr3~in~d below in the tii~cu~ n of the different
1l Lations, the functionality of the CS àpplicntion may
2~ differ ~Ir~pr~n~iin~ upon which ~ e~ the~CS
application .
In the p..~ d ., ':'i- t of the pre~ent invention,
the CS application provides for both the creation of a CCPI
record (service creation) through an o}, ~r. tOI interface, and
30 f or the execution of CCPI records during call p.o ~ ~ - i n~ .
However, the CS application can provide only the cre~tion or
the execution of CCPI records.
Figs. 4A-4D illustrate different notwork nl ~' 4 which
can execute the CS applications.
Fig. 4A 18 a functional block diagra~t of SNS 20. SNS
20 comprises CPU 40, database 42, operator interface 44 and
Cs application 46. operator interface 44 preferably
comprises display 48, keyboard 50 and mouse 52, e~ch
.
~ O 92/11603 2 1) ~ 8 ~ ~ 8 PClr~US91/09457
-- 15 --
connected to CPU 40 . CS application 46 i n~ e~i service
creation portion 54 and call processing portion 56. A CCPI
record can be created at SNS 20 via operator interface 44 and
can also be used by SMS 20 to process calls input to CPU 40
via any numbQr of sourcQs 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
c ~e only call processing portion 56 for processing calls
in a simulated environment using CCPI records created
~l~e~oh-~re and stored in database 42. In this A ~ , t,
S~S 20 would only be used for testing, not service creation.
Further, as ii~r--ee~ in greater det~il below, call
processing portion 56 provided in SMS 20 i~ preferably an
~nhJ-n~e~ v~3r8ion which permit8 a vi8ual indication of the
execution of a CCPI record on a graph displayed to an
operator .
Fig. 4B is a preferred 6 _~i t of a functional block
diagram i 1 ~ing CS application 46 in SCP 18. SCP 18
ZS __ r ~r CPU 58, databa~Q 60, and CS application 46. In
Fig. 4B, CS application 46 ~R only call proc~sin~
portion 56. This iB becau~e SCP 18 typically provides no
Oy~L toL int~rfAce 44 (Fig. 4A), therefore, creation of a
CCPI record is not usually ~LL ~ at SCP 18.
If, as in Fig. 4C, ~ Le~tOL int~fA~ 44 iY provided at
SCP 18, CS application 46 may include s~rvice creation
portion 54 to permit creation of ~ CCPI record at SCP 18. In
Figs. 4B and 4C, call p~ ~c ~sin~ portion 56 ~
messageg provided by ASC switch 12 (Fig. 2) by executing the
CCPI records stored in databa~e 60.
If operator interface 44 is provided in SCP 18, call
processing portion 56 would be an ~nhAn--~c~ version of call
processing portion 56 to per31it a vi~ual indicatlon of the
_ _ _ _ _ _ _ _ _ . , . . _ _ . _ . . _ _ . _ .
WO 92~11603 2 0 9 8 ~ ~ 8 PCr/US91~09457 ~
-- 16 --
~ .
execution of the CCPI re~ord at SCP 18. As described in more
detail below, if an enhanced version of call processing
portion 56 i8 used in SCP 18 without interfacQ 44, a visual
S indiultion of the execution of the CCPI record can be
trAnsferred to another envirortment which provides operator
interfacQ 44 and service creation portion 54 for displaying
the execution path of a CCPI record on the gr~ph
c~LL~ ul.ding to the CCPI record.
Implement~tion 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 Pig. 4D, i ~ Lation of CS application
in PC 22 is similar to that for S~S 20 in Fig. 4A. CS
application 46 in PC 22 pr~ferably includeg ~ervice creation
portion 54 and call proc~Q~inq portion 56. Altern~tively, CS
application 46 may include either ~ervice creatLon portion 54
or call processing portion 56 to perform either of the
associated functions, with the functions which are not being
perf ormed beiny provided in an alternative environment . Call
processing portion 56 may be an Qnh~nrQd version to permit a
visual indication of the QYQcut~nn of a CCPI rQcord a~ PC 22.
B. Architecture of the softw~re
The displayod L.~ t Ation of a CCPI record is
~LL~I ly useful in that lt pQrmits an opQrator or a cu~
to customize, creatQ and understand the dQsired tQl erhnnQ
servicQ. The di-played L~.er_n~ation is merely ~n aid to
the undQrstanding of the design of thQ c~,LL~ A~I~n~ service;
howQver, the di~played 1~L~- tation cannot be int~L~Le,ted
directly by the call procQ~E1n7 environment. The displayed
representation of thQ CCPI rQcord must thereforQ bQ
translatQd into a binary L~ tion which can bQ storQd
and usQd to process calls in a call proces~ing ~nvironmQnt.
In the prefQrred ~ 1~ Atlon of thQ prQ-ent
invention, the displayed l~L~ tion of thQ CCPI record is
first translated into ~m intQrnal L-~L~- ~tation, ~in~
data stLu~L~es and pointQrs ~pL~~ Ling thQ CCPI rQcord,
~W0 92~11603 2 0 9 ~ ~ 0 8 PCT/US91JOg457
-- 17 --
. .
and eventually into the binary Le~L~e-...tation. Fig. 5 shows
this schematically.
Software 51 has three levels cc,.L~ oYIding to three
S LeuLese..Lations of the CCPI record. Display level 53 is used
to provide the displayed Le~uL- e_.,L~tion of a CCPI record,
such as that 8hown in Figs. 1 and 2. Level 53 preferably
contains two sublevels: sublavel 55 and level 57. Sublevel
55 is used to form the actual display for the coLL~ ...Ain,J
10 display tr~rminiql Sublevel 57 contains information on
ob~ects " used to form the displayed -:~L~EL..tatlon . For
example, in the display shown in Fig. 1, the ob~ects may
refer to the Aii '~ and rectangles used to form graph 5.
The division of level 53 into sublQvels aids in porting
IS software 51 to different platforms. Preferably, the software
at level 53 is written in the IB~ 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 80
that it will compile under C++.
Data structure level 59 contains an internal
L~pLesê~tation of the service preferably stored in data
structur~s. Details of th~ data :IL.uuiLu~ 6el are not nr~cr~Ary
to the understanding of this invention, however, it should be
noted that thH software at level 59 is le~s machine A-~ronAr~nt
than that at level 53 becauge the software at level 59 can be
used with many different types of displays, e.g., forms or
graphs, and many different type8 of h~ '- re.
Th~ actual binary L..".~..Lation of the service is at
binary code level 61. Level 61 is the only L~,L~_..tation
30 stored for ~Y~cnt;nn in the PjL~ ''i t. The binary
representation is the mo~t machine i ~ A~ t.
When a CCPI record is stored to a databQse, uuch as
database 42 in Fig. 4A, or retrieved from a databaue, modules
~;ic,L..._~u,,ding to the binary . ~"Lee~.~Lation of the CCPI record
35 translate the internal graphical ~ L~~ t~tion o~ the CCPI
record into the binary LeyL-.ee.~Lation of the CCPI record.
Each .e~L6e_..tatLon of ~ CCPI record is --n;r~lAted by a set
of modUles in the 80ftware. A 'mûdule" consist8 ûf a set of
W0 92/11603 2 ~ 9 8 ~ 0 8 - PCI/US91/09457 ~
-- 18 --
subroutines which are used to manipulate some physical or
~onceptual ob~ect.
The "module" conce~t is at the heart of the
S ob~ect-oriented design in the preferred im~ tation of
this invention, although the module is not neces~ary to carry
out the invention in all of the 1 mr1~ Lations . A set of
module8 i5 associated with each L~yL~ tation of a CCPI
record. The set of modules associated with the binary
10 Lc ~L..e_..Lation 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
15 gtructure L~ L.~ tation of a CCPI record ( level 59 in Fig .
5) i8 rQ~pnn~1hle for r-n1r~7~ting the in~tructions and
structure of the CCPI record. q~hese modules are also
respr~n~1h1e for translating the binary L~ L~c~.~t_tion of
l~vel 61 into the internal data ~LLu..LuLe: L.,~E_..tation of
20 level 59.
A set of modul~s associated with the displayed
~L-~_ Lation of the CCPI record (level 53 in Fig. 5) is
responsible for translating the internal data ~.LLu- L
LQ~L~~ tation into th~ displayed L-~L.- tation and
25 pL~.- 1n~ and collecting in~ 1ion to and from an
op~l..LoL. These modules would genarAl ly b~ written by an
individual ~nuch a~ a pLC- ) and u21e the pL~_, ing
interface (i.e., the interface betwe~n levels 53 and 59 ) of
the modules CCL_ ~ 11ng to the internal data OLLUCLUL~
30 L~pLe_..tation of the CCPI record to crQate new intQrfa~ -
for customer services.
. ,M~ C~,LL~ "~A 1n- to Internal
Data SLLU'_LULe R-,.L~aGL..tAtion Level
3S Fig. 6A shows the ~ ~f~LL.I modules for level 59.
GR~P~ module 62 or~n~ a And intJ-1n- a ~et of nodes in a
graph. Important operation~ of thi~ module include
tr~nslating the internal dat~ ~tructur~ L~ ation into
~0 92/11603 2 ~ ~ 8 6 0 8 pcr/us9lJo94~7
- 19 -
the binary L6~L~e..~ation and visa ver~a, as well as adding
and deleting nodes f rom the graph in the internal data
structure L~L~_..tation.
NODE module 64 manages a single CCPI record
Lnstruction, and ~ eA the parameters of a node.
Tnrl UA,~A in NODE module 64 is BRANCH module 66 . Branch
module 66 manages each branch of a L~ECISlo.. node. DECISION
node~ are oYrl A i n9d in greater detail below.
Tn~ Aed in each BRANCH module 66 is BRANCH VALUE
module 68. BRANCH VALUE module 68 manageJ every value in
each branch of a DECISION node.
GRAPH AND NODE CONTROL module 70 L~Le~_..ts a higher
level abstraction of nodes and graphs, and provide3
~ ~ni ~-nq for adding, editing and deleting nodes ~rom a
graph .
TE~PIATE module 72 provides a template for creating new
nodQs. TEMPLATE module 72 evaluates a template to determine
what information is needed to create a node, and to generate
a node once the lnformation is complete.
LABEL module 74 provides the -nil for parsing and
generating ~tring ob~ects.
EXPERT module 76 manage_ an expert system, translates
the intern~l data a~Lu~;LuL~ Ler,L~._e..tation of a CCPI record
25 into schema_ used by an expert system (~YrlAin~d below)~ and
helps evaluate ~ ee received from the expert system.
2. ~odules CCLL--A'"'~AinlT to Binarv
n~Lar~AAtation Level
Fig. 6B shows the prefarred module~ for level 61 shown
in Fig. 5.
GRAPH BUFFER module 78 manage~ the binary
Lep ~g_..Lation of the CCPI rccord~ as shown in Fig. 5. GRAPH
BUFFER module 78 also ~ LLe~t~3 the ~xecution of the CCPI
35 records.
NODE BUFFER module 80 manages the binary L.pL~_..tation
of a single instruction in a CCPI record.
WO 92/11603 ; ! . PCr/US91/0945~
209~08 20-
REY modulQ 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
5 records to externally provided keys.
CO.~lUNICATION module 84 manages communication ports
which transfer querY ~~~~ r and CCPI records between AI.
network elements. ~nMM~7laTrA~ION module 84 facilitates
reading f rom and writing to the ports .
0 MESSAGE HANDLER module 86 ~ e~nts a device for
passing - ~F~ into and out of call proc~ ; n~l routines .
In particular, ~ESSAGE HANDLER modules 86 converts messages
into call contexts and converts call contexts into ~ 3 ~.
Call contexts are the data ~L~,LuL~ for r-n~r3in~ the calls.
r~T.r. CONTEXT module 88 manages the execution of CCPI
records. Tnrlllri~d in CALL CONTEXT module 88 is CALL STATE
module 90 which manaçe~ the information associated with each
CCPI rQcord being _L~d during call proc~-F1nrJ.
VARIARLE module 92 man~ge~ call variables a~sociated
with the execution of a CCPI record.
STACR module 94 provides conventional stack functions,
such as push and pop operations.
LI,~R module 96 provide~ conventional linked list
f u ~ctions .
n~R~ module 98 man~Jes a database, and provldes
-ni vm- for rQadLng, wrltlng, openlng, closlng ~nd
updatlng a dat~baRe.
~lAIL module lOO sQnds and retrieves CCPI records
between the AIN network elements i r7~ntl f L~ in Flg . 3 . The
sending and receiving of records preferably u~es conventional
data transfer techniques.
3. Mrlr~ for Di8D1~Y8d R-~JL~ 3. ~tion Level
As r~Y~ l~ i n~d above, the modules ~ vLL6_~v~ing to the
displ~yed L~.~L.- tation of CCPI records will generally be
written by ~n individual ( such a~ a ~L~, ) and use the
~LV~,_ ing interface of the modules ~ VLL~ ti1n5 to the
lnternal L~L. ~nLatlon of the CCPI records to creat.~ new
~o 92rll603 2 û 9 8 ~ ~ 8 PCr/US91/09457
-- 21 --
. .
services . These modules generate the di~played interf ace on
the diDplay screen and present information to and collect
information from an operntor creating a new service.
S Fig. 6C illustrate~ a preferred set of module~
coLLOO~ul~ding to the displayed L~ ntation of a CCPI
record for providing the flow chart stylOd interface ( 'gr~ph
intOrface" ) Dsuch aO graph 5 shown in Fig. 1.
Fig. 6D illustratOs a prefOrrOd ôôt of modulOs
10 CoLLeD~Ullding to the displayed LO~L-.eetation 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 modules are preferably divided to
coLLO~pull~t to an applied displayed L~ c/L~ ntation of the CCPI
lS record and an abstract diOplayed LepL- r-~ntatlon of the CCPI
record. An applied displayed ~p ~_.,tation is the visual
image displayed on the screen, while the abstract displayed
Le~L- 5 .,tation defines the imageO to be displayed and
coordinates them onto an abstract plane.
The modules UULL~ ~uAding to the elpplied displayed
representation of a CCPI rOcord are identical for both the
graph interf aee and the f orm interf ace .
SCREEN module 102 draws the displayed interface onto
the Dcreen and elearDs the sereen.
DIALOG module 104 manages the dialog boxes whieh can be
displayed to the ûp~L~toL. Important operations for this
module include ele^rin~, presenting and retrieving
information from the operator via dialog boxes.
CONTROL module 106 manages the state of the interface,
including mouse cliekg and menu geleetions made by the
operator. Thô CONTROL module also handles events gQneratOd
from external ;~Ation ports.
WINDOW TABLE modulQ 10 8 manages inf ormation about QA ch
graph Oditing pad window, inrlu~l~ng which windows ara opQn or
closed and which CCPI rOcords are displayed in which windows.
Important operations f or this module include correlating a
call context with a window and setting and storing paramQters
for each graph editLng pad window.
WO92~11603 ~ ~ ; PCIIUS9l/09457
2 ~ 9 8 6 ~ 8
Fig. 6C illustrates the OBJECT TABLE module 110 and
OBJECT module 112. OBJECT TABLE module 110 manages the
collection of ob~ects used in the abstract displayed
5 representation of a CCPI record. Important operations o~ the
OBJECT TABLE module 110 Lnclude tr~nslatLng the internal data
structure Le~Le ~ ation into the abstract displayed
r. ~,.LeJ_.~tatLon, and adding an ob~ect to, as well as deleting
an object rom, an ob~ect table (not shown).
OBJECT module 112 manages information C~lLL----Y~ ;ng to
an ob~ect or f igurQ to be drawn on a di~iplay screen . OBJECT
module 112 sQts par~meters, such as location, size and shape
for each ob~Qct or figurQ to be drawn on thQ screen.
Fig. 6D illustrates a preferred module r~ Ain~ to
15 the ab8tract dLsplayed Ll=yL~~ ~ation of a CCPI record for
providing a form interface, such as the "976" call screenins~
interf ace shown in Fig . 2 .
PROVISION module 114 tran~latQ~i the internal data
aLLu~.LuLe L~yL~ tation of ~ CCPI record into an ab~tract
20 La,~L..G~ ation CULL---~ Aing to th~ form interface, and
interface~ with the program interf~ce at the module3
coLL~...y.,..~ing to the int~rn~l data ~LL~ LI.~.. of A CCPI record
to provide for the for;n i nt~ A--e .
In an alternative: 'i L, module 114 may be
2S in~ in with the graph interface mûdul~s of Fig. 6C.
This would allow CCPI rQcord~ to bQ displayed as either the
"976" call 8~ L~ in~ form ~hown in Fig. 2, or the graph
CC.LL.~ .. A i ng to thi~ ~rviCQ ~hown in Fig . 1.
A~ sYrlAinsd above, each di~play interface crQates and
30 di~plays a set of CCPI record~. Thi~ ~et COLL~Y~ to a
service concept which the interface i8 ' ~n--ti to support.
If a CCPI record is created by one interface and fall~ withLn
the set of CCPI record3 that can be created by a different
interface, that CCPI records can be di~played by both
35 interf aces .
~o sVtt603 2 ~ 9 8 6 0 8 Pcr/US91/09457
-- 23 --
. .
C. Service Creation Usinq Gral~h Interface
Prior to discussing the creation of a service, an
explanation of the operation of a ~ervice will be given as
5 background. Reference will be madQ 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 f rom the phone number identif ied in the rectangle
10 6 (identified by the ~.eO4" suffix) or calls being made to
the phone number identified in rectangle 6 (Ldentified by the
. eO5 suf fix ) .
The L~ i nri~r of graph 5 ' ~8 a plurality of node~
25, deri~ n boxes 30, and hr~nr~~~ (not lAh~ d) bQtweQn
the nodes 25 and ti~ri R; nn boxes 30 . Each node 25 L~
a high level instruction in the CCPI record c~LL.50~ ,ding to
the graph. ~er i ~ion boxes 30 ~UL ~ ,",1 to ~ie~ n nodes
(nodes 25a and 25i) and identlfy alternative execution paths
ie~pe~nrlin~ on the rQsult provided by thQ ~C.LL~ iin~
20 deri Qion nodQ.
Graph 5 C~LL....~U..~8 to a CCPI rQcord usQd to call
procQss a phonQ call b~ing madQ from phone num~er (201) 659-
2911. The CCPI rQcord COL .._~u..~ing to graph 5 screQns from
the phone number ( 201 ) 699-2911 ~11 call- which thQ customer
25 does not wish to be completed. For example, t~l~rhnn~ calls
made to the phone number "976-1212N are routed between the
hours of 7sOO p.m. to g-OO p.m., as are any phone calls made
to the number ~976-1234~ during the hour~ of 6sOO p.m. to
8:00 a.m. and any phone calls madQ to thQ nu~nber ~g76-1224
30 at any time. Call~ to any other number with thQ "976"
exchange, calls to ~976-1234~ between 8~00 a.m. and 6sOO
p.m., and calls to ~976-1212~ between 9~00 p.m. and 7:00 a.m.
are sub~ect to PIN (Per~onal Identification Number) override.
If the caller s~rpl; 3~5 the PIN of 2558, the call is routed .
3s Otherwise, a busy signal i~ produced.
This service is provided for by graph 5 as follows.
Initially, ti~t~i~ion node 25a checks the NXX (i.e., fourth,
fifth and sixth digits of the phonQ number)(thQ exchange).
WO92/~1603 2 ~ ~ 8 6 Q8 ~ PCr/US9l/09457
-- 24 --
Declsion boxes 30a and 30b identify the two decision
possibilities whlch rQ~uire separate attention. If the call
i8 not a "976" exchange (other) the call is routed by node
5 25~.
If the celll is a "976" ~Y~ hAnge, n~ode 25c checks the
la~t four digits (the extension) at node 25c. If the last
four digits are "1212" (~eri~Lon box 30c) node 251 checks the
time of day. If the call is placed between the hours of 7: 00
lO p m- and 9: 00 p-m-, the call is routed (decision box 30g and
nodQ 25d ) .
I~ the call is placed any other time of the day
inT~ box 30h), the call is to be prevented unless the
proper PIN is provided. Node 25e prompt~ the caller to input
15 a PIN- Node 25f check8 the re8ult. If the caller inputs PIN
"2558' (~ri~ion box 30e), the call is routed by node 25g.
If the caller inputs ~ny other PIN (~e~ n box 30k), node
25h provides the caller with a busy signal.
If th~ last four digits of the phone number being
20 cnlled are ~'1234~ (d~ inn 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. (deni~ion box 30i), the PIN operation is
again pe-L~ ~ be~1nnin~ at node 25e. This is illustrated
in Fig. 1 by the circle 26a which contains a numeral 1. Note
2S that the PIN node 25~ ha~ a "number lt~ n~xt to it. ~his
indicates that the graph conti exQCution st~rting with
that node. If the call i3 being placed at any other time of
day (d~ inn bo~c 30~ ), the call is routed by node 25~ .
If the la~t four digits of the phone number being
30 called are "1224U (~ ion box 30e), th- call i~ routed by
node 25k.
If the la3t f our dLgits of th~ phone number being
called are ~omething other than ~1212, " "1234, " "1224
i on box 30f ), the PIN operation is repeated, as
35 indicated by the circle 26b.
With thiD explanation of graph 5, the step~ of graph
creation and editing can be a~ld,.33~d. Creation and editing
_ _ _ _
~/0 92/11603 2 ~ ~ 8 ~ 0 8 - Pcrtus9l/o94s7
_ 25 --
.,
of a graph, such as graph 5, preferably involves windows and
menus .
1. Menus
Fig. 7 L~p c3~.~Ls operator interface window 120. ~in
window 120 ~ ~ec a menu bar 122 identifying seven menus:
MAIN, nA~ARAC~, TEMPLATE, DATA, OPTIONS, LIBRARY and EXIT.
An operator " clicks " on any of the menu options to select a
de8ired menu. The "remote" window 121 shown Lnside 120 is
optional and will be described in det~il below.
Fig. 8 is a display of the main op~LGtor interface
window 120 showing the options 124 for the MAIN menu. These
options include: GRAPH EDIT PAD, SYSTEM V~T~RTRC, TCAP
M~c~cAr,~c, ~LaIL Ml7CCAr.~C and SWITCH STMrlT A~ . The GRAPH EDIT
PAD option opens a GRAPH EDIT PAD window which is usQd to
cre~te, edit and save graphs.
The SYSTEM vARTA~T~c option opens a system variable
window, as shown in Fig . 9, which displays the call var~ ~hl es
of the operating environment, such as time, day ~nd date.
From this window, thQ op~LGto can change the values of the
system call vJ~ri ~hlQ~ .
The TCAP MESSAGB option opens the TCAP MESSAGE window
as shown in Fig. 10. This window displays the query messages
from a switch or ~witch simulator, not ~hown in Fig. 10.
The MAIL MrccA~:~c option opens a MAI~ MESSAGE window
(similar to th~ TCAP message window, therefore, not ~hown)
which displays the ~r~, ~ a~sociated with the exchange of
CCPI record~ to other devices in the AIN network. The SWITCH
SI~ULATOR option opens a SWITCH STMTlT A~r~ window (not shown)
80 that the operator can generate querie~ into the
application for te~ting CCPI records.
Figure 11 is a di3play of the main interface window 120
showing the options 126 for the nA~A-'`C~ m~nu. Th~se options
include: NEW, OPEN, COPY and DELETE. The NEW option
displays a dialog box to prompt the op~to for a database
name and create~ the new database. The OPEN option di~pl~ys
a dialog box to prompt the operator f or a database name to
W092/11603 2~9g60~ PCI/US9l/09457 ~
-- 26 -
.
open an existing database. The COPY option displays a dialog
box to prompt the operAtor for two d~tabase n~mes nnd copies
the first database into the second database. The DELETE
5 option displays a dialog box to prompt the operator f or a
database name to delete that database.~
Figure 12 is a display of the màin interface window 120
showing the options 128 to the TEMPLATE menu. These options
include: NEW DECISION, NEW ASSIGN~ENT, NEW CONVERSATION, NEW
10 PROCEDURE, EDIT and DELETE. TemplAtes, as ~Yrl~in~d below in
greater detail, are used to create graph elements, called
nodes, which the system does not record as standard.
The NEW DECISION option displays a dialog box for the
operator to create a NEW DECISION node template. The NEW
15 ASSIGN~ENT option di8play8 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 N~W
CONVERSATION node template. The NEW p~O~T~nTrT'` option
displays a dialog box for the operator to create a NEW
20 PROCEDURE node template.
The EDIT option displays a list of node templates (not
shown). The u~L~tuL ~elects the node template to be edited,
and a dialog box with the template information is prQsented
to the u~clLC~tOL. The O~.:L.ItOS can make desired changes to
25 the template inf ormation .
The DELETE option also presents thQ operator with a
list of node templates from which the u~6LC.tor can select
templates to delQt~.
Pig. 13 is a display of the main int~rfac~ window 120
30 showing the options 130 for the OPTIONS mQnu. These options
include: EXECUTION and EDIT.
The EXECUTION option displays a dialog box allowing the
operator to set the global ~ step " and " trace " f lags . As
~Yrl~in9" below in more detail, the gtep flag is ~et to allow
35 an operator to step through th~ graph during call proce~sing.
The trace f lag is used to h i gh 1 i qht the execution path taken
through a graph during call ps~-~ sin~.
_ _ _ _ _ _ _ _ .. . . ... _ _ .. _ _ . _
~0 92/11603 2 ~ 9 8 6 Q ~ Pcr/usgl/09457
-- 27 --
. ~
~ he EDIT option displays a dialog box allowing the
operator to select the inf ormation to be displayed in the
graph nodes. The two types of information generally selected
S are the node title and the node value. r- loY of these
dialog boxe~ are described below.
Fig. 14 is a display of the main interface window 120
showing the optionq 132 for the LIBRARY menu. The~e options
include: u~su~uu-, RETURN, ADD ~nd DELETE. The U~kUKUU~
1û option di8play8 a dialog box which the operator completes
with the n~me of a record desired to be checked out from a
remote database. The RETURN option display~ a dialog box
prompting the operator for the name of the CCPI record to be
~LuL~led to a remote database. The operator can also add a
15 record to the remote databage or delete a record from the
remote database using the ADD and DELETE options,
respectively .
FLg. 15 illustrates a "graph edit pad" window 134 which
i8 used to create, edit and store CCPI records. This window
20 includes a menu bar 136 1 nolu~l ~ n~ eight menu options: GRAPH,
EDIT, VARIABI E, OPTIONS, EXECUTE, VAI,IDATE, INTERF~CE and
EXIT .
Fig. 16 illustrates the "graph edit pad" window 134
with options 138 of the GRAPH menu displayed. The~e options
25 include2 NEW, OPEN, SAVE, SAVE AS, CLOSE, D~ETE, FORWARD,
BACX and ITERATE . The NEW option displays a dialog box ( Fig .
1~ ) prompting the operator for a namQ or "keyn for the record
that the op~L~tol wi~hes to create. The OPEN optLon diqpl~ys
a dialog box (see Fig. 18) prompting the operator Eor the
30 name or "key" of the graph the operator wi~he~ to open.
The SAVE option ~aves to pCt ~ r~- t storage the binary
epLa~_nLation of CCPI records cc,LL.--"-~ A;n~ to the graph.
The SAVE AS option displays a dialog box ~ Fig . 19 )
prompting the ~ L~to for the name or "key" for a CCPI
35 records to be saved, then save~ the binary L~Le~l..tation of
the CCPI records cc lL~ .u,~ding to the graph to ~ L
3torage .
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
WO 92/11603 2 ~ 9 8 6 0 8 PCr~US91/09457 ~
-- 28 --
. .
The CLOSE option displays a warniny dialog box ( see
Fig. 20) requesting the operator for verification to complete
this option. If the re~uest is verified, all C~L~- ~ations
S of the CCPI recordg c~LL...~onding to the graph that Ls
currently being displayed are cleared.
The DELETE option dQletes the ÇCPI records
~ ~l r L~ i nsT to the graph that i8 currently being displayed
i~ deleted from the database. Again, a warning dialog box is
10 presented to the u~L~to-.
The FORWARD option displays the CCPI record in the
database following the CCPI record that i~ currently
displayed. The BACI~ option display- the CCPI record in the
database that p r~c~le~ the CCPI record currently being
15 displayed. The ITERATE option display~ the CCPI records in
the database conYecutively at a predetarm1 n~d interval .
Fig. 24 illustrates the l'graph edit pad" window 134
with options 140 at the EDIT menu diYplayed. These optLons
include: ADD NODE, ADD BRANCH, EDIT, HIDE, CONNECT,
20 TE~PLATE, DELETE SU~TREE and DELETE NODE. The ADD NODE
option displays a dialog box with a list of the nodes the
oper~tor can add ( ~ee Fig . 21 ) . The ADD EIRANCH option
displays ~ dialog box ( see Figs . 22 and 23 ) ~uLL~ ullding to
the DECISION node to which the branch is being added. The
25 operator enters the correct branch inf ormation f or the
selected L~ node.
The EDIT option displays a dialog box ( see Fig . 23 )
with information c~ n~ to the selected node which
allows the U~LC~tU~ to edit a node. The CONNECT option
30 connects one portion of a graph to another portion of the
graph. The TENPLATE option displays the template for the
selected node .
The HIDE option removes f rom the ~creen all nod~s that
are children of the selected node unless the child nodes also
35 have a parent dif f erent f rom the sQlected node . The DELETE
SUBTREE option deletes the selected nodQ and all its children
nodes from the screen and the C~LL- ~ ii ng CCP~ record,
unless a child node also has a parent that i8 different from
~0 92~116~3 2 ~ 9 8 6 0 8 PCr/US91/~94~7
-- 29 --
. .
the aelected node . The DELETE node deletes a node f rom the
graph . These last two options change the graph ' 8
functionality. The HIDE option does not.
Fig. 25 illustrates the graph edit pad windo~ 134 with
the options 142 for the VARIARLE menu heing displayed. These
options include CALL V~RTART R~ and GRAPH VAT~TART~ . The CALL
VART~RT~ option displays a window containing the variables
of the call context for the graph being displayed (see Fig.
10 26 ~ . The GRAPH VARTART ~ option displays a window containing
the vAri~hl~ of the CCPI record being displayed (see Figs.
27 and 28 ) .
Fig. 2g illustrates the graph edit pad window 134 with
the options 144 for the OPTION menu being displayed. These
15 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 ~u~ u~d to each nod~ separately. The
EXECUTION option displays a dialog box ( not shown ) which
20 allows an operator to select the "step" and "trace" flags for
the CCPI record COL .._yu..ding to the graph being displayed.
Fig. 30 illustrates the graph ~dit pad window with the
options 146 of the EXECUTE menu being di~played. These
options include: COMPLETE, STEP and CLEAR. The COMPLETE
25 option completes ~ call prors~in~ of a CCPI record
CCIL.~ ng to the graph. The STEP option HA~ Le~ the
next node of a CCPI record of the di~played graph. The CLEAR
option remoYe~ a vi~ual indication of the execution of a CCPI
record COL ~ t3ing to the displayed graph.
Fig. 31 illustrates the graph edit pad window 134 with
the options 148 for the VALIDATE menu di~played. The~e
options include VALIDATE, DISPLAY and CLEAR. The VALIDATE
option invokes an expert Yystem which flags any errors in the
structure of the CCPI record of the displayed graph. The
DISPLAY option display~ a list of error~ associated with the
selected node . The CLEAR option clears all f lagged errors
f rom the graph .
WO 92/11603 2 ~ 9 8 6 0 8 PCr/US91/09457
-- 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 FORN option L~L~E .Its
5 CCPI record as a form for a "976" call screening service (as
shown in Fig. 2) . The GRAPH option ~pL--- ts the same CCPI
record as a graph ( as shown in Fig . 1 ) .
2. Ol~eration
The creation of a service will now be r~a~rri ~ed with
reference to certain of the windows aYrlA;nq~ abov~. 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 manipulates the windows to diDplay the main
interface window 8hown in Fig. 7 (step 200). The operator
selects the "NAIN" menu (step 202) to display the "MAIN" menu
options to the o~Lc~toL ( Dee 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
20 206 ) .
The operator then sel~cts the ';GRAPH" menu (step 208)
to displ~y the "GRAPH" option~ (see Fig. 16) (step 210). The
operator selects the "NEW" option (step 212), and CONTROL
module 106 calls DIALOG module 104 to d$spl~y the
~oLL~~-,.. ding dialog box (Fig. 17) (step 214).
Next, the op_L~to~ inputs the "k~y" of the graph (step
216 ), and CON~OL module 106 responds by calling GRAPH module
62 to allocate memory for the internal data DLL~ ULe~ repre-
sentation of the graph being created ( 3tep 218 ) . CONTROL
module 106 also calls OBJECT TABLE module liO to allocate
memory for the abstract displayed L~ t~tlon of the graph
to be created (step 220). GRAPH modul~ 62 then calls GRAP~
BUFFER module 78 to allocate memory for a blnary
L~L~ tiOn of the graph being created (step 222). Next,
CONTROL module 106 calls GRAPH module 62 to add the "key" to
the internal L..~Le~en-ation of the graph being created ( step
224 ) .
~O 92/11603 2 0 9 8 6 ~ 8 Pt~US~I~n~457
-- 31 --
CONTROL module 106 then calls OBJECT TABLE module 110
to translate the internal graphical L~",Le~.~tation to an
~bstract displayed e~..e(..,t.ation ( step 226 ) . CONTROL module
106 then call~ SCREEN module 102 to translate the abstract
displayed L~L~_..tation into the applied diYplayed
3_.ltation "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 i8 thQ initiation of
10 a new graph. At this point, only the box with the "key' is
displayed. U~ing the operations of the "EDIT" menu and a
plurality of nodes, an operator can now build a graph to
def ine a desired service .
a. Nodes
Preferably, graphs are ~od of four type~ of
nodes: DECISION nodQs, ASSIGNMENT node~, ~KOc~Lu~E node~ and
CONVERSATION nodes. DECISION nodes control the path of
execution of a graph during call proce~8in9- tioponr7in~
aCcOr-;in~ to values of call VAriAhloa. ASSIGNNENT nodes
assign '~values" and "VAr;AhlQ~D to other Dcall v~r;AhlQ~.
The concepts of vAr;Ahle~ and call v~lr;Ahlo~ arQ oYrl~insd
below. ~ u~! nodes switch control to a differ~nt graph
or to a subroutine . CONVERSATION nodQ~ provide inf ormation
to a caller or derive information from a caller in the course
of proces~; n7 a call .
DEt'Tg't node~ ar~ u~d to branch the ~Yocuti~n through
a graph and have ~evQral important attributQs . The f ir~t of
these attributes is the ' call variable ~' attribute which
indic~tes which variable is u~Qd in detorm;nin~ the correct
branch. Another important attribute i~ thQ "type" of the
call variable which dQtermi nol5 how the branch inf orsnation
will be ~tored and displayed, for QxamplQ, a~ an integ~r or
as an ASCII string . The prefQrred p _ -; n~d DRt`TC node
35 templates generate the following nodQs s
TINE DAY DATE
DLN ANI LATA
PERCENT NET RESULT
WO 92/11603 2 0 9 8 6 0 8 Pcr/uS9l/09457 ~
-- 32 --
. . .
TII~E Node - The TIME node is a DECISION node which tests for
time of day when traversing a graph . The TI~E node ~ s decision
hr~nrh~-8 may specify a 8ingle time, a range of time, multiple
5 times or time ranges. The TI~B node make~ its deci~ion based upon
the current time of day for thH call. The value of the ~ystem
clock i8 used to determine the branch.
Pig . 34 illu~trates a graph u~ing - the TIME node . In this
graph, if the call placed to the 800 number shown in the rectangle
10 l~ made between the hours of 8 5 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 - ThQ DLN (Dialed Line Number) is a DECISION node
which L~:lyL.l- ts the number to which the call is placed. The DLN
1S node decisions are ba~ed upon on~ or more of the digits in the
number dialed by THE calling party. The po~itions 0-9 of the
dlgits of the dialed line number can be used to lndicate which
portion of the dLaled line number the ~er~Ri~n should be made.
Flg. 35 illustrates an example of a ~raph using the DLN node.
20 In this graph, i~ a call being made from the number identified in
the rectangle is placed to an exchange of 976, an ar..~o~ t is
played to the caller, and the call proces~ing is blocked. A~ny
call to any other ~nr~ hAngQ is routed.
PERC~NT Node - The PERCENT node i8 a DECISION node which
2S randomly choose~ a path ba~ed on ~- ~d~t~ ~n~d percentages . An
exampl- of a graph using the PERC~NT node is shown in Fig. 36
where, the fir~t 25 percQnt of phone calls made to the 800 number
identifled in the r~ctangle are roùted via a flrst carrier; the
~econd 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.
nAY Node - The DAY node i8 a JV ,5 ~ node which allows a
graph to branch based upon day of week crlterla. RrAnrh~ for a
D~Y node indicate the path of call rroc~jn~ when the value for
3S the day call variable matches the branch criteria. El~ch branch
out of a day node may contain one or more days or ranges of days.
Fls. 37 illustrate~ ~ graph u~ing a DAY node. In this graph,
if the number in the rectangle ig called on Saturday or Sunday,
. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ . . ... . . , . , . _
~WO g2/11603 2 ~ ~ 8 ~ 0 8 PCr/US91/09457
-- 33 --
the call is forwarded to a different tQle~h~nf~ number. If the day
of the week is Iqonday-Friday ( other ), the call is routed to the
number in the rectangle.
S ~EI - In an ANI (Automated Number Identification) node, a
decision is made ba8ed 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 ut1li7;n7 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 anno--n- ~ i8 played to the caller
~nd the phone call is blocked.
NET Node - The NET node is a DECISION node which detarm;nQ~z
whether a call is on a private network or of f of a private
network . The NET nodes ~ ~iQAi ~ion brAn~ hss 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 i n. n~ TCAP message contains the value
assigned to the NET variable. Figs. 39A and 39B each illustrate a
graph i n~ i n~ a NET node .
DATE Node - The DATE DECISION node allows a graph to branch
based upon day and month criteria. The ~ for a date node
indicate the path the call procQq~; n~ ~hould take when the value
f or the date call variable matches the branch criteria .
An example of a graph using the DATE de~ n node is shown
in Fig. 40. In this graph, if the date on which the call iB
placed to the number identif ied in the rectangle is January l,
30 July 4 or r~- 25, an Ann~ n~ L i~ played to the caller,
and the call pro~Ae~s;n~ is blocked.
T.~ NQde - The LATA (Local Access and ~rrAnl~port Area) node
is a n~cTsIl node which tests the LATA of the origin~ting number.
~lultiple LATA values or ranges of LATA values may be specif ied f or
35 a single branch.
Fig. 41 illustrates a graph using the LATA DECISION node. In
the graph, if a call placed to the 800 number identified in the
rectangle originates in the 252 ~ATA, the call is routed.
WO 92/11603 PCI'/US91/09457
209860~ ~
-- 34 --
Otherwise, an ~n"~ .r t is played, and thQ call processing is
blocked .
RESULT Node - The RESUIT node is as DECISION node which tests
5 the "DIGITS~ call variable identifying dialed digits. The call
variable is ~si~n~d from the lnformation~ collected by a
conversational messagQ Fig. 42 illustrates a graph using the
RESUI T node .
ASSIGNNENT nodes assign values or call v~ri ~hl~C to other
10 call variablQ8- ThQ preferred pr~ f~n~ ASSIGNNENT nodQ nodes
are as follows:
ROUTING NU~BER (RN) CARRIER BILLED NUMBER
FINAL 'I'R~!A'I'M17N~
ROUTING NTllURR~ (RN~ - The RN node is an ASSIGNNENT nodQ that
15 assigns a final routing number. When a telsph~n~ number ig
specified, the syntax is l0 digits that ,.,p - ~ the valid
telephone number. ~ig. 43 illustrates a graph uaing the RN node.
In Fig. 43, the tsl~Fh~ns number for the routing is displayed in
the node. A call made to the 800 number identified in the
20 rectanglQ is actually routed to the phone number identified in the
RN node.
FINAL ~A'I'MTi!~T Node - This is an ASS~ node to as~ign a
f inal treatment code to the f inal treatment variable . The f inal
treatment code tell~ the switch what to do with the call, f or
25 example, routQ, block, busy (see, for example, Fig. 42).
t'ARRTl;!l~ Nod~ - The CARRIER node is an AC' node whLch
allows an ~ tOr to gpecify which long distance carrier will
route the call. When an operator adds a CARRIER node to a graph,
he is rQguested to enter a carrier mnemonic, for example, ~NCI,"
30 ATT.
Fig. 44 show~ an example of a graph using the carrier node.
~ II~ED NUN8ER - Th~ Billed Number (8N) nodQ is an A~S~_.. r~
nodQ which spe~-if ~ a l0-digit number for the tele~Fh~n~ number
that itl to be billed for the call. To create thQ node, an
35 operator preferably spe~f~e~ a l0-digit number in the NP
format de~cribed above if the node is to ~ont~in the value.
92/11603 2 ~ 9 8 6 0 8 Pcr/usg1~og457
-- 3 5
Fig. 44 is an example of qraph ut~ ;nSl the BN node. The
graph in Fig. 44 assigns a carrier, BN and RN for the "800" number
identif ied as the key .
CONVERSATION nodes are used to request and receive
information from the calling party through thQ switch. They
assign the call vAri:~hlt~t~ that ~ ..L the message to played at
the switch and the number of digits to be collected from the
calling party . The pre~A.~f ~ nt~A CONVERSATION node templates
10 generate the following nodes:
PIN GETlODIGITS PLAYANNC
PIN Node - The PIN (Personal Identification Number) node is a
CONVERSATION node which requests that an A~ - Lr "Please
enter your Personal Identification Number, " be played to a caller,
15 requesting that a f our-digit code be entered by the caller . Af ter
the caller enters the PIN number, the four digits become the value
f or the " DIGITS " call variable in the i - n~ conversational TCAP
message that is e~u ..ed to the application for furth~r
processing .
A result decision node is used to branch the execution based
on the digits received.
Fig. 42 illusL~ a a gr~ph using the PIN node. In the
graph, which as shown is 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 Ann~--- t is pl~yed, and the call
process; ntJ is blocked.
GETlODIGITS Node - The GETlODIGITS nodQ is a _ v~s~SATION
node that reque~ts that an an----- t bQ played to ~ caller to
request that the caller input a l0-digit telerhnne number. The
30 value for the GETlODIGITS nodQ is a message number whlch becomes
the Yalue for the announ~ e call variable in an outgoing
conversational TCAP message. The digits entered by the operator
become the value for the DIGITS call varLable in the inl n,J
conversational TCAP message that is L~Lu ..e~ to the application
35 for further processing.
An example of a yraph 1nrlllAin~ a GETlODIGITS node is shown,
for example, in Fig. 45. This 3ervice collects a ten-digit phone
WO 92/11603 2 ~ 9 8 6 0 8 PCr/US91/094s~ ~
-- 36 --
?
number from the calling party and routes the call to that phone
number .
PI,AYANNC - The PI-AYANNC node allows an operator to specify 2n
5 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 ~ome information about the execution, he could call
a routine that he has written and invoke that through the
PROCEDURE node. The preferred pr~clPf1n~d rnO~ unr nodes are as
f ollows: `
~IANDOVER rKO~ un~ LOAD
1S STORE
X~NDQVER Node - The HANDOVER node ( HND ) is a procedure node
which instructs the call proco,YYin~ software to leave the current
graph and move to another graph to continue the call processing.
The value for a HANDOVER nodQ is the key (up to lO characters ) for
20 the HANDOVER graph. If an operator wishes to add a HANDOVER node
to a graph, he is L~y.- L~d to input the key f or the HANDOVER
qraph .
The contents of a U~ n graph may be as complex as
n~c~sary to providQ the Les~. - Led service. The HANDOVER graph
25 may contain any of the nodes, including onQ or morQ HANDOVER
nodes. When ~in1~h'~d process1n~ a HANDOVER graph, control is
LeLuL..-~ to the callLng graph.
Fig. 39A illustrate~ a graph Lncluding a HANDOVER node. This
graph det~rrni n~ whether the call is ~ON" or "OFF" the network
30 (NET)- If ON, the call is routQd. If OFF, exeeution i~
transferred to the graph having key "offnet.hnd." Although the
E~ANDOVER node displays the syntax "HANDOVER" to the operator,
through graph l-~nipulAtion~ (as ~-- 'hqd herein), the operator
can display the values of thQ uP ~v~;n node, which is "offnet.hnd"
35 as shown in Fig. 39E~.
sTnR~ Node - The STORE node is a r~ u~ node which allows
an operator to store values to the graph variAhl-s of a different
~0 92/1 ~603 PCr/US91/09457
-- 37 --
, .
graph . The value f or the STORE node i5 the key of another valid
gr/~ph in the system database.
The STORE node is often used in con~unction with the LOAD
5 node when ~YC`hAn~; ng or upd_ting call variAble values from one
graph to another. Fig. 46 illustrates a graph using the STORE
node .
PROCEDURE Node - The pT~O~`TCnTTr'T~ node is a PROCEDURE node which
allows an operator to select from a group of PLV~, 'ng language
10 routineg 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
rnO~:~uun~ node.
Fig. 47 illustrates a graph using the r~ node. In
this graph, the PROCEDURE node involves a routine to log
information ~bout the call into a file. A routing nu3ber 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 stor~d with a
different graph. Once the vAri~hles are loaded (e.g. after the
execution of the LOAD node), the c~ll processing software can then
use these vArl Ahles . The LOAD node value is the grAph key name
from which you are loading the vAr~Ahl~Q.
To add a LOAD node to a graph, an Uu~L~tol is re~uested to
input a graph key namQ of another valid graph cont_ined within the
system database. Fig. 46 illustrates a graph using the LOAD node.
This graph updates a call fc,L~- rr~in~ numb~r.
b. Tem~latq~8
A template is a data sLLu~ LuLe containing ~om~ or all
inf ormation needed to specify and instantiate a node in ~ graph .
A node is Lnstantiated when lt is added to the internal data
structure Le~ ~e_..tation. Ther~ are four type~ of templates; one
35 for each type of node. Thus, the preferred templates include a
DECISION node template, an ASSIGNMENT node tQmplate, a ~nO~:~;uunE
node template and a CONVERSATION node template. These templates
Wo 92/11603 2 ~ 9 8 6 0 8 PCI/US91/09457 ~
-- 38 --
. .
can be used to create any of the specific nodes identified above,
or any other desired node.
A DECISION node template lncludes a title and a call
5 variable. When an operator de9ires to generate a ~ECISION 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 ~ n~ s a titl~e
field 302 and a call variable field 304. The title field
10 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" marks the call variable field
as unsFec~f~d. This un~per~fied fiQld i8 8Ub3~ Atly specified
15 by an operator when the operator sel~cts the template to
instantiate a node in a graph.
Every field in any template can be a "wild card" which is
det~rm1 n~d by the O~ ,. when instantiating a node . For
example, to create a time ri~ri ~ir,n 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 usQd by the TEN~LATE modulQ to generate a
TIME DECISION node tplate. Once the TIME DECISION node template
exists, an opQL~tos can add time decision nodes to a graph. In a
25 gimilar manner, an operator can build a "datQ," "day," "ANI" or
any other DBrTr- nodQ template and use thQse templates to add
nodes to a graph.
An ~SS r~r~r node template inr~ a title, a first call
variable (which i~ A~ignDd a value), and a ~econd call variable
30 or value (which i~ ~vsi~n~ to the first call variable). An
operator 3e~irin~ to generate an ASSIGNMENT node template selects
the "NEW ASSIGNMENT" option in th~ tplate menu (~e Fig. 12)
which prompts display of a dialog box 306, a~ illustrated in Fig.
49A. The dialog box 306 ~ncl~ ey a title fi~ld 308, a first call
35 variable field 310 and a ~econd call variable or value field 312.
The title field 308 identi_ies the title or name of the ASSIGN~ENT
node t~mplat~ to be created, the fir~t call variable field 310
identifies a "wild card" call variabl~ which i~ a~ d a value,
_ _ _ _ _ _ _ _ _ _ _ _ _ .. _ . . . , .. . .. . . . . . _ . .. .. _ . . . .. _ _ .. . ... . .
~0 92/11603 2 ~ 9 8 6 0 8 PCr~uS91~09457
-- 39 --
and the second call variable or value fLeld 312 identifies a "wild
card" or a call variable or value whLch is ~signed to the first
call variable.
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 ~irst
call variable field 308 and enters the "wild card" "? carrier
into the second call variablQ or value field 312. For example,
10 the operator may input a three digit acronym ~u- ~. yuding to any
long distance carrier company as the value for this wild card.
This information is used by the TEIIPLATE node to generate a
CARRIER assignment node template, which can be selQcted by an
operator to add CARRIER nodQs to a graph.
A PROCEDT1RE node templatQ inc1uds~ a title and the name of a
routine called by this nodQ to execute an ident i f i ~hle
functionality. When an operator dQsires to generate a PROCEDURE
node template, he select8 the "NEW PRt)~'~nr)R~" option in the
template menu ( 8QQ Fig . 12 ) which prompts dLsplay of a dialog box
314, as shown in Fig. 50A. This dialog box 314 includes a tLtle
field 316 and a routine field 318. The title field 316 indicates
the title of the pLûc~dule- node template to be crQated, and the
routine field 318 identifie~ a program routine to be called when
this node is ~ _LeLtcd. For example, as~ume an operator has a
25 program routine named ~'log dcta" which record~ information about
call proc~s~in7 to a file. To crQate a r~ J~ node template
which calls this routine, as rihown in Fig. 50B, the operator
inYerts the title ( log data ) and routine ( log d~ta ) into f ields
316 and 318 of the dialog box 314. The u~ I o- can then use thi~
30 node template to insert thi~ nodQ 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 .,~ ~ ting the
number of digits to be collected from the caller. When an
35 operator desires to generate a rnO~:~Lw~ node tQmplate, he selects
the "NEW CONVERSATIONAL" option in the templatQ menu (see Fig. 12)
which prompts display of a display box 320, a~ shown in Fig. 51A.
This dialog box 320 inc~ g a titlQ field 322, ~n ~nnm~r- t
W092/11603 20ss6a~.~ PCr/USgl/09457~
-- 40 --
~,.
fLeld 324 and a digits field 326. The title field indicates the
title of the CONVERSATION node to be created, the AnnOI-nf t
fLeld identLfLes the ~nno~n~ t to be played to thQ caller and
S the digits field 326 specLfLes the number of dLgits the caller
should input in response to the annù, t.
Por example, to create a CONVERSATION node template which
prompts the caller to enter a four digit personal identifLcatLon
number (PIN), as shown Ln FLg. 51B, the operator enters "PIN" Lnto
10 the tLtle field 322, enters an index number to a message set to be
~nl.n - ~d or displayed in r~~--~~~ t field 324, and enters the
number of digLt~ ing the PIN Lnto the digits field 326.
This PIN node template can be inserted into a graph to prompt a
caller to Lnput a PIN durLng execution of the graph.
c. EditLnq
Fig. 52 is a flow diagram illustrating ~ general editing
operating ~Lu.,~du~ e ~a,L,- -` by servLce creation portion S4 to
build A graph af ter the graph has been initiated . This f low
20 diagram is generic to each of the "EDIT" menu options 140 shown in
Fig. 24. Specific flow r~iA, ~ for each of the "EDIT" menu
options are ~'~ ~ ' h~d below.
Initially, the operator selects an ob~ect on the screen to be
edited (step 700). CONTROL module 106 re~ponds by calling SCREEN
25 module 102 to h~hl ight the select~d ob~ect (step 702) . In a
preferred ~ ' '; , this hi~hl~Jhting is done by rhAn~in~ the
color of the selected ob~ect. The operator then selects the
"EDIT" menu (step 704) to display the ~'EDIT" menu options ~8 shown
in Fig. 24 (step 706). From thoJe options the operator selects
30 the desired "EDIT" menu option (step 708), and CONTROL module 106
responds by calling a routine or module that controlg the selected
"EDIT" option (~tep 710). The called routine or module then edits
the internal data ~L., .LULe L~L~ tion ~A.cnr~iinr3 to the
~elected EDIT option ~step 712).
CONTROL modulQ 106 then calls OBJECT TABLE module 110 to
translate the edited internal dat~ ~LL~ LUL-~ L613_.~LatiOII into
the abstract display ,~y,~E_~tation (stQp 714), and finally calls
the SCREEN module 102 to tran~late the abstract displcy
.
~O 92/11603 2 ~ 9 8 ~ ~ 8 pcr/us9l/o9457
_ 41 --
representation into the dLsplay representntion of the graph ( step
716 ) .
Fig. S3 is a flow diagram illustrating the operation of
5 serYiCe creation portion 54 f or adding a node to a graph . Steps
700-708 of Fig. ~A 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 c211s OBJECT module 112 to determine which node
;VLL~_L.yVlld8 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
15 operator for information to complete the templ~te cvL.~ v"ding to
the selected node I ~tep 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 d~ta ~tructure from the completed template
20 information (step 728). GRAP8 AND NODE CONTROL module then calls
GRAPH module 62 to add the node data ,,L.ueLu.e to the internal
data structure Le""L..- tation (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
25 then performed to translate the internal data ~L~U-;~UL~
LG~_..t ation into the ~bstract displayed Le~aGGatation and to
display th~ graph.
Pig. 54 is a flow diagram illustratLng the operation of
serYice creation portion 54 for adding a branch to a graph.
30 Initially, steps 700-708 and 718 are perel ', except that the
operator selects the "ADD BRANCH" option. GRAPH AND NODE CONTROL
module 70 calls TEMPI.ATE module 72 to d~termine which template
corresponds to the s~lected node (step 734). To do thls, the
fields of the node are matched to each field of each template.
35 The template which most completely matches the node is selected as
the coL.e,,yvnding template.
TE~PLATE module 72 then calls DIALOG module 104 to prompt the
operator for a branch Yalue or Yalues (8tep 736). Next, GRAPH AND
WO 9Z/1 1603 2 ~ 3 8 6 0 g PCI/US91/09457
-- 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 3tructure representation into an3abstract displayed Lt:~LC:se-ltation
and into the dlsplAyed graph.
Fig . 55 is a f low diagram illustrating the operation of
service creation portion 54 for editlng a value in the graph.
Initially steps 700-708 and 718 are performed except that the
10 operator select5 the "EDIT" option. Then, step 734 from Fig. 54
is performed. NQxt, GRAPH AND NODE module 70 determinss if a
branch or node is being edited (step 740). If a node is being
Qdited, TE~lPLATE module 72 calls DIALOG module 104 to prompt the
operator for information to modify the template for the selected
15 node (step 742). Subse~uently, steps 728-732, shown in Fig. 53,
are performed, and stepa 714-716 are performed to translate the
internal data structure L~pL~,E_..Lation into an abstract displayed
representation and to display the graph on the screen. If in step
740 it is det~rmin~l that a branch is being edited, step 736 shown
20 in Fig. 54 is p~LC~ '. GRAPH AND NODE module 70 then calls NODE
module 64 to edit the branch data 8LL~.~ LULel with associated
parameters (step 744). StQps 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
25 another node in th~ graph. Thig i~ a conveni~nce feature which
allows an LI~L~to to refer to a first portions of the completed
gr~ph to complete another portion of the graph without duplicating
the f irst portion of the graph .
Initially~ step~ 700-704 are p~rCr ' except that the
30 operator selects the "CONNECT" option. CONTROL module 106 then
detorminss whether the selected ob~ect L~ .ants a node (step
744 ) . If the selected ob~ect does not L~ t a brAnch or non-
DECISION node, rrocDY~in~ is done (step 746). If the selected
ob~ect L~L03.~.lts a node, CONTROL module 106 sets a connect flag
35 (not shown) for the displayed window (step 748). The operator
then selects an existing node in the graph to which to connect the
selected ob~ect (step 750). Step 702 is then performed. CONTROL
module 106 then det~min~y whether the connect flag is set (step
92/tt603 2 ~ 9 8 ~0 8 PCr/Us91/09457
-- g3 --
. .
752). If the connect flag is not set, the "clicked-onl' ob~ect
becomes the selected ob~ect (step 754). If the connect flag i9
set, CONTROL module 106 calls GRAPH AND NODE CONTROL module 70 and
passes graph, first-selected object 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 ob~ect
and the selected node together (step 758). Once this is done,
steps 714-716 are performed to dLsplay the graph.
Fig. 57 is a flow diagram illustrating the operation of
aervice creation portion 54 to "hide" a portion of the displayed
graph. To l'hide'l a portion of the graph means to delete it from
the displayed graph without deleting it from the other
Le~ nLations of the graph.
Initially, steps 700-708 and 718 are p~.~c -' 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
ob~ect in the data sLLu- L4.~ ~rArhi-~Pl L_~L~ ation. Steps 714-
716 are then performed to display the graph. However, in this
,omho~i t during step 714, OBJECT TABLE module 110 detc~rmines if
the "hide" flag has been ~et for each node. Since, in our
example, the "hide" flag ha~ been set, OBJECT TABLE module 110
does not translate any of the children nodes of the node for which
the hide f lag has been set into the abstract displayed
.e~L~ tation of the graph. This prevents it3 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 hr~nr~h~.
Fig. 58 is a flow diagram illustrating the operation of
8ervice creation portion 54 for deleting a pr~det~ n~d portion
of a graph. Initially, stepa 700-708 and 718 are performed except
that the operator aelects the ~'DELETE St~BTREE" 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 ~LLU-,LU e
WO 92/1 1603 2 ~ ~ 8 6 0 8 -- Pcr~uS9l/09457
_ 44 --
,,
, ~L~ .. tation (step 764) . Steps 714-716 are then repeated to
display the graph.
Fig . 59 i5 a f low diagram illustrating the operation of
5 service creation portion 54 to dQlete one node from a graph.
Initially, stQps 700-708 and 718 are repeated except that the
operator selects the "DELETE NODE" option. GRAPH AND NODE module
~0 dQt~7~nin~s whether or not the selected nodQ has more than one
parent or mOrQ than one child. If yes, this operation is not
10 completed and proc~sin~ i~ f~niRhed (step 767). If not, CONTROL
module 106 calls GRAPH modulQ 62 to remove the nodQ from the
internal data structure L-~LeAan~ation (step 768). CONTROL module
106 then calls NODE module 64 to link the selQcted nodets parent
to its child (~tep 770). Steps 714 ~nd 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 v~aLatC~r d-sires to open an existing stored graph,
the operation of sQrvice creation portion 54 iB a~ shown by the
20 f low diagram in Fig . 6 0 .
Initially, the op~rator display$ the GRAPH menu options and
selects the "OPEN" option (~tep 500). CONTROL module 106 LC_~u~ 5
by calling DIALOG module 104 to display the cvLL~_~vllding dialog
box shown in Fig. 18 (step 502). The v~Lator then inputs the
25 ~ key of the graph hQ de~ire- to open ( step 504 ) and CONTRO~
module 106 calls GRAPH module 62 to allocate memory for the
internal data ~Lu~LuL~ Le~pLe~ ation of the graph to be
displayQd (stQp 506). GRAPH BUFFER module 78 then call8 n~
module 98 to read thQ binary information ~ULLæ ~vllding to the
30 graph from thQ databa~e (sUCh a~ database 42 in Fig. 4A) (step
510). GRAPH module 62 calls GRAPH BUFFER modul~ 78 to translate
the binary L~ Lation of the graph into the internaL data
structure L~L ~_.,Lation of the graph (step 512) . NQxt, CONTROL
module 106 calls OBJECT TABLE module 110 to translate the internal
35 data structure L~yL~ ~ tation of the graph into the abstract
displayed L_~L- 3 .,tation (step 514), and call8 SCREEN module 102
to tranYlate the abstract di~played L~pL~c_.~t~tion of the graph
into the displayed graph format (step 516).
~0 92/11603 2 ~ 9 8 6 0 8 PCI/US91/094s7
-- 45 --
Fig. 61 is a flow di~gram illu6trating the operatiOn of
service creation portion 54 to save a graph to a database.
Initially, the operator displays the graph menu options shown in
5 Fig. 16 (step 600), and selects the "SAVE" option (step 602). In
response, CONTROL module 106 calls GRAPH module 62 to "unload~ the
internal data structure ~ a..Lation of the graph ( step 604 ) .
GRAPH module 62 calls GRAPH BUFFER module 78 to "unload" the
binary e~la3~Atation of the graph ( step 606 ) . GRAPH BUFFER
10 module 78 calls r)A~ARA~E module 98 to write the binary representa-
tion of the graph to the databa-e 42 ( step 608 ) .
If a graph is to be saved according to a new name ( such as
when a graph has been chanyed and is to be ~u~ dingly renamed
(a new key ) ), step 602 in Fig. 61 is changed in that the
15 operator instead selects the "SAVE AS" option and an additional
step (not shown) i8 added between steps 602 and 604 in which
CONTROL module 106 calls DIALOG module 104 to display a dialog box
(not shown) prompting the u~aLc~tu~ to input the new "key" for the
graph .
D. Service Creation Usina "976 Call Screenin~" Interface
Operation of service creation portion 54 for creating a "976"
form interface will now be ~ c~s~ with regard to Fig. 2. To
create a "976" call screening service, an operator selects the 976
25 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 ~Yrlu~l~n~ the completed information, then appears on the
screen. The "976" call screening form 8 in~ n a customer key
70, a general extension menu 72, ~ln~ ~creen option 74,
30 permit option 76 and time of day r~ Lcr 78, and a plurality of
special menus 80 inrlu-l~n~ phone parameter 82, screen option 74,
permit option 76 and time p~ L~- ~ 78. The "976" call screening
form 8 ~18O ~ncl~ s~ a PIN override option 86, as w~ll as a PIN
parameter 88, and "save ~load~ ~'new" and "exit" options 90, 92,
35 94 and 96, respectively.
An operator simply inputs the appropriatQ information and
selects the appropriate options to provide the desired " 976 " call
screening service. Once the operator has input the information to
W0 92/11603 2 0 9 ~3 6 0 8 PCI/US9t/09457
-- 46 --
complete the "976" call screening form, PROVISION module 114
analyzes the information and calls the approprL~te modules in the
internal data structure l~pL~e_..tation to translate the
S iniormatiOn into the internal data gtructure L~r,. o~..tation. This
internal data ~LLU~,LU~-a ep,~ tation can be translated into t}le
binary repre~entation ~ust as in the case with the c~LL.~ ding
graphs a~ shown in Fig. 1. To display the "976" call scr~ening
form, PROVISION module 114 translate~ the internal d~ta structure
10 Lt~L~ LatiOn into the abstract displayed, ~ ntation, and
then SCREEN module 102 translates the abstract displayed
representatLon into the di~played "976" call screening form 8.
E . t'~ 11 ProcessLna
Call processing portion 56 shown in Figs. 4A-4D preferably
comprises all the modules COL~ o.~ing to the binary
r~L,Eo.,Lation of a CCPI record a8 shown in Fig. 6B, although
preferably, calls are predominately processed by COMI~tJNICATE
module 84, ~ESSAGE HANDLER module 86 and CALL CONTEXT module 88.
Fig. 62 is a functional block diagram of call processing
portion 56. Preferably, call proc~8ing portion 56 inclu~
COMllUNICATE modulQ 84, MESSAGE ~iANDLER module 86, CALL CONTEXT
modu~e 88, message handlQr input queue 906, me~sage handler output
queue 908, call input qUeuQ 910, call output queue 912 and
conversational call8 queue 914. ~ module 84 is
connected to mes~age handler input queue 906 and messagQ handler
output queue 908, and receive~ and output8 -~'1; ~ to a rQmote
devic~, such as a switch or switch simulator. IIESSAGE HANDLER
module 86 is ~ eCL ~ to me~sago handler input qu~ue 906, message
handler output quQue 908, call input queue 910, call output aueue
912 and conversational calls quQue 914. CALL CONTEXT module 88 i~
connected to call input aueue 910, call output queuQ 912 and
databasQ 60. A description of the operation of the call
proces~ing application will now be providQd in con~unction with
35 Fig. 62 and the flow r~1r~ ~ of Flgs. 63A-67.
Figs. 63A and 63B are flow r~ r~m~ of the call processing
operationg of COMMtJNICATE module 84. coMMTr~T~E module 84 con-
tinuously monitor~ ~n input port (not shown) for ~ from a
~WO 92/11603 2 ~ ~ 8 6 ~ 8 PCI/US9l/09457
- 47 _
remote device. In one ~mho~i t, COMMUNICATE module responds to
.eO4, .eO5. and .eO2 meYsages in ~ccordance wlth AIN release 0.
In ~nother - ~i L, t"A'T'F: module 84 responds to other
5 ~ input from the remote device, 1nr1~ nq~ those messages
provided for in future AIN releases ~uch as AIN releases 1 and 2.
In Fig. 63A, CnMM~NIt'A'rE module 84 det~rm;nss whether any
messages are available for processing (step 1000). If not, COMMU-
NICA~E module 84 continues to look for a message to be processed.
10 If a message is available for proc~in~, C~ l A~ module 84
reads the message ( step 1002 ) and places the message onto message
handler input queue 906 (step 1004). (~A~P~ module 84 then
continues to look for a new message to be p.~- Qss~d.
In Fig. 63B, cnt.iMrlNT8A~ module 84 looks for any~- sA~e~ on
15 message handler output queue 908 (step 1006). If no message
exists, CO.~ CATE module 84 continues to look for mes3ages. If
a message is on message handler output queue gO8, COMIUNICATE
module 84 gets the message (step 1008) and sends the message to
the remote device (step 1010). cnMMTlNT8A~ module 84 then
20 continues to look for me~sages on message handler output queue
908 .
Fig. 64A illustrates the call pro~ ng operation of MESSAGE
~IANDLER module 86. NESSAGE }~aNDLER module 86 looks for -~-ges
on messagQ handler input queue 906 (step 1100~. If no message is
25 available, NESSAGE HArlDLER module 86 continues to look for
---8~ ~. If a message is on message handlQr input queue 906,
MESSAGE EIAIIDLER module 86 gets the message (step 1102) and
determi n~ ~ whether the message is a cc .-, ~ ~ational rQsponse ( step
1104 ) . If thQ message is not a c~,--vt- ~tional ~ --se, MESSAGE
30 HANDLER module 86 det~rm; - - the Arrrorr~ Ate CCPI record needed to
respond to the message (stQp 1108) and generates a call context
COL ~ o..ding to thQ message ( stQp 1110 ) .
As shown in Fig. 65, call context 160 -;n~A1n~ information
COL~ .,y.,~ding to the execution of a call during call procc~8i ng .
35 This information inc~ messagQ identification number 162, call
status 164, (e.g. active, wait, new or co..~ ,ational), stack
index 166, number of nodes ~L~ e~ 168, a list of call vAri~hl~
_ _ _ _ _ . . . _ _ _ . . . .
W092/11603 2~9s~as PCI/US91/094~7 ~
-- 48 --
,,
170 and call state stack 172. Call stack 172 may contain one or
more call states 174. ~,
A cali state 174 m~intains information . uLL~ uu~lding to the
5 execution of an individual CCPI record during call processing. As
~hown in Fiq. 66, The information maintained by call ~tate 174
includes the "key" of the CCPI record 176, the CCPI record 178 and
the execution offset 180 which cuLL~ o~d8 to the current location
of the execution in the CCPI r~cord.
ûnce a call context 160 has been generated, MESSAGE HANDLER
module 86 places call cont~xt 160 onto call Lnput gueue 910 (step
1112 ) ~nd the call processing operation of MlSSSAGE EIANDLER 86
module shown in Fig. 64A is repeated. If in step 1104 it is
det~ ned that the message is a conversational reDponDe, MESSAGE
15 HA~7DLER module 8 6 getD the cc,. ~ ù~ing call context f rom
converDational calls queue 914 (step 1106) and places call context
160 onto call input queue 910 (step 1112).
Pig. 64B illuD~ te~ another call proc~sln~ operation per-
formed by MESSAGE ~IANDLER module 86. MESSAGE HANDLER module 86
dett-rmin9g whether A call context 160 ig on call output queue 912
(step 1114). If not, MESSAGE HANDLER module 86 continues to look
for a call context 160. If a call contQxt 160 is on call output
queue 912, MESSAGE HANDLER module 86 gets the call context 160
(step 1116) and detern1n~s whether call context 160 is
converDational (8tep 1118).
If call context 160 ig conversational, call contsxt 160 is
placed on conversational calls queue 914 (step 1124) until, as
desrr1 hed with reqard to Fig. 64A, an input message CU~ L~ ; ng
to call context 160 is again processed by MESSAGE HANDLER module
86. If call context 160 iD not conversational, MESSAGE HANDLER
modulQ 86 generates a message from call context 160 (step 1120)
and placeD the message on message handler output queue 908 (step
1122). The call procesl~n~ opQration shown in Fiq. 64B is then
repeated by I~ESS~GE HANDLER module 86.
Fig. 67 illustrates a flow diagram of the call processing
operation performed by CALL CONTEXT module 88. CALL CONTEXT
module 88 monitors c~ll input queue 910 for a call context 160
(step 1200). If no call context 160 is on call input queue 910,
~WO 92/11603 2 0 ~ 8 ~ 08 PCr~USgl/09457
_ 49 --
CALL CONTEXT module 88 continues to look for a call context 160.
If a call context 160 is on call input queue gl0, CALL CONTEXT
module 88 gets call context 160 (step 1202) and det~rmin~s whether
5 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 coLLG~-,..ding 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 gtate 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 det~rmi n~R whether execution of
the CCPI record is complete ( step 1208 ) . Thig i8 done by rh~rki n~
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 detr~rmin~c
whether execution of the CCPI record is complete (s~ep 1208). If
the CCPI record h~s not been completely executetd, call I~ODULE 88
executes one node of the CCPI record (step 1210). After executing
a node, CALL CONTEXT module 88 dQtarmin~R wh~ther the node is a
CONVERSATION node (step 1212). If 80, 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 is not a 1- v ~ATION node, CALL CONTEXT module
88 detarmin~R whethQr the node ~ es~e~ is a "handover nodell
(step 1213). As QYr1~insd above, a "handover node" I - rily
hands the call proceelsinq over to another graph identified as the
value in the l'handover node. " If the eA~_uL6d node is a
~handover'~ node, CALL CONTEXT module 901 repeats stsp 1206 to get
the CCPI record CVL~ G~vl,ding to the "key" value idsntified in the
~handover node, " and step 1207 to create a new call state and push
this new call state onto the call state stack 1~2. Since CALL
CONTEXT module 88 executes the CCPI record on top of the call
state stack 172, if in step 1213 it i~ det^rm;n~i that the
executed node is a ;'handover node, " when the c~ll processing
routine returns to step 1208, it is executing the nsw CCPI record.
However, if in ~tep 1213 it is detarminF~d that the node executed
WO 92/11603 2 ~ 9 8 S ~ 8 PCI/US91/09457
-- 50 --
18 not a Ihandover node, " when the call processing routine
returns to step 1208, it continues executing the nrig~nAl CCPI
record .
S If in step 1208, CALL CONTEXT module 88 determines that the
CCPI record has been completely executed, CA~L CONTEXT module 88
then det~ n~ whether there i~ mpre 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 oytput queue 912 (step
10 1214), and the call proC9s~in~ routine rQturns to step 1200.
If,`in step 1215, it is det~ d that more than one call
state 174 is on call state stack 172, CALL CONTBXT module 88
"pops ' thQ top call state from call state stack 172 (step 1216 )
and executes the CCPI record cuLL-~~onding to that call state
15 (8tep 1208)- Thi8 allow8 one CCPI record to llhand over' to
another CCPI record and then return to execution of the original
CCPI record.
The complete call processing operation for a ~ingle call will
now be d~s~rih~d with regard to Fig. 62. In this example, it i5
20 a58umed~ for ake of description, that the CCPI record contains a
CONVE~SATION node requesting the caller to input a personal
identification number (PIN) (as ~hown in the graph of Pig. 42).
Also, in this examplQ, it i8 assumed that the ~raph "key" is
3151234567.eO4. The L~ ar of the graph i8 as shown in Fig.
25 42.
The graph shown in Fig. 42, with the above change, ha~ been
created and stored as a CCPI record in database 60 at SCP 18.
When ASC switch 12 receives a phone c~ll from a phone having a
phone number (315)123-4567, it send~l a TCAP me~sage to SCP 18.
30 CO~MUNICATE module 84 reads the me~sage and places it onto message
handler input queue 906. MESSAGE HANDLER module 86 gets the
mes~age from me~sage handler input queue 906 and initially
det~i r~ ~ whether the message is a conver~atlonal re~ponse . In
this example, the message is not a conversational response, 80
35 NESSAGE H~NDLER module 86 identifies the CCPI record needed to
respond to the message based on the key 3151234567.eO5, and
generates a call context c~LLO_~ûn~ing to this me~age. MESSAGE
.
~WO 92/11603 2 Q 9 ~ ~ 0 8 PCr/US9l/09457
- 51 -
HANDLER module 86 then places the generated call context onto call
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 initi~lly
det~ n~ whether this call context has been processed
previously. Since, in this example, this call context has not
been previously processed, CALL CONTEXT module 88 calls GRAPH
10 BUFFER module 78 to get the ccLL~..y~nding 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 i8 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 output queue 912.
NESSAGE HANDLER module 86, which i8 looking for a call
context on call output queue 912, reads the call context once it
20 h~s been placed on call output queue gl2. NESSAGE HANDLER module
8 6 then inquires whether the call context is convereational .
Since the ci~ll context is conversational in this ex~mple, NESSAGE
HANDLER module 86 places the call context onto conversational
calls queue 914, and generates a message from the cSIll context to
25 prompt the V~.CL~ItoL to input a PIN. This message i~ placed onto
message handler output queue 908.
CnMMn~Tr~'rE module 84 gets the message from me~sage handler
queue 908 and sends the message back to ASC switch 12. The call
processing operation then continues to proce~s other --9~j~.33 from
30 SCP 1 8 .
In response to the PIN input by the operator, ASC switch 12
again sends a message to SCP 18. ~nMMnNIr~ module 84 reads this
message and places it onto message h~ndler input queue 906.
~ESSAGE HANDLER modul~ 86 gets this message from queue 906 and
35 det~rmin~s whether the message is a conversational response. In
this example, the PIN input by the caller is a conversational
response, and theLef~Les~ NESSAGE HANDLER module 86 gets the
coLLe~ ding call context from conversational call8 queue 914.
WO 92/11603 2 0 ~ 8 6 0 ~ PCI/US9l/09457
-- 52 --
. .
This call context i~ placed onto call input queue 910 for further
processing by CALL CONq~EXT module 88.
CALL CONTEXT module 88 reads the call context from call input
5 queue 910 and det~rm;n~s whether this call context has been
previously proce~ed. Since this call context h~s previously been
processed in this example, the CCPI record is not retrieved from
database 60 . Instead, CALL CONTEXT module 88 det~i nqE~ whether
execution of the CCPI record is complete. Since, in this example,
10 the CCPI record has not been completely executed, the next node of
the CCPI record is e,JLa_uLed. Bach of the nodes of the CCPI record
i8 then executed.
In this example, it is assumed that the operator input PIN
1234. As illustrated by the graph of Fig. 42, CAL1 CONTEXT module
15 88 det~ n~s from the execution of the CCPI record that the call
from phone number (315)123-4567 should be routed, add~ this
inf ormation to the call context and place~ the call context onto
call output queue 912. MESSAGE HANDLER module 86 reads the call
context and, det~m;n~"~ that the call context is not
20 conversational, generates a message from the call context to
inform ASC switch 12 to route the call. MESSAGE HANDLER module 86
places this messagQ onto mess~ge handler output qu~ue 908.
CO~tJNICATE module 84 then reads the mes~age from queue 908 and
sends it to ASC switch 12.
2~
F. ~nh~nrqd Call Pro~eY~ r For Visual
Indication of E~ ~_u~d GraDh
Having created a graph, an operator can test the qraph by
proc~V81 ng a call generated by a swltch or switch ~imulator prior
30 to deploying the CCPI record into the AIN nQtwork 10. This
testing can be done on SMS 20, PC 22, SCP 18, SN 16 or ad~unct 14,
provided these device3 contain a CS application 46 comprising call
proc~i n~ portion 56 and a switch or switch simulator.
Although such a test indicates which cnll proc~ n~ was
3~ performed correctly, if the call proces~ing wa~ performed
incorrectly, the test does not indicate the reason that the c~ll
proc~sin~ failed. Accordingly, another ~ ';'; t of the present
invention provides for a vi~ual indication of the execution path
.
~ 0 92~11603 2 ~ 9 8 6 ~ 8 PCr/US9l/119457
-- 53 --
. .
taken through a graph while proce~in~ a call. This ' -'i t
preferably uses an application - ~in7 an ~nhAn~ed call
processing portion and can be; 1 ' ed on the SMS 20, PC 22,
S SCP 18, SN 16 or ad~unct 14.
The visual indication can be provided at any of these devices
provided a CS application 46 ' ~~8 service creation portion 54
and an operator interface 44 are provided at that device. Thus,
the visual indication of the execution path on the gr~ph can be
10 provided at the device p6LLGL~ng the call proc~;n~ (local
visual indication) or at a device remote from the devLce
perf orming the call proc~ ; n~ ( remote visual indication ) . The
visual indication can be provided for call proce~sln~ in a testing
mode or in the AIN network 10.
In a preferred: ' ; L, the visual indication '
h; ~hli~hting the execution path as taken during call proc~;
directly on the graph, preferably as a red line connecting the
graph nodes e..e~ Qd to process the call (L~f6LLeld to herein as a
trace-). Elowever, any other type of h;~hl;~hting can be used to
20 identify the ~Y~c~ n 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). PrQferably, when a
step' indication is E~Lr _ ', the "trace" is also provided.
In a pref err~d ~ , the pre~ent invention provides f or
the "tracen and ~t~pa visual indications by ~nhJ~nt~ing the call
proces~ing operation performed by CA~ CONTBXT module 88 as shown
in Figs . 68A and 68B. Howav~r, the proceQs; n~ operations of
~n JN I ~ 'A~IIE modul~ 84 and ~BSSAGE HANDLBR module 86 remain the
30 8ame as described above . For the ~nhJ~nro~t call pL~ i ng of
Figs. 68A and 68B, steps 1200-1216 are identical to those shown
for the call proc~4~ing of Fig. 67. }lowever, for enhAn~ed call
processing, after creating a call state for the CCPI ~ecord and
pushing the call state into the call state stack, CAI~ CONTEXT
35 module 88 det~rm;nP~ whether any of the "global" or "record,"
step" or "trace" flags are set (step 1300).
"Global" flags refer to flags ~ A~i;n7 to a plurality of
CCPI records. If a "glob~l" flag is set, the ~Y~ut;on path taken
WO 92/l 1603 ~ PCr/US9l/09457
2~98~ 54_
through the CCPI record is stepped through or traced for every
CCPI record executed ~C-p~n~n~ on the flag selection. ~Record"
flags refer to flags cGLL~ _~u~ding ~to each individual CCPI record.
5 I a ~record' flag i9 set for a CCPI record, the ~LL~L~ol~ding
graph i8 displayed and the execution path tAken through the gr2ph
Ls stepped through or traced dep~ ng on the f lag selection when
a call is executed by c-"h~n~ed call processing portion 56 in
either a creation environment ( local ) or a call processing
10 environment (which in~ an Application c Qlng only
~nholn~Pd cAll procesQ~ng portion 56 and no operator interface;
remote ) .
"Global, "step~ and "trace flags are preferably set by the
operator in accordance with the flow diagram shown in Fig. 69.
15 Initially, the operator digplay8 the main interface window and
selects the "OPTIONS" menu (step 1400). In re~ponse, CONTROL
module 106 displays the "OPTIONS" menu options, as shown in Fig.
13 (step 1402). The operator then select~ the "I~:A~:eU. 10.." 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 tstep 1408).
The c-~LL.~ .ding "global flags are set by CONTROL module 106
(step 1410).
~Record" flags are preferably set by the operator in
accorrl~"re with the flow diagram illustr~ted in Fig. 69 except
that in step 1400 the "OPTIONS" menu 144 is selectQd from the
graph edit pad window as shown in Fig. 29. In addition, after the
flags are set, the o~LGtor performs a "SAVE" operation ~8
30 described above, to set the "record,~' trace or step flag. If the
CCPI record C~L .,~ .ding to the graph is to be call processed at
a remote call ~L~_ ~Ei"g environment, MAIL module 100 transfers
the CCPI record from the creation environment to the r~mote call
processin~ environment.
3~; Referring back to step 1300 in Fig. 68A, if none of the
' global ' or ~record, ' "step" or "trace" flags i~ set, CALL CONTEXT
module 88 del e~eQ, whether the CCPI record has been completely
executed (step 1208). If either the ~globAll~ or "record,l' "trace"
2 ~8 6 ~8 UsglJO9457
~092/11603 PCr/
-- 55 --
. .
or "step" flag is set CALL CONTEXT module 88 dete-r~nines whether
the ~nh~.nced call processing operation is being p~- C ~ in a
creation environment (step 1301). This determination is made
5 based on an environment f lag .
As oYrli~ i n~d above, a creation environment includes a display
48 and service creatlon 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 di~play 48, the execution results of the call processing
are preferably sent to a creation environm~nt for display. Thus,
different actlons are taken by the ~nhAn~ed call processing
portion 56 depon~lin~ on the environment in which the onhAnred call
15 processing is being p~LL~ ~.
If, in step 1301, the onh~nrPd call procos~ing is performed
in a creation environment, CALL CON$EXT module 88 di~plays the
graph edit pad window and associates the call context with the
graph edit pad window (step 1302). If, in step 1301, the anh~nred
20 call processing is performed in a call procos~in~ environment, the
CALL CONTEX$ module 88 opens a file for the call context ~step
1304) to record oY~uti~n information.
CALL CONTEXT module 88 than detormins~ whether the CCPI
record has been completely e~_u~ed (step 1208). If 80, CALL
25 CONTEXT module 88 ~ steps 1215, 1214 and 1216, as discu~sed
with regard to Fig. 67. If not, the next node is executed (~tep
1210 ) .
After executing a node, CALL CONTEXT module 88 again
detormino~ whether the ~global~ ~record~ trace or step flags are
30 set ( step 1306 ) . If not, C~LL CONTEXT module 88 repaats step
1208. If one of these flags is set, however, the determination of
step 1301 is repeated.
If the call proca~sin~ is belng performed in a creation
environment, CALL CON$EXT module 88 calls NODE modul~ 64 to set a
35 f lag in the internal data structure L~ Lation of the graph
indicating that node has been ~c. ~ (step 1308). As iP~3rrih~A
Above, ch~nges to the internal data i~LU~UL~ L~PL~ tation are
reflected up through the abstract displayod LelpLf ~e ~ation, and
- S9l/0~457
wo92tll603 2a986~s Pcr~u
-- 56 --
, .
displayed on the screen. Thus, when performing ~nhAnre~ call
processing at a creation environment, the settlng of a flag in the
internal data structure Lc~ e~ ation fter processing a node is
S reflected as a hi~hl~htLng between the processed nodes on the
displayed graph. If the PnhAnced call processin~ is instead being
performed at a call processing environment without a displ~y or
s~rvice creation portion 54, CA~ CONTEXT module 88 u~dates~the
file to indic~te that the node has been executed (step 1310).
CAI,L CONTEXT module 88 then detP~in~ whether the processed
node i8 a CONVERSATION node (step 1212). If 80, CAIL 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
~re perf ormed .
Af ter creatlng a call state and pushing the call state into
the call st~tQ stack, or if the ~,-oc_8~` node is not a handover
node, the Pnh~nrP~ call processing pe,LoL..._ step 1301. If the
~nhJIncpa C~ll proCe~ n~J i8 being pel ~ ' in a call procpc~i n~
environment, CALL CONTEXT module 88 returns to step 1208. If the
20 ~nh~nred call p ~ ng i8 being performed in a cro~tlon
Qnvironment, CALI, CONTEXT module 88 determinP~ the l'global'
"record~' step fl~gs set (step 1312). If not, CALL CONTEXT module
88 repeats step 1208. If 80, C~LL CONTEXT module 88 sets the
status flag of the call context to ~walt' (step 1314) and returns
25 to step 1200.
Step 1314 c~uses execution of thQ CCPI record being call
processed to stop. Thus, if the CAll is being p oceP8~ in a
cr~ation environm~nt, thQ ~Pcution path taken through the CCPI
record is vi8utl11y indicated by di~playing one nod~ at a time and
30 tracing the execution path between the nodes. The op~rator can
select the "STEP~ option of the EXECUTE menu, shown in Fig. 30, to
~xecute the next node. When the o~- ..tu~ ~elects the STEP option,
the call context for the _OL ~c~n~ing CCPI r0cord is placed on
the call input queue,
For PnhAn~Pd call proc~s~ing, aft~r a call context has been
output to the call output queue 912 tstep 1214), CALL CONTEXT
module 88 der~in~Y whether either the ~lobal~' or record trace
~WO 92/11603 2 0 9 8 6 ~ 8 PCI/US91/094~7
-- 57 -
flags is set ~step 1316). I~ not, CAI,L CONTEXT module 88 returns
to step 1200. If 80, step 1301 is repeated.
If it i9 det~ nPd that ~nh~n~ed call processing is being
S performed in a creation environment, CALL CONTEXT module 88
returns to step 1200 . If, however, it is det~rmi n~d that call
processing is being perL~ ~' in a call proc~in~ 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
prefer~lbly causes a t~leFhnn~ window 121 to appear on the display,
as shown, for example, in Fig. 7. Nindow 121 indicates to the
operator that f iles c<,LL~_yu..ding to CCPI records ex~cuted at a
15 remote call proces5ing 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
~nhln~ed call proce~Ein~ at a remote call processing environment.
20 Initially, CONTROL module 106 receives ths file (step 1600) and
calls GRAPH module 62 to update the internal data structure
Le~L~r_..tation of the graph wlth the information in the file (step
1602). The operator sQlects the t~lephnnA window 121 on the
display ( step 1604 ) and CONTROL module 106 calls DIALOG module 104
25 to di8play a C~L L~.e~-",ding dialog box shown in Fig . 71 ( step
1606 ) . The o~aL~toL then selects the "kQy" of thQ graph to be
displayod (step 1608). Next, CONTROL module 106 calls OBJECT
TABLE module 110 to translate the internal data nLL l_~
LC~!L~ Ee.~tation of the graph into the ab~tract displayed
30 L~.~L-.~_Atation (8tep 1610), CONTROL module 106 also c~lls SCREEN
module 102 to draw the graph onto the display with a ~'trace"
vi~u~1 l=dl~=tlon o~ th~ ~oggtlo= p~tù l= tù~ gr~pù (~t~p 1612).
Wo92,ll603 2a~8~ PCr/US91/094S7 ~
.. . .
-- 58 --
G. Validation
Validation is conRi~red a separate operation from testing.
In testing, a visual indication of the processing is created so
S that the operator can ensure that the p ~ co~ vl~ding to
the qraph is proceeding as desired. Validation, on the other
hand, is intended to determine whether the n~ce~Y~ry connections
have been allowed in creating the graph. In the preferred
' - ' 1 L, validation involves use of an expert system .
Expert systems are available for detecting logical
infractions in a prore~in~ routine and generating a list of these
infractions based on a set of rules and ~ knowledge base
ul~d~Yst.ood by the expert ~ystem. The present invention employs an
expert system to identify logical infractions in displayed graph
15 5. -
Preferably, there are two types of infractionss "severe`' and"warning. Severe infractLon3 are identified by the expert ~yste~
as problems that will produce e~ L~ /U8 call processing. Warning
Lnfractions are itlF~n~fied by the expert system as problems thAt
O may cause erroneous call ~ nq.
The following is an ~ ry li8t of rules utilized by an
~xpert system to identify in an: ' ' i - t of the invention
"severe~ and "~ rn1ng" infractions in a graph.
1. Nust hAve "other" branch for TINE, DATE, LATA nodes
( severe );
2. Nust have all branch v~lues for DAY node tsevere);
3. ~ErT.SI~8N nodes need more than one branch (severe);
4. Every cycle in the graph mu~t have at least one DECISION
node ( sQv~re );
5. No DLN[x,y] node can precede a DI,N[p,q] if xcp and y~q
( warning );
6. No ANI[x,y] node can precede an A21I[p,q] if x~p and y~q
(warning );
7. No duplication of ASb_ ~. nodes on a single path
through the graph ( warning );
~0 92~11603 2 ~ 9 8 ~ 0 8 PCr/US91~)9457
-- 59 --
8. SERVICE SPECIFIC RULES
800
a. no CONVERSATIONAL nodes allowed (warning);
S Out~oinq c~ll scrQenin~
b. no ROUTING NUNBER nodes allowed
Fig. 72 is a flow diagram, illustrating a preferred operation
of an expert sy6tem in Ac-cor~l~nce with the invention. Initially,
the operator sQlects 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 ~Lu~LuL~ .G~L- s~..tation
of the graph being displayed into a get of ~gchemag~ co..- ,~ i; n~
to the nodes of the graph and insert thQsQ " 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 rulQs previously input to the expert
system, such as the rules sEer~fi~i above, and generates a list of
errors in the graph . The Qxpert systQm also f lags Qach node and
branch containing an error ( step 804 ) . Flagging the nodQs and
20 hr~nrhr~s changes the data sL.u- Lu.a3 of the internal dAta
structure e~p.a~_.-Lation of thQ graph.
CONTROL modulQ 106 then calls OBJECT TABLE module 110 to
translate the internal data :,L.u-_Lù.c .c"~ t~tion into thQ
abstract displayed ~ e_..Lation ~ step 806 ), and calls SCREEN
25 module 102 to translatc the abstract displayQd LG~L~c_..t-tion into
the displayed graph (step 808). The flagged nodes are highlighted
on the screen to idG~ntify the error nodes. Thus, the operator can
readily identify errors in the graph and corrcct these errors if
n~ce~8~ry. In a ~.eLe. ~ . ~ L, the ~ L..tor may also
30 select the h ~ ~h 1 i qhted node ( stQp 810 ) to display a list of errors
f or the h i ~h 1 i ~Jhted node ( step 812 ) .
Examples of known expert systGms which can )~e used in accor-
dance with the present invention includQ the AutomAted
Reasoning Tool ~ART) p.~,du- ed by Inference Corporation and the
35 L~ser Expert System produccd by Bell Atlantic l~nowledgQ System
Corporation. Other expert systems are ~vailable and can be used
in accordance with the prQsent invention.
wog2/11603 2~8~ia~ ` PCI/US9l/09457
-- 60 --
H. Summarv
While there has been illustrated and described what are at
present considered to be pref erred A ~ i - ' t g and methods of the
5 present invention, it will be understood by those skilled in the
art that various changs3s and modific~tions m~y be made, and equiv-
alence may be substituted for eiements thereof without departing
from the true ~cope of the invention.
In addition, many '~fic~tions may be made to ~dapt a par-
10 ticular element, technique or i ls tation to the teachings ofthe present invention without departing from the central scope of
the invention . Theref ore, it is intended that this invention not
be limited to the particular ~ ts and methods ~ lose~l
herein, but tho.t the invention include all _ ~ 'i ts falling
15 within the scope of the a~e..~ed claims.
2S
