Digital browser phone
A telephone system wherein all the functions of a digital telephone can be accessed and implemented on a personal computer alone, thereby eliminating the need for a telephone set. By means of the computer display and mouse, keyboard or other input/output command devices, a user accesses and implement all digital telephone functions without the physical telephone set, the personal computer also providing the audio function. A graphical representation of a telephone set or other telephone-related form is provided on the computer display and accessed by the mouse, keyboard or other command device, this being accomplished by a computer program providing graphical interface implementation. A significant advantage of the system is computer access to and utilization of digital telephone functions from a remote location with communication via Internet, LAN, WAN, RAS or other mediums.
Latest Patents:
This application is a continuation application of U.S. patent application Ser. No. 09/513,660 filed Feb. 25, 2000 now U.S. Pat. No. 7,120,140 which claims priority to U.S. Provisional Application No. 60/121,755 filed Feb. 26, 1999 and entitled “Digital Browser Phone”, both of which are incorporated herein by reference.
BACKGROUND OF THE INVENTIONThis invention relates generally to telephone communication systems, and more particularly to a new and improved system wherein all the functions of a digital telephone are usable on a computer.
Digital computers, in particular personal computers, are playing an ever increasing role in telephone systems. For example, the personal computer plays a central role in voice processing systems utilizing computer telephony integration wherein the personal computer is interposed functionally between the telephone switch such as a private branch exchange (PBX) and the telephone set. In addition, the digital telephone itself represents an advance in the additional features and functions it provides over and above those provided by conventional telephones.
SUMMARY OF THE INVENTIONIn a basic computer telephone integration, a PBX is connected through a computer telephony interface to a personal computer which, in turn, is connected through another interface to a telephone set, such as a digital advantageous to provide a telephone system wherein all the functions of a digital telephone can be accessed and implemented on a personal computer alone, thereby eliminating the need for a telephone set. In other words, by means of the computer display and mouse, keyboard or other input/output command devices, a user could access and implement all digital telephone functions without the physical telephone set, the personal computer also providing the audio function. A significant advantage of such a system is computer access to and utilization of digital telephone functions from a remote location with communication via internet, LAN, WAN, RAS or other mediums.
A system 10 according to the present invention is summarized briefly in
In accordance with the present invention, the system of
Briefly, and as shown in
The selection and performance of various digital telephone functions utilizing the graphical phone image 26 and cursor of PC 20 is accomplished by means of a program providing graphical interface implementation. A preferred program is commercially available from Microsoft Corporation and known as ActiveX control. ActiveX control enables one to develop sophisticated controls based on the common object model (COM) that can be installed in dialog boxes or any ActiveX control container application. ActiveX control is a COM-based object that can draw itself in its own window, respond to events like mouse clicks, and be managed through an interface that includes certain properties and methods.
An ActiveX control is implemented as an in-process server, typically a small object, that can be used in a control container. The control container operates the ActiveX control by using the control's properties and methods, and receives notification from the ActiveX control in the form of events. Thus, a control is described completely by properties, methods and events, and ActiveX is a means of implementing a control. While ActiveX is utilized in the present illustration of the invention, other graphical interface implementations can be employed such as JAVA-APPLET and even lower level software such as C or C++ to name a few.
In the system illustrated in
The server control object 54 is responsible for the following functions. Object 54 translates VoiceBridge light events and display updates from the VoiceBridge Thread 56 into graphical user interface (GUI) representations of these events for display on a server monitor 58. The GUI representation 60 is a soft phone that looks like the actual digital station set that the VoiceBridge interface 34′ emulates. In this implementation, the soft phone provides a mirror image of what the client is seeing on his/her PC 20′. The mirror image is a means to provide status of client activity.
Server control object 54 also translates key press and hook state commands from the TCP/IP Socket Thread 62 into GUI representations of these commands for display on the server monitor 58. This completes the mirror image described above. Object 54 translates key press and hook state commands from the TCP/IP Socket Thread 62 into VoiceBridge API commands for execution and interaction with the PBX 12′. Object 54 also translates VoiceBridge light events and display updates from the VoiceBridge Event Thread 56 into a format suitable for subsequent packetization by the TCP/IP Socket Thread 62.
The TCP/IP Socket Thread 62 has the following responsibilities when the control 50 is acting as a server. It packetizes light events and display updates from the Server Control Object 54 for transmission over a socket to the client, and it accepts packetized key press and hook state commands from the client, unpacketizes these commands and submits them to the Server Control Object 54 for execution using VoiceBridge API Commands or display on the GUI. The VoiceBridge Event Thread 56 is responsible for monitoring the VoiceBridge event Queue for incoming light events and display changes using the VoiceBridge API 36′ and submitting these events to the Server Control Object 54 for further processing.
The VoiceBridge API 36′ and the VoiceBridge Card 34′ together provide a suitable interface to the PBX 12′. The VoiceBridge Card 34′ handles all low-level interactions with the PBX 12′ over synchronous digital station links. The VoiceBridge API 36′ provides a means for the rest of the control 50 to interact 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 key strokes from the client machine 20′ into the commands suitable for subsequent packetization by the TCP/IP Socket Thread 66. The mouse clicks and key strokes are input by the user from a GUI representation of a soft phone 68 as previously described. Similar to the server GUI 60, the client GUI 68 is a soft phone that looks like the actual digital station set that the VoiceBridge 34′ emulates. Client control object 64 also translates light events and display updates from the TCP/IP Socket Thread 66 into graphical representations on the client monitor 20. These events are displayed on the GUI soft phone 68 described above.
The TCP/IP Socket Thread 66 has the same responsibilities as described in the server section, but in reverse. That is to say, key press and hook state commands come from the client object and are packetized and sent to the server. Light updates and display updates are taken from the server, unpacketized and passed to the client object for further processing.
To one skilled in the art, it is apparent that programming methods other than socket and threads, as well as protocols other than TCP, IP and H.323 (such as ATM, MGCP or SIP) can be utilized to implement the client and server control objects described herein.
Referring first to
Thus, the voice over IP method of
The arrow 110 in
Referring now to
The system of
The next illustrative example is a client key press transaction. The following sequence describes an entire key press transaction, from the client machine to the PBX for execution in reference to the components of
1. The client user presses a GUI phone key on image 68 using his/her mouse 22′.
2. The Client Control Object 64 is notified on the mouse press and determines the key number (ID) of the GUI phone key that was pressed and tells the TCP/IP Socket Thread 66 to transmit the key press command to the server.
3. The client's TCP/IP Socket Thread 66 builds a key press packet with the appropriate key number and supporting information and sends this data to the server via a socket command.
4. The server's TCP/IP Socket Thread 62 receives the key press command packet, un-packetizes the command and tells the Server Control Object 54 to press the key.
5. The Server Control Object 54 then issues a vb_press_key ( ) command to the VoiceBridge API 36′. The press key command will be described in further detail presently. At the same time, the Server Control Object 54 shows the key press on the server GUI 60 for the purpose of activity trace.
6. The VoiceBridge API 36′ passes the command to the VoiceBridge card 34′, which sends the command along to the PBX 12′ over the synchronous digital data link. The PBX 12′ then acts on the key press appropriately.
The next illustrative example is a light update sequence. The following describes an entire light update transaction. This sequence is very similar to the key press sequence described above, but this time is initiated by the PBX 12′ and terminates on the client GUI phone 68. Note also that a display update sequence is identical to the following sequence, only the data transmitted is different.
1. The PBX 12′ sends a light update data packet over the digital data link to the VoiceBridge card 34′.
2. The VoiceBridge Event Thread 56 receives the light update via an event generated by the VoiceBridge card 34′ and passed through by the VoiceBridge API 36′.
3. The VoiceBridge Event Thread 56 passes the light update event to the Server Control Object 54. The server control tells the server's TCP/IP Socket Thread 62 to transmit the light event to the client.
4. The server's TCP/IP Socket Thread 62 packetizes the light event information, including the light number and new state, and transmits this information to the client via socket commands.
5. The client's TCP/IP Socket Thread 66 receives the light update packet, un-packetizes the update and notifies the Client Control Object 64 of the light update.
6. The Client Control Object 64 then displays the new light state on the lamp image in the GUI phone 68.
The various properties, methods and events of the control associated with the system of
The custom properties of the control are set forth in Table I. In the right-hand column various characteristics are described. When the container changes the properties, changes occur in the characteristics.
The custom methods of the control are set forth in Table II. The parameters in the middle column indicate the actions to be taken. The definitions in the right-hand column are part of the ActiveX definitions. The container of the ActiveX control can interact with the methods set forth in Table II. The StartActivePCMode method is used when the communications link is not IP. The StartRemote method is used when the communications link is with IP.
The custom events of the control are set forth in Table III. The events occur from the control to the container to indicate what happened, i.e. they provide a notification. The six status events in Table III are related to the record/playback methods of Table II and tell the container what to do, i.e. enable or disable keys.
The architecture of the system of the present invention described in connection with
Thus, a telecommuter can connect to the office Local Area Network (LAN) 156 using Remote Access Software (RAS) 154 and use all of the capabilities of a digital station set while at home. And if the telecommuter also has a phone at the office, the control can be set up to ring when the office phone rings (i.e. the telecommuter's desk phone can be bridged onto the control). This allows callers to use the telecommuter's normal office number to reach the telecommuter when they are working at home. In addition, the telecommuter can simultaneously access data (i.e. e-mail, file servers etc.) over his RAS line.
The foregoing also allows creation of remote call centers. Because the control provides all PBX features to remote users, the ACD features of the PBX can be extended remotely. This allows call center agents to be a part of the same ACD queue—even though they may be thousands of miles apart. This saves money on office space and also provides a tremendous increase in flexibility in providing call center overflow scenarios.
The application illustrated in
As further examples, other client applications are enabled through the client control such as a voice mail application and a telephone device. The client control described above makes use of a mouse, keyboard or other input devices to direct commands to the server control. A voice mail application is another input device that can be connected as a remote client control. As calls are directed from the PBX to the server control, these events are delivered to the voice mail client control. In response to these events, a voice mail application will typically answer the incoming call, take input from the calling party and record a message or redirect the call to another telephone extension. These actions taken by the voice mail application are presented as input to the client control which are then delivered to the server control as previously described. The present invention thereby eliminates the need for the voice mail application to be located within the distance restrictions of the PBX, and furthermore enables alternate connection means to this PBX similar to link 32 in
It is therefore apparent that the present invention accomplishes its intended objectives. While embodiments of the present invention have been described in detail, that has been done for purposes of illustration, not limitation.
Claims
1. A communication system comprising:
- at least one telephone switching mechanism;
- at least one computing device including software configured to display a virtual telephone;
- a phone server configured to couple the telephone switching mechanism and the at least one computing device;
- a digital phone emulation interface, configured to provide a digital connection between the at least one telephone switching mechanism and the at least one computing device;
- an application program interface configured to develop a command set from signals provided by the digital phone emulation interface, the command set configured to communicate with the software of the at least one computing device; and
- logic to convert between a synchronous and an asynchronous link.
2. The system of claim 1 wherein the application program interface includes a plurality of features found on digital telephones including dial, transfer, conference, hold, display information, multiple appearances, redial, message waiting indication, disconnect call, hook switch control, handset, speaker and microphone.
3. The system of claim 1 wherein the synchronous link connects the at least one telephone switching mechanism and the digital phone emulation interface.
4. The system of claim 1 wherein the asynchronous link connects the logic and the at least one computing device, the logic located within the phone server.
5. The system of claim 1 wherein the at least one telephone switching mechanism is a PBX.
6. The system of claim 1 wherein the digital phone emulation interface connects voice information to a voice packetization mechanism for delivery over a computer link.
7. A communication system comprising:
- at least one telephone switching mechanism;
- at least one computing device including software configured to display a virtual telephone;
- a mouse coupled to the at least one computing device, the mouse configured to provide access to a plurality of features of the virtual telephone;
- at least one phone server including a digital phone emulation interface, an application interface and logic;
- first and second control objects operatively connected via a first and a second socket thread, the first and second socket thread configured to transmit packetized light events and display information; and
- an event thread operatively connected with the first control object, the event thread configured to transmit events from the application program interface to the first control object.
8. The system of claim 7 wherein the first control object translates events for use on the at least one computing device and transmits commands to the application program interface.
9. The system of claim 7 wherein the second control object translates mouse clicks and key strokes from the at least one computing device into commands.
10. The system of claim 9 wherein the commands are subsequently packetized by the second socket thread.
11. A method of communication comprising:
- selecting a feature on a virtual phone;
- notifying a client control object of the selection;
- allowing a client's socket thread to transmit the selection to a server;
- building a packet and sending the packet to the server via a socket command;
- receiving the packet at the server's socket thread and unpacketizing the command;
- issuing a command from a server to an application program interface;
- passing the command from the application program interface to a digital phone emulation interface; and
- sending the command to at least one telephone switching mechanism over a synchronous digital data link.
12. The method according to claim 11 wherein the step of selecting involves a client key press transaction.
13. The method according to claim 11 wherein the step of selecting involves a hook state transaction.
14. A computer-readable storage medium including instructions that, when executed, cause a computer to:
- display a virtual telephone;
- send a light update data packet from a switching mechanism over a digital data link to an application program interface;
- receive the light update data packet via an event generated by the digital phone emulation interface and passed through by an application program interface;
- pass the light update data packet from an event thread to a control object;
- packetize the light update data packet and transmit the packet to a client;
- receive and unpacketize the light update data packet; and
- display a new light state on the virtual telephone.
15. The computer-readable storage medium of claim 14 wherein the digital phone emulation interface is configured to communicate with software configured to display the virtual telephone.
16. The computer-readable storage medium of claim 14 wherein the virtual telephone includes a plurality of features including dial, transfer, conference, hold, display information, multiple appearances, redial, message waiting indication, disconnect call, hook switch control, handset, speaker and microphone.
17. The computer-readable storage medium of claim 14 wherein the virtual phone is located on at least one computing device, the computing device being accessible from a remote location.
18. A method comprising:
- displaying a virtual telephone;
- sending a light update data packet from a switching mechanism over a digital data link to a digital phone emulation interface;
- receiving the light update data packet via an event generated by the digital phone emulation interface and passed through by an application program interface;
- passing the light update data packet from an event thread to a control object;
- packetizing the light update data packet and transmitting the packet to a client;
- receiving and unpacketizing the light update data packet; and
- displaying a new light state on the virtual telephone.
19. The method of claim 18 further comprising;
- activating one of a plurality of features with a mouse click.
20. The method of claim 18 wherein said packetizing is performed using a TCP/IP thread.
Type: Application
Filed: Oct 10, 2006
Publication Date: Sep 11, 2008
Applicant:
Inventors: Edwin M. Dylag (Grand Island, NY), Robert H. Fritzinger (Williamsville, NY)
Application Number: 11/545,381
International Classification: H04L 12/66 (20060101);