EP0555297A1 - Transaction processing - Google Patents

Abstract

A transaction processing terminal (for example, a telephone operator terminal) has separate data and instruction codes and can accept either data or instructions. The data entry program is recurrent and when you enter instructions, you can call the data entry program (from inside the program) to get the data. The calls are represented graphically on the screen with indication of the connection status.

Description

TRANSACTION PROCESSING

This invention relates to transaction processing, particularly, but not exclusively, to processing telephone call transactions. More specifically, the invention relates to apparatus for transaction processing, and particularly, but not exclusively, to terminal apparatus for instructing, via a communications link, a transaction to be performed by a remote processor.

Transactions of the type with which the present invention are concerned comprise the performance or execution of an operation in accordance with predetermined data. In general, the data needs to be input to the transaction processing apparatus prior to the performance of the operation. For example, in the case of an operator controlled call, in order to connect the call the exchange apparatus must be aware of the caller number and the destination (or called) number, and must also, if the call is properly to be accounted for, know the identity of the person to be charged, the charge rate and so forth. Generally, many other data are also desirable (such as the time of the call) for effective logging of transactions. Similarly, for banking transactions, equivalent data such as the source and/or destination bank accounts, amounts of money, instructing party, authorisation codes and so forth are required.

Prior to the introduction of electronic switching systems, operator services in the telephone network were provided manually. Each operator sat at a board provided with sets of sockets, jack plugs, lights and key switches. Actual connection of calls was effected by manually inserting a jack plug into a socket and using a dial or key pad to dial the required number. The call status of a connection was indicated by lights; the operator could monitor conversations by use of key switches.

In addition to connecting calls, operators were responsible also for noting call details on dockets which formed the basis of accounting and billing activities. Information which an operator might need (such as telephone numbers for emergency services or codes for distant exchanges) was available in the form of printed booklets or hand written notes .

A number of telephone exchanges still provide operator services in this way, even when automatic connection of calls for direct dialling is provided by digital exchange equipment.

An alternative system, the ACRE exchange system, is still in use in a number of analogue exchanges around the U.K. The following briefly describes a cordless ACRE operator work station:

ACRE operator controls and displays are housed in a long low custom-built desk in front of which the operator sits wearing a head-set.

There is a keyboard, the key layout of which splits the keys into 4^* areas on the desk. One area contains the numeric keyboard, another contains circuit call connection keys for controlling the connections of the call; and corresponding indicator lights, and the remaining two areas, to the left and right of these, miscellaneous function keys. A very small back-lit fluorescent display, with a fixed format, contains information on the phone number being dialed and some mnemonics describing the call type. The display layout is analogous to a small printed form.

There are few coherent underlying rules specifying the order in which data is to be entered, so that different types of call entry each involve complex sequences of data entry and function key presses which must be leared by the operator. Reference to a card-file is still usually required when the operator is to connect a large number of call types such as alarm calls, booked calls, freephone calls and so on.

With the advent of digital exchanges, however, it became possible to manage operator controlled calls using specialised dedicated computer equipment. At present, British Telecommunications Public Limited Company uses a system known as BTOSS (British Telecom Operator Service System) . This system is implemented in conjunction with, amongst others, the "System X" digital exchange equipment provided by GEC Plessey Telecommunications (GPT), each operator being provided with a visual display unit (VDU) and a keyboard which communicate with the exchange equipment. The equipment distributes incoming calls to operators, and collects billing information. The VDU presents to the operator a form in which there are a number of fields, a selection of which must be filled in in an appropriate sequence for a call to be connected and billed correctly.

At present, there are 168 different documented procedures to be memorised. The general arrangement of such a system is indicated schematically at Figure 1. Referring to Figure 1, a system such as the BTOSS system comprises a computer controlled digital exchange 101 linked to an operator position 102 which comprises a call monitor 103 comprising loudspeaker 104 and microphone 105 connected as a conventional head set. Also provided is an operator services computer 100 and terminal apparatus 106 comprising a visual display unit (VDU) 107 and keyboard 108. The operator services computer 100 (a mainframe or mini-computer) collects billing information, amends and updates customer accounts, and controls the exchange 101 to change the call state (e.g. make or break a connection). The exchange 101 and computer 100 are operable on receipt of an operator call to route the call to the operator monitor 103 and to open a call record in the memory of the OS computer 100, portions of which are displayed upon the VDU 107 and data for which is entered by the operator via the keyboard 108. The operator may instruct the performance of a number of actions, for example, connecting the monitor 103 to another number, passing the call to another operator, connecting the call to a number and, subsequently, relinquishing the call back to the exchange 101. Where network services (such as alarm calls) are automatically provided, an operator may instruct the exchange 101 to execute such services also.

Generally, the operator will have to enter data to the OS computer 100 and/or exchange 101. In the case of an operator assisted call, the data will include the number to be called. In virtually all cases, it will include some information either indicating the cost of the call or the reason why there is no such cost, which information may for example include an indication of whether the call is normal tariff, reverse charge (or "collect"), credit card, pay-phone and so forth.

In other types of call, the operator will need access to information. For example, the caller may wish to know the area code ( "STD code") for a named area, or may wish connection to a number in that area without indicating its area code. A caller may also raise an enquiry on some aspect of a previous call, requiring access to the records of that call.

Broadly speaking, then, the three types of operation the system must perform are executing actions (affecting the call connection state), collecting input data (either to enable the execution or for ancillary purposes such as recording or billing the transactio ) , and supplying output data (to answer a query, or to be subsequently input as data for assisting execution of an action) .

In this type of prior art system, a typical screen display is shown in Figure 2. A number of data fields are shown on the screen, corresponding essentially to a display of a printed form, each field being designated by an abbreviation.

For each different type of call (168 types are itemised) the operator has to fill in predetermined fields with predetermined information, by moving the cursor to the field, typing in the correct information from the keyboard 108, and pressing the enter button, and then after the relevant fields have been filled in, an action key is pressed which instructs the exchange to execute a desired action (if any). Once the call has been dealt with by the operator, it is relinquished back to the exchange by pressing a "relinquish" button.

Different fields require data in different formats; for example, a call type - credit card, reverse charge etc. - is indicated by an alphabetical mnemonic, whereas a destination number is a string of digits of variable length depending upon the destination, and day/time information is a string of digits of a fixed length and format. As with a printed form, all the fields are displayed at all times. For each type of call, the exchange is configured to require information in a predetermined order. Thus, the fields must be filled in in the order specifed in the procedures manual, or the exchange will mistake the identity of the data and malfunction.

It is found that in practice, the number and the rigidity of procedures leads to the following problems:

Training operators takes a long time;

Operators often give up the training due to perceived and actual system complexity;

The screen layout and terminology are confusing, as are those of the keyboard;

More uncommon procedures are liable to be forgotten by operators; and,

Incorrect data is entered, or the correct data is entered at the wrong point in the sequence, leading to the possiblity of system failures, and/or incorrect customer billing. Some previous proposals for operator terminals are given in:

Thieffry, J and Hacquet, J "Contemporary operator position with automated ticketing and enhanced man machine interface" - 1986 IEEE International Conference on Communications, Strasser, H "A digital traffic operator position for a switching system with distributed control", 1982 International Zurich Seminar on Digital Communications, Man Machine Interaction (published by IEEE New York),

Lakshmipathy, S and Holzborn, 0 "An adaptive man machine interface for EPABX administration and maintenance", 1981 International Switching Symposium, Montreal (published by the International Switching Symposium, Verdun, Canada),

Morell Et Al "ANE 40: a modern telephone operator system", Colloq. Int. de Commutation, Paris (May 7 - 11, 1979, published by Comite du Colloq. Int. de Commutation, Paris Vol. 2, 709 - 714).

In one aspect, the invention provides a transaction processing system arranged to accept data input by a system operator, which can accept data without needing to follow a predetermined data entry sequence. In another aspect, the invention provides a transaction processing system which collects data relating a plurality of different parameters before transmitting any such data to means for executing a transaction.

These embodiments make the system less complicated and more easy to use for operators, and can provide enhanced error prevention. Preferably, a single routine handles both data and instruction input. Use of a recursive routine provides a mechanism for ensuring that, if insufficient data is present to execute a transaction, the system guides the operator to input the missing data.

In a preferred embodiment, the transaction is a telephone call transaction.

