WO2003028357A1

WO2003028357A1 - Computer telephony integration using email address to establish voice connection

Info

Publication number: WO2003028357A1
Application number: PCT/GB2002/004367
Authority: WO
Inventors: Robert Grenville Brockbank
Original assignee: British Telecommunications Public Limited Company
Priority date: 2001-09-27
Filing date: 2002-09-27
Publication date: 2003-04-03

Abstract

A variation of BT's ClickDial service for users who are also users of the companion data sharing service, ClickData. When an originating user makes a ClickDial call, instead of sending in the MakeCall message the destination number associated with the displayed search entry, the user identity, e.g. email address, that was used for ClickData registration is sent. The CTI controller uses the received user identity to access the ClickData database, retrieve the stored internet protocol address from the found entry, use this retrieved internet protocol address to access the ClickDial database, retrieve the stored telephone number from the found entry, and use this retrieved telephone number as the destination number of the ClickDial call. This enables the originating user to contact the desired destination user at the telephone where he is currently logged on. The ClickData client in a user's computer automatically registers with the ClickData service at startup, so a positive response to an 'Are you there'? message sent from the controller to the destination user's computer ensures that the call will be connected to that user's current location.

Description

COMPUTER TELEPHONY INTEGRATION USING EMAIL ADDRESS TO ESTABLISH A

VOICE CONNECTION

This invention relates to the use of a computer for controlling the operation of a telephony system, such use is known in the art as computer telephony integration (CTI), and the systems employing such control are known as CTI systems.

As a general background, the reader will find examples of such CTI systems disclosed in the articles "Introduction to Computer Telephony Integration", by A. Catchpole, G. Crook, and D. Chesterman, British Telecommunications Engineering, Vol. 1 , July 1 995; "Computer Telephony Integration - The Meridian Norstar", by A. Catchpole, British Telecommunications Engineering, Vol. 14, Oct. 1995; "Computer Telephony Integration - The Meridian 1 PBX", by P. Johnson, A. Catchpole, and L. Booton, British Telecommunications Engineering, Vol. 1 5, July 1 996; "Callscape - Computer Telephony Integration for the Small Business", by G. Hillson, G. Hardcastle, and M. Allington, British Telecommunications Engineering, Vol. 1 5, Jan. 1 997, and "Call Centres - Doing Business by Telephone" by M. Bonner, British Telecommunications Engineering, Vol. 1 3, July 1 994; and "ClickDial Web-Enabled CTI", by R. Brockbank, G. Crook and D. Emerson, British Telecommunications Engineering, Vol. 18, April 1999.

According to a first aspect of the present invention, there is provided a method of operating a computer telephony integration (CTI) system comprising a switch and a CTI controller therefor, and a plurality of user workstations, each workstation comprising a computer connected to the CTI controller and a telephone connected to the switch, the method comprising the steps of:- receiving at the CTI controller from a said computer associated with an originating user a MakeCall request containing a user identifier for a desired destination user and actually or effectively a telephone number of the originating user, hereafter referred to as the originating telephone number; retrieving the user identifier and the originating telephone number; accessing a first database in accordance with the retrieved user identifier to find a first entry associated with the desired destination user, each entry in the first database having a user identifier field and an internet protocol address field; upon finding said first entry, retrieving the content of its internet protocol address field; accessing a second database in accordance with the retrieved internet protocol address to find a second entry associated with the desired destination user, each entry in the second database having a telephone number field and an internet protocol address field; upon finding said second entry, retrieving the content of its telephone number field, hereafter referred to as the destination telephone number; and commanding the switch actually or effectively to make a call from said originating telephone number to said destination telephone number.

Preferably, the user identifier is an email address.

The MakeCall request may additionally contains a default destination telephone number for the desired destination user, and there may be included the steps of sending to the retrieved internet protocol address a message for which a reply is expected, and, in the event that no such reply is received within a predetermined timeout, commanding the switch actually or effectively to make a call from said originating telephone number to said default destination telephone number instead of to said destination telephone number.

