Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
SYSTEM WHICH SEAMLESSLY INTEGRATES SEVERAL FORMS OF COMMUNICATION
Document Type and Number:
WIPO Patent Application WO/2001/013582
Kind Code:
A1
Abstract:
A communication system (Fig. 1) and method that makes use of a POP server (106, Fig. 1), a LAN (104, Fig. 1), and offers VOIP.

Inventors:
CONCANNON KENNETH M JR (US)
CONCANNON COLIN M (US)
Application Number:
PCT/US2000/022416
Publication Date:
February 22, 2001
Filing Date:
August 16, 2000
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
CONCANNON KENNETH M JR (US)
CONCANNON COLIN M (US)
International Classes:
H04L12/46; H04L12/58; H04L12/66; H04M3/42; H04M7/00; H04L29/06; H04M3/48; H04M3/523; H04M3/53; H04M7/12; H04Q3/72; (IPC1-7): H04L12/28; H04J3/16; H04L12/413; H04L12/66
Foreign References:
US5867495A1999-02-02
Attorney, Agent or Firm:
Litman, Richard C. (P.O. Box 15035, Crystal City Statio, Arlington VA, US)
Download PDF:
Claims:
CLAIMS We claim:
1. A communications server system for automated routing of communications connectable to a communications network having a local area network (LAN) connected to the Internet and a telephone network, the communications server system comprising: a) at least one server computer connectable to a LAN and a telephone network of a communications network; and b) a server software means executing on said server computer for routing communications through the LAN and the telephone network, including: i) a post office protocol (POP) server means for providing communications between said server computer and a plurality of client computers connected to the LAN using post office protocol; ii) a clientuser database means for storing, relating and retrieving communications routing information; iii) a telecontrol server means for monitoring, switching and controlling communications over the telephone network; iv) a voiceoverInternet protocol gateway means for facilitating the packaging, delivery and reception of all communications between the client computers and the Internet which use voiceoverInternet protocol; and v) a server control means for coordinating the operation of said POP server means, said clientuser database means, said telecontrol server means and said voiceoverInternet gateway means.
2. The communications server system according to claim 1, wherein said POP server means listens on specific ports for client computer systems and is responsible for authenticating and encrypting communications information being received and sent from client computer systems.
3. The communications server system according to claim 1, wherein said clientuser database means provides storage for a plurality of user virtual extension identification markers, virtual extension property information and projects and skills information being worked on by the users of said system.
4. The communications server system according to claim 1, wherein said telecontrol server means comprises software means for managing inbound and outbound telephony from a local private branch exchange (PBX), a public switch telephone network (PSTN) and non PBX telephone number (s).
5. The communications server system according to claim 1, wherein the telephone network is a Private Branch Exchange network and said telecontrol server further comprises means for listening for dual tone multifrequency (DTMF) communications and passing said DTMF communications from said telecontrol server to a local Private branch Exchange telephone network.
6. In a communications network for an organization having a plurality of users, the communications network having a local area network (LAN) connected to the Internet, a plurality of client computers connected to the LAN, a telephone network with a plurality of telephones, each client computer and each telephone being assigned to at least one user, and at least one communications server connected to the LAN, the communications server including a post office protocol (POP) server, a clientuser database, a telecontrol server, a voiceoverInternet gateway, and a control server, the telephone network being connected to the communications server, a communications routing method comprising the steps of: a) assigning a virtual extension to each user in the organization and storing the assignment in said clientuser database; b) for each work project undertaken by the organization, storing a list of users assigned to the project in said clientuser database; c) for each user assigned to a work project, assigning a skill level and storing said skill level in said clientuser database; d) for each incoming communication containing a designation of a recipient by virtual extension, retrieving the user assigned to the virtual extension from said clientuser database and routing the incoming communication to the user so retrieved through the POP server, the telecontrol server or the voiceoverInternetProtocol gateway; e) for each incoming communication without a virtual extension designation but identifying a project, determining a skill level required to respond to the communication, retrieving a user having the required skill level and being assigned to the project and the user's virtual extension from said clientuser database and routing the incoming communication to the user so retrieved through the POP server, the telecontrol server and the voiceoverInternetprotocol gateway; f) for each incoming communication without a virtual extension designation and not identifying a project, identifying the caller, assigning. a virtual extension candidate to the caller, routing the incoming communication to the user so retrieved through the POP server, the telecontrol server, or the voiceoverInternet protocol gateway, and storing the assignment of the virtual extension candidate to the caller in said clientuser database; and g) for each outgoing communication, determining the virtual extension of the user, the recipient of the communication, and a work project associated with the communication, and storing each item so determined in said clientuser database.
7. The method according to claim 6, further comprising the steps of: a) identifying an originating caller of the incoming communication through dual tone multifrequency technology, voice recognition technology, caller ID and automatic number identification (ANI); and b) using the identification of the incoming caller to retrieve the virtual extension from said clientuser database.
8. The method according to claim 6, further comprising the step of utilizing a monitoring calls in progress feature.
9. The method according to claim 6, further comprising the steps of: utilizing a long distance carrier matrix; monitoring existing calls in progress; and saving call information in said clientserver database.
Description:
SYSTEM WHICH SEAMLESSLY INTEGRATES SEVERAL FORMS OF COMMUNICATION TECHNICAL FIELD The present invention relates to the seamless integration of telephone, voice mail, e-mail, fax, paging, Internet, intranet and local area network technologies into a single communications system.

BACKGROUND ART Today's workplace is becoming more complicated than ever.

With the advent of cellular telephones, faxes, e-mails, pagers and the Internet, it can be overwhelming for employees to organize and integrate the information generated by each of these communications systems. The workplace is even further complicated by traveling personnel, home-based offices, multinational offices and a movement by companies to decentralize their workforces. Although all of these things increase efficiency and productivity, they can be very intimidating to use and learn.

Recent pieces of related art have attempted to improve the use of these systems and better organize the information that they generate. The patent issued to Kusaki et al. (U. S. Pat. No.

5,749,053) outlines the use and control of a mobile communications network through base station controllers (BSC). The information on the BSCs is stored by respective local service points (LSP), which can be utilized in a decentralized fashion to accommodate employees who work away from the BSC. The BSC can also request and transfer information outside of its LSPs to another BSC, which is an improvement in the use of BSCs.