In another aspect, the invention provides a transaction processing system which displays transaction data, in which only a subset of the data held on the transaction is displayed at a given time. This makes the display easier to interpret, and guides the operator to entering data for the correct parameters.

The invention may be provided as an intelligent "front end" work station for connection to an existing transaction processing device via a telecommunications channel, or may itself comprise the transaction processing device.

In a further aspect, the invention comprises telecommunications exchange control apparatus which includes means for displaying a graphical representation of a calling and/or called telecommunications device. Such apparatus is known from EP0227327. The invention, in this aspect, is characterised by the provision of a graphic display of the presence, absence, or state of a connection between the called and calling devices. In another aspect, the invention is characterised in that the graphical representation of the telecommunications device indicates the type of device. These features greatly assist an opera*: r in understanding the state of a call to be processed.

Other aspects and preferred embodiments of the invention are as described in the following description and claims, with advantages which will be apparent therefrom.

The invention will now be illustrated, by way of example only, with reference to the accompanying drawings in which;

Figure 1 shows schematically a prior art operator call processing system;

Figure 2 shows schematically a screen produced by the system of Figure 1;

Figure 3 shows schematically a system according to one embodiment of the present invention;

Figure 4 shows the processor of the system of Figure 3 in greater detail;

Figure 5 shows schematically some contents of the store of Figure 4;

Figure 6 shows schematically general arrangement of the display of Figure 3;

Figure 7 shows schematically the arrangement of the keyboard of Figure 3;

Figure 8 shows schematically the method of use of the embodiment of Figure 3 in performing a transaction; Figure 9 shows schematically the arrangement of a table of data of Figure 5;

Figure 10 shows schematically the flow of operation of the system of this embodiment on receiving a communication from exchange equipment;

Figure 11 shows schematically the flow of operation of the embodiment of Figure 3 in processing an operator input from a keyboard;

Figures 12a and 12b show a preferred way of implementing the process of Figure 11;

Figure 13 shows schematically a detail of part of the store of Figure 5;

Figures 14 to 16 show in greater detail parts of Figure 12b;

Figure 17 -shows schematically the flow of operation of the system of this embodiment in transmitting an instruction message to exchange equipment;

Figure 18 shows schematically the format of such an instruction message;

Figure 19 shows schematically the flow of data in this embodiment of the invention;

Figures 20 to 23 show schematically screen displays produced by the described embodiments; and

Figure 24 shows in greater detail the keyboard of Figure 7. General System Description

Referring to Figure 3, in an embodiment of the invention suitable for use as an operator control terminal for processing call transactions, there is provided exchange equipment 1 comprising a computer controlled digital exchange 100 and an operator services (OS) computer 101 which may in fact be identical with those illustrated in Figure 1, and will be treated as such in the following description.

Connected to the exchange via a two wire cable 2a is a monitor unit 3 comprising a loudspeaker 4 and a microphone 5 arranged as a headset, as in the prior art. Also connected to the digital exchange 1 via a data channel 2b (e-g- a logical channel on a conventional computer communications ring circuit) is terminal equipment 6 which comprises a VDU 7, a key board 8 and a processor 9. The data channel is connected to the processor 9, as are the VDU 7 and the keyboard 8. The processor thus controls the format and content of the display on the VDU 7, and receives input from an operator via the keyboard 8.

Processor 9

Referring to Figure 4, the essential elements of the processor 9 are a processing device for central processing unit (CPU) 10, a read/write memory 11 for maintaining call- data (typically an area of random access memory, or RAM), a display control device 12 for formatting the display on the VDU 7, and an output port 13 for connection thereto, a program store 14 (typically a read only memory - ROM - device, but alternatively a read/write memory loaded from an external source such as a disc drive), and an input/output port 15 connectable via a data channel to the OS computer 100. Where the keyboard 6 is a separate unit, a keyboard port 16 for receiving characters from the keyboard 6 is also provided. Conveniently, these elements are interconnected via data and address busses, indicated at 17.

For reasons of availability, a PC-type microcomputer unit is employed; the PC-AT type is suitable. The latter employs an 8088 device running at 4.77 megahertz as the CPU 10, and one megabyte RAM memory device as the store 11.

Store 11

Referring to Figure 5, within the memory 11 there are provided a plurality of stores 400a, 400b, 400c (one for each call which can simultaneously be processed by the system) each of which comprises a table containing all the relevant data which might be required to describe and implement a transaction. To implement a telephone call, necessary data includes the telephone number of the caller and of the party he is calling, and may include the type of telephone device of each party (ordinary phone, payphone, radiophone and so on) . Data necessary to describe and record the call for billing purposes includes the time and date of the call, the call duration, the tariff rate, and the identity of the party who is paying for the call. Although some types of data are required for all calls (for example, the two phone numbers), different types of call require different data; for instance, whereas with a payphone call it is necessary to maintain a record of call duration and of coins deposited, with a call to an emergency service, where no charge is made, these are unnecessary and no other details of the identity of the paying party or of the call duration are necessary. Each table 400a, 400b, 400c is therefore dimensioned to contain fields for each type of data that could be required for all the different types of call transaction which are anticipated to occur, but for any given call, only certain data fields will be required.

As is usual, the store 11 also includes a working memory area 490, employed by the CPU 10 to maintain tables of program execution addresses and, in particular, to maintain a stack memory holding sub-routine return addresses, as will be discussed in greater detail below.

Display Unit 7

Referring to Figure 6, the display unit 7 receives, from the port 13, digital graphics commands and display data in serial format such as ANSI3.64-1979 or IS06429 standard formats, maintains a display buffer memory (not shown), and displays data received from the processor 9 in the format generally shown in Figure 6, which comprises a main display area 150 in which a graphical display of a selected call transaction is maintained throughout that transaction. Within the main display area 150, the information essential to the call transaction (called and calling telephone numbers, and called and calling display types) is displayed in display fields at predetermined positions.

Above the main display area 150, the display 7 is arranged to generate a status display area 206. Since the apparatus is capable of holding data on several different transactions at once, and of dealing with a selected one of the transactions, the purpose of the status display 206 is to show the status of those transactions which are not currently displayed in the main display area 150; thus in the area 206a, which relates to the call currently displayed in the main area 150, two symbols are shown, the left hand one being associated with the calling device field 201 and the right hand one being associated with the called party field 203.

In the area 206a, the circle symbol denotes a connection, and in the area 206b, the asterisk denotes the absence of a connection; it will thus be seen that the other calls indicated by the areas 206b and 206c are not currently in use. A connected call is thus indicated by a pair of circles, as shown in 206a.

A third display area 160 is also provided beneath the main display area 150. The purpose of the third display area 160 is to display auxiliary data which differs for different types of call, or to display other types of information which may be required by the operator during the call. For example, where the call originates from a coin box, data which is specific to coin box calls (such as the number of coins deposited) is displayed within the auxiliary display area 160. Alternatively, where incomplete data is available to the operator, the auxiliary display area 160 may be utilised to display a menu of possible candidate data values from which the operator may select a correct data value. This will be discussed in greater detail below.

The display 7 is arranged to display a cursor 170 at a position selected by the user, and to track the cursor position so that the CPU 10 can determine the data field within the data model record 400a in store 11 to which to write subsequent input data typed in via the keyboard 8.

It is important in this embodiment of the invention that the processor 9 is arranged to communicate rapidly any changes in the data table 400a, 400b, 400c which relate to data presently displayed in the status area 206, the main display area 150, or the auxiliary display area 160 to the display device 7, so that the display produced by the display device 7 accurately reflects the current state of the call data models 400a - 400c held in the store 11.

Keyboard 8 The keyboard 8 is conveniently a typewriter-style keyboard; one suitable keyboard is the 102 keyboard supplied by Ceratech Electronics Limited, United Kingdom, which provides a suitably high reliability and operating life time. The output produced by the keyboard 8 comprises a synchronous serial 8 bit signal indicating the value or identity of the key pressed.

Referring to Figure 7, the upper surface of the keyboard carries a set of alphabetical keys 700 of conventional QWERTY layout, together with conventional punctuation keys (mostly omitted). To the right of the keyboard a dedicated numeric keypad 710 comprising the digits 0-9 is provided.

