Programmable buttons for telephone user interface

Modern telephones now have the capability of implementing wide ranges of features such as speed dial, intercom, conference, transfer, etc. These features are typically provided by the telephone vendor, and accordingly have general applicability to wide classes of users of the telephone. With the exception of speed dial programmability, however, the features are not able to be customized for particular individual users or small groups of users. For example, a typical office telephone, whether conventional or voice-over-internet-protocol (VOIP) includes a large number of buttons which, when activated, implement particular features designated by the system vendor, such as mute, conference, hold, and the like. They sometimes also include a number of buttons—“speed dial buttons”—which may be programmed by the user to dial specific telephone numbers.

Implementation of functionality beyond that built into the telephone system at the time of sale typically involves memorizing detailed keystroke sequences, such as *9# to transfer a call to a subsequently-entered extension. Remembering these keystroke sequences can be frustrating, and results in all but the most commonly used functionality being ignored. There is essentially no easy way for a user or a system administrator to implement user specific functionality or even small user group specific functionality for a telephone system.

Another limitation of conventional telephone interfaces is that they do not provide feedback on real-time call state or current configuration of the function associated with the speed dial. Speed dialing is typically limited to functions controlled by a central telephone switch. As a result, there is no ability to program functions that affect the device, such as mute or the user interface, or to program non-telephony functionality, such as opening windows or invoking an Internet URL.

More recent telephony systems provide a “soft” client allowing control of calls from a display screen, e.g., ShoreTel's™“Personal Call Manager”™ or Cisco Systems™ “Unified Personal Communications Console.”™ Other telephony-enabled clients are available that integrate Instant Messaging and IM Presence, e.g. Microsoft™ “Office Communicator 2005”™ or Skype™. These systems provide a user interface that appears on a user's display screen. Such approaches allow dialing an extension by entering the name of the person to call, as well as other features such as speed dial. These systems, however, do not allow a user of an extension, or even a system administrator for that system, to define custom functionality for a particular button or buttons on a computer or similar device that is not physically a part of the telephone itself.

This invention enables customization of a user interface for a telephone when that user interface is provided on a personal computer, mobile interface, or other similar device coupled to the telephone system. The advantages of using the coupled device interface instead of the physical phone include the availability of a more complete alphanumeric keyboard, a larger display, or a portable wireless device, etc. The system enables a user or an administrator to program custom functions associated with individual buttons and sets of buttons to form toolbars to be displayed on the coupled device screen and thereby implement specific functionality for individual users or groups of users. For example, a user or administrator can program a button on the computer user interface to record a call at a specific extension. Typically, the invention is implemented by using toolbars which include buttons (or other appropriate user interface icons) in which each button may be programmed to implement specific functionality, such as desired by individual users or small groups of users. Instead of a toolbar, other user interfaces, such as a tool box dialog or dynamic menus, may be used to show a customized collection of functions. Preferably users or administrators can add “speed operation” buttons such as “record call at extension 5203, and send the recording to extension 4523,” “transfer to external number 803-555-6767,” “monitor call activity at the accounting department,” “show Instant Messaging presence for a specific contact,” etc. This specific customization to individual users' desired functionality can enable increases in convenience and productivity for users of such telephone systems.

This invention allows a system administrator and/or end users to define custom functions which are associated with abstract “buttons” or similar user interface indicators which are embodied as custom toolbar buttons on a client application running on a computer or mobile device such as a smart phone which is coupled to the telephone system. Each button, dynamic button, menu, or other user interface widget on the display screen implements a function, optionally coupled with one or more parameters such as a telephone number, and optionally endowed with properties like “presence,” to indicate that the feature is performing its function.

FIG. 1 illustrates a soft client running on a personal computer coupled to a desk telephone;

FIG. 2 illustrates programmable buttons as provided by this invention; and

FIG. 3 illustrates an interface for programming buttons such as illustrated in FIG. 2 .

FIG. 1 illustrates a soft client user interface as running on a personal computer coupled to a user telephone. Illustrated is a soft client 10 , i.e., a screen on a computer for a user to control her telephone. The user interface includes a conventional “Windows” menu bar 20 , enabling selection of various system wide functions. A system wide standard toolbar 30 is also shown. Toolbar 30 includes standard system-wide functionality such as “hang-up,” “transfer” etc. Another row 40 on the display allows dialing the phone with only the name of the person desired to be called. Finally a row 50 shows that a call is underway. The client interface presented is specific to the user and independent of the coupled device. If a user logs out of a computer and a different user logs in, the subsequent user receives an interface customized to their own personal and group configuration.

