WO2001028213A1

WO2001028213A1 - Method and apparatus for multi-party telecommunications calls

Info

Publication number: WO2001028213A1
Application number: PCT/AU2000/001245
Authority: WO
Inventors: Alexander John Corbett; Trevor Longwood
Original assignee: Alexander John Corbett; Trevor Longwood
Priority date: 1999-10-14
Filing date: 2000-10-13
Publication date: 2001-04-19
Also published as: AUPQ343299A0

Abstract

A Method and Apparatus (100) for Multi-party telecommunications calls allows a plurality of callers (105) to call into the apparatus, and bid for the chance to communicate with a guest caller (110). The bids can have a monetary value. Callers who wish to talk to the guest are placed in a first queue, and a smaller number of these callers are then chosen from this first queue to be placed in a question queue. Callers in the question queue are then allocated a predetermined period in which to talk to the guest in a sequential manner. Callers are allocated to the question queue on the basis of a weighted, random, or partially random, process. The calls can be moderated.

Description

TITLE

Method and Apparatus for Multi-party Telecommunications Calls

FIELD OF THE INVENTION

This invention relates to method and apparatus for conducting multi-party communications calls in a telecommunications systems and more particularly to such apparatus, systems and methods that avoid contention between parties to a call by allocating talk slots to different parties on a pre-determined basis.

Throughout the specification, unless the context requires otherwise, the word "comprise" or variations such as "comprises" or "comprising", will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.

BACKGROUND ART

Multi-party communication calls, particularly on switched circuit telecommunications systems, suffer from contention problems between participants in the call when too many of these parties seek to speak at the same time.

Such contention may be resolved by priority being assigned to the party that speaks with the loudest volume or by other contention resolution schemes. Alternatively a moderator who selects the order in which parties to a call can speak may be used. With moderator arrangements, other parties listen to the call and have their speech signals filtered or blocked so as not to interfere with the party allocated permission to talk. Typically parties are assigned the right to talk on a "first come first served" basis.

However, where there are a large number of parties to the call, allocating the right to talk on a "first come first served" basis may not provide sufficient incentive for parties to remain listening to the call. This is because a party that joins the call at some point after it commences may have a long time to wait before they can speak.

US 5594948 describes a method for realizing a group call in a digital cellular radio network, in which parties to the call share transmission by allocating talk time on the basis of random allocation.

DISCLOSURE OF THE INVENTION

According to a first aspect of the present invention there is provided a method of operating communications apparatus adapted to provide multi-party conference calls between a plurality of communications channels; the method comprising the steps of receiving bid data from the channels and allocating those channels from which bid data is received to a second sub-set of channels, selecting a first subset of channels, from those in the second sub-set of channels, for the apparatus to receive communications signals from, the selection for the first sub-set being performed according to a predetermined process.

Preferably the method further comprises the step of allocating an order to the channels in the first sub-set and receiving communications signals from the channels according to the order.

Preferably, the predetermined process is a random or partially random process.

Preferably the random or partially random process for selecting channels for the first sub-set comprises a semi-random, pseudo-random or weighted random process.

Preferably, the bid data has a value component for determining relative values between the bids; and selecting the channels for the first sub-set of channels, from the second sub-set, in order of bid value.

Preferably, bids of equal value are assigned an order in the first sub-set according to a random or partially random process. Preferably the method further comprises the step of receiving communications signals from the channels in the first sub-set for a finite period of time and selecting a further set of a predetermined number of channels from the second set, for inclusion in the first sub-set subsequent to the finite period expiring. Preferably the channels are removed from the first sub-set of channels subsequent to the finite period of time expiring.

Preferably the further sub-set of channels are included in the first set of channels subsequent to the apparatus receiving further bid data from the plurality of channels.

Preferably the method further comprises the apparatus designating at least one channel of the plurality of channels as a guest channel; the channels in the first sub-set adapted to communicate with the guest channel.

Preferably the apparatus is adapted such that channels in the first sub-set of channels communicate with the guest channel in a duplex communication mode; and the method includes the further step of broadcasting the duplex communication to the plurality of channels.

Preferably, the method includes the further step of allocating the duplex communication capacity between the guest channel and the channels in the first sub-set of channels in response to the received bid data, the bid data representing a request for duplex communication with a second channel.

Preferably, at any one time, duplex communication is between the guest channel and one of the channels in the first sub-set of channels.

Preferably, the duplex communication between each channel in the first sub-set and the guest channel, is recorded, as a separate file, and stored in a memory, each file being accessible only by the respective callers having duplex communication with the guest channel along their respective channel in the first sub-set. According to another aspect of the invention, there is provided a communications apparatus for multi-party conference calls between a plurality of communications channels, the apparatus comprising means for receiving bid data from the channels and allocating those channels from which bid data is received to a second sub-set of channels, and means for selecting a first sub-set of channels, from those in the second sub-set of channels, for the apparatus to receive communications signals from, the selection for the first sub-set being performed according to a predetermined process.

Preferably, the apparatus includes means for allocating an order to the channels in the first sub-set; and means for receiving communications signals from the channels according to the order.

Preferably, the predetermined process is a random or partially random process.

Preferably, the bid data has a value component for determining relative values between the bids, the channels for the first sub-set of channels being selected from the second sub-set in order of bid value.

Preferably, bids of equal value are assigned an order in the first sub-set according to a random or partially random process.

Preferably, the communications signals are received from the channels in the first sub-set for a finite period of time, and a further set of a predetermined number of channels from the second sub-set, for inclusion in the first sub-set subsequent to the finite period expiring. Preferably, the channels are removed from the first sub-set of channels subsequent to the finite period of time expiring. Preferably the further sub-set of channels are included in the first set of channels subsequent to the apparatus receiving further bid data from the plurality of channels. Preferably at least one channel of the plurality of channels as a guest channel; the channels in the first sub-set adapted to communicate with the guest channel.

Preferably the channels in the first sub-set of channels communicate with the guest channel in a duplex communication mode; the duplex communication being further broadcast to the plurality of channels.

Preferably, there is further provided allocation means for allocating the duplex communication capacity between the guest channel and the channels in the first sub-set of channels, in response to the received bid data, the bid data representing a request for duplex communication with a second channel.