A first group of screen control keys 720 comprising cursor up, down, right and left keys, are used to position the cursor within a display (e.g. a menu display) in the auxiliary display area 160. A group of six call connection keys 730 instruct the exchange 101 to change the state of connection between the calling and call parties and the operator, so as to connect or disconnect the operator monitor 3 to calling party or the called party or both, or to interconnect the two parties. A group of three selection keys 740 enables the operator to select from the three calls displayed in the status display 206 the call which is to be displayed in the main display 150 and to which subsequent data entry and instructions are to relate. It is therefore possible for the operator to interrupt handling one transaction, deal with another transaction, and then return to the first.

A group of ten transaction type, or service, selection keys 750 allow the operator to indicate the type of transaction which the calling customer requires. Because different types of transaction require only subsets of the data which can be held in each call data model 400a, 400b, 400c stored in the store 11, the CPU 10 after receipt of an indication of the transaction type can. instruct the display 7 to display only the relevant subset of data. By depressing such a key, the operator therefore selects the mode in which the processor 9 subsequently operates.

Additionally, the fact that a transaction is of certain types may automatically impose certain conditions on the data in the call data models; for instance, if a call is other than a third party pays, or transfer charge, or "collect" call, then the identity of the paying party is usually that of the caller. Similarly, certain types of service automatically imply a certain tariff rate. Selection of a transaction type key 750 may therefore also cause the CPU 10 to write data automatically to the fields of the call data models 400a, 400b, 400c held in the store 11. One particular type of transaction type key is the emergency services key 751, which is located as a physically distinct site on the keyboard 8 (here, the top left hand corner) and spaced apart from its neighbours, so that it can easily be located enabling the maximum speed of response to emergencies . Two further transaction-type keys 755 relate to transactions which do not involve the exchange 101 but do affect the records of passed and future booked calls held by the OS computer 100. A further bank of five keys 760 assist data entry; each key relates to a single data field held within the call data models 400a - 400c in the store 11, and assists the operator in entering data to that field, as will be discussed in greater detail below. A further group of three keys 765 are also of this "data entry" type, but relate exclusively to fields of data used only during coin box transactions.

A futher group of five keys 770 relate to instructions to the OS computer 100 relating to the stored call records held by the OS computer 100 during the progress of transactions selected by the keys 755. A futher group of five keys 780 relate to call handling between the terminal apparatus 6 and the exchange 101; for example, the operator can instruct that a call be transferred to another operator, or relinquished to the exchange 101 to be dealt with as a normal call without further operator intervention. The operator can also indicate that no further calls are to be accepted by the terminal 6. A further key 781 is also of this type. The enter key 790 and shift key 791 have special functions which will be described below.

It will therefore be seen that the keys on the keyboard 8 may be divided into a number of groups according to their function. Firstly, there are keys for directly entering data (the numeric and alphabetical key groups 710 and 700). Secondly there are instruction keys of various kinds; data entry instruction keys 760, 765, 720 which assist in inputting data; transaction-type, or mode, selecting keys 750, 751, 755 which instruct the CPU 10 to expect, and assist in compiling, the data relevant to the selected transaction; and executive keys 740, 770, 730, 780, 781 which instruct the performance of some action by the terminal 6, or the exchange equipment 1. Some actions (for example, selecting a different call for display on the main display 101 using one of the keys 740) require no data and can be immediately be executed by CPU 10 upon depression of the relevant key, but most require the presence of valid data in some fields of the call data models 400a, 400b, 400c stored in the store 11. It will thus be apparent that keys serving analogous purposes are grouped together on the keyboard 8.

A second principle underlying the layout of the keyboard 8 is that keys which operate in a similar manner are grouped together, as will be discussed below. This has advantages in that an operator will feel familiar with a key and its manner of operation even if it is rarely used, because it operates like its neighbours. For example, the keys in the groups 750, 751, 755 and 730 (and like keys not shown in Figure 7 ) are operable in a first mode to indicate an instruction or a selected operation mode by pressing the key, and in a second mode to reverse or cancel the instruction or selection, by pressing the key together with the shift key 791. A second set of keys always give rise to the same effects whenever pressed; for example,, the data entry keys 760 and 755, the instruction keys 770 and the upper row of four instruction keys of the groups 730 and 780.

The action caused by a third group of keys depends upon whether they have already been pressed; the effect of these keys is to sequentially cycle through a list of possible effects. Several data entry keys of the group 760 are of this type, so that, for example, the tariff datum may be entered by successive presses of an associated key within the group 760 which display successive possible tariff values (Low, Normal) until the desired tariff is displayed on the display 7.

From the foregoing, it will therefore be evident that the keys on the keyboard 8 are grouped firstly in accordance with the nature of the action taken by the CPU 10 in response to pressing the key, and secondly in accordance with the manner in which the keys are operated. A third principle, applicable to the coinbox key group 765, is that where possible keys which are to be used in close succession are grouped together. The advantage of grouping the keys which work in the same way together is that an operator learns quickly how to operate every key, by its position relative to its neighbours . The advantages of grouping keys used together is that the key sequences are more quickly executed, and also more quickly learned.

The keys are appropriately labelled, and the keyboard 8 generates for each a unique code giving rise to a corresponding action in the processor 9 as will be discussed below.

General Method of Use Referring to Figure 8, the general progress of a transaction in accordance with this embodiment of the invention will be discussed. When a caller telephones the number associated with operator services, the call is received at the relevant exchange 101, which signals the operator services computer 100 to distribute the call to an operator. The OS computer 100 therefore signals to the terminal 6, and instructs the exchange 101 to connect the call to the operator monitor 3.

At this point, Figure 8 commences. The operator speaks to the caller via the microphone 5, to ascertain the nature of the transaction he desires. For example, he may desire operator assistance in reaching a number which does not answer. The operator then selects the relevant key on the keyboard 8 within the group 750, 751 or 755, indicating to the CPU 10 the type of data which will be required to be collected within the relevant data model (say 400a) held within the store 11. There is, however, no absolute requirement that the operator should first determine the services required. Alternatively, he could obtain other data from the caller; for example, the callers telephone number or the number he wishes to be connected to. Such data may be entered using the data entry keys 760, 765, in conjunction, if necessary, with the alpha-numeric data keys 700, 710 on the keyboard 8. As discussed above, with reference to Figure 6, the values of certain call data are permanently displayed and updated in the main display area 150, for example, the telephone numbers of the two parties. One action undertaken by the CPU 10 and display 7 in response to the selection of a transaction type by the operator pressing one of the keys 750, 751, 755 is to alter the display in the auxiliary display area 160 to include a display of fields indicating, for that transaction, further items of data to be input.

Each field generally comprises a mnemonic indicating the type of data, followed by a number of spaces (which may provide some indication as to the data format, for example, a date may be represented as dd/mm/yy) . When the cursor 170 is positioned at such a field, data may be entered therein and written to the corresponding part of the data model 400a within the store 11. The fields may be displayed within a box display or "window" . Display devices and processors which include means for defining such windows are well known in the art.

The operator may go through several stages of data entry in this manner. At some point, some action will be required to complete the transaction, or to dispose of it in some fashion. The operator will therefore press an action instructing key from one of the groups

740, 770, 730, 780, or 781. The processor 9 determines the identity of the key and hence the action instructed; determines for that action what data is required in the data model 400a within the memory 11, reads the relevant parts of the data model

400a from the memory 11, checks whether data is present and valid, and hence determines whether it is possible or not to perform the required action. If the data required is present, the processor 9 sends the data together with an instruction, in an appropriate format, via the output port 15 to the exchange equipment for action by the OS computer 100 or exchange 101. If data is missing or is detected to be invalid in some way (for example, alphabetical characters are entered in place of numerical values) no attempt is made to communicate an instruction. Instead, the processor 9 returns to a state or readiness to receive data or instructions via the keyboard 8, and preferably provides a prompt on the display 7 indicating what data is detected as missing or invalid.

After successful performance of the transaction, or when it is desired to terminate the transaction for any other reason, the operator instructs that the call be relinquished; that is, that the monitor 3 be disconnected from the call and that the exchange 101 should proceed to treat the call as normal. The CPU 10 therefore sends a corresponding instruction via the output port 15 to the OS computer 100 and exchange 101, and after so doing, clears the call table 400a in readiness for the next transaction.

In some circumstances, data might be sent directly to the OS computer 100 after entry by the operator, for verification by the OS computer 100 (e.g., entry of credit card numbers) . Call Table 400

