Enhanced dedicated teleconferencing system

The invention claimed is:

1. A method for operating a teleconferencing system, the system having a bridge with a plurality of ports, each for communication with a party and control means responsive to a plurality of commands and a plurality of information responses for each command, said plurality of information responses including a first group and a second group, the control means responding to reformatted information responses of the second group of information responses, the bridge being controlled to execute function according to the commands and in response to inputting of information responses into the control means, the method comprising:

connecting a service computer to the control means for issuing commands thereto for causing the bridge to execute functions corresponding to the commands;

storing in the service computer, the first group of information responses;

inputting into the service computer the second group of information responses;

issuing a selected command from the service computer to the control means for initiating a function corresponding to the selected command;

reformatting at least some of the second group of information responses; and

supplying the first, any unreformatted second and the reformatted second groups of information responses to the control means for completing the function corresponding to the selected command, from the service computer.

2. A method according to claim 1, including connecting at least one first user terminal to the service computer and inputting the second group of information responses to the service computer from the first user terminal.

3. A method according to claim 2, including issuing commands and, the first, the unreformatted second and the reformatted second groups of information responses to the control means from the service computer to establish communication with the bridge to a plurality of parties.

4. A method according to claim 3, including at least some of said plurality of parties having additional terminals, and connecting said additional terminals to the service computer for establishing a path for digital display information between the terminals of said parties having terminals.

5. A method according to claim 4, including passing a note of text comprising digital display information from one of said party terminals to said service computer, storing the note in said service computer and transmitting the note from said service computer to at least one other of said party terminals.

6. A method according to claim 1, including storing a plurality of directories in said service computer, each directory containing information for a plurality of parties, the information for each party comprising a plurality of second group information responses for that party.

7. A method according to claim 6, including identifying each directory with a selected user for permitting selection of parties from at least one directory afer use by the selected user.

8. A method according to claim 7, including listing actual parties' names in the directory with actual telephone numbers for those parties, the party names comprising some of the second group of information responses, the reformatting comprising selecting unique pseudonyms for each actual party name, the pseudonym being unique for the same party name if used in more than one directory for maintaining unique pseudonyms and telephone number combinations for use in operating the control means of the teleconferencing system.

9. A method according to claim 2, including transmitting a status screen from said service computer to said first user terminal, said status screen including a menu showing a plurality of commands, each selectable by the user of the first user terminals, and a listing of parties for a selected conference, including all the second group information responses for each party shown.

10. A method according to claim 2, including transmitting a status screen from said service computer including all the second group of information responses for each party to the first user terminal.

11. A method according to claim 9, including listing said parties on said status screen according to a numerically ordered list of leg numbers, each party having a constant leg number during the operation of a selected conference.

12. A method according to claim 6, including issuing commands and, the first, the unreformatted second and the reformatted second groups of information responses to the control means from the service computer to establish communications with the bridge to a plurality of parties, said parties being all the parties in a selected directory.

13. A method according to claim 3, including storing in the service computer, billing information for the conference and, at the conclusion of the conference, transmitting a billing screen from said service computer to said first user terminal, said billing screen, including a listing of all billing charges for the conference.

14. A method according to claim 9, including indicating on the status screen that an operator is accessing the communications among said parties.

15. A method according to claim 4, including indication that an operator is accessing the communications among said parties, on said first and additional terminals.

16. A method according to claim 1, wherein the names of parties for communication comprise at least some of the second group of information responses, the names being reformatted to ensure that said party names are not duplicated when applied to the control means as the reformatted second group of informaton responses.

17. A method according to claim 1, including operating a plurality of said teleconferencing systems, connecting the service computer to the control means of all said teleconferencing systems.

18. A method according to claim 2, including operating a plurality of said teleconferencing systems, connecting the service computer to the control means of all said teleconferencing systems, and selecting one of said teleconferencing systems using the first user terminal.

19. A method according to claim 1, including detecting when a party is no longer in communication with the bridge and issuing commands and, the first, the unreformatted second and the reformatted second groups of information responses to the control means from the service computer to re-establish communication with the bridge to a party that is no longer in communication with the bridge.

20. A method according to claim 1, including identifying a party who initiates communication with the bridge.

21. A method according to claim 1, including issuing commands and, the first, the unreformatted second and the reformatted second groups of information responses at a specified time and date to the control means from the service computer to establish communication with the bridge to a plurality of parties.