Preferably, the duplex communication between each channel in the first sub-set and the guest channel, is recorded, as a separate file, and stored in a memory, each file being accessible only by the respective callers having duplex communication with the guest channel along their respective channel in the first sub-set.

According to a further aspect of the invention, there is provided a communications apparatus for multi-party conference calls between a plurality of communications channels, the apparatus comprising receiving means to receive bid data from the channels and allocating means to allocate those channels from which bid data is received to a second sub-set of channels, and selecting means to select a first sub-set of channels, from those in the second sub-set of channels, for the apparatus to receive communications signals from, the selection for the first sub-set being performed according to a predetermined process. BRIEF DESCRIPTION OF THE DRAWINGS

Preferred embodiments of the invention shall now be described by way of example only and with reference to the accompanying drawings in which:

Figure 1 is a schematic representation of communications apparatus for providing multi-party conference calls;

Figure 2 is a schematic representation of a control system for the apparatus of Figure 1 ;

Figure 3 is a flow chart depicting a client listen mode process of a second embodiment;

Figure 4 is a flow chart depicting a client talk mode of a second embodiment;

Figure 5 is a flow chart depicting a guest talk mode of a second embodiment; and

Figure 6 is a schematic illustration of the allocation of caller ports to a question queue in the communications apparatus of Figure 1.

BEST MODE(S) FOR CARRYING OUT THE INVENTION

Multi-party conference calls can be established for a number of purposes, such as conducting meetings, chat lines, and interviews with guests of interest in a manner that is similar to talk back radio.

Where, for example, an interview or chat line is conducted, callers often pay a time based charge for participating in the call. Where a caller wishes to talk with the person of interest or to make a contribution to the chat room, they may perceive limited value in the call if they are placed at the end of a queue upon joining the call. This is because a substantial period of time may elapse before the caller reaches the head of the queue where they can talk to the chat room or person of interest.

The present embodiments aim to increase users perception of value from participating in multi-party conference calls by allocating callers to a question queue by a random or partially random process, such as semi-random, pseudorandom or weighted random process. The question queue may also have a finite length and talk periods for callers in the queue may be limited so that additional callers can be allocated a spot in the question queue on a relatively frequent basis by use of the random or partially random process.

Alternatively a process of auctioning the right to talk to a guest may be implemented.

Referring now to Figure 1 which is a schematic representation of communications apparatus 100 that enables a multi-party conference call to be established over a communications network such as a switched circuit telecommunications network.

The communications apparatus 100 has a number of caller ports 105. Each caller port 105 receives an incoming line from a switch or an exchange in a telecommunications network. Typically these lines will be duplex lines that enable two way conversations to be established with another line.

Each caller port 105 has a "signal in" line 130 that receives communications signals from a caller's terminal that is in communication with the port. For example, on a typical telecommunications network, the communications signal will be an audio signal that is received from a telephone. However, other forms of communications signals, such as video conference signals, ISDN (Integrated Services Digital Network), wireless communication signals including mobile signals, and Internet based signals may also be used.

The "signal in" line 130 has a signal filter 135 that may be switched to talk mode which allows communications signals to be passed to the conference apparatus 100 so that the port can engage in duplex communication with another designated port.

The "signal in" line 130 may also be switched to listen mode, so that received signals are not passed on to the conference apparatus 100. Where the filter 135 is switched to listen mode, control signals generated by the caller's terminal, such as DTMF (Dual Tone Multi-frequency) signals, are preferably passed through filter 140 to communications ports 125 of the conference apparatus 100.

The caller port 105 also has a "signal out" line 145 that passes communications signals to the caller's terminal that is in communication with the port 105. Again the "signal out" line 145 may accommodate audio signals and alternate forms of communications signals such as video conference signals and ISDN signals. In some applications it may be preferable for the "signal out" line 145 to pass control signals such as DTMF signals.

The "signal out" line 145 is always enabled so that duplex communication signals between two ports with their filter 135 set to talk mode can be transmitted by the caller port 105 to the terminal it is in communication with. This enables callers to listen to the conference call. However, in another embodiment, the "signal out" line may not always be enabled.

The control ports 125 operate to switch the "signal in" line 130 of the various caller ports 105 between talk mode and listen mode. Further detail on the manner in which caller ports 105 are allocated and then switched to "talk" mode and then switched back to "listen" mode is provided below.

Where callers participate in a multi-party conference call with one or more guests of interest, the communications apparatus 100 has one or more guest ports 110.

These guest ports 110 operate in a similar manner to the caller ports 105, in that they have a "signal in" line 130, including the signal filter 135 that can be set to both "talk" and "listen" mode. It also has a control signal filter 140 that enables control signals from the guest port 110 to be passed to the control port 125. The guest ports also have a "signal out" line 145. The guest ports 110 may be identical to caller ports 105 except that they are designated as "guest ports" 110 by the control ports 125 for the purposes of the current conference call.

A port that is designated as a guest port 110 is generally set to "talk" mode on a permanent basis during the conference call. Where there is more than one guest port operational during a conference call, then it may be desirable to implement contention procedures between these guest ports.

The communications apparatus 100 also has a moderator port 115 that enables duplex communication between a caller port and the moderator port or between a guest port and a moderator port. The moderator port 115 has similar features and operates in a similar manner to a caller port 105 and a guest port 110.

A moderator is an operator of the communications apparatus 100 who has control over the conference call. The moderator may talk to a caller or to a guest at either the moderator's request or a guest's or a caller's request. There may be more than one moderator port 115.

The communications apparatus 100 also has message ports 120 that play prerecorded or computer generated messages to any of the caller, guest or moderator ports. The message ports 120 may also receive communications signals from a caller, guest or moderator port that it is in communication with. These signals may be recorded and used in later messages.

The caller, guest, moderator and message ports are controlled by control ports 125. The control ports 125 have a control signal detection port 126, a port assignment port 127 and a port status port 128.

The control signal detection port 126 detects control signals, such as DTMF signals, that have been received at a caller, guest or moderator port. These control signals are a request, by a terminal participating in a conference call, for the communications apparatus 100 to perform a predetermined action, such as a request to connect a caller port 105 with a moderator port 115. Further detail on the operation of the conference apparatus in response to such control signals is provided below. The port assignment port 127 controls whether a port is in "talk" mode or "listen" mode. It also controls inter-connections between ports. For example, the port assignment port 127 controls whether a caller port 105 is connected to a moderator port 115 in "talk" mode, whether it is connected to a guest port 110 in "talk" mode or "listen" mode or whether it is connected to a message port 120 in "listen" mode or "talk" mode.