Referring to Figure 9, the structure of one of the call tables 400a - 400c within the memory 11 is shown in greater detail. The field 401 within the table 400 stores the type of the calling device; field 402 the status of the call (connected or disconnected); field 403 the called party device type; field 405 the calling party number; field 408 the tariff; field 409 the call class; field 410 the text of any notes the operator may wish to make; and field 411 the called number.

Fields are also included for the call duration, and the total cost of the call (412 and 413, respectively) .

Each field is defined to require data in a given format. For example, the field 401 requires the class of device data to take the form of a mnemonic selected from the list of all possible valid data types (e.g. ORD = ordinary, PPP = payphone). The field 402 requires a flag which is either set or reset, depending on whether the call is connected or disconnected. The fields 403 and 405 require purely numeric telephone number data, whereas the field 404 requires an entry selected from a list of three possible entries corresponding to "FROM", "TO", and "BOTH"; this is shown in Figure 10 as an alphanumeric entry. Thus, for each data field 401 - 411 within each table 400, a corresponding field 401a - 411a is also provided storing an indication of the data type which is required in the corresponding data field 401 - 411. Each field within the table 400 can be displayed in a corresponding display field on the display 7 as will be discussed in greater detail below.

General Sequence of Operation

Referring to Figure 10, when an incoming call is referred to the operator, the exchange 101 switches the call to the monitor 3. The OS computer 100 sends a digital signal via the data channel to the input/output port 15 of the processor 9. The signal may include such data about the call as is known to the exchange; for instance, the calling party number and the calling party device type.

Upon receipt of such a signal at the port 15, the port 15 is programmed to generate an interrupt signal. As discussed in greater detail below, the CPU 10 accordingly pushes all present values of local variables, and the present value of the program counter, onto stacks in the working memory area 490 of the memory 11, and commences the execution of an interrupt servicing routine, in which the incoming data is identified as corresponding to a given field within the call table 400 and is written to that field. The CPU 10 also sends the new data to any corresponding display fields which are currently the VDU 7. The CPU 10 then returns from the execution of the servicing sub-routine, causing the program counter and local variables to be retrieved from the respective stacks in working memory.

Now the call has been received by the processor 9, a graphical display symbol, or icon is written to the display device 7 indicating the calling device type corresponding ot the field 401 (or, if this has not been signalled by the exchange 1, indicating a default type) . The processor 9 now repeatedly reads a character from the keyboard port 16 as shown in Figure 11.

Referring to Figure 7, the character from the keyboard 8 may either be an alpha or numeric data key or a command/function key. If the character is an alphanumeric data character, the CPU 10 determines the cursor position from the display controller 12, and writes the data character into the corresponding character position in the field of the call table 400 which corresponds to the field displayed at the cursor position in the display on the VDU 7.

The character is then passed to the display controller 12 to be written to the corresponding display field on the display 7, to update the display. Depending on which field the cursor is currently positioned at, the character may be written from left to right or vice versa, and error checking may take place (as discussed below) .

If, on the other hand, the character returned indicates that the key pressed on the keyboard 8 was a command key, the CPU 10 attempts to execute the command (as discussed in greater detail below) . Various commands will, however, require the presence in the call table 400 of data in certain fields; for instance, the command to connect the call will require a called party number and a calling party number to be present in the fields 411 and 405 respectively. If data is not present in a field, and is required for the command, then instead of attempting, and failing, to execute the routine, the CPU 10 re-invokes the keyboard reading routine to read a character from the keyboard 8. Data/Instruction Input

Referring to Figures 12a and 12b, the process shown in Figure 11 will be described in greater detail.

Figure 12a demonstrates that the program structure comprises a continuous loop in which the keyboard reading routine of Figure 12b is repetitively called and executed. It will be recognised that this continual loop may be interrupted at any time by an interrupt signal generated from the input/output port 15 upon recieving a signal from the exchange 1 to execute the process of Figure 10.

Referring to Figure 13, within the working memory 490 in the store 11, there are provided a routine address table 491, containing the starting addresses of routines to be executed by the CPU 10. When a routine is called, the CPU 10 reads the relevant routine address from the address table 491 and places the address within the program counter register 10a of the CPU 10. In order that, once the routine has been executed, the CPU 10 can re-commence the task it had been performing, the value previously held within the program counter register 10a is written by the CPU 10 to the next vacant address within a stack table 492 within the working memory 490. This next vacant address value is stored within the stack pointer register 10b of the CPU 10. After storing the program counter 10a contents within the stack address contained in the stack pointer register 10b, the CPU 10 increments the stack pointer register 10b to point at the new next vacant address within the stack 492.

When the CPU 10 has completed the execution of a routine, the last instruction of the routine will correspond to a "return" instruction, which is interpreted by the CPU 10 to require that the stack pointer register 10b is decremented, and the contents of the location within the stack 492 now pointed to by the stack pointer register 10b are read by the CPU and stored within the program counter 10a. Where the CPU 10 employes other registers or internal variables, the current state of each will be written to and read from corresponding stacks (not shown) within the working memory 490 when a call to return from a routine is encountered by the CPU 10, so that after completing the execution of a called routine the internal state of the registers and internal variables of CPU 10 is the same as that prior to commencement of the routine. All the foregoing is well known in the computing art.

It will thus be seen that, if a routine for execution by the CPU 10 is defined to include a call to re-invoke itself, that is to say, is recursively defined, the effect is that each time the call to re-commence execution is encountered the stack pointer register 10b will be incremented so that the "depth" of the stack 492 increases, whereas each time the routine is completely successfully executed the contents of the stack pointer register 10b will be decremented and the depth of the stack 492 will be decreased.

The action taken by the CPU 10 upon receiving and interrupt signal is extremely similar; the address of the interrupt servicing routine is read from the address table 491; the contents of the program counter register 10a and the other internal registers of the CPU 10 are written to the stack 492, and the stack pointer register 10b is incremented; the address of the interrupt servicing routine is stored in the program counter register 10a; and the CPU 10 executes the interrupt servicing routine until a "return" instruction is encountered at which point the stack pointer register 10b is decremented and the program counter register 10a is re-loaded from the stack 492 so that the processor continues with the interrupted task. Thus, returning from the interrupt servicing routine shown in Figure 9, normal execution of the program continues .

Referring to Figure 12b, in the keyboard reading routine (labelled "GETKEY") the CPU 10 first reads, via the keyboard port 16, the character received from the keyboard 8.

Upon receipt of an alphanumeric character, the CPU 10 addresses the display controller 12 to determine the current cursor position, and determines, by look up, the identity of the corresponding field (e.g. 401) within the call table 400. It also reads the corresponding data type field (e.g. 401a). If the character conforms to the expected data type from the type field 401a, it is written into the position in the field 401 corresponding to the cursor position. The character is then written to the VDU 7 to update the screen display field. The routine then returns.

As stated above, in this embodiment, the command or function keys on the keyboard 8 may be divided into three types of action. Firstly, there are keys which indicate that the system is to operate in a particular mode, to provide a particular service. This will affect the class field 409 and may have implications for the tariff field 408. Referring to Figure 14, on pressing such a key, the CPU 10 therefore enters an amended value in the relevant field of the call table 400, and correspondingly updates the display on the VDU 7. For example, by pressing the Emergency key 751, the state of the call is changed from a normal assist call to an emergency call. The CPU 10 therefore writes EMERG into call class field 409 in store 11, and writes N (no charge call) into tariff field 408. Corresponding indications are given in display fields 209 and 208 on the VDU 7.

Other keys indicate actions for assisting the input of data from the operator. Many keys both change the mode and also prompt user input. Referring to Figure 15, in this case, the CPU 10 commences by instructing the display controller 12 to alter the display on the VDU 7 to display the fields for which data input is required, and positions the cursor at such a field.

At this point, the routine is defined to include a further call to the keyboard scanning routine of Figure 12b. This routine is therefore recursive, in that it is defined to include, under some circumstances, an instruction to re-commence execution of itself. Prior to calling the keyboard scanning routine, a "data required" flag 493 is set within the memory 11. As discussed above, the call to the routine causes the CPU 10 to push the contents of the program counter 10a onto the next vacant location address in the stack 492 held in the stack pointer 10b, increment the stack pointer 10b and then load the program counter 10a with the address of the routine of Figure 12b from the table 491 so as to commence execution of the routine of Figure 12b. At this point the operator may choose to enter data into a field or fields where it is required, in which case the CPU 10 stores the data in the relevant field of the call table 400 and cancels the data required flag 493 within the memory 11. If data is required for several fields, a corresponding "data required" flag in working memory 490 may be set for each, and the relevant flag is cancelled after the data has been input.