Improved communication in a decentralized environment is also described in the patent issued to Ryu (U. S. Pat. No. 5,822,421).

Specifically, a communications method between processors in a decentralized multi-node exchange system is outlined, which enables real-time messaging and response between nodes in the system. This increase in transmission speed is achieved by controlling the interruption of receiving and transmitting messages between nodes in the system. This has an application in serving as a real time communications system between decentralized offices and personnel.

Other improvements are also described in the foreign related art. As described in the European patent by Heinzelmann (European Patent No. 367455), an invention relates to providing phone management services to personal computers (PCs) used in a local area network (LAN). This is done by providing a phone management device by logically associating voice terminals of a separate voice and data network, such as a private branch exchange (PBX), with the Pcs used in the LAN.

A phone management server device acts as an interface between the PC and PBX networks onto which are bridged appearances of the logically associated voice terminals. The server device includes hardware and server application software that perform routing and translations between messages of the PC-LAN, which use a first signaling protocol, and messages of the PBX which use a second signaling protocol. Each user of the PC-LAN that is locally associated with a voice terminal on a PBX network that includes application software, provides a user interface and terminates the first signaling protocol. This enables the two networks to interchange information between each other.

These improvements are relatively small in comparison to improvements described in the two patents written by Staples et al.

(U. S. Pat. No. 5,889,845 and U. S. Pat. No. 5,764,639), which enable a remote user to maintain a virtual presence at a corporate office while outside of the office. This is in effect done by a virtual presence server connected to the corporate office. A remote user is connected to the virtual presence server, which can then instruct the corporate PBX to forward all calls.

The virtual presence server can also route e-mail and faxes as well as extend PBX and LAN features to the user. The remote user can make outgoing phone calls, send faxes, transmit data, send e-mail and perform Internet access, all from a remote venue, just as if the user was actually in the office. However, these communications systems are not seamlessly integrated together. If it were possible to do that with these communications systems, the ramifications would be truly spectacular.

None of the above inventions and patents, taken either singly or in combination, is seen to describe the instant invention as claimed.

DISCLOSURE OF INVENTION A system which seamlessly integrates several forms of communication routed into a single communications system. The system includes a Pop Server, a Client User Database, a TeleControl Server, a Voice-Over-IP Gateway and a Control server, which can be implemented with a user's existing telephone, voice mail, e- mail, fax, paging, Internet, intranet and local area network systems.

BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a block diagram system overview of the present invention.

Figs. 2A and 2B are Hardware Configurations (1 site-N+1 nodes).

Figs. 3A and 3B are Hardware Configurations (N+1-X nodes).

Figs. 4A and 4B are Hardware Configurations (N+1 offices).

Figs. 5A, 5B, 5C are Inbound Telephony Figures.

Figs. 6A, 6B, 6C and 6D are Virtual Extension Processes.

Figs. 7A and 7B are Determine Best Route Figures.

Fig. 8 is a Call in Progress Figure.

Fig. 9 is an End Call Figure.

Fig. 10 is a Pop Server Architecture Figure.

Fig. 11 is a Notification Strategy Figure.

Fig. 12 is a Virtual Extension Candidate Process Figure.

Figs. 13A and 13B Project Skill User Association Figure.

Fig. 14 is a Fax Delivery Process Figure.

Fig. 15 is an Auto Attendant Figure.

Fig. 16 is an Outbound Telephony Figure.

Fig. 17 is an Inbound E-Mail Figure.

Figs. 18A and 18B are TeleControl Architecture Figures.

Fig. 19 are Outgoing Telephony Communication Figures.

Similar reference characters denote corresponding features consistently throughout the attached drawings.

BEST MODES FOR CARRYING OUT THE INVENTION Fig. 1 is a block diagram of the hardware configuration associated with connecting the present invention, an Anytime- Anywhere Technology Server (AAT Server) 105, and a client's local area network (LAN) 104, an Internet connection 101, an e-mail

server 103, a web server 102, a public switch telephone network (PSTN) 121 and a private branch exchange (PBX) 113. The AAT Server 105 is comprised of a POP server 106, a Client User Data Table 107, a TeleControl server 108, a Voice-Over-IP (Internet Protocol) Gateway 109 and a Control Server 110.

The POP server 106 is a transmission control protocol user datagram protocol (TCP/UDP) socket server that listens on specific ports for client systems and is responsible for authenticating and encrypting messages on the server side for communications with clients. The POP server 106 provides user information and availability and distributes information between other applications including but not limited to reporting, education, monitoring and support. The POP server maintains a table of internet protocols (IPs) and directory number DN connections for the local PBX 113 as well as remote IP and remote telephony devices.

The Client User Data Table 107 is a database that contains client and user data as well as a locations table for additional client and user data not stored on the current AAT Server 105.

Note that the term"user"is the person that is using the AAT Server and the computers that the user is using are considered "clients". Additional data may also be stored on an external data source connected to the AAT Server 105 depending on the system and client requirements and configuration.

The TeleControl Server 108 is a separate series of processes that monitor voice and switching boards used to tie into the local PBX 113 or the regular phone lines. The TeleControl Server 108 can be used as a server based PBX, act as a gateway between the AAT Server 105 and the local PBX 113, or can facilitate the hybridization between the local PBX 113 and AAT Server 105.

The Voice-Over-IP Gateway 109 facilitates the packaging, delivery and reception of all communications routed through the Internet 101 using the Voice-Over-IP Gateway 109.

The Control Server 110 maintains and coordinates all functions across all systems in the AAT Server 105. The AAT Server 105 also bridges the Control Server 110 systems with the e-mail server 103, the web server 102, the Internet 101, the local PBX 113 and/or the PSTN 121.

When only one AAT Server 105 is connected at a site, the AAT Server 105 is recognized as the Master node for the site. However,

when connecting the AAT Server 105 to a local PBX 113 and/or PSTN 121, there are three possible configurations or options. The first option 111 is when the local PBX 113 has enough resources to support all required telephony. The AAT Server 105 hangs off of the local PBX 113 as a series of extensions 112. The PSTN trunk 115 is connected to the local PBX 113 and all in-house physical directory networks (DNs) 114 are routed through the local PBX 113.