The port status port 128 reports to the communications apparatus 100 the current status of each port. This is so that the communications apparatus 100 will know, for example, when a caller has hung up and so place a caller port 105 into a state where another caller can participate in the conference call.

In operation of the conference apparatus 100, callers who wish to participate in, say a conference call with one or more guests, dial into a caller port 105. The communications apparatus executes a registration procedure and the caller is then allowed to participate in the conference call. Typically the caller will enter the conference call with their port set to "listen" mode.

Guests also dial into the conference call or can be dialed by the communications apparatus 100 and execute a registration procedure that explains how the conference apparatus operates, before the guest commences the conference call with callers.

Referring now to figure 2, which is a schematic representation of control functions within the communications apparatus 100. The control functions include the allocation of caller ports to a question queue. When a caller port 105 reaches the head of the question queue, the caller port 105 is assigned to "talk" mode so that duplex communication between the caller port 105 and the guest port 110 can occur.

Caller ports 105 are allocated to the question queue by a procedure that is random or partially random in operation. For example the process may be semi- random in operation, pseudo-random in operation or have a weighted random operation. Alternatively callers can submit bids of varying monetary value for the right to talk to the guest. Allocation between callers with the same value bid may be done by utilising a random or semi random process.

The question queue is finite in length and caller ports 105 remain at the head of the question queue for a finite period of time. This enables a further number of caller ports 105 to be allocated to the question queue on a periodic or semi- periodic basis.

Allocation of caller ports 105 to the question queue preferably occurs according to a random or partially random process so that participants in the call have equal, or near equal chance of talking to the guest throughout the duration of the conference call. It is believed that this will provide greater incentive for participants to continue their participation in the call compared with callers who find themselves allocated to the end of a long queue that allocates callers on a "first come first served" basis.

Each caller port 105 may remain at the head of the queue for a predetermined period of time, for example, one minute. This provides a participant in the conference call with one minute to talk to the guest. The question queue may reference only ten ports and hence is ten minutes long. Once a predetermined number of caller ports 105 have been removed from the queue then further caller ports 105 can be allocated to the queue. Accordingly, further caller ports 105 can be added to the queue approximately every ten minutes. It is not essential that there be ten ports referenced by the queue or that the talk time of each port is one minute.

Callers participating in a conference call may request to have their port 105 set to "talk" mode by issuing control signals from their terminal. By requesting talk mode the caller is requesting to talk to the guest. The control signals that indicate the caller's interest in talking to the guest may be DTMF signals. The DTMF signals are passed by the filter 140 on the "signal in" line 130 of the caller's port to the control signal detection port 126. The control signal detection port 126 upon receiving a DTMF signal from a port 105, passes DTMF information, derived from the DTMF signal, onto a conference control facility 210. The conference control facility 210 upon receipt of DTMF information, and determination of action that is to be taken in response to the request, instructs the port assignment port 127 as to the ports that are to have their mode of operation (e.g. "talk" or "listen" mode in the case of a caller port) changed and instructs the port assignment port 127 as to any changes in inter-connections between ports that may be required (e.g. connecting a first caller port with a moderator port and setting each of these ports to a "talk" mode of operation).

Where the control signal detection port 126 receives a DTMF signal indicating that a caller wishes to speak to a guest, then the DTMF request is passed onto the control facility 210. The control facility 210 logs the caller ports that have requested to talk to the guest with the talk request facility 205.

A caller's request to talk with a guest is known as a bid and a DTMF signal indicating that request is known as bid data. Accordingly, bid data received by the control signal detection port 126 is passed to the control facility 210 to be logged by the talk request facility 205.

The bid data may be of no monetary value or it may be accompanied by a specified monetary value. If the bid is to be of a monetary value, the caller will also submit details of the monetary value, using, for example, the caller's telephone keypad to input DTMF tones indicative of the value. The caller may also use the DTMF tones to submit data regarding credit/ debit card details by which the caller will pay for the bid.

Use of bid data with monetary value enables an auction for the right to talk to a guest to take place.

Talk slots may be allocated in decreasing order of bid value. Where two or more callers bid the same value, then their place in the talk queue may be allocated according to a random process. Use of bid data is not essential. Alternate embodiments may allocate any of the callers to the question queue on a random basis. Periodically, a queue assignment facility 215 assigns caller ports to a question queue 150 that is held by a question queue controller 220. The queue assignment facility 215 operates under the instructions of the control facility 210 and a batch controller 225.

The queue assignment facility 215, upon instruction from the batch controller 225 to place further caller ports into the question queue, accesses the bid data logged with the talk request facility 205. The queue assignment facility 215 performs a random or partially random process on the bid data in order to select the caller ports that will be entered into the question queue 150. It is preferable that the random or partially random process also determines the order in which the selected caller ports will be entered into the question queue.

The bid data logged with the talk request facility 205 represents a second sub-set 151 of first and second sub-sets of caller ports. The first sub-set 150 of caller ports is the sub-set of caller ports that is assigned to the question queue. Accordingly, the first sub-set of caller ports that constitute the ports assigned to the question queue are selected from the second sub-set of caller ports that is represented by the bid data held by the talk request facility. This can be done by means of bid value - as discussed above - or a random process, such as the one discussed below.

A Weighted Random Process used to allocate caller ports 105 to the question queue is set out as follows. The caller ports 105 are allocated to the question queue according to a weighted random process which determines the next caller(s) that progress to the question queue, and is carried out in the queue assignment facility 215. It is preferable that this allocation is done on a batch process, however this is not essential.

The process for allocating callers to the question queue preferably:

1) provides a chance for any caller to be selected for the question queue (or any caller who has entered bid data to be selected for the question queue); 2) provide a higher chance for callers who have been waiting longer, it may even increase the chances of a caller who has been listening to the call for a long time but only entered bid data at a relatively late stage in the call;

3) if required, always include the caller who has waited the longest;

4) work no matter how many/few time slots or callers there are;