FIG. 2 illustrates an exemplary embodiment of the invention in the context of the soft client 10 , i.e., a screen on a desk telephone unit or on a personal computer for a user to control her telephone. In FIG. 2 an additional toolbar 60 has been defined to include specific features desired by the user of the interface. As shown, toolbar 60 includes specific buttons to perform functions “Night Bell” [ring a chime for after hours calls], “Whisper Page” [page a particular user where the other party talking to the user cannot hear the page], “Retry Busy” [add an outbound Contact Center call to a list of calls to retry later], “Supv Help” [call the supervisor for a Contact Center agent], “Dial VM” [dial a specified extension to leave a message without ringing the extension], “Trunk Flash” [Send a flash signal out the trunk associated with the call], “DDE Mesg” [Send a Windows DDE message that can contain information from the active call], “XMon 1893” [Monitor call activity at extension 1893], and “Record 1893” [Record call at extension 1893 and send the recording to extension 1762]. Below row 60 is a row 62 which enables a search engine function. Below row 62 , row 64 shows that a call with Glen Okita at 747-1893 is underway.

In a preferred embodiment toolbar 60 is defined on a per-user or per-group-of-users basis. As shown, the toolbar 60 is configured to have a multiplicity of programmable buttons or similar devices, and these buttons can be user specific or specific to a small group of users. The specific functionality of each button is programmed to implement the desired function, either with or without one or more parameters, such as an extension (or other telephone number). In some cases the button implements a function with a prompt to the user to enter one or more parameters. The buttons assembled into groups on toolbars. Each toolbar can be provided as a separate row in the user interface, or multiple toolbars may share a row, depending upon the geometry of the interface. Particular toolbars may be shown or hidden by the user by performing various steps with the device to which the telephone system is coupled.

Generally, the toolbar 60 settings are saved in a database and can therefore be moved from computer to computer, for example, if a user is reassigned to a different department in a company. In one implementation the administrator of the telephone system defines the toolbars and then assigns them out to users or groups of users requesting them. The buttons on a given toolbar may combine an operation or function with a parameter or parameters, thereby allowing one-click access to commonly performed operations, for example, transferring a call from a user to a defined extension in the accounting department. In addition, extension monitor or bridged call appearance buttons can be created, providing visual cues that a conference call is under way, an extension is being monitored, or other similar features. Buttons can also be created to execute software functions, for example browse a particular URL-initiated data transfer with a server, provide additional information to a person receiving a call based on the caller ID number, and other such features. Preferably, each toolbar is given a unique name, enabling the users to show or hide the toolbars as preferred.

Table 1 below illustrates typical functionality that can be implemented using the programmable buttons.

As shown in the table above, each programmable button on the toolbar 60 may be programmed to have a particular function listed in the left hand column of the chart. For some functions an extension or telephone number parameter is required, while for others parameters are optional, or not permitted. The particular types of parameter values for a function are shown in the third column. Some functions include an indication that that functionality defined by that button is in use, for example, by changing the color of the button. An example of that is the conference intercom button. The appearance of the button changes when the target extension associated with the button is in use. Of course, other desired features can be implemented in the same manner as those depicted.

In a preferred embodiment, the parameters supplied at configuration time are validated. For example, a function to transfer to extension 3452 cannot be configured if that extension does not exist in the system. Validation can be performed for the parameter types stored in the telephony system database, such as extensions, Call Handling Modes (CHM), Contact IDs, Agent IDs, etc. A parameter can be supplied and validated, but a later action may create a conflict with the original configuration. In a large system it is difficult for a user or administrator to keep track of all references of this extension. For example, a function to transfer to an existing extension 2345 can be configured. Later, one may try to delete extension 2345. At the time of attempted deletion, there are two ways to handle the conflict. One way is to prevent the deletion from occurring until all references to it are removed. If there are many references to an extension, this can be tedious. A preferred approach is to warn the administrator that the extension is referenced, provide a list of the references, and offer the option to automatically remove all the references to the extension. If the removed extension is an optional parameter, the button function is retained but the parameter is removed from the configuration. If the button has the extension as a required parameter, the button is automatically converted to an “unused” function. When the warning is presented, the administrator also has the option to cancel the delete or other operation that would create a conflict.

