WO2000025529A1

WO2000025529A1 - Control input apparatus

Info

Publication number: WO2000025529A1
Application number: PCT/GB1999/003460
Authority: WO
Inventors: Colin Andrew Savage; Stephen Drewe; Victor Charles Page
Original assignee: British Telecommunications Public Limited Company
Priority date: 1998-10-23
Filing date: 1999-10-20
Publication date: 2000-05-04

Abstract

A control input apparatus comprises reconfigurable user interface means for receiving user inputs, processing means configured to process input information to produce native control or configuration data for a subject apparatus, and communication means for communicating native control or configuration data, generated by the processing means, to the subject apparatus. The user interface means may be embodied by a computer running under a GUI operating system.

Description

Control Input Apparatus

Description

The present invention relates to a control input apparatus.

There are many systems that require control and/or configuration information to be input by human operators. Such systems include telephone switches, and plant and vehicle control systems amongst others. A problem arises because the control or ^■■ configuration commands that must be entered into the system are often cryptic which means that highly trained staff are required and that mistakes can be easily made.

According to the present invention, there is provided a control input apparatus for controlling and/or configuring a subject apparatus comprising: storage means storing: user interface definition data sets for respective control and/or configuration tasks in respect of a subject apparatus, and native control and/or configuration data sets for said control and/or configuration tasks, each native control and/or configuration data set having an identification of a data element location therein; user interface means for selectively retrieving a user interface definition data set from the storage means and providing a user interface defined by the retrieved user interface definition data; processing means configured to fill said identified data element location of a native control and/or configuration data set, which data set corresponds to a retrieved user interface definition data set, with native control and/or configuration data in dependence on information input by a user using a user interface defined by a user interface definition data set, retrieved by the user interface means, to produce a complete native control and/or configuration data set; and communication means for communicating such complete native control and/or configuration data sets, produced by the processing means, to the subject apparatus.

The native control and/or configuration data sets may have their identifications of data element locations within themselves or in an associated file, database record or data structure.

Consequently, the user does not need to be familiar with the native control and/or configuration commands of the subject apparatus. Also, skilled staff can be more • effectively used in the preparation of the data sets rather than repeatedly and laboriously constructing long sequences of cryptic commands each time the apparatus requires some control input or reconfiguring.

The processing means may be configured to fill said data element location when it is identified by means of place-holder so as to replace said place-holder.

Preferably, interface definition data set comprises data defining at least one prompt for a user to input information related to the respective task and defining for each prompt an input element adapted for the input of a response to that prompt and the processing means is configured such that the or each place-holder is replaced in dependence on information input by a user using the or each input element.

Preferably, the user interface means comprises means defining a GUI window having a plurality of controls, each control having a property controlling its visibility and the user interface definition data set comprise data identifying which of said controls are to be visible, the user interface means displaying said GUI window with said controls being visible or invisible in dependence on the retrieved user interface definition data. In this context, "control" means a text box, a button, a list box etc. as commonly found in Microsoft Windows, XWindows and MacOS graphical user interfaces.

The present invention may be usefully employed in a communications network, for example a telephone network. In such a case, the processing means may be configured to process input information to produce native control and/or configuration data for a routing node of the network. Conveniently, the communication means comprises a channel of the network.

According to the present invention, there is provided a method of configuring and/or controlling an apparatus, the method comprising the steps of :- retrieving, from storage means, a user interface definition data set, in electronic form, for a control and/or configuration task in respect of a subject apparatus; providing a user interface defined in the retrieved user interface definition data; accepting a user input made using the user interface; retrieving, from storage means, a native control and/or configuration data set, in electronic form, for said control and/or configuration task, the native control and/or configuration data set having an identification of a data element location therein; filling said identified location of the retrieved native control and/or configuration data set with native control and/or configuration data in dependence on said accepted user input to produce a complete native control and/or configuration data set; and communicating said complete native control and/or configuration data set to the subject apparatus.