5) if required, always include the caller who has waited the least.

It is believed that a weighted selection process meets these objectives, by varying the weighting of various caller ports according to criteria such as time elapsed since entering bid data and time elapsed since joining call.

Caller ports 105 that have requested duplex communication with a guest port 110 by entering bid data are allocated to a sub-set of ports. This sub-set is referred to as the second sub-set 151 of caller ports. It may also be referred to as the "Listen Wait" queue or the "LW queue. The first sub-set 150 is the set of caller ports allocated to the question queue. This is illustrated schematically in Figure 6.

The second sub-set 151 is preferably ordered according to the length of time that each port has been in the second sub-set or according to the length of time that each caller port has been participating in the call. Alternatively, the second subset may be weighted according to a combination of both of these factors or other factors. It is not essential to order the second sub-set.

Having ordered the second sub-set, the weighted random selection process preferably selects the caller port at the head of the now ordered second sub-set 151. It then determines how many caller ports remain in the second sub-set and how many slots are available in the question queue, for example in the 10 slot queue (or first sub-set) 150 illustrated in Figure 6, there may be seven slots available when the next set of caller ports are selected for allocation to the question queue. The slots in the queue 150 that are still occupied, are designated the letter "F" in Figure 6. Those that are to be occupied by subsequent caller ports are designated positions 1 to 7. In this example, the second sub-set 151 has thirty-one caller ports allocated to it i.e. in the "Listen Wait" queue 151. Hence, in a batch process, seven ports are preferably selected for allocation to the question queue 150 from the second sub-set/ "Listen Wait" queue 151.

To determine which caller ports 105 are to be allocated to the queue 150, a formula is used, based on the number of caller ports in the second sub-set 151 , the number of available slots in the question queue, and the weighting. This determines an increment value for selection of subsequent caller ports in the second sub-set 151 after the first caller port has been selected, which is allocated to position 1 - see Figure 6. Each increment may be calculated separately, and is calculated using the formula set out in column 4 of the spreadsheet on page 27. This formula can also be set out as follows:

Increment = (Total caller ports remaining in second sub-set 151 )/(((Total no. of slots in queue 150 - value of the next position filled as given in Figure 6)*weighting) + 1)

Hence if, for example, (using a weighting = 3), and having allocated the port at the head of the "Listen Wait" queue 151 to the first empty slot i.e. position 1 in the question queue 150, then there are six slots remaining in the question queue 150 and 30 caller ports in the second sub-set i.e. the "Listen Wait" queue 151. The next position to be filled is position 2, and there were seven slots in the queue 150, so 7-2 = 5. This is multiplied by the weighting, 3, making 15, and then 1 is added to make 16. The number of remaining caller ports in "Listen Wait" queue 151 is 30 as mentioned above. Thirty divided by 16 is 1.89, rounded up is 2. So the next increment is 2, so caller port 29 i.e. 31-2, is allocated to position 2 - see Figure 6. There are now 28 caller ports in the "Listen Wait" queue 151 remaining, and 5 slots in the question queue 150. To determine the third caller port 105 to be selected from the second sub-set i.e. to fill position 3 - see Figure 6, the next increment value is determined in the same way as above. In this case, the increment is 3, calculated as roundup value of 28/((7-3)^*3+1 ) = 2.15. This is repeated until all the slots are filled. Figure 6 illustrates which caller ports 105 are allocated to the question queue 150. 01/28213

This random weighting ensures that callers throughout the "Listen Wait" queue 151 are allocated to the question queue 150, and, particularly, that the last caller in the "Listen Wait" queue 151 is allocated a position in the question queue 150.

The division by the number of slots in the question queue may be further weighted to skew selection toward one end of the second sub-set depending on whether a weighting of greater than one or less than one is used.

During a call, the weighting may be varied dynamically or under moderator control, depending on caller response and behaviour. At one point in the call it may be appropriate to skew caller selection to callers who have been waiting in the second sub-set for a long period of time. At other points in the call it may be appropriate to skew selection toward those callers who have only recently entered bid data.

For Example

It is also possible to reverse the weighting to callers waiting the least by choosing caller ports in the second sub-set in order from the last caller port to issue bid data (i.e. the caller port that most recently issued bid data) to the caller port that first issued bid data (i.e. the first caller port to issue bid data). The question queue controller 220 operates under instruction from the control facility 210. The question queue controller 220 holds the question queue and advises the control facility 210 of the caller port 105 that is presently at the head of the question queue.

The question queue controller 220 monitors the period of time that each caller port is at the head of the question queue. When an allotted period of time for a caller port 105 has expired then, the question queue controller 220 advises the control facility 210 that a new port has been assigned to the head of the question queue. The control facility 210 then re-assigns the caller port 105 that was at the head of the queue to "listen" mode, thereby severing its duplex communication with a guest port 110. The control facility 210 simultaneously assigns "talk" mode to the caller port 105 now at the head of the queue and places it into duplex communication with at least one of the guest ports. A record controller 240 is coupled to the "signal out" line 145, and is operable to record audio signals, in a memory in the record controller 240, that are output on this line 145, as audio files. Other signals, such as video signals, could also be recorded. In this way, a recording of the communication between the caller and guest is made. When a caller ends the communication with a guest, the Record Controller 240 also simultaneously ends the previous recording and starts a new recording of the audio signal on the "signal out" line 145 on a caller port 105 in listen mode. Each new recording is stored under a unique sequential file name. This file name is recorded on a table mapped to a caller ID and conference ID. The conference ID is unique for each conference event.

This allocation process is repeated until a predetermined number, for example three of the caller ports 105 remain in the question queue and the remaining slots in the question queue are empty. When this happens the question queue controller 220 advises the batch controller 225 of the state of the question queue. The batch controller 225 then instructs the queue assignment facility 220 to select a further set of caller ports for assignment to the question queue - as discussed above with respect to the random allocation process. The size of the question queue 150, and the length of time that each caller stays in duplex communication with the guest can be selected to suit the appropriate situation. If, at any point during the conference, a new batch of callers are to be selected to join the question queue 150, and there is less time for the conference remaining than the maximum length of the question queue, then the number of callers selected to join the question queue will be selected to ensure that all callers in the question queue 150 will still get the opportunity to talk to the guest. So, for example, in a ten-caller question queue, with two callers remaining in the question queue, and 1 minute per caller duplex communication time, if there is only 7 minutes left of the conference, then only 5 callers will be selected in the next batch to join the question queue 150. The control facility 210 may also operate to instruct a platform message facility 230 to play an announcement, via the message port 120, to all (or a select number of) caller ports 105, asking the callers to bid for the opportunity to talk to the guest or other messages or instructions. Those callers who respond are logged with the talk request facility as detailed herein.

