CN1375145A - digital browser phone - Google Patents

Abstract

A telephone system (10) wherein all the functions of a digital phone can be accessed and implemented on a personal computer (20) alone, thereby eliminating the need for a telephone set. By means of a computer display (26) and mouse (22), keyboard or other input/output command devices, a user accesses and implements all digital telephone functions without a physical telephone set, the personal computer (20) also provides the audio function. A graphical representation of a telephone set or other telephone-related form is provided on the computer display (26) and accessed by the mouse (22), keyboard or other command device, this being accomplished by a computer program providing graphical interface implementation. A significant advantage of the system (10) is computer access to a utilization of digital telephone functions from a remote location with communication via Internet, LAN, WAN, RAS or other medium (32).

Description

digital browser phone

Cross References to Related Applications

The applicant claims the benefit of priority to provisional application Serial No. 60/121755, filed February 26, 1999, entitled "Digital Browser Phone," which application is incorporated herein by reference.

Background of the invention

This invention relates generally to telephone communication systems, and more particularly to new and improved systems in which all the functions of a digital telephone are available on a computer.

Digital computers (especially personal computers) are playing an increasingly important role in the telephone system. For example, the personal computer plays a central role in speech processing systems utilizing computer telephony integration, wherein the personal computer is functionally interposed between a telephone switch such as a private telephone exchange (PBX) and the telephone set. In addition, digital phones themselves have advanced with additional features and functions that provide more and better functionality than conventional phones.

Summary of the invention

In basic computer telephony integration, the PBX is connected through a computer telephony interface to a personal computer, which in turn is connected through another interface to a telephone, such as a digital telephone. It is highly desirable and advantageously possible to provide a telephone system that can be used and implements all the functions of a digital telephone only via a personal computer, whereby the need for a telephone is eliminated. In other words, through a computer monitor and a mouse, keyboard, or other input/output command device, the user can also use and implement all digital telephony functions without the need for physical telephony equipment, and the personal computer can also provide audio functions. The biggest advantage of this system is that the computer can access and use the functions of the digital phone from a remote location through the communication of the Internet, LAN, WAN, RAS or other media.

Brief description of the drawings

Figure 1 is a block diagram of the system of the present invention;

Figure 2 is a schematic block diagram for illustrating the operation of the system of the present invention;

Figure 3 is a schematic block diagram for further illustrating one aspect of the operation of the system of the present invention;

Figure 4 is a schematic block diagram for further illustrating another aspect of the operation of the system of the present invention;

Figure 5 is a flowchart illustrating the operation of the system of the present invention; and

6-9 are schematic block diagrams illustrating the application of the system of the present invention.

Detailed description of the invention

A system 10 according to the present invention is briefly summarized in FIG. 1 . A PBX or other standard telephone switching equipment is represented by 12, and lines 14, 16 are standard interface lines connecting the PBX 12 to the subscriber's telephone network. In this illustration, a standard personal computer (PC) 20 is operated with a mouse 22 . Alternatively, PC 20 in the system of the present invention may be operated by a keyboard or some other input device. According to the invention, a graphical representation 26 of the digital telephone is provided in a display device of the PC 20. Various phone functions are accessed by manipulating the mouse 22, placing a cursor (not shown) on a particular part of the phone image 26, and then pressing the mouse. For example, the first step in making a call is to remove the handset or receiver from the phone cradle. This can be done by moving the mouse 22 so that the cursor is over the receiver representation in the left half of the image 26, and pressing the mouse 22. This will result in the appropriate commands being issued to the rest of the system, indicating that the initiation of the call is to be made. This process will now be described in detail. The above-mentioned processes are all completed by known ActiveX computer programs, or by other programs that can provide graphic interface implementations in the manner described in detail later. By way of further description, the next step in the call is to dial a number, which is performed by using the mouse 22 to sequentially move the cursor to the graphical representations of buttons in image 26 and pressing each button representation. Each time, the appropriate commands are issued to the rest of the system for the actual telephone dialing operation, as described subsequently. Although the preferred image 26 is used in this description as a representation of a digital phone, the image 26 can also have other phone-related forms, such as a list of phone numbers that the user has the opportunity to call, and menus such as meeting, parking, etc. And phone features like shopping, among others.

