REGISTER  |  SIGN IN
United States Patent5754636
Bayless , ; et al.May 19, 1998
Title
Computer telephone system
Abstract
A telecommunications system (10) is provided that provides for telephone functions to be accessed through client computer system (14). A server computer system (16) provides telephony services, database services and access to E-mail, voice mail, video conferencing and facsimile systems. A graphical user interface 116 is presented to a user to allow the user to perform a large number of functions and to access databases of information associated with calling and called parties.
Inventors:Bayless; Jeanne A. (Plano, TX), Black; William B.  (McKinney, TX), Brannick; Gary L.  (Plano, TX), Lee; Gene W.  (Plano, TX), Lloyd; Lora M.  (Plano, TX), Mason; Larry P.  (Fairview, TX), Mathis; Amy L.  (Plano, TX), Steenbergen; James E.  (Los Gatos, CA), Stoldt; Mark R.  (Allen, TX), Young; Garrett C.  (Garland, TX), Young; Gary C.  (Dallas, TX), Fissel; James E.  (Arlington, TX), Withers; Robert W.  (Maryland Heights, MO)
Assignee:Answersoft, Inc. (Plano, TX)
Appl. No.:804233
Filed:February 21, 1997
Current U.S. Class:379/142.1 379/207.03 379/207.12 379/207.15 379/245 
Field of Search:379/127,130,131,142,96,97,199,201,245,265,266,309
U.S. Patent Documents
4924496May 1990Figa
5054055October 1991Hanle
5077788December 1991Cook
5097528March 1992Gursahaney
5117452May 1992Callele
5152012September 1992Schwob
5210789May 1993Jeffus
5341414August 1994Popke
5349638September 1994Pitroda
5379030January 1995Nolan et al.
5388150February 1995Schneyer
5393713February 1995Schwob
5511117April 1996Zazzera
Other References
Declaration of Gary C. Young Pursuant to Rule 1.132..~
Primary Examiner: Kuntz; Curtis
Assistant Examiner: Shankar; Vijay
Attorney, Agent or Firm:Baker & Botts, L.L.P.
Parent Case Text


CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of application Ser. No. 08/333,058, filed Nov. 1, 1994, entitled "Computer Telephone System" by Jeanne A. Bayless, et al., now abandoned.
Claims

What is claimed is:
1. A method for displaying the locality and state from which a first party is participating in a telephone call with a second party, comprising:
receiving ANI or Caller ID data for the telephone call;
identifying the locality and state from which the first party is calling by using the ANI or Caller ID data to access a database of localities and states, the database directly associating ANI or caller ID data values with localities and states; and
displaying the locality and state to the second party to the telephone call.

2. The method of claim 1 wherein the ANI or Caller ID data used to identify the locality and state from which the first party is calling comprises the area code of the first party.

3. The method of claim 1 wherein the ANI or Caller ID data used to identify the locality and state from which the first party is calling comprises the area code and the exchange of the first party.

4. The method of claim 1 wherein the displaying step comprises displaying the locality and state where the first party is located during the call on a computer monitor.

5. A method for displaying the local time at a locality and state from which a first party is participating in a telephone call with a second party, comprising:
receiving ANI or Caller ID data for the telephone call;
processing at the geographic location of the second party at least a portion of the ANI or Caller ID data to determine the local time at the locality and state at which the first party is located, the processing comprising identifying the locality and state from which the first party is calling by using the ANI or Caller ID data to access a database of localities and states, the database directly associating ANI or caller ID data values with localities and states; and
displaying the local time to the second party to the telephone call.

6. The method of claim 5 wherein the processing step further comprises processing ANI or Caller ID data comprising the area code of the first party.

7. The method of claim 5 wherein the processing step further comprises processing ANI or Caller ID data comprising the area code and the exchange of the first party.

8. The method of claim 5 wherein the displaying step comprises displaying the local time on a computer monitor.

9. The method of claim 5, the step of processing further comprising:
retrieving a time stamp representing the time at the place where the second party is located;
retrieving conversion data from a database using at least a portion of the ANI or Caller ID data as an index to the database;
determining the local time using the time stamp and conversion data.

10. The method of claim 9 wherein the retrieving conversion data step uses ANI or Caller ID data comprising the area code and the exchange of the first party as an index.

11. The method of claim 9, further comprising:
retrieving a date stamp representing the date at the place where the second party is located.

12. The method of claim 9, wherein the conversion data includes data about whether the place at which the first party that is participating in the call is on daylight savings time.
Description


TECHNICAL FIELD OF THE INVENTION

This invention relates generally to telecommunications systems, and more particularly to software and telephone systems that may be used to allow for telephone operations to be performed using personal computers.

BACKGROUND OF THE INVENTION

Telephone systems have been previously developed for use with personal computers. Existing systems, however, are often difficult to use and contain only a limited number of features that users may desire. Such systems do not normally provide robust interfaces to other communications devices such as systems for electronic mail, voice mail, video, facsimile, etc. Many existing systems also are designed for a particular type of computer and may not be easily converted for use on different types of computers. Similarly, the software for many existing systems is difficult to modify to add additional features.

For example, software systems have been provided that display computerized versions of the telephone keys available to the user of the actual telephone. These software systems seek to replicate the telephone interface in order to capitalize on a user's familiarity with that interface. These systems do not take advantage of the flexibility possible in a purely graphical user interface.

In addition, prior systems have not fully capitalized on the ability to identify incoming calls and the ability to build and use a database of information about called and calling parties. While prior art systems have provided some automated directory services, they have not provided the full range of database processing with the flexibility of a graphical user interface.

Therefore, a need has arisen for a software telephone system that provides for database directory service and incoming call identification as well as presenting the user with a fully functional telephone system using a flexible graphical user interface.

SUMMARY OF THE INVENTION

According to one embodiment of the present invention, a telecommunications system is provided that is constructed using a client server architecture. Client processes reside on personal computers available to each user of the system. These personal computers are connected to one another and to a server computer through a local area network. The server computer is connected to a private branch exchange (PBX) which is, in turn, connected to desktop telephone units available to each user. An application program compatible with a typical windowed environment runs on each personal computer to provide each user with a graphical user interface through which each user may receive and place calls and use other telephone functions. In addition, each client computer may access the server computer, as necessary, to access the PBX or to access database information stored in or managed by the server computer. The server computer itself may comprise another personal computer or a larger computer actually storing the information or the server may act as a gateway to information stored on other platforms.

The novel architecture of the present invention allows for a wide variety of telecommunications services to be provided to each user through a highly flexible and efficient graphical user interface. For example, according to one aspect of the present invention, the local time and location of a calling party of a telephone call is displayed for the benefit of a user of the system. In order to accomplish this feature, the system captures automatic number identification (ANI) or Caller ID or DNIS information data for the telephone call. In addition, the system may capture information input by the calling party. This information might be input by the calling party in response to an Interactive Voice Response system. At least a portion of the ANI or Caller ID data may then be used to access database information to determine the place of origin and the local time of the calling party. The local time and place may then be displayed to the user of the system.

This information allows a user to more efficiently communicate with the other party to the call. The present invention may also allow the city and state from which a caller is calling to be displayed to a user of the system. This again allows for more efficient communication between the parties.

According to another embodiment of the present invention, the amount of time a call has been on hold may also be displayed for each telephone call currently in progress with a particular user. Because the hold time may be displayed for each call separately, the user may readily determine how long each party has been on hold and may, for example, handle calls in order from the longest to the shortest time on hold. Because a hold timer is maintained for each call to a user, an employer of the user may log hold timer data for use in monitoring the employee's performance in answering and processing calls in an expeditious manner.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the present invention and the advantages thereof may be acquired by referring to the following descriptions taken in conjunction with the accompanying drawings in which like reference numbers indicate like features and wherein:

FIG. 1 illustrates a computer telephone system constructed in accordance with the teachings of the present invention;

FIG. 2 illustrates a computer system that may be used in the computer telephone system illustrated in FIG. 1;

FIG. 3 illustrates a second embodiment of a computer telephone system constructed in accordance with the teaching of the present invention;

FIG. 4 illustrates an embodiment of a server that may be used in the computer telephone system of FIG. 1;

FIG. 5 illustrates a window that may be used with a GUI object builder of the present invention;

FIG. 6 illustrates a screen which may appear while using the GUI object builder;

FIG. 7 illustrates objects that may be created by the user of the GUI object builder;

FIG. 8 illustrates an architecture for a GUI object builder;

FIG. 9 illustrates two views of the tool bar for the GUI object builder, one in design mode and one in run time mode;

FIG. 10 illustrates an embodiment of the architecture that may be used to allow multi-user access to a single user database;

FIG. 11 illustrates an example of a database control process that may be used to provide multi-user access to a single user database;

FIG. 12 illustrates an embodiment of an in-memory database constructed in accordance with the teachings of the present invention;

FIG. 13 illustrates an embodiment of a method to achieve automatic updates of shared records in the computer telephone system of FIG. 1;

FIG. 14 illustrates a directories window that may be used with the present invention;

FIG. 15 illustrates the directory window of FIG. 14 with multiple directories opened simultaneously;

FIG. 16 illustrates an add directory window that may be used to add additional directories to the computer telephone system illustrated in FIG. 1;

FIG. 17 illustrates a directory properties window that may be used to customize the properties of directories used in computer telephone system 10;

FIG. 18 illustrates the directory customization window that may be used to further customize phone directories used in computer telephone system 10;

FIG. 19 illustrates an embodiment of a process that may be used to add and customize directories for computer telephone system 10;

FIG. 20 illustrates a custom dial plan window that may be used to create custom dial plans for use with computer telephone system 10;

FIG. 21 illustrates a custom dial plan associated with an exemplary telephone number;

FIG. 22 illustrates an extended phone number information window that may be used to associate a dial plan with a telephone number in the computer telephone system of FIG. 1;

FIG. 23 illustrates a make and answer calls preferences window that may be used to set the dial plan override feature in the computer telephone system of FIG. 1;

FIG. 24 illustrates an example procedure that may be used to add or update a custom dial plan in the computer telephone system of FIG. 1;

FIG. 25 illustrates an example of a process that may be used to add or update a phone number in a directory using the computer telephone system of FIG. 1;