Callers who have talked to the guest are given a password ID that is derived from their caller ID and conference ID. This password can be used via a Web interface 250 to retrieve copy of their recording from the record controller 240, by means of a web site.

According to a further embodiment there is provided a representation of the callers, guests and moderators as software objects within conference apparatus such as the apparatus of Figures 1 and 2. These software objects are assigned attributes.

The mode of these objects determines a signal source and a signal destination for each objects port. An action status attribute for each object is used to flag if processing needs to be done with that object.

Objects

Caller = (port, id, mode, action, key, queue) Guest = (port, id, mode, action, key) Moderator = (port, id, mode, action, key)

Object Attributes

Port: specifies the logical channel this call is attached to. ID: Sequential ID number given to a caller when their call is answered. Mode: Defines current mode of object (L - listen; P'x", G'x' - messages; C, GC - conference; D - Dead)

Action: (Y,N) is action required on this object Key: log of control signals such as DTMF key sequence pressed Queue: position in queue (if in a queue)

There are three main functional areas, namely Action request; Yes Action Response; and Routines. There is also a group of variables

Action request:

The Action Request functional area sets the modes and action settings according to various criteria or events such as a new caller event, a hangup event, a DTMF event or a conference queue allocation state.

Yes Action response:

The Yes Action Response functional area is a single routine that looks for the action attribute of any object being set to = "y". This setting of "y" is based on the 'key' attribute information. The Yes Action Response functional area invokes a routine that changes the signal source and signal destination of a port as required.

Routines:

The routine functional area changes the attributes of the object that it invoked into action.

Variables:

Variables are used for tracking global information of a conference. The variables can be used by or changed by any one of the Action request, the Yes Action response and the Routines functional areas.

Variable list:

Queue_count - keeps track of callers selected to talk with guest. Current_count - keeps track of current caller speaking to guest. CIF - Caller Information Flag set when guest wants contact details of caller Con ime - length of conference, (counts down in 1 sec increments until 0) Talk_time - caller talk time with guest, (counts down in 1 sec increments until 0) Start_time - starting time of conference. CurrentJD - used to provide unique identifier for each caller Time_slots - number of intake callers to be put in question queue Total_in_LW - Total number of callers in the "listen wait" mode for asking a question of a guest.

Intake - actual number of calls to go to question queue Guest_contact_number - Entered at the start of conference by guest.

Password ID - a unique number created from a function on the caller ID & conference ID.

Selection of "signal source" and "signal destination" for the caller, guest and moderator ports is now described.

Every caller has a logical port for receiving signals from a caller and for transmitting signals to a caller. These ports can be switched to transmit signals received from a caller to the communications apparatus 100 or to filter signals received from a caller. Each port has a signal source attribute which specifies the source of the signal transmitted by the port and a signal destination attribute which determines the destination of any signal received by the port from a caller, guest or moderator. The value of these attributes is determined by the various modes of operation of the communications apparatus 100.

Signal Source Modes

Conference - signals transmitted by the port as the conference conversation Guest - signals transmitted by the port as only the guests' signals

Messages - signals transmitted by the port as platform sourced audio files Moderator - signals transmitted by the port as the moderator's signals

Signal Destination Modes

All signals received by a caller, guest or moderator are fed through control signal filter 140 such as a DTMF sensitive filter; Conference - signals received at the port from a caller, guest or moderator are Broadcast to all current participants of the conference;

Guest - signals received from the caller or the moderator are transmitted to the guests port;

Messages - all signals received at the port from a caller, guest or moderator are recorded to the communications apparatus 100 as audio files;

Moderator - all signals received at the port from a caller or guest are transmitted to the moderator;

The operation of the moderator port 115, which controls the operation of the communications apparatus 100, and accordingly the conference shall now be described.

The Moderator co-ordinates conference calls and over sees automated processes. Where intervention with a caller or guest is required the moderator, through signals transmitted by the moderator port 115 (or on some apparatus by a separate control panel), has the ability to manually control the conference and selected services

A set of ten conference modes in which the communications apparatus may operate are detailed in Table 1 , Conference modes.

Each column of Table 1 indicates a particular mode of the communications apparatus 100. Each row indicates a particular port type (except for the row titled "key Function which represents the key pressed by the operator in order for the communications apparatus 100 to enter the selected mode). Each cell indicates a particular mode that a port assumes for a particular conference mode. Table 1 : Conference modes

The following KEY sequences on a DTMF telephone keypad may be transmitted to a port and the platform message port 120 will respond with the indicated information:

*91 - number of callers in the question queue

*92 - number of bids from callers to speak to guests

*93 - time left in conference

# - is an immediate reset function to normal mode

*^* - queues in next caller to speak to the guest.

*90 - ends the conference by playing a message to all callers before disconnecting the caller ports, or a specified set of caller ports. *88 - remove abusive caller from conference "77 - Auto redial to Guest

The following routines may be performed by the communications apparatus 100 in respect of caller ports 105 and guest ports 110.

Caller mode routines

P1 request: (Initial greeting)

Play P1 message, which gives an initial greeting and advised that he is added to the conference in listen mode Set mode = L1 , action = N End.

P2.0 request: (Question request accepted) Play P2.0 message, indicating that the caller's request to talk to the guest has been accepted Set mode = LW, action = N End.

P2.1 request: (Question request missed out this time)

Play P2.1 message, indicating that the caller's request has not been accepted and to try again

Set mode = LW, action = N

End.

P3.0 request:(Successful - place in queue to talk to guest)

Play P3.0 message, indicating that the caller is in the queue to talk to the guest, that the conversation will be recorded, and can be accessed via a web site, by using a password, which will be allocated after the conversation has finished. Record name of caller

Set mode = QQ, where QQ is the state where a caller is in the questions queue

150, action = N, queue = queue_count

Queue_count = queue_count + 1

End. P3.1 request: (1 minute to go)

Play P3.1 message - "You are one minute from talking to (the guest)" Set mode = QQ, action = N End.

P4.0 request: (Conference with guest)

Play P4.0 message _ "You are 5 seconds from talking to (the guest), please have your question ready" Set mode = C, action = N, queue = 0 End.

P4.1 request:(Thank you for your questions, here is your password ID - return to listen mode) Password ID = function (caller ID, conference ID)

Play P4.1 message and password ID - "Thank you for your questions, here is your password., you will now be returned to listen mode": confirm or play again.

Set mode = L1 , action = N, change ID = currentJD (ID is changed to stop recycling caller in question selection process) currentJD = currentJD + 1

End.

P4.2 request:(Thankvou for your questions -here is your password ID plus Guest wants your details) Password ID = function (caller ID, conference ID)

Play P4.2 message and password ID - "Thank you for your questions, and here is your password (the guest) wishes to have your details, please leave them after this message": confirm or play again.

Record caller details Set mode = L1 , action = N, change ID = currentJD (ID is changed to stop recycling caller in question selection process) currentJD = currentJD + 1

End. P5.0 request:(Abusive caller disengaged)

- "(the guest/moderator) does not want to continue with this call. If you are unhappy, please leave your details" Record caller details Set mode = dead, action = N Hangup line End.

E1 request: (Unknown DTMF request)

Play E1 message - Sorry, your request is not understood, please key again. Set action = N, mode = key, key = "" (mode is not changed!) End

Guest Mode Routines

G1.0 request:(Guest greeting and instructions)

Play P1.0 message, to greet guest and provide instructions

Record Guest_Contact_number

Set mode = G2, action = Y

End.

G2.0 request: (conference start)

Play music until start ime

Set Conf ime = ?

Run Conf_start Set mode = GC, action = N

End

G3.1 request: (Set caller information flag) CIF = Y Set mode = GC, action = N End.

G3.2 request: (remove abusive caller from conf) Set CIF = A Set talk ime = 0

Get caller with queue_count = current_count + 1 set mode = P4.0, action = Y

Set mode = GC, action = N

End

G3.3 request: (add 15 minutes to conference)

Play G3.3 message (to all...conference has been extended by 15 minutes)

Conf ime = Conf ime + 15 minutes

Set mode = GC, action = N End

G3.4 request: (add 1 minute to caller talk time) Play G3.4 message (confirmation tone) Talkjime = Talkjime + 1 minutes Set mode = GC, action = N End

E1 request: (Unknown DTMF request)

Play E1 message - Sorry your request is not understood, please key again. Set action = N, mode = key, key = "" (mode is not changed!) End.

The following actions can be performed by the communications apparatus 100. These actions are requested via the "action request" attributes of the port objects.

New Call: A new call is detected at a port Answer call: Set port, set ID, mode = P1 , action = Y, key = "", queue = 0 CURRENTJD = CURRENTJD + 1 End Hang up detection:

If mode = QQ Then find all QQ with position greater than queue and reduce by 1

Set mode = dead, action = N

End

DTMF recorder:

Record DTMF sequence (2 digit) Set key = sequence, action = Y End.

Question Controller:

Wait until queue_count <= current_count + 2

If confjime < time_slots +2 then set time_slots = confjime - 2

Compile callers with mode = LW

If total Jn_LW < time_slots then intake = total Jn_LW

Else intake = time_slots Use Weighted-random process to choose callers to fill time slots

List LW callers from lowest ID to highest and give a position number from 1 to Total Jn_LW.

Select caller with positions based on formula, as set out in the spreadsheet below:

Callers with Position D6: D (6 + Intake -1 ) set mode = P3.0, action = Y All other callers in list Set mode = P2.1 action = Y Return to start END

Callers are sorted by the order that they called using their ID, they are then selected based on proximity to preselected formula scale and their position in the queue.

Question Queue Controller:

Conf_start Set intake = 10 (note: defines number of callers taken in each batch of question requests)

Qc_Start

Set Talk_Time = 60 Current_count = current_count + 1 Get caller with queue_count = current_count -1 set mode = P3.1 , action = Y At Talk_Time = 10

Play 10 second warning pip to "C At Talk_Time = 5 If queue_count > current_count then

Get caller with queue_count = current_count + 1 set mode = P4.0, action = Y Else set Talkjime = 9 At Talkjime = 0 Get caller with queue_count = current_count

If CIF = Y set mode = P4.2 (routine to choose if guest wants info on caller) If CIF = A set mode = P5.0 Else set mode = P4.1 Set CIF =N

Return qc_start Yes Action Response

Check all callers If action = Y If key non blank then go to DTMF routine (as set out below) Else go to mode routines End

DTMF routines

Referring now to Figure 3 which details operation of the communications apparatus 100 from the perspective of a caller, from when the caller logs on to the communications apparatus 100 to when the caller is transferred to the question queue. The process starts at step 300 with the caller dialling in to the conference apparatus. The caller receives a platform message as an initial greeting..

Having played the greeting and having received caller's authorisation to proceed by means such as a DTMF signal, the process moves to step 305 where the conference commences by execution of the "new call" action. At this stage, the caller may also submit bid value data, as well as credit/ debit card details, should this be required

The process moves to step 310 after the "new call" action has been executed and the caller routine P1 is executed, in which a greeting is played advising that caller that he is added to the conference in listen mode, and can make a bid to talk to the guest, or, for example, talk to the moderator.

The process then moves to step 315 where the where the filter 140 on the "signal in" line 130 listens for DTMF signals. If the filter 140 receives a DTMF signal, the process determines whether or not the signal was a bid placed by the caller so that they can talk to a guest. If it was not, then process executes the requested action (such as a request to talk to the moderator) before the process returns to step 310 and waits for a further DTMF signal.

If the DTMF signal is a bid to talk to a guest then the process moves to step 320 where caller routine P2.0 is executed. After step 320 the process moves to step 325 and question queue controller 220 selects the next sub-set of caller ports 105 to be entered into the question queue.

After step 325 the process moves to step 330 where the caller ports that have not been selected for the question queue have caller routine P2.1 executed. The caller ports 105 can be reset to the LW (listen and wait to talk to the guest) mode as the question queue is of finite length and the caller ports in the question queue are assigned a finite period of time in which to talk to the guest. Accordingly the question queue empties during the course of the conference call and previously unsuccessful bids that have been re-assigned LW mode may be successful at a later point in the conference call. If at step 325 a caller port is assigned to the question queue then following caller routine P3.0 is executed and the process moves to step 335 and the caller port is assigned to the question queue.

Referring now to Figure 4, which details the process for a caller progressing though the question queue in order and talking to a quest.

The process commences at step 335 where the caller is entered into the question queue as detailed above. Having entered the question queue, the caller waits until they have an opportunity to speak to the guest. When the caller is a set period of time from talking to the guest, for example 5 seconds, the process moves to step 400 where a caller routine P3.1 is executed and a caller hears a message advising that they have one minute before they speak to the guest. The process then moves to step 405 where caller routine P4.0 is executed and the caller hears a message advising that they have 5 seconds before talking to the guest.

After step 405 the process then moves to step 410 where the callers port is assigned "talk" mode that enables the caller to talk to the guest. When the callers time for talking to the guest has expired, the either caller routine P4.1 or caller routine P4.2 is executed, depending upon whether the guest wishes to have the caller's details.

After step 410 the process moves to step 415 where the caller is returned to "Listen" mode. This requires that the caller bid again before they can speak with the guest. It is not essential that the caller is the returned to "listen", the caller may, for example, be returned to LW mode or have their call disconnected.

Referring now to Figure 5, which details a process of operation of the communications apparatus 100 from a guest's perspective. The process commences at step 500 where guest routine G1.0 is executed, including the transmission of a greeting message to the guest and recording of their contact phone number. Following step 500 the process moves to step 505 where guest routine G2.0 is executed until the scheduled start time of the conference. When the conference starts the process moves to step 510 which is conference mode where the guest speaks with callers. From step 510 the guest may control the conference by issuing various commands detailed in step 515. These commends detailed are issued using the key pad on a telephone that generates DTMF signals. The commands that may be issued by the guest include "#9" that ends a call, for example, if the caller is abusive, "#1" that adds a predetermined amount of time to the current callers talk time e.g. one minute, "#7" that extends the conference call time by a predetermined amount of time, such as 15 minutes, and "#8" that enables the guest to request the callers details after they have finished talking.

If the guest does not receive a response from a caller that the guest is supposed to be talking to, then the process moves from step 515 to step 530 and a ten second warning is played to the caller. If the caller responds then the process returns to step 515 otherwise the caller is disconnected and the process returns to step 510 where a new caller is queued in for the guest.

If at step 515 the guest requires the callers details then guest enters in code "#8" and guest routine G3.1 is executed. The process may then either progress to step 510 or returns to step 515.

If at step 515 the guest wishes to terminate a call then the guest issues command "#9". This executes caller routine P5.0 before the process returns to step 510.

If at step 515 the guest wishes to add a further fifteen minutes to the conference call, then the guest issues command #7 and guest routine G3.3 is executed before the process returns to step 515. Alternatively, the guest may wish to talk to the caller for another minute, in which case the guest issues command #1 which causes Guest routine G3.4 to be executed. The following error routines may be implemented:

Error routine - Client Drop Off

(Hang-up detection) A: Waiting in queue.

1 ) Move callers behind forward 1 minute.

2) If caller was next in line advise second caller that they are now next.