The routine then "returns" - i.e., the CPU 10 decrements the stack pointer 10b pulls from the stack 492 the address stored in the location held in the stack pointer 10b there, and loads it into the program counter 10a so as to commence execution at that address, which, it will be recalled, is itself within the routine of Figure 12b. The data required flag 493 is tested once more, and since it is now no longer set, the action is considered to be fulfilled. The CPU 10 then returns from the routine of Figure 12b to the main loop of Figure 12a.

It will be apparent, however, that at the point when the command routine within Figure 12b executed a call to the start of the keyboard scanning routine of Figure 12b, the operator need not enter data as prompted by the cursor 170 but may instead press a further command key. Suppose, in a first example, that a mode changing instruction key is pressed. The CPU 10 amends the call table 400, updates the display on VDU 7, and returns from the routine, without having cancelled the data required flag 493 in the memory 11. Since the flag 493 is still set, the command to enter data has not been completed and consequently the CPU 10 is not instructed to return, but instead to re-display the fields to which data is to be entered on the VDU 7 and execute another call to the start of the keyboard scanning routine of Figure 12b.

Suppose, alternatively, that the operator, instead of pressing an alphanumeric key, presses a command key initiating a data entry action. In this case, the relevant field is displayed on the VDU 7 and the data required flag 493 is set; the call to the start of the keyboard scanning routine is then executed, the stack pointer 10b address is incremented and the program counter 10a contents are again pushed into the stack 492. There is now in effect a second level of recursion, since the stack 492 is now two entries deep and, upon returning from the routine, the program counter 10a will return twice to this point since it is loaded into two successive locations in the stack 492. When the operator eventually enters the required data, the data required flag 493 will be cancelled, and the stack pointer 10b will be decremented, so as to "unwind" the recursions.

The effect is therefore that when a data required flag 493 is set, any subsequent instruction key pressed by the user causes the stack pointer 10b to increment until the flag 493 is cancelled, after which the stack pointer 10b may be decremented.

Finally, suppose that instead of entering an alphanumeric key, the operator enters an executive action key such as the key indicating that a call is to be connected by the exchange 1. Referring to Figure 16, the CPU 10 reads the call table 400 and checks whether valid data is held in the fields required for that action; for example, the calling number field 405, the called number field 403 and the tariff rate field 408. If all the necessary data is held and conforms to the data type validity criteria specified in the corresponding fields 403a, 405a and 408a, the action is executed and the routine returns. If not, the routine proceeds to a stage where data may be entered, as follows.

An "unwind" flag 494 is set in the working memory 490. The flag may be a single value under all circumstances, but preferably indicates the type of data which was unavailable and hence led to the action not being executed. After the return from the routine to the data entry servicing routine, the CPU 10 tests whether the unwind flag 494 is set. In the event that it is, the CPU 10 tests whether the data required flag 493 is set.

If the unwind flag 494 indicates the type of data which is missing, this is compared with the data required flags 493 and if a data required flag is set for that type of data, indicating the CPU 10 has now returned to the point in the routine 12b at which that data was unsuccessfully sought from the operator, then the CPU 10 cancels the unwind flag 494, and instructs the display controller 12 to re-display the display fields corresponding to the missing data fields on the display 7, and calls the start of the keyboard scanning routine of Figure 12b once more to attempt to prompt the operator to input the missing data.

In the event that no data required flag 493 is set, the CPU 10 returns from the routine to the point from which the routine was called. It will thus be seen that the effect of this is that, if an executory action cannot be performed, the recursions are "unwound" by decrementing the stack pointer 10b successively to the point at which the operator could or should have input the necessary data to enable the action to be executed. A very large number of levels of recursion may be built up by successive presses of data entry command keys, limited only by the space allocated to the stack 492 in the working memory 490; the system will nonetheless when possible decrement the stack pointer 10b to proceed back down successive levels of recursion to the point at which the required data may be input by the operator.

The exchange equipment 1 is thus only instructed to execute actions when the processor 9 has determined that the correct data are available in the call record to enable that action to be executed.

The use of a single, recursive, routine to enter data and instructions provides this embodiment of the invention with tolerance to the order in which data and instructions are entered.

Other Data/Instruction Input Possibilities Some other ways of executing this process will also be apparent to the skilled man. For example, the loop 12a, instead of continually reading the keyboard 8, could be interrupt driven to call the keyboard reading routine of Figure 12b only when a character from the keyboard 8 is received at the port 16. Also, instead of employing a recursive program structure in which use is made of the inbuilt instruction set of the CPU 10 to push and pull the contents of the program counter to and from a stack in order to call routines and return from routines, it is straightforward to design a program which appears non-recursive but maintains an explicit stack to achieve the same effect.

Error Checking

An important aspect of this embodiment of the invention is that errors in the input data are detected. Firstly, as stated above, the CPU 10 "filters out", or ignores, values received from the keyboard 8 which do not correspond either to command keys or to alphanumeric characters acceptable as data. Secondly, as stated above, the CPU 10 is arranged to check whether, for a given data field, the data character received is of the correct type (e.g., alphabetical or numeric) .

A third type of error checking is performed when the operator presses the ENTER command key 790. It will be apparent from the foregoing that data entry is character-by-character, and does not under normal circumstances require the use of the ENTER key 790. However, when this key is pressed, the CPU 10 examines each field 401-411 in the call table 400 (or, in a preferred embodiment, only those fields which are presently displayed on the VDU 7 ) and determines whether, for each, there is a value present. It further determines, for each field where a value is present, whether the value is allowable. For example, the data type field 404a indicates that the monitor state field 404 can only contain one of four values, indicating that the monitor is connected to the caller, the called party, both or neither. Similarly, impossible telephone numbers (for example, containing too many or to few digits, or commencing with an impossible digit) can be detected by inspecting the data type fields 403a and 405a. Finally, the contents of certain fields are interdependent; that is, particular combinations are impossible. For example, a transfer charge call entry in the call type field is incompatible with a credit card entry in the payment method field.

In the event that any one of these error criteria is not satisfied, the CPU 10 instructs the display controller 12 to position the cursor at the display field corresponding to the call table field of the erroneous datum, thereby prompting the user to re-enter a valid value. The keyboard scanning routine is then called, as described above.

The same data checks are performed by the CPU 10 when, in attempting to perform an execution-type command, the contents of the call table 400 are examined for the presence of valid data. Erroneous data is treated in exactly the same way as missing data in the above discussion, and so instead of instructing the execution of a command with erroneous data, the CPU 10 returns to a point enabling the correct data to be entered.

Particular Sequences of Operation

In the special circumstance where the executed command completes the transaction (e.g. connects the call), the unwind flag 494 is set to a "total unwind" value, which does not correspond to any data to be supplied, so that the recursion is completely unwound (i.e., the stack pointer 10b is successively decremented to the address of the bottom of the stack 492 and all return addresses are successively pulled from the stack 492 by the CPU 10). In the special case where the key pressed is the "Relinquish" key, the processor 9 transmits the contents of the call table 400 to the exchange equipment 1 and erases the contents of the call table 400 in readiness for the next call.

In the special case where the command instructs the displaying of a selected other one of the calls held in hand by the system, the CPU 10 accordingly varies the value of an index pointer 495 so that subsequent actions refer to the call table for that other call. The data required and unwind flags 493, 494 are set to zero.

Alternatively, they could be stored so that upon returning to the call the operator may resume at the point last displayed.

Instructing Transaction Execution Referring to Figure 17, when an executive action is to be performed, as described above, the CPU 10 determines the data which will be necessary to perform that action and checks whether valid data is held within the data table 400. If valid data is held, the CPU 10 proceeds to assemble, or compile, the message to be transmitted to the OS computer 100 to cause the execution of the desired action. Naturally, the form of the message is dictated by that expected by the exchange equipment 1. It is preferred to provide the process of assembling the message as a separate routine called from the routine of Figure 15, since this simplifies the modifications necessary to enable the CPU 10 to co-operate with different exchange equipment types.