FIG. 26 illustrates a procedure that may be used to implement a dial plan override feature in the computer telephone system of FIG. 1;

FIG. 27 illustrates a color coded folder that may be associated with a directory entry used in the computer telephone system of FIG. 1;

FIG. 28 illustrates a color coded folder that may be associated with a directory entry used in the computer telephone system of FIG. 1;

FIG. 29 illustrates a color coded folder that may be associated with a directory entry used in the computer telephone system of FIG. 1;

FIG. 30 illustrates a color coded folder that may be associated with a directory entry used in the computer telephone system of FIG. 1;

FIG. 31 illustrates an import window that may be used to import directory information from other applications for use with the computer telephone system of FIG. 1;

FIG. 32 illustrates a network directory services import window that may be used to import information using Novell's Netware Directory Service (NWDS) in the computer telephone system of FIG. 1;

FIG. 33 illustrates an example of a procedure that may be used to implement the Netware/network directory services import feature for use with the computer telephone system of FIG. 1;

FIG. 34 illustrates a make and answer calls window that may be used with the computer telephone system of FIG. 1;

FIG. 35 illustrates an example of a process that may be used to display all active calls in a call window in the computer telephone system of FIG. 1;

FIG. 36 illustrates a call window for a user with no calls in progress for the computer telephone system of FIG. 1;

FIG. 37 illustrates a call window for a user with a single call in progress in the computer telephone system in FIG. 1;

FIG. 38 illustrates a call window for a user with a conference call and another call and a non-conferenced call in progress using the computer telephone system of FIG. 1;

FIG. 39 illustrates a block diagram of the system used to arrange a call window for the computer telephone system of FIG. 1;

FIG. 40 illustrates a flow chart of a procedure used to update the call window of FIG. 39 in accordance with telephony events received by the computer telephone system of FIG. 1;

FIG. 41 illustrates how call information may be displayed in expanded or compressed form in the call window that may be used with the computer telephone system of FIG. 1;

FIG. 42 illustrates a make and answer calls preferences window that may be used to set user preferences in the computer telephone system of FIG. 1;

FIG. 43 illustrates an example of a procedure that may be used to change the size of a call object based upon a size preference setting set in the window of FIG. 42;

FIG. 44 illustrates call information that may appear in a call window used with the computer telephone system of FIG. 1;

FIG. 45 illustrates an example of a process used to display call information in a hierarchical fashion in the call window illustrated in FIG. 44;

FIG. 46 illustrates a hold timer displayed for a call received by a user of the computer telephone system of FIG. 1;

FIG. 47 illustrates a procedure used to maintain a hold timer for each call received or placed by a user of computer telephone system 10;

FIG. 48 illustrates an example of a procedure used to display the city and state and local time of a caller participating in a call with a user of a computer telephone system construction according to the teachings of the present invention;

FIG. 49 illustrates how a user of computer telephone system 10 may only be presented with valid telephone functions depending upon the various states of a telephone call;

FIG. 50 illustrates a state table used by computer telephone system 10 to maintain the proper display illustrated in FIG. 49;

FIG. 51 illustrates an example of a procedure used to display only valid telephone function options to a user of the computer telephone system of FIG. 15;

FIG. 52 illustrates a window that shows how a user may create a teleconference in a single step for the computer telephone system of FIG. 1;

FIG. 53 illustrates the result of creation of a teleconference using the window of FIG. 52;

FIG. 54 illustrates an example of a procedure used to implement the single step conferencing feature illustrated in FIGS. 52 and 53;

FIG. 55 illustrates the availability of a conference all control button used with the computer telephone system of FIG. 1;

FIG. 56 illustrates the result of pressing the conference all button of FIG. 55;

FIG. 57 illustrates a procedure used to implement the conference all feature illustrated in FIGS. 55 and 56;

FIG. 58 illustrates the ability of a user of the computer telephone system of FIG. 1 to conduct selective conferencing;

FIG. 59 illustrates the result of a user creating a selective conference using the window illustrated in FIG. 58;

FIG. 60 illustrates a procedure used by the computer telephone system illustrated in FIG. 1 to implement the selective conferencing feature;

FIG. 61 illustrates a procedure used by the computer telephone system illustrated in FIG. 1 to implement the selective conferencing feature;

FIG. 62 illustrates how a call may be added to an existing teleconference in a single step using the computer telephone system of FIG. 1;

FIG. 63 illustrates the results of adding a telephone call to an existing teleconference using the window illustrated in FIG. 62;

FIG. 64 illustrates an example of a procedure used to add a new call to an existing teleconference as illustrated in FIGS. 62 and 63;

FIG. 65 illustrates a merged call option feature used with the computer telephone system illustrated in FIG. 1;

FIG. 66 illustrates a window that results from pressing the merge call control button illustrated in FIG. 65;

FIG. 67 illustrates the availability of a merge call control option when more than two calls are displayed in a call window in a computer telephone system of FIG. 1;

FIG. 68 illustrates the result of pressing the merge call button for the window illustrated in FIG. 67;

FIG. 69 illustrates the call window after two calls have been merged using the window illustrated in FIG. 68;

FIG. 70 illustrates procedures used to implement the merge call feature for the computer telephone system of FIG. 1;

FIG. 71 illustrates procedures used to implement the merge call feature for the computer telephone system of FIG. 1;

FIG. 72 illustrates how some or all calls in a teleconference may be controlled by call control buttons for a conference controller used with the computer telephone system of FIG. 1;

FIG. 73 illustrates the result of controlling all calls in a conference using the window of FIG. 72;

FIG. 74 illustrates the display of valid phone features in the computer telephone system of FIG. 1;

FIG. 75 illustrates speed dial icons used with the computer telephone system of FIG. 1;

FIG. 76 illustrates a speed dial set-up window used with the computer telephone system of FIG. 1;

FIG. 77 illustrates a window used to search for a name in a directory with the computer telephone system of FIG. 1;

FIG. 78 illustrates a window used to search for a name in a directory with the computer telephone system of FIG. 1;

FIG. 79 illustrates the results of searching for a name using the search defined in the windows illustrated in FIGS. 77 or 78;

FIG. 80 illustrates how searching for a name may be done using a partial string of the name in the computer telephone system of FIG. 1;

FIG. 81 illustrates the results of searching using the partial string illustrated in FIG. 80;

FIG. 82 illustrates the search of a name in a directory entry in the computer telephone system of FIG. 1;

FIG. 83 illustrates the result of the search of FIG. 82 when only one name was found in the directory for the search string;

FIG. 84 illustrates extended phone number information that allows a user to establish a primary number in the computer telephone system of FIG. 1;

FIG. 85 illustrates how a primary number is dialed as a result of a search for the name of the party found during the search using computer telephone system of FIG. 1;

FIG. 86 illustrates a procedure used to search for directory entries in the computer telephone system of FIG. 1;

FIG. 87 illustrates a global search window used to conduct a global search of the directories of the computer telephone system illustrated in FIG. 1;

FIG. 88 illustrates a redial list generated by the computer telephone system of FIG. 1;

FIG. 89 illustrates an unanswered calls list generated by the computer telephone system of FIG. 1;

FIG. 90 illustrates an example of a procedure to generate the redial list of FIG. 88;

FIG. 91 illustrates a procedure used to generate the unanswered calls list of FIG. 89;

FIG. 92 illustrates a more digits feature used with the computer telephone system of FIG. 1;

FIG. 93 illustrates the operation of the dial more digits feature used with the computer telephone system of FIG. 1;

FIG. 94 illustrates the operation of the dial more digits feature used with the computer telephone system of FIG. 1;

FIG. 95 illustrates the operation of the dial more digits feature used with the computer telephone system of FIG. 1;

FIG. 96 illustrates an example of a procedure to implement the dial more digits feature for use with the computer telephone system illustrated in FIG. 1;

FIG. 97 illustrates an example of a procedure used to implement the dial more digits feature for use with the computer telephone system illustrated in FIG. 1;

FIG. 98 illustrates a procedure used to transfer call information with a call in the computer telephone system of FIG. 1;

FIG. 99 illustrates a window used with a voice mail tool provided as part of the computer telephone system of FIG. 1;

FIG. 100 illustrates a window used with a voice mail tool provided as part of the computer telephone system of FIG. 1;

FIG. 101 illustrates a window used with a voice mail tool provided as part of the computer telephone system of FIG. 1;

FIG. 102 illustrates a window used with a voice mail tool provided as part of the computer telephone system of FIG. 1;

FIG. 103 illustrates a window used with a voice mail tool provided as part of the computer telephone system of FIG. 1;

FIG. 104 illustrates a window used with a voice mail tool provided as part of the computer telephone system of FIG. 1;

FIG. 105 illustrates a window used with a voice mail tool provided as part of the computer telephone system of FIG. 1;

FIG. 106 illustrates a window used with a voice mail tool provided as part of the computer telephone system of FIG. 1;

FIG. 107 illustrates a window used with a voice mail tool provided as part of the computer telephone system of FIG. 1;

FIG. 108 illustrates an example of a procedure used to implement a voice mail feature used with the computer telephone system of FIG. 1;

FIG. 109 illustrates an example of a procedure used to implement a voice mail feature used with the computer telephone system of FIG. 1;

FIG. 110 illustrates an example diagram of a voice mail system interfaced using software included with the computer telephone system of FIG. 1; and

FIG. 111 illustrates an example of a procedure used to log calls for the computer telephone system of FIG. 1.

DETAILED DESCRIPTION OF THE INVENTION

The present invention and its advantages are best understood by referring to FIGS. 1 through 111 of the drawings, like numerals being used for like and corresponding parts of the various drawings.

SYSTEM ARCHITECTURE