According to the present invention, the system in Fig. 1 also includes a telephone server (generally identified by 30) for connecting PBX 12 and PC 20. Lines 14 and 16 from PBX 12 are connected to server 30. The communication link 32 connects the server 30 and the PC 20, and it can be a LAN, WAN, RAS, Internet, or a modem that can be connected to a telephone line, etc. The signals associated with the PBX 12 and the signals in lines 14, 16 are characterized by synchronous timing, which is a standard requirement for PBX operation. The signals in link 32 and the signals associated with PC 20 are asynchronous, as is required by the flexibility required in the timing of operation of PC 20 and communication link 32. Accordingly, the server 30 communicates possibly between the synchronous operation of the PBX 12 and the asynchronous operation of the communication link 32 and the PC 20. Server 30 allows an asynchronous user (such as a web browser operatively associated with PC 20) to communicate via link 32 with a synchronous device, such as a telephone exchange (i.e., PBX 12).

Briefly stated, and as shown in FIG. 1 , telephony server 30 includes therein digital telephony emulation interface 34 , application program interface 36 and logic 38 for binding link 32 and interfaces 34 , 36 . For example, interface 34 is commercially available from Voice Technology Group, Inc. under the names VoiceBridge-PC and VoiceBridge 2000. Interface 34 can provide a direct digital connection between the various PBXs and the computer telephony application computer (i.e., PC 20) and its processing boards, and can increase the amount of integrated information available from the PBX. The application program interface 36 develops a set of commands that can be understood by the software in the PC 20 according to the signals provided by the interface 34. Logic 38 provides the synchronous/asynchronous conversion described above. In this way, the logic 38 can act as an intermediary between the synchronous switching on the PBX side of the server 30 and the asynchronous packet switching on the other side of the server 30. For example, logic 38 packetizes requests from interface 34 so that they can be transmitted over link 32 and utilized by PC 20. This enables telephony events from the interface 34 to be converted in such a way that they can be utilized by objects in connection with the telephony image 26, ie the aforementioned ActiveX programs.

The selection and execution of various digital phone functions utilizing the graphic phone image 26 and the PC 20 cursor are all done by programs that provide a graphic interface solution. A preferred program is commercially available from Microsoft Corporation and is known as an ActiveX control. ActiveX controls allow the development of complex controls based on the Common Object Model (COM), which can be installed in dialog boxes, or in any ActiveX control container application. An ActiveX control is a COM-based object that draws itself within its own window, responds to events such as mouse clicks, and can be managed through an interface that includes specific properties and methods.

ActiveX controls can be implemented as in-process servers used within a control container, usually a small object. The control container uses control properties and methods to operate ActiveX controls, and receives notifications from ActiveX controls in the form of events. In this way, the control can be fully described through attributes, methods and events, and ActiveX is also a means of implementing control. Although ActiveX is utilized in the current description of the invention, other graphical interface schemes such as JAVA-APPLET and even lower level software such as C or C++ etc. may be used.

FIG. 2 illustrates the application of the principles of system 10 in FIG. 1 to perform digital call control via Internet Protocol (IP). In other words, by using the system in Figure 2, all the call control features of a digital phone can be provided to the user on the PC, wherein the PC can access these features through the Internet, and the selection and use of these features must be done with a mouse. or keyboard interactive phone graphic images or similar forms to complete.

In the system illustrated in FIG. 2, the PBX 12', PC 20', mouse 22', digital telephone emulation interface 34', and application program interface 36' are all similar to the corresponding components in the system 10 in FIG. In the system of Figure 2, some of the control components are actually the same C++ objects, but they operate differently depending on whether the control is configured as a client or a server. For this reason, the description that follows will also be divided into client and server parts. Components located in the dotted line area 50 are all in the same control, and now its methods, properties and events will be described in more detail.

The server control object 54 is responsible for completing the following functions. Object 54 converts VoiceBridge light events and display updates from VoiceBridge thread 56 into a graphical user interface (GUI) representation of these events for display on server monitor 58 . The GUI representation 60 is a softphone modeled by the VoiceBridge interface 34' that looks similar to a real digital telephone. In this scenario, the softphone provides a mirror image of what the user is seeing on his/her PC 20'. This mirror image is the means by which the user's activity status is provided.

The server control object 54 also translates the key and switch status commands from the TCP/IP socket thread 62 into GUI representations of these commands for display on the server monitor 58 . This completes the mirrored image above. Object 54 translates key and switch status commands from TCP/IP socket thread 62 into VoiceBridge API commands for execution and interaction with PBX 12′. Object 54 also converts VoiceBridge light events and display updates from VoiceBridge event thread 56 into a format suitable for subsequent packetization by TCP/IP socket thread 62 .