Preferably, a method according to the present invention comprises the steps of:- retrieving, from storage means, a user interface definition data set, in electronic form, for a control and/or configuration task in respect of a subject apparatus; providing a user interface defined in the retrieved user interface definition data; accepting user inputs made using the user interface; retrieving, from storage means, a native control and/or configuration data set, in electronic form, for said control and/or configuration task, the native control and/or configuration data set having identifications of data element locations therein; filling said identified locations of the retrieved native control and/or configuration data set with native control and/or configuration data in dependence on said accepted user input to produce a complete native control and/or configuration data set; and communicating said complete native control and/or configuration data set to the subject apparatus.

The native control and/or configuration data sets may have their identifications of data element locations within themselves, in which case retrieving such a data set will also cause the data element location identifications to be retrieved. Alternatively, the data element location identifications may need to be retrieved by accessing an associated file, database record or data structure.

Filling an identified location may comprise replacing a place-holder.

Preferably, each interface definition data set comprises data defining at least one prompt for a user to input information related to the respective task and defining for each prompt an input element adapted for the input of a response to that prompt and the processing means is configured such that the or each place-holder is replaced in dependence on information input by a user using the or each input element. More, preferably, user interface definition data comprises data identifying which of a plurality of GUI controls (as defined above) having properties controlling their visibility are to be visible.

A method according to the present invention may be applied to the control and/or configuration of a communication signal routing node in a communication network, for example a telephone network. Conveniently, communicating the native control and/or configuration data set to the subject apparatus comprises transmitting the data via the network which includes the routing node to be controlled and/or configured.

The afore-mentioned native control and/or configuration data sets may consist of one or more discrete instructions for the subject apparatus.

An embodiment of the present invention will now be described, by way of example, with reference to the accompanying drawings, in which:-

Figure 1 illustrates the physical topography of a virtual private network system;

Figure 2 illustrates the conceptual topography of the system of Figure 1; Figure 3 illustrates the database tables of a switch of Figure 1;

Figure 4 illustrates the processing of a call by a switch of Figure 1;

Figure 5 shows the major components of an apparatus according to the present invention;

Figure 6 illustrates the tables of the database used by the apparatus of Figure 5; Figure 7 shows the structure of the program used in the described embodiment;

Figures 8 to 25 show windows displayed by the apparatus of Figure 5; and

Figure 26 shows a data entry window displayed by the apparatus of Figure 5.

Referring to Figure 1, two virtual private networks are provided by the same physical network. The physical network comprises first to fifth NorTel DMSIOO switches la, ..., le. At least one remote line unit 2, 3, 4, 5, 6, 7 is connected to each of the switches la, ...le. In the simple network shown in Figure 1, a first remote line unit 2 is connected to the first switch la, a second remote line unit 3 is connected to the second switch lb, third and fourth remote line units 4, 5 are connected respectively to the third and fourth switches lc, Id, and fifth and sixth remote line units 6, 7 are connected to the fifth switch le. The switches la, ..., le are configured so that each customer benefits from the appearance of a private network notwithstanding that switches and lines are in fact shared in the physical domain.

Customer A has a first extension 8 and a second extension 9 conneαed to the first remote line unit 2, a third extension 11 and a fourth extension 12 connected to the second remote line unit 3, and a fourth extension 14 connected to the fifth remote line unit 6. Customer B has a first extension 10 connected to the first remote line unit 2, a second extension 13 connected to the second remote line unit 4 and a third remote line unit 15 connected to the sixth remote line unit 7. The FeatureNet 5000 service provided by British Telecommunications pic is an example of such as system.

Referring to Figure 2, Customer A's first extension 8 is located in a first geographical area 20, its second extension 9 is located in a second geographical area 21, its third and fourth extensions 11, 12 are located in a third geographical area 22 and its fifth extension 14 is located in a fourth geographical area 23. These areas will be referred to hereinafter as "charge groups".

The customer charging for the network shown in Figures 1 and 2 is based on "notional networking channels" (NNCs). An NNC is a quantum of network capacity. Each NNC is composed of two virtual, unidirectional circuits. NNCs connect different charge groups which may or may not be served by the same switch la, ...,le.