The second option 116 is when a local PBX 113 is not present.

The PSTN trunk 119 is connected directly to the AAT Server 105 and the TeleControl Server 108, which acts as a server-based PBX, while in house physical Dns 118 are directly routed through the AAT Server 105.

The third option 120 is when the local PBX 113 does not have enough resources to support all required telephony. This is a hybridization between the local PBX 113 and the AAT Server 105 used as a server-based PBX. The AAT Server 105 is connected to the local PBX 113 through a series of extensions 112. The PSTN trunks 115,119 are connected to the local PBX 113 and AAT Server 105. In house physical Dns 114 are routed through the local PBX 113 and in house physical Dns 118 are routed through connections 117 to the AAT Server 105.

Fig. 2A is a description of the hardware configuration for connecting multiple nodes (Anytime-Anywhere Technology Servers) at a single site and the fail-safe strategy for maintaining them.

Multiple nodes at a site share the communication loads equally and each node (AAT Server) is attached to the LAN along with the client's web server (s) and e-mail server (s). The communication load is balanced across all nodes and all nodes are connected to the local PBX and/or PSTN in the same manner as a single AAT Server.

AAT Server-1 (Master) 202 is an AAT Server acting as Master node for the site. The Master node maintains the Resource List and Client User Data Table for the site at which the node is acting as Master. Additionally, the Master node is the primary point for all synchronization across nodes in a multi-site strategy. The Master node shares the communication load with all available nodes at the site as described in the Fail Safe Strategy in Fig. 2B.

AAT Server-2 (Backup) 203 is an AAT Server acting as the Backup for the Master node for the site. The Backup node mirrors

the Resource List and Client User Data Table from the Master node and acts as an automatic hot swap should the Master node fail. The Backup node shares the communication load with all available nodes at the site. This represents the original configuration mirroring strategy between the Master node and the Backup node for a multi- node implementation at a site. The Resource List and Client User Database are also mirrored in the original configuration. This mirroring strategy may change based on the status of the AAT Servers as described in the Fail Safe Strategy.

AAT Server-3 201 is the first of N alternate AAT Servers acting as nodes in a multi-node implementation at a single site.

All AAT Servers 3 through N act as automatic hot swap backups in the event of AAT Server-2 (Backup) 203 failing. Additionally, AAT Servers 3 through N share the communication load with all available nodes at the site as described in the Fail Safe Strategy.

AAT Server-N 205 is the last of N alternate servers acting as nodes in a multi-node implementation at a single site. All AAT Servers 3 through N act as automatic hot swap backups in the event of AAT Server-2 (Backup) 203 failing. Additionally, AAT Servers 3 through N share the communication load with all available nodes at the site as described in the Fail Safe Strategy.

The Fail Safe Strategy described in Fig. 2B represents the distribution of the communication load, reassignment of Master nodes and/or Backup nodes and subsequent mirroring of said nodes to provide protection against communication shutdown in the event of node failure. The AAT Server-1 (Master) node 202 is represented by graphs 206,211,216 and 221. The AAT Server-2 (Backup) node 203 is represented by graphs 207,212,217 and 222. The AAT Server-3 node 204 is represented by graphs 208,213,218 and 223 and AAT Server-N node 205 is represented by graphs 209,214,219 and 224.

As shown in Series 1, All Nodes Up, when all nodes are functioning properly, the communication load is distributed equally between all nodes. The Master node 202 is represented by graph 206, Backup node 203 is represented by graph 207 and nodes 3 through N 204,205 are represented by graphs 208 and 209. Additionally, the Master node is mirrored with the Backup node as represented by line 210.

As shown in Series 2, Master Failure, in the event of the Master node 202 failing as represented by graph 211, the Backup

node 203 will assume the responsibilities of the Master node as represented by graph 212 and the best selection alternate node (represented by node 3) will assume the responsibilities of the backup node as represented by graph 213. The new Master node will be mirrored with the new Backup node as represented by line 215.

The communication load will then be distributed equally among all available nodes as represented by graphs 212,213 and 214. When the original Master node is restored, all nodes will be synchronized and the original configuration as described in Series 1, will be reinstated.

As shown in Series 3, Backup Failure, in the event of the Backup node 203 failing as represented by graph 217, the best selection alternate node (represented by node 3) will assume the responsibilities of the Backup node as represented by graph 218.

The Master node, as represented by graph 216, will then mirror itself with the new Backup node as represented by line 220. The communication load will then be distributed equally among all available nodes, as represented by graphs 216,218 and 219. When the original Backup node is restored, all nodes will be synchronized and the original configuration as described in Series 1 will be reinstated.

As shown in Series 4, Alternate Node Failure, in the event of an alternate node failing (any node represented by AAT Servers 3 through N) as represented by graph 223, the communication load will be distributed equally among all available nodes as represented by graphs 221,222 and 224. The Master node and Backup node will continue to mirror themselves as defined in the original configuration in Series 1 and is represented by line 225. When the failed alternate node 223 is restored, all nodes will be synchronized and the original configuration as described in Series 1 will be reinstated.

Fig. 3A is a description of the hardware configuration for connecting multiple sites into a unified office. Each site is comprised of X nodes attached to the site's LAN, PBX and PSTN trunks. The Master node for each site maintains the Client User Data Table and Resource List as described in Fig. 3A.

Site 1 300 is represented as being comprised of multiple AAT Servers 302, 303, 304, 305 configured as described in Fig. 3A, with node 302 acting as Master, node 303 acting as Backup and nodes 304

and 305 representing all alternate nodes 3 through N. Note that Site 1 300 may also be comprised of only a single node acting as Master as described in Fig. 1. For Site 1 300, the Master node (302) maintains the Client User Data Table and Resource List for the site and will be accessed by each Master node (307,312) from all other sites (306,311) in a manner as described in Fig. 3A via the Internet or Dial-up Connection 301.

Site 2 306 is represented as being comprised of multiple AAT Servers 307,308,309,310 configured as described in Fig. 3A with node 307 acting as Master, node 308 acting as Backup and nodes 309 and 310 representing all alternate nodes 3 through N. Note that Site 2 306 may be comprised of only a single node acting as Master as described in Fig. 1. For Site 2 306, the Master node 307 maintains the Client User Data Table and Resource List for the site and will be accessed by each other Master nodes 302,312 from all other sites 300,311 in a manner described in Fig. 3A via the Internet or Dial-up Connection 301.