When the control 50 acts as a server, the TCP/IP socket thread 62 is responsible for completing the following functions. Packetizes light events and display updates from the server control object 54 for transmission to the client via a socket, and accepts packetized key press and hook state commands from the client, and demultiplexes these commands packetized and submitted to the server control object 54 for execution using VoiceBridge API commands or for display in a GUI. The VoiceBridge event thread 56 is responsible for utilizing the VoiceBridge API 36' to monitor the VoiceBridge event queue, check incoming light events and display changes, and submit these events to the server control object 54 for further processing.

The VoiceBridge API 36' and the VoiceBridge board 34' together provide an appropriate interface for the PBX 12'. The VoiceBridge board 34' handles all low-level interactions with the PBX 12' over the Synchronous Digital Station link. The VoiceBridge API 36' provides the means for the rest of the control 50 to interoperate with the PBX 12' using the VoiceBridge internal virtual phone.

The client control object 64 is responsible for the following functions. Object 64 translates mouse clicks and keystrokes from client 20' into commands suitable for subsequent packetization by TCP/IP socket thread 66. As described above, the user inputs mouse clicks and keystrokes through the GUI representation of the softphone 68 . Similar to the server GUI 60, the client GUI 68 is a softphone emulated by VoiceBridge 34' that looks similar to a real digital telephone. Client control object 64 also translates light events and display updates from TCP/IP socket thread 66 into a graphical representation on user monitor 20 . These events can all be displayed in the GUI softphone 68 described above.

The responsibilities of the TCP/IP socket thread 66 are the same as those described in the server section, but in reverse order. That is, the button and hook state commands come from the client object and are sent packetized to the server. Light updates and display updates are fetched from the server, depacketized, and passed to the client object for further processing.

For those skilled in the art, other programming methods besides sockets and threads, and other protocols besides TCP, IP and H.323 (such as ATM or MGCP or SIP) can also be used to implement The client and server control objects described here.

Figures 3 and 4 illustrate the structure of the controls, including voice and digital controls over Internet Protocol (IP). The control is used in a client/server environment to provide IP access to digital phones from remote locations. In the structure of Fig. 3 and Fig. 4, the speech component in the control is processed in one of the following two ways. The method in Figure 3 uses the WAV interface available from Dialogic Corporation, or Natural Microsystems (NMS), or other equipment, together with Microsoft's NetMeeting (version 2.1) SDK, to provide an H.323 protocol stack with audio capabilities. The method in Fig. 4 uses the H.323 protocol stack (middleware) provided by Dialogic DM3 platform, NMS Fusion platform or other devices. In both methods, the NetMeeting (version 2.1) SDK is used on the client side.

Referring first to Fig. 3, in a manner similar to the arrangement of PBX 12, lines 14, 16 and interface 34 illustrated in Figs. Interface 84. Interface 84 is connected by voice bus 86 to a digital signal processor (DSP) 88 contained in server control 90 . The control 90 also includes a WAV interface 92 and a protocol stack 94 . Also included in the client control 100 is a protocol stack 102, and the server and client controls 90 and 100 are connected by an IP communication link 106, respectively.

In this way, the method for voice over IP in FIG. 3 utilizes the WAV interface provided by Dialogic, NMS or other devices. Using this approach, controls 90 and 100 utilize NetMeeting (version 2.1) API calls to handle all connection establishment and capability negotiation on the server and client side. The audio channel remains open during the client/server conversation. Mute is sent until the VoiceBridge interface 84 opens an audio channel with the PBX 80 (i.e. when making or responding to a phone call). This provides the desired effect of "cutting in" the audio when a call is initiated or answered.

Arrow 110 in Figure 3 shows the audio path. PBX 80 provides audio to VoiceBridge interface 84, which in turn places voice data into voice bus 86 via drivers. The voice data is extracted from the voice bus by the DSP card 88 and provided to the server PC (not shown) through the WAV interface 92 . The NetMeeting software 94, 102 utilizes the WAV interface 92 to implement the H.323 protocol, which includes provisions for connection negotiation (H.245) and for voice packetization and transmission (Real Time Protocol-RTP).

