Phone management server for use with a personal computer LAN

Description Submit all comments and votes

TECHNICAL FIELD

The present invention relates to method and apparatus for providing phone management functionality to personal computers (PCs) which are end users of a PC Local Area Network (LAN) by logically associating telephones that are coupled to a separate voice and data network, such as a Private Branch Exchange (PBX), with the PCs coupled to the PC-LAN.

DESCRIPTION OF THE PRIOR ART

In recent years, modern technology has been applied to improve operations in business offices by both the use of computers and the evolution of the traditional Private Branch Exchange (PBX) into an office automation system. Typical of such modern PBXs are, for example, the AT&T System 75 and System 85 Office Communication Systems which provide integrated voice and data processing between nodes and locations of business customers. Integrated voice/data services are those in which voice and data are logically related; that is, a terminal or personal computer (PC) and a telephone are linked at one location to compliment each other, producing a synergy. Typical applications would be to display the name of a caller on a PC screen or storing the call into a database; computer retrieval of information relating to a voice call; and allowing messages to be stored orally or electronically for subsequent retrieval from a variety of voice and data instruments. The System 75 and 85 PBXs are typically connected to their associated voice or data terminals by a premises distribution system that includes a combination of twisted-pair copper wires and optical fibers, and such systems allow customers to control their own communications environment. IEEE Journal On Selected Areas of Communication, Vol. SAC-3, No. 4, July 1985, at pages 522-530 by A. Feiner; AT&T Technology, Vol. 2, No. 3, 1987, at pages 22-29 by J. F. Day et al.; and AT&T Technical Journal, Vol. 64, No. 1, Part 2, January 1985 at pages 145-151 by A. Feiner et al., and pages 153-173 by L. A. Baxter et al.

As the popularity of desktop computers or minicomputers increases, it was found that productivity increases dramatically when computers can easily access other computers and peripheral devices. To provide such access, office communication systems such as a local area network (LAN) were developed to interconnect computers and peripheral devices. A typical LAN for providing such capability is, for example, the AT&T STARLAN network as described, for example, in the article by R. B. Brandt in AT&T Technology, Vol. 3, No. 1, 1988, at pages 32-39; and the article by N. Mokhoff in Electronic Design, Vol. 35, Iss. 15, at pages 57, 58 and 60. The STARLAN LAN provides connections among its nodes with unshielded twisted-pair wiring; and devices with standard RS-232C connectors, such as asynchronous terminals, printers, modems and other computers, are connected to the network through an RS-232C STARLAN Network Access Unit (NAU). The software provided for the STARLAN network makes possible certain kinds of networking services as, for example, (1) the ability of an associated PC to access shared directories, files, and printers on a wide range of DOS- or UNIX-system-based server computers, and (2) the ability of terminals, workstations, printers and other asynchronous RS-232C devices, connected to the network via the NAU, to interact with a network computer as if the devices were connected directly to the RS-232C port on the computer. Such network, however, does not integrate voice transmission capabilities as found with the System 75 and 85 PBXs.

The problem remaining in the prior art is to provide an existing computer-based network that transmits data with a phone management functionality at a reduced cost and without modifying the computer-based network to produce a voice and data network.

SUMMARY OF THE INVENTION

The foregoing problem in the prior art has been solved in accordance with the prsent invention which relates to method and apparatus for providing phone management functionality to personal computers (PCs) or minicomputers which are end users of a PC Local Area Network (LAN) by logically associating voice terminals that are coupled to a separate voice and data network, such as a Private Branch Exchange (PBX), with predetermined PCs coupled to the PCLAN. More particularly, the present invention permits several PC-LAN users to logically associated (1) a voice terminal associated with a PBX, and (2) a PC associated with a PC-LAN in order to provide phone management functions as, for example, (a) displaying calling/called party identification obtained from the PBX on the PC screen, (b) placing voice calls via the PBX associated voice terminal from a PC-based directory; and (c) retrieving messages from the PBX destined for the logically associated voice terminal and displaying the messages on the PC screen using a phone management server protocol.

Other and further aspects of the prsent invention will become apparent during the course of the following description and by reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an exemplary PC-based network and an exemplary PBX-based network that are arranged to provide phone management functionality to the PC-based network in accordance with the present invention;

FIG. 2 is a block diagram showing bridged appearances of three voice terminals to another voice terminal;

FIG. 3 is a block diagram of the present phone management server interconnections in accordance with a preferred embodiment of the present invention; and

FIG. 4 is a block diagram of an exemplary process of retrieving messages on a PC of the PC-based network that is logically associated with a voice terminal on a PBX network in accordance with a preferred embodiment of the present invention.