In the above described embodiment, the OS computer 100 treats a message from the processor 9 as if it were from an operator keyboard 108 (and, correspondingly, generates output to the processor 9 as if it were a display terminal 107). The message assembly routine therefore corresponds, in essence, to a printed procedures manual used by an operator in the prior art; equipment; for each action to be executed, the routine assembles the sequence of key/characters and data which would correspond to those generated by an operator typing in the sequence manually from a keyboard 108.

The general format of a message sent to the OS computer 100 in this embodiment is indicated in Figure 18; it comprises a character or string of characters which identify the data field which is to follow, followed by data from one of the fields of the data table 400. Generally, several such fields are transmitted, each prefixed by an identifier character or characters. Finally, a character corresponding to the ENTER," or RETURN key, or some action key, is transmitted.

The message assembly routine routine may therefore be provided as a look-up table, in which each executory instruction corresponds to, and specifies, a single message sequence. Alternatively, a message assembly subroutine could be provided for each executory instruction key. The CPU 10 generates the required field-identifying characters, and passes them, interspersed with the appropriate data characters from corresponding fields of the data table 400, to the output port 15 for transmission to the OS computer 100.

Interpretation of commands from the exchange equipment 1, as illustrated in Figure 10, may be equally straightforward, requiring merely the decoding of the display instructions which the computer 100 is generating for the benefit of a non-existant display 107. With the described prior art OS computer 100 the display position indicates the identity of the field of the data which follows the display instruction as given fields are displayed at fixed positions.

General Flow of Data

Referring to Figure 19, the flow of data within the invention is generally indicated. The call data model 400 can be written to from the operator via the keyboard 8, or from the exchange equipment 1. The data currently held in fields of the call data model 400 is displayed upon the VDU 7. When a transaction is instructed, data from the call data model 400 is sent to the exchange equipment 1. The call data model thus acts as a buffer, allowing data to be assembled in any desired order and checked before being transmitted.

Actions Amending Transaction Records

In some cases, a caller may not wish to be connected to a number. Instead, he may, for example, wish to book an automatic alarm call at a predetermined time in the future, or to book a call to another person to take place at a fixed time in the future. Alternatively, he may wish to review stored details of transactions which have already taken place, for instance, to check the accuracy of the records, and arising from this he may wish to amend the records of calls which have already taken place (for example, to correct the charge made for a call) .

The OS computer 100 generally maintains a file for calls booked in the future, and a file logging details of previous transactions, and an operator may locate a particular call record within the file, inspect the details, and if necessary amend the record or add a new record to the file. In general, the actions taken by the system of the invention are to collect the data necessary to identify the call within the relevant file (e.g., the date and time of the call, and the identity of the called and/or calling party) , instruct the OS computer 100 to transmit the details of the call from the call file record, display the details in the auxiliary display area 160, amend the details if necessary, and re-transmit the new details back to the OS computer 100. Where it is desired to place a new call, only the last two steps are necessary.

In these cases, the relevant message containing the data fields indicating the details of the booked call is assembled and transmitted as described above to the OS computer 100, but the global "unwind" flag 494 is not set. The OS computer 100 will (shortly afterwards) reply with the relevant data (formatted for display on a nonexistent screen 107), and this message interrupts the operation of the CPU 10, which as described above decodes and displays the data at the relevant point on the display 7.

Detailed description of Screen Displays

Main Display Area 150

Referring to Figure 20, the main display area 150 includes a graphical representation 201 of the calling device, including an indication of the type of device; in this case, the word "ORD" indicates an ordinary subscriber telephone. In addition to an alphanumeric message denoting telephone type it is also preferred to denote different telephone types by different graphical displays.

Running from the calling phone representation 201 is a line representation 202 indicating the points to which the caller is connected. At the far end of the line 202 is a field 203 for a similar representation of the called device; at the initiation of the call, this is unknown to the system and an appropriate character (in this case ? is displayed) .

Between the caller and called device fields 201, 203 is a monitor state field (MON) 204. This indicates the connection of the operator monitor 3; the displayed word "both" indicates that the monitor is connected to speak and listen to both the called and the calling device, and the line segment connected to the line 202 indicates this fact graphically. In the initial stages of a call, the exchange equipment 1 will automatically connected the operator monitor 3 to the calling party as shown in Figure 20.

Adjacent to the calling device field 201 is a calling device number field (FROM) 205. In the event that the calling party is connected to the digital network, the exchange 101 will be aware of his dial number and will supply this to the processor 9 which will automatically generate the relevant number in the data field 405 and display field 205; similarly, if the device type is known to the exchange equipment 100, 101 the relevant information will be signalled to the processor 9, entered in the data field 401 and displayed in the display field 201. Also provided within a main area 150 are; a field 208 displaying the tariff to be charged to this call (TARIFF), a field 209 indicating the type of service or transaction being provided to the calling party (CLASS) and a field 210 in which the operator may record any desired notes during the transaction (NOTES). Finally, a field 211 for displaying the dial number of the called party ("TO") is displayed proximate the called party device field 203. All the above display fields 201 - 211 are controlled to display the data held in the corresponding fields 401 - 411 of the call data table 400 in the store 11.

Referring to Figure 21, the appearance of a payphone graphical representation within the calling party field 201 is shown. The connection line 202 indicates that the called and calling parties are connected, and the monitor state field 204 indicates that the monitor 3 is connected to both parties.

As discussed above with reference to Figure 6, each call index area 206a, 206b, 206c contains a pair of call state display symbols 207a 207b for the calling and called parties.

Auxiliary Display Area 160

Referring to Figure 21, one subset of the data held in fields of the call data table 400 is displayed when the call is a payphone call. In this case, a display area or window 500 is displayed within the auxiliary display area 160, comprising four display fields.

a. Coins field 501 - for coins entered by the caller b. Rem field 502 - for money remaining c. Cost field 503 - for call cost incurred so far d. Dur field 504 - for call duration These fields have corresponding data fields in the data model 400. When the display area 500 is shown, by appropriate positioning of the cursor, data can be entered to the corresponding data fields in the data model 400.

Referring to Figure 23a, in a transfer charge, or "collect" call, the auxiliary display area 160 contains a display field 510 reminding the operator that the call is of this type and showing the called party number, which will be charged for the call (together with the mnemonic XFC).

Where the operator has been asked to tell the paying party the duration and the cost of the call, the auxiliary display area 160 includes a display 520 reminding the operator of this fact, displaying the number to be advised in field 521, the duration of the call in field 522 and the cost in field 523.

Referring to Figure 23b, where the operator intends to manipulate the stored call record files held by the exchange equipment 1, the auxiliary display area 160 includes the display 530 reminding the operator that the call is of this type, and displaying the data fields required, comprising the day of the call field 531, the call time field 532 and the fields for the calling and called numbers 533 and 534 respectively.

Where the operator is requested to book a future call at a predetermined time, a call booking display 600 is displayed in the auxiliary display area 160, as a reminder that the call is of this type, and including fields for the day (601) and time (602) of the call to be booked. As before, these fields have corresponding data fields in the call data table 400, and the data displayed in the display fields matches the data held in the data fields .

Data is entered into the data fields in the call model 400 corresponding to these display fields in the manner described above. The auxiliary display area 160 thus contained a display of those fields for which data entry is required for the type of call concerned, together with a reminder of the type of call.

Menu Display

Referring to Figures 22a and 22b, one other type of display generated within the auxiliary display area 160 is a menu display 300, 301 displaying successive valid possible data items and allowing a user to select a desired item by moving the cursor 170. Once the desired data has been selected, the menu display 300, 301 is removed from the auxiliary display area 160.

Detailed Description of Keyboard

Referring to Figure 24, a brief description of the effects of the keys on the keyboard 8 not previously described will now be given.

BASIC DATA ENTRY KEYS

ENTER Key 790

When the cursor is positioned within a display field, pressing the enter key causes the value in the field to be accepted as a data record. QUERTY S NUMERIC KEYS 700, 710 Information can be entered in fields by using the

QWERTY keys 700 and the numeric keypad 710 on the right hand side of the keyboard 8.

BACKSPACE KEY 792

Individual characters in fields can be deleted by using the Backspace (<) key 792.

Whole contents of fields of information can be deleted by pressing the shift 791 and backspace 792 keys simultaneously.

INSERT KEY 793

The INS key inserts characters into a field at the current cursor position.