According to a second aspect of the present invention, there is provided a computer telephony integration (CTI) system comprising: a switch and a CTI controller therefor; a plurality of user workstations, each workstation comprising a computer connected to the CTI controller and a telephone connected to the switch; a first database in which each entry has a user identifier field and an internet protocol address field; a second database in which each entry has a telephone number field and an internet protocol address field; and wherein the controller is arranged: to receive from a said computer associated with an originating user a MakeCall request containing a user identifier for a desired destination user and actually or effectively a telephone number of the originating user, hereafter referred to as the originating telephone number; to retrieve the user identifier and the originating telephone number; to access the first database in accordance with the retrieved user identifier to find a first entry associated with the desired destination user and to retrieve the content of its internet protocol address field; to access the second database in accordance with the retrieved internet protocol address to find a second entry associated with the desired destination user and to retrieve the content of its telephone number field, hereafter referred to as the destination telephone number; and to command the switch actually or effectively to make a call from said originating telephone number to said destination telephone number.

Preferably, the controller is further arranged: to retrieve from the MakeCall request a default destination telephone number for the desired destination user; to send to the retrieved internet protocol address a message for which a reply is expected; and, in the event that no such reply is received within a predetermined timeout, to command the switch actually or effectively to make a call from said originating telephone number to said default destination telephone number instead of to said destination telephone number.

Specific embodiments of the present invention will now be described by way of example with reference to the drawings in which:

Figure 1 is a schematic diagram showing the general telephony and data arrangement of the present invention.

Acronyms used in the specific description BT British Telecommunications public limited company

CLI Calling Line Identity

CTI Computer Telephony Integration

DN directory number EIN Employee Identification Number

GUI Graphical User Interface

HTML hypertext markup language

IPA Internet Protocol Address NM NetMeeting

PBX Private Branch Exchange

PSTN Public Switched Telephone Network

URL Uniform Resource Locator

In Figure 1 , each of a plurality of users 1 0 (not shown) of a network 1 2 is associated with a respective computer 14 and a respective telephone 1 6 which is an extension of one of a plurality of local CTI-enabled PBXs 1 8 arranged for operation in association with a common CTI server 20. In this specific embodiment the PBXs 1 8 are Nortel Meridians, and the telephones 16 are Meridian Featurephones capable of on hook dialling.

Each of the users 10 is employed by a common employer, in this specific embodiment BT, and has a respective entry in a common corporate telephone directory held on a database 22 which is accessed from the user's computer 14 via the server 20, and for a user to be an originating user in accordance with this specific embodiment of the present invention he needs to be a registered user of both:

(a) a service for making a telephone call by clicking on a MakeCall button associated with the displayed entry for a desired destination user, also referred to as a desired called user, from the common telephone directory, and

(b) a service for sharing data on the originating user's computer with the computer of a desired destination user.

In this specific embodiment, the service (a) is BT's ClickDial service, and the service (b) is BT's ClickData service. As the server 20 is arranged to provide both services, it is referred to as the Click server 20, or in respect of the separate services, as the ClickDial server 20a or the ClickData server 20b, respectively. Before proceeding to describe the particular features of the present invention, to help the reader's understanding a brief description of the individual ClickDial and ClickData services will be given.

BT's ClickDial service

In brief, a user 10 registers with the ClickDial service by accessing a ClickDial Home Page and clicking on a Registration Button in that page. This sends a request message from the user's computer 14 to the ClickDial server 20a, requesting the download of the ClickDial Registration Page. The ClickDial server 20a receives that request, and retrieves the source IPA from its header, generates a nine digit pseudorandom number and includes it in an HTML forms page (i.e. the Registration Page), and sends that page to the user's computer 14. This page has boxes for the user to enter identification data enabling the ClickDial server 20a to access the database 22 and locate the user's entry. The data required is the user's Operational Unit Code and his Employee Identification Number (EIN). Although the EIN is unique and would be sufficient to identify the user, the combination of these two data items provides a degree of security. Aspects of this ClickDial registration procedure are the subject of the applicant's international patent application publication number WO 99/5101 5.

The Registration Page contains instructions requesting the user to make a telephone call from his associated PBX telephone 1 6 to a specified destination DN, which is a DN within the numbering range of a particular PBX 18-CD. On receipt of a call from that user, that PBX 18-CD retrieves the CLI from the signalling information and passes that to the ClickDial server 20a. The ClickDial server 20a instructs the PBX 18-CD to connect that call to a recorded announcement facility 24, and instructs the recorded announcement facility 24 to play an instruction for the user to dial on his keypad the nine digit number displayed on his computer.