A first NNC 24 connects the first charge group 20 to the second charge group 21, a second NNC 25 connects the first charge group 20 to the third charge group 22 and a third NNC 26 connects the first charge group 20 to the fourth charge group 23. The NNC topology can be set up according to a customer's preferences. For instance, in the present example there is little traffic between the second and fourth charge groups 21, 23 and it is therefore more economic for the customer to route such calls via the first and third NNCs 24, 26 than have an NNC linking the second and fourth charge groups 21, 23 directly.

NNCs are constructed using virtual facility groups (VFGs). The number of VFGs used depends on whether the NNC is contained in a single switch la, ...,le or spans two switches la, ...,le. In the case of an NNC on a single switch la, ...,le, e.g. first charge group 20 to second charge group 21, two VFGs are used, one in each direction. In the case of an NNC spanning two switches la, ...,le, e.g. first charge group 20 to third charge group 22, four VFGs are used, one for each direction on each switch la, ...,le. For each NNC, one direction is considered to be the "main" and the other the "return". Normally, the main direction is from the non-hub to the hub. A hub is a charge group with access to more than one NNC. Thus, the first charge group 20 is a hub, whereas the second, third and fourth charge groups 21, 22, 23 are non-hubs. Counting of the usage of NNCs is done in the VFG which supports the main direction. The return VFG is defined as "using" the main VFG. Therefore, a call originating at either end of the NNC uses the same counter for billing purposes. The number of NNCs between two charge groups (i.e. the capacity) is also defined in the main VFG and can be from 1 to 2048 in the present example.

Calls within a charge group are local networking calls and do not attract a charge. However, calls between charge groups use one or more NNCs and do attract a charge.

The physical routing of calls will now be discussed.

Networking is used herein to refer to calls which originate and terminate on different switches la, ..., le. The protocol employed between the switches la, lb, lc, Id, le is ANSI ISUP (ISDN User Part).

"Netinfo" comprises additional information that is sent across the ANSI ISUP links with dialled digits. Netinfo consists of three fields:-

(a) NetID

The NetID is an identifier which is unique to a customer across the network.

(b) CustID The CustID is the customer group number. In each charge group, each customer's extensions have the same customer group number which will be different from that of any other customer's extensions. However, the CustlDs can be reused in each charge group.

(c) NCOS (network class of service) The NCOS field is a value allocated to an extension and is used to specify special processing of calls, e.g. call barring, translations. The same NCOS may be allocated to many extensions.

Referring to Figure 3, the switches la, ... , le each contain a database including inter alia the following tables: the NETNAMES table 27, the CUSTENG table 28, the CUSTHEAD table 29, the NCOS table 30, the XLANAME table 31 and the IBNXLA table 32. These tables are a standard feature of DMSIOO switches. The records of the NETNAMES table 20 map customer names onto NetlDs. The CUSTENG table 28 has a record for each customer group of each customer indexed by CustID and NetID. The NCOS table 30 comprises, for each record in the CUSTENG table 28, up to 256 records containing names of types of special call processing. The CUSTHEAD table 29 has a record for each customer group indexed by CustID and NetID. Each record contains names for an in-customer group routing process and an out of customer group routing process. The XLANAME table 31 provides translations between the special call processing names of the NCOS records and the names from the CUSTHEAD table 29 and indexes for the IBNXLA table 32. The IBNXLA table 32 provides routing control data on the basis of the indexes from the XLANAME table 31 and dialled digits.