FIG. 1 illustrates an embodiment of a computer telephone system 10 constructed in accordance with the teachings of the present invention. Computer telephone system 10 comprises a plurality of telephones 12, a plurality of client computer systems
14, a server computer system 16 and a Private Branch Exchange (PBX) 18. Each telephone 12 may be connected to PBX 18. Each client computer system 14 may be, for example, a general purpose digital computer such as an IBM-compatible personal computer running the Microsoft DOS operating system and the Microsoft Windows operating environment. Each client computer system 14 may be connected to server computer system 16 using a computer network 17. Computer network 17 may comprise an ethernet or token ring local area network or a wide area network. Server computer system 16, for example, may be a general purpose computer that may also comprise a suitable IBM-compatible personal computer. Server computer system 16 may be connected to PBX 18. Server computer system 16 and client computer system 14 may also be connected to other systems such as, for example, a voice mail system (not explicitly shown). Server computer system 16 may actually comprise several independent hardware servers, each responsible for providing separate services to the client computer system 14. In addition, there may be a plurality of each type of service provided to a client. For example, a single client 14 may be serviced by more than one database server, central office telephone line, E-mail system or PBX. For example, a single hardware server system may be dedicated to providing access to PBX 18 while a separate server computer is dedicated to providing database services to client computer system 14. In addition, server computer system 16 may act as a gateway to remote systems such as mainframe or other database storage systems connected to server computer system 16 through, for example, a wide area network.

A client computer system 14 may serve as a hardware platform to run, for example, one or more application programs 20, one or more client service providers 22 through 34 and an operating system 36. Applications 20 may provide various services to a user using client service providers 22 through 34. Each of the client service providers 22 through 34 may access internal or external hardware and software through operating system 36 to provide services to applications 20.

The embodiment illustrated in FIG. 1 gives several examples of client service providers that may be used with computer telephone system 10. Other client service providers may also be used. Client service providers 22 through 34 may include database client service provider 22, network client service provider 24, telephony client service provider 26, E-Mail client service provider 28, voice mail client service provider 30, video client service provider 32 and fax client service provider 34.

Similarly, server computer system 16 may comprise operating system 38 and server service providers 40 through 54. Server service providers 40 through 54 may interact with client computer system 14 to provide services to client computer system
14. Server service providers 40 through 54 may also interact with other internal or external hardware or software such as PBX 18 to aid in providing services to client computer system 14. Server service providers 40 through 54 may use operating system
38 to interface with client computer system 14 and PBX 18. As shown in FIG. 1, server service providers 40 through 54 include database server service provider 40, network server service provider 42, telephony server service provider 44, PBX interface server service provider 46, E-Mail interface server service provider 48, voice mail interface server service provider 50, video interface server service provider 52, and fax interface server service provider 54.

FIG. 2 illustrates a general purpose computer system 56 that may be used for client computer system 14 and/or server computer system 16. General purpose computer system 56 may be adapted to execute any of the well known, MS-DOS, PC-DOS, OS2, Unix Motif, MAC-OS.TM., X-Windows, Windows.TM. Operating Systems or other environments. General purpose computer system 56 comprises microprocessor 58, random access memory (RAM) 60, read-only memory (ROM) 62, mouse 64, keyboard 66, and input/output devices, such as printer 68, disk drives 70, and display 72. The present invention includes computer software that may be stored in RAM 60, ROM 62, or disk drives 70 and is executed by microprocessor 58. It will be recognized that disk drives 70 may include a variety of types of storage media such as, for example, floppy disk drives, hard disk drives, CD ROM drives, or magnetic tape drives.

FIG. 3 illustrates a second embodiment of computer telephone system 10 constructed in accordance with the teachings of the present invention. Although most aspects of the present invention are described below in the context of a client/server architecture such as that illustrated in FIG. 1, the present invention may also be used with a Centrex system such as that illustrated in FIG. 3.

In the embodiment illustrated in FIG. 3, computer telephone system 10 comprises general purpose computer 56, and telephone 12. Computer telephone system 10 is connected to central office 80 through Centrex line 76. General purpose computer 56
is connected to central office 80 using telephone interface software 78 and Centrex line 76.

To allow all functions of computer telephone system 10 to be utilized with the embodiment illustrated in FIG. 3, both client software 82 and server software 84 are executed on general purpose computer 56. However, various functions, such as database services can still be provided remotely through network connections or similar mechanisms. Client software 82 may interface with server software 84 using various modules contained in client software 82, server software 84 and operating system
36. Client software 82 may include one or more applications 20, and one or more of the client service providers 22 through 34 described previously. Server software 84 may include one or more server service providers 40 through 54 described previously. For example, E-mail server 48 is shown and telephony server 44 is shown coupled to central office 80 in FIG. 3. In addition, database server 40 is shown. Database server 40 is shown coupled to a remote database server 41 which may optionally provide additional database services and may be coupled to computer 56 through, for example, a wide area network. Although computer telephone system 10 may employ a client/server architecture, the same general purpose computer 56 may serve as the hardware platform for the software systems associated with both client computer system 14 and server computer system 16 described previously.

The client/server architecture may allow multiple client computer system 14 to make `virtual` connections to one or more servers 16 such as, for example, a telephony server. Communications between client computer system 14 and server computer system 16 may be performed using a two-way highway of communication. Two-way communication may occur, for example, using two different mechanisms.

First, an event may cause a message to be generated and sent to the other side of the virtual connection. The receiver of the message will pick up the message and act upon it. In this type of communication, no back propagation of success or failure will normally be generated as it is informational only. For example, telephony server service provider 44 may send a message to a client computer system 14 to communicate that a telephone call has been received by PBX 18 and is directed at the client computer system 14. Client computer system 14 may receive this message and may enable certain user interface options which may represent service requests such as requests for answering the call. Server computer system 16, however, may not listen for any success indication as the message is informational only. Server computer system 16 normally will not track the success or failure of the message action. Server computer system 16, however, may track whether the message was picked up and, if not, may store information about the call in a call received database for later retrieval by client computer system 14. The concept of server computer system 16 tracking whether events generated by it are picked up by client computer system 14 should be considered to be distinct from the concept of whether actions taken by a client computer system 14 due to a message were successful or not.

A second type of communication may include a request for service. Ordinarily, when this type of communication is used, a requester process is blocked from further requests until server computer system 16 completes the servicing of the request. In the case of multiple threading of processes, multiple requests may be made by the requester because the requester may spawn child processes which carry out the action of requesting the service and handling request errors. Child processes may generate new messages to send to the parent upon successful completion such that the parent process may update any user interface tools or data structures.

In order to implement computer telephone system 10 for an array of possible service providers, such as telephony or database service providers, a mapping program may map telephony requests to the formats used by different service application program interfaces (APIs) such as the Telephony Application Program Interface (TAPI) used by Microsoft and Intel and/or the Telephony Services Application Program Interface (TSAPI) used by Novell and AT&T. The mapping program may also bypass the mapping functions and serve as an API for various services. Computer system 10 may also be used with various PBX systems and/or first party services. The ability of computer telephone system 10 to interface with various service providers allows client applications 20 to target the mapping program without regard for the first or third party API set required to carry out requests.

Computer telephone system 10 may also be used with an automated client reconnect feature. As with any client/server technology, server computer system 16 may have down time which can present problems for client computer system 14 who have connections that are no longer valid. Computer telephone system 10 may employ an automatic client reconnect mechanism in which server computer system 16 notifies client computer system 14 when it becomes operational. During down time for server computer system 16, requests from client computer system 14 are terminated using network time outs. During time periods when a particular client system 14 is down, all calls logs are still maintained by server computer system 16.

Although various aspects of the present invention are described in the context of a client/server architecture, other architectures could be used to serve as a platform for the features described herein. The present invention is not limited to the context of a client/server architecture.

FIG. 4 illustrates an embodiment of server computer system 16 that may be used in computer telephone system 10. Server computer system 16 comprises client support service provider 86, server service providers 40 through 54, low level service providers 88 through 98 and event processor 104. Client support service provider 86 communicates with server service providers 40 through 54, which in turn communicate with low level service providers 88 through 98. Each server service provider may be associated with a low level service provider such as low level voice mail service provider 88, low level video service provider 90, low level database service provider 92, low level E-mail service provider 94, low level fax service provider 96, and low level telephony service provider 98.

An exemplary embodiment for low level telephony service provider 98 is illustrated in FIG. 4. Each other low level service provider 88 through 96 may include components similar or identical to low level telephony service provider 98. In addition, although not explicitly shown, each other low level service provider 88 through 96 may also communicate with event processor 104 in the manner to be described.

Low level telephony services provider 98 comprises request queue 100, event queue 102 and switch interface server service provider 46. In operation, telephony server service provider 44 receives telephony service requests from client support service provider 86. Telephony server service provider 44 provides these requests to request queue 100 using an API. Request queue 100 sends these requests to switch interface server service provider 46. Switch interface server service provider 46
sends requests to and receives messages from PBX 18. After receiving a message from PBX 18, switch interface server service provider 46 sends these messages to event queue 102 using an API. Event queue 102 may send the messages to event processor 104
that may then send notifications to client computer system 14.

In some instances, telephony server service provider 44 may determine that PBX 18 is not capable of performing a request. In such a case, telephony server service provider 44 may generate a message directly and place it in event queue 102 or send the message directly to event processor 104 although the connection between these blocks is not explicitly shown in FIG. 4.

The architecture of computer telephone system 10 is designed to be information-independent as the client server architecture is capable of creating a virtual connection between a client and server regardless of the type of information to be communicated. Moreover, the system may be implementation-independent as the architecture employs API's to access implementation-dependent hardware and software. The use of APIs and especially the mapping program of the present invention isolates the various components of the system architecture from the machine dependent variables of systems providing services to those components.

Because of the implementation-independent and information-independent nature of the client/server architecture, any number of low level service providers may be supported. For example, low level database service provider 92 may include the in-memory database system described below, a multi-user database system, or a single user database system with the multi-user virtual interface described below. The embodiment illustrated in FIG. 4 employs both an in-memory database and a single user database with the multi-user virtual interface described below. This embodiment may use the C-tree database engine available from Faircom or the Btrieve database engine available from Btrieve. Other database software may also be used by interfacing appropriate APIs.

GRAPHICAL USER INTERFACE TOOLS

Computer telephone system 10 may include a graphical user interface (GUI) to provide an interface between a user and an application 20. In this embodiment a graphical user interface can be created using a GUI object builder. The GUI object builder may have a design mode and a run time mode which allows a designer to visually build an application by specifying the windows, window contents, and the behavior of all components of the system. The GUI object builder may receive messages and generate requests as necessary to other components of the system of the present invention. Each object of the GUI object builder is capable of making requests to, and receiving messages from, any external system to which application 20 interfaces. For example, each object is potentially capable of causing telephony requests and receiving messages related to telephony events.