The PBX 18-CD reports received digits to the ClickDial server 20a, which then compares the original nine digit number with the digits received at the PBX 18-CD, and, if they match, records that user as an authorised user of the ClickDial service. The user now clicks on a Next button in the Registration Page to send an appropriate message to the ClickDial server 20a, and the ClickDial server 20a responds by creating a ClickDial cookie at the user's computer 14 containing a pointer to a location in the database 22 storing the actual data corresponding to that cookie. For convenience, where a distinction needs to be made, the terms cookie pointer and cookie data are used. In the preferred embodiment, the cookie data comprises the user's DN (known from the received CLI) and the identity of the PBX 1 8 local to that user (retrieved from the database 22 as one of the items of data stored for each user) . The ClickDial server 20a completes its registration procedure by amending a directory cookie at the user's computer 14 to request download of directory search results in ClickDial form instead of normal search result form. In the display of a ClickDial directory search result there is a ClickDial button adjacent to each displayed retrieved entry. This button hides a link of the form: "http://clickdial.bt.co.uk/clickdial7dn = xxxxxxxxxxx" .

The cookie data is stored in an area of the database 22, referred to as the ClickDial database. In variants, the ClickDial database is physically separate from the database storing the corporate telephone directory. Where this separate ClickDial database is in a different domain to that of the corporate telephone directory, the ClickDial server 20a cannot amend the directory cookie, and the user has to be directed to the actual location of the corporate telephone directory for this amendment of the directory cookie.

When the user 10 accesses the directory service and enters the name of a desired called user, the ClickDial server 20a will perform a search in the corporate telephone directory to locate all entries matching that search criterion and send a page displaying the search result, i.e. one or more retrieved entries, each with their associated ClickDial button, i.e. the MakeCall button referred to above. The user clicks on the appropriate ClickDial button, and the browser on that computer is activated in accordance with the corresponding URL which effectively sends to the ClickDial server 20a a MakeCall request containing the contents of the user's ClickDial cookie and the DN associated with that entry. The ClickDial server 20a now accesses the cookie data and sends an instruction, also referred to as a command, to the user's local PBX 1 8 for an originating call to be made from the source DN to the destination DN. With the speed of modern telecommunications, the user hears ringing tone a small fraction of a second after clicking on a ClickDial button.

Instead of the PBX 1 8 making the connection between the source DN and the destination DN by making an originating call from the source DN, the ClickDial server 20a can command the PBX 1 8 to make respective calls to the source DN and the destination DN and to join the separate calls. For the purpose of the present invention, the expression actually or effectively making a call from a source DN to a destination DN, or equivalent language, shall be taken to mean actually making such a call, i.e. as an originating call from the source DN to the destination DN, or effectively making the call by using the joining method referred to above.

BT's ClickData service

Where a user 10 wishes to share data on his computer with the computer of a desired destination user, then both users need to be registered users of a Share Data service and will each run a data sharing application marketed by Microsoft Corporation under the name "NetMeeting" (NM) . As this is a companion service to the ClickDial service, this service has been called ClickData by BT. It will be appreciated that any other alternative data sharing application can be used.

To register for the ClickData service, the user accesses a ClickData Home Page from the ClickData server 20b, which is arranged to provide the ClickData service in addition to its ClickDial service. This page has a button for requesting the download of a ClickData client.

When the user 1 0 clicks the ClickData client download button, a request is sent to the ClickData server 20b, which responds to receipt of this request by downloading the requested ClickData client and an HTML form containing a box for the entry of an email address, a box for the entry of a main contact telephone number, and a request button for creating further boxes for the entry of further contact telephone numbers. The user 10 enters his email address in the form that it is recorded in the corporate telephone directory in the database 22, email address being one of the items of data stored for each user, and one or more contact telephone numbers, and clicks on a Submit button in the form. The ClickData server 20b receives the submitted form, retrieves the email address and uses it to access the corporate telephone directory in the database 22, checks that only one entry is retrieved, i.e. that the email address is unique in the corporate telephone directory, and, if so, generates a unique nine digit pseudorandom number, referred to as the ClickData Key (CDK) or alternatively "password" , emails it to the user 10 at that email address, and creates an entry in a ClickData database in the database 22. This ClickData database entry comprises fields for the CDK, the email address, the contact telephone numbers and an IPA.