22. A method according to claim 1, including reserving in the service computer a first conference having a conference name forming one of the first group of information responses, and a name of a second conference to be combined with the first conference, issuing commands from the service computer to the control means to store the first and second conference in the control means and at an initial time when both conferences have started, automatically combining the first and second conferences together.

23. A method according to claim 1, including detecting that only one party of a plurality of parties in communication with the bridge remains in communicaton with the bridge, and issuing commands, and the first, the unreformatted second and the reformatted second groups of information responses to the control means from the service computer to disconnect the one party from communication with the bridge.

24. A method according to claim 9, wherein said status screen has a plurality of pages, the method including indicating that status information for parties not shown on the status screen has changed on another page, and indicating the page in which the information has changed.

25. A method according to claim 4, including sending an indication from said additional terminals to at least one of the first user terminals and the service computer, said indication being a request for attention.

26. A method according to claim 17, including connecting a first user terminal to the service computer and inputting the second group of information responses to the service computer from the first user terminal, and estimating the total cost of using each of the bridges connected to said service computer to establish communication with a plurality of parties prior to an establishment of communcation, and transmitting said estimates of the total cost to said first user terminal.

27. A method according to claim 22, including issuing commands and, the first, the unreformatted second and the reformatted second groups of information responses to the control means from the service computer to establish communication with the bridge to a plurality of parties, including the party that initiated communication with the bridge.

28. A method according ro claim 22, including starting the first conference, combining the second conference into the first conference at the initial time after both conferences have been started, the second conference including at least one conferee having a conference access code to be input into the service computer, automatically combining a conferee into the combined first and second conferences when the conferee enters its access code after the initial combining of the first and second conferences.

29. A method according to claim 2, wherein the first user terminal has a keyboard for sending indications to the service computer, the method including sending an indication from the keyboard of the first user terminal to the service computer, requesting an operator assistance from the service computer without interrupting any connection between any party and the ports of the bridge.

30. A method according to claim 6, including connecting a first user terminal to the service computer and inputting the second group of information responses to the service computer from the first user terminal, transmitting a status screen from the service computer to the first user terminal, the status screen including the display of information for at least one party of a directory, sending an indication from the first user terminal to the service computer, requesting the service computer to connect the party having the displayed information with a port of the bridge or requesting the service computer to display information concerning a subsequent party in the directory on the status screen.

31. A method according to claim 1, wherein the plurality of ports of the bridge are divided into segments each for receiving one type of telecommunication service, estimating the cost for a conference using a selected combination of segments and selecting the least expensive combination of segments for conducting the conference.

32. An apparatus for operating a teleconferencing system, the teleconferencing system having a bridge with a plurality of ports, each for communication with a party, and control means responsive to a plurality of commands and a plurality of information responses for each command to execute functions of the bridge in establishing and disconnecting communication with the parties, the plurality of information responses including a first group and a second group of information responses, the apparatus, comprising:

a service computer connectable to the control means for issuing commands and for issuing first and second group information responses for causing the bridge to execute functions corresponding to each command; and

a plurality of party terminals, each connectable to said service computer for receiving a display screen from said service computer concerning a conference, and for issuing commands, the second group information responses to said control means to conduct a conference.

33. An apparatus according to claim 32, wherein said service computer is programmed to store the first group of information responses and to receive the second group of information responses from one of said terminals, said service computer being programmed to issue a command to the control means of a bridge and to thereafter supply the first group of information responses and a reformatted version of at least some of the second group of information responses required for executing the function of the bridge corresponding to said command.

34. An apparatus according to claim 32, wherein said service computer is programmed to store a plurality of directories, each containing information for a plurality of parties, the information for each party including second group information responses usable by said service computer, in conjunction with first group information responses to operate the control means and bridge.

35. An apparatus according to claim 33, wherein each directory is identified to a selected user for use in conducting a plurality of conferences.

36. An apparatus according to claim 32, wherein said service computer is programmed to store data sent by one of said party terminals for dissemination to at least one other party terminal, and for sending said data to said at least one other party terminal.

37. A method of operating a plurality of teleconferencing bridges, each bridge having a plurality of ports for communication with a plurality of parties and control means responsive to a plurality of commands, and a plurality of information responses for each command, each bridge being controlled to execute functions according to the commands and in response to inputs of information responses into the control means, the method comprising:

