Method of Defining Operation of Switching System Peripherals

This invention relates to the field of telephone systems and in particular to a method of defining the operation of telephone sets and other peripherals associated with a telephone system.

Telephone companies have in recent years been increasing the range of features offered to subscribers, and in order to easily make use of those features, telephone sets having displays and feature accessing pushbuttons have come into common use. Examples of such telephone sets are SUPERSET 4.TM. and other versions of that family of telephone sets. Each telephone set version has a different arrangement and number of pushbuttons from another in order to enable easy operation of particular features. The displays are used for composing and receiving messages, and for displaying the function of "soft keys", whose designation changes depending on the feature or step in a sequence invoked by a user, or as commanded by software programs. Other displays indicate the status of telephone line pushbuttons, such as ringing, busy, idle, hold, etc.

The SUPERSET.TM. series of telephone sets has been designed as "dumb" sets, that is, they merely react to commands sent to them for operation from the switching system to which they are connected. The switching system contains programs which, when enabled, cause the displays to operate, cause the switching system to send signals in response to the detection of the depression of pushbuttons, etc. The status of each display indicator and each character in the display is formulated at the switching system and is transmitted as a signal to each telephone set. Other telephone sets may be "intelligent" in that at least some software programs are stored within the telephone set and are invoked upon receiving commands from the switching system for operating the display, sending signals, etc.

Whether the telephone sets are dumb or intelligent, whether the telephone set operation programs are stored within the telephone set, within the peripheral control system associated with the switching system, or whether they are stored in a memory associated with a central processor for controlling the switching system, the operation programs for driving particular forms of telephone sets are specific to each type of telephone set. The result is that if a subscriber desires to upgrade or downgrade his telephone set (i.e. to be able to access a greater number or fewer number of features), there must be change to the operating or driving software specific to that telephone line. In addition, in case other versions of telephone sets become available which have variations of features, different combinations of features or different features from those previously contemplated, a significant change in the operating software is required. Thus when changes to accommodate changed or new forms of telephone sets are required to be effected, significant cost is incurred.

It should be noted that in this specification the term "switching system" is intended to mean any form of communication system which utilizes peripherals, whether using time division or space division switching, communication via a network such as a local area network, etc. Peripherals is intended to mean telephone sets, trunks, special service circuits, etc.

In accordance with the present invention, a remote host system such as a computer system is used to model a prototype of a peripheral whose characteristics are to be defined. The model is effected by displaying on a display screen (referred to herein as a display), a graphic which simulates the peripheral itself. A telephone set will be used as an example herein, but it will be recognized that other peripherals such as trunks can be easily modelled.

The model which is graphically displayed is that of a prototype of the peripheral, not only in form on the screen, but also in operation. Therefore, for example, if the graphic displays a button which is designated to cause a certain feature to operate, pointing and clicking by use of a computer control mouse, for example, will cause the prototype to operate as if it were real.

Once the prototype of the peripheral has been modelled, a control table of data relating to operation of the specific form of prototype is created and locally stored. That data is then downloaded to the switching system to which the peripheral is connected. The software programs for operating a single or group of peripherals are stored in the switching system, and access the table of data corresponding to the modelled prototype in order to cause operation of a real peripheral in accordance with the modelled prototype.

As a result, the telephone company owning the switching system need only operate the prototype modelling system when peripherals are to be updated or changed, or when new peripherals having new features are added to the system. That company is thus freed from having to purchase the services and the software of the switching system manufacturing company to change the switching system programs in such instances. The result is increased flexibility, the ability to easily withdraw or add features to existing telephone sets, to change the designations of telephone pushbuttons, and to facilitate the addition of new types of telephone sets in a cost effective and simple manner. This affords great advantage to the telephone system owner.

In accordance with an embodiment of the invention, a method of defining the operation of switching system peripherals is comprised of storing a software program for operating the peripherals in a switching system, storing at least one table of data for access by the program for defining operating parameters of a corresponding at least one peripheral, modelling a prototype of the peripheral in a remote host system by creating a human-machine-interface simulating the peripheral, storing a control table of data corresponding to the modelled prototype in a memory of the host system, and downloading the control table into the aforenoted at least one table, whereby operation of the peripheral is controlled by the operating software programs and the data in the aforenoted at least one table.

Preferably, the modelling step includes displaying a graphic human-machine-interface (HMI) on a display which simulates the face and forms of pushbuttons, keys, and displays (if any) of the telephone sets, enabling operation of the pushbuttons and keys on the graphic human-machine-interface and operating a telephone set simulation program to verify correct and desired operation of the control table of data.