In variants, the function of the ClickData database is integrated with the corporate telephone directory by adding appropriate fields to the entries in the corporate telephone directory. In one such variant, the CDK field exists only when the user has registered for ClickData. In another such variant, each entry in the corporate telephone directory has a CDK field, i.e. the CDK is one of the items of data stored for each user, but it will be appreciated that until a user has registered for ClickData his CDK field will contain a null value.

The ClickData server 20b then sends a page to the user containing text appropriate to the condition "OK" to inform him that his email address has been recognised as a unique address in the corporate telephone directory. If, for example, the email address had not been recognised, or more than one entry having that email address had been found, then the text in that page would be appropriate to the condition " NOT OK" .

The user 10 having successfully downloaded and installed the ClickData client, now includes the ClickData client as an application to be run at start up of his computer 14. The user 10 also runs the ClickData client and accesses its configuration area, where he enters his email address, the CDK received by email, his familiar name and his surname, these being referred to as user-name and user-surname. He then clicks on a Register button displayed on the screen, and the ClickData client forwards a message containing that data to the ClickData server 20b.

The ClickData server 20b receives that message, retrieves the source IPA from its header and the data from the payload, accesses the ClickData database with the received email address, retrieves the stored CDK from that user's entry in the ClickData database and compares it with the CDK sent by the ClickData client. If there is a match, the ClickData server 20b sends a message to the user's ClickData client containing "OK" text to inform him that his CDK has been recognised and that he has been registered, and enters the retrieved IPA in the IPA field of that user's entry in the ClickData database. In the variant where the ClickData database is integral with the corporate telephone directory, the IPA is one of the items of data stored for each user, but for this variant it will be appreciated that until a user has registered for ClickData that field will have a null value.

If for any reason the registration had not been successful (i.e. was an invalid registration attempt), the text would have been appropriate to "NOT OK" , and the user would check the data in his ClickData client and click on the Register button again. On receipt of the third successive invalid registration attempt the text in the page will include "CDK removed from Database" or in a variant "CDK removed from Directory", and to continue the user would have to request a new CDK.

There now follows a description of an originating user making a Shared Data call, for which it is necessary for that originating user to be registered for both the ClickDial and ClickData services. The server 20 is designed to run both services, and it is now convenient to refer to the server 20 simply as the Click server 20.

To make the Shared Data call using ClickData, the user looks up the intended recipient, i.e. the destination user, in the common directory held on the database 22, and clicks on the associated ClickDial button. The Click server 20 receives a MakeCall request containing the destination DN and the user's cookie (i.e. the pointer), retrieves the source IPA from the header of that request and the destination DN from the MakeCall request, and retrieves from the user's cookie data his source DN and the identity of his local PBX, and instructs the user's local PBX to make a telephone call to the destination DN.

The Click server 20 searches the ClickData database for the destination DN and, if only one matching entry is found, retrieves the stored IPA of that entry. If no match or multiple matches are found, then no further action as taken, as the destination user is either unknown or ambiguous.

Assuming that only one match was found, the Click server 20 sends a ConfirmData message to both IPAs. In simple terms, it is asking the respective computers "Are you there?"

If ClickData clients are running at those addresses, i.e. the computers have been started up, then they each respond with their registration details, i.e. email address and CDK plus NM version, which the ClickData client will obtain directly from the NM application. For each response, the Click server 20 accesses the ClickData database in accordance with the respective email address, retrieves the stored CDK, and checks that it matches the CDK supplied by the ClickData client. If the supplied CDK matches the stored CDK then that response is termed a successful response.

If both computers make a successful response, the Click server 20 sends to each ClickData client a respective "Can Share Data" message containing the NM version corresponding to the other ClickData client .

If a ClickData client does not send any response within a preset timeout, the Click server 20 searches the ClickData database on the basis of the IPA corresponding to that ClickData client and deletes that IPA from all retrieved entries (also referred to as records).

On receipt of the "Can Share Data" message, the ClickData client displays a "Share Data" button. Both users click on their respective "Share Data" buttons, and their respective ClickData client retrieves the user-name and user-surname from its configuration area, passes this data to the respective NM application for use in the initial information that it sends, launches the respective NM application, and sends a "Ready to Share Data" message to the Click server 20.