B: During Conversation with Guest.

Guest queue's next caller using #9 function.

Error Routine - Guest Drops off.

(Moderator managed)

Group Message: "Advise callers that the guest call was terminated and we are trying to re-establish the link. If we are unable to re-establish the connection within 3 minutes the conference will be concluded. Please hold. (play music)

Option 1 : Link re-established. Advise callers - Resume conference from where it left off.

Option 2: Link not made. Advise callers - disconnect all.

It is not essential that the embodiments described herein are restricted to conference calls where one or more callers dial in to talk to one or more guests. The same contention resolution procedures may implemented for a chat line or for a general conference call. Where these procedures are implemented for a chat line or a general conference call, then guest allocation procedures may be required, however, these allocations may be done on a time limited basis or dynamic basis as the moderator chooses. It is not essential that the embodiments described herein are restricted to telephone voice conferences. The same contention resolution procedures may be implemented on other conference media such as video and Internet.

Claims

THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS

1. A method of operating communications apparatus adapted to provide multiparty conference calls between a plurality of communications channels; the method comprising the steps of:

receiving bid data from the channels and allocating those channels from which bid data is received to a second sub-set of channels;

selecting a first sub-set of channels, from those in the second sub-set of channels, for the apparatus to receive communications signals from, the selection for the first sub-set being performed according to a predetermined process.