connecting a single service computer to the control means of at least one of the bridges at a time, for issuing commands to the at least one for causing the at least one bridge to execute functions corresponding to the commands, the computer being connectable to the control means of each of the bridges;

storing at least some of the plurality of information responses in the service computer which can be utilized for the commands in each of the bridges;

sending a selected command from the service computer to the control means of at least one of the bridges to initiate a function corresponding to the selected command in the at least one bridge; and

supplying the information responses for the selected command from the service computer to the control means of the at least one bridge.

Description Submit all comments and votes

FIELD AND BACKGROUND OF THE INVENTION

The present invention relates in general to telephone conferencing techniques, and in particular, to a new and useful method and apparatus of operating a dedicated teleconferencing system to conduct a telephone conference among a plurality of conferees. A teleconferencing service known as the ALLIANCE Dedicated Teleconferencing Service is available from AT&T. ALLIANCE is a trademark of AT&T.

The present invention is best understood by having a knowledge of the characteristics and limitations of the ALLIANCE system.

The words "his" and "him" should be interpreted to include both male and female genders throughout this application.

The ALLIANCE System Configuration

The ALLIANCE system, which is shown at FIG. 1, utilizes a microprocessor controlled device called a bridge 1, which has up to fifty-six ports 2, which can simultaneously connect up to fifty-six telephone lines 3, into a single teleconference, twenty-eight two-party teleconferences, or any number of teleconferences between one and twenty-eight which do not exceed the bridge's fifty-six-port capacity. In order to access lines, the bridge ports are directly connected to a so-called 4ESS toll switch 4, which is a part of the AT&T telephone network. The fifty-six ports are divided into seven groups of eight ports each, shown at 5. A different type of telephone service may be subscribed to by each group. For example, one group may have so-called band 4 WATS service, three groups band 2 WATS service, and all remaining groups regular MTS service. Groups of ports which have the same type of telephone service are known as segments. In the example above, there would be three segments called "1", "2", and "3".

A teleconference can be reserved, initiated ("set-up"), monitored and controlled by an attendant using a terminal or personal computer (PC) using software which allows the PC to emulate a terminal 6. Communication between the attendant terminal and the microprocessor of the bridge is established over a dedicated private data line 7. Modems 8 are used to convert the digital signals of the bridge and attendant terminals to analog signals so that these signals may traverse the private data line. The bridge can be controlled by up to three attendant terminals.

The bridge also has a provision which allows up to three attendants to place themselves on the audio portion of any active conference. There are two methods by which audio communication between the attendant and the bridge can be established. A dedicated private voice line 9 may be attached to one of the bridge's three dedicated attendant audio ports P. The second method allows the attendant to specify that he be dialed back on a public voice line L, which requires the use of an available bridge port 2.

Some of the most important characteristics of the ALLIANCE system configuraton vis-a-vis the present invention is that it is a dedicated system. That is:

(a) The means of control (attendant terminals) are dedicated to a single bridge;

(b) Any single bridge may only communicate with a maximum of three attendant terminals; and

(c) The attendant terminals' location is fixed by the need to use private data lines for his communication with a bridge.

The ALLIANCE System Commands and Displays

Once a communication link between an attendant terminal and the bridge's microprocessor is established, the bridge can be controlled using specific commands sent by the terminal. The bridge microprocessor sends to the terminal three types of data:

1. Prompts requesting particular types of data to be entered by the attendant depending on the situation;

2. Display characters and control characters (Control characters are recognized by the terminal, but not displayed. They control the format of the display characters and other non-displayed functions of the terminal, such as emitting "beep" tones); and

3. Status messages which appear briefly on the twenty-fourth line of the terminal display. Status messages are generated by the bridge every time a change in a conference's or conferee's status changes. For example, the start and end of a conference, conferee on conference, with port number indicated or dropped from a conference, etc.

In practice, the attendant first enters a carriage return which causes the bridge to return the prompt "COMMAND:" in order to request a command. At this prompt, the attendant must type in the first command. If, at this time, or any other time, the "COMMAND:" prompt appears, the attendant enters the letter "H" for HELP, a summary of the ALLIANCE commands is displayed (see Table 1).