When the Click server 20 has received a "Ready to Share Data" message from both computers, it sends a MakeDataCall message to the originating user's ClickData client .

On receipt of the MakeDataCall message, the originating user's ClickData client commands its associated NM application to make a data call to the destination IPA.

The Click server 20 will command Data Call Cleardown procedure on receipt of a clearCall event. Ordinarily, this will be when the originating and destination users have finished sharing data via their NM applications and put their telephone instruments in an on-hook state, but can be at any time after the originating user has initiated a ClickDial call to the destination user. On first receipt of a clearCall event in respect of the originator's DN (or possibly in respect of the destination DN), the Click server 20 sends an EndOfCall message to both ClickData clients. On receipt of the EndOfCall message, each ClickData client closes its associated NM application, if open, and sets its respective GUI to its initial state. The Click server 20 performs housekeeping to complete call records and reset timers, this being particularly needed where, for example, only one ClickData client responded.

The ClickData client also responds to clicking on the "Share Data" button by replacing this button in the GUI with a "Stop Sharing" button, which the user can click at any time during a data call. If the user clicks the "Stop Sharing" button while the telephony call is still in existence, his ClickData client will close its NM. The far end NM will notice that the data session has closed, and will close itself. Both ClickData clients will then revert to their "CanShareData" state, i.e. displaying the "Share Data" button, and thereafter either user can initiate a new data call while that telephony call is still in existence.

It will be appreciated that the destination user does not have to be on a CTI-enabled PBX, or even on a PBX at all. As long as their phone number is in the directory against their name, this described embodiment will work. For example, they could use their mobile number.

Aspects of this ClickData registration procedure are the subject of the applicant's international patent application publication number WO 01 /35602.

Present invention

It will be appreciated from the foregoing description that a user's email address is one of the items of data stored for each entry in the corporate telephone directory. Thus, when the user 1 0 accesses the directory service and enters the name of a desired called user, the displayed search result includes the email address for each entry retrieved by the search, as well as the telephone number.

Whereas in the standard ClickDial service, the originating user selects a displayed retrieved entry, clicks on the appropriate ClickDial button of that entry, and the browser on his computer is activated to send to the ClickDial server 20a a MakeCall request containing the contents of the originating user's ClickDial cookie and the DN associated with that entry, the present invention, in a first embodiment, uses a modified URL to send to the Click server 20 a MakeCall request containing the contents of the originating user's ClickDial cookie and the email address of the selected entry. This modified URL is of the form: "http://clickdial.bt.co.uk/clickdial7email = joe. public@bt.com" .

The Click server 20 receives that MakeCall request and retrieves the IPA from its header, and the contents of the originating user's ClickDial cookie and the email address from respective fields of the request.

The Click server 20 uses the retrieved originating user's ClickDial cookie to obtain the originating user's DN and associated PBX 1 8 identity from that originating user's cookie data, and uses the retrieved email address to access the ClickData database in accordance with the email address to locate the entry corresponding to the desired destination user. From that entry, the stored IPA is retrieved and used to access stored cookie data in the ClickDial database to locate an entry having a matching IPA. If such an entry is found, the DN stored in that entry is retrieved. The Click server 20 is now in possession of the originating user's DN and a destination DN, and proceeds to command the originating user's local PBX 1 8 to make a call from the originating user's DN to the destination DN.

Each time that a user who is registered for the ClickData service starts up his computer 1 4, the ClickData client sends a registration message to the Click server 20 containing the user's email address retrieved from storage in the configuration area. The Click server 20 uses the email address from the received message to locate the user's entry in the ClickData database, and overwrites the stored IPA by the IPA retrieved from the source address field of that received message. By this means the ClickData service copes with changes in IPAs where the network to which the computers 14 are connected uses Dynamic Host Control Protocol to allocate IP addresses, and also with situations where the user is nomadic, e.g. logs on for work at any one of a number of available workstations (referred to as "hotdesking" ), or may use a laptop computer with a modem and log on to the network from a remote location. In this last situation, the remote user registers his mobile telephone for ClickDial use.