Site N 311 represents all additional sites comprising the office as described in Fig. 3A. Site N 311 is represented as being comprised of multiple AAT Servers 312,313,314,315 configured as described in Fig. 3A with node 312 acting as Master, node 313 acting as Backup and nodes 314 and 315 representing all alternate nodes 3 through N. Note that Site N 311 may be comprised of only a single node acting as Master as described in Fig 1. For Site N, the Master node 312 maintains the Client User Data Table and Resource List for the site and will be accessed by all other Master nodes 302,307 from all other sites 300,306 in a manner as described in Fig. 3A via the Internet or Dial-up Connection 301.

In Fig. 3B, All Sites UP, each office 356 is comprised of N sites represented by Sites 1 through N 350,351,352,353,354, 355. Note that the office 356 may be comprised of only a single site, as described in Fig. 2A. In the event that all sites are functioning properly, these sites are synchronized, via the Internet or Dial-up Connection 301, in such a manner as to provide the most efficient means for sharing information without redundancy, as described in Fig. 3B.

Also in Fig. 3B, Site Down, each office 364 is comprised of N sites represented by Sites 1 through N 358,359,360,361,362, 363. Note that the office 364 may be comprised of only a single

site as described in Fig. 2A. In the event that a site is not functioning, as represented by Site 3 360, all functioning sites associated with the down site, Site 2 359 and Site 4 361 will bypass the down site 360 during synchronization as represented by line 366. All available sites in the office will continue to be synchronized, via the Internet or Dial-up Connection 301, in such a manner as to provide the most efficient means for sharing information without redundancy, as described in Fig. 3B.

According to Fig. 4A, a company 400, is comprised of N offices represented by Office 1 406, Office 2 404 and all additional offices in the company 400 represented by Office N 406. Each office in the company 400 has a Master Site that contains the Resource List for the site. Office-1 402 has Master Site 403, Office-2 404 has Master Site 405 and Office-N 406 represents all additional offices within the company 401, each having a Master Site represented by 407. Each office is synchronized on 5 second intervals over the Internet or Dial-up Connection 401 in a manner as described in Fig. 4A. Each office also has a Fail Safe Strategy previously described in Fig. 2B.

According Fig. 4B, a company 456 is comprised of N offices represented by Offices 1 through N 450,451,452,453,454 and 455.

All offices in the company are synchronized in such a manner as to provide the most efficient means for sharing information without redundancy, via the Internet or a Dial-up Connection 401, as described in Fig. 4B.

Fig. 5A is a description of the hardware configuration for routing inbound telephony into the AAT Server 505. Inbound telephony communications are routed through the Internet 501 using Voice-Over-IP 507 into the AAT Server 505 through the Voice-Over IP Gateway 509. Standard telephony communications are routed through the PSTN 502, which has a trunk 515 connected to the local PBX 513, which is then linked to the AAT Server 505 via the TeleControl 508 through a series of extensions 506 or connected directly to the AAT Server 505 via the TeleControl 508.

Fig. 5B shows a flowchart which represents the AAT Control logic used for incoming telephony communications received from either the Internet 501, PSTN 502 or through the local PBX 513 into the AAT Server 505 as described in Fig. 5A.

At 550, determine the nature of the inbound telephony communication. If the telephony communication was received via Voice-Over-IP (through the Internet), continue on the Voice-Over-IP branch to box 551. If the telephony communication was received via Other, continue to box 555.

According to 551, when a communication is determined from box 550, get the associated data attached to inbound telephony communication and associated telephony message from Pop Server and continue to 552. At 552, determine if the extension referenced in the associated data attached to the inbound telephony message is valid. If yes, follow to 554. If no, follow to 553. At 553, if intended extension from telephony communication is not valid, continue to Fig. 15-Auto Attendant. Then continue back to 570.

At 554, if intended extension from telephony communication is valid, continue to Fig. 12-Virtual Extension Process.

According to 555, if the telephony communication was received via 550, determine if an automatic number identification (ANI) is available for the communication. If yes, follow to 558. If no, follow to 557. At 557, if Caller ID is not available, flag the inbound telephony communication as sender unknown and continue to 564. At 558, if ANI or Caller ID is available, match ANI or Caller ID for inbound telephony against any data item to determine match for ANI or Caller ID. Continue to 559. At 559, determine if match to ANI or Caller ID from inbound telephony matches any data item established. If yes, follow to 561. If no, follow to 560.

At 560, if there is no match to ANI or Caller ID in any data item, attach the name or number retrieved from ANI or Caller ID to inbound telephony communication and flag the communication as sender unknown. Continue to 564 of Fig. 5C. At 561, if multiple matches to ANI or Caller ID were found in data items, determine if more than one data item matched ANI or Caller ID for inbound telephony communication. If yes, follow to 563. If no, follow to 562. At 562, if only one data item match was found for the ANI or Caller ID for the inbound telephony communication, attach the name or number from ANI or Caller ID and the data item match to the inbound telephony communication. Continue to 564. At 563, attach name or number, set unknown flag and attach all possible callers list. If more than one data item match was found to ANI or Caller ID, attach the name or number from ANI or Caller ID, attach the

list of all data item matches and flag the communication as sender unknown. Continue to 564. At 564, determine if the inbound telephony is associated with a direct line. If yes, follow to 565.

If no, follow to 567.

At 565, match direct line to virtual extension and continue to 566. At 566, once inbound telephony communication on a direct line is associated with a virtual extension, continue to Fig. 6A, Virtual Extension Process, Part 1. At 567, if the inbound telephony communication is not associated with a dialed number identification service (DNIS). If yes, follow to 568. If no, follow to 569. At 568, if an inbound telephony communication is associated with a DNIS, determine the direct route for the DNIS and continue to 572. At 569, if there is no direct line or no DNIS, send inbound communication to Fig. 15, Auto Attendant to prompt for extension. Once the extension is determined, continue to 570. L 570, when the inbound telephony communication returns from Fig. 15, Auto Attendant with extension, determine if extension is valid.