Referring now to FIG. 4, which illustrates Voice over IP using middleware, components similar to those in FIG. 3 are identified by the same reference numerals (with an apostrophe '). Server control 120 includes middleware 122 and arrow 124 indicates the audio path. There are no changes to the client implementation for this method. The server side does change, and the interface is currently provided on the client side using middleware 122 (eg DM/3 IPLINK from Dialogic, or Fusion from NMS). This middleware provides the H.323 protocol stack in place of the NetMeeting SDK. The speech path identified by the arrow is very similar to the path given in the Figure 3 method.

The system in Figure 2 is further illustrated by the example transactions that follow. The first demonstration instance is to establish a client/server connection. Before the client can establish a connection with the server, the server must wait for the user's connection. Execute the control method whose parameter is FALSE and identified by startRemote(), so as to start the server waiting for the client to connect. The start remote and other control methods and parameters are described in detail below. Next, the remote hostname parameter of the client control is set to the server's IP address (ie, 204.242.28.197). Then execute the control method startRemote() with the parameter TRUE. This starts the initial handshaking sequence between the client and server. The initial handshake sequence is outlined in Figure 5.

The next illustrative example is a client keystroke transaction. The sequence that follows describes the execution of an entire keystroke transaction from the client to the PBX with reference to the components in FIG. 2 . The hook state transaction is the same as the subsequent sequence, only the direction of data transfer is different.

1. The client user presses the GUI phone key on the image 68 with his/her mouse 22'.

2. The client control object 64 receives the notification that the mouse is pressed, and determines the key number of the pressed GUI phone key, and then tells the TCP/IP socket thread 66 to send a key command to the server.

3. The user's TCP/IP socket thread 66 creates a key group with the appropriate key number and supporting information, and sends this data to the server via a socket command.

4. The TCP/IP socket thread 62 of the server receives the button command packet, depackets the command, and tells the server control object 54 to perform the button operation.

5. The server control object 54 then issues a vb_press_key() command to the VoiceBridge API 36'. The key command will be described in detail later. At the same time, the server control object 54 displays keystrokes in the server GUI 60 for the purpose of tracking activity.

6. The VoiceBridge API 36' passes the command to the VoiceBridge board 34' which sends the command to the PBX 12' via a synchronous digital data link. The PBX 12' then performs key operations appropriately.

The next illustrative example is a light update sequence. The entire light update transaction is described subsequently. This sequence is very similar to the key sequence described above, but this time initiated by the PBX 12' and terminated by the client GUI phone 68. It should also be noted that the display update sequence is the same as the one below, the only difference being the data transferred.

1. The PBX 12' sends an optical update data packet to the VoiceBridge board 34' through a digital data link.

2. The VoiceBridge event thread 56 receives light updates via events generated by the VoiceBridge board 34' and passed through the VoiceBridge API 36'.

3. The VoiceBridge event thread 56 sends a light update event to the server control object 54 . The server control tells the server TCP/IP socket thread 62 to send light events to the client.

4. The TCP/IP socket thread 62 of the server packetizes the light event information, including the light sequence number and the new state, and sends the information to the client computer through the socket command.

5. The client's TCP/IP socket thread 66 receives the optical update packet, depackets the update, and notifies the client control object 64 of the optical update.

6. The client control object 64 then displays the new light state in the GUI phone 68 light image.

Now describe the properties, methods, and events of the various controls associated with the system in Figure 2-4. The control's methods and properties allow its container to perform keystrokes (using the mouse or methods), set and get the state of the light, set and get the hookswitch state, and set and get display information for the phone. Additionally, multiple phone types and sizes can be configured. The ability to interact with the VoiceBridge card 34 may be provided within the ActiveX control. This allows complete control of individual VoiceBridge channels from within web pages, Visual Basic programs, or even Power Point presentations. Include client/server capabilities in the control. This allows ActiveX controls to be fully remote operated (call control) over TCP/IP sockets. As mentioned above, a client computer (ie, a laptop) connects to the server using a TCP/IP socket. The server host includes the VoiceBridge board connected to the PBX. The server control accepts key and switch status commands from the client, allowing remote users to interact with the VoiceBridge channel. The client in turn receives light updates, display updates, and gain/loss of carrier events from the server, thereby providing the full status of the VoiceBridge line from the remote location.

The custom properties of the control are given in Table I. Describe its various characteristics in the column to the right. When a container changes these properties, its characteristics change as well.

Table I attribute name attribute type describe PhoneType (phone type) Short Change the type of phone displayed 1(LUCENT7434), 2(MITELSS430), 3(NORTEL2616), 4(SIEMENSROLMPHONE400) SizePercent (size percentage) Short Percentage of all dimensions. Use this value to scale the phone and maintain the original aspect ratio. Set this value to (-1) if the control's size is controlled by another device (ie, using the container's object handle). Min-25%Max-600% KeyUpDownDelay (key down key up delay) Short The time, in milliseconds, that the key was pressed when using the PressKey() method (the key automatically bounces when PressKey() is applied). Min-0 milliseconds Max-1000 milliseconds InteractiveMode (interactive mode) BOOL TRUE - The user can press the key and continue, and can go off-hook with the mouse. FALSE - User input via mouse click is not received. DummyCaps (pseudo-Caps) BSTR This is a dummy parameter used to help serialize (store) all key press information for the control. The content of this parameter cannot be set by the user, nor can it be seen by the user. DisplayText (display text) BSTR Displays the text contained in the device. The string can be of any length and may wrap automatically at column boundaries. Strings that are too long for display are truncated, but stored at their full length. For output to the second line, pad with spaces. No newlines or control symbols are used. EnableToolTips (enable tool tips) BOOL TRUE - Allow tooltips to pop up. FALSE - Suppress popup tooltips. controlID (control ID) Short This ID is used to identify the phone event in the recorded event file. This is the marker symbol associated with each logged event. Allows recording of multiple sets of data in one file and subsequent playback. This ID is also used as the VoiceBridge channel number when the control is used to drive a VoiceBridge channel. RemoteHostName (remote host name) BSTR Identify the IP address of the remote host. This parameter must be set before using the start remote() method to set the client to remote mode.