Considering now, for example, the first switch la and referring to Figure 4, a call is received from Customer A's first extension 8. The first switch la looks up the NetID, CustID and NCOS for the extension (step si) in a suitably constructed lookup table. The NetID, CustID and NCOS are then used to access the CUSTENG table 28 to obtain an indexes for NCOS table records for customer A's first extension 8 (step s2) and NetID and CustID are used to obtain an in-charge group process name and an out of charge group process name from the CUSTHEAD table 29 (step s3). The process name from the first record in the NCOS table 30 is then used to access the XLANAME table 31 to obtain an index for the IBNXLA table 32 (step s4). The index identifies a plurality of records in the IBNXLA table 32 each having different dialled digits field. These IBNXLA table records are searched for a match with the dialled digits from Customer A's first extension 8 (steps s5 & s6). If a match is found at step s6, the call is processed, e.g. barred, according to further information in the current IBNXLA table record (step s7). If no match is found with any of the selected IBNXLA table records at step s6, the current XLANAME table record is inspected for a default behaviour (step s8). If a default behaviour is defined, this is carried out (step s9). If no default behaviour is specified, it is determined whether the last NCOS table record has been processed, if not steps s4 to s8 are repeated. If the last NCOS table record has been processed, the XLANAME table 29 is used to obtain an index for the IBNXLA table 32 using the in-charge group process name. The index selects a plurality of records in the IBNXLA table 32, each having a different dialled digits field. For each selected IBNXLA table record, the dialled digits from Customer A's first extension 8 are compared with those in the IBNXLA table record (step sll). If a match is found (step sl2), the call is routed according to further information in the current IBNXLA table record (step sl3). If no match is found with any of the selected IBNXLA table records (step sl2), the XLANAME table 31 is used to obtain an index for the IBNXLA table 32 using the out of charge group process name. The index selects a plurality of records in the IBNXLA table 32, each having a different dialled digits field. For each selected IBNXLA table record, the dialled digits from Customer A's first extension 8 are compared with those in the IBNXLA table record (step sl4). If a match is found (step sl5), the call is routed according to further information in the current IBNXLA table record (step si 6). If no match is found, the dialled number is reported as being unobtainable (step sl7).

In the case, where a call is routed between switches la, ... , le, the NetID, CustID and NCOS values, obtained at the switch first receiving the call, accompany the dialled digits in the Netinfo. The receiving switch therefore processes the call according to steps s2 to sl7 only. The native instructions for building the database tables 27, 28, 29, 30, 31, 32 of DMSIOO switches are complex and skilled staff are, therefore, required for configuring them. For the provision of virtual private network services, the switches la, ... , le must be configured for the definition of virtual private networks, call barring and dial plans.

Referring to Figure 5, a control input apparatus for configuring the switches la, ..., le of Figure 1 comprises a user interface part 40, a compiler part 41 and a communications link 42. The user interface part 40 allows users to specify configuration information for switches in a user-friendly manner and stores it in a first format. The compiler part 41 takes data entered via the user interface part 40 and converts it into native instructions for DMSIOO switches. The communications link 42 communicates the native instructions to the DMSIOO switch to be configured. The communications link is the network shown in Figure 1.

Referring to Figures 5 and 6, the user interface and compiler parts 40, 41 operate in conjunction with an Oracle (RTM) database 44. The database comprises a customer lookup table 50, a customer template table 51, a switch asset table 52, a switch lookup table 53, a switch constant table 54, a security information table 55 and a screen text table 56. There are one to many relationships between the customer lookup table 50 and the customer template table 51, between the customer lookup table 50 and the switch asset table 52, between the switch lookup table 53 and the switch asset table 52 and between the switch lookup table 53 and the switch constant table 54.

The customer lookup table 50 comprises the following columns:-

CL_CUSTOMER which holds the customer code

CL_NAME which holds the customer's name

The customer template table 51 comprises the following columns:- CT_TEMPLATE which holds the screen template name CT_CUSTOMER which holds the customer code for the screen templates associated customer

CT_VARIABLE which holds the name of a table in the template CT_ROW which holds the number of a row in the table CT_COLUMN which holds he number of a column in the table CT VALUE which holds the value to be placed in the cell identified by CT_ROW and CT_COLUMN

The switch lookup table 53 comprises the following columns:- SL_SWITCH which holds the switch's code

SL_NAME which holds the switch's name

The switch constant table 54 comprises the following columns:- SC_SWITCH which holds the switch's code SC_CONST which holds the name of the constant

SC VALUE which holds the value of the constant

The switch asset table 52 comprises the following columns:-

SA_SWITCH which holds the switch's code SA_TABLE which holds the name of a DMSIOO table name SA_ATTRIBUTE which holds the field of the table SA_VALUE which holds the value for the field SA IN USE which holds whether the attribute is available or in use SA_USER_NAME which holds the name of the user who last used the attribute SA_D ATE_TIME which holds the date and time of last use of the attribute SA_TEMPLATE which holds the template using the switch asset SA_CUSTOMER which holds the customer who owns the template

The screen text table 56 comprises the following columns:-