If yes, follow to 571. If no, follow to 569. At 571, when either a virtual extension is associated with a DNIS or a valid extension has been returned from Fig. 15, Auto Attendant, continue to Fig.

6A, Virtual Extension Process, Part 1. At 572, once the direct routing for the DNIS has been identified, determine if a virtual extension is associated with the DNIS. If yes, follow to 571. If no, follow to 569.

Figs. 6A and 6B, form a flowchart that represents the AAT control logic used for routing inbound telephony communications received from either the Internet, PSTN or through the local PBX into the AAT Server once the virtual extension has been validated, as described in Fig. 5B.

At 601, based on sender characteristics, check for a specific hold message to be used for sender. Continue to 602. At 602, determine properties for virtual extension from the database.

These properties will be used for routing inbound telephony communications to the appropriate addresses. Continue to 603. At 603, determine if the inbound telephony communication is a fax.

If yes, follow to 604. If no, follow to 605. At 604, if the inbound telephony communication is a fax, continue to Fig. 14, Fax Delivery Process. At 605, if the inbound telephony communication is not a fax, determine if there is more than one user associated

with the selected virtual extension. If yes, follow 606. If no, follow 608.

At 606, if more than one user is associated with the selected virtual extension, continue to Fig. 12, Virtual Extension Candidate Process to determine candidates for virtual extension. Once list is determined, continue to 607. At 607, once the candidates for the selected virtual extension have been determined from Fig. 12, Virtual Extension Candidate Process, return to Fig. 6A with the user property list in best candidate order. Continue to 609. At 608, if only a single user is associated with the virtual extension, get the user properties for the user. Continue to 609.

At 609, once the user properties have been retrieved, determine if the user is logged into the system. If yes, follow to 611. If no, follow to 610.

At 610, if the user is not logged-in, continue to Figs. 6C and 6D, Virtual Extension Process Part 2. At 611, if the user is logged-in, a client will be associated with the AAT system.

Continue to 612. At 612, for every client that the user is logged- in to, send the information about the inbound communication to the client (s). Continue to 613. At 613, when the inbound communication information is sent to the clients, determine if any of the clients accept the communication. If yes, follow to 614.

If no, follow to 615. At 614, if one of the clients accepts the communication, continue to Figs. 6C and 6D, Virtual Extension Process, Part 2. At 615, check if more than one user is associated with the virtual extension. If yes, follow to 616. If no, follow to 617. At 616, if more than one user is associated with the virtual extension, determine the next user according to the best candidate order from the User Property List returned from Fig. 12, Virtual Extension Candidate Process. Continue to 609. At 617, if only one user was associated with the virtual extension and the client did not accept the inbound communication, continue to Fig.

11, Notification Strategy.

Figs. 6C and 6D depict a flowchart which represents the AAT control logic used for connecting inbound telephony communications and sending communication information from an inbound telephony communication received from either the Internet, PSTN or through the local PBX into the AAT Server as described in Fig. 6A. At 651, once the destination for the inbound communication has been

determined from Fig. 6A, determine if the destination for the inbound communication is on the local PBX. If yes, follow to 657.

If no, follow to 652. At 652, if the destination for the inbound communication is not on the local PBX, continue to Fig. 7, Determine Best Route. Once the best route has been determined, return and continue to 653. At 653, once the best route has been determined or the destination is on the local PBX, determine if the local AAT server should be used for routing the call. If yes, follow to 657. If no follow to 654.

At 654, if the inbound call should not be routed over the local AAT server, determine if the inbound call is Voice-over IP.

If yes, follow to 655. If no, follow to 658. At 655, if the inbound call was not Voice-over-IP, send the call via Voice-over-IP to the appropriate remote site and include a transmission control protocol (TCP) message with the telephony communication information. At 656, if the inbound call was Voice-over-IP, return the call back to the originating server to be redirected to the appropriate server. At 657, if the inbound call should use the local AAT Server, use the local AAT server to manage placing the outbound call and continue to 658. At 658, when the outbound call has been placed, determine if the communication was answered. If yes, follow 660. If no, follow to 659. At 659, if there was no answer to the outbound call, continue to Fig. 11, Notification Strategy.

At 660, if the outbound communication was answered, determine if a client is associated with the destination for the outbound call. If yes, follow to 664. If no, follow to 661. At 661, if a client is not associated with the inbound communication, determine if a whisper transfer is requested by the user and if the property set for the whisper transfer is available. A whisper transfer is simply a vocal message that informs a user that a call is being made to them. If yes, follow to 662. If no, follow to 664. At 662, if the whisper transfer is appropriate, whisper transfer the inbound communication. Continue to 663. At 663, when the call is whisper transferred, determine if the user accepted the inbound communication. If yes, follow to 664. If no, follow to 615 of Fig. 6A. At 664, if the user accepted the communication from the whisper transfer or there was not a whisper property set, connect the inbound communication using the switching at the AAT

Server via the TeleControl module and monitor the communication.

At 665, continue to Fig. 8, Call In Progress.

Fig. 7, Determine Best Route, is a description of the computer logic used by the AAT Control for determining the best route for incoming telephony communications. At 701, when the best route needs to be determined for an inbound communication, the computer logic begins by determining whether there are multiple sites in a given company and whether the sites are Voice-over-IP enabled. If yes, follow to 702. If no, follow to 711. At 702, if there are multiple sites and those sites are Voice-over-IP enabled, determine whether the destination is in a local area to the local AAT Server.

If yes, follow to 711. If no, follow to 703. At 703, match the area code of the destination in the long distance matrix to determine the least cost routing approach to routing the destination. Continue to 704.

At 704, get the least cost routing approach to routing the communication to the destination. Continue to 705. At 705, once the least cost routing has been determined, determine if the routing utilizes a local site. If yes, follow to 710. If no, follow to 706. At 706, if the least cost routing approach does not utilize a local site, check for enough bandwidth to route the communication via Voice-over-IP and continue to 707. At 707, determine if the bandwidth is acceptable to handle the communication. If yes, follow to 709. If no, follow to 708. At 708, if the bandwidth for Voice-over-IP was not acceptable or the resource on the remote AAT server is not available, determine the next site in the best route approach. Continue to 705. At 709, if the bandwidth for Voice-over-IP is acceptable, determine if the resource on the destination is available. If yes, follow to 710.