CANCL KEY 794 Deletes the entire contents of a field.

Up Cursor Key 7201

Moves the cursor 170 up the screen within a menu window 300 or 301.

Down Cursor Key 7202

Moves the cursor 170 down the screen within a menu window 300 or 301.

Page Down/Left Cursor Key 7203

Pages down through menu information, when a menu window 300, 301 is displayed, or moves the cursor 170 left through the contents of a field when the cursor 170 is positioned within a display field. Page Up/Right Cursor Key 7204

Pages up through menu information, when a menu window is displayed, or moves the cursor 170 right through the contents of a field when the cursor 170 is positioned within a display field.

MODE SELECTION KEYS

Transfer Charge Key 7501 Pressing the XFC (transfer charge, or collect) key 7501 causes the Transfer Charge display window 600 (shown in Figure) to be displayed showing the called number.

Credit Card Key 7502

Pressing the CRC (credit card call) key 7502 generates a Credit Charge display in a display area 160. A flashing cursor 170 is displayed to the right of the CRC display field at which the credit card number may be entered. Pressing the ENTER key 790 instructs the OS computer 100 to check the validity of the card number by sending the number and an instruction message. If the number is accepted the message "VALID" is transmitted back and appears in the display field and connection can proceed. If the number is not accepted the message "INVALID" appears.

Freefone Call Key 7503

Pressing the FRF (Freefone) key causes a Freefone display area to be generated. A flashing cursor 170 is positioned to the right of the FRF display field.

Entering the Freefone code data followed by the ENTER key 790 causes a Freefone number selection menu to be generated. The desired number is selected in the usual fashion and transferred to the called party number field 403. Advise Cost Key 7504

Pressing the ADC (Advise Duration and Cost) key 7504 causes the call data record of a just-completed call to be re-displayed (see Figure 23a), with the cost and duration fields 522 and 523 filled in. The advised number displayed is usually the caller except (as shown) when the called number is entered in the for a transfer charge call advised field 521.

Alarm Call Key 7505

Pressing the ALM (alarm) key causes an Alarm Call display 600 to be displayed in the display area 160 as shown in Figure 23b. A cursor 170 flashing to the right of the Day field 601 prompts for entry of the day for the alarm call. The cursor then flashes to the right of the Time field 602, prompting the entry of the time at which the alarm call is to occur. If further changes to these fields are required the DAY and TIME keys 7604,7405 can be used (see below). Pressing the BOOK CALL key 7552 when ALM is selected causes the call to be booked by the exchange equipment 1.

Personal Call Key 7506 Pressing the PER (personal call by operator) key 7506 causes a Personal Call indication to be displayed, and the operator is prompted to enter the call details at the Notes 210 field by the cursor 170 flashing to the right thereof. Third Party Pays Call Key 7507

When the TPP (third party pays) key 7507 is pressed a similar procedure is followed to that for transfer charge calls (see key 7501 above) but the operator must enter the identity of the paying party in the displayed field.

Fixed Time Call Key 7508

Pressing the FXT (fixed time call) key displays the call booking window of Figure 23b, and data is entered as with the Alarm Call key 7505 above.

Service Call Key 7509

A SVC (service call) indication is displayed. The operator is prompted to use the Notes field 210 to enter the call details by positioning the cursor 170 thereat.

Other Services Key 7510 Pressing the OTHER key 7510 causes the presentation of a menu containing information on less frequently used services allowing the operator to select such a service.

Call File Key 7551

Pressing the CALL FILE key 7551 causes VDU 7 to display a Call File display area 800 within the auxiliary area 160 consisting of Day and Time fields, and From and To call number fields 801-804. When completed, these data fields may be used to instruct the exchange equipment 1 to search the booked call files held by the OS computer 100. A group of keys 770 (see below) on the keyboard 8 enable booked calls stored in the OS computer 100 to be accessed and altered or deleted as discussed above, and are only operational after the key 7551 has been pressed. Book Call Key 7552

If the Alarm of Fixed Time Call keys 7505 or 7508 have been selected when the BOOK CALL key 7552 is pressed the call time details in the fields 601 and 602 and the calling number in the field 405 are supplied to the OS computer 100, which is instructed to book required call. Otherwise, a Book Call window 600 is displayed with Day and Time fields 601, 602 to be completed (see Figure 23b).

DATA ENTRY ASSIST KEYS

Call Class Key 7601

Pressing this key sequentially displays the next of) the following sequence of valid call class data field values the CLASS field 209, for example:

1. Assist - Operator assisted connection call

2. Emerg - Emergency call 3. DQ - Directory Enquiry

The default value (offered first) is Assist, indicating an operator assisted call.

TARIFF Key 7602

Alternates the single data character of the Tariff field 408 between "low" and "normal" (L,N) .