ST VARIABLE which holds the name of a variable within a screen template ST_SEQUENCE which holds the position of the variable in the screen template ST_VALUE which holds the value of the variable

The security information table 55 comprises the following columns:- SY_NAME which holds the user's name

SY_STATUS which holds the user's access privileges

The security information table 55 holds information that is used to allow a particular user access to various functions of the system. The screen text table 56 holds information defining the user interface during run-time.

The user interface program is written in Visual Basic and runs under Microsoft Windows, and includes objects defining various windows or forms. These forms are listed in Table 5.

Table 5

Referring to Figure 7, when a user runs the program, he is asked for his user name ^■ and password (pl) by frmLogin (Figure 10). If these are entered correctly, the user is presented with mdiMain (Figure 25) without any child windows (p2).

Assuming that the database 44 is empty, the user must first add one or more customers. To do this, the user selects the customer menu item on mdiMain. The program responds by displaying frmC ookup (Figure 12). The user can then enter a four-character customer code (NetID) and the customer's name (p3). When the user clicks on the Insert button, the entered data is stored in the customer lookup table 50. A customer can be deleted by entering the code for the customer and then clicking on the delete button. Clicking on the Exit button returns the user to the empty mdiMain window.

Once the customer has been entered, it is necessary to add the switches la, ...,le (Figure 1) used for the customer's virtual private network. This is done by selecting the switches menu item on mdiMain. The program responds by displaying frmSJLookup (Figure 13). The user can then enter a four-character switch code and the switch's name (p4). When the user clicks on the Insert button, the entered data is stored in the switch lookup table 53. A switch can be deleted by entering its code and then clicking on the delete button. Entering the switch code and name and clicking on the Insert button can be repeated until all of the switches la , ...,le have been added. Clicking on the Exit button returns the user to the empty mdiMain window. The system is now populated with customers and the switches la , ...,le and a user can configure the switches using the frmDataEntry (Figure 8). To get to frmDataEntry, the user selects the data entry menu item on mdiMain. This causes the program to display frmFileList (Figure 9). frmFileList presents the user with a listbox of customers, which of course contains only one in the present case, and a tree list of screen templates 45 (p5). The screen templates 45 will be explained when frmDataEntry is described in detail below.

A new customer can be added (p6) from frmFileList by clicking on the Copy button. This brings up frmCustCopy (Figure 22). Selecting a customer and clicking the OK button enables a customer's templates to be copied for another new customer.

When the user has selected a customer and a screen template and clicked on the OK button on frmFileList, the program responds by displaying frmDataEntry or frmTemplateBranch (Figure 22). In the present case, it will be assumed that the selected screen template does not have a branch and the program immediately displays frmDataEntry (p7).

The appearance of frmDataEntry is controlled by the selected screen template and may comprise a plurality of pages. Each page of frmDataEntry may comprise upto ten questions and associated controls for entering answers to the questions. To achieve this ten labels are arranged one above the other in the lefthand side of the form and a text box, a list box, a dropdown combo box and a table are aligned with each label. The default value for the visible properties of the labels, the text boxes, the list boxes, the dropdown combo boxes and the tables. The visible properties of these controls and the displayed text is set by the template.

The format of the screen template files 45 will now be described.

The first line of a screen template file has the following format: hdg,<Long Headings <Short Heading>,<Groups> Long heading is the heading to be used on frmDataEntry. Short heading is the name of the screen template to be used in the template tree list on frmFileList. Group is the name of the template group to which the template belongs. The grouping of templates is purely conceptual and is used only in the generation of the treelist display on frmFileList.

A text box is included in the screen template by using the following field format: txt,<Comment>,<Help>,<Variable Name>,<Format>,<Number of Characters;*, <Customer Default> where:

< Comment > is the text to be displayed in the associated label.

< Help > is the keyword in the help file for providing context sensitive help.

< Variable Name > is the control to be made visible.

< Format > indicates whether a value entered in the text box can be alpha- numeric or only numeric.

< Number of Characters > is the maximum number of characters that can be entered in the text box and is used to set the width of the text box.

< Customer Default > may have the values Y or N and is used by the program to check whether the text box's text property should be set from the Customer database. It is also used to check whether the text property of the text box should be stored as a customer default, if that option is selected by a user.