The customization method of the control is given in Table II. The parameters in the middle column indicate the action to take. The definition in the right column is part of the ActiveX definition. Containers for ActiveX controls are able to interact with the methods presented in Table II. When the communication link is not IP, use the StartActivePCMode method. When the communication link adopts intra-IP, utilize start remote method.

Table II attribute name attribute type describe PressKey (press key) INT KeyNum After pressing the key specified by keyNumber, the key will be released automatically after 'KeyUpDownDelay' milliseconds. SetLightState (set light state) INT lightNumINT newState Sets the specified light to the new blinking state. The blink rate is predetermined by the phone type and cannot be modified by the user. Valid states are: black 0 steady 1 sudden flash 2 flashing 3 fast flashing 4 SetHookState (set hook state) BOOL state TRUE-off-hook FALSE-on-hook GetLightState (get light state) INT lightNum Returns the light state as a short integer. This state is discussed in SetLightState above. An additional return value has been added. Unknown 99 Returns Unknown if an invalid light sequence number is passed to GetLightState. GetHookState (get hook state) NONE Returns the status of the current hook key TRUE-phone off-hook FALSE-phone on-hook SetKeyCaption (set key caption) Short keyNumBSTR caption Sets the title text for the specified key. When displayed, strings that are too long will be is truncated. GetPhoneSize (get phone size) Long ^* sizeXLong ^* sizeY Returns the size of the control within the HIMETRIC unit GetKeyCaption (get the key title) Short keyNum Returns the title of the key specified by keyNum IsValidKey (is a valid key) Short keyNum Returns TRUE if the key specified by keyNUM is valid (ie if the key number is on the phone). Otherwise returns FALSE. IsValidLight (is valid light) Short lightNum Returns TRUE if the light specified by lightNum is a valid light (that is, the light number is on the phone). Otherwise, returns FALSE. StartActivePCMode (start active PC mode) Long password Use this method to start controlling the VoiceBridge channel. The channel number is specified in the controlID attribute that must have been set before calling this method. Note: Active PC Telephony mode is only supported on Windows NT. The VoiceBridge SDK must be installed on the system, and the VoiceBridge board must be loaded before entering active mode. StartRemote (start remote) BOOLclientOrHost According to the value of clientOrHost, the meaning of this command will change slightly. If it is a host, set the clientOrHost parameter to FALSE. Then the control waits for the guest The client machine connects on socket number 333 of the machine. Once the connection is successful, the host will automatically start the active PC mode, and negotiate the channel number and PBX type with the client. Note: Host mode is only supported on Windows NT. The VoiceBridge SDK must be installed on the system, and the VoiceBridge board must be loaded before being connected in host mode. If it is a client, set the clientOrHost parameter to TRUE. The control will then try to establish a connection with the host waiting at the IP address specified in the Remote Host Name. If no hosts are waiting, or if another network error occurs, the error is reported to the application. Note: Client mode can only be supported under Windows NT and windows95. The user's control ID.