2. A method as claimed in claim 1 , wherein the method further comprises the step of allocating an order to the channels in the first sub-set and receiving communications signals from the channels according to the order.

3. A method as claimed in claim 1 or claim 2, wherein the predetermined process is a random or partially random process.

4. A method as claimed in claim 3, wherein the random or partially random process for selecting channels for the first sub-set comprises a semi- random, pseudo-random or weighted random process.

5. A method as claimed in claim 1 , wherein the bid data has a value component for determining relative values between the bids; and the method further comprises the step of selecting the channels for the first sub-set of channels, from the second sub-set, in order of bid value.

6. A method as claimed in claim 5, wherein bids of equal value are assigned an order in the first sub-set according to a random or partially random process.

7. A method as claimed in any preceding claim, wherein the method further comprises the step of receiving communications signals from the channels in the first sub-set for a finite period of time, and selecting a further set of a pre-determined number of channels from the second sub-set, for inclusion in the first sub-set, subsequent to the finite period expiring.

8. A method as claimed in claim 7, wherein the channels are removed from the first sub-set of channels subsequent to the finite period of time expiring.

9. A method as claimed in claims 7 or 8, wherein the further sub-set of channels are included in the first set of channels subsequent to the apparatus receiving further bid data from the plurality of channels.

10. A method as claimed in any preceding claim, wherein the method further comprises the apparatus designating at least one channel of the plurality of channels as a guest channel; the channels in the first sub-set adapted to communicate with the guest channel.

