Telephonic communications – Reception of calling information at substation in wireline...
Reexamination Certificate
1999-09-23
2004-06-01
Hong, Harry S. (Department: 2642)
Telephonic communications
Reception of calling information at substation in wireline...
C379S217010, C379S373040, C379S373050
Reexamination Certificate
active
06744867
ABSTRACT:
CROSS-REFERENCE TO RELATED APPLICATIONS
This application claims priority from Canadian Patent Application No. 2254258, filed Nov. 18, 1998.
FIELD OF THE INVENTION
The invention relates to methods and systems for operating telephone network service logic, and more particularly to conveying information regarding external events, such as incoming calls, to a telephone subscriber without intervention by the subscriber.
BACKGROUND OF THE INVENTION
Known Customer Premises Equipment (CPE) or customer terminals for using telephone networks may be capable of a 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,
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) 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 provider's server, which can then download menus of choices and data for 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, such services, such scripting languages, and the GR-30 message format for sending scripts to terminals, are widely available and need not be repeated here. The GR-30 message format is published in a Bellcore specification.
It is also known to remotely trigger individual terminal functions, e.g. from a local switch in the telephone network, by sending a control message to the terminal which the terminal interprets to perform a particular function. One example of this is the MWI (Message Waiting Indicator) message transmitted in 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 control message may be sent to 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 as the control message, and is interpreted in the terminal. This is published in Bellcore specification TR-NWT-000031.
The term “remote control” is intended to encompass not 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 purposes.
Another example of remote control of a terminal function is the GR30 CPEID (Customer Premises Equipment 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 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 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 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 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 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 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 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 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 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 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.
Some limitations in these known methods have now been appreciated:
1) The reliability of correct detection of such line states or signaling events is limited by terminal hardware limitations and by line quality 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 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 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 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 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 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.
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 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.
SUMMARY OF THE INVENTION
According to a first aspect of the invention there is provided a method of operating telephone network service logic rela
Buckler Brian
Chin Bernard
Cianci Sandro
Al-Aubaidi Rasha
Gibbons Del Deo Dolan Griffinger & Vecchione
Hong Harry S.
Nortel Networks Limited
LandOfFree
Remote control of CPE-based service logic does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Remote control of CPE-based service logic, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Remote control of CPE-based service logic will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3318832