If no, follow to 708. At 710, return to the referencing figure with the routing strategy for the communication.

Fig. 8, Call in Progress, provides a description of the telephony communication functions monitored while a communication is in progress. At 801, while a telephony communication is in progress, the AAT Control user monitors the communication to determine if any of the processes represented by 802 through 809 occurs. At 802, while communication is in progress, it is monitored for the addition of participants. At 803, while communication is in progress, it is monitored for a request to

record communication. At 804, while communication is in progress, it is monitored for a transfer of communication. At 805, while communication is in progress, it is monitored for a participant to be placed on hold. At 806, while communication is in progress, it is monitored for volume adjustment. At 807, while communication is in progress, it is monitored for the participant to be muted.

At 808, while communication is in progress, it is monitored for a participant to be disconnected. At 809, continue to Fig. 9, End Call.

Fig. 9 provides a description of the AAT Control logic used when a telephony communication is ended. At 901, determine if a client computer is associated with the call. If yes, follow to 902. If no, follow to 904. At 902, if no client computer is associated with the call, disconnect the telephony communication and continue to 903. At 903, once the communication has been disconnected or the call back option was not set or there was no answer for the call back, save all available information for the communication at 903. At 904, if there is no client computer associated with the call, determine if the call back option is set.

If yes, follow to 905. If no, follow to 903. At 905, if a call back option has been set, determine if the user is still connected to the call. If yes, follow to 908. If no, follow to 906. At 906, if the user is not still connected to the call, initiate a call back to the user at the same number where the user was located for the previous communication. Continue to 907. At 907, when the call has been initiated to the users last location, determine if there is an answer at that location. If yes, follow to 908. If no, follow to 903. At 908, if there is no answer at the user's last location when the call back summary option has been set, gather all available communication data and store the data for later review by the user.

Fig. 10 is a description of the architecture for the Pop Server 1006 component of an AAT Server 1005. Item 1001 represents the Internet or an office intranet. Item 1002 represents a replaceable security model (Pop Server side) which encrypts information prior to being transferred over either an intranet or the Internet and decrypts the information upon receipt. The Pop Server 1006 allows for different encryption models to accommodate changing security technology. Item 1003 represents a replaceable

security model (Client side) which encrypts information prior to being transferred over the Internet or an intranet and decrypts the information upon receipt. The Pop Server 1006 allows for different encryption models to accommodate changing security technology.

Item 1004 is information being supplied by the AAT Server 1005 that needs to be communicated to the clients. This information is handled via Pop Server 1006. Item 1006 is the Pop Server which enables communication between AAT Server 105 and AAT clients. This is done over transmission control protocol (TCP) sockets 1007- 1010, allowing communication via intranet or the Internet 1001.

The Pop Server 1006 is a software piece that continuously monitors for clients and when clients are found, connects clients with all other functions in the AAT Server 105.

Item 1007 represents TCP Socket 1, which represents the first port opened by the Pop Server 1006. The Pop Server 1006 manages TCP sockets for client connectivity. This is accomplished by opening a TCP port and waiting for a connection from a client. As a connection is made, the Pop Server 1006 opens another port and monitors for clients. There is always one more port open than currently connected clients.

Item 1008 represents TCP Socket 2, which represents the second port opened by the Pop Server 1006. The Pop Server 1006 manages TCP sockets for client connectivity. This is accomplished by opening a TCP port and waiting for a connection from a client. As a connection is made, the Pop Server 1006 opens another port and monitors for clients. There is always one more port open than currently connected clients.

Item 1009 represents TCP Socket 3, which represents the third port opened by the Pop Server 1006. The Pop Server 1006 manages TCP sockets for client connectivity. This is accomplished by opening a TCP port and waiting for a connection from a client. As a connection is made, the Pop Server 1006 opens another port and monitors for clients. There is always one more port open than currently connected clients.

Item 1010 represents TCP Socket n+1, which represents all additional TCP sockets as applicable to the configuration of the system. The Pop Server 1006 manages TCP sockets for client connectivity. This is accomplished by opening a TCP port and waiting for a connection from a client. As a connection is made,

the Pop Server 1006 opens up another port and monitors for clients.

There is always one more port open than currently connected clients. As appropriate, in item 1011, some of the structured information passed via the Internet will be accomplished via extensible markup language (XML) documents from the AAT server 1005 to the clients via the Pop Server 1006. Not all information will be passed via XML.

Item 1012 represents the first client connected to the AAT Server 1005 via the Pop Server 1006 using the TCP socket and security model described. Item 1013 represents the second client connected to the AAT Server 1005 via the Pop Server 1006 using the TCP socket and security model described. Item 1014 represents the third client connected to the AAT Server 1005 via the Pop Server 1006 using the TCP socket and security model described. Item 1015 represents client n connected to the AAT Server 1005 via the Pop Server 1006 and security model described.

Fig. 11 depicts a description of AAT's notification strategy.

At 1101, determine the method of notification for the received communication. Continue to 1102. At 1102, determine where the notification should be sent. Continue to 1103. At 1103, determine the contents of the communication based on user settings. Continue to 1104. At 1104, prepare the notification communication based on the type 1101, destination 1102 and contents 1103. Attach response options associated with this communication. Continue to 1105. At 1105, determine if the notification type is telephony or other.

This will determine which flow to follow for the outgoing communication. If telephony, follow to 1107. If other, follow to 1106.

At 1106, send electronic communication to recipient. Continue to 1108. At 1107, if the notification type is telephony, queue the communication as outgoing and continue to Fig. 19, Outgoing Telephony Communication. Continue to 1108. At 1108, determine if any more notifications are required for the received communication.

If yes, end notification strategy. If no, follow to 1109. At 1109, determine the type for the next requested notification for the received communication. Continue to 1102.

Fig. 12 is a description of the virtual extension candidate process user by the AAT server to determine the best destination for an inbound communication. At 1201, retrieve the properties

associated with the virtual extension to determine allocation type and other routing characteristics. Continue to 1202. At 1202, determine if the allocation type for the virtual extension is explicit or dynamic. If explicit, continue to 1204. If dynamic, continue to 1203. At 1203, if the allocation type for the virtual extension is dynamic, continue to Fig. 13, Project Skill User Association. Return to the referencing process. At 1204, if the virtual extension is explicitly allocated, retrieve the list of users associated with the virtual extension. Continue to 1205. At 1206, determine if there is a priority assignment for the virtual extension. If yes, continue to 1207. If no, continue to 1206.