Furthermore, the present invention is advantageous where updating of the corporate telephone directory is infrequent or effectively non-existent. A user might move to a different work position, workstation or office, and for some reason the corporate administration might not reprogramme the local PBX to associate that user's initially- allocated DN with the equipment number, i.e. PBX port, corresponding to the new position. Provided that a user is registered for both the ClickDial and ClickData services, the modified ClickDial client of the present invention will enable other users to make ClickDial calls to the called user's current location.

In a second embodiment of the present invention, the modified ClickDial button hides a URL of the form:

"http://clickdial.bt.co.uk/clickdial7email =joe.public@bt.com&dn = xxxxxxxxxxx" . In this case the browser, when activated, sends to the Click server 20 a MakeCall request containing the contents of the originating user's ClickDial cookie and both the email address and the DN of the selected entry.

The Click server 20 receives the MakeCall request and retrieves the IPA from the header, and the contents of the originating user's ClickDial cookie, the email address and the DN from respective fields of the request. As in the first embodiment, the Click server 20 uses the retrieved originating user's ClickDial cookie to obtain the originating user's DN and associated PBX 1 8 identity from that originating user's cookie data, and uses the retrieved email address to access the ClickData database in accordance with the email address to try to locate an entry for a destination user.

If the desired destination user is not registered for the ClickData service, no entry will be found in the ClickData database. In an aforementioned variant, his entry in the corporate telephone directory will have a null entry in the IPA field. Upon failing to find a ClickData database entry, (or in the variant, to retrieve a valid IPA from a located entry in the corporate telephone directory), the Click server 20 defaults to using the retrieved DN for the commanded call. Also, if there is an entry in the IPA field, but the Click server 20 fails to receive a response to the ConfirmData message, then the Click server 20 similarly defaults to using the retrieved DN for the commanded call.

In a variant of this second embodiment, the entries in the corporate telephone directory have a field for a published PSTN number, referred to herein as a public DN, and a further field for a sequence of digits which will result in a ClickDial call being routed via BT's internal telephone network, referred to as a private DN. For each retrieved entry, the Click server 20 sends both the public DN and the private DN to the originating user's computer 14, where a modified search application displays the public DN in the search result, along with any other information, e.g. location details, but does not display the private DN. When the originating user activates the ClickDial button, the browser sends to the Click server 20 a MakeCall request containing the contents of the originating user's ClickDial cookie and both the email address and the private DN of the selected entry. In a further variant, for each retrieved entry of the search result a "public" ClickDial button is associated with the displayed public DN and a "private" ClickDial button is associated with the displayed email address. In this way, the originating user has the option ^'of requesting a call to the desired destination user via either the company's private network or the PSTN. In this variant, the browser responds to a click on the "public" ClickDial button by sending a MakeCall request containing the contents of the originating user's ClickDial cookie and only the public DN of the selected entry, i.e. an assumption is made that if the originating user wanted the call to be delivered to the called user's likely current location, then he would click on the "private" ClickDial button, which would result in the browser sending a MakeCall request containing the contents of the originating user's ClickDial cookie and both the email address and the private DN of the selected entry, and the Click server 20 would respond as described above, first trying to find an up-to-date DN for the called user using the retrieved email address, followed in the event of failure by commanding a call to be made to the private DN.

In the above described embodiments, the ClickData database is physically part of the database 22, but in a storage area separate from that of the corporate telephone directory. In variants, it is physically at a location remote from the corporate telephone directory.

In the above described embodiments, the user's email address is used as a user identifier and for sending the CDK when the user registers for ClickData. Alternatively, another form of user identifier can be used, for example the user's EIN, and the ClickData server can obtain the user's email address by accessing a company email directory using that user identifier. In this alternative, the displayed search results still include the user's telephone number and his email address, but the EIN is received with the search results and stored but not displayed. When the originating user clicks on the button, the message sent includes his cookie and the EIN. The entries in the ClickData database have a field for user identifier, e.g. EIN, instead of the email address field, and the ClickData server accesses this database in accordance with the retrieved user identifier to find the desired entry. As before, once that entry is found, the IPA is retrieved and used to locate that use's entry in the ClickDial database. Whereas in the above embodiment the CTI-enabled switch is a Nortel Meridian PBX, it will be appreciated that the present invention embraces other forms of switching function. For example, the switch can be a public network switch, such as a Nortel DMS100 switch which is used in known CTI arrangements in conjunction with a CompuCall CTI controller; and other forms of switching function include switches known as Automatic Call Distributor (ACD), Interactive Voice Response (IVR), and server PBX. Furthermore, the type of switching is not limited to any one form, and, in addition to switched circuit technology, includes Asynchronous Transfer Mode (ATM) switching, and Voice over Internet Protocol (VoIP) switching. With regard to this last form of switching, the switch can be a PBX having an Internet Card, or it can be a general purpose computer, e.g. one running Windows NT, having an Internet card, e.g. a Dialogic Internet card, and in this latter case the CTI controller function is provided by a program running in the computer, rather than in a separate controller. Furthermore, the telephones 1 6 can be connected to their respective computers (clients) 14 via Internet phone jacks, and in an alternative arrangement telephony can be provided for the user via a sound card in his client.