11. A method as claimed in claim 10, wherein the apparatus is adapted such that channels in the first sub-set of channels communicate with the guest channel in a duplex communication mode, the method including a further step of broadcasting the duplex communication to the plurality of channels.

12. A method as claimed in any preceding claim, including the further step of allocating the duplex communication capacity between the guest channel and the channels in the first sub-set of channels, in response to the received bid data, the bid data representing a request for duplex communication with a second channel.

13. A method as claimed in claim 12, wherein, at any one time, duplex communication is between the guest channel and one of the channels in the first sub-set of channels.

14. A method as claimed in claim 12 or claim 13, wherein the duplex communication between each channel in the first sub-set and the guest channel, is recorded, as a separate file, and stored in a memory, each file being accessible only by the respective callers having duplex communication with the guest channel along their respective channel in the first sub-set.

15. A communications apparatus for multi-party conference calls between a plurality of communications channels, the apparatus comprising means for receiving bid data from the channels and allocating those channels from which bid data is received to a second sub-set of channels, and means for selecting a first sub-set of channels, from those in the second sub-set of channels, for the apparatus to receive communications signals from, the selection for the first sub-set being performed according to a predetermined process.

16. A communications apparatus as claimed in claim 15, including means for allocating an order to the channels in the first sub-set; and means for receiving communications signals from the channels according to the order.

17. A communications apparatus as claimed in claim 15 or claim 16, wherein the predetermined process is a random or partially random process.

18. A communications apparatus as claimed in claim 17, wherein the random or partially random process for selecting channels for the first sub-set comprises a semi-random, pseudo-random or weighted random process.

19. A communications apparatus as claimed in claim 15, wherein the bid data has a value component for determining relative values between the bids, the channels for the first sub-set of channels being selected from the second sub-set in order of bid value.

20. A communications apparatus as claimed in claim 19, wherein bids of equal value are assigned an order in the first sub-set according to a random or partially random process.

21. A communications apparatus as claimed in any of claims 15 to 20, wherein the communications signals are received from the channels in the first subset for a finite period of time, and a further set of a pre-determined number of channels, from the second set, are selected for inclusion in the first subset subsequent to the finite period expiring.

22. A communications apparatus as claimed in claim 21 , wherein the channels are removed from the first sub-set of channels subsequent to the finite period of time expiring.

23. A communications apparatus as claimed in claims 21 or 22, wherein the further sub-set of channels are included in the first set of channels subsequent to the apparatus receiving further bid data from the plurality of channels.

24. A communications apparatus as claimed in any of claims 15 to 23, wherein at least one channel of the plurality of channels is designated as a guest channel, the channels in the first sub-set adapted to communicate with the guest channel.

25. A communications apparatus as claimed in any of claims 15 to 24, wherein the channels in the first sub-set of channels communicate with the guest channel in a duplex communication mode, the duplex communication being further broadcast to the plurality of channels.

26. A communications apparatus as claimed in claim 25, and including allocation means for allocating the duplex communication capacity between the guest channel and the channels in the first sub-set of channels, in response to the received bid data, the bid data representing a request for duplex communication with a second channel.

27.A communications apparatus as claimed in claim 26, wherein, at any one time, duplex communication is between the guest channel and one of the channels in the first sub-set of channels.

28. A communications apparatus as claimed in claim 25 or claim 26, wherein the duplex communication between each channel in the first sub-set and the guest channel, is recorded, as a separate file, and stored in a memory, each file being accessible only by the respective callers having duplex communication with the guest channel along their respective channel in the first sub-set.

29. A communications apparatus for multi-party conference calls between a plurality of communications channels, the apparatus comprising receiving means to receive bid data from the channels and allocating means to allocate those channels from which bid data is received to a second subset of channels, and selecting means to select a first sub-set of channels, from those in the second sub-set of channels, for the apparatus to receive communications signals from, the selection for the first sub-set being performed according to a predetermined process.

30. A communications apparatus as claimed in claim 29, including allocating means to allocate an order to the channels in the first sub-set; and receiving means to receive communications signals from the channels according to the order.

31. A communications apparatus as claimed in claim 29 or claim 30, wherein the predetermined process is a random or partially random process.

32. A communications apparatus as claimed in claim 31 , wherein the random or partially random process for selecting channels for the first sub-set comprises a semi-random, pseudo-random or weighted random process.

33. A communications apparatus as claimed in claim 29, wherein the bid data has a value component for determining relative values between the bids, the channels for the first sub-set of channels being selected from the second sub-set in order of bid value.

34. A communications apparatus as claimed in claim 33, wherein bids of equal value are assigned an order in the first sub-set according to a random or partially random process.

35. A communications apparatus as claimed in any of claims 29 to 34, wherein the communications signals are received from the channels in the first subset for a finite period of time, and a further set of a pre-determined number of channels, from the second set, are selected for inclusion in the first subset subsequent to the finite period expiring.

36. A communications apparatus as claimed in claim 35, wherein the channels are removed from the first sub-set of channels subsequent to the finite period of time expiring.

37. A communications apparatus as claimed in claims 35 or 36, wherein the further sub-set of channels are included in the first set of channels subsequent to the apparatus receiving further bid data from the plurality of channels.

38. A communications apparatus as claimed in any of claims 29 to 37, wherein at least one channel of the plurality of channels is designated as a guest channel, the channels in the first sub-set adapted to communicate with the guest channel.

39. A communications apparatus as claimed in any of claims 29 to 38, wherein the channels in the first sub-set of channels communicate with the guest channel in a duplex communication mode, the duplex communication being further broadcast to the plurality of channels.

40. A communications apparatus as claimed in claim 39, and including allocation means for allocating the duplex communication capacity between the guest channel and the channels in the first sub-set of channels, in response to the received bid data, the bid data representing a request for duplex communication with a second channel.

41. A communications apparatus as claimed in claim 40, wherein, at any one time, duplex communication is between the guest channel and one of the channels in the first sub-set of channels.

42. A communications apparatus as claimed in claim 39 or claim 40, wherein the duplex communication between each channel in the first sub-set and the guest channel, is recorded, as a separate file, and stored in a memory, each file being accessible only by the respective callers having duplex communication with the guest channel along their respective channel in the first sub-set.

43. A communications apparatus as hereinbefore described with reference to the accompanying drawings.