The custom events for the controls are given in Table III. Events are generated from controls to containers to indicate what's happening, ie they provide notifications. The six status events in Table III are related to the record/playback methods in Table II and tell the container what to do, ie enable or disable the key.

Table III KeyPressed (key pressed) int keyNumber The user presses a key with the mouse. KeyReleased (key release) int keyNumber The user releases the key previously pressed with the mouse. OffHook (off-hook) NONE The user uses the mouse to go off-hook. OnHook NONE The user hangs up with the mouse. KeyCaptionChanged (key title has been modified) Int keyNumber The user changes the key title specified by keyNumber KeyPressed (key pressed) int keyNumber The user presses a key with the mouse. LightChange (light change) Short lightNum lightNum specified light change flash state.

The system architecture of the present invention described in conjunction with Figures 2-5 performs digital call control over IP. As noted above, the controls can be used in a client/server environment to provide access to digital telephones from remote locations. This capability can lead to a variety of very useful and desirable applications. A block diagram of utilizing the capabilities described above to provide a fully digital telephone feature to a teleworker is illustrated in FIG. 6 . Both PBX 150 and telephony server 152 are similar to PBX 12 and server 30 in the system of FIG. 1 . A remote access server (RAS) 154 is connected to a local area network (LAN) 156, which in turn is connected to a telephony server 152 of the present invention. RAS 154 provides a dial-in connection to LAN 156. The teleworker's personal computer 158 is connected to the RAS 154 via respective modems 160 and 162 and the telephone network 164.

In this way, a teleworker can utilize Remote Access Software (RAS) 154 to connect to the office's Local Area Network (LAN) 156 and use all the capabilities of the digital telephone at home. And if the teleworker also has a phone in the office, the control can also be set to not ring when the office phone rings (ie the teleworker's desk phone can be bridged to the control). This allows callers to be able to reach the teleworker using their normal office phone number when they are working from home. In addition, teleworkers can simultaneously access data (ie, e-mail, file servers, etc.) over their RAS lines.

The above system also allows the establishment of a remote call center. The ACD feature of the PBX can be extended remotely because the control can provide all the features of the PBX to the remote user. This allows call center agents to be part of the same ACD fleet even if they are thousands of miles apart. This saves money on office space and also greatly increases flexibility in call center overload situations.

Figure 7 shows an arrangement similar to that in Figure 6, but wherein the teleworker is connected to the office's LAN 156' via a web server 170 via Internet access.

The application example illustrated in Figure 8 provides a link from a remote office back to the company's PBX and mail system. PBX 180 and telephony server 182 are similar to PBX 12 and server 30 in the system of FIG. 1 . Wide area network (WAN) dedicated lines 184 and 186 connect branch offices or locations 188 and 190, respectively, to the central office or location. Like this, because a plurality of far-end offices have all possessed special-purpose data lines, are used for accessing the database, electronic mail etc. of the company, so the control of the present invention can extend the connection of PBX to the far-end branch. And because the remote offices all use the same PBX, it's possible to deploy a single corporate voicemail system. This eliminates all the difficulty and overhead of trying to bundle multiple separate phone systems and/or voicemail systems into a single seamless system.

An example application is illustrated in FIG. 9 where free calls and voicemail are provided to preferred vendors and users. PBX 200 and telephony server 202 are similar to PBX 12 and server 30 in the system of FIG. 1 . The web server 204 is operatively connected to the telephony server 202 . Vendors 206, 208, and 210 access web server 222, and ultimately telephony server 202, through their PCs 212, 214, and 216, respectively, and the Internet 220. A PBX 200 extension can be assigned to vendors and users by providing them with personal web pages, including controls, on a company intranet or Internet site 222. When you need to contact the seller/customer or make a call to the company, you only need to dial the three-digit or four-digit extension number instead of their long-distance PSTN number. Since calls are made over the Internet, no long distance charges will be added. And because they are all extensions of PBX 200, a company voice mailbox can be assigned to the seller or user, and they can leave messages, answer and add them to the voice mail distribution list.