Thus, it can be seen that in general the present invention can be implemented in any computer controlled switch, by means of a suitable controlling program.

Unless the context clearly requires otherwise, throughout the description and the claims, the words "comprise" , "comprising" and the like are to be construed in an inclusive as opposed to an exclusive or exhaustive sense; that is to say, in the sense of "including, but not limited to" .

Claims

1 . A method of operating a computer telephony integration (CTI) system comprising a switch and a CTI controller therefor, and a plurality of user workstations, each workstation comprising a computer connected to the CTI controller and a telephone connected to the switch, the method comprising the steps of :- receiving at the CTI controller from a said computer associated with an originating user a MakeCall request containing a user identifier for a desired destination user and actually or effectively a telephone number of the originating user, hereafter referred to as the originating telephone number; retrieving the user identifier and the originating telephone number; accessing a first database in accordance with the retrieved user identifier to find a first entry associated with the desired destination user, each entry in the first database having a user identifier field and an internet protocol address field; upon finding said first entry, retrieving the content of its internet protocol address field; accessing a second database in accordance with the retrieved internet protocol address to find a second entry associated with the desired destination user, each entry in the second database having a telephone number field and an internet protocol address field; upon finding said second entry, retrieving the content of its telephone number field, hereafter referred to as the destination telephone number; and commanding the switch actually or effectively to make a call from said originating telephone number to said destination telephone number.

2. A method as claimed in claim 1 , wherein the user identifier is an email address.

3. A method as claimed in claim 1 or claim 2, wherein the MakeCall request additionally contains a default destination telephone number for the desired destination user, and including the steps of sending to the retrieved internet protocol address a message for which a reply is expected, and, in the event that no such reply is received within a predetermined timeout, commanding the switch actually or effectively to make a call from said originating telephone number to said default destination telephone number instead of to said destination telephone number.

4. A computer telephony integration (CTI) system comprising: a switch and a CTI controller therefor; a plurality of user workstations, each workstation comprising a computer connected to the CTI controller and a telephone connected to the switch; a first database in which each entry has a user identifier field and an internet protocol address field; a second database in which each entry has a telephone number field and an internet protocol address field; and wherein the controller is arranged: to receive from a said computer associated with an originating user a MakeCall request containing a user identifier for a desired destination user and actually or effectively a telephone number of the originating user, hereafter referred to as the originating telephone number; to retrieve the user identifier and the originating telephone number; to access the first database in accordance with the retrieved user identifier to find a first entry associated with the desired destination user and to retrieve the content of its internet protocol address field; to access the second database in accordance with the retrieved internet protocol address to find a second entry associated with the desired destination user and to retrieve the content of its telephone number field, hereafter referred to as the destination telephone number; and to command the switch actually or effectively to make a call from said originating telephone number to said destination telephone number.

5. A system as claimed in claim 4, wherein the controller is further arranged: to retrieve from the MakeCall request a default destination telephone number for the desired destination user; to send to the retrieved internet protocol address a message for which a reply is expected; and, in the event that no such reply is received within a predetermined timeout, to command the switch actually or effectively to make a call from said originating telephone number to said default destination telephone number instead of to said destination telephone number.

6. A method of operating a computer telephony integration (CTI) system as claimed in claim 1 , and substantially as herein described with reference to the drawing.

7. A computer telephony integration (CTI) system as claimed in claim 4, and substantially as herein described with reference to the drawing.