The modelling step thus encapsulates the human-machine-interface definition of the telephone set as data, as opposed to tying the human machine interface directly to the controlling software. That data can be changed by subsequent modelling steps. The definition of which soft keys and text strings to be selected and displayed on the telephone, reflects the choices made. The data encapsulation removes the requirement of providing a human-machine-interface definition of the particular set connected to a particular line from the telephone set controlling programs, allowing such programs to be generic for various types of peripherals, and thus less expensive when changes or additions are to be adopted.

A better understanding of the invention will be obtained by reference to the detailed description below, in conjunction with the following drawings, in which:

FIG. 1 is a block diagram illustrating a system arrangement for carrying out the method of the invention;

FIG. 2 is a graphic of the face of a telephone set created using an HMI;

FIG. 3 is a graphic of a display editor window;

FIG. 4 illustrates windows of state information for display blocks to be presented in a telephone set to be presented;

FIG. 5 illustrates a graphic of a window showing key designations of a simulated telephone set;

FIG. 6 illustrates a graphic of a window of line key indicators of a simulated telephone set;

FIG. 7 illustrates a graphic of a window used for call progress tone customization;

FIG. 8 illustrates states for several languages; and

FIG. 9 illustrates windows for implementation of a simulated trunk.

Turning to FIG. 1, a remote host system 1 is illustrated, which typically is comprised of a processor 2, display 3, etc. The processor accesses a memory 4 which can be subdivided into sub-memories as described below. The switching system 5 is comprised of a central processor 6 which operates a switch 7, and accesses memory 8. The operation programs for the processor 6 are stored in memory 8.

Peripheral control systems 9 are connected to switch 7, and either through switch 7 or via other links not shown to processor 6 for communicating with and control thereby. The peripheral systems can access peripheral memories 10, e.g. for storage of control programs for peripherals 11a (e.g. telephone sets), and 11b (e.g. trunks).

According to the prior art, the peripherals operate under control of programs stored in memories 10. Features are invoked by pushing pushbuttons on the telephone sets, causing signals to be transmitted to the peripheral systems which access software stored in a memory 10; or by means of signals arriving at a peripheral system 9 through switch 7 from another peripheral system, similarly causing software programs in a memory 10 to operate, thereby transmitting control and display signals to a local telephone set; or by the peripheral system receiving control signals from processor 6, resulting in peripheral control software programs being retrieved from a memory 10, whereby a local telephone set is controlled and/or characters are displayed on the set display.

For the present invention to operate, programs in memory 10 controlling operation of peripheral telephone sets are generic for all sets of a particular class, and those programs and steps which are to be used to define the operation of particular telephone sets are defined in a data table 12 stored in memory 10. Therefore the combination of the software programs and the data table defines the characteristics of each telephone set and each other peripheral such as the particular form of trunk to be used and signals to be recognized or transmitted thereby.

The remote host system 1 implements a human machine interface (HMI) to both model (define) and test prototypes of each of the peripherals. Models of the peripheral telephone sets were successfully implemented on a Sun Microsystems workstation, which formed the remote host system. An HMI generating program referred to as DEVGUIDE, by Sun Microsystems, provides an HMI editor. Operation of DEVGUIDE will be understood by persons skilled in the art and is described in the Open Windows Developer's Guide, dated Feb. 5, 1990 and available from Sun Microsystems. That guide and other publications referred to therein are incorporated herein by reference.

The human-machine-interface simulation programs are stored in memory 13, for access by processor 2, and are created using the DEVGUIDE program referred to above, from Sun Microsystems. While this facilitates creation of the HMI graphic, it does not create the telephone set simulation programs. Rather than simulation programs, the real programs from the switching system are preferred to be used in the host system, whereby the real programs can be exercised in the simulation system with the data table to be downloaded into the real system.

Provision of the HMI by use of the DEVGUIDE provides compiled software programs for generation of an e.g. telephone set graphic, and results in enable signals when, for example, graphic telephone set buttons are pushed by clicking a mouse pointer on the buttons, by displaying alphanumeric characters in a graphic of a telephone set display, etc. The user of DEVGUIDE is instructed to create his own programs for operation of the system.

In accordance with the present invention, the programmer creates a simulated prototype of the real peripheral which reacts in accordance with the result intended from pushing a button, etc. on the HMI interface which is modelled on the display 3 of the host system. The simulated peripheral, created in computer software, is then tested as a prototype. The simulation programs are created so as to provide a control table of data, in which the data corresponding to the modelled prototype corresponds to the data to be stored in data table 12 of the actual physical switching system. Once the modelled prototype has been successfully tested, a link 20 between the remote host system processor 2 and the switching system processor 5 is established and the control table which has been stored in data storage 14 is downloaded from processor 2 to processor 5. Processor 5 transmits the control table of data to peripheral system 9 which stores it in data table 12 of memory 10. This establishes the parameters for operation of a particular single peripheral, class of peripherals or all peripherals connected do the peripheral system 9.

