CA2254258A1 - Remote control of cpe-based service logic - Google Patents

Abstract

Telephone network service logic relating to calls over the telephone network to a customer terminal, uses both terminal functions and network functions. The terminal has a service logic script for execution at the terminal to control the terminal functions. To control the execution of this script remotely from the network, a script controlled data message is determined and sent over the telephone network to the terminal. This may use the GR30 data message format, with an additional call qualifier specific to the terminal service logic script, and the type of control being requested, e.g., start execution or terminate the script. This enables the reliability of the interaction between the service logic at the network side, and the service logic script at the terminal to be improved. This enables announcement type services to be provided in which a loudspeaker on the terminal can be remotely controlled to make verbal announcements without requiring customer action to lift a receiver.

Description

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

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

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

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

- 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

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

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

_ 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

_ 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

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

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

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

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

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

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

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

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

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

~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

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

~ 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

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 00111000 8 - day 00110010 2 - hour bSiS~'d 9Zb2i=S66 O1 ZZOi= Z~L ~Z9 S1N31tid 1N ad 02:~Z B6. 8Z flON

00110101 5 - minute Parameter 00000010 Ca ling Line Id~cat~on type (514-765-1234) Parameter 00001010 10 length Data 00110101 5 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

00100000 Space bSi9~'d 9Zb2~S66 O1 W0~ t~L ~Z9 S1N31dd 1N 21d 0~:~~ 86~ 8Z flON

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

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

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

_ 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

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

_ 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

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

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

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

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

Claims (22)

What is claimed is.

1. 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 recognise data messages, and having terminal 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 for controlling remotely the execution of one of the terminal service logic scripts at the terminal, the message; and controlling remotely the execution by sending the script control data message over the telephone network to the terminal.

2. The method of claim 1 wherein the script control data message is part of a GR-30 standard message.

3. The method of claim 2 wherein the script control data message uses a call qualifier field of the GR-30 standard message.

4. The method of claim 1 wherein the terminal supports the ADSI protocol.

5. The method of claim 1 wherein the service logic is responsive to events outside the telephone network.

6. The method of claim 1 wherein the data message is determined and sent from a server which is coupled to the network by a telephone line.

7. The method of claim 1 wherein 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.

8. The method of claim 1 wherein the terminal service logic script comprises the step of alerting the customer by voice without requiring customer input.

9. The method of claim 8 wherein the alerting by voice comprises spoken information relating to the call.

10. The method of claim 1 wherein 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.

11. The method of claim 1 wherein the terminal comprises a loudspeaker, and the terminal service logic script comprises the step of coupling the loudspeaker to a voice path of the call over the network.

12. The method of claim 1 wherein 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.

13. The method of claim 12 wherein the predetermined event comprises an event occurring in a computer system, coupled to the telephone network.

14. The method of claim 1 wherein the remote control of the terminal script is made dependent on criteria selected by the customer.

15. 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:
initiating a call over the telephone network to the terminal, sending a data message to the terminal to cause the terminal to go off- hook, and to use the loudspeaker to alert the customer.

16. Apparatus for operating telephone network service logic relating to a call over the 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 service logic scripts for execution at the terminal to control the terminal functions, the apparatus comprising:
circuitry for determining a script control data message for controlling remotely the execution of the terminal service logic script at the terminal, the message specifying to which of the scripts it relates; and circuitry for controlling remotely the execution by sending the script control data message over the telephone network to the terminal.

17. Software stored on a computer readable medium for carrying out the method of claim 1.

18. A customer terminal for use with telephone network service logic relating to a call over a telephone network, the service logic involving both terminal and network functions, the terminal comprising:
circuitry for recognising data messages, storage for terminal service logic scripts for execution at the terminal to control the terminal functions, circuitry for receiving a data message sent over the telephone network, the message specifying to which of the scripts it relates and circuitry for determining to which of the scripts the received data message relates, and circuitry for executing the terminal service logic script to which the data message relates, in accordance with the data message.

19. A method of using the customer terminal of claim 18 for receiving a data message, determining to which of the scripts the received data message relates, and executing the terminal service logic script to which the data message relates, in accordance with the data message.
and executing the script according to the data message.

20. Software stored on a computer readable medium for carrying out the method of claim 19.

21. A method of programming a computer to carry out the method of claim 1.

22. A method of programming a terminal to carry out the method of claim 19.