Patent Application
20090094547
This invention relates to audio conferencing facilities. Such facilities provide the capability for a number of users to participate in a discussion by connecting through a single point of contact. Typical services allow each user to establish connection to a conference call platform. The platform provides a bridge through which all the callers can be connected so that each one can hear what is said by each of the others. Typically, such platforms provide facilities to prevent cross talk, feedback, etc, and may also provide a spatialisation capability to allow different participants' voices to seem to emanate from different loudspeakers.
It is known to use a recorded speech file to announce a user when he joins a conference. The speech files can also be used to announce to a joiner, immediately before he is connected to the conference, the names of those people already taking part, and can also announce the identities of people as they disconnect from the system. However, in existing systems the user generates the speech file at the time of joining the conference.
According to the invention, there is provided a registration process to allow a user access to a communications facility, comprising the step of recording a name file to be linked to a record of the user maintained on a database, for subsequent playback when the user accesses the facility. According to a related aspect, there is provided a process for providing access to communications facilities for a user, wherein when the user accesses the facility, a database containing a record of user data is accessed, a name file associated with the user is accessed from the database, and the name file is played as part of an audio message to one or more parties to a conference call.
The invention also provides a communications facility having means for controlling access thereto, comprising a registration means for generating user data relating to authorisation to use the facility, a user database to store user data generated by the registration means, and a connection server for retrieving data from the user database and controlling communications connections between users, wherein the registration means comprises recording means for generating a name file to be stored as part of the user data, and the connection server comprises retrieval means for retrieving a name file from the database and playback means for generating, from the name file, an audio signal to be played to one or more of the participants to a communication connection.
Thus a user may record his name as part of a registration process to allow access to the conferencing facilities, and this recording is linked to a record of the user maintained on a database for subsequent playback whenever the user accesses the facility. The database may record other data to authenticate the identity of a user accessing the facility: for example it may be linked to a record of the user's ANI (automatic number identification—also known as CLI—calling line identity).
Depending on the facilities available to the user, the name file may be generated by recording an audio input generated by the user, or by entering text input, for example it by a manual data entry means, such as a keyboard. Alternatively, if the user's name is accessible from an existing database, a text file may be generated from that on initial registration. However, the wide variety in pronunciation of personal names makes the spoken option the preferred one.
The name file may be played to participants to the conference at any suitable point, for example to the user whose name file it is, to welcome them to the system, or to other users to announce the arrival or departure of the user from the conference.
By linking a name file to the user's record the user does not need to go through the step of announcing himself every time he joins a conference. This is particularly useful if a participant has a speech impairment, or is in a noisy environment where it may be difficult to be heard but from where, by use of headphones, he can quite easily listen in to the conference. The linking of the speech file to the user's identity also acts as confirmation that participants to a conference are who they claim to be. The speech file may also be used to personalise a greeting to a user when he accesses the system.
An embodiment of the invention will be described by way of example, with reference to the drawings, in which:
The process requires a user to first register his terminal 1 with the conferencing service platform 4. This registration process only needs to be done once, and thereafter the user can access the service as often as he requires, without repeating this registration step. The registration process records the user's ANI (automatic number identification—also known as CLI—calling line identity). Once the user has registered his phone with the platform, he should be able to dial into a defined phone number, and be recognized, from the phone ANI, as authorised to use the service. Access to the user's account can thus be achieved with minimal key strokes
The registration process also allows a user to create unique credentials for authentication when using the service via a phone other than one that has already been registered, providing flexibility to users and enhancing the usability of the service. During the registration process the user is permitted to create a security code, that coupled with the Profile Number would authenticate the user. These credentials allow users to come back to a designated web site to update their various configurations. For instance, if a user changes jobs, he may want to configure passcodes for other colleagues so that they can join conferences he is hosting.
The registration process, by which the data is pre-programmed to the reservations management system, has two variants, depending on whether any of the user data can be made available to the reservations management database 2 from a central source or whether the users have to provide all the data. Central provision may be done, for example, by loading the details of authorised users into the database of the reservations management system from some other source, such as a company's internal telephone directory or other Human Resource database.
When the user of a terminal 1 chooses to register with the service, to allow him to make use of the facility, he accesses the validation server 3 (step 11). The user then provides sufficient data to identify him: this may include name, email address, the user's billing account number, and the phone number of the bridge to which the account is to be connected (preferably a toll free number), a Security PIN (a unique identifier assigned to a company account set up in the reservations management system that can be used for online portals to confirm that a visitor to the website belongs to the company they say they do) and the user's ANI.
The user transmits this data 11 to the validation server 3, which validates the information against what is held in the reservations management database 2 (step 12). The validation server 3 uses the billing Number and Company Security PIN to check that the user is authorized to register. Additional data may be automatically derived from the user-provided data 11 by retrieval of data from the reservations management system 2 during the registration process 12. For example, the user's ANI may be compared with a list of authorised numbers to retrieve the user's other details.
Correctly validated user data is then stored in a database 5 (step 15) for subsequent retrieval. If the validation step 12 fails, the validation server 3 executes further exchanges with the user to help him enter the data properly.
When validation succeeds, the validation server 3 generates a prompt 13 for the user to generate a voice announcement 16 for use in any future use of the facility. This announcement is recorded and maintained as an audio file 41 in the database 5 with the ANI and other data relating to the user.
Instead of an audio recording 41, the user may generate a text message 161 which is again stored, as a text file 42, in the database 5. A further variant allows such a text file 42 representing the user's name to be retrieved from the reservations management system database 2 as part of the validation process 12, 15, again for storage in the database.
Once a user is authorised to use the conference facility, he may now use it to connect to a specific conference residing on a bridge 6, as will now be described with reference to
The user first uses the previously-registered terminal 1 to dial into a dedicated conference phone number (step 20). This number is advised to the user as part of the registration process. The number may be stored in the terminal 1 using short-code or voice-activated dialling to simplify connection.
An Interactive Voice Response system forming part of the server 4 collects the user's ANI, and collects user information associated with that ANI from the database 5 (step 21). This data includes the voice file 41 (
The server 4 then generates a message 24 greeting the user, and instructing the user to press a key on his telephone's keypad to open his account. A user 1 may register to access more than one conference, in which case, as part of the welcome message 24, the user 1 is invited to identify the conference to which he wishes to be connected: for example different keystrokes 25 on the user terminal 1 may be used to initiate connection to different conferences on the bridges 6.
In response to the required keystroke (25), the server requests the user to wait to be joined into his conference, and initiates a dial-out to the user's bridge 6, (step 28). The server 4 then generates an announcement 29 that the user 1 is about to join the conference. During this process, some comfort noise or holding message 27 may be played into the user's line to confirm that he has not been disconnected.
In the embodiment of
Such messages can be generated by a speech synthesiser, incorporating the user name as a voice file 41 at the appropriate point in the message.
In the alternative embodiment of
The audio variant, generated by the user himself, ensures that the user's name is pronounced in the way he wishes. However, the text file allows easier integration with the rest of the message, and can be generated in circumstances, such as a noisy environment, in which generation of an audio file may be difficult.