FIG. 5 illustrates a window 106 used in the design mode of the GUI object builder. Window 106 comprises tool bar 108 which contains a plurality of objects 110. In this embodiment, each object 110 may be represented by an icon. When an application designer presses on an icon, the GUI object builder causes an object of that type to be created. Table 1 lists the objects 110 associated with each icon illustrated in FIG. 5 according to the icon's position. Other objects could also be used with the GUI object builder.

TABLE 1 ______________________________________ Window with Tool Bar Window and Status Line Button ______________________________________ Label Icon Bit Map Rectangle Tool Bar List Button List Edit Timer Object Text Entry Container Multi Column List Box Sub Window Radio Button Select Icon Rich Text Scroll Text Check Box Folder Multi Column List Multi Column Button List Edit Clipping Label Button Menu Password Multi Line Edit Scrollable Container ______________________________________

FIG. 6 illustrates a screen which may appear on display 72 while using the GUI object builder. After the designer clicks on an object 110 using the mouse 64, that object is dynamically created. Double clicking on an object with the mouse or highlighting an object and pressing the "enter" key causes the object detail window 112 appears on display 72 to allow the designer to define various details about the object.

A mouse pointer whose position is controlled by mouse 64 may appear on display 72. The phrase "click the mouse," or variants thereof, refers to pressing a button on mouse 64 when the mouse pointer is located on top of a certain object on display
72.

As illustrated, the designer may assign various properties to the object as well as define how the object reacts to an event. Specifically, for each event, the designer may specify one or more actions that should be taken in response to an event in a user defined order. Events may correspond to systems mentioned above such as the graphical user interface, the telephony system, database system, E-mail system, fax system, video system, and/or voice mail system. Examples of GUI events may include a button being pressed on mouse 64, the mouse pointer being moved, or an object being disabled. Telephony events may include a call being placed on hold, a call arriving, or a call being terminated.

In the design mode, the output of the GUI object builder may be external files that contain the layout and behavior of each designer-created object. These definition files may be input directly in the run time mode of the GUI object builder. No compilation is required, although a compiler may be used to create a more compressed image of the information and decrease load time. Definition files are platform independent and may be created by the design tool of the present invention running on any of the supported platforms and used automatically in all supported platforms without any conversion.

Object definitions may be arranged in a hierarchial manner. For example the levels from highest to lowest may be application, window, designer defined objects, and core objects. Examples of core objects may include buttons, labels, text entries, multi-column list boxes and folders. A designer may combine core objects into higher level objects and assign names to them.

FIG. 7 illustrates several higher level objects that have been created by a designer and duplicated in Window2 as shown. Specifically, FIG. 7 illustrates a number of low level objects such as the numeric labels and buttons. These low level objects have been grouped into a high level object of a window labeled "Window2".

FIG. 8 illustrates the architecture of an embodiment of GUI object builder 114. GUI object builder 114 comprises GUI 116, event action processor 118, system interfaces 120 through 130, network interface 132, start-up control 134 and object definitions storage 136. During design mode, designer 138 creates an application by defining objects that are stored in object definition storage 136. The remaining components of GUI object builder 114 are primarily used in run time mode, although the designer 138 may create object definitions 136 using GUI 116 (not explicitly shown).

GUI object builder 114 is driven by event action processor 118. Event action processor 118 may be considered to be an application 20. Event action processor receives messages associated with all events from GUI 116 and each of the interfaces
120 through 130. Event action processor 118 interacts with GUI 116 and each of the interfaces 120 through 130 using requests. Each request may be initiated by an event. Event action processor 118 maintains the state of objects and systems and can be queried at any time. Queried states are returned as messages to objects, which, in turn, initiate requests responsive to the received messages.

Event action processor 118 receives object definitions upon start-up from start-up control 134. Start-up control 134 retrieves object definitions from object definition storage 136.

Graphical user interface 116 may be part of operating system 36 and interfaces with devices such as mouse 64 and display 72. Event action processor 118 may be an application 20. Telephony interface 120, database interface 122, E-mail interface
124, voice mail interface 126, fax interface 128 and video interface 130 are each a part of the corresponding client service provider 22 through 34. Network interface 132 is controlled by network client service provider 24. GUI object builder 114
automatically adjusts to the mode of operation being in design mode or run-time mode.

FIG. 9 illustrates how tool bar 108 may change depending upon the mode of GUI object builder 114. In design mode, tool bar 108 shows low level objects used for design as illustrated in the window labeled OBJDSGN. In run time mode, however, tool bar 108 may become a launcher used for launching applications created with GUI object builder 114. The window labeled InTouch2 illustrates tool bar 108 in run time mode.

SINGLE USER DATABASE SYNCHRONIZATION

Computer telephone system 10 may be used with a database system designed to be used only by a single user. Multiple user access to a single user database may be provided using a database control process. In this embodiment, all access requests to the database are sent through the control process. The control process analyzes incoming requests to ensure that a current unit of work is not intermixed with other database requests. A unit of work may be defined as a group of database requests enclosed within a begin request and an end request. During a unit of work, database access is limited to only the process executing the unit of work except that Read Only units of work which are not the currently executing unit of work are permitted to execute unless the currently executing unit of work has requested exclusive control of the database. If exclusive control has been requested then read only requests are queued.

FIG. 10 illustrates an example of an architecture for allowing multiple user access to a single user database. Each client computer system 14 sends database requests through database control process 140. Database control process 140 may be, for example, part of the database server service provider 40. Database control process 140 controls database transactions with single user database 142. Read queue 144 and update queue 146 aid database control process 40 handling request which are not part of the current unit of work and must be deferred until later.

In general, the theory of operation of database control process 140 is to execute requests that are part of the current unit of work and queue those requests that are not part of the current unit of work. Two different queues are maintained by database control process 140. The first queue, read queue 144, stores read requests and the second queue, update queue 146, stores update and add record requests. When database control process 140 executes the END request, signaling the end of the current unit of work, it pulls the next queued request from read queue 144 and begins execution of the new request. When read queue 144 is emptied, database control process 140 then pulls a request from update queue 146. This process continues until read queue 144 and update queue 146 have been emptied. Read queue 144 contains those database requests which do not update the database files. Update queue 146 may contain those database requests which will alter the database files.

The above method of operation is designed to send only atomic operations to database 142. By grouping the execution of requests that make up whole units of work, database 142 operates as if only a single user is accessing the database.

FIG. 11 illustrates a flow chart of one embodiment of database control process 140. In step 148 a database request is received by database control process 140 and it is determined whether a unit of work is currently active. As discussed above, a unit of work is active when database control process 140 is processing a database request. In step 148, therefore, database control process 140 is checking to see whether any database request is currently being processed. If a unit of work is not active, the current request may be executed and execution proceeds to step 150. In step 150, a time out timer is set in case the stream of database requests from a client computer system 14 is interrupted. Should transmission of a database request from a client computer system 14 be interrupted, the timer that was set in step 150 may cause an interrupt. Interrupts may occur after a predetermined amount of time such as, for example, thirty seconds. When the interrupt occurs, the current unit of work is discarded.

After each database request is executed in step 152, execution proceeds to step 154 where it is determined whether the end of a particular unit of work has been received. If not, execution proceeds to step 156 where database control process 140
pauses and waits for the next database request. If, however, the request executed in step 152 was the end of a unit of work, then execution proceeds to step 158.

In step 158, database control process 140 determines whether read queue 144 is empty. If so, flow then proceeds to step 162 where it is determined whether update queue 146 is empty. If read queue 144 is not empty, a request is pulled off of read queue 144 in step 160, followed by a return to step 148.

Returning to step 162, if it is determined that update queue 146 is empty, then database control process 140 pauses and waits for another database request to be received illustrated in step 166. If update queue 146 is not empty, execution proceeds to step 164 where a pull request is generated to update queue 146. The request pulled from update queue 146 is then processed beginning at step 148.

Returning to step 148, if a unit of work was active when a database request was received, then execution proceeds to step 168. In step 168, database control process 140 determines whether the owner of the currently active unit of work generated the request received in step 148. If so, then that request is executed in step 152. If not, then execution proceeds to step 170.

In step 170, it is determined whether the request received at step 148 is a read request. If so, then the request is put on read queue 144 as illustrated in step 174. Database control process 140 then pauses in step 176 and waits for another database request to arrive. If it is determined in step 170 that a read request was not received, then the request is placed on update queue 146 in step 172. Then, in step 176, database control process 140 pauses to wait for another database request.

The disclosed database control process makes computer telephone system 10 less expensive because multi-user databases tend to be more expensive than single user database systems. As such, the use of database control process 140 results in a cost savings to users of computer telephone system 10.

IN-MEMORY DATABASE ARCHITECTURE

FIG. 12 illustrates an in-memory database 182. In-memory database 182 is a part of database server service provider 40. Most database systems store data on disk drives 70. Often, however, it may be desirable to store data for a database in RAM
60, or in virtual memory. The use of in-memory database 182 may be most desirable where the data for storage in the database will not be maintained permanently and where an application needs fast access to that data.

As illustrated in FIG. 12, in-memory database 182 may receive data record insert/update requests from applications 20. In-memory database 182 may also receive data record retrieval requests from applications 20 and provide those data records to applications 20.

Provisions may be made within in-memory database 182 for efficient storage of variable length data items, sequencing of data based upon application defined keys, and rapid retrieval of data items. In-memory database 182 may employ, for example, an ISAM style database paradigm for storing and accessing data. Records may be stored in any order and one or more indexes may be created to provide an application-determined sequence to the data. In addition, indexes may support the concept of being sparse, meaning that data records must normally meet specific criteria to be included in the index.

In-memory database 182 may be available in two formats, private and shared. A private database may be available for use by a single process. In this context, all memory allocated by the database is private and may not be accessed by other processes running on the machine. Private databases may be most efficient in terms of memory management and data access. However, they normally will not serve more than the creating process. Private memory databases may be created using an API.

Shared databases may be created by a single process and may be available for use by all processes within the system. The creating process may specify, for example, a 128 character name for the database and all processes that provide the correct name may be granted access to the database. Memory used in storing this type of database may be allocated as shared objects. In-memory database code manages access to the appropriate databases created by new processes.