DETAILED DESCRIPTION

The description of the present invention which follows is directed to the technique of locally associating a telephone connected to an AT&T System 25, 75 or System 85 data and voice communication system, hereinafter referred to as a PBX network, and a personal computer (PC) or minicomputer connected to a separate AT&T STARLAN PC Local Area Network (PC-LAN) in order to provide a phone management server application. It is to be understood that the use of the system 25, 75 or 85 and the STARLAN networks is merely for purposes of explanation and not for purposes of limitation and that other suitable PC-LANs or data/voice networks or systems could be substituted and still fall within the spirit and scope of the present invention. Such other data/voice network or system might include the well-known Integrated Services Digital Network (ISDN) switch.

FIG. 1 is a block diagram of a well-known STARLAN PC-based network 10 and a well-known PBX network 20 which are connected by a phone management server device 21 to provide phone management functionality to network 10 in acordance with the present invention. Phone management server device 21 is shown in FIG. 1 as part of PC-based system 10, but it should be understood that connection 21 could form part of the PBX system 20. The exemplary AT&T STARLAN LAN 10 is a low-cost development of the IEEE 802.3 Carrier Sense Multiple Access/Collision Detection (CSMA/CD) standard network protocol for use over telephone twisted pairs. As shown in FIG. 1, the exemplary STARLAN LAN 10 includes a plurality of N peripheral devices 11 such as PCs 11.sub.1 to 11.sub.3, a terminal 11.sub.4 and a printer 11.sub.5 for the exemplary case where N=5 and a hub 12. As shown in FIG. 1, PCs 11.sub.1 to 11.sub.3 are connected to hub 12 via Network Access Units (NAUs) 13.sub.1 to 13.sub.3, respectively, and terminal 11.sub.4 and printer 11.sub.5 are connected in a daisy-chain configuration from PC 11.sub.3 through an NAU 11.sub.4. The PCs, terminals and printers 11 are coupled to a hub 12 to provide a star network in a manner described extensively in the article by R. B. Brandt in AT&T Technology, Vol. 3, No. 1, 1988, at pages 32-39.

The STARLAN LAN has three fundamental components: Network Access Units (NAUs), Network Extension Units (NEUs) and Network Repeater Units (NRUs). The NAU is the basic building block and acts as an interface which enables a computer, such as a PC or minicomputer, or other device, such as a modem, a printer or asynchronous terminal, to send or receive data over the PC network. There are two types of NAUs; one for a computer which is a plug-in expansion card that is installed in a slot for each computer such as NAUs 13.sub.1 to 13.sub.3, and one for RS-232C devices that is a stand-alone component that can support two devices such as NAU 13.sub.4. The NEU (not shown) is generally found in hub 12 and is the component used by itself or with other NEUs in a tree arrangement, depending on the size of the network, to form the star network as shown in the above-cited Brandt article. Each NEU connects a predetermined plurality of any combination of NAUs and/or other NEUs and their NAUs to its plural ports and receives network signals from these devices, regenerates these signals and returns them to the connected devices. If two or more NAUs 11 transmit data at the same time, the NEU sends a collision-presence signals that causes the associated NAUs to stop transmitting, wait, and then retransmit their data. The NRU (not shown) is also generally found in the hub 12 and is used to connect nodes separated by a long distance to a port on one of the NEUs by receiving network signals, then retiming and regenerating the signals to remove noise. The standard STARLAN networking software for the STARLAN LAN is provided in each of the user PCs 11.sub.1 to 11.sub.3 via their NAUs 13.sub.1 to 13.sub.3 and in the daisy-chained NAUs as in NAU 13.sub.4. Such program allows the user device(s) to be part of the STARLAN network.