A dropdown combo box is included in the screen template by using the following field format: drp,<Cornment>,<Help>,<Variable Narne>,<Format>,<Number of Characters>,<Customer Default>,<Database Entry> where: < Comment > is the text to be displayed in the associated label.

< Help > is the keyword in the help file for providing context sensitive help. < Variable Name > is the control to be made visible.

< Format > indicates whether a value entered in the combo box can be alphanumeric or only numeric.

< Number of Characters > is the maximum number of characters that can be entered in the text box and is used to set the width of the combo box.

< Database Entry > holds the key for the rows of the database which are used to populate the dropdown list of the combo box.

A list box is included in the screen template by using the following field format: lst,<Comment>,<Help>,<Variable Name>,<Number of Characters>,<Database Entry>,<Height> where:

< Comment > is the text to be displayed in the associated label. < Help > is the keyword in the help file for providing context sensitive help.

< Variable Name > is the control to be made visible.

< Number of Characters > is used to determine the width of the list box.

< Database Entry > holds the key for the rows of the database which are used to populate the list box. < Height > is the number of rows to be displayed in the list box.

A table is included in the screen template by using the following field format: tbl,<Comment>,<Help>,<Variable Name>,<Format>,<Number of Characters>,<Customer Default>,<Number of Rows>,<Number of Columns>,<Height>,<Column Heading 1 >,<Column Width 1>,<Column Heading n>,<Column Width n> where:

< Comment > is the text to be displayed in the associated label.

< Help > is the keyword in the help file for providing context sensitive help.

< Variable Name > is the control to be made visible. < Format > indicates whether a value can be alpha-numeric or only numeric.

< Number of Characters > is the maximum number of characters that can be entered in a cell of the table.

< Customer Default > may have the values Y or N and is used by the program to check whether the values in the table should be set from the Customer database. It is also used to check whether the values in table the should be stored as a customer default, if that option is selected by a user.

< Number of Rows > sets the number of rows in the table.

< Number of Columns > sets the number of columns in the table. < Height > is the number of rows to be displayed in the table at any time.

< Column Heading n > sets the heading of column n.

< Column Width n > sets the width of column n.

A page break is included in the screen template by using the following field format: pge

Page breaks can be inserted at any point in the template for aesthetic purposes. However, they must be inserted when a page becomes full.

A branch is included in the screen template by using the following field format: brn,<Number of Branches>,<Branch Title 1 >,...,<Branch Title n> where:

< Number of Branches > is the number of branches in the template.

< Branch Title n > is the title of the nth branch to be displayed in frmTemplateBranch (Figure 19).

To identify which screen items are to appear within each branch, delimiter markers are used as follows:

<branch>,<Branch Number> Screen items <branch>,end

The screen templates may be created using a wordprocessor or a text editor and are stored as ASCII files.

An output template 46 is associated with each screen template. The output templates 46 comprise sets of native switch commands in which the variable data is replaced with codes. The codes can relate to screen inputs made using frmDataEntry, switch constants, and normal and reusable switch assets. Additionally, the customer name and code can be included in an output file by including {b_customer} and {b_customername} in the output template. Switch constraints are string of switch control characters that can be used in many templates, avoiding the need for the strings to be repeated in each output template. The switch assets are field values for switch database tables that differ according to the switch to which a template is being applied. Again, this reduces duplication in output templates.

Values entered or selected using text boxes, combo boxes and list boxes are identified in the output template by the name of the control in curly brackets, e.g. {ListBoxl}, {TextBox3} etc. Tables are handled somewhat differently. When data from a table control is to be included in the output file, < loop/tbl > is included in the template. The placing {T_Cn} in the same line as < loop/tbl > will cause the value in the nth column of the table to be included in the output file for all of the rows of the table.

Switch constants are included in the output file by including {sc_constant name} in the output template.

Normal switch assets from the switch asset table 52 are included in the output file by inserting {SA_N/tbl/ast} in the output template, where tbl is the name of the table and ast is the name of the asset. The SA_N part means that the system should increment the value of the asset each time the asset is called in the output template.