The creator of a database may also specify that a database is read only. In this case, the process creating the database may be the only process permitted to update the database. All other database users may be restricted to reading the database only. Shared in-memory databases may be created using an appropriate API and access to an existing shared database may also be obtained using the appropriate API.

UPDATING OF CLIENT INFORMATION AUTOMATICALLY

Because computer telephone system 10 may employ a client/server architecture, multiple client computer systems 14 may be using shared data simultaneously. Because a client computer system 14 may update a shared record at any time, it is desirable to immediately update information being used by client computer system 14 when that information is changed. For example, when multiple client computer systems 14 are using a phone directory and information for that directory is updated, all client computer system 14 may desire to have that change reflected in the information that they are currently viewing.

FIG. 13 illustrates a flow chart of an example process to achieve automatic updates of shared records in computer telephone system 10. In step 184, a shared database record has just been updated and stored in the database as a result of an update request received, for example, from a client computer system 14. Next, in step 186, it is determined whether the record that was updated is a broadcast record type. A broadcast record type is a record shared by multiple client computer system 14
where client computer system 14 desire to know when such a record has been changed. If the record is not of this type, then the process is completed in step 190. If the record is a broadcast record, execution proceeds to step 188.

In step 188 a broadcast synchronization message is sent to all active client computer systems 14. This message informs each client that a database record has been updated and also provides each client computer system 14 with the actual data that was updated. Broadcast synchronization messages are received by a client computer system 14 in step 192. Then, the synchronization message is sent to all active windows as illustrated in step 194. The records sent in step 194 are then processed in step 196 to determine whether that data is currently being displayed in an active window. If the data is not being displayed, then it need not be updated and execution terminates at step 198. If the data is being displayed, the data is updated in all active windows at step 200.

By updating shared data automatically, each client computer system 14 may always display the most current information. A user may avoid using erroneous data that may have been in use by client computer system 14 in the absence of an automatic update.

DIRECTORY FUNCTIONS

Computer Telephone System 10 may include a number of telephone directory features. These features may be supported using computer software running on client computer system 14 and server computer system 16. The features described below may interface with the user through an application 20, various client service providers 22 through 34, operating system software 36, operating system software 38 and various server service providers 40 through 54. The software in the embodiments described below receives input from the user primarily from keyboard 66 and mouse 64 on a client computer system 14 and provides output to the user using display 72 associated with a particular client computer system 14. The embodiments described below may also use databases which use database server service provider 40 on server computer system 16. The features described below may also interface with PBX 18 using telephony client service provider 26, operating system 36, operating system 38, and telephony server service provider 44.

CUSTOMIZABLE DIRECTORIES

Computer telephone system 10 may allow a user to create custom telephone directories. The user may designate whether these directories are to be private or shared. A private directory may be accessed only by the user that created the directory. A shared directory may be accessed by all users of the system. Both private and shared directories may only be updated by the creator of the directory.

VISUAL INDICATION OF PRIVATE/SHARED STATUS OF DIRECTORY

FIG. 14 illustrates a directories window 202 that may be used with the present invention. The window 202 allows a user to visually determine whether a telephone directory is private or shared. A user may create any number of directories and have access to a predetermined number of directories at any one time. In the example illustrated in FIG. 14, the user has access to eight directories. The user may access these directories using directory icons.

In directories window 202 illustrated in FIG. 14, the user currently has eight active directories on toolbar 222. Four of these directories are personal directories while four of these directories are shared directories. Private directories may be represented by private directory icons 208 while shared directories may be represented by shared directory icons 210. A private directory icon 208 may be represented by a folder having a single tab while a shared directory icon 210 may be represented by a folder having multiple tabs. In other words, a user may immediately determine whether a directory is private or shared simply by viewing the icon representing that directory.

DIRECTORY NAME DISPLAY FEATURE

Although icons present an efficient method of presenting a user with a large volume of information, a user will sometimes forget what directory is represented by a specific directory icon such as icons 208 through 210. The present invention allows a user to quickly determine the name of a directory without having to perform a number of steps. A user will normally use mouse 64 when performing operations in directories window 202. In directories window 202, the user may reveal the name of a directory simply by passing the mouse pointer over the surface of a directory icon 208 through 210. The directory name will then appear in the position of directory name indicator 212. Alternatively, the directory name could be displayed beginning underneath the corresponding directory icon 208 through 210.

For example, in directories window 202 illustrated in FIG. 14, the user has passed the mouse pointer (not explicitly shown) over the second private directory icon 208. (This icon has a silhouette of a person.) The name of the directory, "Personal," now appears as directory name indicator 212. The present invention thus allows a user to easily determine the name of a directory represented by an icon without having to perform a series of steps.

AUTOMATIC OPENING OF DIRECTORIES

The present invention allows a user to automatically open one or more directories without having to perform multiple steps or page through a number of menus. Referring again to FIG. 14, a directory may be opened simply by clicking mouse 64 on one of the directory icons 208 through 210. The present invention gives the user a visual indication of which directories are open and which directories are not open. When a directory is open, the background of a Directory Icon 208 through 210 may be light colored. When a directory is closed, the background of a directory icon 208 through 210 may be a shaded color.

For example, in FIG. 14, the left-most private directory icon 208 has a light-colored background and represents an open directory. All other private directory icons 208 and shared directory icons 210 have shaded backgrounds and represent closed directories. In addition, the shading of the directory icon 208 is changed to appear as a "depressed" button when the directory associated with directory icon 208 is active.

As discussed, clicking mouse 64 on one of the directory icons 208 through 210 opens that directory or closes the directory based on the current state of the system and the type of mouse clock performed. When one or more directories are open, their contents are displayed as directory contents 206. The number of entries in that directory may be displayed in directories window 202 with the number of records indicator 204.

The contents of a directory may be displayed in expanded or compressed mode. Clicking the mouse 64 on expand/compress icon 214 may toggle the display of the directory contents 206 between expanded and compressed mode. In expanded mode, directory contents 206 may reflect all numbers in the directory for a particular name. For example, if the directory includes a home phone number, fax number, and mobile telephone number, these numbers will all be displayed in expanded mode. In compressed mode, however, only the one number marked by the user as the primary number is displayed for each directory entry.

The present invention also allows for efficient creation of directories and editing of active directories. For example, a new directory may be added by clicking the mouse on add directory entry icon 216. An entry may be added to an existing directory by clicking mouse 64 on add directory entry icon 218. A user may edit, or add information to, an existing entry in a directory by clicking on open entry icon 220.

MERGED DIRECTORY LISTINGS

Another feature of computer telephone system 10 allows a user to open any number of telephone directories at any one time. These directories may be sorted and merged together and displayed to a user as one continuous directory. A user may choose to sort the directories using any field of the directory data.

FIG. 14, as described above, illustrates a single open directory. FIG. 15 illustrates directory window 202 when multiple directories have been opened simultaneously. All four directories illustrated in FIG. 15 are open, as indicated by the light background of private directory icons 208 and the "depressed" shading of the icons. The present invention may arrange the merged directory listings alphabetically, as illustrated in FIG. 15, but any criteria may be used for sorting the merged directories for display to the user in directory window 202.

To display multiple directories, a user may simply click on the appropriate icon using mouse 64 while holding down a control key. If a user does not desire to open multiple directories, but simply desires to switch from one directory to another, the present invention avoids the need to close the first directory and then open the second directory. Instead, all open directories are closed automatically when the user clicks on a directory icon 208 through 210 for the directory that the user desires to open.

DESIGNATING DIRECTORIES TO PRELOAD AND CUSTOMIZING DIRECTORIES

As discussed above, a user may create a new directory by clicking mouse 64 on add directory icon 216. After add directory icon 216 has been clicked on, add directory window 224 illustrated in FIG. 16 appears. Add directory window 224 allows a user to designate the name of a directory and whether that directory is a private directory or shared directory. After a new directory has been added, the user may designate that directory as the default directory using directory properties window 226
illustrated in FIG. 17. Directory Properties Window 226 may appear to the user after a new directory is created using add directory window 224 in FIG. 16. After the above steps, the user may be given the opportunity to customize the directory.

FIG. 18 illustrates directory customization window 228. The present invention allows the user to enter a caption to be displayed when the mouse pointer passes over the corresponding directory icon 208 through 210 as described above. The user can also choose a unique icon for each directory. Directory customization window 228 also allows a user to designate whether or not to preload the directory when directories window 202 is first opened. In other words, a user may desire certain directories to always be opened when the user uses computer telephone system 10. The user may specify these directories by designating a preload for each such directory in directory customization window 228.

A user may designate preload in the embodiment illustrated in FIG. 18 by causing an X to appear in preload box 230. The user may cause an X to appear in preload box 230 by clicking mouse 64 on preload box 230. If user clicks again on preload box 230, the X will disappear and the directory will not be preloaded when directory window 202 first opens.

FIG. 19 illustrates a flow chart of an example process by which directories may be added and customized. In Step 232, it is determined whether the user wishes to add a directory which is private. If the user wishes to add a private directory, the directory is added as private in step 234. If the user desires a shared directory, the directory is added as a shared directory in step 236. Execution from step 234 or step 236 proceeds to step 238 where it is determined whether the user desires to set the new directory as the default directory. If the user does not desire to set the new directory as a default directory, the initial directory becomes the default directory in step 242. If the user does desire the new directory to be the default directory, the new directory is set as the default directory in step 240.

Execution from steps 240 and 242 then proceeds to step 244 where it is determined whether the user desires to add the directory to the directories toolbar 222. If the user does not desire to add the directory to the directories toolbar 222, execution proceeds to Step 246 where it is determined whether the user desires to delete a directory from the toolbar 222. If so, execution proceeds to step 250 where the directory's presence is removed from the toolbar 222. Note that directories that are removed from the toolbar 222 still exist but are simply not accessible from the phone directory toolbar 222. After a directory is removed, the procedure terminates in Step 248.

If no directory is to be deleted from toolbar 222, the process terminates in step 248. If the user did desire to add a directory to the directory toolbar 222 in step 244, the directory is added to the toolbar 222 in step 245. After the directory is added, the user has the option of adding a caption to the directory in step 252. If the user chooses to add a caption, that caption is added in step 253. If the user does not desire to place a caption on the directory, the caption automatically takes on the directory name in step 254.

