Note: Descriptions are shown in the official language in which they were submitted.
CA 02254258 1998-11-18
- 1 -
REMOTE CONTROL OF CPE-BASED sERVICE LOGIC
Related At~plicationa
S
Field of the Invention
,. , .
The invention relates to methods of operating
telephone network service logic, to methods of paging a
customer by using a customer terminal coupled to'a
io telephone network, to corresponding apparatus, software,
and methods of programming, to customer terminals for such
methods, to methods of using such customer terminals, to
corresponding software for such terminals, and to methods
of~programming such terminals.
Backcrouad to the Invention
Known Customer Premises Equipment (CPE) or customer
terminals for using telephone networks may be capable of a
ao range of functions such as:
1) causing an indicator light to go on or off,
2) making the terminal go on- or off- hook,
3) dialing and setting up an outgoing call automatically,
as 4) switching a speakerphone on or off,
5) making the display show some downloaded data,
6) making the display show some soft keys, and
7) sending an indication of a soft keypress to the
network.
Such terminals are typically designed for use with the
well known ADSI (Analog Display Services Interface)
bSibO'd 9Zb2~S66 O1 Z10~ TZG ~'L9 S1N31dd 1N 2!d S'L:2~ 86. BZ flON
CA 02254258 1998-11-18
- 2 -
protocol for transmitting voice and data over telephone
networks. This is used widely for enhanced services such
as home banking, and directory services. Such services
involve the customer initiating a call to the service
s provider's server, which can then download menus of
choices and data fox display. The server may control
terminal function to the extent of dictating what is
displayed, and/or heard by the customer. Detailed
descriptions of such terminals and such services are
io widely available and need not be repeated here.
It is also known to trigger remotely individual
terminal functions e.g. from a local switch in the
telephone network, by sending a data message to the
terminal. one example of this is the MWI (Message Waiting
i5 Indicator) message, a GR-30 standard message which can be
used to switch on an indicator on the terminal. This
extension to GR-30 forms part of another published
Bellcore specification, TR -NWT-001401. Another example
may occur in call set-up, when a message may be sent to
ao cause the terminal to display "long distance" for an
incoming long distance call. In this case, a call
qualifier field in the GR-30 call set up message is used.
This is published in Bellcore specification TR-NWT-000031.
The term "remote control" is intended to encompass not
2s only control of a CPE terminal from a switch located on
telecommunication company property, but also from switches
such as PBXs (Private Branch Exchanges). These may be
located in the same building as the terminals they serve,
and are considered as part of the network for present
3o purposes.
Another example of remote control of a terminal
function is the GR30~ CPEID (Customer Premises Equipment
bSiSO'd 9Zb2~S66 O1 ZI0~ TAG ~T9 S1N31tid 1N bd ST:2~ 86. 8Z tlON
CA 02254258 1998-11-18
- 3 -
IDentifier) message used for putting the terminal off-
hook. This is published in ADSI specification document SR-
INS-002461. It is used in SRA (Suppressed Ringing Access)
calls which may be used for transmitting data without the
s telephone ringing and disturbing the customer. This can be
useful for utility meter reading, or for downloading
software scripts for running at the terminal side as
opposed to the network or server side. The switch provides
a suppressed ringing access, then a server sends a CPEID
~o message, and then the line is set up for downloading data
such as a script. This is useful for addressing a
particular terminal where a number of terminals are
connected to the same subscriber line. A disadvantage of
this particular message is that it needs to include the
Zs identity of the individual phone. This information needs
to be obtained and stored somewhere, and the correct
identity retrieved and incorporated each time such a
message is sent, even if there is no need to specify the
particular terminal (e.g. if there is only one terminal or
2o if all terminals are to be addressed). This effectively
restricts use of the message to services such as script
download for which the identity of the phone would be
needed.
Bellcore has published techniques for ADSI script
zs management, usually carried out on an ASMS (ADSI Script
Management Server) connected to or within the network.
This also known as an ACMS (Advanced Call Management
Services) server. Also, European patent application 0 841
792 describes some examples of script download, and is
ao hereby incorporated by reference. Some such scripts may be
limited to actions which control data flow within a call,
e.g. displaying a menu then detecting and sending a soft
bSi90'd 9Lb2~S66 O1 Zi0~ i~G ~i9 SlNSldd 1N bd SZ:~~ 86. Bi SON
CA 02254258 1998-11-18
- 4 -
keypress selection back to the server via a switch. What
is displayed at the terminal is controlled remotely by the
server. Other scripts involve a sequence of actions which
affect the call itself, e.g. putting the terminal off hook
s or on-hook. This subset of scripts will be referred to as
service logic scripts. A call involves at least starting
to set up a voice path
While such service logic scripts are normally triggered
and controlled by customer actions, there exists a
io mechanism for triggering remotely without customer
intervention. Bell-core standard TR-NWT-001273 provides
twenty or so possible triggers which can be sent by a
switch, to cause a service logic script on a terminal to
start or cease. Examples of these triggers include a
is normal ring, a special ring, a normal dial tone after the
terminal goes off-hook, and a stutter dial tone after a
terminal goes off-hook. In each case, a sequence of line
states or telephony signaling events is used to trigger
the service logic script.
2o Some limitations in these known methods have now been
appreciated:
Z) The reliability of correct detection of such line
states or signaling events is limited by terminal
hardware limitations and by line quality
2s considerations.
2) Even if correctly detected, there is a chance that
the given state or signaling event could conceivably
arise in the course of normal call (as opposed to
service specific call) processing, and not be
so intended as a service logic script trigger.
3) The number of different events or states is limited,
hence the number of service logic scripts which may
bS~LO'd 9Ld2~S66 O1 LtO~ TEL ~I9 S1N31dd 1N bd SZ:Z~ 86. 8t nON
CA 02254258 1998-11-18
- S -
be used is limited. Or, if the same state or event is
used in more than one service logic script, there is
a risk of interference between different service
logic scripts, when they are run simultaneously. The
number of events is limited by the standard and
because typically the capability of the local switch
to generate such events or states is fixed in
hardware and thus difficult or expensive to expand or
change. If there is more than one service running, or
io more than one service to which a detected event or.
signaling state could apply, the terminal would have
to make an assumption of some kind to resolve the
ambiguity, or be limited to running one service at a
time. The service designer must either know and take
i5 account of the assumptions, or must design the
services to avoid ambiguities arising, which is
difficult, if not impossible.
It is also known to send a GR30 call set up message to
a terminal when a call is already in progress. The
2o terminal may be arranged to interpret this as a command to
start a SCWID (Spontaneous Call waiting with
IDentification) service script. In this case the
limitation 1) mentioned above is overcome, but limitations
2) and 3) remain.
25 It is also known to use a script time-out mechanism in
the terminal, to terminate service logic at the terminal
after a given time, unless there is some user intervention
to reset the timer. Although this can address limitation
1) mentioned above, to improve the reliability of service
30 logic termination, it may result in premature or delayed
termination, and does not address any of the limitations
in relation to initiating or controlling service logic.
bSi80'd 9Lb2~S66 O1 LTO~ IZG ~T9 S1N31dd 1N dd 9Z:Z~ 86. BZ SON
CA 02254258 1998-11-18
- 6 -
Su~narv of the Invention
According to a first aspect of the invention
s there is provided a method of operating telephone network
service logic relating to a call over a telephone network
to a customer terminal, the service logic involving both
terminal and network functions, the terminal being
arranged to recognize data messages, and having terminal
io service logic scripts for execution at the terminal to
control the terminal functions, the method comprising the
steps of:
determining a script control data message fox
controlling remotely the execution of one of the terminal
15 service logic scripts at the terminal, the message
specifying to which of the scripts it relates; and
controlling remotely the execution by sending the
script control data message over the telephone network to
the terminal.
2o Compared to the prior art Bellcore specification
which uses signaling events or line states to trigger
terminal scripts, sending a data message for controlling
the terminal service logic script enables better
interaction between service logic at the network side and
2s the service logic script at the customer terminal. In
particular, limitation 1) mentioned above, relating to
reliability can be addressed. In relation to the prior art
use of a data message by the SCWID service, limitations 2
and 3 mentioned above are also addressed since the message
3o specifies to which script it relates. In relation to the
prior art remote control of individual terminal functions,
the invention enables, the service logic at the network
side can be simplified and run more efficiently for
bSi60'd 9~b~~S66 O1 GT0~ i~G ~~9 S1N31tid 1N bd 9Z:2~ 86. B~ flON
CA 02254258 1998-11-18
multiple customers. If scripts containing multiple
functions are controlled remotely, compared to controlling
individual terminal functions with individual messages.
This is particularly significant for large networks, and
s for delay sensitive services.
Also, it has now been appreciated that the
consequences of incorrect interaction between service
logic at the network side and the terminal side can be
more serious and harder to foresee, than incorrect
zo triggering of a simple terminal function. At worst, a call
which is not terminated when commanded could disrupt
service or cause unwanted call charges to be billed.
Accordingly, reliability is key for many types of service
to be introduced. This can now be managed, and without
is relying on the service designer needing to anticipate and
avoid the above mentioned interference between services.
For example, if the same type of control message could be
used by more than one type of service logic script, this
enables the terminal to establish which script it relates
2o to. Also, if multiple scripts of the same type are run
simultaneously, this may enable independent control of
each of them.
Preferred features
Preferably the script control data message is
25 part of a GR-3o standard message. An advantage of using
this well established standard is that many installed
switches and terminal use it, and it has proven reliable.
Preferably the script control data message uses a
call qualifier field of the GR-30 standard message. An
~o advantage of this is that it is a part of the GR-30
standard which is suitable for expansion with minimum
changes being needed at either the switch or the terminal.
bSiOT'd 9Lb2~S66 O1 Z~6~ TAG ~~9 S1N81dd 1N bd 9Z:2Z 86. 8T SON
CA 02254258 1998-11-18
_ g _
Preferably the terminal supports the ADSI protocol. An
advantage of using such terminals is that ADSI
capabilities such as display and softkeys in particular,
combine well with the remote control mechanism of the
s invention to enable a wider range of services to be
offered.
Preferably the service logic is responsive to
events outside the telephone network. An advantage of this
is that a wider range of services can be offered if the
io service can make use of such events.
Preferably the data message is determined and
sent from a server which is coupled to the network by a
telephone line. This enables services to be offered and
administered by third parties, independent of the
is telephone network_
Preferably the service logic initiates a call to
the customer terminal, and the script control data message
is sent to the terminal during call set-up. An advantage
of this is that it enables services to be created without
ao requiring their intervention even to answer the call. By
sending the message during call setup, the service can
specify how the call is to be answered by the terminal.
Such services may be used for alerting customers for
example.
is Preferably the terminal service logic script
comprises the step of alerting the customer by voice
without requiring customer input. An advantage of this is
that it enables a customer to be alerted without him
having to take the usual step of lifting a receiver or
ao pressing a button to accept a call. This may be useful to
ensure that urgent calls are not missed
bSiTi'd 9Zb~~S66 O1 ~i0~ I~Z ~Z9 S1N31dd 1N dd 9T:Z~ 86~ 8Z SON
CA 02254258 1998-11-18
_ g _
Preferably the alerting by voice comprises spoken
information relating to the call. This enables a customer
to make the decision of whether to take the call based on
more information.
s Preferably the terminal service logic script
comprises the step of taking the terminal off-hook,
without first checking at the terminal that a terminal
identity sent with the data message matches a pre-assigned
terminal identity. An advantage of this is that the
io service can operate with any terminal without the
administrative burden of maintaining a record of the
terminal identity of every terminal.
Preferably the terminal comprises a loudspeaker,
and the terminal service logic script comprises the step
~s of coupling the loudspeaker to a voice path of the call
over the network. An advantage of this is that it enables
useful services which use the loudspeaker and which can be
remotely controlled. This Can include public address type
services, or alerting or paging services.
ao Preferably the service logic comprises the step
of alerting the customer by a voice message over a
loudspeaker of the terminal, of the occurrence of a
predetermined event. An advantage of this is that the
customer need not initiate a call, nor even answer a call,
2s as long as they are within earshot of their terminal. Thus
they need not interrupt their current activity any longer
than is needed to listen to the information in the voice
message.
Preferably the predetermined event comprises an
3o event occurring in a computer system, coupled to the
telephone network.
bSi~~'d 9Zb2~S66 O1 Zi0~ WL ~I9 S1N31dd 1N bd ZZ:~Z 86~ 8Z SON
CA 02254258 1998-11-18
- 10 -
This helps to overcome some of the disadvantages
of computer systems including e.g. email applications,
which make them poor at alerting customers to events.
Typically they can alert a recipient of a message only by
s an indication on the recipient's screen, and by a tone.
Urgent messages may not reach a customer if they are not
on-line, or if the customer does not interrupt their
current activity to check the content of the messages.
Screen messages may be covered by other windows on the
io screen. If many less important messages are being
received, it may be inconvenient to check the content of
all of them. A terminal for a telephone network is
normally available for receiving calls all the time, and a
verbal message can contain more information to help a
is customer to decide whether to respond immediately.
Preferably the remote control of the terminal
script is made dependent on criteria selected by the
customer. This helps to broaden the range of services
which can be created. Selection by the customer can
2o improve security, prevent nuisance calls or can enable a
customer to prioritize calls and allow remote control only
to selected callers.
Other Aspects of the Invention
as Another aspect of the invention provides a method of
paging a customer by using a customer terminal coupled to
a telephone network, the terminal being arranged for
handling voice calls over the telephone network, and
having a loudspeaker, the method comprising the steps of:
~o initiating a call over the telephone network to
the terminal,
bSi~T'd 9Zb2~S66 O1 ZI0~ IZL ~Z9 S1N31dd 1N bd LT:~~ B6~ 8I flON
CA 02254258 1998-11-18
- 11 -
sending a data message to the terminal to cause
the terminal to go off- hook, and to use the loudspeaker
to alert the customer.
Another aspect provides apparatus corresponding
s to the method of the first aspect.
Another aspect provides software stored on a
computer readable medium for carrying out the method of
the first aspect.
According to another aspect of the invention,
io there is provided a customer terminal for use with the
above aspects of the invention, for receiving a data
message and executing the script according to the data
message.
Another aspect provides a method of using the
~s customer terminal of the preceding aspect for receiving a
data message and executing the script according to the
data message.
Another aspect provides software stored on a
computer readable medium for carrying out the method of
ao using a customer terminal of the preceding aspect.
Another aspect provides a method of programming a
computer to operate according to the method of the first
aspect.
Another aspect provides a method of programming a
2s terminal to operate according to the aspect set out above.
Any of the preferred features may be combined
with any of the aspects set out above as would be apparent
to a skilled person.
Other advantages will be apparent to a skilled
3o person, particularly in relation to any further prior art
other than that discussed above.
bSibT'd 9Zb2~S66 O1 ZT0~ TEL ~T9 S1N31dd 1N ad ZT:~~ 86. 8T flON
CA 02254258 1998-11-18
- 12 -
Brief Descrintioa of the Drawings
Embodiments of the invention will now be
described in more detail by way of example, with reference
to the accompanying drawings, in which:
s Fig 1 shows an embodiment of the invention in
schematic form,
Fig 2 shows another embodiment of the invention in
schematic form, showing elements used for services such as
a Call Screening Monitor Intercept (CSMI) service,
io Fig 3 shows in more detail in schematic form some of
the elements of a local switch of the network shown in Fig
2,
Fig 4 shows an arrangement of a terminal shown in Fig
2,
z5 Fig 5 shows a high level flow chart of the CSMI
service of Fig 2,
Fig 6 shows a sequence chart of the embodiment of Fig
2, for the case that the monitored call is taken,
Fig 7 shows another sequence chart of the embodiment
20 of Fig 2, for the case that the monitored call is not
taken,
Fig 8 shows an arrangement of elements for use in
services such as alerting or announcing services,
Fig 9 shows a flow chart of another embodiment, fox a
2s callex announce service,
Fig 10 shows an arrangement of elements in schematic
form, for services using an external input,
Fig 11 shows a flow chart for an email received
announcement service, which may use the arrangement of Fig
ao l0 and
Fig 12 shows a flow chart for another embodiment, for
a calendar entry announcement service, which may use the
arrangement of Fig 10.
bSiST'd 9Gt~2~S66 O1 ZT0~ TAG ~t9 S1N31dd 1N 21d W:~~ 86. 8T flON
CA 02254258 1998-11-18
- 13 -
Detailed DescriDt~.on
Fig 1 shows in schematic form an embodiment of
the invention including a customer terminal 2o coupled to
s a telephone network 14. Other terminals 17 are also
connected to the network. The customer terminal 10
includes functions for executing service scripts 20 at the
terminal, for handling data messages 30 from the network,
and for handling voice calls sent over the network. The
io other terminals may be similar or may have only the voice
handling capabilities.
The network 14 includes call handling and
routing capabilities 50, and service logic functions 60.
The service logic functions may be implemented on a
is processor located externally or internally to the network.
In practice they are likely to be implemented either on a
local switch, or on an external server coupled to the
network. The service logic includes network functions 80
and terminal functions 70. The terminal functions include
2o the functions of determining a data message 90 and sending
a data message. The function of determining a data
message can be carried out by a processor retrieving a
message from memory or by generating the message according
to input parameters.
25 Fig 2 shows an arrangement including a voicemail
system 110. The voicemail system is coupled to the
telephone network, or may be part of the telephone
network. An example of a service making use of the
voicemail system will be described below with reference to
~o Figs 5 to 7. Fig 2 also shows a caller s terminal 120
coupled to the telephone network. Otherwise the terminal
to and the telephone network 14 can be as shown in Fig 1.
bSi91'd 9Lb~~S66 O1 ZTO~ Z~L ~~9 S1N31dd 1N 21d BT:~~ 86. BT flON
CA 02254258 1998-11-18
- 14 -
Local Switch Elements, Fig 3
Fig 3 shows some of the elements of the telephone
network in more detail, in schematic form. In this case
the service logic may be implemented on a central
processor of a local switch 840. The service logic
function 60 includes a number of functions represented by
a service logic execution processor 820, a service logic
store 810, and a store for user preferences and criteria,
830. The latter may also store a record of which services
~.o a user has subscribed to.
In a local switch 840, modem circuitry 850 is
provided for generating and supplying data messages in the
appropriate format as a modem burst to be sent to one or
more of the numerous subscriber lines served by the
~5 switch. In some applications, the data message can be
generated elsewhere and fed to the call path somewhere
other than the local switch. Each customer terminal is
connected by a subscriber line to a line card 860 in the
local switch. Typically, the modem circuitry, in the form
20 of multiple modems on a single card serves hundreds of
line cards. This may make it imperative to implement
services with as few data messages as possible, so that
the local switch modem circuitry is not so overloaded that
messages have to be queued and thus delayed. The service
2s logic execution processor would determine the type of
message, and the content of the fields, and pass it to the
modem circuitry, with an indication of which subscriber
line or lines it is to be sent over. The modem circuitry
would incorporate it into a modem burst and send it on the
ao given subscriber lines. This can be done at specific times
during call set up, or while a call is in progress.
bSiGt'd 9Zb2~S66 O1 W0~ izL ~T9 S1N31dd 1N bd 8Z:2~ 86. BZ flON
CA 02254258 1998-11-18
- 15 -
The, service logic execution processor is also
shown coupled to the line card of the local switch, to
illustrate schematically that the service logic execution
processor needs to be aware of the state of the line,
s receive inputs from the terminal, and be able to control
the state of the line. There would be other circuitry (not
shown), for achieving such functions, which can be
implemented following well-established practice, and so
need not be described in more detail here. Reference is
io made to well known switches such as Nortel Networks DMS
switches.
Termiaal Elements, Big 4
Fig 4 illustrates some of the principal elements
is of the customer terminal 10. It includes a line interface
and electric hook switch 950, a script store 980, a CLID
(Calling Line Identification) processing element 990,
including detection hardware. A keypad 1000, a display
1010, and loudspeaker 1020 are also provided. All these
2o elements, and a handset and loudspeaker interface 970, are
coupled to and controlled by a microprocessor 960. These
hardware elements may be identical to a conventional
terminal, the distinctive features of the terminal may be
entirely contained in the software for the control
2s microprocessor. If the terminal is arranged to support the
ADSI protocol softkeys would be provided and supported by
the processor.
CSMI Example, Figs 5 to 7
so Fig 5 shows a flowchart of a CSMI service for
enabling a customer to monitor calls as they are recorded
by a voicemail system. Conventionally this has been found
bSiBi'd 9Gb2~S66 O1 Zi6~ Z~G ~T9 S1N31dd 1N bd 8Z:2~ 86. BZ SON
CA 02254258 1998-11-18
- 16 -
to be a valuable facility which is always provided or. CPE
answering machines but it has not been possible to provide
it on network-based voicemail systems. The service shown
in Fig 5 can make use of the arrangement of Figs 2,3 and
s 4. At step 150 an incoming call is received and diverted
by the network to the network voicemail system 1i0. At
step 160 it is determined that the called party is a CSMI
subscriber, e.g., by the local switch as a preliminary
step before starting the appropriate service logic. Under
io the control of the CSM= service logic the local switch
sends a specific data message to instruct the customer
terminal to begin monitoring the call. The data message
will be described in more detail below. At 170, the
customer can listen to the caller starting to leave a
zs message without having to pick up the phone or take any
action. The customer can choose whether to take the call
and speak to the caller, or whether to end the monitoring,
or do nothing.
At 180, if the customer chooses to take the call,
2o the network connects the customer to the caller. At 190
the voicemail system is disconnected unless the customer
has chosen to continue recording the call. The call
continues until either party hangs up at 200. If the
customer chooses to stop the monitoring at 210, e.g., by
2s pressing a button on his terminal, the customer's line and
his terminal are no longer coupled to the call, and the
voicemail continues recording at 220, until the caller
hangs up. If the customer takes no action or the terminal
is unattended, the voicemail continues recording and the
ao terminal continues monitoring, until the caller hangs up.
An example of a further service which might be
run simultaneously is the well known SCwID (spontaneous
bSi6~'d 9Gb~~S66 O1 ZI0~ TEL ~~9 S1N31t1d 1N bd BT:2~ 86. BZ flON
CA 02254258 1998-11-18
- 17 -
call waiting with caller Identification) service. If
another caller calls during monitoring, the SCWID service
may start running, and the terminal will be sent a data
message containing the caller ID, and perhaps a caller
s name. The terminal can be arranged to interrupt the CSMI
terminal script and run a SCWID script to extract the
caller ID and caller name information and display it. An
audible alert may also be given over the loudspeaker. Soft
keys may be displayed to enable the user to make a choice
zo of whether to accept the call. The service logic processor
in the network will be arranged to distinguish between
user choices relating to SCWID, and choices relating to
CSMI. The terminal may be arranged to return to the CSMI
script as appropriate, or effectively run the scripts in
i5 parallel. Any data messages from the network to the
terminal can specify which type of service they relate to,
to ensure there is no unwanted feature interference. A
second instance of the CSMI service could be started
before the first one terminates. In this case, the data
2o message might specify which instance of the CSMI service
it relates to. This is another example of the data message
specifying to which script it refers. In this way,
feature interaction can be managed. Alternatively, the
terminal could also be arranged so that selected other
25 services such as the SCWID service, are not run while the
CSMI service is active.
The CSMI service is shown in more detail in the
sequence charts shown in Figs 6 and 7. Fig 6 shows the
example of what happens in such a service for the case
3o where a customer picks up the call. Fig ~ shows what
happens for the case where the customer takes no action.
In both figures is shown a schematic representation of the
bSiOZ'd 9Lb~~S66 O1 LTO~ TEL ~Z9 S1N31dd 1N ad 6Z:Z~ 86~ 8Z flON
CA 02254258 1998-11-18
- I8 -
customer terminal, 10 for customer "B", a telephone
network 14, which may be the PSTN (Public Service
Telephone Network) a terminal 120 of a caller "A", and the
voicemail system,110. The sequence of actions of each of
s these elements is shown, starting at the top of the chart.
The CSMI call scenario of Fig 6
This shows an example of a script control data message,
in the form of a CSMI Activate Call Qualifier as part of a
io GR-30 Call Setup message. It is used to activate/trigger
CSMI Automatic Monitoring at the terminal, which is an
example of a terminal service logic script;
~An incoming call is forwarded to CSMI subscriber's
Voice Mail System (VMS); VMS answers;
is ~DMS sends CSMI ring splash followed by the GR-30
Call Setup message containing the CSMI Activate
indicator call qualifier;
~CSMI Activate indicator call qualifier is detected
by the ADSI set and triggers the appropriate set
ao function (script or firmware) to provide automatic
monitoring (assuming the subscriber has enabled the ADSI
set auto monitoring functionality);
~ADSI set goes off-hook and turns on the
speakerphone; message being left is heard over the
zs speakerphone; picking up the handset turns off the
speakerphone but does not intercept the call;
~ADSI set display is updated with "Intrcpt" and
"Exit" softkeys during monitoring mode;
bS~i~'d 9Zb2~S66 01 Zt6~ iZL ~i9 S1N31dd 1N ad 6T:~~ B6. 8i nON
CA 02254258 1998-11-18
- 19 -
~If the CSMI subscriber depresses the "Intrcpt"
softkey, set sends a switchhook flash, call is
intercepted;
~If 2-Way CSMI interception is used, the VMS is
s disconnected resulting in a 2-way call between CSMI
subscriber and caller; set display is updated
accordingly;
~If 3-way CSMI interception is used, a "DropVMS"
softkey is displayed; conversation between CSMI
io subscriber and caller is recorded on VMS; CSMI
subscriber depressing the "DropvMS~~ softkey prompts set
to send a switchhook flash; VMS is disconnected
resulting in a 2-way call between CSMI subscriber and
caller; set display is updated accordingly.
Fig 7, CSMI Deactivate Example
The CSMI Deactivate Call Qualifier can be used to
terminate the CSMI Automatic Monitoring session without
user intervention;
Call scenario;
~An incoming call is forwarded to CSMI subscriber's
VMS; VMS answers;
~DMS sends CSMI ring splash followed by the GR-30
2s Call Setup message containing the CSMI Activate
indicator call qualifier;
~CSMI Activate indicator call qualifier is detected
by the ADSI set and triggers the appropriate set
function (script or firmware) to provide automatic
bSi~~'d 9db2~S66 O1 ZT0~ WG ~T9 S1N31dd 1N 21d 6T:~~ 86. 8Z flON
CA 02254258 1998-11-18
- 20 -
monitoring (assuming the subscriber has enabled the ADSI
set auto monitoring functionality);
~1.~DSI set goes off-hook and turns on the
speakerphone; Message being left is heard over the
s speakerphone;
~ADSI set display is updated with "Intrcpt" and
"Exit" softkeys during monitoring mode;
~The set is unattended, meaning no end-user
intervention occurs;
io ~Caller hangs up when message deposit is complete;
VMS is disconnected; DMS detects vMS disconnection and
sends a GR-30 Call Setup message containing the CSMI
Deactivate indicator call qualifier to the set;
~CSMI Deactivate indicator call qualifier is detected
is by the ADSI set; ADSI set is returned on-hook, softkey
display is cleared, screen display is updated with idle
screen (date & time).
The GR-30 Call Setup Message
ao The existing GR-30 Call Setup Multiple Data Message Format
(MDMF) message is used to send the new CSMI specific
events.
CSMI specific Call Qualifier parameters within the
existing GR-30 Call Setup message allow proper
2s activation/deactivation of set functions such as automatic
monitoring.
The GR-30 Call Setup message parameter types;
~ Time & Date
bSi~2'd 9Zb2~S66 O1 ZIO~ Z~Z ~I9 SlNSldd 1N 21d 6Z:~~ 86~ 8Z flON
CA 02254258 1998-11-18
- 21 -
~ Calling Line Identification (CLID) - calling number
~ Dialable Directory Number (DDN) - calling number
~Reason for absence of DN
~ Call Qualifier
s ~ Name - calling name
~ Reason for absence of Name
The Call Qualifier Parameter is the GR-30 Message
This parameter provides additional information on a call.
h~fedcba
Bvte 1 Parameter Code
2 Parameter Length
3 ualifier
Call Qualifier Parameter
i5 The Call Qualifier parameter content;
~ Parameter code is 6 (00000110)
~ Parameter Length is coded in binary and is always 1
(00000001)
~ Qualifier is coded in ASCII (no parity) and
2o currently has only two meanings;
L . Long Distance Indicator = !01001100'
R . Ringer Test indicator - ~01010010~ (value not
currently supported)
bS~bW d 9Z~~~S66 01 ~,i0~ WZ ~Z9 S1N31dd 1N bd 02:2Z B6~ 8i nON
CA 02254258 1998-11-18
- 22 -
New Call Qualifier indicators;
~ C . CSMI Activate Indicator - '01000011'
~ D . CSMI Deactivate Indicator - X01000100'
s Note: The new CSMI Call Qualifier indicators are
not yet standardized, so are proprietary.
It is possible for there to be insufficient room in the
GR30 message for the call qualifier, depending on the
total length of other parameters, notably the DDN
io parameter. Accordingly, a check should be made to ensure
the length of the DDN parameter is not such as to prevent
the call qualifier from being sent. If this is the case,
the CLID parameter should be sent instead of the DDN
parameter
is Example of a GR-30 message pith CSMI call qualifier
Field Name Actual Tt'ansl9tion
Data
Message type10000000 Call Setup Message
Message 0010001 35 ytes
length
Parameter 00000001 Time parameter (Sept.18th
type @ 12:35pm)
Parameter 00001000 8
length
Data 40110000 0
00111001 9 - month
00110001 1
00111000 8 - day
00110001 1
00110010 2 - hour
00110011 3
bSiS~'d 9Zb2i=S66 O1 ZZOi= Z~L ~Z9 S1N31tid 1N ad 02:~Z B6. 8Z flON
CA 02254258 1998-11-18
- 23 -
00110101 5 - minute
Parameter 00000010 Ca ling Line Id~cat~on
type (514-765-1234)
Parameter 00001010 10
length
Data 00110101 5
00110001 1
00110100 4 -- -
00110111 7
00110110 6
00110101 5
00110001 1
00110010 2
00110011 3
00110100 4
Parameter 00000110 Call Qualifier
type
Parameter 00000001 1
length
Data 01000011 CSMI Activate Indicat4r
or
01000100 CSMI Deactivate Indicator
Parameter 00000111 Name (John Doe)
type
Parameter 00001000 8
length
Data 01001010 J
01001111 O
01001000 H
01001110 N
00100000 Space
01000100 D
bSi9~'d 9Zb2~S66 O1 W0~ t~L ~Z9 S1N31dd 1N 21d 0~:~~ 86~ 8Z flON
CA 02254258 1998-11-18
- 24 -
01001111 O
01000101 E
Caller Annouace Example, Figs 8,9
s Fig 8 shows an arrangement of elements similar to
Fig 2, but with the addition of an announcement generator
Although service logic 60 is illustrated as being
located at the local switch, it could conceivably be
located at the announcement generator, external to the
zo network. rn practice, some service logic may conveniently
be provided at the announcement generator. A telephone
line connects the announcement generator to the network.
Hence calls can be forwarded to the announcement
generator, and it can be in the call path, and play a part
is in controlling the call.
As will be described in more detail in relation
to Fig 10 below, the announcement generator is capable of
receiving information in electronic form and converting it
into a speech signal which can be fed into a voice path of
2o a call to reach the customer's terminal. As this voice
synthesis is relatively compute intensive, it is most
practical to provide this in a server in or coupled to the
network, rather than at each terminal. It is also
preferable to provide it directly on the call path, so
2s that it does not suffer degradation e.g. by coding and
decoding if it needs to be transmitted some distance to
reach the call path. If such difficulties can be overcome,
in principle voice synthesis could be carried out
anywhere.
ao Fig 9 shows a flow chart for another embodiment
of the invention which uses the announcement generator
bSib2'd 9Gb~~S66 O1 ZTO~ TEL ~T9 S1N31dd 1N bd 0~:~~ 86~ 8Z flON
CA 02254258 1998-11-18
- 25 -
shown in Fig 8. The service provided is a caller announce
service which gives a customer verbal information about a
caller, spontaneously, without the customer needing to
take any action other than listen.
s At 250, an incoming call is received at the local
switch. Again, it is determined that the called party
subscribes to this caller announce service. If so, the
announcement generator is alerted, e.g. by SS7 signalling,
and appropriate service logic is started. The local switch
io at 260 plays ringing to the caller, and connects the
called terminal to the announcement generator. Information
about the caller may be derived from his CLID, for
example, by the service logic at the local switch ox
perhaps at the announcement generator. In either case, at
15 270, the announcement generator generates a synthesised
speech announcement containing or derived from this
information. This speech is fed into the call path at the
announcement generator, to reach the subscriber line
coupled to the customer's terminal. At 280, the local
2o switch (or possibly the announcement generator) sends a
specific data message to tell the customer terminal to go
off-hook, and to connect its loudspeaker to the line. This
can be done using the GR-3o message as described above,
with another specific call qualifier,
25 The customer can then listen to the information
in the verbal announcement and learn more to help decide
whether to take the call or not. Notably, it is not
necessary for the customer to take action such as lifting
a receiver to listen, or be alerted about the call. At
30 300, if the customer chooses to pick up the call, by
lifting the handset or pressing a button, the customer is
connected to the caller. The call continues until either
bS~B~'d 9Zb~~S66 O1 LT0~ TZG ~~9 S1N91dd 1N ~Id 0~:~~ 86. BZ flON
CA 02254258 1998-11-18
- 26 -
party hangs up at 310. At 320, if the customer chooses
not to take the call, the terminal steps monitoring, and
at 330 the caller is offered the possibility of being
forwarded to the customer's voicemail. If this is
s accepted, the call is recorded until the caller hangs up.
If the customer takes no action after a time-out 340,
again the caller is offered voicemail 330.
To prevent the customer being interrupted too often
by this service, it is useful to have a mechanism to
io enable the service to be activated dependent on criteria
selected by the customer. For example, the customer may
wish to define that the service is triggered only on
receipt of calls from specified callers, or at specified
times, for example. This could be achieved by appropriate
is filtering by the service logic execution processor, based
on preferences stored and retrieved by this processor.
Alternatively, the announcement generator could be
arranged to have similar capabilities.
In an alternative embodiment (not illustrated),
2o instead of the announcement being generated from
information about the telephone call, the caller could be
offered the opportunity to make a short announcement which
will be passed to the customer's terminal directly, or
recorded for replaying at the customer's terminal.
as Furthermore, there is an opportunity, at the time of the
announcement, for brief advertising or information
messages to be inserted.
Figs 10 and 11. Email Received Aiuiouncement Example
3o Fig 10 shows in schematic form an arrangement
similar to that of Fig 2, and including the terminal 10, a
telephone network 714, the announcement generator 700, and
bSi6Z'd 9Lb2~S66 O1 L~0~ i~L ~~9 SlNSldd 1N bd T~:2~ 86. 8T flON
CA 02254258 1998-11-18
_ 27 _
a connection to the Internet 710. This enables a service
to be provided which can be influenced by predetermined
events or make use of external information. The service
logic 760, is conveniently located at the announcement
generator in this case, although other locations are
conceivable. An Internet Service Providex (ISP) 720, which
may be anywhere on the Internet, is also shown.
The announcement generator 700 may be part of the
network or may be external to the network. It is an
io example of a server which may be coupled to the network by
a telephone line, and hence be in the call path. Thus it
may generate and send the data message for controlling the
terminal_ It includes an input processor 880 for handling
inputs from external sources, and extracting the content
z5 of messages and other information about the message, e.g.
about the sender. The external sources may include other
networks, such as the Internet, or other telephone lines,
using modem or fax connections. A speech synthesiser 900
takes the data from the input processor and creates the
verbal announcement according to this data. This may use
a digital signal processor or other specialised hardware.
Such devices are well known and need not be described here
in more detail. The voice signal output by the speech
synthesiser is fed to a call processor 890. This call
2s processor can interface with the telephone network e.g. to
initiate a telephone call or feed the voice signal into an
existing call in the network, and thus make announcements
which reach the customer terminal via the local switch.
Again, this part can be implemented using well known
ao techniques, and so need not be described herein more
detail. The call processor, and other elements of the
announcement generator, may be operating under the overall
bS~O~'d 9Gb2~S66 O1 Gt0~ Z~Z ~t9 S1N31dd 1N ad T2:2~ 86~ 8T flON
CA 02254258 1998-11-18
- 28 -
control of the service logic being executed on the local
switch or the announcement generator, or both.
Fig 12 shows a flowchart for one type of service
which can make use of this arrangement. It enables a
s customer to be alerted by telephone When an event occurs
relating to their own, or any particular email account
serviced by the ISP. In the example shown, the customer
is alerted to the receipt of email. The email is received
at the ISP at step 400. The ISP determines that the
1o customer is a subscriber to this email announcement
service, and forwards the email to the announcement
generator at step 420. The input processor of the
announcement generator includes appropriate hardware and
software to be able to receive and read the forwarded
i5 email. At 420, the announcement generator generates a
verbal announcement based on the email and its content.
Typically, this might include details of who sent the
email, any summary information such as a title, and
details of any attachment. If the email is short, the
ao content may be read out, if it is longer, an indication of
its length may be given.
At 420, the call processor of the announcement
generator initiates a call to the customer, under the
control of the service logic execution processor. At 430,
2s the service logic and call processor at the announcement
generator send a data message to the customer terminal to
cause it to go off-hook and connect its loudspeaker to the
line. At step 440, the customer can listen to the verbal
announcement and choose whether to get more information by
ao taking the call. According to the selection made, at 450
he is connected to the call. If the announcement
generator were appropriately configured, it would be
bS~iW d 9Zb2~S66 01 ZiO~ iZL ~i9 S1N31dd 1N bd i~:~Z 86~ 8T nON
CA 02254258 1998-11-18
_ 29 _
possible for the customer to give commands, e.g., by
pressing keys on the terminal. The service logic at the
announcement generator could be arranged to respond
appropriately. This might enable a dialogue (not
illustrated? to allow the announcement generator to tell
the customer more information about the email or its
contents upon request. It would be possible to arrange
the announcement generator to pass commands back to the
ISP to deal with the email, for example, to send a reply
Zo email to the sender.
If the customer chooses not to take the call, at 470,
the terminal stops monitoring, and at 480 the call may be
disconnected. An option to forward it to the customer's
voicemail could be offered. If the customer takes no
is action after a time-out at 490, the call may disconnected,
or forwarded to another number, or to the voicemail
system, or a retry arranged after a given time has
elapsed.
To prevent the customer being interrupted too often
2o by this service, it is useful to have a mechanism to
enable the service to be activated dependent on criteria
selected by the customer. For example, the customer may
wish to define that the service is triggered only on
receipt of emails from specified senders, or emails with a
25 specified priority indication. This could be achieved by
appropriate filtering by the service logic execution
processor, based on preferences stored and retrieved by
this processor. Alternatively, the announcement generator
could be arranged to have similar capabilities.
ao Another way of implementing the call processing of
this announcement service would be to have the ISP
initiate the call to the customer, using the well-known
bSi~~'d 9Zb2~S66 O1 ZZ0~ WG ~Z9 S1N31dd 1N 2!d Z~:~~ 86~ 8Z flON
CA 02254258 1998-11-18
- 30 -
H323 standard for Internet telephony. In this case, the
speech synthesizer could be coupled to the ISP and an Fi323
gateway could be used to couple the call to the Iocal
switch.
Calendar Entry Announcement Example, Fig 12
Fig 12 shows another example of a service
triggered by a predetermined event. It may use the
arrangement shown in Fig 10. In this service, the event
io is an external event, specifically a reminder generated by
a calendar program, The program may be running on the
customer's computer, or any other computer or computer
network. This service enables a customer to be alerted by
telephone of such a reminder. At 550, the calendar event
i5 reminder is issued by the calendar program, which may
belong to the customer or to a related third party. The
calendar program is arranged to send information about the
reminder to the announcement generator at 560. This can
be achieved by an email to the announcement generator as
zo described above in relation to Figs 1o and 11. other
mechanisms can be conceived for coupling this information
from the network to which the computer is attached, to the
telephone network.
At 570, the announcement generator generates a
Zs verbal announcement based on the event information, and
initiates the call to the customer. At 580, the
announcement generator sends a data message to the
customer terminal to cause it go off-hook and to connect
the loudspeaker to the line. This may use the GR30
~o message as described above. At 590, the customer listens
to the verbal announcement of the calendar event and
decides whether to get more information by taking the
t~S~~~'d 9Gb2~S66 O1 LZ0~ TEL ~~9 S1N31dd 1N 21d 22:~~ 86. BZ flON
CA 02254258 1998-11-18
- 31 -
call. According to the selection made, the customer may
be connected to the call at 600. As described above in
relation to Fig 11, this could give the customer the
opportunity to interact with the announcement generator,
s to obtain more information about the calendar event, or to
issue some commands on how to deal with the event. This
call may continue until either party hangs up at 610.
The customer may choose not to take the call, in
which case the terminal will stop monitoring at 620, and
io the call may be disconnected 630. If the customer makes
no choice, after a time-out 640, the call may be
disconnected, or forwarded to another of the customer's
numbers (not shown), or if appropriate to the voicemail
system, or it may be arranged to call the customer again
is with the same announcement after a predetermined period.
Other Examples, Variations
Determining the script control data message can
encompass creating the message, according to stored
zo instructions or simply retrieving the message from
storage, or receiving the message in one format and
reformatting it to send on to the terminal, or a
combination of these methods.
The terminal may be a single unit or its
2s functions may be spread across a number of connected
units. These may be dedicated adjuncts, or one or more
general purpose computers such as desk-top or lap-top
computers.
Similarly, the service logic at the network side
3o can be distributed over a number of processors in
different locations to suit the application.
bSib~'d 9Lb2~S66 O1 LT0~ TAG ~T9 S1N31tid 1N bd ~:~Z 86~ 8'i flON
CA 02254258 1998-11-18
- 32 -
Customer selection of criteria may enable the
customer to limit loudspeaker alerting to only selected
callers, or have verbal reminders of entries in the
customer's calendar, or when a variable such as a stock
s price reaches a given value, for example.
Although the examples described above have not
referred to wireless networks, the same advantages can be
achieved for wireless networks. A skilled person would be
able to take known wireless networks and make
io modifications corresponding to those described above to
implement embodiments of the invention and achieve these
advantages. For announcement type services, portable
phones are particularly appropriate. It is easier for a
customer to carry only one device, and ensure that
is attempts to contact him whether by tax, email or phone can
all be directed to his phone.
Although the examples described above have not
referred to Internet Protocol (IP) telephone calls, or
calls over ISDN lines, again the same principles can be
Zo applied and modifications corresponding to those described
above can be made.
Although the examples described use a ring splash
to alert customer terminals which have no other indicator
mechanism other than ringing, other distinctive ringing
2s sequences could be used, or there may be no ringing at
all.
References to control of a script are intended to
encompass starting the script, terminating it, or
influencing the course of it, e.g. by causing the script
3o to take one branch where a choice is possible, or by
interrupting the script. Such an interrupt may enable
bS~S~'d 9Gb~~S66 O1 Z10~ ~~L ~~9 S1N31dd 1N bd Z~:2~ 86~ 8Z SON
CA 02254258 1998-11-18
- 33 -
another action to be performed before returning to the
script at the same place or jumping to a new place.
Other useful applications for loudspeaker type
paging services include emergency alerts, e.g. for
s evacuation orders relating to a building or to a
neighbourhood.
Many other types of services relating to calls,
such as conferencing and call forwarding can be combined
with the features of the present invention.
io Other variations of the described embodiments,
and other applications of the invention can be conceived
and are intended to be within the scope of the claims.
pSi9~'d 9Gb~~S66 O1 ZT0~ T~1, ~T9 S1N31dd 1N bd ~~:~~ 86. 8Z flON