In another case, an extension or other value supplied as a parameter may be changed. Consider the same transfer to extension 2345 case above. It is also possible to change an extension from 2345 to 3456. In this case, any references to extension 2345 are automatically changed to refer to extension 3456.

Some of the configurable buttons have optional parameters. If all parameters associated with the function are supplied by the user or administrator at configuration time, then that action is performed when the button is pressed with no further user interaction. On the other hand, if the one or more parameters are not supplied, then an appropriate dialog box may be caused to appear so the user can supply the missing parameters. Where possible, parameters supplied by the user interactively are validated, or a selection box is provided that only contains valid choices. As one example, if a “transfer blind” button without a parameter is pressed, a dialog box appears requesting the extension to which the call is to be transferred. Only extensions that are currently available and valid may be selected using the dialog.

To enable toolbars having fewer than a specified number of configurable feature buttons or other desired icon types, an “unused” function is provided. Any group of “unused” buttons at the start or end of the list are ignored by the telephone system, of if they appear between “used” buttons, then they are interpreted as a divider for a toolbar. Thus, a user can have as few or as many programmable buttons as she desires or a system administrator permits. In another embodiment, an “unused” function is not necessary and the list of functions associated with a toolbar can be inserted or deleted individually.

In the preferred embodiment up to four toolbar layouts may be configured for each user. The layouts are ordered; the first layout applies to the first toolbar, etc. If a user with multiple layouts is assigned to a phone with fewer toolbars, that user will only see the buttons in the number of layouts available. Conversely, if a user with fewer layouts is assigned to a phone with more toolbars, the extra toolbars will be empty.

The button layout configuration illustrates a toolbar, enabling the administrator to individually configure each button. Buttons may be left empty. FIG. 3 is a screenshot of an interface 100 which enables setting the following for each button:

Button function 110 and 120

Button label 130

Button parameter 140 (see Table 1 above)

The button label appears adjacent to the button when it appears in the toolbar. In some cases, button labels can be selectively hidden in the toolbar. A button label can have an option to be shown always, shown if there is room in the toolbar, or not shown. When dynamic buttons are shown as a menu, the button label is always displayed.

Row 5 in interface 100 illustrates programming of a programmable button for a toolbar named “USPTO.” In row 5 a “Telephony” category has been selected. Categories are used to simplify presentation of the list of available functions by only showing functions that belong to a given category. A function may belong to more than one category. There is also the ability to show all functions in a single list. The function chosen is “Dial Mailbox,” a function to allow the user to dial his voicemail box. The programmable button will be labeled “Dial VM.” The target telephone number is 707-1740, that of Glen Okita. As illustrated the interface includes a search function to allow the programmer to search for a particular target telephone number.

Row 8 in the interface 100 illustrates an extension monitor function by which telephone 747-1893 is to be monitored. For extension monitor functions, as shown, the number of ring cycles before playing audible ringing, a default “no connected call” action, a default “connected call” action are also specified.

A series of Extension Monitor buttons are also provided. Extension Monitor buttons have additional parameters. In a preferred embodiment these Extension Monitor parameters are:

Show caller ID name and number always, only when call if offering, or never.

Number of rings cycles before playing audible ringing.

Furthermore, if the Extension Monitor button is pressed during a Transfer, Conference, or similar operation that is prompting for a number, the extension is used as the number. If the button is pressed when a call is offering on the monitored extension, the call is picked up. If the button is pressed when a call is held or parked on a monitored extension, the call is un-parked.

The visual state may reflect more than enablement of that function. For example, a “hang up” button may be grayed out if it is disabled. Each Extension Monitor button has a user-editable label and depicts the current status of the monitored extension. When the cursor is placed over the Extension Monitor button, a summary tool tip of the status of the monitored extension is provided. In a preferred embodiment this includes the name of the user, the state of the extension, the state of any other calls awaiting that user's attention, and other features as desired.

The action taken when a user presses an Extension Monitor button depends upon the current status of that extension, the user's own extension, and, of course the system programming. The two configuration options for Extension Monitor buttons are shown in Table 2 below:

When the user presses an Extension Monitor button, the program logic decides what actions to take. If there is more than one call on the monitored extension, the oldest call is answered. If there are held or parked calls on the extension, then the oldest held or parked call is processed. There is also an option to present a list of the calls held or parked and allowing the user to select which one to connect. Otherwise, if there is an active call on the user's own extension that is selected in the user interface, the “selected call action” is performed on that call, with the monitored extension as a target. Finally, otherwise, the “no selected call” action is performed, with the monitored extension as a target. Status of the monitored extension or contact can also affect the action of pressing the button. For example, if the extension is in an active call the function can be configured to send an IM message instead of placing a call.