Execution proceeds from steps 253 or 254 to step 256 where the user indicates whether he desires to preload phone directories. If the user does not desire to preload phone directories, the directory and its entries are set to be loaded on demand in step 258. If the user does desire to preload phone directories, the directory is set to be preloaded in step 257. After executing steps 257 or 258, the user sets the icon position on toolbar 222 for the new directory in step 260.

PORTABLE PHONE NUMBERS

Computer telephone system 10 may also include customized dial plans that may be separate from the phone numbers. Each phone number stored in a directory may be associated with a dial plan. Dial plans may be used to automate the dialing of access codes, PIN numbers, credit card numbers and other numeric dial strings. For example, a user may desire to use one telephone credit card for personal calls and another telephone credit card for business calls. In computer telephone system 10, a user can establish a dial plan for each credit card and use each dial plan when appropriate. If a user always calls certain numbers for business, the user may designate the appropriate dial plan to be used with those numbers.

FIG. 20 illustrates custom dial plan window 262 that may be used to create a custom dial plan. The user may give each dial plan a name by entering dial plan name 264. A user will often need to use a network prefix to obtain an outside line. For example, in an office environment, the user may sometimes have to dial 9 to obtain an outside line. In the example illustrated in FIG. 20, 9 has been entered as a network prefix. After entering a network prefix, some delay typically occurs before an outside line may be accessed. The comma after the 9 in network prefix 266 indicates that the system should pause for a predetermined time after the 9 has been entered.

The user may also include an access number 268 and authorization code 270 in a custom dial plan. Sometimes, a user needs to dial access number 268, followed by the phone number that the user is calling, followed by authorization code 270. Other times, however, the access number 268 and authorization code 270 both must be dialed before dialing the phone number. The present invention allows the user to designate the dial order using dial order selection 276. In the example illustrated in FIG.
20, the user has selected the order--access number 268, phone number, authorization code 270.

Some phone systems also require an access number 268 to be entered before making both local and toll calls. For example, some businesses monitor outside phone usage of their employees using unique access numbers 268. Local call selection 272
and toll call selection 274 allow a user to designate whether to send an access number 268 with each local call and/or with each toll call. Local call selection 272 and toll call selection 274 may also allow the user to either send or not send an authorization code 270 with each local call or with each toll call.

Custom dial plan window 262 also can display the dial string 278 that will be dialed when the user makes a call. Dial string 278 is updated dynamically as data is entered in other fields to give the user a viausl indication of what digits will be dialed. In this example, the network prefix "9", will be dialed, followed by the access number "567," followed by the phone number to be dialed, followed by the authorization code "6578".

FIGS. 21 and 22 illustrate how a dial plan may be associated with a telephone number. FIG. 21 illustrates directory entry window 280. Directory entry window 280 may display a directory entry for one particular person. In this example, directory window 280 illustrates the directory entry for Bob Atkins. Each directory entry may include a phone number folder 282 which lists a plurality of phone numbers associated with that directory entry. In this example, Bob Atkins has four phone numbers associated with his directory entry--his office number, fax number, pager number and extension.

Each number may have the same dial plan assigned to it or different dial plans may be associated with each number. If no dial plan is associated with a number, a default dial plan may be used when dialing that number. Phone number folder 282
may indicate whether a dial plan has been selected for a given number by the presence or absence of a dial plan icon 284. In this example, dial plan icon 284 appears only after the first phone number for Mr. Atkins. This indicates that a dial plan has been associated with this number, but the other three phone numbers for Mr. Atkins will use a default dial plan.

A user may assign or unassign a dial plan to a particular phone number using extended phone number information window 288. The user may also change the selected dial plan using this window. A user may access extended phone number information window 288 by clicking mouse 64 on extended phone number information icon 286.

Turning to FIG. 22, an example extended phone number information window 288 is illustrated. This window 288 is for the first phone number in phone number folder 282 illustrated in FIG. 21. The user may associate or disassociate a dial plan with the number by clicking mouse 64 on dial plan on/off icon 290. The user may choose which dial plan to associate with the number using dial plan select bar 292. When the user clicks the mouse on dial plan select bar 292, a list of available dial plans may appear and the user need only scroll down and select the appropriate dial plan.

An advantage of the present invention is that a user may easily use computer telephone system 10 on a portable computer while traveling. A user need only design a call plan for the particular location. For example, hotels often have telephone systems where a series of numbers must be dialed to obtain access to an outside line. If a user is in such a hotel, the user may simply create a new dial plan and use computer telephone system 10 with that new dial plan.

Because a user may need to use a different dial plan while traveling, computer telephone system 10 may provide a way to override dial plans that have been associated with numbers in a directory. FIG. 23 illustrates make and answer calls preferences window 294. In window 294, the user may use dial plan option select 296 to override all dial plans associated with numbers in the directory. A user may turn on the override feature by clicking mouse 64 on override dial plan box 298. Clicking on override dial plan box 298 a second time may turn the override feature off. In this example, the override dial plan has been selected.

After the user has chosen to override existing dial plans assigned to specific numbers, the user may indicate which dial plan to use for all calls by using dial plan select bar 300. This dial plan will then be used for all calls that are made from computer telephone system 10 for that user.

A user may also travel on business to a different area code or exchange. The user may indicate to computer telephone system 10 both the area code and exchange where the user will be using computer telephone system 10. Computer telephone system
10 may then determine whether any call made by the user is a local call or a toll call using an area code/exchange database. In certain area codes, all exchanges are local calls, while in other area codes, calls between certain exchanges are toll calls. In large cities, like Chicago, a city may have multiple area codes such that calls between two different area codes are still local calls. Accordingly, a database of area codes and exchanges may be used to determine whether a call to a particular area code or exchange is a local call or a toll call. As long as the user indicates the proper area code and exchange from which he is calling, computer telephone system 10 will dial the correct number of digits in accordance with the selected dialing plan.

FIG. 24 illustrates a flow chart of an example procedure for adding or updating a custom dial plan. In step 302, a dial plan name may be entered by the user. If a dial plan name is not entered, then the user may select an existing dial plan in step 304. If a user does enter a dial plan name, then that dial plan name is stored at step 306 and will be used for the dial plan. In step 308, all relevant information for the dial plan may be entered. Then, in to step 310, the dial plan may be saved in accordance with information added by the user.

FIG. 25 illustrates an example procedure for adding or updating a phone number in a directory. In step 312, the user enters the phone number digits. The user then has the option in step 314 of accepting a default type of number or creating a new type. If the user desires to create his own type, flow proceeds to step 316 where the user may choose a phone number type from the list. If the user desires to use a default type, the default may be assigned in step 318.

Execution from step 316 or 318 proceeds to step 320 where the user is given the option of accepting the default telephone directory in which the directory entry will be placed. If the user desires to use the default directory, that directory is assigned at step 321. If the user does not desire to use the default directory, the user is given the option in Step 322 of selecting a private directory. If the user desires to place the entry in a private directory, the user may select the appropriate private directory at step 326. If the user does not desire to select a private directory, the user may select a shared directory at step 324.

Execution then proceeds to step 328 from any of steps 321, 324 or 326. In step 328, the user may choose to assign a custom dial plan to the phone number. If the user does choose to assign a custom dial plan, that dial plan is assigned in step
332 using extended phone number information window 288 as described above. If the user does not desire to assign a custom dial plan to the number, the system default dial plan is assigned to that number in step 330. From step 330 or 332 execution proceeds to step 334 where the phone number record is added to a database.

FIG. 26 illustrates an example procedure for the dial plan override feature. In step 334, the user enters a phone number on the make and answer calls window dial pad. All data about the phone number entered may be returned from the database at step 336. After the data has been received, the system determines in step 338 whether the make and answer calls dial plan override is turned on. If dial plan override is turned on, then the override dial plan selected in dial plan select bar 300 will be used in step 340 to dial the number. If dial plan override is not on, the system then determines whether the phone number has a custom dial plan assigned to it in step 342. If a custom dial plan has been assigned, the dial plan that is associated with the number is used to dial that number in step 344. If no dial plan has been associated with the number, then the default dial plan may be used to dial the number in step 346.

COLOR CODED DIRECTORY ENTRY FOLDERS

FIGS. 27 through 30 illustrate folders that may be associated with each directory entry. Again, the directory entry for Bob Atkins has been used as an example. FIG. 27 illustrates phone number information folder 282. FIG. 28 illustrates business information folder 352. FIG. 29 illustrates personal information folder 354. FIG. 30 illustrates notes folder 356. These folders illustrate the information that may be stored for each entry in a telephone directory.

The present invention employs several features to make computer telephone system 10 easier to use. First, folders 282, 352-356 have both a text entry and an icon on their tabs. Second, the folders may have color coded borders to indicate which folder is active.

Existing systems do not typically display both an icon and textual information on the tab of a folder. In this embodiment, both icons and text may be placed on the tabs of folders 282, 352-356 to allow a user to more easily determine which folder he desires to access.

Each folder 282 may also have a color coded folder border 350. In this example, phone number folder 282 has a blue border (not explicitly shown), business information folder 352 has a green border (not explicitly shown), personal information folder 354 has a red border (not explicitly shown) while notes folder 356 has a yellow border (not explicitly shown). These borders may only be displayed when the particular folder associated with the folder is active. Color coded borders allow a user to immediately recognize which folder is currently active on the screen simply by recognizing the color of folder border 350.

Folder icons 348 may also be color coded such that folder icons 348 have the same color as folder border 350 when the corresponding folder is currently being displayed. In this way, the user may easily associate the color coded folder border 350
with a particular folder using a similarly colored folder icon 348.

DIRECTORY IMPORTING

The present invention allows a user to import phone directories created for other applications. The user may import these records using, for example, a text file wherein each line of the text file has a record to be entered and each field in the record is separated by a delimiter which may comprise, for example, a comma. The user may design a map for the import using import map window 358 as illustrated in FIG. 31.

Import map window 358 comprises database map window 360, file value window 362 and constant window 364. In file value window 362, each field in a record from the file to be imported is displayed on a separate line of the window. A position number is assigned to each field in the record. If a field is missing, no entry will appear for that position. For example, in FIG. 31, position number 6 for the record being displayed was empty. The user may scroll through all fields in a record using the scroll bar on the right hand side of file value window 362.