The well-known PBX network 20 includes a hub 22 for processing and directing voice and data transmissions between the various associated plurality of N end user voice devices 23.sub.1 to 23.sub.4 (where N=4), such as telephones, and plurality of M end user data devices such as PCs 24.sub.1 to 24.sub.3 (where M=3). Other PBX networks or central offices can also be connected to hub 22 via trunks 25 for routing information transmissions originating and terminating within PBX network 20 to and from, respectively, such other networks and offices when required. As shown for the System 75 communication and control architecture in FIG. 1 at page 154 of the article by L.A. Baxter et al. in AT&T Technical Journal, Vol. 64, No. 1, January 1985, pages 153-173, the exemplary System 75 includes, within a hub 22, Time Division Multiple (TDM) buses to which are connected to the (1) lines coupling the system associated devices 23 and 24, (2) trunks 25 to other PBXs and Central Offices, and (3 ) service circuits required for the system. A control complex is generally included within hub 22, which is also connected to the TDMA buses, including the necessary processors, memories, controllers and maintenance circuits, and the necessary software for providing the network control, to monitor and control system communications such as call processing. Such architecture would be a typical arrangement of an Office Communication System which can be used for PBX network 20. The AT&T System 75, and the larger AT&T System 85, provide integrated data switching, including 64-kb/s transparent switching; and simultaneous voice/data transmission using a Digital Communications Protocol (DCP) that support two 64-kb/s voice and data channels and one 8-kb/s signaling channel at a single interface. Standard system and terminal features for System 75 are listed at pages 147-149 in the article by A. Feiner et al. in AT&T Technical Journal, Vol. 64, No. 1, January 1985 at pages 145-151 and include features such as direct inward and outward dialing, multiple call appearances of extensions, bridged calls, called/calling party identification, message retrieval, etc. The buses, service circuits and control complex are not shown in present FIG. 1, or described further hereinafter, to simplify the description of the present invention, but are included for all overall understanding of such PBX network, and further information thereon can be obtained from the above-mentioned Baxter et al. article.

In accordance with the present invention, phone management functionality is povided to desired PCs on PC network 10 by logically associating certain voice terminals 23 associated with PBX network 20 with desired PCs 11 associated with PC network 10. For purposes of discussion hereinafter, it will be assumed that voice terminals 23.sub.1 to 23.sub.3 of PBX network 20 are to be logically associated with PCs 11.sub.1 to 11.sub.3, respectively, of PC network 10. To perform such logical association of voice terminals and PCs, phone management server device 21 is disposed as an interface between PC Network 10 and PBX Network 20 to provide phone management server functionality to desired PCs 11.sub.1 to 11.sub.3 of PC network 10. Phone management server device 21 is a PC including (1) an NAU 13.sub.5 which interfaces with PC network 10 and permits phone management server device 21 to communicate with the PCs 11 of PC Network 10 using a STARLAN phone management (PM) signaling protocol, (2) a Ditigal Communications Protocol interface (DCPI) 26 which (a) is an existing hardware and software product that only uses the hardware thereof and runs a phone management server application program, and (b) permits phone management server device 21 to communicate with PBX Network 20 using DCP, and (3) internal interface hardware and software which provides the translation in either direction between the protocol of the NAU 13.sub.5 messages and the protocol of the DCPI 26 messages so that transmissions can be provided between the PCs of Network 10 and Hub 22 of Network 20.

Phone management server device 21, with NAU 13.sub.5 and DCPI 26, is a shared PC Network 10 resource running an application that communicates with a PBX Network 20 call control program using standard protocol messages recognized for phone management functions in the PBX Network 20, and communicates with the PC Network 10 end users using a software protocol that provides the phone management server functions to the PCs. The end user PCs 11.sub.1 to 11.sub.3 logically associated with voice terminals 23.sub.1 to 23.sub.3, respectively, on PBX Network 20, each include a phone management application program associated with the included NAU 13.sub.i which terminates the phone management server protocol and provides the end user with access to the phone management functions. More particularly, the phone management server protocol defines a generic command set for access to phone management server functions.

To provide PC Network 10 end users 11 phone management functions, the end user PCs 11 of PC Network 10 and the administration software in hub 22 of PBX Network 20 need to perform in the following manner. First, the PBX Network 20 is administered so that all call appearances of voice terminals 23.sub.1 to 23.sub.3 are bridged to the station corresponding to phone management server device 21 which provides the phone management server function for PC Network 10. Known PBX Networks usually support a predetermined amount of bridged call appearances to a single station or terminal, where any call to the single station or terminal concurrently appears at all other stations or terminals which are bridged to the single station or terminal and requests from any one of the bridged appearances are processed in the same manner. To illustrate bridged appearances within a PBX Network, FIG. 2 shows how exemplary voice terminals 23.sub.1 to 23.sub.3, assumed to correspond to Extension Nos. 7001-7003, respectively, can each have a separate bridged appearance on an exemplary secondary voice terminal 31. These bridged appearances are defined in call processing software 30 in PBX hub 22 and associated one appearance on two or more voice terminals and might be found with an executive and secretary arrangement. The association of the two or more voice terminals is logical and PBX hub 22 treats them equally. In other words, both voice terminals ring simultaneously when a call is destined for a particular extension, and either voice terminal can place a call, answer a call, and retrieve a stored message or display a calling party identification if both voice terminals are capable thereof. The fundamental element is how the PBX call processing software 30 signals the voice terminals. With, for example, two DCP voice terminals with a common bridged appearance such as exemplary voice terminals 23.sub.1 and voice terminal 31, corresponding to Extension 7001, the PBX call processing software in hub 22 signals both voice terminals with the same signaling message over DCP signaling channels 32.sub.1 and 33. In a similar manner, call processing for the bridged appearances of voice terminals 23.sub.2 /31, for Extension 7002, and 23.sub.3 /31, for Extension 7003, is accomplished over signaling channels 32.sub.2 /33 and 32.sub.3 /33, respectively. The signaling messages that propagate between the DCP voice terminals 23 and PBX hub 22 are collectively termed the DCP signaling protocol. In an Integrated Services Digital Network (ISDN), such signaling protocol would be the CCITT-defined Q.931 protocol.

