 |
Description  |
|
|
TECHNICAL FIELD OF THE INVENTION
This invention relates to programing display telephone sets by downloading
scripts from the network to the telephone sets. More specifically, this
invention provides a system and method for automatically generating a
custom service script for a display telephone set based on a user profile
of requested features and sets of generic scripts for each of these
features.
COPYRIGHT AUTHORIZATION
Annex E, F, and G of the disclosure of this patent document contain
material which is subject to copyright protection. Bell Communications
Research Inc., as the copyright owner, has no objection to the facsimile
reproduction by anyone of the patent document or the patent disclosure, as
it appears in the Patent and Trademark Office patent file or records, but
otherwise reserves all copyrights whatsoever.
BACKGROUND OF THE INVENTION
Telecommunications services are complex and, as more services become
available, the user access to these services becomes more unmanageable
without user friendly assistance. Experiments by telecommunications
service providers have shown that if the user interface to network
services can be simplified, it is likely that users may access and use
these new more complex services more often. One way to simplify access to
these services is to provide the user with a screen-assisted interface to
the services.
One such experiment conducted by Bell Communications Research provided a
more usable access to network voice services via advanced Customer
Premises Equipment (CPE) with a screen display and context-sensitive soft
keys. This interface enabled the network to support screen-assisted
management of CLASS.SM. and Custom Calling Services (CCS). The experiment
was to determine if the utility and acceptability, and therefore, usage,
of network services were positively affected by a screen-assisted
telephone. Residential subscribers used a prototype CPE during the
experiment and accessed network services using this device.
The prototype CPE provided a 7 line by 16 character liquid crystal display
(LCD) as a visual interface that responds to user actions in context of
the call states. The visual interface provides the users with context
sensitive menus, step by step prompts, visual indicators of the services
status, and a call log feature. This specific experiment demonstrated the
acceptability of a screen-assisted telephone. It also indicated customer
interest in acquiring such phones and helped to confirm that there is a
need to make network services easier for customers to access and use.
Visual access to voice services via display-based sets can improve the
usability of current and future services by providing customers visual
choices or options for services at appropriate times during a call or
service transaction. To provide this capability in a generic way, the
Analog Display Service Interface (ADSI) protocol has been developed to
provide an interface between the network service features and the advanced
CPE, such as visual displays and soft keys, and allows the network to
support screen-based management of telephone services. The ADSI protocol
has been publicly disclosed in Bellcore Technical Reference "Generic
Requirements for an SPCS to Customer Premises Equipment Data Interface for
Analog Display Services", TR-NWT-001273, December 1992.
The ADSI protocol defines a generic way for the CPE to communicate with the
network switching equipment to access and invoke various service features.
The CPE in using the ADSI protocol to access service features will have
scripts that are executed based on user response to the call states.
However, the network environment for implementing these advanced services
comprises customers served from different central office switch types
using different procedures for accessing the same features. Consequently,
this means that the scripts in each CPE must be matched to the specific
line, switch, and switch software requirements and updated when the switch
software is updated or when the switch is changed. Therefore, embedded
within the ADSI protocol is a feature download capability which allows the
downloading of a service script from the network to the screen capable
CPE. These service scripts stay resident in the CPE's memory and are used
to create screen displays in response to network signals for accessing
service features. These scripts can therefore be changed as the switch and
switch software change and then downloaded in the CPE. If the scripts were
built into the CPE, the customer would be faced with equipment that would
become incompatible with the network as the network changes.
Service scripts for use in ADSI devices are defined in Bellcore Special
Report entitled "Customer Premises Equipment Compatibility Considerations
for the Analog Display Services Interface", SR-INS-002461, December 1992.
Such scripts consist of a set of op.sub.-- code instructions. However, the
telephone companies do not expect a programmer to write Service Scripts in
the binary op.sub.-- codes as defined in DR-INS-002461. High level
scripting languages are being developed for the script programmer.
Appendix 2 of SR-INS-002461 illustrates scripts developed in an example
high level language.
Another variation in the environment for advanced call management features
in screen based telephones, in addition to the need to operate with
various switch types and switch software, is that different customers have
different requirements for suites of service features. Therefore, a
service script to support one customer's suite of service features is
going to be different than that of another customer. Consequently, there
is a need to develop service scripts for various sets of features.
However, to write a service script for each permutation of all feature
sets becomes quite difficult as the number of features increases.
Specifically, if there are m features, then there is a need for
##EQU1##
service scripts. For each one new feature added there will be 2.sup.m more
service scripts required. Building and maintaining these service scripts
can, therefore, become quite labor intensive.
It is therefore an object of my invention to provide the telephone
companies with the ability to build and maintain service scripts without
having to write a separate script for each permutation of service
features. It is a second object of my invention to provide an automated
capability for developing and then consolidating service scripts for
multiple features into a single service script for a customer and
downloading the consolidated service script.
SUMMARY OF THE INVENTION
My method and system automatically consolidate service scripts and download
such consolidated scripts to Analog Display Services Interface compatible
screen telephones. The method and system comprise specifying a general
template for all service features, specifying line specific attributes for
a feature, and then combining the two into a service module. Both the
template and module are specified in terms blocks of instructions grouped
as softkeys, event handler, call states, or macros. A customer's service
is composed of multiple service modules which, when selected, would be
consolidated in a network server computer into a singular service script.
The method of consolidation requires first creating software objects from
the blocks in the template. Second, the blocks from the service modules
are incorporated into each object created by the template or if an object
can't be found, a new object is created. Finally, the incorporation
process includes the insertion of the instructions from the modules into
the appropriate objects according to a rank order of the instructions as
determined by a ranking process in the software. The consolidated service
script is then compiled for downloading and transmitted to a local
processor in the compatible screen telephone.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a schematic diagram of one specific illustrative embodiment of my
invention.
FIG. 2 is a diagram depicting the scripting level class hierarchy in my
invention.
FIG. 3 is a diagram depicting a constituency tree for the template of my
invention.
FIG. 4 is an illustrative flow chart of my inventive method.
DETAILED DESCRIPTION
My invention provides a system and method for automatically consolidating a
set of service scripts into a single service script that is downloaded
from a network server, over the interface defined by Bellcore Technical
Report TR-NTW-001273, to a display device compatible with the
specifications set forth in Bellcore Special Report SR-INS-002461. In
order to best understand my invention it is important to understand my
overall inventive system, those constructs I call service modules and
service templates, the characteristics of my high level scripting
language, and my inventive method of automated service script
consolidation. Accordingly, this specification is divided into four
sections. The first section describes my inventive system for service
script downloading as depicted in FIG. 1. The second section describes my
service modules and templates. The third section describes the necessary
attributes of high level ADSI service scripting. The fourth and last
section describes my inventive method for using modules and templates for
automated service script consolidation.
System for Service Script Downloading
One specific illustrative embodiment of a system in accordance with my
invention to accomplish automated script consolidation is illustrated in
FIG. 1. An ADSI compatible telephone set 20, having a visual display 21
and a processor 22 with memory 25, establishes a connection through the
telephone central office 23 to an ADSI server 24. Within the server 24 a
download session administrator process 26 receives the call and engages
the telephone set 20 into a dialog in accordance with Bellcore
TR-NWT-001273. The administrator process 26 then retrieves from a user
profile database 28, that user's service profile. The profile includes all
services selected by that customer for that line, including both
subscription based and usage sensitive services. The session administrator
process 26 forwards to a service script generation processor 30, the
customer profile retrieved from database 28. The script generation process
30 then retrieves from a service module database 32 service modules that
correspond to those services selected by the user as evidenced in the user
profile (service modules are described in more detail in the sections
below). These service modules are, ideally, modules constructed according
to the requirements of my high level scripting language and service
template and service module constructs described in the sections below.
The script generation process 30 consolidates the selected service modules
into a single service script. The single service script is forwarded to a
compiler process 34 which compiles the service script generated by the
script generation process 30 to produce executable code compatible with
Bellcore TR-NWT-001273. The compiled executable code is forwarded by the
compiler process 34 to the session administrator process 26 and is
downloaded to ADSI telephone set 20 and stored in that set's processor
memory 25.
In the illustrative embodiment herein, the service script generation
process 30 creates a single service script from a set of service modules'
scripts in accordance with my inventive method as described below.
Service Modules and Service Templates
My system for automated service script consolidation requires the
development of service scripts from structures I define as service modules
and service templates.
A service module is a high level set of instructions for a particular
feature (features are network provided telecommunications capabilities)
that can be integrated with other service modules to form a new service
script. Within a service module, instructions are grouped together in
blocks. For example, consider the following segment from the service
module for Three Way Calling:
______________________________________
softkey3way.sub.-- ADD:"Add3rdParty":"Conf"{
do.sub.-- hookflash;
clear.sub.-- display;
clear.sub.-- clipboard;
display"PleaseWait . . . ";
set.sub.-- timer.sub.-- for3sec;
load.sub.-- overlay3way.sub.-- wdt;
______________________________________
Each set of instructions surrounded by "{"and "}" are considered a block of
instructions. By creating service modules for each feature, the
maintenance process is simplified as is the customizing flexibility. The
maintenance process is simplified because the number of service modules to
maintain grows only linearly, rather than exponentially, as the number of
supported features increases. The customizing flexibility is increased
because the priority of a feature can be specified on demand by the order
in which the service modules are specified, instead of hard coding yet
another service script.
My service templates are analogous to the base class and class template
concepts in object oriented programming (OOP). The template defines a set
of standard or skeletal call states and event handlers within the call
states. In one illustrative embodiment of my invention the service
template is nothing more than the script of the service module for Plain
Old Telephone Service (POTS) as disclosed in Annex A. Once a template is
defined, each service module can be created by sharing with, adding to, or
specializing, the template so that the attributes of the template are
inherited by all service scripts. In this way each service module becomes
an derived class of the template, as per the concept of inheritance in the
object oriented paradigm. Each service module shares common attributes
because of the template.
Using the template technique solves problems that arise when states
conflict in multiple service modules when consolidated into a single
service script. All states included in the template will be public to all
service modules. These are the common states, and guidelines can be set
when service modules need to modify the behaviors in these common states
so that conflicts can be resolved. Any other states that are not among the
common states are local states. Local states are private to a particular
service module. These local states need not be regulated because each is
specific only to that particular service module.
The template is the common denominator for all service modules. In the
illustrative embodiment described herein it is a physically separate
entity even though logically it is part of all service modules. With a
separate template, if modifications on the template are required in the
future only one file needs be changed instead of changing the template
portion of all of the service modules. Using this model, a service module
is broken into 2 files, the template file and the feature specific file.
However, I can envision other embodiments where the template is not
physically separate from the service modules.
If an analogy is drawn from set theory, a service module is the union of
the template file and the feature-specific file. Similarly, a service
script is the union of all of the constituting service modules. Using the
object-oriented paradigm, a service script can be viewed as an instance of
a class which is a child class of multiple parent classes. This concept is
called multiple inheritance. As an illustration, view the template as
virtual base class T, each service modules as class M.sub.i (i=1,2, . . .
), and each service script as class S.sub.j (j=1,2, . . . ). Each service
module is derived from the template and so class M.sub.i is a derived
class of T. Now, since a service script is created by combining a set of
service modules, class S.sub.j is a derived class of all of the consisting
class M.sub.i s. The resulting object of multiple inheritance exhibits the
behaviors of all of the constituting parent classes; similarly, a service
script exhibits the behaviors of all of the constituting service modules.
FIG. 2 is an example of the inheritance relationship among the template,
the service modules, and the service scripts. Service scripts at level 40
inherit attributes from service modules at level 42 which inherit
attributes from template 44. Therefore, using these structures if changes
are made in the template they will be reflected through the levels 42 to
the scripts at the lower level 40.
In addition to structuring service scripts in accordance with the template
and module constructs defined above, a scripting language as described
below is helpful in the practice of my inventive method for service script
consolidation.
Attributes of ADSI Service Scripting
Programmers are free to write service scripts in binary code as defined in
the SR-INS-002461 or use a high-level scripting language/environment. The
use of a high level scripting language plays a critical role in successful
service script creation and management because it not only provides a more
user friendly environment for the script programmer but also can act as a
successful means for integration of multiple service scripts. An example
of a scripting language is one that provides a one-to-one mapping between
the scripting language and the op.sub.-- code and return string code
(rs.sub.-- code instructions defined in SR-INS-002461. SR-INS-002461
defines a set of capabilities and constraints from which the scripting
language defined herein is derived.
Depending on the degree of flexibility to be given to the script
programmers and the type of targeted applications, the scripting language
can implement all or only a subset of the instructions disclosed in
SR-INS-002461. In particular, some rs.sub.-- codes pertain mainly to
Service Display Control applications, rather than Feature Downloaded
Service Scripts. Therefore, in my scripting language, these rs.sub.--
codes have been excluded from the scripting instruction set.
My scripting language reduces the complexity of script programing by using
default parameters for the op.sub.-- code/rs.sub.-- code whenever
possible. For example op.sub.-- code 1 in SR-INS-002461 requires
specifying the number of instructions to be executed when the specified
event occurs. For this case, the corresponding scripting instruction for
op.sub.-- code 1 contains a block of script instructions to be executed.
The resulting number of instructions are automatically calculated and put
into the proper field of op.sub.-- code 1, sparing the script programmer
from such meticulous details. An example of a script instruction for
op.sub.-- code 1 may look as follows:
______________________________________
on NORMAL.sub.-- RING
instruction 1;
instruction 2;
. . .
instruction n;
end
______________________________________
When a normal power ring is detected, the specified n instructions will be
executed regardless of the value of the current state ID. This set of
instructions is called a block.
Another example of a scripting instruction that simplifies op.sub.-- code
requirements in order to make script programing easier is:
______________________________________
on NORMAL.sub.-- RING
display "New Call";
end
______________________________________
In this example, the scripting instruction display, which corresponds to
op.sub.-- code 3, hides a lot of complexity from script programmer.
Namely, the Control field, Predefined Display ID field, Stored-at Line
Number field, and the Flag ID field of op.sub.-- code 3 all become
transparent to the programmer. These fields are either assumed, implied,
or calculated by the script compiler. In particular, the Control field
(See SR-INS-002461) is assumed to be 11 (store and display); the
Predefined Display ID field is implied by the string "New Call" and is
assigned automatically; the Store-at-Line Number field is calculated
depending on the number of consecutive display instructions; the Flag ID
is assumed to be 0 (independent of flags). More complicated versions of
display can be provided in case the script programmer needs the hidden
flexibility, but this simplified version makes a lot of sense since these
op.sub.-- code fields bear these assumed/calculated values most of the
time.
To empower the script programmer beyond what is provided in SR-INS-002461,
some scripting instructions can be furnished with capabilities that allow
the script programmer some control over the resulting Service Script even
though they have nothing to do with any op.sub.-- code or rs.sub.-- code.
Since these added capabilities are not supported by SR-INS-002461, they
impact only on the process of producing the resulting Service Scripts.
Their functions are removed once the Service Script is compiled. These
pseudo scripting instructions are commonly referred to as "preprocessor
directives." One example of a preprocessor directive is #ifdef, which can
be found in C-Language; #ifdef allows conditional inclusion of
instructions before compilation. Consider the following example:
______________________________________
on IN.sub.-- CALL.sub.-- ANS
clear.sub.-- display;
display "Talking to";
#ifdef CALLER.sub.-- ID
display "$call1p";
#else
display "Party Unknown";
#endif
end
______________________________________
When an incoming call is answered, the display would show the identity of
the caller if the Caller.sub.-- ID feature or service module is included
in the Service Script; otherwise, the wording "Party Unknown", would be
used instead. The resulting ANSI executable code includes either but not
both. The instructions tagged with a # do not correspond to any op.sub.--
code specified in SR-INS-002461.
However, some "new" scripting capabilities can be defined which actually
result in a sequence of op.sub.-- codes or rs.sub.-- codes i.e. supported
by SR-INS-002461. For example a "banner" instruction could be defined if
deemed useful such that
banner "One Moment, Please.";
would clear the display "One Moment, Please" wait for a few seconds, and
then clear the display again. This would result in a sequence of op.sub.--
codes 5, 2, and 11 if "banner" is an opcode derived instructions; or a
sequences of rs.sub.-- codes 0.times.97, 0.times.98 and 0.times.90 if it
is a rs.sub.-- code-derived instruction. Note that in the SR-INS-002461
specification, some op.sub.-- code and rs.sub.-- code functions overlap
while others don't. Considerations should be taken so that an rs.sub.--
code derived instruction is not confused with an op.sub.-- code derived
instruction and vice-versa. Both the script programmer and the script
compiler need to distinguish between the two.
Procedure calls are desirable and common in programming languages but they
don't exist in the context of the protocol of SR-INS-002461. However, a
pseudo-procedure call can be implemented. It will not be a true procedure
call because the script program pointer is memoryless; as a result there
is no way to get back to where the procedure was invoked upon completing
the procedure calls. Nevertheless, it does reduce the size of the
resulting Service Script, and conservation of code size is one of the
reasons for procedure call. A pseudo-procedure call can be implemented
using the two user-definable event codes (22 and 23). Each
pseudo-procedure essentially consists of op.sub.-- code 1 specifying the
triggering event code say, 22, plus the set of embedded instructions
associated with the op.sub.-- code 1. These pseudo-procedures are placed
within appropriate overlays. Now, an rs.sub.-- code derived scripting
instruction say, go-to, can be defined to invoke the pseudo-procedure. The
go-to instruction can basically consists of the Overlay rs.sub.--
code(0.times.9D) and Event 22 Trigger rs.sub.-- code (0.times.9e).
According to the parameter(s) specified for the go.sub.-- to instruction,
the appropriate overlay is loaded, and event 22 is triggered; thus the
corresponding pseudo-procedure is invoked and executed.
A simpler but less desirable alterative is the use of macros. Macros
provide similar functions as true procedure calls, except they to not
conserve any memory space the way true procedure calls do.
Since ADSI Service Scripts are event driven, the scripting language should
be designed specifically to implement state machines. This means there
should be a state variable upon which state transitions are triggered upon
the happening of various events. I use overlays described in
SR-INS-002461, as the state variable.
Another important attribute of a scripting language to be used in my
inventive method and system is that the instructions are organized into
manageable sized blocks. Specifically, in my scripting language all
instructions are written into blocks defined as states, event handlers,
soft keys, or macros. In my scripting language these blocks are delineated
by brackets. Annex G is a detailed specification of the syntax of my
scripting language.
Referring back to FIG. 1, my inventive system requires a script generation
process 30 for consolidating service scripts. In my preferred embodiment,
this script generation process accomplishes service script generation and
consolidation in accordance with my inventive method, further defined
below. My preferred embodiment of my inventive method requires a
high-level scripting language as defined above and the service module and
service template paradigm described in the previous section.
Method for Automated Service Script Consolidation
The script processing and consolidation is accomplished on three levels and
is written in C++ object-oriented programing language. The template is the
base class in an object oriented paradigm. From the template, objects
based on blocks defined in the template are created. Within the blocks,
other blocks are de | | |