Reusable switch assets from the switch asset table 52 are included in the output file by inserting {SA_R/tbl/ast} in the output template, where tbl is the name of the table and ast is the name of the asset. The SA_R part means that the system should increment the value of the asset only on the first occasion the asset is called in the output template.

A branch is accommodated in the output file by delimiting a branch portion of the output template thus:

< branch > , < Branch Number > branch items

< branch > ,end

When data has been input using frmDataEntry and the OK button has been clicked, the user is presented with frmDataOutput (Figure 16). The user uses this form to select the switch to be configured and the name of the output file to be created (p8).

The output file is created by copying the output template while substituting the place-holders in curly brackets with the data identified thereby.

The output file is transmitted to the selected switches la , ..., le via the network.

If the screen template 45 includes a branch, clicking on the OK button of the form frmFileList. The program responds by displaying frmTemplateBranch (Figure 21) which displays the branches within the template (p9). When the user selects a branch, the program displays frmDataEntry configured according to the chosen branch.

Switch assets can be added (plO) by user using frmS witch Assets (Figure 14). Similarly, switch constants can be added (pll) using frmSwitchConst (Figure 15). The switch assets can be displayed and amended (pi 2) using frmS witch Admin (Figure 16). A search for switch assets (pi 3) can be undertaken using frmSwitchSearch (Figure 19) which is displayed by clicking on the Search button on frmSwitchAdmin.

Customer template data can be displayed and amended (pl4) using frmCust Admin (Figure 18). Selecting "customer" and "template" fills the screen with the attributes used within a template for a given customer. Such a template can be used for more than one customer.

The validity of the template can be checked using frmTemplateValidate (Figure 24). The program code (pi 5) associated with frmTemplateValidate checks the syntax of a selected screen template file and indicates errors in the Result column.

Bulk load (Figure 21) allows a table within a template to be loaded direct from a comma-separated value file, avoiding the need to type the attributes into the table. A list box is used within a template and only the attributes in the list box can be chosen to be put in the template variable.

A user can change his or her password (pl6) by selecting the change password menu item on mdiMain which causes frmChangePassword (Figure 10) to be displayed.

Having described the general principles of the templates 45, 46, screen and output templates for setting call barring on a customers virtual network will now be described.

The screen template is as follows: -

hdg, BARRING DEMO, BARRING DEMO, txt.Enter customer Mnemonic „mn,A,002,N tbl, Enter Ncos and Barred Codes „table,N, 10,N,25,2,8,Ncos,4,Code,5 The resulting screen is shown in Figure 26. The output template is as follows:-

TAB IBNXLA <loop/table>PUT{mn}NCOS{T_C1} {T_C2} TRMT VACT

When the data shown in Figure 26 is input and the OK button clicked, the following output is produced for dispatch to a switch:-

TAB IBNXLA

PUT TTNCOS20 9 TRMT VACT

PUT TTNCOS21 90898 TRMT VACT

PUT TTNCOS21 90899 TRMT VACT

PUT TTNCOS21 90900 TRMT VACT PUT TTNCOS21 90901 TRMT VACT

PUT TTNCOS21 90902 TRMT VACT

PUT TTNCOS21 90903 TRMT VACT

PUT TTNCOS21 90904 TRMT VACT

PUT TTNCOS21 90905 TRMT VACT PUT TTNCOS22 900 TRMT VACT

PUT TTNCOS22 90990 TRMT VACT

PUT TTNCOS22 90345 TRMT VACT

PUT TTNCOS22 90800 TRMT VACT

QUIT

The output data loads data into the IBNXLA table 32. Considering the second line, calls for which the NCOS is "20" and the first dialled digit is "9" are treated "TRMT" as "VACT", that is vacant or barred.

The foregoing description of a DMSIOO switch is not exhaustive but serves to illustrate the advantages of the present invention.

Claims