The process of updating data table 12 can be done in real time so long as it does not occur while a previous data table for a particular peripheral in use is not being processed.

FIG. 2 illustrates a graphic of a telephone set peripheral created using DEVGUIDE on the remote host system and displayed on display 3, in accordance with a successful laboratory prototype, which will be used as the example described below. The graphic can illustrate in a default configuration, the maximum number of feature enabling buttons and displays to be offered on a most featured telephone set being displayed, for example. While a default configuration need not be used, if desired, it is preferred to be used since the user need only change the portions of the HMI of immediate interest or remove buttons, displays, etc. as desired.

In the telephone set prototype modelled and shown in FIG. 2, the following attributes are provided: eight hard keys with two light emitting diodes, volume up and down keys, a speaker on and off key, a microphone, twelve line appearances with associated liquid crystal display indicators, three soft keys and a 2-.times.-16 character display.

It should be noted that HMI customizations relating to a particular device will usually only be applied against the corresponding real devices. Thus HMI changes made relating to one type of telephone set may not apply to another type of telephone set.

The text information appearing on the telephone set display can be modified to show anything the designer wishes, limited only by the display size and character set supported by the peripheral equipment. Different information can be displayed for each different device state, and different information elements can be displayed such as time and date, total call time, user's name, user's extension number, etc. The contents of these information elements are changed dynamically by the telephone system depending on what has been established using the host system and stored in table 12.

In order to edit the display on the telephone set model, a display editor window such as that shown in FIG. 3 may be used. The top line is a general information line and may be customized by selecting from a list of information elements, or by entering text. Some information elements use only part of the display line, using the remainder of the line for text, which can then be customized, as shown in FIG. 3. The selection buttons in the top line (designated by dots) may be invoked. When an information element is selected, the top line of the local display will change accordingly, indicating which characters are reserved.

The bottom line of the display is a text line, which usually provides some indication of the meaning of soft keys (the keys just below the display) and is typed in by the designer. The text line is customized simply by typing into the bottom line and applying the change as each calling state (and associated display) is traversed. The customization takes effect when the Apply button is selected.

In the successful embodiment, the language of the display may be selected, three specific languages being provided for. This selects a text dictionary, which retrieves all presentation text in the system from a multi-language dictionary 15 in memory 4. The multi-language dictionary is comprised of various subdirectories, each specific to a language, and accessed by the host processor 2. Text dictionary files are language-dependent string files used by the application. The text dictionary retrieves any single line within a specified file in a given language. It is preferred that each language directory should contain the same number of files with the same names so that changing languages can be easily done with a change in the text dictionary file path.

Thus, for example, by designing the system in English and then changing to French, the corresponding strings in another dictionary can be invoked, changing all of the display alphanumerics into the other language. Similarly, by selecting a particular language, the alphanumerics displayed in the prototype model graphic changes to that language, by accessing the corresponding strings in the other language selected.

The HMI editor is preferred to utilize call processing state information to determine what display blocks should be presented. The state information is shown in the windows reproduced in FIG. 4. Preferably there is a 1:1 correlation between each unique display block and each device state. The HMI editor therefore requires a unique index to reference the display block for the reference telephone set. If the display information is modified, the HMI editor therefore may use the index to identify the text to be modified.

The soft key function definitions and associated text descriptions are preferably customized for all devices that provide soft keys. The soft key functions and text displays should be configured for each unique device state. The designer selects those functions which could potentially be valid for the user of a given device and are selected as available options. Once the designer has configured the functions of the soft keys, the text above the soft keys is modified to provide a description of the soft key meanings. Each piece of text should be tied to a specific soft key, although it may extend over another soft key on the display.

The soft keys are preferred to be customized for the most general case, i.e. the situation where all possible features are valid. For example, if call waiting is a valid feature, the feature to pick up a waiting call should be offered as a valid soft key in the talk state. If there is no waiting call during system operation, the soft key should be undefined and its text description blank.

The left, center and right soft keys L, C and R shown in FIG. 3 provide a menu indicating the selections which may be assigned to them. For example, call forward, extension and NIL may be the valid options in the idle device state. Any of these options may be assigned to any soft key. In order to customize a soft key a selection should be made from the menu. The selections which are available relate directly to the calling state of the simulated set, i.e. to customize the soft keys for the call forwarding state, the set must first be put into the call forwarding state. The action which is assigned to a soft key then corresponds to a state transition.