Extending the Bridged appearance concept to phone management server 21 of FIG. 1 is shown in FIG. 3 where voice terminal 23.sub.3 on PBX Network 20 has its bridged appearance on phone management server 21 and is logically associated with PC 11.sub.3 on PC Network 10. PC 11.sub.3 via NAU 13.sub.3 runs phone management user application software that provides the user interface to achieve the appropriate screen format for phone management information to be displayed, and terminates a phone management application protocol that also terminates in phone management server 21 via NAU 13.sub.5. Signaling between PC 11.sub.3 and phone management server device 21 is accomplished via PC Hub 12 and signaling channel 34 using a PC Network phone management protocol which functions similar to the the DCP signaling protocol of PBX network 20. Phone management server device 21 includes phone management server application software that performs both the routing and the PBX Network DCP signaling message to PC Network phone management message translations and vice versa.

FIG. 4 illustrates the exemplary functional steps, for the arrangement of FIG. 3, of the retrieval on PC 11.sub.3 of PC Network 10 of one or more messages previously stored by the call processing application software 30 in PBX Hub 22 for the logically associated voice terminal 23.sub.3 of PBX Network 20. Such steps also illustrate the functionality and interaction of the PC phone management user application software, the phone management server application software, and the call processing application software in PBX Hub 22. In the first step shown in block 40, a user on PC 11.sub.3 invokes the phone management user application software and obtains a PC screen display that includes a "message waiting" indication and shown in block 41. The user then invokes the message retrieval command associated with the phone management user application software on PC 11.sub.3 as shown in block 42. In response to such command, the phone management user software in PC 11.sub.3 generates and sends the command message for instituting message retrieval to the phone management server application software in phone management server device 21 via NAU 13.sub.3, signaling channel 34 and NAU 13.sub.5 using the PC Network phone management protocol as shown in block 43 of FIG. 4. Essentially this command message specifies that "PC user 11.sub.3, at PC Network address XXXXX, wants to retrieve a PBX message".

The phone management server application software accepts and translates the received PC Network 10 phone management protocol message into a corresponding DCP protocol message as shown in block 44 of FIG. 4. Essentially the DCP protocol message specifies that "Extension 7003 wants to retrieve a PBX message" and sends it via signaling channel 33 to the PBX call processing application software 30. PBX call processing application software locates the phone message for extension 7003 and sends it to all bridged appearances (voice terminal 23.sub.3 and phone management server device 21) as shown in block 45 of FIG. 4. If voice terminal 23.sub.3 is an analog terminal rather than a digital terminal that accepts the DCP signal, the PBX hub 22 will only send it to phone management server device 21. Phone management server device accepts the message and performs the proper DCP signaling message to PC Network phone management signaling message translation and routes such translated message to the correct PC Network PC, PC 11.sub.3 as shown in block 46 of FIG. 4. The PC phone management user application software accepts the message from server device 21 and displays the message on the screen of PC 11.sub.3 as shown in block 47 of FIG. 4.

It is to be understood that other phone management functions found with PBX Network 20 can also be performed with the present phone management server application, such as placing voice calls on voice terminal 23.sub.3 from a directory on PC 11.sub.3, and displaying calling/called party identification on the screen of PC 11.sub.3 using a similar procedural sequence as shown in FIG. 4. For example, to place a voice call from a directory, blocks 40 and 43-44 of FIG. 4 would remain the same; blocks 41-42 would instead invoke the directory of numbers store in the PC phone management user memory and invoke a particular selection therefrom; and block 45 would state that the PBX call processing application software generates and sends the appropriate call message to either the called extension or over a trunk 25 to a remote PBX or central office to complete the call. Blocks 46 and 47 could also include the steps of transmitting the called/calling party identification information back to the PC for display on the screen of the PC. It is to be further understood that the PBX and PC Network phone management protocols to be used are dependent on, and should be compatible with, the protocols used by the particular PBX and PC Networks 10 and 20 which are to be used and include the voice terminals and PCs to be logically associated.

* * * * *