TABLE 1 __________________________________________________________________________ ADMINISTRATIVE COMMANDS ATTENDANT dial back/dedicated line need MAINTENANCE line is available DATE and TIME STATUS COMMANDS ACTIVE conference attendant requested QUEUE MONITOR conference STATUS reports RESERVATION COMMANDS ADLIB conference MEETME conference DIRECTORY PRESET conference daily LOG SCHEDULE CONFERENCE COMMANDS BLASTUP a conference LISTEN to ports on a conference CALL a number change MODE of a conf/conferee COMBINE two conferences OFF conference DIVIDE into sub-conferences ON a port/conference DROP a port/conference SETUP conference JOIN sub-conference change-SUB-conf. assignment __________________________________________________________________________

COMMAND:

The commands are divided into four categories (as shown in Table 1):

Administrative Commands; Status Commands; Reservation Commands and Conferencing Commands. It is noted that each command can be abbreviated by a unique one, two or three letter string of characters, such as "AT" for ATTENDANT, or "MA" for MAINTENANCE. "MON" is necessary for MONITOR since "MO" is also the first two letters of the MODE command.

The first category is Administrative Commands such as "ATTENDANT" or AT, which gives the attendant his voice/path status. This indicates to the attendant whether the attendant is on a dedicated or dial-back voice path. Another administrative command is MAINTENANCE of MA, which marks a port or group of ports for maintenance. This may be required if one or more ports must be taken out of service, for maintenance. "AVAILABLE" is used to make a port(s) available for use, once maintenance has been completed. "DATE" and "TIME" are used for setting the date and time of the bridge's microprocessor clock/calendar function.

The second group of commands known as Status Commands, return information to the attendant's terminal concerning a conference in progress or the condition of the bridge at any particular time. The most relevant status command to the present invention is the "MONITOR" command. This command allows the attendant to monitor the status of a single specified active conference. The MONITOR command is discussed in detail later on in this section.

Another status command is "ACTIVE" or "AC", which, when typed by the attendant, allows the attendant to see what conferences are currently in progress on the bridge. The information returned to the attendant in response to the "AC" command, includes the type of conference (which will be explained later), the name of the conference, the date therefore, starting and finishing times for the conference, the number of ports being used by the conference (i.e. the maximum number of conferees involved), a code used for one type of conference (the Meetme conference) and whether the Meetme conference is of the assisted or un-assisted type. Other status commands are "QUEUE" or "Q" which displays the ports that have requested attendant assistance, "STATUS" or "ST", which displays the last one hundred status messages that the attendant has received, and "PORT" or "PO", which displays the current status of each port as either in-use, available, or out-of-service for maintenance.

The third group of commands are the Reservation Commands. The Reservation Commands are used to create and maintain a conferee directory, to establish different types of conferences, and to add, change, delete and list conference and directory entries. The "LOG" and "SCHEDULE" commands are for printing lists of which ports and conferences respectively, are reserved for a specified time period.

The "INIT" command erases all conference reservations and conferee directory entries from the microprocessor of the bridge. "INIT" is not displayed on the Help display (Table 1).

As described earlier, the microprocessor of the bridge provides for a single conferee directory with a capacity of up to fifteen hundred unique conferee entries. Using the "DIRECTORY" or "DIR" command, an attendant can add, delete, list and erase directory entries. Each directory entry contains the first name, last name, primary phone number, secondary phone number and segment type for each of the primary and secondary phone numbers.

If the directory is to be manipulated, the attendant types "DI" after the "COMMAND:" prompt. This generates a menu of options (add, change, etc.):

The menu is reproduced below as "MENU 1": ##STR1##

At the prompt "OPTION", the attendant types a single letter to request a sub command. The letter "A" for "ADD", for example.

This causes the ALLIANCE bridge micoprocessor to return a second menu labeled "MENU 2" below: ##STR2##

Each time the operator presses the RETURN or ENTER key on the keyboard of his terminal, the cursor, beginning at "Last Name", advances to the next column corresponding to one of the six fields. At each field, the attendant must enter the appropriate information which is here referred to as variable information reponses.

It should be noted that the next available directory number is assigned by the bridge microprocessor to each newly added conferee. Ths storage of conferee data is common for all conferences and is not subdivided in any way. Multiple directory entries for the same conferee name are not permitted. The only way then to have more than one phone number for a conferee is to specify a secondary phone number in row "S:". However, in order to use this secondary number, it must be manually chosen for each conferee during conference set-up, using a more labor-intensive series of commands than normal. Because the secondary number cannot be chosen for use prior to the conference being set-up, using a secondary number requires the ALLIANCE conference set-up procedure to take a longer amount of time.