The line keys are programmed for line appearances, busy lamp fields, feature access, or speed calls. Only feature access keys are preferably assignable from the HMI editor. This is because, for example, speed call numbers are programmed by the end user. A list of valid features should be provided, and the designer decides which features should appear on which keys. The LCD displays adjacent to the keys should be used to indicate the status of the feature represented by the key.

The line key and hard key designations, together referred to as function keys, are preferably both accessed from the same window, as shown in FIG. 5. The top set of keys correspond to the line keys, while the bottom set of keys correspond to the hard keys.

The designer selects a key, and then associates a feature with the line key or hard key. The function menu box at the bottom of that window as shown, causes a function menu to be displayed which contains all features available for association, also shown in FIG. 5. When the user selects an item from this menu, it should be immediately associated with the key selected (shown with a thick black line and the designation "focus").

Line keys are distinguished from hard keys by their LCD indicators. The window shown in FIG. 6 provides basic customization access to the line key indicators. The user selects a feature, thus bringing a particular line key into focus. The user then selects one of the settings displayed in FIG. 6. The behaviour described by a selection then is immediately applied to the designed line key indicator on a simulated telephone set. For example, selecting Slow Flash should cause the indicator to start a slow flash cycle.

The line key functions are stored with the key identifier in the table. When the line keys are customized, the table entries for the modified keys should be updated with the new function. The table entries for the modified keys are then updated with the new functions. If the customization is on an individual telephone set basis, a different table should be created for each telephone set.

The hard keys are the function keys on a device that do not have associated LCDs. These are keys that are used specifically for feature activation, and not for line appearances or busy lamp fields. In the prior art, the subscriber using the telephone set, and the telephone company (or PABX owner) had no ability to change the definition of any hard keys. With the present invention, the hard keys can be redefined to access any of the available features of interest to the subscriber. To support this redefinition, it is preferred that hard keys on the real telephone sets should have associated printed cardboard inserts carrying the associated definitions, rather than the definitions being printed directly on the telephone set housing.

Hard keys are accessed and customized as described with respect to the line keys.

Hard keys normally will have the same function regardless of state, and the key function is stored with the key identifier in the table. When the hard keys are customized, the table entries for the modified keys are simply updated with the new function.

Call progress tones, such as busy tone, ring-back tone, etc. can be selected from a list by the designer, although it is preferred that call progress tones should not be modified in order to maintain standardization across the nation. However, different types of ringing for different states should be able to be customized using the present invention. In the case of tone and ringing configuration alteration, a window such as that shown in FIG. 7 could be used to customize the prototype model. The call progress tones to be applied to certain states can be contained in a database associated with a state index in the table used to reference the display and soft key information.

FIG. 8 illustrates default states for the languages supported. Each entry is identified by an index, which is associated with a certain point or points in a telephone call. For example, index 1 is associated with the idle state. While in the idle state the operation software references index 1 and extracts the appropriate text from the database and displays it on the host display 3.

For each index there is preferably an equivalent to display in every language that is supported. This structure is preferred because there will be no difference in functionality for different languages, but only differences in the user interface. Therefore for any state in the call there should be some appropriate display in every language.

The altered displays table shown in FIG. 8 contains all of the displays that have been altered using the HMI editor. The pointer connects the default and altered displays. Altered displays apply in one language only. For example, to change the English "thank you" and the Spanish equivalent "gracias", two changes were required to be made.

The altered displays can apply to an individual peripheral, a group of peripherals, or system-wide. The parameter "All" in the altered displays table implies that changes are system-wide. Otherwise if the display applies to a particular group, that group number (or name) is indicated in the table. In the present example, the quality department's idle display has changed to a motto, "Quality is job 1". Similarly, the accounting department's idle display has been changed to "Balance your ledger".

The thick arrow from "altered displays" to the "groups" table show how the two tables are related. The groups table contains the number, name, members and the type of group.

The "display" group is one that contains a set of end users who are grouped together because of their need for similar functionality and HMI of the actual peripheral. Other groups available in the system may be provided, such as "pickup" groups, in which users are grouped by location of their desks, whereby they can utilize a call pickup feature. The different types of groups may or may not contain different members. In the example shown, group No. 2 contains users who have the same HMI and are also in the same pickup and hunt group. To accommodate customizations on an individual basis a group of type "display" is created that contains one member.