The user can create a map for performing the import using database map window 360. The first column of database map window 360 displays the fields available for importation in a directory. The user may scroll through all fields available in a directory using the scroll bar on the right hand side of database map window 360. In column 2 of database map window 360, the user uses drag and drop from the file value window to the database map window.

For example, by viewing records to be imported in import window 358, the user can see that position 3 for imported records represents a name prefix. Accordingly, the user would pick up from position 3 and drop on the name prefix. Once a position for the imported field has been assigned to a particular directory field, the data associated with the current record from the import file being viewed may be displayed in column 3 of database map window 360. The user need not designate the position to be associated with each field using a single record. Instead, the user may view other records using the previous record and next record keys in import window 358. A user may then determine what type of data should have appeared, for example, at position 6 of an imported record. When the user has finished designating the mapping in database map window 360, the user may simply save the map to a file and perform the importation using the saved map.

Import window 358 makes importation easy for a user because the values to be imported are displayed in import window 358. The user is thus allowed to view the actual data to be imported, allowing easy creation of a mapping in database map window
360. Computer telephone system 10 has an additional novel feature. Often, a piece of data may not appear in an import file because the application from which the data is being imported did not support inclusion of that type of data. For example, some systems will not allow a user to specify a company name. If a user knows that the same company name is to be used for all records being imported, the user may specify that company name using constant window 364. The user may enter the constant to be used in constant window 364. That constant may then be associated with one of the fields shown in column 1 of database map window 360. When an importation occurs, the constant from window 364 will be used for that field in all records.

The present invention also allows importation of Novell's Netware network directory services information. FIG. 32 illustrates Netware import window 366 that may be used to set parameters for a Netware network directory services search. Netware import window 366 comprises schedule window 368, phone number format window 370, and Netware parameter window 372.

In schedule window 368, a user may set a time to do a Netware directory services import each day. In phone number format window 370, the user may specify whether a full number is to be imported and if not, how many digits are to be imported. In Netware parameter window 372, the user may specify the base object, context, and search filter for the search and also the directory into which the data may be imported.

FIG. 33 illustrates an example Netware directory services search process that may be used in computer telephone system 10. The process begins at step 374 where it is determined whether it is time to do a Netware directory services import. If not, the process returns to step 374. If it is time to do a Netware directory services import, execution proceeds to step 376 where a network directory services search is performed using the search criteria previously entered by the user. After the search has been completed, the user's phone book is updated at step 378 for each match found during the search in step 376. After step 378, the process may repeat itself by returning to step 374. Because Netware directory services are commonly used, this aspect of the invention allows a user to use computer telephone system 10 of the present invention with an existing system. Users of computer telephone system 10 may thus have access to changes made in phone numbers by other network users that continue to use Netware network directory services.

MAKE AND ANSWER CALLS TOOL

Each user of computer telephone system 10 may be provided with a make and answer calls tool for making and answering telephone calls. This make and answer calls tool has many novel features which make a telephone easy to use, more efficient to use, and more powerful The make and answer calls tool runs as one of the application programs 20 described previously.

SIMULTANEOUS CALL DISPLAY--ALL ACTIVE CALLS DISPLAYED IN WINDOW

The present invention allows information for all calls currently in progress to be displayed on a user's screen. FIG. 34 illustrates make and answer calls window 380. Make and answer calls window 380 may include call window 390 for displaying information about each telephone call in progress.

In call window 390, a call object 388 may be displayed for each call in progress. Each call object 388 may include a call status object 382 and a call information/control object 384. Scroll bar 386 may be used to scroll call window 390 to view all calls displayed in call window 390.

Call status object 382 may include information about each call. For example, in the embodiment illustrated in FIG. 34, call status object 382 may display information as to whether a call is active, on hold, conferenced, etc. Call status object
382 may also display the corresponding user phone number on which the call was received or placed. For example, in FIG. 34, the call with Mark Stoldt is on extension 5207 and is "on hold". Call status object 382 may also display information as to how long a call has been in progress and as to how long a caller has been on hold. In the example illustrated in FIG. 34, the call from Larry Mason has been in progress for eight minutes twenty seconds while the call has been on hold for sixteen seconds.

Call status object 382 may also visually indicate whether a call is currently selected or not. When a call is selected, the user may perform various functions on the call. In the example illustrated in FIG. 34, call status object 382 indicates that a call is selected by displaying a light background for call status object 382. A call which is not selected may have a shaded background for call status object 382.

Call information/control object 384 displays information about the party to the call with whom the user is speaking. For example, call window 390 in FIG. 34 is displaying a call from Mark Stoldt of AnswerSoft, a call from extension 5174 in Plano, Tex., and a call from Eric Lambiase of AnswerSoft at extension 5171 in Plano, Tex. Call information/control object 384 also contains phone function buttons that may be controlled by the user for that particular call. For example, the calls that are on hold in FIG. 34 display the "Off Hold" option while the active call displays both the "Hang Up" and "Hold" option. As will be discussed herein, an important advantage of the present invention is that the options presented to the user are not static but depend on the state of the call. As such, a call that is already on hold does not have a "Hold" button or, in other words, a user is only presented with meaningful function choices at any state of a call.

The present invention, therefore, provides a telephone system 10 that may allow a user to simultaneously view all calls currently in progress with that user. The user need not remember which call was on which line because information about the call appears in call information/control object 384. The user also can easily determine how long a call has proceeded or how long a person has been on hold by looking at call status object 382. The present invention thus gives the user immediate visual access to important information about calls in progress.

FIG. 35 illustrates an example of a process that may be used to display all active calls in call window 390. In step 392, a telephony session is established to monitor all calls for a particular device that may be associated with a user. Then, a telephony event is received at step 394. The process next determines in step 396 whether the event is a new telephone call for the device in question. If a new call for the device has not been received, appropriate call status information associated with the call may be updated in step 398 and the process then may loop back to step 392. If a new call has been made or received, execution proceeds to step 400 where a new call status object is displayed in call window 390, along with the appropriate call information. Execution then loops back to step 392.

GROUPING OF CONFERENCE CALLS

The present invention allows call window 390 to dynamically change in size in accordance with the number of calls in progress. Call window 390 may also group conference calls together such that they are illustrated separately within call window
390. This feature of computer telephone system 10 will be described below with reference to FIGS. 36 through 40.

FIG. 36 illustrates call window 390 with no calls in progress. With no calls in progress, call window 390 is small and may not display any information. Make and Answer calls window 380 still displays the extensions available to that user, a make a call button, redial button, and various other control functions available to the user such as do not disturb, speaker phone and the like.

FIG. 37 illustrates call window 390 with a single call in progress from Eric Lambiase at extension 5171 of AnswerSoft in Plano, Tex. Call window 390 has expanded to hold call object 388 for the call in progress. Additional active calls may be added at the bottom of call window 390. At this point, the single active call may be hung up, put on hold, conferenced, transferred or parked. As such, buttons for these functions and only these functions are displayed in call object 388.

FIG. 38 illustrates call window 390 with a conference call in progress and one individual call in progress. In this example, the conference is between the user and two other parties--Larry Mason and Eric Lambiase. The individual call in the example is with Mark Stoldt.

When the user initiates a conference call, the call status objects 382 for the calls participating in the conference are grouped together and displayed with conference controller 402. Non-conference calls can be displayed in a group as well. In the example illustrated in FIG. 38, the group of non-conference calls consists of only one call at the bottom of call window 390.

A user may have several conference calls in progress simultaneously. When this occurs, the user may be presented with multiple conference call containers. Each conference call container may contain a conference controller 402 and the call objects 388 for each call participating in that particular conference. By using a unique conference container for each conference call, these conference calls may be grouped together in discrete units so that the user may keep track of which parties are involved in each conference call and easily move between the conference calls.

Conference controller 402 provides function buttons to allow a user to place all parties to a conference on hold using the hold conference button. A user may also hang up the entire conference by pressing the hang up conference button. The user may release himself from the conference by pressing the drop yourself button. When a party is part of a conference call, that party may be individually dropped or placed on hold using the buttons in call information/control object 384 for that party.

FIG. 39 illustrates how conference containers 404 and a non-conferenced calls container 406 may be arranged in call window 390. In this example, a conference container 404 is included for each conference call in progress. Each conference container 404 contains a conference controller 402 and a call object 388 for each party to that particular conference. Non-conferenced calls container 406 may be placed in call window 390 below the conference containers 404. Non-conference calls container 406 may contain a call object 388 for each call in progress that is not part of a conference call.

A conference container 404 may only be visible when a conference is in progress. The size of each conference container 404 may increase or decrease as call objects 388 are added or removed from a conference container 404. Calls automatically move from the non-conference calls container 406 to the appropriate conference container 404 when those calls are placed in a conference state. In this embodiment, call objects 388 may always be added at the bottom of a container.

FIG. 40 illustrates an example of a procedure that may be used to update call window 390 in accordance with telephony events that may be received from telephony client service provider 26 and/or telephony server service provide 44. In step 408, a telephony event is received. Next, it is determined in step 410 whether the telephony event is a new call. If the telephony event is a new call, a call object 388 is created at the bottom of non-conference calls container 406 at step 422. Then, in step 434, call window 390 is increased to its maximum height or increased to a height high enough to display the new call object 388. Execution then proceeds to step 438 to determine whether the call window is at its maximum height with the new call object 388 not visible. If so, then scroll bar 386 is enabled in step 440. If not, then the procedure is finished.

Returning to step 410, if the telephony event was not a new call, then execution proceeds to step 412 to determine whether the telephony event is a new conference. If the event is a new conference, then step 424 is executed to show the associated conference container 404 and conference controller 402. Execution then proceeds to step 434 to execute the steps described above.

Referring again to step 412, if the telephony event received was not a new conference, it is then determined in step 414 whether a call is being added to an existing conference. If so, then step 426 is executed and the associated call object 388
is moved from the non-conference calls container 406 to the associated conference container 404.

Returning again to step 414, if the telephony event received was not a call being added to a conference, execution then proceeds to step 416 where it is determined whether a party to a conference call is being moved to a non-conferenced status. If so, then the call object 388 for the party being removed from the conference is moved from the corresponding conference container 404 to the non-conference calls container 406 at step 428.