Four types of conferences can be conducted using the ALLIANCE bridge: Preset; Meetme; Adlib; and Demand. Preset, Meetme and Adlib conferences require a conference reservation to be made in advance of the conference. The "PRESET", "MEETME", or ADLIB" reservation commands respectively, are used for this purpose.

To operate a Reservation Command, the attendant first types the appropriate command such as "PRE" for a Preset conference entry. The attendant must then, by using another group of sub-commands, such as "ADD", "CHANGE", or "DELETE" indicate to the bridge what will be done with regard to a Preset conference entry. The selected sub-command then returns a prompt to the attendant to begin entry of the specific information for that Preset conference, such as conference name, date, start time, finish time, and number of ports. This information is all constant for a specific conference and thus can be thought of as a plurality of constant information responses. The conference type is also a constant for a specific conference. The conference type is automatically entered ("ADD" sub-command) or looked up ("CHANGE, "DELETE") by the microprocessor based on the reservation command chosen.

The differences between the four types of conferences are as follows:

A Preset conference requires that the attendant pre-select the conferees who are to be members of the conference from the directory. The conference size (number of ports) is automatically calculated by the bridge's microprocessor based on how many conferees were selected from the directory. When a Preset conference is set-up (initiated), the attendant has the option of starting the conference right away or of changing any conference or conferee data. The Preset conference can be started in one of two ways:

(a) All conferees can be simultaneously dialed out to by the bridge ("BLASTUP" sub-command); or

(b) Conferees can be dialed one-at-a-time by the bridge and connected to the attendant's voice path when they answer. After establishing contact with the conferee, the attendant can add this conferee to the others in the conference ("ATTENDANT" sub-command). The Attendant assisted method only allows conferees to be added in the order in which they are pre-selected. A conferee can be dialed again if busy or if they do not answer using the "REDIAL" option. However, the REDIAl option cannot be performed once the attendant leaves the ASSISTED-SET UP mode.

A Meetme conference reservation requires the attendant to specify the size of the conference and a four-digit code number. In this type of conference, the conferees dial into (i.e., "MEETME") the conference bridge and enter the specified four-digit touch tone code when prompted by a synthesized voice recording which the bridge generates. The touch tone code is used to instruct the bridge as to which conference this heretofore unidentified caller is to be connected. Since all conferees use the same code to dial into a given conference, there is no way to identify which individual conferees were routed into which ports. This is why, in a Meetme conference, no conferees are pre-selected from the directory. Furthermore, no conferee names appear when monitoring the Meetme conference's status ("MONITOR" command discussed later).

An Adlib conference is essentially the same as a Preset, except the conferees are not chosen until the conference is set up:

(a) The conference size (number of ports) must be manually specified when the conference is reserved; and

(b) The conferees are selected when the conference is set-up, either from the directory or by the attendant manually entering the conferee data for conferees who are not in the directory.

A Demand conference is a conference that does not have a pre-existing reservation. Demand conferences are reserved and started while performing the SETUP conferencing command. A Demand conference is an Adlib conference which uses the current date and time (supplied by the bridge's microprocessor) for its date and start-time.

If the blast-up method of starting a Preset, Adlib or Demand conference is chosen, the MONITOR command for that conference is automatically executed by the bridge.

A conference is said to start (become active) the first time any one of its conferees' status becomes "ON CONF" (ON CONFERENCE). In the case of a blast-up type conference, the first conferee to answer his phone causes his status to change from "RINGING" to "ON CONF". For a meetme type conference, the first conferee to enter his touchtone code becomes "ON CONF". A conference ends when all of the conferees' status becomes "DROPPED". It should be noted that a meetme conference reservation remains valid for the duration of its reserved time period since meetme conferees may dial in and hang up repeatedly during the course of the conference. Therefore, a meetme conference may alternate between being active and inactive. On the other hand, a blastup type conference reservation ends the first time the preset, adlib or demand, conference becomes inactive.

An actual conference is conducted by an attendant using the Conferencing Commands. Conferencing Commands allow the attendant to "SETUP" (initiate) a conference; "LISTEN" to the ports on a conference; talk and listen "ON" a port or a conference; remove themself from being on a port or conference ("OFF"); change the transmission "MODE" of a conferee/conference between talk and listen, and listen-only modes; change the "SUB"-conference designation for conferees on a conference; "DIVIDE" a conference into its designated sub-conferences; "JOIN" the sub-conferences back into one conference or "DROP" (hangup) a port or conference.

A useful conferencing command besides those mentioned above is called "COMBINE". The COMBINE command is used to combine two or more active conferences into one conference. For purposes of discussion, a "combinee" conference is said to be combined into a "combinor" conference. The COMBINE command's most useful function is to combine a meetme-type conference(s) with a blastup-type conference(s). This allows the user to have a conference where some of the conferees dial into the bridge (meetme) while others are dialed-out to by the bridge (blastup). In practice, however, the COMBINE command has four shortcomings:

1. The combinor and combinee conferences must be active before the COMBINE command can be performed;

2. The COMBINE command must be performed manually by the attendant;

3. In the case of a meetme-type combinee conference, meetme conferees who dial into the bridge after the COMBINE has been executed are not added to the combinor conference. Instead, they become members of a separate conference under the old combinee conference reservation. And, should this reservation expire before these "latecomers" dial into the bridge, conferees will not be able to gain access to any conference; and

4. In the case of a blastup-type combinee conference, blastup conferees who have not been blasted up or who have not been put on conference (i.e., status=RINGING, BUSY, No ANSW), before the COMBINE has been executed cannot be blasted up or called later by the combinee conference. The reason for this is that once a blastup-type combinee conference is combined into a combinor conference, the combinee conference and its associated list of conferees cease to exist in the ALLIANCE microprocessor's reservation system.

These shortcomings cause a catch-22 situation in the case of a COMBINE involving meetme and blastup-type conferees: If the blastup conferees are in the combinor conference, then "late-comer" meetme conferees cannot be automatically added to the combinor conference. If the meetme conferees are in the combinor conference, then all blastup conferees must be present before the combine can be executed. Otherwise, those blastup conferees who were not on conference prior to the combine must be manually added one-at-a-time by the attendant to the combinor conference, using the CALL or BLASTUP command. Therefore, to add "latecomer" conferees in either case requires continued attendant monitoring and command executions.

Another useful conferencing command is called "BLASTUP". The BLASTUP command is used to automatically add a new conferee to an active conference or to dial an reconnect a conferee who has been dropped from the conference either by accident or on purpose. When the party answers, the conferee is added to the specified active conference without operator assistance. If the party does not answer within a certain time period (30-40 seconds), the attempted call is stopped.

To operate the BLASTUP command, the operator first types "BL". With each carriage return (RETURN or ENTER key), the cursor on the attendant's terminal is advanced to the next field. The attendant must, in sequence, enter the constant information responses of conference name and conference type. Then the attendant enters the variable information responses of conferee last name, first name, phone number, segment and transmission mode. If the conference has any conferees with sub-conference designations, the attendant must also enter the sub-conference designations for the BLASTUP conferee.

The number of variable information responses and constant information responses are considerable. Note that the conferee and conference related information responses must be repeated for each conferee even if the conferee has been a prior member of the conference and even if the next command is a BLASTUP for the same conference. A similar volume of information must be input by the attendant to call a party directly through the bridge (using a "CALL" or "CA" command) for the purpose of assisting the party and manually adding the party to the conference. The REDIAL option is also available to the attendant while executing the CALL command.

Since many of the commands used to control the ALLIANCE bridge must be used in conjunction with a relatively large number of constant information responses and variable information responses, much demand is placed on the attendant. This is particularly true for the Conferencing Commands where the attendant must operate during an ongoing conference.

It is noted that each of the responses must be exact, or an error signal will be generated by the ALLIANCE bridge.

A comprehensive listing of the commands to which the ALLIANCE bridge can respond, as well as the error messages which the bridge generates in the event of an error, are listed in a glossary and list of error messages appearing on pages 130 through 136 of a manual of operation for the ALLIANCE bridge, dated November, 1986, entitled: ALLIANCE Dedicated Teleconferencing Service Attendant MANUAL. This manual is incorporated here by reference.

At any time during an active conference, the attendant may view the status of all conferees on the conference. To do this, the attendant selects the "MONITOR" or "MON" command. This prompts a request for the conference name which the attendant must type in. A request is then made for the conference type (adlib, preset or meetme) and the first letter of the conference type must be entered. At this point, a display is produced on the attendant's terminal as shown below at MENU 3, which indicates the port number under which each conferee is operating, the status of that conferee, the name of the conferee, the phone number of the conferee, the mode of operation (listen-only or two-way), and the sub-conference (if any).

__________________________________________________________________________ MENU 3 NEXT page QUIT monitor command CONFERENCE preset 1 PORT STATUS NAME PHONE NUMBER MODE SUB __________________________________________________________________________ 1 ON CONF john smith 4085559275 T 1 2 ON CONF bob williams 4155555839 T 2 3 ON CONF jim jones 2125559203 T 1 DROPPED dick robinson 3162764608 L 1 5 RINGING ruth thompson 3035247619 L 2 6 ON CONF alice abrams 9146834291 T 1 4 RINGING henry patterson 7184628804 T 2 7 RINGING lloyd simon 2038583204 T 1 8 RINGING dick robinson 3162764600 T 1 OPTION: __________________________________________________________________________

It is noted that in the ALLIANCE service, the port number of each conferee is indicated on the monitor menu. This port number may change, however, for a certain conferee if, for some reason, the conferee is disconnected and then is called again. When called back, the conferee is placed on the next available port in the specified segment and a new status line is generated at the bottom of the list. For example, on MENU 3 "dick robinson" was originally called on port 4, but dropped before "henry patterson" was called. Hence, "henry patterson" was called on port 4 and "dick robinson" was assigned to port 8, since ports 1-7 were in use prior to "dick robinson" being called back. Each page of the monitor menu can display only thirteen (13) status lines. The order of listing of conferees thus may change over the course of the conference. This makes it very difficult for the attendant to follow attendance of the conference, particularly when the status lines fill more than one menu page.

It can be appreciated from the foregoing that substantial effort and care is needed for an attendant to reserve, set up and control conferences and directory entries. The time required by even a skilled attendant to exercise such effort and care often make the use of the ALLIANCE system impractical, despite its theoretical capabilties.

Some of the most important characteritics of the ALLIANCE system microprocessor and commands vis-a-vis the present invention are as follows:

(1) The ALLIANCE microprocessor does not associate attendant terminals in a one-to-one relationship with active conferences. Since any attendant terminal may invoke any of the conferencing commands at any time on any active conference, a portion of all conferencing commands information responses must always identify the conference name and type of conference that the desired action is to apply to. This portion of the conferencing command has been referred to as a "constant information response" earlier.

(2) The single conferee directory has a limit of fifteen hundred names. Duplicate conferee names, even though they may have different phone numbers, are not permitted. All users also have access to all conferee data entries.

(3) The status of a conference cannot be monitored at the same time as any conferencing command is executed. The attendant must (a) write down any relative conference information from the monitor screen (i.e., conference name, type, conferee port number, name and phone number); (b) exit the monitor command and enter the conference command(s) menu; (c) exit the conference command and re-perform the monitor command to view the results of the conference command(s).

(4) In order for the attendant to add people to the conference in a sequential and controlled manner, the attendant must enter each conferee's name and phone number or directory number while the conference is taking place. To do this, the attendant must maintain a separate list with connferee names, telephone numbers, and/or directory numbers on it because this information is not available for display on the attendant terminal while executing the BLASTUP or CALL command.

SUMMARY OF THE INVENTION

A main object of the present invention is to enhance the operation of dedicated teleconferencing services in general, and the AT&T ALLIANCE service, in particular.

According to the present invention, a service computer is interposed between the user (known as the coordinator of a conference) and the dedicated teleconferencing bridge. The service computer maintains directory lists which are specific to named conferences and may include either within a single conference or across multiple conferences, multiple entries of a conferee name with one or more different telephone numbers for that name.

The service computer also stores all constant information responses that are necessary for a specific named conference and conferee of that conference as they are selected from a directory or called independently from outside the directory. In this way, only a minimum amount of information is needed from the coordinator or user. The coordinator need only provide the variable information responses which are specific to a desired function. For example, if a coordinator wishes to add a new conferee, the coordinator need type in only a single letter command, in this case, A for ADD, followed by the first name, last name, and telephone number of the conferee desired. These three fields of information are then stored in the service computer and used in conjunction with the BLASTUP command, conference type, mode, sub-confer