Stimulus to the modelled prototype is obtained graphically by clicking on the buttons using the mouse pointer, e.g. see FIG. 2. Indicators on the device such as displays, lamps and audio tones, preferably should be utilized to provide graphical feedback in much the same manner as a physical device. Multiple instances of the device should be created and displayed for multiple devices, so that features requiring multiple devices (e.g. conferencing) can be simulated.

FIG. 9 illustrates windows for implementation of a simulated network interface peripheral, in this case an LS/CLASS trunk.

Messages between application software and the simulated network interface are displayed in human readable form in the message buffer shown in the columns "incoming messages" and "outgoing messages". A mode control determines the way in which the simulated device operates. In the manual mode, the user can send arbitrary messages to the application software. In the scripted mode, the user can create a model of the network interface as well as the network itself using a scripting language. In this mode the simulated device acts as a state machine which automatically responds to messages from the application software, according to the scripts provided by the user. Scripts can be created and stored using a script editor.

Using the prototype model, the designer can exercise the application software and view the changes made with the HMI editor. HMI changes can be quickly tested, without affecting subscribers connected to the switching system 5. Record/playback software tools can be used to record sequences of user actions, and call scenarios can be replayed for testing and demonstration purposes.

In the prototyping environment, the operation system of the switching system is simulated, providing the same functions to the application software as the switching system, but in reality executes under the remote host operating system. The application software is the same as that running normally in the switching system 5, but recompiled for the remote host system.

Simulated application layer interface software system should present the same interface to the application software as that which runs on the switching system, but should differ in that it should communicate with simulated devices, rather than real peripherals.

Terminal equipment devices such as telephone sets should be simulated using the graphical representations of the physical device, as described above. This can be typically provided using protocol conversion from the application software of the telephone system to the user interface software which interacts with the user. Thus the messages between the application software and the simulated device are required to undergo protocol conversion between the application specific to the protocol and the internal representation used by the simulated device. Messages from the application software are thus converted into events which are presented graphically to the user by the user interface component. Similarly user initiated events such as key presses are received, converted to messages, and sent to the application software. Each distinct type of terminal equipment requires a different simulation model.

Network interfaces such as trunks, should also be separately simulated. The designer should be able to view the message stream between the application software and simulated network interface. In the manual mode, noted above, arbitrary messages can be sent to the simulated interface to the application software. Using the scripted mode, the designer can define the behaviour of the network itself, and the simulated network should respond to messages from the application software according to the user-defined script.

Messages from the application software undergo protocol conversion between the application dependent protocol and the internal representation used by the simulated network interface, as described above. A message monitor should cause display of the messages between the application and the simulated device in a human readable format. The messages should be stored in a buffer that can be reviewed by the user or optionally saved to a log file.

A mode control can be used to determine the simulation mode. In manual mode, the user can send the aforenoted arbitrary messages to the application software. A message editor can be used to allow the user to select from the available messages.

In the scripted mode, messages between the application software and the simulated interface should be controlled by a script language interpreter. The interpreter is a state machine that uses a user-defined script to define the desired behaviour. This allows simulation of the network itself. By creating appropriate scripts, the application software can be exercised and placed in appropriate states so that the user can observe changes made using the HMI editor. Scripts can be created by the designer using a script editor, and stored in one or more script files.

Preferably, the data tables of the switching system 5 should be able to be uploaded to the host system in order to ensure that the host tables can be matched to those of the target system. The host systems data tables can be downloaded to a specific switching system to overwrite the data tables 12 stored therein. The designer should be given the option of connecting directly or remotely to the switching system. For example when connected directly, the host system can use a RS-232 link 20 via a data set connected to the switching system 5.

When connected remotely, the host system can be connected to the target system via a link 20 which is a telephone line using a modem on the host system, and by dialing the switching system.

It should be noted that since the features of particular telephone sets are defined uniquely or by group, automatic documentation can be used to provide user manuals. Therefore the host system can be configured to cause prestored documents relating to designated features, displays, soft keys, line key indicators and call progress tones specified for particular sets to be printed and distributed to the subscribers.

It should be noted that the data tables 12 can be implemented as real tables with sub-tables, or in other forms such as databases. The data tables may be stored in or associated with memories 10, in or associated with the peripherals themselves, or in associated region 16 of memory 8, or in a separate memory 16, in the switching system 5.

It is preferred that the HMI compiled programs, editor and simulator computer software should be provided to the telephone company, to operate on the remote host system of the telephone company. The customization for that system, or other systems, can then be effected by using the HMI editor and simulation programs.

A person understanding this invention may now conceive of alternative structures and embodiments or variations of the above. All of those which fall within the scope of the claims appended hereto are considered to be part of the present invention.