At 1206, if there is no priority assignment for the virtual extension, then assemble a list of potential routing destinations using automatic call distribution (ACD) or round-robin methodology to determine the next destination. Return to previous figure. At 1207, if there is a priority assignment for the virtual extension, use a combination of weight plus ACD or round-robin methodology to assemble a list of potential routing destinations to determine the next destination. Return to previous figure.

Fig. 13 is a description for determining the potential destinations for virtual extensions with dynamic allocation. At 1301, determine if potential destinations use both project assignments and skill assignments. If yes, continue to 1302. If no, continue to 1312. At 1302, if the potential destination uses both project and skill assignments, determine if the primary factor is the project assignment. If yes, continue to 1305. If no, continue to 1303. At 1303, if the primary factor is not a project assignment, retrieve the list of potential users based on skill assignments. Continue to 1304. At 1304, determine if any users are assigned to skill assignments. If yes, continue to 1311. If no, continue to 1309.

At 1305, if the primary factor is a project assignment, determine the list of users associated with the project. Continue to 1307. At 1306, if the assigned project is a sub-project, go to the main project. Continue to 1305. At 1307, determine if there are any users associated with the project. If yes, continue to 1310. If no, continue to 1308. At 1308, if there were no users for the project, determine if the assigned project is a sub-project of another project. If yes, continue to 1306. If no, continue to

1309. At 1309, if there are no users associated with the skill assignment or there are no users associated with the project and the project is not a sub-project, retrieve the operator extensions.

Return list of extensions to previous figure.

At 1310, if there are users associated with the project, prepare the list of users ordered by the project weight and skill weight. Return list of users to previous figure. At 1311, if there are users associated with the skill assignment, then prepare the list of users ordered by skill weight and project weight.

Return to list of users to previous figure. At 1312, if the potential destination does not use both project and skill assignments, determine if the association is either a project or skill assignment. If project assignment, then follow to 1316. If skill assignment, continue to 1313. At 1313, if the potential destination is associated with a skill assignment, retrieve a list of users associated with that skill assignment. Continue to 1314.

At 1314, determine if there were any users associated with the skill assignment. If yes, continue to 1315. If no, continue to 1318. At 1315, if there were users associated with the skill assignment, prepare the list of users ordered by skill weight.

Return to previous figure. At 1316, if the potential destination is associated with a project, retrieve a list of users associated with the project. Continue to 1319. At 1317, if the project was a sub-project, go to the main project. Continue to 1316. At 1318, if there were no users associated with the skill assignment or there were no users associated with the project and the project was not a sub-project, retrieve a list of the operator extensions.

Return to previous figure. At 1319, determine if there were any users associated with the project. If yes, continue to 1321. If no, continue to 1320. At 1320, if there were no users associated with the project, determine if the project is a sub-project of another project. If yes, continue to 1317. If no, continue to 1318. At 1321, if there are users associated with the project, prepare a list of users ordered by project weight. Return list of users to previous figure.

Fig. 14 is a description of the strategy for managing inbound faxes. At 1401, an incoming communication is identified as a fax by the AAT system. At 1402, determine if an extension is associated with the incoming fax. If yes, follow to 1405. If no,

follow to 1403. At 1403, if no extension was associated with the incoming fax, deliver the fax to the company mailbox. Continue to 1404. At 1404, if a fax was delivered to the company mailbox, alert the fax operators and any users who have indicated that they are expecting a fax. At 1405, if an extension was associated with the incoming fax, continue to Fig. 11, Notification Strategy.

Fig. 15 is a description of the auto attendant strategy for tone and voice recognition differentiation. At 1501, play the appropriate voice user interface auto-attendant menu. At 1502, determine if dual tone multi-frequency (DTMF) is detected. If a tone is detected, continue on to 1503. If no tone is detected, continue to 1504. At 1503, determine if the entry by the user is a valid extension. If yes, continue to 1506. If no, continue back to 1501. At 1504, perform voice recognition on voice entry and continue to 1505. At 1505, determine if a match was detected in the grammar set for the voice input determined in 1504. If there is a high probability of a match of the user input to an extension or group, continue to 1506. If there is a low probability of a match of the user input to any extension or groups, continue back to 1501. At 1506, if a valid extension was determined from 1503 or the voice input recognized in 1504 had a high probability of matching an existing extension, retrieve the appropriate extension or group. Continue to 1507. At 1507, return to previous figure with appropriate extension or group.

Fig. 16 is a description of outbound telephony communications.

At 1601, a telephony communication is initiated by a client in the AAT System. Continue to 1602. At 1602, determine if the initiated telephony communication is a fax. If yes, continue to 1603. If no, continue to 1605. At 1603, if the telephony communication is a fax, determine if the intended recipient is a user. If yes, continue to 1604. If no, continue to 1606. At 1604, if the intended recipient is a user, deliver the fax to the recipient's mailbox. Continue to 1607. At 1605, if the initiated telephony communication is not a fax, determine the best route for the telephony communication. Continue to Fig. 7, Determine Best Route.

At 1606, if the recipient for the outbound fax is not a user, get a list of available fax ports in AAT's enterprise wide system.

Continue to 1609.

At 1607, after the fax is delivered in the recipient's mailbox, continue to Fig. 11, Notification Strategy. At 1608, once the best route for the telephony communication has been determined, continue to Fig. 8, Call in Progress. At 1609, after the list of available fax ports have been complied, determine the best route for the outbound fax. Continue to Fig. 7 and return to 1610. At 1610, once the best route for the outbound fax has been determined, send the fax using the route specified.

Fig. 17 is a description describing the managing of inbound e-mail communications. At 1701, via the connections of the e-mail server and AAT Server, monitor for all incoming e-mails. Continue to 1702. At 1702, a new e-mail communication is detected. Continue to 1703. At 1703, determine if the sender's address has been marked for special monitoring. If yes, continue to 1704. If no, continue to 1701. At 1704, if this address is marked to be monitored, determine if notification strategies are enabled. If yes, continue to 1705. If no, continue to 1701. At 1705, if notification strategies are enabled, determine if the notification is based on the sender. If yes, continue to 1706. If no, continue to 1708. At 1706, if the notification was based on the sender, retrieve the notification recipient address. Continue to 1707.