In another example, other client applications can be enabled through client controls (eg, a voicemail application) as well as the telephony device. The above-mentioned client control uses the mouse, keyboard or other input devices to transmit commands to the server control. A voicemail application is another input device that can be connected as a remote client control. As the call is passed from the PBX to the server control, these events are also passed to the voicemail client control. In response to these events, the voicemail application can typically answer the incoming call, extract input information from the calling party, and record a message or redirect the call to another telephone extension. These actions taken by the voicemail application are represented as input to the client control, and this information is passed to the server control as described above. The present invention thus eliminates the need for voicemail applications to be within the distance constraints of the PBX, and also allows for an alternative connection to the PBX, similar to link 32 in FIG. 1 . A phone can also act as an input/output device for client controls. Key presses on the phone can be used as input by the client control and passed to the server control. Commands from the PBX can be passed to the client control via the server control, and can be provided to a phone attached to the client control for interpretation by the user.

It is therefore apparent that the present invention accomplishes its intended objects. While embodiments of the invention have been described in detail herein, this has been done by way of illustration and not limitation of the invention.

Claims (34)

1. A telephone communication system that provides access to all the functions of a digital telephone without the need for physical telephone equipment, comprising: a) computer means for transmitting phone features to the user; b) telephone server means for converting telephone signals from the telephone exchange into a form usable by the computer means; c) a computer link device for connecting the computer device and the telephony server; and d) Telephone linking means for connecting the telephony exchange and the telephony server. 2. The system of claim 1, wherein the computer means includes a computer display device for visually presenting the plurality of digital telephone features to the user. 3. The system of claim 1, wherein the computer device uses a mouse to accept control input from the user to control the virtual phone. 4. The system of claim 1, wherein the computer means includes a computer program that provides a graphical interface for the user to communicate telephony features and accept commands from the user. 5. The system of claim 1, wherein the telephony server device comprises: a) an interface device for terminating the telephone link at the telephone exchange; b) an application programming interface enabling an application to control the interface device to terminate the telephony link; and c) Logic means for providing telephony features in a format usable by the computer means. 6. The system of claim 5, wherein the telephony server means further includes monitor means capable of providing the status of the interface means. 7. The system of claim 5, wherein the application programming interface includes features that a digital phone should have, including dialing, transfer, conference, hold line, display information, multiple appearances, redial, message waiting indication, disconnect call, fork switchable controls, joystick, speaker and microphone. 8. The system of claim 5, wherein the logic means provides conversion means between the telephony protocol of the telephony link means and the link protocol between the computer means and the telephony server means. 9. The system of claim 8, wherein the telephony protocol is a synchronous protocol. 10. The system of claim 8, wherein the telephony protocol supports a dedicated digital telephone set as a telephone set on the PBX. 11. The system of claim 8, wherein the link protocol is an Internet Protocol-based asynchronous protocol over Ethernet. 12. The system of claim 5, wherein the interface means connects the voice information to the voice packetization means for communication through the computer link means. 13. The system of claim 11, wherein the voice is packetized according to the H.323 protocol standard. 14. The system of claim 5, wherein the interface means connects the control information to the control packetization means for communication through the computer link means. 15. The system of claim 14, wherein the control packetization means includes TCP/IP sockets. 16. The system of claim 14, wherein the control grouping means includes a server control object that manages commands and events among a plurality of devices including the interface means, the computer link means and the monitor means. 17. The system of claim 1, wherein the computer link means comprises a local area network, a remote access server with a modem, a public switched telephone network, and a client modem. 18. The system of claim 1, wherein the computer link means may include a local area network, a web server, and the Internet. 19. The system of claim 1, wherein the computer link device is connected to a plurality of computer devices. 20. The system of claim 1, wherein the plurality of computer link devices are connected to the plurality of computer devices. 21. The system of claim 1, wherein the plurality of telephony server devices are connected to the plurality of computer link devices for connection to the plurality of computer devices. 22. The system of claim 1, wherein the user is a computer-controlled application. 23. The system of claim 22, wherein the computer controlled application is a voicemail application. 24. The system of claim 1, wherein the computer device is a wireless telephone system. 25. Including telephone exchanges and computers in the telephone communication system; a) server; b) a synchronous communication link between the telephone exchange and the server; c) an asynchronous communication link between the server and the computer; and d) the server includes a first component for providing a digital connection between the telephone exchange and a computer telephony application associated with the computer, for providing a command set for use by the computer based on a signal provided by the first component and a third component intermediary between a synchronous exchange associated with the synchronous communication link and an asynchronous packet exchange associated with the asynchronous communication link. 26. A telephone communication system according to claim 25, wherein the asynchronous communication link is via the Internet. 27. The telephony communication system of claim 25, wherein the computer includes a program for providing a graphical interface scheme of telephony-related form representations. 28. A telephone communication system in which all the call control features of a digital telephone are provided to a computer user, and wherein the features are accessible by the computer through a communication link, and wherein selection and use of features is via the telephone features using input devices Graphical image of the system includes: a) telephone exchange; b) a computer comprising a display device, a program providing a graphical interface solution for telephony-related form representations, and an access device for accessing the various features presented in the display device; c) an interface device including a digital telephone emulation interface and an application programming interface; d) a synchronous communication link operatively connecting the telephone exchange to the interface device; e) event thread means operatively connected to the interface means for monitoring incoming phone feature light events and computer display change commands received from the interface means; f) first control object means operatively connected to the interface means and the event thread means; g) a second control object device operatively connected to the computer; h) a first socket thread device operatively connected to the first control object device; i) a second socket thread device operatively connected to the second control object device; j) an asynchronous communication link operatively connected to the first and second socket thread means; h) the first control object means converts the telephone feature key and hook state commands from the first socket thread means into interface commands for execution and interaction with the telephone switching device, and the first control object means converting phone feature light events and display updates received from the event thread means into a form suitable for processing by the first socket thread means; l) the first socket means packetizes phone feature light events and display updates from the first control object for transmission over the asynchronous communication link, and the first socket means through the asynchronous communication link The way accepts the grouped phone feature button and hook switch status commands, and degroups the commands so that they can be processed by the first control object; m) The second control object means converts input device operations and phone feature keystrokes from the computer into commands suitable for grouping by the second socket thread means, and the second control object means converts commands from the second The phone feature light events and display updates of the socket thread device are translated into graphical representations in the computer display device; and n) the second socket device packetizes phone feature light events and hook status commands from the second widget object device for transmission over the asynchronous communication link, and the second socket device communicates via the The asynchronous communication link accepts packetized phone feature light updates and display updates and depackets the updates for processing by the second control object. 29. The telephone communication system of claim 28, wherein the telephone-associated form is a graphic image of a digital telephone device. 30. The telephone communication system of claim 28, wherein the input device is a computer mouse. 31. The telephone communication system of claim 28, wherein the input device is a computer keyboard. 32. The telephone communication system of claim 28, wherein the asynchronous communication link is via the Internet. 33. A method for performing keystroke transactions in a telephone communication system providing access to all features of a digital telephone without necessarily requiring physical telephone equipment, the system including a computer for communicating telephone features to a user, and includes a display device that visually presents various digital telephone features to the user, an input device that accepts input from client controls, such as a mouse, and a computer program that provides a graphical interface for the user to communicate telephone features and accept commands from the user, for A telephone server for converting a telephone signal from a telephone exchange into a computer usable form, a computer link for connecting the computer to the telephone server, and a telephone link for connecting the telephone exchange to the telephone server, the method comprising: a) selection of the graphical user interface telephone key in the image of the computer display device via the input device; b) determine the identity of the telephone key of the graphical user interface, and send a key command to the telephone server; c) Utilize the identification to set up the key grouping, and send the key grouping command with data to the telephone server through the computer link; d) accept a key grouping command with data, and depacketize the command; e) issue a keystroke command to the telephony server; and f) sending a keystroke command from the telephone server to the telephone exchange through the telephone link, so as to execute the keystroke command. 34. A method for performing optical update transactions in a telephony communication system that provides access to all features of a digital phone without requiring physical telephony equipment, the system including a a computer, and including a display device for visually presenting various digital telephone features to a user, an input device for accepting input from client controls, such as a mouse, and a computer program for providing a graphical interface to the user for communicating telephone features and accepting commands from the user, A telephone server for converting telephone signals from a telephone exchange into a computer usable form, a computer link for connecting the computer and the telephone server, and a telephone link for connecting the telephone exchange and the telephone server, the method comprising: a) sending an optical update data packet from the telephone switching device to the telephone server through the telephone link; b) sending light update events from the telephony server and packetizing the light event information; c) sending the packetized light event information through the computer link; d) receiving packetized optical event information and depacketizing the optical event information; and f) Displaying light event information in a computer display device.

Images