Another special button provided by this invention is a “Bridged Call Appearance” button. These are buttons which by their visual state reflect more than being enabled or disabled. They also have a user editable label. These buttons are configured with an extension and stack position as a target. When a cursor us placed over one of them, it shows a summary of the status, namely the state and duration of the calls on that extension. In addition to the Extension Monitor and Bridged Call Appearance buttons, several other buttons are enabled to present information about a current state of that feature. For example, for pick up and unpark functions, if a there is a call to be picked up or unparked, the state, duration, and preferably connected party information of that call are displayed. Similarly, if the extension is in use, that will be displayed.

Administration of the toolbars containing the programmable buttons can be performed by individual users; however, preferably the toolbars are managed by a system administrator. In a preferred embodiment, the system administrator configures the programmable buttons on the toolbar to provide both group toolbars and personal toolbars. The group toolbars, once created, are assigned to user groups so that each user in the group has access to the common toolbar. Such a toolbar typically includes common functions for that group, for example, enabling inventory to be checked, accounting to be conferenced onto the call, shipping to be notified, etc. The group toolbars are made available to all of the users in a designated group. For most toolbars, each user can choose to hide or display that toolbar. In some embodiments, the administrator has the option to require a group or personal toolbar to be shown in the GUI.

If the personal toolbars are to be programmed by the users, the personalized toolbars are implemented by providing users with links to a screen where the individual toolbar can be configured, for example, with a drag-and-drop interface, prompts for extension numbers, etc. The screen can be implemented as a conventional dialog or as a Web page. The buttons can be pre-defined to have standard icons; however, user-designed or user-selected icons may also be employed. Conventional drag-and-drop or other user interface technology can be used to enable the user to configure the toolbars with the programmable buttons. Of course, copies of commonly used toolbars or buttons can be stored on the system, enabling the user to select from among predefined lists. If users wish to change a button's icon, various approaches are provided. For example, user-supplied icons can be provided in .BMP format, and with the same color depth and using the same color palette as the application-supplied icons. Users can also provide their own icon artwork for any programmed button.

In some embodiments, the function of a button occurs in a separate associated system. The associated system is integrated using inter-process communication that allows status and commands to be exchanged between the telephony system and the other system. In a preferred embodiment, the interface to the Contact Center integration is offered by an Active-X control. The Active-X control does inter-process communication with a Contact Center system to perform functions specific to this feature. In operation, when the client application is first activated, the users system determines if it is a Contact Center client. If so, it instantiates the Agent Toolbar ActiveX control, and then verifies that the control is version compatible. After the control has been initialized, the client calls appropriate methods to initialize the system.

During this process, the Contact Center programmable buttons features are installed and initialized. The functionality includes that shown in Table 4 below.

If any button is programmed with an invalid argument, the function will behave as if the argument was not supplied. In this case, the Agent Toolbar will open a dialog to collect a valid argument. An enabled option is shown with an enclosing box (XP style), or in a pushed-un-pushed state. Some of the buttons on the toolbar may be toggle buttons. A toggle button has on and off behavior, such as mute and un-mute of a phone. The toggle button has real-time update where changing the state of mute using the button on the phone is also reflected in the GUI display, and vice-versa. Other states that are shown in synchronized fashion across multiple devices include CHM state, call forward always condition, agent login/logout, whisper page mute, and toggle hands-free mode.

As mentioned above, in the preferred embodiment the programmable buttons can be configured by a system administrator or a user employing various well known programming tools. In the example below we assume a system administrator configures the buttons, however, as will be apparent the description is equally applicable to a user configuring the buttons.

Typically the programming functionality will be implemented by the user selecting an option on a menu, such as “Program Buttons.” Assuming the user has sufficient rights, i.e., the administrator allows them to reprogram their interface, or a portion thereof, the item will be selectable.

Some functions are programmed using freeform strings that allow text substitution of information from an active call. Table 3 illustrates sample variable names for a particular free form strings for programming various buttons.

If the input string contains any variables, the button is only enabled if a call is selected; otherwise, it is grayed out. If the string for a function has no substitution strings, then it is always enabled.

The foregoing has been a description of a preferred embodiment. It will be appreciated that variations from the preferred embodiment will not depart from the scope of the invention as defined by the appended claims.