At 1707, once the notification recipient address has been determined, continue to Fig. 11, Notification Strategy. At 1708, if the notification is not based on the sender, parse the e-mail communication for key words and analyze the sentence structure.

Continue to 1709. At 1709, once the e-mail has been analyzed, determine if any of the information from the e-mail message requires notification. If yes, continue to 1706. If no, continue to 1701.

Fig. 18A represents a high level view of the TeleControl architecture and logic. At 1821, PSTN is simply the public switch telephone network. At 1802, phones 1 through N represent the telephony devices that are placing or receiving communication from the AAT system. They are not internally connected to either the local PBX 1813 or the AAT Server 1805. At 1808, is the TeleControl server 1808, which is part of the AAT Server 1805 which is an application/process that manages inbound and outbound telephony through any switch. 1804 represents any incoming telephony communication captured in the TeleControl server 1808 and is routed

through to the local PBX 1813. If the recipient directory number (DN) is associated with a trunk, refer to Fig. 18B, Recipient on Local PBX-DN is associated with trunk line. If the recipient DN is not associated with a trunk, refer to Fig. 18B, Recipient on Local PBX-DN is not associated with trunk line. The Control Agent 1815, at 1815, is a group of Dns that handle inbound local PBX 1813 traffic. Upon receiving a call, the Control Agent 1815 listens for dual tone multi-frequency (DTMF) that will be passed from the inbound telephony communication from TeleControl 1808. The DTMF is used to distinguish which inbound trunk the Control Agent 1815 answers. The Control Agent 1815, based on the inbound trunk, switches the inbound trunk to the recipient DN. 1813 is the client's existing PBX 1813 that is connected to the AAT Server 1805.1807 are the physical DN's that represent the recipient Dns inside the local PBX 1813.

Fig 18B consists of three diagrams that represent the possible recipient and DN configuration scenarios. Recipient refers to the end destination of the incoming telephony communication. Caller represents the point of origination of the telephony communication when caller is outside of the in-house AAT system.

Fig. 18B includes the first diagram, recipient is not on local PBX, which represents a configuration where both the caller and recipient are not directly connected to the internal AAT system.

1809 represents the point of origination for this telephony communication. 1821 represents a PSTN while 1808 represents the TeleControl Server 1808. The TeleControl Server 1808 manages inbound and outbound telephony routing. Since the recipient is not on the local PBX 1813, when an inbound call is received, TeleControl Server initiates a call to the recipient through the PSTN 1821 and connects the caller and recipient inside the TeleControl 1808 hardware.

Fig. 18B includes the second diagram, recipient is on local PBX, DN is associated with trunk line, represents a configuration where the recipient is directly connected to the internal AAT system and the recipient DN is associated with a trunk line. 1809 is the caller, which is the point of origination for this telephony communication. 1821 is the in-house PBX and 1812 is the recipient, which is the destination of the telephony communication.

Fig. 18B includes the third diagram, recipient is on a local PBX, DN is not associated with trunk line, represents a configuration where the recipient is directly connected to the internal AAT system. 1809 is the caller, which is the point of origination for this telephony communication. 1821 is the PSTN and 1813 is the local in-house PBX. The TeleControl Server, 1808, receives a call and determines that the recipient DN is not associated with a trunk line. The TeleControl Server 1808 passes the call to a group of Dns on the local PBX 1813, referred to as the Control Agents 1815. The Control Agent 1815 is a group of Dns that handle inbound local PBX traffic. Upon receiving a call, the Control Agent 1815 listens for DTMF that will be passed from the inbound telephony communication from the TeleControl Server 1808.

The DTMF is used to distinguish which inbound trunk the Control Agent 1815 answered. The Control Agent 1815, based on the inbound trunk, switches the inbound trunk to the recipient DN, which is the destination of the telephony communication.

Fig. 19, Outgoing Telephony Communication, is a description used for telephony communications that are outgoing after the AAT Server has captured the telephony communication. At 1901, the AAT Server initiates the telephony communication. Continue to 1902.

At 1902, determine if the initiated outgoing telephony communication is a fax. If yes, continue to 1903. If no, continue to 1905. At 1903, if the outgoing telephony communication is a fax, determine if the recipient is a user. If yes, continue to 1904. If no, continue to 1906. At 1904, if the intended recipient is a user, deliver the fax to the recipient's mailbox. Continue to 1907. At 1905, if the outgoing telephony communication is not a fax, determine the best route for the communication. Continue to Fig. 7, Determine Best Route. On return, continue to 1909. At 1906, if the fax recipient is not a fax, get a list of available fax ports in AAT's enterprise wide system. Continue to 1910. At 1907, once the fax has been delivered to the recipient's mailbox, continue to Fig. 11, Notification Strategy. On return, return to previous figure. At 1908, if the call is answered, play the communication to the recipient with any associated response as appropriate. Continue to 1911.

At 1909, once the best route has been determined for the telephony communication, place the call and determine if the call

was answered. If yes, continue to 1908. If no, continue to 1912.

At 1910, once the list of available fax ports has been assembled, determine the best route for the outgoing fax. Continue to Fig.

7, Determine Best Route and on return, continue to 1913. At 1911, collect the response from the recipient of the telephony communication. Continue to 1914. At 1912, if the call was not answered, go to the next notification destination. Return to previous figure. Once the best route has been determined for the fax, send the fax and return to previous figure. At 1914, once the response has been collected, determine if the response requires notification to the sender. If yes, continue to 1915. If no, return to previous figure. At 1915, if the response requires notification to the user, prepare the appropriate communication to be returned to the user. Return to previous figure.

The preferred embodiment of the invention performs the seamless integration of telephone, voice mail, e-mail, fax, paging, Internet, intranet and local area network technologies into a single communications system. A communications routing system is provided that has artificial intelligence capability and associates its users to specific projects, sub-projects and skills.

It is to be understood that the present invention is not limited to the sole embodiment described above, but encompasses any and all embodiments within the scope of the following claims.