Customer Terminal Type Key 7603 Successive operations of the (CCB) key 7603 causes the caller Terminal Type field 401 (and displayed graphically in type field 201 to cycle through the following sequence: 1. Ordinary (ORD)

2. Pre-payment payphone (PPP)

3. Pay-on-answer payphone (CCB)

4. Other (NEQ or NULL entry)

Selecting PPP or CCB brings up the Coin Box (CB) display window 500 as shown in Figure 21.

DAY Key 7604 This positions the cursor in the Day field 601 of the Book Call, Alarm or Fixed Time Call display 600.

TIME Key 7605

As above, this positions the cursor in the Time field 602 and of the display 600.

COIN Entry Key 7651

This position the cursor in the Coins field within the

CB (coinbox) display 500.

Calculate Cost Key 7653

Pressing this key causes the CPU 10 to calculate the cost of a call based on its duration and charge rate, and display the result in the refund field 502 in the CB window 500.

Monitor Selection Key 7301

Successively sets the state of the monitor 3 between:

1. Both (operator is in two way communication with both parties). This is the default.

2. Mute (operator can hear both parties but cannot be heard) . 3. From (operator is in contact with calling customer - the called party is held) .

4. To (operator is in contact with called party - the calling party is held).

The state is also graphically illustrated on the screen in the display field 204.

Call FROM Entry Key 7302

Positions the cursor 170 in the Calling Party field 205 ready for input of the calling party number.

Call TO Entry 7303 Positions the cursor 170 in the Called Party field 211 ready for input of the called party number.

NOTES Entry Key 7606

Positions the cursor in the Notes field 201 to allow the operator to enter notes on the call.

COMMAND Entry Key 781

Allows a command to be typed in using alphabetic keys, and sent to the exchange equipment 1.

EXECUTION KEYS

Call Connection Keys

>FROM Key 7311

Connects the operator monitor 3 with the calling party number. The connection is graphically illustrated on the screen by the display field 204. >TO Key 7312

Connects the operator monitor 3 with the called party. The connection is graphically illustrated on the screen by the display field 204.

FROM>TO Key 7313

Connects the calling and called customers. The connection is graphically illustrated on the screen by the display field 204.

Record Amending Keys

Booked Call File Search Key 7701

This instructs the OS computer 100 to search its stored suspended call file for the details entered in the Book File display, and changes the displayed call fields to reflect the retrieved call details.

Completed Call File Search Key 7702 This instructs the OS computer 100 to search its completed call file for the details entered in the Book File field, and changes the displayed call fields to reflect the retrieved call details.

Activate Booked Call Key 7703

This instructs the OS computer 100 to activate its file of future calls (suspended call file), and causes the currently displayed call to be made immediately.

Copy Call Details Key 7704

This copies the details from a call held in the suspended call file at the OS computer 100 into the currently displayed call data fields in the call table 400. Delete Call Key 7705

This instructs the OS computer 100 to delete a retrieved call from the call file.

Operator Control Keys

Requeue Key 7801

Instructs the OS computer 100 and exchange 101 to requeue the current call to another operator.

Make Ineffective Key 7802

Instruct the OS computer 100 and exchange 101 to make the current call ineffective.

System Time Key 7803

Starts and stops a clock to measure call chargeable duration. This is indicated on the display 7.

Relinquish Key 7804 Used to disassociate the call from the console and to instruct the OS computer 100 and exchange 101 to continue it as a normal network controlled call. The operator monitor 3 connection to the call is broken, the call details are erased from the VDU 7 display and the console is put into the "Not Ready" state.

System Ready Key 7805

Switches the terminal between Ready (will accept calls from the exchange 101) and Not Ready (will not do so) modes. Call Transfer Key 720

Transfers the current call. The operator 13 prompted for a destination, e.g. another operator.

Select Call 1, 2, 3 Keys 7401', 7402,^" 7403

Changes Screen to select between the calls 1, 2 and 3 respectively. The state of hidden calls are shown in areas 206a, 206b, 206c at the top of the main window. The currently-displayed call in the main display area 170 is that affected by operator actions.

Coinslot Open Key (C&FC) 7652

Pressing this key instructs the exchange 101 to open the coinslots on pay-on-answer pay-phones.

PARTICULAR TRANSACTION TYPES

By way of example, some particular types of the transaction are as follows:

Simple Operator Assisted Call

As discussed above with reference to Figure 8, the operator speaks to the caller, types the called and calling party telephone numbers into data fields 403 and 405, instructs the connection of the call and relinquishes the call. The display state is generally as indicated in Figure 20.

Payphone Call Handling a payphone call requires the operator to monitor the coins which have been deposited and the progressive cost of the call; to instruct the payphone to open its coin slots to receive coins when necessary; and to calculate, at the end of the call, any refund due. Data fields for the coins deposited, the cost of the call, the call duration and the remainder due are therefore provided within the call data model 400. Referring to Figure 21, in processing a payphone call, the calling equipment type field 201 displays a graphical representation of a payphone, and the tariff field 208 is set to indicate a zero tariff, because, since the call is paid for with coins no subscriber charge is recorded for later payment.

Within the auxiliary display area 160, a call mode display area or window 500 is displayed which contains, for a call box call, the following fields:

If the exchange 101 indicated that the call originates from a payphone the coinbox display 500 will automatically be displayed.

Referring to Figure 21, the amount in the COINS field 501 is shown as two pounds digits separated by a dash from two pence digits. When the cursor is at this field, a digit typed in from the keyboard 8 will enter the right most place of the field 501. When the next digit, if any, is entered the first is shifted one place to the left. In this way, if a caller enters only 5p the operator need not type in three leading zeros. The date fields are generally in the form dd/mm/yy, and characters are entered from left to right, but as each "/" separator is reached the two digits just typed in are checked to see whether they lie within a valid range (e.g. 1-31 for the days, 1-12 for the months etc.). Entry in time fields is similar. Emergency Calls

In an emergency call, the operator is required to connect the customer to a local emergency service as quickly as possible. When the caller announces that he wishes to make an emergency call, the operator presses the emergency key 751, which sets the call class or type data field 409 to EMERG, and correspondingly displays this value in the call class display field 209. The call tariff data field 408 is set to N (indicating no tariff), and this also is correspondingly displayed in the tariff display field 208.

Referring to Figure 22a, a menu display 300 is generated within the auxiliary display area 160, listing the three emergency services together with corresponding telephone numbers. The cursor 170 is positioned at the uppermost entry in the menu.

The operator interrogates the caller via the monitor apparatus 3 to ascertain which emergency service he requires, and positions the cursor 170 at the appropriate menu entry using the cursor control keys 720. The operator then presses the ENTER button 790. The telephone number associated with the menu entry selected is written to the called party number data field 403 in the data table 400, and displayed in the corresponding display field 203 within the main display area 150. Connection of the call may then be instructed. Directory Assisted Calls

In other cases, the caller may have only partial information as to the telephone number of the called party. For example he may know the local number of the party but not the number of the exchange through which that party is dialled.

The CPU 10 is arranged, as discussed above, to perform an error checking operation upon data entered in the called party telephone number field 403. In the event that the data entered comprises an alphabetical character sequence, the CPU 10 is arranged to generate a destination number menu display 301 as shown in Figure 22b within the auxiliary display area 160, listing alphabetically exchange names similar to the alphabetic data entered, together with their corresponding exchange dialing codes. A complete list of such exchanges and corresponding codes is maintained in the store 11. The operator interrogates the caller as to the correct exchange, positions the cursor 170 at the desired menu entry using the cursor control keys 720 and presses the enter button 790 to select an entry. The exchange dialing code associated with the entry is then entered into the called party field 403 and displayed at the display field 203.

It will be recognised that the same principle could be employed to locate a called party number where the called party name is known, and that the data need not be held in the store 11 but could be read from a distant store via a communications link.

Many other ways of implementing the invention will be readily apparent to the skilled man from the foregoing; in particular, the invention is not in any way limited to any particular type of digital processing circuitry.

Claims

CLAIMS :

1. A transaction processing system comprising means arranged to accept data input by a system operator, means to accept instructions input by a system operator, and . means for causing the execution of a transaction, in response to such an instruction, utilising such data, the data comprising data representing a plurality of parameters, characterised in that the system is arranged to accept data in any parameter order.

2. A system according to claim 1, further comprising prompting means for prompting the operator to input data relating to a selected parameter, in which the user may validly input data relating to another parameter instead.

3. A system according to claim 1 or claim 2, in which, at any stage of operation, an operator may validly input either data or an instruction, and the system is arranged to validly accept either.

4. A system according to claim 3, arranged to execute a single operator entry process common to data and instructions within which process, if an instruction is specified, and the instruction requires data to be input by the operator for its execution, the process is re-executed.

5. A system according to claim 4, in which the process is re-executed recursively, the system being arranged to store an indication of the process stage from which the process was re-executed and, upon completion of data entry, to return to and resume the instruction entry process.

6. A system according to claim 5, in which, following the input by the operator of an instruction to execute a transaction, the system is arranged to execute, if necessary, a succession of such returns.

7. A system according to claim 6, which is arranged, upon instructing the execution of a transaction, to execute all such returns which are stored.

8. A system according to claim 6 or claim 7, in which, upon being unable to execute a transaction due to the unavailability of valid data for a parameter, the system is arranged to execute such returns as are necessary to return to a stage prompting the operator to input the unavailable data.

9. A transaction processing system comprising means arranged to accept data input by a system operator, means to accept instructions input by a system operator, and means for causing the execution of a transaction, in response to such an instruction, utilising such data, the data consisting of representing a plurality of parameters, further comprising display means for displaying data together with an indication of the parameter to which the data corresponds, characterised in that only a subset of the data and parameters are thus displayed.

10. A system according to claim 9, comprising means for determining, from an input instruction, which subset to display, the display means being responsive to the determining means .

11. A system according to any preceding claim, in which, when data relating to a given parameter is available to the system, the system is operable to instruct the execution of a transaction without requiring the input of that data by the operator.

12. A system according to any preceding claim comprising an operator terminal station, connectable via a data port to a data channel connected to means for effecting the transaction.

13. A system according to any preceding claim further comprising means for effecting the transaction.

14. A system according to any preceding claim, wherein the transaction is a telephone call connection transaction, and the parameters relate to telephone call data.

15. A telecommunications exchange comprising a system according to claim 14.

16. Telecommunications exchange control apparatus comprising means for displaying a graphical representation of a calling telecommunications device and of a called telecommunications device, characterised in that it further comprises means for graphically displaying the presence or absence of, and/or the state of, a connection between the called and calling devices.

17. Apparatus according to claim 16, further comprising means for displaying a graphical representation of the connection, if any, between one of the devices and the operator.

18. A system according to either one of claims 16 or 17 in which the connection is graphically represented by a line extending between the connected devices.

19. Exchange apparatus comprising means for displaying a graphical representation of a called or calling telecommunications device, characterised in that the graphical representation is variable in dependence upon the nature or type of the device.

20. Apparatus according to claim 19, arranged to sense the device type and automatically to display a corresponding graphical representation.

21. Apparatus according to claim 19 or claim 20, responsive to an operator input to specify the device type.

22. A transaction processing system including a keyboard comprising a plurality of keys, operable to affect data stored in the system, in which different keys affect data in different manners, characterised in that keys are grouped by the manner in which they affect data.

23. A transaction processing system comprising means arranged to accept data input by a system operator, means to accept instructions input by a system operator, and means for transmitting said data and instructions to execution means for executing the instructions, characterised in that the data input means is arranged to accept a plurality of different parameter data prior to the transmission of any said data.

24. A system according to claim 23 in which the said data is transmitted only upon acceptance of a user instruction.

25. An intelligent terminal to provide an interface between a computer and a human operator, comprising a processor, a display and a data entry device, arranged for allowing the operator to input data offline, and for reformatting the data for supply to the computer.