Returning again to step 416, if the telephony event received was not a conferenced party moving to a non-conferenced status then it is determined in step 418 whether a conference is ending. If a conference is ending, then step 430 is executed where the associated conference container 404 is hidden. Next, the size of call window 390 is decreased to a size large enough to make all call objects 388 visible at step 436. Execution may then proceed to step 438.

Returning again to step 418, if the telephony event received was not the end of a conference, then execution proceeds to step 420 where it is determined whether the event was the end of a call. If not, then the procedure terminates. If so, step
432 is executed where the associated call object 388 is hidden. Execution then continues to step 436. It should be noted that in each case where the size of call window 390 is adjusted due to a new call, a new conference beginning or a call or conference ending, that the call objects 388 are rearranged in any manner desired. The illustrated embodiment provides one example of how the windows may be rearranged.

DISPLAY OF CALL/CALLER INFORMATION--OPTIONAL DISPLAY OF INFORMATION IN EXPANDED/COMPRESSED MODE

The present invention allows the user to decide whether they wish to view the call information in call information/control object 384 in an expanded mode or a compressed mode. In the expanded mode, a larger number of lines of call status information and a larger number of call control options are visible than in compressed mode. For example, in the embodiment illustrated in FIG. 41, up to 8 lines of call status information may be displayed in call information/control object 384 and up to 6 call control options may be visible. In the compressed mode for this embodiment, however, only 2 lines of call status information may be displayed and up to 2 call control buttons may be visible.

For each call in progress, a user may choose whether to display that call in expanded mode or compressed mode. In FIG. 41, the user has chosen to display the call from Larry Mason in an expanded mode and the call from Eric Lambiase in a compressed mode.

Because the user may select an expanded or compressed display format for each call object 388, the user may decide how much information to display for each call according to his needs. This allows the most efficient use of the display area of call window 390. The user may change from expanded format to compressed format or from compressed format to expanded format using expand/compress icon 442. In the expanded mode, clicking on expand/compress icon 442 with mouse 64 may cause call object
388 to be displayed in compressed form. In compressed mode, clicking on expand/compress icon 442 with mouse 64 may cause call object 388 to be displayed in an expanded mode.

The present invention also allows the user to designate a default display format in which each call object 388 is displayed when it is first placed in call window 390. The user sets these options using call status size option window 444 located in Make and Answer calls preferences window 294. FIG. 42 illustrates three options that may be used to specify a default initial size for call object 388. A call may be always displayed in compressed mode, always displayed in expanded mode or displayed in compressed mode when on hold, etc., and only displayed in expanded mode when the call is active. In the example illustrated in FIG. 42, the user has chosen to always display calls in compressed mode.

Thus, the size of call object 388 is determined based upon a size preference setting maintained by the user and/or by a user requested mode for a particular call. An example procedure by which computer telephone system 10 determines how to display a particular call object 388 is illustrated in FIG. 43. The procedure illustrated in FIG. 43 begins at step 446 where a telephony event is received. In step 448, it is determined whether this telephony event is a new call. If the telephony event is not a new call, execution proceeds to step 450, where it is determined whether the state of a call has changed. If the state of a call has not changed, then the expanded or compressed display format need not cause an adjustment and the procedure terminates. A state change includes a change in call display formats. If the state of a call did change, execution then proceeds to step 452, where the system may determine whether a user has previously manually expanded or compressed this call. If so, then the size remains unchanged and the procedure terminates. If not, then execution may proceed to step 454.

Execution also may proceed to step 454 from step 448 if a new call was received as a telephony event. In step 454, it may be determined whether a user preference has been set to always display a call in expanded form. If so, then the size of the call may be set to expanded in step 456. If not, then execution proceeds to step 458.

In step 458, the system determines whether the user has set a preference to always display calls in a compressed format. If so, then the size of the call is set to be compressed in step 460. If not, then in step 462, the system determines whether the current state of the call in question is active. If so, then the size of the call is set to expanded form in step 464. If not, then the size is set to be compressed form in step 466. After steps 460 or 466, execution proceeds to step 470. After steps 456 or 464, execution proceeds to step 468.

In step 470, a call is displayed in compressed mode. In this embodiment, up to 2 call control buttons and 2 lines of status information may be displayed while other non-compressed objects are hidden. Execution then proceeds to step 472. In step 468, a call is displayed in expanded mode. In this embodiment, all available call control buttons and all call status information is displayed. Execution may then proceed to step 472. In step 472, the new size for display of a call is compared to the current (previous) size. If the sizes are not equal, the call status object is resized to show only visible objects in step 474. In step 476, call window 390 is resized to accommodate the larger or smaller size of the call that has been changed.

HIERARCHIAL DISPLAY OF INFORMATION IN COMPRESSED MODE

The present invention employs a hierarchial display of information about a phone call in call information/control object 384. FIG. 44 illustrates the hierarchial display of call information possible with the present invention. FIG. 44
illustrates 3 calls in call window 390. The top call is illustrated in expanded mode while the bottom two calls are displayed in compressed mode.

In this example, five lines may be displayed in call information/control object 384 on five information lines: first information line 478, second information line 480, third information line 482, fourth information line 484, fifth information line 486.

In this example for the call objects 388 displayed in compressed mode, only first information line 478 and second information line 480 are displayed in call window 390. More or less lines of information could be displayed in either expanded or compressed mode.

As discussed above, information about a telephone call is displayed in a hierarchical manner. In addition, if information about a call is unavailable, other available information may be displayed. For example, the two most important pieces of information about a call may be the name of a caller and the company from which the caller is calling. If these pieces of information are available for a given call, they are displayed in call window 390 in that call's call object 388. Sometimes, however, this information may not be available If not, it would be desirable to display other lower priority information that is available. For example, if the name of the caller with which the user is connected is not available, the user may desire for the display to show the phone number from which the caller is calling, or the city and state from which the caller is calling.

The present invention allows the highest priority information available about a call to be displayed. Instead of merely displaying empty fields when certain data is unavailable for a call, lower priority data is displayed in place of the missing data.

In the example illustrated in FIG. 44, five pieces of information about the caller are displayed in expanded mode on information lines 478 through 486 using directories stored in telephone system 10. The calls displayed in FIG. 44 will provide only examples of the types of information that may be displayed in call information/control object 384. Other information could be displayed in a hierarchical fashion without departing from the scope and teachings of the present invention.

In the call displayed in expanded mode in FIG. 44, the name of the party with which the user is speaking, Mark Stoldt, is displayed on first information line 478. The company, AnswerSoft, Inc., with which Mr. Stoldt is associated, is displayed on second information line 480. Third information line 482 displays the telephone number to which the user is connected. In other words, third information line 482 displays the number for the telephone from which Mr. Stoldt is calling. In this example, Mr. Stoldt is calling from an extension, 5172.

Telephone system 10 may obtain the number from which the caller is calling using automatic number identification (ANI) or Caller ID. This information may be provided to an application 20 by telephony client service provider 26 and/or telephony server service provider 44. After obtaining the telephone number from which the caller is calling, application 20 may determine the caller's name and company name by looking the number up in one of the directories associated with computer telephone system 10 by making a database access request that is then serviced by client database server 22 and server database service 40.

Fourth information line 484 in FIG. 44 may contain the city and state from which the caller is calling. The manner in which this information may be displayed is discussed below. Fifth information line 486 may display the local time in the city and state from which the caller is calling. The way that this information is determined is also described below.

In this example, the hierarchy of the information is caller name, caller company name, caller telephone number, city and state from which caller is calling, and local time in the city and state from which caller is calling. In expanded mode, all of the available information is displayed in the hierarchial order. In compressed mode, however, a lesser number of information lines 478 through 486 is displayed in call information/control object 384. As described above, only 2 information lines 478
through 480 are displayed in this example.

When a lesser number of information lines are displayed in call information/control object 384, the highest priority available caller information is displayed. In the example in FIG. 44, the bottom call object 388 in call window 390 reflects a call from Eric Lambiase of AnswerSoft, Inc. In this case, the highest priority information, the caller's name and company name were available so that information was displayed. For the middle call object 388 displayed in call window 390, the telephone number of the caller did not appear in a directory so the caller's name and company were not available. In this example, however, the number from which the caller was calling, 5174, and the city and state from which the caller was calling--Plano, Tex.--were available and were displayed in call information/control object 384.

FIG. 45 illustrates a flow chart of an example method that may be used to display call information in a hierarchial fashion. The procedure begins with step 488 where information about the call status is retrieved. Execution then proceeds to step 490 where the procedure determines if the caller's name is available in one of the directories. If the name is available, then the caller's name is displayed in step 492 on first information line 478. If the caller's name was not available, the application 20 determines whether company information for the caller is available at step 496. If so, then execution proceeds to step 494 where the company information is displayed on first information line 478.

Normally, the caller's phone number, city and state from which the call originated, and local time will always be available. The procedure illustrated in FIG. 45 assumes that this information is available. If the information were not available, the procedure could check to see whether each piece of information was available and display only those items of information available on consecutive information lines 478 through 486.

Assuming that phone number, city and state, and local time information are all available, after step 494 has been executed, steps 502, 510 and 518 may be executed. In step 502, the phone number of the caller is displayed on second information line 480. In step 510, the city and state is displayed on third information line 482. In step 518, the local time of the caller is displayed on fourth information line 484.

Returning to step 492, after step 492 has been executed, it is determined in step 498 if company information is available. If company information is available, steps 500, 508, 516 and 524 are executed. In step 500, company information is displayed on second information line 480. The caller's phone number is displayed on third information line 482 in step 508. In step 516, the city and state from which the caller is calling are displayed on fourth information line 484. The local time in the city and state from which the caller is calling is displayed on fifth information line 486 in step 524.

Returning to step 496, if company information was not available, then steps 504, 512, and 520 are executed. The phone number of the caller is displayed on first information line 478 in step 504. Next, in step 512, the city and state from which the caller is calling is displayed on second information line 480. The local time in the city and state from which the caller is calling is displayed on third information line 482 in step 520.

Returning to step 498, if company information was not available, steps 506, 514 and 522 are executed. In step 506, the phone number from which the caller is calling is displayed on second information line 480. The city and state from which the caller is calling is displayed on third information line 482 in step 514. Next, in step 522, the local time in the city and state from which a cal