1. A control input apparatus for controlling and/or configuring a subject apparatus comprising: storage means storing: user interface definition data sets for respective control and/or configuration tasks in respect of a subject apparatus, and native control and/or configuration data sets for said control and/or configuration tasks, each native control and/or configuration data set having an identification of a data element location therein; user interface means for selectively retrieving a user interface definition data set from the storage means and providing a user interface defined by the retrieved user interface definition data; processing means configured to fill said identified data element location of a native control and/or configuration data set, which data set corresponds to a retrieved user interface definition data set, with native control and/or configuration data in dependence on information input by a user using a user interface defined by a user interface definition data set, retrieved by the user interface means, to produce a complete native control and/or configuration data set; and communication means for communicating such complete native control and/or configuration data sets, produced by the processing means, to the subject apparatus.

2. An apparatus according to claim 1, wherein the processing means is configured to fill said data element location when it is identified by means of placeholder so as to replace said place-holder.

3. An apparatus according to claim 1 or 2, wherein each interface definition data set comprises data defining at least one prompt for a user to input information related to the respective task and defining for each prompt an input element adapted for the input of a response to that prompt and the processing means is configured such that the or each identified data element location is filled in dependence on information input by a user using the or each input element.

4. An apparatus according to claim 3, wherein the user interface means comprises means defining a GUI window having a plurality of controls, each control having a property controlling its visibility and the user interface definition data set comprise data identifying which of said controls are to be visible, the user interface means displaying said GUI window with said controls being visible or invisible in dependence on the retrieved user interface definition data.

5. A communications network including a communication signal routing node and an apparatus according to an preceding claim, wherein the processing means is configured to process input information to produce native control and/or configuration data for the routing node.

6. A communications network according to claim 5, wherein the communication means comprises a channel of the network.

7. A telephone network according to claim 5 or 6.

8. A method of configuring and/or controlling an apparatus, the method comprising the steps of:- retrieving, from storage means, a user interface definition data set, in electronic form, for a control and/or configuration task in respect of a subject apparatus; providing a user interface defined in the retrieved user interface definition data; accepting a user input made using the user interface; retrieving, from storage means, a native control and/or configuration data set, in electronic form, for said control and/or configuration task, each native control and/or configuration data set having an identification of a data element location therein; filling said identified location of the retrieved native control and/or configuration data set with native control and/or configuration data in dependence on said accepted user input to produce a complete native control and/or configuration data set; and communicating said complete native control and/or configuration data set to the subject apparatus.

9. A method according to claim 8, comprising the steps of:- retrieving, from storage means, a user interface definition data set, in electronic form, for a control and/or configuration task in respect of a subject apparatus; providing a user interface defined in the retrieved user interface definition data; accepting user inputs made using the user interface; retrieving, from storage means, a native control and/or configuration data set, in electronic form, for said control and/or configuration task, each native control and/or configuration data set having identifications of data element locations therein; filling said identified locations of the retrieved native control and/or configuration data set with native control and/or configuration data in dependence on said accepted user input to produce a complete native control and/or configuration data set; and communicating said complete native control and/or configuration data set to the subject apparatus.

10. A method according to claim 8 or 9, wherein filling an identified location comprises replacing a place-holder.

11. A method according to claim 8, 9 or 10, wherein each interface definition data set comprises data defining at least one prompt for a user to input information related to the respective task and defining for each prompt an input element adapted for the input of a response to that prompt and the processing means is configured such that the or each identified location is filled in dependence on information input by a user using the or each input element.

12. A method according to any one of claims 8 to 11, wherein the user interface definition data comprises data identifying which of a plurality of GUI controls having properties controlling their visibility are to be visible.

13. A method of controlling and/or configuring a communication signal routing node in a communication network according to any one of claims 8 to 12.

14. A method according to claim 13, wherein communicating the native control and/or configuration data set to the subject apparatus comprises transmitting the data via the network which includes the routing node to be controlled or configured.

15. A method according to claim 13 or 14, wherein the communication network is a telephone network.

16. A control input apparatus substantially as hereinbefore described with reference to the accompanying drawings.

17. A communications network substantially as hereinbefore described with reference to the accompanying drawings.

18. A telephone network substantially as hereinbefore described with reference to the accompanying drawings.

19. A method of configuring and/or controlling an apparatus, the method being substantially as hereinbefore described with reference to the accompanying drawings.

20. A method of controlling and/or configuring a communication signal routing node in a communication network, the method being substantially as hereinbefore described with reference to the accompanying drawings.